JP5364850B2 - データ環境のためのセルフサービス構成 - Google Patents

Description

ますます多くのアプリケーションおよびサービスがネットワーク（例えば、インターネット）を介して利用可能となるのにともない、ますます多くのコンテンツ、アプリケーション、および／またはサービスプロバイダがクラウドコンピューティングなどの技術に取りかかっている。クラウドコンピューティングは、一般に、電子リソースへのアクセスをサービス（例えば、ウェブサービス）を通じて提供するアプローチのことであり、それらのサービスをサポートするために用いられるハードウェアおよび／またはソフトウェアは、任意の所与の時期にサービス要求を満たせるよう、動的にスケーラブルである。ユーザまたは顧客は、一般的にクラウドを通じたリソースへのアクセスのためにレンタル、リースまたは支払いを行い、よって、当該リソースへのアクセスのためにハードウェアおよび／またはソフトウェアを購入および維持する必要は無い。

クラウドにおいては、多様なアプリケーションおよびリソースの態様を調節および管理することができる一方、これらのアプリケーションおよびリソースが依存しているデータレポジトリは、同様に調節可能ではない。一般的に、データ記憶のプロビジョニングおよびスケーリングなどのタスクを行うのは面倒な手作業の手順であり、顧客は、データベース管理者（ＤＢＡ）が構成が有効であるかを判断できるように、ＤＢＡまたは同様の熟練したユーザに構成情報および要求を提供しなければならない。その後、ＤＢＡは一般的に、データレポジトリのイネーブル、チューニングおよび最適化を行なければならない。さらに、顧客が動的にかつ／または自動的にデータベースインスタンスのパラメータを調節し、またはデータレポジトリの他のかかる態様を管理する、容易な方法が存在していない。

本開示による多様な実施形態について、図面を参照しながら説明する。

多様な実施形態を実装することができる環境を示す図である。 多様な実施形態に従って利用することが可能である、制御プレーンおよびデータプレーンの分離の一例を示す図である。 一実施形態に従って利用することが可能なデータプレーンにおけるデータインスタンス生成前に、パラメータ値を指定する例示的プロセス図である。 データインスタンスを生成し、一実施形態に従って利用することが可能なデータプレーンにおいて指定されたパラメータ値を適用する例示的プロセス図である。 一実施形態に従って利用することが可能なデータプレーンにおいて、少なくとも１つのデータインスタンスについてのパラメータ値の変更を要求するための例示的プロセス図である。 一実施形態に従って利用可能なデータインスタンスの性能を監視するための例示的プロセス図である。

本開示の多様な実施形態によるシステムおよび方法は、電子環境におけるデータ記憶の態様を管理するための従来のアプローチにおいて経験された、上記の欠陥および他の欠陥のうちの１つ以上を解消する場合がある。具体的には、多様な実施形態は、別個の制御環境または制御プレーンを提供する。別個の制御環境または制御プレーンを用いることで、データ環境またはデータプレーンの多様な態様の管理および／または変更をユーザが行うことが可能になる。この「セルフサービス」機能は、１組のウェブサービスを介して提供することが可能であり、これにより、ユーザおよび制御プレーンを共に仮想データベース管理者（ＤＢＡ）として用いることが可能になる。ユーザまたは顧客は、例えば複数の外部可視アプリケーションプログラミングインターフェース（ＡＰＩ）のうちの１つを通じて制御プレーンへ要求を提出することができる。多様なＡＰＩを用いて、データ環境内のデータレポジトリ（例えば、関係データベース）についての特定の機能を行うことが可能である。ＡＰＩのうちの１つが受信した要求を分析して、データプレーンにおいて行われるべき所望のアクション（単数または複数）（例えば、データ記憶部またはデータ記憶インスタンスの動作パラメータまたは構成パラメータを調節するアクション）を決定することができる。コンポーネント（例えば、ワークフローコンポーネント）により、当該アクションにとって適切なタスクを決定し、当該タスクを適切な順序で実行することが可能になる。これらのタスクのうちの少なくとも１つは、一般的に、データ環境において実行される（例えば、関係データベースの態様の調節）。

図１は、多様な実施形態による態様を実行するための環境１００の一例を示す。理解されるように、説明目的のためにウェブベースの環境を用いているが、多様な実施形態の実行のために適宜異なる環境を使用してもよい。図示の環境１００は、試験部分または開発部分（または側）および生産部分の両方を含む。生産部分は、電子クライアントデバイス１０２を含む。電子クライアントデバイス１０２は、適切なネットワーク１０４を介した、要求、メッセージまたは情報の送受信を行い、かつデバイスのユーザへ情報を返送するように動作可能な任意の適切なデバイスを含むことができる。このようなクライアントデバイスの例としては、パーソナルコンピュータ、携帯電話、ハンドヘルドメッセージングデバイス、ラップトップコンピュータ、セットトップボックス、パーソナルデータアシスタント、電子ブックリーダーなどが挙げられる。ネットワークは、イントラネット、インターネット、セルラーネットワーク、ローカルエリアネットワーク、または他の任意のこのようなネットワークまたはこれらの組み合わせを含む任意の適切なネットワークを含むことができる。このようなシステムのために用いられるコンポーネントは、選択されるネットワークおよび／または環境の種類に少なくとも部分的に依存する可能性がある。このようなネットワークを介した通信のためのプロトコルおよびコンポーネントは周知であり、本明細書中詳述しない。ネットワークを介した通信は、有線接続または無線接続およびこれらの組み合わせによって可能となる。本例において、ネットワークは、インターネットを含む。なぜならば、環境は、要求の受信および受信に応答したコンテンツの提供を行うウェブサーバー１０６を含むが、他のネットワークに対しては、当業者にとって自明の同様の目的を提供する別のデバイスを用いることも可能である。

例示的環境は、少なくとも１つのアプリケーションサーバー１０８およびデータ記憶部１１０を含む。タスク（例えば、適切なデータ記憶部からのデータの入手）を行うように相互作用させることができるように、連鎖させるかまたは別法により構成されてもよい、いくつかのアプリケーションサーバー、層または他の要素、プロセスまたはコンポーネントが存在することができることが理解されるべきである。本明細書で用いられる場合、「データ記憶部」という用語は、データの保存、アクセスおよび取り出しが可能な任意のデバイスまたはデバイスの組み合わせを指し、任意の標準環境、分散型環境またはクラスタ化環境における、任意の組み合わせおよび任意の数の、データサーバー、データベース、データ記憶デバイス、およびデータ記憶媒体を含んでもよい。アプリケーションサーバーは、必要に応じてデータ記憶部と一体化され、アプリケーションのためのデータアクセスおよびビジネスロジックのうちの大部分を取り扱うクライアントデバイスのための１つ以上のアプリケーションの態様を実行するために、任意の適切なハードウェアおよびソフトウェアを含むことができる。アプリケーションサーバーは、データ記憶部と協働してアクセス制御サービスを提供し、コンテンツ（例えば、ユーザへ転送されるべきテキスト、グラフィックス、音声および／またはビデオ）を生成することができる。本例において、コンテンツは、ＨＴＭＬ、ＸＭＬ、または別の適切な構造化言語の形態でウェブサーバーによってユーザに提供されてもよい。全ての要求および応答ならびにクライアントデバイス１０２とアプリケーションサーバー１０８との間のコンテンツの送達の取り扱いは、ウェブサーバーによって行うことができる。ウェブサーバーおよびアプリケーションサーバーは不要であり、例示的なコンポーネントに過ぎないことが理解されるべきである。なぜならば、本明細書中に記載された構造化コードは、本明細書中の他の箇所に記載されたような任意の適切なデバイスまたはホストマシン上において実行することが可能であるからである。さらに、環境は、ユーザまたはアプリケーションが加入することが可能なサービスとして試験自動化フレームワークを提供することが可能な様態の構造にすることができる。試験自動化フレームワークは、本明細書中に記載された多様な試験パターンのうちの任意のものの実装として提供することが可能であるが、本明細書中に記載または提案されるように他の多様な実装も使用することができる。

環境は、ユーザ（例えば、開発者、データ管理者、または試験者）によるシステムへのアクセスを可能にするユーザデバイス１１８を含む、開発側および／または試験側も含む。ユーザデバイス１１８は、任意の適切なデバイスまたはマシン（例えば、クライアントデバイス１０２について上述したようなもの）とすることができる。環境は、開発サーバー１２０も含む。開発サーバー１２０は、アプリケーションサーバー１０８と同様に機能するが、例えば、コードが生産側において展開および実行され、外部ユーザによるコードへのアクセスが可能となる前に、一般的に開発および試験時の間にコードを実行する。いくつかの実施形態において、アプリケーションサーバーは開発サーバーとして機能することができ、別個の生産用記憶部および試験用記憶部は使用されない場合がある。

データ記憶部１１０は、特定の態様に関連するデータを保存するためのいくつかの別個のデータテーブル、データベースまたは他のデータ記憶機構および媒体を含むことができる。例えば、図示のデータ記憶部は、生産データ１１２およびユーザ情報１１６を保存する機構を含む。これらの生産データ１１２およびユーザ情報１１６を用いて、生産側のためのコンテンツを提供することが可能である。また、データ記憶部は、試験データ１１４を保存する機構も含むように示される。試験データ１１４をユーザ情報と共に試験側のために用いることができる。データ記憶部内への保存が必要となる場合がある多くの他の態様（例えば、ページ画像情報およびアクセス権情報のための）がある可能性があり、適宜上記した機構のうちの任意のものに、またはデータ記憶部１１０内の追加的な機構に保存することができることが理解されるべきである。データ記憶部１１０は、自身と関連付けられた論理を通じて、アプリケーションサーバー１０８または開発サーバー１２０からの命令を受信し、命令に応答して、データの入手、更新、または別法により処理を行うように動作可能である。一例において、ユーザは、特定の種類のアイテムについてのサーチ要求を提出してもよい。この場合、データ記憶部は、ユーザ情報にアクセスして当該ユーザの識別情報を確認し、カタログ詳細情報にアクセスして、その種類のアイテムに関する情報を得ることができる。その後、情報をユーザが視認することが可能なウェブページ上の結果リストなどのようにユーザデバイス１０２上のブラウザを介してユーザへ返送することができる。特定の注目のアイテムに対する情報は、ブラウザの専用ページまたはウィンドウ内において視認することができる。

各サーバーは一般的には、サーバーの一般的管理および動作のための実行可能なプログラム命令を提供するオペレーティングシステムを含み、一般的にはコンピュータで読み出し可能な媒体を含む。コンピュータで読み出し可能な媒体は、命令を保存する。命令は、サーバーのプロセッサによって実行されると、サーバーが意図する機能を行うことが可能になる。サーバーのオペレーティングシステムおよび一般的機能性の適切な実装は公知である、または市販されており、特に本明細書中の開示内容を鑑みれば、当業者により容易に実行される。

一実施形態における環境は、通信リンクを介して１つ以上のコンピュータネットワークまたは直接接続を用いて相互接続されたいくつかのコンピュータシステムおよびコンポーネントを用いた分散型コンピューティング環境である。しかし、当業者にとって、このようなシステムは、図１の場合よりもより少数またはより多数のコンポーネントを有するシステムにおいても等しく動作可能であることが明かであろう。よって、図１中のシステム１００の描写は、本質的に例示的なものとしてとられるべきであり、本開示の範囲を制限するものではない。

図１に示すような環境は、プロバイダ（例えば、電子市場）において有用である可能性があり、複数のホストを用いて、タスク（例えば、コンテンツの提供、ユーザの認証、支払取引の実行、または他の複数のこのようなタスクのうちの任意のものの実行）の実行を行うことが可能である。これらのホストのうちのいくつかは、同一機能を提供するように構成されてもよく、一方で他のサーバーは、少なくともいくつかの異なる機能を行うように構成されてもよい。このような場合の電子環境は、さらなるコンポーネントおよび／または他の配置構成（例えば、図２の構成２００に図示するもの）を含んでもよい。

一実施形態によるシステムおよび方法は、開発者、顧客または他の認証されたユーザが、関係データベース「ＲＤＳ」）、および他のこのようなデータソースを容易かつコスト効率良く入手および構成することを可能にする、関係データベースサービスを提供し、これにより、ユーザはタスク（例えば、クラウド中の関係データセットの保存、処理および問い合わせ）を行うことができる。本例は、インターネット、ウェブサービス、およびインターネットベースの技術について説明するが、多様な実施形態の態様は、電子環境内のネットワークを介して利用可能であるかまたは提供される任意の適切なサービスと共に利用することが可能であることが理解されるべきである。さらに、本明細書ではサービスのことを「関係データベースサービス」と呼ぶが、このようなサービスは、電子環境内における任意の適切な種類のデータレポジトリまたはデータ記憶と共に利用することが可能であることが理解されるべきである。本例において、ＲＤＳは、少なくとも１つのウェブサービスを含む。少なくとも１つのウェブサービスにより、ユーザまたは顧客は、展開、アップグレード、パッチ管理、バックアップ、複製、フェイルオーバー、容量管理、スケーリング、およびデータ管理の他のこのような態様における管理の複雑性について懸念する必要無く、関係データセットの管理を容易に行うことが可能になる。よって、開発者は、データベースインフラストラクチャの管理の複雑性について懸念する必要無しに、高度なクラウドアプリケーションの開発から解放される。

一実施形態において、ＲＤＳは、別個の「制御プレーン」を提供する。別個の「制御プレーン」は、データ記憶の態様の管理において有用なコンポーネント（例えば、ハードウェアおよびソフトウェア）を含む。一実施形態において、ユーザまたは顧客が当該データ記憶部に関連するタスクを行うようＲＤＳに呼びかけを作成することを可能にする、１組のデータ管理アプリケーションプログラミングインターフェース（ＡＰＩ）または他のこのようなインターフェースが提供される。しかしながら、その場合でも、ユーザは、直接インターフェースまたはＡＰＩを用いて当該データレポジトリと通信することが可能であり、データ記憶部の管理または同様のタスクの実行が必要になった場合にのみ、制御プレーンのＲＤＳ特有のＡＰＩを利用することが可能である。

