《oracle数据库健康检查及其评估》由会员分享，可在线阅读，更多相关《oracle数据库健康检查及其评估（26页珍藏版）》请在金锄头文库上搜索。
1、XXXXXXXXXXXXXXXXXXXXOracle数据库健康检查与评估XXXX巡检人：报告生成日期：yyyy-mm-dd 文档控制此文档仅供江苏移动审阅，不得向与此无关的个人或机构传阅或复制。修改记录日期作者版本修改记录分发者、姓名职位审阅记录姓名职位相关文档目录文档控制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配
2、置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索
3、引/行迁移/行链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表空间个数数据文件个数控制文件个数日志文件
4、大小日志组数目每组日志文件成员数量归档方式并发用户量性能需求1.2 检查范围本次检查仅限于数据库。在这次检查中对数据库配置和数据库性能进行了分析。本报告提供的检查和建议不涉及具体的安全分析和应用程序的具体细节。以下提请注意：本次检查仅历时1天，其中还包括了提交分析报告的时间，所以在具体的应用程序性能方面并不加以深入。检查方面具体检查内容硬件配置主机配置共享内存参数信号量操作系统中与数据库相关主要参数操作系统数据库相关要求补丁系统配置硬盘可用空间CPU利用率数据库版本数据库配置数据库产品选项数据库参数运行日志和跟踪文件控制文件Redo log文件归档Redo log文件数据文件表空间回滚段管理安
5、全性管理数据库简单风险评估监听器的设置数据库sql*net配置SQL*Net设置TNSNAMES设置数据库各项命中率数据库性能等待事件AWR统计信息分析数据库I/O性能索引/行迁移/行链接Sort信息统计Enqueue等待分析Latch分析Resource Limit分析Top SQL 语句备份恢复数据库备份策略评估根据客户要求只能检查一项数据库特别关注点检查2. 硬件配置以下列出系统主机的主要配置情况2.1 主机配置机器名用途 (Prod, Test, Development)所在城市，物理位置（机房，远程）操作系统及版本内存cpu 建议：目前系统配置满足数据库要求，操作系统参数设置合理。3
6、. 系统配置和数据库相关的操作系统配置将被检查，包括以下方面：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 Mo
7、unted 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%，要注意监控是否有僵死进程，如果有僵死进程
8、占用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
9、的资源和服务都正常。$ olsnodes$ ocrcheck $ ocrconfig -showbackup$ crsctl check crsCSS appears healthyCRS appears healthyEVM appears healthy$ crs_stat -t4.4 数据库产品选项当oracle软件安装时，会选择要安装的产品。有某些产品的安装是需要license的，本次检查不涉及license问题。一般，很多系统安装的数据库产品选项根本未被使用。以下列出的安装产品选项可供未来的应用开发参考，或是可以被确认有哪些产品选项未在原计划之内。以下是数据库安装的产品选项：Para
10、meterValue4.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运行日志和跟
11、踪文件Oracle 数据库进程生成跟踪文件来记录错误或冲突，这些跟踪文件可以用来进一步分析问题。数据库参数max_dump_file_size限制了这些跟踪文件的大小(以操作系统块的大小为单位)。应当有足够的硬盘空间来容纳最大值的设置，否则的话应当修改上述参数的设置。如果参数max_dump_file_size设得太大，会超过硬盘空间容量；如果设得太小，又不能容纳足够的出错信息供oracle 支持服务部门分析问题。此参数可以在数据库会话级设置，这样可以有选择性地设置较大值。注意每天监控运行日志文件中的出错信息，以便于在问题还是隐患的时候及时发现并解决掉。建议每月初将当前的alert.log重新
12、命名以作备份，同时也可以避免alert.log文件变得太大不易管理。在数据库:实例的运行日志文件发现的最近一月内的主要错误如下所示：建议：4.8 控制文件每个数据库至少有一个控制文件。控制文件记录了数据库的物理结构及同步信息。Control file location控制文件路径如下：NameStatus目前所有的控制文件文件存储在已经做了硬件RAID的磁盘阵列上面，提供了硬件级别的保护。建议 : 4.9 Redo log 文件对于恢复操作，最为关键的结构是在线Redo Log。在线Redo Log一般由两个或两个以上预先分配的存储数据库变化的文件组成。为了防止例程故障，每个数据库的实例都有相
13、关的在线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
