Oracle 异机恢复 - 仅仅恢复业务表空间

-- 场景
数据库中单独的一个表被delete或者truncate。排除可能进行闪回、日志挖掘、闪回查询、基于时间点的表空间恢复等方法,在11g上只能进行异机恢复。然后抽出数据,导入到生产库。在12c开始,支持RMAN对表的恢复。当库的大小不太大的时候,异机恢复还可以,当库为几个T的时候,为了一个表的数据恢复几个T的数据,时间上比较难以接受。本测试,主要测试,仅仅恢复表所在的表空间,来节约恢复时间。经过测试,能达到目的。
测试环境:RDBMS 11.2.0.4 + redhat7.4
恢复到Windows Server 2008 + RDBMS 11.2.0.4


--测试过程,(在同一台机器上进行恢复测试,所以不涉及数据文件路径、redo log路径转换。异机的时候转换下)
## 对数据库做一次全备
## 删除掉数据库所有的文件
## 恢复SPFILE、控制文件
## 在同一台机器上进行恢复,仅仅恢复SYSTEM、SYSAUX、XTTS等表空间(XTTS为业务表空间)数据文件,SPFILE、控制文件等
## 重新创建控制文件,去除掉控制文件中除过SYSTEM、SYSAUX、XTTS之外的数据文件
## 对数据库进行recover(会产生其他表空间的数据文件,实际路径下并没有该文件)
## open resetlogs 开库
## 导出数据 ,导入数据。

-- 数据库上原有的数据文件

RMAN> report schema;

Report of database schema for database with db_unique_name TESTOGG

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    800      SYSTEM               ***     /u01/app/oracle/oradata/testogg/system01.dbf
2    590      SYSAUX               ***     /u01/app/oracle/oradata/testogg/sysaux01.dbf
3    1150     UNDOTBS1             ***     /u01/app/oracle/oradata/testogg/undotbs01.dbf
4    18       USERS                ***     /u01/app/oracle/oradata/testogg/users01.dbf
5    346      EXAMPLE              ***     /u01/app/oracle/oradata/testogg/example01.dbf
6    200      GGS_TBS              ***     /u01/app/oracle/oradata/testogg/ggs_tbs01.dbf
7    10       BB_TBS               ***     /u01/app/oracle/oradata/testogg/bb_tbs01.dbf
8    50       TEST_TBS             ***     /u01/app/oracle/oradata/testogg/test_tbs01.dbf
9    100      XTTS                 ***     /u01/app/oracle/oradata/testogg/xtts01.dbf

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    68       TEMP                 32767       /u01/app/oracle/oradata/testogg/temp01.dbf

RMAN>

-- 启动库到nomount 状态

RMAN> startup nomount force;

Oracle instance started

Total System Global Area     835104768 bytes

Fixed Size                     2257840 bytes
Variable Size                281021520 bytes
Database Buffers             545259520 bytes
Redo Buffers                   6565888 bytes

 

-- 还原spfile,略

-- 还原控制文件

RMAN> restore controlfile from '/backup/control_TESTOGG_20200606_0bv22fdf_1_1';

Starting restore at 06-JUN-20
using channel ORA_DISK_1

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/oradata/testogg/control01.ctl
output file name=/u01/app/oracle/fast_recovery_area/testogg/control02.ctl
Finished restore at 06-JUN-20

RMAN> startup mount;

database is already started
database mounted
released channel: ORA_DISK_1

RMAN>

-- 还原表空间 system,sysaux,undotbs1,xtts的数据文件

RMAN> restore tablespace system,sysaux,undotbs1,XTTS ;

Starting restore at 06-JUN-20
Starting implicit crosscheck backup at 06-JUN-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK
Crosschecked 7 objects
Finished implicit crosscheck backup at 06-JUN-20

Starting implicit crosscheck copy at 06-JUN-20
using channel ORA_DISK_1
Crosschecked 1 objects
Finished implicit crosscheck copy at 06-JUN-20

