Additional Steps If You Used 15.5 Cluster Edition Features Before Downgrading

If you are rolling back after having used any of the 15.5 Cluster Edition features, additional steps may be necessary. Some steps must be completed before downgrading to 15.0.1 Cluster Edition, 15.0.1 cluster Edition ESDs, and 15.0.3 Cluster Edition, other steps are performed immediately after downgrading. Read the documentation on the features below that may require manual changes.

To correct errors related to:

In general, no additional steps are required when you are returning to an Adaptive Server version in which the feature was already available. However, more information is available on the Sybase Web site at the product manual page where you can search the Adaptive Server Enterprise documentation set for more information on your feature. http://sybooks.sybase.com/nav/base.do

  1. If you used Real-Time Messaging features – Drop all stored procedures, views, and triggers that use the messaging built-ins for the real-time messaging feature. For more information about real-time messaging, see the Real Time Data Services Messaging Users Guide.
  2. If you used New Sort Orders – If a new nocase sortorder for Chinese or Japanese character sets is configured as Adaptive server's default sortorder then, before downgrading to a 15.0.1 Cluster Edition or to a Cluster Edition ESD release, switch to a sortorder that is compatible to that release. Switching a sortorder means all user indexes need to be reindexed. Please refer to Chapter 9, “Configuring Character Sets, Sort Orders, and Languages,” in the System Administration Guide for details on how to change server’s default sort order. If sp_downgrade is called when the new nocase sort order is in use, you see the following error message, and the downgrade process is aborted: 
    Cannot downgrade to '%1!' server, which does not support
server's current default sortorder.
  3. If you used Native XML – The XML Service feature of Adaptive Server includes the new xmltable function. You will get an error if you create views or stored procedures using the xmltable function in 15.5 Cluster Edition then return to 15.0.1 Cluster Edition.
  4. If you used instead of Triggers – instead of triggers are objects stored in the system catalogs. Remove these objects before downgrading. When the 15.0.1 Cluster Edition or 15.0.3 Cluster Edition server is started, any unremoved instead of triggers remain in the system catalogs but do not execute.
  5. If you used SQL User-Defined Functions – SQL user-defined functions are objects stored in the system catalogs. If you do not remove them before downgrading, they remain in the catalogs after downgrade. Attempts to drop or execute a SQL user-defined function from a 15.0.1 Cluster Edition or 15.0.3 Cluster Edition version will result in misleading error messages.
  6. If you installed the 15.5 automatic database expansion procedures using installdbextend then applied the threshold procedure to one or more database segments, the thresholds might not work properly when applied to the log segment after a downgrade to 15.0.1 Cluster Edition or 15.0.3 Cluster Edition. To clear all auto-expansion thresholds that might exist on one or more segments before downgrading, run: 
    sp_dbextend 'clear', 'threshold'
    Alternatively, before downgrading, you can disable the entire automatic expansion feature server-wide without changing any existing rules or clearing any thresholds. Execute the following using sa_role:
    use master 
go 
sp_dbextend 'disable', 'database', 'server-wide' 
go
    This prevents threshold procedures from doing any work even if they were fired at runtime.
    Note: Sybase recommends that you leave all the policies and thresholds in place, and simply disable the entire feature server-wide before the downgrade. This simplifies re-enabling automatic expansion if you return to 15.0.2 later.
  7. If you have Replication Issues with downgrade – When downgrading a server that has replication enabled on databases that contain encrypted data, perform one of the following before you start the downgrade procedure:
    1. Ensure that all replicated data in the primary database transaction log has been successfully transferred to the standby or replicate database. The process for doing this is application dependent.
    2. Using the following commands truncate the transaction log in the primary database, and zero the RS locator for that database in the Replication Server®. In the primary database run: 
      sp_stop_rep_agent primary_dbname
dbcc settrunc ('ltm', 'ignore') 
dump tran primary_dbname with truncate_only 
dbcc settruc ('ltm', 'valid')
      Shut down Replication Server. In the RSSD for the Replication Server run:
      rs_zeroltm primary_servername, primary_dbname
Parent topic: Downgrading