Disassembling the Oracle Data Block - A Guide to the BBED
今回はOracleの秘密ツールであるBBEDのガイドをご紹介したいと思います。 BBEDとはBlock Browser and Editorの略で、その名の通りブロックを参照したり 更新したりできるツールです。 Traceファイルなどにブロックダンプを出力せずに対話式で ブロックの内容を確認できるので便利なツールだと思います。 使用開始にあたっての準備は簡単です。Oracle解説のコーナーで説明しています。 このドキュメントでは後半のExampleコーナーで非常に丁寧に どのようにBBEDを使用するのかを説明しているので、 英語がわからないとしてもブロックの参照はできると思います。 （もし英語でわからないところがあれば気軽にお尋ねください！） ！！！！要注意！！！！ このツールの勝手な使用はサポート対象外になります。 商用環境での使用はサポートからの明確な指示が無い限り絶対に止めましょう。 もちろんその他の環境での使用もツールの仕様を良く理解した上で 自己責任で利用しましょう。 このツールは便利である反面、悪用するとDBを乗っ取ったり、 ログインや監査をすり抜けてデータを改ざんすることもできる 恐ろしいツールです。もし悪用が起きてしまった場合、今後のリリースで デフォルトで配置されなくなってしまう可能性があります。 絶対に悪用はやめましょう。 また余程のことが無い限り、editモードを使用するのは止めましょう。 browseモードでブロックの中身を見る程度にしておきましょう。 ！！！！要注意 おわり！！！！ 引用箇所はDeleteしてしまったレコードを復活するためのExampleです。 (お詫び) 引用PDFファイルがTEXTコピーできない為、全て私自身のタイプ入力です。 誤字などあるかもしれませんのでご注意ください。 このガイドの紹介サイトとしては、PL/SQLの暗号解読の回でご紹介した Pete Finniganさんが丁寧に解説してくださっているのでそちらをご覧下さい。 (暗号解読の回はこちら：http://imoment.web.fc2.com/20060827.html) ■ Pete Finnigan's Oracle security weblog http://www.petefinnigan.com/weblog/archives/00000999.htm ■ Excerpt(引用記事) http://orafaq.com/papers/dissassembling_the_data_block.pdf ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 記事本文 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ◆ Disassembling the Oracle Data Block - A Guide to the BBED Example #5 - Recovering Deleted / Damaged Data The following example demonstrates the recovery of deleted data using an older copy of the data file. This has potential uses for clients who have deleted or erroneously updated their data, but cannot afford the time required to restore the database to another location and export the table to a dump file. Connect to the database and delete the data from the table SQL> delete from scott.presidents; 9 rows deleted. SQL> commit; Commit complete. Prepare a bbed parameter file and file list with the current copy of the data file (with the deleted table) and the one from an older back with the data still intact. [oracle@pingu bbed]$ cat bed_copy.par blocksize=8192 listfile=/home/oracle/bbed/fileunix_copy.log mode=edit [oracle@ping bbed]$ cat fileunix_copy.log 1 /home/oracle/OraHome1/oradata/gctdev2/users01.dbf 26214400 2 /gct/oradata/backup2/users01.dbf 26214400 From the current database, determine the number and location of the blocks that comprise the table affected: SQL> select owner, segment_name, header_file, header_block, blocks 2 from dba_segments 3 where owner = 'SCOTT' and segment_name = "PRESIDENTS'; OWNER SEGMENT_NAME HEADER_FILE HEADER_BLOCK BLOCKS -------- -------------- ----------- ------------ ---------- SCOTT PRESIDENTS 7 11 8 So we can see that we need to restore blocks in file 7 from block 11 forward through 8 blocks. However the DBA_SEGMENTS view counts blocks from zero whereas bbed counts them from one. Therefore the bbed block where the table starts is in fact block 12. We can verify this with bbed by printing the ktbbh structure which shows the object id(see the section on the map command) as follows: BBED> set dba 1,11 DBA 0X0040000b (4194315 1,11) BBED> p ktbbh BBED-00400: invalid blocktype (35) Block 11 is empty,however when we check block 12: BBED> set dba 1,12 DBA 0X0040000c (4194316 1,12) BBED> p ktbbh struct ktbbh, 72 bytes @20 ub1 ktbbhtyp @20 0x01 (KDDBTDATA) union ktbbhsid, 4 bytes @24 ub4 ktbbhsg1 @24 0x00006c27 ub4 ktbbhod1 @24 0x00006c27 struct ktbbhcsc, 8 bytes @28 <output removed to aid clarity> b2 _ktbitfsc @86 0 ub2 _ktbitwrp @86 0x0000 ub4 ktbitbas @88 0x00000000 Notice also we are referring to DBA 1,12 rather than DBA 7,12. This is due to the use of the special parameter file where we have included both copies of the file. In this example file 1 is the damaged file and file 2 is the one from the backup with the table intact. We will now copy blocks 12 through 20 from file 2 to file 1: BBED> set offset 0 OFFSET 0 BBED> copy dba 2,12 to dba 1,12 File: /home/oracle/OraHome1/oradata/gctdev2/users01.dbf (1) Block: 12 Offsets: 0 to 511 Dba:0x0040000c ------------------------------------------------------------------------ 06020000 0c00c001 16830300 00000104 2e670000 01000000 276c0000 319c0200 < output removed to aid clarity > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 The process is repeated for all 8 blocks. Once completed the Oracle database is restarted and the table checked: SQL> select * from scott.presidents; NAME START_YEAR END_YEAR ---------------------- ---------- ---------- Dwight Eisnehower 1952 1960 John Kennedy 1960 1963 Lindon Johnson 1963 1969 Richard Nixon 1969 1974 Gerald Ford 1974 1977 Jimmy Carter 1977 1981 Ronald Reagan 1981 1989 George H Bush 1989 1993 Bill Clinton 1993 2001 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 英語の解釈 ※自然な語順で解釈するために敢えて不自然な語順になっている部分があります。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ◆ Disassembling the Oracle Data Block - A Guide to the BBED オラクルのデータ・ブロックの分解 - BBEDガイド Example #5 - Recovering Deleted / Damaged Data 例５ - 削除または壊れたデータの回復 The following example demonstrates the recovery of deleted data using an older copy of the data file. 以下の例ではデータファイルの古いコピーを使用した削除データの回復を 行っています。 This has potential uses for clients who have deleted or erroneously updated their data, but cannot afford the time required to restore the database to another location and export the table to a dump file. これは顧客がデータを削除したり、誤って更新してしまった場合に、 DBを別の場所にリストアしてエクスポートするような余裕が無い場合に 使用する可能性があります。 Connect to the database and delete the data from the table DBへ接続し、テーブルからデータを削除します。 SQL> delete from scott.presidents; 9 rows deleted. SQL> commit; Commit complete. Prepare a bbed parameter file and file list with the current copy of the data file (with the deleted table) and the one from an older back with the data still intact. bbedパラメタファイルと現在の(DELETEしたテーブルを含む)データファイルの コピー及びデータがまだ削除されていない古いバックアップを羅列したファイルリスト を準備します。 [oracle@pingu bbed]$ cat bed_copy.par blocksize=8192 listfile=/home/oracle/bbed/fileunix_copy.log mode=edit [oracle@ping bbed]$ cat fileunix_copy.log 1 /home/oracle/OraHome1/oradata/gctdev2/users01.dbf 26214400 2 /gct/oradata/backup2/users01.dbf 26214400 From the current database, determine the number and location of the blocks that comprise the table affected: 現在のデータベースから、影響するテーブルを含んでいるブロック位置と 番号を決定します。 SQL> select owner, segment_name, header_file, header_block, blocks 2 from dba_segments 3 where owner = 'SCOTT' and segment_name = "PRESIDENTS'; OWNER SEGMENT_NAME HEADER_FILE HEADER_BLOCK BLOCKS -------- -------------- ----------- ------------ ---------- SCOTT PRESIDENTS 7 11 8 So we can see that we need to restore blocks in file 7 from block 11 forward through 8 blocks. これでリストアに必要なブロックがファイル番号７のブロック番号１１から ８ブロック先までであることを確認できます。 However the DBA_SEGMENTS view counts blocks from zero whereas bbed counts them from one. しかしながら、DBA_SEGMENTSビューはブロックをゼロからカウントしているのに 対してbbedは１からカウントしています。 Therefore the bbed block where the table starts is in fact block 12. その為、bbed上でテーブルが始まる実際のブロックは１２になります。 We can verify this with bbed by printing the ktbbh structure which shows the object id(see the section on the map command) as follows: bbedでオブジェクトIDを表示するktbbh(トランザクションヘッダ)構造体をプリント することで以下のように証明することができます。(mapコマンドセクション参照) BBED> set dba 1,11 DBA 0X0040000b (4194315 1,11) BBED> p ktbbh BBED-00400: invalid blocktype (35) Block 11 is empty,however when we check block 12: ブロック１１は空ですが、ブロック１２をチェックすると、、、 BBED> set dba 1,12 DBA 0X0040000c (4194316 1,12) BBED> p ktbbh struct ktbbh, 72 bytes @20 ub1 ktbbhtyp @20 0x01 (KDDBTDATA) union ktbbhsid, 4 bytes @24 ub4 ktbbhsg1 @24 0x00006c27 ub4 ktbbhod1 @24 0x00006c27 struct ktbbhcsc, 8 bytes @28 ＜output removed to aid clarity＞ ＜見易くする為に出力結果を一部削除しています＞ b2 _ktbitfsc @86 0 ub2 _ktbitwrp @86 0x0000 ub4 ktbitbas @88 0x00000000 Notice also we are referring to DBA 1,12 rather than DBA 7,12. DBA 7,12ではなく、DBA 1,12を参照していることに注意してください。 This is due to the use of the special parameter file where we have included both copies of the file. これは２つデータファイルのコピーを含む特別なパラメタファイルを 使用している為です。 In this example file 1 is the damaged file and file 2 is the one from the backup with the table intact. この例では、ファイル１は壊れたファイルでファイル２はテーブルがまだ 残っているバックアップファイルです。 We will now copy blocks 12 through 20 from file 2 to file 1: これからファイル２からファイル１へブロック１２から２０をコピーします。 BBED> set offset 0 OFFSET 0 BBED> copy dba 2,12 to dba 1,12 File: /home/oracle/OraHome1/oradata/gctdev2/users01.dbf (1) Block: 12 Offsets: 0 to 511 Dba:0x0040000c ------------------------------------------------------------------------ 06020000 0c00c001 16830300 00000104 2e670000 01000000 276c0000 319c0200 ＜ output removed to aid clarity ＞ 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 The process is repeated for all 8 blocks. この処理は８ブロック分全てに対して繰り返されます。 Once completed the Oracle database is restarted and the table checked: 終了したらオラクルデータベースを再起動し、テーブルを確認します。 SQL> select * from scott.presidents; NAME START_YEAR END_YEAR ---------------------- ---------- ---------- Dwight Eisnehower 1952 1960 John Kennedy 1960 1963 Lindon Johnson 1963 1969 Richard Nixon 1969 1974 Gerald Ford 1974 1977 Jimmy Carter 1977 1981 Ronald Reagan 1981 1989 George H Bush 1989 1993 Bill Clinton 1993 2001 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 単語/英文解説 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ Disassembling : 分解 The following 〜 : 後続に関する説明文の出だし This has potential uses for clients who have deleted or erroneously updated their data, but cannot afford the time required to restore the database to another location and export the table to a dump file. whoからdataまではclientの修飾 requiredから文の最後まではtimeの修飾 Prepare a bbed parameter file and file list with the current copy of the data file (with the deleted table) and the one from an older back with the data still intact. bbed parameterはbbed起動時に指定できる設定内容が含まれたファイル。 （引用ドキュメント４ページ最下行のThe following...以降の説明参照） file listはbbedで使用するデータファイルの情報を含んだリスト （引用ドキュメント５ページ中段のThe list file should...以降の説明参照） comprise : 含む、構成する forward through 8 blocks : 8ブロック先 whereas : 対極する内容をはさむ際の接続詞 verify : （証拠や確認によって）証明する、立証する ktbbh structure : bbed では特定の構造体に当てはめてブロックの内容を表示する ことができる。p ktbbhコマンドはトランザクションヘッダ構造体形式でブロックの 内容を印字する。（詳細は引用ドキュメント１０ページ中段から始まる表を参照） as follows: : 後続で何かを列挙し始める場合に使用する。 clarity : 清らかさ、認識や理解についての明快さ ＜output removed to aid clarity＞ : ＜中略＞ rather than : 単純な比較ではなく、前者より後者の方が勝っている場合に ratherをつける。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ★ 英語ぷちクイズ ★ ※答えと思うリンクをぷちっとクリックしてください。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ☆「なんでこんなミスしたの？」って言いたい場合は？ ◆Why did you do such a mistake? ┗ http://clickenquete.com/a/a.php?M0002066Q0020246A150a5 ◆Why did you make such a mistake? ┗ http://clickenquete.com/a/a.php?M0002066Q0020246A2138e ◆How did you do such a mistake? ┗ http://clickenquete.com/a/a.php?M0002066Q0020246A3200b ◆How did you make such a mistake? ┗ http://clickenquete.com/a/a.php?M0002066Q0020246A4d9a5 ○結果を見る ┗ http://clickenquete.com/a/r.php?Q0020246Cbb1f 締切：2007年04月07日23時00分 協力：クリックアンケート http://clickenquete.com/ こたえは次回に発表します。 ■ 前回のこたえ ☆ソフトウェアの使い方を質問したい場合は？ ◆How do I use this? ◆How do you use this? ◆How can I use this? ◆How can you use this? ○結果を見る ┗ http://clickenquete.com/a/r.php?Q0019997C3483 ネイティブ数人に確認する限りはHow do you useが一番一般的だという 意見です。もちろんHow do I useも問題ありません。 doの代わりにcanを使用すると単純な"使い方"ではなく、 使う目的や能力を尋ねるイメージに変わってしまうそうです。 敢えてcanを使った質問をするのであれば、What can I use this software for? (このソフトウェアは何のために使えますか？)の方が自然だそうです。 この説明は疑問を感じる人もいる気がしますので、ご意見お待ちしています。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ Oracle 解説 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 引用の例は取り急ぎの復旧策で、redoログやarchiveなどが変わるわけでは ありませんから、復旧後にバックアップを取得する必要があると思います。 このような危険なツールはOracleからは公式に発表されていません。 でもたったの２コマンドで実行可能になります。 Windows版もあるようなのですが、私は見つけることができませんでした。 UNIX版であれば、以下のようにコマンドを実行することで使用可能になります。 cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk $ORACLE_HOME/rdbms/lib/bbed ただし使用する為にはパスワードが必要です。 もちろん公開されていないのですが、このパスワードは固定で、 bbedの実行ファイルをリバースエンジニアリングすることで簡単にわかるそうです。 私は残念ながらそんなスキルは無いので、別の方法で知ることができたのですが、 知った後にstrings -aコマンドやバイナリエディタを使用して実行ファイルの中身を 参照しても、どこに書いてあるかはわかったのですが、そこがそれだという 理由は読み取れませんでした。 申し訳ありませんが、ここでパスワードをお伝えするのは非常に微妙なので みなさんもご自分で調べてみてください。（たぶん簡単にわかります） ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 編集後記 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 今号からご購読いただいた皆様はじめまして。 本日も最後まで読んでいただきありがとうございます。 DBA Villageの投稿で見つけたのですが、 SQLだけでパイチャートを表示するファンクションを作成した人がいます。 http://technology.amis.nl/blog/index.php?p=398 脱力間違いなしなのでお時間のある方はリンク先ご覧下さい。(^-^) それではまた。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ おわりに ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 記述誤りなどのご指摘、 記事に関する疑問点・質問・感想・ご意見・ご感想など yakusa_oracle@yahoo.co.jpまでお願い致します。 簡単な自己紹介はこちら http://pr2.cgiboy.com/S/3191274 バックナンバーはこちら http://imoment.web.fc2.com/ 登録・解除はこちらから http://www.mag2.com/m/0000200441.htm
