Run 'onunload' on an HDR secondary?

IDS 10.00.FC1 Solaris 10 Suppose I am running HDR. Now suppose I run 'onunload -t <filename> <database name>' on the secondary. 'onunload' uses a shared lock on the database, I believe. So, what happens to the incoming transaction logs (from the primary) that need to be applied to the secondary? Do they just accumulate on the secondary until the onunload lock goes away? Then when onunload is finished, are they applied, and HDR just continues merrily on, as before? If onunload runs to completion successfully on the secondary, does that mean I got a consistent, point-in-time backup of the database in the onunload file? Thank you. DG

"David E. Grove" <david_grove@correct.state.ak.us> wrote in message news:12bdkqv734l9kf9@corp.supernews.com... > IDS 10.00.FC1 > Solaris 10 > > Suppose I am running HDR. > > Now suppose I run 'onunload -t <filename> <database name>' on the > secondary. > 'onunload' uses a shared lock on the database, I believe. So, what > happens > to the incoming transaction logs (from the primary) that need to be > applied > to the secondary? Do they just accumulate on the secondary until the > onunload lock goes away? Then when onunload is finished, are they > applied, > and HDR just continues merrily on, as before? We've been wondering this recently too as, contrary to our expectation, you can run a dbexport against an HDR secondary, where the same locking argument presumably applies.

Interesting, we were wondering if you could run ontape on the secondary to back up the database but I have been so busy I haven't been able to investigate or test it. (I just realized it would probably only take a minute to check the c.d.i archives, but then I couldn't implement it for 6 months anyway.) I don't think there is any locking done on the secondary so I wonder if it just gives you whatever it got. You could break replication temporarily while you are doing the onunload and then reestablish it after the onunload. That way you know that no new transactions are being applied to the database. I wonder if doing the following is practical and worthwhile? # On primary onmode -c block # Force checkpoint for consistency. Do you need tocheck secondary to make sure it has everything up to this point before you break replication? onmode -d standard #Break replication onmode -c unblock #Continue servicing your fantastic clients. # On secondary onunload <yadda yadda> # start onunload on the secondary Could this give you a valid "backup" on the secondary? then when your onunload is complete on the secondary. onmode -d primary <secondary> # on the primary database. Of course you can't use your secondary while you are doing the backup. David E. Grove wrote: > IDS 10.00.FC1 > Solaris 10 > > Suppose I am running HDR. > > Now suppose I run 'onunload -t <filename> <database name>' on the secondary. > 'onunload' uses a shared lock on the database, I believe. So, what happens > to the incoming transaction logs (from the primary) that need to be applied > to the secondary? Do they just accumulate on the secondary until the > onunload lock goes away? Then when onunload is finished, are they applied, > and HDR just continues merrily on, as before? > > If onunload runs to completion successfully on the secondary, does that mean > I got a consistent, point-in-time backup of the database in the onunload > file? > > Thank you. > > DG

David E. Grove wrote: > IDS 10.00.FC1 > Solaris 10 > > Suppose I am running HDR. > > Now suppose I run 'onunload -t <filename> <database name>' on the secondary. > 'onunload' uses a shared lock on the database, I believe. So, what happens > to the incoming transaction logs (from the primary) that need to be applied > to the secondary? Do they just accumulate on the secondary until the > onunload lock goes away? Then when onunload is finished, are they applied, > and HDR just continues merrily on, as before? The secondary is in recovery mode and the recovery threads will continue to apply logs from the primary. > > If onunload runs to completion successfully on the secondary, does that mean > I got a consistent, point-in-time backup of the database in the onunload > file? > > Thank you. > > DG

<mpruet@comcast.net> wrote in message news:1152878622.836318.55940@h48g2000cwc.googlegroups.com... > > The secondary is in recovery mode and the recovery threads will > continue to apply logs from the primary. > > I tried running onunload on the secondary, and it ran to completion just fine. However, I conclude from above that the resulting onunload file may not be consistent. I will do the suggested disabling of replication, then do the onunload, then re-enable replication. Follow up questions.... Just out of curiosity... Is it actually necessary to 'onmode -c block', etc. on the primary? Would I actually risk inconsistency by not forcing a checkpoint? Also, could I avoid touching the primary and just 'onmode' the secondary back to standard? (I'm thinking it would then just be like when you initially start HDR, before you get the secondary operational, and I could easily 'onmode' it back to secondary. [I got plenty of log space on the primary.]) Thank you all for comments. Regards, DG