Oracle数据库日常维护方案书

ORACLE数据库日常运行维护年度服务项目

方案书

目录

1

2 3

项目背景及目标 (5)

1.1项目背景 (5)

1.2项目目标 (5)

需求分析 (5)

项目总体方案 (7)

3.1数据库性能优化 (8)

3.1.1检查Oracle数据库性能 (8)

3.1.1.1

3.1.1.2

3.1.1.3

3.1.1.4

3.1.1.5

3.1.1.6

3.1.1.7

3.1.1.8

3.1.1.9

检查数据库的等待事件 (9)

Disk Read 最高的SQL 语句的获取 (9)

查找前十条性能差的sql (9)

等待时间最多的 5 个系统等待事件的获取 (9)

检查运行很久的SQL (9)

检查消耗CPU 最高的进程 (10)

检查碎片程度高的表 (10)

检查表空间的I/O 比例 (10)

检查文件系统的I/O 比例 (10)

3.1.1.10 检查死锁及处理 (10)

3.1.1.11 检查数据库cpu、I/O、内存性能 (11)

3.1.1.12 查看是否有僵死进程 (12)

3.1.1.13 检查行链接/迁移 (13)

3.1.1.14 定期做统计分析 (13)

3.1.1.15 检查缓冲区命中率 (14)

3.1.1.16 检查共享池命中率 (14)

3.1.1.17 检查排序区 (14)

3.1.1.18 检查日志缓冲区 (15)

3.1.2性能调优及方法 (15)

3.1.2.1

3.1.2.2

3.1.2.3

3.1.2.4

3.1.2.5

寻找问题根源 (16)

System_Event 事件 (16)

Session_Event 事件 (16)

Session_Wait (17)

应用优化 (17)

3.1.2.5.1

3.1.2.5.2

3.1.2.5.3

3.1.2.5.4

例程调优 (17)

I-O 优化 (19)

竞争优化 (19)

O-S 监控 (20)

3.2数据库备份恢复 (21)

3.2.1检查Oracle数据库备份结果 (21)

3.2.1.1

3.2.1.2

3.2.1.3

检查数据库备份日志信息 (21)

检查backup 卷中文件产生的时间 (22)

检查oracle 用户的email (22)

3.3数据库迁移 (22)

3.4数据库运维 (23)

3.4.1检查数据库基本状况 (23)

3.4.1.1 3.4.1.2 3.4.1.3 检查Oracle 实例状态 (23)

检查Oracle 服务进程 (24)

检查Oracle 监听状态 (24)

3.4.2检查系统和oracle日志文件 (25)

3.4.2.1 3.4.2.2 3.4.2.3 3.4.2.4 检查操作系统日志文件 (25)

检查oracle 日志文件 (26)

检查Oracle 核心转储目录 (26)

检查Root 用户和Oracle 用户的email (27)

3.4.3检查Oracle对象状态 (27)

3.4.3.1 3.4.3.2 3.4.3.3 3.4.3.4 3.4.3.5 3.4.3.6 检查Oracle 控制文件状态 (27)

检查Oracle 在线日志状态 (27)

检查Oracle 表空间的状态 (28)

检查Oracle 所有数据文件状态 (28)

检查无效对象 (29)

检查所有回滚段状态 (29)

3.4.4检查Oracle相关资源的使用情况 (30)

3.4.4.1 3.4.4.2 3.4.4.3 3.4.4.4 3.4.4.5 3.4.4.6 3.4.4.7 检查Oracle 初始化文件中相关参数值 (30)

检查数据库连接情况 (31)

检查系统磁盘空间 (32)

检查表空间使用情况 (32)

检查一些扩展异常的对象 (33)

检查system 表空间内的内容 (33)

检查对象的下一扩展与表空间的最大扩展值 (34)

3.4.5检查数据库安全性 (34)

3.4.5.1 3.4.5.2 检查系统安全日志信息 (35)

检查用户修改密码 (35)

3.4.6其他检查 (36)

