Null

Size: px

Start display at page:

Download "Null"

かんじふじがわ
4 years ago
Views:

1 Oracle Database Technology Night ~ 集え! オラクルの力 ( チカラ )~ 第 6 回 DB のバックアップリカバリは何が正解なのか Oracle Database に最適化されたバックアップリカバリで出来ること日本オラクル株式会社クラウドテクノロジー事業統括 Database & Exadata プロダクトマネジメント本部データベーステクノロジー部佐々木亨

2 Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. 2

3 本日のテーマ Backup & Recovery 3

4 毎日の運用で行われる vs 万が一の場面でしか行わない Backup Recovery 4

5 手段の一つ vs 目的 ( 最重要 ) Backup Recovery 5

6 BACKUP IS ONE THING RECOVERY IS EVERYTHING 6

7 Oracle Recovery Manager (RMAN) 7

8 申し込み時の事前アンケート結果分類 ( 複数回答有 ) 8

9 Topic 1) 取得しているバックアップを使っていざという時に本当にリカバリできるのか実は不安です 36/180 名 9

10 思い通りにリストアリカバリを出来ていますか? 過去 1 年以内に DB のリストアリカバリを実施した DBA の 84% が失敗の経験あり昨年リストアリカバリに失敗した割合 1%~10% 10%~20% 9% 20%~50% 6% 50%~75% 2% 100% 1% 不明 / 未確定 16% 67% データベースのリストアリカバリを実施した DBA のうち 84% が過去 1 年間に失敗を経験している約 20% の企業 (DBA) は 5 回のリストアリカバリで 1 回以上の失敗を経験している 40% 以上の組織が 4 時間以上の計画外停止を経験し 21% は 8 時間以上の停止を経験している 0% 20% 40% 60% 80% 出典 :UNISPHERE RESEARCH 社 Oracle Database and Data Protection Survey 10

11 どうしてリストアリカバリに失敗したか? 人的エラーバックアップ欠落破損複雑なプロセスにより戻せないバックアップリストアリカバリに失敗した主な理由人的エラーバックアップの破損ハードウェア / ソフトウェアの不具合リストアプロセスに複数の人員が関係しているアプリケーションがリストアされたデータでは起動できない 13% 12% 26% 26% 34% システム毎にバックアップ機器ツール運用方法が標準化されておらずスキル経験共有不足が人的エラーを生む要因となっている (34%) 26% の企業でバックアップの破損必要ファイルの不足によりリストアリカバリに失敗している正しいバックアップを指定できないインテグレイトされていないソリューションと複数ベンダ- 不明 / 未確認 11% 9% 19% 思った時点に戻せずにアプリケーションが起動できない業務が再開できない障害も 12% の企業で発生している 0% 10% 20% 30% 40% 11

12 どうすれば戻せるバックアップと言えるか Oracle Database インスタンスの仕組みを使ってファイルを読む Oracle インスタンスが関知しない ( ホットバックアップモード使用 ) Oracle インスタンスの仕組みを使ってファイルを読む oracle RMAN dd Oracle インスタンス oracle OS OS データファイル ( コピー元 ) バックアップファイル ( コピー先 ) ユーザー管理バックアップデータファイル ( コピー元 ) Recovery Manager バックアップファイル ( コピー先 ) 12

13 具体的にどうすれば良いかバックアップリカバリに関するベストプラクティス RMAN を利用したバックアップでバックアップ時にチェック DB_BLOCK_CHECKSUM ( デフォルト : 全表領域対象 ) によりブロックを読み込み時のブロックチェックサム検証により物理破損を検知任意 "CHECK LOGICAL" 句を付ければ物理的な破損チェックを通過したデータブロックと索引ブロックについて論理的な破損がないかどうかをテスト ( 但し 1-3% のオーバーヘッド ) バックアップ取得後にバックアップのチェック週次で RMAN の CROSS CHECK コマンド週次 / 月次で VALIDATE BACKUPSET (Backup の検査 ), RESTORE VALIDATE (Backup 擬似リストア ) 月次もしくは四半期のリストアリカバリ訓練参考資料 Oracle Open World 2016 "Zero Data Loss Recovery Appliance: Best Practices from Customer Deployments" [CON6535] 13

