Oracle Database In-Memory 高可用性ベスト・プラクティス

Size: px

Start display at page:

Download "Oracle Database In-Memory 高可用性ベスト・プラクティス"

あゆみかつもと
4 years ago
Views:

1 Oracle Database In-Memory

2 1 Oracle Database In-Memory

3 2 Oracle Database In-Memory

4 3 Oracle Database In-Memory

5 parallel_degree_policy SQL> ALTER TABLE customers INMEMORY PRIORITY NONE DUPLICATE ; SQL> ALTER TABLE customers INMEMORY DUPLICATE ALL; parallel_degree_policy 4 Oracle Database In-Memory

6 $ srvctl stop service service prod_dbim_fan database dbm instance dbm1 $ srvctl disable service -service prod_dbim_fan database dbm instance dbm1 5 Oracle Database In-Memory

7 SELECT v.inst_id, v.segment_name name, v.partition_name, v.populate_status status, v.bytes/1024/1024 bytes_mb, v.bytes_not_populated/1024/1024 bytes_not_pop_mb, (v.bytes-v.bytes_not_populated)/1024/1024 bytes_populated_mb FROM gv$im_segments v WHERE v.owner = '&owner_name' ORDER BY 1 bytes_not_populated SELECT v.segment_name name, v.partition_name, 2*max(v.bytes)/1024/1024 tot_mirrored_bytes_mb, sum(v.bytes-v.bytes_not_populated)/1024/1024 tot_bytes_populated_mb FROM gv$im_segments v WHERE v.owner = '&owner_name' GROUP BY v.segment_name, v.partition_name ORDER BY 1 $ srvctl enable service -servcce imquery database dbm instance dbm1 $ srvctl start service service imquery database dbm instance dbm1 6 Oracle Database In-Memory

8 複製モード並列度のポリシー表または問合せのDOP 設定アプリケーションに使用されるパラレルインスタンスグループサービス再移入時に使用されるパラレルインスタンスグループサービス利点 DUPLICATE AUTO AUTO* すべてのインスタンスを含み接続サービスとは異なるすべてのインスタンスを含み接続サービスとは異なる» 単一インスタンス障害の影響がほとんどない» IM の能力が最大化される DUPLICATE LIMITED または MANUAL 非推奨 PQ のアフィニティ設定は不可 DUPLICATE ALL AUTO LIMITED または MANUAL AUTO または MANUAL マネージド接続サービスと同じすべてのインスタンスを含み接続サービスとは異なる» 複数のインスタンス障害への耐性» parallel_degree_policy = LIMITED または MANUAL の使用が可能 7 Oracle Database In-Memory

9 prod_dbim_fan prod_dbim prod_dbim parallel_instance_group parallel_degree_policy= AUTO parallel_instance_group = prod_dbim 8 Oracle Database In-Memory

10 parallel_degree_policy AUTO MANUAL 9 Oracle Database In-Memory

11 parallel_instance_group prod_dbim parallel_instance_group prod_dbim parallel_instance_group prod_dbim_fan parallel_degree_policy = AUTO MANUAL AUTO MANUAL parallel_instance_group = prod_dbim_fan 10 Oracle Database In-Memory

12 parallel_degree_policy AUTO ALTER TABLE lineorder EXCHANGE PARTITION p1 WITH TABLE lineorder_tab; 11 Oracle Database In-Memory

