Oracle Database Technology Night ~ 集え! オラクルの力 ( チカラ ) ~ Oracle Database 18c テクノロジーシリーズ 2 RAC/Sharding と Data Guard/HA の機能強化 ~ Data Guard & HA ~ 日本オラクル

Size: px

Start display at page:

Download "Oracle Database Technology Night ~ 集え! オラクルの力 ( チカラ ) ~ Oracle Database 18c テクノロジーシリーズ 2 RAC/Sharding と Data Guard/HA の機能強化 ~ Data Guard & HA ~ 日本オラクル"

ともなりらぶり
4 years ago
Views:

1 Oracle Database Technology Night ~ 集え! オラクルの力 ( チカラ ) ~ Oracle Database 18c テクノロジーシリーズ 2 RAC/Sharding と Data Guard/HA の機能強化 ~ Data Guard & HA ~ 日本オラクル株式会社ソリューションエンジニアリング統括クラウドインフラストラクチャー本部柴田長

2 以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード機能を提供することをコミットメント ( 確約 ) するものではないため購買決定を行う際の判断材料になさらないで下さいオラクル製品に関して記載されている機能の開発リリースおよび時期については弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社関連会社の米国及びその他の国における登録商標です文中の社名商品名等は各社の商標または登録商標である場合があります

3 アジェンダマルチインスタンス REDO 適用時とブロックチェンジトラッキングの併用 NOLOGGING 処理後のスタンバイデータベースブロックの修復 Shadow Lost Write Protect その他 Data Guard 関連新機能 3

4 アジェンダマルチインスタンス REDO 適用時とブロックチェンジトラッキングの併用 NOLOGGING 処理後のスタンバイデータベースブロックの修復 Shadow Lost Write Protect その他 Data Guard 関連新機能 4

5 マルチインスタンス REDO 適用時とブロックチェンジトラッキングの併用必要なエディション : EE, EE-ES, DBCS-EP, ExaCS 5

インスタンス数まで指定可能 1 スレッド / インスタンス ALL の場合は全インスタンスで同じモードの必要がある (mount/read-only) Data Guard Broker プロパティ値 : ApplyInstances ただし

6 (12.2~) 複数インスタンスでのパラレル REDO 適用 REDO 適用性能の向上 RAC の複数インスタンスでパラレルに REDO 適用を行うことが可能となった高い REDO 適用性能を必要とするような REDO 生成量の多い大規模環境で効果が期待できる検証結果 : 8 ノード RAC で 3,500MB/sec 適用性能 SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT USING INSTANCES [ALL <N>]; N : 1~ インスタンス数まで指定可能 1 スレッド / インスタンス ALL の場合は全インスタンスで同じモードの必要がある (mount/read-only) Data Guard Broker プロパティ値 : ApplyInstances ただし下記を使用しているスタンバイ環境では利用不可ブロックチェンジトラッキング ( 高速増分バックアップ ) Database In-Memory 機能パラレル REDO 適用を使用する場合 ADG_IMC_ENABLED 値が全インスタンスで同じある必要ありプライマリ REDO APPLY スタンバイ 6

(12.2~) 複数インスタンスでのパラレル REDO 適用プライマリスタンバイ Instance 1 Instance 1 12.

7 (12.2~) 複数インスタンスでのパラレル REDO 適用プライマリスタンバイ Instance 1 Instance NSS TTnn MR Process RFS MRP PRnn Instance 2 SRL Instance 2 NSS TTnn ASYNC/SYNC Process RFS PRnn SRL Instance 3 Instance 3 NSS TTnn SRL RFS PRnn 7

