DUL Data UnLoaderでOracleデータを救う

 

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

 

  • Chapter 1: 概要
  • Chapter 2: 基礎知識
  • Chapter 3: バラメタとコマンド
  • Chapter 4: 簡単なデータをリカバリする場合
  • Chapter 5: 複雑なデータをリカバリする場合
  • Chapter 6: データをロードする
  • Chapter 7: 内部ファイル
  • Chapter 8: 実験
  • 前提:
  • Oracleデータベース構造を解明する
    • ハイレベルファイル構造
    • インスタンスプロセス
  • Oracleデータベースの動作を解明する
    • データベース状態: started, mounted, open, shutdown
    • インポート/エクスポートツール
    • SQL*Loader
  • 概念
  • いつにData UnLoaderを使うか?
  • 正常なるデータリカバリ
  • 特徴
  • 制限
  • 主な適用範囲
  • 予想した結果

Overview:  概念:Data UnLoaderとは何か?

  • Bernard van Duijnenによって開發されたCプログラムである
  • データベースファイルから(*.dbf)のテーブルとclusterからデータを抽出する
  • 標準なDumpを構成して、 files (*.dmp) または SQL*Loader コントロール/データファイルのコンビ (.ctl/.dat) でデータを新たな機能データベースに導入する
  • インストールしているあるいは起動したデータベースインスタンスに頼らない独立したアプリ

Overview:  概念: どうやって使えるか

  • データファイル(.dbf)を直にスキャンすることでフォーマットされたデータをリカバリする
    • もし使えるなら、データ/セグメント/範囲及びメータデータもSYSTEM.dbfファイルから抽出する
    • もしSYSTEM.dbf ファイルが使えなければ、ユーザーの知識によって、データ/セグメント/範囲情報を抽出する。
  • Dirty read (書き込みディスクのデータが抽出され、メモリのデータがなくした。アーカイブログが使われていない)
  • 代わり対策として、標準export (.exp)またはデータpumpファイル (.edp)からデータを抽出する (まだ実行中のタスクですが)

Overview: 概念:セキュリティ

  • データセキュリティ
    • DULは直に.dbf ファイルを読み出す
      • データベースか徹底的に使えなくなってもいい
      • データベースにアクセスしているuseridをテストしていない
      • 抽出されたデータが読み取りやすい
  • プログラムセキュリティ
    • DUL 実行可能なファイルの可用性も配置も厳密に制限された

概念: 履歴

    • エンジニアが現場に操作する必要がある
    • エンジニアはお客様の設備にDUL実行なファイルをインストール/削除することを担当する
    • リモートは主流
    • 一部の時間に基づき、低いレベルのレプリケーションプロタクトは45日後にDULを無効化させる

注意: 多くの政府にはリモートでアクセス出来ないから、今でも現場でやる必要がある 

概念: “リモートアクセスオプション

  • お客様が直にホスト(VPN/putty)にアクセスできる
    • これもお客様のセキュリティ部門に関わるから、拒否されたら、再び認められるまで、かなり時間をかかる。
  • Webex または Beehivesessionを共有することで、DBAの動作を確認する。
    • DUL.exeがメールあるいはftpDBAへ送る。
  • このプロセスによってDBAを検討する
    • DUL.exeがメールあるいはftpDBAへ送る。
    • コントロールファイルを配置して、メールでDBAへ送る
    • ASE DULに対して詳しい知識を持つ必要がある

いつにData UnLoaderを使うか?

  • 一般的に言うと、グローバル製品によって、(GPS)サービスリクエスト次第に決めてください。
  • すべての記録も非法データリカバリもテストされ、拒否された後に限る
  • 正常なデータベース/データリカバリ方法が適用出来ない場合
    • 使用可能なバックアップがない
    • バックアップが足りないからデータがなくした
    • 内部エラまたは損害により、データベースが起動できなくなった
    • 正常なリカバリ方法で、 MTTR(平均リカバリ時間)が納得出来ない (i.e. アーカイブログが多すぎたから利用できない)
    • システムデータファイルがなくした
    • 壊れたデータファイルがテーブルスペースをオフラインする
  • DULはほかの手段で検索できないデータを検出できる
  • これはデータベースリカバリの代わり対策じゃない。
  • これはあくまで最後の手だから、常に使われるのはあまり勧めない
  • 注意: 検出できたデータロジックが一致していないかもしれない。

Ø必ず成功するとは限らない!

  • これは損害が予想できないから、すべてのデータベースとデータタイプの相違によって利用できない場合もある。

いつにData UnLoaderを利用するか?

  • DULはほかの手段で検索できないデータを検出できる
  • これはデータベースリカバリの代わり対策じゃない。
  • これはあくまで最後の手だから、常に使われるのはあまり勧めない
  • 注意: 検出できたデータロジックが一致していないかもしれない。

Ø必ず成功するとは限らない!

まともなデータベースリカバリ

  • 今のデータベースリカバリオプション(人工)
    • 前回のバックアップをリカバリして、アーカイブログでロールフォワード
    • 前回の完全バックアップからインポート/エクスポートする
    • SQL*Loaderでソースデータからデータをロードする
    • パラレルでテーブルを作成し、(PCTS)を選択する
    • テーブルスペースを使う
    • コーピーデータベースを作成し、データをエクスポートして、インポートする
  • RMAN (より自動化)
    • 適切なコマンドでRMAN sessionを起動する
  • 無証 init.ora データベースバラメタ
    • _corrupted_rollback_segments
    • _allow_resetlogs_corruption
  • 診断/編集ツール
    • opatch (かなり古いツール,Notes 28864.1, 33182.1を参考する)
    • ブロックブラウザ/編集器 (BBED)
      • 注意: BBED 11gからの配置式じゃない

まともなデータベースリカバリ:制限

  • システムテーブルスペースあるいはデータファイルがなくした場合に代わりものがない
  • データベースはかなりいい調子を保つ必要がある、さもなければ、リカバリできない
  • データファイルを編集するのがめんどくさくて危険である。しかも必ず有効とは限らない。
    • 大量な内部構造知識が必要としている
  • 一部の損害が編集出来ない

サポートする機能

  • Oracle v6 から v11 (12?)まで
  • 多数のプラットフォームに利用できる(すべてじゃない)
    • Linux, AIX, Solaris, Windows
    • 8/13/12から、DUL for HP-UX が使えなくなった
    • プラットフォームをまたがって抽出することができるようになった。
  • これは標準リカバリ方法の代わりものじゃない
  • オフィシャルに支持されていない
  • 最後の手として利用する!
  • もしシステムデータファイルが使用できれば、データディクショナリーを読み取る
  • けど、システムデータファイルがなくともデータを抽出することができる。
    • システムデータファイルがなければ、ユーザー/オブジェクト/列の名前もなくなる
  • 特定なテーブルをアンロードして、モード(ユーザ)のテーブルによる
  • 不完全なテーブルからセグメントをアンロードできる
  • プラットフォームをまたがってアンロードできる。
    • i.e. Windowsからアンロードして、UNIXにロードする
  • 標準なOracleデータベース構造

支持する機能:構造

  • リンク行、行移行
  • hash/index グルプ
  • longs, raws, blobs
  • rowids, dates, numbers
  • 複数の暇リストグルプ
  • segment high water mark
  • unlimited extents

支持する新機能

  • 可配置为自动存储管理(ASM)
  • 简化配置(表空间和相对的文件号现在直接从.dbf 文件读取)
  • Unexp (从一个导出文件中提取)
  • Unpump (从一个数据pump文件中提取)
  • SQL*Loader 现在可用于long rawsblobs
  • 注意: DUL 当前版本为 10.2.0.5.31
    • 基础版本从6/9/2011开始

Limitations / Restrictions

  • データベースが壊れてもいいが、一つ一つのモジュールが損害されてはいけない。
  • DULは一部のテーブルとグルプデータをアンロードする
  • MLSLABELSを支持しない
  • 一部の11 g機能を支持しない
  • DUL v10 v11 datafilesに使える

