OGG for SQL Server - Extract stops capturing - Bug?

Question

Hi, all,
I've found a problem with OGG for SQL Server where the Extract stops capturing data after the transaction log is backed up. I've looked for ways to reconfigure OGG to avoid the problem but couldn't find any reference to options to workaround this problem. It seems to be a bug to me.
My Extract configuration is as follows:
EXTRACT ext1
SOURCEDB mssql1
TRANLOGOPTIONS NOMANAGESECONDARYTRUNCATIONPOINT
EOFDELAY 60
EXTTRAIL dirdat/e1
TABLE dbo.TestTable;
I'm using the EOFDELAY parameter for testing purposes only, since it's easy to reproduce the scenario that causes the issue when the extract polling is configured with longer intervals.
When the Transaction Log backup runs, SQL Server marks all the virtual logs that are older than the primary and secondary truncation points as inactive (status = 0). These virtual logs can then be reused if required. They still contain change records, though, and OGG can read from then if required, before they are overwritten. This situation will never occur if we are not using SQL Replication and have the Extract configured with the parameter MANAGESECONDARYTRUNCATIONPOINT.
However, I'm trying to simulate a scenario where OGG is used along SQL Replication and the extract is configured with the NOMANAGESECONDARYTRUNCATIONPOINT option. The situation that I've reproduced and caused the Extract to stop capturing is the follow sequence of events:
1. Extract reads transaction log and capture change up to LSN X
2. More change are made to the database and the LSN is incremented
3. Log Reader reads Transaction Log, captures changes up to LSN X+Y and advances the secondary truncation point to that LSN
4. A transaction log occurs, backs up all the active virtual logs, advances the primary truncation point to a LSN greater than LSN X+Y, and marks all the virtual logs with LSNs <= X+Y as inactive (status = 0)
5. Changes continue to happen in the database consuming all the available inactive virtual logs and overwriting them.
6. The extract wakes up again to capture more changes.
At this point, the changes between LSNs X and X+Y are not in the Transaction Log anymore, but are available in the backups. From what I understood in the documentation the Extract should detect that situation and retrieve the changes from the Transaction Log backups. This, however, is not happening and the Extract becomes stuck. It still pools the transaction log at the configured interval query the log state with DBCC LOGINFO, but doesn't move forward anymore.
If I stop and restart the Extract I can see from the trace that it does the right thing upon startup. It realises that it requires information that's missing from the logs, query MSDB for the available backups, and mine the backups to get the required LSNs.
I would've thought the Extract should do the same during normal operation, without the need for a restart.
Is this a bug or the normal operation of the Extract? Is there a way to configure it to avoid this situation without using NOMANAGESECONDARYTRUNCATIONPOINT?
The following is the state of the Extract once it gets stuck. The last replicated change occurred at 2012-07-09 12:46:50.370000. All the changes after that, and there are many, were not captured until I restarted the Extract.
GGSCI> info extract ext1, showch
EXTRACT EXT1 Last Started 2012-07-09 12:32 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:54 ago)
VAM Read Checkpoint 2012-07-09 12:46:50.370000
LSN: 0x0000073d:00000aff:0001, Tran: 0000:000bd922
Current Checkpoint Detail:
Read Checkpoint #1
VAM External Interface
Startup Checkpoint (starting position in the data source):
Timestamp: 2012-07-09 11:41:06.036666
LSN: 0x00000460:00000198:0004, Tran: 0000:00089b02
Recovery Checkpoint (position of oldest unprocessed transaction in the data so
urce):
Timestamp: 2012-07-09 12:46:50.370000
LSN: 0x0000073d:00000afd:0004, Tran: 0000:000bd921
Current Checkpoint (position of last record read in the data source):
Timestamp: 2012-07-09 12:46:50.370000
LSN: 0x0000073d:00000aff:0001, Tran: 0000:000bd922
Write Checkpoint #1
GGS Log Trail
Current Checkpoint (current write position):
Sequence #: 14
RBA: 28531192
Timestamp: 2012-07-09 12:50:02.409000
Extract Trail: dirdat/e1
CSN state information:
CRC: D2-B6-9F-B0
CSN: Not available
Header:
Version = 2
Record Source = A
Type = 8
# Input Checkpoints = 1
# Output Checkpoints = 1
File Information:
Block Size = 2048
Max Blocks = 100
Record Length = 20480
Current Offset = 0
Configuration:
Data Source = 5
Transaction Integrity = 1
Task Type = 0
Status:
Start Time = 2012-07-09 12:32:29
Last Update Time = 2012-07-09 12:50:02
Stop Status = A
Last Result = 400
Thanks!
Andre

Answer 1

It might be something simple (or maybe not); but the best/fastest way to troubleshoot this would be to have Oracle (GoldenGate) support review your configuration. There are a number of critical steps required to allow GG to interoperate with MS's capture API. (I doubt this is it, but is your TranLogOptions on one line? It looks like you have it on two , the way it's formatted here.)
Anyway, GG support has seen it all, and can probably wrap this up quickly. (And if it was something simple -- or even a bug -- do post back here & maybe someone else can benefit from the solution.)
Perhaps someone else will be able to provide a better answer, but for the most part troubleshooting this (ie, sql server) via forum tends to be a bit like doing brain surgery blindfolded.