Ｄ社の技術者は誤操作で一番大事なデータベースのSYSTEMテーブルスペースFILE#=1のフィルタと一部のアプリテーブルスペースを削除したことによって、データベースが順調に起動できない。
このシーンでPRMの《Non-Dictionary Mode(ASM) 》ASMの非ディクショナリーモードによって、今のデータフィルタに基づき、いちはやくデータをリカバリできる。
簡単な流れは以下の通り：
Ｄ社の一番大事なCRMリポジトリがASM Diskgroupに追加したディスクがI/O問題があるから。SYSTEMテーブルスペースのDBFデータフィルタがエラになり、データベースが正常に起動できない。
この時はPRMを通って、ASM DiskgroupからDATAFILEを全部フィルタシステムにコーピーして、リカバリシーン６のように、データベースを修復する。
ＰＲＭのDictionary Mode(ASM)もASMのディクショナリーモードで問題を解決できる。簡単な流れは以下の通り：
Ｄ社はASM方法でフィルタシステムとRAWデバイスをかわったが、いま運用しているのは11.2.0.1バーションで、bugが多いので、ASM DISKGROUPディスくがMOUNTをロードできなくて、いろんな手を打ったが、なかなか効果が出ない。
このシーンで使えるのはＰＲＭのASM Files Cloneフィルタコーピー機能です。この機能はダンメージを受けたASM Diskgroupからデータベースフィルタをコーピーできる。
1.インタフェースをオープンして、ToolsメニューコラムでASM File(s) Cloneを選んでください。:
ASM analyzeがDisk groupの中のフィルタとアドレス(File Extent Map)を見つけ出すために、指定されたASM Diskのディスクヘッダーを分析する。これらのデータは以後も使えるように、Derbyデータベースに記録される。ここで、ＰＲＭはASMあらゆるのMetadataを収集して分析して格納する。そして、いろいろな方法でＰＲＭの基本的な機能を改善し、グラフの形式でユーザーに示す。
ASM Analyzeが完成したら、ＰＲＭは探し出したASMのフィルタをリストにする。どれをコーピーする必要があるか、ユーザーが自分で決めて、コーピー先を指定することもできる。
コーピー段階で、ASM Fileのコーピー進捗状況を示されて、完成したら、OKをクリックしてください。
コーピー段階の進捗状況は以下のようにエクスポートする。
| Preparing selected files…
Cloning +DATA2/ASMDB1/DATAFILE/TBS2.256.839732369: ……………………..1024MB ………………………………..2048MB ………………………………..3072MB ………………………………….4096MB ………………………………..5120MB ………………………………….6144MB ……………………………….7168MB …………………………………8192MB …………………………………9216MB …………………………………10240MB …………………………………11264MB …………………………………..12288MB …………………………………….13312MB …………………………….14336MB ……………………………………..15360MB ……………………………….16384MB …………………………………17408MB …………………………………18432MB …………………………………………………………………………………………….19456MB …………………………………… Cloned size for this file (in byte): 21475885056
Cloned successfully!
Cloning +DATA2/ASMDB1/ARCHIVELOG/2014_02_17/thread_1_seq_47.257.839732751: …… Cloned size for this file (in byte): 29360128
Cloned successfully!
Cloning +DATA2/ASMDB1/ARCHIVELOG/2014_02_17/thread_1_seq_48.258.839732751: …… Cloned size for this file (in byte): 1048576
Cloned successfully!
All selected files were cloned done. |
Dbvあるいはrman validateコマンドによって、コーピーされたフィルタを確認できる。例えば：
| rman target /
RMAN> catalog datafilecopy ‘/home/oracle/asm_clone/TBS2.256.839732369.dbf’;
cataloged datafile copy datafile copy file name=/home/oracle/asm_clone/TBS2.256.839732369.dbf RECID=2 STAMP=839750901
RMAN> validate datafilecopy ‘/home/oracle/asm_clone/TBS2.256.839732369.dbf’;
Starting validate at 17-FEB-14 using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: including datafile copy of datafile 00016 in backup set input file name=/home/oracle/asm_clone/TBS2.256.839732369.dbf channel ORA_DISK_1: validation complete, elapsed time: 00:03:35 List of Datafile Copies ======================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN —- —— ————– ———— ————— ———- 16 OK 0 2621313 2621440 1945051 File Name: /home/oracle/asm_clone/TBS2.256.839732369.dbf Block Type Blocks Failing Blocks Processed ———- ————– —————- Data 0 0 Index 0 0 Other 0 127
Finished validate at 17-FEB-14
|
では’、 ASMLIBを使っているASM環境はどうやってＰＲＭを使うでしょう。
簡単に言うと、asmlibについてのASM DISKはOSでll /dev/oracleasm/disksの形式で保存する、例えば：/dev/oracleasm/disksでのフィルタをPRM ASM DISKに追加してすればいい。
| $ll /dev/oracleasm/diskstotal 0
brw-rw—- 1 oracle dba 8, 97 Apr 28 15:20 VOL001 brw-rw—- 1 oracle dba 8, 81 Apr 28 15:20 VOL002 brw-rw—- 1 oracle dba 8, 65 Apr 28 15:20 VOL003 brw-rw—- 1 oracle dba 8, 49 Apr 28 15:20 VOL004 brw-rw—- 1 oracle dba 8, 33 Apr 28 15:20 VOL005 brw-rw—- 1 oracle dba 8, 17 Apr 28 15:20 VOL006 brw-rw—- 1 oracle dba 8, 129 Apr 28 15:20 VOL007 brw-rw—- 1 oracle dba 8, 113 Apr 28 15:20 VOL008 |
/dev/oracleasm/disksでのフィルタをPRM ASM DISKに追加してください
Ｄ社のＳAシステム管理員があるデータベースのSYSTEMテーブルスーペスのフィルタを削除したことによって、データベースがうまく起動せず、データを取り出せない。でも、たとえバックアップがなくても、ＰＲＭで１００％に近いデータをリカバリできる。
此场景中启动PRM后，进入Recovery Wizard后 选择《Non-Dictionary mode》非字典模式:このシーンでＰＲＭを起動したら、Recovery Wizardに入ったら、Non-Dictionary modeを選んでください：
No-dictionaryモードでユーザーが文字セットと各国語キャラクタ・セットを指定する必要がある。システムテーブルスペースをなくした後、データベース情報の文字セットが正確に獲得できないから、ユーザーの入力が必要になる。正確に文字セットを設置したことと必要な言語パックをインストールしたことはNo-Dictionaryモードで、順調に多国語を抽出する保障である。
シーン１と同じように、いまユーザーが獲得可能なすべてのフィルタを入力し（一時的なフィルタを含まない）、正確にBlock SizeとOFFSETを設置してください：
そして、SCANをクリックしてください。SCANの役目はすべてのフィルタのSegment Headerをスキャンし、SEG$.DATとXT$.DATに記録する。Oracleの中で、一つの非パーティション表とパーティション表はテーブルデータセグメントのEXTENT MAP情報に該当する、EXTENT MAPによって、そのテーブルにすべての記録を手に入れる。
また、一つの非パーティション表をある二つのフィルタによって構造したテーブルスペースに格納し、そのSEGMENT HEADERと半分のデータがAフィルタに格納し、その
ほかの半分がBフィルタに格納する。だが、ある事情によってSYSTEMテーブルスペースもSEGMENT HEADERを格納したAフィルタもなくし、Ｂフィルタしか残っていない場合に、ただＢフィルタのデータをリカバリしたいとすれば、SEGMENT HEADERに頼らず、ＢフィルタのEXTENT MAPの情報に頼るしかない。
SEGMENT HEADERに基づく和EXTENT MAPデータのNO-Dictionaryモードのリカバリ需要を同時に満たすために、SCAN操作はここでSEG$.DATとEXT$.DATに書き込み、（テキストフィルタは診断しやすくなるため、すべてのプログラムはＰＲＭ自身が持ち込むDERBYに頼っている。）そしてDERBYデータベースに記録する。
SCANを完成したら、インタフェースの左側にデータベースアイコンが現れる。
この時、二つのバッタンを選べる。：
システムテーブルスペースをなくしたが、すべての応用データテーブルスペースが存在している場合に適応している。
DictionaryモードのTruncateテーブルデータリカバリに適応していない。
システムテーブルスペースをなくしたにかかわらず、SEGMENT HEADERを格納したフィルタもなくした場合に適応している。
簡単にいうと、シーン２の方法でTRUNCATEされたデータをリカバリできないに限って、それ以外の場合はScan Tables From Segmentsを使ってください。Scan Tables From Segmentsを使っても、必要とするデータも見つからないときにScan Tables From Extentsを使うことに考えてください。
私たちはScan Tables From Segmentsモードを優先的に利用することを勧めている。
Scan Tables From Segments完成したら、インタフェース左側の樹形図を起動できる。
Scan Tables操作はSEG$の中のSEGMENT HEADER情報でデータテーブルの情報を構造する、樹形図の中に一つのノードが一つのデータテーブルセグメントを意味する。、その名はobj+データセグメントが記録したDATA OBJECT ID。
一つのノードをクリックして、インタフェース右側のコラムを見てください。
インテリジェントフィールドタイプ分析
システムスペースをなくしたゆえに、NO-Dictionaryモードではデータテーブルの構造情報がない。その構造情報にはテーブルのフィールド名とフィールドタイプを含んでいて、そしてOracleでこれらの情報がディクショナリー情報として格納する。ユーザーがテーブルスペースを使うときに、データセグメントのROW行データで一つ一つのフィールドのタイプを当てる必要がある。ＰＲＭは最先端のＪａｖａ予測技術を応用し、10種以上のメインデータ・タイプも含まれている。
インテリジェント分析の正確度が90％を超え、自動的に多くのシーンを解決できる。
右側のコラムのフィールドの意味：
サンプルデータ分析Sample Data Analysis
この部分にはインテリジェントフィールドタイプ解析の結果で１０個のデータを解析し、そしてその結果を示す。例のデータによって、ユーザーがそのデータセグメントの中のデータを格納する様子を、もっと詳しく理解できる。
もしデータセグメントにあるデータは１０個を足りていないなら、すべての記録が表示される。
TRY TO ANALYZE UNKNOWN column type:
この部分はインテリジェントフィールド型解析が１００％で確認できないフィールドをいろんな手段をつかって解析して、ユーザーは自身の判断でタイプを判明できる。
ＰＲＭ今まだ支持していないタイプは：
XDB.XDB$RAW_LIST_T、XMLTYPE、カスタムタイプなど。
Unload Statement:
この部分はＰＲＭが生成したUNLOAD文で、システムが内部的に使用する場合とＰＲＭ開発チーム及び ParnassusDataエンジニアがサポートしている場合にしか使えない。
ドも使える。ディクショナリーモードと比べれば、主な違いは非ディクショナリーモードでユーザーが自身でフィールドのタイプを実行できる、以下のように、一部のフィールドタイプはUNKNOWNで、これらのフィールドはＰＲＭがまだ支持していないフィールドで、あるいはＰＲＭのインテリジェント解析が順調に解析できなかったから。
もしユーザーがこのテーブルが設計するときの構造さえ知っていれば（アプリ開發者からのフィルタもいい）、自身で正確なColumn Typeを選べるようになる。これによって、ＰＲＭがそのテーブルのデータを順調に目標データベースにデータバイパスできる。
Ｄ社のSAは誤操作で、オンライン業務データベースのSYSTEMテーブルスペースのフィルタと一部のアプリテーブルスペースフィルタを削除した。
このシーンで、一部のアプリデータスペースフィルタが削除されたから、その中にデータテーブルのSEGMENT HEADERフィルタを含む可能性があるので、Scan Tables From Segment Headerより、Scan Tables From Extentsを使うほうがいい。
ステップは以下の通り：
2.データベースを選んで、マウスの右ボタンでScan Tables From Extentsをクリックする
3.ＰＲＭインタフェースに生成した対象樹形図のデータを分析して、導出あるいはデータバイパスする。
4.そのほかの操作はシーン４と同じ。
Ｄ社のＤＢAは誤操作でTS$データディクショナリーを削除したため、データベースが起動できない。
| Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit ProductionWith the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
INSTANCE_NAME —————- ASMME
SQL> SQL> SQL> select count(*) from sys.ts$;
COUNT(*) ———- 5
SQL> delete ts$;
5 rows deleted.
SQL> commit;
Commit complete.
SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down.
Database mounted. ORA-01092: ORACLE instance terminated. Disconnection forced ORA-01405: fetched column value is NULL Process ID: 5270 Session ID: 10 Serial number: 3
Undo initialization errored: err:1405 serial:0 start:3126020954 end:3126020954 diff:0 (0 seconds) Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc: ORA-01405: fetched column value is NULL Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc: ORA-01405: fetched column value is NULL Error 1405 happened during db open, shutting down database USER (ospid: 5270): terminating the instance due to error 1405 Instance terminated by USER, pid = 5270 ORA-1092 signalled during: ALTER DATABASE OPEN… opiodr aborting process unknown ospid (5270) as a result of ORA-1092
|
このシーンでデータディクショナリーは既に壊されたから、データベースを起動するのは不可能だ。
このとき、ＰＲＭでデータベースのデータを抽出することができる。具体的な操作はシーン１とほぼ同じ、ユーザーがデータベースにあるすべてのデータベースフィルタを入力しただけでいい。
２.ディクショナリーモードを選んでくださいDictionary Mode
３. BigかLittle Endianを選ぶにはよく考えてください
４.データフィルタを追加してロードをクリックしてください。
5.実際に応じて、テーブルのデータをリカバリしてください。
ParnassusData Recovery Manager（以下略してＰＲＭ）は企業レベルのOracleデータディザスタリカバリーソフトで、OracleデータベースのインスタンスでＳＱＬを実行することじゃなく、直接にOracle9i,10g,11g,12cからデータベースのデータフィイルを抽出することにより、目標データを救うソフトである。ParnassusData Recovery ManagerはJavaに基づいて開発された安全性が高く、ダウンロードして解凍したあと、インストールすることなしにそのままで運用できて、とっても便利で使いやすいなソフトである。
ＰＲＭはGUIグラフィカルインターフェース（図１）を採用し、新たなプログラミング言語をあらかじめ勉強する必要はなく、Oracle bottom-level structure of database原理さえわかっていれば、リカバリーウィザード(Recovery Wizard)を使うことによって、データをリカバリーできる。
お客様きっとまだこういう疑問を抱いているでしょう：「RMANという応用歴史が長いOracleリカバリーマネジャーのバックアップによるリカバリーはまだ足りないというのか。なぜわざわざPRMを買う必要があるでしょう。」
ご存知の通りですが、今企業に発展し続けていくITシステムでは、データボリュムがまさに日進月歩である。データの整合性を確保することは何より大事ですが、このデータが爆発的に増加する時代のなか、今日のOracle DBAたちは既存のディスクボリュムが不足で、データ全体を格納できないやテープによるバックアップがリカバリーするときに要する時間が予想した平均修復時間に超えていたなどさまざまな課題に直面している。
「データベースにとって、バックアップは一番大事である」ということわざはあらゆるDBAのこころに刻んでいる。けど、現実の環境は千差万別で、筆者の経験では、企業データベース環境でバックアップスペースが足りないとか、購入したストレージデバイスが短期的に手に入ることができないとか、バックアップしていたが、実際にリカバリーしているとき、使えなくなったとか、現場に起きることが実に予想できない。
現実によくあるリカバリートラブルに対応するため、PRM 诗檀データベースリカバリーマネジャーソフトは開発された。PRM 诗檀データベースリカバリーマネジャーソフトはORACLEデータベース内部データ構造理解したうえで、全くバックアップしていないときにSYSTEMテーブルスペースなくしたとか、ORACLEデータディクショナリーテーブルを誤操作したとか、電源がきれたことによりデータディクショナリー一貫性をなくし、データベースを起動できないとか、さまざまな難題に対応できる。さらに、誤切断(Truncate)/削除 (Delete)業務データテーブルなど、人為的な誤操作もリカバリーできる。
Oracle専門家に限っていることじゃなく、わずか数日間しかOracleデータベースを接触していなかった方にも自由自在に運用できる。このすべてはＰＲＭのインストールがとびきりたやすいところとグラフィカル対話型インタフェースのおかげです。これにより、リカバリーを実行する技術者たちはデータベースに関する専門知識を要することじゃなく、あらためて新たなプログラミング言語を勉強する必要もない。データベースの基礎になる格納構造についてはなおさらです。マウスをクルックするだけで、余裕をもってリカバリーできる。
伝統的なリカバリーツールであるDULにたいして、ＰＲＭはDULがかなわない強みをもっている。DULはOracleオリジナル内部リカバリーツールであて、使うたびに必ずOracle内部プロセスに通する。一般的に、Oracle現場技術サポートを購入した少しのユーザーがOracle会社から派遣されたエンジニアの支援の元に、リカバリー作業が始められる。ＰＲＭは少数の専門家しかデータベースリカバリー作業しか務められないという現実を一新し、データベースがトラブルを起きる時点からリカバリー完了するまでの時間を大幅に短縮したから、企業のリカバリーコストを大分軽減した。
ＰＲＭを通ってリカバリーするには二つパータンにわけている。伝統的な抽出方法として、データをファイルから完全抽出して、フラットテキストファイルに書き入れて、そしてSQLLDRなどツールでデータベースへロードする。伝統の使い方がわかりやすいが、既存二倍のデータボリュームのスペースを要求するというデメリットがある。つまり、ひとつのフラットテキストファイルが占めているスペースとあとでテキストデータをデータベースにロードするスペース。時間についても、元のデータをファイルから抽出したから、新規データベースにロードできるため、常に二倍の時間を必要としている。
もう一つはわたしたちＰＲＭにより、独創的なデータバイパスモード、つまりＰＲＭを通ってじかにデータを抽出し、新規や他の使用可能なデータベースにロードする。これより、着陸データストレージに避けて、伝統の方法に比べて、さらに時間もスペースも節約できる。
いま、Oracle ASMの自動ストレージ管理技術はより多くの企業により採用されて、このシステムは伝統のファイルシステムよりずっと多くのメリットをもっている。例えば、性能がより高く発揮できるところ、クラスタを支持しているところ、そして管理するとき、とても便利のところ。でも、普通のユーザーにとって、ASMの格納構造があんまりにわかりにくく、いざASMであるDisk Groupの内部データ構造が故障になって、Disk GroupがMOUNTできなくなる。つまり、ユーザーたち大事なデータをASMに閉じ込まれた。こういうときは、必ずASM内部構造に詳しいOracle会社の専門家を現場に要請して、手動的にトラブルを解決する術しかない。でも、Oracle会社の現場技術サポートを買うには大量な資金が必要としている。
そこで、ＰＲＭの開発者（前Oracle会社シニアエンジニア）はOracle ASM内部データ構造に対する幅広い知識に基づき、ＰＲＭでは、ASMに対するデータリカバリー機能を追加した。
今ＰＲＭが支持しているASMに対するデータリカバリー機能は以下ご覧のとおり：
1. たとえDisk Groupが正常にMOUNTできなくても、ＰＲＭを通って、ASMディスクに使用可能なメタデータを読み取ることができる、さらにこれらのメタデータがDisk GroupにあるASMファイルをコーピーすることもできる。
2. たとえDisk Groupが正常にMOUNTできなくても、ＰＲＭを通って、ASMにあるデータファイルを読み取ることやそのまま抽出することも支持する。抽出する方法については、伝統的な抽出方法とデータバイパスモード両方も支持している。
ParnassusData Recovery Manager(PRM)はJavaに基づいて開発されたから、ＰＲＭがいろんなプラットフォームに運用できる。AIX、Solaris、HPUXなどのUnixプラットフォームも、Redhat、Oracle Linux、SUSEやLinuxプラットフォームも、あるいはWindowsプラットフォームも直接にＰＲＭを運用できる。
ＰＲＭが支持しているオペレーティングシステム：
| Platform Name | Supported |
| AIX POWER | ü |
| Solaris Sparc | ü |
| Solaris X86 | ü |
| Linux X86 | ü |
| Linux X86-64 | ü |
| HPUX | ü |
| MacOS | ü |
ＰＲＭが支持しているデータベースバーション
| ORACLE DATABASE VERSION | Supported | |
| Oracle 7 | û | |
| Oracle 8 | û | |
| Oracle 8i | û | |
| Oracle 9i | ü | |
| Oracle 10g | ü | |
| Oracle 11g | ü | |
| Oracle 12c | ü |
一部の古いサーバがまだAIX 4.3 Linux 3のような古いオペレーティングシステムを使っているため、このようなシステムでは最新なJDK（例えば、1.6/1.7）をインストールできないかもしれないので、ＰＲＭ開発者たちはこのようなことを防ぐために、ＪＤＫ1.4のプラットフォームを運用できれば、ＰＲＭを運用できるようにした。
また、Oracle10gデータベースサーバソフトはＪＤＫ1.4をもっていて、11ｇもＪＤＫ1.5もっているから、Oracle10ｇ以後のどんなバーションもＰＲＭを運用できるようになっていて、ほかのＪＤＫをインストールする必要がない。
对于没有安装JDK 1.4版本的环境，建议从以下地址下载
ＪＤＫ1.4バーションをインストールしていない環境では、いかのアドレスにダウロドしてください。
http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase14-419411.html
PRMが使用できるもっとも古いJavaソフト環境はＪＤＫ1.4ですが、ＪＤＫ1.4後が、Javaプログラムの性能が大きく上昇してきたから、ＰＲＭがＪＤＫ1.6環境でのリカバリースピードがＪＤＫ1.4より大分上回っている。
ＰＲＭを使用できる最小ハードウェア要件
| CPU中央処理装置 | せめて800 MHZ |
| 物理メモリー | せめて512 MB |
| ディスクスペース | せめて50 MB |
ＰＲＭを使うときに推薦するハードウェア構成
| CPU中央処理装置 | 2.0 GHZ |
| 物理メモリー | 2 GB |
| ディスクスペース | 2 GB |
今ＰＲＭを支持している言語
| 语言 | 字符集 | 对应的编码 |
| 中国語 簡体字/繁体字 | 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 |
注意事項：virtual column、11g optimized default columnに対して、データを抽出することは問題ないと思っているが、該当するフィールドをなくす可能性がある。これらも１１ｇから追加した新しい機能ですが、運用している技術者があまりいない。
ＰＲＭが支持しているデータタイプ
| データタイプ | 支持しているか否か |
| 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 |
ＰＲＭはJavaに基づくソフトですから、インストールする必要がなく、ZIPパッケージをダウロドしてから解凍したままでデータをリカバリーに運用できる。
| unzip prm_latest.zip |
诗檀はコマンドラインでＰＲＭを起動することをすすめている。この操作によって、より多くの診断情報を手に入れるから。
Windowsプラットフォームでの起動法
そして、prm.batがバックグラウンドでＰＲＭを起動する。
同時にＰＲＭグラフィカルメインインターフェイスを起動する
ParnassusData Recovery Manager（以下略してＰＲＭ）はビジネス用ソフトウェアである。ParnassusDataはユーザーがＰＲＭをテストするや勉強するために、コミュニティ版を提供している。（コミュニティ版のASM clone機能はなんの限りもなく、今後コミュニティ版ももっと無料機能を追加する。）
なんの限りもなく、自由自在にＰＲＭ Oracleデータベースリカバリーソフトを運用したいには、該当するライセンスを購入する必要がある、いま二種のLicenseタイプを提供している：Standard EditionとEnterprise Edition、詳しい内容はこちら：
| Community Edition | Enterprise Edition | Enterprise service | |
| free | $1500
PER DATABASE |
応相談 | |
| 支持しているデータベースの大きさ | 一万行 | 限りなし | 限りなし |
| ASM機能を支持しているか否か | YES | YES | YES |
| 電話相談や有料現場サポート | NO | YES | YES |
| DOWNLOAD | BUY NOW | BUY NOW |
ユーザーはParnassusData公式サイトhttp://www.parnassusdata.com/でPRM Licenseを購入することができる。購入する時に、リカバリーしたいデータベースの名前、つまりDBNAMEを入力する必要があって、支払いを完了してから、メールを受信する。そのメー
ルの内容は前に入力したDBNAMEと該当するLicense Keyです。
ユーザーがLicense Keyを手に入ってから、ソフトでRegisterをとうろくする。具体的使用法はこのとおり：
今後ＰＲＭを再起動する際に自動的にLicense登録情報を検出し、一度登録したら、繰り返し登録の必要はない。
Ｄ会社の業務メンテナンス技術者は製品データベースをテスト環境として、あるテーブルの全てのデータをTRUNCATEした。DBAはリカバリーしてみたが、最新なバックアップが使えなくなったことに気づき、バックアップから該当するテーブルの記録をエクスポートできなかった。そのとき、DBAはPRMを採用し、TRUNCATEしたデータをリカバリーすることにした。
その環境で、全てのデータベースファイルは使用可能で健全のため、ユーザーはディクショナリーモードでシステムテーブルスペースのファイルとTRUNCATEDされたテーブルのファイルををロードするだけでOKです。
| create table ParnassusData.torderdetail_his1 tablespace users as
select * from parnassusdata.torderdetail_his;
|
ＰＲＭを起動し、Tools => Recovery Wizardを選択する。
Nextをクリックする。
このTRUNCATEシーンではASMストレージを選んでいないため、ディクショナリーモード（Dictionary Mode）だけを選んでいればいい。
次のステップで、いくつのバラメタを選択する必要がある：EndianエンディアンとDB NAME
Oracleファイルはオペレーションシステム（OS）によって、違ったEndianエンディアン形式を採用し、エンディアンと該当するプラットフォームが以下ご覧のとおり：
| Solaris[tm] OE (32-bit) | Big |
| Solaris[tm] OE (64-bit) | Big |
| Microsoft Windows IA (32-bit) | Little |
| Linux IA (32-bit) | Little |
| AIX-Based Systems (64-bit) | Big |
| HP-UX (64-bit) | Big |
| HP Tru64 UNIX | Little |
| HP-UX IA (64-bit) | Big |
| Linux IA (64-bit) | Little |
| HP Open VMS | Little |
| Microsoft Windows IA (64-bit) | Little |
| IBM zSeries Based Linux | Big |
| Linux x86 64-bit | Little |
| Apple Mac OS | Big |
| Microsoft Windows x86 64-bit | Little |
| Solaris Operating System (x86) | Little |
| IBM Power Based Linux | Big |
| HP IA Open VMS | Little |
| Solaris Operating System (x86-64) | Little |
| Apple Mac OS (x86-64) | Little |
例えば、伝統的なUnix AIX-Based Systems (64-bit) 、HP-UX (64-bit)ではBig Endianをつかっている、ここではBig Endianに変更する：
さもないと、Linux x86-64 、WindowsではデフォルトのLittle Endianままになる。
注意事項：もし、ファイルがもともとはAIX(つまりBig Endian)に生成するなら、都合のいいため、これらのファイルをWindowsサーバへコーピーし、ＰＲＭによってデータをリカバリーするなら、元のBig Endian形式に選ぶ必要がある。
ここでは、例のファイルがLinux x86にあるため、EndianをLittleに変更し、Database name入力する。（ここに入力したデータベース名は名前だけで、データベースホントのDBNAMEにいみしていない、PRMlのLicense検出メカニズムがつかっているのはここに入力したDatabase Nameじゃなく、ホントのDBNAMEをつかっているから）：
Nextをクリックする。
Choose Filesをクリックして、一般的には、データベースが大きくなければ、データベースにある全てのファイルを選定する必要がある。データベースが大きで、そしてデータテーブルがどこのフィイルにあるかをしっていれば、SYSTEMテーブルスペースのフィイルとデータテーブル（必要）を含むフィイルしかえらべない。
注意：ChooseインターフェースではCtrl + A とShiftなどキーボード操作を支持している。
後で、特定のファイルのBlock Sizeを指定する。つまり、Oracleデータブロックの大きさをしていする必要がある。ここは実際に応じて変更すればいい。例えば、DB_BLOCK_SIZEは8Ｋだが、一部のデータブロックテーブルスペース指定が16Ｋから、テーブルスペースが8ＫじゃないデータブロックのBLOCK_SIZEを変更すればいい。
ここのOFFSETバラメタは主にRAWデバイスにファイルを格納するときにたいおうするためのバラメタです。
もし、RAWデバイスフィイルをつかっているときにOFFSETをわからなければ、$ORACLE_HOME/binのdbfsizeツールを使って確認すればいい。したのきいろの部分が示したように、ここのRAWデバイスは4ＫのOFFSETをもっている。
| $dbfsize /dev/lv_control_01
Database file: /dev/lv_control_01 Database file type: raw device without 4K starting offset Database file size: 334 16384 byte blocks |
このシーンで全てのファイルは8KのBLOCK SIZE、そしてファイルシステムはOFFSETがないので、Loadをクリックする。
Loadステップに、ＰＲＭはSYSTEMテーブルスペースでOracleデータディクショナリー情報を読み取り、自らのDerbyでデータディクショナリー新規することによって、ＰＲＭがOracleデータベースにあるさまざまなデータを操作できる。
Load完成したあと、バックグラウンドでデータベース・キャラクタ・セットと各国語キャラクタ・セットをエクスポートする。
ＰＲＭは多国言語およびOracleデータベースマルチキャラクタセットを支持しているが、ＰＲＭでデータをリカバリーしたいオペレーションシステムを事前に該当するLanguage Packsをインストールしないといけない。たとえば、Windowsオペレーションシステムでは中国語Language Packsをインストールしていないが、ORACLEデータベース・キャラクタ・セットがオペレーションシステムから独立しているから、このシーンでつかっているORACLEデータベース・キャラクタ・セットがZHS16GBKキャラクタ・セットで、オペレーションシステムは中国語を支持していないですが、このシーンでサーバに配置していないOracleクライアントは影響をうけず、正確にデータをしめすことができる。
でも、ＰＲＭをつかうにはＰＲＭでデータをリカバリーしたいオペレーションシステムが事前に該当するLanguage Packsをインストールする必要がある。例えば、ユーザーがZHS16GBKの中国語キャラクタ・セットデータベースをリカバリーしたいとき、オペレーションシステムが中国語Language Packsをインストールした必要がある。
Linuxにもfonts-chinese中国語フォントパッケージをインストールする必要がある。
Load完成したあと、PRMインターフェースの左側にはデータベースユーザーPacketによる樹形図が現れる。
USERSをクリックし、いろんなユーザー名がでる。例えば、ユーザーがPARNASSUSDATA SCHEMAの下のテーブルをリカバリーしたいが、PARNASSUSDATAをクリックして、テーブルをダブルクリックする。
該当するTORDERDETAIL_HIS表がその前にTRUNCATEDされたから、ダブルクリックしてもデータを示せない。そのとき、テーブルにマウスの右ボタンでUnload truncated dataをクリックする。
ＰＲＭはそのテーブルを含むテーブルスペースをスキャンして、truncatedされたデータを抽出できる。
上のグラフのように、TRUNCATEされたTORDERDETAIL_HISテーブルからすべての984359の記録、指定されたパスに格納する。
| $ cd /home/oracle/prm/prmdata/parnassus_dbinfo_PARNASSUSDATA/
$ ls -l ParnassusData* -rw-r–r– 1 oracle oinstall 495 Jan 18 08:31 ParnassusData.torderdetail_his.ctl -rw-r–r– 1 oracle oinstall 191164826 Jan 18 08:32 ParnassusData.torderdetail_his.dat.truncated
$ cat ParnassusData.torderdetail_his.ctl LOAD DATA INFILE ‘ParnassusData.torderdetail_his.dat.truncated’ APPEND INTO TABLE ParnassusData.torderdetail_his FIELDS TERMINATED BY ‘ ‘ OPTIONALLY ENCLOSED BY ‘”‘ TRAILING NULLCOLS ( “SEQ_ID” , “SI_STATUS” , “D_CREATEDATE” , “D_UPDATEDATE” , “B_ISDELETE” , “N_SHOPID” , “N_ORDERID” , “C_ORDERCODE” , “N_MEMBERID” , “N_SKUID” , “C_PROMOTION” , “N_AMOUNT” , “N_UNITPRICE” , “N_UNITSELLINGPRICE” , “N_QTY” , “N_QTYFREE” , “N_POINTSGET” , “N_OPERATOR” , “C_TIMESTAMP” , “H_SEQID” , “N_RETQTY” , “N_QTYPOS” )
|
データをソーステーブルにロードする（注意：元の環境を上書きされないように、SQLLDRコントロールフィルタを変更するときに、一時的なテーブルをロードしてください。
| $ sqlldr control=ParnassusData.torderdetail_his.ctl direct=yUsername:/ as sysdba
以上はsqlldrでリカバリできたデータの実例です。
Minusによって、リカバリしたデータを比べることもできる select * from ParnassusData.torderdetail_his minus select * from parnassus.torderdetail_his;
no rows selected
|
テスト中、TRUNCATEと元のテーブルと比べて、記録が完全に同様に見える。
それは、ＰＲＭはTRUNCATEテーブルの記録をリカバリできたから。
シーン１では、通常のunload+sqlldr方法を採用したが、実際使用中、私たちはかなり工夫して設計できたDataBridgeデータバイパスモードを勧めます。
なぜデータバイパスモードを使う必要があるでしょう？
通常のunload+sqlldr方法はソースデータ、抽出するデータ、および目標のデータを格納するスペースが必要、つまり、もとの空間の二倍を要求する。バックアップのスペースさえ用意できない企業に対して、これはかなり厳しい要求だと思います。
データバイパスとunload+sqlldrモードの一番大きな違いはデータバイパスはソースリポジトリからデータを抽出し、目標データベースへ転移して、もとのフィルタシステムに抽出データを格納する必要はない。
データバイパスによって、目標データベースに転移されたデータは元々構造化されたから、ＳＱＬで一貫性と整合性をかくにんできる。
データバイパスの目標データベースは異なるマシンにある場合は、ソースデータベースに対して、読み取りしかできない、読み書きIOは二つのマシンに配置し、ＰＲＭリカバリスビートがよく速くなる。
ユーザーリカバリしたいのはTruncateデータの場合に、バイパスによってすぐにソースデータベースに戻れる、リカバリ作業はマウスをクリックするだけですませる。
データバイパスモードを使うには、通常モードと同じ、左側の樹形図に必要なテーブルを選んで、右ボタンでDataBridgeオプションをクリックする。
初めてデータバイパスモードを使うときに、まずは目標データベースとつながる情報を入力する必要がある。これはSQLDEVELOPERにConnectionを構造する作業に似ている。これは目標データベースのホスト、ポート、Service_Nameおよびユーザー登録情報も含んでいる。ここに入力したユーザー情報は、後でデータバイパスを使う目標データベースのユーザーのことだから、つまり、ソースリポジトリから抽出したテーブルは指定された目標データベースユーザーへ転移する。
このように、G10R25というリンクを構造した、ユーザーはmaclean、該当するoracle Easy Connection接続文字列は192.168.1.191:1521/G10R25。
以上のようなデータベース情報入力を完成したら、Testボタンをクリックして、リンクオプションが使えるか否かを確認できる。もし、“ Connect to db server successfully “が戻ってきたら、いまリンクが使えるということを意味する。そのままSaveをクリックして、セブすればいい。
セブできたら、DataBridgeインタフェースに入って、まずはDB Connectionドロップダウンリストに、先に追加したConnection G10R25を選択する：
DB Connectionドロップダウンリストに必要とするデータベースリンクが現れていないなら、DB connectionのそばにある「…」ブタンを押してDB Connection:を追加してください
DB Connectionを正確に選んでいたら、Tablespaceドロップダウンリストが使えるようになる、ふさわしいテーブルスペースを選んでください。
Data Bridgeを使って、truncateをリカバリするときに、以下のようなことを注意してください：ソースリポジトリからtruncateデータをリカバリするときに、databridgeオプションを使って、データをソースデータベースへ伝送する場合（ソースリポジトリじゃなければ問題ない）、Databridgeを新規テーブルにインサートするアドレスはソースデータベースにtruncateされたアドレスにしないでください。さもなければ、truncateされたデータをリカバリしながら、リカバリされたばかりのデータが上書きされることになる。こういう時に上書きされたデータがリカバリできないので、ご注意をください。databridge+を使ってデータをソースデータベースにリカバリするとき、およびdatabridgeにテーブルスペースを指定する場合、ぜひ、リカバリしたいテーブルスペースをつかわないでください。
ユーザーはソースリポジトリから目標リポジトリへ伝送するテーブルの名前のマッピングを変更するか否かを選択できる。例えば、ソースリポジトリであるテーブルがTruncateされた、いまはDataBridgeにより、データをソースリポジトリへリカバリするが、元の名前をつかいたくないで、ほかの名前で格納したいとき、“if need to remap table”を選んでふさわしい名前を入力すればいい：
1.目標リポジトリに該当するテーブルの名前がすでに存在している場合に、ＰＲＭはテーブルを再構造することじゃなく、既存するテーブルを元にリカバリしたいデータをインサートする。テーブルはもう構造したから、指定したテーブルスペースが無力化になる。
２.目標リポジトリに該当するテーブルの名前がまだ存在していない場合は、ＰＲＭが指定したテーブルスペースにテーブルを構造し、リカバリしたいデータをインサートしてみます。
このシーンで私たちがリカバリしたのはTruncateされたデータで、“if data truncated”を選択する必要がある。さもなければ、ＰＲＭは通常のモードでデータを抽出するから、Truncateされたデータが見えなくなる。
Truncateデータの原理は、OracleがデータディクショナリーとSegment HeaderにテーブルのData Object IDを更新するが、実際データに一部のブロックが更新されない。データディクショナリーとセグメントヘッダーのDATA_OBJECT_IDがあとのデータブロックにあるが一致していないため、Oracleサビースプロセスがテーブル全体のデータを読み取るときに、TRUNCATEされたが、まだ上書きされていないデータは読み取れない。
ＰＲＭは自動スキャンによって、データセグメントヘッダー（Segment Header）がTRUNCATEされた後のデータブロックはTRUNCATEされた前のDATA_OBJECT_IDを判断し、ディクショナリーにテーブルフィールドの定義と自動獲得したDATA_OBJECT_IDによって、データを抽出する。
そして、”if to specify data object id”というインプットボックスが存在している。これによって、ユーザーがリカバリしたいデータのData Object IDを指定できる。Truncateデータをうまくリカバリできなかったときに限って、ParnassusDataの技術サポートを元に、指定してください。それ以外、何の数値を指定する必要がない。
以上のように、DataBridge配置を正確に配置できたら、データバイパスを実行できる。DataBridgeボタンをクリックしてください：
データバイパスが完成したら、伝送できたデータ行数と経過時間を示される。
Ｄ社のＤＢAは誤操作でTS$データディクショナリーを削除したため、データベースが起動できない。
| Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options
INSTANCE_NAME —————- ASMME
SQL> SQL> SQL> select count(*) from sys.ts$;
COUNT(*) ———- 5
SQL> delete ts$;
5 rows deleted.
SQL> commit;
Commit complete.
SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down.
Database mounted. ORA-01092: ORACLE instance terminated. Disconnection forced ORA-01405: fetched column value is NULL Process ID: 5270 Session ID: 10 Serial number: 3
Undo initialization errored: err:1405 serial:0 start:3126020954 end:3126020954 diff:0 (0 seconds) Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc: ORA-01405: fetched column value is NULL Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc: ORA-01405: fetched column value is NULL Error 1405 happened during db open, shutting down database USER (ospid: 5270): terminating the instance due to error 1405 Instance terminated by USER, pid = 5270 ORA-1092 signalled during: ALTER DATABASE OPEN… opiodr aborting process unknown ospid (5270) as a result of ORA-1092
|
このシーンでデータディクショナリーは既に壊されたから、データベースを起動するのは不可能だ。
このとき、ＰＲＭでデータベースのデータを抽出することができる。具体的な操作はシーン１とほぼ同じ、ユーザーがデータベースにあるすべてのデータベースフィルタを入力しただけでいい。
２.ディクショナリーモードを選んでくださいDictionary Mode
３. BigかLittle Endianを選ぶにはよく考えてください
４.データフィルタを追加してロードをクリックしてください。
5.実際に応じて、テーブルのデータをリカバリしてください。
Ｄ社のＳAシステム管理員があるデータベースのSYSTEMテーブルスーペスのフィルタを削除したことによって、データベースがうまく起動せず、データを取り出せない。でも、たとえバックアップがなくても、ＰＲＭで１００％に近いデータをリカバリできる。
此场景中启动PRM后，进入Recovery Wizard后 选择《Non-Dictionary mode》非字典模式:このシーンでＰＲＭを起動したら、Recovery Wizardに入ったら、Non-Dictionary modeを選んでください：
No-dictionaryモードでユーザーが文字セットと各国語キャラクタ・セットを指定する必要がある。システムテーブルスペースをなくした後、データベース情報の文字セットが正確に獲得できないから、ユーザーの入力が必要になる。正確に文字セットを設置したことと必要な言語パックをインストールしたことはNo-Dictionaryモードで、順調に多国語を抽出する保障である。
シーン１と同じように、いまユーザーが獲得可能なすべてのフィルタを入力し（一時的なフィルタを含まない）、正確にBlock SizeとOFFSETを設置してください：
そして、SCANをクリックしてください。SCANの役目はすべてのフィルタのSegment Headerをスキャンし、SEG$.DATとXT$.DATに記録する。Oracleの中で、一つの非パーティション表とパーティション表はテーブルデータセグメントのEXTENT MAP情報に該当する、EXTENT MAPによって、そのテーブルにすべての記録を手に入れる。
また、一つの非パーティション表をある二つのフィルタによって構造したテーブルスペースに格納し、そのSEGMENT HEADERと半分のデータがAフィルタに格納し、その
ほかの半分がBフィルタに格納する。だが、ある事情によってSYSTEMテーブルスペースもSEGMENT HEADERを格納したAフィルタもなくし、Ｂフィルタしか残っていない場合に、ただＢフィルタのデータをリカバリしたいとすれば、SEGMENT HEADERに頼らず、ＢフィルタのEXTENT MAPの情報に頼るしかない。
SEGMENT HEADERに基づく和EXTENT MAPデータのNO-Dictionaryモードのリカバリ需要を同時に満たすために、SCAN操作はここでSEG$.DATとEXT$.DATに書き込み、（テキストフィルタは診断しやすくなるため、すべてのプログラムはＰＲＭ自身が持ち込むDERBYに頼っている。）そしてDERBYデータベースに記録する。
SCANを完成したら、インタフェースの左側にデータベースアイコンが現れる。
この時、二つのバッタンを選べる。：
システムテーブルスペースをなくしたが、すべての応用データテーブルスペースが存在している場合に適応している。
DictionaryモードのTruncateテーブルデータリカバリに適応していない。
システムテーブルスペースをなくしたにかかわらず、SEGMENT HEADERを格納したフィルタもなくした場合に適応している。
簡単にいうと、シーン２の方法でTRUNCATEされたデータをリカバリできないに限って、それ以外の場合はScan Tables From Segmentsを使ってください。Scan Tables From Segmentsを使っても、必要とするデータも見つからないときにScan Tables From Extentsを使うことに考えてください。
私たちはScan Tables From Segmentsモードを優先的に利用することを勧めている。
Scan Tables From Segments完成したら、インタフェース左側の樹形図を起動できる。
Scan Tables操作はSEG$の中のSEGMENT HEADER情報でデータテーブルの情報を構造する、樹形図の中に一つのノードが一つのデータテーブルセグメントを意味する。、その名はobj+データセグメントが記録したDATA OBJECT ID。
一つのノードをクリックして、インタフェース右側のコラムを見てください。
インテリジェントフィールドタイプ分析
システムスペースをなくしたゆえに、NO-Dictionaryモードではデータテーブルの構造情報がない。その構造情報にはテーブルのフィールド名とフィールドタイプを含んでいて、そしてOracleでこれらの情報がディクショナリー情報として格納する。ユーザーがテーブルスペースを使うときに、データセグメントのROW行データで一つ一つのフィールドのタイプを当てる必要がある。ＰＲＭは最先端のＪａｖａ予測技術を応用し、10種以上のメインデータ・タイプも含まれている。
インテリジェント分析の正確度が90％を超え、自動的に多くのシーンを解決できる。
右側のコラムのフィールドの意味：
サンプルデータ分析Sample Data Analysis
この部分にはインテリジェントフィールドタイプ解析の結果で１０個のデータを解析し、そしてその結果を示す。例のデータによって、ユーザーがそのデータセグメントの中のデータを格納する様子を、もっと詳しく理解できる。
もしデータセグメントにあるデータは１０個を足りていないなら、すべての記録が表示される。
TRY TO ANALYZE UNKNOWN column type:
この部分はインテリジェントフィールド型解析が１００％で確認できないフィールドをいろんな手段をつかって解析して、ユーザーは自身の判断でタイプを判明できる。
ＰＲＭ今まだ支持していないタイプは：
XDB.XDB$RAW_LIST_T、XMLTYPE、カスタムタイプなど。
Unload Statement:
この部分はＰＲＭが生成したUNLOAD文で、システムが内部的に使用する場合とＰＲＭ開発チーム及び ParnassusDataエンジニアがサポートしている場合にしか使えない。
ドも使える。ディクショナリーモードと比べれば、主な違いは非ディクショナリーモードでユーザーが自身でフィールドのタイプを実行できる、以下のように、一部のフィールドタイプはUNKNOWNで、これらのフィールドはＰＲＭがまだ支持していないフィールドで、あるいはＰＲＭのインテリジェント解析が順調に解析できなかったから。
もしユーザーがこのテーブルが設計するときの構造さえ知っていれば（アプリ開發者からのフィルタもいい）、自身で正確なColumn Typeを選べるようになる。これによって、ＰＲＭがそのテーブルのデータを順調に目標データベースにデータバイパスできる。
Ｄ社のSAは誤操作で、オンライン業務データベースのSYSTEMテーブルスペースのフィルタと一部のアプリテーブルスペースフィルタを削除した。
このシーンで、一部のアプリデータスペースフィルタが削除されたから、その中にデータテーブルのSEGMENT HEADERフィルタを含む可能性があるので、Scan Tables From Segment Headerより、Scan Tables From Extentsを使うほうがいい。
ステップは以下の通り：
2.データベースを選んで、マウスの右ボタンでScan Tables From Extentsをクリックする
3.ＰＲＭインタフェースに生成した対象樹形図のデータを分析して、導出あるいはデータバイパスする。
4.そのほかの操作はシーン４と同じ。
Ｄ社はASM方法でフィルタシステムとRAWデバイスをかわったが、いま運用しているのは11.2.0.1バーションで、bugが多いので、ASM DISKGROUPディスくがMOUNTをロードできなくて、いろんな手を打ったが、なかなか効果が出ない。
このシーンで使えるのはＰＲＭのASM Files Cloneフィルタコーピー機能です。この機能はダンメージを受けたASM Diskgroupからデータベースフィルタをコーピーできる。
1.インタフェースをオープンして、ToolsメニューコラムでASM File(s) Cloneを選んでください。:
ASM analyzeがDisk groupの中のフィルタとアドレス(File Extent Map)を見つけ出すために、指定されたASM Diskのディスクヘッダーを分析する。これらのデータは以後も使えるように、Derbyデータベースに記録される。ここで、ＰＲＭはASMあらゆるのMetadataを収集して分析して格納する。そして、いろいろな方法でＰＲＭの基本的な機能を改善し、グラフの形式でユーザーに示す。
ASM Analyzeが完成したら、ＰＲＭは探し出したASMのフィルタをリストにする。どれをコーピーする必要があるか、ユーザーが自分で決めて、コーピー先を指定することもできる。
コーピー段階で、ASM Fileのコーピー進捗状況を示されて、完成したら、OKをクリックしてください。
コーピー段階の進捗状況は以下のようにエクスポートする。
| Preparing selected files…
Cloning +DATA2/ASMDB1/DATAFILE/TBS2.256.839732369: ……………………..1024MB ………………………………..2048MB ………………………………..3072MB ………………………………….4096MB ………………………………..5120MB ………………………………….6144MB ……………………………….7168MB …………………………………8192MB …………………………………9216MB …………………………………10240MB …………………………………11264MB …………………………………..12288MB …………………………………….13312MB …………………………….14336MB ……………………………………..15360MB ……………………………….16384MB …………………………………17408MB …………………………………18432MB …………………………………………………………………………………………….19456MB …………………………………… Cloned size for this file (in byte): 21475885056
Cloned successfully!
Cloning +DATA2/ASMDB1/ARCHIVELOG/2014_02_17/thread_1_seq_47.257.839732751: …… Cloned size for this file (in byte): 29360128
Cloned successfully!
Cloning +DATA2/ASMDB1/ARCHIVELOG/2014_02_17/thread_1_seq_48.258.839732751: …… Cloned size for this file (in byte): 1048576
Cloned successfully!
All selected files were cloned done. |
Dbvあるいはrman validateコマンドによって、コーピーされたフィルタを確認できる。例えば：
| rman target /
RMAN> catalog datafilecopy ‘/home/oracle/asm_clone/TBS2.256.839732369.dbf’;
cataloged datafile copy datafile copy file name=/home/oracle/asm_clone/TBS2.256.839732369.dbf RECID=2 STAMP=839750901
RMAN> validate datafilecopy ‘/home/oracle/asm_clone/TBS2.256.839732369.dbf’;
Starting validate at 17-FEB-14 using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: including datafile copy of datafile 00016 in backup set input file name=/home/oracle/asm_clone/TBS2.256.839732369.dbf channel ORA_DISK_1: validation complete, elapsed time: 00:03:35 List of Datafile Copies ======================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN —- —— ————– ———— ————— ———- 16 OK 0 2621313 2621440 1945051 File Name: /home/oracle/asm_clone/TBS2.256.839732369.dbf Block Type Blocks Failing Blocks Processed ———- ————– —————- Data 0 0 Index 0 0 Other 0 127
Finished validate at 17-FEB-14
|
では’、 ASMLIBを使っているASM環境はどうやってＰＲＭを使うでしょう。
簡単に言うと、asmlibについてのASM DISKはOSでll /dev/oracleasm/disksの形式で保存する、例えば：/dev/oracleasm/disksでのフィルタをPRM ASM DISKに追加してすればいい。
| $ll /dev/oracleasm/disks
total 0 brw-rw—- 1 oracle dba 8, 97 Apr 28 15:20 VOL001 brw-rw—- 1 oracle dba 8, 81 Apr 28 15:20 VOL002 brw-rw—- 1 oracle dba 8, 65 Apr 28 15:20 VOL003 brw-rw—- 1 oracle dba 8, 49 Apr 28 15:20 VOL004 brw-rw—- 1 oracle dba 8, 33 Apr 28 15:20 VOL005 brw-rw—- 1 oracle dba 8, 17 Apr 28 15:20 VOL006 brw-rw—- 1 oracle dba 8, 129 Apr 28 15:20 VOL007 brw-rw—- 1 oracle dba 8, 113 Apr 28 15:20 VOL008 |
/dev/oracleasm/disksでのフィルタをPRM ASM DISKに追加してください
Ｄ社の一番大事なCRMリポジトリがASM Diskgroupに追加したディスクがI/O問題があるから。SYSTEMテーブルスペースのDBFデータフィルタがエラになり、データベースが正常に起動できない。
この時はPRMを通って、ASM DiskgroupからDATAFILEを全部フィルタシステムにコーピーして、リカバリシーン６のように、データベースを修復する。
ＰＲＭのDictionary Mode(ASM)もASMのディクショナリーモードで問題を解決できる。簡単な流れは以下の通り：
Ｄ社の技術者は誤操作で一番大事なデータベースのSYSTEMテーブルスペースFILE#=1のフィルタと一部のアプリテーブルスペースを削除したことによって、データベースが順調に起動できない。
このシーンでPRMの《Non-Dictionary Mode(ASM) 》ASMの非ディクショナリーモードによって、今のデータフィルタに基づき、いちはやくデータをリカバリできる。
簡単な流れは以下の通り：
Ｄ社の職員があるいらないテーブルスペースを削除したいだが、つまりDROP TABLESPACE INCLUDING CONTENTS操作で、DROP TABLESPACEを実行したら、開發者がDROPされたTABLESPACEにSCHEMAという重要なデータがあるが、テーブルスペースがDROPされて、バックアップもないので、まさに万策尽きという状態である。
こういう時にやくに立てるのはＰＲＭのNo-Dictモードで、DROP TABLESPACEされたすべてのフィルタを抽出してください。多くのデータがこの方法でリカバリできると思うが、非ディクショナリーモードなので、もう一度リカバリしてきたデータとアプリデータテーブルを対応する必要がある。この時に、アプリ開發者の協力が必要で、データはどこのテーブルに属しているのか人工的に判明する必要がある。DROP TABLESPACE操作がデータディクショナリーを変更した上で、OBJ$で該当するテーブルスペースの目標を削除したから、OBJ$からDATA_OBJECT_IDとOBJECT_NAMEの間の関係を得られない。この時に、以下の方法を活かし、DATA_OBJECT_IDとOBJECT_NAMEの関係をより多く手に入ることができる。
| select tablespace_name,segment_type,count(*) from dba_segments where owner=’PARNASSUSDATA’ group by tablespace_name,segment_type;
TABLESPACE SEGMENT_TYPE COUNT(*) ———- ————— ———- USERS TABLE 126 USERS INDEX 136
SQL> select count(*) from obj$;
COUNT(*) ———- 75698
SQL> select current_scn, systimestamp from v$database;
CURRENT_SCN ———– SYSTIMESTAMP ————————————————————————— 1895940 25-4月 -14 09.18.00.628000 下午 +08:00
SQL> select file_name from dba_data_files where tablespace_name=’USERS’;
FILE_NAME ——————————————————————————– H:\PP\MACLEAN\ORADATA\PARNASSUS\DATAFILE\O1_MF_USERS_9MNBMJYJ_.DBF
SQL> drop tablespace users including contents;
テーブルスペースもう削除した
C:\Users\maclean>dir H:\APP\MACLEAN\ORADATA\PARNASSUS\DATAFILE\O1_MF_USERS_9MNBMJYJ_.DBF
ドライブの巻はentertainment 巻のシリアルナンバーはentertainment
フィルタが見つからない
drop tablespaceした後、TABLESPACEに該当するフィルタがOSで削除されたから。
|
この時に、フィルタリカバリツールでリカバリできる。
ＰＲＭを起動する=> recovery Wizard =>非ディクショナリーモード
非ディクショナリーモードなので、自分からふさわしい文字セットを選ぶ必要がある。
先リカバリしてきたフィルタをクリックしてスキャンする。
そしてセグメントヘッダあるいはディスク領域スキャンテーブルを選んでください。セグメントヘッダーがすべてのテーブルをひとつも漏れずに探し出すことができない場合に、ディスク領域でもう一度スキャンしてください。
そして、インタフェースの樹形図にものすごく大量なOBJXXXXXのようなテーブルが現れる。ここのOBJXXXXXはテーブルのDATA_OBJECT_IDであって、そのシステムの開發応用モードに詳しい技術者がサンプルデータ分析を参照して、テーブルとアプリテーブルをつながる。
もし、協力する技術者がいないなら、以下の方法を考えてください。
この例で使っているのはDROPしたTABLESPACEテーブルのスペースであって、データベース自身はなんの問題もないので、FLASHBACK QUERYを活かし、DATA_OBJECT_IDとテーブル名前のつながりを獲得できる。
| SQL> select count(*) from sys.obj$;
COUNT(*) ———- 75436
SQL> select count(*) from sys.obj$ as of scn 1895940; select count(*) from sys.obj$ as of scn 1895940 * 第一行がエラになり
ORA-01555:スナップショットが古すぎて、ロールバックセグメント番号（名は”SYSTEM”)が小さすぎる。
初めてはFLASHBACK QUERYでOBJ$の記録を見つけ出したいが、SYSTEM ROLLBACK SEGMENTを使ったことによって、ORA-01555になる。
この時にAWRビューDBA_HIST_SQL_PLANを使ってください。七天以内でそのテーブルにアクセスしたら実行計画からOBJECT#とOBJECT_NAMEのつながりが得られる。
SQL> desc DBA_HIST_SQL_PLAN 名称 是否为空? 类型 名前 ブランクかいなか タイプ —————————————– ——– ———————– DBID NOT NULL NUMBER SQL_ID NOT NULL VARCHAR2(13) PLAN_HASH_VALUE NOT NULL NUMBER ID NOT NULL NUMBER OPERATION VARCHAR2(30) OPTIONS VARCHAR2(30) OBJECT_NODE VARCHAR2(128) OBJECT# NUMBER OBJECT_OWNER VARCHAR2(30) OBJECT_NAME VARCHAR2(31) OBJECT_ALIAS VARCHAR2(65) OBJECT_TYPE VARCHAR2(20) OPTIMIZER VARCHAR2(20) PARENT_ID NUMBER DEPTH NUMBER POSITION NUMBER SEARCH_COLUMNS NUMBER COST NUMBER CARDINALITY NUMBER BYTES NUMBER OTHER_TAG VARCHAR2(35) PARTITION_START VARCHAR2(64) PARTITION_STOP VARCHAR2(64) PARTITION_ID NUMBER OTHER VARCHAR2(4000) DISTRIBUTION VARCHAR2(20) CPU_COST NUMBER IO_COST NUMBER TEMP_SPACE NUMBER ACCESS_PREDICATES VARCHAR2(4000) FILTER_PREDICATES VARCHAR2(4000) PROJECTION VARCHAR2(4000) TIME NUMBER QBLOCK_NAME VARCHAR2(31) REMARKS VARCHAR2(4000) TIMESTAMP DATE OTHER_XML CLOB
例えば select object_owner,object_name,object# from DBA_HIST_SQL_PLAN where sql_id=’avwjc02vb10j4′
OBJECT_OWNER OBJECT_NAME OBJECT# ——————– —————————————- ———-
PARNASSUSDATA TORDERDETAIL_HIS 78688
Select * from (select object_name,object# from DBA_HIST_SQL_PLAN UNION select object_name,object# from GV$SQL_PLAN) V1 where V1.OBJECT# IS NOT NULL minus select name,obj# from sys.obj$;
select obj#,dataobj#, object_name from WRH$_SEG_STAT_OBJ where object_name not in (select name from sys.obJ$) order by object_name desc;
もう一つの例 SELECT tab1.SQL_ID, current_obj#, tab2.sql_text FROM DBA_HIST_ACTIVE_SESS_HISTORY tab1, dba_hist_sqltext tab2 WHERE tab1.current_obj# NOT IN (SELECT obj# FROM sys.obj$ ) AND current_obj#!=-1 AND tab1.sql_id =tab2.sql_id(+);
|
以上はユーザーがどうしてもリカバリしたいデータテーブルについて、なんの情報も得られない場合にしか使えない。（つまり、このアプリモードについてのひともスクリプトもテキストもない場合）、それにAWRデータに頼っていて、正確性には少し問題がある。
Ｄ社のアプリ開發者がASMの環境で、なんのバックアップもないのに、システムの肝心なアプリテーブルをDROPした。そのときに、ＰＲＭですぐに大部分のデータをリカバリできる。10gのあと、recyclebinゴミ箱を追加した。まずはDBA_RECYCLEBINSビューを確認して、DROPしたテーブルがそこにあるか否かをたしかめる。もしそこにもなかったら、ＰＲＭでリカバリしてください。
リカバリの流れは以下の通り：
まずはDROPされたデータテーブルを含むテーブルスペースを見つけ出す。
ディクショナリーをけんさくして、あるいはLOGMINERでDROPされたデータテーブルのDATA_OBJECT_IDを見つけ出す。DATA_OBJECT_IDを得られない場合にはNON-DICTモードでＰＲＭを起動する。DROPされたデータテーブルを含むテーブルスペースにすべてのフィルタを追加したら、SCAN DATABASE+SCAN TABLE from Extent MAP。
DATA_OBJECT_IDによって、データテーブルを見つけて、DataBridgeモードでもとのデータベースに伝送する。
| SQL> select count(*) from “MACLEAN”.”TORDERDETAIL_HIS”;
COUNT(*) ———- 984359
SQL> SQL> create table maclean.TORDERDETAIL_HIS1 as select * from maclean.TORDERDETAIL_HIS;
Table created.
SQL> drop table maclean.TORDERDETAIL_HIS;
Table dropped. |
Logminerに通って、あるいはリカバリシーン9の方法で大抵なDATA_OBJECT_IDを得られる、LOGMINERを利用するスクリプトは以下の通り：
| 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 * FROM V$LOGMNR_CONTENTS ;
EXECUTE DBMS_LOGMNR.END_LOGMNR; |
たとえここでDATA_OBJECT_ID得られなくとも、データテーブルが多くない場合に人工的にリカバリしたいデータテーブルを見つけ出すことができる。
まずはDROPされたデータテーブルを含むテーブルスペースをOFFLINEする。
| SQL> select tablespace_name from dba_segments where segment_name=’TPAYMENT’;
TABLESPACE_NAME —————————— USERS
SQL> select file_name from dba_data_files where tablespace_name=’USERS’;
FILE_NAME —————————————————————- +DATA1/parnassus/datafile/users.263.843694795
SQL> alter tablespace users offline;
Tablespace altered. |
ＰＲＭを起動して、NON-DICTモードに入って、該当するデータフィルタを追加し、SCAN DATABASE+SCAN TABLE From Extentsを選んでください。
ASM DiskgroupにあるすべてのASM Disks追加したら、ASM analyzeをクリックしてください。
非ディクショナリーモードなので、必要な文字セットを入力してください。
DROPされたデータテーブルを含むテーブルフィルタをクリックすればいい、ほかのフィルタはどうでもいい。そしてSCANをクリックする。
生成したデータベースの名前をクリックし、右ボタンでscan tables from extentsを選んでください。
人工的にDATA_OBJECT_ID=82641のデータはDROPされたTORDERDETAIL_HISテーブルに該当し、DataBridge技術でモートのリポジトリに伝送する。
データベースの文字セットが分からなかったらどうすればいい？
Oracleアラームロゴalert.logを確認することによって、データベースの文字セットが確認できる。例えば：
| [oracle@mlab2 trace]$ grep -i character alert_Parnassus.log
Database Characterset is US7ASCII Database Characterset is US7ASCII alter database character set INTERNAL_CONVERT AL32UTF8 Updating character set in controlfile to AL32UTF8 Synchronizing connection with database character set information Refreshing type attributes with new character set information Completed: alter database character set INTERNAL_CONVERT AL32UTF8 alter database national character set INTERNAL_CONVERT UTF8 Completed: alter database national character set INTERNAL_CONVERT UTF8 Database Characterset is AL32UTF8 Database Characterset is AL32UTF8 Database Characterset is AL32UTF8 |
なぜＰＲＭいつもシャットダウンするあるいはgc warning: うおeated allocation of very large block (appr.size 512000)”などのエラになるでしょう？
それは恐らく推薦していないJAVA環境を使ったせいと思う。とくに、Linuxプラッドフォームでredhat gcj javaを運用したら、よくこのようになる。ParnassusDataはJDK1.6以上の環境でＰＲＭを運用することを勧めている。$JAVA_HOME/bin/java –jar prm.jarによって、ＰＲＭを起動できる。
JDK 1.6のダウンロードリンクは以下の通り：
ＰＲＭのbugを見つけ出したら、どうやってParnassusDataにreport bugすればいいでしょう？
ParnassusDataはあらゆるのreport bugを歓迎する。report_bugs@parnassusdata.comにメールすればいい。メールにbugが出た運用環境、オペレーションシステム、Java運用環境とORACLEデータベースバーション情報を一緒に送信してください。
ＲＰＭを起動するときにこのようなエラになったら、どうすればいいでしょう？
Error: no `server’ JVM at `D:\Program Files (x86)\Java\jre1.5.0_22\bin\server\jvm.dll’.
これはユーザーがJAVA Runtime Environment JREをインストールしているが、JDKをインストールしていないからである。ＰＲＭの起動スクリプトに-severオプションが追加したから、このオプションはJRE 1.5前のバーションにないので、エラになる。
ParnassusDataはJDK1.6以上の環境でＰＲＭを運用することを勧めている。
JDK 1.6のダウンロードリンクは以下の通り
なぜＰＲＭを使うとき、漢字が文字化けになるでしょう？
今我々知っている文字化けに導く原因は以下のふたつがある：
オペレーションシステムに中国語言語パックをインストールしていないので、まともに漢字を映せない。
言語バックをインストールしたが、JAVAの運用環境はJDK 1.4なので、文字化けが出る可能性がある、JDK 1.6以上のバーションを使ってください。
ＰＲＭはLOBラージオブジェクトフィールドを支持していないでしょうか？
いまＰＲＭはCLOB、NCLOB、BLOBなどのLOBラージオブジェクトフィールドを支持している。Disable/Enable Storage in ROWなどの場合はLOBへデータバイパスモードも支持している。
LOBラージオブジェクトフィールドには通常のUNLOAD抽出を支持していない。この抽出方法を使ったら、データを導入する場合にものすごくめんどくさいなので、DataBridgeデータバイパスモードを使ってください。
Ｄ会社の業務メンテナンス技術者は製品データベースをテスト環境として、あるテーブルの全てのデータをTRUNCATEした。DBAはリカバリーしてみたが、最新なバックアップが使えなくなったことに気づき、バックアップから該当するテーブルの記録をエクスポートできなかった。そのとき、DBAはPRMを採用し、TRUNCATEしたデータをリカバリーすることにした。
その環境で、全てのデータベースファイルは使用可能で健全のため、ユーザーはディクショナリーモードでシステムテーブルスペースのファイルとTRUNCATEDされたテーブルのファイルををロードするだけでOKです。
|
create table ParnassusData.torderdetail_his1 tablespace users as select * from parnassusdata.torderdetail_his;
|
ＰＲＭを起動し、Tools => Recovery Wizardを選択する。
Nextをクリックする。
このTRUNCATEシーンではASMストレージを選んでいないため、ディクショナリーモード（Dictionary Mode）だけを選んでいればいい。
次のステップで、いくつのバラメタを選択する必要がある：EndianエンディアンとDB NAME
Oracleファイルはオペレーションシステム（OS）によって、違ったEndianエンディアン形式を採用し、エンディアンと該当するプラットフォームが以下ご覧のとおり：
| Solaris[tm] OE (32-bit) | Big |
| Solaris[tm] OE (64-bit) | Big |
| Microsoft Windows IA (32-bit) | Little |
| Linux IA (32-bit) | Little |
| AIX-Based Systems (64-bit) | Big |
| HP-UX (64-bit) | Big |
| HP Tru64 UNIX | Little |
| HP-UX IA (64-bit) | Big |
| Linux IA (64-bit) | Little |
| HP Open VMS | Little |
| Microsoft Windows IA (64-bit) | Little |
| IBM zSeries Based Linux | Big |
| Linux x86 64-bit | Little |
| Apple Mac OS | Big |
| Microsoft Windows x86 64-bit | Little |
| Solaris Operating System (x86) | Little |
| IBM Power Based Linux | Big |
| HP IA Open VMS | Little |
| Solaris Operating System (x86-64) | Little |
| Apple Mac OS (x86-64) | Little |
例えば、伝統的なUnix AIX-Based Systems (64-bit) 、HP-UX (64-bit)ではBig Endianをつかっている、ここではBig Endianに変更する：
さもないと、Linux x86-64 、WindowsではデフォルトのLittle Endianままになる。
注意事項：もし、ファイルがもともとはAIX(つまりBig Endian)に生成するなら、都合のいいため、これらのファイルをWindowsサーバへコーピーし、ＰＲＭによってデータをリカバリーするなら、元のBig Endian形式に選ぶ必要がある。
ここでは、例のファイルがLinux x86にあるため、EndianをLittleに変更し、Database name入力する。（ここに入力したデータベース名は名前だけで、データベースホントのDBNAMEにいみしていない、PRMlのLicense検出メカニズムがつかっているのはここに入力したDatabase Nameじゃなく、ホントのDBNAMEをつかっているから）：
Nextをクリックする。
Choose Filesをクリックして、一般的には、データベースが大きくなければ、データベースにある全てのファイルを選定する必要がある。データベースが大きで、そしてデータテーブルがどこのフィイルにあるかをしっていれば、SYSTEMテーブルスペースのフィイルとデータテーブル（必要）を含むフィイルしかえらべない。
注意：ChooseインターフェースではCtrl + A とShiftなどキーボード操作を支持している。
後で、特定のファイルのBlock Sizeを指定する。つまり、Oracleデータブロックの大きさをしていする必要がある。ここは実際に応じて変更すればいい。例えば、DB_BLOCK_SIZEは8Ｋだが、一部のデータブロックテーブルスペース指定が16Ｋから、テーブルスペースが8ＫじゃないデータブロックのBLOCK_SIZEを変更すればいい。
ここのOFFSETバラメタは主にRAWデバイスにファイルを格納するときにたいおうするためのバラメタです。
もし、RAWデバイスフィイルをつかっているときにOFFSETをわからなければ、$ORACLE_HOME/binのdbfsizeツールを使って確認すればいい。したのきいろの部分が示したように、ここのRAWデバイスは4ＫのOFFSETをもっている。
| $dbfsize /dev/lv_control_01
Database file: /dev/lv_control_01 Database file type: raw device without 4K starting offset Database file size: 334 16384 byte blocks |
このシーンで全てのファイルは8KのBLOCK SIZE、そしてファイルシステムはOFFSETがないので、Loadをクリックする。
Loadステップに、ＰＲＭはSYSTEMテーブルスペースでOracleデータディクショナリー情報を読み取り、自らのDerbyでデータディクショナリー新規することによって、ＰＲＭがOracleデータベースにあるさまざまなデータを操作できる。
Load完成したあと、バックグラウンドでデータベース・キャラクタ・セットと各国語キャラクタ・セットをエクスポートする。
ＰＲＭは多国言語およびOracleデータベースマルチキャラクタセットを支持しているが、ＰＲＭでデータをリカバリーしたいオペレーションシステムを事前に該当するLanguage Packsをインストールしないといけない。たとえば、Windowsオペレーションシステムでは中国語Language Packsをインストールしていないが、ORACLEデータベース・キャラクタ・セットがオペレーションシステムから独立しているから、このシーンでつかっているORACLEデータベース・キャラクタ・セットがZHS16GBKキャラクタ・セットで、オペレーションシステムは中国語を支持していないですが、このシーンでサーバに配置していないOracleクライアントは影響をうけず、正確にデータをしめすことができる。
でも、ＰＲＭをつかうにはＰＲＭでデータをリカバリーしたいオペレーションシステムが事前に該当するLanguage Packsをインストールする必要がある。例えば、ユーザーがZHS16GBKの中国語キャラクタ・セットデータベースをリカバリーしたいとき、オペレーションシステムが中国語Language Packsをインストールした必要がある。
Linuxにもfonts-chinese中国語フォントパッケージをインストールする必要がある。
Load完成したあと、PRMインターフェースの左側にはデータベースユーザーPacketによる樹形図が現れる。
USERSをクリックし、いろんなユーザー名がでる。例えば、ユーザーがPARNASSUSDATA SCHEMAの下のテーブルをリカバリーしたいが、PARNASSUSDATAをクリックして、テーブルをダブルクリックする。
該当するTORDERDETAIL_HIS表がその前にTRUNCATEDされたから、ダブルクリックしてもデータを示せない。そのとき、テーブルにマウスの右ボタンでUnload truncated dataをクリックする。
ＰＲＭはそのテーブルを含むテーブルスペースをスキャンして、truncatedされたデータを抽出できる。
上のグラフのように、TRUNCATEされたTORDERDETAIL_HISテーブルからすべての984359の記録、指定されたパスに格納する。
| $ cd /home/oracle/prm/prmdata/parnassus_dbinfo_PARNASSUSDATA/
$ ls -l ParnassusData* -rw-r–r– 1 oracle oinstall 495 Jan 18 08:31 ParnassusData.torderdetail_his.ctl -rw-r–r– 1 oracle oinstall 191164826 Jan 18 08:32 ParnassusData.torderdetail_his.dat.truncated
$ cat ParnassusData.torderdetail_his.ctl LOAD DATA INFILE ‘ParnassusData.torderdetail_his.dat.truncated’ APPEND INTO TABLE ParnassusData.torderdetail_his FIELDS TERMINATED BY ‘ ‘ OPTIONALLY ENCLOSED BY ‘”‘ TRAILING NULLCOLS ( “SEQ_ID” , “SI_STATUS” , “D_CREATEDATE” , “D_UPDATEDATE” , “B_ISDELETE” , “N_SHOPID” , “N_ORDERID” , “C_ORDERCODE” , “N_MEMBERID” , “N_SKUID” , “C_PROMOTION” , “N_AMOUNT” , “N_UNITPRICE” , “N_UNITSELLINGPRICE” , “N_QTY” , “N_QTYFREE” , “N_POINTSGET” , “N_OPERATOR” , “C_TIMESTAMP” , “H_SEQID” , “N_RETQTY” , “N_QTYPOS” )
|
データをソーステーブルにロードする（注意：元の環境を上書きされないように、SQLLDRコントロールフィルタを変更するときに、一時的なテーブルをロードしてください。
| $ sqlldr control=ParnassusData.torderdetail_his.ctl direct=y
Username:/ as sysdba 以上はsqlldrでリカバリできたデータの実例です。
Minusによって、リカバリしたデータを比べることもできる select * from ParnassusData.torderdetail_his minus select * from parnassus.torderdetail_his;
no rows selected
|
テスト中、TRUNCATEと元のテーブルと比べて、記録が完全に同様に見える。
それは、ＰＲＭはTRUNCATEテーブルの記録をリカバリできたから。
シーン１では、通常のunload+sqlldr方法を採用したが、実際使用中、私たちはかなり工夫して設計できたDataBridgeデータバイパスモードを勧めます。
なぜデータバイパスモードを使う必要があるでしょう？
通常のunload+sqlldr方法はソースデータ、抽出するデータ、および目標のデータを格納するスペースが必要、つまり、もとの空間の二倍を要求する。バックアップのスペースさえ用意できない企業に対して、これはかなり厳しい要求だと思います。
データバイパスとunload+sqlldrモードの一番大きな違いはデータバイパスはソースリポジトリからデータを抽出し、目標データベースへ転移して、もとのフィルタシステムに抽出データを格納する必要はない。
データバイパスによって、目標データベースに転移されたデータは元々構造化されたから、ＳＱＬで一貫性と整合性をかくにんできる。
データバイパスの目標データベースは異なるマシンにある場合は、ソースデータベースに対して、読み取りしかできない、読み書きIOは二つのマシンに配置し、ＰＲＭリカバリスビートがよく速くなる。
ユーザーリカバリしたいのはTruncateデータの場合に、バイパスによってすぐにソースデータベースに戻れる、リカバリ作業はマウスをクリックするだけですませる。
データバイパスモードを使うには、通常モードと同じ、左側の樹形図に必要なテーブルを選んで、右ボタンでDataBridgeオプションをクリックする。
初めてデータバイパスモードを使うときに、まずは目標データベースとつながる情報を入力する必要がある。これはSQLDEVELOPERにConnectionを構造する作業に似ている。これは目標データベースのホスト、ポート、Service_Nameおよびユーザー登録情報も含んでいる。ここに入力したユーザー情報は、後でデータバイパスを使う目標データベースのユーザーのことだから、つまり、ソースリポジトリから抽出したテーブルは指定された目標データベースユーザーへ転移する。
このように、G10R25というリンクを構造した、ユーザーはmaclean、該当するoracle Easy Connection接続文字列は192.168.1.191:1521/G10R25。
以上のようなデータベース情報入力を完成したら、Testボタンをクリックして、リンクオプションが使えるか否かを確認できる。もし、“ Connect to db server successfully “が戻ってきたら、いまリンクが使えるということを意味する。そのままSaveをクリックして、セブすればいい。
セブできたら、DataBridgeインタフェースに入って、まずはDB Connectionドロップダウンリストに、先に追加したConnection G10R25を選択する：
DB Connectionドロップダウンリストに必要とするデータベースリンクが現れていないなら、DB connectionのそばにある「…」ブタンを押してDB Connection:を追加してください
DB Connectionを正確に選んでいたら、Tablespaceドロップダウンリストが使えるようになる、ふさわしいテーブルスペースを選んでください。
Data Bridgeを使って、truncateをリカバリするときに、以下のようなことを注意してください：ソースリポジトリからtruncateデータをリカバリするときに、databridgeオプションを使って、データをソースデータベースへ伝送する場合（ソースリポジトリじゃなければ問題ない）、Databridgeを新規テーブルにインサートするアドレスはソースデータベースにtruncateされたアドレスにしないでください。さもなければ、truncateされたデータをリカバリしながら、リカバリされたばかりのデータが上書きされることになる。こういう時に上書きされたデータがリカバリできないので、ご注意をください。databridge+を使ってデータをソースデータベースにリカバリするとき、およびdatabridgeにテーブルスペースを指定する場合、ぜひ、リカバリしたいテーブルスペースをつかわないでください。
ユーザーはソースリポジトリから目標リポジトリへ伝送するテーブルの名前のマッピングを変更するか否かを選択できる。例えば、ソースリポジトリであるテーブルがTruncateされた、いまはDataBridgeにより、データをソースリポジトリへリカバリするが、元の名前をつかいたくないで、ほかの名前で格納したいとき、“if need to remap table”を選んでふさわしい名前を入力すればいい：
1.目標リポジトリに該当するテーブルの名前がすでに存在している場合に、ＰＲＭはテーブルを再構造することじゃなく、既存するテーブルを元にリカバリしたいデータをインサートする。テーブルはもう構造したから、指定したテーブルスペースが無力化になる。
２.目標リポジトリに該当するテーブルの名前がまだ存在していない場合は、ＰＲＭが指定したテーブルスペースにテーブルを構造し、リカバリしたいデータをインサートしてみます。
このシーンで私たちがリカバリしたのはTruncateされたデータで、“if data truncated”を選択する必要がある。さもなければ、ＰＲＭは通常のモードでデータを抽出するから、Truncateされたデータが見えなくなる。
Truncateデータの原理は、OracleがデータディクショナリーとSegment HeaderにテーブルのData Object IDを更新するが、実際データに一部のブロックが更新されない。データディクショナリーとセグメントヘッダーのDATA_OBJECT_IDがあとのデータブロックにあるが一致していないため、Oracleサビースプロセスがテーブル全体のデータを読み取るときに、TRUNCATEされたが、まだ上書きされていないデータは読み取れない。
ＰＲＭは自動スキャンによって、データセグメントヘッダー（Segment Header）がTRUNCATEされた後のデータブロックはTRUNCATEされた前のDATA_OBJECT_IDを判断し、ディクショナリーにテーブルフィールドの定義と自動獲得したDATA_OBJECT_IDによって、データを抽出する。
そして、”if to specify data object id”というインプットボックスが存在している。これによって、ユーザーがリカバリしたいデータのData Object IDを指定できる。Truncateデータをうまくリカバリできなかったときに限って、ParnassusDataの技術サポートを元に、指定してください。それ以外、何の数値を指定する必要がない。
以上のように、DataBridge配置を正確に配置できたら、データバイパスを実行できる。DataBridgeボタンをクリックしてください：
データバイパスが完成したら、伝送できたデータ行数と経過時間を示される。
I just wanted to tell you that your blog is wonderful, and to thank you for all great responses on numerous questions. I wanted to ask you, can you send me a newest version of Oracle DUL software for linux. I am very interested in trying it in multitenant architecture. I downloaded one from your website, but when I try to execute it, it says that I need to have latest version for my os.
Oracle DUL is internal tool, can only used by Oracle Support. From DUL Version 10 , the compiled DUL will be expired every month , and have to download it again from beehive.oracle.com . I have no longer access to DUL, because I am now retired from oracle china.
We have made a commercial version DUL ,which called PRM-DUL, you can download it from http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip.
A System Administrator of company D who deleted SYSTEM tablespace by mistake and make DB can not be open. Unfortunately, there is no RMAN backup available. Therefore, for company D try to use PRM-DUL to recover all data.
In this circumstance, run PRM-DUL and go into Recovery Wizard. Select “Non-Dictionary mode”:
In No-dictionary mode, we have to select DB Character Set and DB National Character Set. Because of while losing SYSTEM tablespace, database cannot find character set information.
Similarly as case 1, select all data (not including temp file), and correct Block Size and OFFSET
Then click scan button. Then PRM-DUL will scan all segment header and extents in datafile, and record it into SEG$.DAT and EXT$.DAT. In Oracle, each partition table or non-partition table has a segment header. Once we find segment header, we could find the whole table extent map information. Via extent map, we can get all record.
There is one exception, for example, there is one non-partition table that is stored in two database files. The segment header and half data are stored in datafile A, and the others are on datafile B. While system tablespace and datafile A are lost, PRM-DUL couldn’t find segment header associated with problem table, but it can scan datafile B and get the rest extent map.
In order to recover data via segment header and extent map in no-dictionary mode.
PRM-DUL will create two files: SEG$.DAT(stores segment header info) and EXT$.DAT(stores extent info) ,which is also recorded in PRM-DUL embedded database.
After scan, there is database icon on the left.
Meanwhile, there are 2 option:
It is not necessary to use mode “Scan Tables From Extents” at the first time, unless you can’t find your data by “Scan Tables From Segment”.
Scan tables From segments should be your first choice.
After scanning tables from segments, there will be a tree diagram on the left.
Scan Tables is for constructing the data based on segment header in SEG$. The name of each node in the diagram is named by obj+ DATA OBJECT ID.
Click on node and check right side:
Intelligence on Data Analysis
Because of SYSTEM tablespace lost, there is not data structure information available in NO-Dictionary mode. The column information includes column name and data type. All these are storage in dictionary but not in table. Therefore, PRM-DUL need to guess the data type. PRM-DUL has a JAVA pre analysis algorithm, and has the ability to analysis more than 10 kinds of types.、
Intelligence analysis can successfully guess 90% of columns in most of circumstances
On the right side, the meaning of columns:
Sample Data Analysis:
Intelligence Analysis will analyze 10 records and display the results. These results will help client to know the column information.
As in the picture, the there are 10 records which had been displayed all.
TRY TO ANALYZE UNKNOWN column type:
If PRM-DUL cannot recognize the column’s data type , you can specify data type by yourself.
So far, PRM-DUL does not support below types:
XDB.XDB$RAW_LIST_T、XMLTYPE、Customized TYPE
Unload Statement:
PRM-DUL generated unload scripts, and these scripts can be only used by PRM-DUL support engineers.
In “Non-Dictionary Mode”, Data Bridge is also applicable. Comparing ” Dictionary Mode”, the manger difference that the user can define the type in data transferring. As below picture, the column type is UNKNOW. These types might be PRM-DUL unsupported types for example: XML and etc.
If the user know the data type in this table (from schema design documents), it is necessary to specify the correct types manually.
User D deleted the system tablespace and part of user tablespace datafile by mistake.
In this circumstance, part of user data table was deleted, and this might includes datafile which stored segment header. Therefore it is better to use “Scan Tables From Extents” than” Scan Tables From Segment Header”.
Steps as Below:
User D chooses ASM instead of other filesystem. Since there are many bugs in version 11.2.0.1, it may happen that ASM DISKGROUP cannot be mounted or it does not work after repairing ASM Disk Header.
In this circumstance, user can use ASM Files Clone feature of PRM-DUL to rescue datafile from damaged ASM DiskGroup directly.
ASM Files Clone feature will analyze ASM Disk header, in order to finding Disk group file and File Extent Map. All the information is recorded into PRM-DUL embedded database. PRM-DUL can collect all Metadata, and analyze to show diagram.
Click ASM Clone to start…
There is progress bar while file cloning.
ASM File Clone log as below:
| Preparing selected files…Cloning +DATA2/ASMDB1/DATAFILE/TBS2.256.839732369:……………………..1024MB………………………………..2048MB………………………………..3072MB………………………………….4096MB
………………………………..5120MB ………………………………….6144MB ……………………………….7168MB …………………………………8192MB …………………………………9216MB …………………………………10240MB …………………………………11264MB …………………………………..12288MB …………………………………….13312MB …………………………….14336MB ……………………………………..15360MB ……………………………….16384MB …………………………………17408MB …………………………………18432MB …………………………………………………………………………………………….19456MB …………………………………… Cloned size for this file (in byte): 21475885056
Cloned successfully!
Cloning +DATA2/ASMDB1/ARCHIVELOG/2014_02_17/thread_1_seq_47.257.839732751: …… Cloned size for this file (in byte): 29360128
Cloned successfully!
Cloning +DATA2/ASMDB1/ARCHIVELOG/2014_02_17/thread_1_seq_48.258.839732751: …… Cloned size for this file (in byte): 1048576
Cloned successfully!
All selected files were cloned done. |
| rman target /RMAN> catalog datafilecopy ‘/home/oracle/asm_clone/TBS2.256.839732369.dbf’;cataloged datafile copydatafile copy file name=/home/oracle/asm_clone/TBS2.256.839732369.dbf RECID=2 STAMP=839750901
RMAN> validate datafilecopy ‘/home/oracle/asm_clone/TBS2.256.839732369.dbf’;
Starting validate at 17-FEB-14 using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: including datafile copy of datafile 00016 in backup set input file name=/home/oracle/asm_clone/TBS2.256.839732369.dbf channel ORA_DISK_1: validation complete, elapsed time: 00:03:35 List of Datafile Copies ======================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN —- —— ————– ———— ————— ———- 16 OK 0 2621313 2621440 1945051 File Name: /home/oracle/asm_clone/TBS2.256.839732369.dbf Block Type Blocks Failing Blocks Processed ———- ————– —————- Data 0 0 Index 0 0 Other 0 127
Finished validate at 17-FEB-14
|
When using PRM-DUL in ASM of ASMLIB?
Simple and Clear: asmlib related ASM DISK is stored in OS as ll /dev/oracleasm/disks. For example: Add files of /dev/oracleasm/disks into PRM-DUL ASM DISK
| $ll /dev/oracleasm/diskstotal 0brw-rw—- 1 oracle dba 8, 97 Apr 28 15:20 VOL001brw-rw—- 1 oracle dba 8, 81 Apr 28 15:20 VOL002brw-rw—- 1 oracle dba 8, 65 Apr 28 15:20 VOL003brw-rw—- 1 oracle dba 8, 49 Apr 28 15:20 VOL004brw-rw—- 1 oracle dba 8, 33 Apr 28 15:20 VOL005
brw-rw—- 1 oracle dba 8, 17 Apr 28 15:20 VOL006 brw-rw—- 1 oracle dba 8, 129 Apr 28 15:20 VOL007 brw-rw—- 1 oracle dba 8, 113 Apr 28 15:20 VOL008 |
DBA of company D deleted SYS.TS$ (A bootstrap Table) by mistake, this cause Oracle DB can not be open
| Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit ProductionWith the Partitioning, Automatic Storage Management, OLAP, Data Miningand Real Application Testing optionsINSTANCE_NAME
—————- ASMME
SQL> SQL> SQL> select count(*) from sys.ts$;
COUNT(*) ———- 5
SQL> delete ts$;
5 rows deleted.
SQL> commit;
Commit complete.
SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down.
Database mounted. ORA-01092: ORACLE instance terminated. Disconnection forced ORA-01405: fetched column value is NULL Process ID: 5270 Session ID: 10 Serial number: 3
Undo initialization errored: err:1405 serial:0 start:3126020954 end:3126020954 diff:0 (0 seconds) Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc: ORA-01405: fetched column value is NULL Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc: ORA-01405: fetched column value is NULL Error 1405 happened during db open, shutting down database USER (ospid: 5270): terminating the instance due to error 1405 Instance terminated by USER, pid = 5270 ORA-1092 signalled during: ALTER DATABASE OPEN… opiodr aborting process unknown ospid (5270) as a result of ORA-1092
|
In this circumstance, data dictionary had been damaged; therefore it would be very hard to open the database.
Then, we can use PRM-DUL rescue data in DB. Following processes as below:
