Informix Ver 9.40.FC4
HP-UX 11.11

We have a 350Gb database running baan. The customer has added a number
of new baan companies placed in new dbspaces for testing purposes.

My question is if a corruption occured within one of the new companies
would it be possible to restore the individual dbspace which contained
the affected company, without affecting user access or the live data
within the instance.

I understand the "onbar -r dbspace1 dbspace2" is available but what
about the logical logs?
Would we not need to backup the individual dbspace before work
commenced or is Informix able to restore one dbspace to a point in
time without affecting all other data?


Thanks in advance....


Howard

On Jul 19, 9:40 am, Martin Fuerderer <MARTI...@de.ibm.com> wrote:
> Hi,
>
> you canrestoreindividual dbspaces while the system is running.
> This is possible only with so called non-critical dbspaces, it is
> called "warmrestore" and requiresrestoreof logical logs (which
> in turn requires that they were backed up before).
>
> However, you cannotrestoreindividual dbspaces to arbitrary points
> in time (PITs). When doing a warmrestore, you have torestorethedbspaceto the current time, so that it will be consistent with the
> remaining
> dbspaces (that do not need to be restored). This is done by restoring
> logical logs and applying those log records that are involved with therestoredbspace. (Since the system is still running and logs are in use,
> the restored logs will need space in a temporarydbspacefor this
> purpose).
>
> So, from your e-mail it is not quite clear what kind of "corruption" has
> occurred.
>
> If there was a physical corruption (e.g. on the disk), then IDS noticed
> this at the
> time and marked down the chunk (anddbspace) without further accessing it.
> Therefore a warmrestoreof thedbspacewillrestoreeverything that was
> done before the corruption occured. As there was nothing done afterwards,
> this will then be sufficient to get current with the rest of the system
> and all is
> fine. This is the situation warmrestoreis intended for.
>
> If you have a logical corruption (e.g. table or database dropped
> accidently), then
> IDS will have considered this normal work and will have continued doing
> work on thedbspace. IDS did not mark down thedbspacewithout further
> accessing it. Therefore a warmrestorewould have to roll forward all this
> "work", including the "corrupting action" (table/dbspacedrop, ...).
> I understand that in this situation you would want to say "I don't care
> about
> system consistency (among restored and not-restored dbspaces)", but
> this is (so far) not supported. What you can do in such a case is torestore
> to a different (temporary) IDS instance just the critical dbspaces and thedbspacewith your corrupted database. You do not need torestoreany
> of the other, non-critical dbspaces. Since this will be a coldrestoreyou
> can
> do this as a PITrestoreto the desired point in time (before the
> corruption
> occurred). Then you can access, export, whatever, the database and its
> data ...
>
> (With IDS 10.00 an alternative would be Table LevelRestore.)
>
> Regards,
> Martin
> --
> Martin Fuerderer
> IBM Informix Development Munich, Germany
> Information Management
>
> IBM Deutschland GmbH
> Chairman of the Supervisory Board: Hans Ulrich Märki
> Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
> Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
> Diemer
> Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
> HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940
>
> "howie....@googlemail.com" <howie....@googlemail.com>
> Sent by: informix-list-boun...@iiug.org
> 19.07.2007 08:48
>
> To
> informix-l...@iiug.org
> cc
>
> Subject
> Recovering individual dbspaces
>
> Informix Ver 9.40.FC4
> HP-UX 11.11
>
> We have a 350Gb database running baan. The customer has added a number
> of new baan companies placed in new dbspaces for testing purposes.
>
> My question is if a corruption occured within one of the new companies
> would it be possible torestorethe individualdbspacewhich contained
> the affected company, without affecting user access or the live data
> within the instance.
>
> I understand the "onbar -r dbspace1 dbspace2" is available but what
> about the logical logs?
> Would we not need to backup the individualdbspacebefore work
> commenced or is Informix able torestoreonedbspaceto a point in
> time without affecting all other data?
>
> Thanks in advance....
>
> Howard
>
> _______________________________________________
> Informix-list mailing list
> Informix-l...@iiug.orghttp://www.iiug.org/mailman/listinfo/informix-list



hello Martin,

