核心库

3次/天

3次/天

5次/天

1次/1月

16点/天

务工易

3次/天

3次/天

5次/天

1次/1月

16点/天

中央信息

3次/天

3次/天

5次/天

1次/1月

16点/天

IVR座席

3次/天

3次/天

5次/天

1次/1月

16点/天

二线客服

3次/天

3次/天

5次/天

1次/1月

16点/天

经分

3次/天

3次/天

5次/天

1次/1月

16点/天

百事易

3次/天

3次/天

5次/天

1次/1月

16点/天

病虫害

3次/天

3次/天

5次/天

1次/1月

16点/天

核心库

alert_db.log

messages

listener.log

df -h

16点/天

务工易

alert_db.log

messages

listener.log

df -h

16点/天

中央信息

alert_db.log

messages

listener.log

df -h

16点/天

IVR座席

alert_db.log

messages

listener.log

df -h

16点/天

二线客服

alert_db.log

messages

listener.log

df -h

16点/天

经分

alert_db.log

messages

listener.log

df -h

16点/天

百事易

alert_db.log

messages

listener.log

df -h

16点/天

病虫害

alert_db.log

messages

listener.log

df -h

16点/天

核心库

脚本

awr报告

脚本

脚本

脚本

务工易

脚本

awr报告

脚本

脚本

脚本

中央信息

脚本

awr报告

脚本

脚本

脚本

IVR座席

脚本

awr报告

脚本

脚本

脚本

二线客服

脚本

awr报告

脚本

脚本

脚本

经分

脚本

awr报告

脚本

脚本

脚本

百事易

脚本

awr报告

脚本

脚本

脚本

病虫害

脚本

awr报告

脚本

脚本

脚本

维护记录

频率

维护内容

备注

月度

1. 业务过期数据下线清理，回收空间

2. 数据库文件系统使用率检查

3. 检查表空间碎片，并做相应的处理

季度

1. 数据库备份恢复测试，验证介质可用性

2. 数据库相关日志，备份清理

3. 对现网数据库无效对象确认及清理

半年

1、数据库安全补丁升级

2、对数据库运行参数值检查，性能评估、调整

一年

1、对数据库做一次全面健康检查工作

2、根据本年度运行维护总结，提出下一年相关资源需求计划

维护记录

事件

处理过程

备注

参数不对

检查初始化参数文件是否正常

控制文件损坏

1.确保数据库已经关闭，如果没有用下面的命令来关闭数据库：

racdbl>shutdown immediate;

2.查看初始化文件$ORACLE_BASE/admin/pfile/initORCL.ora,确定所有控制文件的路径。

3.用操作系统命令将其它正确的控制文件覆盖错误的控制文件。

4.用下面的命令重新启动数据库：

racdbl >startup;

5.用适当的方法进行数据库全备份。

损坏所有的控制文件：

1.确保数据库已经关闭，如果没有用下面的命令来关闭数据库：

racdbl >shutdown immediate;

2.从相应的备份结果集中恢复最近的控制文件。对于没有采用带库备份的点可以直接从磁带上将最近的控制文件备份恢复到相应目录；对于采用带库备份的点用相应的rman脚本来恢复最近的控制文件。

3.用下面的命令来创建产生数据库控制文件的脚本：

racdbl >startup mount;

racdbl >alter database backup controlfile to trace noresetlogs;

4.修改第三步产生的trace文件，将其中关于创建控制文件的一部分语句拷贝出来并做些修改，使得它能够体现最新的数据库结构。假设产生的sql文件名字为createcontrol.sql.

注意：

Trace文件的具体路径可以在执行完第3步操作后查$ORACLE_

BASE/admin/bdump/alert_ORCL.ora文件来确定。

5.用下面命令重新创建控制文件：

racdbl >shutdown abort;

racdbl >startup nomount;

racdbl >@createcontrol.sql;

6.用适当的方法进行数据库全备份。

重做日志文件损坏：

数据库的所有增、删、改都会记录入重做日志。如果当前激活的重做日志文件损坏，会导致数据库异常关闭。非激活的重做日志最终也会因为日志切换变为激活的重做日志，所以损坏的非激活的重做日志最终也会导致数据库的异常终止。在ipas/mSwitch中每组重做日志只有一个成员，所以在下面的分析中只考虑重做日志组损坏的情况，而不考虑单个重做日志成员损坏的情况。

确定损坏的重做日志的位置及其状态：

1.如果数据库处于可用状态：

select * from v$logfile;

racdbl >select * from v$log;

2.如果数据库处于已经异常终止：

racdbl >startup mount;

racdbl >select * from v$logfile;

svrmgrl>select * from v$log;

其中，logfile的状态为INVALID表示这组日志文件出现已经损坏；log状态为Inactive：表示重做日志文件处于非激活状态；Active： 表示重做日志文件处于激活状态；Current：表示是重做日志为当前正在使用的日志文件。

损坏的日志文件处于非激活状态：

1.删除相应的日志组：

racdbl >alter database drop logfile group group_number;

2.重新创建相应的日志组：

racdbl >alter database add log file group group_number （’log_file_descritpion’，…） size log_file_size;

损坏的日志文件处于激活状态且为非当前日志：

1.清除相应的日志组：

racdbl>alter database clear unarchived logfile group group_number;

损坏的日志文件为当前活动日志文件：

用命令清除相应的日志组：

racdbl>alter database clear unarchived logfile group group_number;

如果清除失败，则只能做基于时间点的不完全恢复。

打开数据库并且用适当的方法进行数据库全备份：

racdbl >alter database open;

部分数据文件损坏：

若损坏的数据文件属于非system表空间，则数据库仍然可以处于打开状态可以进行操作，只是损坏的数据文件不能访问。这时在数据库打开状态下可以单独对损坏的数据文件进行恢复。若是system表空间的数据文件损坏则数据库系统会异常终止。这时数据库只能以Mount方式打开，然后再对数据文件进行恢复。可以通过查看数据库日志文件来判断当前损坏的数据文件到底是否属于system表空间。