数据库日常运行维护方案

数据库日常运行维护方案

Oracle数据库日常运行维护方案

2019年3月

数据库日常运行维护方案

1 项目背景及目标

1.1 项目背景

XXX信息化建设经过多年的发展和完善，已经建立成熟的网络环境及业务及管理的各类应用系统，目前在线运行的 PC 近 XX台，近年来建设的XX业务管理等若干应用信息系统多数是基于 Oracle数据库系统的应用。这些Oracle 数据库产品的标准服务都已经过了服务期。而各系统随着数据量的逐年增加，陆续出现了性能问题，有必要进行数据库系统的升级及性能优化，以确保应用系统的正常运行，为XXX提供更好的信息服务。

1.2 项目目标

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

➢ 数据库架构的合理化；

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

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

2 需求分析

通过对 xxx 技术要求进行详实的分析以及 xxx信息系统建设的了解，各应用系统的Oracle产品日常运行维护项目主要从如下几个方面进行：

1、 由于 xxx 有些系统软件建设的较早，目前存在不同版本的数据库共存的现象，包括：Oralce8、Oracle9I、Oracle10g以及Oracle11g等。而 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 检查数据库的等待事件

set pages 80

set lines 120

col event for a40

select sid,event,p1,p2,p3,WAIT_TIME,SECONDS_IN_WAIT from v$session_wait

where event not like 'SQL%' and event not like 'rdbms%';

数据库日常运行维护方案

如果数据库长时间持续出现大量像latch free，enqueue，buffer busy waits，db

file sequential read，db file scattered read 等等待事件时，需要对其进行分析，可能存在问题的语句。

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

SELECT SQL_TEXT FROM (SELECT * FROM V$SQLAREA ORDER BY

DISK_READS) WHERE ROWNUM<=5 ;

3.1.1.3 查找前十条性能差的sql

SELECT * FROM (SELECT PARSING_USER_ID

FROM EXECUTIONS,SORTS,COMMAND_TYPE,DISK_READS,SQL_TEXT

V$SQLAREA ORDER BY DISK_READS DESC) WHERE ROWNUM<10 ;

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

SELECT * FROM (SELECT * FROM V$SYSTEM_EVENT WHERE EVENT NOT

LIKE 'SQL%' ORDER BY TOTAL_WAITS DESC) WHERE ROWNUM<=5;

3.1.1.5 检查运行很久的SQL

COLUMN USERNAME FORMAT A12;

COLUMN OPNAME FORMAT A16;

COLUMN PROGRESS FORMAT A8;

SELECT USERNAME,SID,OPNAME,ROUND(SOFAR*100 / TOTALWORK,0)

|| '%' AS PROGRESS,TIME_REMAINING,SQL_TEXT FROM

V$SESSION_LONGOPS , V$SQL WHERE TIME_REMAINING <> 0 AND

SQL_ADDRESS=ADDRESS AND SQL_HASH_VALUE = HASH_VALUE;

3.1.1.6 检查消耗CPU最高的进程

SET LINE 240;

SET VERIFY OFF;

数据库日常运行维护方案

COLUMN SID FORMAT 999;

COLUMN PID FORMAT 999;

COLUMN S_# FORMAT 999;

COLUMN USERNAME FORMAT A9 HEADING "ORA USER";

COLUMN PROGRAM FORMAT A29;

COLUMN SQL FORMAT A60;

COLUMN OSNAME FORMAT A9 HEADING "OS USER";

SELECT PID, SID, SPID,ME USERNAME,

OSNAME,#S_#,AL,M

PROGRAM,OUND,,RTRIM(SUBSTR(_TEXT, 1,80))

SQL FROM V$PROCESS P, V$SESSION S,V$SQLAREA A WHERE =

AND _ADDRESS = S (+) AND LIKE '%&1%';

3.1.1.7 检查碎片程度高的表

SELECT segment_name table_name,COUNT(*) extents FROM dba_segments WHERE

owner NOT IN ('SYS', 'SYSTEM') GROUP BY segment_name HAVING

COUNT(*)=(SELECT MAX(COUNT(*)) FROM dba_segments GROUP BY

segment_name);

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

SELECT PACE_NAME NAME,_NAME "FILE",

PYR, RD PBR,S PYW, WRT PBW FROM

V$FILESTAT F, DBA_DATA_FILES DF WHERE # = _ID ORDER BY

PACE_NAME;

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

SELECT SUBSTR(#,1,2) "#",SUBSTR(,1,30)

"NAME",,,,S FROM V$DATAFILE A,

V$FILESTAT B WHERE # = #;

数据库日常运行维护方案

3.1.1.10 检查死锁及处理

col sid for 999999;

col username for a10;

col schemaname for a10;

col osuser for a16;

col machine for a16;

col terminal for a20;

col owner for a10;

col object_name for a30;

col object_type for a10;

select

sid,serial#,username,SCHEMANAME,osuser,MACHINE,terminal,PROGRAM,owner,object_name,object_type,_id from dba_objects o,v$locked_object l,v$session s

where _id=_id and =n_id;

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

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

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

➢ CPU 使用情况

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

数据库日常运行维护方案

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

➢ 内存使用情况：

如上所示，蓝色部分表示系统总内存，红色部分表示系统使用的内存，黄色部分表示系统剩余内存，当剩余内存低于总内存的 10%时视为异常。

➢ 系统 I/O 情况：

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

➢ 系统负载情况：

如上所示，蓝体字部分表示系统负载，后面的 3 个数值如果有高于 2.5 的时候就表明系统在超负荷运转了，并将此值记录到巡检表，视为异常。

3.1.1.12 查看是否有僵死进程

select spid from v$process where addr not in (select paddr from v$session);

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

数据库日常运行维护方案

3.1.1.13 定期做统计分析

对于采用 Oracle Cost-Based-Optimizer 的系统，需要定期对数据对象的统计信息进行采集更新，使优化器可以根据准备的信息作出正确的 explain plan。在以下情况更需要进行统计信息的更新：

➢ 应用发生变化；

➢ 大规模数据迁移、历史数据迁出、其他数据的导入等；

➢ 数据量发生变化。

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

Select table_name,num_rows,last_analyzed From user_tables where table_name

='DJ_NSRXX'；

select count(*) from DJ_NSRXX；

如 num_rows 和 count(*)如果行数相差很多,则该表需要更新统计信息，建议一周做一次统计信息收集，如：

exec

__schema_stats(ownname=>'CTAIS2',cascade=>TRUE,degree

=> 4);

3.1.1.14 检查缓冲区命中率

SELECT + logical_reads, phys_reads,round(100*(/(+)),4) hit_ratioFROM v$sysstat a,v$sysstat b,v$sysstat c

WHERE ='db block gets' AND ='consistent gets' AND

='physical reads' ;

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

3.1.1.15 检查共享池命中率

select sum(pinhits)/sum(pins)*100 from v$librarycache;

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

sharedpool 的大小。

3.1.1.16 检查排序区

select name,value from v$sysstat where name like '%sort%';

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

数据库日常运行维护方案

sort_area_size(workarea_size_policy=false或pga_aggregate_target(workarea_size_policy=true)。

3.1.1.17 检查日志缓冲区

select name,value from v$sysstat where name in ('redo entries','redo buffer allocation

retries');

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

3.1.2 性能调优及方法

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

1、确定合理的性能优化目标。

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

3、确定当前存在的 Oracle 性能瓶颈 (Oracle 中何处存在等待，哪个 SQL语句与此有关)。

4、确定当前的操作系统瓶颈。

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

6、跟踪并实施变化管理制度。

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

8、重复第 3 到第 7 步直至达到既定的优化目标。

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

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

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

$ORACLE_HOME/rdbms/admin/

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

$ORACLE_HOME/rdbms/admin/

数据库日常运行维护方案

完成 操作后，会在当前目录中生成名为“”的文件，包含系统的性能数据。该报告包括每 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” 级进一步钻取，到达进程级，以确哪个进程引起或经历了等待事件。

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 读取和写入的区域，它的不正确配置会引起严重的 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

根据字节设定，该参数定义了 SGA 缓冲区中 redo log 的大小。缺省值通常是数据库块大小的四倍，这对于多数环境并不是最佳的。对于中型的 Oracle

环境，其结构应该为 512 Kb 左右。对该存储结构而言，更大并不意味着更好。超过 1 MB 就可能有问题。需要监控 V$SESSION_WAIT 中 log buffer space

的等待事件，以优化该内存结构。需要提醒的是，在线 redo log 文件的大小设置不当，会引起 redo 请求的等待。

5）DB_WRITERS

数据库日常运行维护方案

该参数可以针对所有文件系统支持，且不可使用 Direct I-O 的 Oracle 实施设定。这并不需要与 raw partitions 一起使用，因为异步 I-O 更加。建议将该参数设定为(2 * 独立磁盘驱动器数量/卷)。该参数只有在 中的

“average write queue length”持续高于 1 时，才需要设定。在 Oracle 8.0 和

更高版本中，该参数已不再被支持，而为其它两个名为

DB_WRITER_PROCESSES 和 DBWR_IO_SLAVES 的参数取代。若需要设置 DB_WRITER_PROCESSES 值高于 8，则 DB_WRITER_PROCESSES 可被设为 1，且 DBWR_IO_SLAVES 可被设为 “n”，其中 n 的值必须设置为

(2 * 独立磁盘驱动器数量/卷)。

3.1.2.5.2 I-O 优化

I-O 优化是系统优化中的一个关键步骤，还涉及到其它任务，将文件在不同驱动器/卷中进行分布，采用优化分区技术、确定 I-O 子系统瓶颈、确定控制器瓶颈并根据应用的类型选择最佳的 RAID 级。I-O 优化应该在全面了解 Oracle 及

Oracle RDBMS 结构之后进行。应该在进行 I-O 优化前后实施 I-O 数据监控，如

平均服务时间，IOPS，平均磁盘队列长度等。

3.1.2.5.3 竞争优化

多数与 Oracle 有关的竞争问题可以通过主动配置管理相关的初始化参数进行。不恰当地配置 中的锁参数可能引起竞争。为了不打破其中的平衡，所需的参数可进行配置并主动得以处理。

包括表在内的 数据库对 象可能存在 两个竞争 点。第一个 是所配置的“freelists”的数量 (缺省值为 1)。freelist 结构维护着表中可用于插入的块。对于存在大量同步插入的表，有必要配置该结构。为了以主动方式处理 freelist 竞争，必须在建立表时配置 FREELISTS。可考虑的最佳值为 (2 * CPU 数量) 。V$WAITSTAT 不可能指示存在 freelist 竞争，除非存在 freelist 组，而这种设置只存在于 Oracle Parallel Server 中。即便如此，也无法了解哪个表存在竞争中。主动式的 freelist 竞争 调优可以事先预防问题出现。

资源竞争的第二个来源与索引有关，即对象块头中配置的事务槽数量。事务槽

数据库日常运行维护方案

是块头中的区域，是事务处理进程采用自身识别号进行注册，以便任何被修改的更能够通过特定事务槽数量在低层得以识别的地方。如果所有现存的事务槽已 经被其它事务占用，服务器器进程会从块的 PCTFREE 中请求 23 个字节，建立一个新的槽。这种情况适用于存在大量同步事务的对象。对于事务槽的竞争，需要设置 INITRANS 参数。对于块大小为 8K 的数据库，多数情况下，4 为最佳设置，占用的空间仅为 92 字节，却可以大大减少运行时故障和性能问题。

3.1.2.5.4 O-S 监控

数据库忙时，应该对操作系统进行监控，因为操作系统的性能指标会揭示数据库活动的性质及其对系统的影响。例如，为了了解 CPU 的利用率，可以通过

system activity reporter (sar – u interval frequency) 、 mpstat (Sun Solaris), top (多数 UNIX)、 osview (SGI Irix) 及 vmstat 等命令。Sar 和 vmstat 也可被用于确定包括内存使用率、I-O 参数、队列等待、读取/交换区活 动等信息。在 Solaris 上，mpstat utility 也可用于获取前面提到的 CPU 利用率数据。Solaris 上的 Adrian 性能管理工具也很有用。可以利用其中的一到多个工具来确定系统的性能状况，找出可能存在的瓶颈。

Oracle 数据库性能的管理需要遵循系统的方法论，以确保所有核心问题得以解决。多数问题可以事先得以管理。了解与 O-S 相关的问题是成功的关键。勿需置疑，系统硬件配置上的良好平衡也是至关重要的。必须承认，80% 的系统性能问题可以通过书写更好的 SQL 语句来解决。来文试图探究其余 20%中可能覆盖的内容。同时，必须遵守严格的规定，在调优目标达到后终止所有努力。了解自己想到何处是重要的，更重要的是，要知道自己何时到达了目的地。

3.2 数据库备份恢复

为了保证客户数据库系统的数据安全性，降低各种故障、灾难给客户带来的数据丢失，根据客户系统实际情况，协助客户规划实施符合客户工作要求的完善的备份恢复方案，以确保客户数据库系统的安全可靠运行。数据库的恢复与备份主要有以下几点：

➢ 恢复管理器(RMAN)，能使备份恢复操作自动化。

数据库日常运行维护方案

➢ Oracle 数据泵，用以数据库的逻辑备份。

➢ 用户管理允许用户通过操作系统命令手动备份数据库。

➢ 各种各样的其他的数据库备份和恢复软件，增强了 Oracle 的备份实用程序。

Oracle 备份时应注意事项：当数据库处于运行状态时的热备份时，不备份活动事务；使用比如 Oracle 工具（Oracle RAMN）或者其他的第三方软件（IBM/Tivol的数据存储管理器）压缩 Oracle 备份数据；如果维持数据存储空间比备份和恢复数据库时间更重要的话，可以考虑使用二进制压缩。

3.2.1 检查Oracle数据库备份结果

检查 Oracle 数据库备份结果，是日常运维中必不可少的一个环节。包含：检查数据库备份日志信息，检查 backup 卷中文件产生的时间，检查 oracle 用户的

email，总共三个部分。

3.2.1.1 检查数据库备份日志信息

假设：备份的临时目录为/backup/hotbakup，我们需要检查 2018年12月28日的备份结果，则用下面的命令来检查：

#cat /backup/hotbackup/|grep –i error

备份脚本的日志文件为 hotbackup-月份-日期-年份.log，在备份的临时目录下面。如果文件中存在“ERROR:”，则表明备份没有成功，存在问题需要检查。

3.2.1.2 检查backup卷中文件产生的时间

#ls –lt /backup/hotbackup

backup 卷是备份的临时目录，查看输出结果中文件的日期，都应当是在当天凌晨由热备份脚本产生的。如果时间不对则表明热备份脚本没执行成功。

3.2.1.3 检查oracle用户的email

#tail –n 300 /var/mail/oracle

热备份脚本是通过 Oracle 用户的 cron 去执行的。cron 执行完后操作系统就

数据库日常运行维护方案

会发一条 Email 通知 Oracle 用户任务已经完成。查看 Oracle email 中今天凌晨部分有无 ORA-，Error，Failed 等出错信息，如果有则表明备份不正常。

3.3 数据库迁移

数据迁移是日常运维过程中存在的一个必不可少的应急方案。日常维护过程中，由于硬件的原因或其它一些外在因素需要对数据进行迁移，迁移到更加高级的主机上、迁移到远程的机房上、迁移到不同的平台下等等一些情况。对于数据迁移本公司有非常成熟的方案，从以下几种方式我们可以充分了解其优缺点：

➢ exp/imp：这也算是最常用最简单的方法了，一般是基于应用的 owner 级做导出导入；

 优点是可以跨平台使用；

 缺点是停机时间长，停机时间为从 exp 到网络传输到新库，再加上imp

的时间；

➢ 存储迁移：这种情况下，数据文件、控制文件、日志文件、spfile 都在存储上（一般情况下是裸设备），我们可以直接把存储挂到新机器上，然后在新机器上启动数据库；

 优点是该迁移方式非常简单，主要的工作是主机工程师的工作，dba只需配合即可，停机时间为当库、切存储、起库的时间。

 缺点是要求新老库都是同一平台，是相同的数据库版本。

➢ 利用 data guard 迁移；

 优点是停机时间短，停机时间为 switch over 的时间。

 缺点：主机必须双份、存储必须双份。

➢ 用 rman 做迁移，这种方式比较适合于跨文件系统的迁移，如同平台下的不同文件系统。

3.4 数据库运维

数据库的运维主要结合 xxx 系统的实际情况，提供切实可行的运维建设机制，内容覆盖 ORACLE 数据库的日常维护、紧急故障处理，软件升级等，客户可依据服务内容进行相应的定制。我们将会提供全面的、针对性的服务解决方案，以保

数据库日常运行维护方案

证客户系统稳定、高效、可靠的运行，以达到对业务系统的有效支持。

3.4.1 检查数据库基本状况

对数据库的基本状况进行检查，其中包含：检查Oracle实例状态，检查Oracle服务进程，检查 Oracle 监听进程，共三个部分。

3.4.1.1 检查Oracle实例状态

Sql>Select

v$instance;

instance_name,host_name,startup_time,status,database_status from

其 中 “STATUS” 表 示 Oracle 当 前 的 实 例 状 态 ， 必 须 为 “OPEN” ；

“DATABASE_STATUS”表示 Oracle 当前数据库的状态，必须为“ACTIVE”。

SQL> select name,log_mode,open_mode from v$database;

其中“LOG_MODE”表示 Oracle 当前的归档方式。“ARCHIVELOG”表示数据库运行在归档模式下，“NOARCHIVELOG”表示数据库运行在非归档模式下。在我们的系统中数据库必须运行在归档方式下。

3.4.1.2 检查Oracle服务进程

ps -ef|grep ora_|grep -v grep&&ps -ef|grep ora_|grep -v grep|wc –l

例如：

数据库日常运行维护方案

在检查 Oracle 的进程命令输出后，输出显示至少应包括以下一些进程：

 Oracle 写数据文件的进程，输出显示为：“ora_dbw0_CKDB”

 Oracle 写日志文件的进程，输出显示为：“ora_lgwr_ CKDB”

 Oracle 监听实例状态的进程，输出显示为：“ora_smon_ CKDB”

 Oracle 监听客户端连接进程状态的进程，输出显示为：“ora_pmon_CKDB”

 Oracle 进行归档的进程，输出显示为：“ora_arc0_ CKDB”

 Oracle 进行检查点的进程，输出显示为：“ora_ckpt_ CKDB”

 Oracle 进行恢复的进程，输出显示为：“ora_reco_ CKDB”

3.4.1.3 检查Oracle监听状态

/home/oracle>lsnrctl status

例如：

“Services Summary”项表示 Oracle 的监听进程正在监听哪些数据库实例，输出显

数据库日常运行维护方案

示中至少应该有“CKDB”这一项。

检查监听进程是否存在：

[oracle@AS14 ~]$ps -ef|grep lsn|grep -v grep

3.4.1.4 检查系统和oracle日志文件

检查相关的日志文件，包含：检查操作系统的日志文件，检查 Oracle 日志文件，检查 Oracle 核心转储目录，检查 Root 用户和 Oracle 用户的 email，总共四个部分。

3.4.1.5 检查操作系统日志文件

# cat /var/log/messages |grep failed

查看是否有与 Oracle 用户相关的出错信息。

3.4.1.6 检查oracle日志文件

cat /data/oracle/admin/CKDB/bdump/alert_ |grep ora

cat /data/oracle/admin/CKDB/bdump/alert_ |grep err

cat /data/oracle/admin/CKDB/bdump/alert_ |grep fail

Oracle 在运行过程中，会在警告日志文件(alert_)中记录数据库的一些运行情况：数据库的启动、关闭，启动时的非缺省参数；数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点(checkpoint)操作没有执行完成造成不能切换，会记录不能切换的原因；对数据库进行的某些操作，如创建或删除表空间、增加数据文件；数据库发生的错误，如表空间不够、出现坏块、数据库内部错误(ORA－600)等。定期检查日志文件，根据日志中发现的问题及时进行处理:

问题

启动参数不对

处理

检查初始化参数文件

因为检查点操作或归档操作没有完成如果经常发生这样的情况，可以考虑增造成重做日志不能切换 加重做日志文件组；想办法提高检查点或归档操作的效率；

有人未经授权删除了表空间 检查数据库的安全问题，是否密码太简

数据库日常运行维护方案

单；如有必要，撤消某些用户的系统权限

出现坏块 检查是否是硬件问题(如磁盘本生有坏块)，如果不是，检查是那个数据库对象出现了坏块，对这个对象进行重建

表空间不够

出现ORA-600

增加数据文件到相应的表空间

根据日志文件的内容查看相应的 TRC

文件，如果是 Oracle 的 bug，要及时打上相应的补丁

Listener 日志：$ORACLE_HOME/network/log

3.4.1.7 检查Oracle核心转储目录

$ls $ORACLE_BASE/admin/CKDB/cdump/*.trc|wc –l

$ls $ORACLE_BASE/admin/CKDB/udump/*.trc|wc –l

如果上面命令的结果每天都在增长，则说明 Oracle 进程经常发生核心转储。这说明某些用户进程或者数据库后台进程由于无法处理的原因而异常退出。频繁的核心转储特别是数据库后台进程的核心转储会导致数据库异常终止。

3.4.1.8 检查Root用户和Oracle用户的email

#tail –n 200 /var/mail/root

#tail –n 200 /var/mail/oracle

查看有无与 Oracle 用户相关的出错信息。

3.4.2 检查Oracle对象状态

检查相关 Oracle 对象的状态，包含：检查 Oracle 控制文件状态，检查 Oracle

在线日志状态，检查 Oracle 表空间的状态，检查 Oracle 所有数据文件状态，检查 Oracle 所有表、索引、存储过程、触发器、包等对象的状态，检查 Oracle 所有回滚段的状态，总共六个部分。

数据库日常运行维护方案

3.4.2.1 检查Oracle控制文件状态

SQL> select status,name from v$controlfile;

例如：

输出结果应该有 3 条以上（包含 3 条）的记录，“STATUS”应该为空。状态为空表示控制文件状态正常。

3.4.2.2 检查Oracle在线日志状态

SQL> select group#,status,type,member from v$logfile;

例如：

输出结果应该有 3 条以上（包含 3 条）记录，“STATUS”应该为非“INVALID”，非“DELETED”。 注：“STATUS”显示为空表示正常。

3.4.2.3 检查Oracle表空间的状态

SQL> select tablespace_name,status from dba_tablespaces;

例如：

数据库日常运行维护方案

输出结果中 STATUS 应该都为 ONLINE。

3.4.2.4 检查Oracle所有数据文件状态

SQL> select name,status from v$datafile;

例如：

输出结果中“STATUS”应该都为“ONLINE”。或者：输出结果中“STATUS”应该都为

数据库日常运行维护方案

“AVAILABLE”。

3.4.2.5 检查无效对象

sql>select owner,object_name,object_type from dba_objects where status!='VALID' and

owner!='SYS' and owner!='SYSTEM';

如果有记录返回，则说明存在无效对象。若这些对象与应用相关，那么需要重新编译生成这个对象。

3.4.2.6 检查所有回滚段状态

SQL> select segment_name,status from dba_rollback_segs;

输出结果中所有回滚段的“STATUS”应该为“ONLINE”。

3.4.3 检查Oracle相关资源的使用情况

检查 Oracle 相关资源的使用情况，包含：检查 Oracle 初始化文件中相关的参数值，检查数据库连接情况，检查系统磁盘空间，检查 Oracle 各个表空间使用情况，检查一些扩展异常的对象，检查 system 表空间内的内容，检查对象的下一扩展与表空间的最大扩展值，总共七个部分。

3.4.3.1 检查Oracle初始化文件中相关参数值

SQL> select resource_name,max_utilization,initial_allocation,limit_value from

v$resource_limit;

例如：

数据库日常运行维护方案

若 LIMIT_VALU-MAX_UTILIZATION<=5，则表明 与 RESOURCE_NAME 相关的Oracle 初始化参数需要调整。可以通过修改 Oracle 初始化参数文件

$ORACLE_BASE/admin/CKDB/pfile/ 来修改。

3.4.3.2 检查数据库连接情况

查看当前会话连接数，是否属于正常范围。

SQL> select sid,serial#,username,program,machine,status from v$session;

例如：

数据库日常运行维护方案

其中：

SID 会话(session)的 ID 号；

SERIAL# 会话的序列号，和 SID 一起用来唯一标识一个会话；

USERNAME 建立该会话的用户名；

PROGRAM 这个会话是用什么工具连接到数据库的；

STATUS 当前这个会话的状态，ACTIVE 表示会话正在执行某些任务，INACTIVE 表示当前会话没有执行任何操作；

如果建立了过多的连接，会消耗数据库的资源，同时，对一些“挂死”的连接可能需要手工进行清理。如果 DBA 要手工断开某个会话，则执行：（一般不建议使用这种方式去杀掉数据库的连接，这样有时候 session 不会断开。容易引起死连接。建议通过 sid 查到操作系统的 spid,使用 ps –ef|grep spidno 的方式确认 spid

不是 ORACLE 的后台进程。使用操作系统的 kill -9 命令杀掉连接 ）。

注意：上例中 SID 为 1 到 10(USERNAME 列为空)的会话，是 Oracle 的后台进程，不要对这些会话进行任何操作。

3.4.3.3 检查系统磁盘空间

如果文件系统的剩余空间过小或增长较快，需对其进行确认并删除不用的文件。

[oracle@AS14 ~]$ df –h

数据库日常运行维护方案

3.4.3.4 检查表空间使用情况

SQL> select pace_name,,,round((/)*100) "% Free"

from

(select tablespace_name, sum(bytes/(1024*1024)) total from dba_data_files group by

tablespace_name) a,

(select tablespace_name, round(sum(bytes/(1024*1024))) free from dba_free_space

group by tablespace_name) f

WHERE pace_name = pace_name(+)

order by "% Free";

如果空闲率%Free 小于 10%以上（包含 10%），则注意要增加数据文件来扩展表空间而不要是用数据文件的自动扩展功能。请不要对表空间增加过多的数据文件，增加数据文件的原则是每个数据文件大小为 2G 或者 4G，自动扩展的最大限制在 8G。

3.4.3.5 检查一些扩展异常的对象

sql>select Segment_Name, Segment_Type, TableSpace_Name,

(Extents/Max_extents)*100 Percent From _Segments

Where Max_Extents != 0 and (Extents/Max_extents)*100>=95

order By Percent;

如果有记录返回，则这些对象的扩展已经快达到它定义时的最大扩展值。对于这些对象要修改它的存储结构参数。

3.4.3.6 检查system表空间内的内容

SQL> select distinct(owner) from dba_tables

where tablespace_name='SYSTEM' and owner!='SYS' and owner!='SYSTEM'

union

select distinct(owner) from dba_indexes

where tablespace_name='SYSTEM' and owner!='SYS' and owner!='SYSTEM';

如果记录返回，则表明 system 表空间内存在一些非 system 和 sys 用户的对象。应该进一步检查这些对象是否与我们应用相关。如果相关则把这些对象移到非

数据库日常运行维护方案

System 表空间，同时应该检查这些对象属主的缺省表空间值。

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

sql>select _name, _extent, pace_name

from all_tables a,

(select tablespace_name, max(bytes) as big_chunk

from dba_free_space group by tablespace_name ) f

where pace_name = pace_name

and _extent > _chunk

union

select _name, _extent, pace_name

from all_indexes a,

(select tablespace_name, max(bytes) as big_chunk

from dba_free_space group by tablespace_name ) f

where pace_name = pace_name

and _extent > _chunk;

如果有记录返回，则表明这些对象的下一个扩展大于该对象所属表空间的最大扩展值，需调整相应表空间的存储参数。

3.4.4 检查数据库安全性

检查 Oracle 数据库的安全性，包含：检查系统安全信息，定期修改密码，总共两个部分。

3.4.4.1 检查系统安全日志信息

系统安全日志文件的目录在/var/log 下，主要检查登录成功或失败的用户日志信息。

检查登录成功的日志：

[root@rac2 ~]# grep -i accepted /var/log/secure

检查登录失败的日志：

[root@rac2 ~]# grep -i inval /var/log/secure &&grep -i failed /var/log/secure

在出现的日志信息中没有错误(Invalid、refused)提示，如果没有(Invalid、refused)视为系统正常，出现错误提示，应作出系统告警通知。

数据库日常运行维护方案

3.4.4.2 检查用户修改密码

在数据库系统上往往存在很多的用户，如：第三方数据库监控系统，初始安装数据库时的演示用户，管理员用户等等，这些用户的密码往往是写定的，被很多人知道，会被别有用心的人利用来攻击系统甚至进行修改数据。需要修改密码的用户包括：

数据库管理员用户 SYS，SYSTEM；其他用户。

登陆系统后，提示符下输入 cat /etc/passwd，在列出来的用户中查看是否存在已经不再使用的或是陌生的帐号。若存在，则记录为异常。

Sql>alter user USER_NAME identified by PASSWORD;

3.4.5 其他检查

检查当前 crontab 任务是否正常，检查 Oracle Job 是否有失败等共六个部分。

3.4.5.1 Oracle Job是否有失败

Sql>select job,what,last_date,next_date,failures,broken from dba_jobs

Where schema_user='CAIKE';

如有问题建议重建 job，

如：

exec _(1);

commit;

exec _t

(1,'REFRESH_ALL_SNAPSHOT;',SYSDATE+1/1440,'SYSDATE+4/1440');

commit;

3.4.5.2 监控数据量的增长情况

SQL> select

pace_name,(1-()/)*100 used_percent

from (select tablespace_name,sum(bytes) total

from dba_free_space group by tablespace_name) A,

(select tablespace_name,sum(bytes) total

from dba_data_files group by tablespace_name) B

where pace_name=pace_name;

数据库日常运行维护方案

根据本周每天的检查情况找到空间扩展很快的数据库对象,并采取相应的措施：

➢ 删除历史数据

移动规定数据库中至少保留 6 个月的历史数据，所以以前的历史数据可以考虑备份然后进行清除以便释放其所占的资源空间。

➢ 扩表空间

alter tablespace add datafile ‘’ size autoextend off;

注意：在数据库结构发生变化时，如增加了表空间，增加了数据文件或重做日志文件这些操作，都会造成 Oracle 数据库控制文件的变化，DBA 应及进行控制文件的备份，备份方法是：

alter database backup controlfile to '/home/backup/';

或

alter database backup controlfile to trace;

这样，会在 USER_DUMP_DEST(初始化参数文件中指定)目录下生成创建控制文件的 SQL 命令。

3.4.5.3 检查失效的索引

Sql>select index_name,table_name,tablespace_name,status From dba_indexes Where

owner='CTAIS2' And status<>'VALID';

注：分区表上的索引 status 为 N/A 是正常的，如有失效索引则对该索引做

rebuild ， 如 ：

Sql>alter index INDEX_NAME rebuild tablespace TABLESPACE_NAME;

3.4.5.4 检查不起作用的约束

Sql> SELECT owner, constraint_name, table_name, constraint_type, status FROM

dba_constraints WHERE status ='DISABLE' and constraint_type='P';

如有失效约束则启用，如：

Sql>alter Table TABLE_NAME Enable Constraints CONSTRAINT_NAME;

3.4.5.5 检查无效的trigger

Sql> SELECT owner, trigger_name, table_name, status FROM dba_triggers WHERE

status = 'DISABLED';

数据库日常运行维护方案

如有失效触发器则启用，如：

Sql>alter Trigger TRIGGER_NAME Enable;

4 项目实施及管理

4.1 项目实施方案

4.1.1 项目实施策略

项目的实施成功与否主要表现为“两个机制、一个测试”：顺畅沟通机制和技术转移机制、模拟测试。

➢ 顺畅沟通机制：建立和用户方的良好顺畅的协调机制；

➢ 技术转移机制：系统在移交后，日常的管理工作有比较大的专业性，成功的技术转移是以后系统良好运作的前提和保证。建议用户方的技术负责人和系统管理员对项目的全程深入参与。

➢ 模拟测试：通过在模拟环境完成系统调试后并在真实环境完成试运行测试。

因而在本次 Oralce 日常运行维护服务的过程中，我们 xxx 科技也将按照软件项目实施的策略来进行管理，从而保证整个项目的维护就如同开发过程一样严格管理。

4.1.2 项目实施计划

数据库日常运行维护年度服务项目是一个长期的优化维护项目，本项目是、我公司根据多年的开发维护经验可分为两个阶段。第一个阶段为优化实施阶段，包括各个应用系统的环境情况调查，应用系统的统计登记、数据库系统的优化等。第二个阶段为运维阶段，主要包括相关应用的培训，数据库管理培训、数据库备份恢复的培训以及后期系统运维、检查等保护措施，定期对全厂数据库及系统进行巡检，巡检内容包括：系统日志、网络状况、系统空间状况、存储设备状态、系统性能、产品参数与配置、数据库各种文件的状态与配置、数据库安全审计、数据对象配置的合理性、实例的运行效率、SQL 代码性能调优等。

数据库日常运行维护方案

4.1.3 项目交付文档

4.1.3.1 交付要求

我公司提供的资料将使用国家法定单位制即国际单位制，语言为中文。提供的纸介质文件时需同时提供 Office 电子版文件。资料的组织结构清晰、逻辑性强。资料内容正确、准确、一致、清晰完整，满足项目要求。

4.1.3.2 提交文件资料

项目文档的内容至少包括系统的维护手册、数据库定期巡检记录、数据库日常运维手册、文档介质包括：

 系统信息表

 数据库日常运维手册

 数据库定期巡检记录表

 其他相关的技术资料

5 支持服务体系

一个系统开发与实施的成功与否，很大程度上取决于使用单位对该系统的使用情况，一个再好的系统如果没有人使用，那么也不能说该系统是成功的，只能说它是失败的。所以我公司尤其重视对使用单位的人员针对系统的使用培训，并根据不同的使用权限及功能进行有针对性的培训服务。

5.1 技术支持服务

我公司设有专门的技术支持中心,为客户提供快捷周到的服务。技术支持中心有完善的售后服务体系,包括电话支持、电子邮件、远程网络支持、现场响应、紧急恢复等。可快速响应各用户的服务请求，随时为客户提供优质的技术服务。

数据库日常运行维护方案

5.2 电话支持

当系统发生问题时，用户可以从客服专线得到及时有效的 7×24 小时电话支持。客户服务人员做好客户服务需求的记录，并向用户明确服务需求的解决方式、进程和最终的解决办法。提供远程服务器接入、邮件和电话服务支持。

5.3 现场服务

如果用户的问题不能通过电话解决，客户服务部会立刻派经验丰富的运维工程师到现场为用户解决问题，客户服务人员对解决的过程进行记录，并向用户提供解决问题的报告．包括问题原因、解决方法、解决问题的方式和进程，以及建议用户对系统进行正常使用的指导和培训．问题解决后需要用户进行确认。

5.4 紧急故障处理

当系统出现紧急情况时，无论是正常工作时间或非工作时间，我公司在确认后立即派运维工程师进行电话支持和远程支持，同时派运维工程师赴现场提供紧急技术支持。如数据库系统不能正常工作，发生严重影响正常业务办理的紧急故障，要求 10分钟内通过电话、远程控制工具远程响应，指导客户方工程师操作，在1

小时内提交解决方案，2 小时内派出技术专家到客户现场，并以最快的速度解决系统故障。

5.5 定期巡检服务

我公司根据招标文件要求将提供为期一年的数据库运维技术服务，每月2次对

xxx 的数据库以及要求的 MIS 数据库和门户平台进行健康检查并出具巡检报告，发现并预防可能产生的问题；巡检完成后，于次月的 5 日前提交上月度的巡检报告。

巡检内容包括：系统日志、网络状况、系统空间状况、存储设备状态、系统

性能、产品参数与配置、数据库各种文件的状态与配置、数据库安全审计、数据

对象配置的合理性、实例的运行效率、SQL 代码性能调优等。

数据库日常运行维护方案

6 培训方案

良好的培训是项目成功进行的必要条件。我公司建立了完善的培训制度，有专业的培训教师提供数据库日常使用管理和维护培训，针对特定开发完成的系统，我公司进行必要的现场培训和试运行帮助支持，保证系统的顺利实施。

如项目需要，用户方相关技术人员在项目开始时可与我公司的项目组同期进入，我公司负责培训用户方技术人员，并在项目实施的过程中进行“实战”培训，用户方相关技术人员也可以共同进行项目的实施，例如权限配置、数据库空间的管理、数据迁移工作等。

当系统建设完毕后，可以针对具体的应用给普通使用者提供日常操作的培训。

6.1 培训方式

我公司为客户提供现场培训和定制培训两种技术培训方式。用户可根据自身要求或项目需求选择任意一种培训方式。

1、现场培训

可以根据客户需求，对客户实施现场培训，培训时间、地点、课时、课程内容和目的、培训人数等由双方协商制定。

2、定制培训

提供定制培训服务，根据项目的需要及客户的要求，对客户培训产品和系统，包括第三方产品的培训。培训时间、地点、课时、课程内容和目的、培训人数等由双方协商制定。

6.2 培训教材

为了搞好培训工作，我公司将选派具有多年实施及开发经验的工程师承担培训工作。

培训教材将使用针对该项目的专用教材，教材内容丰富并通俗易懂，图文并茂，语言表述形式为中文，加深对教材各知识点的理解，教材可长期保存，并可作为技术资料随时查阅。

 培训教材

数据库日常运行维护方案

培训教材的准备是培训工作的前提，培训教材的好坏直接影响培训的质量。我公司将培训教材细化分为培训讲义、培训教程、系统操作手册和系统技术手册。对于每一种培训教材又根据不同的应用侧重点细分为软件系统安装维护、软件系统功能介绍。为操作人员准备上机操作的实例数据，供操作人员上机操作使用。

1、培训讲义

采用幻灯片(PPT)的模式制作，主要用于授课时的讲解，将从软件的原理介绍、安装维护和功能介绍三方面分别阐述授课内容。

2、培训教程

采用 Word 文档的模式制作，主要详细描述数据库的设计原则和基本设置。通过培训教程，系统操作人员可以掌握系统数据库的设计原则和基本设置，有效地指导系统操作人员使用系统。

3、数据库手册

采用 Word 文档的模式制作，主要针对各级系统管理员。数据库手册主要详细描述系统数据库的维护功能，以及后台数据库服务器和应用服务器的日常维护工作。通过数据库手册可以有效地指导各级系统管理员的日常维护工作。

6.3 培训计划

Oracle数据库产品的管理培训，包括：数据库体系结构、Oracle 门户集成产品知识、日常管理、备份与恢复、性能优化等。

6.4 培训分工

培训阶段的最后工作就是使用编制的培训教材根据培训计划执行培训，在培训的执行阶段，后勤支持工作是非常重要的，它们包括：

 培训场地

 培训教员

 培训教材的制作和打印

 其它支持项目（如投影仪、幻灯等）

数据库日常运行维护方案

这一阶段的最终提交文档是记录了培训工作开展情况和最终培训执行情况的《培训进展状态报告》。