14 CROSSCHECK コマンドリカバリカタログまたは制御ファイルのバックアップに関する情報がディスクの該当するデータと同期されていることを確認する RMAN 以外の方法でファイルを削除する場合はクロスチェックを定期的に実行してカタログ情報を最新の状態に保持する RMAN を使って削除しているから不要? 定期的に実施した方が安全なぜなら例えば外部 NAS にバックアップデータを配置している場合ストレージ管理者により意図せず削除されたり移動されているケースは意外と多い 14

制御ファイルに格納する場合領域に制限有り : 初期化パラメータ :CONTROL_FILE_RECORD_KEEP_TIME( デフォルト 7 日 ) 2.

15 RMAN リポジトリとリカバリカタログ RMAN リポジトリ RMAN がバックアップリカバリおよびメンテナンスに使用するターゲットデータベースに関する管理情報の格納場所格納場所は制御ファイルかリカバリカタログデータベースいずれか 1. 制御ファイルに格納する場合領域に制限有り : 初期化パラメータ :CONTROL_FILE_RECORD_KEEP_TIME( デフォルト 7 日 ) 2. リカバリカタログデータベースに格納する場合リポジトリを長期間保存可能複数の Oracle Database のバックアップ状況を一元管理可能リポジトリ用途は無償ターゲットデータベースターゲットデータベースターゲットデータベースカタログスキーマ制御ファイル制御ファイル制御ファイルリカバリカタログデータベース 15

16 カタログの中身の一例 (List Backup コマンド ) RMAN> LIST BACKUP BS Key Type LV Size Device Type Elapsed Time 終了時間 Incr G DISK 00:02: BPキー : 144 ステータス : AVAILABLE 圧縮 : NO タグ : TAG T ピース名 : +FRA/ORCL/BACKUPSET/2017_01_19/nnndn0_tag t100403_ バックアップセット114のデータファイルのリスト File LV Type Ckp SCN Ckp 時間 Name Incr DATA/ORCL/DATAFILE/system Incr DATA/ORCL/DATAFILE/sysaux Incr DATA/ORCL/DATAFILE/undotbs Incr DATA/ORCL/DATAFILE/users この Level 0 バックアップを手動で削除した後 CROSSCHECK コマンドを実行その後この Level 0 を親とする Level 1 の増分バックアップを取得してみる 16

17 CROSSCHECK コマンド ASMCMD> rm +FRA/ORCL/BACKUPSET/2017_01_19/nnndn0_tag t100403_ RMAN> crosscheck backup; チャネル ORA_DISK_1 の使用バックアップピースがクロスチェックされました : 'EXPIRED' が検出されましたバックアップピースハンドル =+FRA/ORCL/BACKUPSET/2017_01_19/nnndn0_tag t100403_ レコード ID=144 スタンプ = RMAN> list backup; BS Key Type LV Size Device Type Elapsed Time 終了時間 Incr G DISK 00:02: BPキー : 144 ステータス : EXPIRED 圧縮 : NO タグ : TAG T ピース名 : +FRA/ORCL/BACKUPSET/2017_01_19/nnndn0_tag t100403_

18 CROSSCHECK コマンド Level 0 のバックアップが "EXPIRED" という状態で Level 1 の増分バックアップを取得してみると RMAN> backup incremental level 1 database; backup が開始されました ( 開始時間 : ) チャネル ORA_DISK_1 の使用データファイル 1 の親バックアップまたはコピーが見つかりませんデータファイル 3 の親バックアップまたはコピーが見つかりませんデータファイル 4 の親バックアップまたはコピーが見つかりませんデータファイル 6 の親バックアップまたはコピーが見つかりませんチャネル ORA_DISK_1: 増分レベル 0 のデータファイルバックアップセットを開始しています CROSSCHECK したことによって有効な Level 0 バックアップが存在しないことを認識できているので Level 1 の増分バックアップは自動的に Level 0 ( 全体バックアップ ) となる 18

