Oracle専用データ復旧ソフトウェアprm dulユーザーズ・マニュアル

ParnassusData テクニカルホワイトペーパー
Nov 2015
ORACLE 専用データ復旧ソフトウェア
PRM-DUL ユーザーズ・マニュアル
Creation Date: Feb 09, 2014
Last Update: Nov 27, 2015
Version: <Version 0.3>

ParnassusData Recovery Manager For Oracle
Database
ParnassusData
www.parnassusdata.com 2
文書管理
Author
Maclean Liu
Change Logs
Date Author Version Change Log
Feb 09, 2014 Maclean Liu Created.
Apr 14,2014 Maclean Liu V0.2
Apr 25,2014 Maclean Liu Recovery From DROP TABLESPACE
Jun 11,2014 Maclean Liu DataBridge For LOB
Reviewers
Name Position
ZhangYang Hu
HanJue Xu
Approvals
<Approver 1> ZhangYang Hu
<Approver 2>
Distribution
Copy No. Name Location

Database
ParnassusData
目录
文書管理 ............................................................................................................................. 2
Author......................................................................................................................... 2
Change Logs............................................................................................................... 2
Reviewers ................................................................................................................... 2
Approvals.................................................................................................................... 2
Distribution................................................................................................................ 2
概述サマリー .................................................................................................................. 4
なぜＰＲＭを使う必要があるでしょう？ .......................................................................... 5
ＰＲＭソフト紹介............................................................................................................... 7
ＰＲＭのインストールと起動........................................................................................... 12
ＰＲＭのライセンス登録.................................................................................................. 16
異なる Oracle データベーストラブルのリカバリー実行例............................................. 20
リカバリーシーン１ミスでテーブルを Truncate した時の通常リカバリー........ 20
リカバリシーン２過ちで Truncate されたテーブをバイパスリカバリ............... 38
リカバリシーン３ Oracle データディクショナリーがダンメージを受け、データベ
ースが起動できない...................................................................................................... 47
リカバリシーン 4 誤削除と SYSTEM テーブルスペースがなくした。 ............... 50
誤操作でテーブルスペースと一部のアプリテーブルスペースデータフィルタを削除
した。............................................................................................................................ 61
リカバリシーン 6 壊された ASM Diskgroup からデータベースのデータを抽出す
る................................................................................................................................... 62
リカバリシーン 7 ASM の環境でデータベースが起動できない ........................... 71
リカバリシーン 8 ASM で SYSTEM テーブルスペースのリカバリを削除した（な
くした）........................................................................................................................ 75
リカバリシーン 9 誤操作で DROP TABLESPACE したデータをリカバリする . 78
リカバリシーン 10 誤操作で DROP したテーブルのリカバリ ............................. 90
FAQ よくある質問......................................................................................................... 100
Find More ...................................................................................................................... 103
Conclusion ..................................................................................................................... 103

Database
ParnassusData
概述サマリー
ParnassusData Recovery Manager（以下略してＰＲＭ）は企業レベルの Oracle データ
ディザスタリカバリーソフトで、Oracle データベースのインスタンスでＳＱＬを実行する
ことじゃなく、直接に Oracle9i,10g,11g,12c からデータベースのデータフィイルを抽出す
ることにより、目標データを救うソフトである。ParnassusData Recovery Manager は Java
に基づいて開発された安全性が高く、ダウンロードして解凍したあと、インストールするこ
となしにそのままで運用できて、とっても便利で使いやすいなソフトである。
ＰＲＭは GUI グラフィカルインターフェース（図１）を採用し、新たなプログラミング
言語をあらかじめ勉強する必要はなく、Oracle bottom-level structure of database 原理
さえわかっていれば、リカバリーウィザード(Recovery Wizard)を使うことによって、デー
タをリカバリーできる。
图片番号 1

