プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

updatable snapshotでそしてC_MLOG# clusterが損害を受けたときにり現れる。

ORA-00600: internal error code, arguments: [2846], [1], [65535], [1], [8192], [8192]
kdcchk: error when looking at index with key:
col 0; len 16; (16): 43 4c 49 45 4e 54 5f 47 52 50 5f 45 4e 54 52 59
col 1; len 6; (6):44 41 44 4d 49 4e
kdcchk: index points to block 0x00401667 slot 0x0 chain length is 1
kdcchk: chain pointer 0x00401667.0 points to row which does not match!

Running ANALYZE CLUSTER C_MLOG# VALIDATE STRUCTURE causes:
ORA-01498: block check failure – see trace file
kdbchk: the amount of space used is not equal to block size
used=413 fsc=838 avsp=6823 dtl=8096
Block header dump: rdba: 0x00401667
Object id on Block? Y
seg/obj: 0x84 csc: 0x00.5ac50c6 itc: 2 flg: O typ: 1 – DATA
fsl: 0 fnx: 0x4016de ver: 0x01

 

ORACLE PRMは詩檀ソフト独立で開發したORACLEデータベースディザスターリカバリソフトウェアであり、グラフィカルインターフェースで使いやすいし、リカバリ効果も著しいなどのメリットを備えている。
どうかORACLE PRMをダウンロードして、試用してください。

http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

 ストレージがアクセス出来ないから、データベースがシャットダウンした。データベースを再起動したが、まともに起動出来ない。

データベースがmountできるが、起動出来ない。ファイル3(sysaux01.dbf)がこわれたと気づき、メディアリカバリが必要になって、noarhivelogモードを設定して、データベースバックアップがなければリカバリ出来ない。

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01172: recovery of thread 1 stuck at block 131977 of file 3
ORA-01151: use media recovery to recover block, restore backup if needed

SQL> recover datafile 3 ;
ORA-00283: recovery session canceled due to errors
ORA-12801: error signaled in parallel query server P003
ORA-10562: Error occurred while applying redo to data block (file# 3, block#
37292)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 3: ‘/opt/ora

[oracle@mlab2 ~]$ oerr ora 283
00283, 00000, “recovery session canceled due to errors”
// *Cause: An error during recovery was determined to be fatal enough to end
// the current recovery session.
// *Action: More specific messages will accompany this message. Refer to
// the other messages for the appropriate action.

allow 1 corruptionでこわれたブロックを無視してみたが、一部のブロックがスキップ出来ない。

SQL> recover database allow 1 corruption;
ORA-00283: recovery session canceled due to errors
ORA-10562: Error occurred while applying redo to data block (file# 3, block#
37292)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 3: ‘/opt/oracle/oradata/monitor/sysaux01.dbf’
ORA-10560: block type ‘0’
ORA-00600: internal error code, arguments: [4553], [2], [0], [], [], [], [], []

DBVツールでテストして、sysauxテーブルスペースに損害があれば、systemとほかのテーブルが正常に運用している。
sysaux01.dbfデータファイルでofflineする。まずはデータベースを起動して、データをロジックバックアップして、データベースを再構造して、ロジックバックアップでデータをリカバリする。

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01172: recovery of thread 1 stuck at block 131977 of file 3
ORA-01151: use media recovery to recover block, restore backup if needed

SQL> alter database datafile 3 offline drop;

Database altered.

SQL> alter database open;

Database altered.
データベースが起動した。

SYSAUXテーブルスペースがないので、EXPでエクスポートエクスポートしてもリポジトリごとにエクスポート出来ない。ユーザーによって、エクスポートも出来ない。故に、SYSAUXテーブルスペースに対して再構造して、EXPでデータをエクスポートできる。
Monitor1データベースを構造して、バックアップデータをインポートする。そして、Service_namesバラメタをmonitorに修正して、元のデータベースmonitorを閉める。

1：インスタンス名前ORACLE_SID=monitor1
2：該当するディレクトリを作成する /data2/monitor,adump,bdump,cdump,udump
3：コードファイルを作成する：
$ORACLE_HOME/bin/orapwd file=$ORACLE_HOME/dbs/orapwmonitor1 password=monitor1
4: バラメタファイルを修正する
5．今の任務インスタンスをセットする：
export ORACLE_SID=monitor1
6．Oracleに登録する：
sqlplus ‘/ as sysdba’
7．インスタンスを起動する：
SQL>startup nomount
8．スクリプトでデータベース、テーブルスペース、ユーザーなどを作成する。
9.IMPでデータをインポートする。

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

あるユーザーデータベーステーブルスペースtablespaceがOFFLINEしたら、またONLINE出来なくなったトラブルになった。alter tablespace ABC  onlineを操作したら、エラになる：

 

alter tablespace abc online; error at line 1: ORA-00600: internal error code, arguments : [6856],[0],[163] 600のargument 1 によって、そのエラはそのテーブルスペースのデータとundoデータの間に整合性がないからである。

Ora-600 Base	Functionality	Description
6000	ram/data ram/analyze ram/index	data, analyze command and index related activity

 

ここのundoデータは Deferred Undo Segmentと意味する；

あるDEFERRED ROLLBACKもSAVE Undo segmentsと呼ばれている。以下のメリットがある：

