1 Copyright © 2012, Oracle and/or its affiliates. All ...otndnld.oracle.co.jp/ondemand/ddd/PDF/MA-4_print_c.pdf · 高可用性テクノロジーと成功事例に基づいたベスト・プラクティス

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 1

高可用性システムに適した管理性と性能を向上させる ASM と RMAN の魅力

日本オラクル株式会社

テクノロジー製品事業統括本部基盤技術部

プリンシパルエンジニア

柴田長


以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。


Program Agenda

Oracle Maximum Available Architecture

Oracle Automatic Storage Management

Oracle Recovery Manager

Flashback Technologies

Wrap-up




What is Oracle MAA ?

Maximum Availability Architecture (MAA) は、Oracleの実証済み

高可用性テクノロジーと成功事例に基づいたベスト・プラクティス

MAAの目的

– あらゆる停止を回避、検出、修復するためのベスト・プラクティスを提供

– 最適な高可用性アーキテクチャをシンプルに構成

ハードウェアやOSの影響を受けない（特定の高価な製品や技術は不要）

高可用性のソリューションをすぐに提供（Oracleが事前検証済み）


Oracle MAA の全体像 Low-Cost, Integrated, Fully Active, High ROI

Edition-based Redefinition,

Data Guard, GoldenGate

– メンテナンス、アップグレード、

マイグレーションに伴う停止時間を極小化

Production Site

RAC

–拡張性

–サーバー障害対策

Flashback

–人的エラーの訂正 ASM –ボリュームマネージャー

RMAN & Fast Recovery Area –ディスクバックアップ

Active Data Guard –データ保護

–災害対策

–クエリ・オフロード

GoldenGate –スタンバイの活用

（Active-Active） –異機種混在環境への対応

Oracle Secure Backup –テープバックアップ、クラウド対応

Active Replica




Oracle Automatic Storage Management アーキテクチャ

ASM Disk Group

Oracle

Instance

ASM

Instance

CSS

データメタデータ

ASMインスタンス

– ASM Diskgroupを管理するメモリとプロセス群

– Oracleインスタンスを改造したもの

Cluster Synchronization Services

– Oracle Clusterwareのメンバシップ管理サービスを利用

– DBインスタンスとASMインスタンスの存在通知する

ASM Diskgroup

– Oracleインスタンスに対する仮想化ストレージプール

ASM Disk

– ASM Diskgroupを構成する個々のDisk(Logical Unit)


RAW deviceとOracle ASMの比較スタック構成図

RAW device Oracle ASM

Database Database

ASM

OS OS VM

Storage Storage

lvol lvol lvol lvol lvol lvol ・・・

dbf dbf dbf dbf dbf dbf ・・・

idx idx redo tbl tbl tbl

Tablespace ・・・

・・・

raw raw raw raw ・・・

LU LU LU LU ・・・

RAID Group ・・・

dbf dbf dbf dbf dbf dbf ・・・

idx idx redo tbl tbl tbl

Tablespace ・・・

・・・

raw raw raw raw ・・・

LU LU LU LU ・・・

RAID Group ・・・

Volume Group

Disk Group


RAW deviceとOracle ASMの比較 Write時のアドレス変換

RAW device Oracle ASM

Block Address + Data File ID

Volume Manager Layer

Oracle I/O Layer

Mapping Info

Raw Device

Logical Volume Address

Device Address

lvol

Block Address + Data File ID

Oracle I/O Layer

Mapping Info

Raw Device

Device Address

ASM I/O Layer


Oracle ASMの基本思想

「全てのDiskの均等利用を目的に、データをストライプして全てのDisk上に分散配置し、ミラーリングも行う」という設計手法

– I/O性能の確保：全てのDiskのI/O帯域をフル活用

– 可用性を確保：ミラーリングの採用

– 設計の簡素化：物理的なDisk構成を隠蔽し、特別な設計は不要

Stripe And Mirror Everything (S. A. M. E)

ストライピング

ミラーリング


ストレージ物理設計の変化

アクセス・タイプで分離する必要性が希薄化