Database
ParnassusData
なぜＰＲＭを使う必要があるでしょう？
お客様きっとまだこういう疑問を抱いているでしょう：「RMAN という応用歴史が長い
Oracle リカバリーマネジャーのバックアップによるリカバリーはまだ足りないというのか。
なぜわざわざ PRM を買う必要があるでしょう。」
ご存知の通りですが、今企業に発展し続けていく IT システムでは、データボリュムがま
さに日進月歩である。データの整合性を確保することは何より大事ですが、このデータが爆
発的に増加する時代のなか、今日の Oracle DBA たちは既存のディスクボリュムが不足で、
データ全体を格納できないやテープによるバックアップがリカバリーするときに要する時
間が予想した平均修復時間に超えていたなどさまざまな課題に直面している。
「データベースにとって、バックアップは一番大事である」ということわざはあらゆる
DBA のこころに刻んでいる。けど、現実の環境は千差万別で、筆者の経験では、企業デー
タベース環境でバックアップスペースが足りないとか、購入したストレージデバイスが短
期的に手に入ることができないとか、バックアップしていたが、実際にリカバリーしている
とき、使えなくなったとか、現場に起きることが実に予想できない。
現実によくあるリカバリートラブルに対応するため、PRM 诗檀データベースリカバリー
マネジャーソフトは開発された。PRM 诗檀データベースリカバリーマネジャーソフトは
ORACLE データベース内部データ構造理解したうえで、全くバックアップしていないとき
に SYSTEM テーブルスペースなくしたとか、ORACLE データディクショナリーテーブル
を誤操作したとか、電源がきれたことによりデータディクショナリー一貫性をなくし、デー
タベースを起動できないとか、さまざまな難題に対応できる。さらに、誤切断(Truncate)/削
除 (Delete)業務データテーブルなど、人為的な誤操作もリカバリーできる。
Oracle 専門家に限っていることじゃなく、わずか数日間しか Oracle データベースを接触
していなかった方にも自由自在に運用できる。このすべてはＰＲＭのインストールがとび
きりたやすいところとグラフィカル対話型インタフェースのおかげです。これにより、リカ
バリーを実行する技術者たちはデータベースに関する専門知識を要することじゃなく、あ
らためて新たなプログラミング言語を勉強する必要もない。データベースの基礎になる格
納構造についてはなおさらです。マウスをクルックするだけで、余裕をもってリカバリーで
きる。
伝統的なリカバリーツールである DUL にたいして、ＰＲＭは DUL がかなわない強みを

Database
ParnassusData
もっている。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 ディ

Database
ParnassusData
スクに使用可能なメタデータを読み取ることができる、さらにこれらのメタデータが 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 

Database
ParnassusData
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
今ＰＲＭを支持している言語

Database
ParnassusData
语言字符集对应的编码
中国語簡体字/繁体字 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
ドイツ語 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

Database
ParnassusData
アラビア語 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

Database
ParnassusData
注意事項：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

Database
ParnassusData
ＰＲＭが ASM に’対する支持
ファンクション支持しているか否か
ASM から直接にデータを抽出し、ファイ
ルにコーピーする必要がない
YES
ASM からデータをコーピーする YES
ASM metadata を修復する YES
ASM ブラックボックスをグラフィカル
に示す
Future
ＰＲＭのインストールと起動
ＰＲＭは Java に基づくソフトですから、インストールする必要がなく、ZIP パッケージ
をダウロドしてから解凍したままでデータをリカバリーに運用できる。
unzip prm_latest.zip
诗檀はコマンドラインでＰＲＭを起動することをすすめている。この操作によって、より
多くの診断情報を手に入れるから。
Windows プラットフォームでの起動法
1. まずはＪＤＫが正確にインストールしたことと Java が環境変数に追加したことを
確保する
2. ダブルクリックＰＲＭ解凍ディレクトリ下の prm.bat

Database
ParnassusData
そして、prm.bat がバックグラウンドでＰＲＭを起動する。
同時にＰＲＭグラフィカルメインインターフェイスを起動する

Database
ParnassusData
 Linux/Unix 環境での起動法
1. まずはＪＤＫが正確にインストールしたことと Java が環境変数に追加したこ
とを確保する
2. Ｃｄは PRM のディレクトリにある、そして./prm.sh 起動プログラムのメイン
インターフェイスを実行する。

Database
ParnassusData

Database
ParnassusData
ＰＲＭのライセンス登録
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 を入力する必要があって、支払いを完了してから、メールを受信する。そのメー

Database
ParnassusData
ルの内容は前に入力した DBNAME と該当する License Key です。
ユーザーが License Key を手に入ってから、ソフトで Register をとうろくする。具体的
使用法はこのとおり：
1. メニューバーHelp => Register
2. DB NAME と先受信した License Key を入力し、Register をクリックしてＯＫです
今後ＰＲＭを再起動する際に自動的に License 登録情報を検出し、一度登録したら、繰り
返し登録の必要はない。

Database
ParnassusData

Database
ParnassusData
異なる Oracle データベーストラブルのリカバリー実行例
リカバリーシーン１ミスでテーブルを
Truncate した時の通常リカバリー
Ｄ会社の業務メンテナンス技術者は製品データベースをテスト環境として、あるテーブ
ルの全てのデータを TRUNCATE した。DBA はリカバリーしてみたが、最新なバックアッ
プが使えなくなったことに気づき、バックアップから該当するテーブルの記録をエクスポ
ートできなかった。そのとき、DBA は PRM を採用し、TRUNCATE したデータをリカバ
リーすることにした。
その環境で、全てのデータベースファイルは使用可能で健全のため、ユーザーはディクシ
ョナリーモードでシステムテーブルスペースのファイルと TRUNCATED されたテーブル
のファイルををロードするだけで OK です。
create table ParnassusData.torderdetail_his1 tablespace users as
select * from parnassusdata.torderdetail_his;
SQL> desc ParnassusData.TORDERDETAIL_HIS
Name Null? Type
----------------------- -------- -----------
---
SEQ_ID NOT NULL NUMBER(10)
SI_STATUS NUMBER(38)
D_CREATEDATE CHAR(20)
D_UPDATEDATE CHAR(20)
B_ISDELETE CHAR(1)
N_SHOPID NUMBER(10)
N_ORDERID NUMBER(10)

