Unsolved
This post is more than 5 years old
46 Posts
0
971
RecoverPoint consolidate_snapshot experience
Hi
I have a 130TB Sybase/IQ DB using RP CRR for a DR copy. Sybase does all of its processing in memory only "occasionally" flushes the changes to disk so creates a very bursty write environment. We use a script to create a consistent groupset bookmark every hour by forcing a flush. This meets the business requirements for RPO
I want to see if I can reduce the amount of journal space used by using the manual consolidate_snapshot commands to tie in with the groupset bookmark/snapshot.
Bearing in mind the additional overhead of 25% more journal space required to do snapshot consolidation.
Is this something anybody out there has done - not necessarily using Sybase - but with RP in general? If so would you care to share your findings, pitfalls, and most importantly - did it save journal space compared to not using it. I am aware of the formula to calculate journal usage but this will not compare to real life!
My goal is to have 24 hourly db consistent bookmarks and to reduce journal space if possible. The interim bookmarks are of no use as the DB would be in an unknown state.
etaljic81
1K Posts
0
January 22nd, 2013 08:00
You can use the GUI to easily make the change. Expand the CG, select each copy and change the Protection setting (see screenshot).
Have I used it? Yes, once. Does it work? Yes it does. I don't see a lot of people using it since I don't come accross requirements such as the one you specified.
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
April 1st, 2014 17:00
Hi Neil,
I see that your question was made more than 1 year ago, but would you mind to share your experiences with SybaseIQ and RecoverPoint??
Are you able to use the normal crash consistent images generated by RP or you really need to create an "application consistent" image from Sybase IQ using group sets in order to have a consistent database at the DR site??
Thanks
Gerson
NeilHopwood
46 Posts
0
April 2nd, 2014 00:00
Hi Gerson
We do need to create an application consistent bookmark because if we try to recover from a crash consistent image then the roll back/forward could take an unknown amount of time, especially on such a large DB, and this is no good for the required SLA.
An RPO of 1hr is acceptable, in this instance, to the business.
We never went down the road of consolidated snapshots as journal storage was not an issue, it was more a case of trying to be more efficient in the use of disk as we only needed a bookmark once an hour so perhaps I could save a few % of disk.
One of the pitfalls we found was that if a single SG goes into high load or an init state then we cannot make a parallel bookmark for the duration of the HL condition. This does affect our ability to roll back. This is something to be aware of and in our case we report it to the business unit so that if we do need to roll back then we are aware of that we might not have bookmarks for a certain period and backsides are covered!
Does this help?
Regards
Neil
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
April 2nd, 2014 17:00
Hi Neil,
Thanks for your reply.
In fact, we're implementing SybaseIQ with RP CRR to remote replicate data to the DR Site.
We would like to use only the native crash consistent images generated by RP. Do you know if this crash consistent images are considered valid for SybaseIQ in order to have a consistent DB on the DR site?? We would to deploy a synchronous replication(RTO=O) between the sites.
In your RP script to create a consistent groupset bookmark, do you use the "virtual backup" feature of SybaseIQ in order to have a consistent point-in-time of the DataBase??
Thanks in advance.
Gerson