SQL Anywhereで一時ファイルの増加を制御するにはどうすればよいですか？
現在、一時ファイルの問題が拡大しています。私たちのサイトの1つを見ると、私たちが見ている1つのサイトで1日あたり100〜200MBの増加が見られます。このサイトでは、一時ファイルが20Gbに達したときに障害が発生し、空き領域の問題が発生しました。
現在、タイムアウトを抑制しています。 -tiと-tlはゼロに設定されます。この構成が原因で一時テーブルが構築される可能性はどのくらいですか？
さらに。 -tlフラグの理解を深めるために、次の真のステートメントがあります。クライアントがtcpip経由で到達できない場合を除いて、接続はリセットされません。
-ti0または-tl0のいずれかが、SQLAnywhereの一時スペースの問題と関係がある可能性はほとんどありません。暴走したクエリの結果である可能性があります。バージョン9を使用している場合は、次のように制限チェックをオンにできます。
SET OPTION PUBLIC.temp_space_limit_check = 'ON';
バージョン10および11では、そのオプションはすでにオンになっているはずですが、オフになっている可能性があります。新しいmax_temp_spaceオプションも役立ちます。
以前のバージョンでは、暴走したクエリを見つける必要があります。 Foxhoundが役立つかもしれません： http://www.risingroad.com/foxhound/index.html
「危険！クエリが押し付けられています！」も参照してください。で http://sqlanywhere.blogspot.com/2009/03/danger-queries-are-stampeding.html
参考までに、-ti 0無制限の非アクティブタイムアウト設定は、長期間の非アクティブを期待する場合に非常に一般的です。たとえば、大きなWebベースの接続プールで一晩。
ただし、-tl 0無制限の活性タイムアウト設定は、ゾンビ接続が大量に蓄積される場合、実際には危険です（クライアントは長い間停止していますが、サーバーは接続を開いたままにします）。ヘルプが言うように、活性タイムアウトの問題が早すぎる場合は、通常、タイムアウト期間を長くすることをお勧めします。例：-tl3600で1時間。
「tcpip経由でクライアントに到達できない場合を除いて、接続はリセットされません」というステートメントは単純化しすぎているように見えます。活性パケットのチェックは、単純な「到達できない」テストよりもかなり複雑なようです。
ブレック
-tiスイッチと-tlスイッチは一時スペースとは無関係です。
活性の問題に関しては、クライアントとサーバーの両方がn/3秒ごとに活性パケットを送信します。ここで、nは活性タイムアウト値です。これは、その間に他のパケットが送信されていない場合にのみ発生します。 n秒後に一方が他方からパケットを受信しなかった場合、接続は切断されます。
TCP接続はすぐに閉じられるため、接続が実際に反対側によって切断された場合（たとえば、アプリケーション/サーバーがクラッシュしたり、マシンが再起動した場合）、活性は必要ありません。活性はただし、ハングしているアプリケーションや、パケットの通過を妨げるがTCP接続の切断を引き起こさない）ネットワークの問題を検出する場合に役立ちます。