博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Buffer cache spillover: only buffers
阅读量:4683 次
发布时间:2019-06-09

本文共 1150 字,大约阅读时间需要 3 分钟。

在启动数据库 (指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  

转载于:https://www.cnblogs.com/macleanoracle/archive/2013/03/19/2968336.html

你可能感兴趣的文章
hdu1232 畅通工程 并查集的 应用
查看>>
JavaScript 数据类型检测总结
查看>>
克隆数组的几种方式?
查看>>
什么是XMLA-- XML for Analysis
查看>>
Sharepoint2013商务智能学习笔记之使用Current User Filter筛选Excel 数据(六)
查看>>
2012-11-13:延期通知书
查看>>
CodeForces - 367C Sereja and the Arrangement of Numbers
查看>>
js添加文件引用,可以智能感知
查看>>
大数据学习——VMware安装
查看>>
[BZOJ2125]最短路
查看>>
对象和数组的相互转化
查看>>
为什么存储过程比sql语句效率高?
查看>>
非遗园
查看>>
django forms的常用命令及方法(一)
查看>>
python 去除微软的BOM
查看>>
Maven下载私服上的jar包(全局)
查看>>
pytorch 2 variable 变量
查看>>
CentOS 6.5 安装 Python3
查看>>
在flask框架中,对wtforms的SelectMultipleField的一个报错处理
查看>>
java 线程监视器
查看>>