`
itspace
  • 浏览: 978616 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

一次误操作引起的Oracle数据库大恢复

阅读更多

事情起由是在Oracle 10g手动建库脚本中看到dbms_backup_restore.zerodbid(0)过程,其中作用是修改数据库的dbid。于是想通过该存储直接在sqlplus中执行修改dbid。
修改之前记录其dbid
引用
SQL> select dbid from v$database;

      DBID
----------
1488207495


修改dbid

引用
SQL> exec dbms_backup_restore.zerodbid(0);

PL/SQL procedure successfully completed.



貌似执行成功了,但随后alert日志显示ckpt进程将数据实例终止
引用
Tue Mar  9 01:43:22 2010
CKPT: terminating instance due to error 1242
Instance terminated by CKPT, pid = 16653
Tue Mar  9 01:43:53 2010


再次启动数据库报错
引用
Tue Mar  9 01:56:09 2010
Errors in file /ora10g/app/admin/ldbra/udump/ldbra_ora_12275.trc:
ORA-01221: data file 1 is not the same file to a background process
ORA-1221 signalled during: ALTER DATABASE OPEN...


dump Oracle数据文件头
引用
SQL> ALTER SESSION SET EVENTS 'immediate trace name file_hdrs level 3';


通过跟踪文件可以看到dbid以被重置为0
引用
V10 STYLE FILE HEADER:
        Compatibility Vsn = 169870080=0xa200300
        Db ID=0=0x0, Db Name='LDBRA'
        Activation ID=0=0x0
        Control Seq=8122=0x1fba, File size=65280=0xff00
        File Number=1, Blksiz=8192, File Type=3 DATA


还有一种途径是通过bbed工具观察

引用
   struct kcvfhhdr, 76 bytes                @20     
      ub4 kccfhswv                          @20       0x00000000
      ub4 kccfhcvn                          @24       0x0a200300
      ub4 kccfhdbi                          @28       0x00000000


当然第一反应是重建控制文件,看看能不能恢复成功

引用
SQL> alter database backup controlfile to trace;

Database altered.

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "LDBRA" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/ora10g/app/oradata/ldbra/redo01.log'  SIZE 50M,
  GROUP 2 '/ora10g/app/oradata/ldbra/redo02.log'  SIZE 50M,
  GROUP 3 '/ora10g/app/oradata/ldbra/redo03.log'  SIZE 50M
-- STANDBY LOGFILE
DATAFILE
  '/ora10g/app/oradata/ldbra/system01.dbf',
  '/ora10g/app/oradata/ldbra/undotbs01.dbf',
  '/ora10g/app/oradata/ldbra/sysaux01.dbf',
  '/ora10g/app/oradata/ldbra/users01.dbf',
  '/ora10g/app/oradata/ldbra/example01.dbf',
  '/ora10g/app/product/10.2.0/db_1/dbs/company.dbf',
  '/ora10g/app/product/10.2.0/db_1/dbs/streams.dbf'
CHARACTER SET ZHS16GBK
;


郁闷的是重建控制文件不成功:

引用
CREATE CONTROLFILE REUSE DATABASE "LDBRA" RESETLOGS  NOARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01227: log  is inconsistent with other logs


想到还有另外一种语法重建控制文件(重建控制文件之前,备份controlfile和online redolog):
引用
Create controlfile reuse set database "LDBRA"
MAXINSTANCES 8
MAXLOGHISTORY 1
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
Datafile
'/ora10g/app/oradata/ldbra/system01.dbf',
'/ora10g/app/oradata/ldbra/undotbs01.dbf',
'/ora10g/app/oradata/ldbra/sysaux01.dbf',
'/ora10g/app/oradata/ldbra/users01.dbf',
'/ora10g/app/oradata/ldbra/example01.dbf',
'/ora10g/app/product/10.2.0/db_1/dbs/ company.dbf',
'/ora10g/app/product/10.2.0/db_1/dbs/streams.dbf'
LOGFILE GROUP 1 ('/ora10g/app/oradata/ldbra/redo01.log') SIZE 51200K,
GROUP 2 ('/ora10g/app/oradata/ldbra/redo02.log') SIZE 51200K,
GROUP 3 ('/ora10g/app/oradata/ldbra/redo03.log') SIZE 51200K RESETLOGS; 


似乎重建成功了!但是进行recover的时候报错了!
引用
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE;
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [kcvhvdf_1], [], [], [], [], [], [],
[]


可以看到控制文件在重建的过程中进行了dbid重置
引用
SQL> select dbid from v$database;

      DBID
----------
1498845164


问题到这里似乎失去了头绪,呵呵,拷回之前备份的控制文件替换刚建的控制文件。因为我采用的是resetlog选项创建控制文件,从理论上来讲,应该是会重置redolog的,即重新创建redolog。但是目前采用此选项确报ORA-01227错误。不可思议!后来一想可能是跟数据文件中的dbid为0有关。于是采用终极修复方法,bbed!首先将所有数据文件的dbid用bbed工具重置为1488207495,其次将fuzzy标记打为0x2000(因为数据库被ckpt进程异常终止,将标记打为0x2000表示数据库是shutdown immediate关闭),采用上述方法之后控制文件成功创建!
引用
SQL> STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "LDBRA" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
ORACLE instance started.

Total System Global Area 1073741824 bytes
Fixed Size                  1271616 bytes
Variable Size             461375680 bytes
Database Buffers          608174080 bytes
Redo Buffers                2920448 bytes
  GROUP 1 '/ora10g/app/oradata/ldbra/redo01.log'  SIZE 50M,
  GROUP 2 '/ora10g/app/oradata/ldbra/redo02.log'  SIZE 50M,
  GROUP 3 '/ora10g/app/oradata/ldbra/redo03.log'  SIZE 50M
-- STANDBY LOGFILE
DATAFILE
  '/ora10g/app/oradata/ldbra/system01.dbf',
  '/ora10g/app/oradata/ldbra/undotbs01.dbf',
  '/ora10g/app/oradata/ldbra/sysaux01.dbf',
  '/ora10g/app/oradata/ldbra/users01.dbf',
  '/ora10g/app/oradata/ldbra/example01.dbf',
  '/ora10g/app/product/10.2.0/db_1/dbs/company.dbf',
  '/ora10g/app/product/10.2.0/db_1/dbs/streams.dbf'
CHARACTER SET ZHS16GBK
21  ;

Control file created.


尝试打开数据库
SQL> alter database open RESETLOGS;
出现数据库挂起状态,后台alert日志显示[2662]错误,呵呵,看到这个错误,希望就来了!
引用
SMON: enabling cache recovery
Tue Mar  9 03:11:38 2010
Errors in file /ora10g/app/admin/ldbra/udump/ldbra_ora_13676.trc:
ORA-00600: internal error code, arguments: [2662], [2268], [3799096903], [2268], [3799098345], [8388617], [], []
Tue Mar  9 03:11:40 2010
Errors in file /ora10g/app/admin/ldbra/udump/ldbra_ora_13676.trc:
ORA-00600: internal error code, arguments: [2662], [2268], [3799096903], [2268], [3799098345], [8388617], [], []
Tue Mar  9 03:11:40 2010


由于shutdown abort实例不起作用,就采用杀Oracle进程,删除共享内存段的做法,将挂起的数据库实力强制abort:
1、杀Oracle核心进程
引用
[ora10g@test bdump]$ ps -ef|grep ora_
ora10g   14431     1  0 Feb21 ?        00:01:32 ora_pmon_streams
ora10g   14433     1  0 Feb21 ?        00:00:46 ora_psp0_streams
ora10g   14435     1  0 Feb21 ?        00:00:47 ora_mman_streams
ora10g   14437     1  0 Feb21 ?        00:06:57 ora_dbw0_streams
ora10g   14439     1  0 Feb21 ?        00:06:24 ora_lgwr_streams
ora10g   14441     1  0 Feb21 ?        00:46:13 ora_ckpt_streams
ora10g   14443     1  0 Feb21 ?        00:01:02 ora_smon_streams
ora10g   14445     1  0 Feb21 ?        00:00:00 ora_reco_streams
ora10g   14447     1  0 Feb21 ?        00:05:53 ora_cjq0_streams
ora10g   14449     1  0 Feb21 ?        00:03:15 ora_mmon_streams
ora10g   14451     1  0 Feb21 ?        00:02:47 ora_mmnl_streams
ora10g   14453     1  0 Feb21 ?        00:00:01 ora_d000_streams
ora10g   14455     1  0 Feb21 ?        00:00:03 ora_s000_streams
ora10g   14460     1  0 Feb21 ?        00:00:05 ora_qmnc_streams
ora10g   14468     1  0 Feb21 ?        00:00:08 ora_q000_streams
ora10g   14470     1  0 Feb21 ?        00:00:02 ora_q001_streams
ora10g   13622     1  0 03:08 ?        00:00:00 ora_j000_streams
ora10g   13710 12028  0 03:13 pts/5    00:00:00 grep ora_
[ora10g@test bdump]$ kill -9 14431 14433 14435 14437 14439 14441 14443 14445 14447 14449 14451 14453 14455 14460 14468 14470 13622


2、删除Oracle 共享内存段
引用
[ora10g@test bdump]$ ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status     
0xcc481b8c 1441796    ora10g    640        599785472  0                      
0x40b3b558 2818054    ora10g    640        1077936128 0                      

------ Semaphore Arrays --------
key        semid      owner      perms      nsems    
0x0d908ec4 360448     ora10g    640        154      

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

[root@test ~]# ipcrm -m 1441796
[root@test ~]# ipcrm -s 360448


再次尝试将实例打开,这里用到了10015事件。
引用
SQL> alter session set events '10015 trace name adjust_scn level 1';

Session altered.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/ora10g/app/oradata/ldbra/system01.dbf'


SQL> recover database;
Media recovery complete.
SQL> alter database open;

Database altered.


后续工作就是将tempfile添加到temp表空间中,终于恢复成功。
引用
SQL> alter tablespace temp add tempfile '/ora10g/app/oradata/ldbra/temp01.dbf' size 50m reuse;

Tablespace altered.
1
0
分享到:
评论

相关推荐

    oracle数据库故障紧急处理预案.pdf

    这些故障可能是由于硬件故障造成的,也可能是人为误操作而引起。所以我们首先要判断问题的起因,如果是硬件故障则首先要解决硬件问题。在无硬件问题的前提下我们才能按照下面的处理方发来进一步处理。 一、控制文件...

    Oracle数据库备份与恢复技术探索.pdf

    用户误操作,如误删数据表或执行错误的DML(数据操纵语言)操作,同样可能导致数据库故障。后台进程的异常,如电源故障、服务器关闭或重启、硬件损坏等,也可能导致数据库无法正常工作。最后,物理媒介的损坏,如...

    浅谈Oracle数据库备份与恢复策略.pdf

    向前滚动方案则通过重做记录文件功能将数据库恢复到正常状态,虽然开销较大,但恢复程度更为完备。 物理备份也是Oracle数据库备份中的一种重要方式,包括冷备份和热备份。冷备份是在数据库关闭状态下进行的备份,而...

    Oracle数据库系统紧急故障处理方法.txt

    另一种是由于人为误操作所导致的。因此,在进行故障处理之前,首先需要判断故障的具体起因。如果是硬件故障,则需要优先解决硬件问题。只有在确认没有硬件故障的情况下,才能进一步采取措施进行数据库故障的修复。 ...

    Oracle数据库管理操作及数据库应用程序开发总结.doc

    1. **数据库故障概述**:数据库故障可能由硬件问题、软件错误、人为误操作等原因引起,理解这些故障类型有助于制定有效的备份和恢复策略。 2. **数据库备份类型**:主要包括完整备份、增量备份和差异备份,每种类型...

    Oracle第11章数据库备份与恢复.pptx

    综上所述,Oracle数据库备份与恢复是一个复杂而关键的过程,需要DBA深入理解和熟练掌握,以便在面对各种故障时,能迅速、准确地恢复数据,保证业务的正常运行。同时,随着技术的发展,如RMAN(Recovery Manager)等...

    oracle数据库故障紧急处理预案.doc

    Oracle 数据库故障可能是由于硬件故障或人为误操作引起的,因此在处理故障时首先需要判断问题的起因,如果是硬件故障则首先要解决硬件问题。 一、控制文件损坏 控制文件记录了关于 Oracle 的重要配置信息,如...

    Oracle9i数据库的备份与恢复.pptx

    在这种模式下,Oracle9i能够自动恢复数据库,但无法抵御介质故障,例如硬件损坏或用户误操作导致的数据丢失。 归档模式,也称为介质可恢复模式,允许数据库进行在线日志的归档。这意味着即使发生介质故障,也能通过...

    利用oracle 闪回技术恢复数据

    Oracle 闪回技术是Oracle数据库提供的一种强大工具,主要用于数据恢复和事务跟踪。它允许数据库管理员和用户在数据库层面恢复到过去的某个时间点,从而能够有效地处理意外的数据删除、更新错误或其他类似的事故。这...

    Oracle9i 数据库技术9

    【Oracle9i 数据库技术9】这一章主要讨论了数据库的备份与恢复策略,这是确保数据安全和系统连续性的重要方面。备份与恢复涉及到多种类型的故障及其对应的处理方法,以及不同类型的备份方式。 首先,备份的基本概念...

    ORACLE备份与恢复(STUDENT)[归类].pdf

    首先,Oracle数据库可能遭遇的失败类型包括用户误操作和例程失败。用户误操作可能导致数据丢失,而例程失败通常由于硬件故障(如CPU或内存问题)、后台进程异常等原因引起。对于例程失败,简单的`startup`命令通常...

    Oracle 11g数据恢复向导恢复数据文件

    数据文件是组成Oracle数据库物理结构的重要组成部分之一,用于存储数据库的数据。由于硬件故障、人为误操作或其他原因导致的数据文件丢失或损坏,可能会影响到数据库的正常运行。因此,了解如何有效地恢复这些数据...

    oracle 恢复表数据

    在Oracle数据库环境中,数据丢失可能由多种原因引起,如误操作、系统故障、硬件损坏等。为了最大限度地减少这些意外事件的影响,Oracle提供了丰富的工具和技术来帮助恢复数据。具体到“恢复刚删除的数据”这一场景,...

    Oracle_备份与恢复.

    - **用户错误、冲突或磁盘失效**:人为误操作、并发控制问题或存储介质故障导致。 - **SQL语句失败**:语法错误或逻辑错误造成。 - **网络故障**:网络连接中断或延迟影响数据传输。 - **场地灾难**:自然灾害或灾难...

    Oracle 11g 备份与恢复最佳手册

    - **不完全恢复**: 使用完整备份和日志将数据库恢复到过去的某个时间点(或SCN),可能会导致数据丢失。 #### 五、归档与非归档模式 - **归档模式**: Redo Log 写入归档日志。 - **非归档模式**: 没有归档日志,...

    Oracle数据自动备份与恢复.pdf

    备份主要是为了防止数据丢失,这可能由于硬件故障、软件错误、人为误操作或恶意攻击等原因引起。Oracle提供了多种备份类型,包括物理备份(如操作系统备份、RMAN备份)和逻辑备份(如SQL*Plus的EXPDP/IMPDP命令)。...

    数据库备份两例故障的恢复与解决方法

    通过LogMiner工具进行日志分析后,发现是因为一次误操作,将某类费用统一设置为39元。由于该操作发生在两天前,而医院的备份策略只保留一天的数据,因此无法通过简单的备份恢复解决问题。 **解决步骤:** 1. **查找...

    《Oracle内核技术揭秘》PDF版本下载.txt

    Oracle数据库是由美国甲骨文公司开发的一款关系型数据库管理系统(RDBMS),自1979年发布以来,Oracle数据库一直以其高效稳定的表现成为全球最广泛使用的数据库之一。它支持多种操作系统平台,如Windows、Linux、Unix...

    oracle紧急故障处理方法

    首先,物理结构故障通常是由于硬件问题或人为误操作引起的。硬件故障应优先解决,例如检查硬盘、内存等是否正常工作。如果确定问题不在于硬件,那么可以针对具体损坏的文件进行修复。 控制文件是Oracle数据库的关键...

    oci数据库客户端缺失文件

    OCI是Oracle公司提供的一种编程接口,允许开发者用C、C++等语言与Oracle数据库进行交互,执行SQL语句,处理结果集,管理事务等操作。在描述中提到的“oci数据库客户端缺失文件”问题,通常意味着在尝试连接到Oracle...

Global site tag (gtag.js) - Google Analytics