This content has been marked as final. Show 2 replies
Sure, don't let things get out of sync and you'll be fine.
You can piecemeal your replication. If you put everything into one process group, not such a good idea. If you can group your groups, so to speak, you won't have a single point of failure with respect to the data being replicated.
Aside from what GoldenGate shows (long running, clobs, pk/fk type of relationships), you can separate schemas or applications.
Make it easy to access older archived redo logs. If you need to reach back in the past, having the relevant ARLs available makes life easier.
Probably trial and error, but figure out what your cut-off time is for trying to fix things via GoldenGate via just starting over.
We will try the best to sync the data of course.
We are currently replicating one schema only. There are a couple of tables which occupies 5000 million and 9000 million of rows and getting around 50 million inserts per table per day, our worry is that if one of these tables are out of sync to resync a table which such activity and amount of data the procedure can be tricky.
The procedure I mentioned with RMAN is straight forward in terms of Oracle but I have doubts how to deal with the OGG checkpoint table and the OGG trails in the target site when the target database is restored and recovered, how to get these synced with the database just recovered.
Today is the 3TB database but in a couple of months time if OGG works well we will start another project to replicate a 45TB database.