(急)Oracle中误删除表空间的问题(求救)
本帖最后由 ALLSTARS_ORACLE 于 2017-4-26 11:39 编辑操作系统 SUN880 Solaris Oracle817 归档模式
我在使用DBA Sudio时不小时删除了一个表空间,紧跟着我就停掉了数据库进地冷备,
上一次的冷备还是五天前的备份,其中间的归档日志恢复时发现少了一个归档日志,
删除表空间后做了冷备其中有个数据文件(不是删的那个表空间里的数据文件)在往回传的时候报 I/O error 备份时传都是正常的(我用的是FlashFXP传的 在同一台机器上)
现在的问题就是 表空间给删了
与上次冷备后的归档日志少了一少,(在中间)
删除后备份中有一个数据文件报I/O error
请高手指教~!(不好意思 我是个菜鸟 请说明细点 谢谢~~~)
就是啊 我这次死硬了 我在公司里 业务系统跑了两年多啦 要是丢数据的话那我可是麻烦大了
我是个菜鸟 请大哥指出 如何 使用DUL把数据给抓出来
还有 我那个最新备份里 为何有个数据文件备份时没问题 现在拷回来就报 I/O 错误
如遇到这样的问题 应如何解决 这个数据文件还可以恢复吗??
备份的硬盘应该没有问题 我备份的其它数据文件全都是好的 唯有这一个数据文件传回来的时候报I/O错误,
还有其它办法可救吗
求高手们救命啊!!谢谢!!!
就报 I/O error 其它没报
归档文件少一个估计是当时拷的时候选漏掉的 归档是几天的归档 分几次拷的 有可能是两天之间漏掉的。
不是索引表空间
55555555555555 还有救吗＞？
现在已经用上周备份的数据文件回复到归档日志断点的那个地方了 ，不过现在数据还差两三天的数据。考虑用上周备份的控制文件和最新备份（删除表空间后备份）的进行强行启数据库 启数据库的时候报了个 ORA－00603 错。
DROP TABLESPACE误删除表空间的Oracle特殊恢复
某企业核心业务数据库由于误操作导致多个业务表空间被意外DROP，这些业务表空间存放了300多张表，且无任何形式的有效物理、逻辑备份。
诗檀软件工程师赴用户现场。 具体了解了本问题的细节信息：
数据库采用归档模式，但当时未找到有效的物理或逻辑备份。
多个表空间被DROP ，但因为DROP TABLESPACE没有指定inlucding datafiles，故相关数据文件仍保留在文件系统中未被删除。
尝试使用flashback query闪回查询OBJ$、TAB$等表以便获取被DROP TABLESPACE所删除的字典信息时出现ORA-01555错误，说明相关UNDO数据已过期，无法通过闪回查询挽救DROP TABLESPACE相关的字典数据。
尝试使用bbed观察dbf上的字典表，发现OBJ$、TAB$等字典表仅仅残存少量已删除数据，无法通过特殊恢复已删除数据行的手段来恢复字典数据
以上场景信息，由于DROP TABLESPACE后已无法通过闪回查询或bbed特殊手段来恢复对应的数据字典信息，故恢复数据字典来回退drop tablespace操作已不可能。
针对此种场景，在无有效物理或逻辑备份的情况下，使用ORACLE PRM-DUL工具是唯一有效的恢复途径。
注意：针对此类无有效物理备份的场景采用DUL特殊恢复的，并无法保证100%恢复数据。其恢复数据的比例主要取决于数据空间在被ORACLE回收后是否有被重用或覆盖。DROP TABLESPACE操作本身包含一系列的递归操作，即包括递归地DROP该表空间上的所有数据表，在完全DROP该表空间上的所有数据表后才能真正意义上DROP TABLESPACE，则此DROP TABLESPACE持续的时间内其回收的空间可能被重用或覆盖。
由于字典数据已丢失且不可挽回，故在使用ORACLE PRM-DUL时需采用非字典模式(NON-SYSTEM TABLESPACE)，即直接扫描已被DROP TABLESPACE的数据文件，扫描这些数据文件的SEGMENT HEADER或 SEGMENT EXTENTS数据。这些原始数据中虽然包含着实际表上的行数据，但并不包含例如表的名字TABLE_NAME或COLUMN_NAME字段名字或字段类型等元数据。故非字典模式下UNLOAD抽取出来的表的表名为OBJ+其DATA_OBJECT_ID的形式 例如OBJ9999，代表此表为DATA_OBJECT_ID=9999的数据表。故非字典模式下的UNLOAD出来的表，需要人工识别其数据具体属于哪个表，或通过其他手段来识别。
采用PRM-DUL的非字典模式 存在2种扫描方式，基于SEGMENT HEADER 表头或 EXTENT 盘区模式。 对于一个表空间无任何数据文件丢失的且确认表头未丢失的场景优先采用SEGMENT HEADER 表头模式。 PRM-DUL在表头模式下正常 SCAN DATABASE ; SCAN TABLES; 操作后扫描发现了超过190张表，通过业务人员识别和之前获取的表对应关系，优先恢复了部分业务表，但在SEGMENT HEADER 表头模式下未找到5张业务核心表。
通过SEGMENT HEADER 表头模式下未找到五张表，说明了这五张表的SEGMENT HEADER 表头由于DROP TABLESPACE而已损坏或被重用，这说明了DROP TABLESPACE过程中已重用/覆盖部分回收空间。由于扫描SEGMENT HEADER 表头模式下未找到需要的表，故后续采用扫描EXTENT模式。
由于扫描EXTENT模式将扫描出数据文件上所有存有数据行的数据块，而无需一个SEGMENT HEADER 表头，故采用扫描EXTENT模式可以找到最大量的数据，同时由于其扫描范围更广故可能找到更多无需恢复的数据表。由于每一次扫描均需要针对超过1TB数据的数据文件，故每一次扫描均耗费较多时间。
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com 本帖最后由 biotwang 于 2017-8-7 14:21 编辑
Oracle 使用TSPITR恢复被drop表空间的步骤
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com
适用于：
Oracle Database – Enterprise Edition – 版本11.2.0.1 及以上
本文信息适用于任何平台。
目的
使用TSPITR恢复被drop表空间。
范围
RMAN自动Tablespace Point-In-Time Recovery ( TSPITR)使你能快速恢复在Oracle数据库中一个或多个表空间到较早的时间，而不影响数据库中的其他表空间和其他对象的状态。
在11.2版本之前，TSPITR有无法恢复被drop表空间的限制。
从11.2起不再有该限制。我们可以使用TSPITR恢复被drop表空间。
以下示例显示TSPITR恢复被drop表空间的步骤和功能。
详情
示例:
1) 创建一个表空间。
SQL> create tablespace users datafile 'D:\DATABASES\ORA11G\users01.dbf' size 10m reuse;
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS
2) 创建一个用户并在新表空间中创建一个表。
SQL> create user tiger identified by tiger;
SQL> grant dba to tiger;
SQL> conn tiger/tiger
SQL> create table objects tablespace users as select * from dba_objects ;
SQL> select count(*) from objects;
COUNT(*)
----------
17299
3) 记录当前日志序列号。
SQL > select sequence# from v$log where status='CURRENT';
SEQUENCE#
----------
21
4) 对数据库和归档日志进行备份。
% rman target /
RMAN> backup database plus archivelog;
5) 现在登录到数据库，仅执行一些日志切换，然后drop表空间。
SQL> alter system switch logfile;
SQL> alter system switch logfile;
SQL> drop tablespace users including contents and datafiles;
6) 现在记下数据库中当前日志序列号。
SQL> select SEQUENCE# from v$log where status='CURRENT';
SEQUENCE#
----------
25
7)当表空间被drop时，数据库中的序列号是25。因此，如果我们恢复到序列24，就能得回表空间。要恢复到序列24，我们在TSPITR语句的set until子句中使用24 +1= 25。
% rman target /
RMAN> recover tablespace users until logseq 25 auxiliary destination 'd:\';
Starting recover at 03-JAN-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=15 device type=DISK
RMAN-05026: WARNING: presuming following set of tablespaces applies to specified point-in-time
List of tablespaces expected to have UNDO segments
Tablespace SYSTEM
Tablespace UNDOTBS1
Creating automatic instance, with SID='nyxF'
initialization parameters used for automatic instance:
db_name=ORA11G
db_unique_name=nyxF_tspitr_ORA11G
compatible=11.2.0.0.0
db_block_size=8192
db_files=200
sga_target=280M
processes=50
db_create_file_dest=d:\
log_archive_dest_1='location=d:\'
#No auxiliary parameter file used
starting up automatic instance ORA11G
Oracle instance started
Total System Global Area 292933632 bytes
Fixed Size 1374164 bytes
Variable Size 100665388 bytes
Database Buffers 184549376 bytes
Redo Buffers 6344704 bytes
Automatic instance created
List of tablespaces that have been dropped from the target database:
Tablespace users
contents of Memory Script:
{
# set requested point in time
set until logseq 25 thread 1;
# restore the controlfile
restore clone controlfile;
# mount the controlfile
sql clone 'alter database mount clone database';
# archive current online log
sql 'alter system archive log current';
# avoid unnecessary autobackups for structural changes during TSPITR
sql 'begin dbms_backup_restore.AutoBackupFlag(FALSE); end;';
}
executing Memory Script
executing command: SET until clause
Starting restore at 03-JAN-11
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=59 device type=DISK
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: reading from backup piece D:\DATABASES\ORA11G\FRA\ORA11G\BACKUPSET\2011_01_03\O1_MF_NCSNF_TAG20110103T092723_6L2LB86C_.BKP
channel ORA_AUX_DISK_1: piece handle=D:\DATABASES\ORA11G\FRA\ORA11G\BACKUPSET\2011_01_03\O1_MF_NCSNF_TAG20110103T092723_6L2LB86C_.BKP tag=TAG20110103T092723
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=D:\ORA11G\CONTROLFILE\O1_MF_6L2M39N0_.CTL
Finished restore at 03-JAN-11
sql statement: alter database mount clone database
sql statement: alter system archive log current
sql statement: begin dbms_backup_restore.AutoBackupFlag(FALSE); end;
contents of Memory Script:
{
# set requested point in time
set until logseq 25 thread 1;
# set destinations for recovery set and auxiliary set datafiles
set newname for clone datafile 1 to new;
set newname for clone datafile 3 to new;
set newname for clone datafile 2 to new;
set newname for clone tempfile 1 to new;
set newname for datafile 4 to
"D:\DATABASES\ORA11G\USERS01.DBF";
# switch all tempfiles
switch clone tempfile all;
# restore the tablespaces in the recovery set and the auxiliary set
restore clone datafile 1, 3, 2, 4;
switch clone datafile all;
}
executing Memory Script
executing command: SET until clause
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
renamed tempfile 1 to D:\ORA11G\DATAFILE\O1_MF_TEMP_%U_.TMP in control file
Starting restore at 03-JAN-11
using channel ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to D:\ORA11G\DATAFILE\O1_MF_SYSTEM_%U_.DBF
channel ORA_AUX_DISK_1: restoring datafile 00003 to D:\ORA11G\DATAFILE\O1_MF_UNDOTBS1_%U_.DBF
channel ORA_AUX_DISK_1: restoring datafile 00002 to D:\ORA11G\DATAFILE\O1_MF_SYSAUX_%U_.DBF
channel ORA_AUX_DISK_1: restoring datafile 00004 to D:\DATABASES\ORA11G\USERS01.DBF
channel ORA_AUX_DISK_1: reading from backup piece D:\DATABASES\ORA11G\FRA\ORA11G\BACKUPSET\2011_01_03\O1_MF_NNNDF_TAG20110103T092723_6L2L941Y_.BKP
channel ORA_AUX_DISK_1: piece handle=D:\DATABASES\ORA11G\FRA\ORA11G\BACKUPSET\2011_01_03\O1_MF_NNNDF_TAG20110103T092723_6L2L941Y_.BKP tag=TAG20110103T092723
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:45
Finished restore at 03-JAN-11
datafile 1 switched to datafile copy
input datafile copy RECID=12 STAMP=739446137 file name=D:\ORA11G\DATAFILE\O1_MF_SYSTEM_6L2M3MRW_.DBF
datafile 3 switched to datafile copy
input datafile copy RECID=13 STAMP=739446137 file name=D:\ORA11G\DATAFILE\O1_MF_UNDOTBS1_6L2M3N8S_.DBF
datafile 2 switched to datafile copy
input datafile copy RECID=14 STAMP=739446137 file name=D:\ORA11G\DATAFILE\O1_MF_SYSAUX_6L2M3N1G_.DBF
contents of Memory Script:
{
# set requested point in time
set until logseq 25 thread 1;
# online the datafiles restored or switched
sql clone "alter database datafile 1 online";
sql clone "alter database datafile 3 online";
sql clone "alter database datafile 2 online";
sql clone "alter database datafile 4 online";
# recover and open resetlogs
recover clone database tablespace "USERS", "SYSTEM", "UNDOTBS1", "SYSAUX" delete archivelog;
alter clone database open resetlogs;
}
executing Memory Script
executing command: SET until clause
sql statement: alter database datafile 1 online
sql statement: alter database datafile 3 online
sql statement: alter database datafile 2 online
sql statement: alter database datafile 4 online
Starting recover at 03-JAN-11
using channel ORA_AUX_DISK_1
executing Memory Script
database closed
database dismounted
8) 这里，rman使用可传输表空间机制将被drop表空间重新插入数据库。
SQL> select tablespace_name,status,plugged_in from dba_tablespaces;
TABLESPACE_NAME STATUS PLU
---------------- ------- ---
SYSTEM ONLINE NO
SYSAUX ONLINE NO
UNDOTBS1 ONLINE NO
TEMP ONLINE NO
USERS OFFLINE YES ===> Plugged_in is YES.
9) 联机表空间。
SQL>alter tablespace users online;
10) Check for the data.
SQL> conn tiger/tiger
SQL> select count(*) from objects;
COUNT(*)
----------
17299
REFERENCES
NOTE:455865.1 – How to Recover a Drop Tablespace with RMAN Oracle 11.2之前的解决方案
RMAN duplicate命令不能用于恢复一个被drop掉的表空间，因为当前数据库控制文件并没有被删除的表空间的相关数据文件信息。
在Oracle 11g release 2之前，你不能使用表空间时间点恢复（TSPITR）来恢复一个被删除的表空间。
因此，对于现有数据库来说，你有以下两种可考虑的恢复方式：
方案1. 将整个数据库恢复到表空间被删除的时间点。
数据库中的所有数据将被回退到此时间点，不仅仅是对于某个表空间。
方案2. 将目标库克隆到新位置上，进行数据库时间点恢复后导出表空间数据，然后将导出的数据导入回原数据库。这不会影响现有数据库中的其它数据。
方案1：数据库时间点恢复
1. 判断使用restore恢复的'set until'时间点：
- 查看数据库alert.log找到当时'drop tablespace'命令以找到当时的执行时间
- 在此时间点上减去5分钟，并记录此时间以用于RMAN 'set until'语句。
例如：Thu Aug 23 10:21:01 2007
Thread 1 advanced to log sequence 243
Current log# 2 seq# 243 mem# 0: /u01/V102_oradata/redo02.log
Thu Aug 23 10:21:16 2007
drop tablespace test including contents and datafiles
Thu Aug 23 10:21:19 2007
Deleted file /u01/temp/test01.dbf
Completed: drop tablespace test including contents and datafiles以上alert.log日志中显示表空间在10:21，Aug 23 2007被删除。同时我们看到在drop前，写入的在线重做日志序列号为sequence 243。因此对应RMAN 'set until'可以是：
时间点方式:---------------
run
{
set until time "to_date('2007 Aug 23 10:15','yyyy mon dd hh24:mi')";
........
........
}
使用日志序列方式:------------------------
run
{
set until sequence 243 thread 1;
........
........
}请注意：以上语法告知RMAN recover到sequence 242。
2. 关闭目标数据库并以nomount状态重启：RMAN> shutdown immediate;
RMAN> startup nomount;3. 使用相同的'set until'方式恢复控制文件.RMAN> run
{
set until ........................;
restore controlfile;
}
4. mount数据库RMAN> alter database mount;5. 进行数据库时间点恢复RMAN> run
{
set until ........................;
restore database;
recover database;
}6. 使用resetlogs项打开数据库RMAN> alter database open resetlogs;方案2: 从克隆数据库中获取被删除的表空间
数据库的时间点恢复和之前方案1中的基本相同，不同的仅仅是不同的恢复位置。
具体步骤则可以查看MOS下的
Note 223543.1 How to Recover From a DROP / TRUNCATE / DELETE TABLE with RMAN
页:
[1]