3.4.6.1 3.4.6.2 3.4.6.3 3.4.6.4 3.4.6.5 Oracle Job 是否有失败 (36)

监控数据量的增长情况 (36)

检查失效的索引 (37)

检查不起作用的约束 (37)

检查无效的trigger (37)

4 项目实施及管理 (38)

4.1项目实施方案 (38)

4.1.1项目实施策略 (38)

4.1.2项目实施计划 (38)

4.1.3项目交付文档 (39)

4.1.3.1 4.1.3.2 交付要求 (39)

提交文件资料 (39)

5 支持服务体系 (40)

5.1.1售后服务 (40)

5.1.2电话支持 (40)

5.1.3现场服务 (40)

5.1.4电子邮件支持 (41)

5.1.5紧急故障处理 (41)

5.1.6 ORACLE定期巡检服务（24次/年） (41)

6 培训方案 (41)

6.1.1培训方式 (42)

6.1.2教师、教材使用及授课语言 (42)

6.1.3培训计划 (44)

6.1.4培训分工 (44)

1项目背景及目标

1.1项目背景

xxx信息化建设经过多年的发展和完善，已经建立成熟的网络环境及生产经

营管理的各类应用系统，目前全厂在线运行的PC近600台，近年来建设的企业资产管理、基建MIS 管理系统、全面预算管理系统、生产综合管理系统技术监督管理系统等若干应用信息系统多数是基于Oracle 数据库系统的应用。这些Oracle 数据库产品的标准服务都已经过了服务期。而各系统随着数据量的逐年

增加，陆续出现了性能问题，有必要进行数据库系统的升级及性能优化，以确保应用系统的正常运行，为全厂员工提供更好的信息服务。

1.2项目目标

?

? ?

? 尽早发现性能瓶颈，及时调整，保障数据库稳定高效工作；对各个系统数据库进行补丁升级服务，安装补丁前需要对补丁的可行性及风险即你想那个分析，并制定升级计划和应急回退计划。同时要做好系统备份准备及详细的测试工作，确保系统的稳定性、安全性，保障系统业务数据的安全；

数据库架构的合理化；

提升应用系统性能，完成各系统数据库的性能调优工作，包括：外部资源调优、行的重新安排调优、SQL 性能调优、表格和索引存储参数设置调优等。

各业务持续性得到有效的保证。

2需求分析

通过对xxx技术要求进行详实的分析以及xxx科技对xxx信息系统建设的了

解，xxxOracle产品日常运行维护项目主要从如下几个方面进行：

1、由于xxx有些系统软件建设的较早，目前存在不同版本的数据库共存的

现象，包括：Oralce8、Oracle9I以及Oracle10g等。而Oracle9I版本

之前的数据库SQL编程语句还不是业界通用的标准化的语句，它与后

面版本的SQL编程语句有很大的差别，所以在这方面的性能优化需要

做好充分备份的准备。

2、正是由于这些系统建设的较早，基于当时的实际情况，应用系统或数据

库都还存在一些不足，针对这些情况软件开发商都开发出相应的补丁

提供给用户进行升级以防范风险。所以在对各个系统数据库进行补丁

升级服务之前，需要对补丁的可行性、安全性及风险进行充分的测试

和分析。并制定相关的应急预案及数据库升级计划和应急回退计划，

同时还需要做好系统备份准备和详细的测试工作，以确保系统的稳定

性、安全性，从而保证系统业务数据的安全；

3、如上所说，这些系统建设的较为长久，由于长时间的运行各个系统存在

一些冗余，由于冗余的存在使得这些系统数据库需要进行性能的优

化，包括外部资源优化、行的重新安排以及SQL性能优化、表格和索

引存储参数等需要重新进行设置优化。

4、对于当前的一些应用如：企业资产管理系统(EAM)、基建MIS管理系统、

全面预算管理系统、生产综合管理系统、企业门户（EIP/EAI）系统、

综合指标统计分析系统、燃料管理信息系统、标准化管理信息系统、

档案管理信息系统、安健环管理系统、技术监督管理子系统、IT运维

服务系统、SIS系统接口数据库、生产图纸管理系统等等所有这些系

统都需要重新进行整理并形成一个完善的文档资料。

5、由于这些数据库系统承载着xxx非常重要的业务系统数据，所以在日常

维护中需要非常仔细，每周、每月、每季都需要有相应的巡检记录，

需要详细记载以下一些内容：

? ? ? 监控数据库对象的空间扩展情况监控数据量的增长情况

系统健康检查，检查以下内容:

? ? ? ? ? ? ? ? ? ? 数据库对象有效性检查

查看是否有危害到安全策略的问题。

查看alert、Sqlnet等日志并归档报错日志分析表和索引

查看对数据库会产生危害的增长速度

检查表空间碎片

数据库性能调整

预测数据库将来的性能

调整和维护工作

后续空间

3项目总体方案

建立在Oracle数据库上的关键业务系统，是当今企业的核心应用。如何改善其性能和可用性，是包括系统设计、维护和管理人员的最大挑战。为了更好地维护系统和数据库，必须随时了解系统和数据库的运行状况。但由于数据库维护具有一定的复杂性，增加了维护工作的难度。所以数据库维护需要借助一些相关的工具，优秀的数据库管理工具，可以大大简化生产环境下的应用维护和管理，提高IT人员的工作效率。数据库管理人员借助相应的工具可以主动、迅速、方便的监控系统的运行。

基于我公司多年在Oracle数据库的使用及研究经验上，对于Oracle数据库的管理，主要包括三方面的内容：

? ?

? 系统诊断：了解当前运行的Oracle的状态，发现数据库性能瓶颈；

空间管理：即数据库存储结构的调优，包括定期检查数据库的存储结构，发现Oracle数据库存储中的主要问题(如数据库碎片)，进行碎片重组和数据分布以及容量规划等；

调优SQL,分析对系统性能影响比较大的SQL语句，调整SQL语句的执行效率。使SQL存取尽可能少的数据块。

下面我们将从以下这几个方面详细阐述：

3.1数据库性能优化

Oracle 性能管理既是一种艺术，也是一种科学。从实用角度讲，它可以分

为两种类型，主动式和被动式性能管理。主动式性能管理涉及到特定系统实施初期的设计和开发，包括硬件选择、性能及容量规划，海量存储系统的选择，I-O 子系统配置及优化，以及如何对不同组件进行定制，以满足Oracle 数据库和应用系统的复杂要求。

被动式性能管理涉及到现有环境中不同组件的性能评估、故障排除和Oracle 环境的优化。本文旨在探讨如何进行被动式性能调优，以便为Oracle 性能调优提供必要的指导，从而避免仅仅通过反复尝试的方式进行性能调优，提高Oracle 性能管理的效率。

所以ORACLE 数据库性能恶化表现基本上都是用户响应时间比较长，须要用户长时间的等待。获得满意的用户响应时间有两个途径：

一是减少系统服务时间，即提高数据库的吞吐量；

二是减少用户等待时间，即减少用户访问同一数据库资源的冲突率。

对于以上的两个问题，通常我们采用以下几个方面来进行改善：

?

? ? ? ? 调整服务器内存分配。例如，可以根据数据库运行状况调整数据库系统全局区（SGA 区）的数据缓冲区、日志缓冲区和共享池的大小；还可以调整程序全局区（PGA 区）的大小。

调整硬盘I/O 问题，达到I/O 负载均衡。

调整运用程序结构设计

优化调整操作系统参数和使用资源管理器

SQL 优化、诊断latch 竞争、Rollback(undo) Segment 优化、提升block 的效率等等

3.1.1检查Oracle数据库性能

检查Oracle 数据库性能情况，包含：检查数据库的等待事件，检查死锁及处理，检查cpu、I/O、内存性能，查看是否有僵死进程，检查行链接/迁移，定期做统计分析，检查缓冲区命中率，检查共享池命中率，检查排序区，检查日志