i'm asking if during a warm restore IDS reapply logs for the all
dbspaces or just the transactions that depends the data in the
desired dbspace ?
if i made a level 0 backup on sunday and try to warm restore next
friday and i don't have keep the logs for every days, could i be able
to restore the dbspace ?
thanks.
regards,

On Aug 24, 5:39 am, vomari...@yahoo.com wrote:
> On Jul 19, 9:40 am, Martin Fuerderer <MARTI...@de.ibm.com> wrote:
>
>
>
> > Hi,
>
> > you canrestoreindividual dbspaces while the system is running.
> > This is possible only with so called non-critical dbspaces, it is
> > called "warmrestore" and requiresrestoreof logical logs (which
> > in turn requires that they were backed up before).
>
> > However, you cannotrestoreindividual dbspaces to arbitrary points
> > in time (PITs). When doing a warmrestore, you have torestorethedbspaceto the current time, so that it will be consistent with the
> > remaining
> > dbspaces (that do not need to be restored). This is done by restoring
> > logical logs and applying those log records that are involved with therestoredbspace. (Since the system is still running and logs are in use,
> > the restored logs will need space in a temporarydbspacefor this
> > purpose).
>
> > So, from your e-mail it is not quite clear what kind of "corruption" has
> > occurred.
>
> > If there was a physical corruption (e.g. on the disk), then IDS noticed
> > this at the
> > time and marked down the chunk (anddbspace) without further accessing it.
> > Therefore a warmrestoreof thedbspacewillrestoreeverything that was
> > done before the corruption occured. As there was nothing done afterwards,
> > this will then be sufficient to get current with the rest of the system
> > and all is
> > fine. This is the situation warmrestoreis intended for.
>
> > If you have a logical corruption (e.g. table or database dropped
> > accidently), then
> > IDS will have considered this normal work and will have continued doing
> > work on thedbspace. IDS did not mark down thedbspacewithout further
> > accessing it. Therefore a warmrestorewould have to roll forward all this
> > "work", including the "corrupting action" (table/dbspacedrop, ...).
> > I understand that in this situation you would want to say "I don't care
> > about
> > system consistency (among restored and not-restored dbspaces)", but
> > this is (so far) not supported. What you can do in such a case is torestore
> > to a different (temporary) IDS instance just the critical dbspaces and thedbspacewith your corrupted database. You do not need torestoreany
> > of the other, non-critical dbspaces. Since this will be a coldrestoreyou
> > can
> > do this as a PITrestoreto the desired point in time (before the
> > corruption
> > occurred). Then you can access, export, whatever, the database and its
> > data ...
>
> > (With IDS 10.00 an alternative would be Table LevelRestore.)
>
> > Regards,
> > Martin
> > --
> > Martin Fuerderer
> > IBM Informix Development Munich, Germany
> > Information Management
>
> > IBM Deutschland GmbH
> > Chairman of the Supervisory Board: Hans Ulrich Märki
> > Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
> > Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
> > Diemer
> > Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
> > HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940
>
> > "howie....@googlemail.com" <howie....@googlemail.com>
> > Sent by: informix-list-boun...@iiug.org
> > 19.07.2007 08:48
>
> > To
> > informix-l...@iiug.org
> > cc
>
> > Subject
> > Recovering individual dbspaces
>
> > Informix Ver 9.40.FC4
> > HP-UX 11.11
>
> > We have a 350Gb database running baan. The customer has added a number
> > of new baan companies placed in new dbspaces for testing purposes.
>
> > My question is if a corruption occured within one of the new companies
> > would it be possible torestorethe individualdbspacewhich contained
> > the affected company, without affecting user access or the live data
> > within the instance.
>
> > I understand the "onbar -r dbspace1 dbspace2" is available but what
> > about the logical logs?
> > Would we not need to backup the individualdbspacebefore work
> > commenced or is Informix able torestoreonedbspaceto a point in
> > time without affecting all other data?
>
> > Thanks in advance....
>
> > Howard
>
> > _______________________________________________
> > Informix-list mailing list
> > Informix-l...@iiug.orghttp://www.iiug.org/mailman/listinfo/informix-list
>
> hello Martin,
>
> i'm asking if during a warm restore IDS reapply logs for the all
> dbspaces or just the transactions that depends the data in the
> desired dbspace ?
> if i made a level 0 backup on sunday and try to warm restore next
> friday and i don't have keep the logs for every days, could i be able
> to restore the dbspace ?
> thanks.
> regards,

