完整word版Oracle巡检模板文档格式.docx
《完整word版Oracle巡检模板文档格式.docx》由会员分享，可在线阅读，更多相关《完整word版Oracle巡检模板文档格式.docx（16页珍藏版）》请在冰豆网上搜索。
监听器的设置
TNSNAMES
数据库备份和恢复
数据库性能
如果工程师在检查中发现ORACLE配置或性能方面的问题，我们将对检查范围内的情况进行记录，并提出建议。
此次检查所需的资料来源主要是2009年1月16日09:
30–18:
00期间对数据库的监控结果。
建议
以下是本次检查发现的一些主要问题和建议的总结。
No.
问题描述
参考章节
建议解决时间
1
联机日志每个实例只有2组，建议增加到3－4组
联机日志
立即解决
2
近期解决
3
4
存在部分消耗资源的SQL，建议持续监控并优化
5
数据库版本不是最新稳定版本
将来解决
检查方面
评价/发现情况
主机配置
主机配置基本合理，满足当前系统的需要。
内存资源充足，CPU资源充足。
数据库配置较好，但有个别方面需要改进。
数据库性能较好。
3.介绍
目标
数据库配置/性能检查是用来：
-评价数据库当前配置及性能情况
-分析数据库应用瓶颈和资源竞争情况
-指出存在的问题，提出解决建议
检查方法
本次数据库性能检查的工具是：
∙操作系统工具和命令检查操作系统。
∙SQL命令检查数据库配置，SQL命令在ORACLE工具SQL*PLUS中运行。
∙ORACLE工具STATSPACK进行数据库性能资料的收集.
∙ORACLE工具RDA（REMOTEDIAGNOSTICAGENT）进行系统信息收集.
∙ORACLE工具OEM（ORACLEENTERPRISEMANAGER）/PERFORMANCEMANAGER进行数据库运行情况的监控及分析
上述输出结果为建议提供依据。
检查范围
本报告提供的检查和建议主要针对以下方面：
1.主机配置
2.操作系统性能
3.数据库配置
4.数据库性能
本报告的提供的检查和建议不涉及：
-具体的性能调整
-应用程序的具体细节
4.系统配置信息
这个部分列出数据库及所在主机的基本信息。
节点1
节点2
IP
132.77.121.102
主机名
IOM_DB_P570_1
服务器
AIXp570
内存
22GB
CPU个数
16
操作系统
AIX5300-04
Cluster软件
操作系统主要参数
ulimit-a
OracleOwner用户名
Oracle版本
Oracle补丁
$HOME
$ORACLE_BASE
$ORACLE_HOME
警告日志文件存储路径
$ORACLE_SID
bcciom1
SGA
LISTENER端口
1521
2x500MB,1member（s）/group
DB_NAME
Bcciom
DB_BLOCK_SIZE
8192
数据文件大小
150GB
数据文件个数
22
表空间个数
10
控制文件个数
字符集
ZHS16GBK
归档方式
Y
备份方式
RMAN备份到磁带库（TSM）
存储设备
数据库文件存储方式
RAWDEVICE
5.操作系统性能
以下的部分是对操作系统性能的基本分析（并不是针对操作系统或硬件的全面深入的检查），可以从中确定一些性能方面的问题。
这个分析使用的是操作系统的工具:
topas/vmstat/iostat/sar.主要从以下方面来检查操作系统的性能：
CPU利用率、内存、Paging、Swapping、硬盘IO，时间段是2009年1月16日10:
20：
IOM_DB_P570_1:
sar-qu55
vmstat55
从上述的情况中看出，CPU空闲率基本在30％左右，CPU满足需求。
Running/WaitingQueue情况正常。
内存空闲较多。
系统WAITIO正常。
结论/建议
操作系统性能总体较好。
6.数据库配置
这个部分详细阐述了数据库的主要结构。
文件系统
文件系统使用情况
正常。
数据库的当前版本是Oracle9.2.0.5。
9.2.0.5不是当前9i的最新稳定版本，本系统使用这个版本是应用系统和这个版本经过了较好的磨合，从长远考虑建议升级到9.2.0.7或更高稳定版本。
数据库初始化参数
Oracle数据库初始化参数保存在PFILE或SPFILE中，在数据库实例启动时被使用。
本数据库的初始化参数可以看出是经过精心设置的：
IOM_DB_P570_1>
cat/tmp/pfile.ora
暂无建议。
运行日志错误检查
Oracle数据库进程生成alert.log日志文件和跟踪文件（.trc）来记录警告、错误或冲突等信息，这些文件可以用来监控Oracle运行状态和进一步分析问题。
近期无需要特别关注的报错。
无
每个数据库至少有一个控制文件，一般使用多个镜像的控制文件用来保证数据库安全。
控制文件记录了数据库的物理结构及同步信息。
以下本数据库控制文件信息：
select*fromv$controlfile;
STATUSNAME
-------------------------------------------------------
/oradata/bcciom/control01.ctl
/oradata/bcciom/control02.ctl
/oradata/bcciom/control03.ct
联机日志（OnlineRedoLog）
对于恢复操作，最为关键的结构是在线RedoLog。
在线RedoLog一般由两个或两个以上预先分配的存储数据库变化的文件组成。
为了防止例程故障，每个数据库的例程都有相关的在线RedoLog。
每个数据库至少有两个RedoLog组，每组至少有一个日志文件。
Oracle的多重在线RedoLog文件可以确保在线日志文件的安全。
对于多重在线RedoLog文件，LGWR同时将相同的RedoLog信息写入不同的RedoLog文件中，从而减少单个文件丢失的损失。
当Oracle无法访问一个RedoLog文件时，这个文件状态变为INVALID。
当Oracle推测一个RedoLog文件不完整或者不正确时，它的状态变为STALE。
当一个STALE的文件被重用时，即其所在日志文件组活动时，此文件也能够使用。
在线RedoLog文件减少了数据库数据丢失的损失，比如当发生例程故障时，没有被写入数据文件的数据可以从在线RedoLog文件中恢复。
当前数据库的OnlineRedolog文件信息（v$log,v$logfile）
每个实例只有2组REDOLOG，建议每实例增加到3或4组。
数据文件管理（包括临时文件）
数据文件是数据库分配的物理文件。
在Oracle数据库中，一个表空间可以包含一个或多个物理文件。
而一个数据文件则只能关联一个表空间和一个数据库。
一个数据文件可以是一个裸设备，也可是一个文件系统文件。
以下本数据库数据文件空间的管理和使用情况。
selectdistinctblock_sizefromdba_tablespaces;
setlinesize110pagesize50
colfile_idfor9999999
colfile_namefora48
colts_namefora18
colcur_mbfor99999
colmax_mbfor99999
selectstatus,file_id,file_name,tablespace_namets_name,autoextensible,
blocks/128cur_mb,maxblocks/128max_mb
fromdba_data_filesorderbyfile_name;
fromdba_temp_filesorderbyfile_name;
数据文件都存放在裸设备上。
数据文件的Autoextend都设为NO，正常
建议：
表空间管理
每个数据库由一个或多个逻辑存储单位，即表空间所组成。
以下是本数据库表空间的管理和使用情况：
setlinesize100pagesize50
coltablespace_nameformata20
colcontentsfora9
colext_mgmtfora8
colalloc_typefora9
colext_kbformat999999
colssmfora6
coltotal_mbformata12
colfree_mbformata12
colfree_pctformata7
selectc.tablespace_name,c.contents,c.extent_managementext_mgmt,
c.allocation_typealloc_type,c.initial_extent/1024ext_kb,
c.segment_space_managementSSM,a.total_mb,b.free_mb,
to_char（100*b.free_mb/a.total_mb,'
999.99'
）free_pct
from
（selecttablespace_name,to_char（sum（bytes）/1048576,'
99999999.99'
）total_mb
fromdba_data_filesgroupbytablespace_name）a,
）free_mb,
count（*）free_exts,to_char（max（bytes）/1048576,'
99999999'
）max_mb,
to_char（min（bytes）/1048576,'
）min_mb
fromdba_free_spacegroupbytablespace_name）b,
dba_tablespacesc
wherea.tablespace_name=b.tablespace_name（+）andc.tablespace_name=b.tablespace_name
orderbyfree_pct,tablespace_name;
系统表空间（SYSTEM）：
系统表空间非常重要，数据库用户不应以SYSTEM为缺省表空间或临时表空间，也不应把对象建立在SYSTEM表空间内。
以下是本数据库系统表空间的管理和使用情况：
selectowner,count（*）fromdba_segmentswheretablespace_name='
SYSTEM'
groupbyowner;
selectusername,default_tablespace,temporary_tablespacefromdba_users
wheredefault_tablespace='
ortemporary_tablespace='
;
没有应用数据对象存放在系统表空间，正常。
没有应用用户缺省或临时表空间设为SYSTEM，正常。
回滚段
以下数据库的回滚段信息。
采用Oracle9i/10g缺省的自动管理方式。
数据库对象管理
处于无效状态的数据库对象：
selectcount（*）fromdba_objectswherestatus='
INVALID'
selectowner,count（*）fromdba_objectswherestatus='
发现INVALID的对象。
请检查以上INVALID对象是否为应用必需的，如不需要可以drop掉；
如果是需要的，请进行重新编译。
表/索引碎片、表的行迁移/行链接等：
selectowner,table_name,tablespace_name,chain_cntfromdba_tableswherechain_cnt>
0;
selectOWNER||'
.'
||index_nameas"
OWNER.INDEX_NAME"
blevelfromdba_indexeswhereblevel>
=4orderby2desc;
在安全性方面，主要考虑用户访问数据库的控制以及维护系统的安全性问题。
Oracle自动生成两个用户，并授予DBA权限，SYS的初始密码为CHANGE_ON_INSTALL，SYSTEM的初始密码是MANAGER。
拥用SYSDBA权限的用户列表：
拥用DBA权限的用户列表：
经测试，本数据库的SYSTEM用户口令没采用缺省值，正常。
没有其它应用用户被授予DBA权限，正常。
7.OracleNet
概况
OracleNet能够在不同计算机上安装服务和应用程序，并且能够使它们如同同一层上的应用程序一样进行通信。
OracleNet的主要功能就是创建网络通话，并且在客户端和服务器端，或者两个服务器端之间转换数据。
OracleNet必须安装在网络的每台使用Oracle的机器上。
当网络通路建立，OracleNet扮演着客户端和服务器端数据投递者的角色。
LISTENER设置
当前监听设置正常：
SQL*Net设置
当前sqlnet.ora设置正常：
TNSNAMES设置
当前tnsnames.ora设置正常：
正常
8.备份与恢复
备份
采用RMAN把数据库和归档备份到磁带库。
xxxxx
定期检查备份的有效性。
恢复
1.根据不同的数据库失败情况制定相应的恢复策略。
数据库全库恢复
表空间恢复
数据文件恢复
数据表恢复
2.根据制定的恢复策略定期进行恢复测试。
9.数据库性能
数据库的性能情况通过STATSPACK/AWR的报告来体现。
系统负载情况
STATSPACKreportfor
DBNameDBIdInstanceInstNumReleaseClusterHost
-------------------------------------------------------------------------
TADB423494446tadb19.2.0.7.0NOTADB
SnapIdSnapTimeSessionsCurs/SessComment
---------------------------------------------------------------
BeginSnap:
420-May-0920:
38:
38139.6
EndSnap:
520-May-0920:
57:
19138.8
Elapsed:
18.68（mins）
CacheSizes（end）
~~~~~~~~~~~~~~~~~
BufferCache:
2,800MStdBlockSize:
8K
SharedPoolSize:
512MLogBuffer:
8,050K
LoadProfile
~~~~~~~~~~~~PerSecondPerTransaction
------------------------------
Redosize:
145,674.89453,615.42
Logicalreads:
11,837.9536,862.05
Blockchanges:
1,058.233,295.21
Physicalreads:
6,721.7120,930.65
Physicalwrites:
57.48178.98
Usercalls:
123.09383.30
Parses:
117.97367.33
Hardparses:
0.040.13
Sorts:
1.213.78
Logons:
0.000.01
Executes:
171.44533.85
Transactions:
0.32
%BlockschangedperRead:
8.94RecursiveCall%:
89.61
Rollbackpertransaction%:
0.00RowsperSort:
2801.63
InstanceEfficiencyPercentages（Target100%）
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BufferNowait%:
100.00RedoNoWait%:
100.00
BufferHit%:
43.48In-memorySort%:
LibraryHit%:
99.91SoftParse%:
99.96
ExecutetoParse%:
31.19LatchHit%:
ParseCPUtoParseElapsd%:
44.41%Non-ParseCPU:
99.73
SharedPoolStatisticsBeginEnd
------------
MemoryUsage%:
93.4293.41
%SQLwithexecutions>
1:
60.0460.67
%MemoryforSQLw/exec>
41.7841.92
Top5TimedEvents
~~~~~~~~~~~~~~~~~~%Total
EventWaitsTime（s）ElaTime
---------------------------------------------------------------------------
CPUtime62952.40
dbfilescatteredread1,300,48245938.25
dbfilesequentialread456,043988.17
directpathread4,9816.51
dbfileparallelwrite553.22
-------------------------------------------------------------
比较消耗资源的SQL语句
BufferGets
PhysicalReads
监控期间没有发现逻辑读/物理读比较高的SQL语句。
持续监控性能，寻找优化机会。
10.附录（Statspackreports）
升级会员 