[起こりうる現象]
Exadata環境でディスク障害が発生し、そのディスクの交換を行ったあと、ASM
インスタンスの XDWK プロセスで ORA-15196 が発生することがあります。

   ASMインスタンスのアラートログの例:
   ----------------------------------------------------------------------------------
   Wed Jan 01 00:00:00 2014
   Errors in file /u01/app/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_xdwk_1111.trc:
   ORA-15196: invalid ASM block header [kxdam.c:7032] [endian_kfbh] [0] [0] [0 != 1]
   Errors in file /u01/app/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_xdwk_1111.trc:
   SQL> /* Exadata Auto Mgmt: ADD ASM Disk in given FAILGROUP */
   alter diskgroup DATA add
    failgroup CEL11
    disk 'o/192.168.0.111/DATA_CD_11_CEL11'
    name DATA_CD_11_CEL11
    
    rebalance nowait
   
   NOTE: Assigning number (11,11) to disk (o/192.168.0.111/DATA_CD_11_CEL11)
   NOTE: requesting all-instance membership refresh for group=2
   ----------------------------------------------------------------------------------


[対象リリース]
問題が発生するリリース  ：Oracle Exadata Storage Server Software (11.2 -)
問題を修正したリリース  ：12.1.1.1.0
問題を修正予定のリリース：なし
問題を修正したPSR       ：なし
問題を修正予定のPSR     ：なし


[対象プラットフォーム]
すべてのプラットフォーム 


[起こりうる条件]
次の条件のすべてを満たす場合に発生します。
　- Exadata環境で障害があるディスクを交換した


[原因]
製品の不具合です。
交換後の新しいグリッドディスク（Grid Disk）のヘッダーを XDWK プロセスが
読み取って検証するとき、失敗と判断してしまうことがある不具合がありました。


[回避策]
ありません。


[障害発生時の対処]
グリッドディスクをディスクグループにADDする処理は成功しています。
影響は無いため無視します。


[BUG番号]
Bug 14545129
* My Oracle Supportで内容を公開していない場合があります


[参照情報]
Document 1608253.1 Exadata: ORA-15196: invalid ASM block header [kxdam.c:7810] [endian_kfbh] [0] [0] [0 != 1]

刚看到一个微博如下，不知道客户是谁，作者是谁，看了还是有不少感想。数据丟了还在找第三方小公司或所谓牛人做数据恢复？为何不找原厂？

 

微博原文如下：
“ #数据安全警示录# 今早，我艰难的告诉一个用户，他们的数据无法完全恢复。客户在硬盘出现故障后插拔硬盘加载Raid同步，进而导致数据文件出现大量坏块，归档日志损坏错乱，虽然修复了SYSTEM表空间，打开了数据库，但是坏块严重损坏了一致性。这是一个灾难！建议大家遇到类似情况，避免草率的恢复尝试！”
我的感想

 

出故障时要请专家操作，否则处理不好，小错成大错，数据丢失了造成的损失相比服务费就贵多了，而且不同的人做服务，结果也会不一样。用户应该明白什么事该谁做，这是管理的艺术。
想起最近几个客户也有数据丢失的案例，（1）保护好现场立即联系我们的，我们几个小时内把库正常打开，数据无丢失 （2）现场没保护好的，自己处理搞不定才找我们的，我们尽可能回复到最大值，同时和客户应用业务部门协同工作，把数据补全。
相信这些客户在结案时应该觉得买原厂服务是正确的。

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

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

にいる方は：+86  13764045638

Oracle DULはOracle社内部的なデータベースリカバリツールであり、オランダのOracle Support，Bernard van Duijnenによって、開發された。

• DULはOracle会社の製品じゃない。
• DULはOracle会社に支持されていない
• DULはOracle Supportアフタサービス部門の技術者にしか使えない。
• DULは海外で使用するのがOracle会社の許可が必要、まずはOracleの基本的なサービスを購入してから許可が得られる。さもなければ、許可が得られないでしょう。
• DULは厳密にコントロールされている原因はOracle一部のソースコードを採用したからである。

おおよそDUL 9から、Bernard van Duijnenは外の人がDULを使うことを避けたいという理由で、DULにソフトウェアタイムロックを追加した。つまり、彼は定期的に異なったプラットフォームのDULをプログラミングして、（DULはＣ言語に基づく）、そしてORACLE内部的なDUL workspaceにアップロードして(stbeehiveのスペースに基づく)、Oracle Supportは内部的なVPNによってダウンロードできる。例えば、bernard.van.duijnenは10月1日であるバーションをリリースした、時間ロックは30日なら、このバーションは11月1日に使えなくなった。DULは簡単なOSを読み取る時間じゃないから、OS時間を変更するのも役に立たない。Oracleのdatafileも現在の時間も記録したから、DULはdatafileの時間を読み取っているので、とても変更できない。

 

bernard.van.duijnenはHP-UXプラットフォームのDULを提供していないので、HP-UXプラットフォームに該当するバーションもない。

そして、ある古いバーションのOracle DULは10g、11g、12cでいま使えなくなったDULの使用はアメリカに限定されているが、中国ではそれほどじゃないが、一般的にDULを利用しているのはAdvanced Customer Servicesしかいないでしょう。それに現場サポートサビースを買うには大量な資金が必要としている。

