关于昨天被客户问到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不在本文范围内。…