我们目前正在经历一个日益严重的临时文件问题。 看着我们的一个网站，我们可以看到在我们正在观看的一个网站上每天增长100-200MB。 在这个站点，当临时文件达到20Gb并且发生可用空间问题时，发生故障。
目前我们正在压制超时。 -ti和-tl被设置为零。 由于这种configuration，临时表正在build立的机会是多less？
另外。 为了进一步理解-tl标志，下面是一个真实的说明：除非客户端无法通过tcpip连接，否则连接将不会被重置。
-TI 0或-tl 0与SQL Anywhere中的临时空间问题有任何关系。 这很可能是失控查询的结果。 如果您使用的是版本9，则可以打开限制检查，如下所示：
SET OPTION PUBLIC.temp_space_limit_check ='ON';
在版本10和11中，该选项应该已经打开，但也许已closures。 新的max_temp_space选项也很有用。
在早期的版本中，你只需要find失控的查询; 猎狐犬可能会帮助： http ://www.risingroad.com/foxhound/index.html
另请参阅“危险！查询是史无前例的！” 在http://sqlanywhere.blogspot.com/2009/03/danger-queries-are-stampeding.html
仅供参考当您需要长时间不活动时，-TI 0无限制无活动超时设置非常普遍; 例如，在一个大的基于Web的连接池上过夜。
但是，如果导致大量的僵尸连接堆积（客户端长时间死亡，但服务器将连接打开），则“-tl 0无限活动超时设置”实际上是非常危险的。 就像“帮助”所说的那样，如果存在过早的活跃超时问题，通常会增加超时时间; 例如，-3600一小时。
AFAIK声明“连接不会被重置，除非客户端不能通过tcpip到达”似乎是过于简化：检查活性包似乎比简单的“无法达到”testing更复杂。
布瑞克
你说得对，-ti和-tl开关与临时空间无关。
关于活性问题，客户端和服务器每隔n/3秒发送一次活动包，其中n是活动超时值。 这只有在没有其他数据包同时发送的情况下才会发生。 如果任何一方在n秒后没有收到来自另一方的数据包，则连接将被丢弃。
由于TCP连接将立即closures，因此在连接实际上被另一端丢弃（例如，应用程序/服务器崩溃或机器重新启动）的情况下，活动不是必需的。 然而，生存性对于检测挂起的应用程序以及阻止数据包通过但不会导致TCP连接丢失的networking问题非常有用。