図２は、一実施形態に従って利用することが可能なＲＤＳ実装２００の一例を示す。本例において、エンドユーザ用のコンピューティングデバイス２０２が図示されており、タスク（例えば、データプレーン２１０のデータレポジトリをプロビジョニングするタスク）を行うよう、ネットワーク２０６を通して制御プレーン２０８内へ呼びかけを作成することができる。ユーザまたはアプリケーション２０４は、データプレーン２１０のインターフェースを通して、プロビジョニングされたレポジトリに直接アクセスすることができる。エンドユーザコンピューティングデバイスおよびアプリケーションは説明目的のために用いられ、任意の適切なユーザ、アプリケーション、サービス、デバイス、コンポーネントまたはリソースが、多様な実施形態において適宜制御プレーンおよび／またはデータプレーンのインターフェース（単数または複数）にアクセスすることができることが理解されるべきである。さらに、コンポーネントは制御「プレーン」およびデータ「プレーン」に分離されているが、これは、各機能を提供するために用いられる少なくともいくつかのリソース（例えば、ハードウェアおよび／またはソフトウェア）の実際の分離または仮想分離を指すことができることが理解されるべきである。

本例において、制御プレーン２０８は本質的には、制御アクションおよび管理アクション（例えば、プロビジョニング、スケーリング、複製等）を取り扱うハードウェアおよびソフトウェアコンポーネントの仮想層である。この実施形態における制御プレーンは、ウェブサービス層２１２またはウェブサービス階層を含む。ウェブサービス層２１２またはウェブサービス階層は、例えばコンピュータ−実行可能なソフトウェア、アプリケーションサーバーまたは他のこのようなコンポーネントと共に少なくとも１つのウェブサーバーを含むことができる。ウェブサービス層はまた、ネットワーク２０６全体からウェブサービス呼び出しまたは要求を受信するための１組のＡＰＩ２３２（または他のこのようなインターフェース）も含むことができる。各ＡＰＩは、データ環境について行われるべき少なくとも１つの特定のアクション（例えば、関係データベースのインスタンスをプロビジョニングすること、スケールすること、クローンすること、またはハイバネートすること）についての要求を受信するように提供することができる。ＡＰＩのうちの１つへの要求を受信すると、ウェブサービス層は、要求を解析または別法により分析して、呼び出しへの作用または呼び出しの処理に必要なステップまたはアクションを決定することができる。例えば、データレポジトリの生成の要求を含むウェブサービス呼び出しが受信されてもよい。本例において、ウェブサービス層は、要求を解析して、生成すべきデータレポジトリの種類、必要な記憶ボリューム、必要なハードウェアの種類（ただし、存在する場合）または他のこのような態様を決定することができる。要求についての情報は、その後の処理のために、管理（「Ａｄｍｉｎ」）データ記憶部２２２または他の適切な記憶場所またはジョブキューに書き込むことができる。

一実施形態における、ウェブサービス層は、顧客に向いたスケーラブルな１組のサーバーを含む。１組の顧客対向サーバーは、多様な制御プレーンＡＰＩを提供し、ＡＰＩ仕様に基づいて適切な応答を返送することができる。ウェブサービス層は、少なくとも１つのＡＰＩサービス層も含むことができる。一実施形態において、少なくとも１つのＡＰＩサービス層は、ステートレスな複製されたサーバーからなる。ステートレスな複製サーバーは、外向きの顧客ＡＰＩを処理する。ウェブサービス層は、ウェブサービスフロントエンド機能（例えば、認証情報に基づいた顧客認証、顧客の許可、ＡＰＩサーバーへの顧客要求のスロットリング、ユーザ入力の有効化、ならびにマーシャリングまたはマーシャリング解除の要求および応答）を担当することができる。ＡＰＩ層は、ＡＰＩ呼び出しに応答して、管理データ記憶部への／管理データ記憶部からのデータベース構成データの読み出しおよび書き込みも担当することができる。多くの実施形態において、ウェブサービス層および／またはＡＰＩサービス層は、唯一の外部可視コンポーネントとされるか、または、制御サービスの顧客が視認可能であり、かつ制御サービスの顧客によりアクセス可能である唯一のコンポーネントとされる。ウェブサービス層のサーバーは、ステートレスとすることができ、当該分野において公知のように水平方向にスケーリングすることができる。ＡＰＩサーバーだけでなく、永続的データ記憶部は、例えば、単一のデータセンターの不具合に対してサーバーを回復力を持たせるように、ある領域内の複数のデータセンターにわたって分散させることができる。

この実施形態における制御プレーンは、本明細書中において「スウィーパー」と呼ばれるコンポーネント２１４を含む。スウィーパーコンポーネントは、任意の適切なコンポーネントとすることができ、制御プレーンの多様なコンポーネントに対するポーリングを行うか、または、別法により未処理の要求に応答して実行されるべき任意のタスクを決定するように動作可能である。本例において、ウェブサービス層は、管理データ記憶部２２２内における「データベース生成」要求についての命令もしくは情報、または類似のジョブキューを発行してもよく、スウィーパーは、未処理のジョブが無いかどうかについて管理データ記憶部を定期的に確認することができる。当業者にとって明らかであるものとして、多様な他のアプローチを用いることができる（例えば、ウェブサービス層が、スウィーパーに対し、ジョブが存在する旨の通知を送るなど）。スウィーパーコンポーネントは、「データベース生成」要求をピックアップすることができ、要求についての情報を用いて、要求、呼び出しまたは他のこのようなコマンドをワークフローコンポーネント２１６へと送ることができる。ワークフローコンポーネント２１６は、要求に対応する少なくとも１つのワークフローを開始するように動作可能である。一実施形態において、ワークフローは、本明細書中の他の箇所に記載されるワークフローサービスを用いて生成および維持される。ワークフローは一般的には一連のタスクであり、特定のジョブを行うために実行されるべきである。ワークフローは実際の作業ではないが、作業を抽象化したものであり、当該作業の情報のフローおよび実行を制御する。また、ワークフローは状態機械としてみなすこともでき、実行中の任意のタイミングにおけるプロセスの状態を管理および返送することができる。一実施形態において、ワークフローコンポーネント（またはシステムコンポーネント）は、タスク（例えば、レポジトリの生成、改変、および削除、回復、およびバックアップ、セキュリティグループの生成、削除、および改変、ユーザ認証情報の管理、キーローテーション、および認証情報管理）についてのワークフローのホスティングおよび実行を管理および／または実施するように、動作可能である。このようなワークフローは、本明細書中の他の箇所に記載されるようなワークフローサービスの上部において実行することが可能である。ワークフローコンポーネントはまた、異なるデータベースエンジン（例えば、ＭｙＳＱＬ）のために用いられるワークフローステップ間の差を管理することもできる。なぜならば、基本的ワークフローサービスは必ずしも変化しないからである。

本例において、ワークフローは、データベースを生成するためのワークフローテンプレートを用い、元々の要求から抽出された情報を適用して開始することができる。例えば、当該要求がＭｙＳＱＬ（登録商標）関係データベース管理システム（ＲＤＢＭＳ）インスタンスに関するものである場合、Ｏｒａｃｌｅ（登録商標）ＲＤＢＭＳまたは他のこのようなインスタンスとは対照的に、ＭｙＳＱＬインスタンスに向けられたワークフローに特定のタスクが付加される。ワークフローコンポーネントはまた、要求された記憶量、任意の特定のハードウェア要件または他のこのようなタスクに関連する特定のタスクも選択することができる。これらのタスクは、ジョブ全体にとって有用な実行順序でワークフローへ付加することができる。いくつかのタスクを並行して行うこともできる一方で、最初に行われるべき以前のタスクに他のタスクが依存する場合もある。ワークフローコンポーネントまたはサービスは、ワークフロー内のこの情報を含むことができ、タスクを実行し、必要に応じて情報を送ることができる。

顧客のための例示的「データベース生成」ワークフローは、タスク（例えば、データ記憶インスタンスのプロビジョニング、オフインスタンスの永続的記憶のボリュームの割り当て、永続的記憶ボリュームのデータ記憶インスタンスへの割り当て）を含んでもよく、その後、データインスタンスへアクセスする、または別法で接続する際に顧客が利用することが可能な、ＤＮＳアドレスもしくは他のアドレス、ポート、インターフェース、または識別子を割り当てることおよび取り付けることを含んでもよい。本例において、インスタンスへのアクセスの際に用いられるＤＮＳアドレスおよびポートアドレスがユーザに提供される。ワークフローは、特定のデータ記憶技術に用いられる任意の２進数または他の情報（例えば、ＭｙＳＱＬ）をダウンロードおよびインストールするタスクも含むことができる。ワークフローコンポーネントは、これらのタスクおよび任意の関連タスクまたはこのようなタスクの他の任意の適切な組み合わせの実行を管理することができ、データプレーン２１０内のデータ記憶インスタンスに実際に対応する「データベースの生成」に応答して、「データベース」の生成を示す要求に応答を生成することができ、インスタンスへのアクセスの際に用いられるＤＮＳアドレスを提供する。その後、ユーザは、制御プレーン２０８にアクセスするかまたは制御プレーン２０８を経由する必要無く、ＤＮＳアドレスおよびポートを用いてデータ記憶インスタンスに直接アクセスすることができる。同様のジョブ（例えば、記憶量増加のための、１つ以上のデータ記憶インスタンスの削除、生成または改変）を行うために、多様な他のワークフローテンプレートが利用可能である。いくつかの実施形態において、ワークフロー情報は記憶部へと書き込まれ、少なくとも１つの別個の実行コンポーネント（図示せず）が、ワークフロー情報に基づいて実行されるべきタスクを牽引するか、または別法でアクセスもしくは受信する。例えば、プロビジョニングタスクを実行する専用プロビジョニングコンポーネントがあってもよく、このコンポーネントはワークフローコンポーネントによって呼び出されることはないかもしれないが、明らかとなるであろう複数の関連する様態のうちの任意の様態でタスクキューを監視するかまたはプロビジョニングタスクに関する情報を受信することができる。

上記したように、多様な実施形態は、プロセスまたはタスク（例えば、レポジトリのプロビジョニング）の現在の状態について要求または呼び出しを受信することができ、プロセスの現在の状態を返送することができる、ワークフローサービスの有利点を利用することができる。ワークフローコンポーネントおよび／またはワークフローサービスは、各タスクを行うための実際の呼び出しまたは要求は行わないが、しかしその代わりに、次に行われるべきタスクと、当該タスクに必要な任意の情報とを決定することができる、当該ワークフローについての状態情報および構成情報を管理する。その後、ワークフローコンポーネントおよび／またはワークフローサービスは、当該状態情報を含む適切な呼び出し（単数または複数）をデータプレーン内に生成し、これにより、データプレーンのコンポーネントは当該タスクを行うための呼び出しを行うことが可能になる。ワークフローおよびタスクは、スループットの増加および処理リソースの最大化のために、並行にスケジューリングすることが可能である。上述したように、実際のタスクの実施はデータプレーン内において行われるが、タスクは制御プレーンから発生するであろう。例えば、ワークフローコンポーネントは、データ記憶部内へ呼び出しを行うことができるホストマネージャと通信することができる。そのため、所与のタスクについて、特定のパラメータを送るワークフローサービスに対して呼び出しを行うことができ、これにより、ワークフローサービスは、現在の状態のためのタスクを実行することができるように、当該ワークフローのための一連のタスクを生成し、かつ現在の状態を提供する。タスクが実行された（または別法で解決されたまたは結論が出た）後、コンポーネント（例えば、ホストマネージャ）は、サービスに対して返答を出すことができ、その結果、ワークフローにおける次の状態に関する情報（例えば、次のタスクが実行可能）を提供することができる。ワークフローが完了するまで、ワークフローのためのタスクのうちの１つが行われるたびに、サービスは実行されるべき新規タスクを提供することができる。さらに、ワークフローの処理を加速させるために、異なるワークフローについて複数のスレッドを並行して実行することができる。

この実施形態において、制御プレーン２０８は、少なくとも１つの監視コンポーネント２１８も含む。データプレーン内においてデータインスタンスが生成されると、インスタンスに関する情報を制御プレーン内のデータ記憶部（例えば、監視データ記憶部２２０）内に書き込むことができる。監視データ記憶部は別個のデータ記憶部であってもよいし、あるいは別のデータ記憶部の一部であってもよい（例えば、管理データ記憶部２２２内の別個の１組の表、または他の適切なレポジトリ）ことが理解されるべきである。監視コンポーネントは、監視データ記憶部内の情報にアクセスして、データプレーン２１０内のアクティブインスタンス２３４を決定することができる。監視コンポーネントは、他のタスクを行うこともできる（例えば、制御プレーンおよび／またはデータプレーンの複数のコンポーネント（例えば、ウェブサービス層、ワークフローコンポーネント、スウィーパーコンポーネント、および多様なホストマネージャ）からのログおよび／またはイベント情報の収集）。このようなイベント情報を用いて、監視コンポーネントは、顧客向きのＡＰＩの実行などの目的のために、顧客が視認可能なイベントを露出することができる。監視コンポーネントは、制御プレーンのために実行中の全てのレポジトリおよび／またはインスタンスの健康状態を常に監視し、これらのインスタンスのうちの任意のものの不具合を検出し、適切な回復プロセス（単数または複数）を開始することができる。

