Oracle RAC 概要/パート1

負荷の高いサイト、5ナインの可用性。 バックグラウンド（バックエンド）で、データベース内の処理された情報の束。 しかし、ハードウェアに欠陥が生じた場合、OSの長期のエラーがクラッシュした場合、ネットワークインターフェイスはドロップしますか？ 情報の入手可能性はどうなりますか？ 好奇心から、上記の問題を解決するためにオラクルが提供するソリューションを検討することにしました。 Oracle 9iとは異なり、最近のバージョンはOracle 10g（または11g）と呼ばれます。gはグリッド、分散コンピューティングを意味します。 分散コンピューティングの中心にあるのは、クラスターと、追加のデータ複製テクノロジー（DataGuard、Streams）です。 この記事では、Oracle 10gベースのクラスターの仕組みについて概説します。 Real Application Cluster （ RAC ）と呼ばれます。



この記事は完全で包括的なふりをしておらず、設定も除外されています（ボリュームが増加しないように）。 ポイントは、RACテクノロジーのアイデアを伝えることです。



PSムノガブカフに注意してください

記事の続き







Oracle DBMSを初めて使用する人でも読みたいと思うように、できるだけアクセスしやすい記事を書きたいと思いました。 したがって、同じ物理サーバー上に1つのOracleデータベース（RDBMS）がある場合、最も一般的なデータベース構成の側面（シングルインスタンス）から説明を始めます。 これはクラスターに直接関係しませんが、基本的な要件と操作の原則は同じです。

はじめに 単一インスタンス。

単一の物理サーバーにインストールされる最も一般的なデータベースは、 single-instanceと呼ばれます 。 データベースのインスタンスとデータベース自体（一般的に）という概念の違いをあまり重要視していませんでした。 ここで、インスタンスとは、RAMに配置され、ディスクから直接受信したデータ（並べ替え、バッファリング、メンテナンス）を処理するソフトウェア（プロセス、スレッド、サービス）を意味します。 したがって、データベースとは次の組み合わせを意味します。

• データストレージエリア、すなわち ディスク上の物理ファイル（データストレージ）（データベース自体）
• DBインスタンス（RAMでこのデータを受信および処理）（DBMS）

現代のすべてのリレーショナルデータベースでは、データはテーブルに格納されます。 Oracleのテーブル、インデックス、およびその他のオブジェクトは、論理コンテナ（ テーブルスペース）に格納されます 。 物理的には、テーブルスペースはディスク上の1つ以上のファイルにあります。 次のように保存されます。

各データベースオブジェクト（テーブル、インデックス、ロールバックセグメントなど）は、個別のセグメント （1つ以上のファイルのスペースを占有できるディスク領域）に格納されます。 セグメントは、1つ以上のエクステントで構成されます。 エクステントは、ファイル内の連続したスペースです。 エクステントはブロックで構成されています。 ブロックは、Oracleのスペース割り当ての最小単位であり、デフォルトは8Kです。 ブロックには、データの行、インデックス、または中間ロックの結果が格納されます。 Oracleサーバーが通常ディスクに読み書きするのはブロックです。 ブロックには、いわゆるDBA （ データベースブロックアドレス ）というアドレスがあります。











DML（データ操作言語）がデータベースにアクセスするたびに、Oracleは対応するブロックをディスクからRAM、つまりバッファーキャッシュにロードします。 既に存在している可能性がありますが、ディスクにアクセスする必要はありません。 要求がデータを変更した場合（更新、挿入、削除）、ブロックの変更はバッファキャッシュで直接発生し、ダーティとしてマークされます。 ただし、ブロックはすぐにはディスクにフラッシュされません。 結局のところ、ディスクはデータベースのボトルネックであるため、Oracleはできるだけディスクにアクセスしようとしています。 ダーティブロックは、チェックポイントを通過するとき、またはログを切り替えるときに、バックグラウンドDBWnプロセスによってディスクに自動的にフラッシュされます。









データを読み取る1つの長いトランザクションが起動され、その実行プロセスのどこかで、読み取られるブロックの1つを変更する意図で別のトランザクションが起動されたとします。 サーバーはこれらの要求をどのように調整しますか？ 実際、質問は2つに分かれています。

