Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 ‘Why’ and ‘How’ Migration Guide to ASE 11.9.2/12 Ian Annis Principal Consultant Sybase Professional Services (UK) March 2000 UKSUG Masterclass.

Similar presentations

Presentation on theme: "1 ‘Why’ and ‘How’ Migration Guide to ASE 11.9.2/12 Ian Annis Principal Consultant Sybase Professional Services (UK) March 2000 UKSUG Masterclass."— Presentation transcript:

1 1 ‘Why’ and ‘How’ Migration Guide to ASE /12 Ian Annis Principal Consultant Sybase Professional Services (UK) March 2000 UKSUG Masterclass

2 2 Presentation Mission Migration is something that no organisation should undertake lightly. It is a process that requires justification and planning in order to achieve a smooth transition to a new environment. This session will cover the pre-upgrade, migration and post-upgrade issues that need to be addressed in performing a migration to ASE and ASE 12.0

3 3 Agenda l Why Migrate ? l How Migrate ? l Planning & Pre-Upgrade l Migration Steps l Post-Upgrade l ASE 12 l Summary

4 4 Agenda l Why Migrate ? l How Migrate ? l Planning & Pre-Upgrade l Migration Steps l Post-Upgrade l ASE 12 l Summary

5 5 Why Migrate ? l Vendor Push n End of Life (EOL) Policy Ô Version Support (Industry practice -> last 2 releases) Ô Platform Support (Critical mass - support costs) n New Features Ô Performance Enhancements (query optimiser, parallel support,...) Ô Functional Enhancements (row level locking, 64-bit support,...) Ô Availability Enhancements (HA, recovery speed, rebuild index,...) n Emergency Bug Fixes (EBF) l Client Pull n ‘Latest Version’ Syndrome n Change in Environment Ô Platform change n Performance Issues Ô Old application not keeping up with growth in business

6 6 Sybase End of Life (EOL) Example End of Support Notification for Adaptive Server Enterprise 11.5.x on Compaq Alpha NT Adaptive Server Enterprise , and Adaptive Server Enterprise on all platforms Jan 19, 2000 Dear Valued Sybase Customer: This letter provides notification of the end of support for certain older versions of Sybase product offerings. We are announcing the end of support for certain older versions of Adaptive Server Enterprise. Specifically, Sybase will no longer offer support for the following products: ProductEnd of Support Date Adaptive Server Enterprise 11.5.x Jan 31,2001 (for Compaq Alpha NT) Adaptive Server Enterprise Jan 31, 2001 Adaptive Server Enterprise Jan 31, 2001 June 30, 2001(for Silicon Graphics platform only) In addition to the products listed previously, Sybase will also be discontinuing support for the following hardware / operating system platforms. Platform End of Support Date Compaq Alpha NTJan 31, 2001 Until the End of Support Date, Sybase will fix only Priority 1 bugs for the above versions. For all of our active support customers, Sybase will provide a free license upgrade to Adaptive Server Enterprise Sybase Professional Services is available to assist you, on a fee basis, with migration to these current versions of Sybase's database offerings. We strongly recommend that you upgrade to a newer version.

7 7 Sybase EOL Current Position End of Support Notification for Older Versions of Sybase Products March 9, 1999 Sybase will no longer offer support for the following products: ProductEnd of Support Date Sybase SQL Server Jun 30, 2000 (OpenVMS to 31/12/2003) Adaptive Server Enterprise 11.5.xDec 31, 2000 Adaptive Server Enterprise Jan 31, 2001 Adaptive Server Enterprise Jan 31, 2001 (June 30, 2001 for SGI platform only) Open Client/Open Server Dec 31, 2000 (OpenVMS to 31/12/2003) Replication Server Jun 30, 2000 In addition to the products listed previously, Sybase will also be discontinuing support for the following hardware / operating system platforms…. As part of the rationalization of supported hardware/software platforms, a number of platforms are no longer supported from For lists of platforms which have been dropped, go to and look for the following Document IDs: Ô Ô 20406

8 8 Architecture Issues l What else is changing / needs to change n Certification Issues Ô What does certification give you (Sybase monthly update) Ô Doc ID n Operating System Upgrades Ô 32/64-bit support Ô Feature enhancement / Bug Fix / Patches n Problem Upgrades Ô HPUX 9->10 -> 11 Ô Sun Solaris with LVM version 2.4 (keep versions in line) Ô NT Service Packs n Product Compatibility Ô Sybase SQL Server base product for Y2K Ô Will it work with third party product ‘xyz’ n Scope of overall change required

