[17.0.11.7236] alter database Upgrade gives assertion fail

[awitter]

Please help on this upgrade thet is not working!

Error on dbgrad:
SQL Anywhere Upgrade Utility Version 17.0.11.7236
Database upgrade started
Creating system views
Creation of system views completed
Error in file upgrade.sql at line 1195 with sqlcode -300
SQL error (-300) -- Run time SQL error -- *** ERROR *** Assertion failed: 115101 (17.0.11.7236)[DemStuks]
unexpected special domain type
Upgrade failed

Here is the syshistory of the database:

  'operation'  ,'object_id','version'   ,'platform'            ,'first_time'             
  'INIT'       ,0          ,'17.0.4.218','W10 #17134  X86'     ,'2019-03-15 09:51:41.000'
  'START'      ,0          ,'17.0.4.218','W10 #17134  X86'     ,'2019-03-15 09:51:41.000'
  'START'      ,0          ,'17.0.4.218','W2008R2 #7601 SP 1 X','2019-03-15 10:11:08.000'
  'START'      ,0          ,'17.0.9.485','W10 #17134  X86_64'  ,'2019-07-31 12:47:06.000'
  'UPGRADE'    ,0          ,'17.0.9.485','W10 #17134  X86_64'  ,'2019-07-31 12:47:20.000'
  'START'      ,0          ,'17.0.9.485','W2008R2 #7601 SP 1 X','2019-08-06 13:06:43.000'
  'START'      ,0          ,'17.0.9.485','W10 #18363  X86'     ,'2020-01-22 11:26:35.000'
  'LAST_BACKUP',0          ,'17.0.9.485','W10 #18363  X86'     ,'2020-01-22 12:34:35.000'
  'START'      ,0          ,'17.0.10.59','W10 #17134  X86_64'  ,'2020-05-01 12:29:54.000'
  'UPGRADE'    ,0          ,'17.0.10.59','W10 #17134  X86_64'  ,'2020-05-01 12:29:59.000'
  'LAST_BACKUP',0          ,'17.0.10.59','W10 #17134  X86_64'  ,'2020-06-02 09:07:50.000'
  'START'      ,0          ,'17.0.10.60','W10 #17134  X86_64'  ,'2020-07-02 12:22:32.000'
  'UPGRADE'    ,0          ,'17.0.10.60','W10 #17134  X86_64'  ,'2020-07-02 12:22:33.000'
  'LAST_BACKUP',0          ,'17.0.10.60','W10 #17134  X86_64'  ,'2020-07-07 09:07:48.000'
  'START'      ,0          ,'17.0.10.60','W10 #17134  X86'     ,'2021-05-28 11:48:03.000'
  'START'      ,0          ,'17.0.10.60','W10 #19043  X86_64'  ,'2021-11-03 14:38:17.000'
  'START'      ,0          ,'17.0.10.60','W10 #19044  X86_64'  ,'2021-11-18 12:18:06.000'
  'LAST_BACKUP',0          ,'17.0.10.60','W10 #19044  X86_64'  ,'2022-01-05 10:31:01.000'
  'START'      ,0          ,'17.0.10.60','W10 #19042  X86_64'  ,'2022-03-07 11:34:52.000'
  'START'      ,0          ,'17.0.10.60','W10 #19044  X86'     ,'2022-04-20 13:14:14.000'
  'START'      ,0          ,'17.0.10.60','W10 #19045  X86_64'  ,'2022-10-20 05:19:27.000'
  'LAST_BACKUP',0          ,'17.0.10.60','W10 #19045  X86_64'  ,'2022-10-20 11:19:00.000'
  'START'      ,0          ,'17.0.11.72','W10 #19044  X86'     ,'2022-12-02 13:01:47.000'
  'LAST_START' ,0          ,'17.0.11.72','W10 #19044  X86'     ,'2022-12-02 13:01:47.000'

The same error happens with the ALTER DATEBASE UPGRADE command

[awitter]

I think I have narrowed the problem to any database that has been created or upgraded with version 17.0.10.5923. I can upgrade any (well, to a certain extent) database except when the syshistory has version 17.0.10.5923 as upgrade/init in it.

[chris_keating]

This may be related to Engineering Case #820234. If that is the case, the database will need to be rebuilt to correct the issue. If the problem persists after rebuilding, you may want to raise an incident to investigate.