この説明書の添付ファイルはOracle ACSが提供したDULサビースを紹介するフィルタである（現場技術サポートを買うのは高くて、そしてユーザーが毎年もPS基本的なサビースを買っている必要としているので、さもなければACSアドバンスサビースも買えなくなる。

 

DUL – DATA RECOVERY UNLOADER DataSheet

https://www.askmac.cn/wp-content/uploads/2014/01/DUL.pdf

DUL 10の取扱説明書英語バーション

DUL User’s and Configuration Guide V10.2.4.27

https://www.askmac.cn/wp-content/uploads/2014/01/DUL-Users-and-Configuration-Guide-V10.2.4.27.pdf

以下はDUL 10のダウンロードリンクで、ロックされたから、ある時間をたつと使えなくなる。

DUL FOR LINUXプラットフォーム(PRM-DULにアップデートした)

DUL FOR Windowsプラットフォーム (PRM-DULにアップデートした)

 

DULはほぼ壊滅したデータベースにデータを抽出できる。直にOracle Datafileデータフィルタにスキャンして、segment headerを識別して、Extentディスク領域の情報にアクセスして、実際の行データを読み取ることができる。

継続DULはSQLLDRの形式で読み込みフィルタやEXPフォーマットのDMPフィルタを生成することもできる。

もし、SYSTEMテーブルスペースのデータフィルタがまだあるとしたら、DULはOracleデータディクショナリーを読み取る。さもなければ、DULがサンプリングの形式で行を読み取って、そして内部的なアルゴリズムでフィールドタイプ、フィールド長さを判明する。

DULはルーチンライン、移行ライン、チェーンライン、マルチパネルとクラスタテーブルなど、ほぼすべての行タイプを対応できる。それに人工的に介入はいらない。クロスプラットフォームでデータを抽出することも支持している。DULはOracleデータインスタンスを必要としていない。Oracle Datafileから直にデータを抽出する。Dirty readを実行して、すべてのトランザクションもうサブミットしたとする。DULはメディア・リカバリする必要があるかを確認しない。そのまま壊滅したデータブロックから読み取れる。多数のデータベース構造も支持している：

チェーンライン、行の移行、ハッシュ/索引クラスタ、LONG、RAW、ROWID、日付、数値、マルチFREELIST、高水位、NULL

 

詩檀ソフト（Maclean が所属している会社）はDULに基づき、PRM-DULを開發した。DULすべての機能も含めた上で、グラフィックインタフェースとDataBridge（データがDBLINKのように直に目標データベースに伝送できる。）などの機能も追加した。そして、PRM-DULはJavaで編成したので、あらゆるプラットフォームに適応できる。

PRM-DULの無料バーションダウンロード：

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

PRM-DULの取扱説明書

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

PRM-DULの無料バーションは一つのテーブルがデフォルトで一万行しか抽出できない。目標データベースがかなり小さいの場合に、無料PRM-DULを使ってください。データベースが一万行を超えて、データの重要性も高い場合に、企業バーションを使ってください。企業バーションPRM-DULは一つのデータベースに対して、Licenseソフトウェア使用許可書を提供する。一つのLicense は$ 999 USD 。そして、PRM-DULは一部無料なLicenseを提供している。

 

もし、壊滅したデータベースがDULを使ったら、まだリカバリできない場合に、リカバリサポートサビースを考えてください：

詩檀ソフトはいまあらゆるOracleデータベースのトラブルに対応できて、主には：データベースが起動できない、誤操作でテーブルがDROPされた、TRUNCATE、DELETE，ASM DiskgroupがMOUNTできないなど。

PRM-DULはJavaに基づいて開發され、すべてのプラットフォームに対応できて、AIX、Solaris、HPUXなどのUnixプラットフォームであっても、Oracle Linux、SUSEなどのLinuxプラットフォームなどのプラットフォームであっても、Windowsプラットフォームであっても、どんなプラットフォームもそのままに運用できる。

 

PRM-DULが支持しているオペレーションシステムプラットフォーム：

Platform Name	Supported
AIX POWER	Yes
Solaris Sparc	Yes
Solaris X86	Yes
Linux X86	Yes
Linux X86-64	Yes
HPUX	Yes
MacOS	Yes

 

PRM-DULが支持しているデータベースバーション：

ORACLE DATABASE VERSION	Supported
Oracle 7	Yes
Oracle 8	Yes
Oracle 8i	Yes
Oracle 9i	Yes
Oracle 10g	Yes
Oracle 11g	Yes
Oracle 12c	Yes

 

PRM-DULが支持している言語：

 