9 9 Sybase Adaptive Server Releases l Former releases of Adaptive Server Enterprise (ASE) include: n SQL Server 11.0 (released in Dec 1995) Ô SQL Server is baseline release for Y2K compatibility n Adaptive Server Enterprise 11.5 (released in Sept 1997) n Adaptive Server Enterprise (released in Oct 1998) n Adaptive Server Enterprise 12.0 (released Dec 1999) n Supported upgrades to Adaptive Server are from versions: Ô Ô Ô Ô Ô n If you are running a version of Adaptive Server or SQL Server that is earlier than those listed here, it is recommended that you upgrade to one of these versions before upgrading to

10 10 Adaptive Server Enterprise (ASE) l Designed for Performance n OLTP/TPC-C benchmark records n SMP linear scalability (LMM, LPM, Parallel Support) l Designed for 24*7 Operation n Zero requirement for database downtime Ô On-line backup & recovery, and On-line maintenance tasks n Resilience Architecture for: Ô Disks, Processors, Machine, Location Ô High Availability (HA) support in ASE 12.0 Ô OpenSwitch and Replication Server support for Warm Standby l Designed for Low Cost of Ownership n Multi-threaded Kernel Ô < 100 KB memory per user Ô more users supported per processor n DBA Overhead Ô Less maintenance required (less scope for human error ?)

11 11 Changes in SQL Server 11.0.x l New Server Engine n LMM, LPM l ANSI SQL Level 2 l Syntax l Display format l Data Conversions n Money n Integer to Char l New Optimizer l Subquery Processing l Aggregates with EXISTS l BETWEEN l Comments Required some changes to application SQL

12 12 Key Features of ASE l Key New Features: n Data Row Locking n Performance Improvements for Dynamic SQL n Better Query Optimization l Key Benefits n Flexibility in locking granularity n Dramatically higher performance with applications that have lock contention n No performance degradation for existing applications

13 Optimizer Statistics l Statistics now stored in two system tables n Column level stats (distribution, density values and date and time of last modification) are stored in sysstatistics. n Table and Index level statistics are stored in systabstats. n Space for statistics is limited only by the size of the DB. l No guarantee of good performance n Update statistics does guarantee up to date statistics. n There are no rules about when to run update statistics. n Statistics provide accurate information about the data to the optimizer. Ô The more statistics available the more information the optimizer has to work with. Ô Remember to run ‘sp_recompile ’ for pre-compiled objects to access the updated statistics. Ô New ‘optdiag’ tool to view and simulate statistics for DB tables

14 14 Key Features of ASE 12.0 (Avatar) Key Focus Areas l High Availability (HA) n Reduction In Planned Downtime n Active-Active Fail-Over and Single Node Recovery Enhancements l Performance and Scalability n Re-design Optimizer’s Top Half Ô Query Processing Extensibility n OLTP and DW / DSS Performance Ô Sort Merge Joins Ô Abstract Query Plans l Native Object Support n Import Java Classes into Database n Objects = Abstract Data Types Ô Extend Native Type System n Methods = User Defined Functions Ô Use in any SQL SELECT list or WHERE clause l Distributed Transaction Mgmt n Full XA, MS/DTC and DTC-XA n ASE as Transaction Coordinator

15 15 Migration Survey l Who’s carried out an ASE Migration ? l What route did you use ? l Did you read the Installation Guide ? l How much pain did you suffer ?

16 16 Agenda l Why Migrate ? l How Migrate ? l Planning & Pre-Upgrade l Migration Steps l Post-Upgrade l ASE 12 l Summary

17 17 Migration Process l Planning & Pre-Upgrade Tasks n Analyze existing system and business requirements n Decide and prepare on migration route n Plan migration tasks l Migration Tasks n Implement migration route l Post-Upgrade Tasks n Enhance system for new features n Test performance and usability

18 18 Major SAFE/EM Migration Activities Planning the migration project Establishing the current configurations Documenting business requirements Developing compatibility analysis Planning for application and platform migrations Administering the migration project Designing and developing migration scripts for data servers Recording source and target configurations Migrating data and application code Performing quality-assurance testing and corrective actions

19 19 Agenda l Why Migrate ? l How Migrate ? l Planning & Pre-Upgrade l Migration Steps l Post-Upgrade l ASE 12 l Summary

20 20 Analyze Existing System l Document Existing Architecture n Servers, clients, network config and application description Ô H/W & S/W configuration and sizing l Operational Business Requirements n Availability Requirements - allowable downtime periods n Maintenance Procedures - backup plans & schedule n Service Level Requirements l Current Performance Metrics n Transaction profiles by application n Server performance (sp_sysmon) l Additional Business Requirements n Priority list for application migration and dependencies n Resource issues (IT and human)

21 21 Analyze Sybase Configuration l What is currently running n record configuration file or ‘sp_configure’ n record SQL interface file l What disk devices and their usage n record current disk device configuration n map databases and segments to devices n record dump devices l Scripts for Database Objects n Should already have them, else reverse engineer with: Ô Sybase Central (generate DDL) Ô PowerDesigner DataArchitect Ô Third party tools, e.g. Cyrano

22 22 Plan the Upgrade l Be Prepared at every stage n Once you know what you have - you can identify what needs to change l Advanced Reading n Prepare yourself for the task in hand - read the manuals l Determine Migration Route n Based on the requirements gathered to date, choose the appropriate method Ô Cutover without replication Ô phased cutover Ô parallel with replication l Develop Migration Plan n Plan activities and resources required

23 23 Produce Migration Plan l Plan the whole process n Migration Strategy n Fallback Ô what if it didn’t work, how do I stay operational n Application Test Suite Ô plan and develop tests for functional and performance testing n Bridging Strategy Ô how minimize impact to end-users (linked to migration strategy) n Environment Ô consider the whole process - not just the ASE upgrade part n Scheduling Ô plan when it happens Ô set milestones and reviews to be able to know when each stage is finished

24 24 Resources To Perform Migration Process l Documentation n Installation Guide (platform specific) n Release Notes (platform specific) n What New in ASE Release 11.9.x/12.x n Performance & Tuning Guide n System Administration Guide l Tech Support n n Technotes: n Manual: Migrating to Sybase ASE 11.5Migrating to Sybase ASE 11.5 l Sybase Professional Services n Installation & Migration Support (SAFE/EM) n Performance & Tuning

25 25 Migration Strategy l Determine Migration Strategy n Cutover without replication Ô easiest option with minimal resource demands Ô highest risk as it requires downtime during critical migration phases and subject to lengthy recovery on fallback n Phased cutover Ô enables managed/planned migration of an application at a time Ô can use any route to achieve it’s aim dependant on risk/resource/.. n Parallel with Replication Ô minimal system downtime, hence good for 24x7 environments Ô extra set-up and H/W resource required for replication server Ô easy fallback to existing server Ô easy comparison with existing system for performance, functionality Note: Whenever possible, upgrade test and development databases first. Upgrade the production system after testing.

26 26 Migration Routes to ASE l Determine Migration Route n ASE Upgrade Process Ô sqlupgrade to upgrade server- full cutover Ô DIY (manual patch)- full or phased cutover n Fresh Installation of New Server Ô BCP old databases- full or phased cutover Ô Dump & Load old databases- parallel, full or phased cutover Ô Replication Server- parallel or phased cutover Sybase Adaptive Server

27 27 Migration Route Architecture Sybase Replication Server Old ServerNew Server executables Database Object DDL + BCP Data Database Dump + Load Transaction Dump + Load Sqlupgrade or DIY BCP Dump & Load Replication Sqlupgrade or svrbuild

28 28 Moving a Database to Another Server l If a database is to be reproduced exactly on the same hardware platform: n Copy any needed definitions from the old database using Sybase Central (generate DDL) or use existing scripts n Make a copy of the old database using dump database n Create a new database using create database (from scripts !) n Load in the new database contents using load database l If the target database is not identical to the original database: n Copy all definitions using Sybase Central n Create the new database as needed using Sybase Central’s DDL scripts n Copy the data out of the old database using bcp n Copy the data into the new database using bcp

29 29 Database Utilities l ASE Build Utilities n An ASE database utility is a program executed from an operating system prompt or GUI interface that assists in system administration Ô srvbuild - a UNIX-based server installation utility Ô srvbuildres - a UNIX-based server installation utility where a GUI is not available Ô Server Config - a Windows-NT based server installation utility Ô dsedit - an editor for creating and modifying interfaces files Ô bcp - a program that copies data from a database to an operating system file, and vice versa Ô optdiag - a program for detecting inefficient space usage in tables using data-only locking Ô sqlupgrade - a UNIX-based server installation utility to upgrade an existing server

30 30 l Single sybase directory n Files for all components are stored in this directory l Important sybase subdirectories n bin Ô All executables (isql, bcp, and so on) n charsets Ô Character set and sort order localization files n init Ô Installation log files n install Ô Install programs, RUNSERVER files, the error log n scripts Ô Database install scripts Directory Structure: Pre-ASE 12.0

31 31 Directory Structure: Pre-ASE 12.0

32 32 l ASE default character set and sort order n The default character set depends on the platform Ô Windows platforms default to cp850 Ô Digital Unix, IBM AIX, and Sun Solaris default to iso_1 Ô HP defaults to roman8 Ô These character sets support US English and include accented characters for most European Languages n The default sort order is binary sort order n Alternative options can be chosen at installation time l Post installation character sets and sort orders n Whilst they can be changed, it is not advisable as it requires significant manipulation of existing data. These changes are not recommended unless absolutely necessary. l View the current character set and sort order n sp_helpsort Character Sets and Sort Order

