监控一个数据库系统是十分复杂的工作，实际上要监控好一个数据库系统，需要极高的技术积累和长期的经验积累。不过高水平的DBA又往往不愿意干简单的监控工作。因此培养一些懂得监控数据库关键指标的初级DBA对企业来说十分重要。今天老白就和大家聊聊oracle数据库中需要关注的一些关键指标。
上面这张图中的红色框部分就是对于这个数据库实例，老白所关心的关键指标。前面几个就不提了，不论是何种数据库，操作系统资源的使用情况是肯定要关注的。多了一项不常见的，就是操作系统IO延时。从操作系统角度看IO延时和从数据库角度看IO延时还是不太的，虽然二者有着较大的关联。OS延时还包含了一些数据文件之外的IO延时情况。如果IO延时突然变得过高，可能说明存在一些数据库的健康风险。大家可能看到一些不太常见的指标项，实际上这些指标项不是一个简单的指标，而是一个模型评估值。比如共享池相关等待事件数量，这个指标可以从侧面反映当前共享池的风险，这种风险评估的方式，避免了直接访问X$视图去扫描内存中的HEAP结构，避免数据库运维工具造成的运维灾难。很多DBA可能总喜欢去看表空间的使用率，对于表空间的使用情况，过于频繁的访问也是存在较大风险的。对于系统中表空间容量较大，段的数量很大的系统，每隔几分钟统计一次表空间使用率可能会带来灾难性的后果。老白就见过好几次这样的情况。对于一个超过10TB，存在几十万个段的数据库，有可能采集一次表空间使用率需要几十分钟，如果每隔5分钟采集一次，那么就可能对系统的IO造成很大的影响，甚至采集脚本一个小时都无法正常跑完。一个表空间采集脚本搞挂一台国产一体机的事情也是不止一次发生过的。对表空间使用率的监控最好的做法是每天晚上非业务高峰期采集一次，作为一个日检的项目。DBA每天关注下日检的告警情况，如果表空间的使用风险达到一个较高的级别，则尽快采取措施，从而避免表空间问题带来的数据库允许问题。可能有朋友要问了，如果应用出问题，导致一个小时内把一个表空间撑爆了，这种情况你如何监控呢？确实，如果每天分析一次表空间风险，这种情况是无法发现的。不过我们可以通过其他方式来发现这个问题，比如通过REDO量的异常增长来发现这种不正常的问题。另外可能有些人已经留意到了，老白用了表空间风险而没有用表空间使用率。是的，表空间使用率100%并不能说明系统有风险了，因为很多数据文件都是自动扩展的，如果卷组或者磁盘组有足够的空间那么，100%使用率的表空间也是没有太大风险的。有朋友又想了，如果这样，我们只关注ASM磁盘组的使用率不就行了。可能还有一个问题需要考虑，就是如果使用的是普通的数据文件，而不是BIGFILE，那么一个数据文件的数据块的数量是有限的(2的22次方-1)，因此某个数据文件的最大大小是有限的。基于这个老白在系统中引入了表空间风险这个复合指标。其实对于数据库监控来说，复合指标的引入可以大大减轻一线运维人员的监控负担。比如针对等待事件，老白引入了一个指标“等待事件风险等级”，通过一个复杂的模型，把等待事件的风险做了一个直观的分级。当我们看到高风险等级的时候，就可以采取一些主动的分析，从而避免系统出现更为严重的问题。