– 全てのDiskをフル活用し、I/O性能を最大化

部分最適化から全体最適化へ

TblA IdxB TMP TblA IdxA

Sequential Read Random Read

従来イメージ

部分最適化

S. A. M. E

全体最適化

Oracle ASMによるストライピングASM Fileの分散配置

ASM Diskgroupに含まれる全てのASM Diskに対して、ASM File（Data File）をFile Extent(AU)単位に分割して配置ASM File（Data File）をFile Extent(AU)単位に分割して配置

ASM Diskgroup1 2 3 4

ASM File(Data File)

1 2 3 4

1 2 3 4

5 6 7 8

5 6 7 8

Fil E t t (AU)

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.14

Disk Disk Disk Disk

5 6 7 8File Extent (AU)


Oracle ASMによる可用性担保

ファイル毎にミラーリング（External/Normal/High）の設定が可能

– 異なる障害グループに属するASM Disk間で保持

– 通常、リソース(電源等)を共有している単位(筐体/コントローラー)で設定

ミラーリングと障害グループ

ASM Diskgroup

障害グループA

1

4

2

3

障害グループB

3

1

4

2

1 2 3 4

ASMファイル(Normal)

Primary Extent

Secondary Extent

Disk Disk Disk Disk


S.A.M.EはOLTP処理にしか向いていない？

OLTP処理

– データベース側：シングル・ブロック・リード（ブロック・サイズ単位）

– ストレージ側：スモール・ランダム・リード

多くのDiskをストライプして束ねることで、十分なiopsを確保可能

DWH/バッチ処理

– データベース側：マルチ・ブロック・リード（基本、1MB単位）

– ストレージ側：ラージ・シーケンシャル・リード

ストライプにより、シーケンシャルに読み込めなくなってしまう？

各処理と“従来的に期待する”ストレージ側の読み方


Hard Disk Drive技術の進化

1. Disk回転速度の向上

同量のデータを読み出す時間の短縮

セクタの配置が変わり、シーク範囲が狭まる

2. Disk外周のセクタの高密度化

外周でのシークが多くなり、ヘッドの動く距離が短縮され、ランダム・アクセスが高速化

3. Diskの低価格化

多くのDiskを束ねることで十分なI/O性能を確保

ランダム・リードの並列化でシーケンシャル・アクセスも高速化


参考) ランダム・リードの並列化による効果

例えば、15krpmのHDDが60本の場合（中規模システムを想定）

– 1MBのI/Oサイズでランダム・リードした際のスループット

Oracle ORIONの検証結果より、40-45iops/Disk

40iops × 1MB/io = 40MB/sec

40MB/sec × 60本 = 2.4GB/sec

– 1台あたり4Gbps × 2本のFC構成で、2ノードRAC構成の最大スループット

4Gbit / 8 bit / 1sec = 512MB/sec

512MB/sec × 2本 = 1GB/sec

1GB/sec × 2ノード = 2.0GB/sec

Fibre Channel帯域幅がポイント


DG#3

DG#4

従来型のRAW device構成例結局はストライピングが目的

#1 LU#1

LU#16

DG#1

DG#2

dbf#1

dbf#2

dbf#3

dbf#4

dbf#15

dbf#16

TBS#1

…

…

TBS#2

TBS#3

TBS#4

…

Segment(Table/Index)

…

Table Space

(Small File)

Data File RAW Volume

1DG16Volume

Volume Manager

4LU1VG

Vol#1

Vol#2

Vol#3

Vol#4

Vol#15

Vol#16

Vol#16 x 4 x n

RAID Group[RAID1(1+1)]

1RG4LU

…

DG#7

DG#8

#2 LU#17

LU#32

DG#6

…

DG#16 x n

#n

LU#16 x n

…

DG#5


従来のRAWデバイス構成の課題

表領域が非常に細かく分割されている

– 空き領域が表領域毎に独立している為、無駄な空き領域が増大

– 監視対象（表領域）が多く、頻繁に領域不足に陥り、運用工数が増大

