Heim >Datenbank >MySQL-Tutorial > 关于rmanI/O同步异步问题
困扰了好几日的问题,其实并不是所有的rman备份都会被推入到SGA区的,要分情况看,看系统是否支持异步I/O,还有是否配置了相关的从属I/O参数,磁盘和磁带需要分
困扰了好几日的问题,其实并不是所有的rman备份都会被推入到SGA区的,要分情况看,看系统是否支持异步I/O,还有是否配置了相关的从属I/O参数,磁盘和磁带需要分别看待。现在的书就算买理论的都讲得不清不楚,中国这种教育,害人不浅那。还好查了几日,甚至直接下了一篇Rman的电子书从头读,幸运找到这个文章,写的很具体详实。如果系统支持异步i/o,备份到磁盘是不用使用从属的,就算配置了,数据库也会直接忽略该参数值,而且这种情况仅会使用PGA(从通道中分配内存空间)。
还要注意,配置db_io_slaves是和db_write_process参数有冲突的。具体写到另一篇文章中。
我们在学习Oracle的过程中,或多或少会存在个人对概念的理解错误、误解或者根本是教材编写存在不严谨的地方,这样或以讹传讹或三人言虎,导致在Oracle圈子存在着一些古老相传的迷信(superstition),因为这些迷信已经深入人心了,所以我们几乎很难纠正过来;这其实很有意思,IT作为一个高科技的领域也会出现迷信,说明我们在IT技术的”教学”和”思考”上存在问题,这一点值得深思。
这里我列出几个最为常见的迷信,算作抛砖引玉:
1.几乎所有的Oracle入门教程都会在介绍Large pool的时候这样描述:”RMAN 备份使用large pool作为磁盘I/O缓冲区,配置Large pool有助于提高RMAN备份性能”
Truth:除非你启用了slaves IO,否则rman并不使用large pool
RMAN I/O可以分成三种模式:
Mode Disk tape
Asynchronous I/O(异步) 绝大多数操作系统支持AIO,默认disk_asynch_io为TRUE,即默认启用磁盘异步IO。如果磁盘设备不支持AIO,那么会使用synchronous I/O。磁盘异步模式下RMAN I/O缓冲区域从PGA中分配,相关IO性能信息存放在V$backup_async_io视图中 磁带设备本身不支持AIO(tape I/O is always synchronous),虽然默认tape_asynch_io为TRUE,香港服务器,但磁带设备只能通过IO slaves模拟异步IO,所以启用磁带AIO需要另外设置backup_tape_io_slaves=TRUE。此模式下RMAN I/O缓冲区从shared pool或者large pool中分配,相关IO性能信息存放在V$backup_async_io视图中
Synchronous I/O
(同步)
若disk_asynch_io设置为false,或操作系统不支持异步IO,且dbwr_io_slaves=0时启用Synchronous I/O。此时RMAN I/O缓冲区从PGA中分配,相关IO性能信息存放在V$backup_sync_io视图中 默认backup_tape_io_slaves为false,即磁带设备默认不启用AIO而使用Synchronous I/O。此时RMAN I/O缓冲区从PGA中分配,相关性能信息存放在V$backup_sync_io视图中
Slaves I/O
(从属)
启用disk slaves I/O,要求设置disk_asynch_io=false且dbwr_io_slaves>0。此模式下RMAN I/O缓冲区从shared pool或者large pool中分配,相关IO性能信息存放在V$backup_async_io视图中 设置tape_asynch_io=true且backup_tape_io_slaves=true时启用,磁带的AIO模式其实就是使用slaves Io模拟获得的。所以此模式下的一切和tape AIO完全一样我们在使用RMAN备份数据库时无论是磁盘备份还是磁带备份总是优先期望使用AIO异步IO特性(tape aio比较特殊,见上表),使用AIO的前提是设置合理的初始化参数以及操作系统支持AIO,如果我们使用的操作系统不支持AIO那么我们将不得不使用Synchronous IO同步IO。这并不是世界末日,因为Oracle提供了IO从属进程(slaves IO)来模拟AIO,当然这是退而求其次的。为了启用slaves IO,我们需要手动设置backup_tape_io_slaves或dbwr_io_slaves参数来启用IO从属特性,当使用磁带备份时设置backup_tape_io_slaves(此时tape_asynch_io应当为true)为true,美国空间,当使用磁盘设备时设置dbwr_io_slaves(此时disk_asynch_io应当为false)为非零值。在启用slaves IO的前提下RMAN才会从Large pool当中分配内存并加以利用,如果没有配置large pool(注意如果启用了ASMM,那么Oracle会自动为large pool分配一个granule大小的空间)或者large pool过小,那么RMAN的内存缓冲区将从shared pool中分配。如果Oracle仍不能获得足够内存,那么将本地进程获取足够的IO缓存。若我们启用了I/O slaves,那么很有必要配置一个足够大的Large pool(一般60-100M就足够了),香港虚拟主机,这样RMAN的I/O缓存区可以从large pool中分配,避免了RMAN的I/O buffer和shared pool中的library cache等其他组件发生竞争。
If I/O slaves are used, I/O buffers are obtained from the SGA ,or the large pool, if configured.If LARGE_POOL_SIZE is set, then Oracle attempts to get memory from the large pool. If this value is not large enough, then Oracle does not try to get buffers from the shared pool.If Oracle cannot get enough memory, then it obtains I/O buffer memory from local process memory and writes a message to the alert.log file indicating that synchronous I/O is used for this backup.
在默认情况下Oracle对于磁盘设备使用AIO模式(disk_asynch_io=true & dbwr_io_slaves=0 by default),而对于磁带设备使用synchronous I/O(tape_asynch_io=true & backup_tape_io_slaves=false by default),都不会启用slaves I/O,所以默认情况下RMAN总是从PGA中分配缓存。换而言之在默认情况下,即便配置了较大的Large pool也不会为RMAN所用。
RMAN allocates the tape buffers in the SGA or the PGA, depending on whether I/O slaves are used. If you set the initialization parameter BACKUP_TAPE_IO_SLAVES = true, then RMAN allocates tape buffers from the SGA or the large pool if the LARGE_POOL_SIZE initialization parameter is set. If you set the parameter to false, then RMAN allocates the buffers from the PGA.
我们来通过以下演示,进一步验证AIO/Slave IO环境下RMAN内存缓冲区从哪里分配,并加强印象:
SQL> select * From v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi PL/SQL Release 10.2.0.4.0 - Production CORE 10.2.0.4.0 Production TNS for Linux: Version 10.2.0.4.0 - Production NLSRTL Version 10.2.0.4.0 - Production SQL> show parameter async NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ disk_asynch_io boolean TRUE tape_asynch_io boolean TRUE SQL> select * From v$sgastat where pool='large pool'; POOL NAME BYTES ------------ -------------------------- ---------- large pool PX msg pool 903840 large pool free memory 15873376 backup as backupset database skip offline; SQL> select * From v$sgastat where pool='large pool'; POOL NAME BYTES ------------ -------------------------- ---------- large pool PX msg pool 903840 large pool free memory 15873376 /* 在AIO模式下,全库备份后发现large pool未发生变化 */ SQL> alter system set disk_asynch_io=false scope=spfile; System altered. SQL> alter system set dbwr_io_slaves=2 scope=spfile; System altered. /* 以上启用了磁盘I/O Slave特性 */ SQL> startup force; [oracle@rh2 ~]$ ps -ef|grep i10|grep -v grep oracle 20761 1 0 20:44 ? 00:00:00 ora_i101_G10R2 oracle 20763 1 0 20:44 ? 00:00:00 ora_i102_G10R2 /* 启用I/O Slave后会出现ora_ixxx_SID这样的后台进程 */ SQL> select * From v$sgastat where pool='large pool'; POOL NAME BYTES ------------ -------------------------- ---------- large pool PX msg pool 903840 large pool free memory 15873376 RMAN> backup as backupset database skip offline; SQL> select * From v$sgastat where pool='large pool'; POOL NAME BYTES ------------ -------------------------- ---------- large pool PX msg pool 903840 large pool free memory 24151392 large pool KSFQ Buffers 25276416 SQL> / POOL NAME BYTES ------------ -------------------------- ---------- large pool PX msg pool 903840 large pool free memory 41006432 large pool KSFQ Buffers 8421376 /* 启用了I/O Slave后执行备份操作, large pool中出现了KSFQ Buffers,这个KSFQ buffer就是RMAN所使用的缓冲区, 实际决定该buffer大小的是隐藏参数_backup_ksfq_bufsz和_backup_ksfq_bufcnt */ SQL> col name for a30 SQL> col describ for a70 SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ 2 FROM SYS.x$ksppi x, SYS.x$ksppcv y 3 WHERE x.inst_id = USERENV ('Instance') 4 AND y.inst_id = USERENV ('Instance') 5 AND x.indx = y.indx 6 AND x.ksppinm LIKE '%ksfq%'; NAME VALUE DESCRIB ------------------------------ ---------- ---------------------------------------------------------------------- _backup_ksfq_bufsz 0 size of the ksfq buffer used for backup/restore _backup_ksfq_bufcnt 0 number of the ksfq buffers used for backup/restore /* 在10g中似乎Oracle会自动调控以上2个参数 */ SQL> alter system set "_backup_ksfq_bufsz"=131072; System altered. SQL> alter system set "_backup_ksfq_bufcnt"=1; System altered. RMAN> backup tablespace data01; /* I/O slaves的IO统计信息仍存放在V$backup_sync_io视图中, 而非可能是你所预期的v$backup_sync_io视图 */ SQL> select type,buffer_size,buffer_count from v$backup_async_io; TYPE BUFFER_SIZE BUFFER_COUNT --------- ----------- ------------ AGGREGATE 0 0 INPUT 131072 1 OUTPUT 1048576 4