|
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? |
|
> 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. Thanks )))
(19 Mar '18, 08:23)
Ilia63
Replies hidden
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...
(19 Mar '18, 15:13)
Volker Barth
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 operation must be performed twice"). 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.
(20 Mar '18, 02:19)
Ilia63
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...
(20 Mar '18, 03:09)
Volker Barth
"the log is not validated at database start"
(20 Mar '18, 05:22)
Ilia63
> 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.
(20 Mar '18, 07:58)
Breck Carter
Possibly he means "dbbackup -x"?
(20 Mar '18, 08:07)
Volker Barth
1
> 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.
(20 Mar '18, 08:15)
Breck Carter
Let the database X.db have 'Assertion Failed' and Log file corrupted (invalid page number found).
(20 Mar '18, 10:59)
Ilia63
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...
(20 Mar '18, 13:18)
Volker Barth
Unfortunately, many clients neglect the backup/restore practices we offer. And we have what we have now.
(21 Mar '18, 03:03)
Ilia63
|