1. Oracleが長いトランザクションの途中に落ちた場合（変更を加えた場合）はどうなりますか？
2. 最初のトランザクションは、そのキャッシュ内の「鼻の下」で別のトランザクションがブロックを変更したときにどのデータを読み取りますか？

これらの質問に答えるには、 CRの 一貫した読み取り （ 一貫性読み取り ）を確保するためのメカニズムを検討してください 。 それはすべて、トランザクションログの魔法の泡に関するもので、Oracleでは2つのタイプで表されます。

• REDOログ
• セグメントを元に戻す

データベースで変更要求を受信すると、Oracleはそれをバッファキャッシュで使用すると同時に、メインメモリにあるREDOログバッファにこのアクションを繰り返すのに十分な情報を入力します。 トランザクションが完了するとすぐにコミット（コミット）され、サーバーは追加書き込みモードでREDOログのディスクにREDOバッファログの内容をフラッシュし、トランザクションをコミットします。 このアプローチは、変更されたブロックディスクに直接書き込むよりもはるかに安価です。 サーバーがクラッシュすると、キャッシュとその中のすべての変更は失われますが、REDOログファイルは残ります。 オンにすると、Oracleはそれらを確認し、データファイルに反映されなかったテーブルの変更（トランザクション）を再実行することから開始します。 これは、REDO、ロールフォワードからの「ローリング」変更と呼ばれます。 オンラインREDOログは、トランザクションの確認時、チェックポイントの通過時、または3秒ごと（デフォルト）にディスクにフラッシュされます（ LGWR ）。



元に戻すにはもう少し複雑です。 隣接セグメントの各テーブルには、それに関連付けられたキャンセルセグメントが格納されます。 テーブルブロックと共にDMLをクエリする場合、ロールバックセグメントからのデータは必ず読み込まれ、バッファキャッシュにも格納されます。 テーブル内のデータがキャッシュ内で変更されると、取り消しデータもキャッシュ内で変更され、「対策」がそこに追加されます。 つまり、挿入がテーブルに入力された場合、削除がロールバックセグメントに追加され、削除-挿入、更新-前の行の値が入力されます。 ブロック（および対応するUNDOデータ）はダーティとしてマークされ、REDOログバッファーに入れられます。 はい、はい、命令はREDOのログに書き込まれるだけでなく、どの変更を加える価値があるか（やり直し）だけでなく、それらの対抗点も何ですか（元に戻す）。 LGWRは3秒ごとにREDOログバッファーをフラッシュするため、長いトランザクションが失敗すると（数分間）、1分後にサーバーがクラッシュすると、REDOは不完全なコミットエントリを持ちます。 Oracleは、起動時にロールバック（ロールフォワード）し、メモリデータロールバックセグメントで（REDOログから）リカバリされたすべてのコミットされていないトランザクションをロールバック（ロールバック）します。 正義が回復した。



簡単に言及する価値があるのは、取り消しセグメントのもう1つの議論の余地のない利点です。 2番目のシナリオ（図から）では、selectがDBA 500ブロックの読み取り値に達すると、このブロックがキャッシュ（ダーティマーク）で既に変更されていることが突然検出されるため、ブロックの対応する前の状態を取得するためにロールバックセグメントに切り替えます。 そのような以前の状態（フラッシュバック）がキャッシュに存在しなかった場合、ディスクからそれを読み取り、selectの実行を継続します。 したがって、長い「簿記からの選択数（金額）」の借方が貸方と一致します。 一貫した読み取り（CR）。

気が散る。 クラスタ構成へのアプローチを探す時が来ました。 =）

データアクセスレベル。 ASM。

大規模データベースのストレージ（ datastorage ）は、ほとんどの場合SAN （ Storage Area Network ）であり、ディスクアレイのサーバーへの透過的なインターフェイスを提供します。

サードパーティのメーカー（Hitachi、HP、Sun、Veritas）は、多くのプロトコル（最も一般的なものはファイバーチャネル）に基づいて、SANを整理するための包括的なソリューションを提供します。ミラーリング、ロードバランシング、ドライブのオンザフライ接続、パーティション間のスペースの割り当て、 .tp

