| In this Document
APPLIES TO: Oracle GoldenGate – Version 9.5_EA and later
IBM AIX on POWER Systems (64-bit)
***Checked for relevance on 06-Aug-2012*** GOAL 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 FIX OGG 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 required RAWDEVICEOFFSET Directs Extract where to start reading on a raw device. For most operating systems, the offset is 0, but on the AIX platform it is 4096 bytes. RAWDEVICEOFFSET 0 must be used if the customer’s device is configured with the -TO option. The -TO option directs Oracle not to skip the first 4096 bytes of the logical volume, but start writing at 0. (When Oracle skips the first 4096, it can cause problems with fractured blocks.) RAWDEVICEOFFSET 0 directs Extract to start reading where Oracle starts. There is an Oracle utility named offset that helps determine the offset value, located in:
$ORACLE_HOME/bin/offset More Info:
The real scenario is: if "-TO" option was turned on, GoldenGate got error 22 problem; if "-TO" option was turned off, GoldenGate could work properly.
Below is the parameters used to generate logical volume on an AIX cluster for Oracle files: 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":
There is a fairly new -T flag on mklv that is described by CMVC Defect 389055. This flag is NOT documented on the mklv man page. The purpose of this flag is to use with Oracle to tell it to NOT skip the first 4096 bytes of the logical volume. 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 |
转到底部