• それは突然OFFLINEされたテーブルスペースのトランザクションをUNDO/Rollbackに格納して、データをロールバックする。
• Segment_nameデータセグメントの名前はFILE#ファイル番号.Block#ブロック番号
• そのSEGMENT_TYPEはDEFERRED ROLLBACKである
• SYSTEMシステムテーブルに自動的に作成する。
• SYSユーザーに属している
• もしOFFLINEされたテーブルスペースを再びONLINEして、そして、undoデータが既に応用されて、自動的にDROPされた。

 

Deferred Undo Segmentsは特別なロールバックセグメントで、そのundoデータはundoテーブルスペースのデータ構造と違っていて、ある単純な手順ログ形式で存在している。そのSEGMENT_NAMEはFILE#.Block#で，そのセグメントヘッダの物理位置に該当する。

DBA_SEGMENTSから検索してみれば、SEGMENT_TYPE为DEFERRED ROLLBACKのデータセグメントとなる。一般的にSYSTEMテーブルスペースにある。いくつのテーブルスペースがOFFLINEされたら，SYSTEMテーブルスペースが急速に膨らんできた。調べてみれば、DEFERRED ROLLBACKバックアップセグメントがスペースを占めたからである。

 

詳しい内容は：https://www.askmac.cn/archives/deferred-rollback.html

 

ORA-00600: internal error code, arguments : [6856],[0],[163] に対する解決策は該当するdeferred rollbackロールバックデータセグメントをロールバックする。例えばbbedなどのコマンドでdeferred rollback segmentの rollback headerを処理する。

 

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

ORA-01122: database file 9 failed verification check
ORA-01110: data file 9: ‘/mac01.dbf’
ORA-01200: actual file size of 64000 is smaller than correct size of 65600

[oracle@oel8 ~]$ oerr ora 1122
01122, 00000, “database file %s failed verification check”
// *Cause: The information in this file is inconsistent with information
// from the control file. See accompanying message for reason.
// *Action: Make certain that the db files and control files are the correct
// files for this database.

[oracle@oel8 ~]$ oerr ora 1200
01200, 00000, “actual file size of %s is smaller than correct size of %s blocks”
// *Cause: The size of the file as returned by the operating system is smaller
// than the size of the file as indicated in the file header and the
// control file. Somehow the file has been truncated. Maybe it is the
// result of a half completed copy.
// *Action: Restore a good copy of the data file and do recovery as needed.

ORA-1110 、ORA-1122がエラが一緒に現れたとは該当する番号/名前のデータファイルにトラブルが起こったと意味する。例えば、ORA-1200はデータファイルが現れるとはデータファイル自身の大きさが予想した大きさより小さいである。
完全なバックアップとアーカイブを持っているデータベースに対して、RESTORE、REOCOVERでデータファイルをリカバリしてください。何の物理バックアップがないデータベースに対して、DDなどの方法でデータファイルの大きさを修正することによって、トラブルを避けられる。けど、これはせいぜいトラブルを避けるだけで、なくしたデータはリカバリできない。
dd if= of=<output/target datafile> count=< > bs=
Taking the above example (First we take an dd backup of datafile):
dd if=/u02/oradata/careware/users01.dbf of=/tmp/corr_temp.DBF count=64000 bs=8192
Now add 1600 zero blocks to datafile /u02/oradata/careware/users01.dbf
syntax
dd if=/dev/zero of= bs= seek= count=
In parameter seek specify the block from which it should append 1600 blocks.
In this case since the file contains 64000 (as indicated by the error message) so seek=64001 which is the next block from where the append will occur.
dd if=/dev/zero of=/u02/oradata/careware/users01.dbf bs=8192 seek=64001 count=1600 conv=notrunc
Now check the file size at OS level (It should be 65600 * 8192 + 8192)bytes
Do a ls -lrt to confirm the same.
Warning!! Once the database is open, export all the objects present in the tablespace containing the datafile. Please note that for any segment which had blocks that got
truncated at OS level, the export may fail if it tries to read data from the zero padded blocks. In that case it may be needed to apply a procedure to salvage good records.
Once export is complete, create a new tablespace and import the data.
Once it is confirmed that the data is good, drop the old tablespace.

ORA-00600[kcbnew_3] [a] [b] [c]はOracle 9i 9.2の後に導入された新たなブロックテストである。あるデータブロックを格納したcache bufferが再び利用される途中で、bufferの状態はstateで、データはtempあるいはundo。 Oracle一致性テストはbuffer headerのblock classと使用者へ伝えるblock classを比べて、相違なところを見つけた。

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

ORA-00600[kcbnew_3]に三つのバラメタはバーションによって、説明も変わる：
oracle 11.1とそのあと：
[a] メモリーループ内存循环計数器、実は初期のブロックの数
[b]コードインスタンスにそのcacheのobject idをアクセスする
[c] flagでそのbufferの特徴を定義する

oracle 10.1 和 10.2中：
[a] メモリーループ内存循环計数器、実は初期のブロックの数
[b] buffer class
[c] コードインスタンスにそのcacheのobject idをアクセスする

Oracle 9.2で：
[a] buffer class

ORA-600 [kcbnew_3]は コアメモリーbuffer管理に属している。影響は以下の通り：プロセスが失敗するあるいはSQLを実行できなくなるが二度のデータ損害を及ばない。