33 33 Pre-upgrade Checklist l General preparation n Read the documentation - installation guide to hand n Verify software release with OS release + patches required n Run the pre-upgrade option within sqlupgrade Ô check reserve words, system database sizes, DB options, etc. n Check and backup databases Ô Run dbcc checkdb, dbcc checkalloc, and dbcc checkcatalog on all your databases including the master database. Ô If the dbcc's do not return any errors, make backups of all your databases including the master database. Ô Drain replication queues & stop replication (see Installation Guide) Ô Turn off Sybase mirroring if it is enabled n Upgrade your operating system first Ô If possible, run existing SQL Server on the new operating system for several days/weeks to troubleshoot any problems caused by the operating system change before upgrading to ASE /12

34 34 Backup Your Databases l Keep current backups of all databases prior to upgrading, regardless of the route chosen n System Databases (master, model, sybsystemprocs) n User Databases (as required) n Bulk Copy output of master-only system tables to help in disaster recovery scenarios from: Ô sysdatabases Ô sysdevices Ô syslogins Ô sysusages l You may need to rebuild master if: n Adaptive Server fails during the upgrade process (disk problems, etc.) n to duplicate it on another machine n it’s easier to keep up-to-date backups than to rebuild master from scratch

35 35 Agenda l Why Migrate ? l How Migrate ? l Planning & Pre-Upgrade l Migration Steps l Post-Upgrade l ASE 12 l Summary

36 36 Build the Server Environment l Prepare the IT environment for the upgrade n Identify ASE release (and EBF) to be applied n Prepare the H/W (sufficient resource) + OS patches as identified in the Installation Guide Ô New ASE releases usually increase memory requirements n Prepare scripts as appropriate for chosen Migration Path Ô Server level scripts - disk init, server configuration, … Ô Database Object scripts - reverse engineering or prepared scripts n Make required application changes Ô remove new reserved words identified in prepared (sp_checkreswords) Ô changes in syntax, e.g. SQL92 support n Verify and Configure Existing Server if it is being upgraded Ô increase memory allocated to ASE Ô increase size of sybsystemprocs (to 60Mb) Ô copy your own ‘sp_’ for loading after the upgrade

37 37 sqlupgrade Overview l Automatic Phased Process using sqlupgrade n The sqlupgrade Phases Ô Phase 1: Runs the preliminary test to make sure the upgrade will work properly. Ô Phase 2: Runs the upgrade program, which actually performs the specific upgrade tasks. Ô Phase 3: Completes the upgrade by recreating the sybsystemprocs database by running the installmaster and installmodel scripts. The sqlupgrade log is located in $SYBASE/init/logs/sqlupgradeMMDD.NNN..

38 38 Sqlupgrade Phase 1 - pre-upgrade l Boot the previous version of SQL Server to: Ô a. Copies the interface file entry from the earlier interfaces file to the new interfaces file Ô b. Runs preupgrade tests, checking for free space and database options. The program is located in $SYBASE/upgrade/preupgrade Ô c. Checks for reserved word conflicts. File is created in $SYBASE/init/logs/checkres.dmp Ô d. Checkpoints all databases Ô e. Saves the database segment information in a file located in $SYBASE/init/logs/usage.sql. This file is removed after a successful upgrade. Ô f. Shuts down the original SQL Server n 2. Creates a runserver file, RUN_servername, in the install dir n 3. Starts the new server with a new configuration file, $SYBASE/servername.cfg. This step recovers all databases.

39 39 Sqlupgrade Phase 2 - upgrade l Run the $SYBASE/upgrade/upgrade to: Ô a. create temp files to manage the progress of the upgrade (sqlcmds.n) l sqlcmds.0 - contains most of the upgrade's SQL commands; could be used to check current status of upgrade sqlcmds.0 l sqlcmds.1 - contains updates to system tables sqlcmds.1 l sqlcmds.2 - contains generic functions and remapping commands; could be used to check the status of remapping the query trees. sqlcmds.2 l sqlcmds.3 - contains a list of changes to the system table sysindexes sqlcmds.3 Ô b. Ensures the old SQL Server version is supported for the upgrade. Ô c. Runs the appropriate tasks, depending on the version of SQL Server that is being upgraded. To view what is actually being done at this point, view the sqlcmds.* files above for more details. Ô d. Allows updates to system tables. Ô e. Sets the version of the SQL Server to the new version number. Once it has done this step you CANNOT rerun the upgrade program.

40 40 Sqlupgrade Phase 3 - new system build l Runs the $SYBASE/upgrade/upgrade to: Ô a. Turns off allow updates to system tables Ô b. checkpoints all databases Ô c. Updates the runserver file. Ô d. Shuts down and restarts the new release Server. Ô e. Runs the installmaster and installmodel scripts. n Note: it is safer to drop and re-create all compiled objects (stored procedures, triggers, etc.) in the new environment to ensure new query plans are generated

