TRANLOGOPTIONS RAWDEVICEOFFSET

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 0

may be required

RAWDEVICEOFFSET <n>

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 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:

· Create a “big” Volume Group using the mkvg –B flag.

· Create one or more Logical Volumes in that Volume group using the mklv –T O flag. The “-TO” option indicates to Oracle that it can safely use a 0 offset for this Logical Volume.

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 <n> for each thread.  This has to be across the board for all threads.