【数据恢复】解决ORA-600[4xxx]错误并打开数据库

简介:

Recovering a Dropped Table from a Full Database Backup using manual backup and recovery procedures (Doc ID 96197.1) You cannot follow the note exactly as this note is for a valid full backup where you have all logs needed for point in time recovery - the changes you need to make are in the summary steps above. Once you have done the recovery we can attempt a force open (you will have to do the restore/recovery again for sys, sysaux and undo because you have done an open resetlogs on the restored database): YOU ARE ADVISED TO TAKE A FULL COLD OS BACKUP OF THE DATABASE BEFORE PROCEEDING WITH THE FORCE OPEN. To force open a database: 1. if you are using AUM you need to identify ALL rollback segments listed in your dictionary (system dbfs): On unix, you can use the unix strings command to extract the rollback segments: $ strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u > listSMU where system01.dbf is the name of the datafile for the SYSTEM tablespace - if you have > 1 system dbf then you need to do this for each file, writing to a different listSMUn file each time. 2. Mount the database and create a pfile (if you dont already have one) SQL>create pfile='init<sid>.ora' from spfile; Edit the pfile - add : _allow_resetlogs_corruption=true undo_management=MANUAL _corrupted_rollback_segments=<list> Where <list> is the list of rollback segment names extracted as above with '$' appended to each name eg _corrupted_rollback_segments=(_SYSSMU1$, _SYSSMU2$........._SYSSMU10$) 3. Remount the instance using the amended pfile and then do the following: SQL>recover database using backup controlfile until cancel; SQL>cancel SQL>alter database open resetlogs; If this works then you can EXPORT the database contents - the database will have to be completely rebuilt and the data re-imported. IF this fails then I need to see the failure (ORA-1555, ORA-600[2662], ORA-600[4194], Ora-600[4000] are common errors raised during force open), along with the alert log extract showing the start up after setting these hidden parameters. Please remember to REMOVE the hidden parameters after you have exported – the should never be used without advice from Oracle Support.



本文转自maclean_007 51CTO博客,原文链接:http://blog.51cto.com/maclean/1278292

相关文章
|
5月前
|
SQL 弹性计算 关系型数据库
服务器数据恢复-华为ECS云服务器mysql数据库数据恢复案例
云服务器数据恢复环境: 华为ECS云服务器,linux操作系统,mysql数据库(innodb引擎)。作为网站服务器使用。 云服务器故障: 在执行mysql数据库版本更新测试时,误将本应该在测试库上执行的sql脚本执行在生产库上了,生产库上的部分表被truncate,部分表内有少量数据被delete。 需要恢复被truncate的表以及被少量数据被delete的表。
服务器数据恢复-华为ECS云服务器mysql数据库数据恢复案例
|
3天前
|
SQL 存储 小程序
数据库数据恢复—Sql Server数据库文件丢失的数据恢复案例
数据库数据恢复环境: 5块硬盘组建一组RAID5阵列,划分LUN供windows系统服务器使用。windows系统服务器内运行了Sql Server数据库,存储空间在操作系统层面划分了三个逻辑分区。 数据库故障: 数据库文件丢失,主要涉及3个数据库,数千张表。数据库文件丢失原因未知,不能确定丢失的数据库文件的存放位置。数据库文件丢失后,服务器仍处于开机状态,所幸未写入大量数据。
数据库数据恢复—Sql Server数据库文件丢失的数据恢复案例
|
4天前
|
SQL 存储 数据挖掘
数据库数据恢复—数据库ndf文件大小变为0KB的数据恢复案例
存储设备损坏导致存储中SQL Server数据库崩溃。对数据库文件进行恢复后,用户发现有4个ndf文件的大小变为0KB。该SQL Server数据库每10天生成一个大小相同的NDF文件,该SQL Server数据库包含两个LDF文件。
|
17天前
|
NoSQL MongoDB 数据库
MongoDB数据恢复—MongoDB数据库文件被破坏的数据恢复案例
服务器数据恢复环境: 一台Windows Server操作系统服务器,服务器上部署MongoDB数据库。 MongoDB数据库故障&检测: 工作人员在未关闭MongoDB数据库服务的情况下,将数据库文件拷贝到其他分区。拷贝完成后将原MongoDB数据库所在分区进行了格式化操作,然后将数据库文件拷回原分区,重新启动MongoDB服务,服务无法启动。
|
29天前
|
SQL 存储 数据挖掘
数据库数据恢复—RAID5上层Sql Server数据库数据恢复案例
服务器数据恢复环境: 一台安装windows server操作系统的服务器。一组由8块硬盘组建的RAID5,划分LUN供这台服务器使用。 在windows服务器内装有SqlServer数据库。存储空间LUN划分了两个逻辑分区。 服务器故障&初检: 由于未知原因,Sql Server数据库文件丢失,丢失数据涉及到3个库,表的数量有3000左右。数据库文件丢失原因还没有查清楚,也不能确定数据存储位置。 数据库文件丢失后服务器仍处于开机状态,所幸没有大量数据写入。 将raid5中所有磁盘编号后取出,经过硬件工程师检测,没有发现明显的硬件故障。以只读方式将所有磁盘进行扇区级的全盘镜像,镜像完成后将所
数据库数据恢复—RAID5上层Sql Server数据库数据恢复案例
|
2月前
|
关系型数据库 MySQL Shell
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)(二)
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)
23 0
|
2月前
|
SQL 关系型数据库 MySQL
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)(一)
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)
33 0
|
2月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库误truncate table的数据恢复案例
北京某国企客户Oracle 11g R2数据库误truncate table CM_CHECK_ITEM_HIS,表数据丢失,业务查询到该表时报错,数据库的备份不可用,无法查询表数据。 Oracle数据库执行Truncate命令的原理:在执行Truncate命令后ORACLE会在数据字典和Segment Header中更新表的Data Object ID,但不会修改实际数据部分的块。由于数据字典与段头的DATA_OBJECT_ID与后续的数据块中的并不一致,所以ORACLE服务进程在读取全表数据时不会读取到已经被TRUNCATE的记录,但是实际数据未被覆盖。
Oracle数据恢复—Oracle数据库误truncate table的数据恢复案例
|
3月前
|
存储 Oracle 关系型数据库
【数据库数据恢复】Oracle数据库ASM磁盘组掉线的数据恢复案例
oracle数据库ASM磁盘组掉线,ASM实例不能挂载。数据库管理员尝试修复数据库,但是没有成功。
【数据库数据恢复】Oracle数据库ASM磁盘组掉线的数据恢复案例
|
5月前
|
运维 Oracle 关系型数据库
服务器数据恢复-raid5故障导致上层oracle数据库故障的数据恢复案例
服务器数据恢复环境: 一台服务器中有一组由24块FC硬盘组建的raid5磁盘阵列,linux操作系统+ext3文件系统,服务器上层部署有oracle数据库。 服务器故障&检测: raid5阵列中有两块硬盘出现故障掉线,导致服务器上层卷无法挂载,oracle数据库无法正常使用。 通过管理后台查看服务器中硬盘的状态,显示有两块硬盘处于离线状态。