8 (18.1~) 複数インスタンスでのパラレル REDO 適用マルチインスタンス REDO 適用時とブロックチェンジトラッキングの併用 New in 18c これまでは併用出来なかった下記 2 つの機能を併用できるようになったスタンバイデータベースにおける複数インスタンスでのパラレル REDO 適用スタンバイデータベースにおけるチェンジトラッキングファイル有効化 ( 高速増分バックアップ ) SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT USING INSTANCES ALL; SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '+FRA(CHANGETRACKING)' REUSE ; SQL> SELECT * FROM V$BLOCK_CHANGE_TRACKING ; STATUS FILENAME BYTES ENABLED +FRA/orcl/changetracking/ctf

9 アジェンダマルチインスタンス REDO 適用時とブロックチェンジトラッキングの併用 NOLOGGING 処理後のスタンバイデータベースブロックの修復 Shadow Lost Write Protect その他 Data Guard 関連新機能 9

10 NOLOGGING 処理後のスタンバイデータベースブロックの修復必要なエディション : EE-ES, DBCS-EE+, ExaCS (OnP の EE では使えません ) 10

tab1; select count(*) from tab1 * 行 1 でエラーが発生しました : ORA-01578: Oracle データブロックに障害が発生しました ( ファイル番号 15 ブロック番号 131) ORA-01110:

11 (12.1 以前 )NOLOGGING 処理に対するリカバリが必要スタンバイ側でのアクセス時にエラーが返る I/Oネックであるような環境ではデータロード時などに REDO 生成を抑えて実行時間を短縮するためにNOLOGGING を使う場合があった Data Guard 環境においてはプライマリでの NOLOGGING の処理はスタンバイのデータ破損を起こす結果スタンバイ側で該当データへのアクセス時にエラー返る NOLOGGING SQL> select count(*) from tab1; select count(*) from tab1 * 行 1 でエラーが発生しました : ORA-01578: Oracle データブロックに障害が発生しました ( ファイル番号 15 ブロック番号 131) ORA-01110: データファイル 15:'+DATA/xxx/xxx/DATAFILE/ts ' ORA-26040: データブロックが NOLOGGING オプションを使用してロードされました UNRECOVERBLE DATA ORA

12 (12.1 以前 )NOLOGGING 処理に対するリカバリが必要手動でのリカバリ対処方法としては下記のいずれか中間表など一時的なデータなので無視する ( のちに DROP される ) 影響を受けるテーブルの再作成 NOLOGGING 処理開始直前からの増分バックアップをプライマリで取得しスタンバイに増分バックアップを適用するスタンバイデータベースを再作成する 12

13 (12.1 以前 )NOLOGGING 処理への対処影響範囲の特定 / 対処に時間を要するプライマリ LOADING 待機日中業務開始スタンバイ REDO 適用対象ブロックを手動特定必要に応じてデータを再投入 13

(12.2 から ) NOLOGGING 処理に対する検証やリカバリ DWH 向けの機能強化スタンバイで NOLOGGING

アクセスしないと気付けなかった NONLOGGED BLOCK に気付け 1 コマンドでリカバリが可能にデータベース全体 or

14 (12.2 から ) NOLOGGING 処理に対する検証やリカバリ DWH 向けの機能強化スタンバイで NOLOGGING で更新されたブロックに対する VALIDATE/RECOVER の実行が可能 RMAN による検証とリカバリで修復が簡単にアクセスしないと気付けなかった NONLOGGED BLOCK に気付け 1 コマンドでリカバリが可能にデータベース全体 or データファイルごとに実行実行時は管理リカバリモード (MRP) の停止が必要検証 RMAN> VALIDATE DATABASE/DATAFILE...NONLOGGED BLOCK; リカバリ NOLOGGING UNRECOVERBLE DATA VALIDATE/ RECOVER ブロックコピー RMAN> RECOVER DATABASE/DATAFILE... NONLOGGED BLOCK; 14