データプレーン内の各インスタンス２３４は、少なくとも１つのデータ記憶部２２６と、データ記憶部へのアクセスを提供するマシンのためのホストマネージャコンポーネン２２８とを含むことができる。一実施形態において、ホストマネージャはアプリケーションまたはソフトウェアエージェントであり、タスク（例えば、ソフトウェア展開動作およびデータ記憶動作、ならびにデータ記憶部および／または各インスタンスの状態の監視）を管理するようにプログラムされたインスタンスおよび／またはアプリケーションサーバー（例えば、ＴｏｍｃａｔまたはＪａｖａアプリケーションサーバー）上において実行する。一実施形態において、ホストマネージャは、内部システムコンポーネントからしか到達することができずかつ顧客または他の外部エンティティからは利用できないポートをリッスンする。いくつかの実施形態において、ホストマネージャは、制御プレーン層内へのいかなる呼び出しも開始することができない。ホストマネージャは、タスク（例えば、新規レポジトリのためのインスタンスの設定（論理ボリュームおよびファイルシステムの設定を含む）、データベース２進数およびシードのインストール、レポジトリの開始または停止）の管理および／または実行を担当することができる。ホストマネージャは、データ記憶部の健康状態を監視することができ、それだけでなく、データ記憶部をエラー状態（例えば、Ｉ／Ｏエラーまたはデータ記憶エラー）について監視し、必要に応じてデータ記憶部を再開することができる。また、ホストマネージャは、ソフトウェアパッチのインストールを実行および／または管理し、データ記憶部および／またはオペレーティングシステムをアップグレードする。ホストマネージャは、関連メトリック（例えば、ＣＰＵ、メモリおよびＩ／Ｏ使用法に関連する場合があるもの）を収集することもできる。

監視コンポーネントは、監視されているインスタンス２３４について、（例えば特定の要求の送信またはホストマネージャからの心拍の監視により）各ホストマネージャ２２８と定期的に通信することができ、これにより、各ホストの状態を決定することができる。一実施形態において、監視コンポーネントは、１組のイベントプロセッサ（または監視用サーバー）を含む。１組のイベントプロセッサ（または監視用サーバー）は、各ホストマネージャへコマンド（例えば、特定のホストおよび／またはインスタンスの状態を入手せよとのコマンド）を発行するように構成される。指定された数のリトライの後に応答が無い場合、監視コンポーネントは、問題があると判断することができ、当該インスタンスのためのアクション（例えば、問題の確認および必要ならばインスタンスの再プロビジョニング）を行うための情報を管理データ記憶部２２２または別のこのようなジョブキュー内に保存することができる。スウィーパーは、この情報にアクセスすることができ、不具合からの自動回復を試行するために、インスタンスのための回復ワークフローをキックオフすることができる。ホストマネージャ２２８は、制御プレーンの監視コンポーネントおよび他のコンポーネントのプロキシとして機能することができ、制御プレーンコンポーネントを代表してインスタンスのタスクを行う。場合によっては、インスタンスのうちの１つにおいて、自動解決できない問題が発生する（例えば、対応するホスト、インスタンスまたはボリュームの破壊、リブート、再開など）が発生するであろう。一実施形態において、これらのおよび他の顧客可視性イベントにログすることができる、ロギングコンポーネント（図示せず）がある。ロギングコンポーネントは、ＡＰＩまたは他のこのようなインターフェースを含むことができ、これにより、あるインスタンスが一定期間にわたって利用不可能となっている場合、顧客が適切な「イベント」または類似のＡＰＩを呼び出して、当該イベントに関する情報を入手することが可能となる。場合によっては、インスタンスに不具合が発生する場合、要求がペンディングのまま放置される場合がある。この実施形態における制御プレーンはデータプレーンから分離されているため、制御プレーンがデータ要求を受信することは絶対に無い。そのため、制御プレーンは、要求を後で提出できるように待ち行列に入れることはできない（ただし、いくつかの実施形態において、この情報は制御プレーンへ転送される可能性がある）。よって、この実施形態における制御プレーンは、不具合に関する情報をユーザへと提供し、これにより、ユーザは、要求を必要に応じて取り扱うことができる。

上述したように、インスタンスがプロビジョンされ、ＤＮＳアドレスまたは他のアドレスまたは場所がユーザに提供されると、ユーザは、ネットワークを通してＪａｖａデータベース接続（ＪＤＢＣ）または他のこのようなクライアントを用いてデータプレーン２１０へ要求を「直接的に」送ることができ、これによりそのインスタンス２３４と直接相互作用することができる。一実施形態において、データプレーンは、コンピューティングクラウド環境、またはハードウェアコンポーネントおよび／またはソフトウェアコンポーネントの「クラウド」または動的ネットワークにわたるデータ記憶およびアクセスを提供する１組のウェブサービスおよびリソースの形態をとる（または少なくともこれらを含む、もしくはこれらはその一部である）。ＤＮＳアドレスは、このような動的クラウド環境において有用である。なぜならば、使用のために、任意の適切な交換用インスタンスに対するＤＮＳアドレスをプログラムでリマップすることにより、例えばインスタンスまたは利用可能性における不具合をマスクすることが可能であるからである。ユーザ２０２またはアプリケーション２０４から受信された要求は、例えば、ネットワークアドレス変換（ＮＡＴ）ルータ２２４または他の適切なコンポーネントへと送ることができる。ネットワークアドレス変換（ＮＡＴ）ルータ２２４または他の適切なコンポーネントは、要求を実際のインスタンス２３４または要求のＤＮＳに対応するホストへと送ることができる。上述したように、このようなアプローチにより、ユーザまたはアプリケーションがインスタンスへのアクセスに用いられるＤＮＳまたは他のアドレスを変更する必要無しに、インスタンスを例えば動的に移動、更新、複製すること等が可能になる。上述したように、各インスタンス２３４はホストマネージャ２２８およびデータ記憶部２２６を含むことができ、少なくとも１つのバックアップインスタンスまたはコピーを永続的記憶部２３０内に有することができる。このようなアプローチを用いて、インスタンスが制御プレーンを通して構成された後、制御プレーン２３２へアクセスする必要無しに、ユーザ、アプリケーション、サービスまたはコンポーネントが（データプレーンに対する要求を通して）インスタンスと直接相互作用することが可能になる。例えば、ユーザは、インスタンス中のデータに関連する構造化照会言語（ＳＱＬ）または他のこのようなコマンドを、ＤＮＳアドレスを通して直接発行することができる。ユーザは、タスク（例えば、インスタンスの記憶容量の拡張）を行いたいとき、制御プレーンにアクセスするだけでよい。少なくとも１つの実施形態において、制御プレーン２０８の機能性は、プロバイダにより、少なくとも１つのサービスとして提供することができる。少なくとも１つのサービスは、データプレーン２１０のプロバイダに関連する場合もしない場合もあるが、単にデータプレーン内のデータインスタンスのプロビジョンおよび管理に利用可能な第３者サービスである場合もあり、別個のデータプレーン２１０内におけるこれらのインスタンスの利用可能性を監視および保証することもできる。

上述したように、制御プレーンの機能性をウェブサービスまたは他のこのようなサービスとして提供することの１つの利点は、制御プレーンが仮想データベース管理者（ＤＢＡ）として機能し、タスク（例えば、データのプロビジョニング）を行うための人間ＤＢＡの必要性を回避する点である。データのプロビジョニングは現在、必要な構成情報の受信、構成が有効であるか否かの判定、インスタンスの最適化およびチューニング、ならびに他のこのようなタスクの実行のためにＤＢＡを必要とする、面倒な手作業の手順であり、大量の時間および労力を使う。さらに、このようなアプローチは、データ損失後にしか発見されないかもしれないエラーの発生の可能性が高い。本明細書中に記載のような制御プレーンまたはサービスを用いれば、ユーザまたは顧客は、その代わりに、情報（例えば、ハードウェアの種類およびデータベース製品のバージョン）を含む呼び出しを提出することができる。その後、制御プレーンまたはサービスは、データ記憶部またはデータ記憶インスタンスを生成、削除、改変、拡張、または別法により改変するための必要なタスクを行うことができる。制御プレーンはまた、ＤＢＡが各エンジンにおける専門家として機能することを必要とすること無しに、いくつかの異なるデータベースエンジンを一貫した様式でサポートすることもできる。プロビジョンされると、ユーザは、データインスタンス（単数または複数）へのネーティブアクセスを有し、特定のインスタンスについて、単に既存のアプリケーション（例えば、ＭｙＳＱＬアプリケーション）をＤＮＳアドレスまたは他の場所情報に指定することができる。クエリーモデルまたは他のこのような機能性の制限または改変は無い。なぜならば、ユーザは、ＭｙＳＱＬ、Ｏｒａｃｌｅまたは他のデータベース技術上に構築されたアプリケーションを継続して利用することができるからである。

データ記憶部、データ記憶インスタンス、または顧客のための他のデータリソースをプロビジョニングする場合、少なくともいくつかの実施形態における制御プレーンコンポーネントは、データインスタンスの設定に用いられる初期の構成パラメータの組を提供する。このようなデフォルトパラメータグループのパラメータとしては、例えば、バッファキャッシュの割り当て設定、クエリータイムアウト設定、接続タイムアウト設定、および／または他のこのような動作パラメータまたは構成パラメータを挙げることができる。いくつかの実施形態において、制御プレーンの管理コンポーネントは、データベース設定に用いるための最適なまたは少なくともデフォルトのパラメータ値の組を選択または決定する。選択されたパラメータは、複数の要素（例えば、ユーザ、データベースの種類、用いられるアプリケーションの種類、または必要なアクセス等）のうちのいずれかに依存することができる。

クラウドコンピューティングまたは類似のスケーラブルなリソース環境においては、デフォルトまたは初期の構成パラメータの組を多様な実施形態において提供することが特に重要である可能性がある。なぜならば、顧客は、データインスタンスの開始、記憶のスケーリング、および／またはリソースの処理等を含む、データベースをオンデマンドでを操作する能力を有することができるからである。顧客は、例えば、１つ以上のデータインスタンスを指定されたインスタンスクラス記憶空間内に生成し、当該インスタンスがもはや不要となった場合、これらのインスタンスを削除することができる。このような実施形態において、システムは、デフォルト構成パラメータの組をインスタンスクラスについて生成することができ、これにより、当該クラス内に生成された任意のインスタンスは、それらに適用されるデフォルトパラメータグループを有することになる。

多くの場合、生成されたデフォルトパラメータは、多様なインスタンスに対して最適化されるか、または少なくとも適切または受容可能となる。しかしながら、特定の利用形態があってもよく、性能、利用可能性または他のこのような態様を向上または別法により調節するために、顧客がパラメータのうちの１つ以上を調節したいと望む場合がある。例えば、特定のアプリケーションはキャッシュ使用頻度が極めて高い場合があり、顧客が１つ以上のデータベースに対するキャッシュ割り当てを増加することを望む場合がある。顧客は、パラメータの調節を、インスタンス生成の前、または既存インスタンスが実行されている間に行うことを望む場合がある。いくつかの場合において、本明細書中の他の箇所に詳細に記載されるように、データインスタンスが再開またはリブートした場合にのみパラメータは変更することができる。

多様な実施形態によるシステムおよび方法は、１つ以上の顧客露出型インターフェースを提供することにより、これらのおよび他のかかる問題のうちの少なくとも一部を解消する。顧客露出型インターフェースは、データインスタンス、データ記憶部などのためにパラメータを調節、更新、または別法によりカスタマイズするために、顧客が制御プレーンに呼び出しを行うことを可能にする。ＭｙＳＱＬがデータベースエンジンとして用いられる一実施形態において、例えば、ユーザは、調節されたパラメータ（単数または複数）を含む更新されたパラメータグループまたは改変されたパラメータグループを提出することにより、ＭｙＳＱＬ構成パラメータを調節する能力を持つことができる。複数のデータベースエンジンが用いられる実施形態において、ユーザは、エンジン特有の呼び出しおよび／または更新を行うことができ、または、インスタンスに対応する特定のエンジンに対して制御プレーンにより変換または別法により処理することができる、一般的更新または呼び出しを行うことができる。このようなアプローチを用いて、ユーザは、顧客作業負荷、アプリケーションの種類などに応じて、データインスタンスのパラメータまたはデータインスタンスのグループをカスタマイズまたはチューニングすることができる。デフォルトパラメータグループがインスタンスのグループまたはクラスに適用される場合、例えば、ユーザは、各対応するインスタンスに自動適用することができる更新済みパラメータグループを提出することができる。最大負荷期間の間、例えば、顧客は、バッファキャッシュ設定、クエリータイムアウト設定、または接続タイムアウト設定を調節したいと望む場合がある。多様な実施形態において、顧客は、新規パラメータ値（単数または複数）、新規値（単数または複数）等を含む値の全ての組を指定することができる。多様な他のパラメータも同様にカスタマイズ可能であり、カスタマイズされた値は必要に応じて経時的に更新することが可能である。

多様な実施形態は、ユーザが、多様なＲＤＳデータベースのデータベースパラメータを構成することができる、１つ以上のこのようなインターフェースを提供する（例えば、１組のアプリケーションプログラミングインターフェース（ＡＰＩ））。一実施形態において、「エンジンにとらわれない」（すなわち、任意のサポートされたデータベースエンジンに対して利用可能）、１組の適切な抽象化を利用している、１つ以上の構成ＡＰＩが提供される。例えば、顧客は、同一ＡＰＩを用いて、ＭｙＳＱＬデータベースおよびＯｒａｃｌｅデータベースに関する接続タイムアウト設定を調節することができる。多様な実施形態において、ユーザは、ＡＰＩのうちの１つに対してウェブサービス呼び出しを送ることができ、呼び出し中の情報は、例えば、制御プレーンウェブインターフェース層に対するウェブサービス呼び出しを処理するための上述したアプローチと同様のアプローチを用いて処理される。

上述したように、制御プレーン内のワークフローは、データセット生成要求に応答してインスタンス化することが可能であり、インスタンス記憶空間がデータプレーン内に設立され、適切なパッケージマネージャ（例えば、ＲＰＭ）またはホストマネージャが適用される。生成時の間、ワークフローは、制御プレーン内のまたは制御プレーンからアクセス可能な構成ファイル、管理データ記憶部または他の適切な記憶場所からの情報を用いてデフォルト構成設定を牽引および／または生成するタスクを行うことができ、これらの設定を用いて、データ環境内の各インスタンスに適用することが可能なデフォルトパラメータグループを生成することができる。いくつかの実施形態において、パラメータは、ウェブサービス呼び出しからの情報、ユーザについて保存された情報、生成されているインスタンスの種類についての情報などを用いて、動的に生成または決定される。他の実施形態において、高度にチューニングされた１組以上のデータベース設定を制御プレーン内の適切な場所に保存することができ、ワークフローは、現在のタスクに対して適用される適切な組のうちの選択されたものへと方向付けることができる。いくつかの実施形態において、データベースを開始するためにデータベースエンジンによって用いられる、構成ファイルが、データプレーン内に保存される。上述したように、構成ファイルは、パラメータ（例えば、クエリー結果のために割り当てられるキャッシュ量、割り当てられるバッファキャッシュ量、用いられる接続タイムアウト値など）を含んでもよい。しかしながら、上述したように、これらのパラメータは、任意の所与の時点において顧客にとって最適ではないかまたは少なくとも好適ではない場合がある。クラウドコンピューティングまたは従来のＲＤＳシステムにおいて、構成ファイルを編集する能力およびデータベースを再開する能力は、一般的にユーザに対しては、アクセス可能ではない。ユーザは、単にデータプレーン内のデータインスタンスにログオンするため、およびその態様を改変するために、制御プレーンのインターフェースを利用することはできない。

多様な実施形態によるシステムおよび方法により、ユーザが任意の数の呼び出しを制御プレーンに対して行って、任意の適切なデータパラメータ（単数または複数）の改変をウェブサービスＡＰＩまたは他のこのようなインターフェースを介して行うことが可能になる、ＡＰＩベースの内部フレームワーク（または他のインターフェースフレームワーク）が提供される。例えば、ユーザは、ウェブサービス呼び出し（例えば、「ＭｏｄｉｆｙＭｙＤＢＰａｒａｍｓ」）を適切なＡＰＩに対して行って、各インスタンス（単数または複数）のための改変可能な構成パラメータのうちの任意のものを改変することができる。一実施形態において、顧客は、特定の顧客、グループ、クラス、アプリケーションなどに関するデータインスタンスを生成する際に用いられるべき特定のパラメータ値またはパラメータグループを保存するためのものである、コンテナ（本明細書中、「ＤＢパラメータグループ」と呼ぶ）を生成することができる。顧客は、データベースインスタンスの生成時に用いられる、これらのパラメータグループのうちの１つ以上を（例えば、データベースエンジンについて用いられるべきいくつかのまたは全てのパラメータ、または、指定された値がＲＤＳによって割り当てられたデフォルト値（例えば、ｄｅｆａｕｌｔ．ｍｙｓｑｌ）の代わりに用いられるべき、少なくともそれらのパラメータを含んでもよいもの）、選択または指定することができる。上述したように、ＲＤＳによって提供されるデフォルト値は、顧客、アプリケーション、エンジンなどにとって最適かつ／または適切なデフォルト設定として、ＲＤＳシステムまたはその許可されたユーザによって決定することができる。しかし、顧客に対して構成ファイルまたはバケットが存在する場合、ＲＤＳは、当該顧客に対するインスタンスを生成する際、当該構成ファイルからの値を代替的に（または追加的に）用いるように構成することができる。

顧客は、データベースインスタンスの生成において用いられるべき構成パラメータを指定できるだけでなく、既存のインスタンスのためのパラメータを調節する能力も望んでもよい。例えば、顧客は、要素（例えば、作業負荷または性能）に基づいて、より大量のメモリを各クエリーキャッシュに割り当てることが有利であるように、アプリケーションを高度にキャッシュ可能である場合があると判断してもよい。クエリーキャッシュサイズを増やすために、ユーザは、呼び出し（例えば、「ＭｏｄｉｆｙＤＢＰａｒａｍｅｔｅｒＧｒｏｕｐ」）を発行することができる。この呼び出しは、制御プレーンのウェブサービス層の適切なＡＰＩによって受信される可能性があり、ウェブサービス層は、呼び出しを処理して、適切なタスク情報を管理データ記憶部または別の適切なジョブキュー内に配置することができる。スウィーパーコンポーネントは、タスクをジョブキュー内に配置するときに、実行されるべき適切なタスク（例えば、要求、呼び出しまたは他のこのようなコマンドを、当該要求のために少なくとも１つのワークフローをインスタンス化するように動作することが可能なワークフローコンポーネントへと送信するタスク）を決定することができる。その後、ワークフローマネージャは、適切なコンポーネント（例えば、データプレーン内のデータインスタンスのホストマネージャ）と共に機能して、パラメータグループ（単数または複数）内の値を更新し、更新または改変されたパラメータグループ（単数または複数）を対応するインスタンス（単数または複数）に適用することができる。いくつかの実施形態において、顧客は、複数のパラメータグループ（例えば、「ピーク」設定および「オフピーク」設定を含んでもよいなどの）を指定することができ、ユーザは、パラメータグループのうちの１つを特定の時期に適用させるための呼び出しを行うことにより、設定を変更することができる。他の実施形態において、顧客は、特定の期間にわたって変更を行う場合があるが、後で元々の設定またはデフォルト設定に戻ることを望む場合がある。多様な実施形態は、パラメータグループと関連付けられたパラメータのうちの１つ以上をＲＤＳデフォルト（または他のデフォルト値）へと調節して戻すことができる呼び出し（例えば、「ＲｅｓｅｔＤＢＰａｒａｍａｔｅｒＧｒｏｕｐ」）を、ＡＰＩに提供する。このようなリセット値は、例えばデータベースインスタンスの性能が低下しており、インスタンスを適切な性能レベルに戻そうと試みることを顧客が望む場合にも利用することが可能である。

顧客が要求（例えば、ＭｏｄｉｆｙＭｙＤＢＰａｒａｍｓ呼び出しまたはＭｏｄｉｆｙＤＢパラメータＧｒｏｕｐ呼び出し）を適切なＡＰＩへと提出すると、改変されたパラメータグループを、制御プレーン内の新規のバージョン番号に割り当てることができる。ワークフローは、この新規バージョンを、この新規バージョンが適用されるべき適切なインスタンス（単数または複数）のホストマネージャへと送らせるようにすることができる。新規バージョンがホストマネージャへと送られると、例えば、新規バージョン番号を状態値（例えば、「Ｕｐｄａｔｉｎｇ」または「Ｎｏｔ＿ＩｎＳｙｎｃ」）と共に管理データ記憶部内に保存することができ、これにより、更新されたパラメータグループを有するインスタンスの状態をクエリーしているユーザは、情報（例えば、現在のバージョン番号、適用されている新規バージョン番号、および新規バージョンが適用されていることを示す情報）を含むことができる応答を受信することができる。インスタンスのホストマネージャが新規パラメータグループを順調に適用した場合、ホストマネージャは、データ環境内の現在のバージョン情報を更新することができる。ホストマネージャの状態を定期的に確認している監視コンポーネントは、新規バージョン番号をピックアップし、管理データ記憶部内に保存されている情報を更新して、パラメータグループの新規バージョンが今や現在のバージョンとなっていることを示すことができ、状態を、「ＩＮ＿ＳＹＮＣ」などのような状態に更新することができる。その後、状態をクエリーしている顧客は、新規バージョンが適用されておりアクティブになっていると判断することができる。いくつかの実施形態において、新規パラメータグループが連続的に適用されている場合、通知を制御プレーンを介して顧客に送ることができる。

顧客がパラメータグループ、バケット、構成ファイルまたは他のこのような要素を利用することによる利点は、顧客が各インスタンスを別個にチューニングする必要が無くなることである。顧客がパラメータグループまたは変更をフリート、クラスなどの全体に単純に適用することができ、かつ全ての適切なインスタンスが、更新されたパラメータ値を自動的に受信することができるように、抽象化レベルを提供することができる。このようなプロセスは、例えば、複数のデータベースが１つのアプリケーションを実行するために用いられ、かつ当該アプリケーションに対してこれらのデータベース全てを同時にかつ同じ様態でチューニングすることが望ましい場合、有利となる可能性がある。いくつかの場合において、異なる種類のデータベースをアプリケーションに用いることができ、これにより、抽象化レベルをさらに有利にすることができる。なぜならば、制御プレーンによってエンジン間の差を自動的に取り扱うことができるため、アプリケーションに用いられる各データベースエンジンを顧客が別個にチューニングする必要が無くなるからである。さらに、制御プレーンはエンジン依存型変換を取り扱うことができるため、エンジンに依存しない単一の組のツールを利用することができる。

上述したようなコンポーネントを用いて、図３は、一実施形態による例示的プロセス３００を示す。プロセス３００により、顧客は、制御プレーンまたは類似のデータ制御サービスを用いて、データベース、データインスタンス、データレポジトリまたはデータ環境（ここでは、データプレーン）内の他のこのようなデータソースの生成において用いられるべきパラメータ値の指定および／または改変を要求することができる。本明細書中、「顧客」という用語は、データの「所有者」あるいはＲＤＳシステムによってホストされるデータ記憶部またはインスタンスを指すものとして用いられるが、「顧客」という用語は一例にすぎず、任意の適切なユーザまたは開発者が多様な実施形態において制御プレーンおよびデータプレーンにアクセスすることが可能であることが理解されるべきである。さらに、データ環境の制御に関連する実施形態について説明するが、類似のアプローチを、制御環境と分離された環境内の多様な他のコンポーネント、デバイス、アプリケーション、サービスまたは他のこのようなリソースの制御および／または管理に用いることが可能であることが理解されるべきである。

例示的プロセスにおいて、データプレーン内においてデータインスタンスを生成する能力が顧客に付与される（３０２）。これは、顧客と連動してまたは顧客から独立して（例えば、顧客からの要求に応答して）行うことができる。初期顧客構成プロセスの一部として、デフォルトパラメータ値のリストを含む、パラメータグループまたは「仮想コンテナ」が顧客のために生成される（３０４）。コンテナは、後のアクセスのために制御プレーンデータ記憶部内に保存され、特定の顧客、顧客グループ、顧客種類などに（例えば、データ記録またはキーなどによって）結び付けられる。デフォルト値は、使用種類、データベースエンジン、アプリケーションなどに適したものとして、ＲＤＳコンポーネントによって選択される。

顧客は、デフォルトパラメータ値設定を決定するために、制御プレーンを呼び出すことができる。顧客は、その顧客のために生成された任意のデータインスタンスのために、値のうちの少なくとも１つを変更すべきであると決定してもよい。そのため、要求（例えば、ウェブサービス呼び出し）を、複数の制御プレーンＡＰＩまたは他のこのような顧客向きプレーンインターフェースコンポーネントのうちの１つを通して顧客から受信することができる（３０６）。一実施形態において、顧客は、「ＭｏｄｉｆｙＤＢＰａｒａｍｅｔｅｒＧｒｏｕｐ」ＡＰＩを呼び出して、値（単数または複数）の変更を示すことができる。要求は分析され、要求の処理に必要な何らかのアクションが決定される（３０８）。上述したように、これは、ウェブサービス層のコンポーネントの形態をとることができ、要求を解析して、必要とされるアクション（単数または複数）を決定する。要求を受信するＡＰＩが行われるべき特定のアクションに対応する実施形態において、ウェブサービス層は、行われるべきアクションの態様またはパラメータの決定に用いられるべき情報を要求から抽出することができる。一実施形態において、制御プレーンデータ記憶部内のパラメータ情報は直接更新可能であり、一方で、他の実施形態において、制御プレーンデータ記憶部（または例えば構成ファイル）に対して更新されるべき情報が、ジョブキュー（例えば、管理データ記憶部または他のこのような記憶場所内にある場合があるもの）に書き込まれる（３１０）。ジョブキューは、ジョブ情報の存在を決定するために例えばスウィーパーコンポーネントなどのようなものによって監視することができ、ジョブ情報が検出されると（３１２）、要求されたアクションのためにワークフローを開始するための要求を送ることができる（３１４）。これは、スウィーパーコンポーネントによってワークフローコンポーネントへと送られた要求および／またはワークフローをインスタンス化するためのサービスを含むことができる。他の実施形態において、ワークフローコンポーネントは、ジョブについてジョブキューを監視してもよく、あるいは、ウェブサービス層のコンポーネントはジョブ情報を直接ワークフローコンポーネントへと送ってもよい。ジョブ情報が受信されると、情報は解析されて、要求されたアクションに適したワークフローが決定および／または組み立てられる（３１６）。本例において、ワークフローは、単一のタスク（例えば、制御プレーンデータ記憶部内のユーザに対する保存されたパラメータ値情報の更新）を含んでもよい。他の実施形態において、ワークフローは、さらなるタスクおよび／または代替のタスク（例えば、構成ファイルが適用されるデータプレーン内で生成されたデータインスタンスについて最終的にインストールされる構成ファイルの生成）を含んでもよい。他の実施形態において、類似の機能性を実行するために、多様な他のタスクを含み、かつ実行することが可能である。

