F_JD0A6C: An invalid offset <number> encountered error with Sql*Server.
Has anyone seen this error on MS SQLServer before? We can not get the Capture to start.
2019-06-02T08:22:33-04:00: sql2azn-cap-prcrm: F_JD0A6C: An invalid slot offset 61194 encountered at \[002307EF:00037A8F:0001\].
F_JT140F: The previous error occurred before any records were scanned. The scan start time was 2019-06-02T08:20:32-04:00 at address 002307ef:00037a8f:0010 with SEQ 0x2307ef00dea3c0.
Environment: MS SQLServer 2008, SP3 on Windows NT 6 (SP2) with HVR 5.5.
We figured it out. We discovered that using TDE (transparent data encryption) requires using the SQL method of capture.
Enabling a MS SQL*Server database to use TDE has the effect of "zeroing out" the remaining part of the virtual transaction log to force the next virtual transaction log. This guarantees that no clear text is left in the transaction logs after the database is set for encryption. You can find the status of the log file encryption by viewing the encryption_state column in the sys.dm_database_encryption_keys view.
For replication then we should use the SQL method for capture.
Then what are our performance implications for using SQL Method? Do we leverage the SQL Engine?
When we use the SQL interface we use database functions to retrieve log fragments and to retrieve log backup fragments. The increments at which we can get the logs are relatively small so this generates a fair amount of overhead. Also, the LOBs don't come through in their entirety which have to be fetched generating additional overhead. Whether this extra overhead causes a problem or latency, of course, depends on the workload and scenario. For TDE we do not have an alternative at this time but have an enhancement request to support TDE through the native interface but we'd have yet to research if that is possible.
It is recommended that you keep the agent local to the source server and you'll minimize some of the performance impact you may observe.