– データ・ファイル数が多く、SQLの性能劣化やミス・オペレーションを誘発

– 管理レイヤー数が多い為、運用オペレーションの複雑化

データ・ファイル追加時に、既存データをリバランスしていない

– 空き領域が新規ボリュームにのみ存在する為、新たにINSERTされるレコードがそのボリュームに集中することで、ボトルネックが発生し易い

– 既存レコードは既存ボリューム内に格納されている為、性能改善効果は無し

運用の複雑化


Oracle ASMの構成例結局はストライピングが目的

#1 LU#1

LU#4

DG#1

TBS#1 …

TBS#

TBS#9

…

Segment(Table/Index)

…

Table Space

(Big File)

Oracle ASM RAID Group[RAID1(1+1)]

1RG1LU

…

#2 LU#17

LU#32

…

DG#2

#n

LU#4 x n

…


Oracle ASMによる運用管理の簡素化

オペレーションの簡素化

– 表領域拡張やDisk追加の手順が簡素化し、運用オペミスのリスクが減少

管理対象オブジェクトの削減

– ASM Diskgroupの容量内で表領域を自由に拡張可能であり、従来のVolume

やRAWデバイス（データファイル）を意識する必要なし

– ストライピングでI/Oが均等化することで、表領域を細かく分割してI/O競合を回避する必要なし。表領域の総数を大幅に削減可能

データ再配置の工数不要

– Disk追加時に自動的に既存データの再配置（リバランシング）を実施

従来構成の課題を解決


Oracle ASMのリバランス（データ再配置）

ASM Disk（Logical Unit：LU）が追加／削除（故障）した際、

「S. A. M. E」を維持する為にデータの再配置を実施

– メタデータ（配置状況）を元に、ASM File単位で全てのDiskに均等配置されるように最小限のExtent（AU）の移動で実現

– 多重度（リバランス強度）の設定や計画実行で、業務影響を制御可能

データベース無停止でリバランスが可能

- + REBALANCE


ASMによるデータの分散配置 Data File単位で各ASM Diskに対し均等にFile Extent(AU)を割り当て

TBS DBF

TBS DBF

CREATE TABLESPACE TBS DATAFILE ’+DATA’ SIZE 1G ;

DATA ディスク・グループ

ALTER TABLESPACE TBS RESIZE 2G ;

(1) 表領域の作成

(2) 表領域の拡張

File Extent（AU）

TBS DBF

TBS DBF

ALTER DISKGROUP DATA ADD DISK '/devices/disk5‘ ; (3) リバランス（Disk追加）

disk1 disk3 disk2 disk4 disk5


ASMによるデータの分散配置

ASM File（= Data File）単位で均等に分散し直す

追加Diskへ移動するFile Extentは、全てのASM Fileが対象

– 最後に作成した（Diskの後ろに位置する）ASM Fileのみではない

断片化の自動的な解消（コンパクション処理）

– File Extentが追加Diskへ移動することで、既存Diskでは歯抜け状態へ

– リバランスの最後のステップでコンパクション処理を実行することで回避

各ASM Diskにおいて、後方に位置するFile Extent（AU）から順番に

前方の空きスペースへ移動

リバランスの動作


リバランス強度の設定

PSR11.2.0.2~ リバランス強度（power_limit）の動作変更有り

– power_limitパラメータに設定可能な値は、0～1024 （以前は、0~11）

– ARB0プロセス（クラスタで1つのみ起動）が同時に発行する非同期I/Oの数

– ストレージのI/O性能に応じた適切な値を設定すること

事前準備

ASM DiskgroupのCOMPATIBILITY属性を11.2.0.2以上に明示的に設定しなければ、12以上には設定不可（PSR11.2.0.3では、デフォルト11.2.0.0.0）

PSR11.2.0.2以降

alter diskgroup <ASM Diskgroup Name>

set attribute 'compatible.asm'='11.2.0.2.0';


Oracle ASMにおけるDisk障害時の挙動

ミラーリング構成が前提

– 読み取り処理時に I/Oエラーを検知した場合

セカンダリから読み取り、不良ブロックは自動修復

