最近处理一个故障 ，HP上的执行的一个出话单的月任务非常慢，需要6-7小时，通常其他的DB是2-3小时即执行完毕，检查分析发现其中的大批量UPDATE操作后的DUMP TRAN 执行很慢
需要20秒左右，而其他正常的服务器只需要1秒左右。用DD 对比两个DB的磁阵读写速度，慢的DB 反而DD 要快一点点。

出问题的这个DB是新上的，第一次用。

请问有哪些因素可能影响到DUMP TRAN的速度？ 下一步如何排查比较方便？ (咨询了SYBASE北京的人，他们也没说出明确的方法 郁闷）

另外需要说明的时候，出月的任务时候2：00到4：00 会有1万多个UPDATE操作操作相同的大表，不过这种操作在其他DB上也有的，并未影响任务的执行。

我怀疑的如下方面
1 其他数据库的参数比较，都比较过了，都差不多了
2 其他外部的数据库操作，都差不多 主要就是1万多个UPDATE表的操作
3 磁阵的速度。
4 任务的运行的业务逻辑和表的规模都差不多

目前最怀疑的还是磁阵的速度，是否DD也无法测试全面磁阵？ 一定要测试的数据库日志设备所在的那个地方的IO？

"大批量UPDATE操作后的DUMP TRAN 执行很慢"?这个是什么意思？

在慢的时候，做个sysmon看看数据库性能情况。

经过测试发现
update A set A.b=6 WHERE  A.b<>6

这种更新语句,set和where子句使用了相同的列，从查询计划看，sybase使用延迟更新的方式更新数据,即先把数据全部缓存到log段中,随后才更新表数据,由于紧跟其后的dump tran语句就是要操作log段,所以i/o差时会较慢.

比较奇怪的是,在其他DB上测试同样的语句,虽然查询计划显示是使用延迟更新的方式,但是dump tran却很快(1秒内就能完成)

目前还没有办法定位dump tran慢的原因,sybase工程师建议使用数据库中的阀值空间保护存储过程功能来减少dump tran操作.

通常的做事大批量UPDATE后，进行一次DUMP TRAN 保护日志空间不充满，参见ITPUB 18期电子杂志。

通常dump数据的时候跟机器性能有关系，同时可以用vmstat观察一下，看看有没有其他的任务在执行占用比较高的IO，对dump的数据进行压缩，例子：
dump database dlyx to "compress::5::/dump01/dumpdlyx/dlyx01.dmp"
            stripe on "compress::5::/dump01/dumpdlyx/dlyx02.dmp"
            stripe on "compress::5::/dump01/dumpdlyx/dlyx03.dmp"
            stripe on "compress::5::/dump02/dumpdlyx/dlyx04.dmp"
            stripe on "compress::5::/dump02/dumpdlyx/dlyx05.dmp"
            stripe on "compress::5::/dump02/dumpdlyx/dlyx06.dmp"

dump tran的数据量有变化吗？