Hi,
Norma is right! Of course. :-)
In addition:
- only a backup done when server is blocked by
"onmode -c block" is a real external backup in
the view of IDS server. I.e. only such an external
backup can be restored as such (e.g. using
"onbar -r -e ...").
- The above even means that a backup done of
chunks while the server is down is not really an
external backup. This is because "onmode -c block"
writes external archive info to the dbspaces/chunks.
This is not done when server is down. Hence a
backup taken while server is down cannot be
used for external restore (using "onbar -r -e ...").
- The difference of the above comes into play when
someone (sometime) requests that a point-in-time
(PIT) restore is to be done. That can be done only
by using onbar (and ontape sup****ting external
restore in newer versions). And if at this time you do
not have a backup that can be restored with
onbar (or ontape), you loose ...
- A backup taken when server is down normally is
physically consistent because the server does a
checkpoint before it shuts down. Such a backup
can be restored by just putting the chunks in place
while the server is down and then starting the server.
As things were physically consistent at shutdown
they also will be at start up and no physical recovery
will be necessary.
- If the server did not shutdown orderly (i.e. there was
no successful checkpoint), then things on disk may
well be physically inconsistent. Taking a backup
means putting this inconsistency on tape. The restore
will put it back on disk. The server then needs to do
the physical part of the so called "fast recovery".
And this always bears some risk - as Norma Jean
already pointed out. :)
Basically it means "taking a backup of a crashed
system and hoping that it will recover correctly".
But wasn't a backup also to be a cure for a
crashed system ... ?
- A complete checkpoint (not a fuzzy checkpoint)
puts all things to disk so that disks are physically
consistent. But on a busy system thousands of
user threads are blocked during the checkpoint.
They only wait for the checkpoint to finish. And the
nanosecond after the checkpoint finished they will
eagerly start again modifying data. I.e. the physical
consistency is over the moment the checkpoint has
finished. A backup taken after a checkpoint is the
same as one taken without checkpoint as explained
above - with all the fun inconsistency ... This is mainly
due to the absolutely asynchroneous writing to disks
by the server. Even with all disks backed up with
the same "atomic reference point", the disks will not
be physically consistent from IDS server's perspective.
That is exactly why "onmode -c block" exists -
to extend the period of physical consistency further
than the finish time of the checkpoint itself, so that
a consistent backup can be taken.
- If the mirror splitting is so fast, then that should not
cause a long blocking of the server with "onmode -c block",
and hence should not be a reason to not do it.
Unless of course you say consistent backups are
only something for cowards ... ;-)
Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management
IBM Deutschland Research & Development GmbH
Chairman of the Supervisory Board: Martin Jetter
Board of Management: Herbert Kircher
Cor****ate Seat: Boeblingen, Germany
Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294
informix-list-bounces@[EMAIL PROTECTED]
wrote on 02.07.2008 14:50:22:
> No.
> A checkpoint is where data is being flushed from memory to disk, it
> would definitely not be the time to split the mirror.
> The only way you can ensure no disk activity is to block the
> database (or shut it down).
> If you split the mirror without a block or without shutting down the
> db, you can not be guaranteed it will recover. In my years of
> ripping emc bcvs under informix without blocking the db, it is
> highly likely everything will work, but if you are working with
> something mission/business critical, do you want to be the one
> responsible when the database can't recover and you call tech
> sup****t and they tell you what you did is not sup****ted?
>
> Blocking and unblocking the informix database is a very fast thing.
> It will be faster than your split operation.
> You can script it.
> Why take the chance when it is so easy not to?
>
> Norma Jean
>
>
>
> ----- Original Message -----
> From: informix-list-bounces@[EMAIL PROTECTED]
<informix-list-bounces@[EMAIL PROTECTED]
>
> To: informix-list@[EMAIL PROTECTED]
<informix-list@[EMAIL PROTECTED]
>
> Sent: Wed Jul 02 07:29:48 2008
> Subject: External Backup without blocking the database
>
> Hi,
>
> I would like to design a backup and restore concept for Informix with
> a storage cluster technology. For the backup we would use the disk
> mirror option of the cluster software. The storage cluster can do an
> atomar split on mirrored disks. So I would like to ask if I can do the
> external backup without blocking the whole database (onmode -c block).
> I think that maybe a checkpoint with (onmode -c) is ok. And after the
> checkpoint I would like to split all mirrored disks.
> The split is really atomar to all disks. So they they will be splitted
> all in the same time. There is no IO while the split is in progress.
> Is it under these cir***stances possible to don't block the database?
>
> Christian Schmidt.
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@[EMAIL PROTECTED]
> http://www.iiug.org/mailman/listinfo/informix-list
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that any reproduction,
> dissemination or distribution of this communication is strictly
> prohibited. If you have received this communication in error,
> please notify us immediately by replying to the message and
> deleting it from your computer. Thank you. Tellabs
> ============================================================
> _______________________________________________
> Informix-list mailing list
> Informix-list@[EMAIL PROTECTED]
> http://www.iiug.org/mailman/listinfo/informix-list
|