19 RMAN "VALIDATE" 使い方使い方は色々コマンド内容チェック対象とチェックできること BACKUP VALIDATE. RESTORE VALIDATE. VALIDATE BACKUPSET. 実際のバックアップ時と同様にバックアップするファイル全体を読み取るバックアップ自体は作成されない VALIDATE DATABASE と同じチェック特定のファイル / ファイルセットをバックアップからリストア可能かどうかをテストバックアップを読取るだけで本番データファイルへアクセスはしないバックアップセット内の全てのブロックがチェックされバックアップがリストア可能かどうかをテスト本番データファイル破損有無存在有無格納位置が正しいかどうかバックアップファイル破損有無リストアに必要なファイルの存在有無バックアップファイル破損有無リストアに必要なファイルの存在有無 19

20 BACKUP VALIDATE DATABASE RMAN> backup validate database; 破損を検知した場合の出力例 backupが開始されました ( 開始時間 : ) < 中略 > データファイルリスト ================= ファイルステータスマーク済破損空のブロック調査済ブロック高 SCN FAILED ファイル名 : +DATA/ORCL/DATAFILE/system ブロックタイプ失敗ブロック処理済ブロックデータ索引その他検証により1つ以上の破損したブロックが見つかりました詳細はトレースファイル /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4016.trc 20

21 RESTORE VALIDATE RMAN> restore validate database; バックアップファイルが存在しないことを検知した場合の出力例チャネル ORA_DISK_1: バックアップピース +FRA/ORCL/FFC85E3C9CA50A16E A8C06BDA/BACKUPSET/2017_01_19/nnndn0_tag t100403_ から読取り中ですチャネル ORA_DISK_1: ORA-19870: バックアップピース +FRA/ORCL/FFC85E3C9CA50A16E A8C06BDA/BACKUPSET/2017_01_19/nnndn0_tag t100403_ のリストア中にエラーが発生しました ORA-19505: ファイル "+FRA/ORCL/FFC85E3C9CA50A16E A8C06BDA/BACKUPSET/2017_01_19/nnndn0_tag t100403_ " の識別に失敗しました < 途中略 > RMAN-03002: restore コマンドが 01/23/ :43:15 で失敗しました RMAN-06026: 見つからないターゲットがあります - リストアを中止します RMAN-06023: データファイル 7 をリストアするためのバックアップまたはコピーが見つかりません RMAN-06023: データファイル 5 をリストアするためのバックアップまたはコピーが見つかりません 21

22 VALIDATE BACKUPSET RMAN> validate backupset 116; バックアップファイルが存在しないことを検知した場合の出力例 validate が開始されました ( 開始時間 : ) チャネル ORA_DISK_1 の使用チャネル ORA_DISK_1: データファイルバックアップセットの検証を開始していますチャネル ORA_DISK_1: バックアップピース +FRA/ORCL/FFC85E3C9CA50A16E A8C06BDA/BACKUPSET/2017_01_19/nnndn0_tag t100403_ から読取り中です < 途中略 > RMAN-03009: validate コマンド (ORA_DISK_1 チャネル上 ) が 01/23/ :46:09 で失敗しました ORA-19870: バックアップピース +FRA/ORCL/FFC85E3C9CA50A16E A8C06BDA/BACKUPSET/2017_01_19/nnndn0_tag t100403_ のリストア中にエラーが発生しました ORA-19505: ファイル "+FRA/ORCL/FFC85E3C9CA50A16E A8C06BDA/BACKUPSET/2017_01_19/nnndn0_tag t100403_ " の識別に失敗しました 22

23 突然ですが Zero Data Loss Recovery Appliance ならこれらの検査処理が最初から組み込まれているバックアップ取得時 (RMAN コマンド ) バックアップ対象の Oracle Database インスタンスによるデータブロックの検査仮想フルバックアップ作成時受け取ったバックアップを分解検査し仮想フルバックアップ化して HDD に書き込む Recovery Appliance 内に格納されているバックアップの定期検査時日次で全バックアップセットの CROSSCHECK 週次でデータファイルを構成するバックアップデータの最適化 (=Block 読込 ) 隔週で全バックアップセットの検査 (RESTORE VALIDATE と同様 ) 参考資料 DDD 2106 " バックアップリカバリのベストプラクティスが詰まった Zero Data Loss Recovery Appliance 詳解 " 23

