I was thinking that I could use:
SELECT PLAN('statement goes here');
If the result is some text, then I know the syntax of the sql statement is valid.
Is there a better way of doing such validations?
I'm interested solely in validating the syntax correctness of an sql script.
I'm trying to sort out exactly what validation methods are used with the different switches for dbvalid.exe
The docs say that by default "dbvalid validates all the tables, materialized views, and indexes in the database and validates the database file structure". And if run just using -c & -o parameters the output logs "VALIDATE DATABASE", followed by "VALIDATE TABLE ...." for each table. No mention is made of indexes etc but presumably these are done with each table.
If the -s switch is used then the output says "VALIDATE CHECKSUM".
Is validating of checksums in included in VALIDATE DATABASE or should one do both separately? I think it is included as that is how the docs on the SQL statement VALIDATE DATABASE read - but the dbvalid docs aren't clear that it is just executing the sql statements.
A cross reference table showing how the different options in Sybase Central Wizard, the SQL statements and the dbvalid.exe utility all tie in together would be really handy.
When replaying logs on a standby database and then validating it in (in read only mode) we occasionally come across this oddity.
DBValid is unable to start the database even though the previous log application process reports Recovery Complete. After an initial panic, we found that we could start the database directly in read only mode, close it down and then dbvalid was quite happy. Also, the log application process would continue without error on a database that dbvalid said it could not open.
It only happens occasionally, maybe one validation in ten. It's as though when dbvalid starts the database it does something slightly different (that only matters sometimes) from when you start the database directly with the engine, even when you specify all the same start-up parameters.
We tried all sorts of variations on the dbvalid settings without it making any difference. These are the command lines used in the process in the log below:
dbsrv16.exe -o c:\replay.log -a E:\DatabaseLogs\IQX\LiveLog\pearsCopy.log f:\databases\iqx\pears.db
dbvalid -o c:\validate.log -c "start=dbsrv16 -z -o c:\validate_eng.log ;eng=Valid;dbn=Valid;dbf=f:\databases\iqx\pears.db;dbs=-r;uid=XXXX;pwd=XXXX"
It's noticeable that dbvalid adds some extra switches to the engine and the database
Could these extra switches be the difference?
Engine window logs showing three successful log applications followed by dbvalid failing to start the database:
time 808 date 22-01-2016I. 01/22 08:08:00. SQL Anywhere Network Server Version 16.0.0.2076
I. 01/22 08:08:00. Workgroup Edition I. 01/22 08:08:00.
I. 01/22 08:08:00. Copyright © 2014 SAP SE or an SAP affiliate company. I. 01/22 08:08:00. All rights reserved. I. 01/22 08:08:00. Use of this software is governed by the Sybase License Agreement. I. 01/22 08:08:00. Refer to http://www.sybase.com/softwarelicenses. I. 01/22 08:08:00.
I. 01/22 08:08:00. Processors detected: 2 (containing 24 logical processors) I. 01/22 08:08:00. Processor limit (Workgroup Edition): 2 I. 01/22 08:08:00. Processor limit (licensed processors): 2 I. 01/22 08:08:00. Maximum number of processors the server will use: 2 physical processor(s), 12 core(s) I. 01/22 08:08:00. This server is licensed to: I. 01/22 08:08:00. System Administrator I. 01/22 08:08:00. **** I. 01/22 08:08:00. Running Windows 2008R2 Build 7601 Service Pack 1 on X86_64 I. 01/22 08:08:00. Server built for X86_64 processor architecture I. 01/22 08:08:00. 37746200K of memory used for caching I. 01/22 08:08:00. Minimum cache size: 159552K, maximum cache size: 135882628K I. 01/22 08:08:00. Using a maximum page size of 4096 bytes I. 01/22 08:08:00. Multiprogramming level: minimum:24, current:52, maximum:80 I. 01/22 08:08:00. Automatic tuning of multiprogramming level is enabled I. 01/22 08:08:01. Starting database "pears" (f:\databases\iqx\pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:01. Performance warning: Database file "f:\databases\iqx\pears.db" consists of 3 disk fragments I. 01/22 08:08:02. Database recovery in progress I. 01/22 08:08:02. Last checkpoint at Fri Jan 22 2016 00:01 I. 01/22 08:08:02. Transaction log: E:\DatabaseLogs\IQX\LiveLog\pearsCopy.log... I. 01/22 08:08:07. ... recovery 0% complete I. 01/22 08:08:17. ... recovery 4% complete I. 01/22 08:08:19. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:20. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:22. ... recovery 12% complete I. 01/22 08:08:24. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:24. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:27. ... recovery 23% complete I. 01/22 08:08:27. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:28. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:32. ... recovery 31% complete I. 01/22 08:08:35. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:36. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:37. ... recovery 38% complete I. 01/22 08:08:42. ... recovery 43% complete I. 01/22 08:08:47. ... recovery 49% complete I. 01/22 08:08:49. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:50. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:08 I. 01/22 08:08:52. ... recovery 53% complete I. 01/22 08:08:57. ... recovery 58% complete I. 01/22 08:09:02. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:09 I. 01/22 08:09:02. ... recovery 65% complete I. 01/22 08:09:03. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:09 I. 01/22 08:09:07. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:09 I. 01/22 08:09:08. ... recovery 73% complete I. 01/22 08:09:08. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:09 I. 01/22 08:09:13. ... recovery 81% complete I. 01/22 08:09:17. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:09 I. 01/22 08:09:18. ... recovery 87% complete I. 01/22 08:09:19. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:09 I. 01/22 08:09:23. ... recovery 92% complete I. 01/22 08:09:28. ... recovery 99% complete I. 01/22 08:09:29. Checkpointing... I. 01/22 08:09:29. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:09 I. 01/22 08:09:30. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:09 I. 01/22 08:09:30. Recovery complete I. 01/22 08:09:31. Database server shutdown automatically after log applied I. 01/22 08:09:33. Database server stopped at Fri Jan 22 2016 08:09
time 838 date 22-01-2016
I. 01/22 08:38:00. SQL Anywhere Network Server Version 16.0.0.2076
I. 01/22 08:38:00. Workgroup Edition I. 01/22 08:38:00.
I. 01/22 08:38:00. Copyright © 2014 SAP SE or an SAP affiliate company. I. 01/22 08:38:00. All rights reserved. I. 01/22 08:38:00. Use of this software is governed by the Sybase License Agreement. I. 01/22 08:38:00. Refer to http://www.sybase.com/softwarelicenses. I. 01/22 08:38:00.
I. 01/22 08:38:00. Processors detected: 2 (containing 24 logical processors) I. 01/22 08:38:00. Processor limit (Workgroup Edition): 2 I. 01/22 08:38:00. Processor limit (licensed processors): 2 I. 01/22 08:38:00. Maximum number of processors the server will use: 2 physical processor(s), 12 core(s) I. 01/22 08:38:00. This server is licensed to: I. 01/22 08:38:00. System Administrator I. 01/22 08:38:00. * I. 01/22 08:38:00. Running Windows 2008R2 Build 7601 Service Pack 1 on X86_64 I. 01/22 08:38:00. Server built for X86_64 processor architecture I. 01/22 08:38:00. 37746200K of memory used for caching I. 01/22 08:38:00. Minimum cache size: 159552K, maximum cache size: 135882628K I. 01/22 08:38:00. Using a maximum page size of 4096 bytes I. 01/22 08:38:00. Multiprogramming level: minimum:24, current:52, maximum:80 I. 01/22 08:38:00. Automatic tuning of multiprogramming level is enabled I. 01/22 08:38:01. Starting database "pears" (f:\databases\iqx\pears.db) at Fri Jan 22 2016 08:38 I. 01/22 08:38:01. Performance warning: Database file "f:\databases\iqx\pears.db" consists of 3 disk fragments I. 01/22 08:38:02. Database recovery in progress I. 01/22 08:38:02. Last checkpoint at Fri Jan 22 2016 08:09 I. 01/22 08:38:02. Transaction log: E:\DatabaseLogs\IQX\LiveLog\pearsCopy.log... I. 01/22 08:38:07. ... recovery 0% complete I. 01/22 08:38:12. ... recovery 1% complete I. 01/22 08:38:17. ... recovery 12% complete I. 01/22 08:38:22. ... recovery 29% complete I. 01/22 08:38:27. ... recovery 47% complete I. 01/22 08:38:32. ... recovery 63% complete I. 01/22 08:38:37. ... recovery 77% complete I. 01/22 08:38:42. ... recovery 96% complete I. 01/22 08:38:43. Checkpointing... I. 01/22 08:38:43. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:38 I. 01/22 08:38:45. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 08:38 I. 01/22 08:38:45. Recovery complete I. 01/22 08:38:45. Database server shutdown automatically after log applied I. 01/22 08:38:48. Database server stopped at Fri Jan 22 2016 08:38
time 908 date 22-01-2016
I. 01/22 09:08:14. SQL Anywhere Network Server Version 16.0.0.2076
I. 01/22 09:08:14. Workgroup Edition I. 01/22 09:08:14.
I. 01/22 09:08:14. Copyright © 2014 SAP SE or an SAP affiliate company. I. 01/22 09:08:14. All rights reserved. I. 01/22 09:08:14. Use of this software is governed by the Sybase License Agreement. I. 01/22 09:08:14. Refer to http://www.sybase.com/softwarelicenses. I. 01/22 09:08:14.
I. 01/22 09:08:14. Processors detected: 2 (containing 24 logical processors) I. 01/22 09:08:14. Processor limit (Workgroup Edition): 2 I. 01/22 09:08:14. Processor limit (licensed processors): 2 I. 01/22 09:08:14. Maximum number of processors the server will use: 2 physical processor(s), 12 core(s) I. 01/22 09:08:14. This server is licensed to: I. 01/22 09:08:14. System Administrator I. 01/22 09:08:14. * I. 01/22 09:08:14. Running Windows 2008R2 Build 7601 Service Pack 1 on X86_64 I. 01/22 09:08:14. Server built for X86_64 processor architecture I. 01/22 09:08:15. 37746200K of memory used for caching I. 01/22 09:08:15. Minimum cache size: 159552K, maximum cache size: 135882628K I. 01/22 09:08:15. Using a maximum page size of 4096 bytes I. 01/22 09:08:15. Multiprogramming level: minimum:24, current:52, maximum:80 I. 01/22 09:08:15. Automatic tuning of multiprogramming level is enabled I. 01/22 09:08:15. Starting database "pears" (f:\databases\iqx\pears.db) at Fri Jan 22 2016 09:08 I. 01/22 09:08:15. Performance warning: Database file "f:\databases\iqx\pears.db" consists of 3 disk fragments I. 01/22 09:08:17. Database recovery in progress I. 01/22 09:08:17. Last checkpoint at Fri Jan 22 2016 08:38 I. 01/22 09:08:17. Transaction log: E:\DatabaseLogs\IQX\LiveLog\pearsCopy.log... I. 01/22 09:08:22. ... recovery 0% complete I. 01/22 09:08:32. ... recovery 8% complete I. 01/22 09:08:51. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 09:08 I. 01/22 09:08:52. ... recovery 11% complete I. 01/22 09:08:53. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 09:08 I. 01/22 09:08:57. ... recovery 18% complete I. 01/22 09:09:02. ... recovery 29% complete I. 01/22 09:09:07. ... recovery 42% complete I. 01/22 09:09:12. ... recovery 52% complete I. 01/22 09:09:17. ... recovery 64% complete I. 01/22 09:09:22. ... recovery 81% complete I. 01/22 09:09:27. ... recovery 96% complete I. 01/22 09:09:29. Checkpointing... I. 01/22 09:09:29. Starting checkpoint of "pears" (pears.db) at Fri Jan 22 2016 09:09 I. 01/22 09:09:32. Finished checkpoint of "pears" (pears.db) at Fri Jan 22 2016 09:09 I. 01/22 09:09:32. Recovery complete I. 01/22 09:09:32. Database server shutdown automatically after log applied I. 01/22 09:09:34. Database server stopped at Fri Jan 22 2016 09:09
I. 01/22 09:21:45. 1: -z I. 01/22 09:21:45. 2: -o I. 01/22 09:21:45. 3: c:\validate_eng.log I. 01/22 09:21:45. 4: -ha I. 01/22 09:21:45. 5: -ga I. 01/22 09:21:45. 6: -n I. 01/22 09:21:45. 7: Valid I. 01/22 09:21:45. 8: f:\databases\iqx\pears.db I. 01/22 09:21:45. 9: -r I. 01/22 09:21:45. 10: -n I. 01/22 09:21:45. 11: Valid I. 01/22 09:21:45. 12: -hn0,5828:208 I. 01/22 09:21:45.
I. 01/22 09:21:45. SQL Anywhere Network Server Version 16.0.0.2076
I. 01/22 09:21:45. Workgroup Edition I. 01/22 09:21:45.
I. 01/22 09:21:45. Copyright © 2014 SAP SE or an SAP affiliate company. I. 01/22 09:21:45. All rights reserved. I. 01/22 09:21:45. Use of this software is governed by the Sybase License Agreement. I. 01/22 09:21:45. Refer to http://www.sybase.com/softwarelicenses. I. 01/22 09:21:45.
I. 01/22 09:21:45. Processors detected: 2 (containing 24 logical processors) I. 01/22 09:21:45. Processor limit (Workgroup Edition): 2 I. 01/22 09:21:45. Processor limit (licensed processors): 2 I. 01/22 09:21:45. Maximum number of processors the server will use: 2 physical processor(s), 12 core(s) I. 01/22 09:21:45. This server is licensed to: I. 01/22 09:21:45. System Administrator I. 01/22 09:21:45. **** I. 01/22 09:21:45. Running Windows 2008R2 Build 7601 Service Pack 1 on X86_64 I. 01/22 09:21:45. Server built for X86_64 processor architecture I. 01/22 09:21:46. 37746200K of memory used for caching I. 01/22 09:21:46. Minimum cache size: 159552K, maximum cache size: 135882628K I. 01/22 09:21:46. Using a maximum page size of 4096 bytes I. 01/22 09:21:46. Multiprogramming level: minimum:24, current:52, maximum:80 I. 01/22 09:21:46. Automatic tuning of multiprogramming level is enabled I. 01/22 09:21:46. TCP using Winsock version 2.2 I. 01/22 09:21:46. IPv6 support enabled I. 01/22 09:21:46. Database server started at Fri Jan 22 2016 09:21 I. 01/22 09:21:46. Trying to start SharedMemory link ... I. 01/22 09:21:46. SharedMemory link started successfully I. 01/22 09:21:46. Trying to start TCPIP link ... I. 01/22 09:21:46. Starting on port 2638 I. 01/22 09:21:46. Starting UDP listener on IP address 10.200.128.67:2638 I. 01/22 09:21:46. Starting UDP listener on IP address (::1):2638 I. 01/22 09:21:46. Starting UDP listener on IP address 127.0.0.1:2638 I. 01/22 09:21:46. Looking for server with name valid I. 01/22 09:21:46. Sending broadcast to find server I. 01/22 09:21:46. Using broadcast address of: 10.200.128.255 I. 01/22 09:21:46. Looking for server with name valid I. 01/22 09:21:46. Sending broadcast to find server I. 01/22 09:21:46. Using broadcast address of: ff02::1 I. 01/22 09:21:46. Looking for server with name valid I. 01/22 09:21:46. Sending broadcast to find server I. 01/22 09:21:46. Using broadcast address of: 127.255.255.255 E. 01/22 09:21:46. TCP/IP link, function WSASendTo, error code 1214 I. 01/22 09:21:46. TCP/IP link, function send, error code 997 I. 01/22 09:21:46. Broadcast send failed I. 01/22 09:21:51. Server not found (no reply received) I. 01/22 09:21:51. TCPIP link started successfully I. 01/22 09:21:51. Now accepting requests I. 01/22 09:21:51. Starting TCPIP listener on IP address (::):2638 I. 01/22 09:21:51. Starting TCPIP listener on IP address 0.0.0.0:2638 I. 01/22 09:21:51. Starting database "Valid" (f:\databases\iqx\pears.db) at Fri Jan 22 2016 09:21 I. 01/22 09:21:51. Performance warning: Database file "f:\databases\iqx\pears.db" consists of 3 disk fragments E. 01/22 09:21:53. Error: Database cannot be started -- unable to start database "f:\databases\iqx\pears.db"
E. 01/22 09:21:53. Connection ID 1: Connection error '08W09': Unable to start specified database: unable to start database "f:\databases\iqx\pears.db" I. 01/22 09:21:53. Database server shutdown requested by DBSTOP I. 01/22 09:21:53. Disallowing new connections W. 01/22 09:21:55. TCPIP listener on IP address (::):2638 is exiting I. 01/22 09:21:55. Shutting down databases E. 01/22 09:21:55. TCP/IP link, function WSARecvFrom, error code 995 W. 01/22 09:21:55. TCPIP listener on IP address 0.0.0.0:2638 is exiting E. 01/22 09:21:55. TCP/IP link, function WSARecvFrom, error code 995 E. 01/22 09:21:55. TCP/IP link, function WSARecvFrom, error code 995 I. 01/22 09:21:55. Completing server shutdown I. 01/22 09:21:56. Database server stopped at Fri Jan 22 2016 09:21
Some of our customers faced this problem: After some time of heavy usage of one table (many inserts and deletes, but max about 200 rows in average table size) sometimes the primary key index of this table doesnt work any more. Selecting by id gives incorrect results.
Validating table and index doesnt show an error. Rebuilding the primary key index fixes this problem temporarily.
The problem appears in different intervals (sometimes hours, sometimes days, sometimes weeks). As a dirty workaround we used a database event rebuilding this index hourly.
Anybody facing this problem too? Any hints what can cause this problem?
Server version is SQL Anywhere 16.0.0.2322. Client software uses sajdbc4 driver.
On validating a SQLA 16 database we get the following. Can this be fixed ?
Rogue page found in blob on page 00036a00 of table "Ticket_Templates" in database file "c:\sdata\store18_m.db" Invalid blob found on page 000369be of table "Ticket_Templates" in database file "c:\sdata\store18_m.db" Row count mismatch between table "Ticket_Templates" and index "Ticket_Templates" Orphaned blob found on page 00035abb of table "Ticket_Templates" in database file "c:\sdata\store18_m.db" java.sql.SQLException: [Sybase][ODBC Driver][SQL Anywhere]Run time SQL error -- Validation of table "Ticket_Templates" has failed The database 'THELMA_STORE18_M' could not be validated.
[SQL Anywhere 12.0.1.3423 64-bit]
I ran dbvalid against an offline database using this command:
"%SQLANY12%\bin64\dbvalid.exe" -c "uid=dba;pwd=***;dbf=mydatabase.db;eng=validate;start=dbeng12 -r -ch 500m" -o dbvalid-log.txt
When it had completed the last line of the log stated '2 errors reported' and checking through the rest of the log I could see that for 2 tables it contained messages of the form:
VALIDATE TABLE "myowner"."mytable" SQL error (-300) -- Run time SQL error -- Validation of table "mytable" has failed
Note that there are 5 empty lines between the two messages (it doesn't quite display properly above). I don't know if it's relevant but it seems a little odd.
In my experience of earlier versions of SQL Anywhere (8,9) when dbvalid found some kind of corruption in a table the messages it produced were a little more informative and could sometimes allow the problem to be fixed by simply dropping and recreating an index that it suggested was corrupt. I don't think I've seen a 'Run time SQL' error before and it doesn't give me much to go on.
Does this simply indicate that the table is corrupt in such a way that dbvalid can't give any more details or are could it be a problem with dbvalid itself?
Does it raise an exception?
( or can someone tell me how to force an error? )
For example, the dbvalid.exe utility appears to run VALIDATE TABLE statements, and is able to determine "No errors reported"... how?
Is the statement validate table logging anywhere its Progress? Can I find anything in the server messages or the request logging?
I have a 40gb database (SQL Anywhere 17) that I am trying to backup and have begun to get errors when validating a certain table. I am using a maintenance plan that runs when the database should be at the lowest level of use (3:45 am) but I can't get it to validate and do the backup. I have added some prevalidation commands to rebuild the indexes on the table that fails validation and they run successfully. It continually fails with this message:
The maintenance plan has ended because of the following error: Run time SQL error -- Validation of table "TRAV_MODS" has failed SQLSTATE: 40000 SQLCODE: -300 Maintenance plan Backup ZZZZZZ for YYYYY on XXXXXXX finished on 2020-01-15 at 03:50:36.470
Any ideas as to what I might try?
Hi all,
according to the SA 11 and above docs, there seems to be a (slight) difference between running
call sa_validate();
and
call sa_validate(null, null);
From the SA 11.0.1 docs:
If you specify sa_validate() (no arguments), the database server validates all tables, materialized views, indexes, checksums, and the database file.
If neither owner nor tbl_name are specified, all tables and materialized views in the database are validated. Also, the database itself is validated, including checksum validation, and validation that the number of rows in the each table or materialized view matches the number of rows in each associated index.
(Frankly, I can't tell whether both descriptions mean the same thing...)
But in my SQL understanding, both calls should do exactly the same, as all parameters of sa_validate are declared with null as default, and so both calls should be equivalent (and in my tests, they run equally long).
So what's the difference between both calls?
How many runs of 11.0.1.2472 dbvalid.exe do I have to run, using which options, to perform the maximum amount of checking?
I am guessing two runs...
One run with the defaults (no -d -fx -i -s or -t)
One run with just -s
No runs with any of -d -fx -i or -t
Further guesswork: The first run validates everything except checksums, and the second run does that.
Just a follow-up from this question on DBVALID:
If my understanding of John's clarifications in the cited question is correct, then DBVALID with no arguments does a VALIDATE DATABASE and a VALIDATE TABLE for each table/materialized view and a VALIDATE INDEX for each index.
Currently, the SA 12 docs state that ...
by default, dbvalid validates all the tables, materialized views, and indexes, in the database, and validates the database itself.
For sa_validate(), the SA 12 docs (as corrected in DCX) specify, that....
if neither owner nor tbl_name are specified, all tables and materialized views in the database are validated. Also, the database itself is validated, including checksum validation, and validation that the number of rows in the each table or materialized view matches the number of rows in each associated index.
So, is my conclusion correct that both DBVALID with no arguments and sa_validate() with no arguments perform the same set of checks?
If so, that might be another reason the clarify the docs:)
I've got a maintenance plan running that does a validation and then a backup using
backup database directory 'P:\\GKBackups' wait before start transaction log rename;
There seems to be something wrong with the database or something, because the backup file is 'not a valid database file', and it seems the event for the maintenance plan never finished (connections were still disabled; never got email).
Any thoughts?
SQLA 10.0.1.3835
UPDATE:
I did some logging, but I got NOTHING. The backup just never finishes. It never throws an exception either. I have absolutely nothing to go on. The strange thing is, though, that dbbackup.exe will work, just the backup database command will not.
SQL Anywhere 11.01.2527
We're looking to enable by default CHECKSUM clause on all of our databases as it sounds like a good thing.
However, what exactly will happen if a checksum check fails whilst the database performing its normal operations? Is there an assertion that is thrown by the db server? Does some message get logged to the console? Does some database event get fired? Does the database shutdown?
Now we can get information about invalid pages using a VALIDATE or similar procedure (DCX - Using checksums to detect corruption), but that doesn't explain what happens when it is the database server itself that is reading/writing the pages caused by CRUD type operations.
Based on that question, I would suggest that the validation of a database should check the signature string, too.
As John and Mark have explained in comments on this answer, some bytes in the first database page (the "signature") state whether the database file is valid or not.
Well, if the signature is invalid, validation of the database should give an error, too.
Nevertheless, the following statement running on my (not successfully upgraded) database (under 12.0.1.3356) returned no errors at all:
calldbo.sa_validate()
That just seems wrong.
Side effect: If it had given an error, the maintenance plan would not have overwritten a valid database backup.
what is the equivalent to MSSQL DBCC checkdb in sybase?
I'm doing some testing of some relatively large databases (40 - 100 GB) in v12.0.1 (moving from v10.0.1).
I have been comparing times for full checks (using the Sybase Central wizard) and I'm getting broadly similar results on the same database (but reloaded into v12) on the same hardware.
There is mention of improved validation performance in the v12 New Features, so does this suggest that disk speed is my limiting factor?
On my simple single disk test I'm seeing read throughput of around 250MB /min (measured by the Win2008 Resource Monitor) during validation. When I was loading data I was seeing read throughput of about 890 MB/min, but I don't really know enough to compare the two activities). The server isn't doing anything else.
Any thoughts, suggestions, experience appreciated.
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
How can I validate an Ultralite database using the UltraliteJ's api for Android?
I would like to validate the database after execute a ALTER DATABASE FROM FILE command.
If there isn't a way to do that, is there a plan (is it on track) to release this feature for the Android's api?
I have encountered below problem.
-300 sql run time error while validating database..sybase asa 12 db.
Run time SQL error -- %1
Item Value SQLCode -300 Constant
SQLE_ERROR SQLState 40000 ODBC State
S1000 Parameter 1 Identification of the error. Probable cause This error indicates an internal database error, and should be reported to SQL Anywhere technical support.
share if any remedies are available.