– 書き込み処理時に I/Oエラーを検知した場合

障害Diskを自動でオフライン処理

高速ミラー再同期により、生存Disk側から必要最小限のデータを同期

– 複数ストレージを束ねた環境で片側に書き込めなかった場合、復旧後にどちらのストレージ上のデータが新しいのかストレージ側では認識不可能だが、ASMでは可能

ストレージの欠点も補完し得る


Diskの二重障害を考慮した構成案

ASMのHigh Redundancy（トリプル・ミラー）が効率的

– Inifinibandを搭載したExadataであれば、よりメリットが出てくる

***参考までに*** RAID1+0 × Normal vs. RAID0 × High

RAID1+0 ×

Normal RAID0 × High

Read時にアクセスされるDisk数 6本 12本

Write時のFC帯域を流れるデータ量 2倍 3倍

Write時のストレージ内のI/O量 4倍 3倍

Disk使用量 4倍 3倍


ASM File

Fibre Channel

RAID1+0 × Normal vs. RAID0 × High Read時にアクセスされるDisk数

ASM Diskgroup

RAID1

RAID0

RAID1 RAID1

RAID0

RAID1

1 2

1 2

2 3

1 2

2 3

1’ 2’

2’ 3’

RAID1

RAID0

RAID1

3

1

3’

1’

3

1

3

ASM Diskgroup

RAID0

1 2

2 3

3

1

3’ 1’ 2’

RAID0 RAID0

1 2

2 3

3

1

3’ 1’ 2’

1 2 3

RAID1+0 RAID1+0 RAID1+0 RAID0 RAID0 RAID0

RAID

Logical Unit

(Storage

Controller)


Oracle ASMにおけるストレージ設計指針

1. 一つのRAID Groupは、一つのLogical Unitのみ切り出す

2. 可能な限り多くのLUを一つのASM Diskgroupで束ねる

3. 各ASM Diskgroupに含めるASM Disk(LU)は同一の性能 &サイズ

4. Redoログ用のDiskgroupはSSDで別構成

5. RAIDグループと冗長構成パターン例

基本構成1：「RAID1+0」 × External Redundancy

基本構成2：「RAID無し or RAID0」 × Normal Redundancy

二重障害対応構成：「RAID無し or RAID0」 × High Redundancy

可能な限りシンプルに




バックアップ方式の比較 Disk to Disk vs. Oracle Recovery Manager

Disk to Disk RMAN

バックアップの全損リスク × 全損リスク有り ◎ 高速増分バックアップで回避

バックアップの

性能と負荷

消費リソース ◎ ストレージのリソースのみ △ サーバーのリソースを使用

総I/O量 ○ セクタ単位での差分のみ ○ ブロック単位での差分のみ

保持データ総量 △ 正volumeと同等のサイズ ○ 圧縮/削減が可能

Redo生成量 × バックアップ中は増加する ◎ 通常時と同等

管理性 × 手動管理で煩雑な傾向 ○ 世代管理の自動化

汎用性 △ ストレージベンダー依存 ○ H/W構成から独立

破損ブロック対策 × 正常or破損の区別も不可 ◎ バックアップ時に検知可能

ASMリバランスの影響 × 差分データ量が大幅に増加 ◎ 影響なし

バックアップの暗号化 × 正volumeのコピーなので不可 ○ 暗号化可能

価格 × 数千万～数億か（製品依存） ○ EE標準機能

リストア&リカバリ柔軟性 △ 最小でもLU単位 ○ ブロック単位まで対応可能

管理性 × DBAのスキルに依存 ○ アドバイザで自動判別


副volume

正volume

D2D（Disk to Disk）バックアップ運用手順

バックアップ前提運用フェーズ(バックアップ運用)

Clone LUs

Bitmap

DML

dbwr

Source LUs

全体同期 +

切り離し

Bkup開始 Bkup完了

Bkup Window

Bitmap

バックグラウンドで

差分同期 Bitmap比較


+FRA DG

+DATA DG

RMANによる高速増分バックアップ運用手順


