Re: Onbar physical followed by onbar logical...then...ontape ?
Posted in 2005
TBP said:
>
> Gentsch, Sam wrote:
>> -----Original Message-----
>> From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org]
>> On Behalf Of scottishpoet
>> Sent: Monday, November 14, 2005 6:50 PM
>> To: informix-list@iiug.org
>> Subject: Re: Onbar physical followed by onbar logical...then...ontape ?
>>
>>
>>>since you were taught not to mix onbar and ontape the, since you
>>
>> archive using onbar
>>
>>>you will have been backing up your logical logs using onbar as well, I
>>
>> assume this is a
>>
>>>purely hypothetical question
>>
>>
>>
>> Normally, yes logs are backed up with onbar...we lost the Netbackup
>> server, so I backed up logs to disk quickly with ontape to keep things
>> moving,
>> since I Could not access backup manager. And did not have time to figure
>> out how to safely change storage managers to
>> ISM locally and use onbar. But yes, it is purely hypothetical at this
>> point.
>> sending to informix-list
>
> Seeing as there have been several "hack" suggestions I thought I would
> confirm that I have tested the following :
>
> Step 1.
>
> Amend the ixbar.<servernum> file, adding an extra line for the log which
> isn't in the storage manager but is on ontape, and make the object id
> duff (e.g. 99999)
>
> Step 2.
>
> onbar -r -p>
> Step 3.
>
> onbar -r -l>
> At the end it will try and get the "duff" logical log from the storage
> manager and then suspend logical recovery.
>
> Step 4.
>
> ontape -l>
> which will then go off and get the logs via ontape that are on disk.
>
> Not supported, not supported and I believe that it is, errr, not
> supported.
>
> If in doubt about the above, post your ixbar.<servernum> file (or at
> least the relevant bits) and I will "show you how".
But is that supported?
--
Bye now,
Obnoxio
"C'est pas parce qu'on n'a rien ` dire qu'il faut fermer sa gueule"
- Coluche
did i mention i like nulls? heck, i even go so far as to say that all
columns in a table except the primary key could/should be nullable. this
has certain advantages, for example, if you need to insert a child record
and you don't have a parent row for it, just do an insert into the parent
table with the primary key value (everything else null), and voila,
relational integrity is preserved. but this is, admittedly, a bit
controversial among modellers.
--r937, dbforums.com
sending to informix-list