在启动数据库 (指database open)时若需要recovery的redo较多，涉及到的数据块多时可能会看到以下信息: > Buffer cache spillover: only 32768 of 117227 buffers available$   这是由于crash recovery的redo apply本身需要用到buffer cache，此时buffer cache被称作recovery buffer。 一旦分配了recovery buffer，其将不会被释放或age out直到所有数据块的redo change都被应用并写入到磁盘。   由于只有一个实例可以参与recovery(不管是crash recovery还是instance recovery)，恢复实例的buffer cache 大小将会是大规模恢复数据文件(recovery)的限制。 在锁声明阶段(lock claim phase)，若实例耗尽了空余的buffer cache 则会spillover溢出到磁盘上(有点像swap)并必须予以处理。此时锁声明会暂时中止，oracle会先应用日志将redo change应用到哪些已经声明过的buffer cache中。直到所有这些recovery buffer都被恢复并被写出，此时它们才变得对下一次后续的锁声明可用。 由于以上说明的磁盘溢出恢复(spillover recovery)持续多次锁声明和日志应用阶段(理想的是一次锁声明，一次日志应用即完成redo apply)，直到本次完整的恢复完成。 需要注意的是，以上crash recovery的算法在 buffer cache很小的情况下性能较差； 常见的例子是这样的， 在产品数据库中由于有着较大buffer cache而不会遇到该问题，而在某些基于存储或卷管理软件实现的复制、测试环境中，由于需要恢复的数据集合较大而且往往db_cache_size比产品库小很多，所以alter database open时往往看到该(Buffer cache spillover: only 32768 of 117227 buffers available$)，且打开数据库耗费比产品库更多的时间。   我们一般不用担心buffer cache spillover，因为即便速度缓慢在10分钟内数据库往往还是能够打开的，但是如果你监控着alert.log 30分钟都没有任何新日志，那么可能是spillover导致的hang，如果遇到该问题请去OTN Ask Maclean