cancel
Showing results for 
Search instead for 
Did you mean: 

Suggestions with dbvalid error

3,810

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
Intercept Solutions - Sybase SQL Anywhere OEM Partner
Nashville, TN

Accepted Solutions (1)

Accepted Solutions (1)

johnsmirnios
Employee
Employee

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:

  • Make another throw-away copy of your backup database and either pre-start it in writable mode or, if you want to autostart, add a dbs= parameter to you connection string (which will suppress dbvalid from setting DBS=-r).
  • Use in-memory, no-write mode if you are licensed for it
  • Use a backup mechanism that produces a file that doesn't require recovery

See http://dcx.sybase.com/index.html#1201/en/dbadmin/dbvalid.html

-john.

Breck_Carter
Participant

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.

johnsmirnios
Employee
Employee

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.

Breck_Carter
Participant

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.

Breck_Carter
Participant

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.

johnsmirnios
Employee
Employee

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.

Answers (0)