NB Bug Fixed Description
12391183 11.2.0.3,
12.1.0.0 ORA-600 [kcbnew_3] with “_db_fast_obj_truncate”=false
11902008 12.1.0.0 SMON may crash with ORA-00600 [kcbgcur_3] or ORA-600
[kcbnew_3] during Transaction recovery
9275027 11.2.0.2,
12.1.0.0 ORA-600 [kcbnew_3] can occur after TRUNCATE / DROP
9456964 11.2.0.2 OERI[kcbnew_3] after shrinking an IOT and reusing the blocks
freed by shrink
6970071 10.2.0.5,
11.2.0.1 ORA-600 [kcbnew_3] when recyclebin is active
6730125
10.2.0.5,
11.1.0.7,
11.2.0.1
OERI[kcbnew_3] during instance recovery
6079038 10.2.0.5,
11.2.0.1
Internal Errors from DML with error logging / batch errors
against partitioned table
* 6017420 10.2.0.4,
11.1.0.6 OERI[kcbo_link_q_1] / crash with fix for bug 5454831 installed
5558244 10.2.0.4,
11.1.0.6 OERI[kcbnew_3] can occur
5303237 11.1.0.6 ORA-600 [kcbgtcr_5] during create queue table
5218905 10.2.0.4,
11.1.0.6 OERI[kcbnew_3] when segment advisor has been used
+ 4430244 10.2.0.4,
11.1.0.6
Segment advisor can load blocks of dropped objects into buffer
cache (KCB OERI errors)
+ 5523799 Various OERI (eg kcbgtcr_12) using ASSM managed segments –
superceded
5718371 10.1.0.2 OERI[kcbgtcr_12] / [kcbnew_3] from concurrent CTAS and
DROP TABLE
* 3785200 9.2.0.6, 10.1.0.2 Corruption possible in automatic space managed segments
3085651 9.2.0.5, 10.1.0.2 Table corruption / OERI after TRUNCATE on ASSM table with
NESTED TABLE cols
2768278 9.2.0.4, 10.1.0.2 OERI[KCBNEW_3] possible after DROP of 8i segment in locally
managed tablespace
2747978 9.2.0.4, 10.1.0.2 OERI[KCBNEW_3] after resize of locally managed tablespace
2406802 9.2.0.2 OERI[kcbgtcr_3] / OERI[kcbcxx_1] after DROP TABLE in locally
managed tablespace
2414972 9.2.0.2 OERI:[kcbnew_3]/OERI:[kcbgtcr_3] after resize in LOCALLY
MANAGED tablespace

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

[oracle@mlab2 ~]$ oerr ora 201
00201, 00000, “control file version %s incompatible with ORACLE version %s”
// *Cause: The control file was created by incompatible software.
// *Action: Either restart with a compatible software release or use
// CREATE CONTROLFILE to create a new control file that is
// compatible with this release.

 

 

 

 

ORA-00201エラは COMPATIBLEバラメタ設定が誤ったかもしれない。COMPATIBLEバラメタについて :

COMPATIBLEバラメタはOracleがどんな内容をディスクに書き込むかを決められる。より低いCOMPATIBLE数値でデータベースを作成するときに、Oracleは最新のredoログフォーマットを使わない。Oracle 10gの場合であれば、compatibleを”9.2.0″と設定すれば、Oracleが作成したデータファイルは実際の9ir2バーションと同じようになる。こうすれば、10gのメリットやいろんな新機能を利用できる。，compatibleバラメタは影響を与えない。

FROM https://www.askmac.cn/archives/different-between-parameter-compatible-and-optimizer_features_enable.html

 

注意 違ったバーションのORACLE Softwareが作成したデータベースのCOMPATIBLE最小値に対する：

 

• For 11.2, the default value of the COMPATIBLE parameter is 11.2.0. The minimum value is 10.0.0.
• For 11.1, the default value of the COMPATIBLE parameter is 11.1.0. The minimum value is 10.0.0.
• For 10.2, the default value of the COMPATIBLE parameter is 10.2.0. The minimum value is 9.2.0.
• For 10.1, the default value of the COMPATIBLE parameter is 10.0.0. The minimum value is 9.2.0.
• For 9.2, the default value of the COMPATIBLE parameter is 8.1.0. The range of values is between 8.1.0 to the current release.

 

 