図４は、一実施形態による、更新された（または他の）構成情報を用いてデータインスタンスをデータプレーン内に生成する例示的プロセス４００のステップを示す。本例において、要求（例えば、ウェブサービス呼び出し）は、複数の制御プレーンＡＰＩまたは他のこのような顧客向き制御プレーンインターフェースコンポーネントのうちの１つを通して受信することができ、これによりデータインスタンスが生成される（４０２）。一実施形態において、顧客またはアプリケーションは、「ＣｒｅａｔｅＤＢＩｎｓｔａｎｃｅ」ＡＰＩを呼び出して、生成されるべきインスタンス（単数または複数）を示すことができる。要求は分析され、これにより、要求の処理に必要な任意のアクションが決定され（４０４）、生成のための情報がジョブキューに書き込まれる（４０６）。ジョブキューを監視しているスウィーパーコンポーネントは、ジョブ情報の存在を決定して（４０８）、要求されたアクション（単数または複数）のためのワークフローを開始するための要求を送ることができる（４１０）。ジョブ情報が分析されて、要求されたアクションのための適切なワークフローが決定および／または組み立てられる（４１２）。このワークフローは、タスク（例えば、ＲＤＳデータベースインスタンスをプロビジョンするタスク、任意の必要な記憶ボリュームを生成するタスク、データベースをインストールするタスク、インスタンスについてホストマネージャと接触して、インスタンスのために用いられるべき設定パラメータグループを特定するタスク、構成情報をデータプレーン内のディスク上に保存するタスクなど）を含むことができる。上述したように、要素（例えば、要求されるアクションの種類、要求のパラメータ、および使用されているデータベースエンジンの種類）に基づいて、ワークフローについて異なるタスクを選択することが可能である。本例において、制御プレーンは、ワークフローを介して、構成ファイルの生成（４１４）、データプレーン内のインスタンスのための構成ファイルのインストール（４１６）、およびインストールされた構成ファイルからのパラメータ値を用いたデータベースインスタンスの開始（４１８）においてパラメータリストが用いられるように方向付けることができる。

上述したように、状態情報を、行われるべきタスクを状態情報を用いて決定し、データレポジトリおよび／またはデータインスタンスについてタスクを行い、タスクの完了時に応答を返すように動作可能であるデータ環境内のホストマネージャへと送ることにより、ワークフローの第１のタスクから開始するタスクを部分的に管理することができる。応答が受信されると、ワークフローコンポーネントは、行われるべき別のタスクがあるかどうかを決定することができる。行われるべき別のタスクがある場合、次のタスクに関する状態情報がホストマネージャへと送られ、そのタスクの完了時に、ホストマネージャは、応答をワークフローコンポーネントに送る。最終タスクが完了した後、要求されたアクションが完了した旨を示すメッセージを要求元の顧客（または別の適切なユーザ、アプリケーションまたは場所）へと送ることができる。アクションが実行された後、顧客は、制御プレーンへのアクセスまたは制御プレーンの経由無しで、データ環境のデータインターフェースを用いてアクションが行われたデータインスタンスに直接アクセスすることができる。

しかし、１つ以上のインスタンスがアップされ実行されている場合でも、顧客は、構成パラメータのうちの１つ以上を調節することを望む場合がある。例えば、顧客は、現在の作業負荷レベルに基づいてクエリータイムアウト設定を調節することを望む場合がある。図５は、多様な実施形態に従って利用することが可能なインスタンスの実行のためのパラメータを更新するためのプロセス５００の一例を示す。本例において、データベースパラメータの値の変更（例えば、クエリータイムアウトの１０秒から１５秒への変更）を示す要求を制御プレーンＡＰＩ（例えば、「ＭｏｄｉｆｙＤＢＰａｒａｍｅｔｅｒＧｒｏｕｐ」ＡＰＩ）を通して受信することができる（５０２）。要求は解析されて、要求の処理に必要な任意のアクションが決定され（５０４）、その生成のための情報がジョブキューに書き込まれる（５０６）。更新されたパラメータ値情報は、（直接的にまたはジョブキューまたはその結果得られたワークフロー内のタスクとして）制御プレーン内のデータ記憶部へと保存することができる（５０８）。ジョブキューを監視しているスウィーパーコンポーネントは、ジョブ情報の存在を決定することができ（５１０）、少なくともいくつかの実施形態において、要求されたアクション（単数または複数）のためにワークフローを開始するための要求を送ることができる。ジョブ情報は分析されて、要求されたアクションに適したワークフローが決定および／または組み立てられる（５１２）。ワークフローのタスクとして、制御プレーンは、１つ以上の指定されたパラメータグループと関連付けられた各データインスタンスのホストマネージャを呼び出して、更新された構成ファイルをインストールさせることができる（５１４）。更新についての応答を各ホストマネージャから返送してもらうことができ（５１６）、全インスタンスが要求された変更を成功裏に受容したか否かを示す応答を顧客に送ることができる（５１８）。

しかし、いくつかの場合において、ワークフローのタスクは、更新中のパラメータ（単数または複数）の種類（単数または複数）に少なくとも部分的に依存する場合がある。例えば、多くのデータベースは、「静的な」パラメータおよび「動的な」パラメータを含む少なくとも２つの種類のパラメータを有する。ワークフロータスクが、更新された動的パラメータ（単数または複数）をホストマネージャに実質的に当該要求時に適用させることが可能であるように、動的パラメータは実行時間において設定することができる。静的パラメータは、データベースのスタートアッププロセス（例えば、クエリータイムアウト）の間にのみ設定することが可能であり、データベースの実行中には設定することが不可能なパラメータを含む。ワークフローのタスクのうちの１つに起因して新規構成ファイルがインスタンスのためにデータプレーン内に保存され、静的パラメータに対する変更が設けられた場合、データベースは、データベースがリブートされるまで、変更をピックアップおよび／または変更しないことになる。いくつかの実施形態および／またはインスタンスにおいて、ワークフローは、データベースをデータプレーン内においてリブートさせるための明示的なリブートタスクを発行することができる。これは、許可を得るために顧客に接触する、または別法により許可を得た（例えば、要求の受信の一部として許可を得た）後にデータベースをリブートするワークフローを含むことができる。他の実施形態および／または状況において、構成ファイルはデータプレーン内に保存することができ、任意の更新された静的パラメータ値が後続するリブート時に適用される。いくつかの実施形態において、ユーザは、データプレーン内におけるリブートを強制または要求するための明示的なウェブサービス呼び出しを適切なＡＰＩへと発行することができる。他の場合、クラッシュ、予定されたリブートなどの結果リブートが発生した際に、変更が行われることになる。

いくつかの実施形態において、パラメータの種類は、フィールド、フラグまたは他のこのようなアプローチによって示され、他の実施形態において、グローバルリストにより、どのパラメータが静的なパラメータであり、どのパラメータが動的なパラメータであるかが示される。パラメータの種類はデータベースエンジンによって決定され、静的パラメータのうちの少なくともいくつかが制御プレーンによって定義される。いくつかの実施形態において、「種類」の代わりに、制御プレーンは、「適用方法」または類似のパラメータを利用して、パラメータ値を即時に適用すべきかまたはシステムはリブートのために待機させるべきかを示す。適用方法によってリブートが指定された場合、明示的なリブートを要求する選択肢をユーザが有している旨がユーザに通知される可能性がある。いくつかの場合において、リブートは、初期更新パラメータ呼び出しの一部として指定することができ、あるいは、合意により、静的パラメータを変更すべき旨が示された場合毎にシステムをワークフローの一部としてリブートすべきであると指定することも可能である。

いくつかの実施形態において、上述したように、制御プレーンの監視コンポーネントは、データインスタンスのホストマネージャと定期的に通信することができる。このような定期的通信を用いて、監視コンポーネントは、それぞれのホストマネージャのうちの１つ以上から受信されたイベントまたは通信に基づいていつデータベースがリブートしたかを決定することができる。監視コンポーネントは、リブートに関する情報（例えば、適用されている新規構成ファイルの現在のバージョン番号）を抽出することができ、情報を適切な制御プレーンデータ記憶部内において更新することができる。例えば、リブート時において静的パラメータに対して更新を行うべきであった場合、制御プレーンデータ記憶部内のパラメータは、「ペンディング」の値またはこれと関連付けられた類似の値を持っていた可能性がある。データベースがリブートされ、新規パラメータ値が適用されると、パラメータ値は、例えば「現在の」または「適用済み」に更新することができる。他の場合、リブートが検出されたときに、各パラメータ値をバージョン番号と関連付けることができ、構成ファイルの現在のバージョン番号を更新することができる。顧客は、ウェブサービス呼び出しを例えば適切なＡＰＩへと送ることにより、現在のパラメータ値を要求する能力を有することができる。

顧客は多様なデータインスタンスの多様な動作パラメータまたは構成パラメータを変更する能力を望むことができる一方、プロバイダは一般的には、利用可能性および性能について満たされるべき特定の保証を持つ。そのため、少なくともいくつかの実施形態において、データインスタンスの利用可能性および／または性能に大きな悪影響を与え得る変更を顧客が加えることを回避することが望ましい場合がある。いくつかの実施形態において、利用可能性に影響を与え得るパラメータは、顧客による変更ができないように制限される場合がある。他の実施形態において、多様なこのようなパラメータは顧客によって変更可能であるが、プロバイダは、顧客が従わなければならない範囲または値の組を規定することができる。この値の一定範囲は、全ての顧客およびアプリケーションに対して同一とすることができ、あるいは、使用例によって変化させることもできる（例えば、特定の顧客が「好ましい顧客」であるか、あるいは、顧客が多様なパラメータを変更した場合に発生し得る特定の結果について当該顧客が同意しているなど）。いくつかの実施形態において、顧客は、ＡＰＩ（例えば、「ＤｅｃｒｉｂｅＥｎｇｉｎｅＤｅｆａｕｌｔＰａｒａｍｅｔｅｒ」）を呼び出すことができ、これにより、顧客は、情報（例えば、ＲＤＳシステムによってサポートされているパラメータのリスト、特定のエンジン（例えば、ＭｙＳＱＬ）のためのパラメータ、各パラメータの現在の値、デフォルト値および／またはペンディング値、各パラメータの種類（例えば、静的または動的）、各パラメータが改変可能であるか、および改変可能なパラメータのうちの少なくともいくつかの許容範囲または値、ならびに他のこのような情報、ならびに改変可能なパラメータ）を得ることができる。いくつかの実施形態において、値が受容可能な範囲内に確実に収まるようにするために、変更すべきものとして要求されたパラメータ値のうちの少なくともいくつかは、適用される前に明示的に有効化される。

いくつかの実施形態において、顧客および／またはプロバイダは、データインスタンス、インスタンスクラスなどのために用いられるべきパラメータ値のスケジュールを指定することができる。例えば、顧客は、日中は大量のユーザトラフィックを持つ場合がある一方、夜間はごく少量のトラフィックしか持たないため、大量でありかつ／またはキャッシュ密度の高い作業を夜間に実行することを選択する場合がある。このような例において、顧客は、日中は異なる接続タイムアウト値を持ち、特定のアプリケーションの実行が予定されている夜間の時間は異なるキャッシュ割り当てを持つことを望む場合がある。他の場合、複数の理由（例えば、平日対週末、休日または長期休暇など）のうちの任意の理由に起因してトラフィックまたは作業負荷が変動する場合がある。そのため、スケジュールが制御プレーン内に保存される場合がある。スケジュールにより、ワークフローコンポーネントは、現在の構成ファイルにおける変更を適切なホストマネージャ（単数または複数）に適切なタイミングで通信する。いくつかの場合において、パラメータが設定値間において頻繁に（例えば、毎日）変化する。その場合、ワークフローコンポーネントは、バージョン番号の変更をホストマネージャに連絡するだけでよいように、複数のバージョンの構成ファイルをデータプレーン内に保存しておく。このようなアプローチにより、変更が行われるたびにパラメータ値情報を送る必要性が無くなる。

いくつかの実施形態において、顧客は、１つ以上のパラメータについて固定値の代わりに割合、パーセンテージまたは他の相対的値を選択することができる。例えば、顧客は、割り当てられたバッファキャッシュを現在の作業負荷または割り当てに比例することを望んでもよい。このような例において、顧客は、バッファキャッシュは割り当てられた記憶のうちの２５％であるべきである、実行中のメモリのインスタンスのうちの２５％であるべきである、等々と指定することができる。制御プレーンのコンポーネントは、現在の割り当てなどに基づいて適切な値を決定し、必要に応じて調節を行うことができる。いくつかの場合において、特定の時期または間隔において値の変更が可能であり、一方でいくつかの実施形態において値を監視し、かつ更新を持続的に行うことが可能である。一時的スパイクまたはグリッチに起因する過度な変更（単数）および／または変更（複数）を回避するために、複数の以前の間隔にわたる値を平均化するなどにより、特定量だけの割り当て変更が特定の期間にわたって行われた後に変更を行うことができる。ＲＤＳにより顧客がアクション（例えば、多様なインスタンスのスケーリングまたはより多数の記憶空間をオンザフライで追加すること）を行うことが可能になるため、固定値の代わりに範囲またはパーセンテージを指定した方が有利である可能性がある。したがって、例えば、顧客が計算ノードを小型ノードから大型ノードに変更する場合、顧客は中に入って多様なパラメータについて調節する必要は無い。なぜならば、ＲＤＳがユーザ入力に基づいて適切な値を決定し、パラメータ値を必要に応じて自動変更または「オートスケール」することができるからである。

上述したように、いくつかの実施形態において、顧客は、複数のパラメータグループ（例えば、異なる時期において、異なるアプリケーションのために、異なるインスタンスクラスのために、等々に用いられるグループ）を指定する能力を有することができる。そのため、パラメータのうちの少なくともいくつかが、解消するべき矛盾を潜在的に生じる可能性がある異なるグループにおいて指定された異なる値を有することになる危険性がある。例えば、あるアプリケーションが１日のうちの特定の時間に実行されている場合、当該アプリケーションに対するパラメータグループおよび当該時間に対するパラメータグループが存在する場合があり、システムは、これらのパラメータグループの和集合をとって、現在の時間に適用することができる。一実施形態において、顧客により明示的に設定された任意のパラメータ値は、当該パラメータのデフォルト値に対して優先権を取る。他の場合、より最近に指定された値が優先権を取ることができる。いくつかの場合において、例えば悪影響の可能性を最小限にするために、２つの値のうちより控えめな値が選択される可能性がある。いくつかの場合において、性能を一定期間にわたって監視することができ、システムが適切に機能している場合、より控えめではない値を一定期間にわたって適用することができる、中間値を適用することができる、等々。他にも当該分野において公知の多様な矛盾解消アプローチが利用可能であり、あるいは、後に同様の目的のために開発される。

