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