searching for all files in the recovery area
cataloging files...
no files cataloged

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/testogg/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00009 to /u01/app/oracle/oradata/testogg/xtts01.dbf
channel ORA_DISK_1: reading from backup piece /backup/fulldb_TESTOGG_20200606_05v22f8r_1_1
channel ORA_DISK_1: piece handle=/backup/fulldb_TESTOGG_20200606_05v22f8r_1_1 tag=TAG20200606T100203
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:08
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/testogg/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/testogg/sysaux01.dbf
channel ORA_DISK_1: reading from backup piece /backup/fulldb_TESTOGG_20200606_04v22f8r_1_1
channel ORA_DISK_1: piece handle=/backup/fulldb_TESTOGG_20200606_04v22f8r_1_1 tag=TAG20200606T100203
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 06-JUN-20

RMAN>

-- 直接对表空间进行recover,是不可以的 。

RMAN> recover tablespace system,sysaux,undotbs1,XTTS ;

Starting recover at 06-JUN-20
using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/06/2020 10:19:41
RMAN-06067: RECOVER DATABASE required with a backup or created control file

RMAN>

-- 如果对库进行recover的话,会提示其他数据文件不存在。比如提示4号文件,USERS表空间文件是不存在的。(所以需要做的事情,就是重建控制文件。排除这些文件)

RMAN> recover database;

Starting recover at 06-JUN-20
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/06/2020 10:23:13
RMAN-06094: datafile 4 must be restored

--无论是drop 表空间,还是offline表空间,都不可以

-- 重新创建控制文件,其他业务表空间的数据文件不需要。前提是system表空间文件要在(这个时候,已经把system、sysaux、xtts表空间的数据文件已经还原出来)

SYS@testogg>startup nomount
ORACLE instance started.

Total System Global Area  835104768 bytes
Fixed Size                  2257840 bytes
Variable Size             281021520 bytes
Database Buffers          545259520 bytes
Redo Buffers                6565888 bytes
SYS@testogg>CREATE CONTROLFILE REUSE DATABASE "TESTOGG" RESETLOGS FORCE LOGGING ARCHIVELOG
      2  MAXLOGFILES 16
    M  3  AXLOGMEMBERS 3
   4     MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
LOG  7  FILE
  G  8  ROUP 1 '/u01/app/oracle/oradata/testogg/redo01.log'  SIZE 50M BLOCKSIZE 512,
  9    GROUP 2 '/u01/app/oracle/oradata/testogg/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GRO 10  UP 3 '/u01/app/oracle/oradata/testogg/redo03.log'  SIZE 50M BLOCKSIZE 512
-- ST 11  ANDBY LOGFILE
DAT 12  AFILE
 13    '/u01/app/oracle/oradata/testogg/system01.dbf',
   14  '/u01/app/oracle/oradata/testogg/sysaux01.dbf',
 15    '/u01/app/oracle/oradata/testogg/undotbs01.dbf',
   16  '/u01/app/oracle/oradata/testogg/xtts01.dbf'
CHA 17  RACTER SET AL32UTF8
 18  ;

Control file created.

SYS@testogg>

-- catalog 备份文件

RMAN> catalog start with '/backup/';

using target database control file instead of recovery catalog
searching for all files that match the pattern /backup/