ORACLE产品日常运行维护年度服务项目

缓冲区，总共十个部分。

3.1.1.1检查数据库的等待事件

如果数据库长时间持续出现大量像latch free，enqueue，buffer busy waits，db file sequential read，db file scattered read 等等待事件时，需要对其

进行分析，可能存在问题的语句。

3.1.1.2 Disk Read最高的SQL语句的获取

3.1.1.3查找前十条性能差的sql

3.1.1.4等待时间最多的5个系统等待事件的获取

3.1.1.5检查运行很久的SQL

3.1.1.6检查消耗CPU最高的进程

3.1.1.7检查碎片程度高的表

3.1.1.8检查表空间的I/O比例

3.1.1.9检查文件系统的I/O比例

3.1.1.10检查死锁及处理

查询目前锁对象信息：

oracle 级kill 掉该session：

操作系统级kill 掉session：

3.1.1.11检查数据库cpu、I/O、内存性能

记录数据库的cpu 使用、IO、内存等使用情况，使用vmstat,iostat,sar,top

等命令进行信息收集并检查这些信息，判断资源使用情况。

CPU使用情况：

注意上面的蓝色字体部分，此部分内容表示系统剩余的cpu，当其平均值下

降至10%以下的时视为CPU 使用率异常，需记录下该数值，并将状态记为异常。

?

内存使用情况： 如上所示，蓝色部分表示系统总内存，红色部分表示系统使用的内存，黄色

部分表示系统剩余内存，当剩余内存低于总内存的 10%时视为异常。

?

系统 I/O 情况： # iostat -k 1 3

Linux 2.6.9-22.ELsmp (AS14)

07/29/2012

avg-cpu:

%user

%nice

%sys %iowait

%idle 0.16

0.00

0.05

0.36

99.43

Device: sda

tps 3.33

kB_read/s

13.16

kB_wrtn/s

50.25

kB_read 94483478

kB_wrtn 360665804

avg-cpu:

%user

%nice

%sys %iowait

%idle

0.00

0.00

0.00

0.00 100.00

Device: sda

tps 0.00

kB_read/s

0.00

kB_wrtn/s

0.00

kB_read

kB_wrtn

如上所示，蓝色字体部分表示磁盘读写情况，红色字体部分为 cpu IO 等待 情况。

?

系统负载情况：

如上所示，蓝体字部分表示系统负载，后面的 3 个数值如果有高于 2.5 的时

候就表明系统在超负荷运转了，并将此值记录到巡检表，视为异常。

3.1.1.12 查看是否有僵死进程

有些僵尸进程有阻塞其他业务的正常运行，定期杀掉僵尸进程。

注：含有long raw 列的表有行链接是正常的,找到迁移行保存到chained_rows 表中, 如没有该表执行../rdbms/admin/utlchain.sql

Sql>analyze table tablename list chained rows;可通过表chained_rows 中

table_name,head_rowid看出哪些行是迁移行如:Sql>create table aa as select

a.* from sb_zsxx a,chained_rows b where a.rowid=

b.head_rowid and

b.table_name ='SB_ZSXX'; sql>delete from sb_zsxx where rowid in (select

head_rowid from chained_rows where table_name = 'SB_ZSXX'); sql>insert

into sb_zsxx select * from chained_row where table_name = 'SB_ZSXX';

3.1.1.14定期做统计分析

对于采用Oracle Cost-Based-Optimizer 的系统，需要定期对数据对象的统

计信息进行采集更新，使优化器可以根据准备的信息作出正确的explain plan。

在以下情况更需要进行统计信息的更新：

? ? ? 应用发生变化；

大规模数据迁移、历史数据迁出、其他数据的导入等；数据量发生变化。

查看表或索引的统计信息是否需更新，如：

Sql>Select table_name,num_rows,last_analyzed From user_tables where

table_name ='DJ_NSRXX'

sql>select count(*) from DJ_NSRXX 如num_rows 和count(*)如果行数相

