我可以在交易中执行 dump tran 吗？另外，使用延迟对日志的影响？
Can I perform a dump tran mid-transaction? Also, effects of using delay on log?
美好的一天，
两个问题：
A）如果我有这样的事情：
COMPLEX QUERY
WAIT FOR LOG TO FREE UP (DELAY)
COMPLEX QUERY
这真的有用吗？或者 tempdb 的日志段是否会保持完整，因为仍然保存着第一个查询的日志。
B) 在上述情况下，是否可以让中间查询使用 truncate_only 执行转储转储？
（这是一个很长的各种查询链，它们 运行 在一起。它们不会更改数据库中的任何内容，如果不需要的话，我什至不在乎保留日志.)
链的原因是因为我需要相同的两个临时 tables 和一大堆变量，用于链中的各种查询（其中一些用于所有查询）。为了让知识非常有限 SQL 的用户简单地使用查询链，我在长脚本的开头收集了非常简单的信息，自动检索其余信息，然后在整个脚本中使用它
我怀疑这些都行得通，但我想我还是问问吧。
Sybase 版本 15.7 和 12（12.？我不记得了）
谢谢，
Ziv.
根据我对@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)
我读到 'select into' 没有写入日志，所以我用 create 创建 table （由于其他原因我必须这样做），然后使用select 到初始人口的现有 table。 （温度 tables）
完成 table 后，我将其删除，然后是 'commit'。
在链中的各个点，我检查了 tempdb 的日志段，如果它 <70%（通常在 >98%），我使用 goto 到达我删除最后一个临时文件 tables 的脚本末尾脚本结束。 （所以这里不需要手册 'commit'）
我误解了整个 "on commit preserve rows" 事情，这完全取决于智商，而我在 ASE 上。
在交易中转储日志不会对日志量产生任何影响space。 Sybase 日志标记只有在提交（或回滚）时才会移动，并且如果没有旧的打开事务（可以在 syslogshold 中找到）
有几种不同的方法可以解决问题：
- 将日志 space 添加到 tempdb。
这不需要更改您的代码，也不是很困难。甚至有可能 tempdb 的大小不适合系统，额外的日志 space 对其他使用 tempdb 的应用程序很有用。
- 重新编写脚本以在开头添加提交，并仅查询后面的事务。
这将完成几件事。开始时的提交会将日志标记向前移动，这将允许日志转储回收 space。然后，由于您的其余查询只是读取，因此不应有任何事务 space 与它们相关联。请记住，事务日志仅存储有关 Insert/Update/Delete 的信息，而不存储有关读取的信息。
在您上面列出的示例中，可以存储用户详细信息并将其提交到数据库，然后其余查询将只是 select 将这些详细信息用于变量的语句，然后是最终事务会清理 table。在这种情况下，日志只保留第一个事务和最后一个事务..但是中间的查询不会填满日志。
如果不了解有关数据库配置或查询详细信息的更多信息，就很难获得更多详细信息。
美好的一天，
两个问题： A）如果我有这样的事情：
COMPLEX QUERY
WAIT FOR LOG TO FREE UP (DELAY)
COMPLEX QUERY
这真的有用吗？或者 tempdb 的日志段是否会保持完整，因为仍然保存着第一个查询的日志。
B) 在上述情况下，是否可以让中间查询使用 truncate_only 执行转储转储？
（这是一个很长的各种查询链，它们 运行 在一起。它们不会更改数据库中的任何内容，如果不需要的话，我什至不在乎保留日志.)
链的原因是因为我需要相同的两个临时 tables 和一大堆变量，用于链中的各种查询（其中一些用于所有查询）。为了让知识非常有限 SQL 的用户简单地使用查询链，我在长脚本的开头收集了非常简单的信息，自动检索其余信息，然后在整个脚本中使用它
我怀疑这些都行得通，但我想我还是问问吧。
Sybase 版本 15.7 和 12（12.？我不记得了）
谢谢， Ziv.
根据我对@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)
我读到 'select into' 没有写入日志，所以我用 create 创建 table （由于其他原因我必须这样做），然后使用select 到初始人口的现有 table。 （温度 tables） 完成 table 后，我将其删除，然后是 'commit'。 在链中的各个点，我检查了 tempdb 的日志段，如果它 <70%（通常在 >98%），我使用 goto 到达我删除最后一个临时文件 tables 的脚本末尾脚本结束。 （所以这里不需要手册 'commit'）
我误解了整个 "on commit preserve rows" 事情，这完全取决于智商，而我在 ASE 上。
在交易中转储日志不会对日志量产生任何影响space。 Sybase 日志标记只有在提交（或回滚）时才会移动，并且如果没有旧的打开事务（可以在 syslogshold 中找到）
有几种不同的方法可以解决问题：
- 将日志 space 添加到 tempdb。
这不需要更改您的代码，也不是很困难。甚至有可能 tempdb 的大小不适合系统，额外的日志 space 对其他使用 tempdb 的应用程序很有用。
- 重新编写脚本以在开头添加提交，并仅查询后面的事务。
这将完成几件事。开始时的提交会将日志标记向前移动，这将允许日志转储回收 space。然后，由于您的其余查询只是读取，因此不应有任何事务 space 与它们相关联。请记住，事务日志仅存储有关 Insert/Update/Delete 的信息，而不存储有关读取的信息。
在您上面列出的示例中，可以存储用户详细信息并将其提交到数据库，然后其余查询将只是 select 将这些详细信息用于变量的语句，然后是最终事务会清理 table。在这种情况下，日志只保留第一个事务和最后一个事务..但是中间的查询不会填满日志。
如果不了解有关数据库配置或查询详细信息的更多信息，就很难获得更多详细信息。