あらゆる規模のデータベースの構築に関するOracle Corporationの立場は、可能であれば（Oracleの購入後に資金が残っている場合:)、適切なライセンスを備えたOracleの適切なソフトウェアと選択した機器のみが必要であるという事実に基づいています。 したがって、高負荷のデータベースを構築するには、無料のLinuxサーバーと安価なRAIDアレイを使用して、高価なSPARCサーバーと詰め込みSANを使用せずにできます。



データとディスクへのアクセスのレベルで、オラクルはソリューション-ASM （ 自動ストレージ管理 ）を提供しています。 これは、各クラスターノードに個別にインストールされ、ディスク管理サービスを提供するOracleのミニインスタンス（INSTANCE_TYPE = ASM）です。



Oracleはディスクアクセスを回避しようとします これはおそらくデータベースの主なボトルネックです。 Oracleにはデータをキャッシュする機能がありますが、ファイルシステムはディスクへのバッファ書き込みも行います。 なぜデータを2回バッファリングするのですか？ さらに、Oracleがトランザクションを確認し、ファイルに変更が加えられたという通知を受け取った場合、データベースが「クラッシュ」した場合に備えて、キャッシュ内ではなくそれらがすでに存在していることが望ましい。 したがって、RAWデバイス（ファイルシステムのないディスク）を使用することをお勧めします。これにより、ASMが作成されます。



ASMはRAWデバイス上で実行され、その利点は次のとおりです。

• 個別のディスクパーティション管理ソフトウェアは不要
• ファイルシステムは不要

ディスクグループ -複数のディスクの組み合わせ。 ファイルをディスクに書き込む場合、データは1 MBのエクステントで書き込まれ、グループ内のすべてのディスクに分散されます。 これは、1つのテーブルの一部（テーブルスペースから）が異なる物理ディスクに分散しているため、高可用性を確保するために行われます。



ASMの機能：

• データミラーリング：
  
  通常、2または3ステップ、つまり データは2枚または3枚のディスクに同時に書き込まれます。 ミラーリングの場合、ドライブには、データのコピーが配布されるパートナーディスクが8つ以下で示されます。
• 自動ディスク負荷分散（高可用性の確保）：
  
  テーブルスペースデータが10個のディスクに配置され、ある時点で特定のディスクからのデータの読み取りが「ロールオーバー」すると、ASMは同じエクステントをミラーディスクに配置します。
• 自動リバランス：
  
  ドライブが削除されると、ASMはそのドライブに含まれるエクステントを、グループ内の他のドライブにその場で複製します。 ディスクをグループに追加すると、グループ内のエクステントが移動し、各ディスクにほぼ同じ数のエクステントが存在するようになります。

複数のディスクが特定のコントローラーに接続されている（つまり、SPFである）単一点障害（コントローラーに障害が発生すると、ディスクアレイ全体が失われる）を想定します。 ASMには、ディスクグループ内に障害グループを定義するためのテクノロジーがあります。 このメカニズムを使用すると、ミラーリングは、たとえばSANまたはRAIDコントローラーが停止した場合に、 SPF （ 単一障害点 ）を回避するために、異なる障害グループにあるディスク全体にエクステントのコピーを分散させます。



したがって、クラスターは共有ファイルストレージからデータを保存および読み取ることができます。

レベルアップの時間です。

クラスタウェア CRS

このレベルでは、クラスターノードの調整と共同作業を保証する必要があります。 クラスタウェア層：データベースインスタンス自体とディスクストレージの間のどこか：



CRS （ Cluster-Ready Services ）-ノード間のコラボレーション、耐障害性、高いシステム可用性、および障害後のシステム回復を保証するサービスのセット。 CRSは、各クラスターノードにインストールされたデータベース（ソフトウェア）の「ミニインスタンス」のように見えます。 CRSのインストール-Oracle RACの構築に必須。 CRSは、HPやSunなどのサードパーティ製のクラスタウェアソリューションと統合することもできます。



再び小さな「用語」...



CRSは3つの主要なコンポーネントで構成されています。

• CSSD-クラスター同期サービスデーモン
• CRSD-Cluster Ready Servicesデーモン
• EVMD-イベントモニターデーモン