13 停止停止のシミュレーションプロセスアプリケーションへの影響と観察事項 DBノードの計画保守作業 1. すべてのインスタンスのインメモリ列ストアが事前にロードされている状態でワークロードを起動 2. 1 つのインスタンスで正常にサービスを停止 3. 影響を受けたインスタンスのサービスを無効化 4. すべての接続が他のノード上のインスタンスに移動されたことを確認 5. インスタンスまたはノードを停止 6. ノード上で保守作業を実行 7. インスタンスまたはノードを再起動 8. 問合せを実行し再起動されたインスタンスのインメモリ列ストアをロード 9. 影響を受けたインスタンスですべての表が In- Memory にロードされるまで待機 10. 影響を受けたインスタンスのサービスを有効化 11. 影響を受けたインスタンスのサービスを起動 12. 再起動されたインスタンスを使用しているクライアントを観察サービスの強制停止 1. アプリケーションにアプリケーションコンティニュイティが構成されていて ORA エラーまたはORA-40エラーの後にエラーを捕捉して再試行できることを確認 2. ワークロードを起動 3. 1 つのインスタンスで強制的にサービスを停止 4. 同じインスタンスでサービスを再起動 5. 再起動されたサービスに徐々にロードが戻ることを観察再構成時の Oracle RAC 内のアプリケーションへの影響は最小限 ( ただし保守作業時にインスタンスの停止と再起動を要求した場合 ) 次の理由により障害発生時に一時的に応答時間のスパイクが発生 : 問合せの中断アプリケーションコンティニュイティが使用される際の問合せの再実行 / 再現インスタンス障害やインスタンス再起動は発生していないためインメモリ列ストアの再ロードは不要データベースインスタンス障害 1. ORA エラーまたは ORA-40 エラーの後にこれらを捕捉して再試行できることを確認 2. ワークロードを起動 3. 1 つのインスタンス上で SMON を kill 4. 影響を受けたインスタンスのサービスをすみやかに無効化 5. インスタンスが再起動するまで待機 6. 問合せを実行して In-Memory 表を強制的にロードし表のロードが完了するまで待機 7. 影響を受けたインスタンスでサービスを再有効化 8. 再起動されたインスタンスに徐々にロードが戻ることを観察次の理由により障害発生時に一時的に応答時間のスパイクが発生 : 問合せの中断 Oracle RAC の再構成アプリケーションコンティニュイティが使用される際の問合せの再実行 / 再現障害を起こしたインスタンスがクラスタに再結合するとき一時的に応答時間のスパイクが発生 12 Oracle Database In-Memory

14 データベースノード障害 1. ORA-12805エラーまたはORA-40エラーの後にこれらを捕捉して再試行できることを確認 2. ワークロードを起動 3. データベースノードの電源を停止 4. 影響を受けたインスタンスのサービスをすみやかに無効化 5. 電源を投入しインスタンスが再起動するまで待機 6. 問合せを実行して In-Memory 表を強制的にロードし表のロードが完了するまで待機 7. 影響を受けたインスタンスでサービスを再有効化 8. 再起動されたインスタンスに徐々にロードが戻ることを観察次の理由により障害発生時に一時的に応答時間のスパイクが発生 : 問合せの中断 Oracle RAC の MISCOUNT による遅延 ( 通常 1 分 ) この待機時間は BP7 以上のエンジニアドシステムでは数秒に短縮されています Oracle RAC の再構成アプリケーションコンティニュイティが使用される際の問合せの再実行 / 再現障害を起こしたインスタンスがクラスタに再結合するとき一時的に応答時間のスパイクが発生データベース障害時の Data Guard フェイルオーバー 1. ワークロードを起動 2. スタンバイデータベースのサービスが無効化されている ( かつプライマリでは有効化されている ) ことを確認 3. クラスタ内のすべてのノードを ABORT モードで停止 4. スタンバイデータベースがオープンされるまで待機 5. 問合せを実行して In-Memory 表を強制的にロードし表のロードが完了するまで待機 6. 新しいプライマリデータベースでサービスを有効化 7. 新しいプライマリデータベースでロードが発生し始める様子を観察次の理由により障害発生時に応答時間のスパイクが発生 : 問合せの中断スタンバイのオープンキャッシュ内の In-Memory 表のロードアプリケーションコンティニュイティが使用される際の問合せの再実行 / 再現注 : データベースがプライマリとして起動した直後にクライアントやアプリケーションを接続できるようにするとデータベースおよびアプリケーションのリカバリ時間目標 (RTO) は非常に短くなります In-Memory 表があらかじめロードされるまで待機してからアプリケーションが接続できるようにすると停止時間または RTO は長くなります企業および管理者は RTO を短くするか長くするか両者の長所と短所をじっくり検討する必要があります後者を選択すると新しいプライマリデータベースに接続した直後からインメモリ問合せの応答時間が短くなります 13 Oracle Database In-Memory

15 14 Oracle Database In-Memory

16 C O N N E C T W I T H U S blogs.oracle.com/oracle facebook.com/oracle twitter.com/oracle oracle.com

MAA/Data Guard 10g Release 2セットアップ・ガイド – RACプライマリのためのRACロジカル・スタンバイ作成

MAA/Data Guard 10g Release 2セットアップ・ガイド – RACプライマリのためのRACロジカル・スタンバイ作成 MAA/Data Guard 10g Release 2 セットアップガイド - RAC プライマリのための RAC ロジカルスタンバイ作成 Oracle ホワイトペーパー 2006 年 5 月 Maximum Availability Architecture Oracle Best Practices For High Availability MAA/Data Guard 10g Release