List of Files Unknown to the Database
=====================================
File Name: /backup/fulldb_TESTOGG_20200606_07v22fa2_1_1
File Name: /backup/fulldb_TESTOGG_20200606_06v22f9u_1_1
File Name: /backup/arc_TESTOGG_20200606_0av22fde_1_1
File Name: /backup/fulldb_TESTOGG_20200606_04v22f8r_1_1
File Name: /backup/arc_TESTOGG_20200606_09v22fbn_1_1
File Name: /backup/arc_TESTOGG_20200606_08v22fbn_1_1
File Name: /backup/control_TESTOGG_20200606_0bv22fdf_1_1
File Name: /backup/spfile_TESTOGG_20200606_0cv22fdh_1_1
File Name: /backup/fulldb_TESTOGG_20200606_05v22f8r_1_1
File Name: /backup/xtts/full/XTTS_9.tf
File Name: /backup/xtts/inc/02v1lmv6_1_1
File Name: /backup/xtts/inc/03v1lof9_1_1

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /backup/fulldb_TESTOGG_20200606_07v22fa2_1_1
File Name: /backup/fulldb_TESTOGG_20200606_06v22f9u_1_1
File Name: /backup/arc_TESTOGG_20200606_0av22fde_1_1
File Name: /backup/fulldb_TESTOGG_20200606_04v22f8r_1_1
File Name: /backup/arc_TESTOGG_20200606_09v22fbn_1_1
File Name: /backup/arc_TESTOGG_20200606_08v22fbn_1_1
File Name: /backup/control_TESTOGG_20200606_0bv22fdf_1_1
File Name: /backup/spfile_TESTOGG_20200606_0cv22fdh_1_1
File Name: /backup/fulldb_TESTOGG_20200606_05v22f8r_1_1
File Name: /backup/xtts/full/XTTS_9.tf
File Name: /backup/xtts/inc/02v1lmv6_1_1
File Name: /backup/xtts/inc/03v1lof9_1_1

RMAN>

--recover数据库

RMAN> recover database;

Starting recover at 06-JUN-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=84
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=85
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=86
channel ORA_DISK_1: reading from backup piece /backup/arc_TESTOGG_20200606_09v22fbn_1_1
channel ORA_DISK_1: piece handle=/backup/arc_TESTOGG_20200606_09v22fbn_1_1 tag=TAG20200606T100334
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
archived log file name=/archive_log/1_84_1037791425.dbf thread=1 sequence=84
archived log file name=/archive_log/1_85_1037791425.dbf thread=1 sequence=85
archived log file name=/archive_log/1_86_1037791425.dbf thread=1 sequence=86
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=87
channel ORA_DISK_1: reading from backup piece /backup/arc_TESTOGG_20200606_0av22fde_1_1
channel ORA_DISK_1: piece handle=/backup/arc_TESTOGG_20200606_0av22fde_1_1 tag=TAG20200606T100334
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/archive_log/1_87_1037791425.dbf thread=1 sequence=87
unable to find archived log
archived log thread=1 sequence=88
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/06/2020 10:39:19
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 88 and starting SCN of 1493690

RMAN>

-- Open restlogs 打开数据库

RMAN> alter database open resetlogs;

database opened

RMAN>

-- recover完毕,RMAN下report schema 。发现其他的表空间数据文件是存在的。大小是0.文件名称是MISSING0000X。

RMAN> report schema;

Report of database schema for database with db_unique_name TESTOGG

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    800      SYSTEM               ***     /u01/app/oracle/oradata/testogg/system01.dbf
2    590      SYSAUX               ***     /u01/app/oracle/oradata/testogg/sysaux01.dbf
3    1150     UNDOTBS1             ***     /u01/app/oracle/oradata/testogg/undotbs01.dbf
4    0        USERS                ***     /u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00004
5    0        EXAMPLE              ***     /u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00005
6    0        GGS_TBS              ***     /u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00006
7    0        BB_TBS               ***     /u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00007
8    0        TEST_TBS             ***     /u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00008
9    100      XTTS                 ***     /u01/app/oracle/oradata/testogg/xtts01.dbf

RMAN>

-- 查看表空间信息。 其他表空间还是有的。

SYS@testogg>select tablespace_name from dba_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS
EXAMPLE
GGS_TBS
BB_TBS
TEST_TBS
XTTS

10 rows selected.

SYS@testogg>

SYS@testogg>select file_name from dba_data_files;

FILE_NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/testogg/xtts01.dbf
/u01/app/oracle/oradata/testogg/undotbs01.dbf
/u01/app/oracle/oradata/testogg/sysaux01.dbf
/u01/app/oracle/oradata/testogg/system01.dbf
/u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00004
/u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00005
/u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00006
/u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00007
/u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00008

9 rows selected.

SYS@testogg>

-- 当进行drop 掉表空间的时候,提示无法drop。

SYS@testogg>drop tablespace users;
drop tablespace users
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 6 cannot be read at this time
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6:
'/u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00006'
ORA-06512: at line 1166
ORA-00376: file 6 cannot be read at this time
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6:
'/u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00006'