11g 機能の制限 (11/2012)

  • 11g セキュリティファイルlobsはベタテスト段階にある
  • マックセキュリティを支持していない
  • 暗号化は未だに支持されていない
  • exadata cellsASMディスクを支持していない
  • セグメントサイズを変更できる11g ASM ASM を支持する
  • export_modeには複雑なタイプを支持していない
  • export_modeで作成されたdumpファイル=true メータデータを含まない

主要的适用范围

  • engegementを続行する前に、以下のようなことを決めてください:
    • どんなプラットフォーム? OS version? DB version? Blocksize?
    • Is the DB up or down? インストールできるか?起動できるか?
    • SYSTEM.dbf データファイルが使用できるか?リードできるか?
    • リモートアクセスできるか?現場で操作する必要があるか?
    • 抽出する必要があるデータベースあるいはテーブルのサイズ?
    • データフォーマットは何か? Export? SQL*Loader?
    • ディスクスペースアウトプットが足りるか?
    • 必ず成功するとは限らない。

予想した結果

  • ASEから
    • お客様の環境と条件を評価する
    • 必要とするデータは何かを確認する
    • DUL を配置し、データを抽出する
    • 最善を尽くし、DULによってデータでエクスポートしたダンプファイルまたはSQL Loader ファイルをお客様へ提出する
    • お客様を助ける
      • DULログを説明する
      • データをロードしてテストする
  • お客様から
    • すべての必要とする .dbf ファイルをアクセスする-+988 (telnet, owc, ftp?)
    • 新たなデータベースを立ち上げる(例えば、データベースが起動出来ない場合)
    • データをテストしてロードする
    • もしSYSTEM.dbfがなくしたら、アプリ開發者あるいは技術サポートによって、アプリの名前と列をリネームする
    • なくした必要とするすべてのオブジェクトを再構造する(インディクス、トリガー..)
  • アプリケーション機能をテストする
  • よくある質問
    • DUL engagementがどれほどの時間をかかるか?
      • インストール時間はThe setup time depends on次第
        • どんな.dbf ファイルが使えるか
        • 遇到的是哪种损坏?
      • 抽出時間はデータベースのサイズによる
      • 説明結果の時間は
        • SYSTEM.dbfの可用性による
      • データベースの時間を再びロードする
        • ロードが完成した場合に、ASEも必要じゃない

DULの未来

Øより多くのお客様が支持されない機能を利用することに伴って、DUL がいろいろと制約された。

  • 新たなOracleにはデータを保護する/リカバリする機能が加わった。 (i.e. flash リカバリ/Flash back)

Ø日々に多くなるお客様が新たな機能を利用することによって、DULへの注目も減っていくはずである。

1) DULを配置して運用したら、 dul.logに未知のエラが現れた。次のオプションですぐに助けをもらえる。

service@parnassusdata.comへメールするあるいは + 86 13764045638

3) DULのインポートは何か?

a)Export .dmp files

b)SQL*Loader .dat files

c)SQL*Loader .ctl files

d)A dul.log

e)すべても

f)インポートがない。 DULでその場でデータをリカバリする

4) 損害されていないSYSTEM.dbfデータファイルがあれば、,DUL は必要なユーザーデータを抽出できる。ダンプエクスポートファイルあるいはSQL*Loader .datデータファイルをフォーマットする。

a)True

b)False

5) 損害されていないSYSTEM.dbf datafile,、エクスポートファイルをインポートするあるいはSQL*Loaderを実行すればいい。

a)True

b)False

6) 一部のお客様がSYSTEM.dbf datafile, DULをなくしても使用可能なデータを抽出できる。

a)True

b)False

2: 基礎知識Interactive and batch mode

  • 前提:
    • Oracleデータベースサーバに詳しい
      • imp の利用、Interactive and batch mode
      • SQL*Loaderの使用
    • UNIX/Windows 命令行级有初步了解
      • vi UNIX上的其他文本编辑器
      • Windows上的记事本
      • DataUnLoader_Toolkit.zipをダウンロードする
      • DataUnLoader_Labs.zipをダウンロードする
  • Data UnLoader構造
  • 何か必要とするか?
  • DULを配置する
  • DULをインストールして運用する
  • アウトプットログを確認する

Data UnLoader 構造

  • INPUT
    • .dbf datafiles (オフラインコピでもいい)
    • 2 .dul “制御ファイル (DB制御ファイルじゃない)
    • DUL> ヒントのユーザーコマンド
  • dul.exe dul (一つのファイルは约500k)
  • OUTPUT
    • .dmp files あるいは
    • .ctl .dat files (for SQL*Loader)
      •  schema_tablename.filetypeと名付ける
    • ログファイル(dul.log)

何か必要とするか?

  • データをなくした? Dbfを得た? dul.exe?を要する
  • プラットフォームに対してふさわしいファイルをダウンロードする
  • 最善例: 現場にいくなら、内部Oracleアクセスが順調に進めるために、前もってすべてのプラットフォームをダウンロードしてください。
  • init.dulを立ち上げて配置する
  • OS DBに関するバラメタ、コマンド
  • control.dulを立ち上げて配置する
  • データファイルをディスクにインメージする
  • 今はASM を支持するようになった

init.dulを配置する

  • DULdatafiles (.dbf)のフォーマット、プラットフォーム及びどんなアウトプットのバラメタを使うか
  • ここの情報は以下のようなことを指定した
    • DUL メモリサイズ
    • header
    • Oracle ブロクサイズ
    • アウトプットファイルフォーマット
    • Sql*Loader フォーマットと記録サイズ
    • ほかの選べるコマンド
  • DUL メモリサイズを配置する
  • これは足りるサイズでDBA_TAB_COLUMNS, _TABLES, _OBJECTS, and _USERS テーブルを含む必要がある
    • DC_COLUMNS =
    • DC_TABLES =
    • DC_OBJECTS =
    • DC_USERS =
  • 注意: DULはこれらを最小値として使う。実際に利用するときに、増やす必要がある。
  • プラットフォームに関するバラメタを配置する
  • OSD_BIG_ENDIAN_FLAG = true/false

-“エンディアン一つ構造中位の配列

高位優先プラットフォームで、ある単語四つのバイトに配置された。

-Little endian ordering

注意:  DB >= 10gにたいする唯一のosd parm

  • OSD_DBA_FILE_BITS =
  • OSD_C_STRUCT_ALIGNMENT =

データファイルヘッダの構造配置。

  • OSD_FILE_LEADER_SIZE =

-Oracle ファイルヘッダのブロック/バイト数。 Unix datafiles 例外のヘッダブロックがある(ファイルサイズ、ブロックサイズ数)

プラットフォーム特定のバラメタ値

PORT         PLATFORM          ENDIAN FBITS67  FBITS8 CSTR LEAD WORD

 1    Digital VAX OpenVMS       FALSE  8        –      0    0    32

 2    HP Series 9000 HP-UX      TRUE   6        10     32   1    32

 21   Novell Netware (Oracle7)  FALSE  8        –      0    1    32

 21   Novell Netware (Oracle8)  FALSE  –        8      32   1    32

 22   MS DOS                    FALSE  8        –      16   512  16

 46   Intel based server LINUX  FALSE  –        10     32   1    32

 87   Digital Unix              FALSE  6        10     32   1    32

 89   Alpha Vms                 FALSE  8        10     32   0    32

 168  Silicon Graphics UNIX     TRUE   6        ?      32   1    32

 172  Intel Solaris             FALSE  5        ?      32   1    32

 198  Sequent Dynix/PTX         FALSE  6        ?      32   1    32

 319  IBM RS 600 AIX            TRUE   8        10     32   1    32

 358  NCR Intel                 FALSE  8        ?      32   1    32

 453  Sun Sparc Solaris         TRUE   6        10     32   1    32

 601  MS Windows NT Alpha       FALSE  8        8      32   512  32

 615  MS Windows 95             FALSE  8        ?      32   512  32

 912  MS Windows NT Intel       FALSE  8        10     32   1    32

Explanation of the values:

 ENDIAN  OSD_BIG_ENDIAN_FLAG

 FBITS67 OSD_DBA_FILE_BITS (Oracle version6/Oracle7)

 FBITS8  OSD_DBA_FILE_BITS (Oracle8 and greater)

 CSTR    OSD_C_STRUCT_ALIGNMENT

 LEAD    OSD_FILE_LEADER_SIZE

 WORD    OSD_WORD_SIZE