24 データベースレベルの確実な復旧が可能 Recovery Appliance のリソースを使ってバックアップの健全性を確認している従来型統合バックアップ NAS を利用する場合 FC-SW 95% CPU NW-SW 本番 DB サーバーの CPU リソースを使って NAS 上のバックアップファイルの健全性チェック RMAN> VALIDATE CHECKLOGICAL BACKUPSET DEVICE TYPE DISK; I/O FC-SW NW-SW バックアップ用ネットワーク上のI/O(Read) が発生する Recovery Appliance の場合 CPU 本番 DB サーバーの CPU リソースは使わない Recovery Appliance 上のリソースを使って健全性チェックバックアップの健全性チェックは Recovery Appliance 内で完結チェック用ジョブはデフォルトでスケジュール済み DB DB DB DB 従来型 NAS CPU Recovery Appliance 24

25 RMAN や Recovery Appliance は検知しかできないのか基本的には破損検知したら管理者がバックアップの取り直しを行うバックアップの配置先が ASM の場合自動修復されるケースもあるバックアップ破損検知時は ASM のセカンダリのエクステントから復旧を試みる最後の砦であるリストア / リカバリを実施するよりも前に気付けるという点が重要失敗できないプレッシャーの中いざリストア / リカバリを試みたタイミングでバックアップの破損に気付くと. ユーザ管理バックアップはフィルムカメラ RMAN を使ったバックアップはデジタルカメラ大切な写真を現像してみたら目をつむっていたピントがずれていたが無いように実際のオペレーションに備えて定期的にリストアリカバリ訓練を実施することは大事 25

26 Topic 2) 大規模なデータベースに対するバックアップ / リストアを高速に行いたい 51/180 名 26

27 バックアップリストアリカバリの高速化に関する考え方時間当たりの処理能力を上げる並列化 EE マルチセクションバックアップ必要なデータ移動量を減らす増分バックアップ高速増分バックアップ EE EE 永久増分戦略 ( フルバックアップを極力なくす ) 柔軟なリカバリ単位スタンバイデータベースの活用リストアをしない (Oracle MAAの視点で考える ) 27

CHANNEL 1 DEVICE TYPE DISK CONNECT 'sys@orcl1'; 手動割り当て (Backup コマンドの事前に設定 ) ALLOCATE CHANNEL ch1 DEVICE TYPE DISK CONNECT 'sys@orcl1'; RAC

28 バックアップチャネル数と H/W リソースチャネル ( サーバープロセス ) を複数起動してバックアップを並列化高速化のためには複数起動が望ましい一つのチャネルでは一つの CPU コアしか使用できないチャネルの複数起動複数 CPU コアの使用チャネルの単一起動 Backup のオーバーヘッド (CPU や I/O 消費 ) の低減チャネルの割り当て方法には自動と手動がある自動割り当て ( 下記のような永続設定をする ) CONFIGURE DEVICE TYPE DISK PARALLELISM 4 ; CONFIGURE CHANNEL 1 DEVICE TYPE DISK CONNECT 'sys@orcl1'; 手動割り当て (Backup コマンドの事前に設定 ) ALLOCATE CHANNEL ch1 DEVICE TYPE DISK CONNECT 'sys@orcl1'; RAC の場合は CONNECT 句を使ってサーバープロセスを起動するノードを固定したい接続記述子で接続先固定分散させたい接続記述子でロードバランスさせる参考資料 Doc ID / KROWN# RAC 環境でのチャネル割り当てについて 28

