* * * READ ME * * * * * * Veritas Storage Foundation Sybase ASE CE (SFSYBASECE) 5.0.1 GA * * * * * * P-patch * * * Patch Date: 2010-12-15 This document provides the following information: * PATCH NAME * PACKAGES AFFECTED BY THE PATCH * BASE PRODUCT VERSIONS FOR THE PATCH * OPERATING SYSTEMS SUPPORTED BY THE PATCH * INCIDENTS FIXED BY THE PATCH * INSTALLATION PRE-REQUISITES * INSTALLING THE PATCH * REMOVING THE PATCH PATCH NAME ---------- Veritas Storage Foundation Sybase ASE CE (SFSYBASECE) 5.0.1 GA P1 PACKAGES AFFECTED BY THE PATCH ------------------------------ * VRTSvxfen 5.0.1 (Veritas I/O Fencing by Symantec) * VRTSvcssy 5.0.1 (Veritas High Availability Agent for Sybase by Symantec) BASE PRODUCT VERSIONS FOR THE PATCH ----------------------------------- * Veritas Storage Foundation Sybase ASE CE (SFSYBASECE) 5.0.1 GA OPERATING SYSTEMS SUPPORTED BY THE PATCH ---------------------------------------- Solaris SPARC 9 Solaris SPARC 10 INCIDENTS FIXED BY THE PATCH ---------------------------- This patch fixes the following Symantec incidents: * 2093659 SYMPTOM: VCS fails to start due to incorrect fencing mode. DESCRIPTION: VCS fails to recognize the "sybase" fencing mode when the UseFence attribute is set to "SCSI3" in the main.cf file. RESOLUTION: VCS now starts successfully as the fencing driver sends the correct fencing mode. * 2186348 SYMPTOM: Need to support shutdown with timeout option in Sybase agent. DESCRIPTION: Support for new timeout option with Sybase shutdown command in Sybase agent. RESOLUTION: Enhancement: With Sybase ASE CE version 15.5 ESD #1 onwards, a new timeout option is supported with dataserver shutdown command. This option specifies the maximum amount of time within which the Sybase dataserver ensures stopping of all of its running or sleeping database processes. In the current Sybase agent implementation (without this timeout option), this is achieved using some delays (with sleep command), but under certain situations, this implementation may not cover all the cases where few Sybase specific processes still keep running even after calling out shutdown with wait command for shutting down the database. INSTALLING THE PATCH -------------------- INSTALLING THE PATCH USING FULL UPGRADE PROCEDURE: -------------------------------------------------- Run the following steps on all the cluster nodes at the same time: Note: If this is an upgrade of extisting SFSYBASECE cluster, please ignore step 1 and continue from step 2. 1. If this a fresh install of cluster, please install and configure SFSYBASECE 5.0.1 GA. Refer to Veritas Storage Foundation Sybase ASE CE Installation and Configuration Guide and follow the instructions till chapter 5 to complete the exercise. 2. Stop the stack up to the fencing level. Stop VCS which will stop CFS and CVM: # /etc/init.d/vcs stop Then stop vxfen: # /etc/init.d/vxfen stop Unload the vxfen module: # modunload -i where, is the module id for fencing module. The fencing module id may be obtained by "modinfo | grep vxfen". 3. To upgrade to SFSYBASECE 5.0.1 GA P1, upgrade the following packages: For Solaris Sparc 5.9: For VRTSvcssy # patchadd 145466-01 For VRTSvxfen # patchadd 145467-01 For Solaris Sparc 5.10: For VRTSvcssy # patchadd 145466-01 For VRTSvxfen # patchadd 145468-01 4. Verify that the new patch is installed: For Solaris Sparc 5.9 and 5.10 VRTSvcssy: # showrev -p | grep 145466-01 For Solaris Sparc 5.9 VRTSvxfen: # showrev -p | grep 145467-01 For Solaris Sparc 5.10 VRTSvxfen: # showrev -p | grep 145468-01 The following output is displayed if the patch is installed successfully: For VRTSvcssy on Solaris Sparc 5.9 and 5.10: Patch: 145466-01 Obsoletes: Requires: Incompatibles: Packages: VRTSvcssy For VRTSvxfen on Solaris Sparc 5.9 : Patch: 145467-01 Obsoletes: Requires: Incompatibles: Packages: VRTSvxfen For VRTSvxfen on Solaris Sparc 5.10 : Patch: 145468-01 Obsoletes: Requires: Incompatibles: Packages: VRTSvxfen 5. Start fencing and vcs on the node: # /etc/init.d/vxfen start Add UseFence=SCSI3 under cluster servicegroup definition in main.cf on one of the cluster nodes and then start VCS on that node first before starting it on the other nodes: # /etc/init.d/vcs start 6. Upgrade the Sybase ASE CE database if required. Refer to Sybase documentation for instructions. INSTALLING THE PATCH USING PHASED UPGRADE PROCEDURE: ---------------------------------------------------- For phased upgrade, divide the cluster into two subclusters. For e.g. 4 node cluster can have 2 subclusters each with 2 nodes in it. Perform steps 1 to 3 on first subcluster (eg first 2 nodes in 4 node cluster) 1. Stop the stack up to the fencing level: Stop VCS which will stop CFS and CVM: # /etc/init.d/vcs stop Then stop vxfen: # /etc/init.d/vxfen stop Unload the vxfen module: # modunload -i where, is the module id for fencing module. The fencing module id may be obtained by "modinfo | grep vxfen" 2. To upgrade to SFSYBASECE 5.0.1 GA P1, upgrade the following packages: For Solaris Sparc 5.9: For VRTSvcssy # patchadd 145466-01 For VRTSvxfen # patchadd 145467-01 For Solaris Sparc 5.10: For VRTSvcssy # patchadd 145466-01 For VRTSvxfen # patchadd 145468-01 3. Verify that the new patch is installed: For Solaris Sparc 5.9 and 5.10 VRTSvcssy: # showrev -p | grep 145466-01 For Solaris Sparc 5.9 VRTSvxfen: # showrev -p | grep 145467-01 For Solaris Sparc 5.10 VRTSvxfen: # showrev -p | grep 145468-01 The following output is displayed if the patch is installed successfully: For VRTSvcssy on Solaris Sparc 5.9 and 5.10: Patch: 145466-01 Obsoletes: Requires: Incompatibles: Packages: VRTSvcssy For VRTSvxfen on Solaris Sparc 5.9 : Patch: 145467-01 Obsoletes: Requires: Incompatibles: Packages: VRTSvxfen For VRTSvxfen on Solaris Sparc 5.10 : Patch: 145468-01 Obsoletes: Requires: Incompatibles: Packages: VRTSvxfen 4. Add UseFence=SCSI3 under cluster servicegroup definition in main.cf on one of the cluster nodes of first subcluster. 5. Now on the second subcluster (eg remaining 2 nodes of the 4 node cluster), perform the following: Stop the stack up to the fencing level. Stop VCS which will stop CFS and CVM: # /etc/init.d/vcs stop Stop fencing: # /etc/init.d/vxfen stop Unload the vxfen module: # modunload -i where, is the module id for fencing module. The fencing module id may be obtained by "modinfo | grep vxfen" Note: Downtime starts here. Now start fencing and VCS on the node where main.cf is modified in step 4 in the first subcluster. # /etc/init.d/vxfen start # /etc/init.d/vcs start Note: Downtime ends here. 6. Start fencing and vcs on the other nodes (other than the one where main.cf was modified as mentioned in step 4 in the first subcluster. # /etc/init.d/vxfen start # /etc/init.d/vcs start 7. Repeat Steps 2, 3 on the second subcluster with the remaining nodes. 8. Start fencing and vcs on all the nodes in the second subcluster # /etc/init.d/vxfen start # /etc/init.d/vcs start 9. Upgrade the Sybase database if required. Please refer to the Sybase documentation for the same. REMOVING THE PATCH ------------------ UNINSTALLING THE PATCH: ----------------------- Steps to uninstall the Patch from a cluster node: ------------------------------------------------- The following steps should be run on all the nodes in the SFSYBASECE cluster: 1. Stop the stack up to the fencing level: Stop VCS which will stop CFS and CVM: # /etc/init.d/vcs stop Stop fencing: # /etc/init.d/vxfen stop Unload the vxfen module: # modunload -i where, is the module id for fencing module. The fencing module id may be obtained by "modinfo | grep vxfen". 2. Uninstall the patch. For Solaris Sparc 5.9: # patchrm 145466-01 # patchrm 145467-01 For Solaris Sparc 5.10: # patchrm 145466-01 # patchrm 145468-01 3. Verify that the patch is uninstalled from the node: For Solaris Sparc 5.9: # showrev -p | grep 145466-01 # showrev -p | grep 145467-01 For Solaris Sparc 5.10: # showrev -p | grep 145466-01 # showrev -p | grep 145468-01 If the patch is successfully uninstalled, there will be no output. 4. Restart fencing and vcs on the node: # /etc/init.d/vxfen start Remove UseFence=SCSI3 from under the cluster servicegroup definition in main.cf, on one of the cluster nodes and then restart VCS on that node first before starting it on the other nodes: # /etc/init.d/vcs start