that is not true.
When you restart (stop/start) extract, it starts reading from the old SCN where it was stopped/last checkpoint. . it means you do not loose any database changes during the time EXtract was stopped. Only you will note a Lag with Extract when you start it.
hope this helps.
Take care of your backup Policy. for example, in our environment, we use GGS with MS SQL Server 2008 R2. Our backup log of databases are made with Netbackup on a distant server (dump and purge of the log file), the file generated by Netbackup aren't stored on the local MS SQL server and aren't available by GGS. In this case, the stop of an extract must be as short as possible and out the window time of backup. This is the only known case we've experimented a desynchronization between source and target databases.
In the other cases, as explained by 11g, GGS never loose information.
Hey jmbien, in your case with SQL Server, you are really putting yourself at risk with that configuration. I'm assuming you are running Extract with MANAGESECONDARYTRUNCATIONPOINT, let me know if otherwise.
Let's say for example Extract is up and running and that a transaction log backup is about to finish, but just prior to the log backup finishing, a transaction occurs. And let's say Extract is about to capture the next transaction when all of a sudden, the log backup completes and flushes all committed transactions out of the log, just before the Extract captured that new transaction. Extract at this point will switch to the log backup to look for it, but in your case, it can't read the log backup so it abends. That's it. Resync will need to happen now. I've seen this happen too. Just fyi.
However, check out OGG 12c, I think there is a new parameter called ACTIVESECONDARYTRUNCATIONPOINT that you can use instead that wouldn't mark that transaction as flushable from the transaction log until the Extract has indeed captured it. This parameter negates the need for Extract to read from log backups so you're free to use any technology for them that you wish.
thanks for your comment.
I'm going to test this new parameter as soon as possible.
It's the benefit of GoldenGate that you don't need any downtime even if you are upgrading the database. All these can be taken care by using Golden Gate.
I know I have a checkpoint table set up on the replicat side, but not on the extract side. Is this correct? If it is I guess the on the extract side the extract keeps track of things via a file in one of the gg directories?
In my test environment, if I want to start over, say truncate the tables on the replicat side, redo initial load, how do I reset the extract and replicat? I'm guessing I would stop the replicat and extract, and datapump, delete them, truncate the tables on the replicat side, then restart from scratch?