Checkpoint recovery

>Let's say the following backups are done:
>
>Day        Checkpoint       Type of Checkpoint
>----       Number           ------------------
>	   -----
>1         1000              Offline
>2         1001              Online
>3         1002              Online
>
>If we decide to recover from (the offline) Checkpoint 1000, will the
>dump files associated with Checkpoint 1001 and Checkpoint 1002 be
>processed at all ? My conclusion is that they will not be processed
>and that just from Checkpoint 1000 and the journal files one should be
>able to get to the final state. 
>

When recovering from ANY off-line checkpoint, dump files will NOT be
processed.

However, your journalling question is interesting.  I'll have to try it.

>On a related subject, once a new journal file has been opened would there
>be any problem if the completed journal files are compressed (to save
>disk space) ? (We want to perform one in four backups as offline checkpoint;
>we want to keep all its journals online.)

It's even ok to move the closed journal files to an archive area, provided 
you never intend to use the "-d" flag in your checkpoints.

>
>I appreciate responses.
>
>Shaker
>
>c21vc@koeddp01.delcoelect.com
>(317)-451-0859

Cheers,

|--------------------------------------------------------------------------|
| Michael Leo            | The Ingres FAQ is at ftp.adc.com, /pub/ingres.  |
| York & Associates, Inc.| Also check out /pub/ingres/utilities/NAIUA for  |
| Minneapolis, MN, USA   | the NAIUA Tool Kit.  Lastly, access all this via|
| (612) 921-8083 (voice) | WWW at http://www.adc.com/ingres/ing-top.html.  |
| mal@winternet.com      | All constructive suggestions/criticism welcome. |
|--------------------------------------------------------------------------|



c21vc@koeddp01.delcoelect.com (Shaker) wrote:
>	Our DBA tells me that he will never put his faith on the last
>checkpoint working and that he has had several occasions to have to go to
>a previous checkpoint.
>....
>....
>I want to ask: is this distrust of the last (i.e., a single) 
>tape checkpoint reasonable ? Is the tape technology so unreliable that one
>cannot count on a given tape serving its expected function ?

My experience is that there are other reasons beside failing tapes where one
has to restore from a previous checkpoint:

a. Application-related, i.e someone run a job/query that updates the database
in a destructive way, and you don't find out until a new checkpoint has been
taken.

b. Btree-problems, i.e the structure of a Btree table has been corrupted (we
suspect this happens in some rollback/recovery situations), and since
checkpoint uses tar, this is not detected until days later.

We do all our checkpoints to tape with -d flag.  Restoring from a tape other
than the last is done with tar-command directly to the data-directory, and we
use verifydb to mark the database consistent.

What we would like to have is a way to keep the last n (n=2 to 5 =) checkpoints
in the .cnf-file, to make restoring easier.  But this would probably require
the jnl-files to be kept online.  Is there a way to put these out on the same
tape as the checkpoint?  

Rune

***************** Rune Randøy (rra@allianse.no) ******************
**************** Allianse Informasjonssystemer as ****************
********************** Kristiansand, Norway **********************
Ingres Q & A
To William's Home Page
Email William