on 2018 Mar 19 3:47 AM
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?
Request clarification before answering.
> 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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...
"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 ...
> 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.
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
User | Count |
---|---|
45 | |
9 | |
8 | |
6 | |
5 | |
5 | |
4 | |
4 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.