关于昨天被客户问到Oracle RAC在节点间的同步问题,今天稍微整理一下。 由于Oracle RAC多节点共用一份数据库Datafile,因此在磁盘存储方面不存在同步问题。那么实际上所谓各节点同步指的是每个节点间SGA的同步,更专业一些的术语其实就是SCN propagation的算法。 在Oracle9i和Oracle10gR1中,SCN propagation默认使用Lamport方案,受到初始化参数MAX_COMMIT_PROPAGATION_DELAY影响,默认的同步间隔是7秒,也就是在极限情况下,一个节点上的更新在7秒后另外的节点才能知道。将该参数值设置为0,则表示要求任何一个事务在commit之后就立刻通知其他节点SCN变更了,这种方式就被称为BOC(Broadcast On Commit)。 在Oracle10gR2和Oracle11g中,BOC被作为了SCN propagation的默认方案,初始化参数MAX_COMMIT_PROPAGATION_DELAY被废弃,转换成了隐含参数_IMMEDIATE_COMMIT_PROPAGATION,默认值为TRUE。 SQL> @hidden Enter value for par: propagation old 14: x.ksppinm like ‘%_&par%’ new 14: x.ksppinm like ‘%_propagation%’ NAME VALUE ISDEFAULT ISMOD ISADJ —————————————- ————————- ——— ———- —– _evt_system_event_propagation TRUE TRUE FALSE FALSE _immediate_commit_propagation TRUE TRUE FALSE FALSE max_commit_propagation_delay 0 TRUE FALSE FALSE 在Oracle11g RAC中,BOC有了更进一步的改善。包括:…
Month: May 2009
ORA-00064 When Oracle Database Instance Startup
根据Metalink Bug 5455094的解释,在Oracle9iR2 RAC环境中,如果db_cache_size + db_keep_cache_size总共超过了50G,那么数据库实例就会在启动的时候报ORA-00064错误,无法正常启动。 00064, 00000, “object is too large to allocate on this O/S (%s,%s)” // *Cause: An initialization parameter was set to a value that required // allocating more contiguous space than can be allocated on this // operating system. Metalink上的建议是: 1. 降低cache size(这是一个很扯淡的建议,直接无视) 2. 设置_ksmg_granule_size到一个比较大的值,比如_ksmg_granule_size=67108864,实测结果当设置该参数之后,数据库性能低下,反应缓慢。 客户的这个环境,数据库SGA设置高达200G,以上两种方法都不能使用,却可以通过土办法来曲线救国。 1. 设置SGA_MAX_SIZE = 200G,这个参数不会触发Bug…
How to recover data with DUL after table dropped
首先系统情况如下: 1. Oracle版本是9.2.0.8,操作系统是IBM AIX 2. 数据文件存储在裸设备上 3. 被删除的表是分区表 4. 数据库非归档,没有任何备份 5. 在误drop table以后,立刻将包含该表的表空间offline了,并且保留了当时的current online redo文件 6. 保留了之前建表时的create脚本 恢复过程如下: 1. DUL使用的init.dul内容: osd_big_endian_flag=true osd_dba_file_bits=10 osd_c_struct_alignment=32 osd_file_leader_size=1 osd_word_size=32 control_file=/tmp/control.dul db_block_size=8192 compatible=9 2. DUL使用的control.dul文件内容 58 58 /somepath/rawdevice1 4096 blocks 4095873 58 110 /somepath/rawdevice2 4096 blocks 639873 58 126 /somepath/rawdevice3 4096 blocks 255873 第1位是TS#,第2位是RFILE#,第3位是数据文件全路径,第4位是在AIX系统中裸设备需要跳过的字节,第5位是数据文件的真实block数(从v$datafile中以size/db_block_size获得)。 第4,5两位在数据文件为裸设备的情况下才需要,否则在scan database时扫描到裸设备结尾的时候,将可能报错。 3. 通过logminer得到被drop掉的表分区的data object id(因为被drop了,因此无法从system数据字典中获得)。如何使用Logminer不在本文范围内。…