JP2020511708A - 自動自己修復データベースシステム及び自動自己修復データベースシステムを実現する方法 - Google Patents

Abstract

プライマリデータベースと、プライマリデータベースが利用可能なときにプライマリデータベースにデータを書き込み且つプライマリデータベースからデータを読み取るアプリケーションサーバと、プライマリデータベースの複製であるスタンバイデータベースと、自己修復モジュール（ＳＨＭ）とを含む自動自己修復データベースシステムが提供される。ＳＨＭは、プライマリデータベースの利用不能を自動的に検出することができ、スタンバイデータベースが利用可能である場合、ＳＨＭは、スタンバイデータベースを読み取り可能及び書き込み可能として自動的に有効にし、スタンバイデータベースに、他のスタンバイデータベースへのデータの複製を開始するようプライマリサイトにおけるプライマリデータベースのロールを割り当て、アプリケーションサーバとスタンバイデータベースとの間の予め確立された接続を使用してアプリケーションサーバがスタンバイデータベースからデータを読み取り且つスタンバイデータベースにデータを書き込むことを可能にし、スタンバイデータベースがプライマリサイトにおけるプライマリデータベースのロールを引き受けることを結果としてもたらすことができる。

Description

［優先権主張］
本出願は、2017年2月23日に出願された米国出願第15/440,810号に対する優先権を主張する。

［技術分野］
本明細書に記載の対象事項の実施形態は、一般にクラウドベースのコンピューティングに関する。より詳細には、対象事項の実施形態は、自動自己修復データベースシステム、及びクラウドベースのコンピューティング環境で自動自己修復データベースシステムを実現する方法に関する。

今日、インターネットを通じて（又は他のネットワークを介して）サービス及びデータにアクセスすることを可能にするクラウドベースのコンピューティングプラットフォームを多くの企業が今や使用している。これらのクラウドベースのコンピューティングプラットフォームのインフラストラクチャプロバイダは、共通のコンピュータハードウェア及びデータストレージを使用して、しばしば複数の企業（又はテナント）をサポートするネットワークベースの処理システムを提供する。この「クラウド」コンピューティングモデルは、インフラストラクチャプロバイダにより供給される「サービスとして」プラットフォーム上でアプリケーションが提供されることを可能にする。

高可用性（ＨＡ）データベースアーキテクチャは、冗長システム及びソフトウェアを使用して単一障害点（single points of failure）を排除することにより、ダウンタイム及びデータ損失を防止する。管理者のエラー、システム若しくはソフトウェア欠陥により引き起こされるデータ破壊、又は完全なサイト障害は、データベースの可用性に影響を及ぼす可能性がある。単一障害点による影響を防ぐ唯一の方法は、別のシステム上ですでに実行され理想的には第２の場所に配置されている、本番データベースの完全に独立したコピーを有することであり、これは、本番データベースが何らかの理由で利用不能になった場合にすぐにアクセスできる。

オラクル（登録商標）データガード（Oracle Data Guard）はオラクル関係データベース管理システム（ＲＤＢＭＳ）の拡張を形成する。オラクルのデータガードシステムにおいて、データベースは以下の相互排他的なロール、すなわちプライマリ又はスタンバイのうちの１つで動作する。オラクルデータガード技術は単一障害点を排除するのに役立ち、本番又はプライマリデータベースの同期した物理的複製を遠隔地に維持することにより、簡素だが経済的な方法でデータ損失及びダウンタイムを防止する。オラクルデータガードはこれらのスタンバイデータベースを本番データベースのコピーとして維持する。次に、計画された又は計画されていない停電のために本番データベースが利用不能になった場合、オラクルデータガードは任意のスタンバイデータベースを本番ロールに切り替えることができ、停電に関連づけられたダウンタイムを最小限にする。

データガードは、データベース管理者がＳＱＬステートメントを発行することにより、又はデータガードブローカーのインターフェースのいずれかを使用することにより、これらのロールを動的に変更することを可能にする。データガード技術の１つの制限は、該技術が、プライマリデータベースがプライマリデータベースサーバ又はストレージサブシステムにおけるハードウェア障害などの様々なタイプの障害のために利用できないとき、ロール変更の後、新しいスタンバイデータベースの自動供給を保証しないことである。

対象事項のより完全な理解が、以下の図面と関連して考慮されるときに詳細な説明及び特許請求の範囲を参照することにより導き出すことができ、ここで、同様の参照番号は図面を通して同様の要素を示す。
開示の実施形態による自動自己修復モジュールを有する自動自己修復データベースシステムを示すブロック図である。 開示の実施形態による自動自己修復モジュールの様々なモジュールのブロック図を示す。 図３Ａ及び３Ｂは集合的に、開示の実施形態による自動自己修復データベースシステムを提供する一例示的な方法を示すフローチャートである。 図３Ａ及び３Ｂは集合的に、開示の実施形態による自動自己修復データベースシステムを提供する一例示的な方法を示すフローチャートである。 開示の実施形態による、自動自己修復データベースシステムと、それが如何に機能して自己修復能力を達成するかとを示すブロック図である。 開示の実施形態による、自動自己修復データベースシステムと、それが如何に機能して自己修復能力を達成するかとを示すブロック図である。 開示の実施形態による、自動自己修復データベースシステムと、それが如何に機能して自己修復能力を達成するかとを示すブロック図である。 開示の実施形態による、自動自己修復データベースシステムと、それが如何に機能して自己修復能力を達成するかとを示すブロック図である。 いくつかの実装による、オンデマンドデータベースサービスが使用できる環境の一例のブロック図を示す。 いくつかの実装による、図８の要素の例示的な実装と、これらの要素間の例示的な相互接続とのブロック図を示す。 いくつかの実装による、オンデマンドデータベースサービス環境の例示的なアーキテクチャコンポーネントを示すシステム図を示す。 いくつかの実装による、オンデマンドデータベースサービス環境の例示的なアーキテクチャコンポーネントをさらに示すシステム図を示す。 本明細書で論じられる方法論のうち任意の１つ以上をマシンに実行させる命令セットが実行され得るコンピュータシステムの例示的形態におけるマシンの図表現を示す。

本明細書に提示される例示的な実施形態は、クラウドベースのコンピューティング環境で実現可能な自己修復（self-healing）自動データベースシステム、方法、手順、及び技術に関する。例えば、説明される対象事項は、例えば、マルチテナントデータベースシステムを含む任意のクラウドベースのコンピューティング環境の文脈で実現できる。

上記で論じられた問題に対処するために、自動自己修復データベースシステム及び関連する方法が提供される。自動自己修復データベースシステムはプライマリサイト（又はデータセンタ）を含み、これは、プライマリデータベースと、各々がプライマリデータベースの複製である１つ又は複数のスタンバイデータベースと、自己修復モジュールとを含む。自己修復モジュールは、自動自己修復データベースシステムの構成を監視及び管理できるカスタムアプリケーションである。自己修復モジュールは、ベンダのＡＰＩを介してベンダの技術と相互作用することができる。このような技術の例は、オラクル^ＴＭデータガード複製及びフェイルオーバ技術、アマゾン（登録商標）ウェブサービス（Amazon Web Services、ＡＷＳ）^ＴＭスナップショット技術等を含む。自己修復モジュールは、プライマリデータベースの利用不能（例えば、ハードウェア及び／又はソフトウェアの障害（failure））を自動的に検出し、プライマリサイトのスタンバイデータベース、すなわちプライマリデータベースの複製が利用可能であるかを決定することができる。もしそうならば、自己修復モジュールは自動的にフェイルオーバ処理シーケンスを開始することができ、該フェイルオーバ処理シーケンスは、プライマリデータベースの機能性及びキャパシティを復旧するために、プライマリサイトにおけるプライマリデータベースとしてのロール（role）をスタンバイデータベースに自動的に割り当てることを含む。プライマリデータベース障害が発生したときスタンバイデータベースを供給するための自動フェイルオーバ及びＡＰＩを提供することにより、自己修復が達成できる。

例えば、１つの実装において、プライマリデータベースが利用不能になったとき（例えば、故障する（fails）、クラッシュする等）、自己修復モジュールが自動的に利用不能を検出し、任意選択で、スタンバイデータベースにおいて読み取り専用アプリケーションモードを有効にすることにより読み取り専用能力を提供し、（プライマリサイトにおいて）アプリケーションサーバによりサービスされるアプリケーションのトラフィックをこの読み取り専用スタンバイデータベースにルーティングして顧客体験を向上させる。プライマリデータベースが、予め定義され且つ構成可能な期間（例えば、１０分）内に復旧／再開しない場合、プライマリデータベースのロールは、スタンバイデータベースが新しいプライマリデータベースになるように、自動的にスタンバイデータベースにフェイルオーバされることになる。これは、プライマリデータベースの複製であるスタンバイデータベースを読み取り可能及び書き込み可能として有効にし、それを他のスタンバイデータベースへのデータの複製を開始するプライマリロールとして割り当てることによって行うことができる。効率化のために、アプリケーションはプライマリ及びセカンダリ双方のデータベースへの接続を予め確立することができ、それにより、ロール移行が発生したときに新しい接続確立は必要とされない。さらに、オリジナルのプライマリデータベースのストレージサブシステムが依然として利用可能であり、一貫した状態にある場合、さらなる拡張を行うことができる。例えば、故障したプライマリデータベースサーバからストレージサブシステムをデタッチし、それをスタンバイデータベースのデータベースサーバにアタッチすることにより、これは任意のデータ損失を低減するのに役立つ可能性がある。

さらに、システムは自動的に新しいスタンバイデータベースを供給して、手動介入なしにシステムをそのフルキャパシティに戻すことができる。フェイルオーバ処理シーケンスの一部として、スナップショットストレージシステムに記憶された最も最近のスナップショットデータを使用して新しいデータベースが自動的に作成され、プライマリサイトのスタンバイデータベースとして自動的に追加されることができ、それにより、システムは、高い可用性及びスタンバイキャパシティを含むそのフルキャパシティに回復される。いくつかの実装において、故障したオリジナルのプライマリデータベースが復旧したとき／場合、それはスタンバイデータベースとして再供給され得る。

図１は、開示の実施形態による、自動自己修復モジュール１３０を有する自動自己修復データベースシステム１００を示すブロック図である。一実施形態において、自動自己修復データベースシステム１００は、クラウドベースのデータベースシステムである。

自動自己修復データベースシステム１００は、複数のユーザシステム１１２と、プライマリサイト１１０（又はデータセンタ）において又は災害復旧（disaster recovery）サイトとして機能するセカンダリサイト１４０においてアプリケーションサーバ１２４へのユーザシステム１１２のトラフィックのルーティングを制御するロードバランサ１１１と、スナップショットストレージシステム１２８とを含む。

プライマリサイト１１０サイト（又はデータセンタ）は、複数（ｎ個）のアプリケーションサーバ１２４、ここでｎは１以上、プライマリデータベース１２０−１、及びスタンバイデータベース１２０−２及び１２０−３を含む。この特定の実装において、プライマリサイト１１０は２つのスタンバイデータベースを有するが、より少ない又はより多くのスタンバイデータベースが特定の実装に依存して含まれてよい。図示のように、各データベース１２０は、様々なデータベース計算処理、結合、ソート、クエリ、又はトランザクションを実行するデータベースサーバと、ストレージ管理ソフトウェア及びトランザクションデータを記憶するハードウェアを含むストレージサブシステムとを含む。データベースサーバは、ストレージサブシステムからデータを読み取り、ストレージサブシステムにデータを書き込むことができる。ストレージサブシステム及びデータベースサーバ（そのソフトウェアコンポーネント又はモジュールを含む）は一緒に、クエリ言語及び他のインターフェースを介して問合せ、更新、及び削除され得るデータ（又はトランザクション）を処理及び記憶する能力を提供する。図示していないが、サイトは他のハードウェアを含むことができる。この点に関し、本明細書で使用されるとき「サイト」又は「データセンタ」は、別個の電源及びネットワーク接続性を有する物理ハードウェアをホストする設備を参照し得る。通常、サイトは、いくらかの物理的距離だけサイトから物理的に離される（例えば、数十〜数千マイル離れる）。

データガード構成は、本明細書においてプライマリデータベース１２０−１とも呼ばれる、プライマリロールで機能する１つの本番（production）データベースを含む。これは、アプリケーションサーバ１２４により実行されるアプリケーションによってアクセスされるデータベースである。ユーザシステム１１２は、アプリケーションサーバ１２４で実行されるアプリケーションと相互作用する。これに応じて、アプリケーションサーバ１２４で実行されるアプリケーションは、読み取り及び書き込み（Ｒ／Ｗ）要求をプライマリサイト１１０のプライマリデータベース１２０−１に通信する。例えば、アプリケーション１２４は、プライマリデータベース１２０−１にデータを記憶するためにデータを書き込むことができ、プライマリデータベース１２０−１が利用可能であり正常に動作している（例えば、障害又は他の原因の利用不能を経験していない）ときプライマリデータベース１２０−１からデータを読み取ることによりプライマリデータベース１２０−１でデータにアクセスすることができる。この読み取り／書き込みトランザクション能力は、図１においてＲ／Ｗとラベル付けされたアプリケーションサーバ１２４とプライマリデータベース１２０−１との間の矢印により表される。実装に依存して、プライマリデータベース１２０−１は、単一インスタンスのオラクルデータベース又はオラクルリアルアプリケーションクラスタ（Real Application Clusters）データベースのいずれかであり得る。

各スタンバイデータベース１２０−２、１２０−３は、高可用性環境における災害保護のために使用できるプライマリ（又は本番）データベース１２０−１の独立したコピーである。換言すれば、各スタンバイデータベース１２０−２、１２０−３は、プライマリデータベース１２０−１の、トランザクション的に一貫した又は「バックアップ」コピーである。スタンバイデータベース１２０−２、１２０−３は、トランザクションがコミットされ、プライマリデータベース１２０−１に記憶されるとき、プライマリデータベース１２０−１から複製されたデータを同期的又は非同期に受信する。これは、図１において、プライマリデータベース１２０−１とスタンバイデータベース１２０−２との間、プライマリデータベース１２０−１とスタンバイデータベース１２０−３との間、及びプライマリサイト１１０におけるプライマリデータベース１２０−１と災害復旧サイト１４０におけるプライマリデータベース１２０−１との間に延びるラベルなしの両端矢印によって示される。例えば、スタンバイデータベース１２０−２、１２０−３が作成され、データガード構成に組み込まれると、各スタンバイデータベース１２０−２、１２０−３は、プライマリデータベース１２０−１から再実行（redo）データを送信し、次いで再実行をスタンバイデータベースに適用することにより、自動的に維持される。いくつかの実装において、スタンバイデータベースは、単一インスタンスのオラクルデータベース又はオラクルリアルアプリケーションクラスタ（ＲＡＣ）データベースのいずれか（プライマリデータベース１２０−１と同様）であり得る。

特定の状況において後述するように、読み取り専用アプリケーションモードが有効にされたとき、アプリケーション１２４は、スタンバイデータベース１２０−２に記憶されたデータへの読み取り専用アクセスを有してよく、これは、アプリケーションサーバ１２４で実行されるアプリケーションが読み取り専用要求をスタンバイデータベース１２０−２に通信し得、それにより、該アプリケーションはスタンバイデータベース１２０−２からのデータの読み取りのみ可能であるが、スタンバイデータベース１２０−２にデータを書き込みできないことを意味する。この読み取り専用能力は、図１において、「読み取り専用」とラベル付けされたプライマリデータベース１２０−１とスタンバイデータベース１２０−２との間に延びる両端矢印によって表される。アプリケーション１２４は、バックアップスタンバイデータベース１２０−３へのアクセスを通常有さず、なぜならば、該データベースの目的は、新しいデータベースを作成するため又は既存のデータベースが一時的に利用不能な場合にそれを更新するために使用できるバックアップとして機能することだからである。スナップショットバックアップのための専用スタンバイデータベース１２０−３を有する目的は、バックエンドスナップショット動作からユーザシステムワークロード及び要求を分離するためである。これは、性能安定性及び動作のための最適化であり、制限ではない。

一般論として、災害復旧サイト１４０は、組織がそのプライマリサイト１１０（又はプライマリデータセンタ）全体が利用不能になり又は故障したときにその技術インフラストラクチャ及びオペレーションを復旧及び回復するために使用できる設備である。この点に関し、災害復旧サイト１４０は、プライマリサイト１１０と同じように動作するプライマリサイト１１０の対称バージョンであり、実装に依存して、プライマリサイト１１０の一部である同じ要素の全てを含んでよい。このようなものとして、この特定の実装において、災害復旧サイト１４０は、プライマリサイト１１０で実装されるものと同一のプライマリデータベース１２０−１、スタンバイデータベース１２０−２、１２０−３、及びアプリケーションサーバ１２４を含む。ほとんどの実装において、セカンダリ又は災害復旧サイト１４０は、通常、プライマリサイト１１０からいくらかの距離離れて位置し、それにより、サイトは互いに近接して位置しない。このようにして、何らかの予期せぬ災害（例えば、自然災害又は人為的災害）がプライマリサイト１１０を襲った場合、セカンダリサイト１４０は影響を受けない可能性が最も高く、事業の中断がないように稼働を開始できるようにすべきである。

スナップショットストレージシステム１２８は、プライマリサイト１１０及びセカンダリサイト１４０のいずれかで、又は別の場所で、プライマリサイト１１０及び／又は災害復旧サイト１４０と物理的に近接して位置しないように遠隔に実装できる。例えば、開示の実施形態のいくつかによれば、スナップショットストレージシステム１２８は、プライマリサイト１１０に実現されず且つプライマリサイトレベル障害から守るために遠隔に位置する別個のストレージハードウェアである。以下に説明するように、スナップショットアプリケーション及び管理モジュール（図１には図示されていない）は、スタンバイデータベース１２０−３に記憶されたデータのスナップショットを取るために定期的又は周期的に実行され、データのスナップショットをスナップショットストレージシステム１２８に記憶する。スナップショットストレージシステム１２８はプライマリサイト１１０又はＤＲサイト１４０によりアクセスでき、それにより、スナップショットデータはほぼ瞬時に利用可能である。スナップショットデータは、データリストアに、又はフェイルオーバの場合のスタンバイデータベースの供給に使用できる。

いくつかの場合、プライマリサイト１１０におけるプライマリデータベース１２０−１が、何らかの理由で利用不能になる可能性がある。例えば、プライマリデータベース１２０−１は、これらに限られないが電力停止、ハードウェア障害、ソフトウェア障害、ネットワーク障害、又はオペレータエラーなどを含む複数の異なる理由で利用不能になる可能性がある。

この問題に対処するために、開示の実施形態は、各サイト１１０、１４０に自動自己修復モジュール１３０を提供することができる。以下により詳細に説明するように、自動自己修復モジュール１３０は、プライマリサイト１１０におけるプライマリデータベース１２０−１の利用不能及び／又は障害を自動的に検出することができ、プライマリデータベース１２０−１がある期間内に復旧できず、プライマリサイト１１０のスタンバイデータベース１２０−２が利用可能である場合、自動自己修復モジュール１３０はフェイルオーバ処理シーケンスを自動的に開始することができる。フェイルオーバは、プライマリデータベース１２０−１が（例えば、障害、スケジュールされた利用不能等に起因して）利用不能になったとき、プライマリデータベース１２０−１のロールが自動的にプライマリサイト１１０のスタンバイデータベース１２０−２に切り替わり、該スタンバイデータベース１２０−２により引き受けられる動作モードである。プライマリデータベース１２０−１のストレージサブシステムは、完全（intact）でアクセス可能な場合、復旧のためにスタンバイデータベース１２０−２のデータベースサーバに自動的にアタッチされて、潜在的なデータ損失をさらに低減させることができる。スタンバイデータベース１２０−２を読み取り可能及び書き込み可能として有効にする前に、プライマリデータベース１２０−１のストレージサブシステム１２０−１をスタンバイデータベース１２０−２のデータベースサーバに自動的にアタッチすることにより、プライマリデータベース１２０−１の障害の直前のプライマリデータベース１２０−１に対するいくつかのトランザクションが適時にスタンバイデータベース１２０−２に複製され得ないことに起因してさもなければ生じ得るデータ損失が回避できる。プライマリデータベース１２０−１のストレージサブシステムをスタンバイデータベース１２０−２のデータベースサーバに自動的にアタッチした後、スタンバイデータベース１２０−２は、次いで、読み取り可能及び書き込み可能として自動的に有効にされ、次いで、他のスタンバイデータベースへのデータの複製を開始するようプライマリサイト１００におけるプライマリデータベースのロールを割り当てられ得る。

換言すれば、フェイルオーバの一部として、自己修復モジュール１３０はプライマリロールを自動的且つシームレスにスタンバイデータベース１２０−２に割り当てることができ、それにより、スタンバイデータベース１２０−２はプライマリサイト１１０のプライマリデータベースとして機能する。そのようなものとして、プライマリデータベース１２０−１が故障した（又はその他の点で利用不能になった）とき、スタンバイデータベースの１つが、プライマリデータベースとして機能するよう自動的に割り当てられ得る。このようにして、アプリケーションサーバ１２４によりサービスされるアプリケーションは、読み取り／書き込みトランザクションを実行する（例えば、新しいプライマリデータベースとしてのロールを割り当てられたスタンバイデータベースからデータを読み取り、該スタンバイデータベースにデータを書き込む）パーミッションを含む、この「新しい」プライマリデータベースへの完全なアクセスを依然として有する。フェイルオーバロール移行の後、アプリケーションサーバとスタンバイデータベース１２０−２との間の予め確立された接続が、アプリケーションサーバがスタンバイデータベース１２０−２からデータを読み取り、スタンバイデータベース１２０−２にデータを書き込むことを可能にするために使用され、スタンバイデータベース１２０−２がプライマリサイト１１０におけるプライマリデータベースのロールを引き受けることを結果としてもたらす。さらに、以下でより詳細に説明するように、最新のスナップショットを使用して新しいスタンバイが供給され、次いで、複製構成に足し戻され、プライマリサイトを高可用性及びスタンバイキャパシティを含むそのフルキャパシティに戻し回復することができる。

図２は、開示の実施形態による、自動自己修復モジュール１３０の様々なモジュールのブロック図を示す。図２は、データベースヘルス監視モジュール２３２とスナップショットアプリケーション及び管理モジュール２３４と読み取り専用アプリケーションモードモジュール２３６とデータベースフェイルオーバモジュール２３８とスタンバイデータベース供給モジュール２４０とデータベース複製管理モジュール２４２とを含む、自動自己修復モジュール１３０の様々なモジュールを示す。

図１及び図２の様々な要素により実行される様々なタスク及び動作を、図３Ａ〜図７を参照して以下により詳細に説明する。例えば、図２に示される自動自己修復モジュール１３０の様々なモジュールにより実行されるタスク及び動作を含む、プライマリサイト１１０において実行される特定のタスク及び動作、並びに災害復旧サイト１４０において実行されるタスク及び動作を、図３Ａ〜図７を参照し、図１及び図２を継続して参照して以下に説明する。

図３Ａ及び３Ｂは、集合的に、開示の実施形態による自動自己修復データベースシステムを提供するための一例示的な方法３００を示すフローチャートである。予備事項として、方法３００のステップは必ずしも限定的でなく、ステップは別記の特許請求の範囲の範囲から逸脱することなく追加、省略、及び／又は同時に実行可能であることが理解されるべきである。方法３００は任意数の追加又は代替タスクを含んでよく、図３Ａ及び３Ｂに示されたタスクは図示された順序で実行される必要がなく、方法３００は、本明細書に詳細に記載されていないさらなる機能性を有するより包括的な手順又は処理に組み込まれてよいことが十分理解されるべきである。さらに、図３Ａ及び３Ｂに示されるタスクの１つ以上は、意図された全体的な機能性が完全なままである限り、方法３００の実施形態から潜在的に省略され得る。また、図示された方法３００は、いつでも停止可能であることが理解されるべきである。方法３００は、方法３００に関連して実行される様々なタスク又はステップがソフトウェア、ハードウェア、ファームウェア、又はこれらの任意の組み合わせにより実行され得る点でコンピュータにより実現される。例示の目的のために、方法３００の以下の説明は、図１及び図２に関連して上述した要素を参照し得る。特定の実施形態では、この処理の一部又は全ステップ、及び／又は実質的に等価なステップは、プロセッサ読み取り可能媒体に記憶され又は含まれるプロセッサ読み取り可能命令の実行により実行される。

図３Ａ及び図３Ｂは、図４〜図７を参照して説明され、図４〜図７は、プライマリデータベース１２０−１が故障して復旧できなくなった後のデータベースシステム１００の自動自己修復の動作、特に、自動自己修復モジュール１３０が如何に機能してプライマリサイトで自己修復能力を達成するかを示すブロック図である。以下の図３Ａ〜図７の説明において、自動自己修復モジュール１３０は様々な動作、タスク、又はステップを実行するものとして説明されるが、これは、これら様々な動作、タスク、又はステップを実行する命令を実行するこれらエンティティの処理システムを参照することが十分理解されるべきである。実装に依存して、処理システムの一部が中央に位置し、あるいは一緒に動作する複数のシステム間で分散され得る。

再び図３Ａを参照すると、方法３００の開始の前に、及びその間に、スナップショットアプリケーション及び管理モジュール２３４がバックグラウンドで実行して、スタンバイデータベース１２０−３に記憶されたデータのスナップショットを定期的又は周期的に取り、データのスナップショットをスナップショットストレージシステム１２８に記憶する。例えば、一実施形態において、スナップショットアプリケーション及び管理モジュール２３４は、スタンバイデータベース１２０−３の１時間ごとのスナップショットを取り、スナップショットデータをスナップショットストレージシステム１２８に記憶することができる。次いで、スナップショットデータは、データ回復に、又はフェイルオーバの場合のスタンバイデータベースの供給に使用できる。さらに、１時間ごとのスナップショットは、或る時間が経過した後に日次スナップショットにマージされ、データ保有ポリシーによって数日間記憶され得る。スナップショットアプリケーション及び管理モジュール２３４により実行されるこれらのタスクは、図３Ａ及び図３Ｂの番号付きブロックにより示される方法３００の外側で実行されるため、番号なしブロックにより図３Ａに示される。

