| Oracle® TimesTen In-Memory Database Scaleoutユーザーズ・ガイド リリース18.1 E98636-05 |
|
 前 |
 次 |
次の項では、グリッド・モードのOracle TimesTen In-Memory Database (TimesTen Scaleout)の機能とコンポーネントについて説明します。
|
ノート: クラシック・モードのOracle TimesTen In-Memory Database (TimesTen Classic)の概要は、Oracle TimesTen In-Memory Database概要のOracle TimesTen In-Memory Databaseの概要を参照してください。 |
TimesTen Scaleoutは、永続性とリカバリ可能性を備えた高可用性インメモリー・データベース内で高パフォーマンス、フォルト・トレランスおよびスケーラビリティを提供します。図1-1に示すように、TimesTen Scaleoutは、1つ以上のホストで実行されている複数のインスタンスのグリッド間でデータベースのデータを分散することによってこれらの機能を提供します。
|
ノート: TimesTen Scaleoutは物理システムまたは仮想システムをホストとして識別します。各ホストは異なるシステムを表します。TimesTen Scaleoutで各ホストの識別子として使用される名前を決定します。 |
TimesTen Scaleoutにより次のことができます。
グリッド(1つ以上のホストにインストールされた一連の相互接続されたインスタンス)を作成します。
1つ以上のインメモリー・データベース、SQLリレーショナル・データベース、ACID準拠データベースを作成します。
シェアード・ナッシング・アーキテクチャを使用して、可用性の高い方法でグリッドのインスタンスに各データベースのデータを分散します。
データベース全体のデータの分散方法に関係なく、すべてのデータへの完全なアクセス権を使用して、アプリケーションをデータベースに接続します。
データの1つ以上のコピーを保持します。データのコピーを複数保持することで、単一の障害が発生した場合にデータ損失から保護されます。
グリッドにインスタンスを追加または削除して次のことを行います。
必要に応じてデータベースの記憶域容量を拡張または縮小します。
アプリケーションのパフォーマンス要件にあわせてデータベースのコンピューティング・リソースを拡張または縮小します。
TimesTen Scaleoutには、次のような主な機能があります。
TimesTenのデータベースは、今日の企業および業界で必要とされる応答性と高スループットによってアプリケーションを強化する、メモリー最適化されたリレーショナル・データベースです。データベースは物理メモリー(RAM)に完全に適合し、標準SQLインタフェースを提供します。
TimesTenは、すべてのデータがメモリーに格納されるというナレッジを使用して設計されています。その結果、データへのアクセスがより簡単で直接的になり、コード・パスはより短く、アルゴリズムと内部データ構造はより単純になります。こうして、TimesTenは実行時にデータが存在する場所を最適化することにより、パフォーマンスを向上させます。メモリー内のデータを管理し、それに応じてデータ構造とアクセス・アルゴリズムを最適化することにより、データベース操作が最大の効率で実行され、応答性とスループットの大幅な向上を実現します。
TimesTen Scaleoutは、各データベースのデータをシェアード・ナッシング・アーキテクチャのグリッド内のインスタンスに分散することで高パフォーマンスを実現します。TimesTen Scaleoutはデータベースの作業をこれらのインスタンスにパラレルに分散し、これによりSQL文の結果がより高速に計算されます。
TimesTenのデータベースは、電源障害やクラッシュ時にも持続します。TimesTenでは、これは次のものをファイル・システムに定期的に保存することで実現されます。
チェックポイント・ファイルを介したすべてのデータ。
トランザクション・ログ・ファイルを介してトランザクションによって行われた変更。
TimesTen Scaleoutでは、データベースのデータは要素に分散されます。各要素は、独自のチェックポイントおよびトランザクション・ログ・ファイルを保持します。その結果、各要素に格納されたデータは独立して永続します。グリッド内の各インスタンスはデータベースの1つの要素を管理します。障害が発生した場合、残りのインスタンスがアプリケーションにサービスの提供を続行している間、インスタンスはその要素に格納されているデータをチェックポイントおよびトランザクション・ログ・ファイルから自動的にリカバリできます。
TimesTen Scaleoutでもデータの複数のコピーを保持し、永続性とフォルト・トレランスを向上させることができます。
パフォーマンスおよびデータ永続性のニーズに応じてデータベースの永続性設定を変更できます。たとえば、高いパフォーマンス・レベルで操作するために、データをコミットごと、または定期的にバッチでファイル・システムにフラッシュするかどうかを選択できます。
アプリケーションは、SQLおよびPL/SQLを使用してデータベースのデータにアクセスします。SQLをよく理解している開発者は、TimesTen Scaleoutを使用したアプリケーションの開発において、すぐに生産性を高めることができます。
SQLの詳細は、このガイドの第7章「TimesTen ScaleoutでのSQLの使用方法」およびOracle TimesTen In-Memory Database SQLリファレンスを参照してください。PL/SQLの詳細は、表1-9およびOracle TimesTen In-Memory Database PL/SQL開発者ガイドを参照してください。
TimesTen Scaleoutでは、データへのACID (Atomic: 原子性、Consistent: 一貫性、Isolated: 独立性、Durable: 永続性)アクセスを提供するトランザクションがサポートされています。
詳細は、このガイドの第6章「TimesTen Scaleoutでの分散トランザクションの理解」、およびOracle TimesTen In-Memory Databaseオペレーション・ガイドのトランザクション管理を参照してください。
TimesTen Scaleoutでは、データベースのデータを個別のホストに配置されている複数のインスタンスに分散し、可用性、パフォーマンス、記憶域容量、処理能力および持続性を大幅に向上させることができます。TimesTen Scaleoutは複数のインスタンスにデータベースのデータを分散する場合、それらのインスタンスを実行しているホストによって提供されるインメモリー・リソースを使用します。
TimesTen Scaleoutでは、データベースのパフォーマンスと記憶域容量の両方を制御するためにインスタンスを追加または削除できます。インスタンスを追加すると、データベースのメモリー容量が拡張します。また、これらのインスタンスを実行しているホストの追加のコンピューティング・リソースが提供されることで、ワークロードのスループットが向上します。ビジネス・ニーズが変化した場合、インスタンス(およびそのホスト)を削除して、少ないリソースでターゲットを満たすことができます。
TimesTen Scaleoutは複数のインスタンスにデータを分散し、アプリケーションはデータの分散方法を認識する必要はありません。アプリケーションはグリッド内のいずれかのインスタンスに接続すると、特定のデータが配置されている場所を認識しなくても、データベースのすべてのデータにアクセスできます。
TimesTen Scaleoutではデータの分散に関する知識は必要ありませんが、この知識を使用してアプリケーションのパフォーマンスをチューニングできます。可能な場合は、この知識を使用して場所を利用できます。詳細は、疑似列の使用方法を参照してください。
TimesTen Scaleoutは、ネットワークの混雑など、ほとんどの一時的な障害から自動的にリカバリします。TimesTen Scaleoutは、チェックポイントおよびトランザクション・ログ・ファイルからリカバリすることによって、ソフトウェア障害からリカバリします。ハードウェア障害などの永続的な障害は、ユーザーによる操作を必要とすることがあります。
個別のホストにデータのコピーが複数ある場合、TimesTen Scaleoutは高可用性とフォルト・トレランスを提供します。TimesTen ScaleoutにはK-safety (k)という機能が用意されており、グリッドの作成時にkに対して設定した値によって、グリッドに存在するデータのコピー数が定義されます。この機能により、データベースはデータの1つのコピーがアクセス可能であるかぎり、様々な障害が発生した場合にも稼働し続けることができます。
データの1つのコピーのみを作成する場合は、kを1に設定します。この設定は本番環境ではお薦めしません。
データのコピーを2つ作成するには、kを2に設定します。この設定では、グリッドをフォルト・トレラントにすることができます。そのため、1つのコピーが失敗した場合、データの別のコピーが存在します。データの安全性を最大限確保するために、個別の物理ハードウェアにデータの各コピーを配置します。
TimesTen Scaleoutは、ソフトウェアとハードウェアの両方にフォルト・トレランスを提供します。
ソフトウェアの障害は、多くの場合一時的なものです。ソフトウェアのエラーによりデータのコピーの1つが使用できない場合は、データの他のコピーにSQL文が自動的にリダイレクトされます(可能な場合)。その間、TimesTen Scaleoutは障害が発生したシステムのデータをデータベースの残りの部分と同期します。TimesTen Scaleoutでは、インスタンスが実行中であれば、ユーザーが操作してリカバリする必要はありません。
ハードウェア障害は、最終的にユーザーの操作が必要になる場合があります。場合によっては、ホストの再起動のみが必要なことがあります。
TimesTen Scaleoutは、一貫性のある方法で障害を解決するためのメンバーシップ・サービスを提供します。メンバーシップ・サービスにより、起動しているインスタンスの一貫性のあるリストが表示されます。これは、ネットワーク・エラーのためにホストが相互に通信できない2つの別々のグループに分割された場合に役立ちます。
管理アクティビティを実行するには、グリッド内のすべてのホストにログオンする必要はありません。かわりに、ttGridAdminユーティリティを使用して単一のインスタンスからすべての管理アクティビティを実行します。ttGridAdminユーティリティは、各データベースのステータスを定義、デプロイおよび確認するために使用する主要なユーティリティです。
また、ttGridRolloutユーティリティまたはOracle SQL Developer GUI (どちらもすべてのリクエストを実行するために背後でttGridAdminユーティリティを使用)を使用して、グリッドの作成、デプロイおよび管理を容易にすることもできます。
グリッドを初めて作成する場合は、ttGridRolloutユーティリティを使用してグリッドを定義およびデプロイできます。作成後、ttGridAdminユーティリティまたはOracle SQL Developerを使用してグリッドを管理します。
Oracle SQL Developer (グリッドとそのコンポーネントを作成、管理および検索する便利な方法をデータベース開発者に提供するグラフィカル・ユーザー・インタフェース(GUI)ツール)を使用してグリッドを作成および管理できます。また、特定のデータベース・オブジェクトの参照、作成、編集および削除、SQL文とスクリプトの実行、データの操作およびエクスポート、レポートの表示および作成を行うこともできます。詳細は、Oracle SQL Developer Oracle TimesTen In-Memory Databaseサポート・ユーザーズ・ガイドを参照してください。
1人のOSユーザーがグリッドを作成および管理します。このユーザーはインスタンス管理者と呼ばれます。インスタンス管理者の詳細は、『Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイド』のインスタンス管理者に関する項を参照してください。TimesTen Scaleoutでは、インスタンス管理者は次のことができます。
K-safetyを使用してグリッドでデータの1つまたは2つのコピーを作成するかどうかを構成します。
グリッドの管理に使用する1つまたは2つの管理インスタンスを作成します。
データを格納および管理する複数のデータ・インスタンスを作成します。
任意の時点で操作可能なデータ・インスタンスを追跡するメンバーシップ・サービスを設定します。メンバーシップ・サービスは3つ以上のメンバーシップ・サーバーで構成されます。
1つ以上のデータベースを作成します。
データベースのバックアップを格納する1つ以上のリポジトリを作成します。
データベースは複数の要素で構成され、各要素にそのデータベースのデータの一部が格納されます。各データ・インスタンスに各データベースの1つの要素が含まれます。グリッドに複数のデータベースを作成した場合、各データ・インスタンスに複数の要素(各データベースから1つ)が含まれます。
作成するデータベースごとに、データ分散に含める要素を決定します。通常、すべての要素を含めますが、新規データ・インスタンスをオンラインにした場合、これらの新規データ・インスタンスの要素をいつからデータベース操作に含めるかを決定します。データベース操作に要素を含めるには、データベースの分散マップに要素を明示的に追加する必要があります。同様に、グリッドからデータ・インスタンスを削除するには、分散マップから要素を削除する必要があります(これにより、要素はデータベース操作に含まれなくなります)。
要素を分散マップに含めると、データベースの各要素は自動的にレプリカ・セットに配置されます。各レプリカ・セットには、K-safetyに設定された値と同じ数の要素が含まれます。同じレプリカ・セット内の要素は、同じデータを保持します。
次の項では、これらのコンポーネントとグリッド内でのその役割について詳しく説明します。
グリッドでは、インスタンスを使用してデータの1つ以上のコピーを管理、追加および分散します。インスタンスは、TimesTenソフトウェアの実行中のコピーです。ホストにインスタンスを作成する場合は、TimesTenインストールに関連付けます。インストールは、単一のインスタンスで使用するか、複数のインスタンスで共有できます。各インスタンスは、通常、最大のデータ可用性を提供するため、および1つのホストに障害が発生した場合のデータ損失に対する予防手段として、独自のホストに存在します。
各インスタンスには、関連付けられているインスタンス管理者(インスタンスの作成者)およびインスタンス・ホームがあります。インスタンス・ホームは、ホスト上の場所です。同じインスタンス管理者が、グリッド内のすべてのインスタンスを管理します。
TimesTen Scaleoutは、次の2タイプのインスタンスをサポートしています。
管理インスタンスはグリッドを制御し、グリッドの中央構成であるモデルを維持します。管理者がグリッドを容易に管理できるようにするために、すべての管理アクティビティはttGridAdminユーティリティを使用して単一の管理インスタンスを介して実行します。
TimesTen Scaleoutでは2つの管理インスタンスを作成できるため、高可用性を実現し、単一の管理インスタンスの障害によってグリッド管理が妨げられることを回避できます。本番環境のベスト・プラクティスとして、2つの管理インスタンスを作成することを検討してください。作成後、TimesTen Scaleoutは両方の管理インスタンスをアクティブ・スタンバイ構成で構成します。すべての管理操作は、常にアクティブ管理インスタンスを使用して実行します。スタンバイ管理インスタンスは、アクティブ管理インスタンスの障害に対する保護対策としてのみ存在します。
図1-3に示すように2つの管理インスタンスを作成する場合、アクティブ管理インスタンスで使用されるすべての情報はスタンバイ管理インスタンスに自動的にレプリケートされます。つまり、アクティブ管理インスタンスに障害が発生した場合は、スタンバイ管理インスタンスを新しいアクティブ管理インスタンスに昇格させ、これを使用してグリッドの管理を続行できます。
次のことを考慮してください。
スタンバイ管理インスタンスなしで単一の管理インスタンスからグリッドを管理できます。ただし、これは本番環境ではお薦めしません。
両方の管理インスタンスに障害が発生した場合、グリッド内のデータベースは動作を継続します。少なくとも1つの管理インスタンスを再起動するまで、一部の管理操作は行えません。
データ・インスタンスはグリッド内のデータベースごとに1つの要素を格納します。データ・インスタンスは、SQL文およびPL/SQLブロックを実行します。グリッドは各データベース内のデータをデータ・インスタンス間で分散します。図1-4に示すように、すべてのデータ・インスタンスはアクティブ管理インスタンスで管理します。
インスタンスを操作するには、TimesTenディストリビューションのインストールが必要です。インストールは読取り専用であり、ローカルで使用することも、複数のインスタンスで共有することもできます。管理インスタンスのホストとして定義されているシステム上の指定した場所にTimesTenディストリビューションを抽出することによって、初期管理インスタンスのインストールを作成します。TimesTen Scaleoutは、グリッド内の他のホストで後続のインストールをローカルに作成し、それらのホストで実行されるインスタンスに新規インストールを関連付けることができます。同じホスト上で実行されるすべてのインスタンスは同じインストールを共有できます。
インストールに複数のホストがアクセスできるかぎり、そのインストールはそれらのホストのインスタンスで共有できます。ただし、NFSなどの共有ファイル・サーバーのインストールを個別のホスト上の複数のインスタンス間で共有する場合、可用性が低下する可能性があります。共有ネットワーク・ストレージまたはすべてのホストをNFSサーバーに接続するネットワークに障害が発生したり、パフォーマンスの問題が発生した場合、そのインストールを共有するすべてのインスタンスが影響を受けます。そのため、共有ファイル・サーバーのインストールをインスタンス間で共有することは開発環境の有効なオプションですが、本番環境に適切かどうかを評価してください。
グリッド内の各データベースのデータのコピーを1つまたは複数作成するようにグリッドを構成します。TimesTen ScaleoutはK-safety (k)の実装を使用して、データの1つまたは複数のコピーを管理します。グリッドの作成時に、kを1または2に設定することでデータのコピー数を指定します。
グリッドでデータのコピーを2つ作成し個別のホストに配置することを指定した場合、データの可用性とフォルト・トレランスが向上します。
kを1に設定した場合、TimesTen Scaleoutはデータの単一のコピーを保存します(本番環境にはお薦めしません)。
kを1に設定した場合は、1つ以上の要素が失敗した場合に次のことが発生する可能性があります。
要素に含まれるすべてのデータは、要素がリカバリするまで使用できません。
要素がリカバリされない場合、要素に含まれているデータは失われます。
データのコピーが1つのみの場合にも、容量およびデータのアクセシビリティを向上させるためにデータは別の要素に分散されます。
kを2に設定した場合、TimesTen Scaleoutはデータのコピーを2つ保存します。データのコピーが2つある場合、グリッドは複数の障害を許容できます。
1つの要素が失敗した場合、データの2番目のコピーにアクセスし、リクエストされたデータを提供します。K-safetyにより、データのコピーのいずれかが使用可能であれば、データの可用性が実現します。可能な場合は、最大のデータの安全を確保するため、データの各コピーを異なる物理ハードウェアに配置します。
次の項では、複数のコピーを管理および編成する方法について説明します。
データベースの各要素は、kの値に応じてレプリカ・セットに自動的に配置されます。
kを1に設定した場合、各レプリカ・セットには1つの要素が含まれます。
kを2に設定した場合、各レプリカ・セットには2つの要素が含まれます(各要素は、レプリカ・セット内のもう1つの要素の正確なコピーです)。
このため、各レプリカ・セットにはkに設定された値と同じ数の要素が含まれます。
kを2に設定した場合、レプリカ・セット内の両方の要素で常にデータの一貫性を保つために、1つの要素のデータに加えられた変更は、レプリカ・セット内のもう1つの要素にも加えられます。TimesTen Scaleoutの透過性機能により、リクエストされたデータがその要素に含まれていない場合や、リクエストされたデータが複数のレプリカ・セットにまたがる場合でも、任意の要素でトランザクションを開始できます。要素に障害が発生した場合は、レプリカ・セット内の他の要素にアクセスして、リクエストされたデータを提供します。各レプリカ・セット内の1つの要素が機能しているかぎり、データベース内のすべてのデータを使用できます。
各データベースは要素のセットで構成され、各要素にそのデータベースのデータの一部が格納されます。グリッドは各データベースの要素をデータ領域に編成します。
各データベースは、1つまたは2つのデータ領域で構成されます。kを2に設定した場合、各レプリカ・セット内の要素は別のデータ領域に割り当てられます。
図1-5に、2つのデータ領域内でデータの2つのコピーが編成される方法を示します。各データ領域には、データベースのデータの1つのコピーを構成する要素が含まれています。データ領域1に1つのコピーが格納されており、データ領域2に2番目のコピーが含まれています。3つのレプリカ・セットがあり、各レプリカ・セットの要素は別のデータ領域に割り当てられています。このため、データ領域1の各要素は、データ領域2のそのパートナ要素と同じになります。
ニーズが拡大または減少するにつれて、レプリカ・セットをグリッドに追加または削除できます。データ・インスタンスを追加すると、グリッドに各データベースの要素が自動的に作成されます。ただし、データ・インスタンスを追加または削除した場合、データは自動的に再分散されません。レプリカ・セットに要素を割り当て、各データ領域のすべての要素にデータを再分散する適切なタイミングを決定します。
グリッドの物理組織を表すデータ領域グループにホストを割り当てることによって、データを物理的に配置する方法を決定します。データ領域の理解で説明したように、データのコピーはデータ領域に論理的に編成されます。各データ領域は個別の物理リソースを使用する必要があります。共有物理リソースには、類似のラック、同じ電源または同じ記憶域を含めることができます。1つのレプリカ・セット内のすべての要素が物理コンポーネントを共有するホストに格納されている場合、その共有物理コンポーネントに障害が発生した場合、そのレプリカ・セットに格納されているデータは使用できなくなることに注意してください。
TimesTen Scaleoutでは、データ・インスタンスを実行するすべてのホストをデータ領域グループに割り当てる必要があります。K-safetyを使用する場合、データのk個のコピーおよび(1からkの番号が付けられた)同じ数のデータ領域グループが存在します。同じ物理リソースを共有するホストは同じデータ領域グループに割り当てる必要があります。同じデータ領域グループに割り当てられたホスト上で実行されるデータ・インスタンスの要素は、同じデータ領域にあります。各データ領域には、データベース内のすべてのデータの完全コピーが含まれています。
1つのデータ領域グループ内のホストが別のデータ領域グループ内のホストとリソースを物理的に共有しないようにする場合、別のデータ領域グループ内のホストに同時に障害が発生する可能性が低くなります。このシナリオでは、単一のハードウェア障害によって複数のホストが停止した場合にも、データベース内のすべてのデータが使用可能である可能性が高くなります。たとえば、1つのデータ領域グループ内のすべてのホストを、別のデータ領域グループ内のホストの電源と別の電源に接続するようにできます。その場合は、1つのプラグを抜いても、1つのレプリカ・セット内の両方のホストの電源が切断されて一部のデータが使用できなくなることはありません。
図1-6に、kを2に設定して構成され、2つのデータ領域グループが含まれるグリッドを示します。それぞれ2つの電源と3つのホストを含む2つのラックがあります。3つのホストは各データ領域グループに割り当てられています。TimesTen Scaleoutは、各レプリカ・セット内の1つの要素が各データ領域グループに含まれるようなレプリカ・セットを作成します。
ホストをデータ領域グループに割り当てるプロセスには、データ領域をサポートするホストを物理的に分離する方法の決定が含まれます。
グリッドの物理トポロジが単純な場合は、各ホストを各データ領域グループに自分で割り当てることができます。
グリッドの物理トポロジが複雑な場合、TimesTen Scaleoutは、物理グループを使用することによってこれらのホスト間で共有される物理リソースに基づいて、各ホストの適切なデータ領域グループを推奨できます。
構成が複雑で、物理的な依存関係を分析することによって複数のホストを個別のデータ領域グループに割り当てることが困難になる場合は、TimesTen Scaleoutにホストをデータ領域グループに割り当てる方法を推奨するよう指示できます。これを実行するには、TimesTen Scaleoutは、ホストが同じ場所に配置されている場所の物理トポロジまたは同じリソースを使用するホストを認識する必要があります。物理グループを使用して、各ホストがその物理的な依存関係で識別されるグリッドの物理トポロジを記述できます。物理グループは、どのホストが同じ物理リソースを共有しているかをTimesTen Scaleoutに示します。同じ物理グループにグループ化されているホストは同時に障害が発生する可能性があります。
|
ノート: 物理グループ内のホストの関連付けはオプションです。 |
たとえば、次の場合、複数のホストをグループ化できます。
同じ電源を使用する。
複数の棚で構成される同じラックに配置されている。
同じ棚に配置されている。
すべてのホストが物理グループに割り当てられると、TimesTen Scaleoutは、リスクを最小限に抑えるためにどのホストを各データ領域グループに割り当てる必要があるかを示すことができます。物理グループへのホストの割当ての詳細は、グリッドの物理トポグラフィの説明を参照してください。
グリッド内に1つ以上のデータベースを作成できます。各データベースは独立し、個別のユーザー、スキーマ、表、永続性およびデータ分散を保有します。TimesTen Scaleoutは、定義された分散マップおよび各表の分散スキームに従ってデータの分散を管理します。
任意のデータベースの要素とレプリカ・セットの最大数を指定する、グリッドのデータ・インスタンスの数を決定します。各データ・インスタンスは、グリッド内の各データベースの1つの要素をホストします。そのため、グリッド内のデータ・インスタンスは1つ以上のデータベースを同時に管理できます。グリッドに複数のデータベースを作成した場合、各データ・インスタンスに複数の要素(各データベースから1つの要素)が含まれます。
各データベースは複数のレプリカのセットで構成され、各レプリカ・セットにそのデータベースのデータの一部が格納されます。使用可能なデータ・インスタンスのどの要素にデータベースのデータを格納するかを分散マップで定義します。分散マップが定義され適用された後、TimesTen Scaleoutが各要素をレプリカ・セットに自動的に割り当て、データを対応するレプリカ・セットに分散すると、各要素は別のレプリカ・セットの他の要素と通信し、単一のデータベース・イメージを提供します。データが分散される方法の詳細は、表の分散スキームに基づいてデータベースの表ごとに異なる場合があります。
|
ノート: TimesTen Scaleoutでは、ttGridAdminユーティリティによって管理されるパーティション表に、分散マップの構成、またはすべてのデータ・インスタンスがどのように相互に関連付けられているかが格納されます。 |
各データベースのデータを管理および格納するデータ・インスタンスの要素を分散マップに追加した後、データを結果のレプリカ・セットに分散することを明示的に要求できます。
ビジネスのニーズが変化するにつれて、グリッド内のレプリカ・セットの数を増やすことでデータベースの容量を増やすことができます。これを実現するには、次の手順を実行します。
グリッドに新しいホストを追加します。追加するホストの数は、追加するレプリカ・セットの数およびK-safetyの値に比例する必要があります。たとえば、kが2に設定されたグリッド内のデータベースに別のレプリカ・セットを追加する場合は、データ領域グループ1のホストおよびデータ領域グループ2の別のホストを追加する必要があります。
各新規ホストにデータ・インスタンスをサポートするインストールを作成します。
各新規ホストにデータ・インスタンスを作成します。
容量を増加する各データベースの分散マップに新規データ・インスタンスの要素を追加します。TimesTen Scaleoutにより、適切な新規レプリカ・セットが自動的に作成されます。
すべてのレプリカ・セットにデータを再分散します。
グリッドに新規データ・インスタンスを追加したり、既存のデータ・インスタンスを削除した場合、グリッドはデータベースに格納されているデータをそれらの新規または残りのデータ・インスタンスのレプリカ・セットに自動的に再分散しません。かわりに、既存のデータ・インスタンスにデータを再分散する適切なタイミングをユーザーが決定します。再分散は、稼働中のデータベースに悪影響を与えることがあります。影響を最小限に抑えるために、小さい増分で再分散する必要があります。ユーザーが保有するデータ・インスタンスの数が多いほど、1つのレプリカ・セットを漸増的に追加または削除する影響は小さくなります。
データ・インスタンスを同じデータ領域グループ内の新規データ・インスタンスに置換する必要がある場合は、この処理ですべてのデータを再分散する必要はありません。
容量を減らすには、レプリカ・セットを管理するデータインスタンスを分散マップから削除し、グリッド内の残りのデータのインスタンスにデータを再分散します。
TimesTen Scaleoutはレプリカ・セットにデータベース内のデータを分散します。データベース内のすべての表は各レプリカ・セットに存在します。データベース内の各表の分散スキームはCREATE TABLE文で定義します。分散スキームでは、表の行をグリッド間で分散する方法を説明します。
データを分散する方法は、表の作成時に指定する次のいずれかの分散スキームで定義します。
ハッシュ: データは主キーのハッシュまたはユーザーが指定した複数の列の複合に基づいて分散されます。指定された行がグリッドによって選択されたレプリカ・セットに含まれます。行はレプリカ・セット間で均一に分散されます。これは、大部分の表に適しているため、デフォルトの方法です。
図1-7に、ハッシュ分散スキームを使用した表terry.customersの例を示します。各要素は異なるレプリカ・セットに属します。
参照: 外部キーによって識別された親表の場所に基づいて子表のデータを分散します。つまり、子表の指定した行が親表と同じレプリカ・セットに存在します。この分散スキームは、1つのレプリカ・セット内の関連データを分散することで、結合のパフォーマンスを最適化します。多くの場合、親表と子表は問合せで同時に参照されるため、この分散スキームは1つの親表の論理的な子である表に適しています。
図1-8に、親表customersへの参照分散スキームを使用した子表accountsの例を示します。各要素は異なるレプリカ・セットに属します。
複製: データの完全な同一コピーをデータベースのすべての要素に分散します。つまり、すべての行は各要素に存在します。この分散スキームは、各データ・インスタンスに同一データを格納することで、読取りのパフォーマンスを最適化します。この分散スキームは、比較的小さい、頻繁に読み取られる、変更頻度の低い表に適しています。
図1-9に、複製分散スキームを使用した表account_typeの例を示します。各要素は異なるレプリカ・セットに属します。
TimesTen Scaleoutでは、グリッドにデータベースのバックアップを作成して、同じグリッドまたは類似したトポロジを持つ別のグリッドにリストアできます。TimesTen Scaleoutでは、異なるトポロジを持つグリッドにデータベースをエクスポートすることもできます。リポジトリをデータベースのバックアップ、エクスポートおよびログ・ファイルのコレクションの場所として定義します。複数のグリッドで同じリポジトリを使用できます。
ほとんどの本番環境で、TimesTen Scaleoutには1つのプライベート内部ネットワークと1つ以上の外部ネットワークが必要です。
内部ネットワーク: グリッド内のインスタンスは、TCPプロトコルを使用して単一の内部ネットワーク経由で相互に通信します。さらに、インスタンスはこのネットワークを介してメンバーシップ・サーバーと通信します。メンバーシップ・サーバー間は、このネットワークを使用して通信します。
外部ネットワーク: アプリケーションは外部ネットワークを使用してデータ・インスタンスに接続してデータベースにアクセスします。アプリケーションには、管理インスタンスまたはメンバーシップ・サーバーへの外部ネットワーク・アクセスは必要ありません。
詳細は、ネットワーク要件を参照してください。
TimesTen Scaleoutでは、グリッドの単一の中央構成が保持されます。この構成は、モデルと呼ばれます。モデルは、グリッドの論理トポロジを表します。モデルには、グリッドのコンポーネント(インストール、ホスト、データベース定義、インスタンスなど)を表す一連のオブジェクトが含まれています。
複数のバージョンのモデルを持つことができます。モデルに変更を適用するたびに、グリッドにモデルがバージョンとして保存されます。グリッドでは、常に1つのバージョンのみをアクティブにできます。
最新モデルは、変更を加えている、まだ適用されていないモデルです。モデルを変更中の場合、このバージョンは将来の目的のグリッド構造を表し、適用後は現在のモデルになります。
モデルの現在のバージョン(最後に適用されたモデル)は、常にグリッドの現在の構造を表します。
以前のモデルのバージョンは、過去のグリッド構造を表します。
グリッドの目的の構造を作成するには、次の手順を実行します。
最新モデルにグリッド・コンポーネント(インストール、ホスト、インスタンスなど)を追加または削除することによって、目的のグリッド構造を設計します。
目的のモデル構造が完成したら、これらの変更を有効にするためにモデルを適用します。モデルのこのバージョンがモデルの現在のバージョンになります。
モデルの適用後、TimesTen Scaleoutは稼働中のグリッドで現在のモデルの実装を試行します。
現在のモデルのすべてのコンポーネントが実行されているとはかぎりません。たとえば、グリッドに10のホストを構成し、そのうちの6つのみがその時点で実行されている場合でも、10の定義はすべてモデルに存在します。
ttGridAdminユーティリティを使用してグリッド・コンポーネント(インストール、ホスト、インスタンスなど)を追加するたびに、これらのグリッド・コンポーネントに対応するモデル・オブジェクトがモデルに追加されます。各モデル・オブジェクトではグリッド・コンポーネントの属性および関係が指定されます。
一部のモデル・オブジェクトには他のオブジェクトへの関係があります。図1-10に、モデル・オブジェクト間で関係が格納される方法を示します。つまり、ホスト、インストールおよびインスタンスには、次の関係があります。
インストール・モデル・オブジェクトは、インストールされているホスト・モデル・オブジェクトを指します。
管理インスタンス・モデル・オブジェクトとデータ・インスタンス・モデル・オブジェクトの両方は、インスタンスが使用するインストールのインストール・モデル・オブジェクトおよびインスタンスがインストールされているホスト・モデル・オブジェクトを指します。
図1-10に、モデル内に格納されているホスト、インストールおよびインスタンス間の2つの異なるタイプの関係を示します。
1つのデータ・インスタンスを含むホストに単一のインストールをインストールします。データ・インスタンスはインストール、およびそのデータ・インスタンスが存在するホストを指します。
単一のホストに複数のデータ・インスタンスを作成し、すべてのデータ・インスタンスは単一のインストールを共有します。各データ・インスタンスは、同じホストおよび同じインストールを指します。インストールは、インストールされているホストを指します。可用性を高めるには、1つのホスト上で複数のデータ・インスタンスを使用しないでください。
モデルにモデル・オブジェクトを追加または削除する場合、これらの変更は、明示的に適用されるまで、ただちにグリッドに影響を与えることはありません。変更の適用後、TimesTen Scaleoutは稼働中のグリッドに現在のモデルを実装します。たとえば、モデルの最新バージョンに新規インストール・モデル・オブジェクトとデータ・インスタンス・モデル・オブジェクトを追加する場合、モデルに変更を適用すると、そのホストでインストールとデータ・インスタンスの両方を作成および初期化するために必要なすべての操作が実行されます。
TimesTen Scaleoutでグリッドとデータベースを構成する前に、グリッドを作成するために必要な情報を収集します。
次の考慮事項に基づいて、使用するホストおよびメンバーシップ・サーバーの数を決定する必要があります。
メンバーシップ・サーバー: 本番環境では、1つ以上のメンバーシップ・サーバーに障害が発生した場合に過半数の定数を確保するために、3つ以上の奇数個のメンバーシップ・サーバーが必要です。次のことを確認する必要があります。
各メンバーシップ・サーバーは相互に独立した物理リソース(電力、ネットワーク・ノード、記憶域など)を使用します。
メンバーシップ・サーバーはデータ・インスタンスを含むホストと同じシステム上で実行されていません。
管理インスタンス: グリッドの構成機能と管理機能に対する可用性の方法を複数確保するために、2つの管理インスタンスが必要です。管理インスタンスを含むホストで相互に独立した物理リソース(電力、ネットワーク・ノード、記憶域など)が使用されることを確認します。
データ・インスタンス: K-safetyのレベルとレプリカ・セットの数に基づいて、データ・インスタンスに必要なホストの数を決定します。たとえば、kを2に設定し、3つのレプリカ・セットを使用する場合、6つのデータ・インスタンスが必要になります。
また、K-safetyのレベルによって、ホストに必要なデータ領域グループまたは独立した物理的な場所の数が決まります。データ領域グループ1に割り当てられたデータ・インスタンスを含むホストが、データ領域グループ2に割り当てられたデータ・インスタンスを含むホストの影響を受けない物理リソースを使用することを確認します。
図1-11に、3つのメンバーシップ・サーバー、1つのリポジトリ、2つの管理インスタンスおよび6つのデータ・インスタンスの設定の例を示します。この例では、合計11のホストに対するリポジトリを含むメンバーシップ・サーバーが同じ場所に配置されます。
図1-12に、この例のデータ・インスタンスを含むホストが、kを2に設定されたグリッドの2つのデータ領域グループに編成される方法を示します。各データ領域グループのホストはラックを共有します。
データ・インスタンスを含むホストを、共有する物理リソースに基づいてデータ領域グループに割り当てる方法の例は、表1-1を参照してください。
表1-1 システムおよびそのロール
| ホスト名 | メンバーシップ・サーバー | リポジトリ | 管理インスタンス | データ・インスタンス | データ領域グループ | 物理リソース |
|---|---|---|---|---|---|---|
|
ms_host1 |
あり |
あり |
該当なし |
該当なし |
該当なし |
ラック1 |
|
ms_host2 |
あり |
該当なし |
該当なし |
該当なし |
該当なし |
ラック2 |
|
ms_host3 |
あり |
該当なし |
該当なし |
該当なし |
該当なし |
ラック2 |
|
host1 |
該当なし |
該当なし |
あり |
該当なし |
該当なし |
ラック1 |
|
host2 |
該当なし |
該当なし |
あり |
該当なし |
該当なし |
ラック2 |
|
host3 |
該当なし |
該当なし |
該当なし |
あり |
1 |
ラック1 |
|
host4 |
該当なし |
該当なし |
該当なし |
あり |
2 |
ラック2 |
|
host5 |
該当なし |
該当なし |
該当なし |
あり |
1 |
ラック1 |
|
host6 |
該当なし |
該当なし |
該当なし |
あり |
2 |
ラック2 |
|
host7 |
該当なし |
該当なし |
該当なし |
あり |
1 |
ラック1 |
|
host8 |
該当なし |
該当なし |
該当なし |
あり |
2 |
ラック2 |
各ホストおよびメンバーシップ・サーバーが使用すると予想されるネットワーク・アドレスおよびTCP/IPポートを確認します。グリッドで内部および外部ネットワークを使用する方法の詳細は、ネットワーク要件を参照してください。
表1-1で説明したトポロジの内部および外部アドレスの例は、表1-2を参照してください。
表1-2 内部および外部アドレス
| ホスト名 | 内部アドレス | 外部アドレス |
|---|---|---|
|
ms_host1 |
|
該当なし |
|
ms_host2 |
|
該当なし |
|
ms_host3 |
|
該当なし |
|
host1 |
|
該当なし |
|
host2 |
|
該当なし |
|
host3 |
|
|
|
host4 |
|
|
|
host5 |
|
|
|
host6 |
|
|
|
host7 |
|
|
|
host8 |
|
|
特に、設定がファイアウォールの内側にある場合は、各インスタンスが使用するTCP/IPポートを考慮する必要があります。次のTCP/IPポートを定義する必要があります。
メンバーシップ・サーバー: 各メンバーシップサーバーに対して3つのポート番号(クライアント、ピア、リーダー)を定義する必要があります。これらのポート番号の詳細は、表3-1「zoo.cfg構成パラメータ」を参照してください。
管理インスタンス: 各管理インスタンスに3つのポート番号(デーモン、サーバーおよび管理)があります。指定しない場合、デーモン、サーバーおよび管理ポートのデフォルト値はTimesTen Scaleoutによって設定されます。
データ・インスタンス: 各データ・インスタンスに2つのポート番号(デーモンおよびサーバー)があります。指定しない場合、デーモンおよびサーバー・ポートのデフォルト値はTimesTen Scaleoutによって設定されます。
ファイアウォールで保護されている場合は、各インスタンスに割り当てられたサーバー・ポートを除き、前述のすべてのポートとローカル・エフェメラル・ポートを内部ネットワークに対してオープンする必要があります。各インスタンスに割り当てられたサーバー・ポートは、外部ネットワークに対してオープンする必要があります。
各メンバーシップ・サーバーまたはインスタンスに割り当てられたTCP/IPポートの例は、表1-3を参照してください。この例では、各ポートのデフォルト値を使用します。
表1-3 TCP/IPポート
| ホスト名 | メンバーシップ・サーバー(クライアント/ピア/リーダー) | 管理インスタンス(デーモン/サーバー/管理) | データ・インスタンス(デーモン/サーバー) |
|---|---|---|---|
|
ms_host1 |
2181 / 2888 / 3888 |
該当なし |
該当なし |
|
ms_host2 |
2181 / 2888 / 3888 |
該当なし |
該当なし |
|
ms_host3 |
2181 / 2888 / 3888 |
該当なし |
該当なし |
|
host1 |
該当なし |
6624 / 6625 / 3754 |
該当なし |
|
host2 |
該当なし |
6624 / 6625 / 3754 |
該当なし |
|
host3 |
該当なし |
該当なし |
6624 / 6625 |
|
host4 |
該当なし |
該当なし |
6624 / 6625 |
|
host5 |
該当なし |
該当なし |
6624 / 6625 |
|
host6 |
該当なし |
該当なし |
6624 / 6625 |
|
host7 |
該当なし |
該当なし |
6624 / 6625 |
|
host8 |
該当なし |
該当なし |
6624 / 6625 |
グリッドが使用すると予想されるインストール・ディレクトリおよびインスタンス・ホームの場所を定義する必要があります。これらのグリッド・オブジェクトの場所を定義する場合、TimesTen Scaleoutがこれらの識別に使用する名前を定義する必要があります。これらの場所を定義するときは、次の点を考慮してください。
インスタンス・ホームの場合、TimesTen Scaleoutは定義された場所にインスタンス名を追加します。たとえば、instance1という名前のインスタンスの場所として/gridを定義した場合、そのインスタンスのインスタンス・ホームのフル・パスは/grid/instance1になります。
同様の動作がインストール・オブジェクトに適用されます。インストール名を追加するかわりに、TimesTen Scaleoutは定義された場所にリリース・バージョンを追加します。たとえば、インストールの場所として/gridを定義した場合、インストールのフル・パスは/grid/tt18.1.4.1.0になります。
インストール・ディレクトリとインスタンス・ホームに対して定義した場所がまだ存在しない場合は、TimesTen Scaleoutによって作成されます。
メンバーシップ・サーバー・インストール場所の例は、表1-4を参照してください。メンバーシップ・サーバーをインストールする前に、それぞれのシステム上に次の場所を作成する必要があります。
表1-4 メンバーシップ・サーバーのインストール
| ホスト名 | インストール場所 |
|---|---|
|
ms_host1 |
|
|
ms_host2 |
|
|
ms_host3 |
|
管理インスタンスのインストール・ディレクトリおよびインスタンス・ホームの場所の例は、表1-5を参照してください。
表1-5 管理インスタンスのインストール・ディレクトリおよびインスタンス・ホーム
| ホスト名 | インストール名 | インストール・ディレクトリ | インスタンス名 | インスタンス・ホーム |
|---|---|---|---|---|
|
host1 |
installation1 |
|
instance1 |
|
|
host2 |
installation1 |
|
instance1 |
|
データ・インスタンスのインストール・ディレクトリおよびインスタンス・ホームの場所の例は、表1-6を参照してください。
表1-6 データ・インスタンスのインストール・ディレクトリおよびインスタンス・ホーム
| ホスト名 | インストール名 | インストール・ディレクトリ | インスタンス名 | インスタンス・ホーム |
|---|---|---|---|---|
|
host3 |
installation1 |
|
instance1 |
|
|
host4 |
installation1 |
|
instance1 |
|
|
host5 |
installation1 |
|
instance1 |
|
|
host6 |
installation1 |
|
instance1 |
|
|
host7 |
installation1 |
|
instance1 |
|
|
host8 |
installation1 |
|
instance1 |
|
リポジトリの場所の例は、表1-7を参照してください。
グリッドのデプロイを開始する前に、必要なすべての情報が揃っていることを確認するには、表1-8に示されている質問に答えます。
表1-8 質問リスト
| 質問 | 情報のソース |
|---|---|
|
K-safetyの設定はどうなりますか。 |
|
|
使用するメンバーシップ・サーバー数はいくつですか。 |
|
|
使用する管理インスタンス数はいくつですか。 |
|
|
使用するレプリカ・セット数はいくつですか。 |
|
|
データベースのバックアップはどこに格納しますか。 |
|
|
グリッドに使用するホストの数はいくつですか。 |
|
|
どのホストが管理インスタンスを実行しますか。 |
|
|
どのホストがデータ・インスタンスを実行しますか。 |
|
|
データ・インスタンスを含む各ホストのデータ領域グループの割当てはどうなりますか。 |
|
|
独立した物理リソース間でホストとメンバーシップ・サーバーをどのように編成しますか。 |
|
|
グリッドに単一ネットワークまたは個別の内部ネットワークと外部ネットワークのどちらを使用しますか。 |
|
|
各ホストおよびメンバーシップ・サーバーのDNS名またはIPアドレスは何ですか。 |
各ホストおよびメンバーシップ・サーバーのネットワーク・パラメータの定義 |
|
各インスタンスにどのTCP/IPポートを使用しますか。 |
各ホストおよびメンバーシップ・サーバーのネットワーク・パラメータの定義 |
|
各メンバーシップ・サーバーのインストール・ファイルの場所はどこですか。 |
各インスタンスのインストール・ディレクトリおよびインスタンス・ホームの場所の定義 |
|
各インスタンスのインストール・ディレクトリおよびインスタンス・ホームの場所はどこですか。 |
各インスタンスのインストール・ディレクトリおよびインスタンス・ホームの場所の定義 |
データ・インスタンスからの直接接続または外部ネットワークを介したクライアント/サーバー接続を使用してデータベースにアクセスできます。
直接接続: アプリケーションは指定されたデータベースのデータ・インスタンスに直接接続します。
直接接続を使用するアプリケーションは、データベースと同じシステム上で実行されます。どのようなタイプのプロセス間通信(IPC)も必要ないため、直接接続では非常に高速なパフォーマンスが実現されます。ただし、指定されたデータ・インスタンスが停止した場合、接続は別のデータ・インスタンスには転送されず、エラーが返されます。
クライアント/サーバー接続: クライアント/サーバー接続を使用するアプリケーションは、データ・インスタンスまたは外部ネットワークへのアクセス権を持ついずれかのホストで実行されます。クライアント・アプリケーションは自動的に実行中のデータ・インスタンスに接続されます。
クライアントとサーバー間のすべての送受信は、TCP/IP接続で行われます。クライアントとサーバーが内部ネットワーク上の個別のホストに存在する場合、これらはソケットとTCP/IPを使用して通信します。
データ・インスタンスに障害が発生した場合、TimesTen Scaleoutは自動的に別の実行中のデータ・インスタンスに再接続します。必要な場合は、このプロセスを制御するオプションを構成できます。
|
ノート: 必要に応じて、クライアント/サーバー接続が特定のデータ・インスタンスに接続するように指定できます。 |
ワークロードでローカル要素のデータの要求のみを行う場合、直接接続はクライアント/サーバー接続より高速にアクセスできるため、アプリケーションに最適な方法です。ただし、ワークロードでアプリケーションがデータ・インスタンスをすぐに使用できるデータ・インスタンスに切り替える必要があり、複数の要素からデータを取得する場合、クライアント/サーバー接続のほうがスループットが向上する可能性があります。
TimesTen ScaleoutまたはClassicなしの、単独のTimesTenという用語は、通常、単一インスタンスと複数インスタンスの両方(TimesTenユーティリティ、リリース、ディストリビューション、インストール、データベースによって実行されるアクション、データベース内の機能に言及する場合など)に適用されます。
TimesTen Scaleoutは、グリッド・モードのTimesTen In-Memory Databaseを示します。TimesTen Scaleoutは、分散データベースを含む複数インスタンス環境です。
TimesTen Classicは、クラシック・モードのTimesTen In-Memory Databaseを示します。クラシック・モードは、以前のリリースでの単一インスタンスの環境とデータベースです。
Oracle TimesTen Application-Tier Database Cache (TimesTen Cache)製品は、TimesTen Classicの応答性をOracleデータベースのサブセットをキャッシュする機能と組み合せて、アプリケーション層でのレスポンス時間を改善します。
TimesTen Scaleoutは、TimesTen Classicのほとんどの機能をサポートしています。TimesTen Cacheの機能はサポートしていません。次のリストに、TimesTen Scaleoutではサポートされていない前述の2つの製品の機能を示します。
|
ノート: TimesTen Classicの機能の詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドを参照してください。 |
表1-9 TimesTen ScaleoutでサポートされていないTimesTen Classicの機能
| TimesTen Classicの機能 | TimesTen Scaleoutでのサポート(あり/なし) | 説明 |
|---|---|---|
|
OracleデータベースのデータをキャッシュするためのCache Connectオプション |
なし |
Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイドに記載されているいずれの機能もTimesTen Scaleoutではサポートされていません。ただし、TimesTen ScaleoutはOracle Databaseからデータをロードする機能を提供します。 |
|
レプリケーション: アクティブ・スタンバイ・ペアとクラシック・レプリケーション・スキームの両方 |
なし |
TimesTen ScaleoutのK-safety機能によってデータ保護およびフォルト・トレランスを提供できます。そのため、TimesTen Scaleoutでは、Oracle TimesTen In-Memory Databaseレプリケーション・ガイドに記載されているいずれの機能もサポートされていません。詳細は、K-safetyを参照してください。 |
|
ビットマップ索引 |
なし |
|
|
LOBサポート |
なし |
TimesTen Scaleoutでは、表のLOB列はサポートされていません。 |
|
列ベース圧縮 |
なし |
表内の列ベース圧縮 |
|
表のエージング・ポリシー |
なし |
|
|
RAMポリシー |
なし |
TimesTen Scaleoutでは、システム管理者による |
|
X/Open XA標準およびJava Transaction API (JTA) |
なし |
|
|
TimesTen Classic Transaction Log API (XLA)およびJMS/XLA Java API |
なし |
|
|
Oracle Clusterware |
なし |
|
|
索引アドバイザ |
なし |
|
|
オンライン・アップグレード |
なし |
|
|
PL/SQL |
あり |
PL/SQL無名ブロックは完全にサポートされていますが、ユーザーが作成したストアド・プロシージャ、パッケージおよび関数はサポートされません。ただし、プロシージャを呼び出し、無名ブロックからTimesTen提供のパッケージのファンクションを呼び出すことができます。 TimesTen Scaleoutでは、ファンクション、パッケージ、プロシージャを作成、変更および削除するSQL文はサポートされていません。 |
|
SQL文 |
あり |
TimesTen Scaleoutでは、次のものはサポートされていません。
TimesTen Scaleoutでは、次のものが部分的にサポートされています。
|
Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイドでは、TimesTen Scaleoutに含まれているTimesTen Classicの機能は次のように記載されています。
機能がTimesTen Classic内と同様に完全にサポートされている場合は、このマニュアル内に、その機能を説明する短い項があり、そこで他のTimesTenマニュアル(『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』、『Oracle TimesTen In-Memory Database SQLリファレンス』および『Oracle TimesTen In-Memory Databaseリファレンス』など)内の説明への相互参照が示されます。
機能が基礎として使用され、TimesTen Scaleoutの固有要件のためのサポートが追加で提供されている場合は、新しく追加されたサポートが説明され、他のTimesTenマニュアル(『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』、『Oracle TimesTen In-Memory Database SQLリファレンス』および『Oracle TimesTen In-Memory Databaseリファレンス』など)内の機能への相互参照リンクが示されます。
機能がサポートされていない場合、このマニュアルでは相互参照を示していません。
