Cの大規模なサービスが提供され、多くの利用者を集めています。そのため、こうしたサービスのシステムダウンによる企業への影響も、非常に大きなものとなっています。ビジネスチャンス・売り上げのロストはもちろん、場合によっては企業への信頼低下につながるかもしれません。Availability)を検討することは非常に重要です。単一障害点)を解消する必要があります。一般的にデータベースを用いたシステムでは、SPOFの解消をシステム構成の二重化(クラスタ)で実現します。図1の例では、全く同一のハードウェアをActive/Standby構成で用意し、クラスタソフトによりアプリケーション・ハードウェアを監視しています。障害発生時には待機系のサーバに切り替え、障害発生によるダウンタイムを減少させます。(障害発生時)Active/Standby構成クラスタの課題Active/Standby構成によるクラスタでは、SPOFを解消し、可用性を向上させることができますが、以下のような課題も存在します。通常、待機系サーバには稼動系サーバと同様のハードウェアを用います。Active/Standbyという名のとおり、平常時のStandby機は起動しているだけで、計算機リソース(CPU・メモリ)が有効活用されません。稼動系ノードで障害が発生した場合には、クラスタソフトウェアや構成により挙動は若干異なるものの、大きく分類して以下の処理が実施されます。必要になる場合があります。構成では可用性要件を満たせないことが懸念されます。RACには以下の特徴があります。RACはActive/Active型かつ共有データベース(シェアードエブリシング)型のクラスタ構成であるということです。これは、複数インスタンスからの共有データベースへの同時更新を、高速に処理しなければならないことを意味します。Fusionなのです。Fusion実装へ至るクラスタデータベースの進化について紹介します。RACの前身であるOPSは、複数のOracleインスタンスから単一のデータベースへの同時操作を可能にしました。OPSのアーキテクチャ上の特徴は以下のとおりです。OPSの構成OPSでは分散ロックマネージャ(DLM)を用い、複数ノードからの共有データベースへの同時更新を制御しています。PCMロックには大きく分類すると三つのモードがあります。DBブロックの読み込み用に共有可能なロック。参照時に取得されます。他インスタンスとは共有不可能なロック。更新時に取得されます。どのインスタンスもPCMロックを保有していません。ノード間でのデータブロック競合が起こる状況は、以下の四つに分類できます。更新中のブロックに対する別ノードからの更新リクエストread/readの場合にはPCMロックの競合は発生しませんが、その他の競合状況では、PCMのロック変換処理と共有ディスクを介してのデータブロックのノード間受け渡しが必要となります。I/Oを伴うPING処理の発生を、アプリケーションやデータベースの物理設計の工夫によっていかに抑えるかという点が、OPSを扱う上で非常に重要でした。lock方式を利用していました。このロック方式は1つのロックで複数ブロックをロックしてしまうため、PCMロック変換およびPING発生という面で効率が悪いものでした。Locking(DBAロック)という、ロック1つでデータブロック1つをロックできる方式が使用可能になったため、主に参照系のデータウェアハウス処理でOPSが使用されるようになりました。全プラットフォーム共通の機能として実装されました。適用が可能となりました。このように、PCMロックの変換、それに伴うDISK経由でのデータブロック受け渡し(PING)を抑制するため、OPSを扱う技術者には経験・スキルが求められました。各ノードがアクセスするデータ領域を分割し、書き込みやデータローディングを制御する。競合発生抑制の為のパラメタ設定やエクステントの事前割り当てといった工夫が必要でした。Fusionが実装されました。(write/write)を含む全てのパターンでインターコネクト回線を用いた高速ブロック転送が行われるようになったのです。RACは性能面でもスケールアウトするようになり、ほぼ全ての業種・業務において、特段の工夫なく適用可能になりました。RAC以降GCSロックと呼ばれるようになりました。Directory(GRD)として扱われるようになりました。Fusionが行われる様子を実例を交えて解説します。Fusionの基本的な動作について説明しておきましょう(図5)。GRDで管理されている各データブロックには、「マスターノード」が存在します。Fusionを行います。Fusionは、基本的には3ノードのメッセージ交換により処理が完結するのです。続いて、以降の解説で利用するサンプルテーブルやスクリプトを紹介します。実例で使用するサンプルテーブルは以下のとおりです。(30)バッファキャッシュ上のGCSロックホルダー状態を確認したSQL文は以下のとおりです。確認SQL】と記載します。10046というSQLトレースの拡張機能を用いて取得しています。環境はローカル管理表領域、手動セグメント管理(フリーリスト管理)の表領域上に構築されています。以降の図示による解説では3ノード以上のRAC環境を想定していますが、実例は2ノードRACによる確認結果となります。:Node2上でSCOTTユーザのEmployee表が検索(SELECT)されています。:Node1はマスターノードであるNode3に対して、共有モード(Share)でのリクエストを出します。:マスターノードであるNode3は、Node2がブロックを保持していることを認識しているため、インターコネクト経由でのPINGメッセージをNode2に送り、ロックの許可を行います。:Node2は、インターコネクト経由でブロックをNode1に送ります。node2にて以下SQLを発行します。なっているため、CURRENTブロックを共有モードで保持していることを示しています。以下SQLを発行します。その結果、バッファキャッシュ上のGCSロックの状態は以下のように変化しました。SCURの状態でデータブロックを保持していることが確認できます。発行した際のSQLトレース(event10046)結果を確認しますと、以下が確認されました。Fusionにより転送されていることが確認されます。:Node2上でSCOTTユーザのEmployee表が検索(SELECT)されています。:Node1はマスターノードであるNode3に対して、排他モード(Exclusive)でのリクエストを出します。:マスターノードであるNode3は、Node2がブロックを保持していることを認識しているため、インターコネクト経由でのPINGメッセージをNode2に送り、ロックの許可を行います。:Node2は自分のロック(共有モード)をクローズし、インターコネクト経由でブロックをNode1に送ります。Read)となります。今後はCR要求を受けた際に使用されます。node2にて以下SQLを発行します。なっているため、CURRENTブロックを共有モードで保持していることを示しています。以下SQLを発行します。その結果、バッファキャッシュ上のGCSロックの状態は以下のように変化しました。node1にてXCURブロックとして、すなわちCURRENTブロックが排他モードで取得されていることが確認できます。発行した際のSQLトレース(event10046)結果を確認しますと、以下が確認されました。Fusionにより転送されていることが確認されます。:Node2上でSCOTTユーザのEmployee表が更新(UPDATE)されています。:Node1上で、SCOTTユーザのEmployee表を検索(SELECT)します。このときに、読み込み要求は一貫性読み込みのため、CR要求となります。:マスターノードであるNode3は、Node2がブロックのコピーを獲得し、ロールバックしなくてはならないことを伝えます。:Node2は現行ブロックにUNDOセグメントを適用し、CRブロックを生成します。:CRブロックが転送されます。node2にて以下SQLを発行します。なっているため、CURRENTブロックを排他モードで保持していることを示しています。以下SQLを発行します。その結果、バッファキャッシュ上のGCSロック状態は以下のように変化しました。node1のV$BH確認SQL発行結果node2のV$BH確認SQL発行結果node2にてCRブロックが作成され、node1に転送されていることが確認できます。発行した際のSQLトレース(event10046)結果を確認しますと、以下が確認されました。FusionによりCRブロックとして転送されていることが確認されます。:Node2上でSCOTTユーザのEmployee表が更新(UPDATE)されています。:Node1はマスターノードであるNode3に対して、排他モード(Exclusive)でのリクエストを出します。:マスターノードであるNode3は、Node2がブロックを保持していることを認識しているため、インターコネクト経由でのPINGメッセージをNode2に送り、ロックの許可を行います。:Node2は、ブロックを保持したまま、インターコネクト経由で変更済みブロック(ダーティーブロック)をNode1に送ります。この際に、Node2の持つブロックはパストイメージ(PI)となり、PIは障害回復からのリカバリにおいて使用されます。node2にて以下SQLを発行します。なっているため、CURRENTブロックを排他モードで保持していることを示しています。以下SQLを発行します。その結果、バッファキャッシュ上のGCSロック状態は以下のように変化しました。node1のV$BH確認SQL発行結果node2のV$BH確認SQL発行結果node1にXCURモードでデータブロックが保持され、もともと保持していたnode2のデータブロックはPI(パストイメージ)に変更されたことが確認されます。発行した際のSQLトレース(event10046)結果を確認しますと、以下が確認されました。Fusionにより転送されていることが確認されます。RACは高いスケーラビリティと、アプリケーションからの透過性というメリットを得られたのです。RAC環境でパフォーマンスを監視する際のポイントについてご紹介します。profileや待機イベントの様子から、データベースの状態監視やボトルネックの検出が可能です。Fusion」の項に記載しているとおり、シングルデータベースとは異なるクラスタ固有の処理が行われています。Fusionが多発し、処理遅延が発生することもあり得ます。いったボトルネックが、statspackの取得間隔(例えば30分おき)の間に恒久的に発生している場合はstatspackレポートによる解析が可能ですが、ある一瞬の間のボトルネックであった場合には、一瞬の処理遅延あるいは待機が大きかったとしても、全体(取得間隔の30分)から見ると均一化されてしまうため、statspackレポートからの解析を行うことは困難となります。(例えば5秒間隔など)に取得する必要があります。取得した情報を解析する際にも考慮が必要です。10g以降では、バックグラウンドプロセスMMONとMMNLがアクティブセッションの待機イベントを常に記録します。History(ASH)を使用することによって、V$ACTIVE_SESSION_HISTORYやDBA_HIST_ACTIVE_SESS_HISTORYから待機イベントの履歴を確認できるようになりました。Managerを用いることにより、視覚的に待機の状態を確認することも可能になりました。Managerから待機イベントクラス「Cluster」で遅延が発生していることを確認これらのツールを有効に用いることが、ワークロードの管理をするうえでたいへん重要です。reserved.無断転載を禁ずこの文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。本書の内容に関連したいかなる損害についても責任を負いかねます。Corporationの登録商標です。文中に参照されている各製品名及びサービス名は米国OracleCorporationの商標または登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります。Managerを駆使することも重要だと気づきはじめる。Choices採用FacebookTwitterLinkedInYouTube。