Oracle7 8 8i 9i 10g 11g のOracleブロック損害に対応する

2014/12/20 by admin Leave a Comment

この文はOracleに壊れたブロックに対して、どうやって対応できるかを検討する文である。このあと、主な対応法が紹介するので、完全に読みきった前に、勝手に手を打たないでください。

ファイル履歴レコード

この文に掲載したすべてのSQL文もSQL*Plusに適用する。あるいはSYSDBAとして。リンクする時に、server manager（

Orale7/8.0）にも適用する。（例えば“connect / as sysdba”或“connect internal”）

サマリー

この文は壊れたメモリーブロック問題について、検討していない。

注意：もし起動するときに、ORA-600[17XXX]タイプエラが出たら、地方のサポートセンタに連絡してください。

Doc 106638.1-このファイルはお客様に見せられないが、経験豊かな技術員がその中の一部なステップを提供してもいい。

この文で、いろんなタイプなミスを紹介した、ほかのいろんなところにもこの文を使える。大事なのは以下壊れたブロックについての情報を知るべきだと思う：

壊れたブロックを含むファイルの番号（file number）

この文で&.AFNと言う。

壊れたブロックを含む名

この文で&.FILENAMEと言う。

（ファイル番号を知ったが、ファイルなを知らない場合に、V$DATAFILEでファイル名を獲得する：

SELECT name FROM v$tempfile

WHERE file#=(&AFN – &DB_FILES_value);

)

ファイル番号がOracle8iのV$DATAFILEに映していない、&AFNがDB_FILESバラメタ値に超えた場合に、そのファイルが一時的なファイルかもしれない。この場合に以下の問合せでファイル名を見つけ出せる：

SELECT name FROM v$tempfile

WHERE file#=(&AFN – &DB_FILES_value);

)

ファイルの中のブロック番号

この文で&.BLと言う。

影響を受けたブロックのテーブルスペース番号と名を含んで、この文で“&TSN”と“&TABLESPACE_NAMEと言う。

これについての情報を知らない場合に、以下の問合せで見つけ出してください：

SELECT ts# “TSN” FROM v$datafile WHERE file#=&AFN;

SELECT tablespace_name FROM dba_data_files WHERE file_id=&AFN;

テーブルスペースの壊れたブロックのサイズ

この文で“&TS_BLOCK_SIZE”と言う

Oracle9i+に対して、以下の問合せで該当するブロックサイズを確かめてください。：

SELECT block_size FROM dba_tablespaces WHERE tablespace_name =

(SELECT tablespace_name FROM dba_data_files WHERE file_id=&AFN);

Oracle7・8.0及び8.1：

データベースにすべてのテーブルスペースが使っている同じなブロックサイズ。これらのバーションに対して、コマンド”SHOW PARAMETER DB_BLOCK_SIZE”で返した数値は“ &TS_BLOCK_SIZE”とする

例えば、ORA-1578エラ：

ORA-01578: ORACLE data block corrupted (file # 7, block # 12698)

ORA-01110: data file 22: ‘/oracle1/oradata/V816/oradata/V816/users01.dbf’

では：

&AFN は”22″ (エラORA-1110から部分的に獲得する)

&RFN は “7” (エラORA-1578の”file #”から部分的に獲得する)

&BL は “12698” (エラORA-1578の”block #”から部分的に獲得する)

&FILENAME 为 ‘/oracle1/oradata/V816/oradata/V816/users01.dbf’ &TSN 及びほかの情報は、前述したＳＱＬ文から獲得する

そのほかのエラにたいしては（ORA-600、ORA-1498など）Oracle　supportあるいは関連するエラを含む文から獲得してください。

一部なエラに対して、例えば（ORA-1410“invalid ROWID、ORA-12899“value too large for columnなど）、壊れたファイル/ブロックについての詳しい情報を得ていないため、Document 869305.1 を使ってください。

壊れたブロックの対応策：

ブロックが壊れた原因はさまざま：

ハードウェアが壊れた
Osトラブル
Oracleトラブル
“UNRECOVERABLE”あるいは“NOLOGGING”操作を実行したデータベースをリカバリする（この場合にORA-1578エラになるかもしれない、以下の通り）

Oracleエラが発生したタイミングは最初に起きたミスのタイミングと比べて、大分遅くなるかもしれない。

壊れたブロックが現れた時に、すぐその場で根本的な原因を解き明かす訳にはいかない。それに多くの場合に、一番大事なのはデータベースを再起動して運用させることである。よって、この文は壊れたブロックトラブルを解決するステップを紹介する。詳しい内容は以下の通り：

（１）トラブルが起きたブロックのエクステントを確認する。これらのトラブルは一時的なものかあるいは持続的なものかを確かめてください。

エクステントが予想外に大きく拡張した場合やトラブルが不安定な場合に、大事なのは原因を判明する（ハードウェアをテストするなど）。これはとっても大切なことである。ハードウェアがトラブルに落ちた場合に、システムをリカバリするのは何の意味もないから。

（２）問題を起こすようなハードウェアを変更する

（３）データベース目標が影響を受けたことを確かめる。

（４）最適なデータベースリカバリオプションを選択する。

以上のステップに対して、証拠を収集してやるべきことを詳しく記録する。

NOLOGGINGあるいはUNRECOVERABLE操作でブロックを壊した。

もし誰かがNOLOGGINGあるいはUNRECOVERABLE操作を実行したまたその目標を含んだファイルをリカバリしたとしたら、　　　　NOLOGGING操作に影響を受けたデータブロックは壊れたブロックに標識され、このブロックをアクセスするときにORA-1578エラが出てくる。Oracle8iで、このようなエラも出てくる：ORA-26040 エラ“ORA-26040: Data block was loaded using the NOLOGGING option　　　　　　　　（データブロックがNOLOGGINGオプションでロードする）。この時に、原因は一目瞭然である。その前のバーションでそのエラ情報を追加していないので、もし壊れたブロックは実行したNOLOGGING操作のデータファイルをリカバリしたから現れたとしたら、この文で第三章の内容を利用してください。だが以下の問題を注意してください：

リカバリ操作がNOLOGGING操作の影響を受けたデータをリカバリできない。
ブロック内部的なデータを救えない。

壊れたブロック問題のエクステントを確かめる：

ブロックが壊れた場合に、エラ情報を完全に記す必要がある。そして、関連したすべての問題を解き明かすために、そのインスタンスのアラームログとファイルを確認してください。まず、これらのステップは大事なので、壊れたのは一つブロックか、UNRECOVERABLE操作で起こしたエラか、あるいはもっとひどい問題なのかを確かめられる。

DBVERIFYで影響を受けたファイルをスキャンするという方法も悪くないが、これでほかのブロックが壊れていたか否かを確かめて、エクステントを確認できる。DBVERIFYの詳しい情報はDocument 35512.1を参考してください。

壊れたファイル/ブロックリストが作成したら、次のようなステップでどんな処置をとるべきかを確認できる。

証拠

完全なレコード及びトラブルが起きたアプリケーションの詳しい情報。

アラームログが初めて(FIRST)の警告が出すタイミングから、トラブルになるまで数時間の内容

アラームログのすべてのトランクファイル

最近レコードが直面したあらゆるoｓトラブル

レコードが特別な機能を使用しているか否か、例えば：

今のバックアップ位置を覚えてください（日付き、タイプなど）

データベースは今ARCHIVELOGモードにあるか否か例えば：SQLPlus（或 Server Manager）中运行“ARCHIVE LOG LIST”*

（２）壊れそうなハードウェアを変更してください

一般的に、ブロックが壊れたのはハードウェアがトラブルに落ちたからである。壊れそうなハードウェアを見つけたら、すぐに修復してください。また、リカバリする前に、独立したディスクシステムには、リカバリするためのスペースを確保してください。

以下のステップで、データファイルを移動できる：

移動したいファイルがアウトラインの状態を確保してください。あるいはデータベースインスタンスがmount状態を確保してください。
このデータファイルを物理的に新しい位置にリカバリ（あるいはコピ）してください。
このファイルの新しい位置をOracleに知らせてください。

例えば：ALTER DATABASE RENAME FILE ‘/oldlocation/myfile.dbf’

TO ‘/newlocation/myfile.dbf’;

（一時的なファイルを再命名できない。一時的なファイルを削除した後で新たな位置に改めて作成してください）

４.関連するデータファイル/テーブルスペースをオンラインしてください（データベースを起動した状態で）。

重要情報：

いくつのエラが存在している（NOLOGGING操作によるものじゃない）。

影響を受けたファイルがあるOSインタフェースにエラになる。

エラは一時的で不安定なものの場合。

では、根本的なトラブルを解決しないかぎりあるいはほかのディスクスペースを用意しないかぎり、どんな操作を実行しようと、何の意味もない。

ハードウェアアフタサービスに連絡して、全面的にシステムをテストしてください。そしてOracle　supportにエラについてのすべての詳しい情報を知らせてください。

ハードウェアテストが失敗した場合に、ハードウェア自身には問題が起こったと示している。けどハードウェアテストが成功したとはハードウェアがトラブルに落ちていないと言えない。ハードウェアテスト成功したが、トラブルに落ちたこともよくある。

もし、特別なIOオプションを使用した場合に、（direct IO、async IOのようなオプション）、これらのオプションがまた新たなトラブルにならないように、それを停止してください。

（３）どんなものが影響を受けるでしょうか

リカバリ策を作成する前に、どんなものが影響を受けたことを確かめたほうがいい。壊れたブロックは再作成したものでよくある。例えば、５行だけのテーブルにあるブロックがこわれた場合に、リカバリするより、削除して再作成するのはずっと速い。

壊れた各ブロックに対して、以下の情報を収集してください。これを実行するステップは以下の通り：

针对每次坏块需记录的信息
	绝对文件	相关文件	块编号			段
初始错误	号	号		表空间	段类型	所有者.名	相关对象	恢复选项
	&AFN	&RFN	&BL			称

最初から報告してきたエラ、例えば：ORA-1578/ORA-1110、ORA-600及びすべてのバラメタ

絶対ファイル番号、関連するファイル番号及びブロック番号

ファイル番号とブロック番号はエラで現れる。あるいはOracle　supportから提供する。

Oracle8/8i/9i/10で、一般的に絶対ファイル番号と関連するファイル番号が同じようになる。もし異なった場合に（特にOracle7から移した場合）、ぜひ正確な&AFNと&RFN番号を獲得してください。さもなければ、リカバリしたのは誤った目標という状況になるかもしれない！

ORA-1578は関連するファイル番号を報告する。絶対ファイル番号は後のORA-1110に映す。ORA-600に対して、絶対ファイル番号を知らせる。

以下の問合せでデータベースのデータファイルの絶対ファイル番号と関連するファイル番号を知らせる。

SELECT tablespace_name, file_id “AFN”, relative_fno “RFN” FROM dba_data_files;

Oracle8i/9i/10で：

Oracle8についての説明以外、、Oracle8iから一時的なファイルを持っているから、以下の問合せはデータベースにいる一時的なファイルの絶対ファイル番号、関連するファイル番号を映す：

SELECT tablespace_name, file_id+value “AFN”, relative_fno “RFN” FROM dba_temp_files, v$parameter

WHERE name=’db_files’;

Oracle7で、絶対ファイル番号と関連するファイル番号が同じようになる。

セグメントタイプ、所有者及び関連ファイル番号

壊れたブロックの絶対ファイル番号&AFNとブロック番号&Bが示された場合に、以下の問合せは目標のセグメントタイプ、所有者及び名前を示す。データベースが起動した後でこの問合せが使える：

SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents

WHERE file_id = &AFN

and &BL between block_id AND block_id + blocks – 1

;

壊れたブロックが一時的なファイルにあるとしたら、前の問合せが何のデータも返さない。

一時的なファイルに対して、セグメントタイプはTEMPORARY。

もし問合せが行を返さないと、壊れたブロックはロカールマネジテーブルスペース(Locally Managed Tablespace, LMT)のセグメントヘッダにあるかもしれない。この場合に、問合せはアラームログで壊れたブロックメッセージが作成し、問合せも失敗しない、この場合に、以下の問合せを使ってください：

SELECT owner, segment_name, segment_type, partition_name FROM dba_segments

WHERE header_file = &AFN and header_block = &BL

;

セグメントタイプで分類された関連する目標と可能なリカバリオプション：

関連する目標と使用可能なオプションはSEGMENT_TYPEに頼っている。よく見られるセグメントタイプ、問合せ及び使えるリカバリオプションは以下の通り：

CACHE

もしセグメントタイプはCACHEであれば、再び正確なＳＱＬ文とバラメタを入力したことを確かめてください。

また同じ結果が得たとしたら、Oracle　supportに連絡して、自分の知る限りの情報を知らせてください。

オプション：

データベースをリカバリする必要があるかもしれない

CLUSTER

セグメントタイプはCLUSTERの場合に、どんなテーブルを含めているかを確かめる必要がある。

例えば：

SELECT owner, table_name FROM dba_tables

WHERE owner=’&OWNER‘

AND cluster_name=’&SEGMENT_NAME‘

;

オプション：

所有者はSYSの場合、Oracle　supportに連絡して、すべての詳しい情報を知らせてください。

データベースをリカバリする必要があるかもしれない。

非データディクショナリーCLUSTERに対して、可能なオプションはリカバリを含んている。

あるいはCLUSTERにあるすべてのデータをリカバリする。

そしてCLUSTERとすべてのテーブルを再作成する。

CLUSTERにはいくつかのテーブルを含むかもしれないので、やる前に、CLUSTERにある各テーブルの情報を収集してください。

INDEX PARTITION

もしセグメントタイプはINDEX PARTITIONの場合に、名前と所有者を記録して、どんなPARTITIONが影響を受けるかを確かめてください：

SELECT partition_name FROM dba_extents WHERE file_id = &AFN

AND &BL BETWEEN block_id AND block_id + blocks – 1

;

そしてINDEXセグメントのステップで、以下の操作を実行してください。

オプション：

以下の文を使って、INDEX PARTITIONを再作成できる：

ALTER INDEX xxx REBUILD PARTITION ppp;

INDEX

もしセグメントタイプはINDEX 、そして所有者はSYS の場合にOracle　supportに連絡して、すべての詳しい情報を知らせてください。

非データディクショナリーINDEX あるいはINDEX PARTITIONに対して、インディクスがどこのテーブルにあるかを確かめてください。

例えば：

SELECT table_owner, table_name FROM dba_indexes

WHERE owner=’&OWNER‘

AND index_name=’&SEGMENT_NAME‘

;

Eg: SELECT owner, constraint_name, constraint_type, table_name FROM dba_constraints

WHERE owner=’&TABLE_OWNER‘

AND constraint_name=’&INDEX_NAME‘

;

CONSTRAINT_TYPEの可能値は以下のようなものを含んでいる：

P インディクスが主キー制約を支持する

U インディクスが唯一制約を支持する

もしインディクスが主キー制約を支持すれば、主キーが外部キー制約に利用されたかを確認してください。

例えば：

SELECT owner, constraint_name, constraint_type, table_name FROM dba_constraints

WHERE r_owner=’&TABLE_OWNER‘

AND r_constraint_name=’&INDEX_NAME‘

;

オプション：

所有者はSYSの場合、Oracle　supportに連絡して、すべての詳しい情報を知らせてください。

データベースをリカバリする必要があるかもしれない。

非ディクショナリーインディクスに対して、可能なオプションはリカバリ

あるいはインディクスを再作成する

ROLLBACK

もしセグメントタイプはROLLBACKの場合に、Oracle　supportに連絡してください。ROLLBACKセグメントにブロックが壊れたとしたら、特別な処置が必要としている。

オプション

データベースをリカバリする必要があるかも知れない。

TYPE2 UNDO

TYPE2 UNDOはシステム管理のUNDOセグメントで、これはROLLBACKセグメントの特別形式で、これらのセグメントにある壊れたブロックは特別な処置が必要としている。

オプション：

データベースをリカバリする必要がある

TABLE PARTITION

セグメントタイプはTABLE PARTITIONの場合に、名前と所有者を記して、どれのPARTITIONが影響を受けたかを確かめてください：

SELECT partition_name FROM dba_extents WHERE file_id = &AFN

AND &BL BETWEEN block_id AND block_id + blocks – 1

;

そしてテーブルセグメントのステップで以下の操作を実行する。

オプション：

もしすべての壊れたブロックが同じPARTITIONに属している場合に、空っぽなテーブルで壊れたブロックを含むPARTITIONを代われる。これでアプリケーションが実行し続ける（）,そして空っぽなテーブルから損害を受けていないデータを抽出できる。

ほかのオプションについて、次のTABLEオプションを参考してください。

TABLE

所有者はSYSの場合、Oracle　supportに連絡して、すべての詳しい情報を知らせてください。

データベースをリカバリする必要があるかもしれない。

非ディクショナリーTABLEあるいはTABLE PARTITIONについて、テーブルにどんなインディクスがあるかを確認してください。

例えば：

SELECT owner, index_name, index_type FROM dba_indexes

WHERE table_owner=’&OWNER‘

AND table_name=’&SEGMENT_NAME‘

;

そしてテーブルに主キーが存在しているか否かを確認してください：

Eg: SELECT owner, constraint_name, constraint_type, table_name FROM dba_constraints

WHERE owner=’&OWNER‘

AND table_name=’&SEGMENT_NAME‘ AND constraint_type=’P’

;

主なキーが存在している場合に：

例えば：

SELECT owner, constraint_name, constraint_type, table_name

FROM dba_constraints WHERE r_owner=’&OWNER‘

AND r_constraint_name=’&CONSTRAINT_NAME‘

;

オプション：

所有者はSYSの場合、Oracle　supportに連絡して、すべての詳しい情報を知らせてください。

データベースをリカバリする必要があるかもしれない。

非ディクショナリーテーブルに対して、可能なオプションは：

リカバリ

あるいは　テーブルのデータを救う。そしてテーブルを再作成する。

あるいは　壊れたブロックを無視する。（例えば：　　　　　　で問題が起きたブロックをスキップする。

インディクス組織テーブル（IOT）

IOTテーブルで壊れたブロックはテーブルあるいはPARTITIONテーブルの形式で処理する。

唯一の例外はＰＫが壊れた場合である。

IOTテーブルのＰＫはテーブル自身であるから、削除も再作成もできない。

オプション：

所有者はSYSの場合、Oracle　supportに連絡して、すべての詳しい情報を知らせてください。

データベースをリカバリする必要があるかもしれない。

非ディクショナリーテーブルに対して、可能なオプションは：

リカバリ

あるいは　テーブルのデータを救う。そしてテーブルを再作成する。

あるいは　壊れたブロックを無視する。

LOBINDEX

LOBはどのテーブルに属している：

SELECT table_name, column_name FROM dba_lobs

WHERE owner=’&OWNER‘

AND index_name=’&SEGMENT_NAME‘;

所有者はSYSの場合、Oracle　supportに連絡して、すべての詳しい情報を知らせてください。

LOBインディクスを再作成できないから、そのトラブルを影響を受けたテーブルでLOB列の壊れたブロックとして対応する。

TABLE部分中のSQL文で壊れた LOBインディクスのテーブルのインディクスと限り情報を含んでいて、またここに帰る。

オプション：

所有者はSYSの場合、Oracle　supportに連絡して、すべての詳しい情報を知らせてください。

データベースをリカバリする必要があるかもしれない。

非ディクショナリーテーブルに対して、可能なオプションは：

リカバリ

あるいは　テーブルのデータを救う。そしてテーブルを再作成する。

一般的には、壊れたブロックを無視できない。

LOBSEGMENT

LOBはどこのテーブルに属しているかを確かめる：

例えば：

SELECT table_name, column_name FROM dba_lobs

WHERE owner=’&OWNER‘

AND segment_name=’&SEGMENT_NAME‘;

所有者はSYSの場合、Oracle　supportに連絡して、すべての詳しい情報を知らせてください。

データベースをリカバリする必要があるかもしれない。

非ディクショナリーテーブルに対して、

TABLE部分中のSQL文で壊れたLOBインディクスのテーブルのインディクスを含む情報を獲得して、またここに返って、影響を受けた行の詳しい情報を検索する。

報告で壊れたLOBデータがどこの行に属していることをいわないから、壊れたLOBの具体的行を検索するのは難しいかもしれない。

一般的に、トラブルが起きたアプリケーションログ、SQL_TRACE及びセッションの10046トランクファイルを参考して、あるいは事件1578 trace name errorstack level 3をセットして、今のＳＱＬ/バイナリ/行を標識するには力になれるかどうかを検討してください。

例えば：

ALTER SYSTEM SET EVENTS ‘1578 trace name errorstack level 3’;

そして、アプリケーションがこのトラブルを発生させて、トランクファイルを追及する。

もし何の手がかりもない場合に、ＰＬＳＱＬブロックを作成してください。一行ずつ問題があるテーブルをスキャンして、LOB列データを抽出する。スキャンはトラブルが起きたまでずっと続く。この方法は時間をかかるが、最終的には壊れた部分を見つけ出せる。

例えば：

set serverout on

exec dbms_output.enable(100000); declare

error_1578 exception;

pragma exception_init(error_1578,-1578); n number;

cnt number:=0; badcnt number:=0; begin

for cursor_lob in

(select rowid r, &LOB_COLUMN_NAME L from &OWNER..&TABLE_NAME) loop

begin n:=dbms_lob.instr(cursor_lob.L,hextoraw(‘AA25889911’),1,999999) ;

exception

when error_1578 then

dbms_output.put_line(‘Got ORA-1578 reading LOB at ‘||cursor_lob.R);

badcnt:=badcnt+1; end;

cnt:=cnt+1; end loop;

dbms_output.put_line(‘Scanned ‘||cnt||’ rows – saw ‘||badcnt||’ errors’);

end;

/

壊れたLOBブロックに古いバーションが示される（一貫性を守るために）、それにブロックは再利用されていない。この場合に、すべてのテーブルの行もアクセスできるが、リサイクルされて再利用される場合に、LOB列をインサート/アップロードできなくなる。

オプション：

所有者はSYSの場合、Oracle　supportに連絡して、すべての詳しい情報を知らせてください。

データベースをリカバリする必要があるかもしれない。

非ディクショナリーテーブルに対して、可能なオプションは：

リカバリ

あるいは　テーブルのデータを救う。そしてテーブルを再作成する。

あるいは　壊れたブロックを無視する。

TEMPORARY

もしセグメントタイプはTEMPORARYとしたら、壊れたブロックが永久的な目標に影響を及ばない。トラブルが起きたテーブルスペースはTEMPORARYテーブルスペースに使っているか否かを確認してください。

SELECT count(*) FROM dba_users

WHERE temporary_tablespace=’&TABLESPACE_NAME‘

;

オプション：

の場合に、新たな一時テーブルスペースを作成できて、すべてのユーザーをこのテーブルスペースに切り替えて、そしてトラブルが起きたテーブルスペースを削除する。

もし、一時テーブルスペースではない場合に、そのブロックは再び読み取らない。そして次に使う時に再びフォーマッティングされる。根本的な問題を解決されていない場合に、同じようなトラブルが起こらないはずである。

一般的にはリカバリ必要としていないが、ディスクが問題になったかもしれないので、それにテーブルスペースに使えるデータをまだ残っているから、データベースに影響を受けたファイルに対してリカバリしたほうがいい。

ほかのセグメントタイプ

もし返ってきたセグメントタイプは以上のどんなタイプにも属していない場合に、Oracle　supportに連絡して、今まで知っているすべての詳しい情報を提供してください。

行が返っていない

壊れたブロックを含むエクステントがなければ、問合せで使っているバラメタをもう一度チェックしてください。ファイル番号もブロック番号も正確で、DBA_EXTENTSでどれにも属していない場合に、以下の操作を実行してください：

再び関連するファイルをチェックして、一時的ファイルか否かを確認してください。一時ファイルのファイル番号はデータベースバラメタDB_FILESによるもので、このバラメタにどんな変更を加えようと、報告の絶対ファイル番号を変える。

DBA_EXTENTSはローカル管理テーブルスペースでローカルスペース管理するためのブロックを含んでいない。

もしデータベースが問合せ文を運用するタイミングとトラブルが起きたタイミングと違っているとしたら、トラブルが」起きた目標が削除されたかもしれないので、DBA_EXTENTSに対する問合せが何の行も映さない。

もし調査しているのトラブルはDBVERRFYによって報告されるとしたら、DBVは何に属しているかを問わずに、すべてのブロックを検索するから、壊れたブロックがデータファイルにあるが、誰にも使われていない。

オプション：

使われていないOracleブロックのトラブルが無視できるが、いざそのブロックを使いたくなった場合にOracleは新たなブロクインメージを作成する（フォーマッティング）から、このブロックでどんなトラブルも読み取らない。

もしそのブロックがスペース管理ブロックと疑わっているなら、　　　パッケージを使ってください：

exec DBMS_SPACE_ADMIN.TABLESPACE_VERIFY(‘&TABLESPACE_NAME‘);

以上のコマンドは不整合なところをトランクファイルに書き込むが、致命的なトラブルが起こったら、以下のようなトラブルが返される。

ORA-03216: Tablespace/Segment Verification cannot proceed

ビットマップスペース管理ブロックで起こるトラブルは以下のコマンドで修復できる。

exec DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPS(‘&TABLESPACE_NAME‘);

証拠：

各壊れたブロックに対して、その原因を調べたいなら、以下のような物理証拠を収集するのもいい策とおもう：

壊れたブロック及びブロックhexをダンプする

UNIXで

exec DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPS(‘&TABLESPACE_NAME‘);

例えば：

BL=1224：

dd if=ts11.dbf bs=4k skip=1223 count=3 of=1223_1225.dd

VMS で：

DUMP/BLOCKS=(start:XXXX,end:YYYY)/out=dump.out &FILENAME

ＸＸＸＸはオペレーションシステムブロック番号（512バイトブロックで）。この数値を計算したいとすれば、報告のブロック番号で“&TS_BLOCK_SIZE/512”に加算してください。

ARCHIVELOGモードで、コピにトラブルが起きた時間前後のアクチブロゴのセキュリティコピはトラブルを報告する数時間前のコピを格納してください。前のデータファイルインメージとredoレコードは原因を探し出せる。（一般的にＤＢＶはトラブルがファイルバックアップコピにあるか否かを確認するときに使われる）。理想的な状況はトラブルが起こった前のデータファイルバックアップインメージを獲得する、そしてそのタイミングから初めてのエラ報告が返った時点までのすべてのredoレコード。

トラブルブロックのOracleダンプを獲得する

ALTER SYSTEM DUMP DATAFILE ‘&FILENAME’ BLOCK &BL

;

４）リカバリオプションを選ぶ

今、理想的なリカバリオプションは影響された目標に左右される。前の（３）部分で、影響を受けた目標が使用可能なオプションを紹介したが、選択する実際のリカバリ方法は多数の方法を含むことができる。

リカバリ操作が必要としているかいなか？

トラブルはTEMPORARYテーブルスペースに起きたやどんなデータベース目標のブロックにも位置していない場合には何の操作もいらない。トラブルが起きたテーブルスペースをほかのストレージマシンに格納すればいい。「アラーム」を参考してください。

完全にリカバリできるか？

完全にリカバリしたいとすれば、以下の条件を満たさればならない：

-データベースはARCHIVELOGモードにある（“ARCHIVE LOG LIST”コマンドはArchivelogモードを映す

-影響されたファイルの完全なバックアップを持っている。けど、ある場合に、壊れたブロックも既に存在していたが、長い間に見つからない。もし、最新のバックアップにはまだ壊れたブロックを含んでいれば、保存ログが必要になる。もっと早いバックアップを利用できる。

（一般的にはDBV START= / END=オプションでバックアップファイルのリカバリコピのある特定したブロックが壊れていたか否かを確認する）

バックアップ時間から今まですべてのアクチブログも使用可能

すべてのオンラインログが使用可能で、無傷である。

トラブルはNOLOGGINGを実行したリカバリよるものではない

以上の条件を満たせば、最優先なのは完全にリカバリする

以下のようなことを注意してください

（a）トランザクションロールバックが目標にはブロックが壊れたことを気づいたとしたら、rollbackセグメント自身ではなく、undo操作が諦められたかもしれない。この場合に、リカバリ完成したあと、インディクス/データの整合性をチェックして再構造する。

(b)もしリカバリしたいファイルは前回バックアップしたあとのNOLOGGING操作データの場合にデータファイルあるいはデータベースリカバリを運用している途中で、これらのブロックは壊れたブロックと標識される。ある場合に、これは状況を一層ひどくさせる。

もしデータベースリカバリを実行した後も壊れたブロックがまだ残っているとすれば、これはすべてのバックアップに壊れたブロックを含んでいることを意味する。この場合に、ほかのリカバリオプションを選んでください。

「(4A)完全にリカバリ」を参考して、完全リカバリのステップを理解してください。目標から何のデータを抽出する必要がなくなった場合に、目標を削除して、再作成できるでしょうか。

PARTITION …

テーブルパーティションに対して、影響を受けたパーティションだけを削除すればいい。例えば：ALTER TABLE …DROP PARTITION …

壊れたブロックがセグメントヘッダに影響を与えたあるいはパーティションヘッダがアウトラインの状態で、DROP PARTITIONが失敗するかもしれない。対応策はまずそれを同じ定義のテーブルに変更して、削除する。

例えば：ALTER TABLE ..EXCHANGE PARTITION ..WITH TABLE ..;

一番よく見られる状況は再構造できる目標はインディクスの場合。詳しい情報は「(4B)インディクスを再構造する」を参考してください。

どんなセグメントに対しても、壊れたブロックの絶対ファイル番号とブロック番号を持っていれば、以下の方法を試してください：

set long 64000

select dbms_metadata.get_ddl(segment_type, segment_name, owner) FROM dba_extents

WHERE file_id=&AFN

AND　BL BETWEEN block_id AND block_id + blocks -1;

データを再作成する前にデータを救う必要があるか？

もしトラブルは定期的にアップロードする肝心なアプリテーブルにあるとしたら、できるだけ多くのデータをリカバリしてください、そしてそのテーブルを再作成する。

　詳しい情報は(4C)テーブルデータに対する緊急処置

目前の壊れたブロックを無視できるか？

在某些情况下，最直接的选项可能就是忽略坏块，并阻止应用程序对它进行访问。

ある場合に、一番やりやすいオプションは壊れたブロックを無視して、アプリがそれをアクセスすることも阻止する。

詳しい情報は「(4D)壊れたブロックを無視する」に参考してください。

最后的选项

最後の選択肢

以下のような選択が実行できるか？「データベースあるいはテーブルスペースをより早い時点へリカバリする（タイミング修復）」、「壊れたブロック前にcold backupをリカバリする」および「既存するファイルをエクステントする」についての詳しい情報は(4E)最後の選択肢に参考してください。

(4A)完全にリカバリする

データベースはARCHIVELOGモードで、そして影響を受けていないファイルのバックアップを持っていれば、リカバリするのが一番いい方法である。必ずトラブルを解決できるとは限らないが、大多数の壊れたブロックによるトラブルを解決できる。再び同じような問題が起こったら、また別の方法に選んでください。

もし運用しているのはOracle9i（あるいはもっと高いバーション）であれば、RMAN BLOCKRECOVERコマンドでブロックレベルのリカバリを実行できる。

もし運用しているのはより古いバーションであれば、データファイルリカバリ（ほかのデータベース部分を持続的に使用できる）あるいはデータベースリカバリ（データベースを閉めてください）。

　もし、使っているのはOracle 11g（あるいはもっと高いバーション）であれば、Data Recovery Advisor（データリカバリガイド）を使ってください。

ブロックレベルリカバリ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Oracle9iから、RMANが一つのブロックをリカバリできる。同時にデータベースのほかの部分もアクセスできる（データファイルのほかのブロックも含む）。ブロックレベルリカバリはせいぜいブロックを今のタイミングまでしかリカバリできない。

ば、必ずRMANでバックアップする必要があるとは限らない。例えば：実際の状況で、ファイル6のブロック30でORA-1578エラが起こったら、メディアトラブルでブロックを壊れたかもしれないので、もし完全なコールドバックアップがあれば、

“…/RESTORE/filename.dbf”。にリカバリしてください。

仮にすべてのアクチブログもあって（ディフォルト位置にある）、RMANで以下のコマンドでリカバリできる：

rman nocatalog connect target

catalog datafilecopy ‘…/RESTORE/filename.dbf’; run {blockrecover datafile 6 block 30;}

この操作は登録したデータファイルバックアップインメージとアクチブログでブロックレベルのリカバリを実行する。トラブルがあったブロックだけを現在の時点にリカバリする。

RMAN BLOCKRECOVERコマンドや制約について、関連するファイルに参考してください。

データファイルリカバリ

~~~~~~~~~~~~~~~~~~

データファイルリカバリは以下のステップを含んでいる。多数のファイルを持っていれば、各ファイルにこれらのステップを繰り返してください。後のデータベースリカバリを参考してください。データベースがOPEN あるいはMOUNTED状態で、これらのステップも全部利用できる。

影響を受けたデータファイルをアウトラインさせてください

例えば：ALTER DATABASE DATAFILE ‘name_of_file’ OFFLINE;

ファイルを安全な場所へコピする（バックアップが壊れることを防ぐため）

ファイルの最新なバックアップを安全ディスクへリカバリする。

DBVERIFYでリカバリしたファイルに壊れたブロックが残っているかをチェックする

DBVERIFYについての詳しい情報をDocument 35512.1に参考してください

仮にリカバリしたファイルは無傷とする。では、データファイルを再命名して、新たな位置に格納する（元の位置じゃなければ）

例えば：ALTER DATABASE RENAME FILE ‘old_name’ TO ‘new_name’;

データファイルをリカバリする例えば：RECOVER DATAFILE ‘name_of_file’;

データファイルをオンラインさせる

例えば：ALTER DATABASE DATAFILE ‘name_of_file’ ONLINE;

データベースリカバリ

~~~~~~~~~~~~~~~~~

一般的にはデータベースリカバリが以下のステップを含んている：

データベースを閉じる（immediate あるいはabortを使う）

リカバリしたいファイルを安全な場所へコピ

バックアップファイルを無傷なディスクにリカバリする。コントロールファイルやオンラインREDOログファイルをリカバリしないでください。

DBVERIFYでリカバリしたファイルに壊れたブロックが残っているかをチェックする

DBVERIFYについての詳しい情報をDocument 35512.1に参考してください

データベースを起動して、MOUNT状態にしてください（startup mount）

どんな再定位が必要とするデータファイルにも再命名する

例えば：ALTER DATABASE RENAME FILE ‘old_name’ TO ‘new_name’;

必要とするすべてのファイルもオンラインの状態で保ってください

例えば：ALTER DATABASE DATAFILE ‘name_of_file’ ONLINE;

データベースをリカバリする　例えば：RECOVER DATABASE

データベースを起動する

例えば：ALTER DATABASE OPEN;

完全にリカバリした

~~~~~~~~~~~~~~~~~~~~~~~~~~

完全になリカバリを実行する前に、データベースをチェックしてください：

各トラブル目標にも“ANALYZE <table_name> VALIDATE STRUCTURE CASCADE”を実行する，テーブルとインディクスの間で、ミスマッチが存在しているかをチェックしてください。もしundo 操作を諦めることがあれば、そのコマンドはミスマッチと示す。この場合はインディクスを再構造してください。

アプリレベルでテーブルデータのロジック整合性をチェックしてください。

(4B)インディクスを再構造する

壊れた目標はユーザーインディクスの場合に、バックグラウンドテーブルが壊れていないとすれば、インディクスを削除して、再構造できる。もしバックグラウンドテーブルも壊れた場合に、インディクスを再構造する前に、まず壊れたブロックを解決してください。

もし収集してきた情報はインディクスに従属外部キー制約があると示されるとしたら、以下の操作を実行してください

ALTER TABLE <child_table> DISABLE CONSTRAINT <fk_constraint>;

各外部キーに対して

以下のコマンドで主キーを再構造する

ALTER TABLE <table> DISABLE CONSTRAINT <pk_constraint>; DROP INDEX <index_name>;

CREATE INDEX <index_name> .. with appropriate storage clause ALTER TABLE <table> ENABLE CONSTRAINT <pk_constraint>;

外部キー制約を起動する

ALTER TABLE <child_table> ENABLE CONSTRAINT <fk_constraint>;

インディクスパーティションに対して、以下のコマンドを実行してください：

ALTER INDEX …REBUILD PARTITION …;

注意：

（１）ALTER INDEX .. REBUILDコマンドで壊れた非パーティションインディクスを再構造しないようにしてください。

“ALTER TABLE … REBUILD ONLINE”和“ALTER INDEX … REBUILD PARTITION …”古いインディクスセグメントから新たなインディクスを構造しないから、使える。

（２）新たなインディクスにある列は既存するインディクスのサブセットであれば、Create INDEXは既存するインディクスのデータを使える。よって、二つのインディクスが壊れたとしたら、再構造する前に二つも削除してください。

インディクスを再構造する前に、正確な格納オプションを確保してください。

(4C)テーブルのデータを救う

TABLE 、CLUSTER 、 LOBSEGMENTが壊れたら、ブロックのデータもなくしたと理解してください。僅かなデータだけがHEXダンプ、あるいはインディクスの列からリカバリできる。

重要情報：

インディクスからブロックのデータをリカバリするかもしれないから、必要なデータを抽出したまで、既存するインディクスを削除しないでください。

壊れたブロックのテーブルからデータを抽出するのかいくつの方法がある。それらの同じなところはより多くのデータをリカバリすることである。一般的に、壊れたテーブルを再命名するのはいい方法である、これで正確の名で新しい目標を作成できる。

例えば：RENAME <emp> TO <emp_corrupt>;

壊れたテーブルからデータを抽出する方法

（１）Oracle 7.2から（Oracle 8.0、8.1 及び9iも含む）、テーブルに壊れたブロックをスキップできる。これは今まで一番やりやすい抽出法である、詳しい情報は以下のファイルに参考してください。

Document 33405.1 – Extracting data using DBMS_REPAIR.SKIP_CORRUPT_BLOCKS or Event 10231

もし壊れたブロックはIOT overflowセグメントにあるなら、同じ方法を使ってください。異なった場合にEvent 10233と全インディクススキャンを使ってください。

もしトラブルはORA-600 あるいはほかのORA-1578ではないトラブルであれば、DBMS_REPAIRでテーブルに壊れたテーブルをソフトブロックと標識できる。これで、そのブロックをアクセスするときに、ORA-1578エラになり、DBMS_REPAIR.SKIP_CORRUPT_BLOCKSが使えるようになった。

注意：“FIX_CORRUPT_BLOCKSプログラムに壊れたブロックと標識したブロックは、リカバリした後も壊れたブロックと標識する。

DBMS_REPAIRについて、この操作すべての詳しい情報は、関連するファイルに参考してください。ステップは以下の通り：

DBMS_REPAIR.CHECK_OBJECTでトラブルブロックを見つけだす。

そしてORA-1578と映す

必要であればDBMS_REPAIR.SKIP_CORRUPT_BLOCKSで壊れたブロックをスキップできる。

（２）Oracle 7.1から、ROWIDスキャンを選べる。けど、この機能のアルゴリズムが複雑で、ROWIDで壊れたブロックのデータをヒントする。

Document 61685.1 – Using ROWID Range Scans to extract data in Oracle8 and higher Document 34371.1 – Using ROWID Range Scans to extract data in Oracle7

（３）もし、主キーが存在すれば、このインディクスでテーブルデータを選べる。あるいはほかのインディクスで一部のデータを選べる。この方法はかなり時間をかかる。

（４）いろんなリカバリプログラムPLSQLスクリプトがテーブルのデータをリカバリできる。前述したものと比べて、これらの方法はセットや運用にはより時間をかかるが、ORA- 1578以外のいろんな壊れたブロックを処置するときによく効く。けど、これらの方法はすごく高い技術を要求しているから、一般的にお客様がこれについての文はあまり見られない。

以下のプログラムを実行するには、ProCを使う必要がある。それにProCについての知識をよく身につける必要がある：

Document 2077307.6 – SALVAGE.PC for Oracle7

以下のプログラムで、人工的に介入するが必要としている：

Document 2064553.4 – SALVAGE.SQL for Oracle7/8

壊れたLOBSEGMENTブロックを含んだテーブルからデータを抽出する方法

LOBセグメントにDBMS_REPAIRを使えない。

壊れたLOBブロックはどんなテーブルにも利用されていないであればCREATE TABLE as SELECT (CTAS)を使って、テーブルを作成する。あるいは元通りにエクステント/削除/インポートする。もし壊れたLOBブロックが利用されたら、トラブルが起きた行を含まないWHEREで選ぶあるいはエクスポートする。

アラーム：

トラブルが起きたLOB列値をNULLに更新できる。これでSELECT操作を実行するときにORA-1578エラを返せないが、壊れたブロックが再び利用される。LOB列をインサートするやアップデートするときに、壊れたブロックが再利用されると、またORA-1578エラになる。これは知っていた行に壊れたブロックが出たこともよりもっとまずい。だから、テーブルを再作成するときだけLOB列をNULLにセットする。

壊れたブロックからデータを抽出する

壊れたブロック自身が壊れたから、そのブロックから抽出したどんなデータも怪しいデータと見られる。

-TABLEのブロックに対して、Oracle Supportはブロック内容を解説できるアプリを利用できる

テーブルあるインディクスを使って、ブロックにあるROWIDを利用して、列データインディクスを抽出する。前述したROWIDでエクステントスキャンでこれについて紹介していた：

Oracle8/8iに対して，Document 61685.1を参考してください　

Oracle7に対して、 Document 34371.1を参考してください

RedoフロでLogMinerを運用することによって、壊れたブロックに対してデータをロードするインサート/アップロード操作を見つけ出せる。ここで主なファクトはデータが実際にトラブルブロックに加わった時点である。例えば、行２は昨日でインサートしたが、行１が５年前にインサートしたかもしれない。

(4D)壊れたブロックを無視する

トラブルが起きたときに、このような操作もいけると思う：壊れたブロックを無視して、報告のトラブルを受け取る。あるいはアプリレベルで、下位行がアクセスされないように、トラブルが起きたブロックにアクセスすることを阻止すてください。

こうすれば、バルクデータアクセスやほかの任務に向いていないが、ブロックがアクセスされるとエラ報告を阻止するために、4C に検討したDBMS_REPAIRもいい策だとおもう。

ブロックを無視するのは老化しやすく、まもなく削除されるデータにはいい選択肢である。（例えば、日付きによって、パーティションされるテーブルで、古いパーティションがある時点に削除される）。

LOBセグメントで壊れたブロックを無視する

アプリレベルで、テーブルを再作成まで、壊れたLOB列を無視できる。

以上のアラームを出せないように、アプリケーションはテーブルにWHERE述語のビューで、パーティションのデータをアクセスする。

例えば：もしテーブルに MYTAB（a number primary key，b clob）は一行あるいは多数行で壊れたLOBデータに指す。

ALTER TABLE MYTAB ADD ( BAD VARCHAR2(1) );

CREATE VIEW MYVIEW AS SELECT a,b FROM MYTAB WHERE BAD is null;

どんな壊れた行にもBAD=’Y’とセットする

MYVIEWだけでMYTABをアクセスすれば、その行は永遠に隠されるので、アップロードもできない。トラブルが解決するまで隔離される。

このインスタンスにはデザインするときの解決策が、あるアプリケーションには似たようなメカニズムがあるかも知れないので、トラブル行を隠せる。

壊れたブロックに対するアラーム

ブロックを無視できるが、注意すべきことは壊れたブロックがDBVERIFY、RMANバックアップを運用するときに警告や/エラの形式で現れる。

すべての壊れたブロックを記録してください。特にRMANでスキップしたいどんなブロック（例えばMAX_CORRUPTとセットした）、それに壊れたブロックを排除する、

例えば：もし壊れたブロックは無視するブロックと処置され、アプリレベルで、トラブルの行をスキップする

RMANはバックアップするときに壊れたブロックと受け止めて、後のテーブル再作成するときにテーブルを再作成する。

もしRMANはアップロードして今のエラを報告していない場合に、RMANは後に出るブロックを無視する。

それ以外、後はテーブルセグメントのブロックを無視して、問合せで返した結果が一致していないかもしれない。

もし、ブロックを無視したが、DBMS_REPAIR.FIX_CORRUPT_BLOCKS標識を使っているであれば後のリカバリオプションに影響を与える。

(4E)最後の選択肢

もしstandby環境があればまずそれをチェックしてください。

トラブルがどんなタイプのブロックにいようと、ある選択肢が選べる。それはデータベースあるいはトラブルテーブルスペースをブロックが出る前のある時点に帰れる。だが難しいところはトラブルが出た時間を知らなから。

DBVERIFYはリカバリファイルに壊れたブロックがあるか否かをチェックできる。DBVERIFYについての詳しい情報はDocument 35512.1に参考してください。特に

START= / END= DBVオプションはリカバリしたバックアップインメージで手早くテストを実行できる。

この部分にはリカバリ操作の最終的なオプションをあげた。ここまで読んだ方は、必ず以下の通りの一つ状況が起こったでしょう。

-とても大切なデータファイルをなくしたが（あるいはデータファイルに壊れたブロックが現れた）、トラブルのないファイルバックアップもない。

– ARCHIVELOGモードじゃない。それにアクチブログもない

-完全にリカバリしたあとまた同じようなトラブルが繰り返す

最後の機会：

もしデータファイルすべてのコピもなくしたが、ファイル作成したからすべてのアクチブロゴがまだ残っていれば、リカバリできる。例えば：

ALTER DATABASE CREATE DATAFILE ‘….'[as ‘…’] ; RECOVER DATAFILE ‘….’

ALTER DATABASE DATAFILE ‘….’ONLINE;

もしこの状況に逢えたら、以下の操作を実行する前にこれらのステップでデータファイルをリカバリしてみてください。

ここまでたどり着いたら、それはほかの方法がないからである。この時にはインスタンスを閉じて、今のデータベースをバックアップしてください。（例えばバックアップに壊れたブロックがない場合）

使用可能なオプションは以下の通り：

より早いコールドバックアップにリカバリする

例えば：NOARCHIVELOGの場合：

コールドバックアップからコーピーデータベースを作り上げる。

トラブルテーブルを抽出する。あるいはトラブルテーブルスペースを伝送する。

時点に基づくリカバリはデータベースを一致した時点に戻れる。

完全なバックアップとアクチブログが必要としている

すべてのファイルをリカバリして、データベースごとに適当な時点に戻らせる必要がある。

データベースに時点に元づくリカバリを実行できて、トラブルテーブルスペースをトラブルデータベースに伝送する。あるいはトラブルテーブルに伝送する。

時点に基づくテーブルスペースリカバリ

-影響を受けたテーブルスペースだけに時点リカバリするとことができる。いろんなファイルもこの方法を紹介している、例えば、Document 223543.1。

ロジックからコピをエクスポートして、データベースを再作成する。

このオプションを使うにはデータベースを再作成する必要がある。

ほかのオプションと同じように、より完全なインメージを獲得するために、コピデータベースで再作成できる。

完全なバックアップが持っていれば、DB_BLOCK_CHECKING=TRUEでロールバックして、初めてのトラブルが起きた時点を見つけ出せる。リカバリオプションを調査するときに、トラブルデータベースを閉じる必要がない。例えば：システムテーブルスペースとトラブルスペースデータファイルを異なった位置やマシンにリカバリする。異なったインスタンスとして、どこまでの時点までロールバックできるかを確認できる。Oracle9iからテストリカバリオプションで、オプションを研究しながら、リカバリバックアップを用意せねばならない状況に抜け出せる。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle Undelete Record/Rows/Table Database/RDBMS deleted by mistake

2014/12/19 by admin Leave a Comment

Data Record/rows is deleted in Oracle , it just means the row piece has been flagged as deleted, but we can still extract the record/rows from underlying disk .

This can be done by bbed or PRM-DUL (http://www.parnassusdata.com/en).

the flag info can be :

struct kdrh

 

 /* row header structure for passing as an argument to a function */
 struct kdrh
 {
 ub1 kdrhflag; /* the flag byte for the piece being inserted */
 #define KDRHFK 0x80 /* cluster Key */
 #define KDRHFC 0x40 /* Clustered table member */
 #define KDRHFH 0x20 /* Head piece of row */
 #define KDRHFD 0x10 /* Deleted row */
 #define KDRHFF 0x08 /* First data piece */
 #define KDRHFL 0x04 /* Last data piece */
 #define KDRHFP 0x02 /* first column continues from Previous piece */
 #define KDRHFN 0x01 /* last column continues in Next piece */
 #define KDRHFCK (KDRHFK|KDRHFH|KDRHFF|KDRHFL) /* Cluster Key flag settings */
 #define KDRHFSB(c) (KDRHFH|((c)&KDRHFC)) /* StuB flags from regular */
 #define KDRHFSP (KDRHFH|KDRHFF|KDRHFL) /* Single Piece flags */
 #define KDRHFCS (KDRHFSP|KDRHFC) /* Clustered Single piece */
 #define KDRHCK (KDRHFCK|KDRHFN|KDRHFP) /* hash cluster key */
 ub1 kdrhlock; /* locking itl index */
 #define KDRLKCLR 0 /* LocK CLeaR */
 ub1 kdrhccnt; /* the column count for the row piece */
 #define KDRMAXCO UB1MAXVAL /* MAXimum number of COlumns */
 ub1 kdrhckix; /* Cluster Key IndeX */
 #define KDRMAXCK (UB1MAXVAL+1) /* MAXimum number of cluster keys */
 kd4ssrid kdrhhrid; /* Head RowID, if there is one */
 kd4ssrid kdrhnrid; /* Next RowID, if there is one */
 sb2 kdrhkref; /* Key REFerence count */

A hexadecimal dump of a data block showing an entire row has a row flag value of

“2c.” This sets the bits KDRHFH, KDRHFF, KDRHFL, which would display as –HFL–

in a logical tracefile dump. That is, the row piece contains the header, the first column,

and the last column.

If the row is being updated, then the lock byte references the ITL entry# of the

transaction involved. One byte is used to store the number of columns in this row piece.

If the row is part of a cluster, then you see a one byte cluster key index located after

the number of columns field. This is covered later in the course.

Note: Row-level SCNs will require an additional six bytes of additional storage per

row. Row-level SCNs are used principally in replication environments and are used by

users, and may be used in 3-tier apps as a form of optimistic locking.

Row Format: Column data:

The column length is stored in one byte if the length is up to 250 bytes. A NULL value

stored between two populated columns will be represented as 0xFF (literally) in the

length byte. If the column length is over 250 bytes long, three bytes are used to represent

the length, the first byte being the value 0xFE and the next two bytes being the actual

column length.

Trailing NULLs are not stored, thus occupy no space in the block.

A logical block dump of a table with four columns follows

block_row_dump:

tab 0, row 0, @0x7aa

tl: 14 fb: –H-FL– lb: 0x1 cc: 4

col 0: [ 2] c1 02

col 1: [ 4] 52 4f 57 31

col 2: *NULL* This would appear as 0xFF in the length byte.

col 3: [ 1] 31

tab 0, row 1, @0x79f

tl: 11 fb: –H-FL– lb: 0x1 cc: 2

col 0: [ 2] c1 03

col 1: [ 4] 52 4f 57 32 Trailing NULLs for columns 2 and 3 are not stored.

end_of_block_dump

In the index block, patch the flag byte of the index row to undelete the row. i.e. change the flag byte from 0x01 to 0x00.

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

如何理解Oracle中的incarnation概念？

2014/12/16 by admin 3 Comments

如何理解Oracle中的incarnation概念？

小明活到了90岁这是incarnation A ，这个matrix 矩阵世界里的 root (or oracle)管理员将小明世界的时间节点回退到了小明20岁时(同时resetlogs)，由于神的能力还不足以让这个宇宙里的一切量子变化都保证和之前的那一次完全一样，所以这次回退节点里的小明是incarnation B，最后incarnation B的小明也会活到90岁。

虽然最后2个小明都90岁了，但这2个小明并不是一样的，他们都叫小明，但需要区别他们所以一个叫incarnation A 另一个叫incarnation B。在其他平行世界里可能还有其他 incarnation的小明，这取决于 root (or oracle)管理员的需求。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle DUL(data unloader) 専用データ復旧ツールユーザーズマニュアル

2014/12/13 by admin Leave a Comment

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

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

にいる方は：+86 13764045638

独立したｃ–プログラム、

DULは独立したＣプログラムで、データファイルのテーブルから直にラインを読み取る。OracleのRDBMSを全然使われていない。DULはダーティリードする。すべてのトランザクションが提出されたと仮定する。メディア・リカバリが完成されたかを確認する必要はない。

最後の手段

DULはほかの方法で検索できないデータを検索できるので、これがEXP，SQL *などの代用品ではなくて、最後の手段だ。正常な環境にはふさわしくない。

DULを使う前に、RDBMSにいろんな隠しの手段が壊滅したデータベースを起動できることを知ることが必要である。記録なしのinit.oraパラメータとトランザクションがロールフォワードがスキップできて、ローるバックや特定したSMON動作が使えない。

データベースが壊滅した–データブロックがまだ大丈夫

データベースが壊滅したことはまだ大丈夫だが、独立したデータブロックが100％に正確ということを確保しないといけない。すべてをエクスポートしてテストする時に、ブロックが壊れていないことと正確なセグメントに属していることを確保してください。もし、スキャンしている時に壊れたブロックを見つけたとしたら、エラ情報がロードプログラムに印刷してエクスポートする。そして次の行かブロックをインポートする。

cluster/テーブル/インデックスのライン

DULはcluster/テーブル/インデックスのラインにあるデータをエクスポートするしかできない。これはトリガをダンプしない、ストアドプロシージャ、テーブルまたビューのSQLスクリプトを作成しません。（これを説明するデータディクショナリーはエクスポートできる）。そのデータはSQL * LoaderあるいはIMPに適応したフォーマットにエクスポートされる。同時に、SQL * Loaderマッチ制御ファイルも作成される。

DULはインデックスとインデックス組織テーブルをエクスポートできる。これはテーブルになくした行と識別子の数を確かめたい時に使える。

クロスプラットフォームエクスポート

クロスプラットフォームエクスポートを支持している。データベースがDUL-ホストと異なったオペレーションシステムからコピーできる。（今まで関わったデータベース/システム：Sequent/ptx, Vax Vms, Alpha Vms, MVS, HP9000/8xx, IBM AIX, SCO Unix, Alpha OSF/1, Intel Windows NT）。

強力な機能

DULの運用あるいはハングにはデータベースがどれほど壊れていることにかかわらず、ダンプできない。ほぼすべてのOracle機能を支持している。ほかの支持するデータベース構造：ラインリンク、ライン移行、ハッシュ/索引クラスタ、long型、のRAW、行ID、日付、数値、複数の空きリスト・グループ（複数の空きリスト・グループ）、ハイレベルセグメント（セグメントハイウォーターマーク）、NULLが、NULLの列が尾を表示、無制限の拡張、Oracle8の新しいデータブロックレイアウト、パーティションテーブル。後で追加したlobs、圧縮インデックス、9iR2圧縮テーブルも支持している。変数配列（VARRAY）と抽象データ型ADT（ユーザーが定義したもの）は一部だけで支持される。データはexpコマンドキットでエクスポートされたダンプファイルからリカバリできる。Unpumpについて、pumpファイルを支持するために、一部の初期的な手配を完成した。

支持するRDBMSバーション

DULはOracle 6以後のバーションに適応する。DULはすでに6.0.26から10.2までのバーションテストを経過し、古いデータブロックヘッダー配置（6.0.27.2前）も支持する。

マルチバイト支持

DUL可转换为UTF8。这是为了存储在UTF16的 NCLOBS。

DULはシングルバイトのアプリケーションである。そのコマンドパーサはマルチバイト文字を理解できないが、あらゆるマルチバイトをエクスポートできる。すべてのトラブルに対して、解決策がある。

注意

MLSLABELS

信頼されたがOracleマルチレベルのセキュリティステッカー

（LONG）RAW

DULは（long）rawsをエクスポートできる。SQL * Loaderですべてのlong rawsがふさわしいフォーマットで格納されるので、long rawsとblobsがこの二つのモードでエクスポートされる。

Oracle8オブジェクトオプションとLOBS

まだネストされたテーブルを支持していないが、必要としたら、我社に連絡してください。Varray、ADT及びコアとして格納されるlobを支持する。SQL * LoaderモードとEXPモードでCLOBSもNCLOBSも支持される。EXPモードの場合に、BLOBSを処分してください。SQL * Loaderモードで作成された16進法フォーマットが今正確にロードしていない。

ポータビリティ

ANSI-C コンパイラを通って、DULをどんなオペレーションシステムにも移植できる。DULは既にいろんなUNIX，VMSとWindowsNTに移植した。いま、あらゆるの構造はgccとLinuxのクロスコンパイラ環境で完成する。

RDBMS 内部知識

Oracle RDBMSの内部的知識をよく把握すればDULをよりうまく使える。

DULのセットアップと使用

セットアップファイル

DULは二つのセットアップファイルがあるので、“init.dul”にすべてのの設定パラメータ含んでいる。（キャッシュサイズ、ヘッダのレイアウト、Oracleデータ・ブロック・サイズ、出力ファイルフォーマット）コントロールファイルで“control.dul”、データベースのデータファイル名とASMディスクをしていできる。

データファイルディクショナリーが使える

SYSTEMテーブルスペースのデータファイルが使えるなら、Oracleデータディクショナリーが使える。Oracleがこれらファイルに手配した数字と名前は“control.dul”ファイルに追加してください。また、ファイルの数とほかのテーブルスペースも追加する必要がある。これらのテーブルスペースがは最終的にはテーブルとデータをエクスポートする必要がある。これらのファイルを追加しないと、データディクショナリーのエクスポートステップに支障がでないが、後のテーブルのエクスポートが問題になる。

USER$, OBJ$, TAB$ and COL$がエクスポートできる場合に、DULを使ってください

ステップは以下の通り：

ターゲットデータベースにDULを配置する。つまり、正確なdulとdulを立ち上げる必要がある。SYSTEMテーブルスペースのデータファイルの数はすべてのテーブルとデータのデータファイルと一緒にcontrol.dulに追加してください。Oracle８以後のバーションで、テーブルスペースの数と関連するファイルの数はすべてのデータファイルで指定する必要がある。

”BOOTSTRAP；”コマンドを使ってエクスポートする。起動処理中には互換性のセグメントがみつけて、bootstrap$をエクスポートする。古い“dul dictv7.ddl”がいらない。

データファイルをエクスポートして、以下のコマンドを使ってください：
- “UNLOAD TABLE [ owner>.]table ;（；を忘れないでください）
  - データ定義やテーブルのデータをエクスポートする
- “UNLOAD USER user name ;
  - 指定したユーザーにすべてのテーブルとデータをエクスポートする
- “UNLOAD DATABASE ;

これですべての使用可能なデータベーステーブルをエクスポートできた。

使用可能なデータディクショナリーがない場合

もしSYSTEMテーブルスペースのデータファイルが使えなければ、unloadでデータをエクスポートできるが、USER，TABLEおよびCOLUMの名前を知らない。テーブルを認定する作業が大変になるが、まったく完成できないわけがない。アプリケーションとアプリケーションテーブルをより深く理解する必要がある。列タイプはDULによって当てられるが、テーブルと列の名前をなくした。DULが使用している多くの情報が変わらない。

DULを使っているのに、SYSTEMテーブルスペースを使わない

步骤如下：

ステップは以下の通り：

ターゲットデータベースにDULを配置して、正確なdulとdulを作成する。この場合に、control.dulファイルがエクスポートされたテーブル、データの数およびデータファイルの名前が必要としているが、SYSTEMテーブルスペースが必要としていない

SCAN DATABASE;：データベースをスキャンして、セグメンテーションマップを作成する。
SCAN TABLES; or SCAN EXTENTS; 統計行を収集する。
ステップ３のインポートでなくしたテーブルを見つけ出す。
見つけ出したテーブルをエクスポートする。

自動検索

より容易くなくしたテーブルを見つけ出すために、seen_tab.datとseen_col.datの統計情報が新たなデータベースにロードする。テーブルを再構造したい場合に、二つのSQL * Plusスクリプト（fill.sqlとgetlost.sql）を通って、なくしたテーブルの構造情報が「可視」テーブルにスキャンされた情報とマッチする。

ヒントとトラップ

名前はDULと関連していない、データをロードする必要がある人だけと関連している。けど、エクスポートされたデータがどこのテーブルに属しているかを知らないと、データがなんの価値もない。

推測列が間違っている可能性があります。不明である場合にあっても保守的なアルゴリズムが決定します。

表示後方列はNULLデータベースに格納されていません。最後の列はNULL値のみが含まれている場合ので、そのスキャンは検出されません。（テールが正しく処理された輸出表示にNULLカラム）。
テーブルが削除されると、説明のみのデータ辞書から除去されます。データ・ブロックが新しい段落に再利用している場合を除き、それ以外の場合は上書きされません。スキャンソフトウェアは、削除されたテーブルを参照することができます。
表の行は無視されません。新しいオブジェクトIDが古いオブジェクトよりも高いです。テーブルが再構築される場合、同じテーブルの試験および生産のバージョンがある場合、または、識別オブジェクトを決定するために用いることができます。

DDL（DULディスクドライブ言語）エクスポート声明概要

DULはSQLのようなコマンドインタフェースを使っている。エクスポートしたセグメント、テーブル、ユーザー及びすべてのデータベース全体のDDL文。必要としているデータディクショナリー情報がDDL文で前にエクスポートされたデータディクショナリー。以下の三つの文はDEPTテーブルをエクスポートする。データディクショナリーとセグメントマップが使用可能であれば、一番よく見られる形式は：

UNLOAD TABLE scott.dept;

すべての関連情報も文に指定できる：

REM Columns with type in the correct order

REM The segment header loaction in the storage clause

UNLOAD TABLE dept( deptno NUMBER, dname CHAR, loc CHAR) STORAGE( EXTENTS ( FILE 1 BLOCK 1205 ));

Oracleバーション6：

REM version 6 data blocks have segment header location in each block ALTER SESSION SET USE_SCANNED_EXTENT_MAP = TRUE; UNLOAD TABLE dept( deptno NUMBER, dname CHAR, loc CHAR) STORAGE( EXTENTS ( FILE 1 BLOCK 1205 ));

Oracle 7：

Oracle7：

REM Oracle7 data blocks have object id in each block

ALTER SESSION SET USE_SCANNED_EXTENT_MAP = TRUE; UNLOAD TABLE dept( deptno NUMBER, dname CHAR, loc CHAR) STORAGE( OBJNO 1501 );

DULインポートフォーマット

無傷な行しかエクスポートファイルに書入れない。これに対して、各行は、キャッシュされているから。Bufferの大きさはinit.dulのバラメタBUFFERで変更できる。高いBUFFERバラメタが速いスピードに等しくない、それは完全な行を保持するのに十分な大きさでなければなりません。

有三种不同的输出格式模式

三つのインポートフォーマットパタンがある：

インポートパタン
SQL * Loaderパタン：フーロデータファイル
SQL * Loaderパタン：固定した物理記録データファイル

エクスポートモード

作成したファイルはEXPによって作成したファイルのエクスポートと全然違う！そのファイルはIMPでロードできる一番小さいフォーマットである。’テーブルごとに独立したIMPファイルが作成される。これは単純なダンプファイルである。ヘッダ、insert table文とテーブルデータ、一番小さいなcreate table文を含んでいるが、ストレージ句、またはトリガーを含んでいない。（列タイプとstorage文がない）。作成されたヘッダでファイルの文字セットの表示はＶ6タイプである。それはASCIIの文字セットに基づいている。エクスポートを使いたいなら、init.dulバラメタEXPORT_MODEをTRUEに設定してください。

作成された偽ダンプファイルは文字セット情報セットNLS_LANGを含んでいないから、元のデータベースにマッチできない。エクスポートモードで、文字セットが変更されない。

SQL * Loaderモード

データはこのモードで二つの状況が分けられる：１.パタンが全然変更できない。２.パタンが全部UTF8に変更する。その前提はLDR_OUTPUT_IN_UTF8を設定した。データファイルが独立した文字が必要としているから、混合文字セット環境でこの設定が必要としている。

データをロードしている時に、必要ではないデータ文字セットの変更を避けるために、NLS_LANGを設定して元のデータベースにマッチする必要があるかもしれない。

最近二つのSQL * Loaderインポートフォーマットモードで、列はスペースで区切り、二重引用符で囲まれている。データでの二重引用符は倍になる。SQL * Loaderはその点を意識し、一つしかロードしない。init.dulバラメタLDR_ENCLOSE_CHARで二重引用符でかこまれた文字を思うままに変更する。

データストリーミングモード

このモードでは特別なところがない。記録の後には行チェンジコードが印刷される。これはコンパクトモードで、データに行チェンジコードが含んでいない場合に適用する。データストリーミングモードを起動したいなら、LDR_PHYS_REC_SIZE = 0を設定してください。

init.dul

固定物理レコード

データに行チェンジレコードが含んでいるであれば、このモードは必ず必要としている。論理レコードと完全なラインはいくつかの物理記録によって構成されている。デフォルトの記録の長さは81で、VT220に適用する。物理記録の大きさはinit.dulのLDR_PHYS_REC_SIZEで指定できる。

インポートファイル名

作成されたデータファイルの名前はowner name_table name.ext。IMPロード可能な拡張子は“.dmp”である。“.dat”と“.ctl”は変数が代わられることとほかのトラブルを避けるためのSQL * Loaderのデータファイルとコントロールファイルである。（アルファベット、数字及び’_’が使用できる）。

FILEバラメタを設定したとしたら、作成された名前がFILEnnn.extになる。ファイルシステムが長すぎる名前を支持していない場合にこの方法で対応できる。

DUL INTERNALS

必要な情報

データベースブロックからテーブルデータをエクスポートしたい場合に、以下の情報が必要としている。

列//clusterクラスタ情報：列の数とタイプ。CHARまたVARCHAR列の最大の長さ。グルプ列及びグルプの中のテーブルの数。この情報はunloadで得られる。あるいは先にエクスポートされたUSER $，OBJ $，TAB $及びCOL $で獲得する。
セグメント/セクタ情報：テーブルをエクスポートするときに、データセグメントヘッダでのextentテーブルがあらゆるデータブロックの位置を確かめるときに使われる。このデータセグメント（ファイルとブロックの番号）の位置はunload文で指定する。もしセグメントヘッダが正確じゃない/使えない場合に、もう一つ方法がある。DULがデータベースごとにスキャンし、自身のセクタマップを作成できる。

バイナリヘッダ

セグメントヘッダのC-Structsはそのままコピできない。ある特別な機能によって検索される。構造メンバーのすべての代償がDULに組み込まれる。この方法で、クロスプラットフォームエクスポートすることができるようになる。（HPでMVSが作成したデータファイルをエクスポートする）バイト順序の除いて以下四つの配置タイプが発見された。

VAX VMSとNetware：構造メンバーの間で揃えないままで埋める。
韓国Ticom Unixマシン：構造メンバー16進数揃え
MS / DOS ：16進数揃えと16数字長さ。
そのほか（Alpha VMSも含む）：構造メンバーとメンバーの大きさに揃える。

マシン依存

マシンは以下の通りバラメタで配置する：

word（ビッグ/リトルエンディアン）バイトオーダー

DBA（ブロックアドレス）FILE#でより低い部分の数

C-Structでのメンバー揃え

Oracleファイルヘッダブロックあるいはバイトのかず

セグメントヘッダ構造で使用している文の大きさ

データディクショナリーをエクスポート

もしデータディクショナリーのファイルがまだ壊れたいないとすれば、DULがデータベースのデータディクショナリーをエクスポートできる。使いたいデータディクショナリーに対して、内部的なテーブルがまず外部ファイルへエクスポートする必要がある：（USER $，OBJ $，TAB $和COL $）。

Bootstrap命令で必要とするテーブルを見つけてエクスポートする・

DDL（DULディスクライブ言語）ルール

DDL（DUL描述语言）规范

[ ALTER SESSION ] SET init.dul parameter = value ;

Most parameters can be changed on the fly.

BOOTSTRAP [LOCATE | GENERATE | COMPLETE

| UNLOAD Bootstrap$ segment header block address ];

Bootstraps the data dictionary. Default is COMPLETE.

LOCATE finds and unloads the bootstrap$ table.

GENERATE builds a ddl file based on inforation in the cache.

COMPLETE is in fact LOCATE, followed by GENERATE (two times)

COMMIT;

Writes the changed block to the data file.

CREATE BLOCK INDEX index_name ON device ;

ブロックインディクスは壊れたファイルシステムで見つけた有効なOracleブロックのアドレスを含んでいる、これは多数のディスクイメージを合併するとき、そして壊れたファイルシステムからエクスポートするときに使われる。これは極端なファイルシステムトラブルの場合に限って使える。

DESCRIBE owner_name . table_name ;

DUMP [ TABLESPACE tablespace_no ]

[ FILE file_no ]

[ BLOCK block_no ]

[ LEVEL level_no ] ;

Not a complete blockdump, mainly used for debugging.

The block address is remembered.

EXTRACT asm file name to output file name ;

Copies any ASM file from a disk group to the file system.

(there was a problem with online redologs this needs more testing)

MERGE block_index INTO [ segment ];

合併コマンドはインディクスファイルの情報を使って、ファイルの数と目標idの組合の中で可能なデータブロックを確認できる。そして候補ブロックをデータファイルのブロックと比べる。もし今のブロックが壊れていた場合あるいはもっと古いscnが存在するの場合候補ブロックがデータファイルに書き込まれる。これは極端トラブルのときに使える。

REM any_text_you_like_till_End_Of_Line : comment

REM NOT allowed inside ddl statements. ( To avoid a two layer lexical scan).

ROLLBACK; # Cancels the UPDATE statements.

SHOW DBA dba ; # dba -> file_no block_no calculator

| DBA rfile_no block_no ; # file_no block_no -> dba calculator

| SIZES ; # show some size of important structs

| PARAMETER; # shows the values of all parameters

| LOBINFO; # lob indexes found with SCAN DATABASE

| DATAFILES; # summary of configured datafiles

| ASM DISKS; # summary of configured asm disks

| ASM FILES; # summary of configured datafiles on asm

| ASM FILE cid # extent information for asm file

UNEXP [TABLE] [ owner . ] table name

( column list ) [ DIRECT ]

DUMP FILE dump file name

FROM begin offset [ UNTIL end offset ]

[ MINIMUM minimal number of columns COLUMNS ] ;

To unload data from a corrupted exp dump file. No special setup

or configuration is required, just the compatible parameter.

The start offset should be where a row actually begins.

UNPUMP

To unload data from a corrupted expdp (datapump) dump file.

This is still work in progress, the basic commands work

but rather complex to use. Contact me if this is needed.

UNLOAD DATABASE;

UNLOAD USER user_name;

UNLOAD [TABLE] [ schema_name . ] table_name

[ PARTITION( partition_name ) ]

[ SUBPARTITION( sub_partition_name ) ]

[ ( column_definitions ) ]

[ cluster_clause ]

[ storage_clause ] ;

UNLOAD EXTENT table_name

[ ( column_definitions ) ]

[ TABLESPACE tablespace_no ]

FILE extent_start_file_number

BLOCK extent_start_block_number

BLOCKS extent_size_in oracle_blocks ;

UNLOAD LOB SEGMENT FOR [ schema_name . ] table_name [ ( column name ) ] ;

UNLOAD LOB SEGMENT STORAGE ( SEGOBJNO data obj#) ;

UPDATE [ block_address ] SET UB1|UB2|UB4 @ offset_in_block = new_value ;

UPDATE [ block_address ] SET block element name = new_value ;

Now and then we can repair something.

Patches the current block and dumps it.

You can issue multiple UPDATE commands.

Block is not written yet, use COMMIT to write.

storage_clause ::=

STORAGE ( storage_specification [ more_storage_specs ] )

storage_specification ::=

OBJNO object_id_number

| TABNO cluster_table_number

| SEGOBJNO cluster/data_object_number /* v7/v8 style data block id */

| FILE data_segment_header_file_number /* v6 style data block id */

BLOCK data_segment_header_block_number )

| any_normal_storage_specification_but_silently_ignored

SCAN DATABASE;

あらゆるデータファイルのブロックをスキャンして、いくつのファイルを作成する。

セグメントヘッダ（インディクス/グルプ/テーブル）のdat情報を見つけ出す：（目標ID、ファイル番号及びブロック番号）。

連続なテーブル/グルプのデータブロックのdat情報。このファイル（選択可能、init.dul：SCAN_DATABASE_SCANS_LOB_SEGMENTS= TRUE）に限る）。の可能性が大きいである。同時に、必要なメモリーの大きさが問題になるかもしれない。目的は二つがある：１.テーブルをエクスポートするときに、壊れがちなlobインディクスをリカバリする。２. Lobセグメントをエクスポートする（既に削除されたlobまたlobインディクスとlobセグメントがない）

SCANNEDLOBPAGE.datの意味：（segobj#，lobid，fat_page_no，version( wrap, base)，ts#，file#，block#）

DDL（DULディスクライブ言語）サマリー

UNLOAD EXTENTとUNLOAD TABLEルール：

extent mapエクステントマップ

UNLOAD TABLEはextent mapエクステントマップが必要とする。99.99％の場合に、セグメントヘッダのエクステントマップが使える。極めてまれにセグメントがなくした場合に、データベースをスキャンし、ゾーンマップを作成できる。

すべてのデータブロックがそれぞれのセグメントIDを持っている。だが、V6とV7の間に根本的な違いがある。Oracle6によって作られたセグメントブロックがセグメントブロックのアドレスがある。Oracle7によって作られたデータブロックはヘッダにセグメントIDを持っている。

列の定義

列の定義はセグメントに格納する順番を指定する必要がある。col$.segcol#で指定できる。CREATE TABLE言語で指定した列の順番と同じのようにする必要がない。グルプの列を前に移し、longを後ろに移る。ALTER TABLEコマンドでテーブルに追加する列はいつも最後で格納する。

一つのセグメントをエクスポートする

UNLOAD EXTENTは隣接するブロックをエクスポートするときに使える。エクスポートするセグメントはSTROEAGE文で指定する必要がある。一つのセグメントを指定する場合にSTORAGEを使ってください。（EXTENTS（FILE fno BLOCK bno BLOCKS #blocks））（FILEとBLOCKが指定した第一のブロック、BLOCKSセグメントの大きさ。

DUL具体的な列タイプ

二つ例外なDULデータタイプがある：

IGNORE：この列は存在していないようにスキップされる

UNKNOWN：列ごとにヒューリスティック推測がある

SQL * Loaderモードでもっと多くなDULデータタイプがある：

HEXRAW：列は16進数ダンプ。

LOBINFO：LOBアドレスの情報。

BINARY NUMBER：LOBインディクスで使っているマシンワード。

USER $，OBJ $，$ TAB和COL $を識別する

DULはRDBMSと同じなbootstrapプログラムを使っている。つまり、これはシステムデータファイルヘッダのroot dbでbootstrap$の位置を確かめる。バーションの違いによって、root dbaはbootstrap$アドレスの互換セグメント位置も含んでいるかもしれない、あるいは新たなバーションではbootstrap$テーブル自身のアドレスである。bootstrap$テーブルがエクスポートされて、その内容は前の四つのテーブル（USER $，OBJ $，$ TAB和COL $）を検索して分析する。ほかのテーブルは前の四つのテーブルの情報に基づいてエクスポートされた。

SCANスキャンコマンドサマリー

SCAN TABLESとSCAN EXTENTSは同じ情報をスキャンして、似たようなインポートを作成する。すべての行と列も検索されて、以下のデータを収集する：

行はデータブロックで現れる時間間隔。
最大の内部列の長さ
列がNULLになった経過時間。
せめて75％印刷可能なASCIIによって組み込むようになった経過時間。
100％印刷可能なASCIIによって組み込むようになった経過時間。
列が有効なOracle数字になった経過時間。
列が悪くない数字になった経過時間（ゼロで始まることも終わることもない）
列が有効な日付きになった経過時間。
列は有効なrowidになった経過時間。

これらの統計は組み込まれ、一種の列タイプとして提出される。このアドバイスを採用し、結果をエクスポートする。これらの統計データは二つのファイル（seen_tab.datとseen_col.dat）にダンプする。SQL * LoaderとSQL * Plusスクリプトがあれば、一部の識別プロセスが自動的に完成する。（getlostと呼ばれている）。

デスクライブdescribe

このようなデスクライブコマンドがあって、DULディクショナリーメモリーで使用できて、テーブルのディクショナリー情報を示す。

DUL起動手順：

起動プロセスは以下のようなスキップが必要である：

バラメタファイル“dul”が処理された
DULコントロールファイル（ディフォルトは“dul”）がスキャンされた。
USER$，OBJ$，TAB $およびCOL $のダンプをロードしてみてください。もし存在すれば、DULのデータディクショナリーメモリーに格納してください。
Datとdatをロードしてみてください
ＤＤＬ文を受け入れ、または初めのバラメタになったDDLスクリプトを実行してください。

init.dulで指定できるDULバラメタ

ALLOW_TRAILER_MISMATCH

BOOLEAN

この機能を使わないでください。より多くの行を作成されないので、完全にその構造を理解し、なぜ自分がこの機能を使いたくなったかを十分理解したうえで使える。この機能は正確なブロックtrailerテストをスキップした。このテストで失敗したブロックは壊滅した欠片なので、ブロックを修復する迷惑を省みた。

もしディクショナリーはデータファイルより古い場合に、データ目標IDはtruncateされたテーブルと違っている。このバラメタをtrueにしてください、アラームを発生するが、セグメントヘッダの値を使っているから、まだ大丈夫。すべてのブロックも全面的にテストされる。

ASCII2EBCDIC

BOOLEAN

(var)charフィールドはEBCDICからASCIIに書き変わる必要がある。（ASCIIホストでMVSデータベースをエクスポートするときに使う）

BUFFER

NUMBER（バイト）

エクスポートとSQL * Loaderモードで使っているライン出力バッファ（buffer）の大きさはまずそのバッファに格納されて。違っていない行はそのままインポートファイルに書き込む。

COMPATIBLE

NUMBER

データベースバーション：有効値は6.7.8.9。バラメタを指定する必要がある。

CONTROL_FILE

TEXT

DULコントロールファイル名前（ディフォルト：“ control.dul”）

DB_BLOCK_SIZE

NUMBER

バイトで示したOracleブロックの大きさ（最大32Ｋ）

DC_COLUMNS

NUMBER

DC_OBJECTS

NUMBER

DC_TABLES

NUMBER

DC_USERS

NUMBER

Dulディクショナリーメモリー大きさ。もし一つが低すぎるとしたら、自動的に大きさを調整する。

EXPORT_MODE

BOOLEAN

エクスポートモードまたは SQL*Loaderモードを使ってください

FILE

TEXT

（ダンプあるいはデータ）ファイル名を作成する基礎である。 8.3 DOSのようなファイルシステムに適応する。

FILE_SIZE_IN_MB

NUMBER (Megabytes)

最大のダンプファイル大きさ。ダンプファイルはいくつかの部分に分割する。ファイルごとに一つのヘッダを持っていて、独立でロードできる。

LDR_ENCLOSE_CHAR

TEXT

The character to enclose fields in SQL*Loader mode.

LDR_PHYS_REC_SIZE

NUMBER

作成したloaderデータファイルの物理記録の大きさ

LDR_PHYS_REC_SIZE = 0固定した記録がない。すべての記録は改行記号で終わる。

LDR_PHYS_REC_SIZE > 2: 固定した記録の大きさ

MAX_OPEN_FILES

オペレーションシステムレベルでオープンなデータファイルを最大にしてください。

OSD_BIG_ENDIAN_FLAG

マシン言語で表示したバイト手順。Big EndianもMSBと呼ばれている。DULは運用している機械でディフォルトを設定できる。

OSD_DBA_FILE_BITS

OSD_FILE_LEADER_SIZE

bytes/blocks added before the real oracle file header block

OSD_C_STRUCT_ALIGNMENT

Ｃ構造メンバー揃え（0,16あるいは23）。ディフォルトの32は大多数のポートに対しても正しい。

OSD_WORD_SIZE

MS/DOS(16)を除いて、一つのマシンワードの大きさはいつも32。

PARSE_HEX_ESCAPES

Boolean ディフォルト FALSE

解析の時に、文字列で\\xhh 16進数エスケープシーケンス。trueに設定したら、おかしい文字はエスケープシーケンスで指定できる。マルチバイト文字を指定するときにも運用できる。

USE_SCANNED_EXTENT_MAP

BOOLEAN

テーブルをエクスポートするときに、ext.datでスキャンしたゾーンマップを使っている。通常のアルゴリズムはセグメントヘッダでゾーンマップを使っているが、一部のセグメントヘッダがなくした場合にこのバラメタが使える。

WARN_RECREATE_FILES

BOOLEAN (TRUE)

既存のファイルが上書きされたとすれば、FALSEに設定してアラーム通信をキャンセルできる。

WRITABLE_DATAFILES

BOOLEAN (FALSE)

一般的に、DULはデータベースファイルだけを読み取る。けど、UPDATEと SCAN RAW DEVICEも書き出される。バラメタは予想していない損害を防げる。

例 init.dul :

# 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 = 10

osd_c_struct_alignment = 32

osd_file_leader_size = 1

# database parameters

db_block_size = 8k

# loader format definitions

LDR_ENCLOSE_CHAR = ”

LDR_PHYS_REC_SIZE = 81

配置ポートについてのバラメタ

RDBMS　10Ｇから、osdが配置しやすくなった。一般的に、すべてのバラメタがディフォルト値を使える。唯一の注意をかける必要があるのはosd_big_endian_flag、元のデータベースプラットフォームと今のマシンと異なって、クロスプラットフォームエクスポートするときに、osd_big_endian_flagの設定が正しくなければ

既に知っていったバラメタ

10GデータベースはOSDウィキリストがない場合に私たちに知らせてください。

osd_big_endian_flag

big endian あるいはlittle endian（マシンが示したバイト手順）：HP，SUNbig endian：OSD_BIG_ENDIAN_FLAG = TRUE。 DEC和Intel平台是little endian ：OSD_BIG_ENDIAN_FLAG = FALSE。ディフォルト値はDULが運用しているプラットフォームに対して、正しかった。

この点については、決まりのコツがない。以下の方法はUNIXシステムでは可能かもしれない。

echo dul | od -x

If the output is like:

0000000 6475 6c0a

0000004

You are on a big endian machine (OSD_BIG_ENDIAN_FLAG=TRUE).

If you see:

0000000 7564 0a6c

0000004

This is a little endian machine (OSD_BIG_ENDIAN_FLAG=FALSE).

osd_dba_file_bits

以下のコマンドを実行してください。

SQL> select dump(chartorowid(‘0.0.1′)) from dual;

Typ=69 Len=6: 8,0,0,0,0,0 -> osd_dba_file_bits = 5 (SCO)

Typ=69 Len=6: 4,0,0,0,0,0 -> osd_dba_file_bits = 6 (Sequent , HP)

Typ=69 Len=6: 1,0,0,0,0,0 -> osd_dba_file_bits = 8 (NCR,AIX)

Typ=69 Len=6: 0,16,0,0,0,0 -> osd_dba_file_bits = 12 (MVS)

Typ=69 Len=10: 0,0,0,0,0,64,0,0,0,0 osd_dba_file_bits = 10 (Oracle8)

OSD_C_STRUCT_ALIGNMENT

データファイルヘッダの構造配置。0：ｃ-構造（VAX/ VMS）メンバーの間で、埋め込まれていない。16：一部の韓国ticomマシンとMS/ DOS32：構造メンバーはメンバーの大きさで配列する。

SELECT * FROM v$type_size

WHERE type IN ( ‘KCBH’, ‘KTNO’, ‘KCBH’, ‘KTBBH’, ‘KTBIT’, ‘KDBH’

, ‘KTECT’, ‘KTETB’, ‘KTSHC’) ;

一般的にosd_c_struct_alignment=32と以下のようなものがでる：

K KTNO TABLE NUMBER IN CLUSTER 1

KCB KCBH BLOCK COMMON HEADER 20

KTB KTBIT TRANSACTION VARIABLE HEADER 24

KTB KTBBH TRANSACTION FIXED HEADER 48

KDB KDBH DATA HEADER 14

KTE KTECT EXTENT CONTROL 44

KTE KTETB EXTENT TABLE 8

KTS KTSHC SEGMENT HEADER 8

8 rows selected.

VAX/ VMSとNetwareだけに対して、osd_c_struct_alignment=0と以下のようなものがでる：

COMPONEN TYPE DESCRIPTION SIZE

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

K KTNO TABLE NUMBER IN CLUSTER 1

KCB KCBH BLOCK COMMON HEADER 20

KTB KTBIT TRANSACTION VARIABLE HEADER 23

KTB KTBBH TRANSACTION FIXED HEADER 42

KDB KDBH DATA HEADER 14

KTE KTECT EXTENT CONTROL 39

KTE KTETB EXTENT TABLE 8

KTS KTSHC SEGMENT HEADER 7

8 rows selected.

もし、異なったリストがあるとすれば、一部のハッキングと盗聴が必要とする。DULに重大な影響を与えるかもしれない。（メールBernard.van.Duijnen@oracle.com）

osd_file_leader_size

Oracleファイルヘッダのまえのブロック/バイトの数。Unixデータファイルがエクストラ先頭ブロックが100を超えた場合にバイトオフセットと見なし、超えていなければOracleブロックの番号と見なす。

Unix : osd_file_leader_size = 1

Vms : osd_file_leader_size = 0

Desktop : osd_file_leader_size = 1 (or 512 for old personal oracle)

Others : Unknown ( Use Andre Bakker’s famous PATCH utility to find out)

An Oracle7 file header block starts with the pattern 0X0B010000.

選択可能な第三フィールドのcontrol.dulでエクストラなバイトオフセットを追加できる。（AIXあるいはDEC UNIX）

コントロールファイル文法のルール：

コントロールファイル（ディフォルト名“control.dul”）はASMディスク、ブロックインディクス及びデータファイル名を指定するときに使える。

control_file_line ::= asm_disk_spec | file_piece_spec | block_index_spec

互換性は10か以上である場合に、ASMディスクも指定できる。一般的に指定したマシンの名は足りる。

DISK device name [ disk group options ]

disk group option ::= GROUP disk group name

| DISK_NO disk number in group

| F1B1 File1 Block1 location

ブロックインディクスは壊滅したファイルシステムでOracleブロックにアクセスする方法の一つで、一般的には、壊れたファイルシステムが完全に削除されていないかぎり、ブランクではない。Oracleブロックの特別な配置によって、it is possible to datablocks an store their location in the block index。create block indexコマンドを参考してください。block_index_nameは普通な識別子で、唯一なファイル名を作成するときに使われる。

BLOCK INDEX block_index_name

各エントリはデータファイルの一部を指定できる。最小の単位は一つのデータブロックである。この場合に、DULが大き過ぎるファイルに対して、いくつか2ＧＢに過ぎない部分に割り当てられる。

普通の場合に、ファイル名を指定すればいいと思う。一つのブロックに対して、compatibleが10に超えた場合に、ファイルヘッダからファイル番号とテーブルスペース番号を読み取る。

指定したディテールとファイルヘッダと相違がでた場合、壊れたファイルヘッダからファイルをエクスポートするために、DULがアラームを発信する。チューニングするときに、ファイルヘッダをダンプできる。

選択可能な追加のシフトリーダーはエクストラなバイトオフセット、データファイルのすべてのlseek()操作に付き添った。よって、AIXもっとのマシン以外の4Kブロックをスキップできる。あるいは元のマシンでTru64d４ｋブロックを追加できる。

file_piece_spec ::=

[ [ tablespace_no ] relative_file_number]data_file_name

[ optional extra leader offset ]

[ startblock block_no ]

[ endblock block_no ]

例えば

# 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

# ASM disks for two disk groups

disk /media/maxtor/asm/dgn1

disk /media/maxtor/asm/dgn2

disk /media/maxtor/asm/dgn3

disk /media/maxtor/asm/dgn4

disk /media/maxtor/asm/dgodd

# system datafile in the first asm disk group

+DGN/db102/datafile/system.257.621616979

# users datafile in a different disk group

+DGODD/db102/datafile/users.257.621616683

# a so called big file tablespace, use 1024 for the file#

8 1024 /home/oracle/v102/dbs/bigfilets

# Or let DUL find out itself from the header

/home/oracle/v102/dbs/bigfilets

# one tablespace with a different block size

/home/oracle/v102/dbs/ts16k.dbf block_size 16k

# or let DUL find out by header inspection

/home/oracle/v102/dbs/ts16k.dbf

会話を例でエクスポートされた：DULデータディクショナリーに使える。

１.ふさわしい “init.dul”を作成する

２. control.dulを作成する。

sqlplus /nolog

connect / as sysdba

startup mount

set trimspool on pagesize 0 linesize 256 feedback off

column name format a200

spool control.dul

select ts#, rfile#, name from v$datafile;

exit

edit the result

For Oracle8 a different query must be used:

select ts#, rfile#, name from v$datafile;

DULとbootstrapを起動する。

$ dul

Data UnLoader 10.2.1.16 – Oracle Internal Only – on Thu Jun 28 11:37:24 2007

with 64-bit io functions

Strictly Oracle Internal use Only

DUL> bootstrap;

Probing file = 1, block = 377

. unloading table BOOTSTRAP$ 57 rows unloaded

DUL: Warning: Dictionary cache DC_BOOTSTRAP is empty

Reading BOOTSTRAP.dat 57 entries loaded

Parsing Bootstrap$ contents

DUL: Warning: Recreating file “dict.ddl”

Generating dict.ddl for version 10

OBJ$: segobjno 18, file 1

TAB$: segobjno 2, tabno 1, file 1

COL$: segobjno 2, tabno 5, file 1

USER$: segobjno 10, tabno 1, file 1

Running generated file “@dict.ddl” to unload the dictionary tables

. unloading table OBJ$ 52275 rows unloaded

. unloading table TAB$ 1943 rows unloaded

. unloading table COL$ 59310 rows unloaded

. unloading table USER$ 70 rows unloaded

Reading USER.dat 70 entries loaded

Reading OBJ.dat

52275 entries loaded and sorted 52275 entries

Reading TAB.dat 1943 entries loaded

Reading COL.dat 59310 entries loaded and sorted 59310 entries

Reading BOOTSTRAP.dat 57 entries loaded

…

Some more messages for all the other TABLES

…

Database character set is WE8ISO8859P1

Database national character set is AL16UTF16

DUL> unload user SCOTT;

About to unload SCOTT’s tables …

. unloading table EMP 14 rows unloaded

会話を例でエクスポートされた：DULデータディクショナリーに使えない。

１.ふさわしい “init.dul”を作成する

２. control.dulを作成する。

３.データベースのセグメントヘッダとセクションをスキャンする

$ dul

UnLoader: Version 2.0.0.0 – Very Restricted on Tue May 16 11:10:16 1995

DUL> scan database;

data file 1 20480 blocks scanned

data file 4 7680 blocks scanned

data file 5 512 blocks scanned

DUL>quit

DULを再起動して見つけ出したテーブルから列の統計を獲得する、大量なインポートが作成された。

echo scan tables \; | dul > scan.out&

[ many lines here]

Object id 1601 table number 0

UNLOAD TABLE T1601_0 ( C1 NUMBER, C2 UNKNOWN, C3 UNKNOWN, C4 NUMBER, C5 DATE

, C6 NUMBER, C7 NUMBER, C8 NUMBER )

STORAGE ( TABNO 0 EXTENTS( FILE 1 BLOCK 10530));

Colno Seen MaxIntSz Null% C75% C100 Num% NiNu% Dat% Rid%

1 14 3 0% 0% 0% 100% 100% 0% 0%

2 14 6 0% 100% 100% 100% 14% 0% 21%

3 14 9 0% 100% 100% 100% 14% 0% 0%

4 14 3 7% 0% 0% 100% 100% 0% 0%

5 14 7 0% 0% 0% 0% 0% 100% 0%

6 14 3 0% 0% 0% 100% 100% 0% 0%

7 14 2 71% 0% 0% 100% 100% 0% 0%

8 14 2 0% 0% 0% 100% 100% 0% 0%

“7369” “SMITH” “CLERK” “7902” “17-DEC-1980 AD 00:00:00″ “800” “” “20”

“7499” “-0.000025253223″ “SALESMAN” “7698” “20-FEB-1981 AD 00:00:00″ “1600” “30+

0″ “30”

“7521” “WARD” “SALESMAN” “7698” “22-FEB-1981 AD 00:00:00″ “1250” “500” “30”

“7566” “JONES” “MANAGER” “7839” “02-APR-1981 AD 00:00:00″ “2975” “” “20”

“7654” “MARTIN” “SALESMAN” “7698” “28-SEP-1981 AD 00:00:00″ “1250” “1400” “30”

[ many more lines here ]

ここの内容はよく見られるとおもう。これらの情報とempテーブルの理解に基づき、作成してください。

UNLOAD TABLE emp ( empno number, ename char, job char, mgr number,

hiredate date, sal number, comm number deptno number)

STORAGE ( TABNO 0 EXTENTS( FILE 1 BLOCK 10530));

１.この文でempをエクスポートする：

$ dul

UnLoader: Version 2.0.0.0 – Very Restricted on Tue May 16 11:46:33 1995

Loaded 350 segments

Loaded 204 extents

Extent map sorted

DUL> UNLOAD TABLE emp ( empno number, ename char, job char, mgr number,

DUL 2> hiredate date, sal number, comm number deptno number)

DUL 3> STORAGE ( TABNO 0 EXTENTS( FILE 1 BLOCK 10530));

. unloading table EMP 14 rows unloaded

DUL>quit

Sessionをエクスポートする：正しくないinit.dulバラメタ

違ったosd_dba_file_bitsの大きさ

よって、以下のようなインポートが出てくる。一般的には発生しない。デモ・データベースを作成して、DUL記録の問い合わせ（HTMLページ）で検索してください。

DBAのミスマッチはファイルの部分にある。第二番の数字やブロック番号は正しい。

Data UnLoader: Release 3.2.0.1 – Internal Use Only – on Wed Sep 3 10:40:33 1997

Session altered.

DUL: Warning: Block[1][2] DBA in block mismatch [4][2]

DUL: Warning: Bad cache layer header file#=1, block#=2

DUL: Warning: Block[1][3] DBA in block mismatch [4][3]

DUL: Warning: Bad cache layer header file#=1, block#=3

………..and etc……….

osd_file_leader_sizeが間違った。

以下のようなインポートになるかもしれないが、そのほかにも色々な可能性がある。ここで、block offは固定したので、In this case we are a fixed number of blocks off.ファイル番号は正しい、ブロック番号の差は変わらない。

Data UnLoader: Release 3.2.0.1 – Internal Use Only – on Wed Sep 3 10:44:23 1997

Session altered.

DUL: Warning: Block[1][2] DBA in block mismatch [1][3]

DUL: Warning: Bad cache layer header file#=1, block#=2

DUL: Warning: Block[1][3] DBA in block mismatch [1][4]

DUL: Warning: Bad cache layer header file#=1, block#=3

………..and etc……….

osd_c_struct_alignmentが間違った。

以下のようなインポートになる：

Data UnLoader: Release 3.2.0.1 – Internal Use Only – on Wed Sep 3 10:46:10 1997

Session altered.

. unloading table OBJ$

DUL: Warning: file# 0 is out of range

DUL: Warning: Cannot read data block file#=0, block# = 262145

OS error 2: No such file or directory

DUL: Warning: file# 0 is out of range

DUL: Warning: Cannot read data block file#=0, block# = 262146

OS error 2: No such file or directory

………..and etc……….

db_block_sizeが間違った。

DB_BLOCK_SIZEが小さ過ぎると、以下のようなインポートになる。正確なちは4096、2048に設定すれば、一般的には、このバラメタ値はOracleインスタンスのinit.oraファイルから得る。そして正確に設定できない。

Data UnLoader: Release 3.2.0.1 – Internal Use Only – on Thu Sep 4 12:38:25 1997

Session altered.

DUL: Warning: Block[1][2] DBA in block mismatch [513][1159680]

DUL: Warning: File=1, block 2: illegal block version 2

DUL: Warning: Block[1][2] Illegal block type[0]

DUL: Warning: Bad cache layer header file#=1, block#=2

DUL: Warning: Block[1][4] DBA in block mismatch [1][2]

DUL: Warning: File[1]Block[4]INCSEQ mismatch[90268!=0]

DUL: Warning: Bad cache layer header file#=1, block#=4

DUL: Warning: Block[1][6] DBA in block mismatch [1][3]

DUL: Warning: File[1]Block[6]INCSEQ mismatch[139591710!=86360346]

DUL: Warning: Bad cache layer header file#=1, block#=6

………..and etc……….

QUOTE MISSING

以下のようなエラになったのはデータディクショナリーテーブル“USER$，OBJ$，$ TAB及びCOL$”が正確に作成されていないからである。このエラを解決するために、すべてのdictv6.ddlまたはdictv7.ddlを削除し、datと.ctlファイルを作成して再起動すればいい。

Data UnLoader: Release 3.2.0.1 – Internal Use Only – on Wed Sep 3 10:49:30 1997

DUL: Error: Quote missing

壊滅したEXPダンプファイルからデータをリカバリする：UNEXP

EXPダンプファイルに対して何一つも知らないとしたら、リカバリが大変になる。以下は簡単な説明である。ファイルヘッダを除いて、ダンプファイルは部分の標識を識別できる。すべてのテーブルにはＳＱＬ文がある。一番面白い部分はcreate table文。そしてテーブル文にインサートして、情報にバインディングしてください。そして、実際の例で、列ごとに２バイト長があって、実際の列データを付いていない。より長い列にはこんなコツがある。列データの終わりで特別な長さでOXFFFFを標識する　行のヘッダには標識がない。壊れたあとの再同期はエラを試す。壊れた部分は検知できない。そのフォーマットはDIRECTエクスポートと違っている。DIRECTエクスポートに対してDIRECTオプションを使ってください。指定したオフセットは行のヘッダになる。一般的には初めてのバインディングされたアレイから始まるが、最善な柔軟性になるために、行データのどこからでもいい。

第一歩はダンプファイルで転移したＳＱＬ文を見つけ出す。すべてのインポート行は転移した位置から始まる。

DUL> scan dump file expdat.dmp;

0: CSET: 1 (US7ASCII) # Character set info from the header

3: SEAL EXPORT:V10.02.01 # the Seal – the exp version tag

20: DBA SYSTEM # exp done as SYSTEM

8461: CONNECT SCOTT # section for user SCOTT

8475: TABLE “EMP”

# complete create table staement

8487: CREATE TABLE “EMP” (“EMPNO” NUMBER(4, 0), “ENAME” VARCHAR2(10),

“JOB” VARCHAR2(9), “MGR” NUMBER(4, 0), “HIREDATE” DATE, “SAL” NUMBER(7, 2),

“COMM” NUMBER(7, 2), “DEPTNO” NUMBER(2, 0)) PCTFREE 10 PCTUSED 40

INITRANS 1 MAXTRANS 255 STORAGE(INITIAL 65536 FREELISTS 1

FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE “USERS” LOGGING NOCOMPRESS

# Insert statement

8829: INSERT INTO “EMP” (“EMPNO”, “ENAME”, “JOB”, “MGR”, “HIREDATE”,

“SAL”, “COMM”, “DEPTNO”) VALUES (:1, :2, :3, :4, :5, :6, :7, :8)

# BIND information

8957: BIND information for 8 columns

col[ 1] type 2 max length 22

col[ 2] type 1 max length 10 cset 31 (WE8ISO8859P1) form 1

col[ 3] type 1 max length 9 cset 31 (WE8ISO8859P1) form 1

col[ 4] type 2 max length 22

col[ 5] type 12 max length 7

col[ 6] type 2 max length 22

col[ 7] type 2 max length 22

col[ 8] type 2 max length 22

Conventional export # Conventional means NOT DIRECT

9003: start of table data # Here begins the first row

现在从create table语句和直接/常规信息和列数据的开头创建unexp语句。

これからはcreate table文からダイレクト/一般情報と列データの初めての部分でunexpを作成する。

UNEXP TABLE “EMP” (“EMPNO” NUMBER(4, 0), “ENAME” VARCHAR2(10),

“JOB” VARCHAR2(9), “MGR” NUMBER(4, 0), “HIREDATE” DATE, “SAL” NUMBER(7, 2),

“COMM” NUMBER(7, 2), “DEPTNO” NUMBER(2, 0))

dump file expdat.dmp from 9003;

Unloaded 14 rows, end of table marker at 9670 # so we have our famous 14 rows。

この操作によって、普通のSQL * Loaderファイルとそれにマッチするコントロールファイルを作成される。インポートファイルでエクストラな列が付き添う。APは行が部分的と意味している。（なくした一部の列）Ｒは最同期に意味する、これは最同期の第一行。Oは重なり、前の行にエラがある。新しい行はほかの部分に重なる。

コラム

~~~~~~~~~~~~~~~~~

サマリー
DULを使う

2.1ふさわしいinit.dulファイルを作成する

2.2control.dulファイルを作成する

2.3目標情報をエクスポートする

2.4DULを使う

2.5データベースを再建する

どうやってデータディクショナリーに格納された目標定義を再建できるでしょう
セグメントヘッダが壊滅した時に、どうやってデータをエクスポートできるでしょう
ファイルヘッダが壊滅した時に、どうやってデータをエクスポートできるでしょう
システムテーブルスペースなしにどうやってデータをエクスポートできるでしょう
虫垂A：どこで実行できるファイルを見つけ出せるでしょう
リファレンス

サマリー

この文はBernardのデータエクスポート能力に対する説明ではなく、DULをいかに活用できる方法を紹介する文である。

この文は内部的な交流に限る。どんな場合にもこの文をお客様に渡すことが許せない。DULは常に分析者に使うことあるいは分析者の監視を元に使うことを確保してください。

DUL（データエクスポート）はOracleデータベースから検知できないデータを検索できる。けどこれはSQL * Loaderの代わりではない。このデータベースは破壊されやすいから、一つ独立したデータブロックが１００％に正確ということを確保してください。エクスポートするときに、ブロックが壊れていないことと正確なセグメントに属していることを確保するために、ブロックがテストされる。エラ情報がloaderに写されるが、後の行やブロックのエクスポートすることが阻止できない。

2.DULをつかう

まずデータブロックにある目標が必要とする情報を入手してください。これらの統計は、DULディクショナリーにロードされる。

この情報はデータベースが作成された時に、作成したUSER $，OBJ $，$ TAB及びCOL $表を検索して見つけ出した。DULはシステムテーブルスペースで情報を見つけ出せる。データファイルが存在しない場合に、テーブルデータファイルはコントロールファイルに含んでいる必要がある。-0urY 00000000022

2.1 ふさわしい“init.dul”ファイルを作成する

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

REMプラットフォームでバラメタを指定する

REMはよくあるプラットフォームのバラメタを獲得できる。

osd_big_endian_flag=false

osd_dba_file_bits=10

osd_c_struct_alignment=32

osd_file_leader_size=1

osd_word_size = 32222222

REM DULディクショナリーメモリーの大きさ。低すぎた場合に、起動できない。

dc_columns=2000000

dc_tables=10000

dc_objects=1000000

dc_users=400

control_file = D:\Dul\control_orcl.dul

コントロールファイルの位置と名、ディフォルトはcontrol.dul

データベースブロックの大きさ。init.oraあるいは“show parameter %db_block_size%”で見つけ出せる。

db_block_size=4096。

データが指定するために、エクスポート、インポートフォーマットが必要とする。

これにより、Oracleインポートツールに適用したファイルが作成されるが、作成されたファイルがEXPツールで作られたものと全然ちがう。

それはテーブル構造文とテーブルデータのテーブルダンプファイルである。

Grants、ストレージ句、トリガが含んでいない！

export_mode=true

REM互換バラメタは指定できて、6も7も8もいい。

compatible=8

そのバラメタは選択可能でREMが支持していない長すぎたファイル名（e.g. 8.3 DOS）のプラットフォームも、DUL が“owner_name.table_name.ext”を使って、ファイルフォーマットが使用出来ない場合にも指定できる。

file = dump

完全なリストがHTML部分でDULバラメタで獲得できる。init.dulファイルが大多数の場合にも適用できて、すべてのバラメタも含んでいて成功エクスポートすることを保障できる。

2.2“control.dul”ファイルを作成する

論理表スペースと物理データ・ファイルに対して一定な知識が必要、データベースがロードされた時に以下の問合せを実行する：

Oracle 6, 7

———–

> connect internal

> spool control.DUL

> select * from v$dbfile;

> spool off

Oracle 8

——–

> connect internal

> spool control.DUL

> select ts#, rfile#, name from v$datafile;

> spool off

必要であれば、spoolファイル、データファイルの位置とstrpe outに必要ではない情報も編集できる。

例コントロールファイルは以下の通り：

Edit the spool file and change, if needed, the datafile location and stripe

out unnecessary information like table headers, feedback line, etc…

A sample control file looks something like this :

REM Oracle7 control file

1 D:\DUL\DATAFILE\SYS1ORCL.DBF

3 D:\DUL\DATAFILE\DAT1ORCL.DBF

7 D:\DUL\DATAFILE\USR1ORCL.DBF

REM Oracle8 control file

0 1 D:\DUL\DATAFILE\SYS1ORCL.DBF

1 2 D:\DUL\DATAFILE\USR1ORCL.DBF

1 3 D:\DUL\DATAFILE\USR2ORCL.DBF

2 4 D:\DUL\DATAFILE\DAT1ORCL.DBF

注意：DULが大きすぎるデータファイルをスプリットするときに使える。例えば：

REM Oracle8であるデータファイルがいくつかの部分に割り当てられた。すべての部分は１ＧＢを超えていない。

0 1 D:\DUL\DATAFILE\SYS1ORCL.DBF

1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 1 endblock 1000000

1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 1000001 endblock 2000000

1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 2000001 endblock 2550000

2.3 Unload the object information

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ふさわしいDDL（DUL言語）スクリプトでBULツールを起動する。データベースバーションの違いによって、三つ使用可能なスクリプトでUSER$，$ OBJ，TAB$とCOL$テーブルでエクスポートできる。

Oracle6 :> dul8.exe dictv6.ddl

Oracle7 :> dul8.exe dictv7.ddl

Oracle8 :> dul8.exe dictv8.ddl

Data UnLoader: Release 8.0.5.3.0 – Internal Use Only – on Tue Jun 22 22:19:

Parameter altered

Session altered.

Parameter altered

Session altered.

Parameter altered

Session altered.

Parameter altered

Session altered.

. unloading table OBJ$ 2271 rows unloaded

. unloading table TAB$ 245 rows unloaded

. unloading table COL$ 10489 rows unloaded

. unloading table USER$ 22 rows unloaded

. unloading table TABPART$ 0 rows unloaded

. unloading table IND$ 274 rows unloaded

. unloading table ICOL$ 514 rows unloaded

. unloading table LOB$ 13 rows unloaded

Life is DUL without it

USER$, OBJ$, TAB$ and COl$データディクショナリーのデータをSQL*Loaderファイルにエクスポートする。これはエクスポートフォーマットのダンプファイルに処理出来ない。

. unloading table OBJ$

DUL: Error: Column “DATAOBJ#” actual size(2) greater than length in column

definition(1)

………….etc……………

2.4　DULを使う

対話モードでDULを起動する。すべてのddlコマンドを含んでいて、データベースに必要なデータをエクスポートするスクリプトを用意してもいい。本文档で一番よく使われるコマンドを説明する。

DUL> unload database;

=> データベーステーブルごとにエクスポートする（sys’tablesも含む）

DUL> unload user ;

=>指定したユーザーが持っているすべてのテーブルをエクスポートする。

DUL> unload table ;

=>ユーザーが持っているテーブルをアンインストールする。

DUL> describe ;

=>テーブルの列及び指定したユーザーが持っているデータファイルを示す。

will represent the table columns with there relative pointers to the datafile(s) owned by the specified user.

DUL> scan database;

=>すべてのデータファイルのブロックをスキャンする

二つのファイルが作成される：

１.見つけ出したセグメントヘッダseg.dat情報（インディクス/グルプ/テーブル）

2.連続なテーブル/グルプのデータブロックのext.dat情報

（目標ID（V7）、ファイルとセグメントヘッダのブロック番号（V6）、ファイル番号と初めてのブロックの番号、ブロックの数、テーブルの数）

DUL> scan tables;

=> seg.datとext.datをインポートする

すべてのデータセグメントのテーブルをスキャンする。

2.5データベースを再建する

~~~~~~~~~~~~~~~~~~~~~~~~

新しいデータベースを作成する。そして、SQL * LoaderでDULが検索したデータをリカバリする。けど、テーブル構造データをエクスポートするときに、新しいデータベースにはインディクス、grants，PL / SQL及びトリガーを含んでいない。前のデータベースと完全に同じなものを手に入るため、テーブル、インディクスPL / SQLなどの作成スクリプトを再び実行してください。

3.どうやってデータディクショナリーに格納された目標定義を再建する

DULでPL / SQL（パッケージ、プロシージャ、関数、またはトリガー）、補助金、索引、制約または記憶域句（旧テーブル構造）を再建することもできるが、ちょっとだけ厄介になる。DULで関連するデータディクショナリーテーブルをエクスポートして、これらのテーブルを健全なデータベースにロードする。ロードの途中にも健全なデータベースを壊すかもしれない。

１）「DULを使う」で説明したステップでデータディクショナリーテーブル“source$”をエクスポートする。

２）新しいユーザーを作成して、健全なデータベースに登録して、一時テーブルスペースをしてください。

３）リンク、リソース、imp_full_databaseの権限を新しいユーザーに与える。

4）“source$”を新たに作成したモードにインポート/ロードする。

例えば：imp80 userid=newuser/passw file=d:\dul\scott_emp.dmp

log=d:\dul\impemp.txt full=y

5）今、テーブルの問合せから壊れたデータベースでpl/sql packages / procedures /functionsを再建できる。WebIvにこのようなPL / SQLを見つけだしてスクリプトを作成する。

同じステップでインデックス、制約、およびストレージ・パラメータを再建できる。該当するユーザーに再び権限を与えることもできる。

4.セグメントヘッダが壊れたときに、どうやってデータをエクスポートするでしょう

DULでデータブロックの情報を検索できないなら、データベースをスキャンして、マップを作成できる。データファイルからデータをエクスポートしたいなら、データベースをスキャンする必要がある。

（例を説明するためにセグメントヘッダから空っぽなブロックをコピする）

１）ふさわしい“init.dul”と“control.dul”を作成する。

２）テーブルをエクスポートする。これは必ず失敗する。セグメントヘッダには損害がある。

DUL> unload table scott.emp;

. unloading table EMP

DUL: Warning: Block is never used, block type is zero

DUL: Error: While checking tablespace 6 file 10 block 2

DUL: Error: While processing block ts#=6, file#=10, block#=2

DUL: Error: Could not read/parse segment header

0 rows unloaded

３）データベースをスキャンする

DUL> scan database;

tablespace 0, data file 1: 10239 blocks scanned

tablespace 6, data file 10: 2559 blocks scanned

4）DULにセグメントヘッダ情報ではなく、自身で作成したマップを使う必要があると説明してください。

DUL> alter session set use_scanned_extent_map = true;

Parameter altered

Session altered.

DUL> unload table scott.emp;

. unloading table EMP 14 rows unloaded

５.データファイルヘッダが壊れたときに、どうやってデータをエクスポートする。

データベースを起動するときに、データファイルヘッダの損害が示される。データベースが無事に起動できるが、テーブル問合せするときに、損害が示される。

以下の通りのエラ報告をもらえる：

ORACLE instance started.

Total System Global Area 11739136 bytes

Fixed Size 49152 bytes

Variable Size 7421952 bytes

Database Buffers 4194304 bytes

Redo Buffers 73728 bytes

Database mounted.

ORA-01122: database file 10 failed verification check

ORA-01110: data file 10: ‘D:\DATA\TRGT\DATAFILES\JUR1TRGT.DBF’

ORA-01251: Unknown File Header Version read for file number 10

6.システムテーブルスペースなしにどうやってデータをアンインストールするでしょう。

まず、そのアプリケーションとテーブルに十分な理解が必要としている。

列タイプはDULで当てられるが、テーブルも列の名もなくす。

どんな同じデータベースの古いシステムテーブルスペースも大した助けになる。

１）“init.dul”ファイルと“control.dul”ファイルを作成する。この場合にコントロールファイルがリカバリしたいファイルを含んでいるから、システムテーブルスペースが必要としていない。

２）DULで以下のコマンドをインポートしてください：

DUL> scan database;

data file 6 1280 blocks scanned

これでセグメントとセグメントマップも作成される。

３）DULコマンドで以下の操作を実行してください：

Data UnLoader: Release 8.0.5.3.0 – Internal Use Only – on Tue Aug 03 13:33:

Loaded 4 segments

Loaded 2 extents

Extent map sorted

DUL> alter session set use_scanned_extent_map = true;

DUL> scan tables; (or scan extents;)

Scanning tables with segment header

Oid 1078 fno 6 bno 2 table number 0

UNLOAD TABLE T_O1078 ( C1 NUMBER, C2 UNKNOWN, C3 UNKNOWN )

STORAGE ( TABNO 0 EXTENTS( FILE 6 BLOCK 2));

Colno Seen MaxIntSz Null% C75% C100 Num% NiNu% Dat% Rid%

1 4 2 0% 0% 0% 100% 100% 0% 0%

2 4 10 0% 100% 100% 100% 0% 0% 0%

3 4 8 0% 100% 100% 100% 0% 0% 50%

“10” “ACCOUNTING” “NEW YORK”

“20” “RESEARCH” “DALLAS”

“30” “SALES” “CHICAGO”

“40” “OPERATIONS” “BOSTON”

Oid 1080 fno 6 bno 12 table number 0

UNLOAD TABLE T_O1080 ( C1 NUMBER, C2 UNKNOWN, C3 UNKNOWN, C4 NUMBER,

C5 DATE, C6 NUMBER, C7 NUMBER, C8 NUMBER )

STORAGE ( TABNO 0 EXTENTS( FILE 6 BLOCK 12));

Colno Seen MaxIntSz Null% C75% C100 Num% NiNu% Dat% Rid%

1 14 3 0% 0% 0% 100% 100% 0% 0%

2 14 6 0% 100% 100% 100% 0% 0% 21%

3 14 9 0% 100% 100% 100% 0% 0% 0%

4 14 3 7% 0% 0% 100% 100% 0% 0%

5 14 7 0% 0% 0% 0% 0% 100% 0%

6 14 3 0% 0% 0% 100% 100% 0% 0%

7 14 2 71% 0% 0% 100% 100% 0% 0%

8 14 2 0% 0% 0% 100% 100% 0% 0%

“7369” “SMITH” “CLERK” “7902” “17-DEC-1980 AD 00:00:00″ “800” “” “20”

“7499” “ALLEN” “SALESMAN” “7698” “20-FEB-1981 AD 00:00:00″ “1600” “300” “30”

“7521” “WARD” “SALESMAN” “7698” “22-FEB-1981 AD 00:00:00″ “1250” “500” “30”

“7566” “JONES” “MANAGER” “7839” “02-APR-1981 AD 00:00:00″ “2975” “” “20”

“7654” “MARTIN” “SALESMAN” “7698” “28-SEP-1981 AD 00:00:00″ “1250” “1400” “30”

Note : it might be best that you redirect the output to a logfile since

commands like the “scan tables” can produce a lot of output.

On Windows NT you can do the following command :

C:\> dul8 > c:\temp\scan_tables.txt

scan tables;

exit;

４）ステップ３のインポートでなくしたテーブルを見つけ出す。そして、unload文法があるのに、テーブルの名はまだT_0、列の名もC。データタイプは前のデータタイプにマッチしない。

特に“Oid 1078 fno 6 bno 2 table number 0”のような文字列を探す時に、oid = object id, will be used to unload the object目標idは目標をエクスポートするために使われる。

fno = (data)file number （データ）ファイル番号

bno = block number ブロック番号

5）“unload table”コマンドで見つけたテーブルをエクスポートする：

DUL> unload table dept (deptno number(2), dname varchar2(14),

loc varchar2(13)) storage (OBJNO 1078)

Unloading extent(s) of table DEPT 4 rows.

コメント：

DULディスクヘッドのコピー

ディスクヘッドのコピー

最近はASMディスクヘッダエクストラなコピもあって、kfedとリカバリオプションで、本当のヘッダをリカバリできる。割り当てユニットのディフォルト大きさは４Ｋで、

位置

このコピはPSTの最後のブロックと格納されて、アロケーションユニット最後のブロックに意味する。各auに256ブロックがある。

Kfedリカバリ：

唯一な問題はディスクヘッダをなくした/壊れたことを確かめた時に、リカバリがすごく容易くなる：

$ kfed repair

Suの大きさが非標準であれば、以上の操作が失敗して、以下のようにインポートする：

KFED-00320: Invalid block num1 = [3] , num2 = [1] , error = [type_kfbh]

だが、これは予想内で、何の損害もないから。正確なauの大きさを指定すればいい。例えば、4MB AUのコマンドは：

$ kfed repair ausz=4194304

DUL

DULはヘッダコピを検索/使う（いつも？あるいは主なヘッダが壊れた場合に限る？）。もしヘッダが壊れたら、コピがまだ壊れていない場合に、kfedを使うことをアラームする？

参考

Bug 5061821 OSツールはASMディスクヘッダfixed 11.2.0.1，11.1.0.7，10.2.0.5を破壊できる。

注意：417687.1は今のディスクヘッダが壊れた後で新しいASMディスクヘッダを作成する。

rdbms/src/client/tools/kfed/kfed.c

DULはスキャンしたlobをエクスポートする。

LOBからLOBをエクスポートするほうがいいと思う

以下のようなことを確かめる必要がある：

CLOBかBLOBか
CLOBに対しての文字セット、シングルバイトまたはUCS16、バイトサイズ
ブロックサイズ、ヘッダでのlob page＃はfat page number
なくしたページはすべてゼロになる
サイズを知らないが、trailing zeroesを剥奪すればいい？

実行変更：

１. LOBセグメントIDを追加して、lobページ情報をスキャンする。つまり、スキャンしたlobページメモリーの配置はsegid，lobid，fatpageno（chunk＃），version wrap, vsn base, ts#, file#, block#

やるべきこと：

すべてのLOBコマンドをエクスポートする。LOBセグメントでコマンドすべての一般的なプロパティを提供できる。
LOBセグメントからlobidを指定する。選択可能なサイズ、DBAリストでlobコマンドをエクスポートする。
エクスポートされたlobセグメントコマンドを分析する。
セグメントからエクスポートされたLOBコマンドを分析する。

考える必要があること：

file#, block# をdba？pro no calculations, contra more difficult to readに変更する?

お客様とデータサルベージ操作の途中で、DULには問題が起きた。

dul4x86-linux.tar.gzエラ：version ‘GLIBC_2.11’ not found

dul4i386-linux.as3.tar.gzエラ：：You need a more recent DUL version for this os.

クライアントLinuxバーション：2.6.32-400.33.2.el5uek

助けてください！！！

Linux有两个版本，这是第二个，被正常启动的。由于内建复制的保护，您必须确保从Bernard的网站上下载最新的版本。DUL大约每45天失效。

Linuxには二つのバーションがある。正確に起動されたのは二つ目。内蔵コピーを保護するために、Bernardから最新なバーションをダウンロードしてください。DULは約45日で使えなくなる。

大事な時でDULでproduction downデータベースからデータを抽出したい。

– データベースはNOARCHIVELOGモード/ Windows 64位プラットフォームにある。

– go lifeのせいで，使用可能なデータベースバックアップがない

-データベースが小さいが、とっても重要である。

-朝からメディア障害が出て本当のお客様のデータファイル以外のすべてのデータベースのデータファイルを壊した。

-システムテーブルスペースが100％に壊滅した。

-どこにもシステムテーブルスペースのバックアップもない、ましてテストシステムは新たなデータベースのために作成されたから、目標ID，rfileも違っている。

以下の内容を試した：

システムデータファイルでデータをエクスポートする。（システムデータファイルが壊れたから、bootstrapできない）。
システムデータファイルでTESTからデータをエクスポートする（bootstrapできたがエクスポートできない。rfile＃，TS＃にマッチできないから、予想できたが、試しがいがある）。
実際のデータだけでデータファイルをエクスポートする、scaned_tablesを作成できた。お客様の要請に応じてテーブルのリストを提供してmapしたが、お客様が正確な情報を提供できるかどうかにはまだ知らない。

どんなアドレスも大歓迎、例えば：

-　どうやって壊れたシステムテーブルスペースのデータファイルをリカバリして、データをエクスポートするでしょうか

– rfile#, ts#及び目標idがミスマッチした場合に。どうやってTESTからシステムデータファイルを使うでしょうか（異なるデータベースをインストール）

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

PRM-DUL ORACLE 数据恢复软件总贴

2014/12/11 by admin Leave a Comment

PRM-DUL ORACLE 数据恢复软件总贴PRM-DUL 是一个基于JAVA语言编写的DUL类软件，其引入了图形化界面GUI和DataBridge特性。全程GUI使得用户无需大量时间去学习命令行操作，直接可操作PRM-DUL从受损的ORACLE数据库中抽取数据。 DataBridge特性让抽取到的受损数据库的数据可以直接导入到目标库中，像DBLINK一样简单，而不需要使用sqlldr 或者 exp/imp来操作。PRM-DUL目前有2个版本：

社区版：
在完全免费的社区版中，数据抽取和数据搭桥的行数限制是一万行。ASM文件克隆功能在社区版中全面可用。企业版：
购买企业版意味在一套数据库(一个license对应一套数据库)内完全使用PRM的所有功能，没有任何限制购买PRM-DUL，请联系我们：国内热线号码： 13764045638 备用电话：13764045638
ORACLE技术专家服务邮箱：　service@parnassusdata.com

PRM-DUL 最新版本下载地址：
https://zcdn.parnassusdata.com/DUL5108.zip

PRM-DUL 中文版用户手册：
http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database用户手册%20v0.3.pdf

PRM-DUL For Oracle Database中文介绍：

http://www.parnassusdata.com/sites/default/files/PRM%20–%20PARNASSUSDATA%20RECOVERY%20MANAGER%20For%20Oracle%20Database介绍手册.pdf

PRM-DUL FOr Oracle Database 英文版使用手册：

Oracle PRM-DUL User Guide V0.3

PRM-DUL成功案例：

PRM ORACLE数据恢复视频教学：

prm dul恢复oracle数据库最简模式 http://zcdn.parnassusdata.com/prm%20dul%20recover%20oracle%20database%20easiest%20way.mp4
prm dul使用数据搭桥传输Oracle表数据 http://zcdn.parnassusdata.com/prm%20dul%20databridge%20transfer%20oracle%20table.mp4
prm dul在损坏数据库使用exportddl导出建表语句、索引、存储过程、函数等代码 http://zcdn.parnassusdata.com/prm%20dul%20export%20ddl%20from%20corrupted%20oracle%20database.mp4
prm dul恢复oracle中被delete的数据 http://zcdn.parnassusdata.com/prm%20dul%20recover%20oracle%20deleted%20rows.mp4
prm dul恢复oracle中被truncate的数据 http://zcdn.parnassusdata.com/prm%20dul%20recover%20oracle%20truncated%20table.mp4
prm dul用户级别的数据搭桥 http://zcdn.parnassusdata.com/prm%20dul%20schema%20level%20databridge.mp4
prm dul在ASM存储情况下的最简模式 http://zcdn.parnassusdata.com/prm%20dul%20easiest%20way%20with%20ASM%20storage.mp4
prm dul恢复oracle中被drop掉的表 http://zcdn.parnassusdata.com/prm%20dul%20recover%20oracle%20dropped%20table.mp4
prm dul恢复oracle 12c以后可拔插数据库PDB/CDB中的数据 http://zcdn.parnassusdata.com/prm%20dul%20work%20with%20oracle%2012c%20pdb%20pluggable%20database%20container%20database.mp4
prm dul恢复被恶意加密的Oracle数据文件 http://zcdn.parnassusdata.com/prm%20dul%20recover%20malware%20ransomware%20corrupted%20oracle%20datafile.mp4
prmscan oracle数据块重组恢复解决方案 http://zcdn.parnassusdata.com/prmscan.mp4

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

ORACLE数据字典受损导致数据库无法打开的恢复 PRM-DUL

2014/12/09 by admin Leave a Comment

D 公司的DBA由于误操作删除了TS$数据字典基表导致数据库无法启动

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production

With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options

INSTANCE_NAME

—————-

ASMME

SQL>

SQL> select count(*) from sys.ts$;

COUNT(*)

———-

SQL> delete ts$;

5 rows deleted.

SQL> commit;

Commit complete.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-01405: fetched column value is NULL

Process ID: 5270

Session ID: 10 Serial number: 3

Undo initialization errored: err:1405 serial:0 start:3126020954 end:3126020954 diff:0 (0 seconds)

Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc:

ORA-01405: fetched column value is NULL

Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc:

ORA-01405: fetched column value is NULL

Error 1405 happened during db open, shutting down database

USER (ospid: 5270): terminating the instance due to error 1405

Instance terminated by USER, pid = 5270

ORA-1092 signalled during: ALTER DATABASE OPEN…

opiodr aborting process unknown ospid (5270) as a result of ORA-1092

此场景中由于数据字典已经损坏，所以想要正常打开数据库是十分困难的。

此时则可以使用PRM来抽取数据库中的数据。具体步骤与场景1中的相似，用户仅仅需要输入该数据库的所有数据文件即可，其简要步骤如下:

Recovery Wizard
选择字典模式 Dictionary Mode
合理选择Big或者Little Endian
加入数据文件并点击Load
根据实际需求恢复表中的数据

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

误删除/丢失/损坏的SYSTEM表空间且无备份情况下的Oracle数据恢复 PRM-DUL

2014/12/08 by admin 1 Comment

D公司的SA系统管理员误删除了某数据库的SYSTEM表空间所在数据文件，这导致数据库完全无法打开，数据无法取出。在没有备份的情况下，可以使用PRM恢复接近100%的数据。

此场景中启动PRM后，进入Recovery Wizard后选择《Non-Dictionary mode》非字典模式:

No-dictionary模式下需要用户指定字符集和国家字符集，这是因为丢失了SYSTEM表空间后，数据库的字符集信息无法正常获得，所以需要用户的输入。只有输入正确的字符集设置以及安装了必要的语言包才能保证No-Dictionary模式下正常抽取多国语言。

与场景演示1类似，输入用户目前可得的所有数据文件(不包括临时文件)，并设置正确的Block Size和OFFSET:

之后点击SCAN，SCAN的作用是扫描所有数据文件上的Segment Header，并记录到SEG$.DAT和EXT$.DAT中；在ORACLE中一个非分区表或者一个分区表的分区都对应着一个SEGMENT HEADER数据段头，只要能找到SEGMENT HEADER就可以获得整个表数据段的盘区EXTENT MAP 信息，通过EXTENT MAP可以获得该表上的全部记录。

通常存在这样一种情况，例如一张非分区的单表存放在某个由2个数据文件组成的表空间上，其SEGMENT HEADER以及一半的数据存放在A数据文件上，另一半数据存放在B数据文件上。但是由于某些原因，SYSTEM表空间和存放有SEGMENT HEADER的A数据文件均丢失了，只剩下B数据文件了，此时若希望仅仅恢复B数据文件上该表的数据，则不能依赖于SEGMENT HEADER，而只能依赖于从B数据文件上扫描盘区图EXTENT MAP信息了。

为了同时满足基于SEGMENT HEADER和EXTENT MAP数据的NO-Dictionary模式恢复需要，所以SCAN操作在这里会填充SEG$.DAT和EXT$.DAT2个文件(文本文件仅仅为了便于诊断，所有程序实际依赖于PRM自带嵌入数据库DERBY的数据)，并记录到DERBY数据库中。

完成SCAN 后，主界面左侧出现数据库图标。

此时可以选择2种模式：

Scan Tables From Segments，此模式适用于
- 丢失了SYSTEM表空间，但是所有的应用数据表空间均存在
Scan Tables From Extents
- 不适用于Dictionary模式的Truncate表数据恢复
- 丢失了SYSTEM表空间，而且丢失了SEGMENT HEADER所在数据文件

通俗地说除非你无法使用场景2中的方式来恢复已经TRUNCATE掉的数据，否则总是优先使用Scan Tables From Segments模式，如果发现Scan Tables From Segments下找不到你要的数据，再考虑使用Scan Tables From Extents模式。

我们优先采用Scan Tables From Segments模式

Scan Tables From Segments完成后可以点开主界面左边的树形图：

Scan Tables操作基于SEG$中的SEGMENT HEADER信息来构建数据表信息，树形图上每一个节点表示一个数据表段，其名字为obj+ 数据段上记录的DATA OBJECT ID 。

点中一个节点并观察主界面右侧边栏：

智能字段类型解析

由于丢失了SYSTEM表空间，故NO-Dictionary模式下缺乏数据表的结构信息，这些结构信息包括表上的字段名字和字段类型，而且在ORACLE中这些信息均只保存为字典信息，不会在数据表上存放。当用户只有应用表空间时，需要基于数据段上的ROW行数据来猜测每一个字段的类型，PRM采用先进JAVA类型预判技术，可以解析多达10来种主流数据类型；、

智能解析准确度超过90%，可以自动解决大部分场景。

右侧边栏上部各字段的含义：

Col1 no 字段号
Seen Count: 取到的行数
MAX SIZE: 最大长度，单位为字节
PCT NULL: 采样到的NULL的比例
String Nice: 将该字段解析为字符串，并成功的比例
Number Nice: 将该字段解析为数字，并成功的比例
Date Nice: 将该字段解析为Date，并成功的比例
Timestamp Nice: 将该字段解析为Timestamp，并成功的比例
Timestamp with timezone Nice: 将该字段解析为Timestamp with timezone Nice，并成功的比例

示例数据分析Sample Data Analysis:

该部分依据智能字段类型解析的结果来解析10条数据，并显示解析结果。通过示例数据可以帮助用户了解实际该数据段中存放数据的情况。

如果数据段上记录条数不足10条，则显示所有记录。

TRY TO ANALYZE UNKNOWN column type:

该部分是对于智能字段类型分析不能100%确认的字段，尝试用各种字段类型来解析，并呈现给用户，以便用户自行判断其究竟是什么类型。

目前PRM还不支持的类型包括：

XDB.XDB$RAW_LIST_T、XMLTYPE、用户自定义类型等

Unload Statement:

这部分是PRM生成的UNLOAD语句，此生成的UNLOAD语句仅作为系统内部使用和PRM开发团队以及ParnassusData原厂支持工程师使用。

在此《Non-Dictionary Mode》非字典模式下同样可以采用常规和数据搭桥模式，与字典模式相比，主要的区别在于在非字典模式下数据搭桥时用户可以自行执行字段的类型，如下图中中部分字段类型为UNKNOWN，即未知的。这些字段可能是PRM目前还不支持的例如XML字段，也可能是PRM的智能解析没有顺利分析器类型。

如果用户知道这张表设计时的结构（也可以来源于应用开发商的文档），那么可以自行去填选正确的Column Type类型，以便PRM顺利将该表数据搭桥到目标数据库。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

误删除了SYSTEM表空间和部分应用表空间数据文件的Oracle数据恢复 PRM-DUL

2014/12/08 by admin Leave a Comment

D公司的SA由于误操作将在线业务数据库的SYSTEM表空间上的数据文件，以及部分应用表空间数据文件意外删除了。

此场景中由于部分应用表空间数据文件被删除了，这其中可能包括含有数据表的SEGMENT HEADER的数据文件，所以使用Scan Tables From Segment Header可能不如使用Scan Tables From Extents来的合适。

其简要步骤如下：

进入Recovery Wizard ，选择No-Dictionary模，加入所有可用的数据文件，执行Scan Database
选中数据库，并右键Scan Tables From Extents
对于PRM主界面上生成的对象树形图中的数据进行分析和导出/数据搭桥
其余操作与恢复场景4中一样

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

ORA-1578 on Oracle Startup

2014/12/07 by admin Leave a Comment

An ORA-1578 on startup is usually bad news and relates to either a corrupt
rollback segment header, or a corrupt block being referenced during
bootstraping of the instance.

eg:
Database mounted.
ORA-01578: ORACLE data block corrupted (file # 11, block # 2)
ORA-01110: data file 1198: '/tmp/RPrbcor.dbf'
SVRMGR>
( Recovery does not fail if a corrupt block is encountered - the block is
skipped over and recovery continues. Warnings are written to the user
trace file.
eg:
Corrupt block dba: 0x20000003 file=8. blocknum=3. found during
media/instance recovery
on disk type:6. ver:1. dba: 0x2000ffff inc:0x00000001 seq:0x00000007
incseq:0x00010007
Reread of block=20000003 file=8. blocknum=3. found same corupted data
Actions:
1. Shutdown the instance (or you may get ORA-704/ORA-604/ORA-955 when you
next try to open the database)
eg: SHUTDOWN ABORT
2. Although it is possible to offline the affected file/s and double check
which object is involved it is better to first look at recovering the
corrupted file. This is only possible in ARCHIVELOG mode.
eg:
Take a SAFE copy of the existing problem file
Restore a good backup of the problem file
STARTUP MOUNT
ALTER DATABASE DATAFILE 'name_of_file' ONLINE;
RECOVER DATABASE


ALTER DATABASE OPEN;
3. If the ORA-1578 persists or the file cannot be restored then:
a. If this is a SYSTEM tablespace datafile you are in trouble.
Go to "Last Options"
b. If this is not a SYSTEM tablespace datafile you MAY be able to
continue as below.
4. If the ORA-1578 is on a rollback segment header then it is possible
that the header is only being accessed because Oracle is trying to
online the rollback segment. To check for this we can comment out all
of the rollback segments in the init.ora file and attempt to start the
database.
eg: Comment out the ROLLBACK_SEGMENTS=... clause
If you are using PUBLIC rollback segments then also set the init.ora
parameter TRANSACTIONS to a small number (about 20) and
TRANSACTIONS_PER_ROLLBACK_SEGMENT to the same number . Additionally
try to find one rollback segment which is known to be good and set
this in the ROLLBACK_SEGMENTS parameter. This is done to try to stop
Oracle needing to online any PUBLIC rollback segment when the database
opens. If there are no rollback segments you know to be good you can
try this step several times using different named rollback segments.
eg: TRANSACTIONS=20
TRANSACTIONS_PER_ROLLBACK_SEGMENT=20
ROLLBACK_SEGMENTS=(OK_RBS)
Now try to start the database:
eg:
SHUTDOWN ABORT
STARTUP
If the database opens go to step 6
5. If the above has not allowed you to open the database then the next
step is to attempt to offline the problem file:
eg:
SHUTDOWN ABORT
STARTUP MOUNT
ALTER DATABASE DATAFILE 'name_of_file' OFFLINE;
ALTER DATABASE OPEN;
If the "ALTER DATABASE DATAFILE ... OFFLINE" reports
"ORA-01145: offline immediate disallowed unless media recovery enabled"
go to "NOARCHIVELOG" below.
6. If the database opens check which object has the ORA-1578 error.
WARNING: On Oracle8 you need the file number from the accompanying
ORA-1110 error.
SELECT segment_type, owner, segment_name
FROM dba_extents
WHERE file_id=
AND  BETWEEN block_id and block_id+blocks-1
;
If SEGMENT_TYPE is ROLLBACK SEGMENT go to "Recovering Rollback Segments".
If OWNER is SYS more detailed investigation is required to determine
whether the problem object can be rebuilt.
For any other object see Note:28814.1 on how to handle block corruptions.

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

PRM-DUL在Linux/Unix VNC下的显示问题

2014/12/06 by admin Leave a Comment

PRM-DUL在Linux/Unix VNC下的显示问题，PRM-DUL在Linux VNC远程图形化下若出现无法显示菜单栏的问题，那么可以使用快捷键AlT+F7后来拖动窗口，显示出 PRM-DUL的图形化界面。

注意当使用PRM-DUL在恢复大数据量的数据库时优先考虑启用VNC，否则若Xmanager之类的工具出现中断，那么可能需要从头再。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle7 8 8i 9i 10g 11g のOracleブロック損害に対応する

データベースは今ARCHIVELOGモードにあるか否か例えば：SQL*Plus（或 Server Manager）中运行“ARCHIVE LOG LIST”

针对每次坏块需记录的信息

绝对文件

相关文件

块编号

段

初始错误

号

号

表空间

段类型

所有者.名

相关对象

恢复选项

&AFN

&RFN

&BL

称

SELECT tablespace_name, file_id “AFN”, relative_fno “RFN” FROM dba_data_files;

SELECT tablespace_name, file_id+value “AFN”, relative_fno “RFN” FROM dba_temp_files, v$parameter

WHERE name=’db_files’;

SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents

WHERE file_id = &AFN

and &BL between block_id AND block_id + blocks – 1

;

SELECT owner, segment_name, segment_type, partition_name FROM dba_segments

WHERE header_file = &AFN and header_block = &BL

;

SELECT owner, table_name FROM dba_tables

WHERE owner=’&OWNER‘

AND cluster_name=’&SEGMENT_NAME‘

;

SELECT partition_name FROM dba_extents WHERE file_id = &AFN

AND &BL BETWEEN block_id AND block_id + blocks – 1

;

ALTER INDEX xxx REBUILD PARTITION ppp;

SELECT table_owner, table_name FROM dba_indexes

WHERE owner=’&OWNER‘

AND index_name=’&SEGMENT_NAME‘

;

Eg: SELECT owner, constraint_name, constraint_type, table_name FROM dba_constraints

WHERE owner=’&TABLE_OWNER‘

AND constraint_name=’&INDEX_NAME‘

;

P インディクスが主キー制約を支持する

U インディクスが唯一制約を支持する

SELECT owner, constraint_name, constraint_type, table_name FROM dba_constraints

WHERE r_owner=’&TABLE_OWNER‘

AND r_constraint_name=’&INDEX_NAME‘

;

SELECT partition_name FROM dba_extents WHERE file_id = &AFN

AND &BL BETWEEN block_id AND block_id + blocks – 1

;

SELECT owner, index_name, index_type FROM dba_indexes

WHERE table_owner=’&OWNER‘

AND table_name=’&SEGMENT_NAME‘

;

Eg: SELECT owner, constraint_name, constraint_type, table_name FROM dba_constraints

WHERE owner=’&OWNER‘

AND table_name=’&SEGMENT_NAME‘ AND constraint_type=’P’

;

SELECT owner, constraint_name, constraint_type, table_name

FROM dba_constraints WHERE r_owner=’&OWNER‘

AND r_constraint_name=’&CONSTRAINT_NAME‘

;

SELECT table_name, column_name FROM dba_lobs

WHERE owner=’&OWNER‘

AND index_name=’&SEGMENT_NAME‘;

例えば：

SELECT table_name, column_name FROM dba_lobs

WHERE owner=’&OWNER‘

AND segment_name=’&SEGMENT_NAME‘;

ALTER SYSTEM SET EVENTS ‘1578 trace name errorstack level 3’;

set serverout on

exec dbms_output.enable(100000); declare

error_1578 exception;

pragma exception_init(error_1578,-1578); n number;

cnt number:=0; badcnt number:=0; begin

for cursor_lob in

データベースは今ARCHIVELOGモードにあるか否か例えば：SQLPlus（或 Server Manager）中运行“ARCHIVE LOG LIST”*