15 (12.2 から ) NOLOGGING 処理に対する検証やリカバリ参考 ) 1. スタンバイ側で NOLOGGING 処理のブロックを確認管理リカバリモード (MRP) の停止 SQL> RECOVER MANAGED STANDBY DATABASE CANCEL; 下記のいずれかの方法で検証特定のデータファイルを検証 RMAN> VALIDATE DATAFILE < データファイル ID> NONLOGGED BLOCK; データベース全体を検証 RMAN> VALIDATE DATABASE NONLOGGED BLOCK; V$NONLOGGED_BLOCK を確認 SQL> select FILE#,BLOCK#,BLOCKS,NONLOGGED_START_CHANGE#,NONLOGGED_END_CHANGE# from V$NONLOGGED_BLOCK; FILE# BLOCK# BLOCKS NONLOGGED_START_CHANGE# NONLOGGED_END_CHANGE#

16 (12.2 から ) NOLOGGING 処理に対する検証やリカバリ参考 ) 2. スタンバイ側で NONLOGGED のブロックをリカバリ下記のいずれかの方法でリカバリ特定のデータファイルをリカバリ RMAN> RECOVER DATAFILE < データファイル ID> NONLOGGED BLOCK; データベース全体をリカバリ RMAN> RECOVER DATABASE NONLOGGED BLOCK; V$NONLOGGED_BLOCK で該当ブロックを確認 SQL> select FILE#,BLOCK#,BLOCKS,NONLOGGED_START_CHANGE#,NONLOGGED_END_CHANGE# from V$NONLOGGED_BLOCK; レコードが選択されませんでした管理リカバリモードを開始 SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT; 16

17 (12.2 から ) NOLOGGING 処理への対処影響範囲の特定 / 対処が自動化可能になったプライマリ LOADING 待機日中業務開始データ取得スタンバイ REDO 適用 VALIDATE RECOVER 17

18 (12.2 から ) NOLOGGING 処理に対する検証やリカバリ実行時のログリカバリ時動作 RMAN> recover datafile 7 nonlogged block; recover をで開始していますリカバリカタログのかわりにターゲットデータベース制御ファイルを使用していますチャネル : ORA_DISK_1 が割り当てられましたチャネル ORA_DISK_1: SID=17 デバイスタイプ =DISK 記録されていないブロックのリカバリを開始していますデータファイルリスト ================= ファイルステータス記録されていないブロック調査済ブロックスキップされたブロック OK 記録されていないブロックの詳細は v$nonlogged_block ビューから問合せできます記録されていないブロックのリカバリが完了しました経過時間 : 00:00:00 recover をで終了しました 18

19 (12.2 から ) NOLOGGING 処理に対する検証やリカバリ実行時のログスタンバイ T11:04: :00 Started Nonlogged Block Replacement recovery on file 7 (ospid rcvid ) T11:04: :00 Data Transfer Cache defaulting to 96MB. Trying to get it from Buffer Cache for process T11:04: :00 Finished Nonlogged Block Replacement recovery on file 7. 0 blocks remain Statistics for replacement block source database (service=prim) Blocks requested 139, blocks received 139. Reason replacement blocks accepted or rejected Blocks Last block Accept: SCN in range for classic non-logged block プライマリ T11:04: :00 TT06: Start data block transfer (PID:21831) T11:14: :00 TT06: Data block transfer ends 19

20 (12.2 から ) NOLOGGING 処理に対する検証やリカバリ制限事項プライマリ側で Flashback Database や OPEN RESETLOGS を実行している場合スタンバイ側で必要なブロックが手に入らず下記のようなエラーがアラートログに出力される ORA-12942: database incarnation at source does not match 20

(18.1 から ) NOLOGGING 処理に対する自動リカバリ New in 18c Data Guard 構成で管理リカバリモードが有効な場合

