ANBOB™

Oracle提供了非常有用的工具和视图来帮助数据库管理员进行数据库管理。其中包括一些处理空间问题的方案。其中一个这样的视图是DBA_TABLESPACE_USAGE_METRICS, DBA_TABLESPACE_USAGE_METRICS是基于GV$FILESPACE_USAGE，它提供了整体大小和已使用空间的“缩略图”视图。不幸的是，在12.x版本中，该视图无法准确报告UNDO表空间的使用情况，这是由于该视图定义在多个版本中没有改变所导致的结果, 因为CDB的引入早期12c没有DBA_TABLESPACE_USAGE_METRICS考虑到CON_ID问题显示数据错误的bug。。在11版和12版之间，Oracle决定更改GV$FILESPACE_USAGE中FLAG列中数据文件标识符的方式。另外有些ORACLE周边工具为了简化查询，利用该VIEW日常监控表空间使用率，一客户反馈页面无返回数据，记录一下监控工具的遗漏.

V$FILESPACE_USAGE 定义 — 11.2.0.4

select VIEW_DEFINITION  from V$FIXED_VIEW_DEFINITION  where view_name='GV$FILESPACE_USAGE';
VIEW_DEFINITION
----------------------------------------------------------------------------------------------------
SELECT
inst_id,                 -- INST_ID NUMBER
KTTEFINFOTSN,            -- TABLESPACE_ID NUMBER
KTTEFINFOFNO,            -- RFNO NUMBER
KTTEFINFOUSP,            -- ALLOCATED_SPACE NUMBER
KTTEFINFOSIZE,           -- FILE_SIZE NUMBER
KTTEFINFOMSIZE,          -- FILE_MAXSIZE NUMBER
KTTEFINFOSCNB,           -- CHANGESCN_BASE NUMBER
KTTEFINFOSCNW,           -- CHANGESCN_WRAP NUMBER
KTTEFINFOFLAG            -- FLAG NUMBER
FROM
X$KTTEFINFO 

Note:
在很久以前（版本12之前），UNDO表空间的数据文件在GV$FILESPACE_USAGE中被标记为6，并且它是唯一以这种方式进行标识的表空间。因此，视图DBA_TABLESPACE_USAGE_METRICS依赖于该标记来识别并随后报告UNDO使用和空间。

GV$FILESPACE_USAGE视图的更新并不是很及时，这次查询GV$FILESPACE_USAGE 返回0条记录。其实在DBA_TABLESPACE_USAGE_METRICS View Returns No Rows When db_files Limit Is Reached (Doc ID 1903251.1)有记录该问题。是因为数据文件个数达到了db_files 参数限制。

SQL> show parameter db_file

SQL> select max(file#) from v$datafile;

Note:
解决方法增加db_files 参数，（静态需要重启DB)

目前最好查询已知包含相关准确数据的视图（DBA_DATA_FILES、DBA_FREE_SPACE）。 但有可能查询DBA_FREE_SPACE慢的问题,但比较常见的原因是：
1, 回收站有大量的对象
2，fixed或dictionary 对象统计信息缺失或过时

给我们的提示时监控缺失了db_files的监控告警，和不应该偷懒使用了V$FILESPACE_USAGE监控表空间使用率，而应用使用DBA_DATA_FILES、DBA_FREE_SPACE。

— enjoy —

打赏

微信扫一扫，打赏作者吧～