Re: HDR questions

"bozon" <curtis@crowson1.com> wrote in message news:1153751331.455151.291640@s13g2000cwa.googlegroups.com... > You can't make the secondary go into standard mode. It has to stay in > secondary mode. This makes sense to me. > So, if onunload works on a secondary then you would execute this > command when the onunload is done, you would set the primary back to > primary mode. I don't quite understand the meaning, here. 'onunload -t <filename> <databasename>' does run for me on the secondary, but I am doubtful that the resulting file actually contains a consistent database. I don't know for sure, but suspect that it might just scan through all the tables, and I'd get whatever state any particular table is in at the time of the scan. > The servers notice that the secondary is behind now and > the secondary starts resynching with the primary. I never use onunload > so I don't know if it works on a secondary or not. And of course I > haven't tried ontape yet. If I could achieve this objective-- suspend replication, do an onunload, resume replication-- I'd be happy. > If ontape doesn't work on a secondary, I would like to add a feature > request. That would be of value to us.

> > You can't make the secondary go into standard mode. It has to stay in > > secondary mode. > > This makes sense to me. > > > So, if onunload works on a secondary then you would execute this > > command when the onunload is done, you would set the primary back to > > primary mode. > > I don't quite understand the meaning, here. > I don't understand the meaning of this either after reading it (damn monkeys, give'em a typewriter and see what you get). Here is a list of the commands as I see it. onmode -c block # On primary# <optionally wait to make sure that the checkpoint is applied to the secondary before breaking replication> onmode -d standard # On primary onmode -c unblock # On primary onunload ... # On secondary onmode -d primary <secondary-name> # On primary The first step forces the database into a check point and holds it there (until the onmode -c unblock is executed at step 3.) The second step breaks replication while the server is locked in a checkpoint. If your checkpoint gets applied quickly to the secondary you can wait till after the secondary completes applying that checkpoint before you break replication. It seems like once you break replication after the checkpoint has been committed on the secondary and before anything else can be written to the secondary you have as consistent a database as you can get since the primary will not update it during the onunload because it doesn't know about it. > 'onunload -t <filename> <databasename>' does run for me on the secondary, > but I am doubtful that the resulting file actually contains a consistent > database. I don't know for sure, but suspect that it might just scan > through all the tables, and I'd get whatever state any particular table is > in at the time of the scan. > >