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

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

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

症状
你使用原始设备作为存储。你尝试将数据文件添加到表空间。虽然数据文件被添加到操作系统，但操作失败。生成以下错误：
ERROR
———————–
ORA-01119: error in creating database file ‘/oradata02/l28dr/system_02.dbf’
ORA-27041: unable to open file
SVR4 Error: 6: No such device or address

STEPS
———————–
1. 尝试添加数据文件：
SQL> alter tablespace system add datafile ‘/oradata02/l28dr/system_02.dbf’ size 2048M reuse;
alter tablespace system add datafile ‘/oradata02/l28dr/system_02.dbf’ size 2048M reuse
*
ERROR at line 1:
ORA-01119: error in creating database file ‘/oradata02/l28dr/system_02.dbf’
ORA-27041: unable to open file
SVR4 Error: 6: No such device or address
Additional information: 1

2. 查询文件系统显示数据文件存在。
$ ls -ltr /oradata02/l28dr/system_02.dbf

lrwxrwxrwx 1 oracle dba 49 Jun 13 11:43 /oradata02/l28dr/system_02.dbf -> /dev/vx/rdsk/l28dr-oradata-dg/l28dr_system_02_raw

原因
在这个情况下，这是硬件问题。这不是关于Oracle 和裸设备之间的接口。
最后的测试是将Oracle软件从组合中删除严格专注于硬件。
这里它仍然失败，例如：
$ dd if=/oradata02/l28dr/system_02.dbf bs=8192 count=3 of=/tmp/dd.out
dd: /oradata02/l28dr/system_02.dbf: open: No such device or address

如果它也在硬件级别失败了，那么可以肯定这是硬件问题。
解决方案
1. 联系你的硬件供应商寻求帮助，并告知他们你遇到了下一个问题：
$ dd if=/oradata02/l28dr/system_02.dbf bs=8192 count=3 of=/tmp/dd.out
dd: /oradata02/l28dr/system_02.dbf: open: No such device or address

2. 同时，查看你的备份情况，这样一旦硬件被修复，你就能准备好按要求操作Oracle。
参考
NOTE:304488.1 – Using standby_file_management with Raw Devices
BUG:912433 – ORA-1119, ORA-27037, SVR4 ERROR:2, ADD INFO:3 WHEN CREATE TEMP TABLESPACE
NOTE:18693.1 – OERR: ORA 1119 error in creating datafile
NOTE:433399.1 – Could Not Add Datafile Due to ORA-01119, ORA-17502 and ORA-15041

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

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

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

症状

1) 由于（在Solaris上）下一个错误，无法将新的磁盘添加到现有磁盘新磁盘组，或无法创建新的磁盘组：

SQL> create diskgroup testdg external redundancy disk ‘/dev/rdsk/c4t60060480000190103592533031453837d0s2’;
create diskgroup testdg external redundancy disk ‘/dev/rdsk/c4t60060480000190103592533031453837d0s2’
*
ERROR at line 1:
ORA-15018: diskgroup cannot be created
ORA-15031: disk specification
‘/dev/rdsk/c4t60060480000190103592533031453837d0s2’ matches no disks
ORA-15025: could not open disk
‘/dev/rdsk/c4t60060480000190103592533031453837d0s2′
ORA-27041: unable to open file
SVR4 Error: 5: I/O error
Additional information: 42
Additional information: 0
Additional information: 103997248

2) 磁盘有正确的所有权和权限（permissions）：

SQL> !ls -l /dev/rdsk/c4t60060480000190103592533031453837d0s2
lrwxrwxrwx 1 root root 67 Feb 22 20:53 /dev/rdsk/c4t60060480000190103592533031453837d0s2 ->

../../devices/scsi_vhci/ssd@g60060480000190103592533031453837:c,raw
SQL> ! ls -l /devices/scsi_vhci/ssd@g60060480000190103592533031453837:c,raw
crw-rw—- 1 oracle dba 118, 338 Mar 2 09:48

/devices/scsi_vhci/ssd@g60060480000190103592533031453837:c,raw

3) 同时，它能被ASM发现：