41 41 Benefits With sqlupgrade Route l Automated Upgrade n Generally, no intervention is required l Speed n As the data is not being upgraded or reloaded, then it is generally a fast process to run through l When to use this approach n Recommend for development/test systems Ô only use approach on production servers with care and confidence of success, and where a window exists to upgrade, I.e. not 24x7 applications n Acceptable approach for small to medium systems, or very large systems where an alternative server/disk space is not available

42 42 Issues With sqlupgrade Route l Lack Of Control n How handle errors during the upgrade process n One-way operation Ô can recover (same with EBF) to restart upgrade after correcting fault, e.g. read only file not updated, disk or log space, etc. l Recoverability n Poor - see above Ô Must have backups to recover to Ô Service may be unavailable whilst the executables and dumps are re-loaded

43 43 DIY Route Overview l Manual Process using srvbuild phase by phase n As an alternative to using sqlupgrade: Ô Manually install new ASE release Ô create the databases then load the old server dumps from backup Ô When the online database function is run, it will upgrade the old database to the current release. Ô You cannot load the old master database dump, you can only load user databases. Ô Transactions logs can also be loaded in the same way to enable a phased hand-over between the two servers

44 44 Benefits With DIY Route l Clean Installation n No legacy issues to address on new server n Starting point is clean installation containing only the required system databases l Recoverability n This is a safe method as it leaves the original Server intact

45 45 Issues With DIY Route l Requires more DBA effort (time issue) l See Dump & Load issues

46 46 BCP Route Overview l Manual Process using srvbuild and BCP n Build a new server and copy data across: Ô Manually install new ASE release using srvbuild Ô create the databases as per original size or larger Ô create the database objects with the prepared DDL scripts Ô load the old data from BCP files into the new server tables Ô rebuild indexes and triggers

47 47 Benefits With BCP Route l Clean Installation n No legacy issues to address on new server l Platform Independence n Use -c option to pass BCP data in ASCII mode l Data Clustering n Data loaded and allocated in extents contiguously n Forced re-creating of all indexes (if using fast BCP) n Statistics recreated by index creation l Device Allocation n Easier to change device location/size as recreated from scratch

48 48 Issues With BCP Route l Volume of data to migrate (time issue) n Consider using fast BCP approach (no indexes, triggers,..) Ô Drop all the indexes and triggers on the table Ô Copy the data into the table Ô Recreate the indexes and triggers Ô Dump the database (as operation is minimally logged) n Configure and run parallel BCP load into partitioned table Ô Running concurrent sessions of large bulk copy jobs into specific partitions substantially increases performance

49 49 Issues With BCP Route (cont) l Downtime or incremental transaction update n As soon as the data is BCP’ed out, no more transactions can enter the old server unless a method is devised to capture any new transactions against the old server.

50 50 Dump & Load Database Route Overview l Transfer data to new server on same platform n Transactions must be loaded in the correct order, and they all have to be there Ô load transaction without prior load database will fail n Issuing a load database takes a database off line Ô Eliminates administrator’s need to mark databases dbo use only when loading a database and transaction logs Ô set ‘online database ’ after loading is complete Old ServerNew Server

51 51 Rules for Loading Databases l Database Loading Restrictions n Database must not currently be in use n Can load only dumps made on same machine type n The database into which you load must exist, and it must be at least as large as the dumped database Ô Use sp_helpdb to see amount of space allocated to a database n Loading data into an existing database overwrites its data; partial loads are not possible n To create a new database for loading, use the for load option to create database l Dump Compatibility n When an Adaptive Server installation is upgraded to a new release, all databases associated with that server are automatically upgraded Ô Upgrade is on a per-database basis, for upgrading a database or transaction log dump from any previous release to the current one

52 52 Benefits With Dump & Load Route l Speed n Major factor is that the new server can be prepared independently ready for the first dump. n Dump & load is relatively fast - even for large volumes of data, and database is upgraded when it is made online l Up-to-Date n Keep applying transaction log dumps to keep new server up-to-date n Downtime for switch over is minimised l Fallback n Easy to fallback as old server still exists in line until first transaction in new server - same issue on capturing new transaction data

53 53 Issues With Dump & Load Route l Compatibility n Only works on same hardware platform (sometimes OS release restrictions as well) l For load option n New server with physical layout from previous server Ô maybe inefficient use of storage - need indexes re-created Ô may have data loaded into log segments (see SA manual on recovering for incorrect segment mapping after load) l Recoverability n Once new data has been entered the database dump can not be loaded into the previous version Ô recovery to previous version would be via the BCP route.

54 54 Replication Route Overview l Manual Process using srvbuild and Rep Server n Build a new server and create replication configuration: Ô Manually install new ASE release using srvbuild Ô create warm standby configuration in replication server from old database to new database Ô materialise the data for the database Ô test and check performance of new server prior to switch-over Ô switch-over active database to new server and capture transactions back to the old server

