| Oracle TimesTen Cache Connect to Oracle開発者および管理者ガイド
リリース7.0 E05172-03 |
|
 前へ |
 次へ |
アプリケーションで、TimesTenの単一の接続を介して、TimesTenまたはOracleのいずれかにSQL文を送信できます。
SQLがTimesTenまたはOracleのいずれに送られるかは、SQL文の構成およびPassThrough接続属性の設定によって決まります。PassThrough属性を設定して、TimesTenでローカル処理されるSQL文のタイプおよびOracleにリダイレクトされるSQL文のタイプを定義できます。
たとえば、PassThrough=0（デフォルト）を設定すると、すべてのSQLがTimesTenで実行されます。また、PassThrough=3を設定すると、すべてのSQLがOracleに渡されて実行されます。
図3.10に示すように、PassThrough=1を設定すると、TimesTenに存在しない表またはTimesTenで構文エラーを生成する表に対するSQLをパススルーできます。たとえば、キャッシュされた表（表A）に対するUPDATEはTimesTenキャッシュで処理されますが、TimesTenで検出されない表（表G）に対するUPDATEはOracleにパススルーされます。同様に、ttCacheStart、ttCkptなどのTimesTen固有のプロシージャはTimesTenで処理されますが、TimesTenでサポートされていないプロシージャはOracleにパススルーされます。
PassThrough=1と設定すると、DDL文はOracleにパススルーされません。TimesTenに存在しないプロシージャはOracleにパススルーされます。キャッシュ・グループ表のDML文に誤った構文が含まれている場合、そのDML文はOracleに送信されません。ただし、誤った構文を含むすべてのSELECT文は、Oracleに送信されます。
どのレベルのパススルーでも、トランザクションによってDDL文またはDML文がOracleに渡されると、コミットおよびロールバックがOracleとTimesTenの両方で実行されます。それ以外の場合は、TimesTenでのみ実行されます。
READONLYキャッシュ・グループでは、DML文によるキャッシュ・グループの更新が禁止されています。READONLYキャッシュ・グループを使用する場合は、PassThrough=2を設定することで、キャッシュ・グループ内の表に対するすべてのDML文をOracleに送ることができます。この設定は、その他の点についてはPassThrough=1と同じであるため、すべてのDDL文と、DML以外の構文的に互換性のある文およびプロシージャはTimesTenに送られます。同じパススルー動作は、USERMANAGEDキャッシュ・グループのREADONLY表にも適用されます。たとえば、図3.10のキャッシュ・グループの例について考えてみます。READONLY属性を表Aに設定し、PassThrough=2を設定すると、表Aに対するUPDATEはOracleにパススルーされます。
パススルー機能は、AWTおよびSWTキャッシュ・グループ内の表に対するDML処理では使用しないことをお薦めします。AWTキャッシュ・グループでの更新は、定義上はキャッシュと非同期ですが、パススルーによって同期するようにレンダリングされ、それによって意図しない結果になる場合があります。SWTキャッシュ・グループでの更新は、パススルー機能が実装されている場合、自己デッドロックが発生する可能性があります。
SQL文がTimesTenで実行されるか、Oracleにパススルーされるかの決定に対するPassThrough属性設定の影響およびその状況の詳細は、『Oracle TimesTen In-Memory Database APIリファレンス・ガイド』のPassThroughに関する説明を参照してください。
アプリケーションがPASSTHROUGH文に対して正しいSQLデータ型を提供していることを確認してください。ODBCドライバはC型およびSQL型を変換し、変換されたデータおよびSQL型コードをTimesTenに提示します。TimesTenはこの情報をOracleに渡します。
TimesTenは、TimesTen自体で実行される文のパラメータとは異なる方法で、PASSTHROUGH文のパラメータを処理します。TimesTen問合せオプティマイザはデータ型をTimesTen文のパラメータに割り当てます。アプリケーションは、SQLDescribeParam ODBC関数を使用して、これらのデータ型割当てを取得できます。これに対して、PASSTHROUGH文のパラメータにはデータ型が割り当てられません。TimesTenはPASSTHROUGH文のパラメータのデータ型をVARCHAR2(4000)としてレポートします。このデータ型は単なるプレースホルダです。TimesTenがパラメータ値をVARCHAR2データとして受信することを予測しているわけではなく、SQLBindParameter ODBC関数をコールするときに、アプリケーションはPASSTHROUGH文のパラメータのデータ型についてTimesTenに通知する必要があります。SQLBindParameterのfSqlType引数はパラメータのSQLデータ型を指定します。cbColDefおよびibScale引数はその精度およびスケールを指定します（適用可能な場合）。
たとえば、SQLデータ型INTEGERのパラメータをNUMBER(3)パラメータにバインドするには、次の引数を指定してSQLBindParameter ODBC関数をコールします。
fCType=SQL_C_SLONG
fSqlType=SQL_DECIMAL
cbColDef=3
ibScale=0
また、次の引数を使用できます。
fCType=SQL_C_SLONG
fSqlType=SQL_INTEGER
cbColDef=0
ibScale=0
SQL_INTEGERについてcbColDefおよびibScaleは無視されます。
DSNのPassThrough設定は、ttIsqlセッションのpassthroughコマンドで上書きできます。ttOptSetFlagプロシージャをコールし、optflagパラメータとして'passthrough'を指定し、optvalパラメータとして新しいパススルー設定を指定することによって、プログラムでも特定のトランザクションのパススルー設定を再設定できます。新しいパススルー設定はすぐに有効になります。トランザクションの最後に、パススルーはPassThrough属性で指定されている元の値にリセットされます。
| 注意: | PassThroughの動作は、他のオプティマイザ・フラグに似ています。文の準備時に設定されたPassThroughレベルが、その文の実行時に使用されるレベルになります。文を準備してから文を実行するまでの間にPassThroughレベルが変更された場合は、元のPassThroughレベルが実行時に使用されます。 |