SQL> show parameter asm

NAME TYPE VALUE
———————————— ———– ——————————
asm_diskgroups string LOANIQ_REDO01DG01, LOANIQ_REDO
02DG01, LOANIQ_ARCHDG01, LOANI
Q_DATADG01
asm_diskstring string /dev/rdsk/*

asm_power_limit integer 1

SQL> select path from v$asm_disk;

PATH
——————————————————————————–
/dev/rdsk/c4t60060480000190103592533031453837d0s2

4) 而且使用dd能在OS级别访问磁盘：

SQL> !dd if=/dev/rdsk/c4t60060480000190103592533031453837d0s2 of=/dev/null count=100 bs=8192
100+0 records in
100+0 records out

原因
1)使用format命令，确认 “/dev/rdsk/c4t60060480000190103592533031453837d0s2” raw device/partitions 不是有效分区，因为它在引用“backup” 分区 (#2 以下)，包含OS 分区标签 (VTOC) & OS 元数据，同时在cylinder #0中启动:

# format
Searching for disks…done

c4t60060480000190103592533031453837d0: configured with capacity of 68.24GB
AVAILABLE DISK SELECTIONS:
0. c2t50060482D5300A28d0 <EMC-SYMMETRIX-5772 cyl 1 alt 2 hd 15 sec 128>
/pci@8,700000/lpfc@5/fp@0,0/ssd@w50060482d5300a28,0
1. c3t50060482D5300A07d0 <EMC-SYMMETRIX-5772 cyl 1 alt 2 hd 15 sec 128>
/pci@8,600000/lpfc@2/fp@0,0/ssd@w50060482d5300a07,0
2. c4t20000014C3739DB2d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
/scsi_vhci/ssd@g20000014c3739db2
3. c4t20000014C3739FBCd0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
/scsi_vhci/ssd@g20000014c3739fbc
4. c4t60060480000190103592533030463238d0 <EMC-SYMMETRIX-5772 cyl 37270 alt 2 hd 30 sec 128>
.
.
.
.
.
23. c4t60060480000190103592533031453837d0 <EMC-SYMMETRIX-5772 cyl 37270 alt 2 hd 30 sec 128>
/scsi_vhci/ssd@g60060480000190103592533031453837
Specify disk (enter its number): 23
selecting c4t60060480000190103592533031453837d0
[disk formatted]
Disk not labeled. Label it now? yes
FORMAT MENU:
disk – select a disk
type – select (define) a disk type
partition – select (define) a partition table
current – describe the current disk
format – format and analyze the disk
repair – repair a defective sector
label – write label to the disk
analyze – surface analysis
defect – defect list management
backup – search for backup labels
verify – read and display labels
save – save new disk/partition definitions
inquiry – show vendor, product and revision
volname – set 8-character volume name
!<cmd> – execute <cmd>, then return
quit
format> p
PARTITION MENU:
0 – change `0′ partition
1 – change `1′ partition
2 – change `2′ partition
3 – change `3′ partition
4 – change `4′ partition
5 – change `5′ partition
6 – change `6′ partition
7 – change `7’ partition
select – select a predefined table
modify – modify a predefined partition table
name – name the current table
print – display the current table
label – write partition map and label to the disk
!<cmd> – execute <cmd>, then return
quit
partition> p
Current partition table (original):
Total disk cylinders available: 37270 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 root wm 0 – 68 129.38MB (69/0/0) 264960
1 swap wu 69 – 137 129.38MB (69/0/0) 264960
2 backup wu 0 – 37269 68.24GB (37270/0/0) 143116800 <(== Incorrect
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 usr wm 138 – 37269 67.99GB (37132/0/0) 142586880
7 unassigned wm 0 0 (0/0/0) 0

partition> q

2) 普通0 “backup” 分区不是ASM的有效原始失败，因为它包含OS 分区标签和OS元数据，且在cylinder # 0中启动。

解决方案

使用正确的分区(e.g. #6) ==)>
“/dev/rdsk/c4t60060480000190103592533031453837d0s6”，磁盘组被成功创建：

# chown oracle:dba /dev/rdsk/c4t60060480000190103592533031453837d0s6

# chmod g+w /dev/rdsk/c4t60060480000190103592533031453837d0s6

SQL> !dd if=/dev/rdsk/c4t60060480000190103592533031453837d0s2 of=/dev/null count=100 bs=8192
100+0 records in
100+0 records out

SQL> create diskgroup testdg external redundancy disk ‘/dev/rdsk/c4t60060480000190103592533031453837d0s6’;

Diskgroup created.

Database has been forced to open with _allow_resetlogs_corruption and _corrupted_rollback_segments
Now we are trying to export all the data to recreate database, export fails with:
Connected to: Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
ORA-31626: job does not exist
ORA-31633: unable to create master table "SYS.SYS_EXPORT_SCHEMA_05"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPV$FT", line 871
ORA-01115: IO error reading block from file 1 (block # 68730)
ORA-01110: data file 1: '/pelican/PELICAN/system01.dbf'
ORA-27091: unable to queue I/O
ORA-27072: File I/O error
IBM AIX RISC System/6000 Error: 110: Media surface error
Additional information: 7
Additional information: 68729
Additional information: -1

ora10g4S@(/pelican/PELICAN)$ /orahome/ora10204s/bin/dbv file=system01.dbf feedback=100
DBVERIFY: Release 10.2.0.4.0 - Production on Wed Aug 14 12:50:05 2013
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = system01.dbf
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
.....................
DBV-00102: File I/O error on FILE (system01.dbf) during verification read operation (-2)

run
{
allocate channel d1 type disk;
backup check logical validate datafile 1;
release channel d1;
}


RMAN> backup check logical validate datafile 1;
Starting backup at 14-AUG-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=380 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/pelican/PELICAN/system01.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/14/2013 13:31:14
ORA-19501: read error on file "/pelican/PELICAN/system01.dbf", blockno 66817 (blocksize=8192)
ORA-27063: number of bytes read/written is incorrect
IBM AIX RISC System/6000 Error: 110: Media surface error
Additional information: -1
Additional information: 1048576

Reading a block of system datafile fails with IBM AIX RISC System/6000 Error: 110: Media surface err
Reading a block of system datafile fails with IBM AIX RISC System/6000 Error: 110: Media surface err

Action Plan:
=========
1. Shutdown the database with immediate option
2-Un-mount the FS that contain the Datafile
3-Run FSCK to fix the corrupted OS Blocks.
4-Re-mount the FS.
5. Restart the database

我知道老胡的工具JDUL 有几年了。这个工具一开始是老胡的私人项目，叫做jDUL。该项目从一开始就没有作为一个开源工具对外公开。在几年前我有幸被赠予了试用版本，运行它并查看它的功能。老胡对Oracle内部的知识和他的DUL工具版本令我印象深刻。

PRM-DUL可从不能被启动和有效报废的数据库实例中提取数据。它也可用作一种提取数据的快捷方法。我不太建议将它用于生产环境，因为你不太可能受到支持。但它作为一个崩溃恢复工具，对于某些人来说就是救命稻草。

老胡已经开了一个名为DUL救援的网站来完善PRM-DUL，即jDUL。在网站首页有PRM-DUL的详细介绍，包括所有支持功能的列表。它适用于Oracle 8,8i，9i和10g，可以重建字典，处理丢失的SYSTEM表空间，涵盖大多数的数据类型，恢复整个表空间，PL / SQL，支持大多数主要平台，链接（chained），迁移的行，支持trail NULL和分区表。 2.0版本即将包括IOT的LOB和RAW的。

如果你仔细阅读老胡的网站，就能找到对工具的详细说明，一个历史页面，和提供的服务细节。如果你需要租用这个工具，诗檀软件公司是首选的经销商。

网站上还有文本的PRM-DUL 入门，详细说明了如何使用PRM-DUL从Oracle数据库中提取数据。

你还可以得到一个演示版本，只要按照他的网站链接，并使用老胡的安全保护。你需要填写一个配置文件，并对你的数据库运行prm_core.jar，然后就能对任意一张表做10000行以内的dump。

我已经更新了我的Oracle Internals页面，添加了老胡文本的详细信息。

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

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

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

场景：

在数据库open的时候，删除控制文件和所有的redo文件。只有数据文件，shutdown abort 后。然后进行恢复。

2.操作步骤

1.在参数文件中加入隐藏强制开库参数：

startup nomount

alter system set “_allow_resetlogs_corruption”=true scope=spfile;

alter system set  undo_management=manual  scope=spfile;

–注意此处要设置回滚段为手动，否则就算打开了，实例还是可能会由于ORA-4194被PMON中止。

startup nomount force

2.此时由于丢失了reodo，所以使用resetlogs 方式创建控制文件

create controlfile reuse database “CRS”

resetlogs noarchivelog

logfile

group 1 ‘/home/oracle/crs/REDO01.LOG’ size 50M,

group 2 ‘/home/oracle/crs/REDO02.LOG’ size 50M,

group 3 ‘/home/oracle/crs/REDO03.LOG’ size 50M

datafile

‘/home/oracle/crs/SYSTEM01.DBF’,

‘/home/oracle/crs/SYSAUX01.DBF’,

‘/home/oracle/crs/UNDOTBS01.DBF’,

‘/home/oracle/crs/USERS01.DBF’,

‘/home/oracle/crs/EXAMPLE01.DBF’,

‘/home/oracle/crs/MYDB.DBF’

maxlogfiles 50

maxdatafiles 200

maxlogmembers  3;

3.尝试恢复并启动

recover database usibg backup controlfile until cancel;

alter database open resetlogs;

注意此时还可能出现：

ORA-16433

当出现2662的时候，那么就需要重建控制文件

此时使用alter database open resetlogs会出现：

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00600: internal error code, arguments: [2662], [0], [18045054], [0],

[18045088], [4194432], [], [], [], [], [], []

Process ID: 16029

Session ID: 1 Serial number: 3

ORA-600-2262错误：

由于数据文件的SCN 大于数据的SCN

4.处理ORA-2662并强制开库

考虑使用10015 来触发 adjust_scn，注意10g之后，adjust_scn默认是禁用的。必须在参数文件中设置_ALLOW_ERROR_SIMULATION=true:

startup nomount

alter system set “_ALLOW_ERROR_SIMULATION”=true

shutdown immediate

startup mount

recover database until cancel using backup controlfile;

–若出现ORA-16443重复步骤2，重新来过。

alter session set events ‘10015 trace name adjust_scn level 1’;

alter database open restetlogs;

adjust_scn的计算方式：

一般情况只用看第5个值，例如 18045088 ，每10亿 是一个等级。

精确计算是第4个值 *4 +第5个值。此处就是0*4+18045088 小于10亿，所以此处设置 1就可以了。

会根据直接递增数据库的SCN

参考：

Step by step to resolve ORA-600 4194 4193 4197 on database crash (文档 ID 1428786.1)

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

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

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

Oracle force open强制打开数据库的步骤：

1）在数据库关闭的时候备份数据库

如果在进行后续操作之前 ，你没备份的话，可能会由于其他操作而丢失数据库。

2）如果你的数据文件是不同时间点的，你最好使用和最老数据文件相近时间错的system表空间数据文件。这个会减少在开库节点bootstrap节点出现错误的机会。

3）编辑你的*init<sid>.ora文件来变更undo_management和增加2个参数：

• 将undo_management=auto改变到undo_management=manual
• 移除或注释掉 undo_tablespace 和undo_retention
• 增加_allow_resetlogs_corrution=true,_corrupted_rollback_segments=(由逗号组成的自动undo端的列表)

例如：

_corrupted_rollback_segments=(SYSSMU1$,SYSMU2$, SYSMU3$, SYSMU4$, SYSMU5$, SYSMU6$, SYSMU7$ SYSMU8$, SYSMU9$, SYSMU10$)

注意：在alert.log中会告诉你 哪些自动undo、端被使用。使用SYSS搜索。如果alter.log中没找到。在11g之前undo段的名称和上面例子有些不同，格式是_SYSMU_$，例如：
_SYSSMU1_3423929671$
_SYSSMU2_3471197032$
_SYSSMU3_1940572779$
_SYSSMU4_703930491$
_SYSSMU5_2293911943$
_SYSSMU6_2782670761$
_SYSSMU7_3176421677$
_SYSSMU8_1585569843$
_SYSSMU9_1242704454$
_SYSSMU10_777531512$

在UNIX中，你可以使用下列命令来得到undo段的名称：
strings system01.dbf|grep _SYSSMU | cut -d $ -f1 |sort -u

在得到输出后，每个字符串中加上$

•如果你有可用的参数文件，你可以创建一个pfile：
create pfile from spfile;

不要修改spfile

4）在SQL*PLUS中，startup mount，检查是否使用了正确的参数文件，所有的数据文件是online或system状态
show parameter corrupt
show parameter undo

select name,file#,status from v$datafile where status not in(‘ONLINE’,’SYSTEM’,);

如果有任何行返回的话，使用下面用来将文件在线：

alter database datafile file# online;

如果有文件在你试图online的时候状态变更为reover，那么继续进行步骤5.

5）

进行一个虚假的不完全恢复，并使用resetlogs打开数据库。

recover database until cancel;

或者

recover database usibg backup controlfile until cancel

当出现执行归档类型cancel，然后按回车

alter database open resetlogs;

6)如果数据库open，试图查询表，例如：

select sysdata from dual;

如果正常返回了行，那么可以查询其他表来确定数据库是足够正常的来执行导出。

当数据库打开了，你应该立即进行数据库导出。一旦你导出了数据库，可以从幸存的地方重建。这意味着删除所有数据文件和创建一个新的数据库。

已这种方式打开，但是不重建是不被Oracle支持的。任何延时的导出文件或任何试图使用system会导致无法挽回的损害。

注意：确认在init.ora中移除在步骤3中增加的参数。否则你使用这个init

.ora创建新的数据库可能会受到意外的损坏。

7）如果在步骤5open 的时候，实例崩溃了，检查trace文件。如果有trace文件，检查里面是否有ORA-00600[2662]或ORA-00600[4000]。这些错误也可能会在alert.log中。

简单描述一下这个ORACLE数据库恢复需求：

1. 10.2.0.3 数据库 windows平台
2. 主机断电导致数据库打不开
3. 加了隐藏参数打开了数据库
4. 但是system和sysaux上有坏块 导致数据查询不了
5. 把SYSAUX表空间OFFLINE掉了
6. 没有任何备份
7. exp导出报错，无法导出到重建库
8. 问题卡在exp上，数据库是可以打开的
9. 用户尝试了用 dul，但是他搞到的dul是过期的，所以用不了，他尝试修改系统时钟来让dul以为自己不过期，但是dul会读取文件头中的时间，这样瞒不了dul

EXP-00008: 遇到 ORACLE 错误 376
ORA-00376: 此时无法读取文件 3
ORA-01110: 数据文件 3:SYSAUX.DBF’
ORA-06512: 在 “SYS.DBMS_LOGMNR_LOGREP_DICT”, line 995

实际在该案例中SYSAUX不可用 ， 可以通过特殊的方法来彻底重建 SYSAUX表空间。

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

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

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

前几天帮一个北京的用户成功修复了一个900G的生产库无法打开的问题，该库的背景是一个900GB的重要生产库，但是之前几乎没有任何备份，且在instance crash的情况下丢失了当前undo表空间。 尝试打开数据库OPEN database时没有报什么ORA-600[4XXX] 如[4000]的内部错误，而是直接报：

ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: 
Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604
Instance terminated by USER, pid = 573600
ORA-1092 signalled during: ALTER DATABASE OPEN...

ORA-01157: cannot identify/lock data file 2 - see DBWR trace file
ORA-01110: data file 2:
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-01157: cannot identify/lock data file 2 - see DBWR trace file
ORA-01110: data file 2: 
ORA-27046: file size is not a multiple of logical block size
Additional information: 1
Additional information: 444166144
Additional information: 16384

即递归SQL错误+ORA-00376: file 2 cannot be read at this time+ORA-01110，相关的TRACE文件里也没有报出对应的错误。

ORA-00604+ORA-00376仍是因为bootstrap对象上的一些块有活动的事务，在读取这些数据块时为了满足一致性要去读UNDO表空间，但是UNDO表空间数据文件已经被OFFLINE DROP了。

此时首先一点要明确是那些bootstrap对象的数据块中有活动事务，在该场景中几个TRACE里都没有带出这些块的位置信息，这个时间做一个errorstack就可以了：

alter system set events '604 trace name errorstack level 3';

然后OPEN database并触发错误，由于ERRORSTACK会将发生错误时的Data block buffer打印在TRACE中，所以可以直接看到是哪些块有活跃事务，这是直接搜索ITL上LCK>0的记录，并定位相关lb/lock不是0的行记录即可。定位到这些记录后需要手动BBED修复这些数据块中的活跃事务。

在这个实际案例中，发现TRACE中有十几处有活跃事务，那么就是力气活要修复达十几个块了，完全修好这十几个块后OPEN DATABASE成功，接着加上”_corrupted_rollback_segments”参数并必要地修改数据字典从而把老的UNDO表空间彻底DROP掉，并创建新的UNDO表空间并切换之，之后CREATE TABLE等操作就可以顺利执行了。

后续可能还需要修复一些数据表，因为老的UNDO被DROP 掉，可能一些应用数据表上还需要依赖其读一致性数据，因此可能出现ORA-01555错误，可以通过加上对应undo rollback segment的”_corrupted_rollback_segments”来重建这些数据表，最后达到基本修复该数据库的目的。

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

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

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

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

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

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

查询被删除的数据，备份工具使用rman， 数据库备份到磁带上。
环境：
生产库 oracle10204 集群 + AIX5.3 +裸设备
测试库 oracle10204 单实例 + AIX5.3 +裸设备

问题描述：
测试库配置TSM连接到磁带上，直接通过磁带恢复到测试库，在恢复阶段,数据文件已成功restore到测试库上，
但archivelog没有restore过来，找不到磁带上的归档，数据库无法recover,由于备份保留天数65天，不存在归档被删除的可能;

后面尝试在没有recover的情况下通过修改参数_allow_resetlogs_corruption=true强制打开数据库，报ora-00704,ora–00604,ora– 01555的错， 然后通过设置event事件推进SCN值，又通过oradebug修改scn值，仍然报ora-00704,ora–00604,ora–01555的错，问题无 法解决。

此场景中一般需要用到 bbed修改数据块包括例如undo等数据块来绕过部分系统检测，故一般的技术人员无法操作，需要对oracle底层有所了解的工程师支持。

If you cannot recover data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.

APPLIES TO:

Oracle Database – Enterprise Edition – Version 9.0.1.0 and later
Information in this document applies to any platform.

SYMPTOMS

Redo log corruption errors in one of the redo log files while the database is open.

The redo log corruption could be any of these errors:

ORA-16038 log %s sequence# %s cannot be archived
ORA-354 corrupt redo log block header
ORA-353 log corruption near block <num> change <str >time <str>
ORA-367 checksum error in log file header
ORA-368 checksum error in redo log block

Dropping the redo logs is not possible as it may be needed for instance recovery.

The online redo logs may not be dropped if:

There are only two log groups
The corrupt redo log file belongs to the current group

CAUSE

There many possible reasons why a redo log file becomes corrupted.

SOLUTION

Clear the logfile having the problem:

Syntax:

eg: alter database clear logfile group 1;
alter database clear unarchived logfile group 1;

An online redo log file with status=CURRENT or status=ACTIVE in v$log may not be cleared and the error ORA-1624 will be produced. In this case, the database will have to be restored and recovered to a point in time to last available archivelog file.

Explanation:

If an online redo log file has been corrupted while the database is open, the ‘alter database clear logfile’ command can be used to clear the files without the database having to be shutdown.

The command erases all data in the specified logfile group.