DBA_TAB_PARTITIONS是Oracle 19c中查看分区表各分区元数据最直接的视图，但需DBA权限且HIGH_VALUE字段为未解析的RAW格式；普通用户应改用USER_TAB_PARTITIONS或ALL_TAB_PARTITIONS。
dba_tab_partitions 是 oracle 19c 中查看分区表「每个具体分区」元数据最直接的视图，但它要求 dba 权限，且返回的是原始、未解析的 high_value 字段——这点不注意，查出来的边界值就是一串无法阅读的 raw 数据。
为什么查 DBA_TAB_PARTITIONS 常看到 HIGH_VALUE 是乱码
Oracle 把分区边界值（比如 VALUES LESS THAN (DATE '2024-01-01')）以内部二进制格式存进 HIGH_VALUE 字段，直接 SELECT high_value FROM dba_tab_partitions 只会返回类似 HEXTORAW('012C...') 的字符串。这不是 bug，是设计如此。
- 必须用
DBMS_METADATA.GET_DDL或动态 SQL 配合XMLTYPE解析，才能还原可读值 - 对
RANGE分区，HIGH_VALUE表示“小于该值”，不是“包含该值” -
LIST分区的HIGH_VALUE实际为空（NULL），真正值在DBA_TAB_SUBPARTITIONS或子分区列中隐含存储
查分区名、位置、表空间这些基础信息可以直接用
不需要解析，以下字段开箱即用：
-
PARTITION_NAME：分区名称，如P_2023_Q1 -
PARTITION_POSITION：数字序号，从 1 开始，顺序反映创建时的物理排列 -
HIGH_VALUE：仍需解析，但LOW_VALUE在 19c 中基本不用（仅 HASH 分区有参考意义） -
TABLESPACE_NAME：该分区实际存储的表空间，可用于验证是否按规划分散存放 -
NUM_ROWS：统计信息中的行数（需ANALYZE或DBMS_STATS刷新过才准）
示例语句：
SELECT partition_name, partition_position, tablespace_name, num_rows FROM dba_tab_partitions WHERE table_owner = 'SCOTT' AND table_name = 'SALES';
没有 DBA 权限时，别硬查 DBA_TAB_PARTITIONS
普通用户执行会报 ORA-00942: table or view does not exist。这时候应切换到权限匹配的视图：
- 查自己拥有的分区表 → 用
USER_TAB_PARTITIONS - 查自己能访问的所有分区表（含授权的）→ 用
ALL_TAB_PARTITIONS - 确认某张表是否分区 → 先查
USER_TABLES.PARTITIONED = 'YES'，再决定是否继续查分区视图
三者结构完全一致，只是数据范围不同，OWNER / TABLE_OWNER 字段名略有差异，注意 WHERE 条件写法。
DBA_TAB_PARTITIONS 不显示分区键，得配合其他视图
这个视图只管“分区本身”，不管“按什么分”。要定位分区逻辑，必须联查：
- 分区类型和键列 → 查
DBA_PART_TABLES（看PARTITIONING_TYPE） +DBA_PART_KEY_COLUMNS（看COLUMN_NAME） - 子分区信息 → 若
DBA_PART_TABLES.SUBPARTITIONING_TYPE不为空，再查DBA_TAB_SUBPARTITIONS - 分区索引状态 → 单独查
DBA_IND_PARTITIONS，不能从本视图推断
单独依赖 DBA_TAB_PARTITIONS 容易误判复合分区结构，尤其当 SUBPARTITIONING_TYPE = 'HASH' 但主分区边界模糊时。
真正麻烦的不是查不到，而是查到了却看不懂 HIGH_VALUE ——它像一把没给钥匙的锁。解析它需要额外步骤，而多数运维场景其实只需要 PARTITION_NAME 和 TABLESPACE_NAME 就够用了。别一上来就写复杂解析逻辑，先确认你到底需要什么。