図３Ａ及び図３Ｂの方法３００は３０４で始まり、３０４において、データベースヘルス監視モジュール２３２（図２）が、図４の３０４に示されるように、プライマリサイト１１０におけるプライマリデータベース１２０−１の利用不能を自動的に検出する。例えば、一実施形態において、データベースヘルス監視モジュール２３２（図２）は、プライマリデータベースサーバにハートビートを、並びにプライマリデータベース１２０−１にヘルスチェッククエリ及びトランザクションを送信することにより、プライマリサイト１１０におけるプライマリデータベース１２０−１の利用不能又は障害を自動的に検出する。例えば、一実装において、ハートビートメッセージは、例えば、Ｕｎｉｘ（登録商標）又はＬｉｎｕｘ（登録商標）で利用可能な「ｐｉｎｇ」ユーティリティを使用して、プライマリデータベースサーバのネットワーク及びオペレーティングシステムに送ることができる。プライマリデータベースサーバへのハートビートが応答に失敗した場合、又はヘルスチェッククエリ及びトランザクションが完了に失敗した場合、データベースヘルス監視モジュール２３２は、プライマリデータベース１２０−１が利用可能でなく再開又は復旧が必要かを決定することができる。

３０４において、データベースヘルス監視モジュール２３２（図２）はさらに、プライマリデータベース１２０−１の利用不能（例えば、プライマリデータベース１２０−１がどれほどの間利用不能であったか）を追跡するために使用される復旧タイマ／カウンタを開始することができる。以下に説明するように、プライマリデータベース１２０−１が、復旧タイマ／カウンタを超える時間／カウントの間利用不能であると決定されたとき、プライマリデータベース１２０−１は復旧しないと仮定され、これは、プライマリロールを（１）プライマリサイト１１０におけるスタンバイデータベース１２０−２が利用可能である場合、スタンバイデータベース１２０−２に、又は（２）ＤＲサイト１４０における別のプライマリデータベース１２０−１に、のいずれかに移行するフェイルオーバをトリガする。

３０６において、データベースヘルス監視モジュール２３２（図２）が、プライマリサイトのスタンバイデータベースのいずれかが利用可能であるか（例えば、これはプライマリサイトのプライマリ及びすべてのスタンバイデータベースが利用不能であるサイトレベルの障害か、又は、これはプライマリデータベースが利用不能になったがプライマリサイトの少なくとも１つのスタンバイデータベースが利用可能である部分的な障害か）を決定することができる。

データベースヘルス監視モジュール２３２（図２）が、プライマリサイト１１０のデータベースの全てが利用不能である（例えば、故障した）と（３０６において）決定したとき、方法３００は３０８に進み、３０８において、データベースフェイルオーバモジュール２３８（図２）が、災害復旧サイト１４０におけるプライマリデータベース１２０−１へのフェイルオーバ（サイト切り替え動作とも呼ばれる）を実行し、ロードバランサ１１１に、すべてのネットワークトラフィックを災害復旧サイト１４０に向けるように（例えば、利用可能な場合、すべてのトラフィックを災害復旧サイト１４０のプライマリデータベース１２０−１に向けるように）命令する。その結果、ユーザシステム１１２からの任意の読み取り／書き込み要求が、災害復旧サイト１４０におけるアプリケーションサーバ１２４及びプライマリデータベース１２０−１により扱われることになる。

ブロック３１０は、任意的であるため、破線ボックスに示される。データベースヘルス監視モジュール２３２（図２）が、プライマリサイト１１０のスタンバイデータベース１２０−２が利用可能である（例えば、故障していない）と決定したとき、方法３００は、任意選択で３１０に進んでよく、３１０において、読み取り専用アプリケーションモードモジュール２３６（図２）が、スタンバイデータベース１２０−２における読み取り専用アプリモードを有効にして、アプリケーションサーバ１２４によりサービスされるアプリケーションがプライマリサイト１１０におけるスタンバイデータベース１２０−２に記憶されたデータへの読み取り専用アクセスを有することを一時的に可能にする。これは、図４において、アプリケーションサーバ１２４とスタンバイデータベース１２０−２との間の線３１０により示される。トランザクションはコミットできないが、アプリケーションサーバ１２４は依然としてスタンバイデータベース１２０−２からデータを読み取り、プライマリデータベース１２０−１がダウンしている間、及びプライマリデータベース１２０−１が復旧するかどうか（したがって、ロール移行が実施されるべきかどうか）が決定されている間、顧客クエリ及び他の読み取り専用要求を満足することができるので、読み取り専用アクセスを可能にすることは顧客体験の向上に有益である。いくつかの場合に、プライマリデータベース１２０−１が比較的短い期間内に復旧することができる場合、プライマリデータベース１２０−１がプライマリサイト１１０のためのプライマリデータベースとしてのロールを維持するように待機することがより合理的である。

３１２において、データベースヘルス監視モジュール２３２（図２）が、プライマリデータベース１２０−１が復旧タイマ／カウンタを超える時間／カウントの間利用不能であったかどうかを決定する。データベースヘルス監視モジュール２３２（図２）が、プライマリデータベース１２０−１が利用可能であり、復旧タイマ／カウンタが或る復旧時間／カウントに達する前に復旧したことを（３１２で）決定すると、これは、プライマリデータベース１２０−１が復旧時間／カウント内に復旧したことを意味し、方法は３１４に進む。３１４において、データベースヘルス監視モジュール２３２（図２）は、プライマリデータベース１２０−１を（例えば、オペレーティングシステムのデーモン／ウォッチドッグプロセスにより）自動的に再開し、プライマリデータベース１２０−１は、プライマリサイト１１０のプライマリデータベース１２０−１として継続して使用されることになる。アプリケーションサーバ１２４におけるアプリケーションは、プライマリサイト１１０のプライマリデータベース１２０−１への予め確立された接続を継続して使用し、継続して正常に機能することになる。

対照的に、データベースヘルス監視モジュール２３２（図２）が、プライマリデータベース１２０−１が復旧タイマ／カウンタを超える時間／カウントの間利用不能であったと決定したとき、これは、プライマリデータベース１２０−１が復旧時間／カウント内に復旧しなかったことを意味し、方法は３１６に進む。３１６において、データベースフェイルオーバモジュール２３８（図２）が、図５に示すように、スタンバイデータベース１２０−２をプライマリサイト１１０のプライマリデータベースとしての新しいロールに切り替えるためのフェイルオーバをトリガする。一実施形態において、これは、例えば、プライマリデータベース１２０−１のストレージサブシステムを完全でアクセス可能な場合に復旧目的でスタンバイデータベース１２０−２のデータベースサーバに自動的にアタッチすることによって行うことができ、これは、任意のデータ損失を低減し、新しいホストを割り振る遅延を排除するのに役立つ。次いで、スタンバイデータベース１２０−２は、読み取り可能及び書き込み可能として自動的に有効にされ、プライマリサイト１００におけるプライマリデータベースのロールを割り当てられて、他のスタンバイデータベースへのデータの複製を開始することができる。フェイルオーバロール移行の後、アプリケーションサーバとスタンバイデータベース１２０−２との間の予め確立された接続が、アプリケーションサーバがスタンバイデータベース１２０−２からデータを読み取り、スタンバイデータベース１２０−２にデータを書き込むことを可能にするために使用され、スタンバイデータベース１２０−２がプライマリサイト１１０におけるプライマリデータベースのロールを引き受けることを結果としてもたらす。開示の実施形態によれば、効率のために、アプリケーションサーバとスタンバイデータベースとの間の接続は予め確立され、それにより、新しい接続確立が必要とされない。スタンバイデータベース１２０−２は、自動的に切り替えできる。プライマリデータベースとしてのロールを引き受けたデータベース１２０−２は今やアプリケーション１２４により読み取り／書き込みアクセス可能であり（図５において、アプリケーションサーバ１２４とデータベース１２０−２との間に延びる線３１６により示される）、今やＤＲサイト１４０のプライマリデータベース１２０−１とのデータガード複製構成にもある（図５において、プライマリサイト１１０のデータベース１２０−２とＤＲサイト１４０のプライマリデータベース１２０−１との間に延びる両端矢印により示される）。

そのようなものとして、フェイルオーバ処理シーケンスを自動的に開始する前に、データベースヘルス監視モジュール２３２（図２）は、プライマリサイトにおけるプライマリデータベース１２０−１が許可された復旧時間内に復旧したかどうかを（３１２で）決定する。プライマリサイト１１０におけるプライマリデータベース１２０−１が復旧時間内に復旧しなかった場合、３１６において、データベースフェイルオーバモジュール２３８（図２）がフェイルオーバ処理シーケンスを自動的に開始する。データベースフェイルオーバモジュール２３８（図２）は、プライマリサイト１１０のスタンバイデータベース１２０−２にプライマリデータベース又は「新しい」プライマリデータベースとしてのロールを割り当てることにより、プライマリデータベース１２０−１の複製を自動的に供給することになる。これは、このスタンバイデータベース１２０−２がプライマリサイト１１０におけるプライマリデータベースのロールを引き受けることになることを意味する。この例では、データベースフェイルオーバモジュール２３８（図２）がプライマリサイト１１０のプライマリデータベースとしてのロールを引き受けるスタンバイデータベース１２０−２を選択したことを仮定しており、したがって、アプリケーション１２４は、プライマリサイト１１０のプライマリデータベースとしてのデータベース１２０−２に切り替えられることになる。その結果、アプリケーションサーバ１２４によりサービスされるアプリケーションは、新しいプライマリデータベース１２０−２において読み取り／書き込みトランザクションを実行するパーミッションを含む「新しい」プライマリデータベース１２０−２へのフルアクセスを備えることになる。したがって、アプリケーション１２４は、新しいプライマリデータベース１２０−２からデータを継続して読み取ることができ、また、新しいプライマリデータベース１２０−２にデータを書き込むこともできる。

フェイルオーバ処理シーケンスの一部として、図３Ｂの３１８において、スタンバイデータベース供給モジュール２４０（図２）は、図６の線３１８により示されるように、スナップショットストレージシステム１２８に記憶された最も最近のスナップショットデータを使用して新しいデータベース１２０−４を自動的に作成することができる。

次いで、データベース複製管理モジュール２４２（図２）は、新しく作成されたデータベース１２０−４をプライマリサイト１１０のスタンバイデータベースとして（３２０において）自動的に追加することができ、それにより、システムは高可用性及びスタンバイキャパシティを含むそのフルキャパシティに回復される。これは、図７において、プライマリサイト１１０の新しいスタンバイデータベース１２０−４とプライマリサイト１１０のプライマリデータベース１２０−２との間に延びる両端矢印３２０により示される。

以下の説明は、上記で説明した特徴が実現され得るシステムの一例である。以下に説明するシステムのコンポーネントは単なる一例であり、限定的なものとして解釈されるべきでない。図１〜図７に関して上記で説明した特徴は、複数のデータベース、マルチテナントデータベースシステム環境、単一テナントデータベースシステム環境、又は上記の何らかの組み合わせを有するものなどの他タイプのコンピューティング環境で実現され得る。

図８は、いくつかの実装によるオンデマンドデータベースサービスが使用できる環境４１０の一例のブロック図を示す。環境４１０は、ユーザシステム４１２と、ネットワーク４１４と、データベースシステム４１６（本明細書において「クラウドベースのシステム」とも呼ばれる）と、プロセッサシステム４１７と、アプリケーションプラットフォーム４１８と、ネットワークインターフェース４２０と、テナントデータ４２３を記憶するテナントデータベース４２２と、システムデータ４２５を記憶するシステムデータベース４２４と、システム４１６の様々な機能を実現するプログラムコード４２６と、データベースシステムプロセス及びテナント固有プロセスを実行し、例えばアプリケーションホスティングサービスの一部としてアプリケーションを実行するプロセス空間４２８とを含む。いくつかの他の実装において、環境４１０は、これらコンポーネント又はシステムのすべてを有さなくてよく、あるいは、上記に列挙したものの代わりに又は追加で他のコンポーネント又はシステムを有してよい。

