ミラーリングするか、しないか、それが問題だ (2021/06/01)

ミラーリングするか、しないか、それが問題だ (2021/06/01)

https://blogs.oracle.com/maa/to-mirror-or-not-to-mirror-thats-the-question

投稿者：Pieter Van Puymbroeck | Product Manager (Active) Data Guard and Flashback

この質問は、しばしば別の質問から始まります。"どうすれば、データ損失をゼロにし、ダウンタイムを最小限に抑えて、データベースを保護することができますか？どのようなインフラで運用されているかに関わらず、これは非常に良い、一般的で有効な質問です。


データベースの規模が大きくなればなるほど、ソリューションはより創造的になり、その創造性には複雑さとトレードオフが伴います。しかし、適切なディザスタリカバリを実現する唯一の方法は、データを少なくとも1つの他の物理的なサイトに複製することです。これは広く受け入れられている答えであり、シンプルに聞こえますよね？


AからBにデータを転送する方法はいくつかありますが、ここからが面白いところです。ソフトウェアをもっと単純な例に例えると、ネジで視覚化することができます。壁にネジを刺すのにハンマーは使いませんよね？ねじを傷つけてしまうか、意図したようにきれいに壁にねじを打ち込むことができずに壁を傷つけてしまうかのどちらかです。最終的にはうまくいくでしょうが、この作業にはハンマーよりもドライバーの方が適していることは間違いありません。


ソフトウェアにも同じ原則があります。仕事に適したツールを使うことです。


ここでは、Oracle Databaseの適切な保護に焦点を移しましょう。サードパーティのアプリケーションはさておき、このブログ記事では、ストレージレプリケーションと、この技術をOracle Databaseに使用したときに何が起こるのか、あるいは起こりうるのかに焦点を当てます。


ストレージレプリケーション技術の内部を見ると、「書き込まれたものは、宛先側にも書き込まれる必要がある」という非常にシンプルな原則を使用していることを理解する必要があります。これは非常に堅実でシンプルな原則だと思いますよね？そうではありません。もしその1回の書き込みでデータベースが壊れてしまったら？メカニズムはそのブロック内で何が起こっているかを知らず、喜んでデスティネーションにも送ります。つまり、その時点で、両方のサイトで同じ破損が発生するため、スタンバイサイトを失ってしまうのです。最近のシステムでは、書き込みがシステムから2回発行されるため（アレイAに1回、アレイBに1回）、エラーになりにくいというのがよく使われる議論です。しかし...もし、書き込みによって論理的にデータベースが破損したらどうでしょうか？両方のサイトが再び使えなくなり、手遅れになるまで気づかないことが多いのです。


つまり、ブロックの破損は検出できないが、ストレージのレプリケーションでデータベースを保護できるということですね？しかし、実際にはそうではありません。例えば、誤ってファイルを削除してしまったらどうでしょう？その削除が複製され、リモートサイトでもファイルが失われ、同じような悲惨な状況になってしまいます。スタンバイを使用する可能性のあるユースケースを拡大すると、さらに良くなりません。

レプリケーションが行われている間に、読み取り専用の分析クエリやレポートをリモートサイトにオフロードしたい場合はどうでしょうか？ミラーリングされたコピーはこのような用途には使用できません。つまり、ワークロードをオフロードする技術を失うだけでなく、そうすることで得られるスタンバイ環境の継続的な運用検証も失うことになります。このように、ストレージレプリケーションはデータを忠実にコピーしますが、あらゆる種類の破損も忠実にコピーしてしまい、最悪の場合、ミラーサイトが使えなくなってしまうということがわかりますね。


それは今でも続いています。先日、ヨーロッパに200以上の実店舗と約3万人の従業員を抱える大手小売企業の会議に参加するよう依頼されました。彼らはディザスターリカバリープランに関する深刻な問題に直面していました。このような場合、私は喜んで手を貸し、ガイダンスを提供します。その結果、正しく設定され、十分に調整されたストレージレプリケーションシステムが問題に直面していることがわかりました。すべてのシステムは仮想化されており、Oracle Databaseを内蔵したボックスから稼働していました。ある時点で、プライマリストレージアレイがコールドシャットダウンに直面しました。そして、すべてのVMがここで稼働していることに気づいたとき、これは深刻な問題となりました。さらに悪いことに ターゲットシステムへの書き込みがすべて完了しなかったのです。これにより、環境の約75％が完全に使用できなくなりました。問題はエスカレートし、非本番環境全体をバックアップからリストアする必要があり、本番システムから新たなクローンを作成する必要がありました。幸運なことに、本番環境の書き込みは時間内に完了し、これらの環境は反対側で再び開くことができました。完全なリストア作業には10日以上かかりました。本番システムにも影響が及んでいたら、どうなっていたか想像してみてください。


