数据库巡检模板.docx

上传人:b****8 文档编号:12273483 上传时间:2023-06-05 格式:DOCX 页数:27 大小:32.76KB
下载 相关 举报
数据库巡检模板.docx_第1页
第1页 / 共27页
数据库巡检模板.docx_第2页
第2页 / 共27页
数据库巡检模板.docx_第3页
第3页 / 共27页
数据库巡检模板.docx_第4页
第4页 / 共27页
数据库巡检模板.docx_第5页
第5页 / 共27页
数据库巡检模板.docx_第6页
第6页 / 共27页
数据库巡检模板.docx_第7页
第7页 / 共27页
数据库巡检模板.docx_第8页
第8页 / 共27页
数据库巡检模板.docx_第9页
第9页 / 共27页
数据库巡检模板.docx_第10页
第10页 / 共27页
数据库巡检模板.docx_第11页
第11页 / 共27页
数据库巡检模板.docx_第12页
第12页 / 共27页
数据库巡检模板.docx_第13页
第13页 / 共27页
数据库巡检模板.docx_第14页
第14页 / 共27页
数据库巡检模板.docx_第15页
第15页 / 共27页
数据库巡检模板.docx_第16页
第16页 / 共27页
数据库巡检模板.docx_第17页
第17页 / 共27页
数据库巡检模板.docx_第18页
第18页 / 共27页
数据库巡检模板.docx_第19页
第19页 / 共27页
数据库巡检模板.docx_第20页
第20页 / 共27页
亲,该文档总共27页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

数据库巡检模板.docx

《数据库巡检模板.docx》由会员分享,可在线阅读,更多相关《数据库巡检模板.docx(27页珍藏版)》请在冰点文库上搜索。

数据库巡检模板.docx

数据库巡检模板

 

XXXXXXXXXXXXXXX

XXXXX

Oracle数据库健康检查与评估

XXXX

 

巡检人:

报告生成日期:

yyyy-mm-dd

 

 

文档控制

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

修改记录

日期

作者

版本

修改记录

分发者

、姓名

职位

审阅记录

姓名

职位

相关文档

1.检查介绍

1.1检查系统

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

数据库名称

数据库实例名

应用名称

应用类型OLTP/DSS/Batch

开发工具

应用简介

RDBMS版本

CRS版本

所有数据文件所占磁盘空间

SGAtargetsize

DB_BLOCKSize

表空间个数

数据文件个数

控制文件个数

日志文件大小

日志组数目

每组日志文件成员数量

归档方式

并发用户量

性能需求

1.2检查范围

本次检查仅限于数据库。

在这次检查中对数据库配置和数据库性能进行了分析。

本报告提供的检查和建议不涉及具体的安全分析和应用程序的具体细节。

以下提请注意:

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

检查方面

具体检查内容

硬件配置

主机配置

共享内存参数

信号量

操作系统中与数据库相关主要参数

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

系统配置

硬盘可用空间

CPU利用率

数据库版本

数据库配置

数据库产品选项

数据库参数

运行日志和跟踪文件

控制文件

Redolog文件

归档Redolog文件

数据文件

表空间

回滚段管理

安全性管理

数据库简单风险评估

监听器的设置

数据库sql*net配置

SQL*Net设置

TNSNAMES设置

数据库各项命中率

数据库性能

等待事件

AWR统计信息分析

数据库I/O性能

索引/行迁移/行链接

Sort信息统计

Enqueue等待分析

Latch分析

ResourceLimit分析

TopSQL语句

备份

恢复

数据库备份策略评估

根据客户要求只能检查一项

数据库特别关注点检查

 

2.硬件配置

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

2.1主机配置

机器名

用途(Prod,Test,Development)

所在城市,物理位置(机房,远程)

操作系统及版本

内存

cpu

建议:

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

 

3.系统配置

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

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

●存放oracle文件的硬盘区可用空间(oracle文件包括:

数据文件,控制文件,在线redologs,归档redologs,运行情况文件和跟踪文件)。

●硬盘利用率。

●CPU利用率。

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

建议:

3.2硬盘可用空间

硬盘可用情况如下示:

数据库XXXX的硬盘使用率情况如下:

Filesystemkbytesusedavail%usedMountedon

数据库YYYY的硬盘使用率情况如下:

Filesystemkbytesusedavail%usedMountedon

建议:

目前该数据库服务器中还没有其他硬盘空间使用率超过90%的分区。

如果有需要引起注意并且及时增加硬盘空间的容量。

3.3CPU利用率

CPU利用率的统计时间是:

yyyy-mm-ddhh:

mi----yyyy-mm-ddhh:

mi

1.top/glance

2.vmstat220

参考值:

1.最大CPU使用率:

60%--70%

2.系统进程与用户进程占用CPU最大比率:

40/60

数据库XXXX:

数据库YYYY:

 

从上述的情况中看出,数据库:

服务器CPUidle基本在75%以上,CPU资源较为空闲。

建议:

当CPU的使用率超过80%,要注意监控是否有僵死进程,如果有僵死进程占用CPU,需要将僵死进程kill掉。

如果有正常进程占用大量CPU,需要查看是否属于正常业务进程等。

4.数据库配置

本次检查工作主要针对数据库XXXX。

4.1数据库版本和单独补丁

目前已经安装的单独补丁列表如下:

opatchlsinventory-oh$ORACLE_HOME

Patch

BaseBug(s)

Installedon

建议:

4.2CRS版本和单独补丁

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

opatchlsinventory-oh$ORA_CRS_HOME

Name

Version

Installedon

建议:

4.3ORACLECLUSTER配置

OCR使用和备份都正常。

相关CRS的资源和服务都正常。

$olsnodes

$ocrcheck

$ocrconfig-showbackup

$crsctlcheckcrs

CSSappearshealthy

CRSappearshealthy

EVMappearshealthy

$crs_stat-t

4.4数据库产品选项

当oracle软件安装时,会选择要安装的产品。

有某些产品的安装是需要license的,本次检查不涉及license问题。

一般,很多系统安装的数据库产品选项根本未被使用。

以下列出的安装产品选项可供未来的应用开发参考,或是可以被确认有哪些产品选项未在原计划之内。

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

Parameter

Value

4.5初始化参数文件

数据库SPFILE参数指定了当前使用的数据库配置参数,在数据库启动时被使用。

在附录A列出了数据库所有的非默认值的参数。

建议:

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

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

4.6CRS日志文件

从Oracle10gRAC版本开始,新增加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控制文件

每个数据库至少有一个控制文件。

控制文件记录了数据库的物理结构及同步信息。

Controlfilelocation

控制文件路径如下:

Name

Status

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

建议:

4.9Redolog文件

对于恢复操作,最为关键的结构是在线RedoLog。

在线RedoLog一般由两个或两个以上预先分配的存储数据库变化的文件组成。

为了防止例程故障,每个数据库的实例都有相关的在线RedoLog。

每个数据库至少有两个RedoLog组,每组至少有一个日志文件。

Oracle的多重在线RedoLog文件可以确保在线日志文件的安全。

对于多重在线RedoLog文件,LGWR同时将相同的RedoLog信息写入不同的RedoLog文件中,从而减少单个文件丢失的损失。

当Oracle无法访问一个RedoLog文件时,这个文件状态变为INVALID。

当Oracle推测一个RedoLog文件不完整或者不正确时,它的状态变为STALE。

当一个STALE的文件被重用时,即其所在日志文件组活动时,此文件也能够使用。

在线RedoLog文件减少了数据库数据丢失的损失,比如当发生例程故障时,没有被写入数据文件的数据可以从在线RedoLog文件中恢复。

Group#

Thread#

Sequence#

Bytes

Members

Archived

Status

FirstChange#

FirstTime

建议:

4.10归档Redolog文件

Oracle允许将写满的在线RedoLog文件存放在一个或多个脱机位置,即归档RedoLog。

在线日志文件通过归档写入归档日志文件。

后台进程ARCn自动进行归档操作。

您能通过归档日志进行:

∙在线备份

∙基于时间的恢复

ArchivedRedoLogSettings

Parameter

Value

建议:

这里能够很好地在运行环境中使用归档RedoLog。

这样就能够进行基于时间的恢复。

监控归档日志文件所暂时存放的磁盘空间,根据实际情况调整归档日志文件备份到磁带的频度。

4.11数据文件

数据文件是数据库分配的物理文件。

在Oracle数据库中,一个表空间可以包含一个或多个物理文件。

而一个数据文件则只能关联一个表空间和一个数据库。

Oracle通过分配一定的磁盘空间以及所需要的文件头空间,为每个表空间创建一个数据文件。

Datafilelocations

检测数据文件的位置。

当数据文件增长过度,数据库中必须添加数据文件。

应该避免“哪里有空间,哪里建文件”的错误方法,因为这样会增加备份策略和文件维护的复杂性。

下面列出部分数据文件的位置。

Status

Name

Tablespace

FileNumber

RelativeFileNumber

Size

Used(MB)

Used(%)

Autoextensible

建议:

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

Autoextendcapabilities

通过自动扩展命令进行数据文件的自动扩展。

假定数据文件无法分配所需空间,那么它将提高数据文件的大小以获得更多空间。

建议:

4.12表空间

每个数据库由一个或多个逻辑存储单位,即表空间,所组成。

而表空间则由逻辑存储单位段所组成。

而段将被分为多个片。

TablespaceManagement

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

Status

Name

Type

ExtentManagement

SegmentSpaceManagement

Size(MB)

Used(MB)

Used(%)

建议:

TablespaceDefaultStorageManagement

每个表空间中,可以为创建的对象指定缺省的存储参数。

创建对象时指定的存储参数将覆盖缺省值。

如果在创建对象时没有指定存储参数,那么系统将使用缺省值。

表空间缺省存储情况:

Name

Type

InitialExtent

NextExtent

LargestFreeExtent