SYS@testogg>

-- 实际上dbs里面并没有这些文件

[oracle@oggtest backup]$ cd /u01/app/oracle/product/11.2.0/dbhome_1/dbs
[oracle@oggtest dbs]$ ll
total 9836
-rw-rw----. 1 oracle oinstall     1544 Apr 15 10:56 hc_orcl.dat
-rw-rw----. 1 oracle oinstall     1544 Apr 15 11:18 hc_test.dat
-rw-rw----. 1 oracle oinstall     1544 Jun  6 10:40 hc_testogg.dat
-rw-r--r--. 1 oracle oinstall     2851 May 15  2009 init.ora
-rw-r-----. 1 oracle oinstall       24 Apr 15 11:23 lkTESTOGG
-rw-r-----. 1 oracle oinstall     1536 Apr 15 14:37 orapwtestogg
-rw-r-----  1 oracle oinstall 10043392 Jun  6 10:04 snapcf_testogg.f
-rw-r-----. 1 oracle oinstall     3584 Jun  6 10:41 spfiletestogg.ora
[oracle@oggtest dbs]$

-- 测试下,启动关闭库 ,启动关闭正常。

SYS@testogg>shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@testogg>startup
ORACLE instance started.

Total System Global Area  835104768 bytes
Fixed Size                  2257840 bytes
Variable Size             281021520 bytes
Database Buffers          545259520 bytes
Redo Buffers                6565888 bytes
Database mounted.
Database opened.
SYS@testogg>

-- 再次重建控制文件。发下这些MISSING0000X文件还是有的 (过程略)

-- 导出数据试试 ,数据在表空间xtts中 (其实到了这一步,库能起来,能看到表。方法就比较多了)

SYS@testogg>conn u_xtts/oracle
Connected.
U_XTTS@testogg>desc t_xtts
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 OWNER                                              VARCHAR2(30)
 OBJECT_NAME                                        VARCHAR2(128)
 SUBOBJECT_NAME                                     VARCHAR2(30)
 OBJECT_ID                                          NUMBER
 DATA_OBJECT_ID                                     NUMBER
 OBJECT_TYPE                                        VARCHAR2(19)
 CREATED                                            DATE
 LAST_DDL_TIME                                      DATE
 TIMESTAMP                                          VARCHAR2(19)
 STATUS                                             VARCHAR2(7)
 TEMPORARY                                          VARCHAR2(1)
 GENERATED                                          VARCHAR2(1)
 SECONDARY                                          VARCHAR2(1)
 NAMESPACE                                          NUMBER
 EDITION_NAME                                       VARCHAR2(30)

U_XTTS@testogg>select count(*) from t_xtts;

  COUNT(*)
----------
    261273

U_XTTS@testogg>
U_XTTS@testogg>select default_tablespace from dba_users where username='U_XTTS';

DEFAULT_TABLESPACE
------------------------------
XTTS

U_XTTS@testogg>

--expdp无法导出表(记得以前用RMAN从Linux恢复到Windows下,使用隐含参数_allow_restlogs_corruption打开库,也是无法使用数据泵,使用exp解决了)

[oracle@oggtest trace]$ expdp 'u_xtts/oracle' directory=UDMP dumpfile=xtts.dmp tables=T_XTTS

Export: Release 11.2.0.4.0 - Production on Sat Jun 6 10:57:16 2020

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-31626: job does not exist
ORA-31633: unable to create master table "U_XTTS.SYS_EXPORT_TABLE_05"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPV$FT", line 1038
ORA-00376: file 6 cannot be read at this time
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00006'
ORA-06512: at line 1166
ORA-00376: file 6 cannot be read at this time
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/MISSING00006'


[oracle@oggtest trace]$

-- 使用exp可以导出数据

[oracle@oggtest trace]$ exp u_xtts/oracle file=/home/oracle/a.dmp tables=t_xtts

