Oracle 恢复TRUNCATE 的表的方法

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com

 

将表 TRUNCATE 时,不进行回滚就不能以一般性的方法来恢复数据。

用不完整media recovery恢复数据库整体

或者使用表区域的 Point-in-Time 恢复也可以进行恢复,这次的文章可以以下顺序恢复TRUNCATE 的表。

・使用数据库备份制成虚拟数据库

・到TRUNCATE之前为止,将虚拟数据库,进行不完全media恢复

・通过虚拟数据库输出对应表来获得

・利用已获得的输出转储,对原来的数据进行输入

[支持版本]

Oracle 9.2.0.X 为止

Oracle10.1.0 以后请参考 Document 1733030.1(KROWN:105956)

[支持平台]

所有平台

[详细]

0.前提

这个文章有以下前提。

・将数据库日志模式,以ARCHIVELOG模式来使用。

用以下命令可以查看数据库日志模式。

    SQL> archive log list

    数据库日志模式   归档模式

   

・正确地获得数据块备份。

  在线备份或者冷备份都可以。

・虚拟数据库,是用于原来的数据库相同的版本以及平台在同样版本的平台中使用同样oracle的版本。

  (即使是同一个服务器也没关系。用其他服务器传送文件,使用FTP时,请一定要使用binary模式。)

1.原数据库的准备

顺序1-1.确认执行TRUNCATE的日期

  TRUNCATE舍弃对象时,将当时的日期时间记录到目录视图的DBA_OBJECTS LAST_DDL_TIME中。因此,通过执行以下SQL语句,就可以获得执行TRUNCATE的日期时间。

    SQL> alter session set nls_date_format = ‘YYYY-MM-DD HH24:MI:SS’;

    SQL> col owner for a10

    SQL> col object_name for a20

    SQL> select owner,object_name,object_type,last_ddl_time from dba_objects

      2    where owner = ‘SCOTT’ and object_name = ‘EMP’;

    OWNER      OBJECT_NAME          OBJECT_TYPE        LAST_DDL_TIME

    ———- ——————– —————— ——————-

    SCOTT      EMP                  TABLE              2004-04-01 16:07:43

    TRUNCATE后,执行其他DDL时,LAST_DDL_TIME就成为最后执行DDL的时间。这时可以使用这个大概的时间,但如果是oracle9i以后的版本的话,

Document 1723311.1(KROWN:68872)的顺序来使用 LogMiner ,指定TRUNCATE的时间。

顺序1-2.将控制文件的 CREATE语句输入到追踪文件中

  以下的ALTER文中,将控制文件的 CREATE语句输出到追踪文件中。

    SQL> alter database backup controlfile to trace;

包含 CREATE CONTROLFILE 语句的追踪文件,是在用初始化参数 USER_DUMP_DEST指定的目录中制成。

顺序1-3.归档日历的online REDO日志。

  用原数据库将包含日历的online REDO日志归档。

    SQL> alter system archive log current;

2.表的修复工作

利用原数据文件的备份以及归档REDO日志文件,构筑虚拟数据库。

虚拟数据库的SID与数据库名如下所示。

    SID            : dummy

    数据库名 : dummy

顺序2-1.准备必要的文件

  制成用于操作的目录,今后的操作所需要的文件,将在以下目录中准备好。在此,假设是‘/tmp/dummy’

  (1) 初始化参数文件

      以原数据文件中所使用的初始化参数为基础。

      需要最低限度的参数,在此假设文件名为initdummy.ora

        compatible=9.2.0                          /* 与原数据库相同 */

        control_files=’/tmp/dummy/control01.ctl’  /* 指定用于操作的目录   */

        db_block_size=8192                        /* 与原数据库一致 */

        db_name=’dummy’                           /* 设定用于工作的数据库 */

        undo_management=’AUTO’                    /*与原数据库一致*/

        undo_tablespace=’UNDOTBS1′                /*与原数据库一致*/

        log_archive_format = arch%t_%s.arc        /*与原数据库一致*/

        log_archive_dest = /tmp/dummy             /* 指定用于操作的目录   */

      使用回滚段时,设定rollback_segments ,不设定undo_managementundo_tablespace

  (2) 数据库的备份

      需要构成以下表区域的表文件的备份。

      需要使用在执行TRUNCATE之前获得的备份。

      ・系统表区域

      UNDO表領域(或者构成回滚段的表区域)

      ・包含已TRUNCATE的对象表区域

  (3) 归档REDO日志文件

      从获得上述(2)中使用的备份的时间的归档REDO日志文件中,

      需要包含上述顺序1-3中归档的所有项目的归档REDO日志文件。

