Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.
クライアントでキャッシュされる文の数を制御します。
整数 (0 ~ 100)
個々の接続または PUBLIC グループに設定できます。値を変更すると、すぐに有効になります。
10
クライアントで文をキャッシュすると、同一の SQL 文が複数回準備されたときに、データベース要求と文の準備が減少します。同じ SQL 文の準備と削除が繰り返し行われると、クライアントは、文がデータベースサーバーに残された状態で、その文をキャッシュします。この文がアプリケーションによって削除された後でも、継続してキャッシュします。文のキャッシュにより、データベースサーバーは、文の削除や再準備などの余分な作業を節約できます。スキーマの変更、データベースオプション設定の変更、DROP VARIABLE 文の実行が生じると、準備文は自動的に削除され、その SQL 文が次に実行されるときに再び準備されます。これにより、不正な動作の原因となり得るような、キャッシュされた文が再使用されることのないようにします。
このオプションは、準備 (キャッシュ) されたまま維持できる文の最大数を指定します。キャッシュされた文は、max_statement_count リソースガバナーでは考慮されません。
このオプションの設定は、Embedded SQL、ODBC、OLE DB、ADO.NET、SQL Anywhere JDBC ドライバーを使用して作成された接続に適用されます。Sybase Open Client、jConnect、HTTP 接続には適用されません。
このオプションに 0 を設定すると、クライアントの文のキャッシュが無効になります。この値を増加すると、アプリケーションが同じ SQL 文について 10 回以上にわたって準備と削除を繰り返す場合に、パフォーマンスが向上する可能性があります。たとえば、25 の SQL 文をスルーするループを処理するアプリケーションについて考えてみます。ループをスルーするごとに準備と削除を繰り返し、これらの SQL 文のそれぞれにまったく同じ文が含まれているときは、このオプションを 25 に設定すると、パフォーマンスが向上します。
このオプションの値を増加させると、クライアントにおけるメモリの使用量が増加し、データベースサーバーに対するキャッシュ要求が高まります。キャッシュされた文が大量になった場合で、スキーマの変更やオプション設定の変更によって文を再使用できなくなると、その接続において、文のキャッシュは自動的に無効になります。文のキャッシュが自動的に無効にされると、クライアントは再び定期的に文のキャッシュを実行して処理方法を再評価し、文のキャッシュを再び有効にすることに効果があるかどうかを判断します。
クライアントでの文のキャッシュは、次の場合に予期しない結果をもたらす可能性があります。
文を準備し、記述します。その記述は結果のない文を返します。
CREATE OR REPLACE FUNCTION test() RETURNS INT BEGIN RETURN 1; END; CALL test();
DDL 文によって同じ文のテキスト (この例では CALL 文) が同じ接続に結果セットを返すようになる場合。次に例を示します。
CREATE OR REPLACE PROCEDURE test() BEGIN SELECT 2; END; CALL test();
クライアントでの文のキャッシュが有効になっているときに、2 番目の CALL test() 文が誤って記述されます。
CALL test()
ログが tracetime.pl Perl スクリプトを使用して分析される場合は、要求ログが取得される間、max_client_statements_cached オプションを 0 に設定して、クライアントでの文のキャッシュを無効にする必要があります。