29 バックアップチャネルを増やしてもファイルが 1 つだと並列化できない BIGFILE 表領域など特定の 1 つのファイルが非常に大きなサイズの場合複数チャネルを割り当てただけではそのデータファイルに対するバックアップは並列化されないマルチセクションバックアップを利用する指定したサイズ ( セクションサイズ ) 毎にファイルセクションとして分割ファイルセクション単位にバックアップを取得 11gR1 より使用可能 Backupset RMAN> backup database section size 32G ; Backupset Backup Backup Piece Backup Backup Backup Backup Backup Piece Backup Piece Backup Piece Backup Piece データファイルデータファイル通常のバックアップマルチセクションバックアップ 29

マルチセクションバックアップ BS Key Type LV Size Device Type Elapsed Time 終了時間 ------- ---- -- ---------- ----------- ------------ -------- 97 Full 678.

854721995 バックアップセットのコピー #1( バックアップセット97) Device Type Elapsed Time 終了時間 Compressed Tag ----------- ------------ -------- ---------- --- DISK 00:02:07 17-01-10 NO TAG20170110T190424

30 マルチセクションバックアップ BS Key Type LV Size Device Type Elapsed Time 終了時間 Full M DISK 00:02: バックアップセット97のデータファイルのリスト File LV Type Ckp SCN Ckp 時間 Name Full DATA/ORCL/DATAFILE/system バックアップセットのコピー #1( バックアップセット97) Device Type Elapsed Time 終了時間 Compressed Tag DISK 00:02: NO TAG T 複数のバックアップピースから成るバックアップセットが出来るバックアップセット97コピー #1のバックアップピースのリスト BP Key Pc# Status Piece Name AVAILABLE +FRA/ORCL/BACKUPSET/2017_01_10/< 省略 > AVAILABLE +FRA/ORCL/BACKUPSET/2017_01_10/< 省略 > AVAILABLE +FRA/ORCL/BACKUPSET/2017_01_10/< 省略 > AVAILABLE +FRA/ORCL/BACKUPSET/2017_01_10/< 省略 > AVAILABLE +FRA/ORCL/BACKUPSET/2017_01_10/< 省略 >

31 増分バックアップ A A A A A A BACKUP A A A A A A A A A A A A 更新全ブロック ( レベル 0) 全ブロック ( レベル 0) A B A A B B BACKUP B B B B B B 更新 A B C A B C BACKUP B C B C C C データファイル累積増分バックアップ差分増分バックアップ時間レベル 0 のバックアップからの増分前回のバックアップからの増分バックアップファイルのサイズを小さく抑えつつリカバリ時の REDO 適用量を減らす効果が期待できる 31

32 増分バックアップ増分バックアップデータベースサーバー B B B A B A A B B フルスキャンし全データブロックの SCN を調べることで以前のバックアップから更新のあるデータブロックを判断データファイル A B A A B B ( 従来の ) 増分バックアップフルスキャンを行うためバックアップ取得時のディスク I/O の負担は減らない 32

33 高速増分バックアップブロックチェンジトラッキングファイル増分バックアップ B B B ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'filename' REUSE; データベースサーバー B B B 以前のバックアップから更新が発生したデータブロックをビットマップで記録データファイル A B A A B B 高速増分バックアップ更新ブロックのみを読み込むためバックアップ取得時のディスク I/O の負担を軽減 33

34 増分バックアップのリストア通常の増分バックアップだとリストア時間が長くなる可能性があるデータベースにリストアするときまずフルバックアップをデータベースにリストアその上に増分バックアップをリストア C C 増分 2 リストア 3 C C 増分 2 B B B 増分 1 リストア 2 B B B 増分 1 A A A A A A フルリストア 1 A A A A A A フルデータベースバックアップ 34

35 増分更新バックアップリストアは 1 回永久に増分バックアップ運用で良い A A A A A A 更新 BACKUP A A A A A A イメージコピー ( 全ブロックのバックアップ ) A A A A A A A B A A B B BACKUP B B B RECOVER A B A A B B 更新増分バックアップ A B C A B C BACKUP C 増分バックアップ C RECOVER A B C A B C データファイル時間増分更新バックアップイメージコピーに増分を適用但し増分を適用すると過去時点には戻ることができない 35