顺序2-2.设定环境变量

  環境変数 ORACLE_SID をダミーのデータベースに合わせます。

    cshの場合:

      setenv ORACLE_SID dummy

    sh,kshの場合:

      ORACLE_SID=dummy; export ORACLE_SID

  其他oracle相关的环境变量的前提都是进行了合适的设定。

顺序2-3.制成用于虚拟数据库的控制文件

  编辑上述 顺序1-2.中获得的 CREATE CONTROLFILE 语句。将 CREATE

  CONTROLFILE 语句作为 /tmp/dummy/create.sql保存。

    STARTUP NOMOUNT pfile=/tmp/dummy/initdummy.ora

    CREATE CONTROLFILE SET DATABASE “DUMMY” RESETLOGS NOARCHIVELOG

                       ^^^          ^^^^^^^ ^^^^^^^^^ ^^^^^^^^^^^^

        MAXLOGFILES 5

        MAXLOGMEMBERS 3

        MAXDATAFILES 100

        MAXINSTANCES 1

        MAXLOGHISTORY 226

    LOGFILE

      GROUP 1 ‘/tmp/dummy/redo01.log’  SIZE 1M,

      GROUP 2 ‘/tmp/dummy/redo02.log’  SIZE 1M

    DATAFILE

      ‘/tmp/dummy/system01.dbf’,

      ‘/tmp/dummy/undotbs01.dbf’,

      ‘/tmp/dummy/users01.dbf’

    CHARACTER SET JA16SJIS;

                  ^^^^^^^^

    STARTUP NOMOUNT 中使用 pfile 选项,指定 顺序2-1.(1)的初始化参数。

    各个文件的路径为 顺序2-1中制成的用于工作的目录。

    接下来说明CREATE CONTROLFILE语句的各个选项。

       SET           : 因为是变更数据库名,所以请指定SET

       RESETLOGS     : 因为执行不完全media恢复,请指定RESETLOGS

       NOARHIVELOG   : 虚拟数据库不需要ARCHIVELOG

       MAXxxx        : 指定与否都没问题。

       DATAFILE      :仅仅指定 顺序2-1.(2)的文件。

       LOGFILE       : 因为是执行RESETLOGS,所以不需要使用现有的文件名/尺寸。

       CHARACTER SET :请配合原数据库。

顺序2-4.执行 CREATE CONTROLFILE 语句,制成控制文件

  SQL*Plus中执行 顺序2-3中编辑完成的 CREATE CONTROLFILE 语句。

    % sqlplus ‘/ as sysdba’

    SQL> @/tmp/dummy/create.sql

顺序2-5.执行介质恢复

  通过执行查看顺序1-1.中的 TRUNCATE 时间,就可以执行时间更加早的不完全恢复,因为会返回prompt,所以请指定为auto

    SQL> recover database using backup controlfile until time ‘2004-04-01 16:07:43’;

    ORA-00279:如果变更150762(04/05/2004 20:28:33时生成),需要一个线程

    ORA-00289: 必须讨论的日志文件:/tmp/dummy/arch1_12.ARC

    ORA-00280: 变更150762(线程1)存在于顺序编号12中。

    ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}

    auto

    应用日志完成。

    介质恢复完成。

顺序2-6.启动数据库

  为了不完全恢复,请使用 RESETLOGS 选项,启动数据库。

    SQL> alter database open resetlogs;

顺序2-7.输出TRUNCATE完成的表

从虚拟数据库中输出TRUNCATE完成的表。

    % exp scott/tiger tables=emp file=emp.dmp log=imp.log

顺序2-8.输出表

  利用在上述顺序2-7.的虚拟数据库中获得的输出转储,将表输出到原数据库中。

    % imp scott/tiger tables=emp file=emp.dmp log=exp.log ignore=y

  考虑表自身是否存在,指定 ignore=y

如此,表恢复完成。

在按顺序执行这些步骤时,需要事先执行测试,在明确执行顺序后执行。

因为会处理数据文件,可能会不小心删除了元数据库相关的文件,所以请注意不要搞错顺序,一步一步认真操作

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号