Image Bkup(level 0)

BCT File

DML

ctwr

dbwr

Data Files

全体Bkup

Bkup開始 Bkup完了

高速増分Bkup

(level 1)

増分更新Bkup

Bkup Window

BkupSet (level 1)


D2D vs. RMAN（高速増分バックアップ）

実は、バックアップのデータ量は同程度で、コピー時間も同程度

– D2Dは一瞬でバックアップが終わるというイリュージョン

– 実際のデータのコピー処理はバックグラウンドで動き続けている

そして、一見すると、どちらも同じに見えてきますが・・・質問！！

– D2Dでのバックアップ中に正volumeが壊れてしまった場合、リカバリすることが可能でしょうか？

運用手順の比較とRMANの優位点

NG：バックアップに上書きを施す為、有効なバックアップが無い

バックアップの2面持ち or テープバックアップが必須

一方、RMANは増分と更新のフェーズに分割可能で問題なし


副volume

正volume

D2D（Disk to Disk）バックアップ同期中の障害発生時にリカバリ不可


Clone LUs

Bitmap

DML

dbwr

Source LUs

全体同期

+

切り離し

Bkup開始

Bitmap

Bitmap比較

障害発生

最後まで同期されない

= バックアップが

完成していない

= リストア&リカバリ不可


バックアップの性能と負荷

ストレージのCPU、I/Oリソースのみを使用

消費リソース

データベース・サーバーのCPU、I/O

帯域を使用

回避策

– スタンバイでバックアップ、Resource Managerで制御

– 空ブロックや古いUNDO等、バック

アップ不要なデータをスキップすることにより、消費リソースを最小限に抑えることが可能

D2D:◎ RMAN:△



前回の同期時点から正volumeで更新されたセクタのみを副volumeへ再同期

– 読込量、書込み量ともに差分のみに制限することが可能

総I/O量

増分バックアップにより、前回バからの更新ブロックのみをバックアップとして書き込む

Block Change Tracking File（以降、BCT）を使用した高速増分バック

アップにより、バックアップ元からの読み込みを大幅に削減することが可能

– 10g以降利用可能。BCTを使用しな

い場合、書込量は差分のみだが、読込量は全データとなる。

D2D:○ RMAN:○


高速増分バックアップ

BCT Fileには、更新されたブロック・アドレスをビットマップでバージョン管理

– バックアップ時は、前回バックアップ以降に更新されたブロックだけを読み込む

– BCT Fileのサイズは非常に小さい

データベースのサイズ及びRedoのスレッドの数に比例

初期サイズは10MBで、通常、ブロック・サイズの約1/30,000×ノード数

– 300GBまでは10MB、600GB時は20MB+α

– BCT Fileへの書き出しは、CTWRプロセスがトランザクションと非同期で実施

Large Pool（不足時はShared Pool）内のCTWR dba buffer経由

ビットマップ管理で大きなI/Oは皆無、Commit時の遅延も無し

Block Change Tracking の仕組み



バックアップとして保持する副volumeは、正volumeと同じサイズの領域を必要とする

– 同期中に有効なバックアップを保持し続ける為には、副volumeが2面（2倍）必要

– 正常なベースバックアップがないスナップショットはバックアップとは言えない

保持データ総量

バックアップ・セット方式や、圧縮機能を活用することによりバックアップのサイズを縮小可能

– 空ブロックや古いUNDO等、バックアップ不要なデータを排除

D2D:△ RMAN:○



データベースをホット・バックアップ・モード（Begin/End backup）に切り替える必要有り

Begin/Endでのバックアップ中、更新処理のRedoレコードはブロック単位で保持する為、Redo生成量が多くなる傾向

– これを避ける為、更新量が極端に少ない時間帯でのバックアップが設計される

Redo生成量

データベースをホット・バックアップ・モードに切り替える必要無し

よって、D2Dよりも大幅にRedo生成量を抑制可能

– 通常時と同量のRedo生成量で、Redoサイズの設計でバックアップ期間を考慮する必要無し

– オンライン/バッチ処理のピーク時間帯を避ける設計