いくつかの実装において、環境４１０は、オンデマンドデータベースサービスが存在する環境である。オンデマンドデータベースサービス、例えばシステム４１６を使用して実現できるものは、システム４１６へのアクセスを所有、維持、又は提供する、企業の外部のユーザに利用可能にされるサービスである。上記で説明したように、こうしたユーザは、一般に、システム４１６の構築又は維持に関与する必要がない。代わりに、システム４１６により提供されるリソースは、ユーザがシステム４１６により提供されるサービスを必要とするとき、すなわちユーザの要望に応じて、こうしたユーザの使用に対して利用可能であり得る。いくつかのオンデマンドデータベースサービスは、１つ以上のテナントからの情報を共通のデータベースイメージのテーブルに記憶してマルチテナントデータベースシステム（ＭＴＳ）を形成することができる。用語「マルチテナントデータベースシステム」は、データベースシステムのハードウェア及びソフトウェアの様々な要素が１以上の顧客又はテナントにより共有され得るシステムを参照することができる。例えば、所与のアプリケーションサーバが、多数の顧客の要求を同時に処理することができ、所与のデータベーステーブルが、潜在的により多数の顧客のフィードアイテムなどのデータの行を記憶することができる。データベースイメージは、１つ以上のデータベースオブジェクトを含むことができる。関係データベース管理システム（ＲＤＢＭＳ）又は同等物が、データベースオブジェクトに対して情報の記憶及び取り出しを実行することができる。

アプリケーションプラットフォーム４１８は、システム４１６のアプリケーションが実行することを可能にするフレームワーク、例えば、システム４１６のハードウェア又はソフトウェアインフラストラクチャなどであり得る。いくつかの実装において、アプリケーションプラットフォーム４１８は、オンデマンドデータベースサービスのプロバイダ、ユーザシステム４１２を介してオンデマンドデータベースサービスにアクセスするユーザ、又はユーザシステム４１２を介してオンデマンドデータベースサービスにアクセスするサードパーティアプリケーション開発者により開発された１つ以上のアプリケーションの作成、管理、及び実行を可能にする。

いくつかの実装において、システム４１６は、ウェブベースの顧客関係管理（ＣＲＭ）システムを実現する。例えば、いくつかのこうした実装において、システム４１６は、ＣＲＭソフトウェアアプリケーションを実現及び実行し、ユーザシステム４１２への及びユーザシステム４１２からの関連したデータ、コード、フォーム、レンダリング可能なウェブページ及び文書、並びに他の情報を提供し、且つ、関連したデータ、オブジェクト、及びウェブページコンテンツをデータベースシステムに記憶し、データベースシステムから取り出すように構成された、アプリケーションサーバを含む。いくつかのＭＴＳ実装において、複数のテナントのためのデータが、テナントデータベース４２２内の同じ物理データベースオブジェクトに記憶されてよい。いくつかのこうした実装において、テナントデータは、こうしたデータが明白に共有されない限り、あるテナントが別のテナントのデータに対するアクセスを有さないように、あるテナントのデータが他のテナントのデータとは論理的に別個に保持されるようにテナントデータベース４２２の記憶媒体内に配列される。システム４１６はまた、ＣＲＭアプリケーション以外の、又はＣＲＭアプリケーションに対して追加のアプリケーションを実現する。例えば、システム４１６は、ＣＲＭアプリケーションを含む複数のホストされた（標準及びカスタムの）アプリケーションに対するテナントアクセスを提供することができる。ＣＲＭを含んでもよく含まなくてもよい、ユーザ（又は、サードパーティ開発者）アプリケーションが、アプリケーションプラットフォーム４１８によりサポートされてよい。アプリケーションプラットフォーム４１８は、アプリケーションの１つ以上のデータベースオブジェクトへの作成及び記憶と、システム１６のプロセス空間における１つ以上の仮想マシン内でのアプリケーションの実行とを管理する。

いくつかの実装によれば、各システム４１６は、ウェブページ、フォーム、アプリケーション、データ、及びメディアコンテンツをユーザ（クライアント）システム４１２に提供して、システム４１６のテナントとしてのユーザシステム４１２によるアクセスをサポートするように構成される。そのようなものとして、システム４１６は、データが共有されない限り各テナントのデータを別個に保持するようにセキュリティメカニズムを提供する。２つ以上のＭＴＳが使用される場合、これらは互いに近接して（例えば、単一の建物又はキャンパス内に位置するサーバファーム内に）位置してよく、あるいは、これらは互いから遠隔の位置（例えば、市Ａに位置する１つ以上のサーバと、市Ｂに位置する１つ以上のサーバ）に分散されてもよい。本明細書において用いられるとき、各ＭＴＳは、ローカルで分散されているか又は１つ以上の地理的位置にわたる、１つ以上の論理的又は物理的に接続されたサーバを含むことがある。さらに、用語「サーバ」は、当分野において周知である処理ハードウェア及びプロセス空間と、メモリデバイス又はデータベースなどの関連づけられた記憶媒体と、いくつかの例ではデータベースアプリケーション（例えば、ＯＯＤＢＭＳ又はＲＤＢＭＳ）とを含むコンピューティングデバイス又はシステムを参照するように意図される。さらに、「サーバシステム」と「サーバ」とは本明細書においてしばしば置き換え可能に用いられることが理解されるべきである。同様に、本明細書において説明されるデータベースオブジェクトは、単一のデータベース、分散型データベース、分散型データベースの集合、冗長オンライン若しくはオフラインバックアップ又は他の冗長性を有するデータベース等の一部として実現されてよく、分散型データベース又はストレージネットワークと関連づけられた処理インテリジェンスとを含むことができる。

ネットワーク４１４は、互いに通信するシステム又はデバイスの任意のネットワーク又はネットワークの組み合わせであり、あるいはこれらを含んでよい。例えば、ネットワーク４１４は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、テレフォンネットワーク、ワイヤレスネットワーク、セルラーネットワーク、ポイントツーポイントネットワーク、スターネットワーク、トークンリングネットワーク、ハブネットワーク、又は他の適切な構成のうち任意の１つ又は任意の組み合わせであり、あるいはこれらを含んでよい。ネットワーク４１４は、ＴＣＰ／ＩＰ（トランスファーコントロールプロトコル及びインターネットプロトコル）ネットワーク、例えば、（大文字の「Ｉ」を用いて）「インターネット」としばしば呼ばれるネットワークのグローバルインターネットワークなどを含んでよい。インターネットは、本明細書における例のうち多くで用いられる。しかしながら、ＴＣＰ／ＩＰは頻繁に実現されるプロトコルであるが、開示の実装が使用できるネットワークはそのように限定されないことが理解されるべきである。

ユーザシステム４１２は、ＴＣＰ／ＩＰと、より高いネットワークレベルではＨＴＴＰ、ＦＴＰ、ＡＦＳ、ＷＡＰなどの通信するための他の一般的インターネットプロトコルとを用いて、システム４１６と通信することができる。ＨＴＴＰが使用される一例において、各ユーザシステム４１２は、システム４１６のＨＴＴＰサーバへの及びＨＴＴＰサーバからのＨＴＴＰ信号を送信及び受信するために、「ウェブブラウザ」又は簡素に「ブラウザ」と一般に呼ばれるＨＴＴＰクライアントを含むことができる。こうしたＨＴＴＰサーバは、システム４１６とネットワーク４１４との間の単独のネットワークインターフェース４２０として実現されてよく、しかし、これら手法に対して追加で又は代わりに他の手法が用いられてもよい。いくつかの実装において、システム４１６とネットワーク４１４との間のネットワークインターフェース４２０は、ロードシェアリング機能性、例えば、ロードのバランスをとり、且つ入来ＨＴＴＰ要求を複数のサーバにわたり均等に分散するラウンドロビンＨＴＴＰ要求分配器などを含む。ＭＴＳ実装では、サーバの各々がＭＴＳデータに対するアクセスを有することができ、しかしながら、他の代替的な構成が代わりに用いられてもよい。

ユーザシステム４１２は、データベースシステム４１６にアクセスするためにユーザにより使用可能な任意のコンピューティングデバイス又は他のデータ処理装置若しくはシステムとして実現されてよい。例えば、ユーザシステム１２のうち任意のものが、デスクトップコンピュータ、ワークステーション、ラップトップコンピュータ、タブレットコンピュータ、ハンドヘルドコンピューティングデバイス、モバイルセルラーフォン（例えば、「スマートフォン」）、若しくは任意の他のＷｉ‐Ｆｉ（登録商標）対応デバイス、ワイヤレスアクセスプロトコル（ＷＡＰ）対応デバイス、又はインターネット若しくは他のネットワークに直接又は間接的にインターフェースをとることができる他のコンピューティングデバイスであってよい。用語「ユーザシステム」及び「コンピューティングデバイス」は本明細書において、互いに、及び用語「コンピュータ」と置き換え可能に用いられる。上記で説明されたように、各ユーザシステム４１２は、ＨＴＴＰクライアント、例えば、ＷｅｂＫｉｔプラットフォームに基づくウェブブラウザ、Ｍｉｃｒｏｓｏｆｔ（登録商標）のインターネットエクスプローラブラウザ、ＮｅｔｓｃａｐｅのＮａｖｉｇａｔｏｒブラウザ、Ｏｐｅｒａ（登録商標）のブラウザ、Ｍｏｚｉｌｌａ（登録商標）のＦｉｒｅｆｏｘ（登録商標）ブラウザ、又はセルラーフォン、ＰＤＡ、若しくは他のワイヤレスデバイスの場合のＷＡＰ対応ブラウザなどのウェブブラウジング（又は、簡素に「ブラウジング」）プログラムを典型的に実行して、ユーザシステム４１２のユーザ（例えば、システム４１６により提供されるオンデマンドサービスの加入者）がネットワーク４１４を通じてシステム４１６からの自身に利用可能な情報、ページ、及びアプリケーションについてアクセス、処理、及び閲覧することを可能にする。

各ユーザシステム４１２はまた、システム４１６又は他のシステム若しくはサーバにより提供されたページ、フォーム、アプリケーション、及び他の情報と関連してユーザシステム４１２のディスプレイ（例えば、他の可能性の中でもモニタ画面、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）ディスプレイ）上にブラウザにより提供されたグラフィカルユーザインターフェース（ＧＵＩ）と相互作用するように、１つ以上のユーザ入力デバイス、例えばキーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペン、又はスタイラスなどを典型的に含む。例えば、ユーザインターフェースデバイスが使用されて、システム４１６によりホストされたデータ及びアプリケーションにアクセスし、記憶されたデータに対して検索を実行し、その他の方法でユーザがユーザに提示され得る様々なＧＵＩページと相互作用することを可能にすることができる。上記で論じられたように、実装はインターネットとの使用に適するが、他のネットワークがインターネットに対して代わりに又は追加で使用されてもよく、例えば、イントラネット、エクストラネット、仮想プライベートネットワーク（ＶＰＮ）、非ＴＣＰ／ＩＰベースネットワーク、任意のＬＡＮ又はＷＡＮなどである。

ユーザシステム４１２のユーザは、そのそれぞれのキャパシティにおいて異なってもよく、特定のユーザシステム４１２のキャパシティは、こうしたユーザシステムの現在のユーザに対するパーミッション（パーミッションレベル）によって全体的に決定されてよい。例えば、販売員が特定のユーザシステム４１２を使用してシステム４１６と相互作用している場合、そのユーザシステムは、上記販売員に割り振られたキャパシティを有することができる。しかしながら、管理者がそのユーザシステム４１２を使用してシステム４１６と相互作用する間、そのユーザシステムは管理者に割り振られたキャパシティを有することができる。階層的ロールモデルが使用される場合、あるパーミッションレベルのユーザは、より低いパーミッションレベルのユーザによりアクセス可能なアプリケーション、データ、及びデータベース情報に対するアクセスを有することができ、しかし、より高いパーミッションレベルのユーザによりアクセス可能な特定のアプリケーション、データベース情報、及びデータに対するアクセスを有さないことがある。ゆえに、異なるユーザは、ユーザのそれぞれのセキュリティ又はパーミッションレベル（さらに、「承認」とも呼ばれる）に依存して、アプリケーション及びデータベース情報にアクセス及び修正することに関して異なる能力を一般に有することになる。

いくつかの実装によれば、各ユーザシステム４１２、及びそのコンポーネントのうちいくつか又はすべてが、Ｉｎｔｅｌ（登録商標） Ｐｅｎｔｉｕｍ（登録商標）プロセッサなどの中央処理ユニット（ＣＰＵ）を用いて実行されるコンピュータコードを含むブラウザなどのアプリケーションを用いてオペレータ構成可能である。同様に、システム４１６（及び、２つ以上が存在する場合のＭＴＳのさらなるインスタンス）、及びそのコンポーネントのすべてが、プロセッサシステム４１７を用いて動作するコンピュータコードを含むアプリケーションを用いてオペレータ構成可能であってよく、プロセッサシステム４１７は、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標）プロセッサなどを含み得るＣＰＵ、又は複数のＣＰＵを含むように実現されてよい。