init.dulを配置する

  • データベース特定バラメタ
    • db_block_size = 8192 /* db default block size */
    • compatible = 9 /* db version */
  • Sql*Loaderあるいはフォーマットバラメタをエクスポートする
    • export mode = false /* for sql*loader, true=exp */
    • ldr_enclose_char = ” /* delimiter for sql*loader */
    • ldr_phys_rec_size = 81 /* output length */
  • 注意: ほかのバラメタと数値は後で紹介する。

dc_columns = 200000
dc_tables = 40000
dc_objects = 40000
dc_users = 2048
osd_big_endian_flag = true # Only osd parm needed on >=10g
osd_dba_file_bits = 10
osd_c_struct_alignment = 32
osd_file_leader_size = 1
osd_word_size = 32
db_block_size = 8192
compatible=9
export_mode=false
ldr_enclose_char = ”
ldr_phys_rec_size = 81

最小 init.dul

ØDUL dbfヘッダからすべての配置バラメタを見つけ出してみる

ØInit.dul

ØCOMPATIBLE=n

ØOSD_BIG_ENDIAN_FLAG=true/false

プラットフォームをまたがる場合に対して

Ø指定した場合に、 DULinit.dulのバラメタ値を利用する

ØGENERIC_init.dul DUL ToolKitに含む

一つのcontrol.dulを配置する

  • 抽出したいデータは今どこにあるか
    • Datafile の位置はosレベルで獲得できる
    • データベースがインストールできるなら、 v$datafileSQLを使ってください
  • 今は三つのフォーマットの行を支持できる
    • file_piece_spec (従来)
    • asm_disk_spec
    • block_index_spec

control.dul: file_piece_spec

  • [[tablespace_norelative_file_numberdata_file_name

extra_leader_offset ]

[ startblock block_no ]

[ endblock block_no ]

[ block_size nk ]

注意新たなバーション>= 10, the tablespace_no  relative_file_number は選べる。.dbf file headerから読み取れる(損害がなければ)

control.dul: file_piece_specを立ち上げる

データファイルヘッダがdulをアクセス出来ない場合に、以下のSQLを利用してください。

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

  • 仮に前の SQLがデータベースをインストールした
  • けど、データベース制御ファイルから control.dulを作成すればいい
  • >strings <controlfile> >control.dul
  • もう一つのデータベースからダンプでts# and rfile#うぃ獲得できる。

Øalter system dump datafile   ‘c:\app\jdydek\oradata\orcl\users01.dbf’

block min 1 block max 2;

Øトレースファイルから以下のようなことを検索する:

ファイル番号=4

RelFno: 4

インポート:システムダンプを変更して、データファイルをダンプする

Start dump data block from file D:\MY_DATA\DULCLASS\USERS.DBF minblk 1 maxblk 2

V10 STYLE FILE HEADER:

Compatibility Vsn = 169869568=0xa200100

Db ID=2596130611=0x9abdcf33, Db Name=’XE’

Activation ID=0=0x0

Control Seq=323=0x143, File size=12800=0x3200

File Number=4, Blksiz=8192, File Type=3 DATA

File Space Header Block:

Header Control:

RelFno: 4, Unit: 8, Size: 12800, Flag: 9

AutoExtend: YES, Increment: 1280, MaxSize: 655360

Initial Area: 7, Tail: 12800, First: 42, Free: 1557

Deallocation scn: 0.0

Header Opcode:

Save: No Pending Op

End dump data block from file D:\MY_DATA\DULCLASS\USERS.DBF minblk 2 maxblk 2

control.dul: 選べるts# file#

0 1 /p012/oracle/GTU5ASP/system.dbf
1 2 /p014/oracle/GTU5ASP/undotbs01.dbf
2 3 /p015/oracle/GTU5ASP/sysaux01.dbf
4 4 /p028/oracle/GTU5ASP/pinn_data01.dbf
0 5 /p030/oracle/GTU5ASP/system02.dbf
4 6 /p020/oracle/GTU5ASP/pinn_data02.dbf
1 7 /p018/oracle/GTU5ASP/undotbs02.dbf
4 8 /p033/oracle/GTU5ASP/pinn_data03.dbf

インストールモードでデータベースに以下のようなSQLを実行する。

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

注意たとえs# and rfile#,がなくとも、すべてのデータファイルを獲得するために有効である

# 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

12 /tmp/huge_file_part1 startblock 1 endblock 1000000

21 /tmp/huge_file_part2 startblock 1000001 endblock 2000000

32 /mnt3/huge_file_part3 startblock 2000001 endblock 2550000

/p012/oracle/GTU5ASP/system.dbf

/p014/oracle/GTU5ASP/undotbs01.dbf

/p015/oracle/GTU5ASP/sysaux01.dbf

/p028/oracle/GTU5ASP/pinn_data01.dbf

/p030/oracle/GTU5ASP/system02.dbf

/p020/oracle/GTU5ASP/pinn_data02.dbf

/p018/oracle/GTU5ASP/undotbs02.dbf

/p033/oracle/GTU5ASP/pinn_data03.dbf

注意: dul v10が壊れていなければ、dbf headersからテーブルの数と関連するファイル番号を読み取れる。

control.dul: asm_disk_spec

  • DISK device name [ disk group options  ]
  • disk group option ::=

GROUP  disk group name |

DISK_NO  disk number in group |

F1B1  File1 Block1 location

  • 注意:设备名称通常是足够的。其他属性从文件头检索

control.dul: asm_disk_spec

# ASM disks for disk groups

disk /media/maxtor/asm/dgn1

disk /media/maxtor/asm/dgn2

disk /media/maxtor/asm/dgn3

disk /media/maxtor/asm/dgodd

第一のasmディスクのシステムデータファイル

+DGN/db102/datafile/system.257.621616979

異なったディスクのユーザーデータファイル

+DGODD/db102/datafile/users.257.621616683

  • 11/27/12:  最新のDUL 実行可能なファイルが一つの新たなasm層がある。

control.dul: block_index_spec

  • BLOCK INDEX block_index_name
  • ブロックインディクスは損害したファイルシステムのOracleブロックをアクセスする方法の一つである
  • in control.dulを使う前にDULコマンドを使ってください:
  • CREATE BLOCK INDEX index_name ON  device ;

DULをインストールして実行する

  • dul.exe はコマンドであって、バラメタドライブである。SQL*Plusのような構造を使ってください。
  • コマンドについて詳しい情報はマニュアルに参考してください
  • インストールプログラムがない。Exeプログラムだけをディレクトリにコピする。テキスト編集器でinit.dul control.dulを立ち上げる。
  • あるUNIX shellあるいはWindows DOS ヒントからDULを実行する。
  • >./dul.exe /* for UNIX */
  • >dul /* for Windows */

DULを実行する:よく使われるコマンド

  • 一部よく使われる標準コマンド
    • SHOW PARAMETERS; /* display all parm settings */
    • BOOTSTRAP; /* read dictionary metadata */
    • SCAN DATABASE; /* scans all known datafiles */
    • SCAN TABLES; or SCAN EXTENTS;
    • UNLOAD DATABASE; /* extracts all users/tables */
    • UNLOAD TABLE schema.table (…..) ;
    • UNLOAD USER user_name;
    • UNLOAD OBJECT number;
    • EXIT; or BYE; /* end dul session */
  • 3 章将回顾所有命令的详细内容。

「新しい」コマンド/機能

  • オンラインユーザーガイド (より完全に)
  • ASM 支持 (control.dul フォーマットが異なる)
  • SCAN LOB SEGMENT FOR …
  • UNEXP TABLE schema.table_name
  • UNPUMP … (wip, check with Bernard)
  • dul.exe には一部のコーピー保護がある
    • 今のバーションをダウンロードする
    • Date sensitive inactivation これでプログラムを実行することを阻止するかもしれない
      • 起動出来ない
      • あるオペレーションシステムが最新DULバーションが必要になる

dul.logをチェックする

  • dul.exe は実行される度にログが作成される
  • ディフォルトにはそのログが“dul.log”と名付けられた。
  • DULを何度も実行されるときに,
    • ディフォルトは実行するたびに、the dul.logを上書きする。
    • RESET_LOGFILE=falseを設定して、実行する度に dul.logsを追加する。あるいは二回実行する間にdul.logをリネームする。
  • 注意: init.dulに10個のバラメタだけを設定したが、実際には約50個のバラメタがあるかもしれない。設定していない部分がディフォルト値になる。

dul.log

DUL version 10.2.0.5.17 with 64-bits i/o

Init.dul parameter settings:
_SLPE_DEBUG = FALSE
ALLOW_CHECKSUM_MISMATCH = FALSE
ALLOW_DBA_MISMATCH = FALSE
ALLOW_OTHER_OBJNO = FALSE
ALLOW_TRAILER_MISMATCH = FALSE
ASM_DO_HARD_CHECKS = TRUE
AUTO_UPDATE_CHECKSUM = TRUE
AUTO_UPDATE_TRAILER = TRUE
BUFFER = 1048576
CF_FILES = 1022
CF_TABLESPACES = 64
COMPATIBLE = 10
CONTROL_FILE = control.dul
DB_BLOCK_SIZE = 8192
DB_NAME =

UNEXP_VERBOSE = FALSE
USE_LOB_FILES = FALSE
USE_SCANNED_EXTENT_MAP = false
VERIFY_NUMBER_PRECISION = TRUE
WARN_RECREATE_FILES = TRUE
WRITABLE_DATAFILES = FALSE

Reading USER.dat 42 entries loaded
Reading OBJ.dat 16246 entries loaded and sorted 16246 entries
Reading TAB.dat 1512 entries loaded
Reading COL.dat 58768 entries loaded and sorted 58768 entries
Reading TABPART.dat
DUL: Error: File TABPART.dat, line 1: token missing
DUL: Warning: Ignoring file TABPART.dat cache

Database national character set is AL16UTF16
Entries from control file control.dul:

DUL: Error: open( ‘C:\ORACLEXE\ORADATA\XE\SYSTEM.DBF’, Read Only)
OS error 2: No such file or directory

DUL: Error: open( ‘C:\ORACLEXE\ORADATA\XE\DULDAT01.DBF’, Read Only)
OS error 2: No such file or directory

DUL: Error: open( ‘D:\DULDAT02-corrupt.DBF’, Read Only)
OS error 2: No such file or directory

DUL> show parameters

DUL> bye
Goodbye

简单なデータ抽出vs. 複雑なデータ抽出

  • 简单: SYSTEM datafile
  • モードの名前も、テーブルの名前も、列も、属性もアクセスできる
  • BOOTSTRAP; データディクショナリーから情報を読み取る
  • 複雑:  SYSTEM テーブルスペースがない
  • モードの名前もテーブルの名前も属性の名前がお客様からインメージする必要がある
  • データベースとテーブルをスキャンしてください;
  • アンロードするために、use_scanned_extents_map=trueを設定する

ほかの複雑データから抽出

  • 複雑:SYSTEM.dbfがあるかないか
    • ある遮断テーブルからデータを抽出する
    • あるdropped テーブルからデータを抽出する
    • あるdeleted テーブルからデータを抽出する
    • 一部インサートされた遮断テーブルからデータを抽出する
  • 注意: 10gから、新たな機能を利用することで、以上のトラブルを避けられる。

Preparing to engage

  • DUL テーストトラブルリスト
    • e-mail あるいは scoping callから答えを得られる
    • 予想値を設定する
  • 今のexe zip/gzファイルをダウンロードする
    • DUL ツール (注意: 日付きの有効保護)
    • DUL マニュアル
  • 現場に行けば、あるCDあるいはUSBにコピしてください
    • 注意 すべてのプラットフォームを同じCDに格納する
    • プラットフォームをまたがるDULもあり
  • 現場行かない場合に、e-mailあるいは ftpでお客様に届ける

1) 配置が間違えて、DULはエラ情報が作成された。どんなステップで再実行すればいいか?