差很多,则该表需要更新统计信息，建议一周做一次统计信息收集，如：Sql>exec sys.dbms_stats.gather_schema_stats(ownname=>'CTAIS2',cascade=>

TRUE,degree => 4);

如果命中率低于90% 则需加大数据库参数db_cache_size。

3.1.1.16检查共享池命中率

如低于95%，则需要调整应用程序使用绑定变量，或者调整数据库参数shared pool 的大小。

3.1.1.17检查排序区

如果disk/(memoty+row) 的比例过高，则需要调整

sort_area_size(workarea_size_policy=false 或

pga_aggregate_target(workarea_size_policy=true)。

如果 redo buffer allocation retries/redo entries 超过 1% ，则需要增

大 log_buffer 。

3.1.2 性能调优及方法

性能调优主要有主动调优和被动调优，主动调优在前面我们已经进行了阐述， 被动调优主要有以下方法进行。

? ? ?

? ? ? ? ?

确定合理的性能优化目标

测试并记录当前的性能指标

确定当前存在的 Oracle 性能瓶颈 (Oracle 中何处存在等待，哪个 SQL

语句与此有关)

确定当前的操作系统瓶颈

优化相关的组件 (应用、数据库、I/O 、连接 OS 及其它)

跟踪并实施变化管理制度

测试并记录目前的性能指标

重复第 3 到第 7 步直至达到既定的优化目标 不要对并非性能瓶颈的部分进行优化，否则可能引起额外的问题。正如任何 聪明的人会告诉你的：“如果还未坏，千万不要修”。更重要的是，一旦既定的优 化目标已经达到，就务必停止所有的优化。

获取 Oracle 的性能指标 (测试前及测试后)必须在峰值处理时测试并获取系 统在优化前和优化后的性能指标。数据采集不应在数据库 instance 刚刚起动后 进行。同时，测试数据应在峰值期间每过 15 分钟进行一次。初始化参数

ORACLE产品日常运行维护年度服务项目

TIMED_STATISTICS 应该被设为TRUE。

通过运行以下脚本开始快照：

$ORACLE_HOME/rdbms/admin/utlbstat.sql.

通过运行以下脚本结束快照：

$ORACLE_HOME/rdbms/admin/utlestat.sql.

完成utlestat.sql 操作后，会在当前目录中生成名为“report.txt”的文件，

包含系统的性能数据。该报告包括每15 分钟捕获的所有与Oracle 例程相关的

参数。

3.1.2.1寻找问题根源

如上所述，通过查看v$system_event 事件开始系统事件的问题诊断。下一

步是查看v$session_event，找出引起或经历等待事件的进程。最后一步是通过

v$session_wait 获得事件的细节。同时，应该进一步通过OS 进行深入分析，了解核心的CPU、内存和IO 状态参数。最后，结合两种不同的诊断的结论，找出系统瓶颈所在。

3.1.2.2 System_Event事件

v$system_event 可以从全局的角度查看Oracle 系统中的所有事件。尽管它

并不包括任何进程级的信息(当前或历史)，但却可以显示上次例程弹出后总的等

待时间。这种动态性能视图中的数据，会在下次例程起动时清零。出于这种原因，这种视力中的数据应该在不同时段进行抽样。

3.1.2.3 Session_Event事件

v$session_event 视图在进程级提供与v$system_event 相同的信息(即，

SID 等)。这种视图可以从“system-wide events” 级进一步钻取，到达进程级，

以确哪个进程引起或经历了等待事件。

ORACLE产品日常运行维护年度服务项目

3.1.2.4 Session_Wait

v$session_wait 视图在特定事件的进程级提供低层次的信息挖掘。不同于

其它一些视图，这种方式可以“实时”获取进程级的等待信息。这是真正有用的

信息。切记，每次查看这一视图得到的结果可能不一样。这可能与数据库中当前

的活动有关。

3.1.2.5应用优化

从统计(和现实) 的角度看，80% 的Oracle 系统性能问题可以通过SQL 代码

优化来解决。任何应用优化的过程，不外乎是索引优化、全表扫描、并行机制改

进和选择正确数据组合方法的过程。这正是要达到最佳应用性能所必须考虑的因

素。没有SQL 的优化，就无法实现高性能的应用。良好的SQL 语句可以减少CPU 资源的消耗，提高响应速度。同时，优化后的SQL 语句还可以提高应用的可扩

展性，这是除增加大量内存外，任何其它硬件手段也无法实现的。

3.1.2.5.1例程调优

需要配置的主要初始化参数

以下是一些已知与例程优化关系最密切的一些核心Oracle 初始化参数。它

们都会影响Oracle 及SGA 区的活动。任何对这些参数的改动，在实施到生产环

境之前，都必须进行测试。一旦改变了生产环境的参数，就必须对相关的Oracle

动态性能指标和操作系统的性能进行监测，寻找可能由此产生的异常现象。

1) DB_BLOCK_SIZE

