Hi Karl,

My problem was/is twofold.

First, the .cnf file was off by a few, so the old ckp folder wasn't being deleted. Fixed that.

Second, our new backup process gets the data offsite and I'm ultimately charged for storage space at the end of the month.

My plan is to keep a monthly, a weekly and the two most recent days of activity stored, so I need to drop the oldest ckp. I intend to have the automation software run the ckp with the -d to do that, so I don't have to monitor the thing each night at 10:30.

Still working out the schedule on that, now that the first probem is fixed.

Cheers,

Mike

The journal files contain a running log of updates that have occurred  
since a checkpoint.
Having extra journal files around is not necessarily an indication of  
trouble.

I'd do an "infodb databasename" in a command prompt window and  
examine the section that
is titled something like "checkpoint history for journal".  It should  
show you the
last checkpoint (just one if you're doing -d), and the valid flag  
should be 1.
If valid is 0, something is going wrong during the checkpoints and  
you need
to find out what.   (presumably the ckpdb output says what.)

If there's no problems, look at the first_jnl and last_jnl sequence  
numbers
and match them up with your leftover journal files.  If your leftover
files are older, that just means that somehow they got missed and you
can just delete them by hand.  (If your journals are in the sequence  
listed,
then they are current and you should just leave them alone.)

By the way, I don't care for the -d option to ckpdb myself.  Only  
having one
preceding checkpoint in the database checkpoint history limits your
recovery options when things go pear-shaped.  It's better to not use -d,
and manage disk space by deleting old checkpoints and journals yourself.
A middle way is to build up some safe number of checkpoints, and then  
start
using alterdb -delete_oldest_ckp which deletes the oldest checkpoint.
This is more automatic but you do have to keep an eye on it to make
sure that it doesn't go haywire and leave you with insufficient
disk space.

Karl

_______________________________________________
Info-Ingres mailing list
Info-Ingres@kettleriverconsulting.com
http://www.kettleriverconsulting.com/mailman/listinfo/info-ingres

-----------------------------------------
Please note - the Rodem e-mail system
DOES NOT accept compressed files
(ZIP extension). Please send file
attachments in the original document
format - doc xls dwg pdf jpg gif, etc.

File attachments with more than one
period in the filename, or attachments
larger than 5,000 KB will also be
blocked.

If you have any questions, please contact
the Rodem e-mail Administrator at this
address: admin@rodem.com.
-----------------------------------------