Upgrade from version 10 to version 12

[bgreiman]

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

[VolkerBarth]

Just to confirm: Your understanding that a v10 database should be running with v11 and v12 is correct.

[justin_willey]

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.

[VolkerBarth]

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.

[bgreiman]

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

[bgreiman]

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.
5. Once everything appears to be stable, run unload/reload to permanently move to v12.

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

[Former Member]

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.

[bgreiman]

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?

[Former Member]

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.

[bgreiman]

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.

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

[Former Member]

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.