Database
ParnassusData
C_ORDERCODE CHAR(20)
N_MEMBERID NUMBER(10)
N_SKUID NUMBER(10)
C_PROMOTION NVARCHAR2(5)
N_AMOUNT NUMBER(7,2)
N_UNITPRICE NUMBER(7,2)
N_UNITSELLINGPRICE NUMBER(7,2)
N_QTY NUMBER(7,2)
N_QTYFREE NUMBER(7,2)
N_POINTSGET NUMBER(7,2)
N_OPERATOR NUMBER(10)
C_TIMESTAMP VARCHAR2(20)
H_SEQID NUMBER(10)
N_RETQTY NUMBER(7,2)
N_QTYPOS NUMBER(7,2)
select count(*) from
ParnassusData.TORDERDETAIL_HIS;
COUNT(*)
----------
984359
select bytes/1024/1024 from dba_segments
where segment_name='TORDERDETAIL_HIS' and
owner='PARNASSUSDATA';
BYTES/1024/1024
---------------
189.71875
SQL> truncate table

Database
ParnassusData
Table truncated.
SQL> select count(*) from
COUNT(*)
----------
0
ＰＲＭを起動し、Tools => Recovery Wizard を選択する。

Database
ParnassusData
Next をクリックする。
この TRUNCATE シーンでは ASM ストレージを選んでいないため、ディクショナリー
モード（Dictionary Mode）だけを選んでいればいい。

Database
ParnassusData
次のステップで、いくつのバラメタを選択する必要がある：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

Database
ParnassusData
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 ままになる。

Database
ParnassusData
注意事項：もし、ファイルがもともとは AIX(つまり Big Endian)に生成するなら、都合
のいいため、これらのファイルを Windows サーバへコーピーし、ＰＲＭによってデータを
リカバリーするなら、元の Big Endian 形式に選ぶ必要がある。
ここでは、例のファイルが Linux x86 にあるため、Endian を Little に変更し、Database
name 入力する。（ここに入力したデータベース名は名前だけで、データベースホントの
DBNAME にいみしていない、PRMl の License 検出メカニズムがつかっているのはここに
入力した Database Name じゃなく、ホントの DBNAME をつかっているから）：

Database
ParnassusData
Next をクリックする。
Choose Files をクリックして、一般的には、データベースが大きくなければ、データベ
ースにある全てのファイルを選定する必要がある。データベースが大きで、そしてデータテ
ーブルがどこのフィイルにあるかをしっていれば、SYSTEM テーブルスペースのフィイル
とデータテーブル（必要）を含むフィイルしかえらべない。
注意：Choose インターフェースでは Ctrl + A と Shift などキーボード操作を支持して
いる。

Database
ParnassusData

Database
ParnassusData
後で、特定のファイルの 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 をクリックする。

Database
ParnassusData
Load ステップに、ＰＲＭは SYSTEM テーブルスペースで Oracle データディクショナ
リー情報を読み取り、自らの Derby でデータディクショナリー新規することによって、Ｐ
ＲＭが Oracle データベースにあるさまざまなデータを操作できる。

Database
ParnassusData
Load 完成したあと、バックグラウンドでデータベース・キャラクタ・セットと各国語キ
ャラクタ・セットをエクスポートする。

Database
ParnassusData
ＰＲＭは多国言語および Oracle データベースマルチキャラクタセットを支持している
が、ＰＲＭでデータをリカバリーしたいオペレーションシステムを事前に該当する
Language Packs をインストールしないといけない。たとえば、Windows オペレーション
システムでは中国語 Language Packs をインストールしていないが、ORACLE データベー
ス・キャラクタ・セットがオペレーションシステムから独立しているから、このシーンでつ
かっている ORACLE データベース・キャラクタ・セットが ZHS16GBK キャラクタ・セッ
トで、オペレーションシステムは中国語を支持していないですが、このシーンでサーバに配
置していない Oracle クライアントは影響をうけず、正確にデータをしめすことができる。
でも、ＰＲＭをつかうにはＰＲＭでデータをリカバリーしたいオペレーションシステム
が事前に該当する Language Packs をインストールする必要がある。例えば、ユーザーが
ZHS16GBK の中国語キャラクタ・セットデータベースをリカバリーしたいとき、オペレー
ションシステムが中国語 Language Packs をインストールした必要がある。
Linux にも fonts-chinese 中国語フォントパッケージをインストールする必要がある。
Load 完成したあと、PRM インターフェースの左側にはデータベースユーザーPacket に
よる樹形図が現れる。