a)バラメタを修正して、再起動する

b) DULを再びインストールして、.dbfファイルを新たなディレクトリに移す

c)バックアップログとデータファイル

d)DUが実行出来ない

2) これらのファイルを説明する:

a)init.dul

b)control.dul

c)dul.exe

d)dul.log

e)system.dbf

3) 以下の場合に、データディクショナリーの相違によって異なった方法でデータを抽出する:

a) データベースが起動できない

b) データベースがロードできない

c) あるテーブルが遮断出来ない

d) テーブルの行がdeletedされた

e) あるテーブルがdroppedされた

バラメタとコマンド

  • 前提:
    • Oracleデータベースサーバに対して深刻な知識が必要としている
      • Impツールの使用
      • SQL*Loaderの使用
    • UNIX/Windowsコマンドラインに対して少しの知識が必要としている
      • vi あるいはUNIXでほかのテキスト編集器
      • Windowsのテキスト
  • 起動シーケンス
  • もっとも役に立つバラメタ
  • あまり使われていないバラメタ
  • 無証バラメタ

起動シーケンス

>dul [選べるコマンドファイルの名前]

1.バラメタファイル(ディフォルト“init.dul“)が処理された。

2.制御ファイル (ディフォルト “control.dul”)が処理された。

3. USER$, OBJ$, TAB$ 及び COL$dumpsをテストして、使えるなら、DULのデータディクショナリーメモリにロードする。

4. seg.dat col.datをロードする。

5. “DUL>”ヒントを映し、コマンドを納得する(あるいは、コマンドラインに初めてのバラメタファイルのコマンドとして実行する)

  • CONTROL_FILE = control.dul
    • .dbf 位置にソースのファイル名を入力する
    • “control.dul” はディフォルトである
  • LOGFILE = dul.log
    • インポートで書き込みのファイルを実行する
    • “dul.log” はディフォルトである
  • RESET_LOGFILE = [TRUE/false]

Trueの場合に、DULが実行される度に前のdul.logを上書きする。

  • DB_NAME=text
  • DB_ID=number
    • これらのバラメタはDULが今にどんなデータベースインスタンスを処理しているかを確実に知らせる(名前あるいはid)
    • お客様が複数のデータベースから.dbfファイルを提供するときに使える。
    • DUL dul.logにマッチしていない.dbf ファイルを報告する
    • 最好从control.dulからこれらの .dbfファイルをドロップして、再びdul sessionを実行する
  • EXPORT_MODE=[true/false]
    • Trueの場合に,DULでエクスポート(.dmp)ファイルをアウトプットする
    • Falseの場合に、,DUL SQL*Loader ファイル (.dat and .ctl)をアウトプットする
  • SQL*Loaderでアウトプットする場合に
    • LDR_ENCLOSE_CHAR =  /* delimiter char */
    • LDR_OUTPUT_IN_UTF8 =[true/false]
    • LDR_PHYS_REC_SIZE = 81
      • If 0, 決めたサイズがない、行ごとに新たなキャラクターで終わる
      • If >2, 各行のサイズが決められた
  • BUFFER=1048576
    • 大量なバイトを指定して、ある行をメモリする
    • 行出力メモリ領域サイズがexportSQL*Loaderモードで使われる
    • 各行がメモリ領域に格納される
    • 完全でエラもない行だけがインポートファイルに書き込む
    • この数値に超えれば、DULが失敗し、再起動する
    • 多くの場合に、ディフォルトの1Mでいい。けど、メモリ領域が小さすぎてエラになった場合にも慌てないでください。
  • FILE_SIZE_IN_MB=number
    • ある数値が指定した最大のdump (.dmp)ファイルのサイズが、MBを単位にする。ディフォルトの0は制限されていないと意味している 。
    • もしディスクスペースが制限されていれば、使える。
    • DULが実行されているときに、これより大きいなダンプファイルが複数のブロックに配られる。
    • これで、ユーザーがファイルをもう一つのファイルシステムにコーピーして、削除することでスペースを回収できる。
    • dump ファイルが独立でインポートする

