Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.

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 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.


Jeff Gibson
Intercept Solutions - Sybase SQL Anywhere OEM Partner
Nashville, TN

asked 01 Dec '11, 19:20

Jeff%20Gibson's gravatar image

Jeff Gibson
accept rate: 20%

edited 01 Dec '11, 19:22

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



permanent link

answered 01 Dec '11, 21:39

John%20Smirnios's gravatar image

John Smirnios
accept rate: 37%


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

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

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

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

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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 01 Dec '11, 19:20

question was seen: 3,420 times

last updated: 03 Dec '11, 10:18