55 55 Benefits With Replication Route l Clean Installation n No legacy issues to address on new server l Platform Independence n Data conversions handled between servers l Availability and Recoverability n Best method for true 24x7 operation where continuation of service must be maintained n Can be configured in warm standby mode to switch and get new transactions being replicated into old server - allows for rapid fallback if problems are found on the new server n Valid functional and performance testing with up-to-date data prior to switch-over

56 56 Issues With Replication Route l Effort required (time & resource issue) n Requires resources and skills to set up and use replication server Ô May already have expertise in-house n Materialisation process can take a long time on large production systems Ô Ensure optimal configuration of replication server for the task in hand Ô Not a major issue as the operational system carries on running during this process Ô Ensure adequate spare capacity to handle materialisation overhead on the old server

57 57 Agenda l Why Migrate ? l How Migrate ? l Planning & Pre-Upgrade l Migration Steps l Post-Upgrade l ASE 12 l Summary

58 58 Testing the New Server l Stability & Performance Prior to Roll-out n The primary goal of testing is to ensure that after migration: Ô Application behavior is predictable. Ô Application and operational service levels are preserved or exceeded. Ô The test and production systems are stable and the data is safe. Ô The upgrade is successful and does not adversely impact the production system Note: testing strategies are not covered in this presentation

59 59 Verification and Use of New Server l Verify the version level of Adaptive Server. To verify that you are at the new version level, connect to isql and run the following commands:  1> select l Look for “11.9.2” in the version string.  1> sp_configure "upgrade version" sp_configure should return the Run Value “11920”. l Re-enable Replication n If replication server is in use Ô reset the secondary truncation point Ô restart replication server Ô enable the rep_agent on appropriate databases l Configure Client connections

60 60 Post-Upgrade Steps - Update Statistics l Update Statistics n 11.9.x statistics have been improved n now on all columns n better support for large tables (more distribution steps) n defaults to previous server statistics after pre 11.9.x load n preferred method to update stats: Ô run optdiag on each user table (backup of pre-upgrade stats) Ô run update statistics on each user table Ô run sp_recompile on each user table Ô check new stats with optdiag Ô see: “Optimizer Statistics After Upgrading to ASE ”, Doc ID 20461

61 61 Post Upgrade Steps - Data Only Locking l Identify and Reduce Lock Contention n Use ‘sp_sysmon’ and ‘sp_object_stats’ to identify possible lock contention issues Ô consider using (only where required) l ‘alter table lock datapages’ l ‘alter table lock datarows’

62 62 What if ….. l Serious errors / server won’t start n Resort to backup or previous server n Switch client interface files back to old server n Manual patching/upgrade of the problem (Tech Support) l Poor Performance n Testing should have identified obvious performance problems n Run standard commands to identify problem area, e.g. sp_sysmon, sp_object_stats (11.9.2), etc. n Ensure statistics are up-to-date l What about new transactions n Capture transaction text (difficult !) n BCP out data daily to be able to recreate new data n Replication of new transactions back to old server

63 63 Agenda l Why Migrate ? l How Migrate ? l Planning & Pre-Upgrade l Migration Steps l Post-Upgrade l ASE 12 l Summary

64 64 Key Features of ASE 12.0 Key Focus Areas l High Availability (HA) n Reduction In Planned Downtime n Active-Active Fail-Over and Single Node Recovery Enhancements l Performance and Scalability n Re-design Optimizer’s Top Half Ô Query Processing Extensibility n OLTP and DW / DSS Performance Ô Sort Merge Joins Ô Abstract Query Plans l Native Object Support n Import Java Classes into Database n Objects = Abstract Data Types Ô Extend Native Type System n Methods = User Defined Functions Ô Use in any SQL SELECT list or WHERE clause l Distributed Transaction Mgmt n Full XA, MS/DTC and DTC-XA n ASE as Transaction Coordinator

65 HA - High Availability l ASE HA Objectives in this Release n Reduction In Unplanned Downtime Ô Near-seamless Fail-Over of One ASE Node Onto Another, Cluster Configured, Companion Node Ô High Performance Fail-Over (No Start-Up Overhead) Ô High Performance Recovery After Fail-Over Ô Integration With HW/OS Vendor HA Systems n Reduction of Planned Downtime Ô Back Up Server Performance Enhancements Ô On Line Index Reorganization

66 66 SystemDB systemprocs security Interfaces File Master User S1 Establish Companion SystemDB systemprocs security Master S2 Replicate Users/Logins Establish Proxy DBs Establish Companion User Interfaces File HA System HA - Establish Companion