LOGGING モード (STANDBY NOLOGGING FOR LOAD PERFORMANCE or STANDBY NOLOGGING FOR DATA

データベースが変更されました SQL> select FORCE_LOGGING from v$database; FORCE_LOGGING

21 (18.1 から ) NOLOGGING 処理に対する自動リカバリ New in 18c Data Guard 構成で管理リカバリモードが有効な場合自動的に破損ブロックをプライマリから取得して置き換える機能が動作する (MOUNT でも動作した ) 前提事項 NOLOGGING オペレーション実施前にデータベースを適切な LOGGING モード (STANDBY NOLOGGING FOR LOAD PERFORMANCE or STANDBY NOLOGGING FOR DATA AVAILABILITY) に変更する SQL> ALTER DATABASE SET STANDBY NOLOGGING FOR LOAD PERFORMANCE; データベースが変更されました SQL> select FORCE_LOGGING from v$database; FORCE_LOGGING STANDBY NOLOGGING FOR LOAD PERFORMANCE NOLOGGING UNRECOVERBLE DATA 自動修復ブロック要求ブロックコピー! MRP 21

22 (18.1 から ) NOLOGGING 処理に対する自動リカバリ Data Guard 構成に利用できる LOGGING モード一覧 New in 18c LOGGING モード FORCE LOGGING SET STANDBY NOLOGGING FOR DATA AVAILABILITY 18c ~ SET STANDBY NOLOGGING FOR LOAD PERFORMANCE 18c ~ 説明全てのロード処理が NOLOGGING にならないようにするためのモードプライマリとスタンバイ間のネットワークが確立されている場合は必要データをネットワーク越しに送りネットワークが切れている場合は LOGGING モードになり REDO ログに更新後データを残す ( その後スタンバイに送られて反映される ) スタンバイで REDO を適用する際 NOLOGGING 処理が実行されたためにブロックが破損してしまう場合にはスタンバイが自動的にプライマリにデータを要求する 22

23 (18.1 から ) NOLOGGING 処理に対する自動リカバリ STANDBY NOLOGGING FOR LOAD PERFORMANCE モード New in 18c 管理リカバリプロセスが REDO 適用時に NOLOGGING 処理を検知するとプライマリに対して該当ブロックを要求するスタンバイのアラートログには次のような出力がされる T16:58: :00 Data Transfer Cache defaulting to 96MB. Trying to get it from Buffer Cache for process スタンバイ側でデータを受信するプロセスの実体としてはサーバープロセス ( 名前は DTS:Data Transfer Service) SQL> SELECT PROCESS, PID FROM V$MANAGED_STANDBY WHERE PID=19717; PROCESS PID DTS

24 (18.1 から ) NOLOGGING 処理への対処影響範囲の特定と対処を効率化 (LOAD PERFROMANCE モード ) New in 18c プライマリ LOADING 待機日中業務開始データ取得スタンバイ REDO 適用 (VALIDATE & RECOVER) 24

25 (18.1 から ) NOLOGGING 処理に対する自動リカバリ STANDBY NOLOGGING FOR DATA AVAILABILITY モード New in 18c プライマリとスタンバイのネットワーク接続が正常な場合には LOAD PERFORMANCE モードと同様の動作ネットワーク接続が切れている場合はプライマリデータベースが検知をし強制的に LOGGING 処理に切り替わる T12:35: :00... (PID:31966): Error received logging on to the standby... (PID:31966): Check whether the listener is up and running. WARNING! A session under STANDBY NOLOGGING for DATA AVAILABILITY mode failed to complete all necessary setup. The operation will continue but without sending data blocks to any standbys. Instead block image redo will be logged. Check network connectivity to the standbys. 25

26 (18.1 から ) NOLOGGING 処理への対処影響範囲の特定と対処を効率化 (DATA AVAILABILITY モード ) New in 18c プライマリ LOADING ( 障害時は logging に自動切替 ) 待機日中業務開始スタンバイ REDO 適用 26

27 アジェンダマルチインスタンス REDO 適用時とブロックチェンジトラッキングの併用 NOLOGGING 処理後のスタンバイデータベースブロックの修復 Shadow Lost Write Protect その他 Data Guard 関連新機能 27

28 Shadow Lost Write Protect 必要なエディション : EE, EE-ES, DBCS-EE+, ExaCS 28

29 Lost Write とは? 例えばストレージ装置から Block の書込み完了が通知されたにも関わらず実際には Disk に書き込まれていない事象ディスク上には更新前の Data Block が存在 Block の構造としては正常な為 Lost Write が発生した Block にアクセスしてもエラーは発生しない不正なデータをユーザー / 顧客に提供するリスク不正なデータ汚染が広がるリスク Lost Write による影響の例在庫が無いにも関わらず在庫有りとして注文を受けてしまう注文を受けたはずなのに注文を受けていないことになってしまう Database Clusterware Volume Manager OS Driver / MultiPath SW I/O-Interface(DsikNW) Storage Utilities Storage Manager Controller/Cache/DiskShelf Disk 29

30 (12.2 まで )Lost Write Protect DB_LOST_WRITE_PROTECT パラメータの有効化 Data Guard(Physical Standby Database) で Lost Write を検出する仕組みを提供 1. Primary Database で Block を Disk から読み出す際に検証用 Redo を生成 Data File Number Data Block Address(DBA) System Change Number(SCN) 2. Data Guard の仕組みで Physical Standby Database へ Redo を転送 3. Standby Database 側の対象 Block と Redo 内の SCN を比較検証もし SCN が不一致の場合は Lost Write が発生していると判定可能 30

DDD2013 高可用性ベストプラクティスによるデータ破壊対策完全版 http://www.oracle.

31 DDD2013 高可用性ベストプラクティスによるデータ破壊対策完全版 31

32 Shadow Lost Write Protection New in 18c Data Guard 構成無し ( フィジカルスタンバイデータベース無し ) でデータベースや表領域データファイル単位でのロストライト検知を有効化できる機能 Data Guard 構成が無い環境においてもデータ破損によるデータロストを最小化できる本機能を有効化すると対象表領域上のバッファ上の任意のデータがディスクに書き出されるタイミングでそのブロックの SCN を記録するディスクからの読み込み時に実際の SCN と上記 SCN を比較してロストライトが発生していないかどうかを判断する ( 実際 SCN < 上記 SCN なら発生 ) 32

33 Shadow Lost Write Protection 有効化手順 New in 18c Shadow Lost Write Protect 検知用に下記のように表領域を作成する SQL> create bigfile tablespace SHADOW_TBS datafile '/u01/app/oracle/oradata/prim/shadow_tbs_01.dbf' size 10M lost write protection; 表領域が作成されました正しく作成されたかどうかを確認します SQL> select CONTENTS from DBA_TABLESPACES where TABLESPACE_NAME='SHADOW_TBS'; CONTENTS LOST WRITE PROTECTION 33

34 Shadow Lost Write Protection 有効化手順 New in 18c データベース全体で Shadow Lost Write Protection を有効化します SQL> alter database enable lost write protection; データベースが変更されました対象とする表領域 / データファイルに対して Shadow Lost Write Protection を有効化します SQL> alter tablespace users enable lost write protection; 表領域が変更されました SQL> select LOST_WRITE_PROTECT from DBA_TABLESPACES where TABLESPACE_NAME='USERS'; LOST_WR ENABLED 34

35 Shadow Lost Write Protection New in 18c ロストライトを検知すると下記のエラーが出力されます SQL> select * from lwp1; select * from lwp1 * 行 1 でエラーが発生しました : ORA-65478: シャドウ消失書込み保護 - 消失書込みが見つかりました ####### アラートログの内容 T16:46: :00 ERROR - I/O type:buffered I/O found lost write in block with file#:7 rdba:0x1c00f84, Expected SCN:0x e078a SCN in block:0x dfe88, approx current SCN:0x e0aa4, RAC instance:1 pdb:1 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************************************************** 35

36 Shadow Lost Write Protection その他補足事項 New in 18c ダイレクトパスロードでも有効に動作します RMANバックアップによるブロックアクセスでも動作します少なくとも2% の領域を余分に使います DB_LOST_WRITE_PROTECT パラメータの設定有無に関わらず動作します 36

37 アジェンダマルチインスタンス REDO 適用時とブロックチェンジトラッキングの併用 NOLOGGING 処理後のスタンバイデータベースブロックの修復 Shadow Lost Write Protect その他 Data Guard 関連新機能 37

38 その他 Data Guard 関連新機能 38

39 v$dataguard_process Data Guard に関連するプロセスの状態を確認できる v$managed_standby の置き換え SQL> select NAME, PID, ROLE, ACTION from v$dataguard_process; NAME PID ROLE ACTION LGWR log writer IDLE TMON redo transport monitor IDLE TT gap manager IDLE TT redo transport timer IDLE ARC archive local IDLE ARC archive redo IDLE ARC archive redo IDLE ARC archive redo IDLE TT async ORL multi WRITING TT heartbeat redo informer IDLE SQL> select NAME, PID, ROLE, ACTION from v$dataguard_process; New in 18c NAME PID ROLE ACTION LGWR log writer IDLE TMON redo transport monitor IDLE TT gap manager IDLE TT redo transport timer IDLE ARC archive local IDLE ARC archive redo IDLE ARC archive redo IDLE ARC archive redo IDLE MRP managed recovery IDLE PR recovery logmerger APPLYING_LOG PR recovery apply slave IDLE PR recovery apply slave IDLE PR recovery apply slave IDLE PR recovery apply slave IDLE rfs RFS async WRITING rfs RFS archive IDLE rfs RFS ping IDLE 39

40 ネットワーク越しでのスタンバイ DB のリフレッシュ New in 18c プライマリで増分バックアップを取得しその増分バックアップでスタンバイデータベースをリフレッシュ可能ですスタンバイ側でリカバリに必要なアーカイブ REDO ログをプライマリスタンバイ双方で消してしまった場合の復旧に便利スタンバイ DB を再起動マウント状態にしてプライマリからのバックアップをリストアします RMAN> recover standby database from service prim ; 40

41 ネットワーク越しでのスタンバイ DB のリフレッシュ New in 18c 次のような動作が自動実行される 1. スタンバイを停止 2. スタンバイをNOMOUNT 3. プライマリでスタンバイ制御ファイル作成し制御ファイルをリストア 4. スタンバイをMOUNT 5. standby_file_management=manual 6. スタンバイの現行 SCN 以降の増分バックアップをプライマリで取得スタンバイにリストア 7. リカバリ 8. standby_file_management=auto 41

42 テックナイトアーカイブ資料とお役立ち情報各回テックナイトセッション資料ダウンロードサイト oracle technight 技術コラムしばちょう先生の試して納得! DBA への道技術コラム津島博士のパフォーマンス講座もしもみなみんが DB をクラウドで動かしてみたら 42

43 43

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

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

46 46

第 3 章メディア障害とバックアップリカバリこの章ではメディア障害の発生に備えたバックアップ方法と障害時の基本的なリカバリ方法について説明します 1. メディアリカバリ概要 2. ファイルの多重化 3. アーカイブモードの設定 4. バックアップ概要 5. 一貫性バックアップ ( オ

第 3 章メディア障害とバックアップリカバリこの章ではメディア障害の発生に備えたバックアップ方法と障害時の基本的なリカバリ方法について説明します 1. メディアリカバリ概要 2. ファイルの多重化 3. アーカイブモードの設定 4. バックアップ概要 5. 一貫性バックアップ ( オはじめにコース概要と目的データベースのバックアップの取得方法障害発生時のリカバリ方法について習得します受講対象者データベース管理者の方前提条件データベースアーキテクチャおよびデータベースマネジメントコースを受講された方または同等の知識をお持ちの方テキスト内の記述について構文 [ ] 省略可能 { A B } A または B のどちらかを選択 n _ 数値の指定デフォルト値