Ok GG experts another question.
If a primary extract is up and running on a production system and the need arises to stop the extract, make a change and restart. Will the database changes made during the time the extract is stopped be lost? I'm assuming they would be, and the databases are now out of sync. If this is the case how do you work around this? Is the only way to take a downtime and prohibit data changes while the extract is stopped?
Thanks In Advance
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.
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?