システム４１６は、本明細書に説明されるプロセスの実現のいくつかを実行するためにサーバ又は他のコンピューティングシステム（又は、こうしたサーバ若しくはコンピューティングシステムの集合）により実行可能であり、あるいは該サーバ又は他のコンピューティングシステムをプログラムするために使用される、非一時的命令を記憶させた有形のコンピュータ読み取り可能媒体を含む。例えば、コンピュータプログラムコード４２６は、本明細書に説明されるようにウェブページ、アプリケーション、並びに他のデータ及びメディアコンテンツを相互通信及び処理するようにシステム４１６を操作及び構成する命令を実現することができる。いくつかの実装において、コンピュータコード４２６はダウンロード可能であり、ハードディスクに記憶されてよいが、プログラムコード全体又はこれらの一部はまた、ＲＯＭ又はＲＡＭなどの周知である任意の他の揮発性又は不揮発性のメモリ媒体又はデバイスに記憶されてもよく、あるいは、プログラムコードを記憶することができる任意の媒体、例えば、フロッピーディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、コンパクトディスク（ＣＤ）、マイクロドライブ、及び磁気光ディスクを含む任意タイプの回転媒体、並びに磁気若しくは光学カード、ナノシステム（分子メモリＩＣを含む）、又は、命令若しくはデータを記憶するのに適した任意の他タイプのコンピュータ読み取り可能媒体若しくはデバイス上で提供されてもよい。さらに、プログラムコード全体又はその一部は、周知のように送信媒体を通じて、例えばインターネットを通じてソフトウェアソースから、又は別のサーバから、送信及びダウンロードされてもよく、あるいは、周知の任意の通信媒体及びプロトコル（例えば、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、イーサネット（登録商標）等）を用いて、周知の任意の他の既存のネットワーク接続（例えば、エクストラネット、ＶＰＮ、ＬＡＮ等）を通じて送信されてもよい。さらに、開示の実装のコンピュータコードは、サーバ又は他のコンピューティングシステム上で実行できる任意のプログラミング言語、例えば、Ｃ、Ｃ＋＋、ＨＴＭＬ、任意の他のマークアップ言語、Ｊａｖａ（登録商標）^ＴＭ、Ｊａｖａｓｃｒｉｐｔ（登録商標）、ＡｃｔｉｖｅＸ（登録商標）、任意の他のスクリプティング言語、例えばＶＢＳｃｒｉｐｔなどにおいて具現化されてもよく、周知である多くの他のプログラミング言語が使用されてもよい（Ｊａｖａ^ＴＭはＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社の商標である。）。

図９は、いくつかの実装による図８の要素の例示的な実装とこれら要素間の例示的な相互接続とのブロック図を示す。すなわち、図９もまた環境４１０を例示し、しかし図９では、システム４１６の様々な要素とこうした要素間の様々な相互接続とが、いくつかのより特定の実装に従ってさらなる特定性で示される。図９にも示される図８からの要素は、図９において図８で使用されたのと同じ参照番号を使用する。さらに、図９において、ユーザシステム４１２は、プロセッサシステム５１２Ａ、メモリシステム５１２Ｂ、入力システム５１２Ｃ、及び出力システム５１２Ｄを含む。プロセッサシステム５１２Ａは、１つ以上のプロセッサの任意の適切な組み合わせを含むことができる。メモリシステム５１２Ｂは、１つ以上のメモリデバイスの任意の適切な組み合わせを含むことができる。入力システム５１２Ｃは、１つ以上のタッチスクリーンインターフェース、キーボード、マウス、トラックボール、スキャナ、カメラ、又はネットワークへのインターフェースなどの入力デバイスの任意の適切な組み合わせを含むことができる。出力システム５１２Ｄは、１つ以上のディスプレイデバイス、プリンタ、又はネットワークへのインターフェースなどの出力デバイスの任意の適切な組み合わせを含むことができる。

図９において、図８のネットワークインターフェース４２０は、一組のＨＴＴＰアプリケーションサーバ５００_１〜５００_Ｎとして実現される。各アプリケーションサーバ５００は、本明細書において「アプリサーバ」とも呼ばれ、テナントデータベース４２２及びその中のテナントデータ５２３、並びにシステムデータベース４２４及びその中のシステムデータ５２５と通信して、ユーザシステム５１２から受信した要求をサービスするように構成される。テナントデータ５２３は、個々のテナントストレージ空間５１３に分割されることができ、テナントストレージ空間５１３は、物理的又は論理的に配置又は分割されてよい。各テナントストレージ空間５１３内で、テナントデータ５１４及びアプリケーションメタデータ５１６が、各ユーザについて同様に割り当てられることができる。例えば、ユーザの最も最近使用した（ＭＲＵ）アイテムのコピーが、ユーザストレージ５１４に記憶されてよい。同様に、テナントである組織全体のＭＲＵアイテムのコピーが、テナントストレージ空間５１３に記憶されてよい。

プロセス空間４２８は、システムプロセス空間５０２、個々のテナントプロセス空間５０４、及びテナント管理プロセス空間５１０を含む。アプリケーションプラットフォーム４１８は、アプリケーション開発者のアプリケーションの作成及び管理をサポートするアプリケーションセットアップメカニズム５３８を含む。こうしたアプリケーション及びその他が、例えば、テナント管理プロセス５１０により管理される１つ以上のテナントプロセス空間５０４として、加入者による実行のために、保存ルーチン５３６によりメタデータとしてテナントデータベース４２２に保存されてよい。こうしたアプリケーションに対する起動は、ＰＬ／ＳＯＱＬ５３４を用いてコード化されてよく、ＰＬ／ＳＯＱＬ５３４は、ＡＰＩ５３２に対するプログラミング言語スタイルインターフェース拡張を提供する。いくつかのＰＬ／ＳＯＱＬ言語実装の詳細な説明が、Craig WeissmanによるMETHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICEと題され2010年6月1日に発行された、本明細書においてその全体を及びすべての目的のために参照により援用される、本発明の譲受人に譲渡された米国特許第7,730,478号で論じられている。アプリケーションに対する起動は、１つ以上のシステムプロセスにより検出でき、上記システムプロセスは、起動を行い、且つ仮想マシン内でアプリケーションとしてメタデータを実行する加入者のために、アプリケーションメタデータ４１６を取り出すことを管理する。

図９のシステム４１６は、ユーザシステム５１２におけるユーザ又は開発者に対する、システム４１６常駐プロセスへのユーザインターフェース（ＵＩ）５３０及びアプリケーションプログラミングインターフェース（ＡＰＩ）５３２をさらに含む。いくつかの他の実装において、環境４１０は、上記で列挙された要素と同じ要素を有さなくてよく、あるいは、上記で列挙された要素に対して代わりに又は追加で他の要素を有してよい。

各アプリケーションサーバ５００は、異なるネットワーク接続を介して、例えばテナントデータ５２３及びシステムデータ５２５に対するアクセスをそれぞれ有するテナントデータベース４２２及びシステムデータベース４２４に、通信可能に結合されることができる。例えば、１つのアプリケーションサーバ５００_１はネットワーク４１４（例えば、インターネット）を介して結合でき、別のアプリケーションサーバ５００_Ｎは直接ネットワークリンクを介して結合でき、別のアプリケーションサーバ（図示されていない）はさらに異なるネットワーク接続により結合できる。トランスファーコントロールプロトコル及びインターネットプロトコル（ＴＣＰ／ＩＰ）は、アプリケーションサーバ５００とシステム４１６との間で通信するために使用できる典型的なプロトコルの例である。しかしながら、使用されるネットワーク相互接続に依存してシステム４１６を最適化するように他のトランスポートプロトコルが使用されてもよいことが当業者に明らかであろう。

いくつかの実装において、各アプリケーションサーバ５００は、システム４１６のテナントである任意の組織に関連づけられた任意のユーザの要求を扱うように構成される。任意の時間に様々な理由でサーバプールからアプリケーションサーバ５００を追加及び削除できることが望ましい可能性があるため、いくつかの実装において、特定のアプリケーションサーバ５００に対するユーザ又は組織のサーバアフィニティが存在しない。いくつかのこうした実装において、ロードバランシング機能（例えば、Ｆ５ Ｂｉｇ‐ＩＰロードバランサ）を実現するインターフェースシステムが、アプリケーションサーバ５００とユーザシステム５１２との間に通信可能に結合されて、アプリケーションサーバ５００に対する要求を分配する。１つの実装において、ロードバランサは、最小接続アルゴリズムを使用して、アプリケーションサーバ５００に対するユーザ要求をルーティングする。ロードバランシングアルゴリズムの他の例、例えば、ラウンドロビン及び観察された応答時間などが使用されてもよい。例えば、いくつかの例において、同一ユーザからの３つの連続した要求が３つの異なるアプリケーションサーバ５００に至ることがあり、異なるユーザからの３つの要求が同一のアプリケーションサーバ５００に至ることがある。このようにして、例として、システム４１６はマルチテナントシステムであり得、このシステム４１６は、いろいろなユーザ及び組織にわたる異なるオブジェクト、データ、及びアプリケーションの記憶とこれらに対するアクセスとを扱う。

１つの例示的なストレージ使用事例において、あるテナントが、各販売員がシステム４１６を使用して自身の販売の態様を管理するところの販売陣（sales force）を採用する会社であり得る。ユーザは、すべてがユーザ個人の販売プロセスに適用可能である連絡先データ、リードデータ、顧客フォローアップデータ、パフォーマンスデータ、ゴール及び進捗データ等を（例えば、テナントデータベース４２２の中に）維持することができる。ＭＴＳ配置の一例において、アクセス、閲覧、修正、報告、送信、算出等すべきデータ及びアプリケーションのすべてが、ネットワークアクセスを超えるものを有さないユーザシステム５１２により維持及びアクセスされることができるため、ユーザは、自身の販売努力及びサイクルを多くの異なるユーザシステムのうちいずれかから管理することができる。例えば、販売員が顧客を訪問し、顧客がそのロビーにおいてインターネットアクセスを有する場合、販売員は、ロビーで顧客が到着するのを待つ間に、この顧客に関する重要なアップデートを得ることができる。

各ユーザの雇用主にかかわらず、各ユーザのデータは他のユーザのデータとは別個に記憶できるが、いくつかのデータが、テナントである所与の組織の複数のユーザ又はユーザ全員によって共有されるか又はアクセス可能である組織範囲のデータであってよい。ゆえに、テナントレベルで割り振られたシステム４１６により管理されるいくつかのデータ構造が存在し得ると同時に、他のデータ構造がユーザレベルで管理されてよい。ＭＴＳが、あり得る競合他社を含む複数のテナントをサポートすることができるため、ＭＴＳは、データ、アプリケーション、及びアプリケーション使用を別個に保持するセキュリティプロトコルを有することができる。さらに、多くのテナントが、自身の独自システムを維持するよりもＭＴＳへのアクセスを選ぶ可能性があるため、冗長性、アップタイム、及びバックアップが、ＭＴＳにおいて実現できるさらなる機能である。ユーザ固有データ及びテナント固有データに加えて、システム４１６は、複数のテナントにより使用可能なシステムレベルのデータ又は他のデータをさらに維持してよい。こうしたシステムレベルのデータには、複数テナント間で共有可能な産業レポート、ニュース、投稿メッセージ等を含むことができる。

いくつかの実装において、ユーザシステム５１２（これは、さらにクライアントシステムであり得る）は、アプリケーションサーバ５００と通信して、システム４１６からのシステムレベル及びテナントレベルのデータを要求し、更新する。こうした要求及び更新は、１つ以上のクエリをテナントデータベース４２２又はシステムデータベース４２４に送信することを含んでよい。システム４１６（例えば、システム４１６の中のアプリケーションサーバ５００）は、所望の情報にアクセスするように設計された１つ以上のＳＱＬステートメント（例えば、１つ以上のＳＱＬクエリ）を自動的に生成することができる。システムデータベース４２４は、データベースからの要求されたデータにアクセスするためのクエリプランを生成してよい。用語「クエリプラン」は、データベースシステム内の情報にアクセスするために使用される１つ以上のオペレーションを一般に参照する。

各データベースは、所定の又はカスタマイズ可能なカテゴリに合わせられたデータを含む、一組の論理テーブルなどのオブジェクトの集合として一般に見ることができる。「テーブル」はデータオブジェクトの一表現であり、本明細書において、いくつかの実装に従うオブジェクト及びカスタムオブジェクトの概念的説明を簡素化するのに使用されることがある。「テーブル」及び「オブジェクト」は本明細書において置き換え可能に使用され得ることが理解されるべきである。各テーブルは、可視のスキーマの中の列又はフィールドとして論理的に配置された１つ以上のデータカテゴリを一般に含む。テーブルの各行又は要素は、フィールドによって定義された各カテゴリについてのデータのインスタンスを含むことができる。例えば、ＣＲＭデータベースが、名前、住所、電話番号、ファックス番号などの基本的な連絡先情報のフィールドで顧客を説明するテーブルを含んでよい。別のテーブルが、顧客、プロダクト、販売価格、日付などの情報のフィールドを含む購入注文を記述してよい。いくつかのＭＴＳ実装において、すべてのテナントによる使用のために、標準のエンティティテーブルが提供されてよい。ＣＲＭデータベースアプリケーションについて、こうした標準のエンティティには、ケース、アカウント、連絡先、リード、及び機会のデータオブジェクトのテーブルを含み、各々が予め定義されたフィールドを含んでよい。本明細書において用いられるとき、用語「エンティティ」もまた、「オブジェクト」及び「テーブル」と置き換え可能に使用されることがある。