いくつかの実施形態において、制御プレーンの監視コンポーネントは、フィードバックループの一部として機能することができる。なぜならば、監視コンポーネント（または制御プレーンの類似のコンポーネント）は、ホストマネージャ（単数または複数）から性能情報を定期的に受信することができ、これにより、制御プレーンは、性能情報を分析し、多様なパラメータに対して行うべき任意の調節を行うことができるからである。このような調節は、例えばスケジュールまたは指定されたパーセンテージもしくは範囲に従って行うことができ、あるいは、例えばプロバイダが性能または利用可能性を最適化するように選択した１つ以上のアルゴリズムに従って行うこともできる。例えば作業負荷が高い期間においては、接続タイムアウトを増加しておくことが望ましく、利用可能なキャッシュが少なくなっている場合は、キャッシュ量を調節する必要があるかもしれない、等々。また、特定の顧客、アプリケーションなどに対して適用される多様な規則または方針に従って調節を行うことも可能である。いくつかの実施形態において、動的パラメータを自動調節することができるが、静的パラメータの変更については顧客に提案を行うことができる。なぜならば、静的パラメータを変更するには、データインスタンスのリブート（および一時的な利用不可能性）が必要になる可能性があるからである。

図６は、例示的プロセス６００を示す。例示的プロセス６００により、制御プレーンまたは制御サービスは、データ環境内のデータインスタンス（またはデータ記憶部、レポジトリなど）の性能を監視することができる。状態に関する要求が、制御プレーンからデータインスタンスのホストマネージャコンポーネントへと送られる（６０２）。指定された期間内に応答が受信されたかについて判定する（６０４）。応答が受信されなかった場合、要求の閾値が送られたかについて決定する（６０６）。要求の閾値が送られていない場合、別の要求が送られる可能性がある（６０８）。応答メッセージが受信された場合、応答を分析して、何らかのアクション（例えば、対処すべき何らかのエラーまたはタスクがあるか、パラメータ値を調節すべき旨を示す性能情報があるか、または現在のパラメータグループのバージョン番号が変えられているか）を行う必要があるかどうかを判定する（６１０）。そのような必要が無く、かつ当該インスタンスを健康であると判断される場合、プロセスは、後で送信されてきた別の状態要求により継続することができる。応答メッセージがデータインスタンスについてアクションを行うべきである旨を示している場合、アクションについての情報（例えば、アクションの種類およびアクションを行うために利用または調節されるべきパラメータ）が、管理データ記憶部または他のこのような記憶場所に配置されていてもよいようなジョブキューへと書き込まれる（６１２）。ジョブキューを監視することで、ジョブ情報の存在を、スウィーパーコンポーネントなどのようなものにより、判断することが可能であり（６１４）、ジョブ情報が検出されると、要求されたアクションのためのワークフローを開始するように要求を送ることができる（６１６）。他の実施形態において、ワークフローコンポーネントは、ジョブに対してジョブキューを監視してもよく、あるいは、ウェブサービス層のコンポーネントがジョブ情報を直接ワークフローコンポーネントへ送ってもよい。

ジョブ情報が受信されると、情報を分析して、要求されたアクションに適したワークフローを決定および／または組み立てる（６１８）。その後、ワークフローを実行される（６２０）。データ環境内において実行されるべきタスクがワークフロー中に含まれている場合、状態または他の情報をデータ環境内のホストマネージャへと送ることで、タスクを実行し、ワークフロー（例えば、上述したプロセスを用いて達成されるかもしれないもの）を実行することが可能になる。最終タスクが成功裏に完了した場合、データインスタンスは、データプレーンインターフェースを介して顧客またはアプリケーションから送られてくる要求を単純に処理し続ける。ワークフローが制御環境内においてアクション（例えば、管理データ記憶部内のバージョンおよび状態情報の更新）を行うことである場合、ワークフローは、制御環境の適切なコンポーネントに多様なタスクを指示することができる。何れかのタスクが成功裏に完了できなかった場合、または当該タスクがアクション（例えば、データインスタンスのリブート）を必要とすることになる場合、例えば、メッセージまたは他の通知を顧客（または別の適切なユーザ、アプリケーション、または場所）へと送ることができる。他にも多様な通知アクション（例えば、アクション通知の生成および／またはエラーログへの情報追加）を行うことが可能である。

上述したように、制御プレーン層は、多様な基本ソフトウェアフレームワークを有利に利用するかまたはその「上位に立って」、タスク（例えば、ワークフローの実行、データプレーンのホストマネージャと制御プレーンのコンポーネントとの間のセキュアな通信路の確立、データプレーンのインスタンス上へのソフトウェアのインストール、および多様なデータベースバックアップおよび回復手順の実行）を行うことができる。

例えば、制御プレーン層は、ワークフローサービスの利点を利用して、ワークフローを管理することができる。一般的に公知のように、任意のワークフローエンジンの主な特徴として、処理を非同期的かつ再開可能に行うことがエンジンにより可能となる点がある。上述したように、ワークフローは状態機械とみなすことができ、初期状態から開始して、ワークフローの異なるステップの実行により一連の中間状態遷移を経た後、最終目標に到達する。この最終目標は、状態機械の最終状態とみなすことができる。ワークフローサービスは、ワークフローを生成する能力を提案し、所与のワークフローの現在の状態と、次に実行されるべきステップ（単数または複数）とを決定するための仕掛けを提供する。サービスは、状態機械の現在の状態を保存することができ、連続的に実行されるステップを追跡し、ワークフローを継続的に進めるために実行することが必要なステップを追跡する。サービスは一般的には、我々のための状態遷移を実際には実行しない。ワークフローのためのタスクを実行する的確なタスクは、多くの実施形態においてワークフローの「クライアント」コンポーネントにより実行されることになる。制御プレーンは任意の所与の時間において並行して実行される複数のワークフローを有することができ、またこれらのワークフローは異なるタスクを行うためのものとすることができるため、制御プレーンは、複数のワークフローをスケジュールしかつ複数の活動を並行して実行することが可能なアーキテクチャの利点を利用することができる。

別の有利に利用可能なアーキテクチャは、セキュアな通信をデータプレーンのホストマネージャへホストプレーンのコンポーネントから提供することに関連する。一実施形態において、制御プレーンのワークフローおよび監視コンポーネントは、常にホストマネージャと通信して、多様なタスク（例えば、データベースメンテナンスおよびソフトウェアインストール）を行い、それだけでなく多様なインスタンスおよび／またはレポジトリの状態を確認する。少なくともいくつかの実施形態において、制御プレーンとホストマネージャとの間の全通信をセキュアなネットワークを介して行うことで、任意の何者かによる盗聴またはホストマネージャへの不正コマンドの発行を回避することが重要である。

一実施形態において、セキュアなソケット層（ＳＳＬ）を介してハイパーテキスト転送プロトコルを用いて、ホストマネージャへの全通信路をセキュアにする。ホストマネージャアプリケーションをホストする各アプリケーションサーバーは、インスタンスのブートアップ時のスクリプトを用いて開始することができる。アプリケーションサーバーエンジンの開始前に、自署署名した証明を生成し、この証明をインストールして、ＳＳＬ通信路（単数または複数）を有効化するためのスクリプトを実行することができる。このスクリプトにより。一実施形態において、ＳＳＬ通信は通信路の暗号化に用いられ、クライアント認証には用いられない。すなわち、クライアント認証は、その代わりに、各要求中に埋め込まれた公開鍵／秘密鍵による署名によって達成され、これにより、一実施形態において、全クライアントが、秘密鍵を用いてクエリーストリングパラメータに署名する。この署名は、ホストマネージャのためのアプリケーションサーバーにより展開することができる、カスタムインターセプターによって有効化することができる。さらに、データプレーン内の各監視対象インスタンスに対してセキュリティグループ（すなわち、ファイアウォール規則）を確立することで、所与のネットワークまたはセキュアなグループ内にいるホストのみがホストマネージャポートを用いて通信することができる。セキュアな情報および認証情報（例えば、秘密鍵）を適切な鍵保存場所に保存することができ、その結果、鍵管理および鍵交代などのような機能を提供することができる。

ホストマネージャアプリケーションのインストールおよび任意の更新は、全ての他のインスタンスを削除する必要が無いやり方で、各インスタンスについて管理下に置くことも可能である。一実施形態において、インスタンスは、ブートアップ時にアプリケーションサーバーエンジンを開始させ、アプリケーションサーバーマネージャフレームワークを呼び出して新規ホストアプリケーションを展開させることにより、ホストマネージャがインストールされる。他の通信と同様に、通信を傍受することができ、ソフトウェアをインストールし、またはホストマネージャを更新を強要する前にクライアントを認証することができ、これは、既存のレポジトリの利用可能性に影響を与えること無しに達成することができる。

基礎フレームワークに依存する可能性がある別の態様は、レポジトリおよびデータバックアップに関連する。多様な理由により、制御プレーンが顧客レポジトリおよびインスタンスをバックアップすることが望ましい可能性がある（例えば、ユーザによって開始されるバックアップ（これは、バックアップの時間ウィンドウの間に実行可能である）およびデータベース回復の間にシステムによって開始されるバックアップ、等々）。双方のインスタンスを取り扱うように、単一のフレームワークを実行することができる。レポジトリをバックアップするために、フレームワークは、データファイルおよび任意の関連ログファイル双方のバックアップを取り扱うことができる。多様なステップおよびプロセスについて説明するが、多様なステップおよびアプローチは多様なデータベースエンジン（例えば、ＭｙＳＱＬおよび他のもの）によって異なる可能性があることが理解されるべきである。

一実施形態によるデータをバックアップするためのアプローチは、適切なデータボリュームのスナップショットがとられ、ログファイルが同様に適切な場所にコピーされるまで、データ操作を一時停止する。例えば、管理階層は、バックアップ手順を開始する前に、バックアップウィンドウを待機することができる。バックアップウィンドウ内に入ると、管理階層は、レポジトリバックアップのためのワークフローインスタンスが生成することになるワークフローをリエート（ｒｅａｔｅ）することができる。一例において、ワークフローは、「ｓｕｐｅｎｄＤａｔａｂａｓｅＦｏｒＢａｃｋｕｐ」または類似のＡＰＩをホストマネージャのために呼び出す。このＡＰＩは、例えば、表のフラッシュおよびロックを行うタスク、Ｉ／Ｏをデータボリュームに対して一時停止するタスク、ＬＶＭスナップショットをログボリュームのために生成および取り付けるタスク、最終ログ位置によりログ位置ファイルを生成するタスク、およびデータベース再開のためにタイマーを起動させるタスクなどのタスクを管理することができる。このタイマーを用いれば、タスク（例えば、スナップショット撮影）の実行時に管理階層がハングアップした場合にレポジトリを再開させることが可能となり、その結果、レポジトリが偶発的に無期限に中断される事態が回避される。ワークフローは、上記のタスクおよび／または他のこのようなタスクの完了について、ホストマネージャをポーリングすることができる。ホストマネージャがレポジトリを一時停止したことをワークフローが確認すると、ワークフローは、１組の順序付けられたタスクを用いて、データボリュームをバックアップすることを試行する。例えば、ワークフローは、各データボリュームのスナップショットを生成し、スナップショットが成功裏に生成されていることを確認することを示すことができる。ｂａｃｋｕｐ＿ｄａｔａ＿ｖｏｌｕｍｅｓ表などのような場所内の各スナップショットボリュームに行を挿入することができる。その後、ワークフローは、ホストマネージャの「ｒｅｓｕｍｅＤａｔａｂａｓｅＦｒｏｍＢａｃｋｕｐ」または類似のＡＰＩを呼び出すことができる。このプロセスは、レポジトリログおよびログ位置情報を適切な記憶場所にコピーすることができ、ログスナップショットを取り外すことができ、ログスナップショットログボリュームを除去し、全ての表をロック解除する。その後、管理階層は、バックアップが完了し、レポジトリが再度利用可能である旨を示す顧客イベントを作成することができる。

上述したように、ログファイルは、同様の様態でバックアップ可能である。これらのログを用いて、タスク（例えば、データファイルを回復しなければならない場合の多様なトランザクションの再生）を行うことができる。エンジンログは適切な記憶場所にコピーすることができ、これにより、以前バックアップされたログファイルを簡単なリストコマンドを用いて得ることができる。ホストマネージャは、この結果を用いて、コピーすべきログがあるかを決定することができる。例えば、ホストマネージャは、最終シーケンスをバックアップすることが可能なように書かれたログファイルリストを得るために、バケットリストを要求することができる。新規ログが生成されている場合、ログがデータベースエンジンによってアクティブに書き込まれているものではないと先ず判断することができ、その後、ログをコピーすることができ、かつそのコピーは成功裏に行われたことを確認することができる。

上述したように、多様な動作環境において多様な実施形態を実行することが可能である。いくつかの場合において、そのような多様な動作環境としては、複数のアプリケーションのうちの任意のアプリケーションを作動させるために使用することが可能な１つ以上のユーザコンピュータ、コンピューティングデバイス、または処理デバイスを挙げることができる。ユーザデバイスまたはクライアントデバイスは、複数の汎用パーソナルコンピュータ（例えば、標準オペレーティングシステムを実行するデスクトップコンピュータまたはラップトップコンピュータ、ならびにモバイルソフトウェアを実行し、複数のネットワーキングプロトコルおよびメッセージングプロトコルをサポートする能力を有するセルラーデバイス、無線デバイスおよびハンドヘルドデバイス）のうちの任意のものを含むことができる。このようなシステムはまた、開発およびデータベース管理などの目的のための多様な市販のオペレーティングシステムおよび他の公知のアプリケーションのうちの任意のものを実行する複数のワークステーションも含むことができる。これらのデバイスはまた、他の電子デバイス（例えば、ダミーターミナル、シンクライアント、ゲーミングシステム、およびネットワークを介して通信する能力を有する他のデバイス）も含むことができる。