You have to have all of the logical logs created since the archive was
taken in order to perform a successful warm restore. Otherwise the
dbspace that's been restored will be marked 'Inconsistent' and will be
effectively offline.

Only logical log pages that reference the restored dbspace(s) will be
reapplied. Other dbspaces will be unaffected.

It is a good practice to keep logical logs until at least the second
following level zero archive is safely on tape/disk. This is so that
if the intermediate archive is somehow damaged you can always restore
the older one and roll forward the full set of logs past the interrum
archive to the present time. The truly paranoid among us discard
nothing, tape is cheap.

Art S. Kagel

On Aug 28, 7:38 pm, "Art S. Kagel" <art.ka...@gmail.com> wrote:
> On Aug 24, 5:39 am, vomari...@yahoo.com wrote:
>
>
>
> > On Jul 19, 9:40 am, Martin Fuerderer <MARTI...@de.ibm.com> wrote:
>
> > > Hi,
>
> > > you canrestoreindividual dbspaces while the system is running.
> > > This is possible only with so called non-critical dbspaces, it is
> > > called "warmrestore" and requiresrestoreof logical logs (which
> > > in turn requires that they were backed up before).
>
> > > However, you cannotrestoreindividual dbspaces to arbitrary points
> > > in time (PITs). When doing a warmrestore, you have torestorethedbspaceto the current time, so that it will be consistent with the
> > > remaining
> > > dbspaces (that do not need to be restored). This is done by restoring
> > > logical logs and applying those log records that are involved with therestoredbspace. (Since the system is still running and logs are in use,
> > > the restored logs will need space in a temporarydbspacefor this
> > > purpose).
>
> > > So, from your e-mail it is not quite clear what kind of "corruption" has
> > > occurred.
>
> > > If there was a physical corruption (e.g. on the disk), then IDS noticed
> > > this at the
> > > time and marked down the chunk (anddbspace) without further accessingit.
> > > Therefore a warmrestoreof thedbspacewillrestoreeverything that was
> > > done before the corruption occured. As there was nothing done afterwards,
> > > this will then be sufficient to get current with the rest of the system
> > > and all is
> > > fine. This is the situation warmrestoreis intended for.
>
> > > If you have a logical corruption (e.g. table or database dropped
> > > accidently), then
> > > IDS will have considered this normal work and will have continued doing
> > > work on thedbspace. IDS did not mark down thedbspacewithout further
> > > accessing it. Therefore a warmrestorewould have to roll forward all this
> > > "work", including the "corrupting action" (table/dbspacedrop, ...).
> > > I understand that in this situation you would want to say "I don't care
> > > about
> > > system consistency (among restored and not-restored dbspaces)", but
> > > this is (so far) not supported. What you can do in such a case is torestore
> > > to a different (temporary) IDS instance just the critical dbspaces and thedbspacewith your corrupted database. You do not need torestoreany
> > > of the other, non-critical dbspaces. Since this will be a coldrestoreyou
> > > can
> > > do this as a PITrestoreto the desired point in time (before the
> > > corruption
> > > occurred). Then you can access, export, whatever, the database and its
> > > data ...
>
> > > (With IDS 10.00 an alternative would be Table LevelRestore.)
>
> > > Regards,
> > > Martin
> > > --
> > > Martin Fuerderer
> > > IBM Informix Development Munich, Germany
> > > Information Management
>
> > > IBM Deutschland GmbH
> > > Chairman of the Supervisory Board: Hans Ulrich Märki
> > > Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
> > > Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
> > > Diemer
> > > Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
> > > HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940
>
> > > "howie....@googlemail.com" <howie....@googlemail.com>
> > > Sent by: informix-list-boun...@iiug.org
> > > 19.07.2007 08:48
>
> > > To
> > > informix-l...@iiug.org
> > > cc
>
> > > Subject
> > > Recovering individual dbspaces
>
> > > Informix Ver 9.40.FC4
> > > HP-UX 11.11
>
> > > We have a 350Gb database running baan. The customer has added a number
> > > of new baan companies placed in new dbspaces for testing purposes.
>
> > > My question is if a corruption occured within one of the new companies
> > > would it be possible torestorethe individualdbspacewhich contained
> > > the affected company, without affecting user access or the live data
> > > within the instance.
>
> > > I understand the "onbar -r dbspace1 dbspace2" is available but what
> > > about the logical logs?
> > > Would we not need to backup the individualdbspacebefore work
> > > commenced or is Informix able torestoreonedbspaceto a point in
> > > time without affecting all other data?
>
> > > Thanks in advance....
>
> > > Howard
>
> > > _______________________________________________
> > > Informix-list mailing list
> > > Informix-l...@iiug.orghttp://www.iiug.org/mailman/listinfo/informix-list
>
> > hello Martin,
>
> > i'm asking if during a warm restore IDS reapply logs for the all
> > dbspaces or just the transactions that depends the data in the
> > desired dbspace ?
> > if i made a level 0 backup on sunday and try to warm restore next
> > friday and i don't have keep the logs for every days, could i be able
> > to restore the dbspace ?
> > thanks.
> > regards,
>
> You have to have all of the logical logs created since the archive was
> taken in order to perform a successful warm restore. Otherwise the
> dbspace that's been restored will be marked 'Inconsistent' and will be
> effectively offline.
>
> Only logical log pages that reference the restored dbspace(s) will be
> reapplied. Other dbspaces will be unaffected.
>
> It is a good practice to keep logical logs until at least the second
> following level zero archive is safely on tape/disk. This is so that
> if the intermediate archive is somehow damaged you can always restore
> the older one and roll forward the full set of logs past the interrum
> archive to the present time. The truly paranoid among us discard
> nothing, tape is cheap.
>
> Art S. Kagel