x	目的（簡単に）	どんな権利で動作しますか	プロセスが終了すると、再起動します。
CSSD	クラスター環境でのノードの相互作用のための同期メカニズム。	ユーザー	プロセス
CRSD	リソースの可用性をサポートするメインエンジン	根	ホスト
EVMD	クラスターで発生するイベントのアラートプロセス	ユーザー	プロセス

クラスタ設定は、 OCR （ Oracle Cluster Registry ）に保存されます 。 OCRは、現在の構成を格納するデータベースノードプロファイルの特別なファイルです。ノードの可用性、サービスの分散（クラスター内のノードの異なるグループによって複数のデータベースをサポートできます）、ネットワーク設定など。 物理的に、OCRは共通のデータストレージに格納されます。 クラスタ操作中、各ノードはOCRをメモリに保存し、1つのノード（マスター）のみがディスク上で直接OCR更新を実行します。



タブレットから明らかになったように、最も重要なプロセスである「最も強力なデーモン」はCRSD （ Cluster Ready Services Daemon ）です。 彼の責任には、ノードの起動、停止、障害ログの生成、ノードのクラッシュが発生した場合のクラスターの再構成、クラッシュの回復とOCRプロファイルファイルの保守が含まれます。 デーモンがクラッシュすると、ホスト全体が再起動します。 CRSはOCRリソースを管理します：グローバルサービスデーモン（GSD）、ONSデーモン、仮想インターネットプロトコル（VIP）、リスナー、データベース、インスタンス、およびサービス。



CSSD （ クラスター同期サービスデーモン ）サービスの役割には、クラスターノードの相互作用の調整、ノードとノード間のリソースの同期、次の機能による可用性の決定が含まれます。

• ノードメンバーシップ（NM）。 毎秒、ノード間のハートビートをチェックします。 NMは、いわゆる投票ディスクにアクセスできる他のノードも表示し（複数ある場合は、少なくとも大多数）、そこに通常のエントリを作成します。 ノードがハートビートに応答しないか、投票ディスクに数秒間エントリを残さない場合（Linuxの場合は10、Solarisの場合は12）、マスターノードはクラスタから除外します。
• グループメンバーシップ（GM）。 この機能は、後続のクラスター再構成のために、ノードがクラスターに追加/削除/ドロップアウトされたときのタイムリーな通知を担当します。

CSSDは、現在ノードに含まれているノードとインスタンスに関する動的な情報を提供し、クラスター内のリソースのロックを担当します。



クラスター内の情報提供者はEVMD （ Event Manager Daemon ）であり、ノードにイベントを通知します：ノードが実行されている、通信が失われている、復元されていること。 CRSDとCSSDの間のブリッジとして機能します。 アラートは、SMS（電子メールなど）を介してアラートを送信できるユニバーサルOracleゲートウェイであるONS（Oracle Notification Services）にも送信されます。



クラスターは、次のスキームに従って開始します：CSSDはOCR共有リポジトリーから読み取り、クラスター構成を読み取って投票ディスクの場所を特定し、投票ディスクを読み取ってクラスター内のノード（バラ）の数とその名前を見つけ、隣接ノードとの接続を確立しますIPCプロトコル。 ハートビートを交換することにより、すべての隣接ノードが上昇したかどうかを確認し、現在の構成で誰がマスターとして識別されているかを見つけます。 最初のマスターノードがマスターノードになります 。 開始後、実行中のすべてのノードがマスターに登録され、その後、リソースに関する情報が提供されます。



CRSまでは、データベースインスタンスがノードにインストールされます。

ノードは、プライベートネットワーク-Cluster Interconnect - IPCプロトコル（ プロセス間通信 ）を介して互いに通信します。 要件には、高帯域幅と低遅延があります。 高速バージョンのイーサネット、サードパーティソリューション（HP、Veritas、Sun）、または成長中のInfiniBandに基づいて構築できます。 後者は、高スループットに加えて、カーネルレベルの呼び出しを必要とせずに、アプリケーションバッファーから直接書き込みおよび読み取りを行います。 トップIP LinuxではUDP、WindowsではTCPを使用することをお勧めします。 また、相互接続を介してパケットを送信する場合、遅延のために6〜15ミリ秒の範囲内に保つことをお勧めします。



記事の続き