多様な態様を、サービス志向アーキテクチャの一部であってもよいような、少なくとも１つのサービスまたはウェブサービスの一部として実行することも可能である。サービス（例えば、ウェブサービス）は、任意の適切な種類のメッセージングを用いて（例えば、拡張マークアップ言語（ＸＭＬ）形式のメッセージを用い、適切なプロトコル（例えば、ＳＯＡＰ（「シンプルオブジェクトアクセスプロトコル」に由来する）を用いて交換することにより）通信することができる。このようなサービスにょって提供または実行されるプロセスは、任意の適切な言語（例えば、ウェブサービス記述言語（ＷＳＤＬ））を用いて書き込むことが可能である。ＷＳＤＬなどのような言語を用いることで、クライアント側コードを多様なＳＯＡＰフレームワーク内において自動生成することなどのような機能性が可能になる。

ほとんどの実施形態において、多様な市販のプロトコル（例えば、ＴＣＰ／ＩＰ、ＯＳＩ、ＦＴＰ、ＵＰｎＰ、ＮＦＳ、ＣＩＦＳ、およびＡｐｐｌｅＴａｌｋ）のうちの任意のものを用いて通信をサポートするために用いられる当業者に良く知られている少なくとも１つのネットワークが用いられる。ネットワークは、例えば、ローカルエリアネットワーク、広域ネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、およびこれらの任意の組み合わせとすることができる。

ウェブサーバーを用いた実施形態において、ウェブサーバーは、ＨＴＴＰサーバー、ＦＴＰサーバー、ＣＧＩサーバー、データサーバー、Ｊａｖａサーバー、およびビジネスアプリケーションサーバーを含む、多様なサーバーまたはミッドティアアプリケーションのうちの任意のものを実行することができる。サーバー（単数または複数）は、例えば任意のプログラミング言語（例えば、Ｊａｖａ（登録商標）、Ｃ、Ｃ＃またはＣ＋＋）、あるいは任意のスクリプト記述言語（例えば、Ｐｅｒｌ、Ｐｙｔｈｏｎ、またはＴＣＬ）、ならびにこれらの組み合わせで書かれた１つ以上のスクリプトまたはプログラムとして実行されてもよい１つ以上のウェブアプリケーションを実行することなどのようなことにより、ユーザデバイスからの要求に応答して、プログラムまたはスクリプトを実行する能力を有してもよい。サーバー（単数または複数）は、非限定的に、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）、およびＩＢＭ（登録商標）から市販されているものを含む、データベースサーバーも含んでもよい。

環境は、上述したように多様なデータ記憶部および他のメモリおよび記憶媒体を含むことができる。これらは、１つ以上のコンピュータにとって局所的な（かつ／または１つ以上のコンピュータ中に常駐している）記憶媒体の上、あるいは、ネットワークを介した任意のコンピュータまたは全てのコンピュータから遠隔の位置などのような多様な場所に常駐することができる。実施形態の特定の組において、情報は、当業者に公知のストレージエリアネットワーク（「ＳＡＮ」）内に常駐してもよい。同様に、コンピュータ、サーバーまたは他のネットワークデバイスに帰属する機能を実行するために必要な任意のファイルは適宜局所的におよび／または遠隔的に保存してもよい。システムがコンピュータ化されたデバイスを含む場合、このようなデバイスはそれぞれ、バスを介して電気的に接続されていてもよい、ハードウェア要素を含むことができる。これらの要素としては、例えば、少なくとも１つの中央処理装置（ＣＰＵ）、少なくとも１つの入力デバイス（例えば、マウス、キーボード、コントローラ、タッチスクリーン、またはキーパッド）、および少なくとも１つの出力デバイス（例えば、表示デバイス、プリンタ、またはスピーカ）が挙げられる。このようなシステムは、ディスクドライブ、光学記憶デバイス、およびソリッドステート記憶デバイスなどのような、ランダムアクセスメモリ（「ＲＡＭ」）またはリードオンリーメモリ（「ＲＯＭ」）などのような、１つ以上の記憶デバイス、ならびにリムーバブルメディアデバイス、メモリカード、フラッシュカード等々もまた含んでもよい。

このようなデバイスはまた、コンピュータ可読記憶媒体リーダー、通信デバイス（例えば、モデム、ネットワークカード（無線または有線）、赤外線通信デバイスなど）、および上述したようなワーキングメモリも含むことができる。コンピュータ可読記憶媒体リーダーは、一時的および／またはより恒久的に、コンピュータ可読情報を含有、保存、送信および検索するためのリモート記憶デバイス、ローカル記憶デバイス、固定記憶デバイスおよび／または取り外し可能な記憶デバイスならびに記憶媒体を意味する、コンピュータ可読記憶媒体と接続することができるかまたはこれらを受容するように構成することができる。システムおよび多様なデバイスは典型的には、少なくとも１つのワーキングメモリデバイス内に配置された複数のソフトウェアアプリケーション、モジュール、サービスまたは他の要素、例えば、オペレーティングシステム、およびクライアントアプリケーションまたはウェブブラウザなどのようなアプリケーションプログラムを含むことになる。代替の実施形態が、上述したものと異なる多数の改変を有してもよいことを理解するべきである。例えば、カスタマイズされたハードウェアが使用されてもよく、かつ／または特定の要素をハードウェア、ソフトウェア（ａｐｐｌｅｔなどのようなポータブルソフトウェアを含む）、もしくは両方において実行してもよい。さらに、他のコンピューティングデバイス（例えば、ネットワーク入力／出力デバイス）への接続も使用されてもよい。

コードまたはコードの部分を収容するための記憶媒体およびコンピュータ可読媒体としては、（例えば、そのような記憶媒体および通信媒体を非限定的に挙げると、情報（例えば、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータ）の記憶および／または送信のための、任意の方法または技術において実行される、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多機能ディスク（ＤＶＤ）または他の光学記憶、磁気カセット、磁気テープ、磁気ディスク記憶または他の磁気記憶デバイス、または所望の情報の保存のために使用することが可能でありかつシステムデバイスによるアクセスが可能な他の任意の媒体を含む、揮発性媒体および不揮発性媒体、取り外し可能な媒体および取り外し不可能な媒体などのような、記憶媒体および通信媒体を含む当該分野において公知であるかまたは用いられている任意の適切な媒体を挙げることができるが、これに限らない。本明細書中に提供される開示および教示内容に基づけば、当業者は、多様な実施形態を実行するための他の様態および／または方法を理解するであろう。

付記項１． 関係データベースインスタンスの構成値を１つ以上のセルフサービスウェブサービスを用いて管理するための、コンピュータ実装される方法であって、
実行可能な命令と共に構成された１つ以上のコンピュータシステムによる制御の下、
各々がユーザにウェブサービス要求を制御環境へ提出させることを可能にする、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、各ＡＰＩは、前記ユーザに対する関係データベースについて別個のデータベース環境内において行われるべき所望のアクションに対応する、提供することと、
前記データベース環境内においてプロビジョンされるべき少なくとも１つのデータインスタンスのためのデフォルトパラメータグループを提供することであって、前記デフォルトパラメータグループは、複数のデータベース構成パラメータに対する値を含み、前記デフォルトパラメータグループは、第１のバージョン番号を有する、提供することと、
前記複数のＡＰＩのうちの第１のＡＰＩを通して第１のウェブサービス要求が前記制御環境に受信されることに応答して、前記別個のデータベース環境内においてデータインスタンスをプロビジョニングする際に適用されるべき第１の改変されたパラメータグループを指定するための少なくとも１つのタスクを実行させることであって、前記第１の改変されたパラメータグループは、第２のバージョン番号を有する、実行させることと、
前記複数のＡＰＩのうちの第２のＡＰＩを通して第２のウェブサービス要求が前記制御環境に受信されることに応答して、前記ユーザのためにプロビジョンされた少なくとも１つのデータインスタンスについて、第３のバージョン番号を有する第２の改変されたパラメータグループを適用するための少なくとも１つのタスクを前記別個のデータベース環境内において実行させることと、
を含み、
前記ユーザは、単一のウェブサービス呼び出しを前記制御環境に提出することにより、前記関係データベースの１つ以上のインスタンスのパラメータ値を指定または改変することができる、
方法。

付記項２． 前記デフォルトパラメータグループは、前記データベース環境内においてプロビジョンされるべき前記少なくとも１つのデータインスタンスに対して最適化された、少なくとも１つのパラメータ値を含む、付記項１のコンピュータ実装される方法。

付記項３． 前記少なくとも１つのデータインスタンスの現在のパラメータグループバージョンおよび前記少なくとも１つのデータインスタンスに適用されている任意の変更を示す状態情報について前記制御環境内に保存されている情報を更新することをさらに含む、付記項１のコンピュータ実装される方法。

付記項４． ユーザが別個の制御環境を用いてデータベース環境内のデータインスタンスの動作パラメータを管理することを可能にする、コンピュータ実装される方法であって、
実行可能な命令と共に構成された１つ以上のコンピュータシステムによる制御の下、
複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、前記ＡＰＩはそれぞれ、ユーザがウェブサービス要求を前記制御環境に提出することを可能にし、各ＡＰＩは、前記ユーザに対する１つ以上のデータインスタンスについてデータベース環境内において行われるべき所望のアクションに対応する、ことと、
前記データベース環境内においてプロビジョンされるべき１つ以上の１つのデータインスタンスについて、デフォルトパラメータグループを提供することであって、前記デフォルトパラメータグループは、複数のデータベースパラメータに対する値を含み、前記デフォルトパラメータグループは第１のバージョン番号を有する、提供することと、
ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記１つ以上のデータインスタンスについて改変されたパラメータグループを適用させることであって、前記改変されたパラメータグループは第２のバージョン番号を有し、前記ユーザは、前記データインスタンスのうちの少なくとも１つを生成する前に、前記１つ以上のデータインスタンスのうちの任意のもののパラメータ値を改変することができるか、または、前記１つ以上のデータインスタンスのうちの任意のものが前記データベース環境上で実行しているのと同時に、前記１つ以上のデータインスタンスのうちの任意のもののパラメータ値を改変することができる、適用させることと、
を含む、方法。

付記項５． 前記パラメータ値が動的値である場合、前記改変されたパラメータグループの更新されたパラメータ値が実質的に前記要求時において前記実行しているデータインスタンスに適用され、
前記パラメータ値が静的値である場合、前記データインスタンスがリブートされると、前記パラメータ値が前記実行しているデータインスタンスに適用される、
付記項４のコンピュータ実装される方法。

付記項６． ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記実行しているデータインスタンスのうちの１つ以上をリブートし、これにより前記静的値を適用させること、
をさらに含む、付記項５のコンピュータ実装される方法。

付記項７． 少なくとも１つのデータインスタンスについて前記改変されたパラメータグループを適用することは、前記改変されたパラメータグループがそこへ適用されるべき各データインスタンスの前記少なくとも１つのパラメータ値を含む、構成ファイルをインストールすることをさらに含む、付記項４のコンピュータ実装される方法。

付記項８． 前記データベース環境は、複数のデータインスタンスをデータインスタンスクラス内に提供するように動作可能であり、
前記ユーザは、前記データインスタンスクラス内の前記複数のインスタンス全てについて、単一のウェブサービス呼び出しを用いて改変されたパラメータグループを指定することがさらに可能である、
付記項４のコンピュータ実装される方法。

付記項９． 前記ウェブサービス要求に応答して、前記１つ以上のデータインスタンスについて前記改変されたパラメータグループを適用させるための少なくとも１つのタスクを含むワークフローを前記制御環境内において実行することであって、前記ワークフローは、前記１つ以上のデータインスタンスの現在のパラメータグループバージョンについての情報および前記１つ以上のデータインスタンスに適用されている何らかの変更を示す状態情報を更新するための少なくとも１つのタスクをさらに含む、実行すること、
をさらに含む、付記項４のコンピュータ実装される方法。

付記項１０． 前記制御プレーンの監視コンポーネントは、前記１つ以上のデータインスタンスそれぞれについてホストマネージャと定期的に通信し、前記ホストマネージャが前記データインスタンスのうちの１つについて前記パラメータグループの現在のバージョンを更新するのに応答して、前記データインスタンスの前記現在のパラメータグループバージョンの情報および成功裏に適用された前記改変されたパラメータグループを示す状態情報を更新する、付記項９のコンピュータ実装される方法。

付記項１１． 前記１つ以上のデータインスタンスについての情報を監視することと、
前記更新パラメータグループ内の少なくとも１つのパラメータ値を更新すべきである場合、前記監視された情報に少なくとも部分的に基づいて、更新されたパラメータグループを自動的に適用すること、
をさらに含む、付記項１０のコンピュータ実装される方法。

付記項１２． 前記制御環境内のデータ記憶部に対するデータインスタンスについて、前記パラメータグループの現在のバージョンのパラメータ値を保存すること、
をさらに含む、付記項４のコンピュータ実装される方法。

付記項１３． 前記ユーザは、パラメータ値と、前記データベース環境の態様との間の関係を指定することができ、
前記データベース環境の前記態様の前記関係および変更を用いて、前記パラメータ値は自動的に更新する能力を有する、
付記項４のコンピュータ実装される方法。

付記項１４． 前記ウェブサービス要求は、データベースエンジンと無関係である、付記項４のコンピュータ実装される方法。