该参数在数据库建立前设定，决定了数据库中每个数据块的大小。只有重新

建立数据库，才有可能改变该参数。db_block_size 的配置应遵循以下公式：

DB_BLOCK_SIZE = FILESYSTEM BLOCKSIZE >= O-S PAGESIZE 这可以确保Oracle 获得最佳I/O 性能，同时不会由于冗余或不必要的I/O，给I/O 子系统带来压力。

2) DB_BLOCK_BUFFERS

该参数决定了SGA 区数据库缓冲区中的块数量。由于这是Oracle 读取和写

ORACLE产品日常运行维护年度服务项目

入的区域，它的不正确配置会引起严重的I/O 性能问题。尽管缓冲区的大小与应

用性质、数据库大小、同步用户数等无关，它的确是SGA 区中最大的组件。经常

可以看到缓冲区占用75-80%SGA 区内存的情况。另外，这一参数设置过大，也会

引起整个系统的内存不足，引起操作系统过多的读写操作。

该参数及SHARED_POOL_SIZE 通常是两个最重要的SGA 优化目标。只有当数

据库缓冲率长时间低于70%时，才需要增加其大小说。即使在这种情况下，也需

要进一步审查应用的性能和整个系统的吞吐性。若存在延迟性的应用设计问题，

则无论数据库缓冲区的大小如何，缓冲和读写率都不会有太大改变为。在实调优

中，也曾发现由于SQL 语句的问题，出现缓冲率很高，但仍存在全系统性能问题

的情况。

3) SHARED_POOL_SIZE

该参数按字节数设定，定义了SGA 中共享区的大小。该组件的大小严重依赖

于应用的类型(即该应用是重用SQL，还是生成动态SQL，等等)。同时它也取决

于同步用户的数量，以及实例是否被配置成支持多线程服务器(MTS)。如果该应

用采用了MTS 配置，则共享区应该明显增加，因为光标状态和用户进程数据等程

序全局区域(PGA)都被置入了共享区。

有关多数应用的SHARED_POOL_SIZE 大小设置，可以从每10 个同步用户16 MB 共享区开始。这不是一成不变的，因为应用的性质最终会决定该组件的大小。只

有当库缓冲和字典缓冲使用率一直低于90%时，才需要关注这一参数。但如果应

用并未采用变量合并和/共离图标时，内存的数量并不会使缓冲使用率高于90%。

共享区过大会导致处理时间增加，甚至SQL 语句的挂起。如果应用不能有效

地重用SQL，则无论配置多大的库缓冲或字典缓冲都无济于事，不能改善缓冲使

用率。

另一个值得考虑的因素是需要随时使用的存储PL/SQL 代码数量。应用的核

心包可以通过查看DBA_SOURCE、USER_SOURCE 得以确认，其大小通过查询

DBA_OBJECT_SIZE 了解。另外，为了确定存储PL/SQL 是否被置于内存，可以查

询动态性能视图V$DB_OBJECT_SIZE。内时，包DBMS_SHARED_POOL 中的程序大小可被用于确定应用中大包的规模。

4) LOG_BUFFER