系统紧急故障处理方法
来源:互联网 发布:域名映射 编辑:程序博客网 时间:2024/04/30 13:13
<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 728x15, 创建于 08-4-23MSDN */google_ad_slot = "3624277373";google_ad_width = 728;google_ad_height = 15;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>
控制文件损坏:
控制文件记录了关于oracle的重要配置信息,如数据库名、字符集名字、各个数据文件、日志文件的位置等等信息。控制文件的损坏,会导致数据库异常关闭。一旦缺少控制文件,数据库也无法启动,这是一种比较严重的错误。
损坏单个控制文件:
1.确保数据库已经关闭,如果没有用下面的命令来关闭数据库:
svrmgrl>shutdownimmediate;
2.查看初始化文件$ORACLE_BASE/admin/pfile/initORCL.ora,确定所有控制文件的路径。
3.用命令将其它正确的控制文件覆盖错误的控制文件。
4.用下面的命令重新启动数据库:
svrmgrl>startup;
5.用适当的方法进行数据库全备份。
损坏所有的控制文件:
1.确保数据库已经关闭,如果没有用下面的命令来关闭数据库:
svrmgrl>shutdownimmediate;
2.从相应的备份结果集中恢复最近的控制文件。对于没有采用带库备份的点可以直接从磁带上将最近的控制文件备份恢复到相应目录;对于采用带库备份的点用相应的rman脚本来恢复最近的控制文件。
3.用下面的命令来创建产生数据库控制文件的脚本:
svrmgrl>startupmount;
svrmgrl>alterdatabasebackupcontrolfiletotracenoresetlogs;
4.修改第三步产生的trace文件,将其中关于创建控制文件的一部分语句拷贝出来并做些修改,使得它能够体现最新的数据库结构。假设产生的sql文件名字为createcontrol.sql.
注意:
Trace文件的具体路径可以在执行完第3)步操作后查看$ORACLE_BASE/admin/bdump/alert_ORCL.ora文件来确定。
5.用下面命令重新创建控制文件:
svrmgrl>shutdownabort;
svrmgrl>startupnomount;
svrmgrl>@createcontrol.sql;
6.用适当的方法进行数据库全备份。
重做日志文件损坏:
数据库的所有增、删、改都会记录入重做日志。如果当前激活的重做日志文件损坏,会导致数据库异常关闭。非激活的重做日志最终也会因为日志切换变为激活的重做日志,所以损坏的非激活的重做日志最终也会导致数据库的异常终止。在ipas/mSwitch中每组重做日志只有一个成员,所以在下面的分析中只考虑重做日志组损坏的情况,而不考虑单个重做日志成员损坏的情况。
确定损坏的重做日志的位置及其状态:
1.如果数据库处于可用状态:
select*fromv$logfile;
svrmgrl>select*fromv$log;
2.如果数据库处于已经异常终止:
svrmlgr>startupmount;
svrmgrl>select*fromv$logfile;
svrmgrl>select*fromv$log;
其中,logfile的状态为INVALID表示这组日志文件出现已经损坏;log状态为Inactive:表示重做日志文件处于非激活状态;Active:表示重做日志文件处于激活状态;Current:表示是重做日志为当前正在使用的日志文件。
损坏的日志文件处于非激活状态:
1.删除相应的日志组:
svrmgrl>alterdatabasedroplogfilegroupgroup_number;
2.重新创建相应的日志组:
svrmgrl>alterdatabaseaddlogfilegroupgroup_number(’log_file_descritpion’,…)sizelog_file_size;
损坏的日志文件处于激活状态且为非当前日志:
1.清除相应的日志组:
svrmgrl>alterdatabaseclearunarchivedlogfilegroupgroup_number;
损坏的日志文件为当前活动日志文件:
用命令清除相应的日志组:
svrmgrl>alterdatabaseclearunarchivedlogfilegroupgroup_number;
如果清除失败,则只能做基于时间点的不完全恢复。
打开数据库并且用适当的方法进行数据库全备份:
svrmgrl>alterdatabaseopen;1<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 728x15, 创建于 08-4-23MSDN */google_ad_slot = "3624277373";google_ad_width = 728;google_ad_height = 15;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>
<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 160x600, 创建于 08-4-23MSDN */google_ad_slot = "4367022601";google_ad_width = 160;google_ad_height = 600;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>
Oracle物理结构故障是指构成数据库的各个物理文件损坏而导致的各种数据库故障。这些故障可能是由于故障造成的,也可能是人为误操作而引起。所以我们首先要判断问题的起因,如果是硬件故障则首先要解决硬件问题。在无硬件问题的前提下我们才能按照下面的处理方发来进一步处理。控制文件损坏:
控制文件记录了关于oracle的重要配置信息,如数据库名、字符集名字、各个数据文件、日志文件的位置等等信息。控制文件的损坏,会导致数据库异常关闭。一旦缺少控制文件,数据库也无法启动,这是一种比较严重的错误。
损坏单个控制文件:
1.确保数据库已经关闭,如果没有用下面的命令来关闭数据库:
svrmgrl>shutdownimmediate;
2.查看初始化文件$ORACLE_BASE/admin/pfile/initORCL.ora,确定所有控制文件的路径。
3.用命令将其它正确的控制文件覆盖错误的控制文件。
4.用下面的命令重新启动数据库:
svrmgrl>startup;
5.用适当的方法进行数据库全备份。
损坏所有的控制文件:
1.确保数据库已经关闭,如果没有用下面的命令来关闭数据库:
svrmgrl>shutdownimmediate;
2.从相应的备份结果集中恢复最近的控制文件。对于没有采用带库备份的点可以直接从磁带上将最近的控制文件备份恢复到相应目录;对于采用带库备份的点用相应的rman脚本来恢复最近的控制文件。
3.用下面的命令来创建产生数据库控制文件的脚本:
svrmgrl>startupmount;
svrmgrl>alterdatabasebackupcontrolfiletotracenoresetlogs;
4.修改第三步产生的trace文件,将其中关于创建控制文件的一部分语句拷贝出来并做些修改,使得它能够体现最新的数据库结构。假设产生的sql文件名字为createcontrol.sql.
注意:
Trace文件的具体路径可以在执行完第3)步操作后查看$ORACLE_BASE/admin/bdump/alert_ORCL.ora文件来确定。
5.用下面命令重新创建控制文件:
svrmgrl>shutdownabort;
svrmgrl>startupnomount;
svrmgrl>@createcontrol.sql;
6.用适当的方法进行数据库全备份。
重做日志文件损坏:
数据库的所有增、删、改都会记录入重做日志。如果当前激活的重做日志文件损坏,会导致数据库异常关闭。非激活的重做日志最终也会因为日志切换变为激活的重做日志,所以损坏的非激活的重做日志最终也会导致数据库的异常终止。在ipas/mSwitch中每组重做日志只有一个成员,所以在下面的分析中只考虑重做日志组损坏的情况,而不考虑单个重做日志成员损坏的情况。
确定损坏的重做日志的位置及其状态:
1.如果数据库处于可用状态:
select*fromv$logfile;
svrmgrl>select*fromv$log;
2.如果数据库处于已经异常终止:
svrmlgr>startupmount;
svrmgrl>select*fromv$logfile;
svrmgrl>select*fromv$log;
其中,logfile的状态为INVALID表示这组日志文件出现已经损坏;log状态为Inactive:表示重做日志文件处于非激活状态;Active:表示重做日志文件处于激活状态;Current:表示是重做日志为当前正在使用的日志文件。
损坏的日志文件处于非激活状态:
1.删除相应的日志组:
svrmgrl>alterdatabasedroplogfilegroupgroup_number;
2.重新创建相应的日志组:
svrmgrl>alterdatabaseaddlogfilegroupgroup_number(’log_file_descritpion’,…)sizelog_file_size;
损坏的日志文件处于激活状态且为非当前日志:
1.清除相应的日志组:
svrmgrl>alterdatabaseclearunarchivedlogfilegroupgroup_number;
损坏的日志文件为当前活动日志文件:
用命令清除相应的日志组:
svrmgrl>alterdatabaseclearunarchivedlogfilegroupgroup_number;
如果清除失败,则只能做基于时间点的不完全恢复。
打开数据库并且用适当的方法进行数据库全备份:
svrmgrl>alterdatabaseopen;1
<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 160x600, 创建于 08-4-23MSDN */google_ad_slot = "4367022601";google_ad_width = 160;google_ad_height = 600;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>
- 系统紧急故障处理方法
- oracle系统紧急故障处理方法
- oracle系统紧急故障处理方法
- oracle系统紧急故障处理方法
- Oracle数据库系统紧急故障处理方法
- oracle系统紧急故障处理方法
- 据库系统紧急故障处理方法 (…
- Oracle系统紧急故障处理(数据文件、日志文件以及表空间损坏的处理)
- Oracle - Oracle系统紧急故障处理(数据文件、日志文件以及表空间损坏的处理)
- Oracle系统紧急故障处理(数据文件、日志文件以及表空间损坏的处理)
- Oracle系统紧急故障处理(数据文件、日志文件以及表空间损坏的处理)
- Linux系统紧急救护处理
- 内存不足的紧急处理方法
- 由于开启审计导致故障的紧急处理
- 浅谈linux系统下常见的故障与处理方法
- 瑞博PM9000GTA 系统漏气故障分析与处理方法
- 故障处理方法
- USBC 故障处理方法
- 将文本文件导入Sqlserver
- 精通Flex 3.0――14.1.3 LCDS的内容结构
- 改程序是如此痛苦,备份软件,写好修改文档时如此重要
- 我自己设计的中文分词算法
- 通用8086软中断接口
- 系统紧急故障处理方法
- 常见sql高级运用
- :一条SQL实现将多行数据并为一行显示
- 发布我的中文分词程序源代码--DartSplitter
- 精通Flex 3.0――14.2 一个最基本的LCDS应用
- 问题“未于信任SQLServer连接相关联”的解决
- 死锁导致站点访问不了之解决方案
- 精通Flex 3.0――14.3 通过Remoting访问服务端的应用
- 精通Flex 3.0――14.3.1 Remoting服务介绍