ORA-00206: error in writing (block 3, # blocks 1) of control file
ORA-00202: control file: ‘/h24oradat/ccdb_dbs/shccdb/shccdb/control01.ctl’
ORA-27072: File I/O error
IBM AIX RISC System/6000 Error: 5: I/O error
Additional information: 8
Additional information: 3

 

[oracle@mlab2 ~]$ oerr ora 206
00206, 00000, “error in writing (block %s, # blocks %s) of control file”
// *Cause: A disk I/O failure was detected on writing the control file.
// *Action: Check if the disk is online, if it is not, bring it online and try
// a warm start again. If it is online, then you need to
// recover the disk.

 

 

[oracle@mlab2 ~]$ oerr ora 27072
27072, 00000, “File I/O error”
// *Cause: read/write/readv/writev system call returned error, additional
// information indicates starting block number of I/O
// *Action: check errno

当访问控制文件出现错误时都可能出现ORA-00202错误：

 

[oracle@mlab2 ~]$ oerr ora 202
00202, 00000, “control file: ‘%s’”
// *Cause: This message reports the name file involved in other messages.
// *Action: See associated error messages for a description of the problem.

[oracle@mlab2 ~]$ oerr ora 210
00210, 00000, “cannot open the specified control file”
// *Cause: Cannot open the control file.
// *Action: Check to make sure the control file exists and is not locked by
// some other program.

 

[oracle@mlab2 ~]$ oerr ora 221
00221, 00000, “error on write to control file”
// *Cause: An error occurred when writing to one or more of the control files.
// *Action: See accompanying messages.

以上のエラインスタンスはコントロールファイルをアクセスときにAIX I/O errorが現れて、アクセス失敗した。

 

 

コントロールファイルがこわれた場合に対して：

 

• コントロールファイルにブロックがこわれたORA-00207 “control files are not for the same database“
• ORA-00600: internal error code, arguments: [kccpb_sanity_check_2]
• ora-00221
• ora-00210

 

コントロールファイルを再構造する。

 

ORACLEデータベースを正常にオープンできない場合やマウントできない場合、データベースが損傷した場合等にオラクルデータベースファイル(～.dbf)を直接読み込むことによって、ファイルから有効なデータを抽出するツールです。

Oracleデータベース救済-リカバリ-運用とメンテナンス-オプティマイザサビースは詩檀ソフトに訪ねてください。

自分でうまくいかないときに詩檀ソフトORACLEデータベースリカバリチームに助けを求めてください。

携帯番号： +86 13764045638    メール：service@parnassusdata.com

ある企業に一番大事な業務は誤操作で、複数の業務テーブルスペースがDROPされた。これらの業務テーブルスペースには300あまりのテーブルを格納している。それにどんなバックアップもない。

詩檀ソフトエンジニアが現場に赴いて、トラブルについての詳しい情報を理解する：

1. データベースはアーカイブモードだが、有効なバックアップがない。
2. 複数のテーブルスペースがDROPされたが、DROP TABLESPACEがinlucding datafilesを指定していないから、関連するデータファイルがまだ削除されていない。
3. flashback queryでOBJ$、TAB$などのテーブルを検索して、DROP TABLESPACEに削除されたディクショナリー情報を獲得するときに、ORA-01555エラが現れる。これはUNDOデータも期限切りと意味している。flashback queryで、DROP TABLESPACEについてのディクショナリーデータをリカバリできない。
4. bbedでdbfのディクショナリーテーブルを観察して、OBJ$、TAB$などのディクショナリーテーブルが削除されたわずかのデータしか残っていない。特別なリカバリで削除されたデータ行をリカバリするという方法でディクショナリーデータをリカバリできない。

以上のシーン情報で、DROP TABLESPACEしたあとでflashback queryあるいはbbedなどの手段で該当するデータディクショナリーをリカバリできないから、データディクショナリーをリカバリすることでdrop tablespace操作をロールバックするには不可能である。

この場合に対して、有効な物理あるいはロジックバックアップもない場合に、ORACLE PRM-DULを使わないとリカバリできない。

 

注意：このような有効なバックアップがない場合に対して、100%にデータをリカバリできることを保障できない。データをリカバリする比率はデータスペースがOracleに回収された後に再び使われるかあるいは上書きされるかということで決める。DROP TABLESPACE操作自身には一連の再帰操作を含んでいるから。つまり、そのテーブルスペースにあるすべてのデータテーブルを再帰的にDROPして、すべてのデータテーブルを完全にDROPしたこそホントのDROP TABLESPACEが始められる。持続期間’で回収したスペースが再び利用され、上書きされる。

 

ディクショナリーデータは既になくしたから、ORACLE PRM-DULに非ディクショナリーモード(NON-SYSTEM TABLESPACE)で作業を進行する。つまり、DROP TABLESPACEされたデータファイルのSEGMENT HEADERあるいはSEGMENT EXTENTSデータを直にスキャンする。これらのデータにはテーブルの行データを含んでいるが、TABLE_NAMEあるいはCOLUMN_NAMEなどのメータデータを含んでいない。非ディクショナリーモードで抽出したテーブルのテーブルの名前はOBJ+で、そのDATA_OBJECT_ID形式は、例えばOBJ9999、そのテーブルがDATA_OBJECT_ID=9999のデータテーブルと意味している。故に、非ディクショナリーモードでUNLOADされたテーブルはそのデータはどこのテーブルに属しているかを人工的に識別する必要がある。

 

PRM-DUL非ディクショナリーモードで、二つのスキャン方法がある：SEGMENT HEADERあるいはEXTENTモード。テーブルスペースが何のデータファイルもなくしていない上にテーブルヘッダもなくしていない場合に、SEGMENT HEADERモードを使ってください。PRM-DULはテーブルヘッダモードでDATABASEとTABLES;をSCANして、190を超えたテーブルを見つけ出した。一部の業務テーブルをリカバリできたが、SEGMENT HEADERモードで五つ肝心な業務テーブルを見つけ出せない。

 

これは五つのテーブルのSEGMENT HEADERがもうDROP TABLESPACEされてこわれたと意味している。これはDROP TABLESPACEプロセスで一部の回収スペースが上書きされたと意味する。SEGMENT HEADERモードで必要なテーブルを見つけ出せないから、後はEXTENTモードで実行する。

 

EXTENTモードはデータファイルにあるすべての行のデータブロックを見つけ出すから、SEGMENT HEADERを必要としていない。故に、EXTENTモードで大量なデータを獲得できる。スキャンした範囲がより広くなるので、リカバリする必要としていないデータテーブルもより多く現れるから、前の方法よりずっと時間をかかる。

某企业核心业务数据库由于误操作导致多个业务表空间被意外DROP，这些业务表空间存放了300多张表，且无任何形式的有效物理、逻辑备份。

诗檀软件工程师赴用户现场。 具体了解了本问题的细节信息：

1. 数据库采用归档模式，但当时未找到有效的物理或逻辑备份。
2. 多个表空间被DROP ，但因为DROP TABLESPACE没有指定inlucding datafiles，故相关数据文件仍保留在文件系统中未被删除。
3. 尝试使用flashback query闪回查询OBJ$、TAB$等表以便获取被DROP TABLESPACE所删除的字典信息时出现ORA-01555错误，说明相关UNDO数据已过期，无法通过闪回查询挽救DROP TABLESPACE相关的字典数据。
4. 尝试使用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

ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件，其具有全程图形化界面、简单高效等特点。

欢迎下载使用ORACLE PRM。 下载地址：http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

PRM用户使用手册。http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%20v0.3.pdf

 

 

ORA-01122: database file 9 failed verification check
ORA-01110: data file 9: '/mac01.dbf'
ORA-01200: actual file size of 64000 is smaller than correct size of 65600

[oracle@oel8 ~]$ oerr ora 1122
01122, 00000, "database file %s failed verification check"
// *Cause:  The information in this file is inconsistent with information
//         from the control file. See accompanying message for reason.
// *Action: Make certain that the db files and control files are the correct
//         files for this database.

[oracle@oel8 ~]$ oerr ora 1200
01200, 00000, "actual file size of %s is smaller than correct size of %s blocks"
// *Cause:  The size of the file as returned by the operating system is smaller
//         than the size of the file as indicated in the file header and the
//         control file. Somehow the file has been truncated. Maybe it is the
//         result of a half completed copy.
// *Action: Restore a good copy of the data file and do recovery as needed.

 

 

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

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

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

 

 

ORA-1110 、ORA-1122错误一起出现一般意味着对应号码/名字的数据文件存在问题， 而最底下的错误号一般能揭示该问题的本质，例如ORA-1200是说明数据文件的实际大小小于预期的大小。

针对有完整备份和归档的数据库可以尝试常规RESTORE、REOCOVER的方法来恢复该数据文件，而对于没哟任何形式物理备份的数据库而言，可以尝试使用DD等手段来修改数据文件大小，并绕过该问题。 注意这样做只是绕过问题而已，可能丢失的数据仍会丢失，并不会因此而恢复。

dd if= of=<output/target datafile> count=< > bs=
Taking the above example (First we take an dd backup of datafile):
dd if=/u02/oradata/careware/users01.dbf of=/tmp/corr_temp.DBF count=64000 bs=8192
Now add 1600 zero blocks to datafile /u02/oradata/careware/users01.dbf
syntax
dd if=/dev/zero of= bs= seek= count=
In parameter seek specify the block from which it should append 1600 blocks.
In this case since the file contains 64000 (as indicated by the error message) so seek=64001 which is the next block from where the append will occur.
dd if=/dev/zero of=/u02/oradata/careware/users01.dbf bs=8192 seek=64001 count=1600 conv=notrunc
Now check the file size at OS level (It should be 65600 * 8192 + 8192)bytes
Do a ls -lrt  to confirm the same.
Warning!! Once the database is open, export all the objects present in the tablespace containing the datafile. Please note that for any segment which had blocks that got
truncated at OS level, the export may fail if it tries to read data from the zero padded blocks. In that case it may be needed to apply a procedure to salvage good records.
Once export is complete, create a new tablespace and import the data.
Once it is confirmed that the data is good, drop the old tablespace.

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

Parnassusdata Software Database Recovery Team

Service Hotline:  +86 13764045638 E-mail: service@parnassusdata.com

 

ORACLE PRM-DUL Download: http://zcdn.parnassusdata.com/DUL5108.zip

 

오라클 DUL 네덜란드, 오라클 지원, 버나드 반 Duijnen 개발에서 회사 내에서 오라클 데이터베이스 복구 도구입니다 :
DUL 오라클의 제품이 아닙니다
DUL는 오라클에 의해 지원되는 제품이 아닙니다
DUL 엄격하게 내부 용 오라클 지원 영업 지원 부서로 제한됩니다
DUL 그렇지 않으면 DUL를 사용하는 경우에도 자격이 없습니다, ​​먼저 PS 오라클의 표준 서비스는 DUL 사용할 수 있습니다 구입해야 외국에서 오라클의 내부 승인을 거쳐야 사용
DUL 엄격하게 제어되는 이유 중 하나는 오라클 소스 코드의 사용이며, 엄밀히 제어 되어야만

약 DUL 9 처음부터 DUL 소프트웨어 시간 잠금 DUL의 사용을 제한하기 때문에주기 위해 버나드 반 Duijnen 외부 세계는 그가 정기적으로 DUL가 (C 언어를 기반으로 DUL)를 다른 플랫폼에서 컴파일 주기적으로 ORACLE 내부 DUL에 업로드 덧붙였다 작업 공간 (기반 stbeehive 공간), 오라클 지원은 다운로드 내부 VPN 로그인을 사용할 수 있습니다. 즉, 잠금 날짜의 버전을 출시 년 10 월 1 일 bernard.van.duijnen처럼 30 일 11월 1일 DUL 간단하게 읽을 수 없습니다, ​​기본적으로 비효율적 인 OS 시간에 다음이 버전, 그래서 OS를 변경할 수있는 시간입니다 그것은 쓸모가 없다. 오라클의 데이터 파일 레인은 또한 현재 시간을 기록하기 때문에, 그래서 DUL 시간에 데이터 파일을 읽습니다. 불가능한 일반 사용자가 DUL와 시간을 변경하십시오.
DUL 더 HP-UX의 버전을 해당 있도록 bernard.van.duijnen 학생들이 DUL 플랫폼 HP-UX를 제공하지 않기 때문에주의.
너무 나이가 현재의 10g, 11g, 12C 데이터베이스에서 사용되는 오라클 DUL 버전 한편 이전 버전은 기본적으로 작동하지 않습니다. 미국에서 사용 DUL이 엄격하게 중국에서 제어, 다음 기본 오라클 ACS 고급 고객 서비스 부서가 사용이됩니다, 오라클 ACS 현장 서비스 가격이 여전히 비싸다 구입할 수 있습니다.
부록은 오라클 ACS 프리젠 테이션 문서를 제공 DUL 서비스 (물론 원래 사이트 서비스를, 그렇지 않으면 당신은 심지어 현장 서비스 ACS 고급 서비스를 살 수없는, 더 비싼, 사용자가 매년 PS 표준 서비스를 구입 한 경우) :

 

 

 

다음 다운로드 링크 DUL 10이지만 때문에 로크의 때문에 정기적 실패.

 

DUL FOR LINUX platform (updated to PRM-DUL)

DUL FOR Windows platform (updated to PRM-DUL)

시 탄 소프트웨어 (기업 맥클레인이있는) DUL 유사한 제품, PRM-DUL을 개발했다. 그래픽 인터페이스 (GUI)와 DataBridge의 도입에 기초 DUL 및 기타 기능 (데이터 착륙하지 않고는 SQLLDR 직접 대상 DBLINK로 데이터베이스에 동일 파일 전송된다) PRM-DUL가 작성되기 때문에 당신은 모든 플랫폼을 교차 할 수 있도록, JAVA 기반 HP-UX 등.

 

 

PRM-DUL 무료 버전 다운로드 :
http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip
PRM-DUL 설명서 http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89% 8B % E5 % 86 % 8C %의 20v0.3.pdf

데이터베이스는 데이터 테이블의 더 만 이상의 행이 직접 무료 PRM-DUL을 사용할 수 있도록 작은 경우 PRM-DUL은 무료 버전의 기본 각 테이블은 데이터의 만 행을 추출 할 수 있습니다. 데이터베이스가 크고 데이터가 매우 중요한 경우에, 당신은 데이터베이스에 대한 PRM-DUL, Enterprise 버전 PRM-DUL의 라이센스 소프트웨어 라이센스를 Enterprise Edition을 구입 고려할 수, 라이센스 가격은 (17 포함 7,500위안입니다 %의 부가 가치세).
한편 PRM-DUL 또한 일부 무료 라이센스를 제공합니다 :
무료 및 오픈 여러 PRM-DUL Enterprise Edition의 라이센스 키

사용 DUL 후 오라클 데이터베이스 복구 경우가 여전히 작동하는 경우에, 당신은 서비스 복구의 채택을 고려할 수 있습니다 :
테이블은 ASM 디스크 그룹 수없는 MOUNT이 좋아하는, 잘못된 드롭, TRUNCATE는, 삭제 등을하고, 데이터베이스를 열 수 없습니다 :시 탄 소프트웨어는 포함 오라클 복원의 거의 모든 장면을 제공합니다.

 

그들은 당신이 찾을 수 있습니다 처리 할 수없는 경우시 탄 Oracle 데이터베이스 복구 소프트웨어 전문 팀 구성원은 회복 할 수 있도록하기!
탄시 데이터베이스 복구 소프트웨어 전문 팀

대체 전화 번호 : +86 13764045638 이메일 : service@parnassusdata.com

 

Current recovery options 
restore and rollforward
export/import
use SQL*Loader to re-load the data
(parallel) create table as select (PCTS)
Transportable Tablespace


Diagnostic tools
orapatch
BBED (block browser/editor) 
Undocumented parameters
_corrupted_rollback_segments, _allow_resetlogs_corruption  etc... 


No alternatives in the case of loss of SYSTEM tablespace datafile(s) 
The database must be in ‘reasonably’ good condition or else recovery is not possible (even with the undocumented parameters!) 
Patching is very ‘cumbersome’ and is not always guaranteed to work
Certain corruptions are beyond patching
Bottom line - loss of data!!


The most common problem is the fact that customer’s backup strategy does not match their business needs. 
Eg.  Customer takes weekly backups of the database, but in the event of a restore their business need is to be up and running within (say) 10 hours.   This is not feasible since the ‘rollforward’ of one week’s worth of archive logs would (probably) take more than 10 hours!!


Building a cloned database exporting data, and importing into the recovery database.
Building a cloned database and using Transportable Tablespaces for recovery. 


DUL could be a possible solution
DUL (?) - Bernard says ‘Life is DUL without it!’
bottom line - salvage as much data as possible



DUL is intended to retrieve data that cannot be retrieved otherwise
It is NOT an alternative for restore/rollforward, EXP, SQL*Plus etc. 
It is meant to be a last resort, not for normal production usage
Note: There are logical consistency issues with the data retrieved


DUL should not be used where data can be salvaged using one of the supported mechanisms (restore/rollforward, exp/imp etc…)


Doesn’t need the database or the instance to be open
Does not use recovery, archive logs etc…
It doesn’t care about data consistency
more tolerant to data corruptions
Does not require the SYTEM tablespace to recover


DUL is a utility that can unload data from “badly damaged” databases. 
DUL will scan a database file, recognize table header blocks, access extent information, and read all rows 
Creates a SQL*Loader or Export formatted output
matching SQL*Loader control file is also generated




DUL version 3 (still in testing!) supports IMP loadable dump file.  More on DUL version 3 later...



Read the Oracle data dictionary if the SYSTEM tablespace files are available 
Analyze all rows to determine 
number of columns, column datatypes and column lengths


If the SYSTEM tablespace datafiles are not available DUL does its own analysis, more on this later...



DUL can handle all row types
normal rows, migrated rows, chained rows, multiple extents, clustered tables, etc. 
The utility runs completely unattended, minimal manual intervention is needed.
Cross platform unloading is supported



DUL can open other datafile(s) if there are extents in that datafile(s).
Although DUL can handle it, LONG RAW presents a problem for SQL*Loader - we’ll talk about this shortly...

For cross platform unloading the configuration parameters within "init.dul" will have to be modified to match those of the original platform and O/S rather than the platform from which the unload is being done.
DUL unloads in the physical order of the columns. The cluster key columns are always unloaded first.


Recovers data directly from Oracle data files 
the Database (RDBMS) is bypassed 
Does dirty reads, it assumes that every transaction is committed
Does not check if media recovery has been done
DATABASE CORRUPT - BLOCKS OK 
Support for Locally Managed Tablespaces


DUL does not require that media recovery be done.
Since DUL reads the data directly from datafiles,  it  reads data that is committed as well as uncommitted.  Therefore the data that is salvaged by DUL can potentially be logically corrupt.  It is upto the DBA and/or the Application programmers to validate the data.


The database can be copied from a different operating system than the DUL-host 
Supports all database constructs: 
row chaining, row migration, hash/index clusters, longs, raws, rowids, dates, numbers, multiple free list groups, segment high water mark, NULLS, trailing NULL columns etc...
DUL should work with all versions 6 , 7, 8 and 9
Enhanced to support 9i functionality. 


DUL has been tested with versions from 6.0.36 up to 7.2.2. The old block header layout (pre 6.0.27.2) also works! 


The main new features are: 
  Support for Oracle version 6, 7, 8 and 9 
  Support for Automatic Space Managed Segments 
  New bootstrap procedure: just use ‘bootstrap;’.   No more 
       dictv6,7 or 8.ddl files 
  LOB are supported in SQL*Loader mode only 
  (Sub)Partitioned tables can be unloaded 
  Unload a single (Sub)Partition 
  Improved the scan tables 
  The timestamp and interval datatypes 
  Stricter checking of negative numbers 
  (Compressed) Index Organized Tables be unloaded 
  Very strict checking of row status flags 
  Unload index to see what rows you are missing 
  Objects, nested tables and varrays are not supported (internal  
        preparation for varray support ) 


DUL has been tested with versions from 6.0.36 up to 9.0.1. The old block header layout (pre 6.0.27.2) also works! 
DuL 92 is mostly bug fixes:
The latest version is DUL92. The main new features are: 
     fix for problem with startup when db_block_size = 16K 
     fix for scan database and Automatic Space Managed Segments 
     fix for block type errors high block types; new max is 51 
     Support for Automatic Space Managed Segments 
     phase zero of new unformat command 
     internal preparation for varray support 
     Bug fix in the stricter checking of negative numbers 
     Bug fix in the unloading of clustered tables 


The database can be corrupted, but an individual data block used must be 100% correct
blocks are checked to make sure that they are not corrupt and belong to the correct segment
DUL can and will only unload table/cluster data. 
it will not dump triggers, constraints, stored procedures nor create scripts for tables or views
But the data dictionary tables describing these can be unloaded


Note: If during an unload a bad block is encountered, an error message is printed in the loader file and to standard output. Unloading will continue with the next row or block. 


MLSLABELS (trusted oracle) are not supported
No special support for multi byte character sets
DUL can unload (LONG) RAWs, but there is no way to reload these 1-to-1 with SQL*Loader
SQL*Loader cannot be used to load  LONG RAW data.



DUL can unload (long) raws, but there is no way to reload these 1-to-1 with SQL*Loader. There is no suitable format in SQL*Loader
to preserve all long raws. Use the export mode instead or write a Pro*C program to load the data.



DUL and large files (files > 2GB) 
Starting from DUL version 8.0.6.7 DUL will report if it can do 32-bit i/o(no large file support) or 64-bit i/o with large file suport.
DUL support for raw devices
DUL will work on raw devices. But DUL is not raw device aware.


Raw Devices:
On some platforms we skip the first part of the raw device. DUL does not automatically skip this extra part. The easiest way to configure DUL in this is the optional extra offset in the control file. These extra offsets that I am aware of are 4K on AIX raw devices and 64K for Dec Unix. 
DUL does not use the size as stored in the file header. So DUL will read the whole raw device including the unused part at the end.


There are two configuration files for DUL
init.dul
control.dul
Configuration parameters are platform specific.


If you do decide that DUL is the only way to go, then here is how to go about configuring and using DUL.  Good Luck!!


Contains parameters to help DUL understand the format of the database files 
Has information on  
DUL cache size
Details of header layout
Oracle block size
Output file format
Sql*Loader format and record size. 
etc...


Sample init.dul file for Solaris looks like:
# The dul cache must be big enough to hold all entries from the Dictionary dollar tables.
dc_columns = 200000
dc_tables = 20000
dc_objects = 20000
dc_users = 40
# OS specific parameters
big_endian_flag = true
dba_file_bits = 6
align_filler = 1
db_leading_offset = 1
# Database specific parameters
db_block_size = 2048
# Sql*Loader format parameters
ldr_enclose_char = "
ldr_phys_rec_size = 81


Used to translate the file numbers to file names
Each entry on a separate line, first the file_number then the data_file_name
A third optional field is an extra positive or negative byte offset, that will be added to all fseek() operations for that datafile.


This optional field makes it possible to skip over the extra block for AIX on raw devices or to unload from fragments of a datafile.

The control file would look like : 
  1  /u04/bugmnt/tar9569610.6/gs/sysgs.dbf                                
  2  /u04/bugmnt/tar9569610.6/gs/rbs.dbf                                  
  3  /u04/bugmnt/tar9569610.6/gs/user.dbf         
  4  /u04/bugmnt/tar9569610.6/gs/index.dbf                   
  5  /u04/bugmnt/tar9569610.6/gs/test.dbf
When the database is up and running v$dbfile contains the above information.



# sample init.dul configuration parameters
# these must be big enough for the database in question
# the cache must hold all entries from the dollar tables.
dc_columns = 200000
dc_tables = 10000
dc_objects = 10000
dc_users = 40

# OS specific parameters
osd_big_endian_flag = false
osd_dba_file_bits = 6
osd_c_struct_alignment = 32
osd_file_leader_size = 1

# database parameters
db_block_size = 8192

# loader format definitions
LDR_ENCLOSE_CHAR = "
LDR_PHYS_REC_SIZE = 81

#ADD PARAMETERS
export_mode=true  # still needed with dul9
compatible=9


# AIX version 7 example with one file on raw device
   1 /usr/oracle/dbs/system.dbf
   8 /dev/rdsk/data.dbf 4096

   # Oracle8 example with a datafile split in multiple parts, each part smaller than 2GB
   0  1 /fs1/oradata/PMS/system.dbf
   1  2 /tmp/huge_file_part1 startblock 1 endblock 1000000
   1  2 /tmp/huge_file_part2 startblock 1000001 endblock 2000000
   1  2 /mnt3/huge_file_part3 startblock 2000001 endblock 2550000



Case1: Data dictionary usable


Case 1:  
SYSTEM tablespace available
Case 2:  
Using DUL without the SYSTEM tablespace


Straight forward method  	                     
Execute ‘dul’ from os prompt then ‘bootstrap’ from DUL
Don’t need to know about the application tables structure, column types etc...


DUL> unload table hr.emp_trunc;

DUL: Error: No entry in OBJ$ for "EMP_TRUNC" type = 2
DUL: Error: Could not resolve object id
DUL: Error: Missing dictionary information, cannot unload table
DUL> scan database;

Case2: Without the SYSTEM tablespace 

Needs an in depth knowledge about the application and the application tables
The unloaded data does not have any value, if you do not know from which table it came from
Column types can be guessed by DUL but table and column names are lost
The guessed column types can be wrong


Note: 
1) Any old SYSTEM tablespace from the same database but weeks old can be of great help!
2) If you recreate the tables (from the original CREATE TABLE scripts) then the structural information of a "lost" table can be matched to the "seen" tables scanned with two SQL*Plus scripts. (fill.sql andgetlost.sql)

