PRM DUL ORACLE 誤削除とSYSTEMテーブルスペースがなくした

Ｄ社のＳ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を完成したら、インタフェースの左側にデータベースアイコンが現れる。

この時、二つのバッタンを選べる。：

1. Scan Tables From Segments、このバッタンは：

システムテーブルスペースをなくしたが、すべての応用データテーブルスペースが存在している場合に適応している。

2. Scan Tables From Extents

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％を超え、自動的に多くのシーンを解決できる。

右側のコラムのフィールドの意味：

• Col1 noフィールド番号
• Seen Count: 獲得した行数
• MAX SIZE:最大の長さ、単位はバイト
• PCT NULL: 獲得したNULLの比率
• String Nice: そのフィールドを文字列に解析し、そして成功した例
• Number Nice:そのフィールドを数字に解析し、そして成功した例
• Date Nice: そのフィールドをDateに解析し、そして成功した例
• Timestamp Nice: そのフィールドをTimestampに解析し、そして成功した例
• Timestamp with timezone Nice: そのフィールドをTimestamp with timezone Niceに解析し、そして成功した例

サンプルデータ分析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を使うほうがいい。

ステップは以下の通り：

1. Recovery Wizardに入って、No-Dictionaryモードを選んで、すべて使用可能なデータフィルタを追加し、Scan Databaseを実行する。

2.データベースを選んで、マウスの右ボタンでScan Tables From Extentsをクリックする

3.ＰＲＭインタフェースに生成した対象樹形図のデータを分析して、導出あるいはデータバイパスする。

4.そのほかの操作はシーン４と同じ。