これは最近のケースであり、ストレージベンダーに承認された、正しくチューニングされ構成されたシステムからのものである。良かれと思ってした予防措置にもかかわらず、このような現実のストレージ複製による災害が、現代のディザスタリカバリ構成で起こりうると安心できるでしょうか？頻繁に起こるものでしょうか？いいえ、このような大規模な災害と同様に、稀なことではありますが、実際に起こっています。


ねじの話を覚えていますか？Oracle Databaseを保護するためには、もっと優れたツールがあります。それがOracle Active Data Guardです。


MAAの重要なテクノロジーであるOracle Data Guardは、シンプルな原理で動作します。それは、REDO と呼ばれるデータベーストランザクションによって行われたすべての変更を使用することです。Data Guard は、「REDO を出荷してから、REDO を適用する」という最も単純な原則を採用しています。Redo には、Oracle Databaseがデータベース トランザクションを回復するために必要なすべての情報が含まれます。プライマリ データベースと呼ばれる本番データベースは、REDO を 1 つ以上の独立したレプリカ （スタンバイ データベースと呼ばれる）に送信します。Oracle Active Data Guard のスタンバイ データベースは、継続的にリカバリの状態にあり、プライマリ データベースとの同期を維持するために REDO の検証と適用を行います。この検証は、Data Guardでのみ行うことができます。ブロックに何が必要なのかは、データベースだけが知っています。このようにして、スタンバイデータベースに送られるデータが完全に正しいことを保証することができます。


また、Oracle Data Guard は、ネットワークやスタンバイの停止によりプライマリデータベースとの接続が一時的に切断されたスタンバイデータベースを自動的に再同期します。




こうすることで、I/Oレイヤーをバイパスし、ブロックの破損がターゲットの宛先に送られるリスクを低減します。さらに、データベース・トランザクションが多くのブロックに触れる場合、ストレージ・ミラーリングはそれらすべてのブロックを複製します。OracleのオンラインREDOログといえば、常に変化していることを思い出すでしょう! REDOの発生率が高い環境を想像してみてください。それらのブロックはすべてもう一方のボックスに配信されますが、リカバリーには必要ありません。したがって、これは単なるオーバーヘッドです。




Oracle Data Guardのレプリケーションは、転送するデータ量を大幅に削減するだけでなく、転送前にブロックが論理的に正しいかどうかを検証します。また、データはリモートサイトでも検証されます。


Oracle Data Guardは、Oracle Enterprise Editionに含まれており、スタンバイデータベースの作成と管理、役割の移行（スイッチオーバーとフェイルオーバー）の実行、スタンバイを使ったスナップショット・スタンバイモードでのリード/ライトテスト、さらにはFast-startフェイルオーバーによる自動化されたフェイルオーバーなど、Data Guardのすべての機能を提供します。これは、ストレージミラーリングだけでは実現できないことです。


スタンバイデータベースを読み取り専用で開き、その間にすべてのREDOが到着して適用されることが可能です。このリモートサイトでの読み取り専用機能、および Oracle Data Guard のその他の機能には、Oracle Active Data Guard オプションが必要です。この Active Data Guard ライセンスでは、バックアップやローリングアップグレードなどの運用作業の負荷を軽減するために、スタンバイデータベースをより便利にする追加機能が提供されます。これらの機能の好例が、19cの新機能であるDMLリダイレクションです。これにより、読み取り専用のスタンバイ・データベースに対して臨時のDMLを実行することができます。この機能については以前ブログで紹介しました。


もうお分かりだと思いますが、Oracle Active Data Guardは、Oracle Databaseに保存されている大切なデータを完全に保護する仕事に適した唯一のツールであり、本稿で取り上げたように、このアプローチがストレージレベルのレプリケーションと比較してOracle Databaseの保護に優れているのはそのためです。 レポート


For more details, refer to:
Oracle.com/goto/dataguard
Oracle.com/goto/maa
You can also follow me on Twitter at @VanPupi or Oracle MAA at @OracleMAA for new updates.

コメント

コメントを投稿

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

