Question

我正在开发一个Sybase ASE（迁移到15.7）数据清除实用程序，供多个表/数据库使用，以删除大量不需要的旧数据。我计划在每晚12点到3点之间以及凌晨3点之后安排它，它应该在第二天中午12点睡觉和醒来并继续清洗。标准不会影响用户。

这是一个很好的设计，使用以下方法让批次睡到第二天？还是会损害表现？我在调用waitfor之前提交了tran。
```
waitfor time "12:00:00"
```

交易记录：

我使用以下查询找到事务日志大小并等待直到事务日志可用空间＆lt;一些％。这是一个好方法吗？

另外，考虑到我的通用场景，在进行等待之前我应该检查的最佳事务日志使用％限制是多少？ - 我应该使用“转储交易”吗？我读到我们不应该在生产系统中使用“dump transaction truncate only”。我应该以不同的方式使用它吗？你有什么建议我的情景吗？

select @tlogPctUsed = ceiling(100 * (1 - 1.0 * lct_admin("logsegment_freepages",d.dbid) / sum(case when u.segmap in (4, 7) then u.size end)))
  from master..sysdatabases d, master..sysusages u
 where u.dbid = d.dbid
   and d.dbid = db_id()
   and d.status != 256
group by d.dbid

while (@tlogPctUsed > @tlogPctLimit)
begin
    waitfor delay @10Seconds
    select @tlogPctUsed = ceiling(100 * (1 - 1.0 * lct_admin("logsegment_freepages",d.dbid) / sum(case when u.segmap in (4, 7) then u.size end)))
      from master..sysdatabases d, master..sysusages u
     where u.dbid = d.dbid
       and d.dbid = db_id()
       and d.status != 256
    group by d.dbid
end

Answer 1

ASE Job Scheduler将是一种更稳定的运行清除方法，而不是 waitfor 。

不建议生产系统使用truncate_only *的转储事务的原因是它对可恢复性的影响。您可以通过将事务日志作为进程的一部分转储到文件来解决此问题。这样您就可以处理日志填充问题，并在数据库发生故障时保持恢复系统的能力。

有关转储事务日志的更多信息，请参阅Sybase ASE 15.7 Reference Manual: Commands

此外，可以将sp_thresholdaction设置为在达到特定阈值时自动转储事务日志。 Sybase ASE 15.7 Reference Manual: Procedures就是那个例子。

Answer 2

waitfor不应该损害你的性能，但是如果ASE重启，DBA终止，连接丢失，客户端等等，你可能会失去这个会话，对我来说，它看起来像是不稳定的解决方案。考虑使用cron或ASE Job Scheduler

Answer 3

谨慎使用Job Scheduler - 请注意此ASE java函数中的已知错误，例如为了让失败的JS任务从沉睡中恢复而需要回收ASE，这使得JS的使用风险比等待更高。

Cron更可靠。

Sybase ASE数据清除批处理 - 等待和事务日志管理

3 个答案: