| Oracle® TimesTen In-Memory Database Scaleoutユーザーズ・ガイド リリース18.1 E98636-05 |
|
 前 |
 次 |
この章では、TimesTen Scaleoutでデータベースを作成および構成する方法について説明します。
|
ノート:
|
データベースの作成プロセスには、次のタスクが含まれます。
データベース定義には、データベースの説明が含まれています。これにより、データベース名およびデータベースの属性が定義されます。データベース定義は、現在のバージョンのモデルに追加した後、データベースを作成するために使用できます。各データベースには、関連付けられた1つ以上の接続可能オブジェクトが含まれています。接続可能オブジェクトにより、アプリケーションからデータベースへの接続方法が指定されます。接続可能オブジェクトについては、データベースへの接続を参照してください。
データベース定義を作成するには、データベース定義ファイルが必要です。データベース定義ファイルは、ファイル名の接尾辞として.dbdefを使用する必要があります。データベース定義の名前は、データベース定義ファイルの名前から導出されます。たとえば、database1.dbdefという名前のデータベース定義ファイルでは、database1という名前のデータベース定義が作成されます。
|
ノート: データベース定義名には、データ・ソース名と同じ制限があります。詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドのTimesTenデータベースを識別するためのデータ・ソース名の指定方法を参照してください。 |
データベース定義ファイルには、そのデータベースの接続属性を指定します。データベース定義でサポートされている接続属性のタイプは、次のとおりです。
データ・ストア属性は、データベースが作成されるときにデータベースに関連付けられます。これらは、データベースを再作成することでのみ変更できます。
最も一般的に使用されるデータ・ストア属性は、次のとおりです。
DataStore: データベースの各要素のチェックポイント・ファイルのフルパスおよびファイル名の接頭辞を定義します。必須です。
LogDir: データベースの各要素について、トランザクション・ログ・ファイルのファイル・システム・ディレクトリを定義します。
DatabaseCharacterSet: データベースで使用される文字セットを定義します。必須です。
Durability: トランザクションの永続性の程度を定義します。
初期接続属性は、データベースがメモリーにロードされるときにデータベースに関連付けられます。これらは、データベースをメモリーからアンロードして、初期接続属性に異なる値を指定して再ロードしたときにのみ変更できます。
最も一般的に使用される初期接続属性は、次のとおりです。
PermSize: データベースの各要素の永続メモリー領域の割当て済サイズを定義します。永続メモリー領域には、永続的なデータベース・オブジェクト(表など)が含まれています。TimesTen Scaleoutでは、永続メモリー領域の内容のみをファイル・システムに書き込みます。
TempSize: データベースの各要素の一時メモリー領域の割当て済サイズを定義します。一時メモリー領域には、文の実行時に生成された一時データが含まれます。
|
ノート: 各ホストには、ホストに関連付けられているデータ・インスタンスと同じ数のデータベース要素を格納するために十分なメイン・メモリーが必要です。リージョン・サイズの設定の詳細は、このドキュメントのPermSize属性の値の決定およびOracle TimesTen In-Memory Databaseオペレーション・ガイドのデータベースのメモリー・リージョン・サイズの指定とTimesTenの記憶域のプロビジョニングを参照してください。 |
PL/SQL初期接続属性は、PL/SQL操作に関するデータベースの動作を定義し、データベースがメモリーにロードされるときにデータベースに関連付けられます。これらは、データベースをメモリーからアンロードして、PL/SQL初期接続属性に異なる値を指定して再ロードしたときにのみ変更できます。
サーバー接続属性は、接続に関するデータベースの動作を定義し、データベースがメモリーにロードされるときにデータベースに関連付けられます。これらは、データベースをメモリーからアンロードして、サーバー接続属性に異なる値を指定して再ロードしたときにのみ変更できます。
|
ノート: データベース定義ファイル内のデータ・ストアではないすべての接続属性、初期接続属性、PL/SQL初期接続属性またはサーバー接続属性が、TimesTen Scaleoutによってデフォルトで作成される接続可能オブジェクトに追加されます。詳細は、接続可能オブジェクトの作成を参照してください。 |
例5-1に示すように、データベース定義ファイルを作成します。
例5-1 データベース定義ファイル
次の例では、データベース定義ファイルdatabase1.dbdefを次のように定義して作成します。
チェックポイント・ファイルのフルパスは/disk1/databases/database1
ログ・ファイルのディレクトリは/disk2/logs
データベース文字セットはAL32UTF8
永続性設定は0。
各要素の永続メモリー領域は32 GB
各要素の一時メモリー領域は4 GB
各要素の内部トランザクション・ログ・バッファは1 GB
データベースへのユーザー指定同時接続の上限は2048
vi /mydir/database1.dbdef DataStore=/disk1/databases/database1 LogDir=/disk2/logs DatabaseCharacterSet=AL32UTF8 Durability=0 PermSize=32768 TempSize=4096 LogBufMB=1024 Connections=2048
すべての接続属性の詳細は、Oracle TimesTen In-Memory Databaseリファレンスの接続属性を参照してください。
ttGridAdmin dbdefCreateコマンドにより、データベース定義ファイルに基づいてデータベース定義が作成されます。TimesTen Scaleoutでは、データベース定義ファイルの名前を使用して、データベース定義の名前を指定します。
database1.dbdefファイルに基づいてdatabase1データベース定義が作成されます。
% ttGridAdmin dbdefCreate /mydir/database1.dbdef Database Definition database1 created.
また、ttGridAdmin dbdefCreateコマンドによって、同じ名前の接続可能オブジェクトも作成され、ここには、データベース定義ファイル内に存在するすべての一般接続属性が含められます。例5-1のdatabase1.dbdefファイルには一般接続属性が含まれていないため、database1接続可能オブジェクトに属性は含められません。この接続可能オブジェクトは、常に、直接接続に対してのみ設定されます。
現在のバージョンのモデルに、database1データベース定義を追加します。
% ttGridAdmin modelApply ... Updating grid state...................................................OK Pushing new configuration files to each instance......................OK ... ttGridAdmin modelApply complete
TimesTen Scaleoutにより、database1データベース定義に定義されている属性に基づき、すべてのデータ・インスタンスの構成ファイルに、database1接続可能オブジェクトが追加されます。
|
ノート: TimesTen Scaleoutでは、最新バージョンのモデルに加えた変更を操作グリッドに適用するたびに、構成ファイルが上書きされます。このため、ttGridAdminユーティリティを活用せずにこれらのファイルを変更しないようにする必要があります。 |
ttGridAdmin dbdefCreateまたはttGridAdmin modelApplyコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベース定義の作成(dbdefCreate)またはこのドキュメントのモデルに加えた変更の適用をそれぞれ参照してください。
TimesTen Scaleoutでは、ユーザー・データはデータベースを形成する一連の要素に分散されます。現在のバージョンのモデルの各データ・インスタンスには、グリッド内の各ユーザー・データベースについて1つの要素が含まれています。
データベース定義に格納されている属性に基づいて、データベースを作成できます。データベースを作成すると、各データ・インスタンスによってデータベースの1つの要素が作成され、メモリーにロードされます。
各データ・インスタンスに対してデータベースの要素を作成するプロセスは、非同期です。各データ・インスタンスのデーモンでは、作成のフラグが設定された新しいデータベースが存在することを認識すると、すぐに、個別に要素を作成してメモリーにロードするために必要な操作を実行します。
ttGridAdmin dbCreateコマンドにより、データベース定義に基づいてデータベースが作成されます。
database1データベース定義に基づいてdatabase1データベースが作成されます。
% ttGridAdmin dbCreate database1 Database database1 creation started
分散マップの定義を続行する前に、すべてのデータ・インスタンスで、データベース要素がメモリーにロードされたことが報告されるまで待機します。例5-2に示すように、ttGridAdmin dbStatusコマンドを使用して、データベース作成プロセスのステータスを確認できます。
例5-2 データベース作成プロセスのステータスの確認
この例は、database1データベースのステータス・サマリーを示しています。レポートに、データベースのすべての要素がロード済として表示されていることに注意してください。
% ttGridAdmin dbStatus database1 -element Database database1 element level status as of Wed Jan 10 14:34:08 PST 2018 Host Instance Elem Status Date/Time of Event Message ----- --------- ---- ------ ------------------- ------- host3 instance1 1 loaded 2018-01-10 14:33:23 host4 instance1 2 loaded 2018-01-10 14:33:21 host5 instance1 3 loaded 2018-01-10 14:33:23 host6 instance1 4 loaded 2018-01-10 14:33:23 host7 instance1 5 loaded 2018-01-10 14:33:23 host8 instance1 6 loaded 2018-01-10 14:33:23
ttGridAdmin dbCreateまたはttGridAdmin dbStatusコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースの作成(dbCreate)またはデータベースのステータスのモニター(dbStatus)をそれぞれ参照してください。
TimesTen Scaleoutは柔軟なスケーラビリティを備えています。ビジネス・ニーズに応じて、データベース内の要素の数を増加または削減できます。新しいデータ・インスタンスをグリッドに追加したとき、データベースに格納されているデータが、新規または残りのインスタンスの要素間で自動的に再分散されることはありません。TimesTen Scaleoutでのデータの分散方法は、グリッド内の各ホストに関連付けられているデータ領域グループおよびデータベースの分散マップで定義されているデータ・インスタンスの要素によって定義されます。
|
ノート: データベースの分散マップを変更する操作中、DDL文およびDML文はTimesTen Scaleoutによってブロックされます。メンテナンス期間中やスケジューリングした停止中など、オープン・トランザクションが存在しないときに分散マップを変更するようにしてください。 |
-addオプションを使用してttGridAdmin dbDistributeコマンドを実行すると、データ・インスタンスの要素がデータベースの分散マップに追加されます。-addオプションのパラメータとしてallを使用すると、グリッド内の使用可能なすべてのデータ・インスタンスの要素が追加されます。allパラメータは、通常、新しいデータベースの分散マップの初期定義に使用されます。
grid1グリッドで使用可能なデータ・インスタンスのすべての要素を、database1データベースの分散マップに追加します。
% ttGridAdmin dbDistribute database1 -add all -apply Distribution map updated
ttGridAdmin dbDistributeコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースの分散スキームの設定または変更(dbDistribute)を参照してください。
アプリケーションをデータベースに接続できるようにするには、データベースをユーザー接続に対してオープンする必要があります。データベース作成プロセスと同様に、要素をオープンするプロセスは非同期です。各データ・インスタンスのデーモンは、データベースにオープンのフラグが設定されていることを認識すると、すぐに、その要素をオープンするために必要な操作を実行します。
|
ノート:
|
ttGridAdmin dbOpenコマンドにより、ユーザー接続に対してデータベースをオープンします。
ユーザー接続に対してdatabase1データベースをオープンします。
% ttGridAdmin dbOpen database1 Database database1 open started
例5-3に示すように、ttGridAdmin dbStatusコマンドを使用して、データベース・オープン・プロセスのステータスを確認できます。
例5-3 データベース・オープン・プロセスのステータスの確認
この例は、database1データベースのステータス・サマリーを示しています。レポートに、データベースのすべての要素がオープンとして表示されていることに注意してください。
% ttGridAdmin dbStatus database1 -element Database database1 element level status as of Wed Jan 10 14:34:43 PST 2018 Host Instance Elem Status Date/Time of Event Message ----- --------- ---- ------ ------------------- ------- host3 instance1 1 opened 2018-01-10 14:34:43 host4 instance1 2 opened 2018-01-10 14:34:43 host5 instance1 3 opened 2018-01-10 14:34:42 host6 instance1 4 opened 2018-01-10 14:34:42 host7 instance1 5 opened 2018-01-10 14:34:42 host8 instance1 6 opened 2018-01-10 14:34:42
ttGridAdmin dbOpenまたはttGridAdmin dbStatusコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのオープン(dbOpen)またはデータベースのステータスのモニター(dbStatus)をそれぞれ参照してください。
データベースに接続できるようにするには、データベースの各要素を作成してメモリーにロードし、分散マップに追加して、ユーザー接続に対してオープンする必要があります。これらすべての操作については、前の項(データベースの作成)を参照してください。
接続可能オブジェクトは、データベースに接続するためにアプリケーションで使用可能な名前を定義します。接続可能オブジェクトは、データベースと同じ名前にすることも、異なる名前にすることもできます。接続可能オブジェクトには、次の2つのタイプがあります。
直接接続可能オブジェクト: アプリケーションで直接通信を介してデータベースに接続できる名前を定義します。
クライアント/サーバー接続可能オブジェクト: アプリケーションでクライアント/サーバー通信を介してデータベースに接続できる名前を定義します。
TimesTen Scaleoutでは、単一データベースに対して定義された接続属性の異なるセットを含む複数の接続可能オブジェクトを作成できます。
接続可能オブジェクトは、次のタイプの接続属性をサポートしています。
一般接続属性は、接続のたびに設定され、その接続期間中のみ保持されます。
すべての接続属性の詳細は、Oracle TimesTen In-Memory Databaseリファレンスの接続属性を参照してください。
TimesTen Scaleoutでは、デフォルトで、グリッドに追加された各データベース定義について、直接接続可能オブジェクトが作成されます。この接続可能オブジェクトを使用すると、アプリケーションで、データベースの分散マップ内の任意のデータ・インスタンスからデータベースへの直接接続を作成できます。TimesTen Scaleoutでは、データベース定義に割り当てられた名前を使用して、接続可能オブジェクトの名前を指定します。データベースへのクライアント/サーバー接続を確立するには、クライアント/サーバー接続可能オブジェクトを作成する必要があります。
接続可能オブジェクトを作成するためのタスクは、次のとおりです。
接続可能オブジェクト・ファイルでは、データベースへの接続に使用する属性を指定します。接続可能オブジェクト・ファイルでは、ファイル名接尾辞として.connectを使用する必要があります。接続可能オブジェクト・ファイルのファイル名接頭辞により、接続可能オブジェクトの名前が設定されます。たとえば、database1CS.connectという名前の接続可能オブジェクト・ファイルにより、database1csという名前の接続可能オブジェクトが作成されます。
|
ノート: 接続可能オブジェクト名には、データ・ソース名と同じ制限があります。詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドのTimesTenデータベースを識別するためのデータ・ソース名の指定方法を参照してください。 |
例5-4に示すように、database1データベースの接続属性を使用してクライアント/サーバー接続可能オブジェクト・ファイルを作成します。
例5-4 接続可能オブジェクト・ファイル
この例では、接続文字セットとしてAL32UTF8を、および接続のユーザーIDとしてterryを設定する、database1CS.connectという名前の接続可能オブジェクト・ファイルの内容を示しています。
ConnectionCharacterSet=AL32UTF8 UID=terry
|
ノート: ユーザーIDを指定しない場合、TimesTenでは、接続リクエストをUIDとして送信するユーザーのOSユーザーIDが使用されます。この場合、OSユーザーIDは認証できないため、localhost以外のシステムからの接続リクエストは失敗します。詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのUIDおよびPWDおよびOracle TimesTen In-Memory Databaseセキュリティ・ガイドのTimesTenでの認証を参照してください。 |
ttGridAdmin connectableCreateコマンドにより、接続可能オブジェクト・ファイルに基づいて接続可能オブジェクトが作成されます。
database1CS.connect接続可能オブジェクト・ファイルに基づいて、database1CS接続可能オブジェクトを作成します。
% ttGridAdmin connectableCreate -dbdef database1 -cs /mydir/database1CS.connect Connectable database1CS created.
|
ノート:
|
現在のバージョンのモデルにdatabase1CS接続可能オブジェクトの作成を適用して、接続可能オブジェクトを使用できるようにします。
% ttGridAdmin modelApply ... Updating grid state...................................................OK Pushing new configuration files to each instance......................OK ... ttGridAdmin modelApply complete
ttGridAdmin connectableCreateまたはttGridAdmin modelApplyコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスの接続可能オブジェクトの作成(connectableCreate)またはこのドキュメントのモデルに加えた変更の適用をそれぞれ参照してください。
アプリケーションは、ODBCダイレクト・ドライバ、ODBCクライアント・ドライバまたはODBCドライバ・マネージャを使用してデータベースに接続できます。詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドのODBCドライバおよびJDBCドライバを使用したTimesTenへの接続を参照してください。
次のトピックでは、これらのDSNを使用してデータベースへの直接接続およびクライアント接続を確立する方法について説明します。
TimesTen Scaleoutでは、データベース定義ファイルで指定されたすべての一般接続属性を含む、直接接続可能オブジェクトが自動的に作成されます。TimesTen Scaleoutでは、データベース定義の名前を使用して、接続可能オブジェクトの名前を指定します。接続可能オブジェクトが現在のバージョンのモデルに適用されると、TimesTen Scaleoutにより、接続可能オブジェクトと同じ名前のすべてのデータ・インスタンスでDSNが定義されます。これにより、ODBCアプリケーションとJDBCアプリケーションは、接続可能オブジェクトに関連付けられたデータベースに接続できます。
データ・インスタンスからttIsqlユーティリティを使用して、データベースへの直接接続を確立できます。
host3.instance1データ・インスタンスから、database1接続可能オブジェクトを使用してdatabase1データベースに接続します。
% ttIsql -connStr "DSN=database1" Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=database1"; Connection successful: DSN=database1;UID=pat;DataStore=/disk1/databases/database1; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;LogDir=/disk2/logs; PermSize=32768;TempSize=4096;TypeMode=0; (Default setting AutoCommit=1) Command>
|
ノート: この例では、インスタンス管理者として、grid1グリッドのすべてのインスタンス(データおよび管理)に対して定義されているデータベースに接続します。データベース・ユーザーの詳細は、Oracle TimesTen In-Memory Databaseセキュリティ・ガイドのTimesTenユーザーの概要を参照してください。 |
ttIsqlユーティリティの詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドのttIsqlユーティリティの使用方法を参照してください。
クライアント/サーバー接続可能オブジェクトを使用すると、すべてのデータ・インスタンスで、TimesTen Clientドライバを使用してTimesTen Clientインスタンスまたはアプリケーションからの接続を受け入れることができます。ただし、グリッドに含まれないTimesTen Clientからのクライアント接続を確立するには、TimesTen Clientのシステムまたはユーザーodbc.iniファイルにクライアントDSNを作成する必要があります。
ttGridAdmin gridClientExportコマンドにより、グリッドで使用可能なすべてのクライアント/サーバー接続可能オブジェクトが、TimesTen Clientで使用されているシステムまたはユーザーodbc.iniファイルを置き換えるようフォーマットされたファイルにエクスポートされます。
grid1グリッドのクライアント/サーバー接続可能オブジェクトをファイルにエクスポートします。
% ttGridAdmin gridClientExport /mydir/sys.odbc.ini
例5-5は、結果として得られるファイルの内容を示しています。
例5-5 エクスポートされたodbc.iniファイル
[ODBC Data Sources] database1CS=TimesTen 18.1.4 Client Driver [database1CS] TTC_SERVER_DSN=DATABASE1 # External address/port info for host3.instance1 TTC_SERVER1=host3.example.com/6625 # External address/port info for host4.instance1 TTC_SERVER2=host4.example.com/6625 # External address/port info for host5.instance1 TTC_SERVER3=host5.example.com/6625 # External address/port info for host6.instance1 TTC_SERVER4=host6.example.com/6625 # External address/port info for host7.instance1 TTC_SERVER5=host7.example.com/6625 # External address/port info for host8.instance1 TTC_SERVER6=host8.example.com/6625 ConnectionCharacterSet=AL32UTF8 UID=terry
ttGridAdmin gridClientExportコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのグリッド外部のクライアント/サーバー接続のためのsys.odbc.iniのエクスポート(gridClientExport)を参照してください。
LinuxまたはUNIX上のTimesTen ClientにクライアントDSNを追加するには、TimesTen Clientのシステムまたはユーザーodbc.iniファイルを作成したファイルと置き換えるか、ファイルの内容をシステムまたはユーザーodbc.iniファイルにコピーします。次に、TimesTen Clientから、ttIsqlCSユーティリティとともにdatabase1CS DSNを使用して、database1データベースに接続します。
% ttIsqlCS -connStr "DSN=database1CS" Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=database1CS;UID=terry; Enter password for 'terry': Connection successful: DSN=database1CS;TTC_SERVER=host3.example.com; TTC_SERVER_DSN=DATABASE1;UID=terry;DATASTORE=/disk1/databases/database1; DATABASECHARACTERSET=AL32UTF8;CONNECTIONCHARACTERSET=AL32UTF8; PERMSIZE=32768;TEMPSIZE=4096;TYPEMODE=0; (Default setting AutoCommit=1) Command>
|
ノート: この例では、データベースに対して少なくともCREATE SESSION権限を持つterryユーザーで、データベースに接続します。データベース・ユーザーとその作成方法の詳細は、Oracle TimesTen In-Memory Databaseセキュリティ・ガイドのデータベース・ユーザーの作成または識別を参照してください。 |
ttIsqlCSユーティリティおよびTimesTen Clientの詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドのTimesTen ClientおよびTimesTen Serverの使用を参照してください。
TimesTen Clientリリース18.1に含まれているttInstallDSNユーティリティを使用することで、Windows上のTimesTen ClientにクライアントDSNを追加できます。ttInstallDSNユーティリティは、ttGridAdmin gridClientExportコマンドの出力ファイルの内容に基づいてシステムDSNを作成します。ファイルまたはその内容を、TimesTen ClientがインストールされているWindowsシステムで使用できるようにする必要があります。
C:\>ttInstallDSN -f C:\Users\terry\Downloads\sys.odbc.ini Found the following DSNs in available 'C:\Users\terry\Downloads\sys.odbc.ini'. 0 : database1CS [ Please select the DSN to be imported: ] 0 Adding DSN 'database1CS'.
|
ノート: TimesTen Clientの環境変数を設定して、Windowsの管理者としてttInstallDSNユーティリティを実行する必要があります。詳細は、Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイドのTimesTen用の環境変数の設定を参照してください。 |
TimesTen Clientシステムから、ttIsqlユーティリティでdatabase1CS DSNを使用してdatabase1データベースに接続できるようになりました。
C:\>ttIsql -connStr "DSN=database1CS" Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=database1CS;UID=terry; Enter password for 'terry': Connection successful: DSN=database1CS;TTC_SERVER=host3.example.com; TTC_SERVER_DSN=DATABASE1;UID=terry;DATASTORE=/disk1/databases/database1; DATABASECHARACTERSET=AL32UTF8;CONNECTIONCHARACTERSET=AL32UTF8; PERMSIZE=256;TEMPSIZE=128;TYPEMODE=0; (Default setting AutoCommit=1) Command>
|
ノート: この例では、データベースに対して少なくともCREATE SESSION権限を持つterryユーザーで、データベースに接続します。データベース・ユーザーとその作成方法の詳細は、Oracle TimesTen In-Memory Databaseセキュリティ・ガイドのデータベース・ユーザーの作成または識別を参照してください。 |
ttInstallDSNユーティリティの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttInstallDSNを参照してください。
ttIsqlユーティリティおよびTimesTen Clientの詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドのTimesTen ClientおよびTimesTen Serverの使用を参照してください。
アプリケーションからクライアント/サーバー接続可能オブジェクトに接続するとき、グリッド内のデータ・インスタンスのいずれかに対して、TCP/IP接続が確立されます。ただし、インスタンスがビジー状態の場合、インスタンスでは、クライアント接続をグリッド内の他のインスタンスに自動的にリダイレクトできます。
デフォルトでは、グリッド内で使用可能な任意のインスタンスに、クライアント接続を自動的にリダイレクトできます。ただし、この動作は、次のものを使用して制限または変更できます。
TTC_Redirect接続属性を使用して、クライアントのリダイレクト方法を定義します。
自動リダイレクション: デフォルトで、この接続属性は1に設定されます。これにより、現在のインスタンスがビジー状態または使用不可の場合、クライアント接続は、グリッド内の使用可能ないずれかのインスタンスに自動的にリダイレクトされます。接続は、クライアント接続数が最も少ないインスタンスにリダイレクトされます。
単一レプリカ・セット内の要素: クライアントで単一レプリカ・セット内の要素を含むインスタンスに接続する必要がある場合(目的のデータがこのレプリカ・セットに含まれているため)、TTC_Redirect属性を0に設定します。次に、クライアントでは、同じレプリカ・セット内の要素を含むインスタンスにのみ接続します。接続が拒否された場合は、接続エラーが戻されます。
TTC_Redirect_Limit接続属性を使用して、クライアントのリダイレクト回数を制限します。グリッド内のインスタンスの数は、パフォーマンス上の理由からリダイレクトされるクライアント接続の試行回数を制限する必要があるサイズに設定できます。TTC_Redirect_Limit属性は、接続リダイレクションの試行回数に設定できます。たとえば、TTC_Redirect_Limitを設定すると、他のインスタンスへのクライアント接続リダイレクションの試行が10回に制限されます。クライアントが、この試行回数内で接続されない場合、接続エラーが戻されます。
クライアント接続を適切なインスタンスにリダイレクトできない場合、クライアント接続は失敗します。クライアント・フェイルオーバー・プロセスの詳細は、クライアント接続のフェイルオーバーを参照してください。
TTC_RedirectまたはTTC_Redirect_Limit接続属性の詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのTTC_REDIRECTまたはTTC_Redirect_Limitをそれぞれ参照してください。
TimesTen Client接続属性の変更方法の詳細は、接続可能オブジェクトでの接続属性の変更を参照してください。
接続しているデータベースが実際に分散データベース(TimesTen Scaleout)であり、単一インスタンス・データベース(TimesTen Classic)でないことを確認する必要がある場合は、ttConfiguration組込みプロシージャを使用して、ttGridEnable属性の値をコールします。組込みプロシージャにより、グリッド内のデータベースのttGridEnable=1が戻されます。
Command> CALL ttConfiguration('ttGridEnable');
< TTGridEnable, 1 >
1 row found.
Command>
ttConfiguration組込みプロシージャの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttConfigurationを参照してください。
TimesTen Scaleoutでは、データはグリッドの要素間で分散されます。データの分散方法は、CREATE TABLE文のDISTRIBUTE BY句で指定された分散スキームによって定義されます。データの分散方法や特定のデータが格納されている要素に関係なく、アプリケーションでは、単一の要素に接続しているときにデータベース内のすべてのデータにアクセスできます。ただし、表の分散スキームを定義するとき、いくつかのことを考慮する必要があります。
|
重要: データベース・オブジェクトの作成を開始する前に、Oracle TimesTen In-Memory Databaseセキュリティ・ガイドのTimesTenでの認証を参照してください。 |
TimesTen Scaleoutの表に使用可能なデータの分散スキームは、次のとおりです。
ハッシュ分散スキームでは、主キーのハッシュまたはユーザー指定の一連の列に基づいて、データが分散されます。ハッシュ・キーにより、行を格納する必要があるレプリカ・セットが決定されます。表内の特定の1行は、1つのレプリカ・セットにのみ格納されます。表に主キーまたはユーザー指定の分散列が存在しない場合、この目的でTimesTen Scaleoutによって追加された非表示列のハッシュに基づいてデータが分散されます。この分散スキームは、トポロジの変更に対して適応性があり、一貫性のあるハッシュを使用します。つまり、ハッシュ・キー列に特定の値を含む行は、トポロジが変更されない場合には常に同じレプリカ・セットに割り当てられます。トポロジが変更された場合、行の位置は、データが再分散されたときに変わる可能性があります。
|
ノート: DISTRIBUTE BY句を指定せずに表を作成する場合は、TimesTen Scaleoutにより、表のハッシュ分散スキームが定義されます。さらに、列がDISTRIBUTE BY HASH句で指定されていない場合は、TimesTen Scaleoutにより、分散スキームのキー列として主キー列が選択されます。主キーが定義されていない場合は、TimesTen Scaleoutにより、ハッシュ・キーとして非表示列が作成されます。 |
cust_id主キー列のハッシュに基づいてデータを分散するDISTRIBUTE BY HASH句を使用したcustomers表を作成します。
CREATE TABLE customers ( cust_id NUMBER(10,0) NOT NULL PRIMARY KEY, first_name VARCHAR2(30) NOT NULL, last_name VARCHAR2(30) NOT NULL, addr1 VARCHAR2(64), addr2 VARCHAR2(64), zipcode VARCHAR2(5), member_since DATE NOT NULL ) DISTRIBUTE BY HASH;
図5-1は、データベースの作成で構成したdatabase1データベースのcustomers表のデータ分散を示しています。TimesTen Scaleoutでは、cust_id列のハッシュに基づいて、各要素にデータを分散します。
ハッシュ分散スキームの詳細は、Oracle TimesTen In-Memory Database SQLリファレンスのCREATE TABLEを参照してください。
参照分散スキームでは、外部キー制約の対応する親行の位置に基づいて、子表のデータが分散されます。この分散スキームにより、単一要素の関連データを分散することで、結合のパフォーマンスが最適化されます。親表と子表を結合すると、すべてのデータが同じ要素上に格納されるため、TimesTen Scaleoutでは異なる要素にアクセスする必要がありません。親表をハッシュまたは参照によって分散できるため、複数層の参照分散が可能となります。
|
ノート: DISTRIBUTE BY REFERENCE句を使用するときには、必ず外部キー制約の子キー列をNOT NULLとして宣言してください。 |
cust_id主キー列のハッシュに基づいてデータを分散するDISTRIBUTE BY HASH句を使用したcustomers親表を作成します。次に、fk_customer外部キー内の参照列customers(cust_id)の対応する値の位置に基づいてaccounts表のデータを分散するDISTRIBUTE BY REFERENCE句を使用したaccounts子表を作成します。
CREATE TABLE customers ( cust_id NUMBER(10,0) NOT NULL PRIMARY KEY, first_name VARCHAR2(30) NOT NULL, last_name VARCHAR2(30) NOT NULL, addr1 VARCHAR2(64), addr2 VARCHAR2(64), zipcode VARCHAR2(5), member_since DATE NOT NULL ) DISTRIBUTE BY HASH; CREATE TABLE accounts ( account_id NUMBER(10,0) NOT NULL PRIMARY KEY, phone VARCHAR2(15) NOT NULL, account_type CHAR(1) NOT NULL, status NUMBER(2) NOT NULL, current_balance NUMBER(10,2) NOT NULL, prev_balance NUMBER(10,2) NOT NULL, date_created DATE NOT NULL, cust_id NUMBER(10,0) NOT NULL, CONSTRAINT fk_customer FOREIGN KEY (cust_id) REFERENCES customers(cust_id) ) DISTRIBUTE BY REFERENCE (fk_customer);
図5-2は、データベースの作成で構成したdatabase1データベースのcustomers表のデータ分散を示しています。TimesTen Scaleoutでは、customers表のデータをcust_id主キー列のハッシュに基づいて各レプリカ・セットに分散します。この図は、fk_customer外部キー内の参照列cutomers(cust_id)の対応する値の位置に基づいた、accounts表のデータ分散も示しています。
参照分散スキームの詳細は、Oracle TimesTen In-Memory Database SQLリファレンスのCREATE TABLEを参照してください。
複製分散スキームでは、表のデータの同一コピーをデータベースのすべての要素に分散します。この分散スキームにより、すべてのデータ・アクセスが確実にローカルとなり、表に対する読取りと結合のパフォーマンスが最適化されます。ただし、挿入および更新においては、他の分散スキームよりもリソースが大量に消費されます。
データベースのすべての要素にデータを分散するDUPLICATE句を使用したaccount_type表を作成します。
CREATE TABLE account_type ( type CHAR(1) NOT NULL PRIMARY KEY, description VARCHAR2(100) NOT NULL ) DUPLICATE;
図5-3は、データベースの作成で構成したdatabase1データベースのaccount_type表のデータ分散を示しています。TimesTen Scaleoutにより、データベースのすべての要素についてデータのコピーが作成されます。
複製分散スキームの詳細は、Oracle TimesTen In-Memory Database SQLリファレンスのCREATE TABLEを参照してください。
マテリアライズド・ビューを使用すると、表の分散のセカンダリ・フォームを作成でき、次のようなシナリオで役立ちます。
主キーおよび一意列を含む表を、主キー列に基づくハッシュによって分散する場合、TimesTen Scaleoutでは、一意列に挿入または更新される値の一意性を検証するために、データベースの各要素に接続することが必要になる場合があります。この場合、ハッシュ分散スキームでは、重複する値が同じ要素内に配置されることを保証できません。さらに、一意列に基づいてハッシュによって分散される表のマテリアライズド・ビューを作成する場合、TimesTen Scaleoutでは、マテリアライズド・ビュー内の行の位置が一意列の値によって決定されるため、より効率的に一意列の値の一意性を確認できるようになります。また、問合せのパフォーマンスを最適化するために、マテリアライズド・ビューに一意列の索引を作成することもお薦めします。このシナリオの例は、例5-6を参照してください。
問合せで通常は結合されている列の独立した2つのグループを含む表がある場合は、列のいずれかのグループに基づいて、ハッシュによって表を分散することを検討してください。これにより、列のこのグループに対する問合せが最適化されます。次に、列の2番目のグループに対する問合せを最適化するには、列の2番目のグループに基づいてハッシュによって分散される表のマテリアライズド・ビューを作成します。このシナリオの例は、例5-7を参照してください。
TimesTen Scaleoutでマテリアライズド・ビューを使用するときには、次の点を考慮してください。
分散は、ハッシュ分散スキームのみに制限されます。
主キーをハッシュ・キーとして使用する場合にも、ハッシュ・キー列は明示的に指定する必要があります。
SQLオプティマイザによって、問合せの実行時間が改善される可能性が検出された場合、ベース表に対する問合せが、かわりに使用可能なマテリアライズド・ビューを使用するようにリライトされることがあります。
例5-6 ハッシュ・キーとして一意列を含むマテリアライズド・ビュー
この例では、cust_id主キー列のハッシュに基づいてデータを分散するDISTRIBUTE BY HASH句を使用したcustomers親表を作成します。また、この例では、DISTRIBUTE BY REFERENCE句を使用するaccounts子表も作成されます。TimesTen Scaleoutでは、cust_id外部キー列の対応する値の位置に基づいて、accounts表のデータを分散します。最後に、この例では、phone一意列のハッシュに基づいてデータを分散するDISTRIBUTE BY HASH句を使用したphone_mvマテリアライズド・ビューを作成します。この例では、特定のphone値の単一データ・インスタンスに含まれるデータをレビューするのみで、accounts表のphone列の値の一意性を検証できます。
CREATE TABLE customers (
cust_id NUMBER(10,0) NOT NULL PRIMARY KEY,
first_name VARCHAR2(30) NOT NULL,
last_name VARCHAR2(30) NOT NULL,
addr1 VARCHAR2(64),
addr2 VARCHAR2(64),
zipcode VARCHAR2(5),
member_since DATE NOT NULL
) DISTRIBUTE BY HASH;
CREATE TABLE accounts (
account_id NUMBER(10,0) NOT NULL PRIMARY KEY,
phone VARCHAR2(16) NOT NULL UNIQUE,
account_type CHAR(1) NOT NULL,
status NUMBER(2,0) NOT NULL,
current_balance NUMBER(10,2) NOT NULL,
prev_balance NUMBER(10,2) NOT NULL,
date_created DATE NOT NULL,
cust_id NUMBER(10,0) NOT NULL,
CONSTRAINT fk_customer
FOREIGN KEY (cust_id)
REFERENCES customers(cust_id)
) DISTRIBUTE BY REFERENCE (fk_customer);
CREATE MATERIALIZED VIEW phone_mv
DISTRIBUTE BY HASH (phone)
AS SELECT phone FROM accounts;
例5-7 独立した列グループのマテリアライズド・ビュー
この例では、cust_id主キー列のハッシュに基づいてデータを分散するDISTRIBUTE BY HASH句を使用したcustomers表を作成します。また、この例では、account_id主キー列のハッシュに基づいてデータを分散するDISTRIBUTE BY HASH句を使用したaccounts表を作成します。次に、この例では、call_id主キー列のハッシュに基づいてデータを分散するDISTRIBUTE BY HASH句を使用したcall_records表を作成します。
CREATE TABLE customers (
cust_id NUMBER(10,0) NOT NULL PRIMARY KEY,
first_name VARCHAR2(30) NOT NULL,
last_name VARCHAR2(30) NOT NULL,
addr1 VARCHAR2(64),
addr2 VARCHAR2(64),
zipcode VARCHAR2(5),
account_id NUMBER(10,0),
member_since DATE NOT NULL
) DISTRIBUTE BY HASH;
CREATE TABLE accounts (
account_id NUMBER(10,0) NOT NULL PRIMARY KEY,
phone VARCHAR2(15) NOT NULL,
account_type CHAR(1) NOT NULL,
status NUMBER(2,0) NOT NULL,
current_balance NUMBER(10,2) NOT NULL,
prev_balance NUMBER(10,2) NOT NULL,
date_created DATE NOT NULL,
cust_id NUMBER(10,0) NOT NULL UNIQUE
) DISTRIBUTE BY HASH;
CREATE TABLE call_records (
call_id NUMBER(10,0) NOT NULL PRIMARY KEY,
caller NUMBER(10,0) NOT NULL,
receiver NUMBER(10,0) NOT NULL,
call_time TIMESTAMP NOT NULL,
code INT NOT NULL
) DISTRIBUTE BY HASH;
次の問合せに示すように、特定のコードを使用してコールしたアカウントおよび顧客に関するレポートが必要であることを考慮してください。
SELECT accounts.account_id, customers.cust_id, call_records.code
FROM accounts, customers, call_records
WHERE customers.cust_id = call_records.caller
AND call_records.code = ?
AND customers.account_id = accounts.account_id;
customers表とcall_records表の結合を最適化するために、この例では、caller列に基づいてcall_records表にcustomers_calls_mvマテリアライズド・ビューを作成します。
CREATE MATERIALIZED VIEW customers_calls_mv
DISTRIBUTE BY HASH (caller)
AS SELECT caller, code FROM call_records;
また、customers表とaccounts表の結合を最適化するために、この例では、account_id列に基づいてcustomers表にcustomes_account_mvマテリアライズド・ビューを作成します。
CREATE MATERIALIZED VIEW customers_account_mv
DISTRIBUTE BY HASH (account_id)
AS SELECT account_id FROM customers;
マテリアライズド・ビューの詳細は、Oracle TimesTen In-Memory Database SQLリファレンスのCREATE MATERIALIZED VIEWを参照してください。
データベースが正常に動作するには、各要素の永続メモリー領域と一時メモリー領域の両方で、十分なメモリーが使用可能であることが必要です。例5-8に示すように、SYS.V$MONITORとSYS.GV$MONITORのシステム・ビューを問い合せることで、データベースのローカル要素やすべての要素について、この2つの領域に対するメモリーの割当て、使用中および最高水準で使用中のメモリー量をモニターできます。
例5-8 要素のメモリー領域のモニタリング
Command> SELECT elementid, perm_allocated_size, perm_in_use_size, perm_in_use_high_water, temp_allocated_size, temp_in_use_size, temp_in_use_high_water FROM sys.v$monitor; ELEMENTID: 1 PERM_ALLOCATED_SIZE: 262144 PERM_IN_USE_SIZE: 30338 PERM_IN_USE_HIGH_WATER: 30338 TEMP_ALLOCATED_SIZE: 131072 TEMP_IN_USE_SIZE: 21073 TEMP_IN_USE_HIGH_WATER: 24600 1 row found. Command> SELECT elementid, perm_allocated_size, perm_in_use_size, perm_in_use_high_water, temp_allocated_size, temp_in_use_size, temp_in_use_high_water FROM sys.gv$monitor; ELEMENTID: 1 PERM_ALLOCATED_SIZE: 262144 PERM_IN_USE_SIZE: 30338 PERM_IN_USE_HIGH_WATER: 30338 TEMP_ALLOCATED_SIZE: 131072 TEMP_IN_USE_SIZE: 21073 TEMP_IN_USE_HIGH_WATER: 24600 ELEMENTID: 3 PERM_ALLOCATED_SIZE: 262144 PERM_IN_USE_SIZE: 30289 PERM_IN_USE_HIGH_WATER: 30322 TEMP_ALLOCATED_SIZE: 131072 TEMP_IN_USE_SIZE: 21070 TEMP_IN_USE_HIGH_WATER: 24470 ELEMENTID: 5 PERM_ALLOCATED_SIZE: 262144 PERM_IN_USE_SIZE: 30289 PERM_IN_USE_HIGH_WATER: 30322 TEMP_ALLOCATED_SIZE: 131072 TEMP_IN_USE_SIZE: 20943 TEMP_IN_USE_HIGH_WATER: 24407 ELEMENTID: 2 PERM_ALLOCATED_SIZE: 262144 PERM_IN_USE_SIZE: 30338 PERM_IN_USE_HIGH_WATER: 30338 TEMP_ALLOCATED_SIZE: 131072 TEMP_IN_USE_SIZE: 20943 TEMP_IN_USE_HIGH_WATER: 24470 ELEMENTID: 4 PERM_ALLOCATED_SIZE: 262144 PERM_IN_USE_SIZE: 30289 PERM_IN_USE_HIGH_WATER: 30322 TEMP_ALLOCATED_SIZE: 131072 TEMP_IN_USE_SIZE: 21006 TEMP_IN_USE_HIGH_WATER: 24407 ELEMENTID: 6 PERM_ALLOCATED_SIZE: 262144 PERM_IN_USE_SIZE: 30289 PERM_IN_USE_HIGH_WATER: 30322 TEMP_ALLOCATED_SIZE: 131072 TEMP_IN_USE_SIZE: 21006 TEMP_IN_USE_HIGH_WATER: 24470 1 row found.
必要に応じて、PermSizeまたはTempSize属性の値を増加して、いずれかの領域に割り当てられているメモリー量を増加します。データベースのPermSizeまたはTempSize属性を変更する方法の詳細は、データベース定義での接続属性の変更を参照してください。
SQLスキーマ、およびデータベースの各表に想定される行数とttSizeユーティリティに基づいて、PermSize属性の値を見積もることができます。たとえば、最終的にcustomers表に1,000,000行を挿入することが想定される場合、例5-9に示すように、表で約287 MB (300,448,527バイト=286.53 MB)が使用可能である必要があります。
例5-9 表のサイズの見積り
% ttSize -tbl terry.customers -rows 1000000 database1 Rows = 1000000 Total in-line row bytes = 300442597 Indexes: Range index TERRY.CUSTOMERS adds 5930 bytes Total index bytes = 5930 Total = 300448527
ただし、ttSizeユーティリティは、TimesTen Classicのデータベースに最適化されています。TimesTen Scaleoutのデータベースでは、TimesTen Classicの類似するデータベースよりも、1行当たりの使用バイト数が8から16バイト多くなります。見積りをより正確にするために、ttSizeユーティリティによって計算される値に、8から16バイトを加算することを検討してください。customers表の場合、ttSizeユーティリティによって計算される値に1行当たり16バイトを加算すると、約302 MB (316,448,527バイト=301.79 MB)が使用可能である必要があります。
データベースのすべての表に対してこの見積りを繰り返し、各表の見積りサイズを加算することにより、すべてのホストを横断してデータベースが必要とする永続メモリー領域のサイズを大まかに把握できます。ただし、PermSize属性は、データベース全体ではなく1つの要素に対して割り当てられるメモリーの量を定義します。各要素に割り当てる必要がある各表の見積りサイズの量を決定するには、表の分散スキームを考慮する必要があります。
ハッシュまたは参照分散スキームを使用する表の場合は、ttSizeユーティリティを使用して見積もる前に、レプリカ・セット数で行数を除算します。
|
ノート: 参照分散スキームを使用する表では、キー値の参照が均等にならない可能性があることを考慮してください。データで、1つ以上のキー値を他の使用可能なキー値よりも頻繁に参照として使用する場合、行数をレプリカ・セット数で除算する計算は、不正確になる可能性があります。データの構成に基づいた特別な考慮事項が必要になります。 |
複製分散スキームを使用する表の場合は、見積りに合計行数を使用します。最終的に、データベースの各要素について、複製分散を使用する表のすべての行を検索します。
customers表でハッシュ分散スキームを使用し、database1データベースが3つのレプリカ・セットで構成されていることを考慮すると、各要素には333,334行を格納できる必要があり、これは、例5-10に示すように、customers表のみについて(PermSize属性によって定義された)永続メモリー領域の101 MB (100,209,711 + 16 * 333,334バイト= 100.65 MB)に相当します。
例5-10 単一要素内の表のサイズの見積り
% ttSize -tbl terry.customers -rows 333334 database1 Rows = 333334 Total in-line row bytes = 100203781 Indexes: Range index TERRY.CUSTOMERS adds 5930 bytes Total index bytes = 5930 Total = 100209711
ttSizeユーティリティの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttSizeを参照してください。
TimesTen Scaleoutでは、様々なソースからデータベースにデータをロードできます。ttBulkCpユーティリティを使用してファイルから、またはttLoadFromOracle組込みプロシージャを使用してOracleデータベース表から、特定の表にデータをロードできます。
TimesTen Scaleoutでは、ttBulkCpユーティリティとttLoadFromOracle組込みプロシージャの両方でlocalOnlyフィルタ・オプションがサポートされます。このフィルタを使用すると、ローカル要素およびそのレプリカにハッシュされた行のみをロードできます。localOnlyフィルタ・オプションを使用すると、ttBulkCpユーティリティおよびttLoadFromOracle組込みプロシージャでは、ローカル要素のレプリカではないリモート要素にハッシュされた行が無視されます。指定したオプションに関係なく、ttBulkCpユーティリティおよびttLoadFromOracle組込みプロシージャでは、重複する行は表にコピーされません。
localOnlyフィルタ・オプションを有効にすると、表の分散スキームに応じて、ttBulkCpユーティリティおよびttLoadFromOracle組込みプロシージャは次のように動作します。
ハッシュ: ローカル・データ・インスタンスとそのレプリカの要素にハッシュされたハッシュ・キー値を含む行が、保持および挿入されます。残りの要素にハッシュされた行は無視されます。
参照: ローカル要素とそのレプリカにハッシュされたハッシュまたは参照キー値を参照する参照キー値を含む行が、保持および挿入されます。残りの要素にハッシュされた行は無視されます。
複製: localOnlyオプションは無視されます。すべてのデータ・インスタンスの要素に、行が挿入されます。
localOnlyフィルタ・オプションを使用する長所は、次のとおりです。
バルク・ロード操作時にデータを分散するために必要なネットワーク帯域幅が減少します。
バルク・ロード操作が失敗した場合、他の要素とは無関係に再試行できます。
localOnlyフィルタ・オプションを使用する短所は、次のとおりです。
すべてのホスト、または少なくともグリッドの各レプリカ・セットに対して1つのホストで、ソース・ファイルを使用できる必要があります。このことは、ttBulkCpユーティリティを使用したバルク・ロード操作にのみ適用されます。
各レプリカ・セットの1つの要素について、バルク・ロード操作を1回実行する必要があります。
すべてのバルク・ロード操作で、データ・セット全体を処理する必要がありますが、別のレプリカ・セットにハッシュされた行はすべて無視されます。
次の各項では、TimesTen Scaleoutの表にデータをロードする方法について説明します。
-iオプションを指定してttBulkCpユーティリティを使用すると、ファイルからデータをロードできます。このオプションでは、標準のINSERT SQL文を使用して、データベースの特定の表にデータをロードします。ttBulkCpユーティリティを使用すると、表の分散スキームに基づいて、各行が対応する要素に挿入されます。
|
ノート:
|
次の各項では、ttBulkCpユーティリティを使用するとき、データベースにデータをロードするためのオプションについて説明します。
単一のデータ・インスタンスでのみソース・ファイルを使用できる場合は、-iオプションを指定してttBulkCpユーティリティを実行し、指定したデータベースの分散スキームに基づいて、指定したデータベースの行を対応する要素に挿入します。
ソース・ファイルへのアクセス権を持つデータ・インスタンスから、ファイル内のすべての行をdatabase1データベースのcustomers表に挿入します。
% ttBulkCp -i -connStr "DSN=database1;UID=terry" customers
/mydir/customers_data.dmp
Enter password for 'terry':
/mydir/customers_data.dmp:
1000 rows inserted
1000 rows total
ttBulkCpユーティリティの使用の詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドのttBulkCpユーティリティを使用したデータのバルク・コピーおよびOracle TimesTen In-Memory DatabaseリファレンスのttBulkCpを参照してください。
グリッド内のすべてのホストでソース・ファイルを使用できる場合、データベースの各レプリカ・セットのいずれかのデータ・インスタンスで-iおよび-localOnlyオプションを指定してttBulkCpユーティリティを実行し、ファイルからローカル要素とそのレプリカ・セットにハッシュされた行を表に挿入します。
アクティブ管理インスタンス(この例のアクティブ管理インスタンスはhost1.instance1)からttGridAdmin dbStatus -replicasetコマンドを使用すると、各レプリカ・セットに関連付けられているデータ・インスタンスの判別に役立ちます。
% ttGridAdmin dbStatus database1 -replicaset
Database database1 Replica Set status as of Thu Jan 11 13:17:29 PST 2018
RS DS Elem Host Instance Status Date/Time of Event Message
-- -- ---- ----- --------- ------ ------------------- -------
1 1 1 host3 instance1 opened 2018-01-10 14:34:43
2 2 host4 instance1 opened 2018-01-10 14:34:43
2 1 3 host5 instance1 opened 2018-01-10 14:34:42
2 4 host6 instance1 opened 2018-01-10 14:34:42
3 1 5 host7 instance1 opened 2018-01-10 14:34:42
2 6 host8 instance1 opened 2018-01-10 14:34:42
ソース・ファイルからローカル要素とそのレプリカにハッシュされた行を、database1データベースのcustomers表に挿入します。必ず、使用可能な各レプリカ・セットのいずれかのデータ・インスタンス(host3.instance1、host5.instance1、host7.instance1データ・インスタンスなど)で、ttBulkCpユーティリティを実行するようにしてください。
host3.instance1データ・インスタンスで実行する場合、次のようになります。
% ttBulkCp -i -localOnly -connStr "DSN=database1;UID=terry" customers
/mydir/customers_data.dmp
Enter password for 'terry':
/mydir/customers_data.dmp:
339 rows inserted
661 rows not inserted (ignored)
1000 rows total
|
ノート: この例では、host4.instance1データ・インスタンスの要素はhost3.instance1データ・インスタンスの要素のレプリカとして定義されており、host3.instance1データ・インスタンスの要素のcustomers表に挿入されたものと同じ行が、host4.instance1データ・インスタンスの要素のcustomers表に挿入されます。 |
host5.instance1データ・インスタンスで実行する場合、次のようになります。
% ttBulkCp -i -localOnly -connStr "DSN=database1;UID=terry" customers
/mydir/customers_data.dmp
Enter password for 'terry':
/mydir/customers_data.dmp:
327 rows inserted
673 rows not inserted (ignored)
1000 rows total
|
ノート: この例では、host6.instance1データ・インスタンスの要素はhost5.instance1データ・インスタンスの要素のレプリカとして定義されており、host5.instance1データ・インスタンスの要素のcustomers表に挿入されたものと同じ行が、host6.instance1データ・インスタンスの要素のcustomers表に挿入されます。 |
host7.instance1データ・インスタンスで実行する場合、次のようになります。
% ttBulkCp -i -localOnly -connStr "DSN=database1;UID=terry" customers
/mydir/customers_data.dmp
Enter password for 'terry':
/mydir/customers_data.dmp:
334 rows inserted
666 rows not inserted (ignored)
1000 rows total
|
ノート: この例では、host8.instance1データ・インスタンスの要素はhost7.instance1データ・インスタンスの要素のレプリカとして定義され、host7.instance1データ・インスタンスの要素のcustomers表に挿入されたものと同じ行が、host8.instance1データ・インスタンスの要素のcustomers表に挿入されます。 |
ttGridAdmin dbStatusコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのステータスのモニター(dbStatus)を参照してください。
ttBulkCpユーティリティの使用の詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドのttBulkCpユーティリティを使用したデータのバルク・コピーおよびOracle TimesTen In-Memory DatabaseリファレンスのttBulkCpを参照してください。
ttLoadFromOracle組込みプロシージャを使用すると、Oracleデータベースからデータをロードできます。
次の各項では、ttLoadFromOracle組込みプロシージャを使用するとき、1つのOracleデータベースから1つのデータベースにデータをロードする方法について説明します。
ttLoadFromOracle組込みプロシージャで1つのOracleデータベース表から1つのデータベース表にデータをインポートできるようにするには、TimesTen ScaleoutがそのOracleデータベースを認識し、そのOracleデータベースと通信できる必要があります。このことを実現するには、次を実行する必要があります。
|
ノート: sqlnet.oraとtnsnames.oraの両方のファイルの内容のインポートは、OCI、Pro*C/C++またはODP.NETを使用してOracle Databaseと通信するアプリケーションに関連します。詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのOracle Databaseの操作を参照してください。 |
ttGridAdmin SQLNetImportコマンドを実行して、sqlnet.oraファイルの内容を最新バージョンのモデルにインポートします。
sqlnet.oraファイルの内容をインポートします。
% ttGridAdmin SQLNetImport /mydir/sqlnet.ora SQLNet configuration file /mydir/sqlnet.ora imported
ttGridAdmin TNSNamesImportコマンドを実行して、tnsnames.oraファイルの内容を最新バージョンのモデルにインポートします。
tnsnames.oraファイルの内容をインポートします。
% ttGridAdmin TNSNamesImport /mydir/tnsnames.ora TNSNames configuration file /mydir/tnsnames.ora imported
ttGridAdmin modelApplyコマンドを実行して、最新バージョンのモデルに加えた変更を操作グリッドに適用します。
% ttGridAdmin modelApply ... Updating grid state...................................................OK Pushing new configuration files to each Instance......................OK ... ttGridAdmin modelApply complete
ttGridAdmin modelApplyコマンドの詳細は、モデルに加えた変更の適用を参照してください。
次の例では、ttIsqlユーティリティを使用してdatabase1データベースに接続し、Oracleデータベースのterry.customers表からdatabase1データベースのterry.customers表に行をコピーします。
|
ノート: データベース・ユーザーに、組込みプロシージャでデータをコピーする目的の表に対するINSERT権限があること確認してください。 |
任意のデータ・インスタンスの要素への接続から、次を実行します。
Command> call ttLoadFromOracle('terry', 'customers', 'SELECT * FROM
terry.customers');
< 1000 >
1 row found.
ttLoadFromOracle組込みプロシージャの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttLoadFromOracleを参照してください。
localOnly=Yパラメータを指定してttLoadFromOracle組込みプロシージャをコールし、ローカル要素とそのレプリカにハッシュされた行をOracleデータベース表からTimesTen Scaleoutデータベース表にコピーします。localOnly=Yパラメータを使用した場合、ttLoadFromOracle組込みプロシージャでは、ローカル要素のレプリカではないリモート要素にハッシュされた行が無視されます。
次の例では、ttIsqlユーティリティを使用してdatabase1データベースに接続し、ローカル要素とそのレプリカにOracleデータベースのterry.customers表からハッシュされた行をdatabase1データベースのterry.customers表にコピーします。必要に応じて、アクティブ管理インスタンス(この例のアクティブ管理インスタンスはhost1.instance1)からttGridAdmin dbStatus -replicasetコマンドを使用すると、各レプリカ・セットに関連付けられているデータ・インスタンスの判別に役立ちます。
% ttGridAdmin dbStatus database1 -replicaset
Database database1 Replica Set status as of Thu Jan 11 13:17:29 PST 2018
RS DS Elem Host Instance Status Date/Time of Event Message
-- -- ---- ----- --------- ------ ------------------- -------
1 1 1 host3 instance1 opened 2018-01-10 14:34:43
2 2 host4 instance1 opened 2018-01-10 14:34:43
2 1 3 host5 instance1 opened 2018-01-10 14:34:42
2 4 host6 instance1 opened 2018-01-10 14:34:42
3 1 5 host7 instance1 opened 2018-01-10 14:34:42
2 6 host8 instance1 opened 2018-01-10 14:34:42
必ず、使用可能な各レプリカ・セットのいずれかのレプリカ(host3.instance1、host5.instance1、host7.instance1データ・インスタンスなど)で、ttLoadFromOracle組込みプロシージャを実行するようにしてください。
|
ノート: データベース・ユーザーに、組込みプロシージャでデータをコピーする目的の表に対するINSERT権限があること確認してください。 |
host3.instance1データ・インスタンスの要素への接続から、次を実行します。
Command> call ttLoadFromOracle('terry', 'customers', 'SELECT * FROM
terry.customers', 4, 'localOnly=Y');
< 339 >
1 row found.
|
ノート: この例では、host4.instance1データ・インスタンスの要素はhost3.instance1データ・インスタンスの要素のレプリカとして定義されており、host3.instance1データ・インスタンスの要素のcustomers表に挿入されたものと同じ行が、host4.instance1データ・インスタンスの要素のcustomers表に挿入されます。 |
host5.instance1データ・インスタンスの要素への接続から、次を実行します。
Command> call ttLoadFromOracle('terry', 'customers', 'SELECT * FROM
terry.customers', 4, 'localOnly=Y');
< 327 >
1 row found.
|
ノート: この例では、host6.instance1データ・インスタンスの要素はhost5.instance1データ・インスタンスの要素のレプリカとして定義されており、host5.instance1データ・インスタンスの要素のcustomers表に挿入されたものと同じ行が、host6.instance1データ・インスタンスの要素のcustomers表に挿入されます。 |
host7.instance1データ・インスタンスの要素への接続から、次を実行します。
Command> call ttLoadFromOracle('terry', 'customers', 'SELECT * FROM
terry.customers', 4, 'localOnly=Y');
< 334 >
1 row found.
|
ノート: この例では、host8.instance1データ・インスタンスの要素はhost7.instance1データ・インスタンスの要素のレプリカとして定義され、host7.instance1データ・インスタンスの要素のcustomers表に挿入されたものと同じ行が、host8.instance1データ・インスタンスの要素のcustomers表に挿入されます。 |
ttGridAdmin dbStatusコマンドまたはttLoadFromOracle組込みプロシージャの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのステータスのモニター(dbStatus)またはttLoadFromOracleをそれぞれ参照してください。
TimesTen Scaleoutでは、データベースは作成時にメモリーに自動的にロードされます。データベースは、メモリーにロードされると、明示的にアンロードされるまでメモリー内に残ります。データベースへのすべての接続を閉じても、データベースがメモリーから自動的にアンロードされることはありません。
データベースのアンロードが必要な場合がある1つの理由は、PermSize属性の値を増加するなど、初期接続属性の値を変更するためです。
メモリーからデータベースをアンロードするには、次のタスクを実行します。
ユーザー接続に対してデータベースを閉じます。ttGridAdmin dbCloseコマンドにより、データベースへの新しいユーザー接続を無効にします。
すべてのアプリケーションをデータベースから切断します。ttGridAdmin dbDisconnectコマンドは、データベースへのすべてのユーザー接続を終了します。
データベースをメモリーからアンロードします。ttGridAdmin dbUnloadコマンドにより、それぞれのホストのメモリーからデータベースの各要素をアンロードします。
ユーザー接続からdatabase1データベースをクローズします。
% ttGridAdmin dbClose database1 Database database1 close started
|
ノート: ttGridAdmin dbCloseコマンドでは、データベースへの既存の接続は閉じられず、かわりに、新しいユーザー接続の作成が禁止されます。開かれているすべての接続を個別に終了する必要があります。データベースのクローズは、要素ごとにそのデータ・インスタンスによって個別に実行される非同期操作です。
また、インスタンス管理者は、データベースがクローズされているかどうか関係なく、データベースへの新しい接続をいつでも作成できます。 |
database1データベースのすべての要素がユーザー接続に対してクローズされていることを確認します。
% ttGridAdmin dbStatus database1 -elements Database database1 element level status as of Tue Nov 27 13:35:45 PST 2018 Host Instance Elem Status Date/Time of Event Message ----- --------- ---- ------ ------------------- ------- host3 instance1 1 loaded 2018-11-27 13:35:43 host4 instance1 2 loaded 2018-11-27 13:35:43 host5 instance1 3 loaded 2018-11-27 13:35:43 host6 instance1 4 loaded 2018-11-27 13:35:43 host7 instance1 5 loaded 2018-11-27 13:35:43 host8 instance1 6 loaded 2018-11-27 13:35:43
|
ノート: ttGridAdmin dbStatusユーティリティでは、要素のステータスは、要素がユーザー接続に対してクローズされるとオープン済ではなくロード済として表示されます。 |
すべてのアプリケーションをdatabase1データベースから切断します。ワークロードを停止し、データベースからすべてのアプリケーションを正常に切断する必要があります。データベースからすべてのアプリケーションを個別に切断できない場合は、例5-11に示すように、ttGridAdmin dbDisconnectコマンドを使用してデータベースからすべてのユーザー接続を切断します。
例5-11 データベースからのアプリケーションの切断
この例では、すべてのオープン・トランザクションがコミットまたはロールバックされると、database1データベースからすべてのユーザー接続が切断されます。
% ttGridAdmin dbDisconnect database1 -transactional Database database1 dbDisconnect started
ttGridAdmin dbDisconnectStatusコマンドを使用して切断プロセスのステータスを確認します。
% ttGridAdmin dbDisconnectStatus database1
Database Host Instance Elem State Started
--------- ----- --------- ---- ------------ ------------------------
database1 Complete 2018-11-27T13:38:43.000Z
host3 instance1 1 Disconnected
host4 instance1 2 Disconnected
host5 instance1 3 Disconnected
host6 instance1 4 Disconnected
host7 instance1 5 Disconnected
host8 instance1 6 Disconnected
次に、ttGridAdmin dbStatusコマンドの-connectionsオプションを使用して、データベースへの接続がないことを確認します。
% ttGridAdmin dbStatus database1 -connections Host Instance ConnId Name Pid Type CHost CAddr CPid ---- -------- ------ ---- --- ---- ----- ----- ----
|
ノート: -transactionalオプションが失敗したか時間がかかりすぎる場合は、ttGridAdmin dbDisconnectコマンドの-immediateオプションを使用することで、すべてのオープン・トランザクションでロールバックを強制的に実行し、アプリケーションを切断します。
また、 |
database1データベースをアンロードします。
% ttGridAdmin dbUnload database1 Database database1 unload started
データベースのアンロードは、各データ・インスタンスによって個別に実行される非同期的な操作です。データベースへの開かれたユーザー接続がある場合、この操作ではエラーが返されます。
|
ノート: ttGridAdmin dbDisconnect -abortコマンドを使用した場合は、一部の要素が無効化されてttGridAdmin dbUnloadが失敗する可能性があります。ttGridAdmin dbUnloadコマンドの-forceオプションを使用して、アンロードを続行できるようにします。このオプションでは、データが失われる可能性があります。 |
例5-12に示すように、ttGridAdmin dbStatusコマンドを使用して、データベースのアンロード・プロセスのステータスを確認できます。
例5-12 データベースのアンロード・プロセスのステータスの確認
この例は、database1データベースのステータス・サマリーを示しています。レポートに、データベースのすべての要素がクローズ済およびアンロード済として表示されていることに注意してください。
% ttGridAdmin dbStatus database1 Database database1 summary status as of Tue Nov 27 13:41:18 PST 2018 created,unloaded,closed Completely created elements: 6 (of 6) Completely loaded elements: 0 (of 6) Completely created replica sets: 3 (of 3) Completely loaded replica sets: 0 (of 3) Open elements: 0 (of 6)
ttGridAdmin dbClose、ttGridAdmin dbDisconnect、ttGridAdmin dbDisconnectStatus、ttGridAdmin dbUnloadまたはttGridAdmin dbStatusコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのクローズ(dbClose)、すべての接続の強制切断(dbDisconnect)、強制切断のステータスの確認(dbDisconnectStatus)、データベースのアンロード(dbUnload)またはデータベースのステータスのモニター(dbStatus)をそれぞれ参照してください。
メモリーにデータベースを再ロードするには、次のタスクを実行します。
メモリーにデータベースをロードします。ttGridAdmin dbLoadコマンドにより、データベースの各要素をそれぞれのホストのメモリーにロードします。
ユーザー接続に対してデータベースをオープンします。ttGridAdmin dbOpenコマンドにより、ユーザー接続に対してデータベースを有効化します。
メモリーにdatabase1データベースのすべての要素をロードします。
% ttGridAdmin dbLoad database1 Database database1 load started
ユーザー接続に対してdatabase1データベースをオープンします。
% ttGridAdmin dbOpen database1 Database database1 open started
ttGridAdmin dbLoadまたはttGridAdmin dbOpenコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのメモリーへのデータベースのロード(dbLoad)またはデータベースのオープン(dbOpen)をそれぞれ参照してください。
接続属性には、それぞれの永続性に基づいて3つのタイプがあります。
データベースを作成するときに設定され、変更できない属性。これらの属性に割り当てる値は、データベース定義に格納します。
データベースをメモリーにロードするときに設定され、アンロードおよびメモリーへのデータベースの再ロード時に変更可能な属性。これらの属性に割り当てる値は、データベース定義に格納します。
データベースへの各接続によって設定され、その接続が継続している間保持される属性。これらの属性に割り当てる値は、接続可能オブジェクトに格納します。
次の各項では、データベースの格納場所に応じて、その接続属性を変更する方法について説明します。
データベース定義の変更とは、データベース定義でサポートされている接続属性の割リ当てられた値を変更することです。データベース定義でサポートされ、データベースの作成後に変更可能な接続属性のタイプは、次のとおりです。
初期接続属性
PL/SQLの初期接続属性
TimesTen Server接続属性
TimesTen Scaleoutにより、データベース定義で明示的に指定されていないサポートされるすべての属性にデフォルト値が割り当てられます。デフォルト値が割り当てられた属性は、データベース定義に属性を含めることで変更できます。データベース定義で定義されている属性を追加または変更して、現在のバージョンのモデルに変更を適用すると、TimesTen Scaleoutにより、すべてのデータ・インスタンスの構成ファイルが、データベース定義に関連付けられたDSNの新しい属性で上書きされます。
データベース定義でサポートされている属性に割り当てられた値を変更するには、次のタスクを実行します。
データベース定義を作成(または変更)するときに使用したファイルへのアクセス権がない場合、database1データベース定義の内容をファイルにエクスポートします。
% ttGridAdmin dbdefExport database1 /mydir/database1.dbdef
例5-13は、エクスポート・ファイルの内容を示しています。
例5-14に示すように、エクスポートされたデータベース定義ファイルで、PermSize属性の値を32768から49152に変更します。
変更されたデータベース定義ファイルの内容を、database1データベース定義にインポートします。
% ttGridAdmin dbdefModify /mydir/database1.dbdef Database Definition DATABASE1 modified.
database1データベース定義に加えた変更を、現在のバージョンのモデルに適用します。
% ttGridAdmin modelApply ... Updating grid state...................................................OK Pushing new configuration files to each Instance......................OK ... ttGridAdmin modelApply complete
メモリーからのデータベースのアンロードに示すようにdatabase1データベースをアンロードします。
メモリーへのデータベースの再ロードに示すように、database1データベースを再起動して、database1データベース定義に加えた変更を有効にします。
すべての接続属性の詳細は、Oracle TimesTen In-Memory Databaseリファレンスの接続属性を参照してください。
ttGridAdmin dbdefExport、ttGridAdmin dbdefModifyまたはttGridAdmin modelApplyコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベース定義のエクスポート(dbdefExport)、データベース定義の変更(dbdefModify)または最新バージョンのモデルの適用(modelApply)をそれぞれ参照してください。
接続可能オブジェクトの変更とは、接続可能オブジェクトでサポートされている接続属性の割り当てられた値を変更することです。接続可能オブジェクトでサポートされている接続属性のタイプは、次のとおりです。
一般接続属性
NLS一般接続属性
PL/SQL接続属性
TimesTen Client接続属性
TimesTen Scaleoutにより、接続可能オブジェクトで明示的に指定されていないサポートされるすべての属性にデフォルト値が割り当てられます。デフォルト値が割り当てられた属性は、接続可能オブジェクトに属性を含めることで変更できます。接続可能オブジェクトで定義されている属性を追加または変更して、現在のバージョンのモデルに変更を適用すると、TimesTen Scaleoutにより、すべてのデータ・インスタンスの構成ファイルが、接続可能オブジェクトに関連付けられたDSNの新しい属性で上書きされます。
接続可能オブジェクトでサポートされている属性に割り当てられた値を変更するには、次のタスクを実行します。
接続可能オブジェクトを作成(または変更)するときに使用したファイルへのアクセス権がない場合、database1CS接続可能オブジェクトの内容をファイルにエクスポートします。
% ttGridAdmin connectableExport database1CS /mydir/database1CS.connect
例5-15は、エクスポート・ファイルの内容を示しています。
例5-16に示すように、エクスポートされた接続可能オブジェクト・ファイルで、SQLQueryTimeout接続属性の値を300に変更します。
変更された接続可能オブジェクト・ファイルの内容を、database1CS接続可能オブジェクトにインポートします。
% ttGridAdmin connectableModify /mydir/database1CS.connect Connectable DATABASE1CS modified.
database1CS接続可能オブジェクトに加えた変更を、現在のバージョンのモデルに適用します。
% ttGridAdmin modelApply ... Updating grid state...................................................OK Pushing new configuration files to each Instance......................OK ... ttGridAdmin modelApply complete
すべての接続属性の詳細は、Oracle TimesTen In-Memory Databaseリファレンスの接続属性を参照してください。
ttGridAdmin connectableExport、ttGridAdmin connectableModifyまたはttGridAdmin modelApplyコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスの接続可能オブジェクトのエクスポート(connectableExport)、接続可能オブジェクトの変更(connectableModify)または最新バージョンのモデルの適用(modelApply)をそれぞれ参照してください。
破棄プロセスではデータが廃棄されるため、データベースの破棄を試行する前に、すべてのデータをバックアップしたことを確認してください。TimesTen Scaleoutのデータをバックアップする方法の詳細は、データベースのバックアップおよびリストアを参照してください。
ttGridAdmin dbDestroyコマンドでは、データベースを破棄するために、次の操作が実行されます。
すべてのデータ・インスタンスに格納されているデータベースのチェックポイント・ファイルとログ・ファイルが削除されます。
データベースの作成を記録したエントリを含め、データベースのステータスを追跡する管理インスタンス内のエントリが削除されます。
ただし、データベースを破棄する前に、データベースをアンロードする必要があります。詳細は、メモリーからのデータベースのアンロードを参照してください。
database1データベースを破棄します。
% ttGridAdmin dbDestroy database1 Database DATABASE1 destroy started
また、データベースに関連付けられているデータベース定義を削除することが必要な場合もあります。ttGridAdmin dbdefDeleteコマンドにより、最新バージョンのモデル内のデータベース定義を削除します。このコマンドでは、データベース定義に関連付けられるすべての接続可能オブジェクトも削除されます。
最新バージョンのモデルから、database1データベース定義とその関連接続可能オブジェクトを削除します。
% ttGridAdmin dbdefDelete database1 Database Definition database1 deleted
database1データベース定義の削除を、現在のバージョンのモデルに適用します。
% ttGridAdmin modelApply ... Pushing new configuration files to each Instance......................OK ... ttGridAdmin modelApply complete
TimesTen Scaleoutにより、データベース定義とその接続可能オブジェクトがグリッドから削除されます。
ttGridAdmin dbDestroy、ttGridAdmin dbdefDeleteまたはttGridAdmin modelApplyコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースの破棄(dbDestroy)、データベース定義の削除(dbdefDelete)または最新バージョンのモデルの適用(modelApply)をそれぞれ参照してください。
