>在任何地方都有一个使用sql的办公室16，db是83gigs，使用日志文件。

您正在使用什么版本的SQL Anywhere？

恢复紧迫性的增长速度远远快于导致

的检查点

>整天的恢复紧迫感经常达到99％。

恢复紧急度通常比检查点紧急度上升得更快。 它也可以上升到100％以上而不会引起性能问题； 1000％并非闻所未闻。

>这将导致从日志文件到磁盘的数据刷新。

您如何知道正在发生"从日志文件到磁盘的数据刷新"？

您怎么知道检查点紧急性是由什么引起的？

检查点与事务日志文件无关，它们与将检查点日志刷新到数据库文件有关。 ...或者您正在谈论正在发生的检查点？

>在刷新发生时，未计划的请求将从0变为具有850的高位。

您一次运行了多少个繁忙的连接？

您是否绝对确定计划外请求会上升到850？ ...这绝对是一个惊人的数字，比我见过的还要大。

>在此时间段内所有用户都挂起，并且计划外完成

>请求转到0，所有阻塞的连接都清除。

您是说检查点发生的次数太多，花费的时间太长并且似乎导致性能问题吗？

您最近是否更改了recovery_time选项？ 还是您每分钟运行的事务比以前更多（或更复杂）？

我没有更改recovery_time，默认设置为位。 我会处理一下交易