Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
第44回瀬戸内オラクル技術団 ~止まらないデータベースを構築するポイントのすべてを教えます~
日本オラクル株式会社
クラウド・テクノロジー事業統括データベースソリューション本部 中部・西日本ソリューション部 2016年2月23日
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
•以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
2
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Program Agenda
Oracle Maximum Availability Architecture
Oracle Real Application Clusters
Oracle Automatic Storage Management
Oracle Data Guard
Recovery Manager
Flashback Database
1
2
3
4
5
3
6
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Oracle Maximum Availability Architecture
4
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
ITインフラに求められる主な要件
1. パフォーマンス(拡張性)
2. 管理性(運用容易性)
3. 高可用性
4. セキュリティ
• いくら高性能で拡張性が高くても、 足回りがガッチリ(高可用性)していなければ、宝の持ち腐れになりかねない
5
データベース・クラウド環境であっても普遍
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
計画”外”停止の主な要因 2012 IOUG Database Availability Survey アンケート結果より
6
主な理由 •#2 人的エラー(45%) •#3 サーバー障害(45%) •#4 ストレージ障害(42%) •#5 アプリケーション・エラー(31%)
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle Maximum Availability Architecture http://www.oracle.com/technetwork/jp/content/maa-094615-ja.html
• Oracle Maximum Availability Architecture (MAA) とは、 Oracle 開発チームの実証済み高可用性テクノロジと、お客様の成功事例に基づいたOracleのベスト・プラクティスのブループリント
–アーキテクチャやベストプラクティス、顧客事例、デモなど詳細情報をWebサイトにて掲載
• MAAの目的
–最適な高可用性アーキテクチャの設計から複雑な仕組みを排除すること • ハードウェアやOSの影響を受けない
• サーバーとストレージのコスト削減に利用できる
• Oracle の新バージョンや新機能に適応できる
–計画停止を極小化し、計画外停止を回避、検出および修復するためのベスト・プラクティスを提供
7
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle Maximum Availability Architecture
8
Edition-based Redefinition, Online Redefinition, Data Guard, GoldenGate – Minimal downtime maintenance, upgrades, migrations
Active Data Guard – Data Protection, DR – Query Offload
GoldenGate – Active-active replication – Heterogeneous
Active Replica
RMAN, Oracle Secure Backup, Zero Data Loss Recovery Appliance – Backup to disk, tape or cloud
Enterprise Manager Cloud Control – Site Guard, Coordinated Site Failover
Application Continuity – Application HA
Global Data Services – Service Failover / Load Balancing
RAC – Scalability – Server HA
ASM – Local storage
protection
Production Site
Flashback – Human error
correction Application Test Suite, Real Application Testing – Minimal Testing Costs
Advanced Security – Data encryption,
protection
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAAの高可用性機能
9
ストレージ障害
人的エラー
データ破損
サイト障害
システム障害
データ障害
計画外停止
システム変更
データ 変更 計画的停止
Real Application Clusters
Automatic Storage Management Flashback Technology
Recovery Manager H.A.R.D
Active Data Guard GoldenGate
Online Reconfiguration Rolling Upgrades
Online Redefinition
アプリ 変更
Data Guard
Online Application Upgrade Edition-based Redefinition
Oracle M
AA
Best P
ractices
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
可用性の担保・運用負荷軽減・コスト適正化の考え方 • 可用性の担保・運用負荷・コスト適正化には密接に関係があり、障害発生時のリスクと損失、対応にかかる運用負荷や コストを十分に吟味した上で適正なバランスをとる事が大切です。
1.リスクと損失
– 業務上の機会損失リスク
– 意志決定の遅延リスク
– 業務担当者の作業コストの損失
• たとえば初期コストを抑える為十分なシステム投資を行わない場合、トータルコストがかえって大きくなってしまう事例も多々あります。
10
十分な可用性担保を システム側で対応しない
障害発生時負荷増大
業務停止による損失大
人的対応コストの増大
業務リカバリコスト増大
障害対策の為の改修 トータルコスト増大
初期導入コスト削減
システム運用人件費増大
•業務運用人件費増大 •業務対応コスト増剤 •業務停止による損失
システム改定コスト(2重投資)
初期投資を抑えた例
障害
2.運用負荷
•利用者側(業務遂行側)の負荷
(システム担当者との調整)
•システム担当者の負荷
3.障害対応コストの増加
•業務担当者の障害対応コスト
(システム側含めた調整作業)
•システム担当者の作業コスト
•障害対策コスト
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
サービスレベルの定義検討 リファレンスアーキテクチャ: IPA高回復力システム基盤導入ガイド
11
IPAモデルシステム BRONZE SILVER GOLD PLATINUM
モデル システム
の 特徴
①システム基盤の強度 低 中 高 高
②復旧時間 障害時 1-3日 2時間以内 2時間以内 2時間以内
災害時 1-6ヶ月 1-6ヶ月 1-7日 2時間以内
③投資規模 低 中 高 高
モデル システム
の 主要要件
①バックアップ方式、取得間隔 非同期 月次
非同期 週次
非同期 数回/日
同期 数回/時
②機器などの冗長化 なし あり あり あり
③バックアップサイト なし なし あり あり(ホットスタンバイ)
出典: 事業継続のための高回復力システム基盤導入ガイド 概要編
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAA: サービス・レベル区分 本セッションでご紹介する機能のマッピング
12
GOLD 包括的な高可用性と災害からの保護 データロス:ゼロもしくはほぼゼロ
SILVER ローカルサイト障害に対する高可用性 データロス: 最新バックアップ時点まで保護
BRONZE シングル・インスタンス、基本的なサービス再起動 データロス: 最新バックアップ時点まで保護
PLATINUM 重要アプリケーションに対して無停止 データロス:ゼロ
RAC Data Guard GoldenGate
ASM RMAN Flashback
✔ ✔ ✔ ✔ ✔
✔ ✔ ✔ ✔ ✔
✔ RAC
One Node ✔ ✔ ✔
✔ ✔ ✔
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAA: サービス・レベル区分例 計画外停止及び計画停止に対するサービス・レベル
13
停止クラス 高可用性層 計画外停止(ローカル・サイト) 計画メンテナンス データ保護
リカバリ不能なローカル停止および障害時リカバリ
Platinum Platinum対応アプリケーションでは アプリケーションの停止なし
アプリケーションの停止なし 包括的なランタイム検証と 手動チェックの組合せ
Platinum対応アプリケーションではアプリケーションの停止なし、処理中のトランザクションを維持、データ損失ゼロ
Gold 包括的な高可用性と 障害時リカバリ
すべてがローリングまたは オンライン
包括的なランタイム検証と 手動チェックの組合せ
リアルタイム・フェイルオーバー、ゼロまたはゼロに近いデータ損失
Silver 自動フェイルオーバーを含む 高可用性
一部ローリング、 一部オンライン、 一部オフライン
基本的なランタイム検証と 手動チェックの組合せ
バックアップからのリストア、最後のバックアップ以降に生成されたデータを失う可能性
Bronze 単一インスタンス、リカバリ可能な インスタンスおよびサーバー障害での 自動再起動
一部オンライン、 大部分オフライン
基本的なランタイム検証と 手動チェックの組合せ
バックアップからのリストア、最後のバックアップ以降に生成されたデータを失う可能性
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Oracle Real Application Clusters
14
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAAの高可用性機能
15
ストレージ障害
人的エラー
データ破損
サイト障害
システム障害
データ障害
計画外停止
システム変更
データ 変更 計画的停止
Real Application Clusters
Automatic Storage Management Flashback Technology
Recovery Manager H.A.R.D
Active Data Guard GoldenGate
Online Reconfiguration Rolling Upgrades
Online Redefinition
アプリ 変更
Data Guard
Online Application Upgrade Edition-based Redefinition
Oracle M
AA
Best P
ractices
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle Real Application Clusters (RAC) Oracle9i より提供されているクラスタ技術
•複数ノードで構成する共有ディスク/共有キャッシュ型のデータベース –全ノードが全データに直接アクセス可能
– Cache Fusion Technologyで、キャッシュ・データの一貫性を維持
•主な特徴
16
可用性 高速なフェイルオーバーを実現し、システム障害時のダウンタイムを最小化
拡張性 負荷の増減に応じた処理性能の最適化が可能
投資コスト 最低限必要な構成で導入でき、初期コストを抑えることが可能
リソースの有効活用により 最適な投資コストを実現
Enterprise Edition Real Application Option
Or Standard Edition
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
RAC による高可用性の実現 高速なフェイルオーバー
•障害が発生した場合、リカバリや切り替えを高速に実施
RAC HA構成
Active Standby
待機サーバー 稼働 サーバー
平常時には起動している
のみ
Active Active Active
データベース再起動
ディスクの切り替え
処理の高速な フェイルオーバー
数分~数十分 数十秒~数分
17
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
RAC による高拡張性の実現 サーバー追加によるスケーラビリティの向上
•必要に応じてサーバを追加し、処理能力の拡張が可能
入れかえ 買いたし
必要に応じて追加
処理能力の増減に応じて H/W をリプレイス
待機サーバー 稼働 サーバー
RAC HA構成 18
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
RAC による最適な投資コストの実現
•必要に応じてサーバ追加による性能拡張が可能なため導入時は最小限の構成でシステム構築が可能
•全サーバーで処理を行うので待機用途のサーバは不要
• システム統合でリソースを共有化し、遊休リソースをなくしサーバを集約 集約することで運用管理も簡易化されコストも削減可能
19
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle Real Application Clustersの高可用性 サーバー障害時の継続稼働に必要な機能
20
2. 自身の健全性を維持
• Oracle Clusterware 関連プロセスの監視
• RAC データベース 関連プロセスの監視
3. 正常サーバーへの接続
• サービス名を用いたRAC データベースへの接続
• 接続時のフェイルオーバーと仮想IPアドレス
1. 障害サーバーの切り離し
• クラスタ・ノード・メンバーシップ管理
• インスタンス・リカバリ
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle Real Application Clusters 必要なH/W & S/W構成図
21
パブリック・ネットワーク
クライアントとの通信を行う ネットワーク
インターコネクト・ネットワーク
ノード間通信を行うネットワーク
共有ストレージ
データベース・ファイルを配置する全ノードからアクセス可能なストレージ
ノード
RACを構成する データベース・サーバー
Oracle Clusterware
Oracle Database
Oracle Automatic Storage Management
Database
Grid Infrastructure
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
クラスタ・ノードのメンバーシップ管理 Cluster Synchronization Services (CSS) によるクラスタノードの異常検知
•各ノードの CSS がクラスタ・ノード構成の一貫性に責任を持つ –相互に生存監視を実施し、異常ノードを切り離す
• CSSは2種類のハートビートをしている –ネットワーク・ハートビート(1秒毎)
• 死活監視のため
• misscount (30sec) 間ハートビートが ない場合はメンバーシップの変更
–ディスク・ハートビート • スプリットブレイン解決時のため
22
IP
CSS CSS CSS
IP IP
投票ディスク
Node#1 Node#2 Node#3
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
インスタンス・ダウン時のデータ・ブロックの自動リカバリ Oracle Real Application Clusters
•障害が発生したインスタンスのキャッシュ上にしか存在しなかったデータ・ブロックは、生存する他インスタンスが自動的にリカバリを実施 –正常インスタンスが障害インスタンスのREDOログを読み込み自動リカバリ
• 障害インスタンスの再起動を待つ必要はない
23
Active Active Active Down
REDO DATA REDO REDO
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle Real Application Clusters 可用性を維持するために行っている監視
24
Oracle Clusterware Oracle Clusterware Oracle Clusterware
ASM Instance ASM Instance ASM Instance
Database Instance Database Instance Database Instance
2. インスタンス・ メンバーシップの監視
4.インスタンス内での
相互監視
5.Oracle Clusterware
によるリソースの監視
1.クラスタノード・ メンバーシップの監視
3.Oracle Clusterware
内での相互監視
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
クラスタ・データベースへの接続に求められること アプリケーション・レイヤー視点
• クラスタとしての整合性を取ったり、ノード内の健全性を維持する動作をしていても、アプリケーションから正常なサーバーに接続できなければシステムとして動作しない
•接続に求められること 1. インスタンスを意識せずに接続ができること
2. 接続リクエストが正常なノードに割り振られる
3. 障害ノードに対する無効な接続は破棄されること
25
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
サービスを使用してクライアントから接続
• Oracle クライアントは 「サービス」に対して接続します
–Oracle クライアントは RAC のノード数やインスタンス名は知りません
26
クライアントは「SERVICE_NAME」 を指定して接続する
(DESCRIPTION = (ADDRESS=(PROTOCOL=TCP) (HOST=scanname) (PORT = port ) ) (CONNECT_DATA= (SERVICE_NAME=SERVICE_A ) ) )
接続するサービス名と SCANリスナーが稼動している アドレス情報 ( スキャン名、port 番号等 ) を記述
SERVICE_A
SERVICE_B
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
(DESCRIPTION =
(ADDRESS =
(PROTOCOL=TCP)(HOST=scanname)(PORT=port))
(CONNECT_DATA =
(SERVICE_NAME = serviceA )))
RACの接続の仕組み(11gR2~)
DNS サーバ SCAN名の名前解決 (scanname)
クライアント
接続
リスナー1 リスナー2 リスナー3
SCAN
リスナー3 SCAN
リスナー2
SCAN
リスナー1
SCAN名: scanname SCAN VIP1: XX.XX.XX.101 SCAN VIP2: XX.XX.XX.102 SCAN VIP3: XX.XX.XX.103
serviceA
serviceB
SCAN VIP (3,1,2)
• SCAN名 • ポート番号 • サービス名
リダイレクト先の指示
SCAN VIP1
SCAN VIP3
SCAN VIP2
VIP1 VIP3 VIP2
Node#1 Node#2 Node#3
27
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle Real Application Clustersの高可用性 サーバー障害時の継続稼働に必要な機能
28
2. 自身の健全性を維持
• Oracle Clusterware 関連プロセスの監視
• RAC データベース 関連プロセスの監視
3. 正常サーバーへの接続
• サービス名を用いたRAC データベースへの接続
• 接続時のフェイルオーバーと仮想IPアドレス
1. 障害サーバーの切り離し
• クラスタ・ノード・メンバーシップ管理
• インスタンス・リカバリ
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Oracle Automatic Storage Management
29
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAAの高可用性機能
30
ストレージ障害
人的エラー
データ破損
サイト障害
システム障害
データ障害
計画外停止
システム変更
データ 変更 計画的停止
Real Application Clusters
Automatic Storage Management Flashback Technology
Recovery Manager H.A.R.D
Active Data Guard GoldenGate
Online Reconfiguration Rolling Upgrades
Online Redefinition
アプリ 変更
Data Guard
Online Application Upgrade Edition-based Redefinition
Oracle M
AA
Best P
ractices
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
従来のRAWデバイス構成例
31
目的はストライピングによるI/O性能の向上、 しかし、管理性は?
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
従来のRAWデバイス構成の課題 運用の複雑化
•表領域が非常に細かく分割されている –空き領域が表領域毎に独立している為、無駄な空き領域が増大
–監視対象(表領域)が多く、頻繁に領域不足に陥り、運用工数が増大
–データ・ファイル数が多く、SQLの性能劣化やミス・オペレーションを誘発
–管理レイヤー数が多い為、運用オペレーションの複雑化
• データ・ファイル追加時に、既存データをリバランスしていない –空き領域が新規ボリュームにのみ存在する為、新たにINSERTされるレコードがそのボリュームに集中することで、ボトルネックが発生し易い
–既存レコードは既存ボリューム内に格納されている為、性能改善効果は無し
32
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
データベース・ストレージ管理の課題
•領域不足/性能劣化の改善の為、ディスク追加
• ホットスポット回避のためには既存データの再配置が必要
33
ディスク追加時の課題
ディスクは3本あるが、最新データが入っている1本のみにアクセスが集中
ホットスポットが発生
ディスクを追加し RAIDグループを再構成
データ再配置 全ディスクに対してI/O
unload load
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
データベース・ストレージ管理の課題 複雑なディスク管理
•業務の複雑化により、従来の個別最適化を目指す運用は困難な傾向 –必要なディスク性能を事前見積もり? 偏りの最適化?
34
総容量 実使用量
?
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle によるストレージ仮想化 Oracle Automatic Storage Management(ASM)
• Oracle Database 10g より提供されている、 ディスク構成の仮想化技術 – Oracleデータベースに対してボリューム・マネージャ 兼ファイルシステム • Oracle Databaseにフラットなディスク・プールを提供
+ ディスク管理工数を大幅削減
• 複数ディスク・アレイにまたがってディスクを仮想化、 ディスク追加/削除時にデータを透過的に再配分
–エディション(EE/SE)に関係なく、シングル環境、 クラスタ環境共に使用可
– 11g Release2より、ASMクラスタファイルシステムが実装
35
Enterprise Edition Or Standard Edition
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle ASMの構成例 Simple is the BEST
36
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle ASMによるストライピング ASM File(データファイル)の分散配置例
• ASM Diskgroupに含まれる全てのASM Diskに対して、 ASM File(Data File)をFile Extent(Allocation Unit:=AU)単位に分割して配置
37
ASM Diskgroup
1 2 3 4
1 2 3 4
Disk Disk Disk Disk
5 6 7 8
5 6 7 8
ASM File(Data File)
File Extent (AU)
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle ASMによるミラーリング Normal Redundancy時のミラーリングと障害グループ例
•異なる障害グループに属するASM Disk間で保持
•通常、リソース(電源等)を共有している単位(筐体/コントローラー)で設定
38
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
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle ASMによるミラーリング Oracle Clientに透過的、かつ自動的にBlockを修復
• ASM Diskgroupに、ミラーリング(External/Normal/High)の設定が可能 – Normal / High Redundancy時
• 読み取り処理時に I/Oエラーを検知した場合
–セカンダリから読み取り、不良ブロックは自動修復
– Oracle Clientに対して透過的(ORAエラーは戻らない)
• 書き込み処理時に I/Oエラーを検知した場合
– Oracle Clientに対して透過的(ORAエラーは戻らない)
–障害Diskを自動でオフライン化
–障害Diskの復旧時、高速ミラー再同期により生存Disk側から必要最小限の差分データを同期
–復旧できない場合、ASM Diskgroupから切り離し(自動リバランスが発生)
39
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle ASMのリバランス(データ再配置) データベース無停止でリバランスが可能
• ASM Diskを追加/削除(故障)した際、データの再配置を実施 –メタデータ(配置状況)を元に、ASM File単位で全てのDiskに均等配置されるように 最小限のExtent(AU)の移動で実現
–多重度(リバランス強度)の設定や計画実行で、業務影響を制御可能
40
- + REBALANCE
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
ASMによる全体最適化機能
• ストライピング –ディスク・グループ内の、全てのディスクで ストライピング(ホットスポットが発生しない)
–性能の維持
• ミラーリング –ファイルタイプに応じて、Oracle レベルで ミラーリング(2重化/3重化/ミラー無し)
–可用性の担保
•動的リバランシング –ディスクの追加/削除時に自動的にデータを再配置
–拡張性
41
1 2 3 1’ 2’
1’ 2’ 3’´ 4’
Add
Drop
1 2 3 4 1’ 2’ 3’ 4’
2 1 4 3
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle ASMによる運用管理の簡素化 従来構成の課題を解決
• オペレーションの簡素化 –表領域拡張やDisk追加の手順が簡素化し、運用オペミスのリスクが減少
•管理対象オブジェクトの削減 – ASM Diskgroupの容量内で表領域を自由に拡張可能であり、従来のVolumeやRAWデバイス(データファイル)を意識する必要なし
–ストライピングでI/Oが均等化することで、表領域を細かく分割してI/O競合を回避する必要なし。表領域の総数を大幅に削減可能
• データ再配置の工数不要 – Disk追加時に自動的に既存データの再配置(リバランシング)を実施
42
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Oracle Data Guard / Active Data Guard
43
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAAの高可用性機能
44
ストレージ障害
人的エラー
データ破損
サイト障害
システム障害
データ障害
計画外停止
システム変更
データ 変更 計画的停止
Real Application Clusters
Automatic Storage Management Flashback Technology
Recovery Manager H.A.R.D
Active Data Guard GoldenGate
Online Reconfiguration Rolling Upgrades
Online Redefinition
アプリ 変更
Data Guard
Online Application Upgrade Edition-based Redefinition
Oracle M
AA
Best P
ractices
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
リアルタイム・データベース複製 • 本番データベースのコピーを作成し、データを保護
• 災害対策/データ保護、移行/パッチの適用/アップグレードなどに利用可能
• スタンバイ・データベースのリソースを活用し、本番データベースの負荷を軽減
Data Guard / Active Data Guard
DB ログを転送
REDOログ 適用
REDOログ情報を 自動的に転送
本番データベース スタンバイ・データベース
データ誤差無し
高速なデータ同期、ネットワーク帯域小
トランザクションの順次性保障 DRサイトの利活用
45
Enterprise Edition Active Data Guard Option
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Data Guard アーキテクチャ
46
データファイル オンライン REDOログ
REDO転送
ログバッファまたはオンラインREDOログ
からREDOを転送、スタンバイ側で受信
ログ
バッファ
ログ
バッファ
LGWR
NSS/NSA RFS
アーカイブログ データファイル スタンバイ REDOログ
REDO適用
リカバリの仕組みで
REDOを逐次適用
MRP
サーバー プロセス
アーカイブログ
プライマリ スタンバイ
データファイルはデータ・ブロックレベルで等しいが、
データファイルをコピーしているわけではない
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
ストレージのリモートミラーと Data Guard
47
データファイル
オンライン REDOログ
アーカイブログ
ストレージの
リモートミラー
D
ata
Gu
ard
制御ファイル
データファイル
スタンバイ REDOログ
アーカイブログ
制御ファイル
データファイル
オンライン REDOログ
アーカイブログ
制御ファイル
データファイル
オンライン REDOログ
アーカイブログ
制御ファイル
MRP
広帯域な
ネットワーク回線が必要
REDOのみ転送
プライマリのデータ破損がそのままスタンバイに反映される
プライマリのデータ破損はスタンバイに反映されない
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Automatic Block Media Recovery Active Data Guardによる透過的なBlock修復(逆向きも有効)
48
②Block破損の検知
④正常Blockを自動転送
③スタンバイに正常Blockを要求
⑤自動的にリカバリ (Redo適用でBlockを最新化)
①SQL発行
⑥エラーなく 検索結果が戻る
alert SQL> SELECT max(c1) FROM tab1;
MAX(C1) ----------------- 5000
Requesting Auto BMR for (file# n, block# m)
×
Primary Database Standby Database
Enterprise Edition Active Data Guard Option
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
同期転送と非同期転送 アーキテクチャ
49
ログ バッファ
ログ バッファ
NSS RFS
データファイル スタンバイ REDOログ
SQL> COMMIT;
① ②
③ ④
サーバー プロセス
データファイル オンライン REDOログ
①
②
ログ バッファ
ログ バッファ
NSA RFS
データファイル スタンバイ REDOログ
SQL> COMMIT;
① ㋐
㋑ ③
サーバー プロセス
データファイル オンライン REDOログ
①
②
同期転送
非同期転送
LGWR
LGWR
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
同期転送と非同期転送 データ保護の要件と性能要件の選択
•同期転送と非同期転送の切替はオンラインで変更可能
50
同期転送 非同期転送
メリット ゼロ・データロスを実現可能 性能への影響がほぼない
デメリット 性能への影響を検討する必要がある データロスに関する検討が必要
• アプリケーション特性(REDO生成量)
• ネットワーク帯域、遅延
• スタンバイREDOログファイルのI/O性能
• プライマリがmountできれば 全てのRedoを転送出来る為、 データロスは回避可能
• トランザクション再実行
※ データロス: 未転送のままプライマリに残った REDOをスタンバイに適用できない
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
ゼロ・データロスのData Guardの切替操作
• スイッチオーバー –計画停止用途
–データロスなしを保証
• フェイルオーバー –計画外停止用途
–同期転送ならデータロスなし
–非同期転送ならデータロストあり (未転送データ分)
51
昇格
降格
昇格
どちらも、サーバー / OS / ストレージ構成に依存しない手順
SQL、またはOracle Enterprise Managerの1クリックで実行可能
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Data Guardのスイッチ・オーバーの活用 ローリング・アップグレード
•計画停止時間を極小化して、パッチ適用やアップグレードの実施が可能
52
1
A B
ノードBを停止 ノードBをアップグレード
Upgrade
ノードBを再起動し、 ABへ再同期後にスイッチ
A B
Upgrade済
2
ノードAを停止 ノードAをアップグレード
Upgrade
A B
Upgrade済
3
ノードAを再起動し、 BAへ同期再開
A B
Upgrade済 Upgrade済
4
NEW
P P
※必要に応じて、スイッチ・オーバー
P
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Public Cloudにも対応
• オンプレミスのデータベースをクラウド環境で保護 – Primary:オンプレミス => Standby: クラウド
– Data Guard or Active Data Guard を利用
–現時点(2016年1月)では、手動構成 (将来的に自動化を予定)
• MAA 構成として – MAA 及び Cloud Team により検証済み
– MAA 技術ホワイトペーパーとして構成手順を発行済み • http://www.oracle.com/technetwork/database/availability/dr-to-oracle-cloud-2615770.pdf
53
オンプレミス to クラウド
(Active) Data Guard
On-Premises Primary Database
Oracle Cloud Standby Database
Sandbox Test/Dev in the cloud
Reporting
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Recovery Manager
54
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAAの高可用性機能
55
ストレージ障害
人的エラー
データ破損
サイト障害
システム障害
データ障害
計画外停止
システム変更
データ 変更 計画的停止
Real Application Clusters
Automatic Storage Management Flashback Technology
Recovery Manager H.A.R.D
Active Data Guard GoldenGate
Online Reconfiguration Rolling Upgrades
Online Redefinition
アプリ 変更
Data Guard
Online Application Upgrade Edition-based Redefinition
Oracle M
AA
Best P
ractices
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
ほとんどのお客様がリストア/リカバリに失敗している
•失敗原因の上位は、 “ユーザー・エラー”、“バックアップの破損”、“Hardware/SoftwareのBug”
56
出典: Oralce Database and Data Protection Survey by Unisphere Research
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Recovery Manager (RMAN) の概要 Oracle Database のバックアップ・リカバリ専用ツール
• データベースのバックアップ、リストア、リカバリ、バックアップ・ファイルの管理を行うためのクライアント・ユーティリティ
•実行方法は2種類
– OS プロンプトからRMANを起動しコマンドラインで実行
– Oracle Enterprise Manager Cloud Controlを使用して実行
•代表的なバックアップ対象ファイル
–制御ファイル
–データファイル
–アーカイブ REDO ログ・ファイル
–サーバー・パラメータファイル
$ rman target /
RMAN> backup database;
RMAN> restore database;
RMAN> recover database;
Enterprise Edition Or Standard Edition
57
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
RMAN の構成 RMAN でターゲットデータベースに接続してバックアップ・リカバリを実施する
RMAN
ターゲット・データベース
制御ファイル アーカイブREDOログ・フ
ァイル
データファイル
RMAN情報
サーバー・ プロセス
カタログ・データベース
RMAN情報 同期 テープ・ライブラリ
メディア・マネージャ or Oracle Secure Backup
バックアップ先ディスク
RMANの管理情報はCONTROL_FILE_RECORD_KEEP_TIME
初期化パラメータに指定した日数期間、制御ファイルに保持される。
RMAN 情報をカタログ・データベース
に格納すれば、長期のバックアップ履歴や、多くのターゲット・データベースのRMAN情報を管理可能。
58
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
D2D Backup vs. Oracle Recovery Manager 12c
59
Disk to Disk RMAN
バックアップの全損リスク × 全損リスク有り ◎ 高速増分バックアップで回避
バックアップの 性能と負荷
消費リソース ◎ ストレージのリソースのみ △ サーバーのリソースを使用
総I/O量 ○ セクタ単位での差分のみ ○ ブロック単位での差分のみ
保持データ総量 △ 正volumeと同等のサイズ ○ 圧縮/削減が可能
Redo生成量 × バックアップ中は増加する ◎ 通常時と同等
管理性 × 手動管理で煩雑な傾向 ○ 世代管理の自動化
汎用性 △ ストレージベンダー依存 ○ H/W構成から独立
破損ブロック対策 × 正常or破損の区別も不可 ◎ バックアップ時に検知+修復
ASMリバランスの影響 × 差分データ量が大幅に増加 ◎ 影響なし
バックアップの暗号化 × 正volumeのコピーなので不可 ○ 暗号化可能
価格 × 数千万~数億か(製品依存) ○ EE標準機能
リストア&リカバリ 柔軟性 △ 最小でもLU単位 ◎ ブロック単位、表単位まで可能
管理性 × DBAのスキルに依存 ○ アドバイザで自動判別
* 12c
* 12c
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
副volume
正volume
D2D(Disk to Disk)バックアップ
バックアップ前提 運用フェーズ(バックアップ運用)
Clone LUs
Bitmap
DML
dbwr
Source LUs
全体同期 +
切り離し
Bkup開始 Bkup完了
Bkup Window
Bitmap
バックグラウンドで 差分同期 Bitmap比較
60
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
+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)
Enterprise Edition
61
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
副volume
正volume
D2D(Disk to Disk)バックアップ 同期中の障害発生時にリカバリ不可
バックアップ前提 運用フェーズ(バックアップ運用)
Clone LUs
Bitmap
DML
dbwr
Source LUs
全体同期 +
切り離し
Bkup開始
Bitmap
Bitmap比較
障害発生
最後まで同期されない = バックアップが 完成していない
= リストア&リカバリ不可
62
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
破損ブロック対策
• バックアップ時にブロック破損を認識不可。ブロック破損を含むイメージをバックアップとして取得
– リストア&リカバリのタイミングでブロック破損に気付き、リカバリ不可に陥る可能性有り
–例えば、毎日バックアップを取得 + 2世代保持していたとしても、実際には一週間前にブロックが破損してた場合には修復に必要なバックアップは既に存在していない。
確実にリカバリ可能なバックアップか?
• ブロック構造を理解できる為、バックアップ時にブロック破損を検知可能
–確実にリストア&リカバリ可能なバックアップを取得可能
• 参考情報 – KROWN#127924:RMANを使ってバックアップを取得する際に破損ブロックが検知された場合の対処方法について
– KROWN#68810:ORA-1578の主な発生原因とその対処方法について
D2D:× RMAN:◎
63
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
バックアップの性能と負荷
• 前回の同期時点から正volumeで更新されたセクタのみを副volumeへ再同期
–読込量、書込み量ともに差分のみに制限することが可能
総I/O量
• 増分バックアップにより、前回バックアップからの更新ブロックのみを書き込む
• Block Change Tracking File(以降、BCT)を使用した高速増分バックアップにより、バックアップ元からの読み込みを大幅に削減することが可能
– 10g以降利用可能。BCTを使用しない場合、書込量は差分のみだが、読込量は全データとなる。
D2D:○ RMAN:○
64
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
管理性
• リカバリ時に必要となるデータ・ファイル以外のファイルのバックアップ方法の正確な理解が必要
– アーカイブ・ログや制御ファイルは、データ・ファイルのバックアップとは別にバックアップが必要
– さらに、それらのファイルを世代管理(保持or削除)する仕組みの設計/実装/運用が必須
–煩雑となりミスオペを誘発
データ・ファイル以外のバックアップ関連ファイル
• アーカイブや制御ファイルも含めて必要なバックアップの世代管理を自動化できる
– RMANによるデータ・ファイルのバックアップと同時に、それらのファイルも自動的にバックアップすることが可能
–保持/削除ポリシーの設定で、ミスオペの発生を防止可能
D2D:× RMAN:○
65
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
リストア&リカバリの柔軟性
• ブロック破損レベルの軽微な論理障害でも、そのブロックを含むLU全体のリストアを行い、広い範囲でリカバリが必要となる
– この範囲を小さくすることを検討し始めると、ASM Diskgroupの細分化の検討が必要となり、結果的には設計/運用の複雑化を生じさせる傾向有り
障害範囲に応じた最適な単位でのリストア&リカバリ
• 特定のブロック単位、表単位、データファイル単位、データベース全体のように、最適な単位を提供
D2D:△ RMAN:◎
66
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
RMANのバックアップ・リカバリ手順 ブロック単位のリカバリ(RECOVER … BLOCK)
• データ・ブロックの障害箇所の特定
• ブロック・メディア・リカバリの実行
– v$database_block_corruption に記録されているすべてのブロックをリカバリ
67
RMAN> RECOVER DATAFILE 6 BLOCK 108;
% sqlplus / as sysdba
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
------ -------- ------- ------------------ ---------
6 108 1 0 CHECKSUM
RMAN> RECOVER CORRUPTION LIST;
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
バックアップの性能と負荷
• ストレージのCPU、I/Oリソースのみを使用
消費リソース
• データベース・サーバーのCPU、I/O帯域を使用
• 回避策
– スタンバイでバックアップ、Resource Managerで制御
D2D:◎ RMAN:△
68
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
D2D Backup vs. Oracle Recovery Manager 12c
69
Disk to Disk RMAN
バックアップの全損リスク × 全損リスク有り ◎ 高速増分バックアップで回避
バックアップの 性能と負荷
消費リソース ◎ ストレージのリソースのみ △ サーバーのリソースを使用
総I/O量 ○ セクタ単位での差分のみ ○ ブロック単位での差分のみ
保持データ総量 △ 正volumeと同等のサイズ ○ 圧縮/削減が可能
Redo生成量 × バックアップ中は増加する ◎ 通常時と同等
管理性 × 手動管理で煩雑な傾向 ○ 世代管理の自動化
汎用性 △ ストレージベンダー依存 ○ H/W構成から独立
破損ブロック対策 × 正常or破損の区別も不可 ◎ バックアップ時に検知+修復
ASMリバランスの影響 × 差分データ量が大幅に増加 ◎ 影響なし
バックアップの暗号化 × 正volumeのコピーなので不可 ○ 暗号化可能
価格 × 数千万~数億か(製品依存) ○ EE標準機能
リストア&リカバリ 柔軟性 △ 最小でもLU単位 ◎ ブロック単位、表単位まで可能
管理性 × DBAのスキルに依存 ○ アドバイザで自動判別
* 12c
* 12c
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Flashback Database
70
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAAの高可用性機能
71
ストレージ障害
人的エラー
データ破損
サイト障害
システム障害
データ障害
計画外停止
システム変更
データ 変更 計画的停止
Real Application Clusters
Automatic Storage Management Flashback Technology
Recovery Manager H.A.R.D
Active Data Guard GoldenGate
Online Reconfiguration Rolling Upgrades
Online Redefinition
アプリ 変更
Data Guard
Online Application Upgrade Edition-based Redefinition
Oracle M
AA
Best P
ractices
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Flashback Technology もしもの時の救世主!!
• ユーザー・エラーからの早急かつ容易な復旧が可能 • DBのバックアップ全体のリストア不要⇒変更されたブロックのみをリストア、DBを特定時点まで戻す
• 過去データの参照が可能!⇒ 不正なデータ改竄防止に効果
72
Flashback機能の種類 Flashback機能による復旧イメージ
Enterprise Edition
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Flashback Database データベース全体を指定された過去の時点の状態へ
•活用例 –人的ミス(データ削除や不適切な更新処理の実行等)からの迅速な復旧
– Primary側でLost Writeが発生した為に、Data GuardでFail-Over実行後、 旧Primaryを新Standby環境として迅速に復旧させる場合
• Oracle Database独自のロギング・メカニズム(Flashback Log) –データ更新時、自動的に更新前ブロック・イメージを高速リカバリ領域に保存
– Flashback Log(更新前ブロック・イメージ)でDB全体の復旧を実現 • リストア/リカバリ不要、Export/Import処理よりも高速
• Flashback Databaseでリカバリ可能なオペレーション – DML処理、TRUNCATE、スキーマ・ユーザーの削除(DROP USER)
73
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Flashback Database によるリカバリ リカバリに要する時間のイメージ
74
時間
Point-in-Timeリカバリの場合
Flashback Databaseによるリカバリの場合
ロールフォワード バックアップファイルのリストア
Flashback Log
の適用
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
【参考】 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)
75
保証付きリストア・ポイントは、 復旧可能な時点をGRP作成時点に限定し、Flashback Logの生成量を大幅に抑制可能
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
【参考】 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;
76
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>
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Flashback Database Flashback Loggingのオーバーヘッドとチューニング
• Flashback Loggingの有り無しで、 全件update処理時間が増加する傾向
– UNDOの物理読み込みがボトルネック
UNDO表領域をSSD上に配置することで、高速化を実現
Flashback LogではUNDOの更新前ブロックも保持する必要がある為、通常時には発生しないUNDOの物理読込みが追加される
77
【White Paper】 進化したバックアップ/リカバリを実現するFlashback Database活用のベストプラクティス http://www.oracle.com/jp/gridcenter/partner/nssol/wp-fbdb-gridcent-nssol-v2-484389-ja.pdf
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAAで救われた実例 カットオーバ直前のデータ移行処理の実行順序を誤り、論理データ破壊! 稼働前なので、バックアップはデータベース作成直後のものしか取得していない!!
• https://blogs.oracle.com/dbjp/entry/exadata_000193
78
RAC+ASM
DG Switch Over 運用で ロール切替(正副入替)
Flashback DB 機能で 処理実行直前へ巻き戻し
DG Stand by 再構築 再びDG Switch Overで
ロール切替(正副)
正規の処理を確実に実施 -> 無事運用開始へ
Flashback Database
RAC+ASM
DataGuard
RAC/ASM構成(Exadata)
+Data Guard による DR環境
プライマリ・データベースの性能を重視しスタンバイ・データベースのみで Flashback Log を確保
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Summary
79
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle Maximum Availability Architecture
80
Edition-based Redefinition, Online Redefinition, Data Guard, GoldenGate – Minimal downtime maintenance, upgrades, migrations
Active Data Guard – Data Protection, DR – Query Offload
GoldenGate – Active-active replication – Heterogeneous
Active Replica
RMAN, Oracle Secure Backup, Zero Data Loss Recovery Appliance – Backup to disk, tape or cloud
Enterprise Manager Cloud Control – Site Guard, Coordinated Site Failover
Application Continuity – Application HA
Global Data Services – Service Failover / Load Balancing
RAC – Scalability – Server HA
ASM – Local storage
protection
Production Site
Flashback – Human error
correction Application Test Suite, Real Application Testing – Minimal Testing Costs
Advanced Security – Data encryption,
protection
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAAの高可用性機能
81
ストレージ障害
人的エラー
データ破損
サイト障害
システム障害
データ障害
計画外停止
システム変更
データ 変更 計画的停止
Real Application Clusters
Automatic Storage Management Flashback Technology
Recovery Manager H.A.R.D
Active Data Guard GoldenGate
Online Reconfiguration Rolling Upgrades
Online Redefinition
アプリ 変更
Data Guard
Online Application Upgrade Edition-based Redefinition
Oracle M
AA
Best P
ractices
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle MAA: サービス・レベル区分 本セッションでご紹介する機能のマッピング
82
GOLD 包括的な高可用性と災害からの保護 データロス:ゼロもしくはほぼゼロ
SILVER ローカルサイト障害に対する高可用性 データロス: 最新バックアップ時点まで保護
BRONZE シングル・インスタンス、基本的なサービス再起動 データロス: 最新バックアップ時点まで保護
PLATINUM 重要アプリケーションに対して無停止 データロス:ゼロ
RAC Data Guard GoldenGate
ASM RMAN Flashback
✔ ✔ ✔ ✔ ✔
✔ ✔ ✔ ✔ ✔
✔ RAC
One Node ✔ ✔ ✔
✔ ✔ ✔
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle Database が提供する高可用性ソリューション(MAA)は可用性を高めるだけでは留まらず、性能および管理性の向上も実現します。
Oracle Real Application Clusters
Oracle Automatic Storage Management
Oracle Data Guard
Recovery Manager
Flashback Technology
Oracle Maximum Available Architecture
83
Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 84
Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 85