ASE正常shutdown,启动时也要recovery半天？

logit99

shutdown之前还把进程都杀掉的，但重启的时候，业务库总要recovery十几分钟，然后redo半小时。查了下日志，以前没有的。从上周起开始的2次重启都这样，会是什么原因？还有，有没有办法知道它在REDO的时候相关联的是哪几张表？

andkylee

你kill掉进程，系统还没来得及回滚就重启了，当然会进行recovery了。 很正常的。

logit99

回复 1# logit99


    以前都这样kill进程再重启，没遇到过redo啊，难道这台机器太慢了，要很长时间回滚?
如果不kill掉进程，用shutdown with nowait,那是必然要redo半天的.

andkylee

可能你们的事务都比较长　，比较大吧？

logit99

回复 4# andkylee


    前面又重启了一次，这次没有任何进程在操作，所以也没有kill进程，但重启之后还是redo了半个小时。估计有什么表坏掉了。而且在shutdown 的时候，正常情况下应该命令一执行，几秒钟就停了，但我发现要等个2分钟再停。

andkylee

dbcc checkdb检查一下

Eisen

-t7409试试先不回滚启动，然后看看是否log空间不足以作完redo和undo，如果不够的话，先扩一下log然后再正常启动一次试试。

wfcjz

先执行6楼所说的DBCC。然后去看DBCC对果。

然后再按照7楼的加-t7409启动看日志里有什么？

andkylee

回复 7# Eisen


    traceflag 7409 Force the server to scan *data* segment allocation pages; to recalculate free data page space rather than use saved counts at boot time. (see case 11195087)

    加这个参数不会导致不回滚吧？此参数用来解决空间统计不准确导致不能正常启动的问题，好像本论坛有关于使用该traceflag的一个帖子。


加traceflag 3608   试试， 仅仅恢复master库，而不恢复用户库也不做检查点。

logit99

回复 6# andkylee


    dbcc checkdb 太影响系统性能，会慢死的，就是对几张大表做dbcc tablealloc 都非常慢，一慢就死锁进程，是生产库，所以不敢用。