Export: Release 11.2.0.4.0 - Production on Sat Jun 6 10:59:47 2020

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.


Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export done in US7ASCII character set and UTF8 NCHAR character set
server uses AL32UTF8 character set (possible charset conversion)

About to export specified tables via Conventional Path ...
. . exporting table                         T_XTTS     261273 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
Export terminated successfully with warnings.
[oracle@oggtest trace]$

-- 导入测试

PS C:\Users\Administrator> sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on 星期六 6月 6 13:07:58 2020

Copyright (c) 1982, 2017, Oracle.  All rights reserved.

@>conn system/oracle
Connected.

SYSTEM@test>create user u_xtts identified by oracle;

User created.

SYSTEM@test>grant connect,resource to u_xtts;

Grant succeeded.

SYSTEM@test>grant dba to u_xtts;

Grant succeeded.

SYSTEM@test>

PS C:\Users\Administrator> imp u_xtts/oracle file=c:\dump\a.dmp tables=t_xtts

Import: Release 11.2.0.4.0 - Production on 星期六 6月 6 13:12:30 2020

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.


Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

Export file created by EXPORT:V11.02.00 via conventional path
import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
export client uses US7ASCII character set (possible charset conversion)
export server uses UTF8 NCHAR character set (possible ncharset conversion)
. importing U_XTTS's objects into U_XTTS
. importing U_XTTS's objects into U_XTTS
. . importing table                       "T_XTTS"     261273 rows imported
Import terminated successfully without warnings.
PS C:\Users\Administrator>

-- 验证下数据

SYSTEM@test>conn u_xtts/oracle
Connected.
U_XTTS@test>select count(*) from t_xtts;

  COUNT(*)
----------
    261273

U_XTTS@test>delete from t_xtts where object_id=500;

3 rows deleted.

U_XTTS@test>commit;

Commit complete.

U_XTTS@test>select count(*) from t_xtts;

  COUNT(*)
----------
    261270

U_XTTS@test>

