美好的一天，
两个问题： A）如果我有这样的事情：
COMPLEX QUERY
WAIT FOR LOG TO FREE UP (DELAY)
COMPLEX QUERY
这实际上有用吗？或者tempdb的日志段是否仍然保持完整，因为仍然保留第一个查询的日志。
B）在上面的情况中，是否可以让中间查询使用truncate_only执行dump tran？
（这是一个很长的链接，各种各样的查询一起运行。他们不会改变数据库中的任何内容，如果我不这样做，我也不会关心日志。必须。）
链的原因是因为我需要相同的两个临时表和一大堆变量，用于链中的各种查询（其中一些用于所有查询）。为了简单地由具有非常有限的SQL知识的用户使用查询链，我在长脚本的开头收集非常简单的信息，自动检索其余信息，然后通过脚本使用它
我怀疑其中任何一种都可行，但我想我也可以问。
Sybase版本15.7和12（12.？我不记得了）
谢谢， 谢夫。
根据我对@ michael-gardner答案的理解，这就是我的计划：
FIRST TEMP TABLES CREATION
MODIFYING OPERATIONS ON FIRST TABLES
COMMIT
QUERY1: CREATE TEMP TABLE OF THIS QUERY
QUERY1: MODIFYING OPERATIONS ON TABLE
QUERY1: SELECT
COMMIT
(REPEAT)
DROP FIRST TABLES (end of script)
我读到了＆＃39;选择进入＆＃39;没有写入日志，所以我用创建创建表（由于其他原因我必须这样做），并使用select into existing table进行初始填充。 （临时表） 完成表格后，我放弃它，然后“提交”。 在链中的各个点我检查tempdb的日志段，如果它＆lt; 70％（通常在> 98％），我使用goto到达脚本的末尾，我放弃了最后一个temp表和脚本结束。 （所以不需要手册＆＃39;在这里提交）
我误解了整个＆＃34;在提交保留行＆＃34;事情，那完全依靠智商，我在ASE。
答案 0 :(得分：0)
在事务中间转储日志不会对日志空间量产生任何影响。只有存在提交（或回滚）时，Sybase日志标记才会移动;如果没有旧的打开事务（可以在syslogshold中找到）
有几种不同的方法可以解决问题：
这不需要更改代码，也不是很困难。甚至可能tempdb的大小不适合系统，额外的日志空间对于使用tempdb的其他应用程序也很有用。
这将完成一些事情。开头的提交会将日志标记向前移动，这将允许日志转储回收空间。然后，由于其余的查询只是读取，因此不应该是与它们关联的任何事务空间。请记住，事务日志仅存储有关插入/更新/删除的信息，而不是读取信息。
在上面列出的示例中，用户详细信息可以存储并提交到数据库，然后其余查询只是使用变量的这些详细信息的select语句，然后最终事务将清理表。在这种情况下，日志仅保留第一个事务和最后一个事务..但中间的查询不会填充日志。
如果不了解有关数据库配置或查询详情的更多信息，则很难更加详细。