ORACLE DUL ツール使用法を説明する

ORACLEデータベース によくあるエラ の解決策

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

  1、紹介 このファイルはDULを紹介する文だけで、完全なDUL機能ディスクライブじゃない。 DULは別の方法で叶えないデータテストを代わるもので、つまり、exportもSQL*Loaderも使えない。データベースが壊されるかもしれないが、データベースが１００％の正確性を保障してください。エクスポートするときに、すべてのデータベースも正確で正確なセグメントに属していることを保障してください、もしDULに間違えたブロックを見つけ出したら、エラ情報はファイルにインポートするが次の行やブロックにエクスポートすることを中止されない。 2、DULを使う まずはデータベースにエクスポートしたいオブジェクトの該当する情報があるかを確認してください。 USER$, OBJ$, TAB$ 及びCOL$から情報を検索する。 DULはシステムテーブルスペースから情報を獲得する。システムテーブルスペースデータファイルには必ず制御ファイルを含む。もしシステムテーブルスペースファイルが存在していなければ、第六のステップに注目してください。 2.1ふさわしい“init.dul”ファイルを作成する ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ REMプラットフォーム指定バラメタ(NT) REMが獲得できるよくあるプラットフォームのバラメタリスト：。 osd_dba_file_bits=10 osd_c_struct_alignment=32 osd_file_leader_size=1 osd_word_size=32 REM dulディクショナリーメモリサイズ。もし低すぎた場合に、起動できなくなる。 dc_columns=2000000 dc_tables=10000 dc_objects=1000000 dc_users=400 dc_segments=100000 制御ファイルの位置とファイル名で、ディフォルト値はcontrol.dulにある REM 在当前の路径control_file=D:\Dul\control_orcl.dul   データベースブロックサイズがinit.oraのファイルに見つけ出せる。あるいはサーバ管理器に“show parameter %db_block_size%”を実行して、検索する。そのバラメタを壊されたブロックのブロックサイズに変更してください。 db_block_size=4096   データはエクスポート/インポートフォーマットが必要としたら、指定できるように変更してください。REMにはエクスポート/インポートのファイルフォーマットを指定する必要がある。REMはツールが使えるファイルを作成する必要がある、作成されたファイルがEXPによってエクスポートされたファイルと全然違っている。これはテーブル構造やテーブルデータを含むテーブルダンプファイルを作成する。Grantsもストレージ句もトリガーもこのダンプファイルに含んでいない。 export_mode=true （falseはsqlloader,true表示imp） REM　compatible　バラメタは6、7あるいは8に設定できる。 compatible=8   そのバラメタは選択可能で、REMが支持していない長いファイル名（e.g. 8.3 DOS）のプラットフォームに、あるいはファイルフォーマットDULが “owner_name.table_name.ext”を使えないときに指定できる。ここでダンプファイルはdump001.ext，dump002.extに似ている。 file = dump   2.2”control.dul”ファイルを作成する ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   データベースがmountされた状態で、以下のようなクエリを実行して、データベースのロジックテーブルスペースと物理データファイル構造が分かる。 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   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 : 必要とすれば、spoolファイル、データファイルの位置とstripe outに必要としていない情報を編集する。例えばテーブルヘッダなど… 制御ファイルの例は以下の通り： 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 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データオブジェクト情報をエクスポートする ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   ふさわしい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: Copyright (c) 1994/1999 Bernard van Duijnen All rights reserved.   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   USER$, OBJ$, TAB$ and COl$ データディクショナリーのデータを SQL*Loader ファイルにエクスポートする。これはインポートフォーマットのダンプファイルに格納できない。 バラメタ export_mode = false 　ddlスクリプトに移して、“true”に変更できない。DULにエラを招くことになるから： . unloading table                                     OBJ$ DUL: Error: Column “DATAOBJ#” actual size(2) greater than length in column definition(1) ………….etc……………   2.4　DULを使う ~~~~~~~~~~~~~~ 交換モードでDULを起動する、すべてのｄｄｌコマンドも含むスクリプトを前もって用意して、必要としたデータベースのデータをエクスポートする。このファイルによく使われるコマンドを説明するが、これは完全なバラメタリストじゃない。 DUL> unload database; =>これでデータベースごとにエクスポートする（SYSのテーブルも含む）   DUL> unload user <username>; => これで指定したすべてのユーザーが持っているテーブルをエクスポートする。   DUL> unload table <username.table_name>; => これで这将导出用户所指定の表   DUL> describe <owner_name.table_name>; これでテーブルの情報を示す。   DUL> scan database; => すべてのデータファイルのすべてのブロックをスキャンする。 二つのファイルが作成される： 1：seg.datが見つけ出したセグメントヘッダの情報（インディクス/グルプ/テーブル）（オブジェクトID，ファイル番号とブロック番号）。 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（プログラムパッケージ、プロセス、関数、トリガー）を再構造する。Grants、インディクス、制約あるいはストレージ句（古いテーブル構造）は悪くないが、少々ややこしくなった。DULで関連するデータディクショナリーテーブルをエクスポートする必要がある。そして、これらのテーブルを新たなデータベースにロードする。壊れたデータベースのデータディクショナリーを新たなデータベースディクショナリーにロードすることが新たなデータベースを壊すかもしれない。   例は壊れたデータベースからpl/sql、package、ストレージプロセス、関数ｐについての詳しい情報を検索する： 1）「DULを使う」という節に語ったステップに沿い、データディクショナリーテーブルsource$を説明してエクスポートする。 2）新しいユーザーを作成し、無傷のデータベースに登録して、必要とするディフォルト一時的なテーブルスペースを指定する。 3）リンク、リソース及び imp_full_databaseの権限を新しいユーザーに与える。 4）テーブル“source$”を新たに作成したモードへエクスポート/ロードする： 例えば：imp80 userid=newuser/passw file=d:\dul\scott_emp.dmp log=d:\dul\impemp.txt full=y 5）ここで、newuser.source$テーブルから壊れたデータベースを探し出して、pl/sql packages / procedures /functionsを再構造する。WebIvにこのようなPL / SQLが見つけ、スクリプトを作成する。   同じステップがインディクス、制約、ストレージバラメタを再構造するときにあるいは該当するユーザーに権限を与えるときに使える。いつもあるタイプを使う必要があるときにオブジェクトを再構造して、壊れたデータベースのすべての機能をリカバリできる。例えば：壊れたデータベースのバーションは7.3.4バーションの場合に、いくつビットマップインディクスを持っているはず。7.3.2バーションあるいは前のスクリプトを使う場合にビットマップを再構造できなくなる。     4.セグメントヘッダブロックが壊れた場合にどうやってデータをエクスポートできるか ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DULが通常の方法でデータブロック情報をを検索できないが、データベースをスキャンすることによって、自身セグメント、領域情報を作成できる。データファイルからデータをエクスポートして、データベースをスキャンするプロセスが必要としている。 （この例を説明するために、セグメントヘッダブロックによって、空のブロックをコピした） 1）init.dulとcontrol.dulを作成する 2)テーブルをエクスポートして、ヘッダブロックに損害があるから失敗した。 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 3）データベーススキャンを実行する 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   5、データファイルヘッダが壊れた場合にどうやってデータをエクスポートできるか ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ データベースを起動するときに、いつもデータファイルヘッダブロックが壊れたと報告する。これはセグメントヘッダが壊れた場合と違って、その中のデータベースが起動できる。そしてテーブルを検索するときに限って、エラ情報が報告される。この場合に対してDULでリカバリできる。 以下のようなエラが報告される： 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、システムテーブルスペースなしにどうやってデータをエクスポートできるか ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ システムテーブルスペースが使えなければ、エクスポートすることが持続できるが、オブジェクト情報がデータディクショナリーテーブルUSER $，OBJ $，$ TAB和COL $から検索できなくなった。故に所有者の名前もテーブル名も列名もDULディクショナリーにロードしない。RDBMSについての知識が必要とするから、テーブルを識別することが大変になる。 まずは、アプリとそのテーブルに詳しい知識が必要としている。列タイプがDULで当てられるが、テーブルも列の名もなくなる。 同じデータベースにどんな古いシステムテーブルスペースも力になれる！ 1）“init.dul”ファイルと“control.dul”ファイル作成する。この場合に制御ファイルにリカバリしたいすべてのデータファイルも含んでいるが、システムテーブルスペースの情報が必要としていない。 2）では再びDULを使って、以下のコマンドを入力する： DUL> scan database; data file 6 1280 blocks scanned これでセグメントとセグメント情報を作成する。 3）DULを再び使って、DULで以下の操作を実行してください：   Data UnLoader: Release 8.0.5.3.0 – Internal Use Only – on Tue Aug 03 13:33:   Copyright (c) 1994/1999 Oracle Corporation, The Netherlands. All rights res 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% “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)); “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; 4）ステージ３のインポートからなくしたテーブルを見つけ出す。以上のアウトプットを観察すれば、unload从步骤3の输出中找到丢失の表;如果你仔细看上面の输出会发现，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.