もっとも役に立つバラメタ

  • COMPATIBLE=[6,7,8,9,10,11]
    • データベースバーションを指定する
  • DB_BLOCK_SIZE=8192
    • ディフォルトデータベースブロックサイズを指定する
  • USE_SCANNED_EXTENT_MAP = [FALSE/true]
    • Falseの場合に (ディフォルト値), seg headerのセグメントインメージを使う
    • Trueの場合に、SCANコマンドによっている作成したexternal ext.datファイルファイルのセグメントインメージアンロードテーブルを使ってください
    • 複雑の場合に対して、ext.dat が異なった実行プロセスに作成される。

あまり使われていないバラメタ

  • ALLOW_CHECKSUM_MISMATCH = FALSE
    • Trueの場合に、ブロックテストをスキップする
  • ALLOW_DBA_MISMATCH = FALSE
    • Trueの場合に、 ブロックアドレステストをスキップする
  • ALLOW_OTHER_OBJNO = FALSE
    • Trueの場合に、 有効なオブジェクトの数を確認することをスキップする
  • ALLOW_TRAILER_MISMATCH = FALSE
    • Trueの場合に、block trailerをテストすることをスキップする
  • TRUEを設定する前に、よく考えてください!
  • FILE = text
    • text 8.3 DOSファイルの名前を作成する基礎である
  • MAX_OPEN_FILES = 8
    • 最大の#dbfsは同時にオペレーションシステムレベルに起動している。
  • PARSE_HEX_ESCAPES = FALSE
    • 解析の時に\\xhhを使って、十六進数シーケンス? No
    • TRUEと設定すれば、,シーケンスを使えるようにするために \\ 文字列を指定してください
    • 複数のバイトキャラクターを指定するときにも使える
  • WARN_RECREATE_FILES = TRUE
    • trueの場合に、ファイルが上書きされたら、ログアラームメッセージがない
    • false,の場合に、アラームメッセージを抑える
  • WRITABLE_DATAFILES = FALSE
    • false (ディフォルト)の場合に、 DULread onlyと確保してください
    • trueの場合に、DULがコマンドモードに限られたデータファイル編集ができる。

無証バラメタ

  • _SLPE_DEBUG=FALSE
  • ASM_DO_HARD_CHECKS = TRUE
  • AUTO_UPDATE_CHECKSUM = TRUE
  • AUTO_UPDATE_TRAILER = TRUE
  • CF_FILES = 1022
  • CF_TABLESPACES = 64
  • DEFAULT_CHARACTER_SET =
  • DEFAULT_NATIONAL_CHARACTER_SET =
  • DB_ID =
  • DB_NAME =
  • FEEDBACK = 0
  • OSD_MAX_THREADS = 1055
  • SCAN_DATABASE_SCANS_LOB_SEGMENTS = TRUE
  • SCAN_STEP_SIZE = 512
  • TRACE_FLAGS = 0
  • UNEXP_MAX_ERRORS = 1000
  • UNEXP_VERBOSE = FALSE
  • USE_LOB_FILES = FALSE
  • VERIFY_NUMBER_PRECISION = TRUE

もっとも役に立つコマンド

  • [ALTER SESSION] SET init.dul parameter = value ;
    • 多くのバラメタが動的に変えられる。
  • BOOTSTRAP;
    • データディクショナリーをスキャンして、外部ファイルを構造する。
    • もし SYSTEM.dbf が使えるなら
  • DESCRIBE owner_name.table_name ;
  • REM any_text_till_end_of_line
  • REM ddl 文にあることはない
  • SCAN DATABASE;
    • すべての配置データファイルのブロックをスキャンする。
    • 二つや三つのファイルを作成する
  • SEG.dat

セグメントタイトルを見つけた

  • EXT.dat

連続したテーブル/groupデータブロック

  • SCANNEDLOBPAGE.dat

lob datablockの情報

–If SCAN_DATABASE_SCANS_LOB_SEGMENTS=TRUE

  • SCAN TABLES;
    • SEG.da EXT.datでインポートする。
    • すべてのデータセグメントにあるすべてのテーブル
  • SCAN EXTENTS;
    • SEG.dat EXT.datでインポートする。
    • すべてのセグメントが該当するセグメントヘッダが見つけ出していない。あるテーブルスペースが完全ではない場合に、あるいはセグメントヘッダが壊れた場合に限って使える。
  • SHOW DBA dba ;
    • dba to file_no block_no calculator
  • SHOW DBA rfile_no block_no ;
    • file_no block_no to dba calculator
  • SHOW SIZES ;
    • 大切な構造のサイズ
  • SHOW PARAMETER;
    • すべてのバラメタの既存する数値を映した
  • SHOW LOBINFO;
    • データベースをスキャンすることで見つけ出したlobインディクスを映した
  • SHOW DATAFILES;
    • 配置データファイルまとめ
  • SHOW ASM DISKS;
    • 配置asmディスクまとめ
  • SHOW ASM FILES;
    • Asmで、配置データファイルをまとめる
  • SHOW ASM FILE cid
    • Asmファイルの範囲情報
  • UNLOAD DATABASE; /* everything except SYS */
  • 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#) ;

  • EXIT, QUIT, EOF, BYE all cause DUL to terminate.
  • COMMIT;
    • ブロックを変更してデータファイルに書き込む。
    • 多くの場合に DUL READ-ONLY!使う
  • CREATE BLOCK INDEX index_name ON  device ;
    • あるブロックインディクスが壊れたファイルシステムに見つけ出した有効なOracleブロックアドレスである。
    • ファイルシステムが壊れた場合に限って使える。
  • DUMP [ TABLESPACE tablespace_no ]

[ FILE  file_no  ]

[ BLOCK  block_no  ]

[ LEVEL  level_no  ] ;

  • これはチュニックのための完全なblockdump, である。
  • EXTRACT asm file name to  output file name  ;
  • あるディスクgroupから、ASMファイルをファイルシステムにコピする。(オンラインredologsトラブルがあって、より多くのテストが必要としている)
  • MERGE block_index INTO [ segment ];
    • mergeコマンドがインディクスファイルの情報で可能なデータブロックを探し出す。
    • 各ブロックを既存するブロックと比べる。
      • 例えば、既存するブロックが壊れた。あるいはより古いscn。ブロックがデータファイルに書き込む。
    • これはファイルシステムが極端に壊れた場合に利用できる。
  • ROLLBACK;
  • UPDATE文を取り消す
  • SCAN DUMP FILE dump file name

[ FROM  begin offset  ]

[ UNTIL  end offset  ];

  • あるダンプエクスポートファイルをスキャンする。
  • SCAN LOB SEGMENT storage clause ;
  • SCAN LOB SEGMENT FOR

  table name  [.  column name] ;

  • LOBPAGE.dat 情報を作成するために、lob セグメントをスキャンする。
  • より速く、より小さく。
  • パーティションオブジェクトに対して、SCAN DATABASEを使ってください。;
  • UPDATE [ block_address ]

SET UB1|UB2|UB4 @ offset_in_block = new_value ;

  • UPDATE [ block_address ]

SET  block element name  = new_value ;

  • 既存するブロックバッチとダンプ 。
  • 複数のUPDATEコマンドを追加できる。
  • 今まで、書いていないブロックであり、 COMMITで編集する。
  • UNEXP [TABLE] [ owner. ] table name

 column list  ) [ DIRECT ]

DUMP FILE  dump file name

FROM  begin offset  [ UNTIL  end offset  ]

[ MINIMUM  min number of cols    COLUMNS ] ;

  • 壊れたexp dumpファイルからデータをアンロードする。
  • 特別に設定することが必要としていない、互換性のあるバラメタがあればいい。
  • begin offsetは行の始まりにある 
  • UNPUMP
    • 壊れたexpdp (datapump) dumpファイルからデータをアンロードする。
    • これは進行中のタスクである。基本的なコマンドが効くときに、使うと複雑になる。

1) DULはコマンドヒントで実行され、バッチモードで実行できない。

a)True

b)False

2) バッチモードで使うと、DULがパラレルで実行できる。

a)True

b)False