END

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
PRM DUL for oracle恢复被truncate截断掉的表 Oracle DBA神器:PRM灾难恢复工具,Schema级别数据恢复。PRM For Oracle Database – schema级别oracle数据库数据恢复特性 ,PRM即ParnassusData Recovery Manager是企业级别Oracle数据库灾难恢复工具。PRM可以在无备份的情况下恢复被truncated/drop掉的表,也可以恢复无法打开的Oracle数据库(Alter Database Open失败)中的数据。 PRM是图形化增强版的Oracle DUL工具,同时具备很多Oracle DUL不具备的特性 情况 当某张表被意外truncated掉了,需要恢复其上的所有数据时。表空间的多个数据文件均存放在ASM上,且没有任何形式的备份。 注意这边文章针对的是PRM在 数据字典模式下的Truncate恢复选项不可用时使用,数据字典模式下的Truncate恢复选项是最简单、易用的一种模式,具体使用见《使用PRM恢复Oracle数据库中误truncate截断的表数据》http://www.parnassusdata.com/zh-hans/node/52 PRM 3.0的下载地址: http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3002.zip PRM 的官方网站: http://www.parnassusdata.com/ PRM背景 PRM恢复表数据时存在多种模式, PRM需要知道哪些表上的数据块是需要被读取并取出数据的。默认的表现形式是直接从segment header数据段头里获取EXTENT MAP即盘区图,另一种方案就是由PRM自己去构建一个盘区图。 这些盘区图可以通过,PRM的SCAN DATABASE选项来获得: Recovery Wizard => Non-Dictionary Mode,如果是ASM则选择Non-Dictionary Mode(ASM) 执行SCAN Database后会生成SEG$和EXT$的数据到PRM内嵌的数据库中,之后可以选择SCAN TABLES FROM SEGMENTS 或者 SCAN TABLES FROM EXTENTS。 FROM Segments 意味着使用Segment Header中获得的Extent MAP信息,而FROM Extents意味着使用PRM自己扫描获得的EXTENT信息。 请注意当TRUNCATE发生后, 数据表Table的Segment Header中的Extent MAP信息就会被清空了, 但实际存放数据的数据块中的行数据还是在哪里的,除非被其他数据表/索引的增长而覆盖了。 所以当Truncate发生后选择SCAN TABLES FROM SEGMENT 是找不回数据的,必须使用SCAN TABLES FROM EXTENTS, EXTENT的信息是PRM自己去数据文件中扫描获得的,所以只要有数据的地方PRM就会自己去找到。 除了Truncate需要使用到 SCAN TABLES FROM EXTENTS之外对于DROP TABLE的恢复也可以用到SCAN TABLES FROM EXTENTS , 总之当Segment Header找不到(可能存放Segment Header的数据文件丢失了)、或者已损坏(可能Segment Header的数据块被损坏了)、或者其中的Extent Map数据无效(Truncate、DROP或逻辑损坏)时都可以使用SCAN TABLES FROM EXTENTS 。 但是如果不存在上述的问题时,建议用SCAN TABLES FROM SEGMENTS ,因为从Segment Header获取信息更方便也更高效一些。 在PRM中同一个程序实例 同时只能使用SCAN TABLES FROM SEGMENTS 或者 SCAN TABLES FROM EXTENTS 中的一个。 使用SCAN TABLES FROM EXTENTS 后需要找到对应被TRUNCATE掉的表的原始DATA_OBJECT_ID,即左侧属性图中的一个对象,并将其DataBridge 数据搭桥传输到目标数据库中即可。 用户truncate误删 schema下的若干数据表,无法使用flashback query等技术恢复数据,尝试从之前的全备份中恢复,数据库restore速度较快,但是archivelog恢复时由于HP data Protecter的不明原因导致归档恢复十分缓慢,缓慢一个归档往往要几分钟,而需要restore数百个归档,时间上无法接受。 该案例通过PRM-DUL直接在字典模式下恢复truncate数据的功能,在不到一个小时内就恢复了数十万条数据,虽然我们无法保证不丢失一条数据,但至少帮助用户在最短时间内恢复了主要业务
第1章 ORACLE数据库基础知识 1 1.1 产品概述 1 1.1.1 产品简介 1 1.1.2 基本概念 1 1.2 ORACLE系统结构 2 1.2.1 ORACLE物理结构 2 1.2.2 系统全局区 4 1.2.3 进程 6 1.3 存储管理 7 1.3.1 逻辑结构 8 1.3.2 表(Table) 12 1.3.3 视图(View) 15 1.3.4 索引(Index) 16 1.3.5 同义词(Synonym) 16 1.3.6 序列(Sequence) 17 1.3.7 数据库链(Database Link) 17 第2章 管理ORACLE数据库 19 2.1 启动与关闭 19 2.1.1 权限 19 2.1.2 ORACLE的四中状态 20 2.1.3 启动数据库 20 2.1.4 关闭数据库 22 2.2 应用开发工具(SQL * Plus) 24 2.2.1 SQL 24 2.2.2 PL/SQL 26 2.2.3 数据库管理工具 29 2.3 备份及恢复 29 2.3.1 备份(转入) 29 2.3.2 恢复 31 2.4 ORACLE数据库的网络应用 33 2.4.1 SQL*Net产品介绍 33 2.4.2 配置客户机/服务器结构 35 第3章 常用任务 39 3.1 如何恢复被误删的数据文件 39 3.2 如何杀掉吊死session 39 3.3 如何修改字符集 39 3.4 如何追加表空间 39 3.5 如何加大表的maxextents值 40 3.6 如何查询无效对象 40 3.7 怎样分析SQL语句是否用到索引 40 3.8 如何将Oracle8数据导入Oracle7数据库 41 3.9 怎样判断是否存在回滚段竞争 41 3.10 怎样手工跟踪函数/存储过程执行情况 42 3.11 多种业务使用同一数据库如何分配回滚段 42 3.12 怎样远程用Sql*Load倒入数据 43 3.13 怎样倒出、倒入文本数据 43 3.13.1 倒出 43 3.13.2 倒入 43 3.14 如何更新当前数据库日志备份方式为archive 44 3.15 如何修改ORACLE数据库的SID 44 3.16 Unix环境下如何实现自动备份 44 3.16.1 设置运行环境 45 3.16.2 倒出数据 45 3.16.3 异地备份 46 3.16.4 启动备份进程 47 3.17 怎样分析Oracle故障 48 3.18 如何设置ORACLE PARALLEL SERVER 49 3.18.1 HOSTS文件 50 3.18.2 OGMS的LST文件 51 3.18.3 LISTENER.ORA文件 51 3.18.4 INITORA8.ORA文件 52 第4章 常见问题处理 54 4.1 增大Processes参数后数据库不能启动 54 4.2 误将datafile删除导致数据库无法启动 54 4.3 rollback segment 状态为 "Needs recovery"如何处理 54 4.4 ORACLE8 DOWN机如何处理 55 4.4.1 大量trace文件导致DOWN机处理方法 55 4.4.2 动态锁参数配置不适当导致DOWN机 56 4.5 创建或追加表空间操作不成功处理方法 56 4.6 Job不能执行处理方法 56 4.7 temp表空间溢出处理办法 57 4.8 还有一定表空间为何不能建新表 57 4.9 不带参数建立表发现表空间迅速变小 57 第5章 ORACLE数据字典与视图 58 5.1 常用数据字典与视图 58 5.1.1 dba_tablespaces(user_tablespaces) 58 5.1.2 dba_data_files(user_data_files) 58 5.1.3 dba_segments(user_segments) 58 5.1.4 dba_rollback_segs 59 5.1.5 dba_extents 59 5.1.6 dba_free_spaces 59 5.2 数据字典与视图表 59 第6章 SQL语言运算符与函数 66 6.1 各种运算符列表 66 6.2 字符函数列表 67 6.3 数值函数列表 68 6.4 日期函数列表 68 6.5 聚组函数列表 69
以下是一个 Oracle 数据损坏恢复的案例,包括具体解决步骤和具体命令: 1. 案例背景 某企业的 Oracle 数据库中出现了数据坏块的情况,导致数据库无法正常启动和运行。经过初步排查,发现是数据库中的数据文件出现了坏块,需要进行修复。 2. 解决过程 步骤一:备份数据 在进行任何操作之前,首先需要备份数据库中的数据,以便在操作失误或出现意外情况时进行恢复。同时可以将备份数据恢复到测试环境中,以便进行后续的测试和验证。 步骤二:确定损坏的数据文件和坏块位置 确认数据库中出现了坏块的数据文件和坏块位置。可以使用 DBVERIFY 工具进行检查,例如: ``` dbv file=/u01/app/oracle/oradata/ORCL/users01.dbf blocksize=8192 ``` 该命令将检查 users01.dbf 文件中的所有块是否正常。 步骤三:创建修复表空间 创建一个临时的修复表空间,用于存放修复后的数据。例如: ``` CREATE TABLESPACE repair_ts DATAFILE '/u01/app/oracle/oradata/ORCL/repair01.dbf' SIZE 100M; ``` 步骤四:将损坏块标记为已修复状态 将损坏的块标记为已修复状态,以便在下一步中进行修复。例如: ``` ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' OFFLINE IMMEDIATE; ``` ``` RMAN> BLOCKRECOVER DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' BLOCK 100; ``` 步骤五:将修复后的数据导入修复表空间 将修复后的数据导入到修复表空间中。例如: ``` ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' ONLINE; ``` ``` ALTER TABLESPACE users MOVE TABLESPACE repair_ts; ``` 步骤六:检查数据库完整性 重新启动数据库后,需要检查数据库的完整性和一致性。可以使用 Oracle 提供的工具进行检查,例如使用 DBVERIFY 工具检查数据文件是否损坏,使用 ANALYZE 命令检查数据库的逻辑一致性等。 步骤七:恢复数据库服务 在确认数据库的完整性和一致性后,可以重新启动数据库服务,进行正常的业务操作。 3. 结论 通过以上的步骤,成功恢复了该企业的 Oracle 数据库服务。该案例也提醒用户需要采取备份和恢复措施,加强对于数据库的监控和维护,提高数据库的可用性和安全性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值