いくつかのＭＴＳ実装において、テナントは、カスタムオブジェクトを作成及び記憶することを可能にされ、あるいは、例えばカスタムインデックスフィールドを含むカスタムフィールドを標準のオブジェクトに対して作成することにより、標準のエンティティ又はオブジェクトをカスタマイズすることを可能にされてよい。WeissmanらによるCUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEMと題され2010年8月17日に発行された、本明細書においてその全体を及びすべての目的のために参照により援用される、本発明の譲受人に譲渡された米国特許第7,779,039号は、マルチテナントデータベースシステムにおいてカスタムオブジェクトを作成し、標準オブジェクトをカスタマイズするためのシステム及び方法を教示している。いくつかの実装において、例えば、すべてのカスタムエンティティデータ行が単一のマルチテナントの物理テーブルに記憶され、このテーブルは組織ごとに複数の論理テーブルを含むことがある。顧客の複数の「テーブル」が実際は１つの大きいテーブルに記憶されること、又は、顧客のデータが他の顧客のデータと同じテーブルに記憶され得ることは、顧客に対して透過的である。

図１０Ａは、いくつかの実装によるオンデマンドデータベースサービス環境６００のアーキテクチャコンポーネントの例を示すシステム図を示す。本明細書に説明されるように、組み合わされた１つ以上のネットワークを一般に参照するクラウド６０４に通信可能に接続されたクライアントマシンは、１つ以上のエッジルータ６０８及び６１２を介してオンデマンドデータベースサービス環境６００と通信することができる。クライアントマシンは、上記で説明されたユーザシステム１２のうち任意のものの例であり得る。エッジルータは、ファイアウォール６１６を通じて１つ以上のコアスイッチ６２０及び６２４と通信することができる。コアスイッチは、ロードバランサ６２８と通信することができ、ロードバランサ６２８は、ポッド６４０及び６４４などの異なるポッド上にサーバ負荷を分配することができる。ポッド６４０及び６４４は、１つ以上のサーバ又は他のコンピューティングリソースを各々含むことができ、オンデマンドサービスを提供するために使用されるデータ処理及び他の動作を実行することができる。ポッドとの通信は、ポッドスイッチ６３２及び６３６を介して行うことができる。オンデマンドデータベースサービス環境のコンポーネントは、データベースファイアウォール６４８及びデータベーススイッチ６５２を通じてデータベースストレージ６５６と通信することができる。

図１０Ａ及び図１０Ｂに示されるように、オンデマンドデータベースサービス環境にアクセスすることは、様々な異なるハードウェア又はソフトウェアコンポーネント間で送信される通信を含むことができる。さらに、オンデマンドデータベースサービス環境６００は、実際のオンデマンドデータベースサービス環境の簡素化された表現である。例えば、図１０Ａ及び図１０Ｂには、各タイプの１つ又は２つのデバイスのみが示されているが、オンデマンドデータベースサービス環境のいくつかの実装は、各タイプの１つから複数の範囲のデバイスを含むことができる。また、オンデマンドデータベースサービス環境は、図１０Ａ及び図１０Ｂに示される各デバイスを含む必要はなく、あるいは図１０Ａ及び図１０Ｂに示されないさらなるデバイスを含むことができる。

さらに、オンデマンドデータベースサービス環境６００内のデバイスの１つ以上が、同一の物理デバイス上又は異なるハードウェア上に実現できることが理解されるべきである。いくつかのデバイスは、ハードウェア又はハードウェアとソフトウェアの組み合わせを使用して実現できる。ゆえに、本明細書において使用される「データ処理装置」、「マシン」、「サーバ」、及び「デバイス」のような用語は、単一のハードウェアデバイスに限定されず、むしろ、これらの用語への参照は、説明された機能性を提供するよう構成されたハードウェア及びソフトウェアの任意の適切な組み合わせを含むことができる。

クラウド６０４は、しばしばインターネットを含むデータネットワーク又は複数のデータネットワークを参照することを意図している。クラウド６０４と通信可能に接続されたクライアントマシンは、オンデマンドデータベースサービス環境６００の他のコンポーネントと通信して、オンデマンドデータベースサービス環境により提供されるサービスにアクセスすることができる。例えば、クライアントマシンは、オンデマンドデータベースサービス環境にアクセスして、情報を取り出し、保存、編集、又は処理することができる。いくつかの実装において、エッジルータ６０８及び６１２は、クラウド６０４とオンデマンドデータベースサービス環境６００の他の構成要素との間でパケットをルーティングする。例えば、エッジルータ６０８及び６１２は、ボーダーゲートウェイプロトコル（ＢＧＰ）を採用することができる。ＢＧＰはインターネットのコアルーティングプロトコルである。エッジルータ６０８及び６１２は、インターネット上の自律システム間のネットワーク到達性を指定するＩＰネットワーク又は「プレフィックス」のテーブルを維持することができる。

いくつかの実装において、ファイアウォール６１６は、オンデマンドデータベースサービス環境６００の内部コンポーネントをインターネットトラフィックから保護することができる。ファイアウォール６１６は、一組のルール及び他の基準に基づいて、オンデマンドデータベースサービス環境６００の内部コンポーネントへのアクセスをブロック、許可、又は拒否することができる。ファイアウォール６１６は、パケットフィルタ、アプリケーションゲートウェイ、ステートフルフィルタ、プロキシサーバ、又は任意の他タイプのファイアウォールのうちの１つ以上として動作することができる。

いくつかの実装において、コアスイッチ６２０及び６２４は、オンデマンドデータベースサービス環境６００内のパケットを転送する高キャパシティスイッチである。コアスイッチ６２０及び６２４は、オンデマンドデータベースサービス環境内の異なるコンポーネント間でデータを迅速にルーティングするネットワークブリッジとして構成できる。いくつかの実装において、２つ以上のコアスイッチ６２０及び６２４の使用は、冗長性又は低減されたレイテンシを提供し得る。

いくつかの実装において、ポッド６４０及び６４４は、オンデマンドデータベースサービス環境により提供されるコアデータ処理及びサービス機能を実行する。各ポッドは、様々なタイプのハードウェア又はソフトウェアコンピューティングリソースを含むことができる。ポッドアーキテクチャの一例が、図１０Ｂを参照してより詳細に論じられる。いくつかの実装において、ポッド６４０と６４４との間の通信は、ポッドスイッチ６３２及び６３６を介して行われる。ポッドスイッチ６３２及び６３６は、例えばコアスイッチ６２０及び６２４を介して、ポッド６４０及び６４４とクラウド６０４に通信可能に接続されたクライアントマシンとの間の通信を容易にすることができる。また、ポッドスイッチ６３２及び６３６は、ポッド６４０及び６４４とデータベースストレージ６５６との間の通信を容易にし得る。いくつかの実装において、ロードバランサ６２８は、ポッド６４０と６４４との間でワークロードを分配することができる。ポッド間のオンデマンドサービス要求のバランスをとることは、リソースの使用を向上し、スループットを増加し、応答時間を低減し、又はオーバーヘッドを低減するのに役立つ可能性がある。ロードバランサ６２８は、トラフィックを分析及び転送するためのマルチレイヤスイッチを含んでよい。

いくつかの実装において、データベースストレージ６５６へのアクセスは、データベースファイアウォール６４８により守られる。データベースファイアウォール６４８は、プロトコルスタックのデータベースアプリケーションレイヤで動作するコンピュータアプリケーションファイアウォールとして動作することができる。データベースファイアウォール６４８は、構造問合せ言語（ＳＱＬ）インジェクション、データベースルートキット、及び承認されていない情報開示などのアプリケーション攻撃からデータベースストレージ６５６を保護することができる。いくつかの実装において、データベースファイアウォール６４８は、トラフィックをゲートウェイルータに渡す前にトラフィックをプロキシする（proxy）よう１つ以上の形式のリバースプロキシサービスを使用するホストを含む。データベースファイアウォール６４８は、データベーストラフィックの内容を検査し、特定のコンテンツ又はデータベース要求をブロックすることができる。データベースファイアウォール６４８は、ＴＣＰ／ＩＰスタックの上のＳＱＬアプリケーションレベルで動作して、データベース又はＳＱＬ管理インターフェースへのアプリケーションの接続を管理し、データベースネットワーク又はアプリケーションインターフェースへ又はこれらから移動するパケットを傍受及び強制することができる。

いくつかの実装において、データベースストレージ６５６との通信は、データベーススイッチ６５２を介して行われる。マルチテナントデータベースストレージ６５６は、データベースクエリを扱うための２つ以上のハードウェア又はソフトウェアコンポーネントを含むことができる。したがって、データベーススイッチ６５２は、オンデマンドデータベースサービス環境の他のコンポーネント（例えば、ポッド６４０及び６４４）により送信されたデータベースクエリを、データベースストレージ６５６内の正しいコンポーネントに向けることができる。いくつかの実装において、データベースストレージ６５６は、図８及び図９を参照して上記で説明したように、多くの異なる組織により共有されるオンデマンドデータベースシステムである。

図１０Ｂは、いくつかの実装によるオンデマンドデータベースサービス環境のアーキテクチャコンポーネントの例をさらに示すシステム図を示す。ポッド６４４は、オンデマンドデータベースサービス環境６００のユーザにサービスを行うために使用できる。いくつかの実装において、各ポッドは様々なサーバ又は他のシステムを含む。ポッド６４４は、１つ以上のコンテンツバッチサーバ６６４、コンテンツ検索サーバ６６８、クエリサーバ６８２、ファイルフォース（file force）サーバ６８６、アクセス制御システム（ＡＣＳ）サーバ６８０、バッチサーバ６８４、及びアプリサーバ６８８を含む。ポッド６４４はまた、データベースインスタンス６９０、クイックファイルシステム（ＱＦＳ）６９２、及びインデクサ６９４を含むことができる。いくつかの実装において、ポッド６４４内のサーバ間の一部又は全部の通信がスイッチ６３６を介して送信され得る。

いくつかの実装において、アプリサーバ６８８は、ポッド６４４を介してオンデマンドデータベースサービス環境６００により提供されるアプリケーションの構築をサポートするための手順（例えば、プログラム、ルーチン、スクリプト）の実行専用のハードウェア又はソフトウェアフレームワークを含む。いくつかの実装において、アプリサーバ６８８のハードウェア又はソフトウェアフレームワークは、本明細書に説明される様々な方法又はプロセスのブロックの実行を含む、本明細書に説明されるサービスの動作を実行するように構成される。いくつかの代替的な実装において、２つ以上のアプリサーバ６８８が含まれ、こうした方法を実行するために協働することができ、あるいは本明細書に説明される１つ以上の他のサーバが、開示の方法を実行するように構成されてよい。

コンテンツバッチサーバ６６４は、ポッドの内部の要求を扱うことができる。いくつかのこうした要求は、長期にわたり、あるいは特定の顧客に結び付けられないことがある。例えば、コンテンツバッチサーバ６６４は、ログマイニング、クリーンアップワーク、及びメンテナンスタスクに関連する要求を扱うことができる。コンテンツ検索サーバ６６８は、クエリ及びインデクサ機能を提供することができる。例えば、コンテンツ検索サーバ６６８により提供される機能は、ユーザがオンデマンドデータベースサービス環境に記憶されたコンテンツを検索することを可能にし得る。ファイルフォースサーバ６８６は、ファイルフォースストレージ６９８に記憶された情報の要求を管理することができる。ファイルフォースストレージ６９８は、文書、画像、及びベーシックラージオブジェクト（ＢＬＯＢ）などの情報を記憶することができる。ファイルフォースサーバ６８６を使用して情報の要求を管理することにより、データベース上のイメージフットプリントを低減することができる。クエリサーバ６８２は、１つ以上のファイルストレージシステムから情報を取り出すために使用できる。例えば、クエリシステム６８２は、アプリサーバ６８８から情報の要求を受信し、ポッドの外側に位置するＮＦＳ６９６に情報クエリを送信することができる。

ポッド６４４は、異なる組織が同じデータベースへのアクセスを共有するマルチテナント環境として構成されたデータベースインスタンス６９０を共有することができる。さらに、ポッド６４４により行われるサービスは、様々なハードウェア又はソフトウェアリソースを要求することができる。いくつかの実装において、ＡＣＳサーバ６８０は、データ、ハードウェアリソース、又はソフトウェアリソースへのアクセスを制御する。いくつかの実装において、バッチサーバ６８４は、指定された時間にタスクを実行するために使用されるバッチジョブを処理する。例えば、バッチサーバ６８４は、バッチジョブをトリガするために、命令をアプリサーバ６８８などの他のサーバに送信することができる。