付記項１５． ユーザが別個の制御環境を用いてデータベース環境内のデータインスタンスの動作パラメータを管理することを可能にするシステムであって、
プロセッサと、
命令を含むメモリデバイスと、
を備え、
前記命令が前記プロセッサによって実行されると、前記プロセッサに、
各々がユーザにウェブサービス要求を前記制御環境へと提出させることを可能にする、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、各ＡＰＩは、前記ユーザの１つ以上のデータインスタンスについてデータベース環境内において実行されるべき所望のアクションに対応する、提供することと、
前記データベース環境内においてプロビジョンされるべき１つ以上の１つのデータインスタンスについて、デフォルトパラメータグループを提供することであって、前記デフォルトパラメータグループは複数のデータベースパラメータに対する値を含み、前記デフォルトパラメータグループは第１のバージョン番号を有する、提供することと
ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記１つ以上のデータインスタンスについて改変されたパラメータグループを適用させることであって、前記改変されたパラメータグループは第２のバージョン番号を有し、前記ユーザは、前記データインスタンスのうちの少なくとも１つを生成する前に、前記１つ以上のデータインスタンスのうちの任意のもののパラメータ値を改変することができるか、または、前記１つ以上のデータインスタンスのうちの任意のものが前記データベース環境上で実行しているのと同時に、前記１つ以上のデータインスタンスのうちの任意のもののパラメータ値を改変することができる、適用させることと、
をさせる、システム。

付記項１６． 前記パラメータ値が動的値である場合、前記改変されたパラメータグループの更新されたパラメータ値が実質的に前記要求時において前記実行しているデータインスタンスに適用され、
前記パラメータ値が静的値である場合、前記データインスタンスがリブートすると、前記パラメータ値が前記実行しているデータインスタンスに適用される、
付記項１５に記載のシステム。

付記項１７． 前記命令が実行されると、前記プロセッサに、
ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記実行しているデータインスタンスのうちの１つ以上をリブートさせ、それにより前記静的値を適用させること、
をさらにさせる、付記項１５に記載のシステム。

付記項１８． 少なくとも１つのデータインスタンスについて前記改変されたパラメータグループを適用することは、前記改変されたパラメータグループがそこに適用されるべき各データインスタンスに対して少なくとも１つのパラメータ値を含む、構成ファイルをインストールすることをさらに含む、付記項１５に記載のシステム。

付記項１９． 前記データベース環境は、複数のデータインスタンスをデータインスタンスクラス内に提供するように動作可能であり、
前記ユーザは、前記データインスタンスクラス内の前記複数のインスタンス全てについて、単一のウェブサービス呼び出しを用いて改変されたパラメータグループを指定することがさらに可能である、
付記項１５に記載のシステム。

付記項２０． 前記命令が実行されると、前記プロセッサに、
前記ウェブサービス要求に応答して、前記１つ以上のデータインスタンスについて前記改変されたパラメータグループを適用させるための少なくとも１つのタスクを含むワークフローを前記制御環境内において実行させることであって、前記ワークフローは、前記１つ以上のデータインスタンスの現在のパラメータグループバージョンについての情報および前記１つ以上のデータインスタンスに適用されている何らかの変更を示す状態情報を更新するための少なくとも１つのタスクをさらに含み、前記制御プレーンの監視コンポーネントは、前記１つ以上のデータインスタンスそれぞれについてホストマネージャと定期的に通信し、前記ホストマネージャが前記データインスタンスのうちの１つについて前記パラメータグループの現在のバージョンを更新するのに応答して、前記データインスタンスの前記現在のパラメータグループバージョンについての情報および成功裏に適用された前記改変されたパラメータグループを示す状態情報を更新する、実行させること、
をさせる、付記項１５に記載のシステム。

付記項２１． コンピュータ可読記憶媒体であって、別個の制御環境を用いてデータベース環境内のデータインスタンスの動作パラメータを管理するための命令を記憶し、前記命令がプロセッサによって実行されると、前記プロセッサに、
各々がユーザにウェブサービス要求を前記制御環境へと提出させることを可能にする、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、各ＡＰＩは、前記ユーザの１つ以上のデータインスタンスについてデータベース環境内において行われるべき所望のアクションに対応する、ことと、
前記データベース環境内においてプロビジョンされるべき１つ以上の１つのデータインスタンスについて、デフォルトパラメータグループを提供することであって、前記デフォルトパラメータグループは複数のデータベースパラメータに対する値を含み、前記デフォルトパラメータグループは第１のバージョン番号を有する、提供することと、
ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記１つ以上のデータインスタンスについて改変されたパラメータグループを適用させることであって、前記改変されたパラメータグループは第２のバージョン番号を有し、前記ユーザは、前記データインスタンスのうちの少なくとも１つを生成する前に、前記１つ以上のデータインスタンスのうちの任意のものに対するパラメータ値を改変することができるか、または、前記１つ以上のデータインスタンスのうちの任意のものが前記データベース環境内で実行しているのと同時に、前記１つ以上のデータインスタンスのうちの任意のものに対するパラメータ値を改変することができる、適用させることと、
をさせる、コンピュータ可読記憶媒体。

付記項２２． 前記パラメータ値が動的値である場合、前記改変されたパラメータグループの更新されたパラメータ値が実質的に前記要求時において前記実行しているデータインスタンスに適用され、
前記パラメータ値が静的値である場合、前記データインスタンスがリブートされると前記パラメータ値が前記実行しているデータインスタンスに適用される、
付記項２１に記載の、コンピュータ可読記憶媒体。

付記項２３． 前記命令が実行されると、前記プロセッサに、
ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記実行しているデータインスタンスのうちの１つ以上をリブートさせ、これによって前記静的値を適用させること、
をさらにさせる、付記項２１に記載の、コンピュータ可読記憶媒体。

付記項２４． 少なくとも１つのデータインスタンスについて前記改変されたパラメータグループを適用することは、前記改変されたパラメータグループがそこに適用されるべき各データインスタンスに対する前記少なくとも１つのパラメータ値を含む、構成ファイルをインストールすることをさらに含む、付記項２１に記載の、コンピュータ可読記憶媒体。

付記項２５． 前記データベース環境は、複数のデータインスタンスをデータインスタンスクラス内に提供するように動作可能であり、
前記ユーザは、前記データインスタンスクラス内の前記複数のインスタンス全てについて、単一のウェブサービス呼び出しを用いて改変されたパラメータグループを指定することがさらに可能である、
付記項２１に記載の、コンピュータ可読記憶媒体。

Claims (15)

1. ユーザが別個の制御環境を用いてデータベース環境内のデータインスタンスの動作パラメータを管理することを可能にする、コンピュータ実装される方法であって、
   実行可能な命令と共に構成された１つ以上のコンピュータシステムによる制御の下、
   各々がユーザにウェブサービス要求を制御環境へ提出させることを可能にする、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、各ＡＰＩは、前記ユーザの１つ以上のデータインスタンスについてデータベース環境内において実行されるべき所望のアクションに対応する、ことと、
   前記データベース環境内においてプロビジョンされるべき１つ以上のデータインスタンスについて、デフォルトパラメータグループを提供することであって、前記デフォルトパラメータグループは複数のデータベースパラメータの値を含み、前記デフォルトパラメータグループは第１のバージョン番号を有する、ことと、
   ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記１つ以上のデータインスタンスについて改変されたパラメータグループを適用させることであって、前記改変されたパラメータグループは第２のバージョン番号を有し、前記ユーザは、前記データインスタンスのうちの少なくとも１つを生成する前に、前記１つ以上のデータインスタンスのうちの任意のものに対するパラメータ値を改変することができるか、または、前記１つ以上のデータインスタンスのうちの任意のものが前記データベース環境上で実行しているのと同時に、前記１つ以上のデータインスタンスのうちの任意のものに対するパラメータ値を改変することができる、適用させることと、
   を含むことを特徴とする方法。
2. 前記パラメータ値が動的値である場合、前記改変されたパラメータグループの更新されたパラメータ値が実質的に前記要求時において前記実行しているデータインスタンスに適用され、
   前記パラメータ値が静的値である場合、前記データインスタンスがリブートされると前記パラメータ値が前記実行しているデータインスタンスに適用されることを特徴とする請求項１に記載の、コンピュータ実装される方法。
3. ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記実行しているデータインスタンスのうちの１つ以上をリブートさせ、それにより前記静的値を適用させることをさらに含むことを特徴とする請求項２に記載の、コンピュータ実装される方法。
4. 少なくとも１つのデータインスタンスについて前記改変されたパラメータグループを適用することは、前記改変されたパラメータグループがそこに適用されるべき各データインスタンスに対する前記少なくとも１つのパラメータ値を含む、構成ファイルをインストールすることをさらに含むことを特徴とする請求項１に記載の、コンピュータ実装される方法。
5. 前記データベース環境は、複数のデータインスタンスをデータインスタンスクラス内に提供するように動作可能であり、前記ユーザは、前記データインスタンスクラス内の前記複数のインスタンス全てについて、単一のウェブサービス呼び出しを用いて改変されたパラメータグループを指定することがさらに可能であることを特徴とする請求項１に記載の、コンピュータ実装される方法。
6. 前記ウェブサービス要求に応答して、前記１つ以上のデータインスタンスについて前記改変されたパラメータグループを適用させるための少なくとも１つのタスクを含むワークフローを前記制御環境内において実行させることであって、前記ワークフローは、前記１つ以上のデータインスタンスの現在のパラメータグループバージョンについての情報および前記１つ以上のデータインスタンスに適用されている何らかの変更を示す状態情報を更新するための少なくとも１つのタスクをさらに含む、実行されることをさらに含むことを特徴とする請求項１に記載の、コンピュータ実装される方法。
7. 前記制御プレーンの監視コンポーネントは、前記１つ以上のデータインスタンスそれぞれについてホストマネージャと定期的に通信し、前記ホストマネージャが前記データインスタンスのうちの１つについて前記パラメータグループの現在のバージョンを更新するのに応答して、前記データインスタンスの現在のパラメータグループバージョンの情報および成功裏に適用された前記改変されたパラメータグループを示す状態情報を更新することを特徴とする請求項６に記載の、コンピュータ実装される方法。
8. 前記制御環境内のデータ記憶部に対するデータインスタンスについて、前記パラメータグループの現在のバージョンのパラメータ値を保存すること、
   をさらに含むことを特徴とする請求項１に記載の、コンピュータ実装される方法。
9. 前記ユーザは、パラメータ値と、前記データベース環境の態様との間の関係を指定することができ、前記パラメータ値は、前記データベース環境の前記態様の前記関係および変更を用いて自動的に更新する能力を有することを特徴とする請求項１に記載の、コンピュータ実装される方法。
10. ユーザが別個の制御環境を用いてデータベース環境内のデータインスタンスの動作パラメータを管理することを可能にするシステムであって、
    プロセッサと、
    命令を含むメモリデバイスと、
    を備え、
    前記命令が前記プロセッサによって実行されると、前記プロセッサに、
    各々がユーザにウェブサービス要求を前記制御環境へと提出させることを可能にする、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、各ＡＰＩは、前記ユーザの１つ以上のデータインスタンスについてデータベース環境内において実行されるべき所望のアクションに対応する、提供することと、
    前記データベース環境内においてプロビジョンされるべき１つ以上のデータインスタンスについて、デフォルトパラメータグループを提供することであって、前記デフォルトパラメータグループは複数のデータベースパラメータに対する値を含み、前記デフォルトパラメータグループは第１のバージョン番号を有する、提供することと
    ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記１つ以上のデータインスタンスについて改変されたパラメータグループを適用させることであって、前記改変されたパラメータグループは第２のバージョン番号を有し、前記ユーザは、前記データインスタンスのうちの少なくとも１つを生成する前に、前記１つ以上のデータインスタンスのうちの任意のものに対するパラメータ値を改変することができるか、または、前記１つ以上のデータインスタンスのうちの任意のものが前記データベース環境上で実行しているのと同時に、前記１つ以上のデータインスタンスのうちの任意のものに対するパラメータ値を改変することができる、適用させることと、
    をさせることを特徴とするシステム。
11. 前記パラメータ値が動的値である場合、前記改変されたパラメータグループの更新されたパラメータ値が実質的に前記要求時において前記実行しているデータインスタンスに適用され、
    前記パラメータ値が静的値である場合、前記データインスタンスがリブートすると前記パラメータ値が前記実行しているデータインスタンスに適用されることを特徴とする請求項１０に記載のシステム。
12. 前記命令が実行されると、前記プロセッサに、
    ウェブサービス要求が前記複数のＡＰＩのうちの１つを通して前記制御環境に受信されるのに応答して、前記実行しているデータインスタンスのうちの１つ以上をリブートさせ、これにより前記静的値を適用させることをさらにさせることを特徴とする請求項１０に記載のシステム。
13. 少なくとも１つのデータインスタンスについて前記改変されたパラメータグループを適用することは、前記改変されたパラメータグループがそこに適用するべき各データインスタンスに対する前記少なくとも１つのパラメータ値を含む、構成ファイルをインストールすることをさらに含むことを特徴とする請求項１０に記載のシステム。
14. 前記データベース環境は、複数のデータインスタンスをデータインスタンスクラス内に提供するように動作可能であり、
    前記ユーザは、前記データインスタンスクラス内の前記複数のインスタンス全てについて、単一のウェブサービス呼び出しを用いて改変されたパラメータグループを指定することがさらに可能であることを特徴とする請求項１０に記載のシステム。
15. 前記命令が実行されると、前記プロセッサに、
    前記ウェブサービス要求に応答して、前記１つ以上のデータインスタンスについて前記改変されたパラメータグループを適用させるための少なくとも１つのタスクを含むワークフローを前記制御環境内において実行させることであって、前記ワークフローは、前記１つ以上のデータインスタンスの現在のパラメータグループバージョンについての情報および前記１つ以上のデータインスタンスに適用されている何らかの変更を示す状態情報を更新するための少なくとも１つのタスクをさらに含む、実行させること、
    をさらにさせ、
    前記制御プレーンの監視コンポーネントは、前記１つ以上のデータインスタンスそれぞれについてホストマネージャと定期的に通信し、前記ホストマネージャが前記データインスタンスのうちの１つについて前記パラメータグループの現在のバージョンを更新するのに応答して、前記データインスタンスの前記現在のパラメータグループバージョンの情報および成功裏に適用された前記改変されたパラメータグループを示す状態情報を更新することを特徴とする請求項１０に記載のシステム。

Images