67 HA - Reduction in Planned Downtime l Reduction in backup & recovery overhead n Order of Magnitude Back-up and Restore Performance Improvements l Reduction in time for index maintenance n Random inserts and deletes in an index cause: Ô Drop in space utilization Ô Declustering (Scan of page chain in key order may cause random I/O) n Online index rebuild preferred to recreating indexes using reorg rebuild Ô Copy all index rows to new pages and deallocate old pages under an intent lock (an extent at a time) - DOL indexes only Ô high concurrency operation with minimal logging and no deadlocks Ô achieve clustering and desired space utilization goals

68 68 Java In The Database l Java Is Becoming a Generally Accepted Computing Platform l Java Offers The Promise of Unified Programming Model Across All Tiers n Develop, Debug, and Deploy Objects/Logic Components and Data Objects Across Client, Data Stores and Middle Tiers l Java Offers a Rich Environment for Database Programming n Complete, Object-oriented Programming Language Provides Tremendous Extensions to SQL Capabilities n Non-proprietary and Portable Language n “Pointer-safe” Language for Integrity of Database Kernel

69 Java in Adaptive Server Enterprise l Goals in This Release: n Extend ASE's T-SQL Language Capabilities With Java n Use Java Classes As: Ô User Defined Functions Ô User Defined Datatypes n Embed Java Virtual Machine Inside the Server n Provide Utilities to Install Java Classes Into a Database n Enable Remote Java Debugging

70 70 DB 2 ASE Oracle New York Tokyo London Client Applications Transaction Servers and TP Monitors Trends in Distributed Computing l Distributed Data Architectures n Increasing in frequency Ô Business units make decisions Ô Multiple database vendors n Yet, data is a corporate asset ! Ô Some data requires a “tightly consistent” model l N-tier Application Architectures n Can provide high-end scalability and fault tolerance Ô Multiple Application Servers providing same services l Both Require Support for Advanced Distributed Xact APIs, e.g.XA & DTC

71 What is Distributed Transaction Management (DTM) ? l A Transaction Management Framework n A framework consisting of 3 components Ô Transaction Monitor/Manager or Transaction Coordinator Ô Application Client Ô Resource Manager(s)/Dispenser(s) n A conceptual framework where several Resource Managers participate in doing a unit of work (transaction) n Transactional scope limits the failures occurring across execution domains n Transaction boundaries are demarcated with API n Transaction outcome and commitment policies are implemented within this framework n XA and DTC are two models that are currently available in industrial strength Ô Tuxedo/Encina/TopEnd/MTS-MSDTC/CICS

72 DTM Support Within ASE 12.0 l ASE Transaction Manager / Co-ordinator n ASE Transaction Manager understands different transaction types (Local, Internal, Subordinate and External) n The transaction states are validated through a state machine n Various Protocols supported by the external transactions (XA, ASTC, MSDTC) are driven through a protocol table n During recovery, prepared push-model external transactions are re-instantiated and Server is made available as soon as possible

73 Increased Query Execution Options l Begins re-architecting “top half” of the Optimizer & Execution Engine for extensibility of new join and access strategies l First Extension Will Support n Parallel and Serial Sort/Merge Joins n Sort/Merge Joins Between OMNI Proxy Tables or Between Local and OMNI Proxy Tables n Smart Transformation of WHERE Clause Predicates n Improved Selectivity Estimation for LIKE Predicates n Join transitive closure n Abstract Query Plans n Support for up to 50 tables in a join clause n Execute Immediate

74 Optimizer Enhancements in ASE 12.0 n Sort Merge Joins Ô Ordered joins provide clustered access to joining rows; result in less logical and physical I/Os. Ô Can exploit indexes that pre-order rows on joining columns or create work tables as required Ô Sort Merge Join Algorithm (4 distinct types supported) - Often Better Performance for DW/DSS Queries Than Nested Loop Join of ASE 11.x n LIKE Clause Ô New costing to improve selectivity and qualifying row estimates n Join Transitive Closure Ô Provides the optimizer with additional join paths and, hopefully, faster plans. Ô SARG transitive closure was added in ASE 11.5 n Predicate Transformation Ô Significant performance improvement in queries with limited access paths (i.e. very few possible SARGS/Joins/OR’s that can be used to qualify rows in a table) n Increase maximum number of non-RI tables per query Ô from 16 user tables and 12 work tables Ô to 50 user tables and 14 work tables

75 Sort Merge Join Example Part Clustered on p_partkey Partsupp Clustered on ps_partkey Lineitem Clustered on l_orderkey Part Clustered on p_partkey Partsupp Clustered on ps_partkey Lineitem Sorted on l_partkey select … from part, partsupp, lineitem where p_partkey = ps_partkey and ps_partkey = l_partkey and ps_orderkey = l_orderkey and p_type = ‘CD’ Unsorted Access to innermost table Sorted Access to innermost table