いくつかの実装において、ＱＦＳ６９２は、カリフォルニア州サンタクララのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）から入手可能なオープンソースファイルストレージシステムである。ＱＦＳは、ポッド６４４内で利用可能な情報を記憶しアクセスするための高速アクセスファイル記憶システムとして機能することができる。ＱＦＳ６９２は、いくつかのボリューム管理能力をサポートすることができ、多くのディスクをファイルストレージシステムに一緒にグループ化することができる。ファイルストレージシステムのメタデータは別個のディスクセットに保持することができ、これは、長いディスクシークが許容できないストリーミングアプリケーションに有用であり得る。ゆえに、ＱＦＳシステムは、ネットワークファイルストレージシステム６９６又は他のストレージシステムに記憶されたデータを識別、取り出し、移動、又は更新するために、１つ以上のコンテンツ検索サーバ６６８又はインデクサ６９４と通信することができる。

いくつかの実装において、１つ以上のクエリサーバ６８２は、ポッド６４４の外側に記憶された情報を取り出し又は更新するために、ＮＦＳ６９６と通信する。ＮＦＳ６９６は、ポッド６４４内に位置するサーバが、ローカルストレージがアクセスされる方法と同様の方法でネットワークを通じてファイルにアクセスするための情報にアクセスすることを可能にし得る。いくつかの実装において、クエリサーバ６８２からのクエリは、ロードバランサ６２８を介してＮＦＳ６９６に送信され、ロードバランサ６２８は、オンデマンドデータベースサービス環境で利用可能な様々なリソースにわたりリソース要求を分配することができる。また、ＮＦＳ６９６は、ＱＦＳ６９２と通信して、ＮＦＳ６９６に記憶された情報を更新し、あるいはポッド６４４内に位置するサーバによる使用のためにＱＦＳ６９２に情報を提供することができる。

いくつかの実装において、ポッドは、１つ以上のデータベースインスタンス６９０を含む。データベースインスタンス６９０は、ＱＦＳ６９２に情報を送信することができる。情報がＱＦＳに送信されたとき、それは、さらなるデータベース呼び出しを使用することなく、ポッド６４４内のサーバによる使用に利用可能であり得る。いくつかの実装において、データベース情報はインデクサ６９４に送信される。インデクサ６９４は、データベース６９０又はＱＦＳ６９２で利用可能な情報のインデックスを提供することができる。インデックス情報は、ファイルフォースサーバ６８６又はＱＦＳ６９２に提供され得る。

図１１は、本明細書で論じられる方法論のうち任意の１つ以上をマシンに実行させる命令セットが実行され得るコンピュータシステム７００の例示的形態におけるマシンの図表現を示す。システム７００は、マシンに本明細書で論じられた方法論のうち任意の１つ以上を実行させる命令セットが実行され得るコンピュータシステムの形態であってよい。別の実施形態において、マシンは、ＬＡＮ、イントラネット、エクストラネット、又はインターネット内の他のマシンに接続（例えば、ネットワーク接続）されてもよい。マシンは、クライアント／サーバネットワーク環境でサーバマシンのキャパシティで動作してよい。マシンは、パーソナルコンピュータ（ＰＣ）、セットトップボックス（ＳＴＢ）、サーバ、ネットワークルータ、スイッチ若しくはブリッジ、又はそのマシンにより取られるべきアクションを指定する命令セット（順次又はその他）を実行することができる任意のマシンであってよい。さらに、単一のマシンのみが図示されているが、用語「マシン」はまた、本明細書で論じられる方法論のうちいずれか１つ以上を実行する命令のセット（又は複数のセット）を個々に又は連帯的に実行するマシンの任意の集合を含むとみなされるものとする。

例示的なコンピュータシステム７００は、処理デバイス（プロセッサ）７０２、メインメモリ７０４（例えば、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリ、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、例えば同期ＤＲＡＭ（ＳＤＲＡＭ）など）、スタティックメモリ７０６（例えば、フラッシュメモリ、スタティックランダムアクセスメモリ（ＳＲＡＭ））、及びデータストレージデバイス７１８を含み、これらはバス７３０を介して互いに通信する。

処理デバイス７０２は、マイクロプロセッサ、中央処理ユニットなどの１つ以上の汎用処理デバイスを表す。より詳細には、処理デバイス７０２は、複合命令セット計算（ＣＩＳＣ）マイクロプロセッサ、縮小命令セット計算（ＲＩＳＣ）マイクロプロセッサ、超長命令語（ＶＬＩＷ）マイクロプロセッサ、又は他の命令セットを実現するプロセッサ若しくは命令セットの組み合わせを実現するプロセッサであってよい。また、処理デバイス７０２は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサなどの１つ以上の専用処理デバイスであってもよい。

コンピュータシステム７００は、ネットワークインターフェースデバイス７０８をさらに含んでよい。コンピュータシステム７００はまた、ビデオ表示ユニット７１０（例えば、液晶ディスプレイ（ＬＣＤ）又は陰極線管（ＣＲＴ））、英数字入力デバイス７１２（例えば、キーボード）、カーソル制御デバイス７１４（例えば、マウス）、及び信号生成デバイス７１６（例えば、スピーカ）を含んでもよい。

データストレージデバイス７１８は、本明細書に説明される方法論又は機能のうちいずれか１つ以上を具現化する命令７２２の１つ以上のセット（例えば、インメモリバッファサービス７４の命令）が記憶されたコンピュータ読み取り可能媒体７２８を含んでよい。また、命令７２２は、コンピュータ読み取り可能媒体を同様に構成するコンピュータシステム７００、メインメモリ７０４、及び処理デバイス７０２によるその実行中に、処理デバイス７０２のメインメモリ７０４内及び／又は処理論理７２６内に、完全に又は少なくとも部分的に存在してもよい。命令はさらに、ネットワークインターフェースデバイス７０８を介してネットワーク７２０を通じて送信又は受信されてもよい。

コンピュータ読み取り可能記憶媒体７２８は、一例示的な実施形態において単一の媒体であるように示されているが、用語「コンピュータ読み取り可能記憶媒体」は、１つ以上の命令セットを記憶する単一の媒体又は複数の媒体（例えば、集中型又は分散型のデータベース、及び／又は関連づけられたキャッシュ及びサーバ）を含むとみなされるべきである。用語「コンピュータ読み取り可能記憶媒体」は、また、マシンによる実行のための命令セットを記憶、エンコード、又は搬送することができ、且つマシンに本発明の方法論のうち任意の１つ以上を実行させる任意の媒体を含むとみなされるものとする。したがって、用語「コンピュータ読み取り可能記憶媒体」は、これらに限定されないがソリッドステートメモリ、光媒体、及び磁気媒体を含むとみなされるものとする。

前述の説明は、本発明のいくつかの実施形態の良い理解を提供するために、特定のシステム、コンポーネント、方法等の例などの多くの特定の詳細を記述している。しかしながら、本発明の少なくともいくつかの実施形態がこれら特定の詳細なしに実施され得ることが当業者に明らかであろう。他の例において、周知のコンポーネント又は方法は、本発明を不要に分かりにくくすることを避けるために、詳細に説明されず、あるいは簡素なブロック図形式で提示される。ゆえに、記述された特定の詳細は単に例示に過ぎない。具体的な実装はこれらの例示的な詳細と異なってよく、依然として本発明の範囲内にあることが意図される。

上述の説明では、多くの詳細が記述されている。しかしながら、本開示の恩恵を有する当業者には、本発明の実施形態がこれら特定の詳細なしに実施され得ることが明らかであろう。いくつかの場合、説明を分かりにくくすることを避けるために、周知の構造及びデバイスが詳細ではなくブロック図形式で示される。

詳細な説明のいくつかの部分は、コンピュータメモリ内のデータビットに対する演算のアルゴリズム及び記号表現の観点で提示されている。これらのアルゴリズム説明及び表現は、他の当業者にその作用の実体を最も効果的に伝えるために、データ処理分野の当業者により使用される手段である。アルゴリズムは、ここで、そして一般に、所望の結果をもたらすステップの自己一貫したシーケンスであると考えられる。ステップは、物理量の物理的操作を必要とするステップである。必ずではないが、通常、これらの量は、記憶され、転送され、組み合わせられ、比較され、またその他の方法で操作されることができる、電気又は磁気信号の形式をとる。主に公共的使用の理由で、これらの信号をビット、値、要素、シンボル、キャラクタ、語、数字などと呼ぶことが時に便利であることが判明している。

しかしながら、上記のすべて及び同様の用語は適切な物理量に関連づけられるべきであり、これら量に適用される簡便なラベルに過ぎないという点に留意すべきである。上述の議論から明らかなように、別段具体的に示されない限り、説明全体を通じて、「決定する」、「識別する」、「追加する」、「選択する」などの用語を利用する議論は、コンピュータシステムのレジスタ及びメモリ内の物理量（例えば、電子）として表されるデータを、コンピュータシステムのメモリ若しくはレジスタ又は他のこうした情報記憶、送信、若しくは表示デバイス内の物理量として同様に表される他のデータへ操作及び変換する、コンピュータシステム又は同様の電子コンピューティングデバイスのアクション及びプロセスを参照することが十分理解される。

本発明の実施形態はまた、本明細書における動作を実行する装置に関する。この装置は、必要とされる目的に対して特別に構築されてよく、あるいはコンピュータに記憶されたコンピュータプログラムにより選択的に作動又は再構成される汎用コンピュータを含んでもよい。こうしたコンピュータプログラムは、これらに限られないがフロッピーディスク、光ディスク、ＣＤ−ＲＯＭ、及び磁気光ディスクを含む任意タイプのディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光学カード、又は電子命令を記憶するのに適した任意タイプの媒体などの、コンピュータ読み取り可能記憶媒体に記憶されてよい。

本明細書に提示されるアルゴリズム及び表示は本質的に、いずれかの特定のコンピュータ又は他の装置に関連しない。様々な汎用システムが本明細書の教示に従うプログラムと共に使用されてよく、あるいは、必要とされる方法ステップを実行するためにより特化された装置を構築することが便利と判明する可能性がある。様々なこれらのシステムに必要とされる構造は以下の説明から明らかになる。さらに、本発明は、いずれかの特定のプログラミング言語を参照して説明されていない。本明細書に説明される本発明の教示を実現するために、様々なプログラミング言語が使用され得ることが十分理解される。

前述の詳細な説明において少なくとも１つの例示的な実施形態が提示されたが、多数のバリエーションが存在することが十分理解されるべきである。また、本明細書に説明する１つ又は複数の例示的な実施形態は、請求される対象事項の範囲、適用可能性、又は構成を何らかの方法で限定するよう意図するものではないことが理解されるべきである。むしろ、前述の詳細な説明は、説明された１つ又は複数の実施形態を実現するための便利なロードマップを当業者に提供するであろう。本特許出願の出願時に既知の均等物及び予見可能な均等物を含む、特許請求の範囲により定義される範囲から逸脱することなく、要素の機能及び配置において様々な変更がなされ得ることが理解されるべきである。

Claims (21)

1. プライマリサイトを含むデータベースシステムにおける方法であって、前記プライマリサイトは、プライマリデータベースが利用可能であるとき前記プライマリデータベースにデータを書き込み且つ前記プライマリデータベースからデータを読み取るアプリケーションサーバをさらに含み、当該方法は、
   自己修復モジュールにより、前記プライマリデータベースの利用不能を自動的に検出するステップと、
   前記自己修復モジュールにより、前記プライマリサイトのスタンバイデータベースが利用可能であるかどうかを決定するステップであり、前記スタンバイデータベースは前記プライマリデータベースの複製である、ステップと、
   前記自己修復モジュールが、前記プライマリデータベースが利用不能であると検出し前記スタンバイデータベースが利用可能であると決定したとき、前記自己修復モジュールによりフェイルオーバ処理シーケンスを自動的に開始するステップであり、前記フェイルオーバ処理シーケンスは、
   前記スタンバイデータベースを読み取り可能及び書き込み可能として自動的に有効にし、前記スタンバイデータベースに、他のスタンバイデータベースへのデータの複製を開始するよう前記プライマリサイトにおけるプライマリデータベースのロールを割り当てることと、
   フェイルオーバロール移行の後、前記アプリケーションサーバと前記スタンバイデータベースとの間の予め確立された接続を使用して、前記アプリケーションサーバが前記スタンバイデータベースからデータを読み取り且つ前記スタンバイデータベースにデータを書き込むことを可能にし、前記スタンバイデータベースが前記プライマリサイトにおける前記プライマリデータベースのロールを引き受けることを結果としてもたらすことと、
   を含む、ステップと、
   を含む方法。
2. 前記スタンバイデータベースに記憶されたデータのスナップショットを周期的に取るステップと、
   データの前記スナップショットを前記プライマリサイトに実現されない別個のストレージハードウェアを含むスナップショットストレージシステムに記憶するステップと、
   をさらに含む請求項１に記載の方法。