语言	字符集	对应的编码
中国語　簡体字/繁体字	ZHS16GBK	GBK
中国語　簡体字/繁体字	ZHS16DBCS	CP935
中国語　簡体字/繁体字	ZHT16BIG5	BIG5
中国語　簡体字/繁体字	ZHT16DBCS	CP937
中国語　簡体字/繁体字	ZHT16HKSCS	CP950
中国語　簡体字/繁体字	ZHS16CGB231280	GB2312
中国語　簡体字/繁体字	ZHS32GB18030	GB18030
日本語	JA16SJIS	SJIS
日本語	JA16EUC	EUC_JP
日本語	JA16DBCS	CP939
韓国語	KO16MSWIN949	MS649
韓国語	KO16KSC5601	EUC_KR
韓国語	KO16DBCS	CP933
フランス語	WE8MSWIN1252	CP1252
フランス語	WE8ISO8859P15	ISO8859_15
フランス語	WE8PC850	CP850
フランス語	WE8EBCDIC1148	CP1148
フランス語	WE8ISO8859P1	ISO8859_1
フランス語	WE8PC863	CP863
フランス語	WE8EBCDIC1047	CP1047
フランス語	WE8EBCDIC1147	CP1147
ドイツ語	WE8MSWIN1252	CP1252
ドイツ語	WE8ISO8859P15	ISO8859_15
ドイツ語	WE8PC850	CP850
ドイツ語	WE8EBCDIC1141	CP1141
ドイツ語	WE8ISO8859P1	ISO8859_1
ドイツ語	WE8EBCDIC1148	CP1148
イタリア語	WE8MSWIN1252	CP1252
イタリア語	WE8ISO8859P15	ISO8859_15
イタリア語	WE8PC850	CP850
イタリア語	WE8EBCDIC1144	CP1144
タイ語	TH8TISASCII	CP874
タイ語	TH8TISEBCDIC	TIS620
アラビア語	AR8MSWIN1256	CP1256
アラビア語	AR8ISO8859P6	ISO8859_6
アラビア語	AR8ADOS720	CP864
スペイン語	WE8MSWIN1252	CP1252
スペイン語	WE8ISO8859P1	ISO8859_1
スペイン語	WE8PC850	CP850
スペイン語	WE8EBCDIC1047	CP1047
ポルトガル語	WE8MSWIN1252	CP1252
ポルトガル語	WE8ISO8859P1	ISO8859_1
ポルトガル語	WE8PC850	CP850
ポルトガル語	WE8EBCDIC1047	CP1047
ポルトガル語	WE8ISO8859P15	ISO8859_15
ポルトガル語	WE8PC860	CP860

 

ＰＲＭが支持しているテーブル格納タイプ：

テーブル格納タイプ	支持しているか否か
Cluster Tableクラスタ化表	YES
索引構成表，パーティションまたは非パーティション	YES
通常のヒープテーブル、パーティションまたは非パーティション	YES
一般的なヒープテーブルは、基本的な圧縮を有効にします	YES(Future)
一般的なヒープテーブルは、高度な圧縮を有効にします	NO
一般的なヒープテーブルは、ハイブリッド列圧縮を有効にします	NO
一般的なヒープテーブル暗号化を有効にします	NO
仮想列と仮想フィールドをもつテーブル	NO
チェーン行、行移行、chained rows 、migrated rows	YES

 

ＰＲＭが支持しているデータタイプ

データタイプ	支持しているか否か
BFILE	No
Binary XML	No
BINARY_DOUBLE	Yes
BINARY_FLOAT	Yes
BLOB	Yes
CHAR	Yes
CLOB and NCLOB	Yes
Collections (including VARRAYS and nested tables)	No
Date	Yes
INTERVAL DAY TO SECOND	Yes
INTERVAL YEAR TO MONTH	Yes
LOBs stored as SecureFiles	Future
LONG	Yes
LONG RAW	Yes
Multimedia data types (including Spatial, Image, and Oracle Text)	No
NCHAR	Yes
Number	Yes
NVARCHAR2	Yes
RAW	Yes
ROWID, UROWID	Yes
TIMESTAMP	Yes
TIMESTAMP WITH LOCAL TIMEZONE	Yes
TIMESTAMP WITH TIMEZONE	Yes
User-defined types	No
VARCHAR2 and VARCHAR	Yes
XMLType stored as CLOB	No
XMLType stored as Object Relational	No

 

ＰＲＭがASMに’対する支持

 

ファンクション	支持しているか否か
ASMから直接にデータを抽出し、ファイルにコーピーする必要がない	YES
ASMからデータをコーピーする	YES
ASM metadataを修復する	YES
ASMブラックボックスをグラフィカルに示す	Future

ＰＲＭがASMに’対する支持

 

ファンクション	支持しているか否か
ASMから直接にデータを抽出し、ファイルにコーピーする必要がない	YES
ASMからデータをコーピーする	YES
ASM metadataを修復する	YES
ASMブラックボックスをグラフィカルに示す	Future

 

 

 

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

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からシステムデータファイルを使うでしょうか（異なるデータベースをインストール）

 

最近有个大型客户，Oracle DB和IBM DB2都经历了相似的故障，IBM DB2故障后不能重新打开，库中数据丢失，需要从别的来源倒入，历时很多天；

Oracle则在原厂顶级高手的努力下，几个小时就把库打开，避免数据丢失。产品和服务缺一不可，很多高难度问题，尤其不公开的诀窍，只有原厂懂。

通过这个PK, 再次证明选择的重要性。尽管一些企业目前热衷于去IOE,  但请想仔细想想自己是否适合。

俗话说“好马配好鞍”，如果你的业务真那么关键和重要，费用也能承受的情况下，建议还是选择oracle及其原厂服务。关键时候绝对给力，为你成功保驾护航！

感谢现场工程师的给力表现和客户的选择！致敬！！！

在物理备库上restore datafile时遇到RMAN-06026错误：

 

 

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

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

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

 

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

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

 

RMAN> run{
debug on;
set until time "to_date('2013-08-08 19:12:03','yyyy-mm-dd hh24:mi:ss')";
restore database ;
debug off;
}
2> 3> 4> 5> 6> 
RMAN-03036: Debugging set to level=9, types=ALL

RMAN-03023: executing command: SET until clause

RMAN-03090: Starting restore at 2013-08-15 10:19:14
RMAN-06009: using target database control file instead of recovery catalog
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08605: channel ORA_DISK_1: SID=661 instance=PTRDDB1 device type=DISK

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/15/2013 10:19:18
RMAN-06026: some targets not found - aborting restore
RMAN-06100: no channel to restore a backup or copy of datafile 7
RMAN-06100: no channel to restore a backup or copy of datafile 4
RMAN-06100: no channel to restore a backup or copy of datafile 3
RMAN-06100: no channel to restore a backup or copy of datafile 2
RMAN-06100: no channel to restore a backup or copy of datafile 1

RMAN> 

RMAN> 

RMAN> 

RMAN> 

RMAN> 

RMAN> run{
debug on;
set until time "to_date('2013-08-08 19:12:03','yyyy-mm-dd hh24:mi:ss')";
restore database preview;
debug off;
}2> 3> 4> 5> 6> 

RMAN-03036: Debugging set to level=9, types=ALL

RMAN-03023: executing command: SET until clause

RMAN-03090: Starting restore at 2013-08-15 10:19:48
RMAN-12016: using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/15/2013 10:19:54
RMAN-06026: some targets not found - aborting restore
RMAN-06100: no channel to restore a backup or copy of datafile 7
RMAN-06100: no channel to restore a backup or copy of datafile 4
RMAN-06100: no channel to restore a backup or copy of datafile 3
RMAN-06100: no channel to restore a backup or copy of datafile 2
RMAN-06100: no channel to restore a backup or copy of datafile 1

 

 

 

检查数据文件的ABSOLUTE_FUZZY_CHANGE#，发现 出现问题的数据文件 1、2、3、4、7 有较大的ABSOLUTE_FUZZY_CHANGE#。

 

 

      recid     file#     checkpoint_time  checkpoint_change#    ABSOLUTE_FUZZY_CHANGE#
      3934          3 2013-08-08 19:00:50          424443795              424454469
      3935          4 2013-08-08 19:00:50          424443795              424454521
      3936          7 2013-08-08 19:00:50          424443795              424456295
      3937          8 2013-08-08 19:00:50          424443795                      0
      3938          9 2013-08-08 19:00:50          424443795                      0
      3939          2 2013-08-08 19:00:50          424443795              424452449
      3940          5 2013-08-08 19:00:50          424443795                      0
      3941          1 2013-08-08 19:00:50          424443795              424453386
      3942         10 2013-08-08 19:00:50          424443795                      0
      3943          6 2013-08-08 19:00:50          424443795                      0
      3944         11 2013-08-08 19:00:50          424443795                      0
      3945          0 2013-08-08 19:00:50          424443795                      0
      3946          0 2013-08-08 19:00:50          424443795                      0
      3948          0 2013-08-08 19:00:50          424443795                      0
3949          0 2013-08-08 19:27:03          424492130                      0

 

 

 

对于restore until time而言要求数据文件备份的ABSOLUTE_FUZZY_CHANGE#对应的时间点要小于指定的until time 时间点，rman才认为该数据文件备份是有效的，否则将跳过该备份。

 

 

ABSOLUTE_FUZZY_CHANGE#是rman备份中服务进程读取到数据块中的High Scn，为了维护一致性要求 restore时恢复到的时间点 要 大约备份点对应的checkpoint_change#和ABSOLUTE_FUZZY_CHANGE#。

 

 

详见文档Common Causes for RMAN-06023 and RMAN-06026 (Doc ID 1366610.1)

 

 

Backup start on T1 (SCN=1000) and ends on T2 (SCN=1050), than the backup can ONLY be used if the UNTIL SCN is 1050 or higher.
So if the ‘UNTIL TIME T2’ is converted to SCN 1045, than this backup will NOT be used.
V$BACKUP_DATAFILE / RC_BACKUP_DATAFILE is giving more info on this.
CHECKPOINT_CHANGE# corresponds with T1
ABSOLUTE_FUZZY_CHANGE# corresponds with T2. When ABSOLUTE_FUZZY_CHANGE# is NULL, than it is the same as the CHECKPOINT_CHANGE#

 

 

 

我们测试使用restore until scn并指定大于ABSOLUTE_FUZZY_CHANGE#的一个SCN,可以绕过该问题:

 

 

RMAN> run
{
set until scn 424456295;
restore database preview;
}2> 3> 4> 5> 

executing command: SET until clause

Starting restore at 2013-08-15 13:30:39
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=649 instance=PTRDDB1 device type=DISK

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
------- ---- -- ---------- ----------- ------------ -------------------
6719    Full    554.91M    DISK        00:02:38     2013-08-08 19:07:21
        BP Key: 6719   Status: AVAILABLE  Compressed: YES  Tag: TAG20130808T190511
        Piece Name: /export/home/oracle/rman/ptddb_before_3nogq6j8
  List of Datafiles in backup set 6719
  File LV Type Ckp SCN    Ckp Time            Name
  ---- -- ---- ---------- ------------------- ----

 

 

 