76 76 Managing Optimizer Changes After Upgrade l What happens to the installed base when the optimizer is enhanced? n Most find it better but some find it worse… l What could go wrong with the Optimizer? n Statistics may not apply to the data that is now in the table n The query plan used for a stored procedure may not be applicable to the query at hand n The buffer cache model and the actual buffer cache usage at run time could differ l One solution to all these problems would be to implement rules based optimization. However: n Rule based decisions could be sub-optimal as they require the developer to have a knowledge of the eventual data layout n Developers very often have very little knowledge of how to write efficient query plans and there is a considerable overhead in writing/testing them

77 77 Curing Unexpected Optimizer Behavior l What are the options for improving the optimizer and getting rid of unexpected behavior? n Implementing a better and more dynamic cost model n Implementing some form of extremely flexible rules based optimization n Allowing good query plans to be captured and re-used

78 78 Abstract Query Plans l An abstract query plan is a persistent, human readable description of a query plan, that’s associated to a SQL statement l It is not syntactically part of the statement l The description language is a relational algebra l Possible to specify only a partial plan, where the optimizer completes the plan generation l Stored in a system catalog sysqueryplans l Persistent across: n connections n Server versions (i.e. upgrades)

79 79 Where will AP’s be used? l Application providers don’t want to include vendor specific syntax in their queries l In general, users don’t want to modify a production application to solve an upgrade optimizer problem l Still, it’s possible to include them if so desired n Example: Ô select c1 from t1 where c2 = 0 plan ‘(I_scan () t1)’ l Abstract query plans are captured and reused: n set plan dump ‘new_plans_group’ on n set plan load ‘new_plans_group’

80 80 Directory Structure: ASE 12.0 l Top-level directory l Subdirectories for each component that include the following n Executable program for the component n Installation and configuration tools for the component n Display-related files needed by the component l Naming convention for subdirectories includes a component identifier and the software release version n Examples: Ô ASE-12_0/ (location of ASE files) Ô OCS-12_0/ (location of Open Client files) Ô jConnect-4_2/ (location of jConnect 4.2 files)

81 81 Overview of ASE 12.0 Directory Structure

82 82 Important ASE-12_0 Subdirectories l bin n Executable files for most server utilities l init n ASE installation log files l install n Install programs, RUNSERVER files, the error log l scripts n Optional database installation scripts l Note that some executables (such as isql and bcp) are located in the OSC-12_O/bin subdirectory

83 83 ASE 12.0 Requirements l Operating system levels for ASE 12.0: n Solaris 2.6 (2.7 for 64-bit) n HP/UX 11.0 (32 & 64 Bit) n AIX (32 & 64 Bit) n Intel NT 4.0 with Service Pack 4 n Digital Unix 4.0D l Minimum disk space n Standard installation: 678 MB (Full installation: 700 MB) n Custom installation: Depends on components chosen l New License Manager n SySAM - Sybase Software Asset Management to install l Upgrade from Versions n 11.0.x, 11.5, ,

84 84 Agenda l Why Migrate ? l How Migrate ? l Planning & Pre-Upgrade l Migration Steps l Post-Upgrade l ASE 12 l Summary

85 85 Key Lessons For A Successful Migration l Plan for Success n Plan the whole process n Read the available documentation to prepare yourself/team n Highlight and overcome potential problem areas by trailing migration approach and scripts on development/test systems prior to production roll-out l Execute the Plan n Follow the procedures and your migration plan n Be prepared with the recovery fallback option for your chosen strategy

86 86 SPS Migration Involvement l Plan & Execute Migration Services n Rapid Delivery of Migration Services n Risk minimisation through SPS experience of similar migrations n Product Knowledge to exploit new product features n Professional approach using documented Quality Standards & SAFE/EM™ methods l Assured delivery n Single source of technology, experience and methodology n ISO 9001 TickIT of both technology and staff © Copyright United Feature Syndicate 1997

87 87 Conclusion l Successful and painless migrations don’t just happen by accident, it requires you to: n Use a proven and structured migration approach n Plan and execute the whole migration task n Follow the documentation - it exists to help you n Please ask questions...

88 88 Sybase Contacts l Sybase Technical Support, North America: SYBASE ( to order product upgrade ) l Sybase Technical Support, UK: (01628) ( to order product upgrade) l Sybase Web Site l Comments to: Ian Annis Principal Consultant Sybase Professional Services (01628)

89 89 ‘Why’ and ‘How’ Migration Guide to ASE /12 Ian Annis Principal Consultant Sybase Professional Services (UK) March 2000 UKSUG Masterclass

Download ppt "1 ‘Why’ and ‘How’ Migration Guide to ASE 11.9.2/12 Ian Annis Principal Consultant Sybase Professional Services (UK) March 2000 UKSUG Masterclass."

Similar presentations

Ads by Google