Database
ParnassusData
USERS をクリックし、いろんなユーザー名がでる。例えば、ユーザーが
PARNASSUSDATA SCHEMA の下のテーブルをリカバリーしたいが、
PARNASSUSDATA をクリックして、テーブルをダブルクリックする。
該当する TORDERDETAIL_HIS 表がその前に TRUNCATED されたから、ダブルクリ
ックしてもデータを示せない。そのとき、テーブルにマウスの右ボタンで Unload truncated
data をクリックする。

Database
ParnassusData
ＰＲＭはそのテーブルを含むテーブルスペースをスキャンして、truncated されたデータ
を抽出できる。

Database
ParnassusData

Database
ParnassusData
上のグラフのように、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

Database
ParnassusData
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 でリカバリできたデータの実例です。

Database
ParnassusData
Minus によって、リカバリしたデータを比べることもできる
select * from ParnassusData.torderdetail_his minus select * from parnassus.torderdetail_his;
no rows selected
テスト中、TRUNCATE と元のテーブルと比べて、記録が完全に同様に見える。
それは、ＰＲＭは TRUNCATE テーブルの記録をリカバリできたから。
リカバリシーン２過ちで Truncate された
テーブをバイパスリカバリ
シーン１では、通常の unload+sqlldr 方法を採用したが、実際使用中、私たちはかなり工
夫して設計できた DataBridge データバイパスモードを勧めます。
なぜデータバイパスモードを使う必要があるでしょう？
通常の unload+sqlldr 方法はソースデータ、抽出するデータ、および目標のデータを格納

Database
ParnassusData
するスペースが必要、つまり、もとの空間の二倍を要求する。バックアップのスペースさえ
用意できない企業に対して、これはかなり厳しい要求だと思います。
データバイパスと unload+sqlldr モードの一番大きな違いはデータバイパスはソースリ
ポジトリからデータを抽出し、目標データベースへ転移して、もとのフィルタシステムに抽
出データを格納する必要はない。
データバイパスによって、目標データベースに転移されたデータは元々構造化されたか
ら、ＳＱＬで一貫性と整合性をかくにんできる。
データバイパスの目標データベースは異なるマシンにある場合は、ソースデータベース
に対して、読み取りしかできない、読み書き IO は二つのマシンに配置し、ＰＲＭリカバリ
スビートがよく速くなる。
ユーザーリカバリしたいのは Truncate データの場合に、バイパスによってすぐにソース
データベースに戻れる、リカバリ作業はマウスをクリックするだけですませる。
データバイパスモードを使うには、通常モードと同じ、左側の樹形図に必要なテーブルを
選んで、右ボタンで DataBridge オプションをクリックする。

Database
ParnassusData
初めてデータバイパスモードを使うときに、まずは目標データベースとつながる情報を
入力する必要がある。これは SQLDEVELOPER に Connection を構造する作業に似てい
る。これは目標データベースのホスト、ポート、Service_Name およびユーザー登録情報も
含んでいる。ここに入力したユーザー情報は、後でデータバイパスを使う目標データベース
のユーザーのことだから、つまり、ソースリポジトリから抽出したテーブルは指定された目
標データベースユーザーへ転移する。

Database
ParnassusData
このように、G10R25 というリンクを構造した、ユーザーは maclean、該当する oracle
Easy Connection 接続文字列は 192.168.1.191:1521/G10R25。
以上のようなデータベース情報入力を完成したら、Test ボタンをクリックして、リンク
オプションが使えるか否かを確認できる。もし、“ Connect to db server successfully “が戻
ってきたら、いまリンクが使えるということを意味する。そのまま Save をクリックして、
セブすればいい。

Database
ParnassusData
セブできたら、DataBridge インタフェースに入って、まずは DB Connection ドロップ
ダウンリストに、先に追加した Connection G10R25 を選択する：
DB Connection ドロップダウンリストに必要とするデータベースリンクが現れていない
なら、DB connection のそばにある「…」ブタンを押して DB Connection:を追加してくだ
さい

Database
ParnassusData
DB Connection を正確に選んでいたら、Tablespace ドロップダウンリストが使えるよう
になる、ふさわしいテーブルスペースを選んでください。

Database
ParnassusData
Data Bridge を使って、truncate をリカバリするときに、以下のよう
なことを注意してください：ソースリポジトリから truncate データをリ
カバリするときに、databridge オプションを使って、データをソースデ
ータベースへ伝送する場合（ソースリポジトリじゃなければ問題ない）、
Databridge を新規テーブルにインサートするアドレスはソースデータベ
ースに truncate されたアドレスにしないでください。さもなければ、
truncate されたデータをリカバリしながら、リカバリされたばかりのデ
ータが上書きされることになる。こういう時に上書きされたデータがリ
カバリできないので、ご注意をください。databridge+を使ってデータを
ソースデータベースにリカバリするとき、および databridge にテーブル
スペースを指定する場合、ぜひ、リカバリしたいテーブルスペースをつか
わないでください。
ユーザーはソースリポジトリから目標リポジトリへ伝送するテーブルの名前のマッピン
グを変更するか否かを選択できる。例えば、ソースリポジトリであるテーブルが Truncate
された、いまは DataBridge により、データをソースリポジトリへリカバリするが、元の名
前をつかいたくないで、ほかの名前で格納したいとき、“if need to remap table”を選んで
ふさわしい名前を入力すればいい：

Database
ParnassusData
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 ボタンをクリックしてください：

Database
ParnassusData
データバイパスが完成したら、伝送できたデータ行数と経過時間を示される。

Database
ParnassusData
リカバリシーン３ Oracle データディクシ
ョナリーがダンメージを受け、データベー
スが起動できない
Ｄ社のＤＢA は誤操作で TS$データディクショナリーを削除したため、データベースが
起動できない。

Database
ParnassusData
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

Database
ParnassusData
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:
Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc:
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.実際に応じて、テーブルのデータをリカバリしてください。

Database
ParnassusData
リカバリシーン 4 誤削除と SYSTEM テー
ブルスペースがなくした。
Ｄ社のＳA システム管理員があるデータベースの SYSTEM テーブルスーペスのフィル
タを削除したことによって、データベースがうまく起動せず、データを取り出せない。でも、
たとえバックアップがなくても、ＰＲＭで１００％に近いデータをリカバリできる。
此场景中启动 PRM 后，进入 Recovery Wizard 后选择《Non-Dictionary mode》非字典
模式:このシーンでＰＲＭを起動したら、Recovery Wizard に入ったら、Non-Dictionary
mode を選んでください：

Database
ParnassusData
No-dictionary モードでユーザーが文字セットと各国語キャラクタ・セットを指定する必

Database
ParnassusData
要がある。システムテーブルスペースをなくした後、データベース情報の文字セットが正確
に獲得できないから、ユーザーの入力が必要になる。正確に文字セットを設置したことと必
要な言語パックをインストールしたことは 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 に頼

Database
ParnassusData
らず、Ｂフィルタの EXTENT MAP の情報に頼るしかない。
SEGMENT HEADER に基づく和 EXTENT MAP データの NO-Dictionary モードのリ
カバリ需要を同時に満たすために、SCAN 操作はここで SEG$.DAT と EXT$.DAT に書き
込み、（テキストフィルタは診断しやすくなるため、すべてのプログラムはＰＲＭ自身が持
ち込む DERBY に頼っている。）そして DERBY データベースに記録する。

Database
ParnassusData
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

Database
ParnassusData
を使うことに考えてください。
私たちは Scan Tables From Segments モードを優先的に利用することを勧めている。
Scan Tables From Segments 完成したら、インタフェース左側の樹形図を起動できる。

Database
ParnassusData
Scan Tables 操作は SEG$の中の SEGMENT HEADER 情報でデータテーブルの情報を
構造する、樹形図の中に一つのノードが一つのデータテーブルセグメントを意味する。、そ
の名は obj+データセグメントが記録した DATA OBJECT ID。
一つのノードをクリックして、インタフェース右側のコラムを見てください。

Database
ParnassusData
インテリジェントフィールドタイプ分析
システムスペースをなくしたゆえに、NO-Dictionary モードではデータテーブルの構造
情報がない。その構造情報にはテーブルのフィールド名とフィールドタイプを含んでいて、
そして Oracle でこれらの情報がディクショナリー情報として格納する。ユーザーがテーブ
ルスペースを使うときに、データセグメントの ROW 行データで一つ一つのフィールドの
タイプを当てる必要がある。ＰＲＭは最先端のＪａｖａ予測技術を応用し、10 種以上のメ
インデータ・タイプも含まれている。
インテリジェント分析の正確度が 90％を超え、自動的に多くのシーンを解決できる。
右側のコラムのフィールドの意味：

Database
ParnassusData
 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
この部分にはインテリジェントフィールドタイプ解析の結果で１０個のデータを解析し、

Database
ParnassusData
そしてその結果を示す。例のデータによって、ユーザーがそのデータセグメントの中のデー
タを格納する様子を、もっと詳しく理解できる。
もしデータセグメントにあるデータは１０個を足りていないなら、すべての記録が表示
される。
TRY TO ANALYZE UNKNOWN column type:
この部分はインテリジェントフィールド型解析が１００％で確認できないフィールドを
いろんな手段をつかって解析して、ユーザーは自身の判断でタイプを判明できる。
ＰＲＭ今まだ支持していないタイプは：
XDB.XDB$RAW_LIST_T、XMLTYPE、カスタムタイプなど。

