3>go
1>dump transaction database_name with truncate_only
2>go
1>update large_tab set col1=0
2>where col2>=x
3>go
1>dump transaction database_name with truncate_only
2>go
若这个transaction 需要备份到介质上，则不用with truncate_only 选项。若执 行dump transaction with truncate_only，应该先做dump database 命令。
删除一个表的所有记录：
例：
1>delete table large_tab
2>go
同样，把整个table的记录都删除，要记很多log，我们可以用truncate table命 令代替上述语句完成相同功能。
1>truncate table large_tab
2>go
这样，表中记录都删除了，而使用truncate table 命令，log只记录空间回收情况，而不是记录删除表中每一行的操作。
基于子查询的数据插入
例：
1>insert new_tab select col1,col2 from large_tab
2>go
同样的方法，对这个大的transaction，我们应该处理为几个小的transactions。
1>Insert new_tab
2>select col1,col2 from large_tab where col1<=y
3>go
1>dump transaction database_name with truncate_only
2>go
1>insert new_tab
2>select col1,col2 from large_tab where col1>y
3>go
1>dump database database_name with truncate_only
2>go
同样，若想保存log到介质上，则dump transaction 后不加with truncate_only 选项。若执行dump transaction with truncate_only，应该先做dump database 动作。
批量数据拷贝
在使用bcp把数据拷入数据库时，我们可以把这个大的transaction变成几个小的transactions处理，避免log剧增。
开放trunc log on chkpt 选项
1>use master
2>go
1>sp_dboption database_name,trunc,true
2>go
1>use database_name
2>go
1>checkpoint
2>go
bcp... -b 100 (on unix)
bcp... /batch_size=100(on vms)
关闭trunc log on chkpt选项，并dump database。
在这个例子中，一个批执行100行拷贝。也可以将bcp输入文件分成两或多个分开的文件，在每个文件执行后做dump transaction 来避免log 满。
若bcp使用快速方式（无索引，无triggers），这样操作不记log，换句话说，log 只记载空间分配情况。在这种情况下，要先做dump database（为恢复数据库用）。若log太小，可置trunc log on chkpt 选项，这样在每次checkpoint后清除log。
八、Threshold 和transaction log 管理
ASE提供阈值管理功能，它能帮助用户自动监视数据库log设备段的自由空间。这方面的详细讨论见NO.5技术支持杂志。log的管理是灵活而复杂的，我们应该在实践中摸索经验，针对每个数据库的不同情况，不同操作，做不同处理。
2． 如何截断数据库的事务日志？
事务日志填满数据库中的日志空间后，可能不能使用转储事务日志的办法备份并且清除原来存在的日志，因为转储日志这个动作本身也需要记录日志。
这时候，可以首先使用dump transaction database_name with truncate_only命令，该命令只是截断/清除事务日志，并不生成实际的备份。
如果不能奏效，可以使用dump transaction database_name with no_log命令。该命令也是仅仅清除既有的事务日志，不生成实际的备份文件，且该命令本身不记日志。
如果该命令还不能奏效，应当使用alter database命令为此数据库的日志分配额外的空间，随后执行dump transaction。
． 使用dump transaction with no_log的危险性
在命令参考手册中的dump transaction with no_log条目下，有一条警告信息告诉你，你应该把这条命令作为没有其它办法时的最后一招才使用它。但是“最后一招”究竟是什么意思呢？当你使用这条命令时会怎样呢？那你应使用哪条命令来代替它呢？最后，若这条命令如此有问题，为什么Sybase却要提供它呢？
Sybase技术支持建议你定期的dump你的transaction log。你必须根据你的数据库中记入日志的活动量的大小以及你的数据库的大小来决定dump的方式。有些地方按月dump transaction；有些地方每夜dump transaction。
若你从未做过dump transaction，transaction log将最终会满。 SQLServer使用log（日志）是出于恢复目的的。 当log满时，服务器将停止事物的继续进行，因为服务器将不能将这些事物写进日志，而服务器不能运行大多数的dump tran命令，因为ASE也需在日志中记录这些命令。
这就是为什么当其它dump tran命令不能执行时no_log可执行的原因。但是想一下dump transaction with no_log被设计执行的环境，将不做并发性检查。
若你在对数据库的修改发生时使用dump transaction with no_log，你就会冒整个数据库崩溃的风险。在多数情况下，它们被反映成813或605错误。为了在数据库被修改时，删除transaction log中的不活跃部分可使用dump transaction with truncate_only。这条命令写进transaction log时，并且它还做必要的并发性检查。这两条命令都有与其相关的警告，在命令参考手册中会看到这些警告。请确保在使用其中任一条命令以前，你已理解这些警告和指示。 Sybase提供dump transaction with no_log来处理某些非常紧迫的情况。为了尽量确保你的数据库的一致性，你应将其作为“最后一招”。
4． 为什么数据库事务日志满了，使用dump tran with no_log仍不能截断日志？
有两种情况，可能出现这个问题。一是应用系统给ASE发送了一个用户自定义事务，一直未提交，这个最早活跃事务阻碍系统截断日志。二是客户端向ASE发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务结束后，才能被截掉。
对于第一种情况，只要督促用户退出应用或者提交事务，系统管理员便可清掉日志。因为给ASE发送Dump transaction with no-log或者with truncate-only，它截掉事务日志的非活跃部分。所谓非活跃部分是指服务器检查点之间的所有已提交或回退的事务。而从最早的未提交的事务到最近的日志记录之间的事务日志记录被称为活跃的。从此可以看明，打开的事务能致使日志上涨，因为在最早活跃事务之后的日志不能被截除。
对于第二种情况，道理也同上。只是在处理它时，需慎重从事。如果这个大事务已运行较长时间，应尽量想法扩大数据库日志空间，保证该事务正常结束。若该事务被强行回滚，ASE需要做大量的处理工作，往往是正向执行时间的几倍，系统恢复时间长，可能会影响正常使用的时间。
