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

【问题标题】：Sybase ASE data purge batch - waitfor and transaction log managementSybase ASE 数据清除批处理 - 等待和事务日志管理
【发布时间】：2017-09-17 02:03:31
【问题描述】：

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

这是一个很好的设计来使用下面的让批次休眠到第二天吗？还是会损害性能？我在调用 waitfor 之前提交了 tran。
```
waitfor time "12:00:00"
```

交易记录：

我正在使用以下查询查找事务日志大小，并等待事务日志可用空间

另外，考虑到我的一般情况，在继续等待之前我应该检查的最佳事务日志使用百分比限制是多少？ -我应该使用“转储交易”吗？我读到我们不应该在生产系统中使用“仅转储事务截断”。我应该以不同的方式使用它吗？你有什么适合我的场景的建议吗？

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

【问题讨论】：

标签： batch-processing sap-ase

【解决方案1】：

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

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

更多关于转储事务日志的信息可以在Sybase ASE 15.7 Reference Manual: Commands找到

此外，sp_thresholdaction 可以设置为在达到某个阈值时自动转储事务日志。 Sybase ASE 15.7 Reference Manual: Procedures 有这个例子。

【讨论】：

感谢您的投入，迈克尔。我的 DBA 刚刚确认我们的数据库配置了“truncate log on chkpt”和“abort tran on log full”。在这种情况下，我可以安全地使用“仅截断转储事务”。对吗？
嗨，Michael，我让我的 DBA 在我们的 ASE 中设置作业调度程序，但他说只有一个 DBA 知道作业调度程序，而 sybase ASE 作业调度程序很难使用。他让我避免它并选择 cron。您能否让我知道您对 ASE 作业调度程序的看法，并让我知道这是否真的足以避免痛苦？感谢您对此的任何建议。
谢谢迈克尔。最后一件事要确认这一点。因此，可以在我的过程中以编程方式使用 ASE 作业调度程序。这是正确的吗？我计划通过在我的存储过程中调用“sp_sjobcreate”来创建计划作业。这行得通吗？

【解决方案2】：

waitfor 应该不会损害您的性能，但是在 ASE 重新启动、DBA 终止、与客户端的连接丢失等情况下，您可能会丢失此会话，对我来说，这看起来像是不稳定的解决方案。考虑使用 cron 或 ASE Job Scheduler

【讨论】：

【解决方案3】：

谨慎使用 Job Scheduler - 注意此 ASE java 函数中的已知错误，例如回收 ASE 只是为了让一个失败的 JS 任务从休眠状态中恢复过来，这使得使用 JS 的风险比等待更高。

Cron 更可靠。

【讨论】：