Database
ParnassusData
Unload Statement:
この部分はＰＲＭが生成した UNLOAD 文で、システムが内部的に使用する場合とＰＲ
Ｍ開発チーム及びParnassusData エンジニアがサポートしている場合にしか使えない。

Database
ParnassusData
ドも使える。ディクショナリーモードと比べれば、主な違いは非ディクショナリーモード
でユーザーが自身でフィールドのタイプを実行できる、以下のように、一部のフィールドタ
イプは UNKNOWN で、これらのフィールドはＰＲＭがまだ支持していないフィールドで、
あるいはＰＲＭのインテリジェント解析が順調に解析できなかったから。
もしユーザーがこのテーブルが設計するときの構造さえ知っていれば（アプリ開發者か
らのフィルタもいい）、自身で正確な Column Type を選べるようになる。これによって、
ＰＲＭがそのテーブルのデータを順調に目標データベースにデータバイパスできる。
誤操作でテーブルスペースと一部のアプリ
テーブルスペースデータフィルタを削除し
た。
Ｄ社の SA は誤操作で、オンライン業務データベースの SYSTEM テーブルスペースのフ

Database
ParnassusData
ィルタと一部のアプリテーブルスペースフィルタを削除した。
このシーンで、一部のアプリデータスペースフィルタが削除されたから、その中にデータ
テーブルの 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.そのほかの操作はシーン４と同じ。
リカバリシーン 6 壊された ASM Diskgroup
からデータベースのデータを抽出する
Ｄ社は ASM 方法でフィルタシステムと RAW デバイスをかわったが、いま運用して
いるのは 11.2.0.1 バーションで、bug が多いので、ASM DISKGROUP ディスくが
MOUNT をロードできなくて、いろんな手を打ったが、なかなか効果が出ない。
このシーンで使えるのはＰＲＭの ASM Files Clone フィルタコーピー機能です。この機
能はダンメージを受けた ASM Diskgroup からデータベースフィルタをコーピーできる。
1.インタフェースをオープンして、Tools メニューコラムで ASM File(s) Clone を選んで
ください。:

Database
ParnassusData
2. ASM Disks に入って、SELECT…をクリックして、使用可能な ASM Disks を追加す
る。例えば、/dev/asm-disk5(linux)。すべての使用可能な LUN を追加した後、ASM analyze
ボタンをクリックしてください。

Database
ParnassusData

Database
ParnassusData
ASM analyze が Disk group の中のフィルタとアドレス(File Extent Map)を見つけ出
すために、指定された ASM Disk のディスクヘッダーを分析する。これらのデータは以
後も使えるように、Derby データベースに記録される。ここで、ＰＲＭは ASM あらゆ
るの Metadata を収集して分析して格納する。そして、いろいろな方法でＰＲＭの基本
的な機能を改善し、グラフの形式でユーザーに示す。

Database
ParnassusData
ASM Analyze が完成したら、ＰＲＭは探し出した ASM のフィルタをリストにする。ど
れをコーピーする必要があるか、ユーザーが自分で決めて、コーピー先を指定することもで
きる。

Database
ParnassusData
コーピー段階で、ASM File のコーピー進捗状況を示されて、完成したら、OK をクリッ
クしてください。
コーピー段階の進捗状況は以下のようにエクスポートする。
Preparing selected files...

Database
ParnassusData
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:
......
Cloning
+DATA2/ASMDB1/ARCHIVELOG/2014_02_17/thread_1_seq_48.258.839732751:
......
All selected files were cloned done.
Dbv あるいは rman validate コマンドによって、コーピーされたフィルタを確認できる。
例えば：
rman target /

Database
ParnassusData
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

Database
ParnassusData
/dev/oracleasm/disks でのフィルタを PRM ASM DISK に追加してください
リカバリシーン 7 ASM の環境でデータベ
ースが起動できない
Ｄ社の一番大事な CRM リポジトリが ASM Diskgroup に追加したディスクが I/O 問題
があるから。SYSTEM テーブルスペースの DBF データフィルタがエラになり、データベ
ースが正常に起動できない。
この時は PRM を通って、ASM Diskgroup から DATAFILE を全部フィルタシステムに
コーピーして、リカバリシーン６のように、データベースを修復する。
ＰＲＭの Dictionary Mode(ASM)も ASM のディクショナリーモードで問題を解決でき
る。簡単な流れは以下の通り：
1. Recovery Wizard
2. Dictionary Mode(ASM)
3. 必要な ASM DISK を追加し（リカバリしたいデータベースを含む ASM Disk Group に
すべての ASM DISK）
4. ASM analyze クリックする
5. あとのフィルタのために、ふさわしい Endian を選ぶ。
6. ASM analze のフィルタリストで必要とするデータフィルタを選んでください。一つの
リポジトリしかない場合に、Select all を選んでください。
7. ロードをクリックして、後のリカバリはシーン３に似ている。