Chapter 4: 简单なシーン

  • 前提:
  • Oracle データベースサーバに詳しい
    • imp ツール
    • SQL*Loader の使用
  • UNIX/Windows コマンドラインレベルに少しの知識
    • vi あるいはUNIXのテキスト編集器
    • Windowsのテキスト
  • 简单データリカバリ
    • 完全データベース抽出
    • 部分データベースデータ抽出
    • モードデータ抽出
    • テーブルデータ抽出
    • セグメントデータ抽出
    • データディクショナリー抽出
  • SYSTEM.dbf データファイルが使える、しかも壊れていない
  • エンジニアがアプリケーションプログラムテーブル構造・列タイプなどの情報を知る必要がない。
  • メータデータ (ユーザーネーム、テーブルネーム、列ネーム、列タイプ) BOOTSTRAPSYSTEM.dbfからコマンドを読み取る。
    • BOOTSTRAP コマンドプロセスで作成された情報はOSテキストファイルに格納して、後のDUL sessionに読み取れる。
  • 使えるすべての.dbf ファイルでデータベースごとにアンロードする(i.e. SYSTEM, XDB, MDSYS, OUTLN, etc)
  • init.dul control.dulを配置する
  • Run /dul

DUL>bootstrap;

DUL>unload database;

DUL>exit

データベースごとに抽出

データベースごとに抽出することはある結果を導くために最速なやり方だと思うが(特にお客様が急いでいるときに)、けど、必要より多くのファイルが作成されるかもしれない。

  • ディスクスペースはお客様に対して問題になる(データベースが非常に巨大な場合に)、ファイルを作りすぎるとトラブルになる
  • 連続に各テーブルを抽出することになるが、データベースごとに抽出することが一番時間をかかる。
  • お客様が必要とするデータを含む、制限されたcontrol.dulの配置 dbfs
  • DUL が必要とされていないdbfsをスキャンしないことで、時間を省みる。

最佳实践DULは自動的に実行されることはない。正確的に配置された場合に、多くのデータベースがsessionを抽出することで時間を省みる。

データベースの一部だけを抽出する

  • 最善のpractical: 時間を省みるために、肝心なデータを含まないcontrol.dulからデータを取り消す。これは特別なUNDOTBS, SYSAUX, IDX, INDEX, TEMP, etc
  • お客様が必要としていないdbfsを識別できる
  • init.dul control.dulを配置する
  • Run /dul

DUL>bootstrap;

DUL>unload database;

DUL>exit

データベースを部分的に抽出するコマンドはデータベースごとに抽出するコマンドと同じになるが、DULcontrol.duldbfファイルだけを識別できるから、アウトプットを制限する

  • DUL はあるデータディクショナリーに使われたテーブルスペースオブジェクトのエラメッセージをアウトプットするが、control.dulに該当する.dbfがない。
  • これらのエラが無視してもいいが、お客様に説明する必要がある。
  • 最善のpracticalもしお客様がアプリケーション.dbfの内容に対して、明白ではない場合に、control.dulに格納してください、さもなければ、データがなくなる。
    • 時間を省みるために、DUL sessionをパラレルに実行することを考えてください。
    • 複数DUL sessionを実行する場合に、dul.logを上書きしないために、異なったディレクトリから実行する
  • 部分的に抽出する場合に:あるお客様のテーブルスペースがオフラインした。そのデータファイルに一つだけ損害した。
  • この場合に、そのテーブルスペース(及びシステム)のdbfsだけを含む。そして、control.dulからほかを排除する
  • init.dul control.dulを配置する
  • Run /dul

DUL>bootstrap;

DUL>unload database;

DUL>exit

  • 最善のpractical: 複数のエラメッセージを取り消す同時に時間を省みるために、モードやテーブルレベルで抽出してください。
  • 注意:実際の場合に、データベースが崩壊していないが、抽出するデータがデータベースの一部かもしれない。
  • ある遮断テーブル
  • ある削除されたユーザー
  • ある壊れたテーブルスペース

モードデータ抽出

  • ユーザーが必要とするだけのモードをアンロードする。
  • init.dul control.dulを配置する
  • Run /dul

DUL>bootstrap;

DUL>unload USER scott;

DUL>unload USER apps;

DUL>exit

テーブルデータを抽出する

  • ユーザーが必要とするだけのモードをアンロードする。
  • init.dul control.dulを配置する
  • Run /dul

DUL>bootstrap;

DUL>unload TABLE scott.dept;

DUL>unload TABLE apps.po_orders;

DUL>exit

テーブルデータを抽出する

  • UNLOAD TABLE コマンドは選べるバラメタがある。
  • UNLOAD [TABLE] [ schema_name . ]  table_name

[ PARTITION(  partition_name ) ]

[ SUBPARTITION(  sub_partition_name ) ]

[ (  column_definitions ) ]

 cluster_clause  ]

 storage_clause  ] ;

  • storage_clause ::=

STORAGE ( storage_specification )

  • storage_specification ::=

OBJNO object_id_number

|       TABNO cluster_table_number

|       SEGOBJNO cluster/data_obj_number /*v7/v8 */

|       BLOCK data_segment_header_block_number )

简单なシーンセグメント(Extent)データ抽出

  • 更に制限すればデータがセグメントによって抽出できる(一つの部分テーブルと限られた行しかない。)
  • これはお客様の一部のテーブルが壊れて、特定の行あるいはブロックが使えない場合に使える。
  • init.dul control.dulを配置する
  • Run /dul

DUL>bootstrap;

DUL>unload EXTENT scott.customer …;

DUL>exit

  • 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 ;

  • DULはデータだけを抽出する。
  • もしお客様がほかのオブジェクトの作成シナリオを格納していなければ、データディレクトリからソースコードを抽出して作成する。

UNLOAD table sys.source$;

注意: もしそのデータが抽出されたら、ほかのデータベースのSYSにロードできない。そのデータを独立したモードインポートする、SQL逆シナリオを編集する。

簡単なシーンアウトプット

  • dul.log
    • すべてののバラメタ設定を挙げる。
    • 見つけ出したdb_id あるいは db_nameを挙げる
    • 識別できるデータファイルを挙げる:file#, relative file#, startblock, #blocks, blocksize及びoffset
    • schema.tableの行数
    • 可能なアラームとエラ情報
  • 抽出するファイル
  • schema_tablename.dmp or .dat or .ctl
  • dul.log

Found db_id = 1321768231

0 1 c:\app\jdydek\oradata\orcl\SYSTEM01.DBF startblock 0 blocks 93441 block size 8192 (off=0)

4 4 c:\app\jdydek\oradata\orcl\USERS01.DBF startblock 0 blocks 641 block size 8192 (off=0)

DUL> unload table locationd (col001 number, col002 varchar2(11)) storage (extents (file 4 block 530));

. unloading table                 LOCATIOND       6 rows unloaded

DUL> exit

  • 一般的には、DUL sessionの間に可能なアラームとエラの完全リスト。
  • アラーム
    • よく無視されるが、その原因を探ってください。
  • エラ
    • これでDULを中止させるかもしれない。
  • 必要とするのはオペレーションシステムの最新DULバーション
  • 原因: DULが約45日ごとに再編集する。しかも異なったディドラインがある。
  • バーション GLIBC_2.11 (required by dul)を見つけ出していない
    • 原因: Linuxには二つのDULがある
    • ダウンロードして、Linuxのもう一つのDULバーションを試してください(動的リンク)
  • 抽出するテーブルは行数を映すはずだが:

. unloading table    LOGSTDBY$FLASHBACK_SCN

DUL: Error: No entry in control file for block: ts# = 1 rfile# = 2 block# = 2050

DUL: Error: While processing ts# 1 file# 2 block# 2050

DUL: Error: Could not read/parse segment header

0 rows unloaded

  • 原因: すべてのお客様アプリケーションデータを含まないデータファイルを排除する。例えばSYSAUXDULはデータディレクトリに確実に存在しているテーブルスペースとブロックを見つけ出せない。
  • 起動する間に、以下のようなことが見られる。:

DUL: Error: open( ‘C:\ORACLEXE\ORADATA\XE\SYSTEM.DBF’, Read Only)

