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

必要な情報

 

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

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

バイナリヘッダ

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

1. VAX VMSとNetware：構造メンバーの間で揃えないままで埋める。
2. 韓国Ticom Unixマシン：構造メンバー16進数揃え
3. MS / DOS ：16進数揃えと16数字長さ。
4. そのほか（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;

1. 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

 

Copyright (c) 1994 2007 Bernard van Duijnen All rights reserved.

 

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

Copyright (c) 1994/95 Oracle Corporation, The Netherlands. All rights reserved.

DUL> scan database;

data file 1 20480 blocks scanned

data file 4 7680 blocks scanned

data file 5 512 blocks scanned

DUL>quit

1. 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

Copyright (c) 1994/95 Oracle Corporation, The Netherlands. All rights reserved.

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

Copyright (c) 1994/95 Oracle Corporation, The Netherlands. All rights reserved.

Session altered.

Session altered.

Session altered.

Session altered.

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

Copyright (c) 1994/95 Oracle Corporation, The Netherlands. All rights reserved.

Session altered.

Session altered.

Session altered.

Session altered.

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

Copyright (c) 1994/95 Oracle Corporation, The Netherlands. All rights reserved.

Session altered.

Session altered.

Session altered.

Session altered.

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

Copyright (c) 1994/95 Oracle Corporation, The Netherlands. All rights reserved.

Session altered.

Session altered.

Session altered.

Session altered.

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

 

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は重なり、前の行にエラがある。新しい行はほかの部分に重なる。

 

 

 

 

 

目录

コラム

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

1. サマリー
2. DULを使う

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

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

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

2.4DULを使う

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

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

• サマリー

この文は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:

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

. 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:

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%

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をエクスポートするほうがいいと思う

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

1. CLOBかBLOBか
2. CLOBに対しての文字セット、シングルバイトまたはUCS16、バイトサイズ
3. ブロックサイズ、ヘッダでのlob page＃はfat page number
4. なくしたページはすべてゼロになる
5. サイズを知らないが、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コマンドを分析する。

考える必要があること：

1. 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も違っている。

以下の内容を試した：

1. システムデータファイルでデータをエクスポートする。（システムデータファイルが壊れたから、bootstrapできない）。
2. システムデータファイルでTESTからデータをエクスポートする（bootstrapできたがエクスポートできない。rfile＃，TS＃にマッチできないから、予想できたが、試しがいがある）。
3. 実際のデータだけでデータファイルをエクスポートする、scaned_tablesを作成できた。お客様の要請に応じてテーブルのリストを提供してmapしたが、お客様が正確な情報を提供できるかどうかにはまだ知らない。

どんなアドレスも大歓迎、例えば：

-　どうやって壊れたシステムテーブルスペースのデータファイルをリカバリして、データをエクスポートするでしょうか

– rfile#, ts#及び目標idがミスマッチした場合に。どうやってTESTからシステムデータファイルを使うでしょうか（異なるデータベースをインストール）