Dummy (Fast) Checkpoints

> Hello everyone,
> 
> This message is related to the thread "journaling on Ingres 6.4/06" started
> by Georg Borgström.
> 
> Apparently, for whatever reason, a bug (or feature?) has been introduced in
> recent patches for Ingres 6.4/06 & OpenIngres 1.2 (I haven't tested OI 2.0
> /Ingres II ) which makes it difficult to do certain kinds of table
> maintenance on a  production 24X7 database; specifically, it has become
> necessary to do a "ckpdb +j" after enabling journaling on individual or new
> tables with the "set journaling on xxxxx" syntax, even if journaling already
> has been enabled on the database as a whole.
> 
> This may seem like only a minor inconvenience to CA tech support, but it can
> be a major headache in some cases.  In our case, we are looking forward to
> having to schedule at least 8 hours of system downtime for an offline
> checkpoint.  Since the database is 24X7 (credit card transactions), a backup
> server has to be set up to handle transactions during the downtime, and a
> lot of late night processing has to be cancelled and rescheduled, producing
> backlog that will have to be processed on another day... etc. etc.   This
> means alot of weekend overtime for the DBA & local tech support.
> 
> All of this because some tables were altered through copydb (destroyed and
> recreated).  As the tables are very large, the workaround suggested by CA
> tech support is not viable:
> 
> >> > >>   Workaround :
> >> > >> Use the syntax : create table X (...) with journaling
> >> > >> instead of using "set journaling on table" statement
> 
> The problem is that "create table X (...) with journaling " forces the copy
> into the table to be logged, which, besides being slow, inevitably causes a
> log full error.
> 
> The local DBA has proposed a solution which is either brilliant or crazy...
> (does CA still use the "Mr. Bungle" examples in their Database
> Administration training? :-)
> 
> Her idea is to edit the WSDD line of "cktmpl.def" file,  commenting out or
> removing the "tar" command.  Then, during a very short scheduled downtime,
> perform an offline checkpoint to disk (ckpdb +j). Immediately upon
> completion, the "cktmpl.def" would be returned to normal, and an online
> ckpdb to tape would be executed.
> 
> The idea is to trick ingres into thinking it has taken an offline
> checkpoint, which will immediately be replaced by an online checkpoint.
> 
> My initial reaction is,  that I can't see why this wouldn't work-- as long
> as it is followed by a true checkpoint.
> 
> She has actually tested this procedure on another database, and it appears
> to have worked.  But, as always, I am wary of "Mr. Bungle" style solutions.
> Can anyone shoot any holes in the idea?
> 
> Tia :-)
> 
> James Gramling
> Rio de Janeiro, Brasil
> jamesg@NOSPAMnovanet.com.br (remove NOSPAM to reply)


Hi James,

    Kudos and browny points to your DBA. She is to be treasured, even if her
    maniacal laughing gets on your nerves.

    As Karl says, as long as this is followed by a regular checkpoint then
    there shouldnt be a problem. When you think about it, there is no reason
    why this wont work. The cktmpl.def only controls the creation of the tar
    files, its upto the journal support programs to do the rest. By removing
    the tar file creation all you do is save time and wont hurt anything else.
    And of course its the time thing that stops us doing this '+j' checkpoint
    for real.

    I've just tried this by using Steve McElhinney's suggestion for
    II_CKTMPL_FILE set locally to point to the monkied cktmpl.def.
    I replaced the WSDD/WSTD etc tar calls with /bin/true. That way I get a
    true signal being sent back to the dmfjsp program so that it thinks all is
    okay.

    eg: instead of 
        WSDD:   cd %D;/bin/tar cf - . | /usr/local/bin/gzip > %A
    use WSDD:   cd %D;/bin/true

    Now the ckpdb -v +j takes a very short period of time, the checkpoint is
    marked valid (although of course there are no tar files) 

    And the journalling works!

    Martin Bowes
Ingres Q & A
Back to William's Home Page
Email William