36 任意時点へ Point in Time リカバリ可能 (DB の複製も可能 ) 任意の時点に 1 回のリストアで Point in Time リカバリ可能 Recovery Appliance は週次 Full+ 日次増分と増分更新バックアップの良い点を兼ね備えているリストア回数任意の地点に戻せるか 1. 週次 Full+ 日次増分 2. 増分更新バックアップ 3. Recovery Appliance Full 1 回 + 戻したい地点までの増分 N 回 Full 1 回 Full 1 回戻せる戻せない戻せる過去時点に戻りたいユースケースある時点の本番データベースのバックアップを使ってステージング環境にテスト用のデータベースを作成する ( ステージング環境で本番同等データでテストを実施したり過去時点のデータを参照することが可能 ) 36

37 リストアリカバリリストアリカバリの単位を選べる基本的にはファイル単位バックアップリストアデータファイル #1 データファイル #1 データファイル #1 データファイル #1 データファイル #2 データファイル #2 データファイル #2 データファイル #2 データファイル #3 データファイル #3 データファイル #3 データファイル #3 表領域 ( オンライン ) バックアップ領域表領域 ( オフライン ) バックアップ領域データブロック単位でもリストア / リカバリ可能正常データブロックは継続してアクセス可能 EE リストア 12c からはテーブル単位でもリカバリ可能 EE データファイル表領域 ( オンライン ) バックアップ領域 37

38 RMAN のバックアップリカバリ手順ブロック単位のリカバリ (RECOVER BLOCK) データブロックの障害箇所の特定 SQL> select * from v$database_block_corruption; FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO CHECKSUM ブロックメディアリカバリの実行 RMAN> RECOVER DATAFILE 6 BLOCK 108; v$database_block_corruption に記録されているすべてのブロックをリカバリ RMAN> RECOVER CORRUPTION LIST; 38

39 スタンバイデータベースの活用リストアをしないバックアップ取得時の負荷がどうしても気になる場合は Data Guard のフィジカルスタンバイデータベースでバックアップを取得可能 ( スタンバイで取ったバックアップをプライマリにも戻せる ) Active Data Guard オプションがあれば高速増分バックアップを使えるどうしても高い RTO 要件で大量データのリストアが必要になるケースでは RTO を満たせないケースもあるかもしれないそのような障害に対してはリストアをせずに下記のような対処も可能バックアップされた Image Copy 形式のデータファイルに切り替える [* 参考 ] 構築しておいたスタンバイデータベース (Active Data Guard/GoldenGate) に切り替えるただし軽微な問題は ( ブロック単位やファイル単位 ) リストアで対応した方が良いし壊れた環境を戻すためにもバックアップは必ず必要 [* 参考 ] しばちょう先生の試して納得!DBA への道第 45 回 Recovery Manager の SWITCH コマンドでリストア時間ゼロ 39

40 SK Hynix 様の Outage Matrix 40

41 Topic 3) マルチテナント環境でのバックアップリカバリ方法で気を付けるべき点はどこか 16/180 名 41

42 これまでと同じように運用可ただし 2 点考慮ポイント有り基本的には取得する単位戻す単位を選べるようになっただけでこれまでと同じように運用できますただし下記の 2 点については意識する必要があります 1. 新規 PDB を作成した後には必ず新規 PDB のデータファイルを含むバックアップを取得して下さい 2. ユーザ管理 ( ストレージ機能を使ったミラーボリュームのスプリット ) バックアップでは PDB 単位で PITR(Point In Time Recovery) をすることはできません CDB 全体で戻す必要があります RMAN を使えば好きなようにリカバリできます 42

43 マルチテナント環境でのバックアップリカバリ CDB ( 開発テスト環境 ) 1 回でデータベース全体をバックアップ PDB1 PDB2 PDB3 プラガブルデータベースごとデータベース全体のの Point-in-time リカバリ Backup 取得先 43

PDB 作成後には必ずバックアップを取得して下さいシードから PDB を作成する方法ローカル PDB のクローニングの手順の中に下記の記載があります https://docs.oracle.com/cd/e57425_01/121/admin/cdb_plug.

recover logfile '/u02/app/oracle/fast_recovery_area/dbm/dbm/archivelog/2016_09_28/o1_mf_1_1_cypl3c8v_.