thanks for the details. too bad i can't stop the logical restore after
ontape -r -D dbspace and force the dbspace to a state of consistency.
jack

On Aug 31, 5:01 am, vomari...@yahoo.com wrote:
> On Aug 28, 7:38 pm, "Art S. Kagel" <art.ka...@gmail.com> wrote:
>
>
>
> > On Aug 24, 5:39 am, vomari...@yahoo.com wrote:
>
> > > On Jul 19, 9:40 am, Martin Fuerderer <MARTI...@de.ibm.com> wrote:
>
> > > > Hi,
>
> > > > you canrestoreindividual dbspaces while the system is running.
> > > > This is possible only with so called non-critical dbspaces, it is
> > > > called "warmrestore" and requiresrestoreof logical logs (which
> > > > in turn requires that they were backed up before).
>
> > > > However, you cannotrestoreindividual dbspaces to arbitrary points
> > > > in time (PITs). When doing a warmrestore, you have torestorethedbspaceto the current time, so that it will be consistent with the
> > > > remaining
> > > > dbspaces (that do not need to be restored). This is done by restoring
> > > > logical logs and applying those log records that are involved with therestoredbspace. (Since the system is still running and logs are in use,
> > > > the restored logs will need space in a temporarydbspacefor this
> > > > purpose).
>
> > > > So, from your e-mail it is not quite clear what kind of "corruption" has
> > > > occurred.
>
> > > > If there was a physical corruption (e.g. on the disk), then IDS noticed
> > > > this at the
> > > > time and marked down the chunk (anddbspace) without further accessing it.
> > > > Therefore a warmrestoreof thedbspacewillrestoreeverything that was
> > > > done before the corruption occured. As there was nothing done afterwards,
> > > > this will then be sufficient to get current with the rest of the system
> > > > and all is
> > > > fine. This is the situation warmrestoreis intended for.
>
> > > > If you have a logical corruption (e.g. table or database dropped
> > > > accidently), then
> > > > IDS will have considered this normal work and will have continued doing
> > > > work on thedbspace. IDS did not mark down thedbspacewithout further
> > > > accessing it. Therefore a warmrestorewould have to roll forward allthis
> > > > "work", including the "corrupting action" (table/dbspacedrop, ...).
> > > > I understand that in this situation you would want to say "I don't care
> > > > about
> > > > system consistency (among restored and not-restored dbspaces)", but
> > > > this is (so far) not supported. What you can do in such a case is torestore
> > > > to a different (temporary) IDS instance just the critical dbspaces and thedbspacewith your corrupted database. You do not need torestoreany
> > > > of the other, non-critical dbspaces. Since this will be a coldrestoreyou
> > > > can
> > > > do this as a PITrestoreto the desired point in time (before the
> > > > corruption
> > > > occurred). Then you can access, export, whatever, the database and its
> > > > data ...
>
> > > > (With IDS 10.00 an alternative would be Table LevelRestore.)
>
> > > > Regards,
> > > > Martin
> > > > --
> > > > Martin Fuerderer
> > > > IBM Informix Development Munich, Germany
> > > > Information Management
>
> > > > IBM Deutschland GmbH
> > > > Chairman of the Supervisory Board: Hans Ulrich Märki
> > > > Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
> > > > Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
> > > > Diemer
> > > > Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
> > > > HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940
>
> > > > "howie....@googlemail.com" <howie....@googlemail.com>
> > > > Sent by: informix-list-boun...@iiug.org
> > > > 19.07.2007 08:48
>
> > > > To
> > > > informix-l...@iiug.org
> > > > cc
>
> > > > Subject
> > > > Recovering individual dbspaces
>
> > > > Informix Ver 9.40.FC4
> > > > HP-UX 11.11
>
> > > > We have a 350Gb database running baan. The customer has added a number
> > > > of new baan companies placed in new dbspaces for testing purposes.
>
> > > > My question is if a corruption occured within one of the new companies
> > > > would it be possible torestorethe individualdbspacewhich contained
> > > > the affected company, without affecting user access or the live data
> > > > within the instance.
>
> > > > I understand the "onbar -r dbspace1 dbspace2" is available but what
> > > > about the logical logs?
> > > > Would we not need to backup the individualdbspacebefore work
> > > > commenced or is Informix able torestoreonedbspaceto a point in
> > > > time without affecting all other data?
>
> > > > Thanks in advance....
>
> > > > Howard
>
> > > > _______________________________________________
> > > > Informix-list mailing list
> > > > Informix-l...@iiug.orghttp://www.iiug.org/mailman/listinfo/informix-list
>
> > > hello Martin,
>
> > > i'm asking if during a warm restore IDS reapply logs for the all
> > > dbspaces or just the transactions that depends the data in the
> > > desired dbspace ?
> > > if i made a level 0 backup on sunday and try to warm restore next
> > > friday and i don't have keep the logs for every days, could i be able
> > > to restore the dbspace ?
> > > thanks.
> > > regards,
>
> > You have to have all of the logical logs created since the archive was
> > taken in order to perform a successful warm restore. Otherwise the
> > dbspace that's been restored will be marked 'Inconsistent' and will be
> > effectively offline.
>
> > Only logical log pages that reference the restored dbspace(s) will be
> > reapplied. Other dbspaces will be unaffected.
>
> > It is a good practice to keep logical logs until at least the second
> > following level zero archive is safely on tape/disk. This is so that
> > if the intermediate archive is somehow damaged you can always restore
> > the older one and roll forward the full set of logs past the interrum
> > archive to the present time. The truly paranoid among us discard
> > nothing, tape is cheap.
>
> > Art S. Kagel
>
> thanks for the details. too bad i can't stop the logical restore after
> ontape -r -D dbspace and force the dbspace to a state of consistency.
> jack

Oh, it's possible. There's enough information in my Internals
presentation from the IIUG/IDUG conferences (available online at the
IIUG and IDUG websites) to be able to do it if you're a careful C
programmer. It's one of the explicit topics I cover with an eye to
recovering at least to the archive's PIT if, worst case, all of your
logical log tapes are trashed. However, it is STRONGLY not
recommended and if you do it, IBM will disavow any knowledge of how to
fix any future problems that they can possibly claim are the result of
having done so.

Art S. Kagel