D2D:× RMAN:◎


管理性

リカバリ時に必要となるデータ・ファイル以外のファイルのバックアップ方法の正確な理解が必要

– アーカイブ・ログや制御ファイルは、データ・ファイルのバックアップとは別にバックアップが必要

– さらに、それらのファイルを世代管理（保持or削除）する仕組みの設計/実装/運用が必須

– 煩雑となりミス・オペレーションを誘発し易い傾向

データ・ファイル以外のバックアップ関連ファイル

アーカイブや制御ファイルも含めて必要なバックアップの世代管理を自動化できる

– RMANによるデータ・ファイルのバッ

クアップと同時に、それらのファイルも自動的にバックアップすることが可能

– 保持/削除ポリシーの設定で、ミスオペの発生を防止可能

D2D:× RMAN:○


破損ブロック対策

バックアップ時にブロック破損を認識不可。ブロック破損を含むイメージをバックアップとして取得

– リストア&リカバリのタイミングでブ

ロック破損に気付き、リカバリ不可に陥る可能性有り

– 例えば、毎日バックアップを取得 +

2世代保持していたとしても、実際に

は一週間前にブロックが破損してた場合には修復に必要なバックアップは既に存在していない。

確実にリカバリ可能なバックアップか？

ブロック構造を理解できる為、バックアップ時にブロック破損を検知可能

– 確実にリストア&リカバリ可能なバックアップを取得可能

参考情報

– KROWN#127924:RMANを使ってバックアップを取得する際に破損ブロックが検知された場合の対処方法について

– KROWN#68810:ORA-1578の主な発生原因とその対処方法について

D2D:× RMAN:◎


RMANのブロック破損チェックデフォルト設定では、ブロック破損を一つ検知すると中止

RMAN> -- 増分バックアップを実施

backup incremental level 1 tablespace RTEST1;

backupが開始されました(開始時間: 12-07-23)

チャネルORA_DISK_1の使用


チャネルORA_DISK_1: 増分レベル1のデータファイル・バックアップ・セットを開始しています

チャネルORA_DISK_1: バックアップ・セットにデータファイルを指定しています

入力データファイル・ファイル番号=00010 名前=+DATA/o11g/datafile/rtest1.282.789398885

チャネルORA_DISK_1: ピース1(12-07-23)を起動します

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03009: backupコマンド(ORA_DISK_1チャネル上)が07/23/2012 16:22:00で失敗しました ORA-19566: 破損ブロックの制限0を超えています(ファイル+DATA/o11g/datafile/rtest1.282.789398885)

SQL> select * from V$DATABASE_BLOCK_CORRUPTION;

FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE

---------- ---------- ---------- ------------------ ---------------------------

10 14980 1 6681461 FRACTURED


RMANのブロック破損チェック破損ブロックの修復例（KROWN#127924）とオブジェクトの確認

RMAN> --特定ブロックの修復

recover datafile 10 block 14980 ;

recoverが開始されました(開始時間: 12-07-23)



スタンバイの検索が終了し、1ブロックをリストアしました

メディア・リカバリを開始しています

メディア・リカバリが完了しました。経過時間: 00:00:01

recoverが完了しました(完了時間: 12-07-23)

SQL> --破損オブジェクトの確認

SELECT SEGMENT_TYPE, OWNER||'.'||SEGMENT_NAME "SCHEMA.TABLE"

FROM DBA_EXTENTS

WHERE 10 = FILE_ID

AND 14996 BETWEEN BLOCK_ID AND BLOCK_ID+BLOCKS -1 ;

SEGMENT_TYPE SCHEMA.TABLE

------------- -------------

TABLE RUSER.RTBL1


参考) Oracle Databaseのデータ破損対策


ASMリバランスの影響

ASM層でリバランスした後の正volumeと副volumeの同期処理は、

非常に多くのセクタがバックアップ対象となり得る

– ASM Extentの移動（コンパクション

も含む）を、ストレージ側は異なるデータが書き込まれた（差分）としか認識できない。

前回バックアップからの差分データ量の違い

