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 を入力する必要があって、支払いを完了してから、メールを受信する。そのメー

http://www.parnassusdata.com/


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:\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 で削除されたから。


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

http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html#jdk-6u45-oth-JPR



Database

ParnassusData


ＰＲＭの bug を見つけ出したら、どうやって ParnassusData に report bug すればいい

でしょう？

ParnassusData はあらゆるの report bug を歓迎する。[email protected]

にメールすればいい。メールに 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 のダウンロードリンクは以下の通り

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 へデータバイパスモード

mailto:[email protected]





Database

ParnassusData


も支持している。

LOB ラージオブジェクトフィールドには通常の UNLOAD 抽出を支持していない。この

抽出方法を使ったら、データを導入する場合にものすごくめんどくさいなので、DataBridge

データバイパスモードを使ってください。


Database

ParnassusData


Find More

Resource : http://www.parnassusdata.com/resources/

Technical Support: [email protected]

Sales: [email protected]

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

http://www.parnassusdata.com/resources/



http://www.parnassusdata.com/

http://www.parnassusdata.com/zh-hans/contact

http://www.facebook.com/parnassusData

http://twitter.com/ParnassusData

http://weibo.com/parnassusdata


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.