cancel
Showing results for 
Search instead for 
Did you mean: 

Log file corrupted (invalid page number found): reasons, best practices, Live Backup

1,632

Is there a list of reasons that cause this error (of course, not official, but received, say, from practical experience)?

Are there any best practices that will help to avoid this error (besides the backup/recovery-strategy)?

Let's use the Live Backup. Will the Live backup log be corrupted likewise, or will we be able to use a Live backup log instead of a corrupted log?

Accepted Solutions (1)

Accepted Solutions (1)

Breck_Carter
Participant
0 Kudos

> Is there a list of reasons that cause this error?

Bad disk (straightforward), bad RAM (very scary), software bug (unlikely).

> Are there any best practices that will help to avoid this error (besides the backup/recovery-strategy)?

Avoid? no

Deal with? Consider using a transaction log mirror (dbtran -m) which might provide a valid file if the main log file becomes corrupt.

> will we be able to use a Live backup log instead of a corrupted log?

Possibly, but a live log backup is a significant investment in setup and administration.

AFAIK you can use all methods together: transaction log mirror, multiple live log backups, High Availability... but I don't know of anyone who does that.

An hourly log backup, plus transaction log mirror, is a very simple approach that provides great safety... then add High Availability if you really care about continuity of operations. Note that HA is NOT an alternative to backup.

0 Kudos

Thanks )))

VolkerBarth
Contributor
0 Kudos

Instead of using a log mirror, I would prefer to store both database and log file on mirrored devices (RAID level 1, 5 or higher) because that way all database files are protected against media failures. It's way more difficult to protect against RAM errors, methinks...

0 Kudos

Thanks.

We do not use the Transaction log mirror, because the client believes that this can lead to some performance degradation ("There is a performance penalty for using a transaction log mirror because each database log write op..."). But the client does not object to a Live Backup.

ps I understand Breck's objections to this approach. The Breck is right, for administration of Live Backup we had to write a separate application.

pps Still, it is very unfortunate that the ASA-server does not validate the Transaction log when the database is started. At least when the Transaction log mirror is off.

VolkerBarth
Contributor
0 Kudos

Whatmakes you say the log is not validated at database start? In my experience the server does check whether the log is fitting or not. Or do you relate to the fact that the server can start a database without a log when the database has been shutdown cleanly (i.e. without open transactions), and then create a new log?

To mirror logs: IMHO that is no real performance penalty as the mirror should reside on a different device, otherwise there is not much additional protection against media failure compared to a single log...

0 Kudos

"the log is not validated at database start"
I had two similar cases.
The Transaction log was damaged as "Log file corrupted (invalid page number found)", but the user did not feel it at all: the database continued to work / restarted successfully.
Then (say, one working day later) came 'Assertion failed' for database.
And we run only a truncated (dbtran -k) Transaction log for a good database backup. Without one working day ...

Breck_Carter
Participant
0 Kudos

> And we run only a truncated (dbtran -k) Transaction log

What does that statement mean?

The dbtranslate utility does not modify the actual transaction log in any way, it is a read-and-translate utility only.

VolkerBarth
Contributor
0 Kudos

Possibly he means "dbbackup -x"?

Breck_Carter
Participant

> believes that this can lead to some performance degradation

I doubt anyone would notice the difference during normal operations... that warning in the Help is dates back decades, back when disks were slowwwww.

HOWEVER, server startup time may suffer if the transaction log is huge: "On startup, the server checks that the transaction log and its mirror are identical by performing a full comparison of the two files; if they are identical, the database starts as usual. The comparison of log and mirror adds to database startup time."

If you care about server startup time, that may be a reason to keep the transaction log small by doing frequent dbbackup backup-and-restart-log operations (you may not care, not if the server is only restarted occasionally or off-hours).

It also means the mirror log provides an extra level of safety.

0 Kudos

Let the database X.db have 'Assertion Failed' and Log file corrupted (invalid page number found).
Let there is a "good" backup of the database (Y.db).
If the log is corrupted, we are not trying to execute for "good" database: dbeng12 Y.db -a X.log
We are trying to translate the corrupted log into a script using -k option: dbtran -j .... -k X.log
And then in ISQL run: READ "X.sql" for Y.db

VolkerBarth
Contributor
0 Kudos

OK, that's understood... I thought you were talking about backup practice, not about restore (or rather data salvage). For the latter, Dbtran is certainly a helpful tool:) Been there, too...

0 Kudos

Unfortunately, many clients neglect the backup/restore practices we offer. And we have what we have now.
Once again I thank for the advice and help.

Answers (0)