BCTを使用した高速増分バックアップは、ASMのリバランスによる影響は受けない。

– 例) ブロック・アドレスFILE#1、BLOCK#100のブロックは、ASMのリバランスで配置されるASM Disk

が変更されたとしても、データベースから見たブロック・アドレスFILE#1、BLOCK#100は変化しない為、差分とは見なされない。

D2D:× RMAN:◎


リストア&リカバリの柔軟性

ブロック破損レベルの軽微な論理障害でも、そのブロックを含むLUを全

体のリストアを行い、広い範囲でリカバリが必要となる

– この影響範囲を小さくすることを検討し始めると、ASM Diskgroupの

細分化の検討が必要となり、結果的には設計/運用の複雑化を生じさせる傾向有り

障害範囲に応じた最適な単位でのリストア&リカバリ

特定のブロック単位、データファイル単位、データベース全体のように、最適な単位を提供

D2D:× RMAN:○


バックアップ方式の比較 Disk to Disk vs. Oracle Recovery Manager

Disk to Disk RMAN

バックアップの全損リスク × 全損リスク有り ◎ 高速増分バックアップで回避

バックアップの

性能と負荷

消費リソース ◎ ストレージのリソースのみ △ サーバーのリソースを使用

総I/O量 ○ セクタ単位での差分のみ ○ ブロック単位での差分のみ

保持データ総量 △ 正volumeと同等のサイズ ○ 圧縮/削減が可能

Redo生成量 × バックアップ中は増加する ◎ 通常時と同等

管理性 × 手動管理で煩雑な傾向 ○ 世代管理の自動化

汎用性 △ ストレージベンダー依存 ○ H/W構成から独立

破損ブロック対策 × 正常or破損の区別も不可 ◎ バックアップ時に検知可能

ASMリバランスの影響 × 差分データ量が大幅に増加 ◎ 影響なし

バックアップの暗号化 × 正volumeのコピーなので不可 ○ 暗号化可能

価格 × 数千万～数億か（製品依存） ○ EE標準機能

リストア&リカバリ柔軟性 △ 最小でもLU単位 ○ ブロック単位まで対応可能

管理性 × DBAのスキルに依存 ○ アドバイザで自動判別





Flashback Technology の革新的なエラー訂正

– エラー発生前の「正しい」データを参照する

エラー発生時点に巻き戻すための時間および負荷は DB規模ではなく、エラー発生以降の処理量に依存

シンプルなSQLで復旧

– SQL> flashback database to <timestamp>;

様々な復旧手段を提供

– Flashback Query, Table, Transaction, Database, Drop, Data Archive

Fast, Granular Error-Correction

Correction Time = Error Time + f(DB_SIZE)

0

20

40

60


Flashback Database

Oracle Database独自のロギング・メカニズムを採用（Flashback Log）

– データ更新時、自動的に更新前ブロック･イメージを高速リカバリ領域に保存

Flashback Log（更新前ブロック・イメージ）でDB全体の復旧を実現

– リストア/リカバリ不要、Export/Import処理よりも高速

Flashback Databaseでリカバリ可能なオペレーション

– DML処理（INSERT、DELETE、UPDATE）

– TRUNCATE

– スキーマ・ユーザーの削除（DROP USER）

データベース全体を指定された過去の時点の状態へ


Flashback Database

Flashback Logの取得を有効化（選択可能）

– Flashback LogモードをON

SQL> ALTER DATABASE FLASHBACK ON;

– 保証付きリストア・ポイントを作成

SQL> CREATE RESTORE POINT <GRPName>

GUARANTEE FLASHBACK DATABASE;

その他の設定

– Archive Logモード

– 高速リカバリ領域（DB_RECOVERY_FILE_DEST / DB_RECOVERY_FILE_DEST_SIZE）

– Flashback Log保持期間（DB_FLASHBACK_RETENTION_TARGET）

有効化の設定

保証付きリストア・ポイントは、

復旧可能な時点をGRP作成時点に限定し、Flashback Logの生成量を大幅に抑制可能


Flashback Database

