ASE 15.7 SPxxx or ASE 16.0.x.x - Which one should I choose?

[Former Member]

For those considering to move up the ladders from their current ASE release (whether it is ASE 12.5.x or ASE 15.x) there are, obviously, two possible migration alternatives:  ASE 15.7 & ASE 16.   To make the decision more tricky, SAP has stamped both with the same supportability badge:  both have the same EOL dates somewhere in 2020.  Which should one choose, then, and what are the basic elements of making this decision?

Well, this depends on your upgrade methodology.

Binary overlay and its variants:

This one is the easiest to implement. Unload the binaries into the same base directory (or into a separate one if you choose a clean install - my favorite anyway). Run through pre-upgrade steps.  Run through post-upgrade steps. And voila.... Not really.  There is a fundamental difference for this method depending which target migration version you choose:

• For ASE 15.x based migrations the selection of the target version controls whether it is minor or major upgrade.  Staying on the 15.x base means there is a possible downgrade path ONLY if you choose to upgrade to 15.7 release.  So, if you are relying on replacing ASE binaries AND you are based on 15.x right now, jumping to ASE 16 crosses the no-return point. There is no downgrade path from ASE 16 to ASE 15 (or earlier).
• For ASE 12.x based migration the selection of the target version is of less importance from the downgrade perspective.  It is always one way.  There may be more intermediate steps, but the way back is the same.  None?

A thing to keep in mind for ASE 15.x based customers:  SP100 is a breaking point for ASE 15.x SPxxx targets.  There is no direct downgrade path from post SP100 ASEs to pre SP100 ASEs.  So if you do plan to choose ASE 15.7 for your target ASE release your downgrade will have to go through an intermediate stop:  first you will have to downgrade your new ASE to pre-SP100 release (relying on sp_downgrade_esd).  Only then you will be able to roll back all the way to your original release (relying on sp_downgrade).  This is a nuisance, but at least there is a possible downgrade path in case you hit some serious issues post-migrate (it was tested to work, so no need to worry).

Replication server:

This is my true favorite. I remember that ASE 15 migration official documents referred to replication server as one of the best methodologies to move from pre-15 to post-15 releases (if I remember right, there was a "Migration Guide" dedicated to moving away from the safety zone of 12.5.x ASEs).  Contrary to that, the installation guides for the ASE 15.7 or ASE 16 do not mentioning replication server alternative for the upgrade.  This is quite unfortunate, since now DBAs who are aware of the possibility to use replication server have to go extra steps to persuade the decision making board as to why this method is the best.  It is not hard to do it (the ASE of origin left intact, downtime is measured in seconds, rollback procedure is clean, rollback is measured in seconds, &c), but had the documentation officially stated this it might have helped DBAs to drive the point.  Actually, since ASE moves to the direction of a full-fledged Replication Server bundled into ASE package (ASE 16 SP02 will have HADR functionality packaged as a part of ASE installation - for those purchasing HADR license) I'd suggest SAP decision making board to put it back into documentation AND wrap some basic RS functionality into base ASE 16 package restricted to be used for the migration purposes only.  This might have made the migration more "trivial" as well as generated taste for the product for those unfamiliar with it.  Just a thought...

For those employing Rep Server as a part of ASE migration, selecting ASE 15.7 over ASE 16 does not have true advantage points.  The service packs for each are issued more or less at the same rate.  Conservatives might say that ASE 15.7 is more Sybase-flavored while ASE 16 is 100% SAPiant.  But ASE is already 100% SAPiant.  SAP decides where the product will go and it does it not bad at all...

For the conservatives I'd suggest to consider this in their decision making:

AES 16 has over a 1000 bug fixes atop ASE 15.7

Consider the statistics below - based on the release notes for the ASE 16 service patches (Solaris based, Windows have similar number, Linux - may have even more as there are exclusive Linux features in some of future ASE releases).

Release	Date	Bug fixes
EBF 22626: 16.0 SP0 PL1	24.04.2014	290
EBF 22668: 16.0 SP0 PL2	01.07.2014	20
EBF 23020: 16.0 SP0 PL3	04.09.2014	71
EBF 23371: 16.0 SP0 PL5	15.12.2014	94
EBF 23902: 16.0 SP01	17.03.2015	434
EBF 24357: 16.0 SP01 PL01	22.04.2015	52
EBF 24486: 16.0 SP01 PL02	30.06.2015	114
		1075

ASE 16 is packed with more goodies than ASE 15.7

Post SP 100 ASE 15.7 itself is something to strive to (reorg defrag, create index ... online, optimize temp table resolution to avoid SP recompiles, more metrics in monState for those messing with general ASE profiling).  ASE 16 adds even more functionality.  Some of it listed below:

1.  Dynamic Histograms:  useful for tables where out-of-range values are added frequently to the table to avoid costly table scans for new max column values.

2.  Mounting/Unmounting Encrypted Databases:  not possible before ASE 16.

3.  Compressed Indices:  use simple alter database commands to enable/disable index compression (table, index, partition, DOL & APL).

4.  Support for select into #table in multi-statement transaction:  for those who use it - yes, we can.

5.  Partition Locking:  better concurrency mechanisms with partition-level locking.

6.  Wider Query Limit: for subqueries and wild joins, in case it is really necessary.

7.  Create or Replace Semantics:  yes, now in ASE too it is possible to preserve object IDs.

8.  Improved Query Performance:  various improvements in parallelism and access to compressed values.

9.  Full DB Encryption:  a new functionality to complement already available column encryption.

10.Residual Data Removal:  for those sensitive to what may be sniffed out with low level post-DML dbcc commands.

11.Config History:  ability to record config changes in sybsecurity.

12.Wrapping various ELC TFs as config parameter:  Yep, those neat 75x TFs are now configurable.  So is ELC size.

13.ULC Queue:  new way to improve contention on log device - for the nasty "unpin" type contention which was plaguing ULC hit ratio.

14.Select-level with recompile:  ability to recompile only a single SQL statement in SP to assist optimizer.

ASE 16 SP02 will add more features to the list - some pretty heavy weight (like out-of-the box HADR solution, more cache types to keep physical IO as low as possible, dynamic partition management a-la EMC FAST, new ASE management tools - including the precious workload replay capabilities which once DBA might only dream to have - & more).  But that is (close) future.

So which release do you choose?

To put it simple:

If you can go ASE 16, do it.  It has more to offer than ASE 15.7.  If your roll-back procedure is based on Replication Server and thus your migration is instantaneous stopping half-way is not too wise.  If you are note pushed by hard schedules and do not have to commit to the migration project right now you might want to wait for the next ASE 16 release - SP02. It will have an impressive set of functionality to offer.  If the same quarterly release rate continues by SAP,ASE 16 SP02 PL01 will be available in about half a year time.  Not very far ahead. 

If you rely on an ASE binaries based rollback - you don't really have a choice.  ASE 15.7 is your target selection.

Keep in mind, though:  although it may seem that the decision making matrix hinges on the question "do I cross the no-return point?" in fact it does not.  The no-return point will be crossed sooner or later.  Should it be crossed now?  Depends on your readiness and your risk mitigation techniques.

ATM.