HDR questions

> What about backing up without marking the database as backed up? Isn't > that a new feature of informix 10? ontape -F in think. > > Would this allow a backup to be done on the secondary, because it isn't > updating the system tables? > > > > Yes you can run ontape on the secondary to get a consistent archive of the > > > servers. The operation would not block or otherwise affect concurrent > > > updates from the primary except as any resource usage on the machine and > > > server would. The archive would be restorable onto either host. Maybe I'm doing something wrong, but I cannot do an 'onunload' (or 'ontape') on the secondary of an HDR pair. Also, tried 'ontape -F', but no luck. So, I figure I have to disable replication. First I try 'onmode -d standard' on the secondary, thinking maybe I can temporarily stop HDR on the secondary. But, that fails (get messsage in online.log telling me I have to first turn replication off before changing back to standard). So, I execute 'onmode -d standard' on the primary; then on the secondary. This, of course, completely disables the replication, and I can then do an 'onunload' or 'ontape' (or whatever else I might want to do) on the [former] secondary. That's great. But, then I can't re-establish HDR. I mean I can't just have the secondary pick up where it left off, and recover the accumulated logs from the primary-- If I run 'onmode -d primary <secondary-server>' on the primary; and 'onmode -d secondary <primary-server>' on the secondary, I get an out-of-sync message telling me a restore is needed. Which means I have to re-establish HDR from the get-go. That is, a brand new archive from the primary, transport to secondary, 'ontape -p' it, and then use 'onmode' to enable the primary and secondary. So, what do I want out of this anyway? I'd like to use 'onunload' on the secondary of an HDR pair, without having to re-establish HDR from the very beginning. Is there some way to temporarily suspend HDR on the secondary, unload some data from the secondary, and then resume HDR (without a level 0 physical restore)? (I have plenty of log space to accumulate transactions on the primary while the secondary is suspended). Regards, DG

"David E. Grove" <david_grove@correct.state.ak.us> wrote in message news:12c2tnm6e7lnjaa@corp.supernews.com... > > So, I execute 'onmode -d standard' on the primary; then on the secondary. > This, of course, completely disables the replication, and I can then do an > 'onunload' or 'ontape' (or whatever else I might want to do) on the > [former] > secondary. > > That's great. > > But, then I can't re-establish HDR. I mean I can't just have the > secondary > pick up where it left off, and recover the accumulated logs from the > primary-- Of course not. As soon as you bring the esrtwhile secondary on-line as a primary it writes a log record, and from this point onwards the two instances are incompatable as an HDR pair. > I'd like to use 'onunload' on the secondary of an HDR pair, without having > to re-establish HDR from the very beginning. Works OK for me: $ touch 1.uld $ onunload -t 1.uld capsPlease mount tape and press Return to continue ... <abort load after a few secs as it's a huge database> ^CInterrupt received ... The unload has been aborted. $ ls -l 1.uld -rw-r--r-- 1 informix informix 80216064 Jul 22 12:03 1.uld

You can't make the secondary go into standard mode. It has to stay in secondary mode. 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. 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 ontape doesn't work on a secondary, I would like to add a feature request. Of course does this mean that the ontape on the secondary would wait till a check point had been done on the primary before it starts? I don't think you would want the secondary telling the primary to check point. (ontape backups force a checkpoint before they start and the backup is current as of that checkpoint.) This would be a fine trade off of backing up on the secondary. The backup would wait until the next primary checkpoint is completed before starting. If you really wanted the backup now you could force a checkpoint on the primary yourself. Of course I will need to start adding OTC's disclaimer at the bottom if I keep answering questions for things I haven't actually done. My heart is in the right place but my head might be up my ... ;-) Neil Truby wrote: > "David E. Grove" <david_grove@correct.state.ak.us> wrote in message > news:12c2tnm6e7lnjaa@corp.supernews.com... > > > > So, I execute 'onmode -d standard' on the primary; then on the secondary. > > This, of course, completely disables the replication, and I can then do an > > 'onunload' or 'ontape' (or whatever else I might want to do) on the > > [former] > > secondary. > > > > That's great. > > > > But, then I can't re-establish HDR. I mean I can't just have the > > secondary > > pick up where it left off, and recover the accumulated logs from the > > primary-- > > Of course not. As soon as you bring the esrtwhile secondary on-line as a > primary it writes a log record, and from this point onwards the two > instances are incompatable as an HDR pair. > > > > I'd like to use 'onunload' on the secondary of an HDR pair, without having > > to re-establish HDR from the very beginning. > > Works OK for me: > > $ touch 1.uld > $ onunload -t 1.uld caps> Please mount tape and press Return to continue ... > <abort load after a few secs as it's a huge database> > ^CInterrupt received ... > The unload has been aborted. > $ ls -l 1.uld > -rw-r--r-- 1 informix informix 80216064 Jul 22 12:03 1.uld

