-
Title
After activation, capture does not read any messages(In AIX platform) -
Description
Capture fails to read redo log when performed an activation on AIX platform
event_log has the following messages:
Warning 2012-08-17 11:00:50.231135 22216856 1286 Capture: A portion of the redo log could not be parsed (capturing from ora112a) [module oct]Notice 2012-08-17 11:00:50.233263 22216856 1286 Capture: Begin record skip at seqno=1516 offset=0 rc=5 (capturing from ora112a) [module oct]OCAP Log has these errors:ocap 2012-08-17 11:00:51.889435 22216856 1286 Block zero has magic number 0x8000ddf1, should be 0x5a5b5c5d or 0x6a6b6c6docap 2012-08-17 11:00:51.891761 22216856 1286 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=ocap 2012-08-17 11:00:51.891789 22216856 1286 Log parser error 5ocap 2012-08-17 11:00:51.891813 22216856 1286 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -
Cause
Redo logs on RAW devices on certain platforms have hard coded offsets.These values were hard coded into the product.If the redo logs are on RAW DEVICE and when this offset changes it causes this error. -
Resolution
WORKAROUND:stop captureset param SP_OCT_REDO_RAW_OFFSET 0start captureSP_OCT_REDO_RAW_OFFSET description:This parameter tells the Capture process how many bytes to skip when it reads a redolog or data file that is located on a raw device. These bytes need to be skipped on certainplatforms because they are reserved for the operating system's use. This parametershould be kept to the default setting of -1, which tells Capture to use the default valuethat is programmed for the platform.Default: -1Range of valid values: any integerTakes effect: when Capture is restarted--------------------------------------------------------------------------In later versions like SharePlex 9.1 and up, the event log messages are modified as shown below:
Info 2018-03-27 16:51:44.604251 29813 643084816 Capture exited with code=1, pid = 29814 (capturing from o.ORA11GR2)
Error 2018-03-27 16:51:44.601373 29814 1114429760 Capture: [SP-OCT01001] Unable to find archivelog with sequence#: 77041 (thread: 1). <CAUSE> SharePlex was unable to locate the redo/archive log for sequence 77041 in the database location or under the directory defined by SP_OCT_ARCH_LOC parameter. <ADVICE> Restore this archivelog to archive location if missing or set the file's location using SP_OCT_ARCH_LOC. Make sure it is not compressed then restart capture. See 'http://advice.shareplex.com/SP-OCT01001' for additional advice and support. (capturing from o.ORA11GR2) [module oct]
Likewise, the output of “status” issued from source sp_ctrl gives out a clearer hint (reason) for Capture error by printing the message “Stopped: missing archive log” as below:
sp_ctrl (alvsupl14:9111)> status
Brief Status for alvsupl14
Process State PID Running Since
--------------- ------------------------------ -------- --------------------
Cop Running 29813 27-Mar-18 16:51:30
Capture Stopped: missing archive log
Read Running 29816 27-Mar-18 16:51:30
Export Running 29815 27-Mar-18 16:51:30
Cmd & Ctrl Running 29861 27-Mar-18 16:51:34
-
Additional Information
SP-OCT01003 Setting the parameter to 0 for AIX means that the default value used is not true and that no offset should be used when reading the redo logs. The parameter below is a workaround in case the offset has changed. ----------------------------------------------------------------------- In most platform, when we use raw devices for saving Oracle files such as datafile or redolog file, Oracle could use the first block of the device. However, in case AIX and HP Tru64 it's a little bit different. There is a feature in AIX which saves OS information in the first block of volume with special Logical Volume Control Block (LVCB). In this case, Oracle skips the first block and from second block it saves Oracle information. For performance issue, however, Oracle generally wants to use the first block, and fortunately AIX is able to control the block usage for Oracle activity. That is , as system engineer creates a raw volume, if he uses a special option like ["-T O"], Oracle can have a chance to use the first block with zero offset. Oracle documents says: NOTE: If you have an AIX version that supports zero offset Raw Logical Volumes (RLVs), and your Oracle version is 9.2.0.3 or higher, it is strongly recommended that you use an RLV with a zero offset (by including the "-T O" option when creating the RLV with the "mklv" command). So then, if the volume(raw device) is created that way, what does SharePlex or GoldenGate have to to? Basically, these products are programmed adaptable this special attribute, that is, in AIX platform, those will try to read Oracle data by skipping the first block. Problem is that if system engineer makes volumes with zero offset, we have to use special parameter in SharePlex or GG like SP_OCT_REDO_RAW_OFFSET / RAWDEVICEOFFSET. Generally, the volumes are created without zero offset feature, Oracle warns it and writes following information in alert log. In this case, if DBMS is shutdown abnormally, data loss issue could happen.