Checkpoint d*.dmp files

On May 13, 15:01, Gan Wei Yong wrote:
> Subject: *.dmp file in dmp directory
>
> We have daily ckpdb backup for one of our ingres database, and it created 2
files under dump directory /appli/ingres/dmp/default/database. (file name is
c0000001.dmp, d0000001.dmp etc...)
>
> We notice the c*.dmp file will be created for every 'ckpdb' but d*.dmp is
not.
> ....
>
> Anybody know what is the purpose of d*.dmp files ? why sometime this file is
created but sometimes is not. ...

I believe the d*.dmp files are a record of transactions that occurred
during the online checkpoint.  If nothing interesting happened, no
d*.dmp file is created.  The c*.dmp file is a control file, basically a
copy of the aaaaaaa.cnf file (I don't pretend to know the exact relationship).

You can delete the d*.dmp file only if you are deleting the checkpoint too
and never plan to use that checkpoint ever again.

-- 
Karl Schendel            Phone: (412) 963-8844
Telesis Computer Corp      Fax: (412) 963-1373
wiz@telesismfg.com


Hi Gan,

    The files in the dump directory are VERY IMPORTANT! 

    The c*.dmp files are saved configuration files. You get one per checkpoint.
    It is the configuration file at the time the checkpoint commenced. It is
    essential to have the saved configuration file from a checkpoint if you
    wish to use that checkpoint to recover your database with a rollforwarddb.

    The d*.dmp files are the dump files. These record the before images of all
    records changed during the lifetime of the checkpoint. This is done for
    all tables not just the journalled tables. They are totally essential for
    the recovery of your database to the time the checkpoint finished.

    The existence of thre d*.dmp files indicates that you are getting dumping
    occuring during your checkpoint. To restore your database with a
    rollforwarddb you not only require the saved configuration file for the
    checkpoint, you also require any dump files written by that checkpoint and
    the journal files. Use infodb dbname to tell you which checkpoint owns
    which dump file(s) and what journals are also required.

    eg. 
----Checkpoint History for Journal----------------------------------------------
    Date                      Ckp_sequence  First_jnl   Last_jnl  valid  mode
    ----------------------------------------------------------------------------
...
    Sat Oct 11 03:37:22 1997            328       1103      1103      1  ONLINE
    Sat Oct 11 21:49:44 1997            329       1104      1104      1  ONLINE
    Mon Oct 13 04:15:28 1997            330       1105      1106      1  ONLINE
    Tue Oct 14 03:37:06 1997            331       1107      1108      1  ONLINE
----Checkpoint History for Dump-------------------------------------------------
    Date                      Ckp_sequence  First_dmp   Last_dmp  valid  mode
    ----------------------------------------------------------------------------
...
    Sat Oct 11 03:37:22 1997            328          0         0      1  ONLINE
    Sat Oct 11 21:49:44 1997            329        330       330      1  ONLINE
    Mon Oct 13 04:15:28 1997            330        331       331      1  ONLINE
    Tue Oct 14 03:37:06 1997            331          0         0      1  ONLINE
----Cluster Journal History-----------------------------------------------------


    All the checkpoints listed above are marked valid so I can use anyone of 
    them to recover my database. I know for a fact that only checkpoint 329
    and 330 are available on disk the others on tape. (This is not displayed
    in the infodb output, it is a site dependant thing - after all you should
    know what your checkpointing to and when).

    If I was to recover my database from checkpoint 330 to the current date
    and time, I would require:
    1.  Saved configuration file: c0000330.dmp
    2.  Saved Dump files:         d0000331.dmp
    3.  Journal to get database to point in time that checkpoint 330
    completes: ie j0001104.jnl
    4.  All Journals and Dumps written since that checkpoint. In this case
    only Journals and they are numbers j0001105.jnl to j0001108.jnl inclusive.

    The rollforwarddb commnad would then be:
    rollforwarddb '#c330' +j -udbowner dbname

    You rely upon these files to recover your database. Hence deleting them
    should only be done when the files are sufficiently old that they are no
    longer required to recover the database. ie so many subsequent checkpoints
    have occurred. At our site we compress saved configuration, dump and
    journal files after 3 days and remove them after 5. This can also vary
    dependant upon the importance of the database. In some cases we remove
    after 14 days. This process can be scripted using the infodb output as a
    guide. Your script should ensure that the files required to restore from
    the last valid checkpoint are NEVER compressed or removed.

    Hope that explains it all.

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