SEO

Hi,

you can restore individual dbspaces while the system is running.
This is possible only with so called non-critical dbspaces, it is
called "warm restore" and requires restore of logical logs (which
in turn requires that they were backed up before).

However, you cannot restore individual dbspaces to arbitrary points
in time (PITs). When doing a warm restore, you have to restore the
dbspace to 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 the
restore dbspace. (Since the system is still running and logs are in use,
the restored logs will need space in a temporary dbspace for 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 (and dbspace) without further accessing it.
Therefore a warm restore of the dbspace will restore everything 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 warm restore is 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 the dbspace. IDS did not mark down the dbspace without further
accessing it. Therefore a warm restore would have to roll forward all this
"work", including the "corrupting action" (table/dbspace drop, ...).
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 to
restore
to a different (temporary) IDS instance just the critical dbspaces and the
dbspace with your corrupted database. You do not need to restore any
of the other, non-critical dbspaces. Since this will be a cold restore you
can
do this as a PIT restore to 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 Level Restore.)

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.lfc@googlemail.com" <howie.lfc@googlemail.com>
Sent by: informix-list-bounces@iiug.org
19.07.2007 08:48

To
informix-list@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 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

_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list