必须用dataobj#而非obj#关联dba_objects，因DDL会重置data_object_id导致obj#错配；space_used_delta单位为块，需乘对应表空间block_size转GB，并过滤负值及首快照异常。
直接用 dba_hist_seg_stat 算段增长率，必须先解决 object_id 和 data_object_id 错配问题——ddl（如 truncate、alter table move）会重置 data_object_id，但历史快照仍按旧 obj# 和 dataobj# 关联，硬连表会导致空间增量归错对象。
为什么不能直接 GROUP BY obj# 求 space_used_delta 累计？
因为 DBA_HIST_SEG_STAT 中的 obj# 对应的是采集时刻的 object_id，而 dataobj# 才真正标识段的物理存储实例。一次 TRUNCATE 后，object_id 不变，data_object_id 变更，新插入数据产生的增长会被记在新 dataobj# 下；但若只按 obj# 聚合，就把新旧两个物理段的增长混在一起，结果虚高或断层。
- 查证方式：
SELECT object_id, data_object_id FROM dba_objects WHERE segment_name = 'YOUR_TABLE'，执行 DDL 前后对比 - 典型错误现象：某表显示单日增长 50GB，但
dba_segments.bytes只增了 2GB——大概率是dataobj#切换后，脚本把历史快照里旧段的残留 delta 全算进来了 - 正确做法：所有关联必须用
dataobj#，且需和dba_objects的data_object_id对齐，不能用object_id
如何安全提取某张表的准确日增长量？
核心是绑定时间窗口 + 按 dataobj# 追踪，再过滤掉非正常快照（如快照间隔内发生 DDL 导致 space_used_delta = 0 或异常跳变）。
- 先确认目标表当前
data_object_id：SELECT data_object_id FROM dba_objects WHERE owner = 'SCHEMA' AND object_name = 'TABLE_NAME' - 再查该
data_object_id在最近两天快照中的累计增长：SELECT SUM(space_used_delta) * (SELECT block_size FROM dba_tablespaces t JOIN dba_segments s ON t.tablespace_name = s.tablespace_name WHERE s.owner = 'SCHEMA' AND s.segment_name = 'TABLE_NAME') / 1024/1024/1024 AS gb_growth FROM dba_hist_seg_stat s WHERE s.dataobj# = :bind_dataobj_id AND s.snap_id IN (SELECT snap_id FROM dba_hist_snapshot WHERE begin_interval_time >= TRUNC(SYSDATE) - 1) - 注意：
space_used_delta单位是数据库块，不是字节，必须乘以对应表空间的block_size才能转 GB - 避免跨快照周期误算：如果某次快照前刚
TRUNCATE，后续第一个快照的space_used_delta会极大（从 0 突增），应结合dba_hist_snapshot的end_interval_time判断是否为“首快照”并单独处理
DBA_HIST_SEG_STAT 的采样盲区有哪些？
它不记录段被 DROP 或 RECYCLE 的动作，也不捕获 LOB 段中未启用 SECUREFILE 时的隐式扩展细节；更关键的是，快照频率默认 60 分钟，短于这个间隔的爆发写入（如批量导入）可能只被捕捉到起点和终点，中间增长被平滑掉。
-
space_used_delta = 0不代表没增长，可能是两次快照间段未触发检查点或缓存未刷盘 - 对于
INDEX或LOBINDEX，其增长常滞后于主表，因 Oracle 可延迟更新索引块——需同步查dba_hist_seg_stat中对应索引的dataobj# - 分区表要注意：每个分区是独立段，
dataobj#各不相同，不能只查主表名，得用dba_tab_partitions展开所有data_object_id - 如果发现某段长期
space_used_delta为负，不是收缩，而是统计误差或快照时读到了临时分配未提交的空间，应过滤掉space_used_delta 的异常值
真正难的不是拼出 SQL，而是每次看到异常增长时，得立刻反查 dba_hist_ddl_log（如果启用了）或 v$transaction 活动事务，确认是不是有人在跑 INSERT /*+ APPEND */ 却忘了 COMMIT，导致空间被占着不释放——DBA_HIST_SEG_STAT 只告诉你“涨了多少”，但不会告诉你“谁在涨”。
