我们目前遇到了一个临时文件不断增长的问题。通过观察我们的一个网站，我们发现该网站每天的增长量为 100 - 200 MB。当临时文件达到 20GB 时，该网站就会出现故障，并出现可用空间问题。
我们目前正在抑制超时。-ti 和 -tl 设置为零。由于此配置而建立临时表的可能性有多大？
此外。为了进一步理解 -tl 标志，以下说法是否正确：除非无法通过 tcpip 访问客户端，否则不会重置连接。
答案1
-ti 0 或 -tl 0 不太可能与 SQL Anywhere 中的临时空间问题有关。这很可能是失控查询的结果。如果您使用的是版本 9，则可以按如下方式打开限制检查：
设置选项公共。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 无限制活动超时设置导致大量僵尸连接堆积（客户端早已死亡，但服务器保持连接打开），则它实际上是危险的。如帮助中所述，如果您遇到过早的活动超时问题，通常最好增加超时时间；例如，-tl 3600 持续一小时。
据我所知，“除非无法通过 tcpip 访问客户端，否则不会重置连接”这一说法似乎过于简单：活动数据包的检查似乎比简单的“无法访问”测试更为复杂。
布雷克
答案2
您说得对，-ti 和 -tl 开关与临时空间无关。
关于活跃度问题，客户端和服务器每n/31000 秒都会发送活跃度数据包，其中n是活跃度超时值。只有在同时没有发送其他数据包的情况下才会发生这种情况。如果任何一方在 1000 秒后没有收到另一方的任何数据包n，则连接将被断开。
如果连接实际上被另一方断开（例如，应用程序/服务器崩溃或机器重启），则不需要活动性，因为 TCP 连接将立即关闭。但是，活动性对于检测挂起的应用程序和阻止数据包通过但不会导致 TCP 连接断开的网络问题很有用。