GoldenGate for SQL Server未生成抽取文件，Oracle同步异常求助

Hey there, I’ve run into this exact scenario a few times with GoldenGate—where processes show as running but no trail files get generated, and checkpoints lag way behind. Let’s break down the key troubleshooting steps to get your sync back on track:

1. Dig Beyond info all for Extract Details #

info all only gives a high-level "RUNNING" status, but the real clues are in the detailed extract info and reports:

• Run info extract <your_extract_name>, detail – This will show you the current log read position, checkpoint timestamps, and any quiet errors (like waiting on a specific transaction log) that don’t pop up in ggserr.log. Keep an eye out for lines like "Checkpoint not advancing" or "Waiting for log segment".
• Open the extract report file in the dirrpt folder (e.g., <your_extract_name>.rpt) – Scroll to the bottom for recent entries. Often, you’ll find details here that aren’t logged in ggserr.log—like permissions issues accessing SQL Server’s transaction logs, or a stuck long-running transaction holding up capture.

2. Validate SQL Server Transaction Log Health #

GoldenGate’s SQL Server extract relies entirely on reading transaction logs—if those logs are unavailable or truncated, capture stops cold:

• Check your source database’s recovery model: If it’s set to Simple, SQL Server automatically truncates logs after checkpoints, which wipes data the extract hasn’t processed yet. Switch it to Full recovery model immediately if this is the case.
• Run dbcc sqlperf(logspace) in SQL Server Management Studio to check log usage. If logs are being backed up too frequently (by a SQL Agent job, for example), the extract might be missing out on logs before it can read them. Adjust your log backup retention to ensure logs stay available until GoldenGate processes them.

3. Check dirdat Directory Health #

Even if the extract is running, it might not be able to write new trail files:

• Verify disk space on the server hosting dirdat—if the drive is full, no new files can be created.
• Check OS permissions for the GoldenGate service/user: The account running GoldenGate needs full read/write access to the dirdat folder. On Windows, this means adding the user to the folder’s security permissions with modify rights; on Linux/Unix, ensure the user has rwx permissions.

4. Inspect Manager Process for Hidden Blockages #

Restarting the manager is a good first step, but let’s confirm it’s functioning properly:

• Run info manager to check the listening port, and make sure there are no firewall rules blocking traffic between your source and target servers on that port.
• Review the manager report (dirrpt/MGR.rpt) for errors related to trail file management or process communication. Sometimes the manager can’t register new trail files, even if the extract is running.

5. Force a Trail Rollover (If Necessary) #

If the extract is stuck on an old checkpoint, forcing a new trail file can kickstart capture—only do this if you’ve confirmed you don’t need the 30 hours of lagged data, or you have a backup to restore from:

1. Stop the extract: stop extract <your_extract_name>
2. Force a trail rollover: alter extract <your_extract_name>, etrollover
3. Restart the extract: start extract <your_extract_name>
4. Monitor with info extract <your_extract_name>, detail to see if the checkpoint starts advancing and new trail files appear in dirdat.

6. Verify the Pump Process is Actually Reading Trails #

Since the pump shows as running, double-check it’s pulling data from the source trails:

• Run info pump <your_pump_name>, detail to see if it’s stuck on an old trail position. If it’s not advancing, the pump might be hitting a permission issue or a corrupted trail file.
• Check the pump’s report file in dirrpt for errors like "Trail file not found" or "Failed to read trail header".

内容的提问来源于stack exchange，提问作者mehmet sahin