1. MOUNTモードで起動（OPEN状態では実行不可）

2. Flashback Databaseの実行

SQL> FLASHBACK DATABASE TO <?>;

3. 読み取り専用でOPENして、データ確認

SQL> alter database open READ ONLY;

4. RESETLOGSでOPEN

SQL> shutdown immediate;

SQL> startup MOUNT;

SQL> alter database open RESETLOGS;

復旧の実行例

KROWN#128066

SCN指定 SCN 100

現時点から1時間前指定

TIMESTAMP(SYSDATE – 1/24)

絶対日時指定

TIMESTAMP(TO_TIMESTAMP(

'2012/11/20 12:00:00',

'YYYY/MM/DD HH24:MI:SS')

リストア・ポイント指定

RESTORE POINT <RPName>


Flashback Database

Flashback Loggingの有り無しで、

全件update処理時間が増加する傾向

– UNDOの物理読み込みがボトルネック

UNDO表領域をSSD上に配置することで、高速化を実現

Flashback LogではUNDOの更新前ブロッ

クも保持する必要がある為、通常時には発生しないUNDOの物理読込みが追加される

Flashback Loggingのオーバーヘッドとチューニング

【White Paper】進化したバックアップ／リカバリを実現するFlashback Database活用のベストプラクティス

http://www.oracle.com/jp/gridcenter/partner/nssol/wp-fbdb-gridcent-nssol-v2-484389-ja.pdf


Oracle Database が提供する高可用性ソリューション（MAA）は可用性を高めるだけでは留まらず、性能および管理性の向上も実現します。






Oracle Enterprise Manager Cloud Control 12c


Oracle Database 11g: バックアップ・リカバリ Database

お申込み・お問合せ http://www.oracle.com/jp/education オラクルユニバーシティ Tel: ０１２０-１５５-０９２

定価￥２１８，２９５（税込） ※Oracle PartnerNetwork会員様は、パートナー割引価格で受講いただけます。

・ Oracle Database 11g: 管理クイックスタートを受講済みあるいは同等の知識のある方前提条件

コース日程

３日間

・データベース管理者（システム構築、運用管理、保守などに携わるエンジニア、アナリスト）対象者

■Recovery Manager（RMAN）およびEnterprise Managerの使用

■リカバリ可能性の構成

■RMANリカバリ・カタログの使用

■バックアップの概要および計画

■バックアップの作成

コース

内容

RMANによるOracle Database 11g バックアップ・リカバリを集中的に学習！

このコースを終えると、リカバリ要件の評価、バックアップおよびリカバリ手順の適切な計画の立案ができるようになります。このコースで

は、「Oracle Database 11g: 管理ワークショップⅠ」コースおよび「Oracle Database 11g: 管理ワークショップⅡ」コースで説明されてい

るバックアップおよびリカバリ手法を確認し、バックアップ、障害、リストアおよびリカバリの様々なシナリオについて学習します。バックア

ップおよびリカバリ操作にRecovery Manager（RMAN）およびEnterprise Managerを使用するため、受講者は、RMANおよび

Enterprise Managerについての一般的な知識を持っていることを前提としています。様々なエラーからのリカバリするその他の方法とし

て、フラッシュバック機能についても学習します。

■データ・リカバリ・アドバイザの使用

■リカバリの実行

■フラッシュバック・テクノロジの使用

■RMANパフォーマンスおよびチューニング

【会場：トレーニングキャンパス青山】 ■2012年11月26日(月)～28日(水) ■2013年1月22日(火)～24日(木)

【品川インターシティ会場】 ■2013年3月26日(火)～28日(木)

【銀座会場】 ■2012年12月22日(土)～24日(月) ※土日祝日含む ■2013年2月12日(火)～14日(木) ■2013年3月18日(月)～20日(水)

受講料



Documents

1 Copyright © 2012, Oracle and/or its affiliates. All ...otndnld.oracle.co.jp/ondemand/ddd/PDF/MA-4_print_c.pdf · 高可用性テクノロジーと成功事例に基づいたベスト・プラクティス