但是使用该scn对应的时间点则失败：

 

通过dump logfile 获得scn对应的时间点：

 

 

scn 424456290        194CB062    194cb062   08/08/2013 19:07:00
scn 424464586        194CD0CA   194cd0ca   08/08/2013 19:12:03
scn 424456295        194CB067    194cb067   08/08/2013 19:07:00  ==>之前使用成功的SCN号对应的时间点

 

 

 

之前我们测试成功的scn 424456295 对应时间点08/08/2013 19:07:00， 但使用set until time该时间点仍报错

 

 

 

 RMAN>  run{
set until time "to_date('2013-08-08 19:07:20','yyyy-mm-dd hh24:mi:ss')";
restore database preview;
}2> 3> 4> 

executing command: SET until clause

Starting restore at 2013-08-15 13:28:41
using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/15/2013 13:28:42
RMAN-06026: some targets not found - aborting restore
RMAN-06100: no channel to restore a backup or copy of datafile 7
RMAN-06100: no channel to restore a backup or copy of datafile 4
RMAN-06100: no channel to restore a backup or copy of datafile 3
RMAN-06100: no channel to restore a backup or copy of datafile 2
RMAN-06100: no channel to restore a backup or copy of datafile 1

 

 

 

由于在数据库open之前没有严格的scn和时间的对照表，所以set until time时通过评估将时间转换为scn的， rman在这里只能做评估(estimate)。 特别是某个十分接近于备份结束的时间点的时间戳时，若该时间戳被转换为scn，且该scn小于对应备份的数据文件的ABSOLUTE_FUZZY_CHANGE#，则会造成该备份不可用。
该问题详见Common Causes for RMAN-06023 and RMAN-06026 (Doc ID 1366610.1)中的描述：
When an SET UNTIL TIME is being used, RMAN will convert it to an UNTIL SCN. This is an estimate as there is NO hard relation between a timestamp and an SCN.

RMAN is making an estimate. Especially when a timestamp is used which is close to the end-time of the backup, than this might be an issue. If the conversion to an SCN is generating an SCN which is BEFORE the end fuzziness of the datafiles in the backup, than the backup can NOT be used.

 

 

建议：

Restore database/datafile 建议优先使用set until scn 指定scn号，该scn号应当大于checkpoint_change#和ABSOLUTE_FUZZY_CHANGE#。
ABSOLUTE_FUZZY_CHANGE#信息可以通过V$BACKUP_DATAFILE视图获得。

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

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

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

SQL> startup;
ORACLE instance started.

Total System Global Area 1419685888 bytes
Fixed Size                  2288344 bytes
Variable Size             536872232 bytes
Database Buffers          872415232 bytes
Redo Buffers                8110080 bytes
Database mounted.
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2],
[38], [4248], [4250], [], [], [], [], [], [], []


SQL> recover database;
Media recovery complete.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2],
[38], [4248], [4250], [], [], [], [], [], [], []


SQL> 
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/s01/diag/rdbms/mac/MAC_1/trace/MAC_1_ora_8585.trc



----------------------------------------------
WARNING! Crash recovery of thread 2 seq 38 is
ending at redo block 4248 but should not have ended before
redo block 4250
Incident 19490 created, dump file: /s01/diag/rdbms/mac/MAC_1/incident/incdir_19490/MAC_1_ora_8585_i19490.trc
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []

2013-07-07 01:01:41.295135 : Abort recovery for domain 0, flags = 0x4
2013-07-07 01:01:41.295177 : kjb_abort_recovery: domain flags=0x0, valid=0
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []
2013-07-07 01:01:41.295860 : Abort recovery for domain 0, flags = 0x4
2013-07-07 01:01:41.295876 : aborting recovery of 0 (0) with cluster inc 2 (0) recovery 1
2013-07-07 01:01:41.295890 : kjb_abort_recovery: domain flags=0x0, valid=0
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []

*** 2013-07-07 01:01:51.235
*** 2013-07-07 01:01:51.235800 13917 dbsdrv.c
Successfully allocated 2 recovery slaves
Parallel Media Recovery started with 2 slaves

*** 2013-07-07 01:02:07.397
Slave# 3: PR01 exited
Slave# 2: PR02 exited
Slave# 1: PR00 exited
ksvp2penabled: ep->flg = 0, rpr->slv_flg = 0
ksvp2penabled: ep = 0x7f9d0f67fe98, rpr = 0xb4da61c8

*** 2013-07-07 01:02:11.666
2013-07-07 01:02:11.666458 : Start recovery for domain=0, valid=0, flags=0x4
Successfully allocated 2 recovery slaves
Using 67 overflow buffers per recovery slave
Thread 2 checkpoint: logseq 38, block 2, scn 2678499
  cache-low rba: logseq 38, block 3797
    on-disk rba: logseq 38, block 4250, scn 2679872
  start recovery at logseq 38, block 3797, scn 0
Thread 1 checkpoint: logseq 35, block 2, scn 2661821
  cache-low rba: logseq 35, block 52000
    on-disk rba: logseq 35, block 52006, scn 2679836
  start recovery at logseq 35, block 52000, scn 0

