Oracle数据库健康检查及其评估

XXXXXXXXXXXXXXX

XXXXX

Oracle数据库健康检查与评估

XXXX

巡检人：

报告生成日期：yyyy-mm-dd

文档控制

此文档仅供江苏移动审阅，不得向与此无关的个人或机构传阅或复制。修改记录

分发者

审阅记录

相关文档

目录

1.检查介绍

1.1检查系统

系统主要包括1个数据库，具体情况如下：

1.2检查范围

本次检查仅限于数据库。在这次检查中对数据库配置和数据库性能进行了分析。本报告提供的检查和建议不涉及具体的安全分析和应用程序的具体细节。

以下提请注意：本次检查仅历时1天，其中还包括了提交分析报告的时间，所以在具体的应用程序性能方面并不加以深入。

以下列出系统主机的主要配置情况

2.1主机配置

建议：

目前系统配置满足数据库要求，操作系统参数设置合理。

和数据库相关的操作系统配置将被检查，包括以下方面：

●操作系统数据库相关要求补丁

●存放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.3CPU 利用率

CPU利用率的统计时间是：yyyy-mm-dd hh:mi---- yyyy-mm-dd hh:mi

1.top / glance

2.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_HOME

建议：

4.2CRS版本和单独补丁

CRS安装单独补丁列表如下：

opatch lsinventory -oh $ORA_CRS_HOME

建议：

4.3ORACLE CLUSTER配置

OCR使用和备份都正常。相关CRS的资源和服务都正常。

4.4数据库产品选项

当oracle软件安装时，会选择要安装的产品。有某些产品的安装是需要license的，本次检查不涉及license问题。一般，很多系统安装的数据库产品选项根本未被使用。以下列出的安装产品选项可供未来的应用开发参考，或是可以被确认有哪些产品选项未在原计划之内。

以下是数据库安装的产品选项：

4.5初始化参数文件

数据库SPFILE参数指定了当前使用的数据库配置参数，在数据库启动时被使用。在附录A列出了数据库所有的非默认值的参数。

建议：

1.数据库的参数可以看出大部分都是经过精心设置的。

2.建议调整的参数值，请在测试环境数据库中测试确认之后，再调整于生产环境数据库。

4.6CRS日志文件

从Oracle 10g RAC版本开始，新增加CRS组件。CRS对于RAC使用是必不可少，因此crs的稳定对于RAC数据库的正常运行至关重要。在健康检查中会检查CRS、CSS和EVM的LOG信息。

.

建议：

2．检查CRS其他相关进程日志，没有发现问题。

4.7RDBMS运行日志和跟踪文件

Oracle 数据库进程生成跟踪文件来记录错误或冲突，这些跟踪文件可以用来进一步分析问题。数据库参数'max_dump_file_size'限制了这些跟踪文件的大小(以操作系统块的大小为单位)。应当有足够的硬盘空间来容纳最大值的设置，否则的话应当修改上述参数的设置。

如果参数'max_dump_file_size'设得太大，会超过硬盘空间容量；如果设得太小，又不能容纳足够的出错信息供oracle 支持服务部门分析问题。此参数可以在数据库会话级设置，这样可以有选择性地设置较大值。

注意每天监控运行日志文件中的出错信息，以便于在问题还是隐患的时候及时发现并解决掉。建议每月初将当前的alert.log重新命名以作备份，同时也可以避免alert.log文件变得太大不易管理。

在数据库:实例的运行日志文件发现的最近一月内的主要错误如下所示：

建议：

4.8控制文件

每个数据库至少有一个控制文件。控制文件记录了数据库的物理结构及同步信息。

Control file location

控制文件路径如下：

目前所有的控制文件文件存储在已经做了硬件RAID的磁盘阵列上面，提供了硬件级别的保护。

建议:

4.9Redo 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文件中恢复。

建议：

4.10归档Redo log 文件

Oracle允许将写满的在线Redo Log文件存放在一个或多个脱机位置，即归档Redo Log。在线日志文件通过归档写入归档日志文件。后台进程ARCn自动进行归档操作。您能通过归档日志进行：

?在线备份

?基于时间的恢复

Archived Redo Log Settings

建议：

这里能够很好地在运行环境中使用归档Redo Log。这样就能够进行基于时间的恢复。监控归档日志文件所暂时存放的磁盘空间，根据实际情况调整归档日志文件备份到磁带的频度。

4.11数据文件

数据文件是数据库分配的物理文件。在Oracle数据库中，一个表空间可以包含一个或多个物理文件。而一个数据文件则只能关联一个表空间和一个数据库。Oracle通过分配一定的磁盘空间以及所需要的文件头空间，为每个表空间创建一个数据文件。

Data file locations

检测数据文件的位置。当数据文件增长过度，数据库中必须添加数据文件。应该避免“哪里有空间，哪里建文件”的错误方法，因为这样会增加备份策略和文件维护的复杂性。下面列出部分数据文件的位置。

建议：

目前看来，数据文件存放位置基本准确。

Autoextend capabilities

通过自动扩展命令进行数据文件的自动扩展。假定数据文件无法分配所需空间，那么它将提高数据文件的大小以获得更多空间。

建议：

4.12表空间

每个数据库由一个或多个逻辑存储单位，即表空间，所组成。而表空间则由逻辑存储单位段所组成。而段将被分为多个片。

Tablespace Management

以下是关于数据库表空间管理的信息。

建议：

Tablespace Default Storage Management

每个表空间中，可以为创建的对象指定缺省的存储参数。创建对象时指定的存储参数将覆盖缺省值。如果在创建对象时没有指定存储参数，那么系统将使用缺省值。

表空间缺省存储情况：

数据库表空间的管理方式均为本地管理，这有利于减少表空间级别的碎片，同时避免了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 方式，对表空间采用位图管理，更利于空间的使用及回收管理。

建议：

在数据库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的参数设置如下：

只有当SQLNET需要跟踪判断所出现的问题时，TRACE_LEVEL_LISTENER才需要被设置。所获得的跟踪文件需交由Oracle Support进行分析。SQLNET跟踪只需在一段时间内开启，因为这将占用一些网络资源。

6.2SQL*Net

配置文件SQLNET.ORA包含了客户端和服务器对SQL*Net配置的设置信息。当前的SQLNET参数如下：

6.3TNSNAMES

TNSNAMES.ORA包含与连接描述符相匹配的网络服务名。连接描述符包括监听程序的地址以及

connect_data。TNSNAMES.ORA设置如下：

由于TNSNAMES中相关的网络服务名比较多，完整的TNSNAMES.ORA中的内容可以见服务器上的配置文件。

7.数据库性能

数据库的性能情况通过AWR的报告来体现。由于本次检查并不是完整的性能检查，所以本报告只列举最主要的性能问题。

XXXX

YYYY

我们可以参考用户系统忙时的AWR信息进行分析，不一定局限于检查时段，这样可以更加深入的发现问题。

7.1数据库各项基于时间模型的统计信息

对数据库业务负荷压力最大情况下每一个实例的一个AWR报告的列出主要的性能结果，如数据库各项基于时间模型的统计信息等：

XXXX

YYYY

7.2数据库负荷压力分析XXXX

Load Profile

YYYY

Load Profile