bozon wrote: > If ontape doesn't work on a secondary, I would like to add a feature > request. Of course does this mean that the ontape on the secondary > would wait till a check point had been done on the primary before it > starts? I don't think you would want the secondary telling the primary > to check point. Taking a backup on the secondary is a bit more complicated than who issues the checkpoint. ;-) Here are some key issues.... 1) Unlogged databases need to be backed-up, but are not replicated as part of HDR 2) blobspace blobs need to be backed-up, but are not replicated as part of HDR 3) unlogged UDTs need to be backed-up, but are not replicated as part of HDR M.P. (ontape backups force a checkpoint before they start > and the backup is current as of that checkpoint.) This would be a fine > trade off of backing up on the secondary. The backup would wait until > the next primary checkpoint is completed before starting. If you really > wanted the backup now you could force a checkpoint on the primary > yourself. > > Of course I will need to start adding OTC's disclaimer at the bottom if > I keep answering questions for things I haven't actually done. > > My heart is in the right place but my head might be up my ... ;-) > > Neil Truby wrote: >> "David E. Grove" <david_grove@correct.state.ak.us> wrote in message >> news:12c2tnm6e7lnjaa@corp.supernews.com... >>> So, I execute 'onmode -d standard' on the primary; then on the secondary. >>> This, of course, completely disables the replication, and I can then do an >>> 'onunload' or 'ontape' (or whatever else I might want to do) on the >>> [former] >>> secondary. >>> >>> That's great. >>> >>> But, then I can't re-establish HDR. I mean I can't just have the >>> secondary >>> pick up where it left off, and recover the accumulated logs from the >>> primary-- >> Of course not. As soon as you bring the esrtwhile secondary on-line as a >> primary it writes a log record, and from this point onwards the two >> instances are incompatable as an HDR pair. >> >> >>> I'd like to use 'onunload' on the secondary of an HDR pair, without having >>> to re-establish HDR from the very beginning. >> Works OK for me: >> >> $ touch 1.uld >> $ onunload -t 1.uld caps>> Please mount tape and press Return to continue ... >> <abort load after a few secs as it's a huge database> >> ^CInterrupt received ... >> The unload has been aborted. >> $ ls -l 1.uld >> -rw-r--r-- 1 informix informix 80216064 Jul 22 12:03 1.uld>

I always seem to crash into reality when I have flights of fancy. If you didn't have any of the afore mentioned features could you allow it? I know this limits the capability but many sites don't use those features. Madison Pruet wrote: > bozon wrote: > > > If ontape doesn't work on a secondary, I would like to add a feature > > request. Of course does this mean that the ontape on the secondary > > would wait till a check point had been done on the primary before it > > starts? I don't think you would want the secondary telling the primary > > to check point. > > Taking a backup on the secondary is a bit more complicated than who > issues the checkpoint. ;-) > > Here are some key issues.... > > 1) Unlogged databases need to be backed-up, but are not replicated as > part of HDR > > 2) blobspace blobs need to be backed-up, but are not replicated as part > of HDR > > 3) unlogged UDTs need to be backed-up, but are not replicated as part of HDR > > > M.P. > > > (ontape backups force a checkpoint before they start > > and the backup is current as of that checkpoint.) This would be a fine > > trade off of backing up on the secondary. The backup would wait until > > the next primary checkpoint is completed before starting. If you really > > wanted the backup now you could force a checkpoint on the primary > > yourself. > > > > Of course I will need to start adding OTC's disclaimer at the bottom if > > I keep answering questions for things I haven't actually done. > > > > My heart is in the right place but my head might be up my ... ;-) > > > > Neil Truby wrote: > >> "David E. Grove" <david_grove@correct.state.ak.us> wrote in message > >> news:12c2tnm6e7lnjaa@corp.supernews.com... > >>> So, I execute 'onmode -d standard' on the primary; then on the secondary. > >>> This, of course, completely disables the replication, and I can then do an > >>> 'onunload' or 'ontape' (or whatever else I might want to do) on the > >>> [former] > >>> secondary. > >>> > >>> That's great. > >>> > >>> But, then I can't re-establish HDR. I mean I can't just have the > >>> secondary > >>> pick up where it left off, and recover the accumulated logs from the > >>> primary-- > >> Of course not. As soon as you bring the esrtwhile secondary on-line as a > >> primary it writes a log record, and from this point onwards the two > >> instances are incompatable as an HDR pair. > >> > >> > >>> I'd like to use 'onunload' on the secondary of an HDR pair, without having > >>> to re-establish HDR from the very beginning. > >> Works OK for me: > >> > >> $ touch 1.uld > >> $ onunload -t 1.uld caps> >> Please mount tape and press Return to continue ... > >> <abort load after a few secs as it's a huge database> > >> ^CInterrupt received ... > >> The unload has been aborted. > >> $ ls -l 1.uld > >> -rw-r--r-- 1 informix informix 80216064 Jul 22 12:03 1.uld> >