*** 2013-07-07 01:02:11.696
Started writing zeroblks thread 1 seq 35 blocks 52006-52013
WARNING! Crash recovery of thread 2 seq 38 is
ending at redo block 4248 but should not have ended before
redo block 4250
Incident 19491 created, dump file: /s01/diag/rdbms/mac/MAC_1/incident/incdir_19491/MAC_1_ora_8585_i19491.trc
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []

2013-07-07 01:02:12.266277 : Abort recovery for domain 0, flags = 0x4
2013-07-07 01:02:12.266316 : kjb_abort_recovery: domain flags=0x0, valid=0
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []
2013-07-07 01:02:12.266546 : Abort recovery for domain 0, flags = 0x4
2013-07-07 01:02:12.266566 : aborting recovery of 0 (0) with cluster inc 2 (0) recovery 1
2013-07-07 01:02:12.266578 : kjb_abort_recovery: domain flags=0x0, valid=0
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [2], [38], [4248], [4250], [], [], [], [], [], [], []



SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump controlf 3;
Statement processed.
SQL> oradebug tracefile_name
/s01/diag/rdbms/mac/MAC_1/trace/MAC_1_ora_8898.trc

low cache rba:(0x26.ed5.0) on disk rba:(0x26.109a.0)
on disk scn: 0x0000.0028e440 07/06/2013 13:11:33

原因是读取thread 2的redo logfile发现其仅写到4248个块， 但实际control中记录ON DISK DBA该为109a 即4250。

尝试重建控制文件：

SQL> alter database backup controlfile to trace;

Database altered.



SQL> alter system set cluster_database=false scope=spfile;

System altered.

SQL> startup force nomount;
ORACLE instance started.

Total System Global Area 1419685888 bytes
Fixed Size                  2288344 bytes
Variable Size             536872232 bytes
Database Buffers          872415232 bytes
Redo Buffers                8110080 bytes

CREATE CONTROLFILE REUSE DATABASE "MAC" NORESETLOGS  NOARCHIVELOG
    MAXLOGFILES 192
    MAXLOGMEMBERS 3
    MAXDATAFILES 1024
    MAXINSTANCES 32
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 (
    '+DATADG/MAC/ONLINELOG/group_1.263.819691857',
    '+DATADG/MAC/ONLINELOG/group_1.264.819691859'
  ) SIZE 50M BLOCKSIZE 512,
  GROUP 2 (
    '+DATADG/MAC/ONLINELOG/group_2.265.819691861',
    '+DATADG/MAC/ONLINELOG/group_2.266.819691861'
  ) SIZE 50M BLOCKSIZE 512,
  GROUP 3 (
     '+DATADG/MAC/ONLINELOG/group_3.272.819692415',
    '+DATADG/MAC/ONLINELOG/group_3.273.819692417'
  ) SIZE 50M BLOCKSIZE 512,
  GROUP 4 (
    '+DATADG/MAC/ONLINELOG/group_4.274.819692419',
    '+DATADG/MAC/ONLINELOG/group_4.275.819692421'
  ) SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  '+DATADG/MAC/DATAFILE/system.258.819691771',
  '+DATADG/MAC/DATAFILE/sysaux.257.819691725',
  '+DATADG/MAC/DATAFILE/undotbs1.260.819691817',
  '+DATADG/MAC/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/system.269.819691869',
   '+DATADG/MAC/DATAFILE/users.259.819691817',
  '+DATADG/MAC/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/sysaux.268.819691869',
  '+DATADG/MAC/DATAFILE/undotbs2.271.819692307',
  '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/system.279.819692587',
  '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/sysaux.277.819692585',
  '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/users.280.819692587',
  '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/example.278.819692585'
CHARACTER SET AL32UTF8
;


RECOVER DATABASE
-- Database can now be opened normally.

alter system set cluster_database=true scope=spfile;

startup force mount;


ALTER DATABASE OPEN;
-- Open all the PDBs.
ALTER PLUGGABLE DATABASE ALL OPEN;
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE '+DATADG/MAC/TEMPFILE/temp.267.819691865' REUSE;
ALTER SESSION SET CONTAINER = PDB$SEED;
ALTER TABLESPACE TEMP ADD TEMPFILE '+DATADG/MAC/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/pdbseed_temp01.dbf' REUSE;

ALTER SESSION SET CONTAINER = MACC;
ALTER TABLESPACE TEMP ADD TEMPFILE '+DATADG/MAC/DD7D8C1D4C234B38E04325AAE80AF577/DATAFILE/macc_temp01.dbf' REUSE;
ALTER SESSION SET CONTAINER = CDB$ROOT;

重建控制文件后问题消失， 主要问题还是 主机断电对redo logfile的写丢失， 而控制文件却更新了on disk rba，导致控制文件中的RBA大于redo logfile中实际存在的， 通过重建控制文件后2者一致 从而问题消失。

针对Flash Recovery Area删除文件不回收空间的问题诊断， 即在FRA下删除了文件但space未被回收的情况， 首先收集如下信息

 

ALERT LOG

 

select * from v$recovery_area_usage;

select * from v$recovery_file_dest;

 

rman 收集：

show all;

catalog recovery area;

 

并收集以下TRACE:

alter session set events ‘immediate trace name kra_trace level 1’;

