|
I'm trying to get the validation utility running on our SQL Anywhere 12 database similar to how we had it working with our ASA6 database. Basic design is that we have replication running every hour at the top of the hour through a scheduled task. We run the backup utility every hour at the bottom of the hour. That backup script truncates the log file and splits it into smaller ones so we have it around for replication. We're basically trying to fire off the validation utility at about 1:45 in the morning. Here is the command line from the batch file... "D:\Program Files\SQL Anywhere 12\Bin32\dbvalid.exe" -c "dbf=c:\database\production.db;uid=dba;pwd=*****;" -o "c:\database\prodvalid.txt" When we run the batch file, we get the following error placed in the output log. SQL Anywhere Validation Utility Version 12.0.1.3484 SQL error (-82) -- Unable to start specified database c:\database\production.db cannot be started read-only because it requires recovery Any thoughts on what might be happening here would be appreciated. I know the database isn't bad. The backups are firing off successfully. TIA Jeff Gibson |
|
Some backups require recovery and if you go through recovery & start up a backup, you will write new entries into the transaction log and that makes it difficult or impossible to then use the database as part of a recovery scheme. To avoid that problem, dbvalid opens the database in read-only mode which can only be done if the database doesn't require recovery. Alternatives include:
See http://dcx.sybase.com/index.html#1201/en/dbadmin/dbvalid.html -john. 3
In addition to what John said: if you create a copy of the backup (and leave the original backup alone), and then do whatever is required with the backup to run dbvalid (like start it to recover it), and that dbvalid runs OK, then you KNOW that the original backup is also OK... because there is nothing you did during the copy or dbvalid processes that would turn a bad database into a good one. In fact, IMO that is the technique that should be used, rather than (say) run dbvalid on the original database because that would not guarantee that the backup is OK.
(02 Dec '11, 08:31)
Breck Carter
Replies hidden
1
Breck, that was what I meant by making a throw-away copy of your backup database. It's not always a reasonable option if your database is very large.
(02 Dec '11, 08:58)
John Smirnios
Comment Text Removed
1
John, yes I know that was what you meant... I was just providing extra motivation re: dbvalid on the final copy proves all earlier copies are OK since the copy process cannot remove flaws.
(02 Dec '11, 09:42)
Breck Carter
2
If you can't make a throw-away copy of the backup because it is too large probably implies you can't make regular backups in the first place... "the file is too large" is usually a symptom of a far deeper problem: a really crappy backup and recovery strategy. Backup copies don't need to be stored in the super-duper-high-performance-insanely-expensive-disk-farm, and TB-size USB 2 drives are now available for less than U$100 per TB. The bigger the database, the MORE backup copies you need, not less.
(02 Dec '11, 09:48)
Breck Carter
2
Agreed but there are always exceptions so it's worth listing alternatives. For example, "large" could mean "large relative to storage available on an embedded device". Sometimes the database is part of an embedded app and the user doesn't want to require 2x the size of the original database be available prior to backup & validate (and, yes, some people keep their 'backups' on the same drive -- mostly as protection against corruption rather than drive failure). I do like the in-memory no-write approach if only it didn't require a separate license.
(03 Dec '11, 10:18)
John Smirnios
|