44 PDB 作成後には必ずバックアップを取得して下さいシードから PDB を作成する方法ローカル PDB のクローニングの手順の中に下記の記載があります PDB の作成 / 複製を跨ったリカバリは出来ません RMAN-20505: create datafile during recovery RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/u02/app/oracle/fast_recovery_area/dbm/dbm/archivelog/2016_09_28/o1_mf_1_1_cypl3c8v_.arc' ORA-00283: recovery session canceled due to errors ORA-01244: unnamed datafile(s) added to control file by media recovery ORA-01110: data file 25: '/u02/app/oracle/oradata/dbm/3d8ada5071f77fe2e b90af336/datafile/o1_mf_system_cypkzg hz_.dbf' 44

45 PDB 作成後には必ずバックアップを取得して下さい本番 DB CDB 新規 PDB 作成 CDB 障害 PDB PDB PDB PDB PDB 日次バックアップ PDB 作成後バックアップ Backup ストレージ取得済み取得予定 Day1 03:00 PDB 作成後 Day2 03:00 PDB のバックアップが無い場合 PDB のバックアップが有る場合リストアリカバリ失敗障害発生直前まで復旧可能 45

ストレージ機能で取得したバックアップは PDB 単位では Point In Time リカバリできない CDB CDB$ROOT PDB$SEED PDB 1 SYSTEM SYSAUX USERS TEMP データファイル UNDO 制御ファイル REDO ログファイルアーカイブ REDO SYSTEM SYSAUX TEMP データファイル SYSTEM SYSAUX

46 ストレージ機能で取得したバックアップは PDB 単位では Point In Time リカバリできない CDB CDB$ROOT PDB$SEED PDB 1 SYSTEM SYSAUX USERS TEMP データファイル UNDO 制御ファイル REDO ログファイルアーカイブ REDO SYSTEM SYSAUX TEMP データファイル SYSTEM SYSAUX USERS データファイル TEMP UNDO は全 PDB 共通なので UNDO データファイルを戻せない CDB$ROOT PDB$SEED PDB 1 SYSTEM SYSAUX USERS TEMP データファイル UNDO アーカイブ REDO SYSTEM SYSAUX TEMP データファイル SYSTEM SYSAUX USERS データファイル TEMP 46

47 Topic 4) RMAN の 12.2 での新機能について知りたい 9/180 名 47

48 新機能の詳細は巻末の参考資料を参照下さい RMAN は 12.2 で次のような機能拡張が行われているクラウドに移行するツールとしての拡張バックアップリカバリユーティリティとしての構文拡張 48

49 まとめ RMAN は Oracle Database のバックアップを確実にリカバリするために必要な機能が多数提供されています Zero Data Loss Recovery Appliance は上記のような機能をベストプラクティスとして多く取り込み自動化されている製品です 49

50 参考資料バックアップリカバリ基礎著者登場! これは使えるOracle 新機能活用術 -バックアップ/ リカバリ編 RMANを使いこなしたい人しばちょう先生による特別講義! RMANバックアップの運用と高速化チューニング Recovery Appliance について知りたい Oracle Zero Data Loss Recovery Applianceによるデータベース保護のアーキテクチャバックアップリカバリのベストプラクティスが詰まった Zero Data Loss Recovery Appliance 詳解 12c R2 の RMAN について知りたい Active Data Guard/Data Guard & RMAN & Online Operation 50

51 Safe Harbor Statement The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. 51

52 みなさまの投稿をお待ちしております Twitter #OracleTechNight

53 Oracle Digital はオラクル製品の導入をご検討いただく際の総合窓口電話とインターネットによるダイレクトなコニュニケーションでどんなお問い合わせにもすばやく対応しますもちろん無償どんなことでもご相談ください 53

54 54

55 55

Oracle パブリック・クラウド・サービス無料トライアル申込手順書

Oracle パブリック・クラウド・サービス無料トライアル申込手順書 Oracle パブリッククラウドサービス無料トライアル申込手順書日本オラクル Oracle Digital Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may