イメージ
Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20) https://mikedietrichde.com/2024/11/20/important-update-to-oracle-database-19c-support-timelines/ 長い沈黙は、私が隠れているという意味ではありません。つまり、今はとても忙しいということです。そして、より少ない旅行で、私はあなたのコメントにもブログと返信するより多くの時間を持っていることを願っています。それでも、Oracle Database 19cサポート・タイムラインの非常に重要な更新について説明します。 * 更新された内容 2024年11月19日現在、Oracle Database 19cのサポート・タイムラインが調整されています。 MOSノート: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールを見ると、新しい日付が表示されます。 Premier Support、2029年12月31日まで 2030年1月1日から2032年12月31日までの拡張サポート 2033年1月1日から2034年12月31日までのアップグレード・サポート これは知ることがとても大切です。 他のリリースの更新はありますか。 MOSノートの終わりにある変更ログ: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールでは、Oracle Database 21cの最新の更新も確認できます。このリリースのPremier Support期間は、2027年7月31日まで延長されました。 また、Oracle Database 23aiのパッチ適用終了日は2032年12月31日に設定されています。 Lifetime Support Policy 更新は、Oracle Technology Productsの Oracle Lifetime Support Policy (6ページ)でも確認できます。 From: Oracle Lifetime Support Policy for Oracle Technology Product s – page 6 – Nov 19, 2024 特に、次の表に示す制限事項に注意してください。 Oracle Database 1...
続きを読む

Oracle APEXのInteractive Gridで、Oracle Formsと比較して、重複行の検証を制御/通過させる方法 (2022/07/21)

イメージ
Oracle APEXのInteractive Gridで、Oracle Formsと比較して、重複行の検証を制御/通過させる方法 (2022/07/21) https://medium.com/oracledevs/how-to-control-or-pass-validation-for-duplicate-rows-in-interactive-grid-of-oracle-apex-as-compare-18f453f750bf 投稿者： Jignesh oracle Formsでは、データブロックの重複行を制御するのは非常に簡単ですが、IGの検証を制御するにはどうすればよいでしょうか。 必要な出力 ステップ1：インタラクティブグリッドのある白紙ページを作成します（私は1つの領域「IG」を作成し、インタラクティブグリッドとしてタイプを選択しました） ステップ 2: リージョンに Static ID を定義する (私の場合、リージョンは IG で、Static ID も IG です) ステップ3：複製を制御したいカラムのStatic IDを定義します ステップ4：関数とグローバル変数に移動します コード： var validity, message, ui = this.data; (function($) { function update(model) { var projKey = model.getFieldKey(“PROJECT_ID”), recObj = [], recArray = []; model.forEach(function(record, index, id) { var projid = parseInt(record[projKey], 10), // record[salKey] should be a little faster than using model.getValue in a loop meta = model.getRecordMetadata(id); if (!isNaN(projid) && !meta.deleted && !meta.agg) { recObj = {ID: id, project_id: projid}; recArray.push(recObj)...
続きを読む

Oracle APEX 24.1の一般提供の発表 (2024/06/17)

イメージ
Oracle APEX 24.1の一般提供の発表 (2024/06/17) https://blogs.oracle.com/apex/post/announcing-oracle-apex-241 投稿者： Ashish Mohindroo | Vice President, Product Management APEX Low Code Application Platform Oracle APEX 24.1は、 ダウンロード が一般的に可能になり、世界中のOCI APEX Application DevelopmentおよびAutonomous Database Cloud Serviceリージョンにロールアウトされています。この最新リリースで、GenAIを使用して最初のローコード・アプリケーションを構築する方法を学習します。リリースのお知らせのリプレイはこちらからご覧いただけます。 このリリースでは、優れたエンタープライズ・グレードのアプリケーションを簡単に構築できるイノベーションの3つの主要な柱(AI支援アプリケーション開発、Oracleの次世代データ・プラットフォームのパワー活用、高度なWebおよびモバイル・アプリケーションを構築するための強力なエンタープライズ・グレードのコンポーネント)が提供されています。 AI支援アプリ開発 このリリースでは、AIをローコード開発に直接取り込み、すべての開発者が高度なクラウドおよびモバイル・アプリケーションを簡単に構築できるようにしています。開発者は、AIをアシスタントとして使用して、時間と労力を削減してアプリを構築できるようになりました。APEX AIアシスタントを使用すると、開発者は複数のウィンドウを使用して表名と列名を検索する必要がなくなります。 APEX 24.1 では、クラウドおよびモバイル・アプリの自然言語ベースの開発を可能にするネイティブAI搭載APEX AIアシスタントを導入しました。APEX AIアシスタントを使用すると、すべての開発者は自然言語を使用してSQLを生成できるため、アプリケーションをより簡単に構築したり、ワンクリックで構文修正を実行したり、表名を覚える必要がなくなります。開発者は、自然言語プロンプトを使用して目的の機能とコンポーネントを指定し、直感的な会話型インタフェースを使用し...
続きを読む