TRANLOGOPTIONSRAWDEVICEOFFSET
今天介绍一下ogg中TRANLOGOPTIONS RAWDEVICEOFFSET参数,在ogg的官方文档中是没有这个参数的说明的。 这个参数的作用就是,当你使用裸设备的时候需要设置该参数。 下面看看mos上咋说: Oracle GoldenGate Supports Reading Redo And Archive Log files Store
今天介绍一下ogg中TRANLOGOPTIONS RAWDEVICEOFFSET参数,在ogg的官方文档中是没有这个参数的说明的。
这个参数的作用就是,当你使用裸设备的时候需要设置该参数。
下面看看mos上咋说:
Oracle GoldenGate Supports Reading Redo And Archive Log files Stored On Raw Devices With Source Database On AIX OS And Also Requires TRANLOGOPTIONS RAWDEVICEOFFSET Parameter (文档 ID 1269855.1) | 转到底部 |
In this Document
APPLIES TO:Oracle GoldenGate – Version 9.5_EA and later GOALOracle GoldenGate Supports Reading Redo And Archive Log files Stored On Raw Devices With Source Database On AIX OS And Also Requires TRANLOGOPTIONS RAWDEVICEOFFSET ParameterFIXOGG supports redo and archive log files stored on raw devices, but if the Source database exists on AIX OS then the use of TRANLOGOPTIONS RAWDEVICEOFFSET 0may be requiredRAWDEVICEOFFSET There is an Oracle utility named offset that helps determine the offset value, located in: More Info: mklv -y 'o_entry_d_01' -t 'raw' '-S64K' -TO ora_entry_vg 129 hdiskpower21 hdiskpower22 hdiskpower23 hdiskpower24 hdiskpower25 hdiskpower26 hdiskpower27 hdiskpower28 Before option "T" was turned on, GoldenGate had an "error 22" problem and could not be started. After option "T" was on, GoldenGate worked properly. The default for AIX is 4096. Included below are comments from IBM about option "-TO": When Oracle skips the first 4096, it can cause problems with fractured blocks. When Oracle sees a type of "O" (uppercase O, not 0 zero), it will intentionally overwrite the LVCB by starting at the beginning of the LV, thus preventing fractured 4K blocks. The problem was being seen when a halt -q was issued, and any fractured blocks became corrupted. By default, the first 4k of each AIX Logical Volume is reserved for the Logical Volume Control Block(LVCB). This means that the first Oracle data block begins at a 4k offset into the Logical Volume. When fine granularity striping is used (either within AIX LVM or within ESS RAID-5 or RAID-10 arrays), this can result in a slight I/O performance degradation when an Oracle DB Block Size is greater than 4k is used. (An 8k DB Block Size is typical for OLTP applications and a 16k DB Block size is typical for Data Warehouse applications.) This is because every few DB blocks are physically split across device boundaries – with the first part of the DB block residing on one physical disk and the remainder of the DB block residing on another physical disk. This can result in two physical I/Os being required to read or write a single DB block. The larger the DB Block size used, the higher the percentage of split blocks and the greater the potential for I/O performance degradation. When running Oracle 9i Release 2 (or later), it is possible to eliminate the 4k offset. This is recommended for new Oracle implementations or for existing applications with extremely high I/O performance requirements. Currently, the capability to do this is delivered in two parts: An IBM AIX e-fix (APAR IY36656 for AIX 5.1) and an Oracle patch (bug 2620053). The functionality will be included in future release levels of AIX and in Oracle 9.2.0.3 or later. Once the prerequisite software has been installed, do the following to take advantage of the zero offset feature: In order to eliminate the 4k offset for an existing Oracle database, new Logical Volumes must be created and the existing data must be migrated to the new Logical Volumes using normal migration procedures. This parameter is valid for RAC also. However, please make sure all the Database thread in RAC has the same offset/setup when using raw device for the redo log, as GoldenGate can't set specific RAWDEVICEOFFSET |