Database
ParnassusData

Database
ParnassusData
リカバリシーン 8 ASM で SYSTEM テーブ
ルスペースのリカバリを削除した（なくし
た）
Ｄ社の技術者は誤操作で一番大事なデータベースの SYSTEM テーブルスペース
FILE#=1 のフィルタと一部のアプリテーブルスペースを削除したことによって、データベ
ースが順調に起動できない。
このシーンで PRM の《Non-Dictionary Mode(ASM) 》ASM の非ディクショナリーモー
ドによって、今のデータフィルタに基づき、いちはやくデータをリカバリできる。
簡単な流れは以下の通り：
1. Recovery Wizard
2. Dictionary Mode(ASM)
3. 必要な ASM DISK を追加し（リカバリしたいデータベースを含む ASM Disk Group
にすべての ASM DISK）
4. ASM analyze クリックする
5. あとのフィルタのために、ふさわしい Endian を選ぶ。（非ディクショナリーモードな
ので、人工で選ぶ必要がある）。
6. ASM analze のフィルタリストで必要とするデータフィルタを選んでください。一つの
リポジトリしかない場合に、Select all を選んでください。
7. ロードをクリックして、後のリカバリはシーン３に似ている。

Database
ParnassusData

Database
ParnassusData
リカバリシーン 9 誤操作で DROP
TABLESPACE したデータをリカバリする
Ｄ社の職員があるいらないテーブルスペースを削除したいだが、つまり 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(*)
----------

Database
ParnassusData
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:PPMACLEANORADATAPARNASSUSDATAFILEO1_MF_USERS_9MNBMJYJ_.DBF
SQL> drop tablespace users including contents;
テーブルスペースもう削除した
C:Usersmaclean>dir
H:APPMACLEANORADATAPARNASSUSDATAFILEO1_MF_USERS_9MNBMJYJ_.DBF
ドライブの巻は entertainment
巻のシリアルナンバーは entertainment
フィルタが見つからない
drop tablespace した後、TABLESPACE に該当するフィルタが OS で削除されたから。

Database
ParnassusData
この時に、フィルタリカバリツールでリカバリできる。
ＰＲＭを起動する=> recovery Wizard =>非ディクショナリーモード

Database
ParnassusData
非ディクショナリーモードなので、自分からふさわしい文字セットを選ぶ必要がある。

Database
ParnassusData
先リカバリしてきたフィルタをクリックしてスキャンする。

Database
ParnassusData

Database
ParnassusData
そしてセグメントヘッダあるいはディスク領域スキャンテーブルを選んでください。セ
グメントヘッダーがすべてのテーブルをひとつも漏れずに探し出すことができない場合に、
ディスク領域でもう一度スキャンしてください。

Database
ParnassusData
そして、インタフェースの樹形図にものすごく大量な OBJXXXXX のようなテーブルが
現れる。ここの OBJXXXXX はテーブルの DATA_OBJECT_ID であって、そのシステムの
開發応用モードに詳しい技術者がサンプルデータ分析を参照して、テーブルとアプリテー
ブルをつながる。

Database
ParnassusData
もし、協力する技術者がいないなら、以下の方法を考えてください。
この例で使っているのは DROP した TABLESPACE テーブルのスペースであって、デ
ータベース自身はなんの問題もないので、 FLASHBACK QUERY を活かし、
DATA_OBJECT_ID とテーブル名前のつながりを獲得できる。
SQL> select count(*) from sys.obj$;
COUNT(*)
----------
75436

Database
ParnassusData
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)

Database
ParnassusData
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

Database
ParnassusData
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 データに頼っていて、正確性には少し問題がある。

Database
ParnassusData
リカバリシーン 10 誤操作で DROP したテ
ーブルのリカバリ
Ｄ社のアプリ開發者が 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.

Database
ParnassusData
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_LOG
MNR.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

Database
ParnassusData
SQL> alter tablespace users offline;
Tablespace altered.
ＰＲＭを起動して、NON-DICT モードに入って、該当するデータフィルタを追加し、
SCAN DATABASE+SCAN TABLE From Extents を選んでください。

Database
ParnassusData
ASM Diskgroup にあるすべての ASM Disks 追加したら、ASM analyze をクリックして
ください。

Database
ParnassusData
非ディクショナリーモードなので、必要な文字セットを入力してください。
DROP されたデータテーブルを含むテーブルフィルタをクリックすればいい、ほかのフ
ィルタはどうでもいい。そして SCAN をクリックする。

