您说的这个案例，只有通过传统的全库恢复来解决了，没有什么特别好的办法。如果存储宕了，啥都完了。
是重复出现这样的问题吗? 还有在你执行这个sql的时候，是否有其他的记录日志的操作。。
生产运维表时，可能有其他表或package与之相关。请问：如何查看与一个表相关的package名（例如存储过程里有对表的一些SQL操作，编译生产package后，如何查找哪些package与该表相关）？
for Oracle, OEM (Cloud Control 12c or Grid Control 11g)
备份时需要显式带include logs参数的话，应该是V9.7以下的版本了。出现这个报错，是因为备份时需要已经归档的日志S0007672.LOG，而这个日志估计已经被移走了。当带了include logs参数的时候，归档日志最好保留个两天再移走，这样可以避免因为找以前的日志而无法备份的情况。...
肯定要很久，由于logfilsiz设置为25000（970MB），而softmax设置为520，也就是说从日志角度970*5.2接近5GB，从而导致db2stop force时隐匿deactivate db都要写最多5GB日志的缓冲池脏池到硬盘上，这样肯定快不了。建议解决的办法为降低logfilsiz在100MB、softmax到100、调高logprimary，这...
这个问题感觉不是太好回答，建议你去看看每个版本升级后这些方面有哪些改进，这虽然比较费时，但应该可以告诉你想知道的内容
THIS MAY BE A BUG ,IT MAY EXIST IN DB2 LEVEL THAT LOWER THAN V9.7.4。Problem conclusionFixed in DB2 V9.7 FP4To possibly avoid the issue, make sure that number of openfiles(nofiles, ulimit -n) ulimit is not set greater than 64K.1. To get the value for...