execute dbms_backup_restore.refreshAgedFiles;

alter session set events ‘immediate trace name kra_trace level 4’;

在有充分审计Audit   SQL的情况下，定位某条DROp/Truncate DDl还是比较容易的。

 

问题是 没有任何SQL审计时呢？

 

首先需要 明确的是 对于 关键的产品数据库系统而言 有效的审计非常重要，不能将以下的方法当做审计选项来用。

其次对于重要的环境和重要的对象， 一般推荐创建一个DDL Trigger 让直接运行的DDL报错，而需要先将对应的DDL Disable之后才能成功 执行DDL， 这样可以降低表/索引因为人为失误导致的误操作。

 

最简单的仍是通过 dba_objects 定位其最后的DDL时间，虽然这个LAST_DDL_TIME 未必是真实的案发时间了， 但如何与应用程序报错结合起来 还是能大致了解问题发生的时间段的， 而这个时间段 对于问题追查至关重要。 此外对于DROP命令而言显然弄不到这个LAST_DDL_TIME。

 

接着可以通过ASH 视图 DBA_HIST_ACTIVE_SESS_HISTORY和 V$ACTIVE_SESSION_HISTORY来定位一些DDL语句， 由于ASH默认是1秒采样一次，所以如果遇到了一些例如RAC 中truncate/drop 常见的 DFS Lock Handle、Enqueue Lock等等待，那么一般ASH都能捕捉到这个DDL，当然这也看运气，毕竟ASH不是审计功能。

 

SQL_OPCODE    12 为DROP TABLE  10为 DROP INDEX、85为TRUNCATE TABLE、86为TRUNCATE CLUSTER

select USER_ID, SQL_OPCODE, XID, SAMPLE_TIME,MODULE,MACHINE
from v$active_session_history
where SQL_OPCODE in (12, 10, 85, 86)
and SAMPLE_TIME between xx and xx;

select USER_ID, SQL_OPCODE, XID, SAMPLE_TIME,MODULE,MACHINE
from dba_hist_active_sess_history
where SQL_OPCODE in (12, 10, 85, 86)
and SAMPLE_TIME between xx and xx;

 

如果上述查询给出少量精准结果(例如MACHINE和MODULE很特殊)，那么一般就很容易定位了。  如果查出大量结果，一般优先排除应用程序模块例如 JDBC Thin，如果应用程序本身有BUG导致莫名的DDL，那么理论上应当经常发生。 如果看到一些例如SQLPLUS、PL/SQL Developer认为登陆执行上述命令的记录，则需要特别关注。

 

由于DDL语句不作为 共享SQL保存在V$SQL、V$SQLAREA中所以 就算你获得了SQL_ID还是看不到这些SQL语句的，所以无法通过SQL_TEXT来定位这些SQL到底是什么样子。

 

这个时候往往需要做Logminer了， 但好在我们有大致的Sample  Time和XID 这样定位SQL就很简单。

 

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => ‘/oracle/logs/log1.f’, OPTIONS => DBMS_LOGMNR.NEW);

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => ‘/oracle/logs/log2.f’, OPTIONS => DBMS_LOGMNR.ADDFILE);
execute DBMS_LOGMNR.START_LOGMNR(DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG+DBMS_LOGMNR.COMMITTED_DATA_ONLY);
SELECT (XIDUSN || ‘.’ || XIDSLT || ‘.’ || XIDSQN) AS XID,
USERNAME, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE XID=’XXX’;

EXECUTE DBMS_LOGMNR.END_LOGMNR;

 

 

此外在没有审计的情况下 值得参考的数据还有 Listener监听器的日志、OS登陆的Shell日志等。

ORA-1410 invalid rows错误是与ORA-8103相似的Oracle数据库逻辑层面的讹误。

 

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

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

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

 

了解ORA-1410逻辑坏块问题的成因，以及有效的解决手段十分重要。

解决方案之一：

可以通过如下PL/SQL过程将健康数据复制到新建表中，对于问题数据块中的数据将被跳过，对于能够容忍数据丢失的场景可以考虑这样恢复，之后truncate 原表/分区并将健康数据加载进去。 具体的脚本见下面的链接：

【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题

 

oerr ora 1410
01410, 00000, “invalid ROWID”
// *Cause:
// *Action:

如果对ORA-1410做errorstack 一般会看到下面的LOG:

OBJD MISMATCH typ=6, seg.obj=%d, diskobj=%d, dsflg=%d, dsobj=%d, tid=%d, cls=%d

 

触发ORA-1410错误的stack call一般都是：  kcbgtcr=>kcbzib=>kcbz_check_objd_typ，即在对数据块做逻辑读时运行到kcbz_check_objd_typ函数时，检测到OBJD 不一致的问题。由于seg.obj和diskobj不一致，而10g以后的kcbz_check_objd_typ函数负责验证块上的objd是否mistmatch，若不一致则触发ORA-1410错误。

造成objd mimatch的主要可能有几种：

1、 写丢失 Lost Write， 写丢失造成相关数据块没有为现有对象正常格式化，导致虽然该数据块的checksum是正确的,但对应数据字典却是不一致的。 写丢失也可能由磁盘或卷组镜像同步软件的不完整复制造成。

 

If the on-disk objd is < kcbdsobj, then there is possibility of Oracle messing up or IO layer (OS Cache, Volume mgr etc) missing writes.

 

对于Lost Write在10g版本中没有太好的预防方案，隐藏”_db_lost_write_checking”控制在DBWR写数据文件后立即去读被写的块以便检测出Lost Write，但是该参数对性能的损耗较大，不建议设置。

11g中引入了DB_LOST_WRITE_PROTECT参数配合Data Guard使用可以有效检测出Lost Write问题。

 

DB_LOST_WRITE_PROTECT enables or disables lost write detection. A data block lost write occurs when an I/O subsystem acknowledges the completion of the block write, while in fact the write did not occur in the persistent storage.When the parameter is set to TYPICAL on the primary database, the instance logs buffer cache reads for read-write tablespaces in the redo log, which is necessary for detection of lost writes.   When the parameter is set to FULL on the primary database, the instance logs reads for read-only tablespaces as well as read-write tablespaces.   When the parameter is set to TYPICAL or FULL on the standby database or on the primary database during media recovery, the instance performs lost write detection.   When the parameter is set to NONE on either the primary database or the standby database, no lost write detection functionality is enabled.

 

 

2、 一些DDL操作例如Exchange Partition 造成block级别的不一致，同一个数据块被2个数据对象所使用，而当这2个对象被使用时都可能覆盖问题数据块。 实际上这种情况也可能是Lost Write所引起的。

 

3、 文档Summary Of Bugs Containing ORA 1410 (Doc ID 422771.1)介绍了引起ORA-1410的主要BUG，其中BUG 4592596(Corruption (ORA-1410) from multi-table insert with direct load) 和 BUG 3868753 (Concurrent export / INSERT of ASSM segment can fail with ORA-1410 / ORA-8103)均为对表的Direct path/Parallel INSERT引起后续对表的SELECT操作报ORA-1410错误。

这说明了Direct Path/Parallel Insert操作有小概率引发ORA-1410错误发生的可能，而常规的conventional insert则不会引发ORA-1410。

 

4、 objd mimatch也可能仅仅是Oracle Buffer Cache内存中的block存在不一致，而Disk磁盘上的block仍是完好的。这一般是Oracle Buffer层的BUG引起的，对于该种现象一般flush buffer_cache即可解决问题。虽然在本例中flush buffer_cache未能解决问题，但是若问题仅仅发生在Memory层，则仍建议先考虑flush buffer_cache。

 

针对该由于OBJD MISMATCH所引起的ORA-1410问题可以采取如下措施：

1、 尝试刷新buffer cache:

alter system flush buffer_cache;   ==>如果是RAC建议2个实例都要flush

刷新后再次运行触发ORA-1410错误的语句，若不再报错则说明刷新BUFFER_CACHE有效

 

 

2、 若flush buffer_cache解决不了问题，那么做analyze validate structure 和收集errorstack操作，分析原因：

alter session set events ‘1410 trace  name errorstack  level 3’;

运行会触发ORA-1410的语句，收集生成的trace文件

analyze table XXX   validate structure online;  ==>在线validate structure

@?/rdbms/admin/utlvaild   ==>对于分区对象需要运行utlvaild脚本

analyze table XXX partition (partition_name) validate structure online;

 

 

 

 

3、对于已经在磁盘上形成OBJD MISMATCH现象的数据对象：

a. 考虑通过move table、partition、subpartition来尝试解决该问题

alter table xxx move tablespace;

or

alter table move partition xxx tablespace;

or

alter table move sunpartition xxx tablespace;

 

ORA-1410问题相关的一些BUG罗列如下:
Bug 5637976
Abstract: ORA-8103/ORA-1410 from concurrent INSERT / export on ASSM tables
This occurs in 10gR2 when there are concurrent inserts and direct path exports. The newly created/updated blocks are not being flushed to disk, so the export is getting a stale version of the block from disk.
Fixed in 10.2.0.4 and 11.1.0.6

Unpublished Bug 4592596
Abstract: Corruption (ORA-1410) from multi-table insert with direct load
This error occurs if a SQL plan is compiled for a parallel run with a Degree of Parallelism (DOP) > 1, but at the time of running, due to lack of resources, it runs serial. Then the problem of invalid rowid will happen.
Fixed in 10.2.0.4 and 11.1.0.6.

Bug 5596325
Abstract: Text query gives wrong results or fails with ORA-1410 ORA-29903
If CONTAINS queries return ORA-1410: invalid rowid errors, and there are more than 200,000,000 documents in the index, then you may have encountered this bug.
Fixed in 10.2.0.4 and 11.1.0.6

Unpublished Bug 6444339
Abstract: TRUNCATE/PURGE DOES NOT CLEAN DEPENDENCIES PROPERLY.
DDL statements to an object were not invalidating all dependencies, so a stale rowid could remain in cache and produce a ORA-1410 if used.
Fixed in 11.2 and 10.2.0.5

Bug 8740993
Abstract: ORA-1410 OCCURRED ON ADG STANDBY DATABASE DURING TABLE SCAN.
This bug applies to standby databases and occurs when the standby is re-applying DDL for table drops/truncates/shrinks. The buffer cache is not being updated for the new object numbers.
Fixed in 12.1, 11.2.0.2