1

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

  1. 这是一个很好的设计，可以使用以下内容让批次休眠到第二天吗？还是会损害性能？我在调用 waitfor 之前提交了 tran。

    waitfor time "12:00:00"

  2. 交易日志：

    • 我正在使用以下查询查找事务日志大小，并等待事务日志可用空间 < 一些百分比。这是一个好方法吗？

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

      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
4

3 回答 3

0

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

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

有关转储事务日志的更多信息，请参见Sybase ASE 15.7 参考手册：命令

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

于 2013-04-01T04:44:24.620 回答
0
  1. waitfor 不应该损害您的性能，但是在 ASE 重新启动、DBA 终止、与客户端的连接丢失等情况下，您可能会丢失此会话，对我来说，这看起来像是不稳定的解决方案。考虑使用 cron 或 ASE Job Scheduler
于 2013-04-05T13:25:03.620 回答
0

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

Cron 更可靠。

于 2017-09-16T18:03:31.890 回答