The current size of our database is around 2TB. The current estimate for binary dump, load and re-building index is around 25 hours (using 32 cores).
Our application is 24/7/365, so bring it down for 25 hours will be a great challenge for me to sell to our stakeholders. Alternatively, there are some options which I could consider at Business level which will help to minimise the downtime of the application.
However, I was thinking whether it is possible to Restore AI files created on a newly created database? by following below steps-
1. Backup the database at a cut off time, take a copy to server B
2. Enable AI Image file in server A
3. Leave the current database in server A up and running as normal with AI files turned on
4. on Server B - run binary dump, load and rebuild the index
5. on Server B - on completion, shutdown database on server A, copy AI files to Server B, now is it possible to apply those AI files that have been created on to the newly created database?
I've tried playing with the sports database, it throws lots of system error but those errors are not easy to understand.
Any help on this will be appreciable.
What are you trying to do isn't possible. That isn't the way that after imaging works.
The first question is why are you doing the dump and reload? Make sure you have a valid reason first. (You might)
For databases this size you are usually better off doing partial dump and reloads... usually by storage area. Take more outages and do a portion per outage. Assuming of course you are going to see any benefit from the dump and load.
Unfortunately step 5 will not work. Roll forward process expects the same physical layout from the source and target database. For example, to apply a record change AI note on server B, information of the record, like area number, block-number, offset etc. from the note (generated from server A) must match the one on server B. However, binary load and index build will change the physical layout of the record on server B, so when you try to apply the AI file, you may see all kinds of errors like dbkey mismatch, update counter mismatch, cannot locate buffer and so on.
Dapeng
Thanks both for your quick response.
Yes I share the same experience, but thought of checking if someone has tried breaking algorithm behind mismatch counters and keys :-)
> 2. Enable AI Image file in server A
Do you not have AI enabled currently in production?
> On Mar 3, 2016, at 10:06 AM, eswarm wrote:
>
> Yes I share the same experience, but thought of checking if someone has tried breaking algorithm behind mismatch counters and keys :-)
doing that will not help.
the counters are there for a reason. when a block's counters don't match the counter in the ai note, nearly always the data in the block will not match either.
ignoring the mismatched counters when a note that says "replace the 23 bytes at block offset 581 with these other 48 bytes in area 12, block 651" is applied will result in corruption and maybe a crash if the contents of the data block is not in the expected state.
other notes could cause knots in linked lists.
Rob, It is enabled for replication plus.
For this specific task, I thought of keeping it very simple.
Has anyone used Bravepoint's Pro D&L, it sounds what I've been looking for, but would like to know people experiences before contacting them.
I have used it and it gets the job done, but I might be a bit 'biased', so I'll let others to comment.
I have been using Bravepoint's Pro D&L several times since 2005. You will have some small down time, that will be basically the time to restore a database back in place. Definitely not 25 hours.
The actual D&L I would be doing on a replica (server B) and then bring the resulted database to server A.
And then apply the changes that were made during that time (not through apply AI) while the old primary still working.
The best thing that I like about Bravepoint's Pro D&L is that you are not in a hurry in D&L process. It takes as long as it takes.
If something goes wrong you just try again and the downtime that I talked above happens only when everything is done, well almost everything.