所有企业的业务数据库系统都是重中之重，如何来保证系统安全性与稳定性，需要DBA每日来通过相应的巡检指标进行相关记录，今天我们就来简单说一下

OS健康检测

将CPU、内存、磁盘I/O状况、网络状况等填到上午高峰期检查情况和下午高峰期检查情况栏里。对于CPU和内存、磁盘IO记录数值，对于网络状况，记录正常或不正常。

检测CPU情况

可以看到，1分钟，5分钟，15分钟的负载都为0，系统很健康的说

检测内存状况

可以看到，内存虽然占用了90%以上，但是SWAP交换分区并没有被占用，所以属于业务正常情况

检测硬盘状况

可以看到，文件系统只用到了不足10%，还有很大的磁盘空间，很健康

通过vmstat命令检测系统

1、进程procs：

r：在运行队列中等待的进程数 。

b：在等待io的进程数 。

2、Linux 内存监控内存memoy：

swpd：现时可用的交换内存(单位KB)。

free：空闲的内存(单位KB)。

buff: 缓冲去中的内存数(单位：KB)。

cache：被用来做为高速缓存的内存数(单位：KB)。

3、Linux 内存监控swap交换页面

si: 从磁盘交换到内存的交换页数量，单位：KB/秒。

so: 从内存交换到磁盘的交换页数量，单位：KB/秒。

4、Linux 内存监控 io块设备:

bi: 发送到块设备的块数，单位：块/秒。

bo: 从块设备接收到的块数，单位：块/秒。

5、Linux 内存监控system系统：

in: 每秒的中断数，包括时钟中断。

cs: 每秒的环境(上下文)转换次数。

6、Linux 内存监控cpu中央处理器：

cs：用户进程使用的时间。以百分比表示。

sy：系统进程使用的时间。以百分比表示。

id：中央处理器的空闲时间。以百分比表示。

假如r经常大于4，且id经常小于40，表示中央处理器的负荷很重。 假如bi，bo 长期不等于0，表示物理内存容量太小。

通过iostat命令检测系统

%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的

svctm: 平均每次设备I/O操作的服务时间

await: 平均每次设备I/O操作的等待时间

avgqu-sz: 平均I/O队列长度

如果%util接近100%,表明i/o请求太多,i/o系统已经满负荷,磁盘可能存在瓶颈,一般%util大于70%,i/o压力就比较大,读取速度有较多的wait.同时可以结合vmstat查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)。

await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢。

通过sar命令检测系统

sar命令较为复杂，牵扯参数较多，这里就不再详解了

检测Oralce进程

Oracle后台进程是oracle实例的重要组成部分，后台进程是否正常工作直接决定了Oracle运行的正常与否。如果Oracle后台进程停止，将导致Oracle实例的崩溃。(最少应该有dbwr、lgwr、smon、pmon、ckpt等几个主要进程)

检测Oracle监听

Oracle监听进程侦听从客户端(如应用服务器)发来的对数据库的连接请求，然后为该请求建立一个连接。如果监听进程关闭，则无法建立起应用服务器与数据库服务器之间的连接。(SID最少应该有一个为READY状态)

检测Oracle死锁

死锁是由于2个session互相交叉阻塞对方而产生的，Oracle会自动探测到死锁并回滚其中的一个事务。死锁一般是由于应用逻辑造成的，发生死锁时，需要将导致死锁的SQL反馈给开发人员，以进一步解决。(也应该时常检测alert日志，看看有没有严重的或者频繁出现的ORA-错误并解决)

Oracle检测

检查Oracle实例状态

正常情况下，Oracle实例状态处于OPEN状态，通过检查此项，可以确定Oracle实例是否正常。

检查Oracle数据库状态

通过查看Oracle数据库状态，可以检查数据库名称、数据库归档模式、数据库打开模式，从而确定数据库是否处于正常的状态。(测试库未开启归档，属于正常)

检查Oracle会话状态

当前会话数是当前从应用服务器到数据库服务器之间建立的连接数量，这个数量与数据库的负载之间有密切的联系，一个稳定运行的数据库里，会话数量应保持平稳，如果出现会话数量大幅增加或大幅减少，就意味着可能出现了问题，需要进一步查找原因。(需要与日常稳定数值对比)

检查锁等待会话

通过查看会话的锁等待状况，可以了解数据库中是否有锁资源争用的现象，如果出现了时间较长的锁等待现象，可能会严重影响业务的正常运行。因此，如果在检查中发现数据库锁等待问题，需要进一步检查问题发生的原因。(返回值为0，表示正常)

检查控制文件状态

控制文件是数据库的重要组成部分，如果所有的控制文件发生损坏，将导致数据库无法打开，通过检查控制文件状态，可以及时发现损坏的控制文件，及时采取补救措施。(STATUS为空，状态正常)

检查Oracle重做日志文件状态

重做日志文件是oracle数据库的重要组成部分，通过检查重做日志文件可以及时发现重做日志文件出现的损坏等问题。(STATUS为空，TYPE为ONLINE，状态正常)

检查Oracle表空间状态

正常情况下，表空间应处于online状态，如果表空间处于offline状态，则用户将无法访问表空间，通过检查表空间状态，可以及时发现那些表空间处于非正常状态。(STATUS为ONLINE，状态正常)

检查Oracle回滚段状态

在回滚段处于自动管理的模式下，回滚段的状态是自动转换的，由Oracle控制。(STATUS为ONLINE，状态正常)

检查Oracle数据文件状态

通过检查Oracle数据文件状态，可以及时发现发生数据损坏的数据文件。(STATUS：系统表空间为SYSTEM，其余表空间为ONLINE，状态正常)

检查Oracle所有对象状态

在正常情况下，数据库中所有对象状态都应该是VALID，如果出现了处于INVALID状态的对象，则需要进一步检查，确定是否需要重新编译。(无返回值，状态正常)

检查Oracle相关资源使用情况

通过查看v$resource_limit视图，可以查看数据库初始化参数设置是否合理，如果有不合理或者超过参数设置范围的情况，就需要考虑进行适当的调整。(返回结果中“LIMIT_VALU”‐“MAX_UTILIZATION”>5，状态正常)

检查Oracle表空间增长情况

Oracle数据库的数据是存放在表空间里，如果表空间剩余空间不足，数据库无法继续写入数据，数据库将报错。因此，及时检查表空间使用情况，确保表空间剩余空间维持在20%以上，对数据库的正常稳定运行来说具有重要意义。(所有表空间的PCT_FREE均大于20%，状态正常)

检查Oracle扩展异常对象

数据库中每个segment是由extent组成，而每个segment所能容纳的extent数量是有限制的，dba_segments中的max_extents列就是每个segment所能容纳的最大extent数量。如果segment中的extent数达到了这个数量的限制，则segment将无法继续扩展，数据库将报错。因此，通过检查每个segment中的extent数量，可以及时发现数据库中扩展异常的对象，以便于采取进一步参数，避免出现segment无法扩展的问题出现。(无返回值，状态正常)

检查Oracle系统表空间

Oracle系统表空间一般是用于存放sys和system用户数据的，通常其它用户的数据是不能存放在系统表空间中，通过检查这项内容，可以发现有哪些非sys和system用户的数据被存放在系统表空间里，以防止其存储空间被过度占用而引起数据库问题。(此类用户属于内部用户，状态正常)

除了上述基本检测外，还需要检测每日的RMAN备份情况(全备或者增量备份)，逻辑备份情况(EXPDP或EXP)，并生成statspack与AWR报告，对数据库进行具体性能分析。