|
I am testing version 12 (12.0.1.3406) and planning an upgrade very soon from v10.01.3960. As part of test, I take the latest v10 backup, read in last log file to recover (dbeng10 -a) and then attempt to start as a v12 database (as I understand upgrade or unload/reload is not a requirement). v12 database will not load successfully, instead creates Error Report (which I sent to Sybase under reporting option). I can still load engine with v10. What should I try next? I really want to get to v12 but my hands are tied until I can get this engine to load sucessfully. Other details: Windows 7 200 GB database 8GB RAM |
|
Have you considered doing a full unload and reload? That way you get the full benefit of v12. A v10 database running under 12 is still a v10 database and many of the new features will not be available. Have a look at this: http://dcx.sybase.com/index.html#1201/en/sachanges/v10upgrade-s-4897531.html Rebuilding is often a good thing anyway as it reorganizes all the tables / indexes etc. 1
FWIW, more information on "What am I missing if I don't reload/upgrade the database when upgrading the database engine?" can be found in this FAQ. It deals with going from 11.0.1 to 12 (Innsbruck Beta) but does apply to 10 to 12 as well.
(17 Aug '11, 06:19)
Volker Barth
|
|
I realize this is possibly something I will have to open a case with tech support on, but here are some more details from error log that is generated. VERSION=12.0.1.3406 FILENAME=C:\ProgramData\SQL Anywhere 12\diagnostics\SA12_20110816_160740_6804.crash_log OS=Windows 7 Build 7601 Service Pack 1 PROCESSOR=X86_64 EXEC_ARCH=X86_64 EXEC_PATH=C:\Program Files\SQL Anywhere 12\Bin64\dbeng12.exe MODULE_PATH=C:\Program Files\SQL Anywhere 12\Bin64\dbserv12.dll EXCEPTION_PTR=000000000CAADEF0 EXCEPTION_CODE=3221225477 EXCEPTION_FLAGS=0 EXCEPTION_RECORD=0000000000000000 EXCEPTION_ADDRESS=000000002072A970 EXCEPTION_NumParameters=2 EXCEPTION_Param0=0000000000000000 EXCEPTION_Param1=000000031FD5A000 TRYING_TO_SAVE_MINI_DUMP C:\ProgramData\SQL Anywhere 12\diagnostics\SA12_20110816_160740_6804.dmp DUMPLEVEL 0 SAVING_MINI_DUMP_COMPLETED CRASH_LOG_COMPLETE |
|
Our game plan was to:
1. Thoroughly test as much as possible.
2. Upgrade software to v12.
3. Start up v10 database under v12.
4. If any issues arose, we could then abandon v12 and re-start engine as v10 until v12 issues could be resolved. I was able to take another v10 backup and load up on server as v12. I ran some tests and am now getting the database to crash with error: Assertion failed: 101212 (12.0.0.3409)[Backup]Page number on page does not match page requested--transaction rolled back. I was able to re-start engine again as v12, but error re-occurs when I run statements again (large DELETE statement). What does this assertion error indicate? Could one of the database spaces be corrupted somehow? How can you tell? I run a full validation with v10 weekly and that does not report any errors. Next steps? Wait for newer ebf and start testing process again? Revert back to maintenance release or older ebf? Unload/Reload (takes 24 hours due to size of database and then lose ability to rollback to v10). Can you start that same database under v10, run the DELETE statement and encounter the same assertion (or another assertion)? If so, your database may be corrupt (for which you may want to unload/reload in v10, then start in v12). Otherwise, you may need a support case to get everything going.
(17 Aug '11, 16:37)
Tyson Lewis
I was able to re-start database under v10, run the statements causing the errors under v12 and did not receive any assertion errors. To me this points to a possible bug with this v12 ebf? Anything else I should be considering?
(17 Aug '11, 17:48)
bgreiman
Replies hidden
Can't say for sure. After that, if you can readily reproduce the issue with v12, submitting a support case will be the easiest/quickest way to research it further. There is also a portal for submitting bugs cases, but they offer no guarantee on response or time. Also, if you're testing both versions on different machines, check your IO system/driver. Heavy IO usage if that delete statement is taking care of many rows may reveal an issue with a RAID controller or other storage component.
(17 Aug '11, 20:25)
Tyson Lewis
I have been able to reproduce issue on 3 machines now, so that is leading me to fact that part of one of the files may be corrupt? I am going to try to unload/reload and then run testing steps after that. I don't think it is hardware related at this point. My only question is why would v10 not have any problems, but v12 would. Checksums turned on in v12 flagging an error that v10 did not find because checksums turned off by default? If file integrity is issue, wouldn't dbvalid have found issues? I will keep testing. I appreciate all of the comments and advice on this forum.
(18 Aug '11, 10:40)
bgreiman
I was able to start a validation (here is bottom part of log): Orphaned page (008c7350) found in database file "c:bersyscentral.db" Orphaned page (008c7351) found in database file "c:bersyscentral.db" Orphaned page (008c7352) found in database file "c:bersyscentral.db" Orphaned page (008c7353) found in database file "c:bersyscentral.db" Orphaned page (008c7354) found in database file "c:bersyscentral.db" Orphaned page (008c7355) found in database file "c:bersyscentral.db" Orphaned page (008c7356) found in database file "c:bersyscentral.db" Orphaned page (008c7357) found in database file "c:bersyscentral.db" Orphaned page (008c7358) found in database file "c:bersyscentral.db" SQL error (-300) -- Run time SQL error -- Database validation failed for database file "c:bersyscentral.db" 1 error reported Are the orphaned page messages anything to be worried about? I ran the validation in a quite environment. Anything I can do to get a better indication of the following error: SQL error (-300) -- Run time SQL error -- Database validation failed for database file "c:bersyscentral.db" Where to from here? I am guessing unload/reload using v10? And then think about migrating to v12. Wondering why I never got any of the above messages when doing dbvalid using v10.
(18 Aug '11, 14:17)
bgreiman
Replies hidden
If the orphaned pages are reproducible (i.e. same errors reported for each validation), then there is some corruption in the database. If you are autostarting this database for a validation in v12, you may be running a database start event which can cause spurious validation errors.
(18 Aug '11, 15:25)
Tyson Lewis
|
Just to confirm: Your understanding that a v10 database should be running with v11 and v12 is correct.