ORA-00379: no free buffers available in buffer pool DEFAULT for block size 32K

在做异机迁移恢复数据库时,报如下错误。

PSDRPC returns significant error 1013.

PSDRPC returns significant error 1013.

PSDRPC returns significant error 1013.

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 03/03/2017 04:43:22

RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile ‘+DATA/dbtx/archivelog/2017_03_03/thread_2_seq_9187.323.937629789‘

RMAN>

因为之前设置了db_32k_cache_size参数,并且建立了32k block_size大小的表空间,但是现在用的参数文件无db_32k_cache_size参数,导致无法为相应的块按照32k的block_size来分配buffer cache,因此参数文件中加入db_32k_cache_size参数问题解决。

时间: 2024-10-10 21:17:31

ORA-00379: no free buffers available in buffer pool DEFAULT for block size 32K的相关文章

shared pool 和buffer pool 详解(之二, Cache Buffers LRU Chain、Cache Buffers LRU Chain闩锁竞争与解决)

[深入解析--eygle]学习笔记 1.1.2  Cache BuffersLRU Chain闩锁竞争与解决 当用户进程需要读数据到Buffer Cache时或Cache Buffer根据LRU算法进行管理等,就不可避免的要扫描LRU  List获取可用Buffer或更改Buffer状态,我们知道,Oracle的Buffer Cache是共享内存,可以为众多并发进程并发访问,所以在搜索的过程中必须获取Latch(Latch是Oracle的一种串行锁机制,用于保护共享内存结构),锁定内存结构,防止

buffer pool和shared pool详解(之四,重要视图、以及转储)

1.2.5  X$KSMSP视图 Shared  Pool 的空间分配和使用情况,可以通过一个内部视图来观察,这个视图就是X$KSMSP. X$KSMSP的名称含义为: [K]ernal [S]torage [M]emory Management [S]GA Hea[P]其中每一行都代表着Shared Pool中的一个Chunk.以下是x$ksmsp的结构: 12:03:45 [email protected] SQL>desc x$ksmsp Name                     

buffer pool 和shared pool 详解(一)

[深入解析--eygle]学习笔记 1.1 buffer pool原理 Buffer Cache是Oracle SGA中一个重要部分,通常的数据访问和修改都需要通过BufferCache来完成.当一个进程需要访问数据时,首先需要确定数据在内存中是否存在,如果数据在Buffer中存在,则需要根据数据的状态来判断是否可以直接访问还是需要构造一致性读取:如果数据在Buffer中不存在,则需要在Buffer Cache中寻找足够的空间以装载需要的数据,如果Buffer  Cache中找不到足够的内存空间

020:InnoDB Buffer Pool

一. 缓冲池(Buffer Pool) 1. 缓冲池介绍 每次读写数据都是通过 Buffer Pool : 当Buffer Pool 中没有用户所需要的数据时,才去硬盘中获取: 通过 innodb_buffer_pool_size进行设置总容量,该值设置的越大越好: innodb_buffer_pool_instances 设置为多个缓冲池: 总容量还是innodb_buffer_pool_size 设置多个instance 可将热点打散,提高并发性能(建议设置成CPU个数值) Buffer P

SQL Server 2014新特性——Buffer Pool扩展

Buffer Pool扩展 Buffer Pool扩展是buffer pool 和非易失的SSD硬盘做连接.以SSD硬盘的特点来提高随机读性能. 缓冲池扩展优点 SQL Server读以随机读为主,SQL Server IO分为2部分:buffer pool管理方式,和buffer pool. SQL Server 从磁盘中读入数据,并且存放在buffer pool中以供读取和修改,修改完之后脏数据还是放在buffer pool中,当内存紧张执行lazy write把脏数据写入磁盘,并且释放内存

Innodb Buffer Pool内部结构

Innodb Buffer Pool内部结构 1.    Innodb Buffer 功能 Innodb buffer pool的主要功能存储外存页面在内存中的镜像.镜像有如下2种镜像: (1)只读镜像:只读镜像读取的是非脏页. (2)更新镜像:更新镜像为buffer pool中的脏页. Innodb实现了行级多版本(MVCC),而不是整个页的多版本.Oracle在实现中存在第三种镜像,就是版本镜像.而innodb中确实没有.在innodb中任何外存中的脏页的读取以及更新都是在buffer po

MYSQL的InnoDB Buffer Pool内部机制

1. 基本结构:INNODB用least recently used (LRU) 算法来管理他的buffer_pool. buffer_pool在内部被分隔为两个list. a young list 和 a old list. Young list 存储那些高频使用的缓存数据(默认占整个BUFFER的5/8) Old list 存储那些低频使用的数据(默认占整个BUFFER的3/8) 2.使用机制:当一个新块数据被从磁盘缓存到buffer当中,它默认被放在Old list的头部,即midpoin

MySQL buffer pool中的三种链

三种page.三种list.LRU控制调优 一.innodb buffer pool中的三种页 1.free page:从未用过的页 2.clean page:干净的页,数据页的数据和磁盘一致 3.dirty page:脏页 SQL执行需求: 1.找free页 2.刷新脏页 1.这个页不是热的数据页(刷冷页) 2.这个页最早修改时间(刷修改时间比较早的页,有可能是热页),方便日志文件的覆盖 3.覆盖冷的clean页 为了实现上述需求,innodb用到链表技术(每种链表一种作用,链的存在意义是为了

关于MySQL buffer pool的预读机制

预读机制 两种预读算法 1.线性预读 2.随机预读 对预读的监控 一.预读机制 InnoDB在I/O的优化上有个比较重要的特性为预读,预读请求是一个i/o请求,它会异步地在缓冲池中预先回迁多个页面,预计很快就会需要这些页面,这些请求在一个范围内引入所有页面.InnoDB以64个page为一个extent,那么InnoDB的预读是以page为单位还是以extent? 数据库请求数据的时候,会将读请求交给文件系统,放入请求队列中:相关进程从请求队列中将读请求取出,根据需求到相关数据区(内存.磁盘)读