OS error 2: No such file or directory

  • 原因: control.dulに指定したデータファイルが指定した位置にいない。
  • control.dulの位置を変更する
  • 支持していない特性/データタイプ

DUL: Error: Type REF, typcode 110 is not supported(yet)

0000000000 00220208 6d6aa16a cad6403a b6c27d8e .”.. mj.j ..@: ..}.

  • 原因: DULがそのデータタイプを識別できないかもしれない
  • OS に関するエラ
  • If osd_dba_file_bits size is wrong:

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

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

  • If osd_c_struct_alignment is wrong:

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

  • If db_block_size is wrong:

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

1) データベースにすべてのdbfファイルを使えるようにする必要があることによって、DULでユーザーが必要とするデータを検索できる

a)True

b)False

Chapter 5: 複雑なシーン

  • 前提:
  • Oracle データベースサーバに詳しい
    • imp ツール
    • SQL*Loader の使用
  • UNIX/Windows コマンドラインレベルに少しの知識
    • vi あるいはUNIXのテキスト編集器
    • Windowsのテキスト
  • 简单データリカバリ
    • 完全データベース抽出
    • 部分データベースデータ抽出
    • モードデータ抽出
    • テーブルデータ抽出
    • セグメントデータ抽出
    • データディクショナリー抽出
  • SYSTEM.dbf ファイルが使えなくなったまたは壊れた
    • 最佳实践: 続行する前に、お客様にはより古いバックアップSYSTEM.dbf バーションがある。データベースに深刻な変更がある場合を除いて、古いSYSTEM.dbfでも利用できる。
  • 抽出することによって、列データタイプが DULに当てられるかもしれないが、テーブルネームも列ネームもなくした
    • 当てた列データタイプが誤ったかもしれない
    • dul.logには統計データを含む
  • アプリケーションとテーブルの機能に詳しい人が必要
  • どこからのデータも知らずに、アンロードするだけで、何の意味もない。
  • DUL はオブジェクトだけによって、テーブルを識別できる
  • DUL は列番号だけで列を識別する
  • そのプロセスがせめてDULによって再び使われる必要がある

1. DULを実行して、すべてのオブジェクト、データタイプを分析して、各オブジェクトに対して、通用のUNLOADコマンドを作成する

2.お客様と一緒に dul.log統計データ、テーブルインメージオブジェクト、及びデータタイプをチェックする。

3. 必要であれば、UNLOAD を修正する。

    注意: お客様からの列ネームが作成されるかもしれない “Col1, Col2, Col3…”によって代われる。そのときに、テーブルネームがオブジェクト番号に代われるかもしれない。

4. DULでオブジェクト番号によって、各変更されたUNLOADコマンドを処理する。

  • 注意: もしNULLs, DULだけがあるなら、終わりの列が見つけない
    • Trailing NULL 列がデータベースにストレージされていない
    • 列の数がソーステーブルとマッチしていない
  • 削除されたテーブルはリカバリされて、有効なオブジェクト番号つきのUNLOADが作成される
    • あるテーブルが削除されたときに、ディスクライブ.がデータディクショナリーから削除されるかもしれない。オブジェクトつきの行が未だにデータファイルにある。
  • 行がなければ、報告されない

複雑シーンに、 DULを実行する 1:データファイルを分析する

  • init.dul control.dulを配置する
  • USE_SCANNED_EXTENT_MAP=falseを確保してください
  • Run /dul

DUL>scan database;

DUL>set USE_SCANNED_EXTENT_MAP=true

DUL>scan tables;   /* or scan extents */

DUL>exit

初めての実行でのdul.logをチェックしてください

  • 統計データと作成されたUNLOADコマンドをチェックしてください
  • 对每一个发现的对象号, DUL :
    • 显示它的列分析置信级统计数据
    • 以纯文本格式发表5行数据
  • 単純なテキストでテーブルのマックとデータタイプを利用してください

Analyzing segment: data object id 12088 segment header at ( file 4 block 11)   heap organized table

Col    Seen  Max PCT  PRINT  NUMBERS DATES TIMESTAMP WITH TZ INTRVAL ROWIDS LOB

no   count Size NUL 75%100% AnyNice AnyNice AnyNice AnyNice Y2M D2S AnyNice

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

2       4   22   0 100 100   0   0   0   0   0   0   0   0   0   0  50   0   0

DUL: Warning: No character set id for CHAR Column

“1” “Europe”

“2” “Americas”

“3” “Asia”

“4” “Middle East and Africa”

UNLOAD TABLE OBJNO12088 ( COL001 NUMBER, COL002 VARCHAR2(22) )

STORAGE( DATAOBJNO 12088 );

複雑な場合 UNLOAD コマンドを修正する

この場合に、作成されたUNLOADコマンドでお客様の要求を満たす:

UNLOAD TABLE OBJNO12088 ( COL001 NUMBER, COL002 VARCHAR2(22))

STORAGE( DATAOBJNO 12088 );

以下のようになるかもしれない:

UNLOAD TABLE location ( loc_id NUMBER (10), description VARCHAR2(25))

STORAGE( DATAOBJNO 12088 );

DUL 実行 2:実行 UNLOADs

  • 関連するUNLOADコマンドをコピする:
  • バチ処理のもう一つのテキストあるいはもう一つのオンラインDUL session LOADSの数が少ない

/dul

DUL>UNLOAD TABLE location ( loc_id NUMBER (10), description VARCHAR2(25)) STORAGE( DATAOBJNO 12088 );

. unloading table                  LOCATION       4 rows unloaded

複雑な場合 遮断テーブルから抽出する

  • Oracle 8によって、各オブジェクトには二つのオブジェクトidがある。
    • 標準オブジェクトidはデータディクショナリーの依存関係をトレースするために使われる。
    • データオブジェクトidはセグメントのブロックを標識するために使われる。
    • オブジェクトが作成され、二つは平等である。
  • あるテーブルが遮断されて、データオブジェクトidが増やす。
  • 遮断する前のデータを獲得するために、前のデータオブジェクトIDが必要としている(既存するid – 1かもしれない)
  • SQLで遮断されたテーブルを識別する

SELECT name, obj#, dataobj# from sys.obj$

where obj# <> dataobj#;

  • SQLでユーザーと内部IDを識別する

SELECT user_id, username from sys.dba_users

order by username;   /* or user_id */

REM Find truncated objects for a specific userid

set pages 60

col username        format a12 trunc

select d.username,

o.owner#, o.name, o.obj#, o.dataobj#

from sys.obj$ o,

sys.dba_users d

where o.obj#<>o.dataobj#         /* Truncated? */

and o.owner# = d.user_id

and d.username = upper(‘&1’)   /* For 1st parm */

order by owner#, name;

dropされたテーブルからデータを抽出する

  • 10gから开始, Oracle にはゴミ箱が実現できて、ディフォルトには使われる。
  • データベースが起動された場合に、お客様が削除されたテーブルをリカバリできる:

Øテーブルschema.tablename を削除する前にフラシュバックする闪回

もしデータベースがshut downして、フラシュバックもできない場合に、抽出したデータは正確のデータオブジェクトidを識別する。

Ødul.logで、行数に似ているオブジェクトが見られる。

削除されたテーブルからデータを抽出する

以下のシーンでデータUnLoaderに対してテストする:

  • フラシュバックリカバリ領域に配置していないあるいはデータベースバーションがフラシュバックを支持していない。
  • ある職員を削除してみると、お客様が職員のidWHERE文を忘れた、それに:

ØDELETE from hr.emp;

ØCOMMIT;    /* all rows are deleted… now what?  */

  • DULどうやって配置すれば、hr.empテーブルに削除されたデータを抽出できるか?
  • 使えるSYSTEM.dbfデータファイルがなければ、DULを実行完了までどんなステップが必要なのか?

a)お客様と一緒に dul.logを確認する

b)行数に基づき、テーブルを識別する

c) UNLOADコマンドを修正して、適切なテーブルと列ネームを利用する

d)コピ UNLOAD コマンドを修正する

e) DULを再実行して、各 UNLOADコマンドをインポートする