MinimumExtents

MaximumExtents

MinimumExtentLength

Increase(%)

数据库表空间的管理方式均为本地管理,这有利于减少表空间级别的碎片,同时避免了DB在进行空间管理时对数据字典表(FET$、UET$)的争用。

我们知道系统中存在越多的空闲extent,越容易发生碎片问题。

其中空闲extent的大小非常重要,如果在表空间上有许多个无法满足指定的next大小的空闲extent,那这个空闲extent就无法被重新使用并成为碎片,这时就需要重新整理碎片;我们可以使用COALESCE命令合并相邻的extent,来减少系统中的碎片。

如果系统中不连续的小空闲extent过多,也就是碎片过多,则可能需要通过重建表空间的方式来消除碎片。

系统多数表空间使用ASSM,ASSM使用位图而不是传统的FreeList来管理段内的freedbblock,大大提升了空间管理的性能。

同时显著的减少segmentheader类型的bufferbusywait等待事件。

建议:

表空间的管理方式选择合理。

NextExtent

保证段能够增长是很重要的,因此在必要时分配nextextent。

如果在表空间中没有足够的空余空间,那么nextextent无法分配,对象也无法增长。

在数据库中没有发现无法分配NEXTEXTENT的段。

TemporaryTablespace

临时表空间用于存放临时段。

为了维护数据库的性能,临时表空间的维护方法有别于其他一般表空间。

缺省情况下,所有表空间都创建为PERMANENT。

所以在创建临时段时,需要保证表空间类型为TEMPORARY。

由于这些表空间中的排序段不被清除,所以减少了空间事务争夺,同时减少了SMON对于CPU的使用率。

当进行长时间清理时,用户无法进行排序操作。

在这种情况下,可以指定用户使用状态为PERMANENT的临时表空间。

这有可能会引起空间事务争夺,但是可以允许用户在磁盘上进行排序操作。

由于表空间的extent使用了localmanagement方式,对表空间采用位图管理,更利于空间的使用及回收管理。

Status

Name

Size(MiB)

MinimumExtents

MaximumExtents

MinimumExtentLength

Increase(%)

建议:

在数据库TEMP为TEMPORARY类型的表空间,ExtentManagement方式为LOCAL。

保证每一个数据库用户都被分配一个临时类型的TEMP表空间。

以下列出了将PERMANENT表空间作为默认临时表空间的用户:

没有发现用户将PERMANENT表空间作为默认临时表空间。

4.13回滚段管理

回滚段能够用来保证读一致性,回滚事务以及恢复数据库。

RollbackSegmentList

5.数据库简单风险评估

5.1安全性管理

在安全性方面,主要考虑用户访问数据库的控制以及维护系统的安全性问题。

DatabaseAdministratorUsernames/Passwords

Oracle自动生成两个用户,并授予DBA权限:

∙SYS

∙SYSTEM

经检查,SYS和SYSTEM都没有使用初始缺省密码。

这样有利于维护数据库的安全性,否则任何具有Oracle知识背景的人都能进入数据库。

建议:

目前数据库用户安全方面设置良好,设置安全合理。

SYSDBAUsers

被授予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.2SQL*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.3TNSNAMES

TNSNAMES.ORA包含与连接描述符相匹配的网络服务名。

连接描述符包括监听程序的地址以及connect_data。

TNSNAMES.ORA设置如下:

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

7.数据库性能

数据库的性能情况通过AWR的报告来体现。

由于本次检查并不是完整的性能检查,所以本报告只列举最主要的性能问题。

XXXX

SnapId

SnapTime

Sessions

Cursors/Session

BeginSnap:

EndSnap:

Elapsed:

DBTime:

YYYY

SnapId

SnapTime

Sessions

Cursors/Session

BeginSnap:

EndSnap:

Elapsed:

DBTime:

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

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

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

XXXX

StatisticName

Time(s)

%ofDBTime

sqlexecuteelapsedtime

DBCPU

parsetimeelapsed

hardparseelapsedtime

hardparse(sharingcriteria)elapsedtime

PL/SQLexecutionelapsedtime

PL/SQLcompilationelapsedtime

connectionmanagementcallelapsedtime

sequenceloadelapsedtime

repeatedbindelapsedtime

hardparse(bindmismatch)elapsedtime

DBtime

backgroundelapsedtime

backgroundcputime

YYYY

StatisticName

Time(s)

%ofDBTime

DBCPU

sqlexecuteelapsedtime

parsetimeelapsed

hardparseelapsedtime

hardparse(sharingcriteria)elapsedtime

hardparse(bindmismatch)elapsedtime

PL/SQLexecutionelapsedtime

sequenceloadelapsedtime

PL/SQLcompilationelapsedtime

connectionmanagementcallelapsedtime

inboundPL/SQLrpcelapsedtime

repeatedbindelapsedtime

DBtime

backgroundelapsedtime

backgroundcputime

7.2数据库负荷压力分析

XXXX

LoadProfil

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > IT计算机 > 电脑基础知识

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2