| Oracle® TimesTen In-Memory Databaseオペレーション・ガイド 11gリリース2 (11.2.2) B66441-07 |
|
 前 |
 次 |
TimesTenデータベースは、表、ビュー、順序などの要素の集合です。TimesTenデータベースはSQLを使用してアクセスし、操作できます。データベースが存在しない場合、インスタンス管理者がデータベースに接続する際に指定した属性を使用して、TimesTenによってデータベースが作成されます。TimesTenデータベースへの既存の接続をすべて切断することで、データベースの共有メモリー・セグメントを解放できます。
TimesTenデータベースの構成および管理は接続定義の属性に含まれているため、この章では、まずTimesTenデータベース接続の構成方法について説明します。
一度データベースを作成すると、次の処理を実行できます。
ttIsqlユーティリティを使用したデータべースへの接続およびSQLファイルの実行または対話型SQLセッションの開始(「バッチ・モードと対話モード」を参照)。
データベースを使用するアプリケーションの実行。
主な内容は次のとおりです。
Oracle TimesTen Application-Tier Database Cache概要のTimesTenの接続オプションに関する説明に記載されているとおり、アプリケーションではTimesTen ODBCドライバを使用して、TimesTenデータベースにアクセスします。アプリケーションでは、提供されているインタフェースを介してODBCダイレクト・ドライバ、Windows ODBCドライバ・マネージャ、ODBCクライアント・ドライバまたはODBCドライバを間接的に使用し、TimesTenデータベースにアクセスできます。
図1-1に、アプリケーションで様々なドライバおよびインタフェースを使用して、TimesTenデータベースにアクセスする方法を示します。
Cアプリケーションでは、TimesTen ODBCドライバと直接リンクしたり、Windows ODBCドライバ・マネージャとリンクしたり、ODBCドライバにアクセスするOCIまたはPro*C/C++インタフェースを使用して、TimesTenと対話します。
Javaアプリケーションでは、JDBCライブラリをロードして、TimesTenと対話します。
C++アプリケーションでは、TimesTenで提供されるクラス・セット(TTClasses)、またはODBCドライバにアクセスするOCIまたはPro*C/C++インタフェースを使用して、TimesTenと対話します。
C#アプリケーションはTimesTenデータベース用のOracle Data Provider for .NETサポートを介してTimesTenと対話します。
次の点について考慮します。
ODBCドライバに直接リンクするアプリケーションでは、ダイレクト・ドライバにリンクしているか、クライアント・ドライバにリンクしているかにかかわらず、リンクしているドライバのみ使用できます。いずれかのTimesTenドライバに直接リンクするアプリケーションでは、複数のデータベースに同時に接続できます。
TimesTenダイレクト・ドライバでは、複数のTimesTenデータベース(すべて同じバージョンのTimesTen)への複数の接続がサポートされています。
TimesTenクライアント・ドライバ(クライアント/サーバー接続を支援するために使用)では、複数のTimesTenデータベース(それぞれが異なるバージョンのTimesTenでも可能)への複数の接続がサポートされています。
このオプションの場合、ドライバ・マネージャにリンクする場合と比較すると、柔軟性は低くなりますがパフォーマンスは向上します。
ドライバが別のデータベース用である場合でも、同じアプリケーション内で複数のODBCドライバとアプリケーションをリンクできます。アプリケーションが複数のODBCドライバをロードする場合、アプリケーションでWindows ODBCドライバ・マネージャなどのドライバ・マネージャを使用する必要があります。
また、TimesTenダイレクト・ドライバおよびTimesTenクライアント・ドライバの両方を使用する必要がある場合は、複数のドライバが必要になることがあります。
Windows ODBCドライバ・マネージャは、実行時にODBCドライバを動的にロードします。ただし、ODBCドライバ・マネージャを使用する場合は、ランタイム・オーバーヘッドが増大し、アプリケーションのパフォーマンスに影響が出る場合があるため、ODBCドライバ・マネージャを使用する利点を十分検討してください。
|
注意: ODBCドライバ・マネージャを使用しているアプリケーションで、XLAは使用できません。 |
TimesTenドライバ・マネージャを使用するアプリケーションのコンパイル方法の詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』のアプリケーションのコンパイルおよびリンクに関する説明、『Oracle TimesTen In-Memory Database Java開発者ガイド』のJavaアプリケーションのコンパイルに関する説明および『Oracle TimesTen In-Memory Database TTClassesガイド』のアプリケーションのコンパイルおよびリンクに関する説明を参照してください。
次の項では、TimesTenデータベースの定義方法について説明します。
TimesTenには次のODBCドライバが含まれています。
TimesTen Data Managerドライバ: 直接接続のアプリケーションで使用するTimesTen ODBCドライバ。
TimesTenクライアント・ドライバ: クライアント/サーバー・アプリケーションで使用するTimesTen Client ODBCドライバ。
TimesTenには、次の2つのバージョンのData Manager ODBCドライバが含まれています。
本番: ほぼすべてのアプリケーション開発およびすべてのデプロイメントには、本番バージョンのTimesTen Data Managerドライバを使用します。
デバッグ: デバッグ・バージョンのTimesTen Data Managerドライバは、TimesTenで問題が発生した場合にのみに使用します。このバージョンは、内部エラーのチェックも行うため、本番バージョンより処理が遅くなります。UNIXの場合は、追加のデバッグ情報を表示するために、TimesTenデバッグ・ライブラリを-gオプションでコンパイルします。
Windowsの場合、本番バージョンのTimesTen Data Managerがデフォルトでインストールされます。デバッグ・バージョンをインストールするには、「Custom」セットアップを選択します。TimesTen Clientドライバをインストールするには、「Typical」または「Custom」のいずれかを選択します。
表1-1に、Windows用のODBCドライバを示します。
表1-1 Windowsプラットフォーム用に提供されているODBCドライバ
| 環境 | バージョン | 名前 |
|---|---|---|
|
Windows |
本番 |
TimesTen Data Manager 11.2.2 Driver。 |
|
Windows |
デバッグ |
TimesTen Data Manager 11.2.2 Debug Driver。 |
|
Windows |
クライアント |
TimesTen Client 11.2.2 Driver。 |
UNIXの場合、インストール時に選択したオプションに応じて、TimesTenは、クライアント・ドライバまたは本番バージョンおよびデバッグ・バージョンのTimesTen Data Manager ODBCドライバがインストールされることがあります。
表1-2に、UNIXプラットフォーム用のTimesTen ODBCドライバを示します。
表1-2 UNIXプラットフォーム用に提供されているODBCドライバ
| 環境 | バージョン | 場所および名前 |
|---|---|---|
|
Solaris Linux |
本番 |
TimesTen Data Manager 11.2.2 Driver。 |
|
Solaris Linux |
デバッグ |
TimesTen Data Manager 11.2.2 Debug Driver。 |
|
Solaris Linux |
クライアント |
TimesTen Client 11.2.2 Driver。 |
|
AIX |
本番 |
TimesTen Data Manager 11.2.2 Driver。 |
|
AIX |
デバッグ |
TimesTen Data Manager 11.2.2 Debug Driver。 |
|
AIX |
クライアント |
TimesTen Client 11.2.2 Driver。 |
JDBCを使用すると、JavaアプリケーションからTimesTenにSQL文を実行し、結果を処理できるようになります。これは、Javaプログラミング言語でデータにアクセスする主要なインタフェースです。JDBCは、TimesTenのインストール時にTimesTen Data Managerとともにインストールされます。
図1-1に示すとおり、TimesTen JDBCドライバは、ODBCドライバを使用してTimesTenデータベースにアクセスします。このドライバは、JDBCメソッドごとに一連のODBC関数を実行して適切な処理を行います。JDBCはすべてのデータベース処理でODBCに依存するため、JDBCを使用する場合の最初の手順は、TimesTenデータベースおよびJDBCのかわりにTimesTenデータベースにアクセスするODBCドライバの定義になります。
TimesTen JDBC APIは、TimesTenネイティブAPIにブリッジするためのネイティブ・メソッドを使用して実装され、複数のドライバが異なるデータベースに接続できるドライバ・マネージャを備えています。DriverManagerクラスのJDBCドライバ・マネージャは、ロード済で、Javaアプリケーションで使用可能なすべてのJDBCドライバの情報を追跡します。Javaアプリケーションを使用すると、複数のドライバのロードおよび各ドライバへの個別接続を実行できます。たとえば、TimesTen Client JDBCドライバおよびTimesTenダイレクト・ドライバの両方を1つのアプリケーションでロードできます。その後、Javaアプリケーションによって、ローカル・システムまたはリモート・システムのいずれかのデータベースに接続できます。
TimesTenでサポートされているJava関数のリストは、『Oracle TimesTen In-Memory Database Java開発者ガイド』のjava.sqlパッケージのインタフェースのサポートに関する説明を参照してください。
アプリケーションから接続する場合は、データソース名(DSN)を使用して、接続先となる特定のTimesTenデータベースを一意に識別します。具体的に、DSNは、TimesTenデータベースを識別する名前(文字列)で、データベースへの接続時に使用する接続属性の集まりです。Windowsの場合、データベースへのアクセスに使用するODBCドライバもDSNで指定します。
また、ユーザーまたはアプリケーションのいずれかがDSNを指定しなかった場合や接続時にodbc.iniファイルに定義されていなかったDSNを指定した場合に使用可能なデフォルトDSNを定義することもできます。詳細は、「デフォルトDSNの設定」を参照してください。
|
注意: ユーザーが、権限のない接続属性(初期接続属性など)を持つDSNを使用しようとすると、エラーが表示されます。初期接続属性の権限の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の接続属性に関する説明を参照してください。 |
DSNではTimesTenデータベースを一意に識別しますが、データベースは複数のDSNが参照できます。このような一意のDSN間で異なる点は、データベースへの接続属性の指定です。これによって、1つのデータベースの様々な接続構成に対してわかりやすい名前が付きます。
|
注意: ODBC標準に従うと、ある属性が接続文字列内に複数回出現する場合、指定されている最初の値が使用され、後続値は使用されません。 |
最大長は32文字です。
大文字と小文字は区別されません。
()[]{},;?*=!@\/を除くASCII文字で構成されます。
TimesTenではDSNの一部としてスペースを使用することを推奨しません。DSNにスペースが含まれている場合、一部のTimesTenユーティリティはスペースに遭遇したところでDSNを切り捨てます。さらに、DSNをスペースで開始または終了したり、スペースのみで構成することはできません。
次の項では、DSNの構成および管理方法について説明します。
DSNは2層の命名システムで解決され、TimesTenはまず定義済ユーザーDSN内で、次に定義済システムDSNでDSNの解決を試みます。
ユーザーDSNは、このDSNを作成したユーザーのみが使用できます。
Windowsの場合、ユーザーDSNは「ODBC データソース アドミニストレータ」の「ユーザー DSN」タブで定義します。
UNIXでは、ユーザーDSNはユーザーのodbc.iniファイルで定義します。TimesTenによるこのファイルの特定では、まずファイルがODBCINI環境変数で指定されているかを検索します。ない場合、TimesTenは$HOME/.odbc.iniファイルを特定します。
ユーザーDSNは、作成したユーザーのみが使用できますが、使用を制限されるのはDSN(文字列名およびその属性)のみです。基礎となるデータベースは、他のユーザーのユーザーDSNまたはシステムDSNで参照できます。
TimesTenでは、TimesTen Data ManagerとTimesTen Clientの両方のデータソースを.odbc.iniファイルでサポートしています。
システムDSNは、TimesTenデータベースへの接続用にシステムDSNが定義されているシステム上ですべてのユーザーが使用できます。
Windowsの場合、システムDSNは、「ODBC データソース アドミニストレータ」の「システム DSN」タブで定義します。
UNIXの場合、システムDSNは、システムodbc.iniファイルと呼ばれるsys.odbc.iniファイルに定義されます。TimesTenはシステムDSNファイルの場所を次の順序で特定します。
ファイルがSYSODBCINI環境変数で指定されている場合、そのファイルが特定されます。
root以外のインストールでは、ファイルはinstall_dir/info/sys.odbc.iniにあります。rootインストールでは、/var/TimesTen/InstanceName/sys.odbc.iniにあります。
rootまたはroot以外の場所のいずれでも見つからない場合、TimesTenは/var/TimesTen/sys.odbc.iniファイルを検索します。
これらのいずれの場所でも見つからない場合、TimesTenはシステム上で/etc/odbc.iniファイルを参照します。
DSNは、ローカル・データベースやリモート・データベースを一意に識別するために作成します。直接接続またはクライアント/サーバー接続用に使用するDSNのタイプを次に説明します。
Data Manager DSN: ローカル・データベースを指定するDSNは、ダイレクト・ドライバであるTimesTen Data Manager ODBCドライバを使用します。本番バージョンまたはデバッグ・バージョンのTimesTen Data Managerドライバを使用できます。
Data Manager DSNは、パス名およびファイル名の接頭辞を使用してデータベースを参照します。データベースのパス名は、C:\data\chns\AdminDSや/home/chns/AdminDSなど、データベースが格納されているディレクトリの場所およびデータベースの接頭辞を示します。
|
注意: このパス名および接頭辞は、ファイル名を定義するものではなく、データベースが格納されているディレクトリの場所およびすべてのデータベース・ファイルの接頭辞を示しています。データベースが使用する実際のファイルにはC:\data\chns\AdminDS.ds0や/home/chns/AdminDS.log2など接尾辞が付きます。 |
指定したTimesTenデータベースを参照するData Manager DSNは、データベースが存在するシステムと同じシステムで定義する必要があります。TimesTenによって、各データベースにdsName.resnファイルが作成されます。これらのファイルは、ログを維持するためにTimesTenによって内部的に使用されます。
同じデータベースを複数のData Manager DSNで参照している場合、他のパス名で同じ場所を識別できても、必ず同一のデータベース・パス名を使用する必要があります。たとえば、1つのDSNでデータベースを参照するシンボリック・リンクを使用し、別のDSNで実際のパス名を使用することはできません。Windowsの場合、マップしたドライブ文字はデータベースのパス名に指定できません。
クライアントDSN: クライアントDSNではリモート・データベースを指定し、TimesTenクライアントを使用します。クライアントDSNは、hostname、DSNのペアを指定して間接的にTimesTenデータベースを参照します(ここで、hostnameはTimesTenサーバーが実行しているサーバー・システムを表し、DSNはサーバー・ホスト上のTimesTenデータベースを指定するサーバーDSNを表します)。
サーバーDSN: サーバーDSNは常にシステムDSNとして定義され、クライアント・アプリケーションがアクセス可能な、そのサーバー上の各データベースのサーバー・システム上で定義されます。サーバーDSNの形式および属性は、Data Manager DSNのものと似ています。
UNIXの場合、特定のユーザーが作成したすべてのユーザーDSN(クライアントDSNおよびData Manager DSNの両方)は、同じユーザーodbc.iniファイルで定義されます。同様に、すべてのシステムDSNは同じシステムodbc.iniファイルで定義されます。
次の表に、TimesTenでサポートされているDSNタイプ、ユーザーDSNとシステムDSNのいずれを作成するか、およびDSNの場所を示します。
| DSNタイプ | ユーザーDSNかシステムDSNか | DSNの場所 |
|---|---|---|
| Data Manager DSN | ユーザーDSNまたはシステムDSN | データベースがあるシステム上にあります。 |
| クライアントDSN | ユーザーDSNまたはシステムDSN | 任意のローカルまたはリモート・システム上にあります。 |
| サーバーDSN | システムDSN | データベースがあるシステム上にあります。 |
クライアントDSNおよびサーバーDSNの詳細は、「TimesTen ClientおよびTimesTen Serverの使用方法」を参照してください。
TimesTen Data Manager DSNまたはサーバーDSN属性には次の4つのタイプがあります。
|
注意: すべての属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の接続属性に関する説明を参照してください。 |
データ・ストア属性は、データベースの作成時にデータベースに関連付け、その後の接続では変更できません。変更するには、データベースを破棄して作成しなおす必要があります。
最もよく使用されるデータ・ストア属性は、次のとおりです。
DataStore: データベースのディレクトリ名およびファイル名の接頭辞。
LogDir: データベースのトランザクション・ログ・ファイルのディレクトリ名。デフォルトでは、トランザクション・ログ・ファイルはチェックポイント・ファイル・ディレクトリに入っています。トランザクション・ログ・ファイルおよびチェックポイント・ファイルを別々のディスクに保存すると、システムのスループットが向上する場合があります。
DatabaseCharacterSet: ストレージ・エンコーディングを定義する必須のキャラクタ・セット指定。
初期接続属性は、TimesTenデータベースがメモリーにロードされる際に使用されます。初期接続属性の設定でデータベースをロードできるのは、インスタンス管理者のみです。デフォルトでは、最初の接続が確立されたときにはアイドル・データベース(接続のないデータベース)がメモリーにロードされます。これらの属性は、データベースへの最後の接続がクローズされるまで、後続のすべての接続で保持されます。初期接続属性は、TimesTenデータベースをアンロードしてから、インスタンス管理者が初期接続属性に異なる値を使用して再接続しないかぎり、変更できません。
最もよく使用される初期接続属性は、次のとおりです。
PermSize: データベースの永続メモリー領域の割当て済サイズを構成します。永続メモリー領域には、永続データベース要素が含まれています。TimesTenでは、チェックポイント処理の際に、永続メモリー領域のみがディスクに書き込まれます。
TempSize: データベースの一時メモリー領域の割当て済サイズを構成します。一時メモリー領域には、文の実行時に生成された一時データが含まれます。
一般接続属性は、接続のたびに設定され、その接続期間中のみ保持されます。各同時接続には別の値を設定できます。
最もよく使用される一般接続属性は、次のとおりです。
UID: 直接またはクライアント/サーバー接続を使用してデータベースへの接続に使用されるユーザー名を指定します。インスタンス管理者として、または外部ユーザーとして接続する場合、ユーザー名を指定する必要はありません。ユーザー名を指定しない場合、TimesTenはUIDがオペレーティング・システムで指定されたユーザー名であると想定します。
PWD: 指定されているUIDに対応するパスワードを指定します。内部ユーザーの場合、指定したDSNのodbc.iniファイルで、または接続文字列でPWD属性を設定しないと、パスワードを要求されます。外部ユーザーの場合は、オペレーティング・システムによって検証されるので、パスワードを指定する必要はありません。
クライアント/サーバー接続を開始すると、接続用に送信されるパスワードはすべて、クライアント/サーバー・プロトコルで暗号化されます。
|
注意: UIDとPWDの一般接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のUIDとPWDに関する項を参照してください。インスタンス管理者、外部ユーザー、内部ユーザーの詳細は、「ユーザー管理による認証の制御」を参照してください。 |
PWDCrypt: 指定したUIDに対応する、暗号化されたパスワードを指定します。
TimesTenキャッシュ属性では、TimesTenにロードされるデータのロード元であるOracle DatabaseインスタンスのOracleサービス識別子を入力できます。
Windowsの場合、「ODBC データソース アドミニストレータ」で属性を指定します。
UNIXの場合、odbc.iniファイルで属性を指定します。odbc.iniファイルに指定されていない属性に対しては、デフォルト値が使用されます。
次の項では、次のいずれかのプラットフォームでData Manager DSNを作成する方法について説明します。
次の項では、WindowsでDSNを作成する方法について説明します。
「ODBC データソース アドミニストレータ」でODBCドライバを指定します。
Windowsデスクトップで、「スタート」→「設定」→「コントロール パネル」→「管理ツール」→「データ ソース (ODBC)」を選択します。「ODBC データソース アドミニストレータ」が開きます。
|
注意: 64ビットのWindowsシステムで32ビットのTimesTenインストールを使用している場合、次の実行可能ファイルから32ビットのODBC Data Source Administratorを起動してください。C:\WINDOWS\SysWOW64\odbcad32.exe |
ユーザーDSNまたはシステムDSNのどちらを作成するか選択します。ユーザーDSNおよびシステムDSNについては、「ユーザーDSNおよびシステムDSNの概要」を参照してください。
次のいずれかを実行します。
既存のTimesTenデータソースを選択して、「構成」をクリックします。
「追加」をクリックします。次に、適切なTimesTenドライバをリストから選択します。「完了」をクリックします。これによって、「TimesTen ODBC Setup」ダイアログ・ボックスが表示されます。
「TimesTen ODBC Setup」ダイアログ・ボックスの「Data Store」タブで、データソース名(DSN)、データベース・ディレクトリのパスと接頭辞、およびデータベース・キャラクタ・セットを指定します。データベース・ディレクトリのパスは、マップしたドライブを参照できません。図1-2を参照してください。
DSN、データベース・パス、接頭辞の詳細は、「TimesTenデータベースを識別するためのデータソース名の指定」を参照してください。データベース・キャラクタ・セットについては、「データベース・キャラクタ・セットの選択」を参照してください。説明フィールドはオプションです。
図1-3、図1-4および図1-5で示すとおり、「TimesTen ODBC Setup」ダイアログ・ボックスの「First Connection」タブ、「General Connection」タブ、「NLS Connection」で適切な接続属性を指定します。さらに、Oracle DatabaseにTimesTen Cacheを使用している場合は、図1-6に示す接続属性を指定します。マルチスレッドのクライアント/サーバー構成を使用している場合は、図1-7に示す接続属性を指定します。
|
注意: 接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の接続属性に関する説明を参照してください。 |
終了後、「OK」をクリックします。
この項の内容は次のとおりです。
UNIXの場合、ユーザーDSNは、$HOME/.odbc.iniファイルまたはODBCINI環境変数に指定したファイルで定義します。このファイルは、ユーザーodbc.iniファイルと呼ばれます。システムDSNは、install_dir/info/sys.odbc.ini内のシステムodbc.iniファイルで定義します。
ユーザーおよびシステムのodbc.iniファイルの構文は同じです。構文は、「odbc.iniファイル・エントリの説明」で説明されています。システムodbc.iniファイルは、TimesTenをマシンにインストールすると作成されます。ユーザーodbc.iniファイルはユーザーが独自に作成する必要があります。
DSNを作成するには、次の手順を実行します。
odbc.iniファイルでDSNを指定します。DSNは、DSN定義の最初に大カッコで囲み1行で指定します。次に例を示します。
[AdminDS]
TimesTenドライバを設定するには、odbc.iniファイルでDRIVER属性を指定します。次の例では、このDSNが使用されるように設定されているTimesTen ODBCドライバを示します。
[AdminDS]
DRIVER=install_dir/lib/libtten.so
odbc.iniファイルで、データベース・ディレクトリのパスおよび接頭辞を指定します。次の例では、/users/robinをデータベース・ディレクトリのパス、FixedDsをデータベース・ファイルの接頭辞に指定しています。
DataStore=/users/robin/FixedDs
「データベースのパス名での環境変数の使用方法」で説明するとおり、データベース・ディレクトリのパスには環境変数を使用できます。
データベース・キャラクタ・セットを選択します。次の例では、odbc.iniファイルのデータベース・キャラクタ・セットをUS7ASCIIと定義しています。
DatabaseCharacterSet=US7ASCII
odbc.iniファイルに接続属性を設定します。odbc.iniファイルに指定されていない属性に対しては、デフォルト値が使用されます。
データベースのパス名およびトランザクション・ログ・ファイルのパス名の指定に環境変数を使用できます。たとえば、データベースの場所に$HOME/AdminDSを指定できます。
環境変数は、$varnameまたは$(varname)で表現できます。カッコはオプションです。データベースのパス名のバックスラッシュ(\)は、後続の文字をエスケープします。
|
注意: 環境変数の展開では、データベースに接続しているプロセスの環境を使用します。異なるプロセスでは、同じ環境変数に対して異なる値を指定できるため、データベースのパス名を様々に展開することができます。環境変数は、ユーザーodbc.iniファイルでのみ使用できます。システムodbc.iniファイルでは指定できません。 |
各プラットフォームにクライアント・サーバーDSNを定義する方法の詳細は、「TimesTen ServerシステムでのサーバーDSNの定義」と「TimesTen ClientシステムでのクライアントDSNの作成」を参照してください。
TimesTenでは、特定のDSNを解決する際、次の処理が実行されます。
|
注意:
|
次のファイル内で指定された名前のユーザーDSNを検索します。
ODBCINI環境変数で参照されるファイル(環境変数が設定されている場合)。
ユーザーのホーム・ディレクトリ内の.odbc.iniファイル(ODBCINI環境変数が設定されていない場合)。
一致するユーザーDSNが検出されない場合は、指定した名前を持つシステムDSNを検索します。
SYSODBCINI環境変数で参照されるファイル(この環境変数が設定されている場合)。
デーモンのホーム・ディレクトリ内のsys.odbc.iniファイル(SYSODBCINI環境変数が設定されていない場合)。
UNIXの場合、非rootインストールでは、ファイルはinstall_dir/info/sys.odbc.iniに入っています。また、rootインストールでは、/var/TimesTen/InstanceName/sys.odbc.iniまたは/var/TimesTen/sys.odbc.iniに入っています。
この項では、データベースの設定方法に関する追加の例を示します。
例ごとに、Windowsの「ODBC データソース アドミニストレータ」の設定およびその設定に対応するUNIXのodbc.iniエントリについて説明します。
必要に応じてデフォルトのデータソース定義を追加することもできます。接続時にアプリケーションでodbc.iniファイルにないDSNが指定された場合やアプリケーションでDSNが指定されなかった場合、TimesTenデータベースへの接続はデフォルトDSNを使用して構成されます。
デフォルトのデータソースを定義する際には、名前をdefaultにする必要があります。「DSN 仕様」で説明しているとおり、デフォルトDSNはその他のデータソースと同じ属性を使用して定義できます。
|
注意: Windowsプラットフォームでは、「ODBCデータ ソース アドミニストレーター」を使用してデフォルトDSNを作成する場合、「ユーザーDSN」、「システムDSN」、「ファイルDSN」のそれぞれのタブに1つずつしかDSNを指定できません。デフォルトDSNをODBCドライバと関連付ける必要があります。 |
接続時、TimesTenは次のいずれかのシナリオでデフォルトDSNを使用します。
接続文字列にキーワードと値のペアDSN=defaultを指定した場合。
接続文字列のDSN接続属性に未定義の値を指定した場合。
接続文字列のDSN接続属性に値を指定しなかった場合。
ただし、一般的には特定のデータソースを使用して接続するのが最善です。
デフォルトDSNを使用する場合、ttDestroyユーティリティによるデータベース破棄などDSN名を必要とするTimesTenユーティリティ操作を実行する際に、DSN名としてdefaultと入力してください。
次の例は、ユーザーがttIsqlを呼び出して、未定義のDSNで接続しているところを示します。odbc.iniファイルのdoesNotExistに定義がないため、TimesTenはdefault DSNを使用してデータベースを作成し、そのデータベースに接続を開始します。 この例はまた、DSNにdefaultを指定してttStatusとttDestroyの両方のユーティリティを呼び出しているユーザーも示します。さらに、ユーザーがDSNとしてdefaultのかわりにdoesNotExistを指定した場合のエラーも示します。
$ ttIsql doesNotExist; Copyright (c) 1996-2011, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=doesNotExist"; Connection successful: Command> exit Disconnecting... Done. ]$ ttStatus default TimesTen status report as of Mon Oct 22 12:27:52 2012 Daemon pid 13623 port 16138 instance myhost TimesTen server pid 13632 started on port 16140 ------------------------------------------------------------------------ Data store /timesten/install/info/default There are no connections to the data store Replication policy : Manual Cache Agent policy : Manual PL/SQL enabled. ------------------------------------------------------------------------ Accessible by group xyz End of report $ ttDestroy doesNotExist; Failed to destroy data store: Specified DSN is not found in user and system odbc.ini files (or registry) $ ttDestroy default;
次の例は、デフォルトDSN用の接続属性を構成する方法を示します。必須ではありませんが、他のDSNと同様の方法で、デフォルトDSN用の接続属性を構成できます。これは「ODBC Data Sources」の項には指定されていません。
[ODBC Data Sources] sampledb_1122=TimesTen 11.2.2 Driver ... [default] Driver=install_dir/lib/libtten.so DataStore=install_dir/info/DemoDataStore/default PermSize=40 TempSize=64 DatabaseCharacterSet=US7ASCII [sampledb_1122] Driver=install_dir/lib/libtten.so DataStore=install_dir/info/DemoDataStore/sampledb_1122 PermSize=40 TempSize=32 PLSQL=1 DatabaseCharacterSet=US7ASCII
この例では、一時データベースを設定する方法について説明します。一時データベースの詳細は、「データベースの概要」の説明を参照してください。
Windowsの場合、「TimesTen ODBC Setup」ダイアログ・ボックスで一時データベースを設定できます。図1-9および図1-10を参照してください。
UNIXで一時データベースを設定するには、odbc.iniファイルで次のエントリを作成します。すべてのUNIXプラットフォームのドライバのリストは、「TimesTen ODBCドライバを使用した接続」の表を参照してください。
大カッコで囲まれたテキストは、データソース名です。
[TempDs]
Driver=install_dir/lib/libtten.so
DataStore=/users/robin/TempDs
#this is a temporary database
Temporary=1
#create database if it is not found
AutoCreate=1
#log database updates to disk
LogPurge=1
DatabaseCharacterSet=US7ASCII
PL/SQL一般接続属性の値を指定できます。
|
注意: すべてのPL/SQL接続属性の完全なリストは、『Oracle TimesTen In-Memory Databaseリファレンス』の接続属性に関する説明を参照してください。 |
PL/SQL接続属性には次のものがあります。
PLSQL_OPTIMIZE_LEVEL: PL/SQLライブラリ・ユニットのコンパイルに使用する最適化レベルを設定します。
PLSQL_MEMORY_ADDRESS: TimesTenダイレクト・ドライバを使用する各プロセスにPL/SQL共有メモリー・セグメントがロードされる場所を示す仮想アドレス(16進値)を指定します。このメモリー・アドレスは、データベースへのすべての接続、およびデータベースに接続するすべてのプロセスで同じである必要があります。
次の例では、PLdsn DSNを作成し、PLSQLを1に設定してPL/SQLを有効にし、PL/SQL共有メモリー・セグメントのサイズを32MBに設定します。
[PLdsn] Datastore=/users/user1/PLdsn PermSize=32 DatabaseCharacterSet=AL32UTF8 ConnectionCharacterSet=AL32UTF8 PLSQL=1 PLSQL_MEMORY_SIZE=32
この他の例は、『Oracle TimesTen In-Memory Database PL/SQL開発者ガイド』のPL/SQL接続属性に関する説明を参照してください。
異なる接続属性を持ち、同じデータベースを参照する複数のDSNを作成できます。
この例では、AdminDSNおよびGlobalDSNの2つのDSNを作成します。これらのDSNは、接続キャラクタ・セット以外は同じです。US7ASCIIキャラクタ・セットを使用するアプリケーションは、AdminDSNを使用することによってTTDSデータベースに接続できます。マルチバイト文字を使用するアプリケーションは、GlobalDSNを使用してTTDSデータベースに接続できます。
Windowsの場合、ODBCデータソース・アドミニストレータを使用して、図1-11に示すようにAdminDSNを定義します。AdminDSNは、AL32UTF8データベース・キャラクタ・セットを使用して作成されます。図1-12は、US7ASCIIがAdminDSNの接続キャラクタ・セットであることを示しています。
図1-13に示すように、GlobalDSNもAL32UTF8データベース・キャラクタ・セットを使用して作成されます。図1-14は、GlobalDSNの接続キャラクタ・セットがAL32UTF8であることを示しています。
次の例では、UNIXでDSNを指定する方法を示しています。ここでは、Solaris用のTimesTen Data Manager ODBCドライバを使用します。
大カッコで囲まれたテキストは、データソース名です。
[AdminDSN] Driver=install_dir/lib/libtten.so Datastore=/data/TTDS DatabaseCharacterSet=AL32UTF8 ConnectionCharacterSet=US7ASCII [GlobalDSN] Driver=install_dir/lib/libtten.so DataStore=/data/TTDS DatabaseCharacterSet=AL32UTF8 ConnectionCharacterSet=AL32UTF8
次の項では、odbc.iniファイルのエントリについて説明します。
オプションのODBC Data Sourcesセクションの各エントリは、データソースおよび使用するドライバの記述が示されます。このデータソース・セクションの形式は、次のとおりです。
[ODBC Data Sources] DSN=driver-description
DSNは必須で、ドライバが接続するデータソースを識別します。この名前を選択します。
driver-descriptionは必須です。これは、データソースに接続するドライバについての説明です。
オプションのData SourcesセクションがTimesTen ServerのシステムDSNファイルに含まれる場合、クライアントDSNの設定時に使用されます。すべてのシステムDSNは、TimesTen Serverで使用できるすべてのDSNを表示する、クライアントのODBCデータソース・アドミニストレータ用のクライアントDSN設定に使用できます。ユーザーは、いつでもODBC データソース アドミニストレータで新しいシステムDSNを追加できます。DSNをシステムDSNファイルに追加する場合は、クライアントに公開できるDSNのみを含めるようにしてください。すべてのシステムDSNは、公開されていないものも、クライアント/サーバー構成からアクセスできる場合があります。
ODBC Data Sourcesセクションに示される各DSNには、専用のDSN指定があります。Data Manager DSNのDSN指定の形式は、表1-3で示すとおりです。
表1-3 データ・ソース指定の形式
| コンポーネント | 説明 |
|---|---|
|
|
|
|
|
データソースとリンクされているTimesTen Data Managerドライバ。これが関連するのは、ドライバ・マネージャを使用している場合、またはクライアント/サーバーの使用例におけるサーバーの場合です。 |
|
|
アクセスできるデータベースのディレクトリ・パスと接頭辞です。これは必須です。 |
|
|
データベースのキャラクタ・セットにより、データを格納する際のキャラクタ・セットが決定されます。データベースのキャラクタ・セットは必要であり、データベースの作成後に変更することはできません。詳細は、「データベース・キャラクタ・セットの選択」を参照してください。 |
|
オプションの属性 |
属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の接続属性に関する説明を参照してください。 |
たとえば、sampledb_1122というDSNの指定は、次のようになります。
[sampledb_1122] Driver=install_dir/lib/libtten.so DataStore=install_dir/info/DemoDataStore/sampledb_1122 ...
TimesTenクライアントDSNのデータベース指定は、表1-4で示す形式になっています。
|
注意: ここではTimesTenクライアントDSNの構文を示していますが、クライアントDSNおよびサーバーDSNの詳細な設定方法については、「TimesTen ServerシステムでのサーバーDSNの定義」と「TimesTen ClientシステムでのクライアントDSNの作成」を参照してください。 |
表1-4 TimesTen Clientを構成するデータベース指定
| コンポーネント | 説明 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
クライアント接続のタイムアウト値(秒)。 |
|
注意: ほとんどのTimesTen Data Manager属性は、TimesTen Clientデータベースでは無視されます。 |
たとえば、TimesTen Server ttserver上のsampledb_1122に接続するクライアント/サーバーのデータソースsampledbCS_1122の場合、データソース指定は次のようになります。
[sampledbCS_1122] TTC_Server=ttserver TTC_SERVER_DSN=sampledb_1122 TTC_Timeout=30
次の例は、UNIXの.odbc.iniファイル(一部)を示します。
... [ODBC Data Sources] sampledb_1122=TimesTen 11.2.2 Driver ... [sampledb_1122] Driver=install_dir/lib/libtten.so DataStore=install_dir/info/DemoDataStore/sampledb_1122 PermSize=40 TempSize=32 PLSQL=1 DatabaseCharacterSet=US7ASCII ... ######################################################################## # This following sample definitions should be in the .odbc.ini file # that is used for the TimesTen 11.2.2 Client. # The Server Name is set in the TTC_SERVER attribute. # The Server DSN is set in the TTC_SERVER_DSN attribute. ######################################################################### [ODBC Data Sources] sampledbCS_1122=TimesTen 11.2.2 Client Driver ... [sampledbCS_1122] TTC_SERVER=localhost TTC_SERVER_DSN=sampledb_1122 ...
TimesTenアプリケーションでは、データベースに接続するためにDSNまたは接続文字列を指定する必要があります。モジュール性および保守を考えると、特定の接続で特定の属性設定によってDSN設定またはデフォルト設定を上書きする必要がある場合を除いて、属性はアプリケーション内の接続文字列ではなくDSNで設定することをお薦めします。
接続文字列の構文には、接続属性の定義が含まれます。ここでは各属性はセミコロンで区切られています。
DSN属性の設定を決定するには、次の優先ルールを使用します。
接続文字列で指定された属性設定は、優先度が最も高くなります。属性が接続文字列に複数回指定されている場合は、最初の指定が使用されます。
属性が接続文字列で指定されていない場合は、DSNで指定された属性設定が使用されます。
デフォルトの属性設定は、優先度が最も低くなります。
接続文字列にDriver、DataStoreおよびDatabaseCharacterSetの各属性が含まれている場合は、ODBCアプリケーションまたはttIsqlユーティリティを使用してDSNを事前に定義しなくても、TimesTenデータベースに接続できます。接続文字列を次のように定義します。
Driver属性を使用したODBCドライバの名前またはパス名。
Windowsの場合、Driver属性の値はTimesTen ODBCドライバの名前にする必要があります。たとえば、TimesTen Data Manager 11.2.2などです。
UNIXの場合、Driver属性の値はTimesTen ODBCドライバの共有ライブラリ・ファイルのパス名にする必要があります。このファイルは、install_dir/libディレクトリにあります。
DataStore属性を使用したデータベースのパスおよびファイル名の接頭辞。
DatabaseCharacterSet属性を使用したデータベースのキャラクタ・セット。
次の例では、ttIsqlユーティリティで接続文字列を使用して、Driver、DataStoreおよびDatabaseCharacterSet属性を指定して接続する方法を示します。
C:\ ttIsql Copyright (c) 1996-2011, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. Command> connect "Driver=TimesTen Data Manager 11.2.2;DataStore=C:\sales\admin;DatabaseCharacterSet=US7ASCII";
TimesTenでは、データベースをメイン・メモリーにロードまたはアンロードするタイミングを決定するRAMポリシーを指定できます。データベースごとに個別のRAMポリシーを設定できます。
RAMポリシーのオプションは次のとおりです。
inUse: データベースは、データベースへの最初の接続をオープンするとメモリーにロードされ、1つ以上の接続がオープンしているかぎり、メモリーに常駐したままになります。データベースへの最後の接続をクローズすると、データベースはメモリーからアンロードされます。これがデフォルトのポリシーです。
inUse with RamGrace: データベースは、データベースへの最初の接続をオープンするとメモリーにロードされ、1つ以上の接続がオープンしているかぎり、メモリーに常駐したままになります。データベースへの最後の接続をクローズすると、猶予期間中、データベースはメモリーに常駐したままになります。データベースは、猶予期間中データベースに接続されているプロセスがない場合にのみメモリーからアンロードされます。猶予期間は、随時設定および再設定できます。猶予期間は、次に猶予期間が変更されるまでのみ有効です。
always: データベースはメモリーに常駐したままになります。TimesTenデーモンは再起動すると、データベースを自動的に再ロードします。リカバリ不能なエラー条件が発生しないかぎり、必ずデータベースは自動的に再ロードされます。データベース・エラーのリカバリに関する詳細は、「自動リカバリ失敗後のRAMポリシーの変更」を参照してください。
「manual」: データベースはシステム管理者によって手動でロードおよびアンロードされます。ロードされると、管理者がデータベースをアンロードするまで、またはリカバリ不能なエラー条件が発生しないかぎり、TimesTenによってデータベースはロードされたままになります。データベース・エラーのリカバリに関する詳細は、「自動リカバリ失敗後のRAMポリシーの変更」を参照してください。
システム管理者は、RAMポリシーを設定するか、ttAdminユーティリティまたはC API RAMポリシー・ユーティリティを使用してデータベースを手動でロードまたはアンロードします。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明または『Oracle TimesTen In-Memory Database C開発者ガイド』のTimesTenユーティリティAPIに関する説明を参照してください。
|
注意: デフォルトでは、致命的なエラー後のデータベースの自動リカバリが失敗した場合、TimesTenはalwaysおよびmanual RAMポリシーをInUseに変更して、失敗の再発を防止します。RAMポリシーの変更を防止する方法に関する詳細は、「自動リカバリ失敗後のRAMポリシーの変更」を参照してください。 |
次の例では、ttdata DSNで識別されるデータベースについてRAMポリシーをalwaysに設定します。
|
注意: 1行目で、RAMレジデント・ポリシーがalwaysに設定されています。その他の出力には、ttAdminユーティリティで設定できる他のポリシーも示されています。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス・ガイド』のttAdminに関する説明を参照してください。 |
% ttadmin –rampolicy always ttdata RAM Residence Policy : always Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False
致命的なエラーによってデータベースが無効になり、TimesTenによって実行された自動データベース・リカバリが失敗した場合、デフォルトでは以下が発生します。
TimesTenは、alwaysおよびmanual RAMポリシーをInUseに変更して、エラーの再発を防止します。alwaysとmanual RAMポリシーのどちらの場合でも、TimesTenは、同じ障害が複数回発生していても、障害ごとにデータベースをリロードします。ただし、InUse RAMポリシーの場合は、プロセスが接続を試みるまでTimesTenは自動的にデータベースをリロードしません。
致命的なエラーが原因でデータベースが無効化された場合、このデータベースに接続されたユーザー・プロセスは、データベースが無効化されたことを認識できないときがあります。この場合、すべてのユーザー・プロセスが接続を閉じるまで、無効化されたデータベースがメモリー上に存在します。したがって、無効化されたデータベースと新しくリロードされたデータベースの両方がメモリーに共存することがあります。
|
注意: 無効なデータベースがメモリーにまだ存在している間に大きなデータベースをメモリーにリロードすると、使用可能RAMが一杯になることがあります。データベースの自動リロードを防止する方法の詳細は、「自動リカバリ失敗後のデータベースのリロードを防止する」を参照してください。 |
TimesTenデーモンを開始する前に、ttendaemon.optionsファイルの-enablePolicyInactiveオプションを設定して、データベースのリカバリ動作を変更できます。設定すると、自動リカバリが失敗したときの動作は次のようになります。
manualおよびalwaysのRAMポリシーには変更はありません。
レプリケーション・エージェントとキャッシュ・エージェントは再起動されません。
データベースのリロードが数回失敗すると、TimesTenはpolicyInactiveモードを設定し、データベースのロードがそれ以上試行されないようにします。
次のいずれかによってpolicyInactiveはクリアされ、通常の動作に戻ります。
TimesTenデーモンが再起動する。
プロセスが正常に接続される。
管理者がデータベースのttAdminコマンドを実行し、RAMポリシーの変更、RAMロードの実施、キャッシュまたはレプリケーション・エージェントの開始のいずれかを行う。
次のメッセージのいずれかがttStatus出力に表示されることで、policyInactiveモードがアクティブかどうかを確認できます。
「Automatic reloads disabled.」
「Data store should be manually loaded, but inactive due to failures.」。RAMポリシーがmanualの場合に表示されます。
「Data store should be loaded, but inactive due to failures.」。RAMポリシーがalwaysの場合に表示されます。
致命的なエラーが原因でデータベースが無効化された後、TimesTenは、データベースがRAMポリシー、キャッシュ・エージェントのポリシーおよびレプリケーション・エージェントのポリシーの設定と一貫性を維持しているかぎり、データベースのリロードとリカバリを試みます。ただし、ユーザー・プロセスは、データベースの無効化を認識していない場合に引き続きデータベースに接続されていることがあります。この場合、すべてのユーザー・プロセスが接続を閉じるまで、無効化されたデータベースがメモリー上に存在します。したがって、無効化されたデータベースと新しくリロードされたデータベースの両方がメモリーに共存することがあります。データベースが大きい場合、これが問題になることがあります。
|
注意: データベースのリロードとリカバリを実行するかどうかはRAMポリシーによって決定されるだけでなく、キャッシュ・エージェントとレプリケーション・エージェントも無効化後にデータベースをリロードするかどうかの要素になります。障害の後にデーモンがエージェントを自動的に再起動するようにキャッシュ・エージェントとレプリケーション・エージェントのポリシーを設定すると、エージェントはデータベースへの接続を開始します。これが初めての接続であれば、デーモンはデータベースをリロードし、リカバリを実行します。キャッシュ・エージェントおよびレプリケーション・エージェントのポリシーの詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のレプリケーション・エージェントの起動および停止に関する説明、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・エージェント起動ポリシーの設定に関する説明および『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。 |
無効化の後にデータベースが自動的にリロードすることを防止するには、ttAdmin -noautoreloadコマンドを使用します。デフォルトの自動データベース・リロード動作に戻すには、ttAdmin -autoreloadコマンドを使用します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。
次のいずれかによってデータベースの初期化とリカバリが開始し、通常の動作に戻ります。
TimesTenデーモンが再起動する。
プロセスが正常に接続される。
管理者がデータベースのttAdminコマンドを実行し、RAMポリシーの変更、RAMロードの実施、キャッシュまたはレプリケーション・エージェントの開始のいずれかを行う。
データベースの自動リロードを防止する動作を設定した場合、リロードされていないデータベースに接続しようとすると次のエラーメッセージが表示されることがあります。
Error 707, "Attempt to connect to a data store that has been manually unloaded from RAM"
次の項では、メモリーからデータベースのロードとアンロードについて説明します。
データベースをメモリーにロードする前に、RAMポリシーをmanualまたはinUseに設定します。RAMポリシーがalwaysに設定されている場合、これはデータベースを常にロードしていることを指定するポリシーなので、データベースはすでにロードされています。また、TimesTenデーモンが実行中であることも確認してください。TimesTenデータベースのデフォルトのRAMポリシーは、inUseです。RAMポリシーの指定の詳細は、「RAMポリシーの指定」を参照してください。
データベースをメモリーにロードしようとする前に、TimesTenデーモンが実行中であることを確認します。
ttDaemonAdmin -start
データベースをメモリーにロードするには、ttAdminユーティリティを実行します。
次の例では、TimesTenデータベースのRAMポリシーをmanualに設定します。
ttAdmin -ramPolicy manual sampledb_1122 RAM Residence Policy : manual Manually Loaded In RAM : False Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False
次に、ttAdmin -ramloadユーティリティを使用してTimesTenデータベースをメモリーにロードします。ttAdminユーティリティの-ramLoadオプションは、RAMポリシーがmanualのときにしか使用できません。
ttAdmin -ramLoad sampledb_1122 RAM Residence Policy : manual Manually Loaded In RAM : True Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False
次の例では、データベースのRAMポリシーをinUseとして定義し、猶予時間を200秒に設定しています。
ttAdmin -ramPolicy inUse -ramGrace 200 sampledb_1122 RAM Residence Policy : inUse plus grace period RAM Residence Grace (Secs) : 200 Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False
データベースが構成済レプリケーションである、またはデータベースのキャッシュである場合、ttAdminユーティリティを実行してレプリケーション・エージェントおよびキャッシュ・エージェントを起動します。
ttAdmin -repStart sampledb_1122
ttAdmin -cacheStart sampledb_1122
これらのユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する項とttDaemonAdminに関する項を参照してください。
メモリーからデータベースをアンロードする前に、データベースへのアクティブな接続をすべてクローズし、データベースのRAMポリシーをmanualまたはinUseに設定する必要があります。
データベースへのアクティブな接続をすべてクローズするには、ttStatusユーティリティを実行して、データベースに接続されているプロセスを検出し、停止します。ttStatusの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatusに関する説明を参照してください。
データベースにキャッシュまたはレプリケーションを構成している場合は、ttAdminユーティリティの-cacheStopおよび-repStopオプションを使用して、キャッシュ・エージェントとレプリケーション・エージェントを停止します。
RAMポリシーを「manual」または「inUse」に設定する方法は、「RAMポリシーの指定」を参照してください。
RAMポリシーがmanualに設定されているデータベースをメモリーからアンロードするには、ttAdmin -ramUnloadユーティリティを実行します。アクティブな接続をすべてクローズすると、RAMポリシーがinUseのデータベースがメモリーからアンロードされます。RAMポリシーがmanualのデータベースをメモリーからアンロードする方法については、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』で、メモリーからのデータベースのアンロードに関する項を参照してください。
ttAdminユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。
TimesTenは、連続した単一のメモリー領域内に2つの個別のメモリー領域を作成してデータベース領域を管理します。1つの領域には永続データが格納され、もう1つには一時データが格納されます。
永続データには、TimesTenデータベースを構成する表および索引が含まれます。データベースをメモリーにロードする際に、永続メモリー領域の内容がディスク上のファイルから読み込まれます。永続メモリー領域は、チェックポイント処理の際にディスクに書き込まれます。
一時データには、ロック、カーソル、コンパイルしたコマンド、およびコマンドの実行と問合せ評価に必要なその他の構造が含まれます。一時メモリー領域は、データベースをメモリーにロードする際に作成され、データベースをアンロードする際に削除されます。
データベースがメモリーに格納されている場合にデータベースのサイズを制御する接続属性には、PermSizeおよびTempSizeがあります。PermSize属性には、永続メモリー領域のサイズを指定し、TempSize属性には一時メモリー領域のサイズを指定します。
|
注意: これらの属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の接続設定に関する説明を参照してください。 |
永続データ・パーティションおよび一時メモリー領域のサイズは、データベースをメモリーにロードする際に設定され、データベースがメモリーに格納されている間は変更できません。いずれかの領域のサイズを変更するには、メモリーからデータベースをアンロードし、PermSize属性またはTempSize属性の値を変更して再度接続する必要があります。メモリーからデータベースをアンロードする方法については、「メモリーからのデータベースのアンロード」を参照してください。
次の項では、データベース・サイズの管理について説明します。
永続または一時のメモリー領域に空きがない場合は、データベースにプロシージャ、表または行を作成できません。データベースを正しいサイズにするには、PermSizeおよびTempSize接続属性に適切なサイズを設定します。
サイズを見積るには、ttSizeユーティリティを使用するか、または適切な見積りが得られるまでアプリケーションを実行します。
データベースを保持できる十分な大きさの共有メモリー・セグメントがあることを確認する必要があります。通常、この共有メモリー・セグメントの最小サイズは、次の式で計算します。
PermSize + TempSize + LogBufMB + 64 MB overhead
|
注意: 追加の共有セグメントを、PL/SQLの場合はPLSQL_MEMORY_SIZEを使用して作成し、クライアント/サーバーの場合は-serverShmSizeデーモン・オプションを使用して作成できます。 |
PermSizeに割り当てる量を計算する場合は、PL/SQLのプロシージャ、関数およびパッケージによって永続メモリー領域内の領域が使用される点を考慮に入れてください。ストアドPL/SQLユニットが必要とする永続メモリー領域の量は、ユニットのサイズと複雑さによって決定されます。小さいプロシージャに必要な量は3KBより少ない可能性がありますが、大きいプロシージャではより多い量が必要となる可能性があります。平均すると、適度に複雑なユニットでは約20KBの永続メモリー領域領域が使用されます。
データベースがレプリケーション用に構成されている場合は、データベースのすべてのレプリカについてデータベース・サイズを再構成します。データベースのサイズを変更した後、データベースをメモリーにロードし、キャッシュ・エージェントおよびレプリケーション・エージェントを再起動します。
詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のインストールの前提条件に関する説明および『Oracle TimesTen In-Memory Databaseリファレンス』のTempSize属性およびPermSize属性に関する説明を参照してください。
TimesTenは、2つのチェックポイント・ファイルにデータベースのコピーを保存し、それぞれがDataStore属性で指定されているディレクトリに格納されます。各チェックポイント・ファイルがディスク上で大きくなるので、サイズは増えません。そのため、各チェックポイント・ファイルのサイズは、データベースが永続メモリー領域でアクセスしたことのあるデータベースの最大サイズに等しくなることがあります。各チェックポイント・ファイルの最大サイズは、PermSizeにデータベース・ヘッダーを加えたサイズです。各永続データベースについて、両方のチェックポイント・ファイルとすべてのトランザクション・ログ・ファイルを保存するための十分なディスク領域が必要です。DataStore属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のDataStoreに関する説明を参照してください。
Preallocate接続属性を1に設定すると、TimesTenはチェックポイント・ファイルへの接続時にディスク領域を保持できます。これは、大規模なデータベースで、データをデータベースに追加するときに、チェックポイントファイルにディスクの空き容量が常にあるかを確認するのに役立ちます。Preallocate接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のPreallocateに関する説明を参照してください。
TimesTenのSYS.MONITOR表には、PermSizeとTempSizeの使用状況の監視に使用できるいくつかの列があります。具体的には、PERM_ALLOCATED_SIZE、TEMP_ALLOCATED_SIZE、PERM_IN_USE_SIZE、PERM_IN_USE_HIGH_WATER、TEMP_IN_USE_SIZEおよびTEMP_IN_USE_HIGH_WATERの各列です。これらの各列には、データベースに現在割り当てられているサイズや、データベースの使用中のサイズがKB単位で表示されます。この情報は、接続が確立または解放されるたび、およびトランザクションがコミットまたはロールバックされるたびにシステムによって更新されます。
データベースの断片化は、ttBlockInfo組込みプロシージャをコールすることでブロック・レベルで監視できます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttBlockInfoに関する説明を参照してください。
TimesTenには、メモリー不足の警告を発行するタイミングを指定するPermWarnThresholdおよびTempWarnThresholdの2つの一般接続属性が用意されています。いずれの属性も、パーセントで値を指定します。
メモリー不足の警告を受信するには、アプリケーションで組込みプロシージャttWarnOnLowMemoryをコールする必要があります。
また、これらの属性によって、SNMP警告のしきい値も設定されます。『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップを使用した診断に関する説明を参照してください。
次のユーティリティを使用すると、データベースの既存の表の特定部分を管理できます。
既存の表への行データの追加。ttBulkCpユーティリティを使用します。データをASCIIファイルに保存して、ttBulkCpユーティリティを使用すると、TimesTenデータベースの表に行データをロードできます。
追加する行には、表と同じ列数を含める必要があります。また、各列のデータは、その列に定義されているデータ型である必要があります。
ttBulkCpユーティリティはASCIIファイルに保存されたデータに対して処理を行うため、列数とデータ型がTimesTenデータベースの表の列数とデータ型と一致し、検出されたファイルがttBulkCpと互換性を持っている場合、このユーティリティを使用して他のアプリケーションからデータをインポートすることもできます。
データベース内の表の所有者の名前変更。ttMigrateユーティリティを使用します。表のリストア時に、-renameオプションを使用して表の所有者の名前を変更します。
TimesTenでは、データベースへのマルチスレッド・アプリケーション・アクセスがサポートされています。データベースに接続すると、すべてのスレッドで、この接続に対する処理を発行できます。
通常、スレッドは、スレッド固有の接続に対して処理を発行するので、他のすべてのスレッドでは別のトランザクションが存在します。スレッドの作成および削除が頻繁に行われる環境では、接続をプールに保持することでパフォーマンスを向上できます。スレッドは、必要に応じてこのプールから接続を割り当てて、接続および切断によるオーバーヘッドを回避できます。
TimesTenでは、複数のスレッドで同じ接続に対してリクエストを発行できるため、トランザクションにリクエストが混在します。これらのリクエストは、TimesTenによってシリアライズされます(アプリケーションによっては、独自のシリアライズが必要な場合があります)。
また、TimesTenは、1つのスレッドで複数の接続にリクエストを出したり、同一のデータベースまたは異なるデータベースに対して、複数の個別トランザクションおよび同時トランザクションを制御することができます。
一部の状況では、TimesTenデータベースではメモリー・フラグメンテーションが進行しているため、大量の空きメモリーが既存の表の部分的に埋まったページに割り当てられていることがあります。これにより、空きメモリーが不足するため、他のユーザーにメモリーを割り当てられなくなることがあります(他の表用の新しいページなど)。このような状況では、メモリーを他のユーザーが利用できるようにするために、データベースをデフラグする必要があります。
表がALTER TABLE ADD SQL文で変更されてから、2番目の表パーティションが作成されます。デフラグメンテーションにより、2番目の表パーティションを削除し、すべての表の列を含む1つの表パーティションを作成できます。2番目の表パーティションが作成された場合、領域の利用およびパフォーマンスを向上するために、データベースを定期的にデフラグすることをお薦めします。
次のプロシージャは、両方のタイプのデータベース断片化に対応します。
データベースをデフラグするには、次のようにttMigrateユーティリティを使用します。
データベースへのすべての接続を停止します。
ttMigrateを使用してデータベースのコピーを保存します。
ttMigrate -c ttdb ttdb.dat
管理ユーザーとして、ttdbデータベースを再構築します。
ttMigrate -r -relaxedUpgrade -connstr "dsn=ttdb" ttdb.dat
|
注意: 表パーティションを圧縮しない場合は、ttMigrate -rコマンドを実行するときに-relaxedUpgradeオプションを指定しません。 |
このとき
すべてのユーザー、キャッシュ・グループおよびアクティブ・スタンバイ・ペアはttdbにリストアされています。
キャッシュ・グループは、AUTOREFRESH STATE = OFF状態にあります。
キャッシュ・エージェントおよびレプリケーション・エージェントは実行されていません。
ALTER TABLE ADD SQL文を使用して表に列を追加するときに表パーティションを追加できます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の「ALTER TABLE」の注意を参照してください。
ttMigrateの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttMigrate」を参照してください。
(最小の総サービス・ダウンタイムで)TimesTenデータベースをデフラグするには、ttMigrate -relaxedUpgradeおよびttRepAdmin -duplicateユーティリティを組み合せて使用します。これらのデータベースは、TABLE DEFINITION CHECKINGがRELAXEDに設定されているレプリケーション・スキームに関係しています。また、ttMigrate -relaxedUpgradeオプションによってパーティションを圧縮します。
|
注意: レプリケーション・スキームにいずれのキャッシュ・グループも含まれていないか、またはREADONLYキャッシュ・グループのみが含まれる場合に、アクティブ・スタンバイ・ペアのレプリケーション・スキームに関係するTimesTenデータベースのみをデフラグできます。 |
次の項では、レプリケーション・スキームに関係しているTimesTenデータベースをデフラグする方法について説明します。
|
注意: 各項で示す例は、ユーザーがレプリケーション・スキームの構成および管理に精通していることを前提としています。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の「スタート・ガイド」に関する説明を参照してください。 |
次の項では、アクティブ・スタンバイ・ペア・レプリケーション・スキームに関係しているTimesTenデータベースをデフラグする方法について説明します。
この項の例では、アクティブ・データベースがttdb1でスタンバイ・データベースがttdb2のアクティブ・スタンバイ・ペア・レプリケーション・スキームによるオンライン・デフラグメンテーションの実行方法を示しています。
スタンバイのTimesTenデータベースに対するレプリケーションを停止してそのスタンバイ・データベースのコピーを保存し、そのスタンバイ・データベースをデフラグする方法を次に示します。
|
注意: スタンバイ・データベースをデフラグしている間、アプリケーション処理をアクティブ・データベースで続行できます。 |
スタンバイ・データベースのコピーを保存するには、次の手順を実行します。
スタンバイ・データベース(ttdb2)でレプリケーション・エージェントを停止します。
ttAdmin –repStop ttdb2
サブスクライバがある場合、アクティブ・データベースでttRepStateSaveを実行し、スタンバイのステータスを失敗に設定します。スタンバイ・データベースが使用できない間は、アクティブ・データベースへの更新は、サブスクライバ・データベースに直接レプリケートされます。
ttRepStateSave('FAILED', 'ttdb2', 'ttsrv2');
ttMigrateを使用してスタンバイ・データベースのコピーを保存します。
ttMigrate -c -relaxedUpgrade ttdb2 ttdb2.dat
キャッシュ・エージェントを停止し、キャッシュ・グループを削除し、スタンバイを廃棄します。
ttAdmin –cacheStop ttdb2
キャッシュ・マネージャ・ユーザーとして接続されている間に、すべてのキャッシュ・グループを削除します。
Command> DROP CACHE GROUP t_cg;
スタンバイ・データベースを破棄します。
ttDestroy ttdb2
スタンバイ・データベースを再構築します。インスタンス管理者として、スタンバイに次のことを実行します。
ttIsql ttdb2
キャッシュ・マネージャ・ユーザーを作成し、このユーザーにADMIN権限を付与します。
Command> CREATE USER cacheadmin IDENTIFIED BY cadminpwd; Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE, DROP ANY TABLE TO cacheadmin; Command> GRANT ADMIN TO cacheadmin;
|
注意: ttMigrate –rを実行するには、キャッシュ・マネージャ・ユーザーにはADMIN権限が必要です。移行が完了したら、希望する場合は、このユーザーからADMIN権限を取り消します。
|
キャッシュ・マネージャ・ユーザーとして、ttdb2データベースを再構築します。
ttMigrate -r -relaxedUpgrade -cacheuid cacheadmin -cachepwd cadminpwd -connstr "dsn=ttdb2;uid=cacheadmin;pwd=cadminpwd;oraclepwd=oraclepwd" ttdb2.dat
このとき
すべてのユーザー、キャッシュ・グループおよびアクティブ・スタンバイ・ペアはttdb2にリストアされています。
キャッシュ・グループは、AUTOREFRESH STATE = OFF状態にあります。
キャッシュ・エージェントおよびレプリケーション・エージェントは実行されていません。
キャッシュ・マネージャ・ユーザーとして、スタンバイでキャッシュ・エージェントを起動します。
ttAdmin –cacheStart ttdb2
キャッシュ・グループをロードします。
Command> ALTER CACHE GROUP t_cg SET AUTOREFRESH STATE PAUSED;
Command> LOAD CACHE GROUP t_cg COMMIT EVERY 256 ROWS PARALLEL <nThreads>;
|
注意:
|
完了したら、キャッシュ・グループの状態を確認します。
Command> cacheGroups; Cache Group CACHEADMIN.T_CG: Cache Group Type: Read Only Autorefresh: Yes Autorefresh Mode: Incremental Autorefresh State: On Autorefresh Interval: 10 Seconds Autorefresh Status: ok Aging: No aging defined Root Table: ORATT.T Table Type: Read Only 1 cache group found.
スタンバイ・データベースでレプリケーション・エージェントを起動します。
ttAdmin -repStart ttdb2
スタンバイでレプリケーションの状態を確認します。
ttIsql ttdb2 Command> call ttRepStateGet; < STANDBY, NO GRID > 1 row found.
スタンバイ・データベース(ttdb2)はデフラグされ、アクティブ・データベースとスタンバイ・データベースの両方は機能しています。
アクティブ・データベースにデータベース・デフラグメンテーションを実行するには、アクティブ・データベースとスタンバイ・データベースのロールを入れ替えます。アクティブ(ttdb1)はスタンバイ・データベースになります。元のスタンバイ(ttdb2)はアクティブ・データベースになります。
すべてのアプリケーション処理を停止し、すべてのアプリケーションの接続を切断します。処理中の問合せのみが、ttdb2 TimesTenデータベースで稼働するように移動できます。
現行のスタンバイ・データベース(ttdb2)のデータベース名およびホストを入力パラメータとして、現行のアクティブ・データベース(ttdb1)でttRepSubscriberWait組込みプロシージャをコールします。これにより、キューに入れられたすべての更新が現行のスタンバイ・データベースに送信されます。
|
注意: waitTimeを-1に設定した場合、コールは、コール前にコミットされたすべてのトランザクションがサブスクライバに送信されるまで待機します。
ただし、
|
Command> call ttRepSubscriberWait(NULL,NULL,'ttdb2','ttsrv2', 100);
現行のアクティブ・データベースでレプリケーション・エージェントを停止します。
Command> call ttRepStop;
現行のアクティブ・データベースでttRepDeactivate組込みプロシージャをコールします。これによって、このデータベースはIDLE状態になります。
Command> call ttRepDeactivate; Command> call ttRepStateGet; < IDLE, NO GRID > 1 row found.
古いスタンバイ・データベースでttRepStateSet('ACTIVE')組込みプロシージャをコールしてスタンバイをアクティブに昇格します。このデータベースがアクティブ・スタンバイ・ペアのアクティブ・データベースになります。ttRepStateGet組込みプロシージャを使用して、データベースがアクティブになったことを確認します。
Command> call ttRepStateSet('ACTIVE');
Command> call ttRepStateGet;
< ACTIVE, NO GRID >
1 row found.
アクティブ・データベースだったデータベースでレプリケーション・エージェントを停止します。
ttAdmin -repStop ttdb1
新しいアクティブ・データベースでttRepStateSaveを実行し、以前のアクティブ・データベースの状態を失敗に設定します。スタンバイ・データベースが使用できない間は、アクティブ・データベースへの更新は、サブスクライバ・データベースに直接レプリケートされます。
Command> call ttRepStateSave('FAILED', 'ttdb1', 'ttsrv1');
新しいアクティブ・データベース(ttdb2)でアプリケーションのフル・ワークロードを再起動します。
このデータベースがアクティブ・スタンバイ・ペアのスタンバイ・データベースとして機能するようになります。
新しいアクティブからttRepAdmin -duplicateを使用して、スタンバイを廃棄し、新しいスタンバイを再作成します。これらの手順の間、アクティブ・データベースではアプリケーション処理は続行できます。
新しいスタンバイ・データベースでキャッシュ・エージェントを停止します。
ttAdmin –cacheStop ttdb1
キャッシュ・マネージャ・ユーザーとして、すべてのキャッシュ・グループを削除します。
Command> DROP CACHE GROUP t_cg;
データベースを破棄します。
ttDestroy ttdb1
新しいアクティブを複製して新しいスタンバイ・データベースを再作成します。
ttRepAdmin -duplicate -from ttdb2 -host ttsrv2 –setMasterRepStart -UID ttadmin -PWD ttadminpwd -keepCG -cacheUID cacheadmin -cachePWD cadminpwd ttdb1
新しいスタンバイ・データベースでキャッシュ・エージェントおよびレプリケーション・エージェントを起動します。
ttAdmin –cacheStart ttdb1 ttAdmin –repStart ttdb1
このプロセスにより、ごく数秒の間サービスが中断するのみで、アクティブ・データベースとスタンバイ・データベースの両方がデフラグされます。
次の項では、アクティブ・スタンバイ・ペアではないレプリケーション・スキームに関係しているTimesTenデータベースをデフラグする方法について説明します。
|
注意: 次の項では、双方向レプリケーション・スキームに関係しているデータベースをデフラグする方法について説明します。双方向レプリケーション・スキームでは、各データベースはマスターおよびサブスクライバの両方になります。 |
この項の例では、2つのTimesTenデータベース(それぞれttdb1およびttdb2という名前)で双方向および一方向レプリケーションによるオンライン・デフラグメンテーションを実行する方法を示します。一方向レプリケーションの例では、ttdb1はマスターを表し、ttdb2はサブスクライバを表します。
この手順の第1歩は、TimesTenデータベースの1つでレプリケーションを停止し、このデータベースをデフラグすることです。
|
注意: データベースの1つをデフラグしている間、他のデータベースではアプリケーション処理を続行できます。 |
TimesTenデータベースのコピーを保存するには、次の手順を実行します。
データベースの1つでレプリケーション・エージェントを停止します。
ttdb2データベースの場合:
ttAdmin –repStop ttdb2
ttMigrateを使用してttdb1データベースのコピーを保存します。
ttMigrate -c -relaxedUpgrade ttdb2 ttdb2.dat
データベースを破棄します。
ttDestroy ttdb2
ADMIN権限のあるTimesTenユーザーとして、ttdb2データベースを再構築します。
ttMigrate -r -relaxedUpgrade -connstr "dsn=ttdb2;uid=ttadmin;pwd=ttadminpwd" ttdb2.dat
このとき
すべてのユーザーがttdb2に格納されました。
レプリケーション・エージェントは稼働していません。
ttdb2でレプリケーション・エージェントを再起動します。
ttAdmin -repStart ttdb2
ttdb2 TimesTenデータベースがデフラグされました。
ttdb1データベースにデータベース・デフラグメンテーションを実行するには、次の操作を実行します。
すべてのアプリケーション処理を停止し、すべてのアプリケーションの接続を切断します。すべての処理をttdb2 TimesTenデータベースで稼働するように移動できます。
デフラグしたデータベース(ttdb2)のデータベース名およびホストを入力パラメータとして、デフラグされていないTimesTenデータベース(ttdb1)でttRepSubscriberWait組込みプロシージャをコールします。これにより、キューに入れられたすべての更新が両方のデータベースに送信されます。
|
注意: waitTimeを-1に設定した場合、コールは、コール前にコミットされたすべてのトランザクションがサブスクライバに送信されるまで待機します。
ただし、
|
ttdb1の場合:
ttIsql ttdb1 Command> call ttRepSubscriberWait(NULL,NULL,'ttdb2','ttsrv2', 100);
双方向レプリケーション・スキームを使用する場合、手順3および手順4をスキップして手順5に進んでください。
一方向レプリケーション・スキームの場合(ttdb1がマスターでttdb2がサブスクライバ)、両方のTimesTenデータベースでレプリケーション・スキームを破棄します。
ttdb1の場合:
ttIsql ttdb1 Command> DROP REPLICATION r1;
ttdb2の場合:
ttIsql ttdb2 Command> DROP REPLICATION r1;
一方向レプリケーション・スキームの場合、マスター(ttdb1)およびサブスクライバ(ttdb2)でレプリケーション・スキームを破棄します。
ttdb1の場合:
ttIsql ttdb1 Command> DROP REPLICATION r1;
ttdb2の場合:
ttIsql ttdb2 Command> DROP REPLICATION r1;
ttdb2でレプリケーション・エージェントを起動します。
ttAdmin -repStart ttdb2
ttdb1でレプリケーション・エージェントを停止します。
ttAdmin -repStop ttdb1
一方向レプリケーション・スキームを変更する場合、ttdb2データベースは一方向スキームでマスター・データベースとして稼働しており、ttdb1データベースは一方向レプリケーション・スキームでサブスクライバ・データベースとして稼働しています。
ttRepAdmin -duplicateを使用して、デフラグされていないレプリケーション・スキーム内のTimesTenデータベースを破棄して再作成します。これらの手順の間、デフラグしたデータベースではアプリケーション処理を続行できます。
データベースを破棄します。
ttDestroy ttdb1
レプリケーション・スキームに関係したデフラグ済のTimesTenデータベース(ttdb2)を複製して、新しいTimesTenデータベース(ttdb1)を再作成します。
ttRepAdmin -duplicate -from ttdb2 -host ttsrv2 –setMasterRepStart -UID ttadmin -PWD ttadminpwd ttdb1
新しいスタンバイ・データベースでレプリケーション・エージェントを起動します。
ttAdmin –repStart ttdb1
この処理は、一方向レプリケーション・スキームまたは双方向レプリケーション・スキームのいずれに属するTimesTenデータベースも、数秒のサービス停止時間のみでデフラグします。
