journals

[ConvertFromOldNGs]

by John Munro >> Wed, 5 Mar 2008 22:28:14 GMT

We are using the following ini file settings, so I would expect the oldest current journal to be 15 minutes old, but there are journals in there an hour and a half old. Does this mean that a process has been in transaction state for an hour and a half? If not, what else could be delaying the journals being closed? Is this normal?

[PersistentDb]
EnableArchivalRecovery=true
JournalMaxSize=120M
JournalCloseAction=MoveAndCompress
JournalMinSize=0
JournalSwitchInterval=15


thanks,

John

[ConvertFromOldNGs]

by Gerard O'Brien >> Wed, 5 Mar 2008 23:21:27 GMT

I have responded to this for contacts in parsys in the past. What follows is the text from the response to one such contact. Hopefully it explains what you see.

cheers
Gerard


When a journal switch occurs a new journal becomes the current write journal. A journal switch has nothing to do with closing and releasing journals. A journal that has been switched from is in a stable state and is available for copying and verifying for backup purposes.

The database retains control of the journal until it is no longer required for transaction abort or database recovery purposes at which time it is released and any journal close action performed. You can copy but not remove the file while it is in this state.

Multiple journal files that are held open by database recovery should be viewed as the current journal set. A journal is dropped from this set when it is no longer required for either transaction abort or for database restart recovery. How many journals there are in the current journal set depends on transaction activity and on the settings for the JournalMinSize, JournalMaxSize and JournalSwitchInterval parameters. There is no limit. As the recovery point is evaluated journals no longer required are dropped from the current journal set and released. Recovery point evaluation only occurs during transaction activity.


Transaction activity is the normal stimulus for the evaluation that may result in the establishment of a restart recovery point. Other activities (e.g., changing database usage, deleting a map file, normal close down) also force the establishment of a restart recovery point but transaction activity is the usual stimulus. The establishing of a restart recovery point is called a checkpoint.

An accumulator of bytes written to the audit since the last checkpoint is maintained by transaction auditing. A checkpoint operation is initiated when this value goes beyond 1/3 of the JournalMaxSize ini file parameter value.

The checkpoint operation establishes a known restart recovery state consequentially determining which journals in the current journal set are no longer required and initiating their release if they don't contain and are not spanned by an active transaction.

[ConvertFromOldNGs]

by John Munro >> Tue, 11 Mar 2008 15:29:23 GMT

I'm not sure whether it's because of this checkpoint logic or not, but we're getting this error

Recover Database failed due to error: A required transaction journal was not found (3125) dbadmin(2927)

when we try to restore a database using files created by an online backup. The journal it's referring to is the current journal of the db that was backed up.

I thought an online backup was supposed to copy all of the journals it needs to the backup directory?

[ConvertFromOldNGs]

by Patwos >> Tue, 11 Mar 2008 20:36:58 GMT

"The journal it's referring to is the current journal of the db that was backed up."

If you don't specify a journal, or point in time, for the recovery to stop at it will continue asking for the next journal in sequence until it reaches the last journal.

"I thought an online backup was supposed to copy all of the journals it needs to the backup directory?"

No, although if you do not have archival recovery enabled it did in earlier releases of Jade force a journal swap and copy that journal to the backup directory to make the online backup usable. I'm not sure what current releases do in this regard.

With archival recovery enabled it leaves it up to the implementation to make appropriate use of JournalCloseAction and/or JournalTransferEvents to ensure the jounals that any online backup will require to complete recovery is copied/moved to an appropriate alternate location.

Hope that helps,
Pat.

[ConvertFromOldNGs]

by John Munro >> Tue, 11 Mar 2008 20:50:51 GMT

When we do the restore we do restore and roll forward to end of last journal. I don't understand why that doesn't stop at the last journal in the backup directory.

Basically my question is this - we have an online backup plus all of the archived journals from that point until the present, why is that not enough?

[ConvertFromOldNGs]

by Gerard O'Brien >> Wed, 12 Mar 2008 20:35:34 GMT

Hopefully you mean the last journal in the current directory.

"end of last journal" doesn't mean "end of last journal present in directory".

When you roll forward to last journal you are telling the database to stop only when it has reached the "current" journal. The "current" journal is the journal that is in "write state", i.e., the one that was being written. The database knows if a journal it is processing is "current" or not. A journal that is terminated by a "switch" record is not the last journal.

To terminate a roll forward at the end of a particular journal you specify that journal number as the "end of journal" termination condition.

You can dump a journal using jdbutil. The last record at the end of a switched-from journal will be an [Audit].switch record.