Steps to follow: 
1.configure DUL for the target database. This means creating a correct init.dul and control.dul. 
2.SCAN DATABASE; : scan the database for extents and segments. 
3.SCAN TABLES; : scan the found segments for rows. 
4.SCAN EXTENTS; : scan the found extents. 
5.Identify the lost tables from the output of step 3. 
6.UNLOAD the identified tables. 



DUL will not find “last” columns that only contain NULL's
Trailing NULL columns are not stored in the database
Tables that have been dropped can be seen
When a table is dropped, the description is removed from the data dictionary only
Tables without rows will go unnoticed


During startup DUL goes through the following steps: 
the parameter file "init.dul" is processed
the DUL control file (default "control.dul") is scanned
try to load dumps of the USER$, OBJ$, TAB$ and COL$ if available into DUL's data dictionary cache
try to load seg.dat and col.dat. 
accept DDL-statements or run the DDL script specified as first argument



DUL version 3, 8, 9 and 92 are available. 

http://www-sup.nl.oracle.com/dul/index.html

 exceutables, user’s and configutration guide
Available on most common platforms
Solaris
AIX
NT
HP etc...


DUL version 9 is currently available on: 
aix
alphavms62
att3000
dcosx
hp.tar.bin
osf1
rm4000.tar.bin   
sco
sequen
sunos
sunsol2
vaxvms55
vaxvms61
win95
winnt 

DuL with Dictionary


 Configure init.dul and control.dul
 Load DuL
 Bootstrap
 Unload database, user, table


DuL without Dictionary


 Configure init.dul and control.dul (control will include
   the datafiles needing to be recovered only).
 Load DuL
 alter session set use_scanned_extent_map = true
 scan database
 scan tables
 Using the found table definitions construct an uload 
   statement:
unload table dul2.emp (EMPLOYEE_ID number(22), FIRST_NAME varchar2(20), 
LAST_NAME varchar2(25), 
EMAIL varchar2(25),PHONE_NUMBER varchar2(20), HIRE_DATE date, JOB_ID varchar2 (10),
SALARY number(22), COMMISSION_PCT number(22),MANAGER_ID number(22), 
DEPARTMENT_ID number(22))
storage (dataobjno 28200);