基本: Data GuardとフラッシュバックによるOracle Database 23aiのパワーの解放- パート2 (2025/04/01)
基本: Data GuardとフラッシュバックによるOracle Database 23aiのパワーの解放- パート2 (2025/04/01)
投稿者：Francisco Munoz Alvarez | Distinguished Product Manager
前回の議論の続きから、このシリーズの第 1 部「Data Guard と Flashback による Oracle Database 23ai のパワー」で取り上げたテクノロジについて、さらに詳しく掘り下げてみましょう。 <シリーズの前の記事へのリンク>
遊びの時間
Oracle Data Guardとフラッシュバック、そしてOracle Database 23aiで導入された新機能について解説しました。次は、シンプルながらも典型的なユースケースでこれらの機能を実際に確認してみましょう。このシナリオでは、スタンバイ・データベースへのフェイルオーバー後にフラッシュバック（クエリとテーブル）を利用できるかどうかを検証します。具体的には、インカネーションが変更された場合、フラッシュバックを使用してフェイルオーバー直前に何が起こったかを確認できるかどうかを検討します。
まず、プライマリ データベース内のデータベース インカネーションの詳細を確認しましょう。
SQL> select * from v$database_incarnation; INCARNATION# RESETLOGS_CHANGE# RESETLOGS PRIOR_RESETLOGS_CHANGE# PRIOR_RES STATUS RESETLOGS_ID PRIOR_INCARNATION# FLASHBACK_DATABASE_ALLOWED CON_ID ------------ ----------------- --------- ----------------------- --------- ------- ------------ ------------------ -------------------------- ---------- 1 1 14-FEB-24 0 PARENT 1144840863 0 NO 0 2 1343420 08-FEB-25 1 14-FEB-24 CURRENT 1155034180 1 NO 0
プライマリ データベースの現在のインカネーションは 1155034180 です。次に、以下に示すように、UNDO 表領域の保持期間を 86400 に設定します。
SQL> alter system set undo_retention=86400;
System altered.HR スキーマを使用するようにセッションを設定し、現在のタイムスタンプをチェックし、更新コマンドを実行して、トランザクションをコミットします。
SQL> alter session set current_schema=HR;
Session alteredSQL> select systimestamp; SYSTIMESTAMP --------------------------------------------------------------------------- 12-FEB-25 10.24.56.272744 AM +00:00
SQL> update hr.employees set HIRE_DATE=sysdate where employee_id=100;
1 row updated.SQL> commit;
Commit complete.ここで、フラッシュバック クエリを使用して、1 時間前の hire_date の値を確認し、それを現在の値と比較します。
SQL> select hire_date from hr.employees as of timestamp systimestamp-1/24 where employee_id=100; HIRE_DATE --------- 17-JUN-03
SQL> select hire_date from hr.employees where employee_id=100; HIRE_DATE --------- 12-FEB-25
上記のように、hire_date の以前の値は 2003 年 6 月 17 日でしたが、トランザクションをコミットした後、新しい値は 2025 年 2 月 12 日になっています。プライマリデータベースがダウンした時刻とフェイルオーバーが開始された時刻を参照するために、現在のタイムスタンプを確認します。
SQL> select systimestamp; SYSTIMESTAMP --------------------------------------------------------------------------- 12-FEB-25 10.37.28.908251 AM +00:00
プライマリ インスタンスを強制的にクラッシュさせるには、データベースの pmon プロセスを強制終了します。
[ fmunoza_main ] bash-4.4$ ps -eaf | grep pmon fmunoza 1112986 1 0 FEB12 ? 00:00:49 ora_pmon_main222 fmunoza 1485907 1 0 10:29 ? 00:00:00 <b>ora_pmon_main22</b> fmunoza 1486768 1484883 0 10:37 pts/0 00:00:00 grep pmon
[ fmunoza_main ] bash-4.4$ kill -9 1485907次のステップは、Data Guard コマンドライン インターフェイス (DGMGRL) に接続し、手動フェイルオーバーを実行することです。
DGMGRL> connect /
Connected to "dgmain22b"
Connected as SYSDG.DGMGRL> failover to "dgmain22b"; 2025-02-12T10:38:31.179+00:00 Performing failover NOW, please wait... 2025-02-12T10:38:37.728+00:00 Failover succeeded; the new primary is "dgmain22b". 2025-02-12T10:38:37.729+00:00 Failover processing complete, broker ready.
フェイルオーバーが完了したので、データベース (pdb1) に接続し、データベース インカネーションのステータスを確認します。
SQL> alter session set container=pdb1;
Session altered.SQL> select * from v$database_incarnation; INCARNATION# RESETLOGS_CHANGE# RESETLOGS PRIOR_RESETLOGS_CHANGE# PRIOR_RES STATUS RESETLOGS_ID PRIOR_INCARNATION# FLASHBACK_DATABASE_ALLOWED CON_ID ------------ ----------------- --------- ----------------------- --------- ------- ------------ ------------------ -------------------------- ---------- 1 1 14-FEB-24 0 PARENT 1144840863 0 NO 0 2 1343420 08-FEB-25 1 14-FEB-24 PARENT 1155034180 1 NO 0 3 2704078 12-FEB-25 1343420 08-FEB-25 CURRENT 1155465511 2 NO 0
フェイルオーバー後に変更された新しいインカネーションは 1155465511 です。では、最初の質問に戻りましょう。フェイルオーバー後、インカネーションが変更された後も Flashback は機能しますか？それが可能かどうか確認してみましょう。
SQL> select hire_date from hr.employees where employee_id=100; HIRE_DATE --------- 12-FEB-25
SQL> select hire_date from hr.employees as of timestamp systimestamp-1/24 where employee_id=100; HIRE_DATE --------- 17-JUN-03
これは素晴らしいニュースです。上記のようにフラッシュバッククエリが機能していることはわかりますが、フラッシュバックテーブルについてはどう思われますか？動作するでしょうか？
SQL> flashback table hr.employees to timestamp sysdate-1/24; flashback table hr.employees to timestamp sysdate-1/24 * ERROR at line 1: ORA-08189: cannot flashback the table because row movement is not enabled
フラッシュバックテーブル操作を実行するには、まず行の移動を有効にする必要があります。有効にしてもう一度試してみましょう。
SQL> alter table hr.employees enable row movement;
Table altered.SQL> flashback table hr.employees to timestamp sysdate-1/24;
Flashback completeSQL> select hire_date from hr.employees where employee_id=100; HIRE_DATE --------- 17-JUN-03
上記のシナリオは、フェイルオーバー イベントが発生した後でも、Oracle データベース内でフラッシュバックのパワーを簡単に活用できる方法を示す明確で比較的単純な例です。
Oracleの機能を活用した災害復旧戦略の推進
従来の災害復旧手法では、多くの場合、膨大な手作業、古いバックアップへの依存、そして長時間のダウンタイムが伴い、運用効率の低下やデータ損失の可能性につながります。これに対し、Oracle DatabaseのData GuardやFlashbackなどの機能を活用することで、目標復旧時間（RTO）と目標復旧ポイント（RPO）を大幅に向上させることができます。これらの高度な機能により、企業は壊滅的な障害やデータ破損インシデントが発生した場合でも、最小限の中断でデータベースシステムを迅速に復旧できます。Data Guardのリアルタイム同期機能は、フェイルオーバー操作にほぼ瞬時に対応できるスタンバイ・データベースを維持することで、継続的な保護を実現します。
サイバー攻撃による予期せぬソフトウェア破損に直面した大手金融機関のケースを考えてみましょう。Oracle Data Guardを活用することで、この金融機関は数秒以内にスタンバイ・データベースに切り替えることができ、重要な銀行サービスをトランザクションデータを失うことなく継続運用できました。迅速なフェイルオーバー機能により、本来であれば損害をもたらす可能性のあるイベント発生時においても、データの整合性が確保され、顧客の信頼を維持できました。もう一つの説得力のある事例として、グローバルeコマース・プラットフォームが、誤ったアプリケーション導入によって発生した論理エラーを検出した後、Oracle Flashbackテクノロジーを活用したケースが挙げられます。チームは、数時間にわたる大規模なバックアップをリストアする代わりに、影響を受けたオブジェクトを瞬時に以前の状態に復元し、ダウンタイムを大幅に削減し、トランザクションの一貫性を維持しました。
災害対策を戦略的に強化するには、これらの堅牢なOracle機能を包括的な災害復旧計画に統合する必要があります。組織は、Data Guard構成を徹底的にテストし、様々な障害シナリオにおいてプライマリ・データベースとスタンバイ・データベース間のシームレスなフェイルオーバー移行を確保する必要があります。フラッシュバック・テクノロジーの統合においては、自動リストア・ポイント（スナップショット）を頻繁に設定し、異常発生時に速やかに検出できるよう綿密な監視体制を維持することが推奨されます。明確なコミュニケーション・プロトコルを策定し、IT部門全体でこのテクノロジーを用いた訓練を積極的に実施することで、チームは重大なインシデント発生時に、より効果的に対応できるようになります。
Data Guardのスタンバイ機能とFlashbackの高精度なデータ修正機能を組み合わせることで、組織は物理障害や論理エラーに対する多層的な防御メカニズムを構築できます。この組み合わせにより、災害復旧の効率が向上し、今日の不安定なデジタル環境における様々な予期せぬ課題に対するレジリエンス（回復力）が強化されます。
まとめ: Oracle Databaseによる競争優位性の獲得
Oracle DatabaseのData GuardとFlashback機能を活用することで、現代のIT運用に大きなメリットがもたらされます。これらのツールは、シームレスなデータ管理、セキュリティプロトコルの強化、そして堅牢なディザスタリカバリ機能を実現します。ITプロフェッショナル、データベース管理者、そしてテクノロジー愛好家は、これらの機能を効率的に活用することで、回復力に優れた安全な環境を構築できます。
メリットは明らかです。最小限のダウンタイムによる継続的な運用の確保、高度なセキュリティ対策による重要なデータ資産の保護、そして潜在的なデータ損失インシデントからの迅速なリカバリなど、これらは主要なメリットのほんの一部です。Data GuardとFlashbackをワークフローに統合することで、効果的なリスク軽減を実現し、常に進化するテクノロジー環境において常に一歩先を行くことができます。これらの強力な機能を活用することで、Oracle Databaseシステムの潜在能力を最大限に引き出しましょう。
参考文献:
コメント
コメントを投稿