[awitter]

Thank you. I cannot see that case, the notes site always says it is being updated. Also, complete rebuild would be impossible, we have thousands of customers each with their own databases.

[awitter]

The server may return the assertion error 115101 "unexpected special 
domain type" or 
201501 "Page 0xf:0xfffffff for requested record not a table page" 
if the server runs, alters or drops a stored procedure with a parameter of 
type ROW, ARRAY or TABLE REF. 
The problem only happens if the procedure has been created with a server 
of version 
17.0.10 but runs on a server with a version 17.0.9 or lower or the opposite 
way around.
This has been fixed.

In existing databases you may fix the problem by rebuilding the database.

No, this is not the case, running a prior database I deleted all our own created procedures, so the only procedures left are those of Sybase themselves. This could mean that many databases will be unusable except when Sybase fixes this.

Also very annoying is the fact that we cannot see what procedure is the culprit. Just a generic line, It would be nice to have that upgrade script too, maybe we could (temporarY) remove the procedures and then create them afterwards, but we need to know what item is the problem.

[chris_keating]

Knowing which procedures fit the criteria described has no value in correcting an impacted database. The only way to correct an impacted database is to rebuild.

[awitter]

I will open a case, because rebuilding is unacceptable for thousands of clients, having databases of several gigabytes that would mean they are down for a few hours! (and some will be down for over a day due to slow rebuilding on large databases)

[VolkerBarth]

Just to understand: If a rebuild is not feasible, what exactly are you trying to achieve with the datatabase upgrade? Do you want to use features that require an upgrade? Or do you upgrade regularly?

(I'm just asking as we usually only do rebuilds when moving to a newer major version, but once that is done, usually only update the database server software without upgrading the database itself – unless a particular feature requires that...)

[chris_keating]

There are options for performing a rebuild with limited downtime. https://help.sap.com/docs/SAP_SQL_Anywhere/e38b2f6217f24bdb90a3ff8ae57b1dd5/cac085ad462f4fe7b4beeb4d...

https://help.sap.com/docs/SAP_SQL_Anywhere/e38b2f6217f24bdb90a3ff8ae57b1dd5/f6237af94e9d440ebbf885fa...

https://help.sap.com/docs/SAP_SQL_Anywhere/e38b2f6217f24bdb90a3ff8ae57b1dd5/b5a46def58654f52acc26c9f...

[awitter]

Unfortunately, the first sentence: The following conditions must be met: * The original database must be created by SQL Anywhere version 17 Not all databases are created by version 17, so this is not a true solution.

Also, trying to make an incident, but the SAP is not really helpful and indeed extremely difficult to come through. "System"? What "system"? The search screen doesn't show any 'system'. I know the product! (well, they changed the name a few times, but hey, just try them all) so, still trying to get an incident done...

[awitter]

We try to make as least upgrades as possible, because it seems that many upgrades create some sort of breaking problem. However, now a bug in the SAP ASA version 17.0.10.6089 forces us to upgrade... giving us other problems on the road. The bug was solved in Engineering Case #825949. and indeed we wait until a major software release, but we make that software ourselves, suiting thousands of customers using this software. Some of our clients just cannot have a downtime of a few hours. We know that a rebuild on their (very fast!!) systems take aproximately 8 hours!

[VolkerBarth]

Thanks for the clarification.

For software bug fixes like the mentioned one, I would assume it's usually only necessary to update the software, not the database itself, unless the error does tell otherwise. So I would still suggest to clarify whether you really need an UPDGRADE or not. (Of course I fully second your expectation that an upgrade should not fail...)

That being said, AFAIK, in order to support all new database features of a new major version, a rebuild is needed. If not all databases have been built with v17, are mere upgrade won't do the trick.

[awitter]

It must be some option that has been removed, for this is what I get on the 17.0.10.6089 server:

SQL Anywhere Upgrade Utility Version 17.0.11.7236
Database upgrade started
Creating system views
Creation of system views completed
Setting option values
Setting option values completed
Creating migration procedures
Creation of migration procedures completed
Creating jConnect procedures
Creation of jConnect procedures completed
Upgrade completed - shut down database and archive transaction log now

Notice that on 17.0.11 after the 'Creation of system views completed' the error pops up

Should I make a case with SAP on this?