3. 前記スタンバイデータベースは第１のスタンバイデータベースであり、前記フェイルオーバ処理シーケンスは、
   前記自己修復モジュールにおいて、スナップショットストレージシステムに記憶された前記プライマリデータベースからの最も最近のスナップショットデータを使用して新しいデータベースを自動的に作成することと、
   前記自己修復モジュールにおいて、前記新しいデータベースを前記プライマリサイトにおける第２のスタンバイデータベースとして自動的に追加して、キャパシティをフルに回復することと、
   をさらに含む請求項２に記載の方法。
4. 前記プライマリデータベースは第１のプライマリデータベースであり、前記データベースシステムは、第２のプライマリデータベースを含む災害復旧サイトをさらに含み、当該方法は、
   前記プライマリサイトのデータベースのすべてが故障し、前記プライマリサイトにおいてスタンバイデータベースが利用可能でないとき、ロードバランサを介し、ユーザシステムからのトラフィックを前記第２のプライマリデータベースへのアクセスを有する前記災害復旧サイトにおけるアプリケーションサーバに向けるステップ
   をさらに含む請求項１、２、又は３に記載の方法。
5. 前記自己修復モジュールが前記スタンバイデータベースが前記プライマリサイトにおいて利用可能であると決定したとき、前記アプリケーションサーバが前記プライマリサイトにおける前記スタンバイデータベースからの読み取り専用アクセスを有することを一時的に可能にするステップ
   をさらに含む請求項１乃至４のうちいずれか１項に記載の方法。
6. 前記自己修復モジュールが前記スタンバイデータベースが前記プライマリサイトにおいて利用可能であると決定したとき、前記自己修復モジュールにおいて、前記フェイルオーバ処理シーケンスを自動的に開始する前に、前記プライマリサイトにおける前記プライマリデータベースが復旧時間内に復旧したかどうかを決定するステップと、
   前記プライマリサイトにおける前記プライマリデータベースが前記復旧時間内に復旧しなかったとき、前記自己修復モジュールにおいて、前記フェイルオーバ処理シーケンスを自動的に開始するステップと、
   をさらに含む請求項１乃至５のうちいずれか１項に記載の方法。
7. 前記自己修復モジュールが前記プライマリサイトにおける前記プライマリデータベースが前記復旧時間内に復旧したと決定したとき、前記プライマリデータベースを自動的に再開するステップであり、前記アプリケーションサーバにおけるアプリケーションは前記プライマリデータベースとして前記プライマリサイトからの前記プライマリデータベースを継続して使用する、ステップ
   をさらに含む請求項６に記載の方法。
8. 前記プライマリデータベースは第１のデータベースサーバ及び第１のストレージサブシステムを含み、前記スタンバイデータベースは第２のデータベースサーバ及び第２のストレージサブシステムを含み、
   自動的に有効にする前に、前記第１のストレージサブシステムを完全でアクセス可能な場合に復旧のために前記第１のデータベースサーバから前記第２のデータベースサーバに自動的にアタッチするステップ
   をさらに含む請求項１乃至７のうちいずれか１項に記載の方法。
9. プロセッサ及びメモリを含むコンピューティングシステムであって、前記メモリはコンピュータ実行可能命令を含み、前記コンピュータ実行可能命令は当該コンピューティングシステムに、
   プライマリサイトにおけるプライマリデータベースの利用不能を自動的に検出することであって、前記プライマリサイトは、前記プライマリデータベースが利用可能であるとき前記プライマリデータベースにデータを書き込み且つ前記プライマリデータベースからデータを読み取るアプリケーションサーバをさらに含み、
   前記プライマリサイトにおいてスタンバイデータベースが依然として利用可能であるかどうかを決定することであって、前記スタンバイデータベースは前記プライマリデータベースの複製であり、
   前記プライマリデータベースが利用不能であると検出され前記スタンバイデータベースが利用可能であると決定されたとき、フェイルオーバ処理シーケンスを自動的に開始することであって、前記フェイルオーバ処理シーケンスは、
   前記スタンバイデータベースを読み取り可能及び書き込み可能として自動的に有効にし、前記スタンバイデータベースに、他のスタンバイデータベースへのデータの複製を開始するよう前記プライマリサイトにおけるプライマリデータベースのロールを割り当てることと、
   フェイルオーバロール移行の後、前記アプリケーションサーバと前記スタンバイデータベースとの間の予め確立された接続を使用して、前記アプリケーションサーバが前記スタンバイデータベースからデータを読み取り且つ前記スタンバイデータベースにデータを書き込むことを可能にし、前記スタンバイデータベースが前記プライマリサイトにおける前記プライマリデータベースのロールを引き受けることを結果としてもたらすことと、を含む
   ことをさせることができる、コンピューティングシステム。
10. 前記コンピュータ実行可能命令はさらに当該コンピューティングシステムに、
    前記スタンバイデータベースに記憶されたデータのスナップショットを周期的に取ることであって、前記スタンバイデータベースは第１のスタンバイデータベースであり、
    データの前記スナップショットを前記プライマリサイトに実現されない別個のストレージハードウェアを含むスナップショットストレージシステムに記憶し、
    スナップショットストレージシステムに記憶された前記プライマリデータベースからの最も最近のスナップショットデータを使用して新しいデータベースを自動的に作成し、
    前記新しいデータベースを前記プライマリサイトにおける第２のスタンバイデータベースとして自動的に追加してキャパシティをフルに回復する
    ことをさせることができる、請求項９に記載のコンピューティングシステム。
11. 前記コンピュータ実行可能命令はさらに当該コンピューティングシステムに、
    前記スタンバイデータベースが前記プライマリサイトにおいて利用可能であると決定されたとき、前記アプリケーションサーバが前記プライマリサイトにおける前記スタンバイデータベースからの読み取り専用アクセスを有することを一時的に可能にする
    ことをさせることができる、請求項９又は１０に記載のコンピューティングシステム。
12. 前記プライマリデータベースは第１のデータベースサーバ及び第１のストレージサブシステムを含み、前記スタンバイデータベースは第２のデータベースサーバ及び第２のストレージサブシステムを含み、前記コンピュータ実行可能命令はさらに当該コンピューティングシステムに、
    自動的に有効にする前に、前記第１のストレージサブシステムを完全でアクセス可能な場合に復旧のために前記第１のデータベースサーバから前記第２のデータベースサーバに自動的にアタッチする
    ことをさせることができる、請求項９、１０、又は１１に記載のコンピューティングシステム。
13. 自動自己修復データベースシステムであって、
    プライマリサイトを含み、前記プライマリサイトは、
    プライマリデータベースと、
    前記プライマリデータベースが利用可能であるとき前記プライマリデータベースにデータを書き込み且つ前記プライマリデータベースからデータを読み取るアプリケーションサーバと、
    前記プライマリデータベースの複製であるスタンバイデータベースと、
    自己修復モジュールと
    を含み、前記自己修復モジュールは、
    前記プライマリデータベースの利用不能を自動的に検出し、
    前記プライマリサイトの前記スタンバイデータベースが利用可能であるかどうかを決定し、
    前記自己修復モジュールが、前記プライマリデータベースが利用不能であると検出し前記プライマリサイトの前記スタンバイデータベースが利用可能であると決定したとき、フェイルオーバ処理シーケンスを自動的に開始することであって、前記フェイルオーバ処理シーケンスは、
    前記スタンバイデータベースを読み取り可能及び書き込み可能として自動的に有効にし、前記スタンバイデータベースに、他のスタンバイデータベースへのデータの複製を開始するよう前記プライマリサイトにおけるプライマリデータベースのロールを割り当てることと、
    フェイルオーバロール移行の後、前記アプリケーションサーバと前記スタンバイデータベースとの間の予め確立された接続を使用して、前記アプリケーションサーバが前記スタンバイデータベースからデータを読み取り且つ前記スタンバイデータベースにデータを書き込むことを可能にし、前記スタンバイデータベースが前記プライマリサイトにおける前記プライマリデータベースのロールを引き受けることを結果としてもたらすことと、を含む
    ように構成される、自動自己修復データベースシステム。
14. 前記自己修復モジュールは、前記スタンバイデータベースに記憶されたデータのスナップショットを周期的に取るようにさらに構成され、当該自動自己修復データベースシステムは、
    遠隔に位置し且つ前記プライマリサイトに実現されない別個のストレージハードウェアを含むスナップショットストレージシステム、をさらに含み、前記スナップショットストレージシステムは、データの前記スナップショットを記憶するように構成される、請求項１３に記載の自動自己修復データベースシステム。
15. 前記スタンバイデータベースは第１のスタンバイデータベースであり、前記自己修復モジュールは、前記フェイルオーバ処理シーケンスの一部として、スナップショットストレージシステムに記憶された前記プライマリデータベースからの最も最近のスナップショットデータを使用して新しいデータベースを自動的に作成し、前記新しいデータベースを前記プライマリサイトにおける第２のスタンバイデータベースとして自動的に追加してキャパシティをフルに回復するようにさらに構成される、請求項１４に記載の自動自己修復データベースシステム。
16. 前記プライマリデータベースは第１のプライマリデータベースであり、当該自動自己修復データベースシステムは、
    ロードバランサと、
    アプリケーションサーバ及び第２のプライマリデータベースを含む災害復旧サイトと、
    をさらに含み、
    前記ロードバランサは、前記プライマリサイトのデータベースのすべてが故障し、前記プライマリサイトにおいてスタンバイデータベースが利用可能でないとき、ユーザシステムからのトラフィックを前記第２のプライマリデータベースへのアクセスを有する前記災害復旧サイトにおける前記アプリケーションサーバに向けるように構成される、
    請求項１３乃至１５のうちいずれか１項に記載の自動自己修復データベースシステム。
17. 前記自己修復モジュールは、前記自己修復モジュールが前記スタンバイデータベースが前記プライマリサイトにおいて利用可能であると決定したとき、前記アプリケーションサーバが前記プライマリサイトにおける前記スタンバイデータベースからの読み取り専用アクセスを有することを一時的に可能にするようにさらに構成される、請求項１３乃至１６のうちいずれか１項に記載の自動自己修復データベースシステム。
18. 前記自己修復モジュールは、
    前記自己修復モジュールが前記スタンバイデータベースが前記プライマリサイトにおいて利用可能であると決定したとき、前記フェイルオーバ処理シーケンスを自動的に開始する前に、前記プライマリサイトにおける前記プライマリデータベースが復旧時間内に復旧したかどうかを決定し、
    前記プライマリサイトにおける前記プライマリデータベースが前記復旧時間内に復旧しなかったとき前記フェイルオーバ処理シーケンスを自動的に開始する
    ようにさらに構成される、請求項１３乃至１７のうちいずれか１項に記載の自動自己修復データベースシステム。
19. 前記自己修復モジュールは、
    前記自己修復モジュールが前記プライマリサイトにおける前記プライマリデータベースが前記復旧時間内に復旧したと決定したとき、前記プライマリデータベースを自動的に再開することであって、前記アプリケーションサーバにおけるアプリケーションは前記プライマリデータベースとして前記プライマリサイトからの前記プライマリデータベースを継続して使用する
    ようにさらに構成される、請求項１８に記載の自動自己修復データベースシステム。
20. 前記プライマリデータベースは第１のデータベースサーバ及び第１のストレージサブシステムを含み、前記スタンバイデータベースは第２のデータベースサーバ及び第２のストレージサブシステムを含み、
    前記自己修復モジュールは、
    自動的に有効にする前に、前記第１のストレージサブシステムを完全でアクセス可能な場合に復旧のために前記第１のデータベースサーバから前記第２のデータベースサーバに自動的にアタッチする
    ようにさらに構成される、請求項１３乃至１９のうちいずれか１項に記載の自動自己修復データベースシステム。
21. コンピューティングシステムに、
    プライマリサイトにおけるプライマリデータベースの利用不能を自動的に検出することであって、前記プライマリサイトは、前記プライマリデータベースが利用可能であるとき前記プライマリデータベースにデータを書き込み且つ前記プライマリデータベースからデータを読み取るアプリケーションサーバをさらに含み、
    前記プライマリサイトにおいてスタンバイデータベースが依然として利用可能であるかどうかを決定することであって、前記スタンバイデータベースは前記プライマリデータベースの複製であり、
    前記プライマリデータベースが利用不能であると検出され前記スタンバイデータベースが利用可能であると決定されたとき、フェイルオーバ処理シーケンスを自動的に開始することであって、前記フェイルオーバ処理シーケンスは、
    前記スタンバイデータベースを読み取り可能及び書き込み可能として自動的に有効にし、前記スタンバイデータベースに、他のスタンバイデータベースへのデータの複製を開始するよう前記プライマリサイトにおけるプライマリデータベースのロールを割り当てることと、
    フェイルオーバロール移行の後、前記アプリケーションサーバと前記スタンバイデータベースとの間の予め確立された接続を使用して、前記アプリケーションサーバが前記スタンバイデータベースからデータを読み取り且つ前記スタンバイデータベースにデータを書き込むことを可能にし、前記スタンバイデータベースが前記プライマリサイトにおける前記プライマリデータベースのロールを引き受けることを結果としてもたらすことと、を含む
    ことをさせることができるコンピュータ実行可能命令を含むコンピュータプログラム。

Images