You are on page 1of 27

Transaction Logging and its

implications
Reinhard Schmitz
The goal of Transaction logging:
Recovery of lost data for any given point in time

Recovery to the last second before a server crash

It speeds up the server

Consistency checks are normally not needed
anymore.

No view rebuilds needed for views with
transaction logging enabled
What is Transaction Logging?
Transaction logging captures all the changes
made to a database and writes them to a
transaction log.

The logged transactions are then written to
disk in a batch, either when resources are
available or when scheduled.
What is a Transaction?
A transaction is a related series of changes
made to a database on a server. For example,
opening a new document, adding text, and
saving the document is one transaction. In this
case, the transaction consists of three
separate implicit API calls: NotesOpen,
NoteUpdate, and NoteClose.
Subtitle may be used here
What is a Transaction Log?
A transaction log is a record of changes made
to Notes databases. The transaction log
consists of log extents and the log control
file (NLOGCTRL.LFH).
A log extent is one of the log files into which
the transaction logs are written. It has the form
Sxxxxxxx.TXN, where x character represents
a seven-digit number that is unique to that
server.
Subtitle may be used here
How Domino handles log extents
Domino fills each extent sequentially before
writing data to a new one.

The records are secured using a proprietary
byte-stream format.

Each server has only one transaction log that
captures all the changes to databases that are
enabled for transaction logging.
How Domino handles log extents (cont.)
Logging style can be circular or archived

Circular logging style:
When disk space is used up the oldest log
extents are being renamed and overwritten

Archived logging style:
Log extents that are marked as archived by
the (third party) backup software are being
renamed and overwritten
Use transaction logging to:
Schedule regular backups. Backups based on
transaction logs are faster and easier than full
database backups that do not use transaction
logging.

Recover from a media failure. If you have a
media failure, you can restore the most recent
full backup from tape, then use the transaction
logs to add the data that was not written to
disk.
Use transaction logging to: (cont.)
Recover from a system crash. When the
server restarts, it runs through the end of the
transaction logs and recovers any writes that
were not made to disk at the time of the crash.
Logged databases do not require a
consistency check.

Log the database views. You can avoid most
view rebuilds. (In GME only used for particular
views in the Domino Directory, such as
($ServerAccess) and ($Users))
Backup in case of media recovery
To use all the features of transaction logging
for backups and backup recovery, you need a
third-party backup utility that uses the backup
and recovery methods of the Domino C API
Toolkit.

In the case of a media recovery, a database
backup is taken with the third-party utility,
while logging keeps track of updates to the
database.

Backup in case of media recovery (cont.)
When the database is then lost, the backup is
brought up to current state by going through
the transaction log and applying any updates
which have happened to that databases since
the database backup was taken.

Restart Recovery
Note that restart recovery does not require a
third-party utility.

Logging goes on while updates are happening.
When the server crashes then restarts, any
updates which would have otherwise been lost
are written to the database. This significantly
reduces lost data and database corruption
because of server crashes, and reduces
overall restart time since the consistency
check of databases is not required.
The database instance ID (DBIID)
When you enable transaction logging, Domino
assigns a unique database instance ID
(DBIID) to each Domino database.

When Domino records a transaction in the log,
it includes this DBIID.

During recovery, Domino uses the DBIID to
match transactions to databases.
The database instance ID (DBIID) (cont.)
Some database maintenance activities cause
Domino to reconstruct the database in such a
way that old transaction log records are no
longer valid.

When this happens, a new DBIID is assigned
to the database.

After a database is assigned a new DBIID,
take a new full backup of the database
The database instance ID (DBIID) (cont.)
Domino assigns a new DBIID when:

You enable transaction logging for the first time.
You run the Compact task with an option, for
example the option to reduce file size.
You run the Fixup task on corrupted databases.
You move a Domino database to a logged server.
Security settings of a DB are being modified (in
the DB property box)
Disabling transaction logging for a
specific database (no GM Standard)
After you set up transaction logging on a
server, Domino logs all databases on that
server.

You can disable transaction logging of
specific databases, but this practice is not
recommended because if unlogged
databases are corrupted during a system or
media failure, you must run the Fixup task to
recover the database.
How to enable Transaction logging
Runtime can be
Favor restart recovery time
Standard
Favor runtime
Logging style can be:
Archived
Circular
New notes.ini settings:
TRANSLOG_AutoFixup=1
TRANSLOG_UseAll=1
TRANSLOG_Style=1
TRANSLOG_Performance=3
TRANSLOG_Path=Z:
TRANSLOG_Status=1
Previous_TRANSLOG_Status=1
Previous_TRANSLOG_Path=Z:\
Previous_TRANSLOG_Style=1
Backup concept using TSM (Tivoli Storage
Manager)
A selective backup of all databases (full
backup) is being performed once a week
(normally on weekends)

Transaction logs are being backed up every
30 minutes

A incremental backup is performed every four
hours to back up database that have had a
new DBIID assigned

Domina (Space Reclamation)


Troubleshooting
Invalid transaction log path

If Domino cannot access the transaction log
path, the server console displays error
messages indicating: the invalid log path,
databases requiring media recovery or Fixup,
and a panic error.

Refer to Domino Administrator Guide for a
step by step procedure how to fix it.



Troubleshooting (cont.)
Log file is full

If the transaction log drive appears to be full,
the server console displays error messages
indicating:
Cannot write to log file: Recovery Manager:
Log File is Full, try again later
The error may occur because of a failed write
to the transaction log.

Troubleshooting (cont.)
Log file is full (cont.)

If the error occurred because of a failed write
to the transaction log this is in most cases a
temporary problem.

A indication for this condition is that there is
still ample space on the transaction log drive.

In most cases, restarting the Domino Server
will fix this issue.

Troubleshooting (cont.)
Log file is full (cont.)

If the error occurred because there is no more
space on the transaction log drive:

Shut down the Domino Server
Check for the root cause most likely the
backup of the transaction logs does not work
properly
If this was a temporary issue the log extents
that already have been backed up (check log
files) can be deleted and the server can be
restarted


Troubleshooting (cont.)
Log file is full (cont.)

If none of the log extents on the disk have
been backed up yet:

Move part of the log extents to another disk to free up
space and restart server

Fix the problem with the backup

Move the log extents in batches back to the transaction
log drive

After they have been backed up delete them



Troubleshooting (cont.)
Transaction log damaged or corrupted

If the transaction log appears to be damaged
or corrupted, the server console displays error
messages indicating: the log is damaged,
databases requiring media recovery or Fixup,
and a panic error.
The error may occur because of a failed read
from or write to the transaction log.
Refer to Domino Administrator Guide for a
step by step procedure how to fix it.

Troubleshooting (cont.)
Transaction log damaged or corrupted (cont.)

If the server does not come up again the log
control file (NLOGCTRL.LFH) might be
corrupt and needs to be replaced.

It is important to recreate the log control file
matching the logger ID of the recently written
log extents.

To do so, refer to a step by step guide in the
S&I DB



Questions & your feedback...

.
.
.
..
.
.


eds.com

You might also like