Oracle数据库健康检查与评估.docx

XXXXXXXXXXXXXXXXXXXXOracle数据库健康检查与评估XXXX巡检人：报告生成日期：yyyy-mm-dd iiJoint Contact Guide v3.0 Commercial in ConfidencePage ii文档控制此文档仅供江苏移动审阅，不得向与此无关的个人或机构传阅或复制。修改记录日期作者版本修改记录分发者、姓名职位审阅记录姓名职位相关文档目录文档控制2修改记录2分发者2审阅记录2相关文档2目录31.检查介绍51.1检查系统51.2检查范围52.硬件配置72.1主机配置73.系统配置83.1操作系统数据库相关要求补丁83.2硬盘可用空间83.3CPU 利用率84.数据库配置104.1数据库版本和单独补丁104.2CRS版本和单独补丁104.3ORACLE CLUSTER配置104.4数据库产品选项104.5初始化参数文件114.6CRS日志文件114.7RDBMS运行日志和跟踪文件114.8控制文件114.9Redo log 文件124.10归档Redo log 文件134.11数据文件134.12表空间144.13回滚段管理155.数据库简单风险评估175.1平安性管理176.SqlNet 概况186.1监听器Listener186.2SQL*Net186.3TNSNAMES187.数据库性能197.1数据库各项基于时间模型的统计信息197.2数据库负荷压力分析207.3各项命中率217.4等待事件217.5统计信息分析217.6数据库I/O性能227.7索引/行迁移/行链227.8Enqueue等待分析237.9Latch分析237.10Resource Limit分析237.11Top SQL语句248.数据库备份策略评估258.1备份258.2恢复259.数据库特别关注点检查2610.检查总结27附录:初始化参数28数据库所有非默认值的参数：281. 检查介绍1.1 检查系统系统主要包括1个数据库，具体情况如下：数据库名称数据库实例名应用名称应用类型OLTP/DSS/Batch开发工具应用简介RDBMS 版本CRS 版本所有数据文件所占磁盘空间SGA target sizeDB_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. 系统配置和数据库相关的操作系统配置将被检查，包括以下方面：l 操作系统数据库相关要求补丁l 存放oracle文件的硬盘区可用空间(oracle文件包括：数据文件，控制文件，在线redo logs，归档redo logs，运行情况文件和跟踪文件)。l 硬盘利用率。l 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:mi1. top / glance2. vmstat 2 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_HOMEPatchBase Bug(s)Installed on 建议：4.2 CRS版本和单独补丁CRS安装单独补丁列表如下：opatch lsinventory -oh $ORA_CRS_HOMENameVersionInstalled on建议：4.3 ORACLE CLUSTER配置OCR使用和备份都正常。相关CRS的资源和效劳都正常。$ olsnodes$ ocrcheck $ ocrconfig -showbackup$ crsctl check crsCSS appears healthyCRS appears healthyEVM appears healthy$ crs_stat -t4.4 数据库产品选项当oracle软件安装时，会选择要安装的产品。有某些产品的安装是需要license的，本次检查不涉及license问题。一般，很多系统安装的数据库产品选项根本未被使用。以以下出的安装产品选项可供未来的应用开发参考，或是可以被确认有哪些产品选项未在原方案之内。以下是数据库安装的产品选项：ParameterValue4.5 初始化参数文件数据库SPFILE参数指定了当前使用的数据库配置参数，在数据库启动时被使用。在附录A列出了数据库所有的非默认值的参数。建议：1. 数据库的参数可以看出大局部都是经过精心设置的。2. 建议调整的参数值，请在测试环境数据库中测试确认之后，再调整于生产环境数据库。4.6 CRS日志文件从Oracle 10g RAC版本开始，新增加CRS组件。CRS对于RAC使用是必不可少，因此crs的稳定对于RAC数据库的正常运行至关重要。在健康检查中会检查CRS、CSS和EVM的LOG信息。.建议：2检查CRS其他相关进程日志，没有发现问题。4.7 RDBMS运行日志和跟踪文件Oracle 数据库进程生成跟踪文件来记录错误或冲突，这些跟踪文件可以用来进一步分析问题。数据库参数max_dump_file_size限制了这些跟踪文件的大小(以操作系统块的大小为单位)。应当有足够的硬盘空间来容纳最大值的设置，否那么的话应当修改上述参数的设置。如果参数max_dump_file_size设得太大，会超过硬盘空间容量；如果设得太小，又不能容纳足够的出错信息供oracle 支持效劳部门分析问题。此参数可以在数据库会话级设置，这样可以有选择性地设置较大值。注意每天监控运行日志文件中的出错信息，以便于在问题还是隐患的时候及时发现并解决掉。建议每月初将当前的alert.log重新命名以作备份，同时也可以防止alert.log文件变得太大不易管理。在数据库:实例的运行日志文件发现的最近一月内的主要错误如下所示：建议：4.8 控制文件每个数据库至少有一个控制文件。控制文件记录了数据库的物理结构及同步信息。Control file location控制文件路径如下：NameStatus目前所有的控制文件文件存储在已经做了硬件RAID的磁盘阵列上面，提供了硬件级别的保护。建议 : 4.9 Redo log 文件对于恢复操作，最为关键的结构是在线Redo Log。在线Redo Log一般由两个或两个以上预先分配的存储数据库变化的文件组成。为了防止例程故障，每个数据库的实例都有相关的在线Redo Log。每个数据库至少有两个Redo Log组，每组至少有一个日志文件。Oracle的多重在线Redo Log文件可以确保在线日志文件的平安。对于多重在线Redo Log文件，LGWR同时将相同的Redo Log信息写入不同的Redo Log文件中，从而减少单个文件丧失的损失。当Oracle无法访问一个Redo Log文件时，这个文件状态变为INVALID。当Oracle推测一个Redo Log文件不完整或者不正确时，它的状态变为STALE。当一个STALE的文件被重用时，即其所在日志文件组活动时，此文件也能够使用。在线Redo Log文件减少了数据库数据丧失的损失，比方当发生例程故障时，没有被写入数据文件的数据可以从在线Redo Log文件中恢复。Group #Thread #Sequence #BytesMembersArchivedStatusFirst Change #First Time建议：4.10 归档Redo log 文件Oracle允许将写满的在线Redo Log文件存放在一个或多个脱机位置，即归档Redo Log。在线日志文件通过归档写入归档日志文件。后台进程ARCn自动进行归档操作。您能通过归档日志进行： 在线备份 基于时间的恢复Archived Redo Log SettingsParameter Value 建议：这里能够很好地在运行环境中使用归档Redo Log。这样就能够进行基于时间的恢复。监控归档日志文件所暂时存放的磁盘空间，根据实际情况调整归档日志文件备份到磁带的频度。4.11 数据文件数据文件是数据库分配的物理文件。在Oracle数据库中，一个表空间可以包含一个或多个物理文件。而一个数据文件那么只能关联一个表空间和一个数据库。Oracle通过分配一定的磁盘空间以及所需要的文件头空间，为每个表空间创立一个数据文件。Data file locations检测数据文件的位置。当数据文件增长过度，数据库中必须添加数据文件。应该防止“哪里有空间，哪里建文件的错误方法，因为这样会增加备份策略和文件维护的复杂性。下面列出局部数据文件的位置。StatusNameTablespaceFile NumberRelative File NumberSizeUsed (MB)Used (%)Autoextensible 建议：目前看来，数据文件存放位置根本准确。Autoextend capabilities通过自动扩展命令进行数据文件的自动扩展。假定数据文件无法分配所需空间，那么它将提高数据文件的大小以获得更多空间。建议：4.12 表空间每个数据库由一个或多个逻辑存储单位，即表空间，所组成。而表空间那么由逻辑存储单位段所组成。而段将被分为多个片。Tablespace Management以下是关于数据库表空间管理的信息。StatusNameTypeExtent ManagementSegment Space ManagementSize (MB)Used (MB)Used (%)建议：Tablespace Default Storage Management每个表空间中，可以为创立的对象指定缺省的存储参数。创立对象时指定的存储参数将覆盖缺省值。如果在创立对象时没有指定存储参数，那么系统将使用缺省值。表空间缺省存储情况：NameTypeInitial ExtentNext ExtentLargest Free ExtentMinimum ExtentsMaximum ExtentsMinimum Extent LengthIncrease (%)数据库表空间的管理方式均为本地管理，这有利于减少表空间级别的碎片，同时防止了DB在进行空间管理时对数据字典表FET$、UET$的争用。我们知道系统中存在越多的空闲extent,越容易发生碎片问题。其中空闲extent的大小非常重要，如果在表空间上有许多个无法满足指定的next大小的空闲extent，那这个空闲extent就无法被重新使用并成为碎片，这时就需要重新整理碎片；我们可以使用COALESCE命令合并相邻的extent，来减少系统中的碎片。如果系统中不连续的小空闲extent过多，也就是碎片过多，那么可能需要通过重建表空间的方式来消除碎片。系统多数表空间使用ASSM，ASSM使用位图而不是传统的FreeList来管理段内的free db block，大大提升了空间管理的性能。同时显著的减少segment header类型的buffer busy wait等待事件。建议：表空间的管理方式选择合理。Next Extent保证段能够增长是很重要的，因此在必要时分配next extent。如果在表空间中没有足够的空余空间，那么next extent无法分配，对象也无法增长。在数据库中没有发现无法分配NEXT EXTENT的段。Temporary Tablespace临时表空间用于存放临时段。为了维护数据库的性能，临时表空间的维护方法有别于其他一般表空间。缺省情况下，所有表空间都创立为PERMANENT。所以在创立临时段时，需要保证表空间类型为TEMPORARY。由于这些表空间中的排序段不被去除，所以减少了空间事务争夺，同时减少了SMON对于CPU的使用率。当进行长时间清理时，用户无法进行排序操作。在这种情况下，可以指定用户使用状态为PERMANENT的临时表空间。这有可能会引起空间事务争夺，但是可以允许用户在磁盘上进行排序操作。由于表空间的extent 使用了local management 方式，对表空间采用位图管理，更利于空间的使用及回收管理。StatusNameSize (MiB)Minimum ExtentsMaximum ExtentsMinimum Extent LengthIncrease (%)建议：在数据库TEMP为TEMPORARY类型的表空间，Extent Management 方式为LOCAL。保证每一个数据库用户都被分配一个临时类型的TEMP表空间。以以下出了将PERMANENT表空间作为默认临时表空间的用户：没有发现用户将PERMANENT表空间作为默认临时表空间。4.13 回滚段管理回滚段能够用来保证读一致性，回滚事务以及恢复数据库。Rollback Segment List5. 数据库简单风险评估5.1 平安性管理在平安性方面，主要考虑用户访问数据库的控制以及维护系统的平安性问题。Database Administrator Usernames/PasswordsOracle自动生成两个用户，并授予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_LISTENERN/ACONNECT_TIMEOUT_LISTENERN/ATRACE_LEVEL_LISTENERN/A只有当SQLNET需要跟踪判断所出现的问题时，TRACE_LEVEL_LISTENER才需要被设置。所获得的跟踪文件需交由Oracle Support进行分析。SQLNET跟踪只需在一段时间内开启，因为这将占用一些网络资源。6.2 SQL*Net配置文件SQLNET.ORA包含了客户端和效劳器对SQL*Net配置的设置信息。当前的SQLNET参数如下：Parameter Value AUTORCLATIC_IPCN/ATRACE_LEVEL_CLIENTN/ATRACE_FILE_CLIENTN/ATRACE_DIRECTORY_CLIENTN/ASQLNET.EXPIRE_TIMEN/A6.3 TNSNAMESTNSNAMES.ORA包含与连接描述符相匹配的网络效劳名。连接描述符包括监听程序的地址以及connect_data。TNSNAMES.ORA设置如下：由于TNSNAMES中相关的网络效劳名比拟多，完整的TNSNAMES.ORA中的内容可以见效劳器上的配置文件。7. 数据库性能数据库的性能情况通过AWR的报告来表达。由于本次检查并不是完整的性能检查，所以本报告只列举最主要的性能问题。XXXXSnap IdSnap TimeSessionsCursors/SessionBegin Snap:End Snap:Elapsed:DB Time:YYYYSnap IdSnap TimeSessionsCursors/SessionBegin Snap:End Snap:Elapsed:DB Time:我们可以参考用户系统忙时的AWR信息进行分析，不一定局限于检查时段，这样可以更加深入的发现问题。 7.1 数据库各项基于时间模型的统计信息对数据库业务负荷压力最大情况下每一个实例的一个AWR报告的列出主要的性能结果，如数据库各项基于时间模型的统计信息等：XXXXStatistic NameTime (s)% of DB Timesql execute elapsed timeDB CPUparse time elapsedhard parse elapsed timehard parse (sharing criteria) elapsed timePL/SQL execution elapsed timePL/SQL compilation elapsed timeconnection management call elapsed timesequence load elapsed timerepeated bind elapsed timehard parse (bind mismatch) elapsed timeDB timebackground elapsed timebackground cpu timeYYYYStatistic NameTime (s)% of DB TimeDB CPUsql execute elapsed timeparse time elapsedhard parse elapsed timehard parse (sharing criteria) elapsed timehard parse (bind mismatch) elapsed timePL/SQL execution elapsed timesequence load elapsed timePL/SQL compilation elapsed timeconnection management call elapsed timeinbound PL/SQL rpc elapsed timerepeated bind elapsed timeDB timebackground elapsed timebackground cpu time7.2 数据库负荷压力分析XXXXLoad Profile Per SecondPer TransactionRedo 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:YYYYLoad Profile Per SecondPer TransactionRedo 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 各项命中率XXXXInstance 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:YYYYInstance 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 等待事件列出最主要的等待事件：XXXXEventWaitsTime(s)Avg Wait(ms)% Total Call TimeWait ClassYYYYEventWaitsTime(s)Avg Wait(ms)% Total Call TimeWait Class7.5 统计信息分析我们选取业务最为繁忙的上午时段的AWR报告进行分析。一、 关于CPU数据库使用情况Totalper Secondper TransCPU used by this sessionparse time cpurecursive cpu usage分析：可以看出系统CPU主要用于SQL语句的真正的执行阶段。二、 关于数据库事务提交/会滚性能指标Totalper Secondper Transuser callsuser commitsuser rollbacks分析：在实例快照统计中，用户回滚率正常。7.6 数据库I/O性能1、 本数据库的数据文件绝大局部的平均的读取时间20ms,表示当前的数据库I/O速度是可以接受的，如果有一些数据文件的平均读取时间大于20ms，需要引起注意。2、 ORACLE认为平均读取时间大于20ms是I/O性能比拟差的，如果一个数据文件的平均读取时间一直大于20ms的话，建议：应该检查对该数据文件上的查询语句，并且优化SQL语句。如果该数据文件包含索引，一个可以考虑的选择是使用压缩索引来减少I/O。数据文件应该尽量条带化，分布在不同的物理硬盘上面。7.7 索引/行迁移/行链索引索引需要维护。对于表的删除或者添加操作都会间接地对索引进行相应操作。过时的索引结构会产生碎片，此时索引需要被重新建立。当前数据库中未发现需要重建的索引。行链当一条记录太大，一个数据块无法将其存储时，oracle 就会将其存储在相链接的块中。如果一条记录中含有数据类型如：LONG,LONG RAW,LOB,行链那么无法防止。行迁移当一个数据块已满，而一条记录在更新后记录长度增加了，这时oracle 就会将整个记录迁移到一个新的数据块，这就是行迁移。Rowid 在行迁移之后保持不变。除大数据类型之外，上述情况对数据库的性能是有影响的。从上面实例活动统计局部的table fetch continued row分析可以看出当前数据库中链接行的多少。关于行迁移/行链接统计信息Totalper Secondper Trans目前行链接较少，但是仍需关注，是否行链接集中在特定的segment，以及是否属于不可防止的行链接情况。建议：为防止或者尽量减少出现行链接/行迁移的可能，建议适当增大表、表分区的pctfree存储参数。7.8 Enqueue等待分析在统计报告中的TOP5 event中均没有出现Enqueue等待事件，说明Enqueue等待不是系统的性能瓶颈，性能良好。7.9 Latch分析在数据库的latch命中率为n%以上，符合要求。7.10 Resource Limit分析下面列出了出现在Resource limit统计的Resource情况，需要客户和应用开发厂家根据业务情况评估是否需要调整：Resource NameCurrent UtilizationMax UtilizationInitial AllocationLimit Value7.11 Top SQL语句列出最消耗系统逻辑IO(Buffer Gets)的三条SQL语句：Buffer Gets Executions Gets per Exec %TotalCPU Time (s)Elapsed Time (s)SQL IdSQL ModuleSQL Text建议：1、 使用explain plan去分析TOP SQL的执行方案，找出消耗资源较高的原因。8. 数据库备份策略评估8.1 备份备份策略每天对数据库做全库备份。建议：使用RMAN对数据库进行备份。8.2 恢复恢复策略建议:定期进行恢复测试以确保备份的可用性和恢复步骤的熟悉。1、根据不同的数据库失败情况制定相应的恢复策略。l 数据库全库恢复l 表空间恢复l 数据文件恢复l 数据表恢复2、根据制定的恢复策略进行恢复测试。9. 数据库特别关注点检查10. 检查总结附录:初始化参数数据库所有非默认值的参数：Parameter NameValueModified内容总结1XXXXXXXXXXXXXXXXXXXXOracle数据库健康检查与评估XXXX巡检人：报告生成日期：yyyy-mm-dd健康检查报告 第27页