Database
ParnassusData

Database
ParnassusData
生成したデータベースの名前をクリックし、右ボタンで scan tables from extents を選ん
でください。

Database
ParnassusData
人工的に DATA_OBJECT_ID=82641 のデータは DROP された TORDERDETAIL_HIS
テーブルに該当し、DataBridge 技術でモートのリポジトリに伝送する。

Database
ParnassusData

Database
ParnassusData
FAQ よくある質問
データベースの文字セットが分からなかったらどうすればいい？
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
なぜＰＲＭいつもシャットダウンするあるいは 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 のダウンロードリンクは以下の通り：
http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-arhive-
downloads-javase6-419409.html#jdk-6u45-oth-JPR

Database
ParnassusData
ＰＲＭの bug を見つけ出したら、どうやって ParnassusData に report bug すればいい
でしょう？
ParnassusData はあらゆるの report bug を歓迎する。report_bugs@parnassusdata.com
にメールすればいい。メールに bug が出た運用環境、オペレーションシステム、Java 運用
環境と ORACLE データベースバーション情報を一緒に送信してください。
ＲＰＭを起動するときにこのようなエラになったら、どうすればいいでしょう？
Error: no `server' JVM at `D:Program Files
(x86)Javajre1.5.0_22binserverjvm.dll'.
これはユーザーが JAVA Runtime Environment JRE をインストールしているが、JDK
をインストールしていないからである。ＰＲＭの起動スクリプトに-sever オプションが追
加したから、このオプションは JRE 1.5 前のバーションにないので、エラになる。
ParnassusData は JDK1.6 以上の環境でＰＲＭを運用することを勧めている。
JDK 1.6 のダウンロードリンクは以下の通り
http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-
downloads-javase6-419409.html#jdk-6u45-oth-JPR
なぜＰＲＭを使うとき、漢字が文字化けになるでしょう？
今我々知っている文字化けに導く原因は以下のふたつがある：
オペレーションシステムに中国語言語パックをインストールしていないので、まともに
漢字を映せない。
言語バックをインストールしたが、JAVA の運用環境は JDK 1.4 なので、文字化けが出
る可能性がある、JDK 1.6 以上のバーションを使ってください。
ＰＲＭは LOB ラージオブジェクトフィールドを支持していないでしょうか？
いまＰＲＭは CLOB、NCLOB、BLOB などの LOB ラージオブジェクトフィールドを支
持している。Disable/Enable Storage in ROW などの場合は LOB へデータバイパスモード

Database
ParnassusData
も支持している。
LOB ラージオブジェクトフィールドには通常の UNLOAD 抽出を支持していない。この
抽出方法を使ったら、データを導入する場合にものすごくめんどくさいなので、DataBridge
データバイパスモードを使ってください。

Database
ParnassusData
Find More
Resource : http://www.parnassusdata.com/resources/
Technical Support: service@parnassusdata.com
Sales: sales@parnassusdata.com
Download Software: http://www.parnassusdata.com/
Contact: http://www.parnassusdata.com/zh-hans/contact
Conclusion
ParnassusData Corporation , Shanghai , GaoPing Road No. 733 . China
Phone: (+86) 13764045638
ParnassusData.com
Facebook: http://www.facebook.com/parnassusData
Twitter: http://twitter.com/ParnassusData
Weibo: http://weibo.com/parnassusdata
Copyright © 2013, ParnassusData and/or its affiliates. All rights reserved. This
document is provided for information purposes only and the contents hereof are subject

Database
ParnassusData
to change without notice. This document is not warranted to be error-free, nor subject to
any other warranties or conditions, whether expressed orally or implied in law, including
implied warranties and conditions of merchantability or fitness for a particular purpose.
We specifically disclaim any liability with respect to this document and no contractual
obligations are formed either directly or indirectly by this document. This document may
not be reproduced or transmitted in any form or by any means, electronic or mechanical,
for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or
registered trademarks of Advanced Micro Devices. Intel and Intel Xeon are trademarks
or registered trademarks of Intel Corporation. All SPARC trademarks are used under
license and are trademarks or registered trademarks of SPARC International, Inc. UNIX
is a registered trademark licensed through X/Open Company, Ltd. 0410
Copyright © 2015 ParnassusData Corporation. All Rights Reserved.

Oracle専用データ復旧ソフトウェアprm dulユーザーズ・マニュアル

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Oracle専用データ復旧ソフトウェアprm dulユーザーズ・マニュアル

Similar to Oracle専用データ復旧ソフトウェアprm dulユーザーズ・マニュアル (20)

More from maclean liu

More from maclean liu (20)

Oracle専用データ復旧ソフトウェアprm dulユーザーズ・マニュアル