Chapter 6: データをロードする

  • ユーザーの要求次第、sessionのアウトプットは
    • 何百のアウトプットダンプファイル (*.dmp)
    • 何百のSQL*Loaderファイル (*.dat, *.ctl)
      • その一部は一時ファイルから、無視できる。
    • 何百のLOB*.dat または *.ctl
      • これは一時DULファイル、無視できる
  • お客様が使えるインポートで以下のフォーマットをなつけてやる:schema_tablename.dmp, .dat or .ctl

データをロードする

  • アウトプットファイルが作成出来たら、ASEDBAによって制御する。
  • けど一部のユーザーがデータをロードする必要がある。
    • もし、多くのファイルが作成され、次のシナリオで一緒にバチ処理できる。DUL 導入 Unix Shell シナリオ

#!/usr/bin/sh

#batch file import for dul

for i in `cat /dul/filelist`

do

imp scott/tiger rows=y full=y grants=y indexes=y

ignore=y buffer=1048576 commit=y

file=/dul/$i

log=/dul/log/$i.log charset=american

done

DUL SQL*Loader Unix Shell シナリオ

#!/usr/bin/sh

#batch file import for dul

for i in `cat /dul/filelist`

do

sqlldr system/manager

control=<path>/$i

log=<path>/$i.log

done

データ DULをロードして Windows バチ処理ファイルを導入する

REM batch file import for dul

for %%f in ( *.dmp )

do imp system/manager FULL=y

FROMUSER=dul TOUSER=scott ROWS=y GRANTS=y

INDEXES=y IGNORE=y BUFFER=1048576 COMMIT=y

FILE=C:\DUL\%%F

LOG=C:\DUL\LOG\%%F.LOG

Chapter 7: DUL 内部ファイル

  • 前提:
  • Oracle データベースサーバに詳しい
    • imp ツール
    • SQL*Loader の使用
  • UNIX/Windows コマンドラインレベルに少しの知識
    • vi あるいはUNIXのテキスト編集器
    • Windowsのテキスト
  • Excelにアクセスして、導入と解析ファイルを獲得する
  • DULが二種の一時内部ファイルを作成する
  • .dat
  • .ctl
  • 使っている肝心な内部ファイル
    • EXT.dat Extent map
    • SEG.dat Segment map
    • SEEN_TAB.dat Found table names
    • SEEN_COL.dat Found column names
  • EXT.dat SEG.dat はデータベースの最初段階に作成された。
  • DUL はこれらのファイルでデータファイルをスキャンして内容を確認する
  • SEEN_COL.dat SEEN_TAB.datはスキャンテーブル/セグメントに作成したオブジェクト統計情報を作成する
  • すべてのファイルもDULによって、アンロードリカバリできる
  • EXT.dat (SCAN DATABASE过程中创建😉
    • 連続したテーブル/groupデータブロックの情報を含む
    • 九つの列によって組み合う
      • Object ID
      • File# of セグメントヘッダ
      • Block# ofsegment header
      • File#
      • Block# of  セグメントヘッダの初めてのブロック
      • ブロックの数 = 指定したHWMのセグメントのブロック
      • テーブルの数,
  • SEG.dat (SCAN DATABASEプロセスで作成された😉
    • セグメントヘッダを含む情報
    • 四つの列によって組み合う
      • Object ID
      • File#
      • Rfile#
      • Block#
  • SEEN_TAB.dat (SCAN TABLE过程中创建😉
  • 探し出したテーブルオブジェクトの情報を含む
  • 6 列によって組み合う
    • Object ID
    • Table #
    • Block #
    • ??
    • # of columns
    • Row count
  • SEEN_COL.dat (SCAN TABLEプロセスで作成される😉
    • 16の列によって組み合う
      • Object ID
      • Table #
      • Column #
      • Field Type
      • Max Internal Size
      • Null found
      • Number of rows
      • 75% Character
      • 100% Character
      • Number
      • % Nice Number
      • % Date
      • % Row ID
  • SEG.dat

“77876” “4” “4” “522 ”

  • EXT.dat

“4” “16777227” “6” “5” “77876” “1” “1” “1” “0“

  • SEEN_TAB.dat

77876 4 522 0 2 5

  • SEEN_COL.dat

77876 0 1 2 2 F 5 0 0 0 5 5 0 0 0 0

77876 0 2 1 11 F 5 0 5 5 0 0 0 0 3 0

Chapter 8: 練習/テスト

  • 前提: Chapter 1
  • 前提: Chapter 2
  • 内部Oracle DUL ウエブサイトにアクセスする
  • 前提: Chapters 3-7
  • ノットブックにインストールしたOracle Database 11g
  • Oracle 11gデータベースのテーブル・開發をアクセスする
  • 完全なDBA管理権限
  • Chapters 3-7: 実験インストールステップ
  • 注意: 実際に、データベースがクロスされるかもしれない。インストールと検証をより簡単にするために、データベースを起動したままに保持してください。
  • データベースが起動したかとかかわらずDUL .dbf ファイルを実行できる。
  • SYSDBA として、データベースに登録して、以下のようなシナリオを実行し、labuser, labuserのテーブルを作成する。導入データのnewuser
    • @create
  • 一般的なステップを実行し、以下のタスクを完成してください
    • DUL ツールをダウンロードする
    • お客様の設備でインストールする
    • init.dul config.dulファイルを配置する
    • 適切なコマンドシーケンスを確認する
      • 「ガイド」を実行するまたは
      • データベースをスキャンする扫描数据库或扫描表或区段
    • データベース/ユーザー/テーブル/セグメント/オブジェクトをアンロードする
    • 必要とするデータベースとテーブルスペースを再構造する
    • インポートあるいはアウトプット SQL*Load DUL
  • Chapter 3: バラメタとコマンド
  • 通用の_init.dulのコピからinit.dulを作成する
  • プラットフォームのOSDバラメタを修正する
  • ほかのバラメタをテストして修正する
  • データベースから control.dulを作成する
  • データベースがインストールしていれば、 v$datafilesSQLを実行してください 。

Ø@control_dul.sql

  • OSからcontrol.dul,を作成し、必要におうじて編集する
  • Oradataディレクトリから.dbfファイルのファイルリストを獲得する

Ø/strings CONTROL01.dbf > control.dul

  • Chapter 4: 簡単なデータをリカバリするシーン

1) init.dul control.dulで、データベースごとに抽出してください

  • dul < Chap4_Ex1.txt
  • ログを確認する
  • アウトプットディレクトリをテストする
  • どれほどのファイルが作成したか
  • これらのファイルには一時のファイルがどれほどあるか?
  • これらのファイルがどれほどロードに使われるか?
  • エラ情報を確認する
  • 完成したか?
  • Chapter 4:簡単なデータを救うシーン

3)一つのターゲットモードを実行して、抽出する

  • ユーザーlabuserをアンロードする;
  • ログを確認して、テーブルネームと行数を獲得する

4) 一つのテーブルを実行して抽出する

  • テーブルsys.source$をアンロードする;
  • 注意: そのテーブルのデータはインディクス、トリガーのソースシナリオを再構造するために使われる。
  • ログを確認して行数とエラを獲得する
  • 導入してChapter 4のデータを検証する
  • Chapter 5: 複雑なデータを救うシーン
  • @actions /* truncate, drop, delete tables */
  • control.dul,を編集して SYSTEM01.dbfを削除する
  • dul < Chap5_Ex1.txt
  • dul.logを確認する
  • ログから一部のUNLOADコマンドを抽出する
  • 一部のUNLOADコマンドを獲得する
  • UNLOADコマンドを実行する
  • 導入してChapter 5のデータを検証する
  • Chapter 6: データをロードする
  • 抽出した.dmp またはdat/.ctl ファイルをテストデータベースを新たなモードに導入する
  • import.bat 実行してWindowsから導入する
  • newuser に導入したデータを確認する
  • Chapter 7: 内部ファイル
  • ext.dat, seg.dat, seen_tab.dat seen_col.dat テキストをExcelに解析する
  • 行数、テーブルの列統計データ、オブジェクト番号を確認する。

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号