cancel
Showing results for 
Search instead for 
Did you mean: 

dbvalid giving different errors?

2,942

SQL Anywhere 11.0.1.2837 (Windows 2008 R1 64bit)

We run dbvalid on a backup of a database. The database has two dbspaces, total size is 26GB.

Backup is performed using:

"%SQLANY11%\\bin64\\dbbackup.exe" -k recover -s -c "links=tcpip;dsn=dbbackup" E:\\backups\\db -y -r

Database validation is performed using:

"%SQLANY11%\\bin64\\dbvalid.exe" -c "dbf=E:\\backups\\db\\database.db;uid=validator;pwd=validator;dbs=-ds E:\\backups\\db"

A recent backup that was validated raised some errors like so:

Database validation failed for page 0046df32 of database file "E:\\backups\\db\\databaseLogs.db"
Database validation failed for page 0046df33 of database file "E:\\backups\\db\\databaseLogs.db"

When running the exact same dbvalid command a second time on the exact same database files, it still produced errors but for different pages. Like so:

Database validation failed for page 0046e141 of database file "E:\\backups\\db\\databaseLogs.db"
Database validation failed for page 0046e142 of database file "E:\\backups\\db\\databaseLogs.db"

But then also produced the following:

VALIDATE TABLE "Database"."ExampleTable"
Primary key for "ExampleTable" has invalid or duplicate index entries

Does that sound correct? I would've assumed that dbvalid would've returned the exact same errors in both runs?

(note - I've changed db names, uids, pwds and table names to protect the innocent)

Accepted Solutions (1)

Accepted Solutions (1)

After quite some time, we finally managed to figure out the issue.

Due to the infrastructure the customer has, dbvalid has to be run on the same Machine as the production database.

Let me expand (again, names and file locations have been changed to protect the innocent):

Firstly this is how the Production database is set up (I've removed some cache control and logging parameters):

-xTCPIP(Port=2638)
-nDatabase
😧\\Databases\\db\\database.db
-nDatabase

We now go ahead and run the dbvalid command on the same Machine using:

"%SQLANY11%\\bin64\\dbvalid.exe" -c "dbf=E:\\backups\\db\\database.db;uid=validator;pwd=validator;dbs=-ds E:\\backups\\db"

Now even though we had specified that dbvalid should be run against E:backupsdbdatabase.db (DBF=E:backupsdbdatabase.db) dbvalid was connecting to the Running Production Database and not the backup. This is due to SQL Anywhere determining that the Server Name and Database Name for the dbvalid should be "Database" and then finding that there is already a Server and Database running with that same name, thus causing it to connect to that Server and Database combination instead of starting a new Database (or throwing an error).

Thus as this was a running database with CRUD operations being performed, dbvalid would end up throwing errors for invalid pages even though in reality there wasn't.

So after all that, we've now changed the dbvalid command to be:

"%SQLANY11%\\bin64\\dbvalid.exe" -c "START=dbsrv11 -x NONE -xd -ch 1g;DBF=E:\\backups\\db\\database.db;uid=validator;pwd=validator;ServerName=validatedb;dbs=-r -ds E:\\backups\\db"

Lesson learnt - Read the documentation with a fine toothcomb and then double-check everything.

Update - I've created a suggestion for SQL Anywhere to try and solve or at least help the user discover this problem.

VolkerBarth
Contributor
0 Kudos

Would you share with us how the following could happen?

even though we had specified that dbvalid should be run against E:backupsdbdatabase.db (DBF=E:backupsdbdatabase.db) dbvalid was connecting to the Running Production Database and not the backup

I'm asking since this kind of "lesson learnt" is usually very helpful for others - confine the reactions on my (possible similar) FAQ where I missed an ENG parameter in a particular call...

reimer_pods
Participant

I support Volker's suggestion. My 2 cents just in case ...

Presumably the DBN parameter was not specified, so the engine chose the already running database with the same (file) name. I've had to learn that the hard way, so now I either specify a different database name or use another engine to start the backup database.

0 Kudos

@Volker and @Reimer - expanded answer to hopefully answer your questions.

VolkerBarth
Contributor
0 Kudos

Ah, yes, what a subtle pitfall:) - And I second your suggestion to handle DBF differently - though I'd suggest to ask for that in a separate question...

Answers (0)