Oracle数据库巡检模板 | 周末送资料
XXXXX
Oracle数据库健康检查与评估
（模板）
1. 检查介绍
1.1 检查系统
系统主要包括1个数据库，具体情况如下：
数据库名称 | |
数据库实例名 | |
应用名称 | |
应用类型OLTP/DSS/Batch | |
开发工具 | |
应用简介 | |
RDBMS 版本 | |
CRS 版本 | |
所有数据文件所占磁盘空间 | |
SGA target size | |
DB_BLOCK Size | |
表空间个数 | |
数据文件个数 | |
控制文件个数 | |
日志文件大小 | |
日志组数目 | |
每组日志文件成员数量 | |
归档方式 | |
并发用户量 | |
性能需求 |
1.2 检查范围
本次检查仅限于数据库。在这次检查中对数据库配置和数据库性能进行了分析。本报告提供的检查和建议不涉及具体的安全分析和应用程序的具体细节。
以下提请注意：本次检查仅历时1天，其中还包括了提交分析报告的时间，所以在具体的应用程序性能方面并不加以深入。
检查方面 | 具体检查内容 |
硬件配置 | 主机配置 |
共享内存参数 | |
信号量 | |
操作系统中与数据库相关主要参数 | |
操作系统数据库相关要求补丁 | |
系统配置 | 硬盘可用空间 |
CPU利用率 | |
数据库版本 | |
数据库配置 | 数据库产品选项 |
数据库参数 | |
运行日志和跟踪文件 | |
控制文件 | |
Redo log文件 | |
归档Redo log文件 | |
数据文件 | |
表空间 | |
回滚段管理 | |
安全性管理 | |
数据库简单风险评估 | 监听器的设置 |
数据库sql*net配置 | SQL*Net设置 |
TNSNAMES设置 | |
数据库各项命中率 | |
数据库性能 | 等待事件 |
AWR统计信息分析 | |
数据库I/O性能 | |
索引/行迁移/行链接 | |
Sort信息统计 | |
Enqueue等待分析 | |
Latch分析 | |
Resource Limit分析 | |
Top SQL 语句 | |
备份 | |
恢复 | |
数据库备份策略评估 | 根据客户要求只能检查一项 |
数据库特别关注点检查 |
2. 硬件配置
以下列出系统主机的主要配置情况
2.1 主机配置
机器名 | |
用途 (Prod, Test, Development) | |
所在城市，物理位置（机房，远程） | |
操作系统及版本 | |
内存 | |
cpu |
建议：
目前系统配置满足数据库要求，操作系统参数设置合理。
3. 系统配置
和数据库相关的操作系统配置将被检查，包括以下方面：
操作系统数据库相关要求补丁
存放oracle文件的硬盘区可用空间(oracle文件包括：数据文件，控制文件，在线redo logs，归档redo logs，运行情况文件和跟踪文件)。
硬盘利用率。
CPU利用率。
3.1 操作系统数据库相关要求补丁
建议：
3.2 硬盘可用空间
硬盘可用情况如下示：
数据库XXXX的硬盘使用率情况如下：
Filesystem kbytes used avail %used Mounted on
数据库YYYY的硬盘使用率情况如下：
Filesystem kbytes used avail %used Mounted on
建议：
目前该数据库服务器中还没有其他硬盘空间使用率超过90%的分区。如果有需要引起注意并且及时增加硬盘空间的容量。
3.3 CPU 利用率
CPU利用率的统计时间是：yyyy-mm-dd hh:mi---- yyyy-mm-dd hh:mi
1. top/ glance
2. vmstat2 20
参考值：
1. 最大CPU使用率：60%--70%
2. 系统进程与用户进程占用CPU最大比率：40/60
数据库XXXX:
数据库YYYY:
从上述的情况中看出，数据库:服务器CPU idle基本在75%以上，CPU资源较为空闲。
建议：
当CPU的使用率超过80%，要注意监控是否有僵死进程，如果有僵死进程占用CPU，需要将僵死进程kill掉。如果有正常进程占用大量CPU，需要查看是否属于正常业务进程等。
4. 数据库配置
本次检查工作主要针对数据库XXXX。
4.1 数据库版本和单独补丁
目前已经安装的单独补丁列表如下：
opatch lsinventory -oh$ORACLE_HOME
Patch | Base Bug(s) | Installed on |
建议：
4.2 CRS版本和单独补丁
CRS安装单独补丁列表如下：
opatch lsinventory -oh$ORA_CRS_HOME
Name | Version | Installed on |
建议：
4.3 ORACLECLUSTER配置
OCR使用和备份都正常。相关CRS的资源和服务都正常。
4.4 数据库产品选项
当oracle软件安装时，会选择要安装的产品。有某些产品的安装是需要license的，本次检查不涉及license问题。一般，很多系统安装的数据库产品选项根本未被使用。以下列出的安装产品选项可供未来的应用开发参考，或是可以被确认有哪些产品选项未在原计划之内。
以下是数据库安装的产品选项：
Parameter | Value |
4.5 初始化参数文件
数据库SPFILE参数指定了当前使用的数据库配置参数，在数据库启动时被使用。在附录A列出了数据库所有的非默认值的参数。
建议：
1. 数据库的参数可以看出大部分都是经过精心设置的。
2. 建议调整的参数值，请在测试环境数据库中测试确认之后，再调整于生产环境数据库。
4.6 CRS日志文件
从Oracle 10g RAC版本开始，新增加CRS组件。CRS对于RAC使用是必不可少，因此crs的稳定对于RAC数据库的正常运行至关重要。在健康检查中会检查CRS、CSS和EVM的LOG信息
建议
检查CRS其他相关进程日志，没有发现问题。
4.7 RDBMS运行日志和跟踪文件
Oracle 数据库进程生成跟踪文件来记录错误或冲突，这些跟踪文件可以用来进一步分析问题。数据库参数'max_dump_file_size'限制了这些跟踪文件的大小(以操作系统块的大小为单位)。应当有足够的硬盘空间来容纳最大值的设置，否则的话应当修改上述参数的设置。
如果参数'max_dump_file_size'设得太大，会超过硬盘空间容量；如果设得太小，又不能容纳足够的出错信息供oracle 支持服务部门分析问题。此参数可以在数据库会话级设置，这样可以有选择性地设置较大值。
注意每天监控运行日志文件中的出错信息，以便于在问题还是隐患的时候及时发现并解决掉。建议每月初将当前的alert.log重新命名以作备份，同时也可以避免alert.log文件变得太大不易管理。
在数据库:实例的运行日志文件发现的最近一月内的主要错误如下所示：
1.……
2.……
建议：
4.8 控制文件
每个数据库至少有一个控制文件。控制文件记录了数据库的物理结构及同步信息。
Control filelocation
控制文件路径如下：
Name | Status |
目前所有的控制文件文件存储在已经做了硬件RAID的磁盘阵列上面，提供了硬件级别的保护。
建议 :
4.9 Redolog 文件
对于恢复操作，最为关键的结构是在线RedoLog。在线Redo Log一般由两个或两个以上预先分配的存储数据库变化的文件组成。为了防止例程故障，每个数据库的实例都有相关的在线Redo Log。
每个数据库至少有两个RedoLog组，每组至少有一个日志文件。Oracle的多重在线RedoLog文件可以确保在线日志文件的安全。对于多重在线Redo Log文件，LGWR同时将相同的Redo Log信息写入不同的Redo Log文件中，从而减少单个文件丢失的损失。
当Oracle无法访问一个Redo Log文件时，这个文件状态变为INVALID。当Oracle推测一个Redo Log文件不完整或者不正确时，它的状态变为STALE。当一个STALE的文件被重用时，即其所在日志文件组活动时，此文件也能够使用。
在线Redo Log文件减少了数据库数据丢失的损失，比如当发生例程故障时，没有被写入数据文件的数据可以从在线Redo Log文件中恢复。
Group # | Thread # | Sequence # | Bytes | Members | Archived | Status | First Change # | First Time |
建议：
4.10 归档Redo log 文件
Oracle允许将写满的在线Redo Log文件存放在一个或多个脱机位置，即归档Redo Log。在线日志文件通过归档写入归档日志文件。后台进程ARCn自动进行归档操作。您能通过归档日志进行：
在线备份
基于时间的恢复
Archived Redo Log Settings
Parameter | Value |
建议：
这里能够很好地在运行环境中使用归档Redo Log。这样就能够进行基于时间的恢复。监控归档日志文件所暂时存放的磁盘空间，根据实际情况调整归档日志文件备份到磁带的频度。
4.11 数据文件
数据文件是数据库分配的物理文件。在Oracle数据库中，一个表空间可以包含一个或多个物理文件。而一个数据文件则只能关联一个表空间和一个数据库。Oracle通过分配一定的磁盘空间以及所需要的文件头空间，为每个表空间创建一个数据文件。
Data file locations
检测数据文件的位置。当数据文件增长过度，数据库中必须添加数据文件。应该避免“哪里有空间，哪里建文件”的错误方法，因为这样会增加备份策略和文件维护的复杂性。下面列出部分数据文件的位置。
Status | Name | Tablespace | File Number | Relative File Number | Size | Used (MB) | Used (%) | Autoextensible |
建议：
目前看来，数据文件存放位置基本准确。
Autoextend capabilities
通过自动扩展命令进行数据文件的自动扩展。假定数据文件无法分配所需空间，那么它将提高数据文件的大小以获得更多空间。
建议：
4.12 表空间
每个数据库由一个或多个逻辑存储单位，即表空间，所组成。而表空间则由逻辑存储单位段所组成。而段将被分为多个片。
TablespaceManagement
以下是关于数据库表空间管理的信息。
Status | Name | Type | Extent Management | Segment Space Management | Size (MB) | Used (MB) | Used (%) |
建议：
Tablespace Default Storage Management
每个表空间中，可以为创建的对象指定缺省的存储参数。创建对象时指定的存储参数将覆盖缺省值。如果在创建对象时没有指定存储参数，那么系统将使用缺省值。
表空间缺省存储情况：
数据库表空间的管理方式均为本地管理，这有利于减少表空间级别的碎片，同时避免了DB在进行空间管理时对数据字典表（FET$、UET$）的争用。我们知道系统中存在越多的空闲extent,越容易发生碎片问题。其中空闲extent的大小非常重要，如果在表空间上有许多个无法满足指定的next大小的空闲extent，那这个空闲extent就无法被重新使用并成为碎片，这时就需要重新整理碎片；我们可以使用COALESCE命令合并相邻的extent，来减少系统中的碎片。如果系统中不连续的小空闲extent过多，也就是碎片过多，则可能需要通过重建表空间的方式来消除碎片。
系统多数表空间使用ASSM，ASSM使用位图而不是传统的FreeList来管理段内的free db block，大大提升了空间管理的性能。同时显著的减少segmentheader类型的buffer busy wait等待事件。
建议：
表空间的管理方式选择合理。
Next Extent
保证段能够增长是很重要的，因此在必要时分配next extent。如果在表空间中没有足够的空余空间，那么next extent无法分配，对象也无法增长。
在数据库中没有发现无法分配NEXTEXTENT的段。
Temporary Tablespace
临时表空间用于存放临时段。为了维护数据库的性能，临时表空间的维护方法有别于其他一般表空间。缺省情况下，所有表空间都创建为PERMANENT。所以在创建临时段时，需要保证表空间类型为TEMPORARY。由于这些表空间中的排序段不被清除，所以减少了空间事务争夺，同时减少了SMON对于CPU的使用率。
当进行长时间清理时，用户无法进行排序操作。在这种情况下，可以指定用户使用状态为PERMANENT的临时表空间。这有可能会引起空间事务争夺，但是可以允许用户在磁盘上进行排序操作。
由于表空间的extent 使用了local management 方式，对表空间采用位图管理，更利于空间的使用及回收管理。
Status | Name | Size (MiB) | Minimum Extents | Maximum Extents | Minimum Extent Length | Increase (%) |
建议：
在数据库TEMP为TEMPORARY类型的表空间，Extent Management 方式为LOCAL。
保证每一个数据库用户都被分配一个临时类型的TEMP表空间。以下列出了将PERMANENT表空间作为默认临时表空间的用户：
没有发现用户将PERMANENT表空间作为默认临时表空间。
4.13 回滚段管理
回滚段能够用来保证读一致性，回滚事务以及恢复数据库。
Rollback Segment List
5. 数据库简单风险评估
5.1 安全性管理
在安全性方面，主要考虑用户访问数据库的控制以及维护系统的安全性问题。
Database Administrator Usernames/Passwords
Oracle自动生成两个用户，并授予DBA权限：
SYS
SYSTEM
经检查，SYS和SYSTEM都没有使用初始缺省密码。这样有利于维护数据库的安全性，否则任何具有Oracle知识背景的人都能进入数据库。
建议：
目前数据库用户安全方面设置良好，设置安全合理。
SYSDBA Users
被授予SYSDBA权限的用户能够进行DBA的操作，包括建立数据库，关闭数据库。
建议：
目前数据库不存在具有DBA权限的业务用户，用户权限管理情况较好。
6. SqlNet 概况
Net8能够在不同计算机上安装服务和应用程序，并且能够使它们如同同一层上的应用程序一样进行通信。Net8的主要功能就是创建网络通话，并且在客户端和服务器端，或者两个服务器端之间转换数据。Net8必须安装在网络的每台机器上。当网络通路建立，Net8扮演着客户端和服务器端数据投递者的角色。
6.1 监听器Listener
位于服务器端的监听程序是单独的进程。它从客户端接受连接请求，并管理这些对服务端的请求。当前LISTENER的参数设置如下：
Parameter | Value |
STARTUP_WAIT_TIME_LISTENER | N/A |
CONNECT_TIMEOUT_LISTENER | N/A |
TRACE_LEVEL_LISTENER | N/A |
只有当SQLNET需要跟踪判断所出现的问题时，TRACE_LEVEL_LISTENER才需要被设置。所获得的跟踪文件需交由OracleSupport进行分析。SQLNET跟踪只需在一段时间内开启，因为这将占用一些网络资源。
6.2 SQL*Net
配置文件SQLNET.ORA包含了客户端和服务器对SQL*Net配置的设置信息。当前的SQLNET参数如下：
Parameter | Value |
AUTORCLATIC_IPC | N/A |
TRACE_LEVEL_CLIENT | N/A |
TRACE_FILE_CLIENT | N/A |
TRACE_DIRECTORY_CLIENT | N/A |
SQLNET.EXPIRE_TIME | N/A |
6.3 TNSNAMES
TNSNAMES.ORA包含与连接描述符相匹配的网络服务名。连接描述符包括监听程序的地址以及connect_data。TNSNAMES.ORA设置如下：
由于TNSNAMES中相关的网络服务名比较多，完整的TNSNAMES.ORA中的内容可以见服务器上的配置文件。
7. 数据库性能
数据库的性能情况通过AWR的报告来体现。由于本次检查并不是完整的性能检查，所以本报告只列举最主要的性能问题。
XXXX
Snap Id | Snap Time | Sessions | Cursors/Session | |
Begin Snap: | ||||
End Snap: | ||||
Elapsed: | ||||
DB Time: |
YYYY
Snap Id | Snap Time | Sessions | Cursors/Session | |
Begin Snap: | ||||
End Snap: | ||||
Elapsed: | ||||
DB Time: |
我们可以参考用户系统忙时的AWR信息进行分析，不一定局限于检查时段，这样可以更加深入的发现问题。
7.1 数据库各项基于时间模型的统计信息
对数据库业务负荷压力最大情况下每一个实例的一个AWR报告的列出主要的性能结果，如数据库各项基于时间模型的统计信息等：
XXXX
Statistic Name | Time (s) | % of DB Time |
sql execute elapsed time | ||
DB CPU | ||
parse time elapsed | ||
hard parse elapsed time | ||
hard parse (sharing criteria) elapsed time | ||
PL/SQL execution elapsed time | ||
PL/SQL compilation elapsed time | ||
connection management call elapsed time | ||
sequence load elapsed time | ||
repeated bind elapsed time | ||
hard parse (bind mismatch) elapsed time | ||
DB time | ||
background elapsed time | ||
background cpu time |
YYYY
Statistic Name | Time (s) | % of DB Time |
DB CPU | ||
sql execute elapsed time | ||
parse time elapsed | ||
hard parse elapsed time | ||
hard parse (sharing criteria) elapsed time | ||
hard parse (bind mismatch) elapsed time | ||
PL/SQL execution elapsed time | ||
sequence load elapsed time | ||
PL/SQL compilation elapsed time | ||
connection management call elapsed time | ||
inbound PL/SQL rpc elapsed time | ||
repeated bind elapsed time | ||
DB time | ||
background elapsed time | ||
background cpu time |
7.2 数据库负荷压力分析
XXXX
Load Profile
Per Second | Per Transaction | |
Redo size: | ||
Logical reads: | ||
Block changes: | ||
Physical reads: | ||
Physical writes: | ||
User calls: | ||
Parses: | ||
Hard parses: | ||
Sorts: | ||
Logons: | ||
Executes: | ||
Transactions: |
% Blocks changed per Read: | Recursive Call %: | ||
Rollback per transaction %: | Rows per Sort: |
YYYY
Load Profile
Per Second | Per Transaction | |
Redo size: | ||
Logical reads: | ||
Block changes: | ||
Physical reads: | ||
Physical writes: | ||
User calls: | ||
Parses: | ||
Hard parses: | ||
Sorts: | ||
Logons: | ||
Executes: | ||
Transactions: |
% Blocks changed per Read: | Recursive Call %: | ||
Rollback per transaction %: | Rows per Sort: |
7.3 各项命中率
XXXX
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: | Redo NoWait %: | ||
Buffer Hit %: | In-memory Sort %: | ||
Library Hit %: | Soft Parse %: | ||
Execute to Parse %: | Latch Hit %: | ||
Parse CPU to Parse Elapsd %: | % Non-Parse CPU: |
YYYY
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: | Redo NoWait %: | ||
Buffer Hit %: | In-memory Sort %: | ||
Library Hit %: | Soft Parse %: | ||
Execute to Parse %: | Latch Hit %: | ||
Parse CPU to Parse Elapsd %: | % Non-Parse CPU: |
7.4 等待事件
列出最主要的等待事件：
XXXX
Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
YYYY
Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
7.5 统计信息分析
我们选取业务最为繁忙的上午时段的AWR报告进行分析。
一、关于CPU数据库使用情况
Total | per Second | per Trans | |
CPU used by this session | |||
parse time cpu | |||
recursive cpu usage |
分析：
可以看出系统CPU主要用于SQL语句的真正的执行阶段。
二、关于数据库事务提交/会滚性能指标
Total | per Second | per Trans | |
user calls | |||
user commits | |||
user rollbacks |
分析：
在实例快照统计中，用户回滚率正常。
7.6 数据库I/O性能
1、本数据库的数据文件绝大部分的平均的读取时间<20ms,表示当前的数据库I/O速度是可以接受的，如果有一些数据文件的平均读取时间大于20ms，需要引起注意。
2、ORACLE认为平均读取时间大于20ms是I/O性能比较差的，如果一个数据文件的平均读取时间一直大于20ms的话，建议：
应该检查对该数据文件上的查询语句，并且优化SQL语句。
如果该数据文件包含索引，一个可以考虑的选择是使用压缩索引来减少I/O。
数据文件应该尽量条带化，分布在不同的物理硬盘上面。
7.7 索引/行迁移/行链
索引
索引需要维护。对于表的删除或者添加操作都会间接地对索引进行相应操作。过时的索引结构会产生碎片，此时索引需要被重新建立。
当前数据库中未发现需要重建的索引。
行链
当一条记录太大，一个数据块无法将其存储时，oracle 就会将其存储在相链接的块中。如果一条记录中含有数据类型如：LONG,LONGRAW,LOB,行链则无法避免。
行迁移
当一个数据块已满，而一条记录在更新后记录长度增加了，这时oracle 就会将整个记录迁移到一个新的数据块，这就是行迁移。Rowid 在行迁移之后保持不变。除大数据类型之外，上述情况对数据库的性能是有影响的。从上面实例活动统计部分的table fetch continued row分析可以看出当前数据库中链接行的多少。
关于行迁移/行链接统计信息
Total | per Second | per Trans | |
目前行链接较少，但是仍需关注，是否行链接集中在特定的segment，以及是否属于不可避免的行链接情况。
建议：
为避免或者尽量减少出现行链接/行迁移的可能，建议适当增大表、表分区的pctfree存储参数。
7.8 Enqueue等待分析
在统计报告中的TOP5 event中均没有出现Enqueue等待事件，说明Enqueue等待不是系统的性能瓶颈，性能良好。
7.9 Latch分析
在数据库的latch命中率为n%以上，符合要求。
7.10 Resource Limit分析
下面列出了出现在Resourcelimit统计的Resource情况，需要客户和应用开发厂家根据业务情况评估是否需要调整：
Resource Name | Current Utilization | Max Utilization | Initial Allocation | Limit Value |
7.11 Top SQL语句
列出最消耗系统逻辑IO(BufferGets)的三条SQL语句：
Buffer Gets | Executions | Gets per Exec | %Total | CPU Time (s) | Elapsed Time (s) | SQL Id | SQL Module | SQL Text |
建议：
1、使用explain plan去分析TOP SQL的执行计划，找出消耗资源较高的原因。
8. 数据库备份策略评估
8.1 备份
备份策略：
每天对数据库做全库备份。
建议：
使用RMAN对数据库进行备份。
8.2 恢复
恢复策略：
建议:
定期进行恢复测试以确保备份的可用性和恢复步骤的熟悉。
1、根据不同的数据库失败情况制定相应的恢复策略。
数据库全库恢复
表空间恢复
数据文件恢复
数据表恢复
2、根据制定的恢复策略进行恢复测试。
9. 数据库特别关注点检查
10. 检查总结
附录:初始化参数
数据库所有非默认值的参数：
Parameter Name | Value | Modified |
由社区会员上传分享，下载word文档请点击阅读原文
相关资料
长按二维码关注公众号