What would you do if you knew? Teradata Database Nodes Preparing to Move from SLES 10 to SLES 11 B K April 2015

Transcription

1 What would you do if you knew? Teradata Database Nodes Preparing to Move from SLES 10 to SLES 11 B K April 2015

2 The product or products described in this book are licensed products of Teradata Corporation or its affiliates. Teradata, Active Data Warehousing, Active Enterprise Intelligence, Applications-Within, Aprimo Marketing Studio, Aster, BYNET, Claraview, DecisionCast, Gridscale, MyCommerce, QueryGrid, SQL-MapReduce, Teradata Decision Experts, "Teradata Labs" logo, Teradata ServiceConnect, Teradata Source Experts, WebAnalyst, and Xkoto are trademarks or registered trademarks of Teradata Corporation or its affiliates in the United States and other countries. Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc. AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc. Apache, Apache Avro, Apache Hadoop, Apache Hive, Hadoop, and the yellow elephant logo are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. Apple, Mac, and OS X all are registered trademarks of Apple Inc. Axeda is a registered trademark of Axeda Corporation. Axeda Agents, Axeda Applications, Axeda Policy Manager, Axeda Enterprise, Axeda Access, Axeda Software Management, Axeda Service, Axeda ServiceLink, and Firewall-Friendly are trademarks and Maximum Results and Maximum Support are servicemarks of Axeda Corporation. Data Domain, EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation. GoldenGate is a trademark of Oracle. Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company. Hortonworks, the Hortonworks logo and other Hortonworks trademarks are trademarks of Hortonworks Inc. in the United States and other countries. Intel, Pentium, and XEON are registered trademarks of Intel Corporation. IBM, CICS, RACF, Tivoli, and z/os are registered trademarks of International Business Machines Corporation. Linux is a registered trademark of Linus Torvalds. LSI is a registered trademark of LSI Corporation. Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United States and other countries. NetVault is a trademark or registered trademark of Dell Inc. in the United States and/or other countries. Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries. Oracle, Java, and Solaris are registered trademarks of Oracle and/or its affiliates. QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation. Quantum and the Quantum logo are trademarks of Quantum Corporation, registered in the U.S.A. and other countries. Red Hat is a trademark of Red Hat, Inc., registered in the U.S. and other countries. Used under license. SAP is the trademark or registered trademark of SAP AG in Germany and in several other countries. SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc. SPARC is a registered trademark of SPARC International, Inc. Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and other countries. Unicode is a registered trademark of Unicode, Inc. in the United States and other countries. UNIX is a registered trademark of The Open Group in the United States and other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. The information contained in this document is provided on an "as-is" basis, without warranty of any kind, either express or implied, including the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply to you. In no event will Teradata Corporation be liable for any indirect, direct, special, incidental, or consequential damages, including lost profits or lost savings, even if expressly advised of the possibility of such damages. The information contained in this document may contain references or cross-references to features, functions, products, or services that are not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features, functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions, products, or services available in your country. Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any time without notice. To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please teradata-books@lists.teradata.com Any comments or materials (collectively referred to as "Feedback") sent to Teradata Corporation will be deemed non-confidential. Teradata Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform, create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services incorporating Feedback. Copyright by Teradata. All Rights Reserved.

3 Table of Contents Preface...7 Purpose... 7 Audience... 7 Revision History... 7 Additional Information...8 Related Documents... 8 Related Links...9 Product Safety Information...9 Chapter 1: Overview of the Linux SLES 11 Upgrade SLES 10 to SLES 11 Upgrade Basics System Requirements for SLES Hardware Requirements...11 Software Requirements...12 Workload Pre-Migration Requirements...12 Responsibilities during the Upgrade...13 Upgrade Planning Timeline Upgrade Operation Timeline Chapter 2: Upgrade Preparation...17 Differences between Priority Scheduling in SLES 10 and SLES Priority Scheduling in SLES Priority Scheduling in SLES Understanding the Workload Migration Process Preparing Workloads for Migration Migration without Workload Preparation Other Workload Migration Considerations Workload Migration from TASM-Licensed Systems...20 Default Results of Workload Migration from TASM-Licensed Systems Pre-Migration Workload Configuration Options for TASM-to-IWM Upgrades Pre-Migration Workload Configuration Options for TASM-to-TASM Upgrades...22 Preparing to Move from SLES 10 to SLES 11 3

4 Table of Contents Workload Migration from PSF-Licensed Systems Default Results of Workload Migration from PSF-Licensed Systems Pre-Migration Workload Configuration Options for PSF-to-IWM Upgrades Pre-Migration Workload Configuration Options for PSF-to-TASM Upgrades Priority Definition Set Conversion Verifying Priority Definition Set Configurations...25 Creating Rule Sets from Priority Definition Sets Workload Migration from Appliance-Licensed Systems Default Tactical Workload Exception Default Limit and Reserve Values Determining Workloads for the SLG Tier SLG Workload Criteria SLG Workload Identification Process Overview...33 SLG Workload Identification Process Modifications Example: SLG Workload Determination SLG Workload Allocation Percentage Considerations...36 Calculating SLG Workload Allocation Percentage Backing Up the Database...37 Chapter 3: Using the Pre-Migration Tool...39 Downloading the Pre-Migration Tool Running the Pre-Migration Tool...39 Connecting to the Database Selecting a Rule Set for Pre-Migration...40 Setting Workload Type...42 Setting Timeshare Workload Access Level Setting SLG Workload Allocation Percentage Managing Remaining Rulesets...45 Chapter 4: Upgrade Paths...47 Upgrade Compared to Migration...47 General Upgrade Considerations License- and Platform-Dependent Upgrade Considerations Upgrade Scenarios...49 Upgrading a SLES 10 TASM-Licensed System to SLES Preparing to Move from SLES 10 to SLES 11

5 Table of Contents Upgrading a SLES 10 PSF-Licensed System to SLES Upgrading a SLES 10 Appliance-Licensed System to SLES Migration Scenarios Migrating from a SLES10 TASM-Licensed System to a SLES 11 System Migrating from a SLES 10 PSF-Licensed System to a SLES 11 System Migrating from a SLES 10 Appliance-Licensed System to a SLES 11 System Chapter 5: After the Upgrade...57 Using the Workload Designer Portlet to Refine Migration Results...57 License-Independent Post-Upgrade Configuration Configuration after Upgrading from a SLES 10 Appliance- or PSF-Licensed System...57 Configuration after Upgrading to a SLES 11 TASM-Licensed System Distributing Workload Resources...58 SLES 11 Adjusting Tactical Workload Exceptions Enabling Timeshare Decay...62 Setting Limits and Reserves Setting State-Specific Values for Throttles...62 Deleting Throttles...63 Allocating Workload Resources in SLG Tiers...63 SLES 11 Adding Virtual Partitions Preparing to Move from SLES 10 to SLES 11 5

6 Table of Contents 6 Preparing to Move from SLES 10 to SLES 11

7 Preface Purpose This guide is intended to familiarize customers and Teradata support staff with the process of upgrading a Teradata system from SLES 10 to SLES 11, with a focus on preparing for workload migration. It is intended as a supplement and not an alternative to the established Change Control process. Audience The audience for this guide includes, but is not limited to, the following: Customer system administrators and facilities personnel Teradata installation, service, and support personnel Revision History Date Description April 2015 Modified content on SLG workload allocation percentage to reflect new default value of 5% and updated minimum-value recommendation, as well as eliminate references to overall tier percentage limit no longer imposed by the Pre-Migration Tool. Added topic "Priority Definition Set Conversion" to centralize background information on preparing PD sets for processing by the Pre-Migration Tool, and honed related task topics accordingly. Updated threshold values for the default tactical workload exception. Deleted table illustrating SLG allocation percentage calculation. Added topics "General Upgrade Considerations" and "License- and Platform-Dependent Upgrade Considerations" to centralize information common across upgrade and migration scenarios, and honed related task topics accordingly. December 2014 Initial release. Preparing to Move from SLES 10 to SLES 11 7

8 Preface Additional Information Additional Information Related Documents Documents are located at Teradata Service Documentation Library. Title Teradata Viewpoint User Guide Describes the Teradata Viewpoint portal, portlets, and system administration features, including the Workload Designer portlet, which is used after operating system upgrade to review and modify as necessary the results of workload migration. Teradata Database Node Software Upgrade Guide: Overview and Preparation Outlines the Teradata Database upgrade process in general, and describes how Teradata customers and Teradata Customer Services associates collaborate to prepare for and plan a Teradata Database upgrade. Teradata Database Node Software Migration Guide Outlines the steps required for migrating an entire Teradata Database system, including access rights. Teradata Manager User Guide Provides information on Teradata Manager, a Teradata Tools and Utilities product, including the Priority Scheduler component, which was used with versions of Teradata Database earlier than to define Priority Definition (PD) set components and configure the sets themselves. Utilities, Volume 2, L - Z Describes utility programs that support Teradata Database, including Priority Scheduler, which was used with versions of Teradata Database earlier than to define PD set components and configure the sets themselves. Teradata Workload Analyzer User Guide Provides information on Teradata Workload Analyzer, a Teradata Tools and Utilities product, which was used with versions of Teradata Database earlier than to convert PD sets to rule sets containing workloads. Publication ID B B B (15.0) B (14.10) B (14.0) B (13.10) B (13.0) B (12.0) B B B Preparing to Move from SLES 10 to SLES 11

9 Preface Product Safety Information Related Links URL Description Secure site for accessing Orange Books, technical alerts, and knowledge repositories; viewing and joining forums; and downloading software packages. External site for published Teradata customer documentation. Product Safety Information This document may contain information addressing product safety practices related to data or property damage, identified by the word Notice. A notice indicates a situation which, if not avoided, could result in damage to property, such as equipment or data, but not related to personal injury. Example Notice: Improper use of the Reconfiguration utility can result in data loss. Preparing to Move from SLES 10 to SLES 11 9

10 Preface Product Safety Information 10 Preparing to Move from SLES 10 to SLES 11

11 CHAPTER 1 Overview of the Linux SLES 11 Upgrade SLES 10 to SLES 11 Upgrade Basics The path for transitioning from SLES 10 to SLES 11 depends on hardware. If your existing hardware supports SLES 11, you can upgrade the operating system in place without migrating data. If you have purchased different hardware that supports SLES 11, you must migrate data from your SLES 10 system to your SLES 11 system. In either case, the required steps for transitioning a Teradata system vary depending on existing database and operating system versions. Pre- and post-upgrade workload-management licensing, which may be dictated by existing hardware, also influence the following aspects of the upgrade: Means of migrating workloads Tasks to prepare workloads for migration Workload-management options and required configuration post upgrade Regardless of upgrade and workload-migration paths, transitioning from SLES 10 to SLES 11 has implications for workload priority scheduling in Teradata Database, because resource allocation is handled differently on the two operating systems. In addition, upgrading from SLES 10 to SLES 11 may result in CPU overhead of 6-8%. Upgrading an operating system is an involved process that occurs in multiple phases beginning at least 90 days before and ending a day or two after the upgrade itself. To initiate the upgrade process, obtain a Change Control number from Teradata Customer Services. System Requirements for SLES 11 Any hardware or software upgrades necessary to meet the requirements for upgrading from SLES 10 to SLES 11 should be isolated from and performed well in advance of upgrading the operating system. Doing so provides for monitoring the performance characteristics on the new platform so that you can fine tune priority-scheduling settings prior to operating system upgrade. Hardware Requirements Teradata Data Mart 560P Teradata Data Mart Appliance 670 Preparing to Move from SLES 10 to SLES 11 11

12 Chapter 1 Overview of the Linux SLES 11 Upgrade System Requirements for SLES 11 Teradata Extreme Data Appliance 1650 and above Teradata Data Warehouse Appliance 2650 and above Teradata Enterprise Data Warehouse 5600 and above Teradata Active Enterprise Data Warehouse 6650 and above Software Requirements Teradata Database version based on hardware version, as outlined in the following table Hardware Version 560P, 670, 1650, 2650, 4600, 5600, 5650, 6650, 6650-SSD, 6680, 6690 Minimum Teradata Database Version , , If upgrading from SLES 10 systems licensed for Priority Scheduling Facility (PSF), the following unique requirements for database version secondary to workload migration scenario apply. If you have in-depth understanding of Priority Definition (PD) set configuration and want to use the Workload Management Pre-Migration Tool (known as the Pre- Migration Tool) to refine the otherwise automatic results of the migrating workload priority-scheduling settings, you must use Teradata Workload Analyzer (TWA) to create rule sets from PD sets while still running Teradata Database version 13.0 or earlier and before upgrading the operating system. If you intend to use the Pre-Migration Tool to migrate workloads based on userdefined SLES 10 performance groups, you must be running Teradata Database version or later or at the time of operating system upgrade to ensure that workloads based on default performance groups are assigned the expected timeshare access level in SLES 11. Teradata Viewpoint version or later 3 GB or more free space on the Teradata file system Workload Pre-Migration Requirements Teradata Database version or later Teradata Tools and Utilities version or later Teradata Call-Level Interface version 2 (CLIv2) release or later TDICU or later TeraGSS or later 12 Preparing to Move from SLES 10 to SLES 11

13 Responsibilities during the Upgrade Chapter 1 Overview of the Linux SLES 11 Upgrade Responsibilities during the Upgrade Preparation and planning are key to a successful operating system upgrade. Consult with Teradata Customer Services well in advance to establish an approach for performing the upgrade, including roles and responsibilities. Upgrade Planning Timeline Although each situation is unique, the general milestones in planning an upgrade from SLES 10 to SLES 11 are outlined in the following table. Milestone Timing Tasks Professional Services Upgrade Readiness Assessment Initial Risk Mitigation Customer Support Core Pre-Upgrade Assessment Report and Final Risk Mitigation Starting at least 90 days before targeted upgrade date and finishing within 2 days Starting at least 60 days before and finishing at least 30 days before targeted upgrade date Starting at least 30 days before and finishing at least 10 days before targeted upgrade date Starting at least 10 days before and finishing by targeted upgrade date Ascertain upgrade type and focus Identify affected software (both Teradata and third-party) Determine software and hardware procurement requirements Detail workload management migration steps based on pre- and post-upgrade environment including licensing Itemize potential risks Determine required level of engagement with Professional Services Identify reference documents relevant to the upgrade scenario Identify any existing custom security hardening measures that the customer wants to also implement on SLES 11 Provide the customer with the Pre-Migration Tool, if applicable based on upgrade scenario Collect system data and analyze system status Communicate identified issues to site team Confirm whether customer will be premigrating workloads Present recommendations Upgrade Operation Timeline The following table outlines the general tasks involved when performing a SLES 10 to SLES 11 upgrade operation. The time required to complete the tasks depends on a number of factors including amount of third-party software that must be installed on the SLES 11 system post upgrade, and the number of rule sets for which workloads are being migrated. Preparing to Move from SLES 10 to SLES 11 13

14 Chapter 1 Overview of the Linux SLES 11 Upgrade Upgrade Operation Timeline Likewise, the type and degree of manual intervention required may vary based on environment. The upgrade operation is led by Teradata Customer Services staff, who engage the customer as needed. Activity Estimated Time Frame Tasks Upgrade preparation 1 to 2 hours Confirm that the customer has completed workload pre-migration activities, if applicable Ensure that all users have exited the system Stop system processes Install all required software at required versions, including the Parallel Upgrade Tool (PUT) used to facilitate the upgrade process Verify availability of all required licenses and software patches Identify configuration settings that require modification prior to the upgrade Resolve all system errors and warnings Back up the TDWM database Manually copy files not automatically moved as part of the upgrade process, such as third-party software configuration files and user-defined function (UDF) source code, if applicable Identify any existing custom security hardening measures that the customer wants to also implement on SLES 11 PUT operation 2 to 4 hours Confirm alternate boot environment health and alert absence Use PUT to perform certain validation and operational steps including acquisition and distribution of software installation packages Manually intervene as required, such as for password validation, file backup, and custom configuration setting restoration Downtime 1 to 2 hours Use PUT to shut down and restart database and nodes, perform required verification operations, install Teradata and Linux software, verify links in new environment, and related activities Validate ethernet device renumbering Install required third-party software Restore files and configuration settings, as necessary Validate various system parameters Execute program to convert rule sets for workload-configuration migration Confirm successful integration with Teradata Viewpoint 14 Preparing to Move from SLES 10 to SLES 11

15 Chapter 1 Overview of the Linux SLES 11 Upgrade Upgrade Operation Timeline Activity Estimated Time Frame Tasks Verify that custom security hardening measures are implemented in the new environment, if applicable Post-upgrade work 1 hour Install hardware-specific BIOS-access software Verify that the UDF source code is restored to original directories, if applicable Execute PUT utility log collection function to gather information about the upgrade process Preparing to Move from SLES 10 to SLES 11 15

16 Chapter 1 Overview of the Linux SLES 11 Upgrade Upgrade Operation Timeline 16 Preparing to Move from SLES 10 to SLES 11

17 CHAPTER 2 Upgrade Preparation Differences between Priority Scheduling in SLES 10 and SLES 11 Teradata Database manages priority scheduling differently in SLES 10 and SLES 11. Note: The following descriptions are very basic and designed to highlight the main differences in priority scheduling between SLES 10 and SLES 11. For additional detail on priority scheduling and other aspects of workload management in SLES 11, see Teradata Viewpoint User Guide. Priority Scheduling in SLES 10 In SLES 10, Teradata Database uses resource partitions, performance groups, performance periods, and allocation groups to schedule priority. At the highest level, the user can define up to four resource partitions and assigns a weight value to each. This value determines the proportion of resources available to a partition relative to the other partitions. In addition, the user associates each partition with at least one performance group, which, in turn, is associated with between one and eight performance periods, and with at least one allocation group. User queries run in allocation groups based on a shared enforcement priority (EP) of either Tactical, Priority, Normal, or Background. The combination of resource partition and allocation group parameters, acting through their common performance groups, determines the precise priorities of workloads running on Teradata Database. The following figure illustrates priority scheduling in SLES 10. Preparing to Move from SLES 10 to SLES 11 17

18 Chapter 2 Upgrade Preparation Differences between Priority Scheduling in SLES 10 and SLES 11 Priority Scheduling in SLES 11 In SLES 11, Teradata Database takes a tiered approach to priority scheduling. By default, a single virtual partition is defined at the top level, with up to ten virtual partitions allowed (depending on licensing). Each partition includes one Tactical tier and one Timeshare tier, by default, and (again, depending on licensing) one optional Service Level Goal (SLG) tier, with up to five SLG tiers allowed within a virtual partition. Tiers, in turn, contain workloads. Like an allocation group, a workload represents a group of queries with common characteristics. But unlike allocation groups in SLES 10, workloads in SLES 11 are used directly to determine scheduling priority. At the broadest level, tier assignment determines priority, with workloads in the Tactical tier taking highest priority, followed by workloads in the SLG tier 1, followed by workloads in SLG tiers 2 through 5 (in order), followed by workloads in the Timeshare tier. At a finer level, a user-configurable allocation percentage for each workload in the SLG tier determines priority within that tier. Likewise, a user-configurable access level for each workload in the Timeshare tier determines priority within that tier as either Top, High, Medium, or Low. In 18 Preparing to Move from SLES 10 to SLES 11

19 addition to user-specified workloads, the Tactical and SLG tiers also contain a default Remaining workload to ensure that some resources always flow to tiers below. The following figure illustrates priority scheduling in SLES 11. Chapter 2 Upgrade Preparation Understanding the Workload Migration Process Understanding the Workload Migration Process Because of the different approaches taken to priority scheduling in SLES 10 and SLES 11, the database that houses workloads must undergo conversion as part of the operating system upgrade. Although some aspects of the required conversion occur automatically when the applicable script is run during the upgrade process, a certain degree of manual intervention is required to emulate SLES 10 workload-scheduling behavior in SLES 11. If your upgrade scenario allows, use the Pre-Migration Tool to facilitate this process before transitioning to SLES 11. Note: Using the Pre-Migration Tool increases the likelihood of emulating existing priorityscheduling behavior upon operating system upgrade. The tool cannot be used after upgrade. Preparing Workloads for Migration Use the Pre-Migration Tool to: Control which rule sets and, therefore, workloads to migrate. When you select rule sets for migration, only those rule sets and their corresponding workloads are migrated. Note: The ability to control which rule sets are migrated applies only to the following versions of Teradata Database: 13.10; 14.0 lower than ; and lower than Otherwise, all SLES 10 rule sets and workloads are migrated, regardless of whether the tool is used. Distribute workloads among tiers. Change allocation percentages for SLG workloads. Preparing to Move from SLES 10 to SLES 11 19

20 Chapter 2 Upgrade Preparation Workload Migration from TASM-Licensed Systems Note: SLG tiers are available only with Teradata Active System Management (TASM) licensing. Teradata Integrated Workload Management (IWM) licensing provides the Tactical and Timeshare tiers only. Adjust access levels for timeshare workloads. The Pre-Migration Tool writes output directives into a pre-migration table called tdwm.premigrate. When the TDWMDIP program is run after upgrading the operating system, the SLES 10 Teradata Workload Manager (TDWM) rule sets, including corresponding workloads, are migrated to SLES 11 based on the directives within the tdwm.premigrate table. Migration without Workload Preparation If you do not use the Pre-Migration Tool or do not implement any changes when using the tool, the tdwm.premigrate table remains empty of directives, and workload migration defaults to an automated process. In such cases, a higher degree of post-upgrade configuration may be required to emulate existing priority-scheduling behavior, as compared to the post-upgrade configuration necessary when using the Pre-Migration Tool. Note: In the absence of workloads, as is the case with SLES 10 appliance-licensed systems, you cannot use the Pre-Migration Tool when upgrading to SLES 11. In such scenarios, performance groups are migrated in a default manner. Use the Workload Designer portlet in Teradata Viewpoint to review and adjust as necessary workload-management settings to meet priority-scheduling goals. Other Workload Migration Considerations The migration process yields a pre-configured exception for tactical workloads, regardless of whether the Pre-Migration Tool is used. The process also sets pre-configured system-wide limit and reserve values for the Always planned environment. You cannot change the exception or the limit and reserve values before workload migration. However, with IWM licensing, you can subsequently use the Workload Designer Portlet in Teradata Viewpoint to change the reserve values or exception; TASM licensing provides for changing values for these parameters as well as limit values. Regardless of whether you use the Pre-Migration Tool to prepare workloads for the operating system upgrade, the results of the migration process vary based on the type of system from which you are upgrading and the workload-management licensing you have secured for use with SLES 11. Likewise, the workload-management options available post upgrade vary based on licensing. Workload Migration from TASM-Licensed Systems As part of upgrading to SLES 11, priority-scheduling settings for workloads are migrated from the SLES 10 system. When upgrading from a TASM-licensed SLES 10 system, you can use the Pre-Migration Tool to refine the otherwise automatic results of the migrating workload priority-scheduling settings. Use the tool before running the TDWMDIP program as part of the transition process to increase the likelihood of emulating existing priorityscheduling behavior upon upgrade to SLES 11. Regardless of whether you use the tool, use the Workload Designer portlet in Teradata Viewpoint post upgrade to review and adjust workload-management settings as necessary. 20 Preparing to Move from SLES 10 to SLES 11

21 Default Results of Workload Migration from TASM-Licensed Systems When used alone, the TDWMDIP program yields the following results related to workload migration, which are otherwise subject to modification by using the Pre-Migration Tool. All SLES 10 rule sets and workloads are migrated. Note: This result is subject to modification by using the tool only with the following Teradata Database versions: 13.10; 14.0 earlier than ; and earlier than When you use the tool to select rule sets for migration from any of these database versions, only those rule sets and their corresponding workloads are migrated. For all other Teradata Database versions that support using the tool, all SLES 10 rule sets are migrated regardless of selection. All SLES 10 workloads associated with allocation groups that are assigned the Tactical enforcement priority and are configured to use single or few AMPs are converted to SLES 11 tactical workloads, which automatically designates them for expedited processing. All SLES 10 workloads associated with allocation groups that are assigned the Tactical enforcement priority and are configured to use all AMPs or that have no AMP designation set as part of their classification criteria are assigned to SLG tier 1 and allocated 5% of tier resources. Note: SLG tiers are available only with TASM licensing. All other SLES 10 workloads are converted to SLES 11 timeshare workloads and assigned access levels based the relative weight of the corresponding SLES 10 allocation groups, as shown in the following table. SLES 10 Allocation Group Relative Weight > 10% Top > 5% to 10% High > 2% to 5% Medium 0 to 2% Low Chapter 2 Upgrade Preparation Workload Migration from TASM-Licensed Systems SLES 11 Access Level Access level affects the volume of resources provided to workload queries at a ratio of 2:1. Queries in a workload that is assigned the Top access level receive eight times the volume of resources as queries in a workload that is assigned the Low access level, four times the volume of resources as queries in a workload that is assigned the Medium access level, and two times the volume of resources as queries in a workload that is assigned the High access level. The TDWMDIP program yields the following additional results related to workload migration, which are not subject to modification by using the Pre-Migration Tool. All workloads are placed in the single, default Standard virtual partition. The rule set that was active at the time of migration is automatically activated. Pre-Migration Workload Configuration Options for TASM-to-IWM Upgrades If when using the Pre-Migration Tool, you indicate that the SLES 11 system is not licensed for TASM, you can use the tool to perform the following workload-configuration activities, which are authorized with IWM licensing. Reclassify automatically designated tactical workloads as timeshare workloads, if they are not reserved for highly critical queries with response-time requirements of 1 second or less, and, therefore, should not be expedited. Preparing to Move from SLES 10 to SLES 11 21

22 Chapter 2 Upgrade Preparation Workload Migration from PSF-Licensed Systems Reclassify automatically designated timeshare workloads as tactical workloads, if they are reserved for highly critical queries with response-time requirements of 1 second or less, and, therefore, should be expedited. Adjust access levels for timeshare workloads to meet priority-scheduling goals. Pre-Migration Workload Configuration Options for TASM-to-TASM Upgrades If when using the Pre-Migration Tool, you indicate that the SLES 11 system is licensed for TASM, you can perform all the IWM-specific activities as well as the following activities, which are authorized only with TASM licensing. Reclassify automatically designated SLG workloads to other tiers. The SLG tier should be reserved for workloads that are of secondary importance to tactical workloads but are associated with a short service level goal or service level expectation; require a short response time due to business importance; and do not generally consume a significant amount of CPU resources. If any workloads automatically assigned to the SLG tier do not meet this criteria, use the Pre-Migration Tool to reclassify them as tactical or timeshare workloads, as appropriate. Reassign automatically designated tactical or timeshare workloads that meet the criteria for SLG workloads to SLG tier 1. If any automatically designated tactical workloads are not reserved for highly critical queries with response-time requirements of 1 second or less but do meet the criteria for SLG tier assignment, use the Pre-Migration Tool to reclassify them as SLG workloads. Likewise, if any automatically designated timeshare workloads meet the criteria for SLG tier assignment, use the tool to reclassify them accordingly. Change allocation percentages for SLG workloads. Without pre-migration intervention, each workload assigned to the SLG tier is by default allocated 5% of tier resources. Use the Pre-Migration Tool to change these values as necessary. Note: After upgrading to SLES 11 and monitoring the outcome of your original settings, you can adjust SLG workload allocation percentages using the Workload Designer portlet in Teradata Viewpoint. Workload Migration from PSF-Licensed Systems As part of upgrading to SLES 11, priority-scheduling settings for workloads are migrated from the SLES 10 system. If you have in-depth understanding of PD set configuration, you may want to use the Pre-Migration Tool to refine the otherwise automatic results of this process. Transitioning from SLES 10 PSF-licensed systems carries the following unique requirements related to workload migration. To use the Pre-Migration Tool, you must first convert PD sets to rule sets while still running Teradata Database 13.0 or earlier. Note: The Pre-Migration Tool provides direct access to the Teradata utilities used to review PD set configurations and convert PD sets to rule sets. Additional related information can be found in the following Orange Books: 22 Preparing to Move from SLES 10 to SLES 11

23 Chapter 2 Upgrade Preparation Workload Migration from PSF-Licensed Systems Using Teradata s Priority Scheduler, A02 Teradata Workload Analyzer, A Teradata Active System Management Component, Best practices and Recommendations, A02 Teradata Active System Management, Usage Considerations & Best Practices, A01 If you are migrating workloads based on user-defined SLES 10 performance groups, you must be running Teradata Database version or later or at the time of operating system upgrade to ensure that workloads based on default performance groups are assigned the expected timeshare access level in SLES 11. Regardless of whether you use the tool, use the Workload Designer portlet in Teradata Viewpoint post upgrade to review and adjust workload-management settings as necessary. Default Results of Workload Migration from PSF-Licensed Systems When used alone, the TDWMDIP program yields the following results related to workload migration, which are otherwise subject to modification by using the Pre-Migration Tool. All SLES 10 rule sets and workloads are migrated. Note: This result is subject to modification by using the tool only with the following Teradata Database versions: 13.10; 14.0 earlier than ; and earlier than When you use the tool to select rule sets for migration from any of these database versions, only those rule sets and their corresponding workloads are migrated. For all other Teradata Database versions that support using the tool, all SLES 10 rule sets are migrated regardless of selection. All performance groups are converted to timeshare workloads. The workloads created based on the default performance groups are automatically assigned timeshare access levels based on account string as shown in the following table. SLES 10 Account String $R* $H* $M* $L* SLES 11 Access Level Top High Medium The workloads created based on expedited user-defined performance groups are assigned the Top access level. The workloads created based on all other user-defined performance groups are assigned access level values based on SLES 10 allocation group relative weight as shown in the following table. SLES 10 Allocation Group Relative Weight Low > 10% Top > 5% to 10% High > 2% to 5% Medium 0 to 2% Low SLES 11 Access Level Access level affects the volume of resources provided to workload queries at a ratio of 2:1. Queries in a workload that is assigned the Top access level receive eight times the volume Preparing to Move from SLES 10 to SLES 11 23

24 Chapter 2 Upgrade Preparation Workload Migration from PSF-Licensed Systems of resources as queries in a workload that is assigned the Low access level, four times the volume of resources as queries in a workload that is assigned the Medium access level, and two times the volume of resources as queries in a workload that is assigned the High access level. Use the Pre-Migration Tool to change the workload access level values as necessary. Note: For ease of identification, SLES 11 workloads created from SLES 10 user-defined performance groups are named and assigned an account string that reflects the performance group name. The SLES 11 workloads created from the SLES 10 default performance groups are named as shown in the following table. SLES 10 Performance Group $R* $H* $M* $L* SLES 11 Timeshare Workload Name T-WD H-WD M-WD L-WD You cannot change workload names using the Pre-Migration Tool, but you can subsequently change them using the Workload Designer portlet in Teradata Viewpoint. Only settings in the System GDO are migrated. The TDWMDIP program yields the following additional results related to workload migration, which are not subject to modification by using the Pre-Migration Tool. All workloads are placed in the single, default Standard virtual partition. The rule set that was active at the time of migration is automatically activated. Query milestones are lost. However, you can achieve similar results following upgrade to SLES 11 by using the Workload Designer portlet in Teradata Viewpoint to enable the Decay option for timeshare workloads. Two throttles to limit system concurrence are provided: GeneralQuery (with a limit of 52) and OneSecondQuery (with a limit of 30). You can use the Workload Designer portlet post upgrade to change or delete these throttles, as required. Allocation group and resource partition CPU limits are lost. Ability to swap night/day setup is lost. Pre-Migration Workload Configuration Options for PSF-to-IWM Upgrades If when using the Pre-Migration Tool, you indicate that the SLES 11 system is not licensed for TASM, you can use the tool to perform the following workload-configuration activities, which are authorized with IWM licensing. Reclassify automatically designated timeshare workloads as tactical workloads, if they are reserved for highly critical queries with response-time requirements of 1 second or less, and, therefore, should be expedited. Adjust access levels for timeshare workloads to meet priority-scheduling goals. Pre-Migration Workload Configuration Options for PSF-to-TASM Upgrades If when using the Pre-Migration Tool, you indicate that the SLES 11 system is licensed for TASM, you can perform all the IWM-specific activities as well as the following activities, which are authorized only with TASM licensing. 24 Preparing to Move from SLES 10 to SLES 11

25 Chapter 2 Upgrade Preparation Workload Migration from PSF-Licensed Systems Reassign automatically designated timeshare workloads to SLG tier 1. If any automatically designated timeshare workloads meet the criteria for SLG tier assignment, use the tool to reclassify them accordingly. The SLG tier should be reserved for workloads that are of secondary importance to tactical workloads but are associated with a short service level goal or service level expectation; require a short response time due to business importance; and do not generally consume a significant amount of CPU resources. Change allocation percentages for SLG workloads. Without pre-migration intervention, each workload assigned to the SLG tier is by default allocated 5% of tier resources. Use the Pre-Migration Tool to change these values as necessary. Note: After upgrading to SLES 11 and monitoring the outcome of your original settings, you can adjust SLG workload allocation percentages using the Workload Designer portlet in Teradata Viewpoint. Priority Definition Set Conversion If you have an in-depth understanding of PD set configuration, you may want to use the Pre- Migration Tool to refine the otherwise automatic results of migrating priority-scheduling settings when upgrading a PSF-licensed SLES 10 system to SLES 11. The Pre-Migration Tool processes workloads based on rule sets. Because they are not used in PSF systems, you must create rule sets from PD sets if you want to use the tool. The resulting rule sets contain workloads based on the allocation groups in PD sets. Note: You must create rule sets from PD sets while still running Teradata Database version 13.0 or earlier. Before creating rule sets, verify that your PD sets are configured in a manner that best meets your priority-scheduling goals. For detailed information on the components and configuration of PD sets, see Teradata Manager User Guide (B ) and Utilities, Volume 2, L - Z (B ). For detailed information on creating rule sets from PD sets, including mapping considerations, see Teradata Workload Analyzer User Guide (B ). Additional related information can be found in the following Orange Books: Using Teradata s Priority Scheduler, A02 Teradata Workload Analyzer, A Teradata Active System Management Component, Best practices and Recommendations, A02 Teradata Active System Management, Usage Considerations & Best Practices, A01 The Pre-Migration Tool provides direct access to the Teradata utilities used to verify PD set configuration and create rule sets from PD sets. Verifying Priority Definition Set Configurations The following procedure outlines the main steps of verifying PD set configuration when the process is initiated from the Pre-Migration Tool. Preparing to Move from SLES 10 to SLES 11 25

26 Chapter 2 Upgrade Preparation Workload Migration from PSF-Licensed Systems 1 From the Pre-Migration Tool menu bar, click Migration > Priority Scheduler Administrator. The Priority Scheduler Administrator (PSA) window appears. 2 Verify the configuration for each PD set from which you want to create a rule set for processing through the Pre-Migration Tool. Related Topics Downloading the Pre-Migration Tool, on page 39 Connecting to the Database, on page 40 Creating Rule Sets from Priority Definition Sets The following procedure outlines the main steps of creating rule sets from PD sets when the process is initiated from the Pre-Migration Tool. 1 From the Pre-Migration Tool menu bar, click Migration > Migrate PSF Setting. 2 In the Teradata Workload Analyzer menu bar, click Analysis > Convert PDSets to Workloads. The Select PDSet(s) dialog box appears. 3 Under Available PDSet(s), click the listing for the PD set to be converted, and verify the following items. The entire row is selected rather than just the cell containing the PD set name. Shading indicates the scope of selection. An OpEnv is selected. Note: Operating environment corresponds to performance period. Teradata Workload Analyzer selects operating environments that most closely match the performance periods associated with PD sets. If the default selection is not accurate, select the correct option from the list or click Define Periods to create the required operating environment. Only one PD set is associated with the Default period. 4 [Optional] Specify the scope for retrieval of active performance groups. a b c Click DBQL Inputs... In the Data Collection Interval dialog box, change the values for the Date Range, the Time Window, or both. Click OK. 5 Click Proceed. The Existing PSA Setting tab appears. 26 Preparing to Move from SLES 10 to SLES 11

27 Chapter 2 Upgrade Preparation Workload Migration from PSF-Licensed Systems 6 Review the information for each unique combination of resource partition and operating environment. Option To display information for a different resource partition To display information for a different performance period for the current resource partition To deactivate a performance group To display allocation group weight information Description Select the applicable option from the RP_Name list. Select the applicable option from the OpEnv list. Clear the check mark in the Active check box. The check box label changes to Inactive. Click the AG Weights button. After reviewing the information in the Existing Priority Scheduler Weights dialog box, click Close. 7 Under Convert by, click Performance Group. Note: Because it provides for programmatic association of performance periods with operating environments, conversion by performance group is recommended over conversion by account. 8 Click Convert to begin the conversion process. The Migrated TASM Settings tab appears. Preparing to Move from SLES 10 to SLES 11 27

28 Chapter 2 Upgrade Preparation Workload Migration from PSF-Licensed Systems 9 If the enforcement priority assigned to an allocation group is inaccurate, select the preferred option from the Enforcement Priority list. 10 Click Simplified Structure. This option maps the PD set such that the Default resource partition is not used for requests even if the original PD set did so. Instead, a new resource partition is created for the work from the Default resource partition, reserving the Default resource partition for system work. A Tactical partition is created for short-running, high-priority tactical queries, and the remaining work is mapped to the Standard partition. 11 Click Continue. The system creates a rule set based on the PD set, with candidate workloads being created based on the allocation groups in the PD set. Note: The conversion process usually creates one workload for each account found. However, if a query milestone is associated with an allocation group, two workloads result. Such workloads are named to reflect the account name appended with different numerals. For ease of identification, you can rename these as well as any other workloads in the Standard partition, each of which is also named based on the account associated with the corresponding allocation group. To do so, right-click the workload listing, select Rename, type the preferred Name and, optionally, Description in the displayed dialog box, and click OK. 12 Under Parameters, click View CPU Distribution, and review the information for each operating environment. 28 Preparing to Move from SLES 10 to SLES 11

29 Chapter 2 Upgrade Preparation Workload Migration from Appliance-Licensed Systems 13 [Optional] If you have secured TASM licensing for use in SLES 11 and intend to assign workloads to the SLG tier, review and adjust as necessary service level goals for those workloads. a b In the Teradata Workload Analyzer menu bar, click Rule Set > Calculate All WD SLGs. A progress bar appears, followed by a display of SLG Recommendations. In the rule set tree, expand the workload branch for which you want to access service level goal settings, and click SLG Graph. c d Change the various display parameters as necessary to review the required information. Set options and values to define the required service level goals for the workload. e Click Apply. 14 When you are ready to save the rule set, click Rule Set > Save to Database. Related Topics Downloading the Pre-Migration Tool, on page 39 Connecting to the Database, on page 40 Calculating SLG Workload Allocation Percentage, on page 36 Workload Migration from Appliance-Licensed Systems As part of upgrading to SLES 11, priority-scheduling settings for workloads are migrated from the SLES 10 system. Because workloads are not provided on SLES 10 appliance- Preparing to Move from SLES 10 to SLES 11 29

30 Chapter 2 Upgrade Preparation Default Tactical Workload Exception licensed systems, you cannot use the Pre-Migration Tool to refine the otherwise automatic results of migrating priority-scheduling settings. Instead, when the TDWMDIP program is run as part of the process, the four SLES 10 performance groups are automatically converted to four SLES 11 timeshare workloads, placed in the single default virtual partition named Standard, and assigned access levels based on SLES 10 account string value (that is, Top, High, Medium, and Low). Access level affects the volume of resources provided to workload queries at a ratio of 2:1. Queries in a workload that is assigned the Top access level receive eight times the volume of resources as queries in a workload that is assigned the Low access level, four times the volume of resources as queries in a workload that is assigned the Medium access level, and two times the volume of resources as queries in a workload that is assigned the High access level. The following table illustrates the SLES 11 timeshare workload names, access levels, and access rates that result from conversion of SLES 10 performance groups when upgrading or migrating from appliance-licensed systems. SLES 10 Performance Group SLES 11 Timeshare Workload Access Level Access Rate $R* T-WD Top 8 $H* H-WD High 4 $M* M-WD Medium 2 $L* L-WD Low 1 The following additional results occur automatically when the TDWMDIP program is run as part of the SLES 11 upgrade process. The rule set that was active at the time of migration is automatically activated. Query milestones are lost. However, you can achieve similar results following upgrade to SLES 11 by using the Workload Designer portlet in Teradata Viewpoint to enable the Decay option for timeshare workloads. Two throttles to limit system concurrence are provided: GeneralQuery (with a limit of 52) and OneSecondQuery (with a limit of 30). You can use the Workload Designer portlet post upgrade to change or delete these throttles, as required. After operating system upgrade, use the Workload Designer portlet in Teradata Viewpoint to review and adjust workload configurations as necessary. Default Tactical Workload Exception As a safeguard against expediting workloads that are not really tactical, the migration process yields a pre-configured exception for each tactical workload. These exceptions cannot be disabled, but the associated values can be changed after upgrade to SLES 11. The exception specifies default threshold values, as shown in the following table. Exception Criterion CPU per node Default Threshold Value 2 CPU seconds 30 Preparing to Move from SLES 10 to SLES 11

31 Chapter 2 Upgrade Preparation Default Limit and Reserve Values Exception Criterion I/O per node CPU (sum over all nodes) I/O (sum over all nodes) Default Threshold Value 200 MB 2 CPU seconds * number of nodes 200 MB * number of nodes If a tactical workload exceeds any of the defined thresholds, it is diverted to the WD-Default workload in the Timeshare tier. This default workload is assigned an access level of Medium. You cannot disable tactical workload exceptions, but you can use the Workload Designer portlet in Teradata Viewpoint to change the default values and the workload to which queries divert. Note: The workload to which tactical queries divert must be in the Timeshare tier or, if available and appropriate, an SLG tier. Default Limit and Reserve Values Regardless of whether you use the Pre-Migration Tool, the workload-migration process that occurs as part of upgrading to SLES 11 specifies system-wide limit and reserve values for the Always planned environment, as shown in the following table. Parameter CPU Limit Value I/O Limit 100 Reserved AWTs Max AWTs for new work Existing value in "PsfGlobalOpenvValues" of base state (Always PlannedEnv) otherwise 100 Existing value in "PsfGlobalOpenvValues" of base state (Always PlannedEnv) otherwise 0 Existing value in "PsfGlobalOpenvValues" of base state (Always PlannedEnv) otherwise 80 Regardless of workload-management licensing in SLES 11, you can use the Workload Designer portlet in Viewpoint to change reserve values as necessary to meet priorityscheduling goals. With TASM licensing, you can change both reserve and limit values. When determining values for CPU and I/O limits, administrators of TASM-licensed systems should consider the following: In SLES 11, operating system utilities and work running on nodes external to those housing the Teradata Database are not subject to the CPU limit. However, non-database demands as well as resources that may be required for tuning or growth purposes should be taken into account when establishing CPU limit. By adjusting the limit downward from 100%, you can provide adequate resources for all work while reserving resources for any necessary refinements. All database activities that were exempt from the CPU limit in SLES 10, including rollbacks when running at the default DBS control settings and work running in the System performance group, are subject to the limit in SLES 11 by default. Preparing to Move from SLES 10 to SLES 11 31

32 Chapter 2 Upgrade Preparation Determining Workloads for the SLG Tier Unlike in SLES 10, tactical workloads in SLES 11 are subject to the CPU limit. However, in SLES 11, such workloads are allocated the highest priority by default. Thus, there is no need to limit CPU at the system level to insulate tactical work from competition for CPU resources. To protect against a perceptible increase in average elapsed time for completing highly critical work or work associated with short service level agreements, CPU limit be should be set no lower than 63%. Only physical I/Os that actually involve reading or writing from disk are subject to I/O limit. The cost of each such I/O is determined after the I/O request arrives, based on hardware specifications for the device. This cost is then subtracted from the total allowable bandwidth for the device as mandated by the established I/O limit value. A given device s available I/O bandwidth can be ascertained at any point in time based on the known maximum bandwidth of the device and the cost of the I/Os already performed. When I/O limit is reached within a given enforcement interval, I/O activity on the device ceases for the remainder of that interval. Note: Although administrators of TASM-licensed systems can set disparate values for CPU and I/O limits, it is strongly recommended that you refrain from doing so. If default migration processing results in such a disparity, use the Workload Designer portlet in Teradata Viewpoint to adjust the I/O limit value to match the CPU limit value. Establish disparate values for these parameters only at the recommendation of authorized Teradata support personnel. For more information, please see Teradata Viewpoint User Guide. Additional information pertinent to CPU and I/O limits specifically can be found in the following Orange Book: Workload Management Capacity on Demand, Teradata Database and Linux SLES11, A02. Determining Workloads for the SLG Tier In SLES 11, the highest scheduling priority is given to workloads in the Tactical tier, with the next highest priority being given to workloads in the SLG tiers. Note: SLG tiers are available only with TASM licensing. The SLG tier is for workloads that are associated with a short service level goal or service level expectation; require a short response time due to business importance; and do not generally consume a significant amount of CPU resources. Although critical to the business, SLG workloads are secondary in importance to tactical workloads. SLG Workload Criteria When considering which workloads to associate with the SLG tier, expect fewer than ten, if any, to qualify. To make a determination, specifically consider the following criteria. The service level goal or agreement assigned to the workload. The importance to the business of the workload. The relative weight value of the corresponding allocation group. You can use the Workload Mapping tab in the Teradata Viewpoint Workload Designer portlet to ascertain workload-to-allocation group relationship. To find information on 32 Preparing to Move from SLES 10 to SLES 11

33 Chapter 2 Upgrade Preparation Determining Workloads for the SLG Tier allocation group relative weight and CPU resource consumption, use the ResUsageSPS table or pie charts in the Teradata Viewpoint Workload Monitor portlet. Note: The Workload Monitor portlet shows the relative weight that an allocation group would be assigned if all defined allocation groups were active. Therefore, relative weights of some allocation groups may actually be smaller at run time than the portlet indicates. Conversely, the ResUsageSPS table reflects relative weights as calculated by Priority Scheduler at run time based only on the active allocation groups. The amount of CPU resources consumed by the workload at peak processing times. The typical run time, expected resource demands, and the business importance of the work destined for the workload. SLG Workload Identification Process Overview In general, only non-tactical but business-critical workloads associated with service level goals or agreements should be considered for the SLG tier. After identifying each such workload, complete the following steps to assess candidacy for SLG-tier assignment. 1. If the service level goal or agreement is 10 seconds or longer, assign the workload to the Timeshare tier. Otherwise, proceed to the next step. 2. If the CPU consumption at peak processing times is higher than the relative weight of the allocation group, assign the workload to the Timeshare tier. Otherwise, proceed to the next step. 3. If the expected run time is long and the resource demands are great, assign the workload to the Timeshare tier. If, however, the expected run time is short and the resource demands are minimal, the workload may be a good candidate for the SLG tier. The following flowchart illustrates this process. Preparing to Move from SLES 10 to SLES 11 33

34 Chapter 2 Upgrade Preparation Determining Workloads for the SLG Tier SLG Workload Identification Process Modifications The assessment process may yield no candidate workloads for the SLG tier. In this case, consider expanding the scope to include workloads with slightly longer service level goals or agreements, such as 20 or 30 seconds, or workloads with a slightly higher CPU-consumption value than allocation group relative weight. Conversely, the process may indicate that a higher than recommended number of workloads qualify for SLG tier assignment. In this case, investigate whether the cause is business-critical, short-running work being spread across many workloads. If so, and the total CPUconsumption value of the workloads is low to moderate (for example, no more than 25% combined), consider expanding the total number of workloads assigned to the SLG tier beyond the recommended single-digit scope. Example: SLG Workload Determination The following figure simulates pie charts in the Teradata Viewpoint Workload Monitor portlet to illustrate the process of assessing which workloads best qualify for SLG tier assignment. Note: Pie charts in the Workload Monitor portlet do not show allocation group or workload CPU consumption details for the L, M, H, R, or System performance groups. Because the DBA does not need to maintain those constructs in SLES 11, they can be discounted during migration. The left side of the figure lists the workloads associated with the allocation groups on the right side. The relationship between workloads and allocations groups is indicated by the parenthetical number following each workload and allocation group listing. For example, the 34 Preparing to Move from SLES 10 to SLES 11

35 Chapter 2 Upgrade Preparation Determining Workloads for the SLG Tier ETL_Priority and MSI_Medium workloads are associated with the User_Medium allocation group, as indicated by the (9) following each listing. Note: Actual pie charts in the Workload Monitor portlet do not contain the parenthetical numbers indicating workload-to-allocation group relationship. The figure has been enhanced with these components to illustrate the process of assessing which workloads best qualify for SLG tier assignment. You can, however, ascertain workload-to-allocation group relationship in the Workload Designer portlet, on the Workload Mapping tab. Beside each workload listing, the figure displays the peak CPU usage percentage; likewise, the relative weight percentage is shown beside each allocation group listing. Note: The Workload Monitor portlet shows the relative weight that an allocation group would be assigned if all defined allocation groups were active. Therefore, relative weights of some allocation groups may actually be smaller at run time than the portlet indicates. Conversely, the ResUsageSPS table reflects relative weights as calculated by Priority Scheduler at run time based only on the active allocation groups. You can use either source for relative weight information when completing the steps of the pre-migration process. Following the recommended process for assessing which workloads best qualify for SLG tier assignment, the first step is to eliminate all tactical workloads from consideration. In this example, the first step excludes all workloads with a parenthetical designator of 5. The next step is to eliminate all workloads that are not business-critical. For this example, assume that all workloads are critical to the business. Likewise, assume that all workloads have a service level goal of less than 10 seconds. Given these facts, all remaining workloads are still possible candidates for the SLG tier, leaving the following as criteria for making a decision: The expected run time and the resource demands of the work destined for the workload The ratio of workload CPU consumption at peak processing times to relative weight of the allocation group associated with the workload Given the high CPU usage value for workload MSI_Long, at 44%, eliminate it from consideration, leaving the following workloads to assess: DBA_Ctl CRT_Short MSI_Very_Short MSI_Short ETL_Priority MSI_Medium CRT_Long ETL_Background User_Loads Assuming that all remaining workloads have a short run time, the final assessment criterion to apply is ratio of workload CPU consumption at peak processing times to relative weight of the allocation group associated with the workload. Given that workload CPU consumption should be lower than the relative weight of the associated allocation group, only the following workloads qualify for SLG tier assignment: DBA_Ctl: This workload maps to allocation group 6 with a relative weight of 15%, yet the workload consumes only 1% of the CPU. Preparing to Move from SLES 10 to SLES 11 35

36 Chapter 2 Upgrade Preparation Determining Workloads for the SLG Tier CRT_Short: This workload maps to allocation group 7 with a relative weight of 10%, yet the workload consumes only 8% of the CPU. MSI_Very_Short: This workload maps to allocation group 7 with a relative weight of 10%, yet the workload consumes only 3% of the CPU. MSI_Short: This workload maps to allocation group 8 with a relative weight of 7%, yet the workload consumes only 4% of the CPU. SLG Workload Allocation Percentage Considerations The allocation percentage assigned to SLG workloads should be high enough to ensure a reasonable distribution of resources to SLG workloads in comparison to timeshare workloads. In general, avoid low single-digit values for SLG allocation percentage. In addition, consider the following characteristics of SLG workloads: The percentage assigned to a workload represents an allocation of the resources flowing to its tier rather than an allocation of total system resources. The volume of resources provided to a workload based on allocation percentage is divided among concurrent queries running in the workload. After upgrading to SLES 11 and monitoring the outcome of your original settings, you can adjust SLG workload allocation percentages as necessary using the Workload Designer portlet in Teradata Viewpoint. Before doing so, however, consider that the SLG tier should be reserved for highly critical workloads that consume few resources. If some workloads that you have associated with the SLG tier are less critical to the business than others, consider moving those workloads to the Top access level of the Timeshare tier. Calculating SLG Workload Allocation Percentage To calculate SLG workload allocation percentage, complete the following steps. 1 Establish a baseline allocation percentage for the SLG workload based on its CPU usage at peak consumption. 2 Estimate the combined CPU usage at peak processing times for tactical workloads. 3 Adjust the baseline allocation percentage of the SLG workload to reach a final allocation percentage as follows: a b c Subtract the current combined peak CPU usage value for all tactical workloads from 100 to establish the CPU percentage remaining after tactical workloads use the resources they require. Establish an initial adjusted allocation percentage for the SLG workload by dividing its baseline allocation percentage by the value resulting from the preceding step, that is, the CPU percentage remaining after tactical workloads use the resources they require. Finalize the adjusted allocation percentage for the SLG workload by adding 5 or more percentage points to ensure that the workload is always given higher priority than any of the timeshare workloads. Note: This last adjustment may be particularly important when a workload's baseline allocation percentage is a single-digit value. 36 Preparing to Move from SLES 10 to SLES 11

37 Chapter 2 Upgrade Preparation Backing Up the Database Backing Up the Database Because of the different approaches taken to priority scheduling in SLES 10 and SLES 11, and the related workload conversion that must occur, the SLES 10 TDWM database must be backed up before upgrading the operating system. In an in-place upgrade scenario, this measure ensures ongoing access to workload-management configurations and functionality should you need to revert to the SLES 10 environment. In a migration scenario, the backup is restored on the destination system in preparation for the required workload conversion. Depending on your baseline and target operating environments, database upgrade and additional database backup may be required as part of transitioning to SLES 11. If so, be sure to review Teradata Database Node Software Upgrade Guide: Overview and Preparation and, if migrating between hardware to upgrade the operating system, Teradata Database Node Software Migration Guide for the applicable database version. Preparing to Move from SLES 10 to SLES 11 37

38 Chapter 2 Upgrade Preparation Backing Up the Database 38 Preparing to Move from SLES 10 to SLES 11

39 CHAPTER 3 Using the Pre-Migration Tool Downloading the Pre-Migration Tool Prerequisite: To download the Pre-Migration Tool, you must have a Site ID and Change Control Number. If you have not yet obtained these items, contact Teradata Customer Services. The Pre-Migration Tool must be installed on a Windows workstation, where the following software is also installed: Teradata Database version or later Teradata Tools and Utilities version or later Teradata Call-Level Interface version 2 (CLIv2) release or later TDICU or later TeraGSS or later 1 Access the Teradata Software Server ( or through 2 Search for premigration. 3 Select the version that aligns with your version of the database. 4 At the bottom, follow the instructions to download the Pre-Migration Tool. Specific steps vary, depending on whether you are connected to the Teradata Database. Running the Pre-Migration Tool Open the Pre-Migration Tool to begin the process of reviewing and, if necessary, adjusting default rule set and workload migration settings. 1 From the Start menu, point to Programs and click Workload Management Pre- Migration Tool for SLES 11 (selecting the option that corresponds to your Teradata Database release). The Workload Management Pre-Migration Tool window appears. Preparing to Move from SLES 10 to SLES 11 39

40 Chapter 3 Using the Pre-Migration Tool Connecting to the Database Connecting to the Database As a first step in reviewing and, if necessary, adjusting rule set and workload migration settings, connect to the corresponding Teradata Database as user tdwm. Note: A local mode is not available. 1 From the Pre-Migration Tool menu bar, click File > Connect The Connect to Teradata Database dialog box appears. 2 Specify database and credential information: a At System (DBS) Name, type or select the name of the Teradata Database. b At Password, type the password associated with user tdwm. Note: Because you must connect to the database as user tdwm, the User Name box is pre-populated with this value, which cannot be edited. Likewise, the Session Character Set is static. 3 [Optional] Click More, and specify the following: a b From the Authentication Mechanism list, select the applicable option. At Authentication Parameter, type the appropriate authentication parameter for the selected authentication mechanism. c If applicable, select the appropriate option from Account String. 4 Click OK. A message prompts for indication of TASM licensing status. 5 Indicate whether your SLES 11 system is (Yes) or is not (No) licensed for TASM. Note: TASM licensing is not available for appliance systems and is optional for other systems. Without TASM licensing, systems default to IWM licensing. The workloadmanagement options available with IWM licensing represent a subset of the options available with full TASM licensing. For example, only one virtual partition can be created, and SLG tiers are not available with IWM licensing. You can begin the process of reviewing and refining workload conversion settings by completing the procedure for selecting the rule sets containing the workloads. Selecting a Rule Set for Pre-Migration Without manual intervention before upgrading to SLES 11, workloads in SLES 10 rule sets are converted in a default manner that may not meet your priority-scheduling goals. Well prior to the operating system upgrade, use the Pre-Migration Tool to select SLES 10 rule sets for which you want to refine workload priority-scheduling settings in preparation for migration. 40 Preparing to Move from SLES 10 to SLES 11

41 Chapter 3 Using the Pre-Migration Tool Selecting a Rule Set for Pre-Migration 1 From the Pre-Migration Tool menu bar, click Migration > Start Pre-Migration for SLES11. A wizard appears, displaying the Select RuleSet page. Note: If workloads are not defined for a SLES 10 rule set, the corresponding row in the Available RuleSets grid is unavailable, and the Status value is set to Workloads Not Available. In this case, no workloads are migrated upon upgrade, but other components of the rule set are. 2 Click the row housing the rule set for which you want to refine workload priorityscheduling settings in preparation for migration to SLES 11, and click Next. If you did not previously complete the pre-migration process for the rule set, the Current Enforcement Priority To New Workload Method Mapping page appears, where you can adjust the SLES 11 workload method (that is, tier) mapping for the rule set workloads, if necessary. If you did previously complete the pre-migration process for the rule set, a message appears, prompting you to indicate whether you want to overwrite the existing premigration settings (Yes) or leave the existing pre-migration settings in place (No). Preparing to Move from SLES 10 to SLES 11 41

42 Chapter 3 Using the Pre-Migration Tool Setting Workload Type Setting Workload Type Without manual intervention before upgrading, workloads are mapped to workload methods (that is, tiers) in SLES 11 based on a combination of their AMP and EP settings in SLES 10. Use the Pre-Migration Tool to review and, if necessary, adjust these default mappings before upgrading the operating system. To do so, complete the outlined steps for each applicable workload. 1 On the Current Enforcement Priority to New Workload Mapping page, in the same row as the workload listing, click the Workload Method arrow, and select the option with which the workload should be associated: Option Tactical SLG Tier Description This method should be used primarily for single or few-amp, highly critical queries with response-time requirements of 1 second or less. Tactical workloads receive the highest priority available and are allowed to consume whatever resources they require. These workloads are automatically expedited and are provided access to special pools of reserved AMP worker tasks, if defined, as well as other internal performance boosts. The SLG tier is for workloads that are associated with a short service level goal or service level expectation; require a short response time due to business importance; and do not generally consume a significant amount of CPU resources. Although critical to the business, SLG workloads are secondary in importance to tactical workloads. By default, SLG workloads are each allocated 5% of tier resources. This value can subsequently be changed as required. Note: SLG tiers are available only with TASM licensing. Timeshare This method is for workloads with response times that are less critical to the business and without service level expectation. Timeshare workloads generally represent lower-priority or background work and sandbox applications. The majority of system resources are expected to be consumed by timeshare workloads, each of which can subsequently be assigned an access level representing a priority of Top, High, Medium, or Low. 42 Preparing to Move from SLES 10 to SLES 11

43 Chapter 3 Using the Pre-Migration Tool Setting Timeshare Workload Access Level 2 When you have changed all workload method mappings as required, click Next. The Workload Methods Setting page appears, where you can change any of the following: Allocation percentages for SLG workloads Mapping of relative weight values to timeshare access levels for planned environments Access levels for timeshare workloads Setting Timeshare Workload Access Level By default, access level values are assigned to timeshare workloads based on allocation group relative weight values in SLES 10. To do so, a pre-configured mapping scheme of access level values to relative weight values for each planned environment is used. Before upgrading the operating system, use the Pre-Migration Tool to review the access level values automatically assigned to timeshare workloads for each planned environment, and complete the outlined steps to: Adjust the mapping scheme of access level values to relative weight values for each planned environment, if doing so will minimize required changes to access level values for individual timeshare workloads. Change access level values for each applicable timeshare workload for each applicable environment as necessary to meet priority-scheduling goals Note: Access level affects the volume of resources provided to workload queries at a ratio of 2:1. Queries in a workload that is assigned the Top access level receive eight times the Preparing to Move from SLES 10 to SLES 11 43

44 Chapter 3 Using the Pre-Migration Tool Setting Timeshare Workload Access Level volume of resources as queries in a workload that is assigned the Low access level, four times the volume of resources as queries in a workload that is assigned the Medium access level, and two times the volume of resources as queries in a workload that is assigned the High access level. The following table illustrates the impact of access level on access rate. Access Level Top 8 High 4 Medium 2 Low 1 Access Rate The volume of resources provided to timeshare workloads based on access level is not divided among concurrent queries running in a workload. Rather, resource volume per workload is adjusted as necessary to maintain the ratio scheme across access levels. Complete the following steps to set timeshare workload access level. 1 [Optional] Adjust the mapping scheme of access level values to relative weight values for each planned environment: a b On the Workload Methods Setting page, under Planned Environment, select the operating period to which the mapping scheme you are adjusting applies. Under RelWeight to Access Level Mapping, in the Min and Max boxes beside each access level value for which you want to change the mapping scheme, type the preferred relative weight percentage values. 44 Preparing to Move from SLES 10 to SLES 11

45 Chapter 3 Using the Pre-Migration Tool Setting SLG Workload Allocation Percentage c Click Apply to PlannedEnv. If the adjustment affects the access level assignments of any timeshare workloads for the selected planning environment, the changes are reflected in the Access Level/ Share column under Timeshare and SLG Tier Settings. 2 Change timeshare workload access level values as necessary: a b c Under Planned Environment, select the operating period to which the change in access level applies. Under Timeshare and SLG Tier Settings, in the same row as the workload listing, click the Access Level/Share arrow, and select whether the workload access level should be Top, High, Medium, or Low. Click Apply. Setting SLG Workload Allocation Percentage Prerequisite: See: Calculating SLG Workload Allocation Percentage, on page 36 Without manual intervention before upgrading to SLES 11, each SLG workload is allocated 5% of tier resources, for each planned environment. If necessary, use the Pre-Migration Tool to change this value before upgrading. To do so, perform the outlined steps for each applicable SLG workload and each applicable environment. Note: SLG tiers are available only with TASM licensing. 1 On the Workload Methods Setting page, under Planned Environment, select the operating period to which the allocation percentage you are setting applies. 2 For the SLG workload to which you want to assign a different allocation percentage, type the preferred value in the Access Level/Share box in the same row. Note: After upgrading to SLES 11 and monitoring the outcome of your original settings, you can adjust SLG workload allocation percentages as necessary using the Workload Designer portlet in Teradata Viewpoint. Before doing so, however, consider that the SLG tier should be reserved for highly critical workloads that consume few resources. If some workloads that you have associated with the SLG tier are less critical to the business than others, consider moving those workloads to the Top access level of the Timeshare tier. 3 Click Apply. Managing Remaining Rulesets Rule sets for which you do not use the Pre-Migration Tool to refine the otherwise automatic results of migrating priority-scheduling settings may necessitate a comparatively high degree of post-upgrade configuration to emulate existing workload-processing behavior. Preparing to Move from SLES 10 to SLES 11 45

46 Chapter 3 Using the Pre-Migration Tool Managing Remaining Rulesets Related Topics Using the Workload Designer Portlet to Refine Migration Results, on page Preparing to Move from SLES 10 to SLES 11

47 CHAPTER 4 Upgrade Paths Upgrade Compared to Migration There are two paths for transitioning a Teradata system from SLES 10 to SLES 11: upgrade and migration. Path Upgrade Migration Context If your existing hardware supports SLES 11, you can upgrade the operating system in place without migrating data. This path is available for the following platforms: 560P, 670, 1XXX (1650 and above), 2XXX (2650 and above), 5XXX (5600 and above), and 6XXX (6650 and above). If you have purchased different hardware that supports SLES 11, you must migrate data from your SLES 10 system to your SLES 11 system. This path is the only means of upgrading from the following platforms: 550P, 551P, 1XXX (below 1650), 2XXX (below 2650), and 5XXX (below 5600). In either case, the required steps for transitioning a Teradata system vary depending on existing database and operating system versions. Pre- and post-upgrade workload-management licensing, which may be dictated by existing hardware, also influence the following aspects of the upgrade: Means of migrating workloads Tasks to prepare workloads for migration Workload-management options and required configuration post upgrade Preparation and planning are key to a successful operating system upgrade. Consult with Teradata Customer Services well in advance to establish an approach for performing the upgrade, including roles and responsibilities. General Upgrade Considerations The following considerations apply when transitioning from SLES 10 to SLES 11, regardless of platform and licensing. If required as part of upgrading to SLES 11, perform hardware and Teradata Database upgrades well in advance. Doing so provides for monitoring the performance Preparing to Move from SLES 10 to SLES 11 47

48 Chapter 4 Upgrade Paths License- and Platform-Dependent Upgrade Considerations characteristics on the new database version so that you can better fine tune priorityscheduling settings prior to operating system upgrade. You can upgrade to later Teradata Database versions one major release at a time until reaching the required version. In preparation for upgrading the database, be sure to review Teradata Database Node Software Upgrade Guide: Overview and Preparation. If migrating between systems to upgrade the operating system, the Teradata Database version on the source system can be no more than two releases earlier than and cannot exceed the version installed on the destination system. In preparation for migrating a system, be sure to review Teradata Database Node Software Migration Guide for the applicable database version. Backing up the TDWM database prior to upgrading the operating system ensures ongoing access to priority-scheduling configurations and functionality should you need to revert to the SLES 10 environment after completing the upgrade. In a migration scenario, the backup is restored on the destination system in preparation for the required workload conversion. After upgrading to SLES 11, use the Workload Designer portlet in Teradata Viewpoint to review and adjust workload configurations as necessary. License- and Platform-Dependent Upgrade Considerations The following considerations that apply when transitioning from SLES 10 to SLES 11 are license or platform dependent. If you have not secured TASM licensing for use with your SLES 11 system, or TASM licensing is not available on the system hardware, licensing defaults to IWM upon operating system upgrade. The workload-management options available with IWM licensing represent a subset of the options available with full TASM licensing. For example, only one virtual partition can be created, and SLG tiers are not available with IWM licensing. Note: After upgrading a SLES 10 appliance-licensed system in place, only IWM licensing is available with SLES 11. If you are upgrading or migrating from a TASM-licensed system, you can use the Pre- Migration Tool to refine the otherwise automatic results of migrating SLES 10 workload priority-scheduling settings. If you are upgrading or migrating from a PSF-licensed system and have in-depth understanding of PD set configuration, you can likewise use the Pre-Migration Tool. As a pre-requisite to using the tool in the latter scenario, however, you must convert PD sets to rule sets containing workloads while still running Teradata Database version 13.0 or lower. Whether transitioning from a TASM-licensed or PSFlicensed system, use the Pre-Migration Tool well in advance of the operating system upgrade. Note: The minimum Teradata Database version for using the Pre-Migration Tool is Because SLES 10 appliance-licensed systems do not provide rule sets and workloads, you cannot use the Pre-Migration Tool when upgrading or migrating from these systems. 48 Preparing to Move from SLES 10 to SLES 11

49 Chapter 4 Upgrade Paths Upgrade Scenarios If your SLES 10 system includes rule sets that you have not used and do not intend to use in the future, delete them to speed the process of workload migration. If you are migrating workloads based on user-defined SLES 10 performance groups from a PSF-licensed system, you must be running Teradata Database version or later or at the time of operating system upgrade, to ensure that workloads based on default performance groups are assigned the expected timeshare access level in SLES 11. If installing Teradata Database version on a 2690 or 2700 system, do not enable hardware compression. Upgrade Scenarios If your existing hardware supports SLES 11, you can upgrade the operating system in place without migrating data. The main upgrade scenarios are as follows: Upgrading a SLES 10 TASM-licensed system to a SLES 11 system licensed for TASM or IWM Upgrading a SLES 10 PSF-licensed system to a SLES 11 system licensed for TASM or IWM Upgrading a SLES 10 appliance-licensed system to a SLES 11 system licensed for IWM Note: After upgrading a SLES 10 appliance-licensed system in place, only IWM licensing is available with SLES 11. Upgrading a SLES 10 TASM-Licensed System to SLES 11 The following procedure outlines the main steps of upgrading a SLES 10 TASM-licensed system to a SLES 11 system licensed for TASM or IWM. Before performing this task, be sure to review General Upgrade Considerations and License- and Platform-Dependent Upgrade Considerations. 1 Ensure that the Teradata Database version on the system is supported on SLES 11 and meets the requirements for workload migration based on whether you plan to use the Pre-Migration Tool. 2 If your system includes rule sets that you have not used and do not intend to use in the future, delete them to speed the process of workload migration. 3 [Optional] To refine the otherwise automatic results of converting workloads for use in SLES 11, use the Pre-Migration Tool well in advance of the operating system upgrade. Note: If you do not use the tool, or if you accept all default settings when using the tool, workloads as automatically migrated may not meet your priority-scheduling goals in SLES Back up the TDWM database. This database encompasses the tdwm.premigrate table, which contains any adjustments to workloads that resulted from use of the Pre-Migration Tool. Preparing to Move from SLES 10 to SLES 11 49

50 Chapter 4 Upgrade Paths Upgrade Scenarios 5 Upgrade from SLES 10 to SLES Run the TDWMDIP program. The TDWMDIP program converts SLES 10 workloads or performance groups to SLES 11- compatible workloads based on a default processing scheme or the directives in the tdwm.premigrate table within the TDWM database, if such directives exist. 7 Bring the system to the Logons Enabled state. 8 Use the Workload Designer portlet in Teradata Viewpoint to refine workload settings as necessary. Related Topics System Requirements for SLES 11, on page 11 Understanding the Workload Migration Process, on page 19 Workload Migration from TASM-Licensed Systems, on page 20 Upgrading a SLES 10 PSF-Licensed System to SLES 11 The following procedure outlines the main steps of upgrading a SLES 10 PSF-licensed system to a SLES 11 system licensed for TASM or IWM. Before performing this task, be sure to review General Upgrade Considerations and License- and Platform-Dependent Upgrade Considerations. 1 [Optional] If you have an in-depth understanding of PD set configuration and intend to use the Pre-Migration Tool to refine the otherwise automatic results of converting workloads for use in SLES 11, complete the following steps while still running Teradata Database version 13.0 or earlier and well in advance of the operating system upgrade. a b Use PSA to verify that your PD sets are configured in a manner that best meets your priority-scheduling goals. You can access PSA from within the Pre-Migration Tool itself by clicking Migration > Priority Scheduler Administrator. Use TWA to create rule sets from PD sets. You can access TWA from within the Pre-Migration Tool itself by clicking Migration > Migrate PSF Setting. Note: If you do not use the tool, or if you accept all default settings when using the tool, workloads as automatically migrated may not meet your priority-scheduling goals in SLES Ensure that the Teradata Database version on the system is supported on SLES 11 and meets the requirements for workload migration based on whether you plan to use the Pre-Migration Tool. 3 If your system includes rule sets that you have not used and do not intend to use in the future, delete them to speed the process of workload migration. 4 [Optional] To refine the otherwise automatic results of converting workloads for use in SLES 11, use the Pre-Migration Tool well in advance of the operating system upgrade. 50 Preparing to Move from SLES 10 to SLES 11

51 Chapter 4 Upgrade Paths Upgrade Scenarios 5 Back up the TDWM database. This database encompasses the tdwm.premigrate table, which contains any adjustments to workloads that resulted from use of the Pre-Migration Tool. 6 Upgrade from SLES 10 to SLES Run the TDWMDIP program. The TDWMDIP program converts SLES 10 workloads or performance groups to SLES 11- compatible workloads based on a default processing scheme or the directives in the tdwm.premigrate table within the TDWM database, if such directives exist. 8 Bring the system to the Logons Enabled state. 9 Use the Workload Designer portlet in Teradata Viewpoint to refine workload settings as necessary. Related Topics System Requirements for SLES 11, on page 11 Understanding the Workload Migration Process, on page 19 Workload Migration from PSF-Licensed Systems, on page 22 Upgrading a SLES 10 Appliance-Licensed System to SLES 11 The following procedure outlines the main steps of upgrading a SLES 10 appliance-licensed system to a SLES 11. In this scenario, licensing defaults to IWM, which provides access to a subset of the components available with full TASM licensing. Before performing this task, be sure to review General Upgrade Considerations and Licenseand Platform-Dependent Upgrade Considerations. 1 Ensure that the Teradata Database version on the system is supported on SLES Back up the TDWM database. This database encompasses configurations for the default performance groups. 3 Upgrade from SLES 10 to SLES Run the TDWMDIP program. The TDWMDIP program converts the default SLES 10 performance groups to SLES 11- compatible workloads based on a pre-defined processing scheme. 5 Bring the system to the Logons Enabled state. 6 Use the Workload Designer portlet in Teradata Viewpoint to refine workload settings as necessary. Preparing to Move from SLES 10 to SLES 11 51

52 Chapter 4 Upgrade Paths Migration Scenarios Related Topics System Requirements for SLES 11, on page 11 Understanding the Workload Migration Process, on page 19 Workload Migration from Appliance-Licensed Systems, on page 29 Using the Workload Designer Portlet to Refine Migration Results, on page 57 Migration Scenarios If you have purchased different hardware that supports SLES 11, you must migrate data from your SLES 10 system to your SLES 11 system. Note: All migrations are performed under the guidance of Teradata Customer Services. The main migration scenarios are as follows: Migrating from a SLES 10 TASM-licensed system to a SLES 11 system licensed for TASM or IWM Migrating from a SLES 10 PSF-licensed system to a SLES 11 system licensed for TASM or IWM Migrating from a SLES 10 appliance-licensed system to a SLES 11 system licensed for TASM or IWM Migrating from a SLES10 TASM-Licensed System to a SLES 11 System The following procedure outlines the main steps of migrating from a SLES 10 TASM-licensed system to a SLES 11 system licensed for TASM or IWM. Before performing this task, be sure to review General Upgrade Considerations and License- and Platform-Dependent Upgrade Considerations. 1 Ensure that the version of Teradata Database on the source system meets the requirements for migration based on the database to be installed on the destination system and whether you plan to use the Pre-Migration Tool. 2 If the source system includes rule sets that you have not used and do not intend to use in the future, delete them to speed the process of workload migration. 3 [Optional] To refine the otherwise automatic results of converting workloads for use in SLES 11, use the Pre-Migration Tool on the source system well in advance of the operating system upgrade. Note: If you do not use the tool, or if you accept all default settings when using the tool, workloads as automatically migrated may not meet your priority-scheduling goals in SLES Back up the source system data, including the TDWM database. This database encompasses the tdwm.premigrate table, which contains any adjustments to workloads that resulted from use of the Pre-Migration Tool. 52 Preparing to Move from SLES 10 to SLES 11

53 Chapter 4 Upgrade Paths Migration Scenarios 5 On the destination system, install SLES On the destination system, install a version of Teradata Database that is supported on SLES 11 and meets or exceeds the minimum requirements of the hardware. 7 On the destination system, restore the TDWM database. 8 On the destination system, run the post_data_restore script. The post_data_restore script executes the TDWMDIP program, which converts SLES 10 performance groups or workloads, as applicable, to SLES 11-compatible workloads based on a default processing scheme or the directives in the tdwm.premigrate table within the TDWM database, if such directives exist. 9 Bring the destination system to the Logons Enabled state. 10 Use the Workload Designer portlet in Teradata Viewpoint to refine workload settings as necessary. Related Topics System Requirements for SLES 11, on page 11 Understanding the Workload Migration Process, on page 19 Workload Migration from TASM-Licensed Systems, on page 20 Migrating from a SLES 10 PSF-Licensed System to a SLES 11 System The following procedure outlines the main steps of migrating from a SLES 10 PSF-licensed system to a SLES 11 system licensed for TASM or IWM. Before performing this task, be sure to review General Upgrade Considerations and License- and Platform-Dependent Upgrade Considerations. 1 [Optional] If you have an in-depth understanding of PD set configuration and want to use the Pre-Migration Tool to refine the otherwise automatic results of converting workloads for use in SLES 11, complete the following steps on the source system while still running Teradata Database version 13.0 or earlier and well in advance of the operating system upgrade. a Use PSA to verify that your PD sets are configured in a manner that best meets your priority-scheduling goals. You can access PSA from within the Pre-Migration Tool itself by clicking Migration > Priority Scheduler Administrator. b Use TWA to create rule sets from PD sets. You can access TWA from within the Pre-Migration Tool itself by clicking Migration > Migrate PSF Setting. Note: If you do not use the tool, or if you accept all default settings when using the tool, workloads as automatically migrated may not meet your priority-scheduling goals in SLES Ensure that the version of Teradata Database on the source system meets the requirements for migration based on the database to be installed on the destination system and whether you plan to use the Pre-Migration Tool. Preparing to Move from SLES 10 to SLES 11 53

54 Chapter 4 Upgrade Paths Migration Scenarios 3 If the source system includes rule sets that you have not used and do not intend to use in the future, delete them to speed the process of workload migration. 4 [Optional] To refine the otherwise automatic results of converting workloads for use in SLES 11, use the Pre-Migration Tool on the source system well in advance of the operating system upgrade. 5 Back up the source system data, including the TDWM database. This database encompasses the tdwm.premigrate table, which contains any adjustments to workloads that resulted from use of the Pre-Migration Tool. 6 On the destination system, install SLES On the destination system, install a version of Teradata Database that is supported on SLES 11 and meets or exceeds the minimum requirements of the hardware. 8 On the destination system, restore the TDWM database. 9 On the destination system, run the post_data_restore script. The post_data_restore script executes the TDWMDIP program, which converts SLES 10 performance groups or workloads, as applicable, to SLES 11-compatible workloads based on a default processing scheme or the directives in the tdwm.premigrate table within the TDWM database, if such directives exist. 10 Bring the destination system to the Logons Enabled state. 11 Use the Workload Designer portlet in Teradata Viewpoint to refine workload settings as necessary. Related Topics System Requirements for SLES 11, on page 11 Understanding the Workload Migration Process, on page 19 Workload Migration from PSF-Licensed Systems, on page 22 Migrating from a SLES 10 Appliance-Licensed System to a SLES 11 System The following procedure outlines the main steps of migrating from an SLES 10 appliancelicensed system to a SLES 11 system licensed for TASM or IWM. Before performing this task, be sure to review General Upgrade Considerations and License- and Platform-Dependent Upgrade Considerations. 1 Ensure that the version of Teradata Database on the source system meets the requirements for migration based on the database to be installed on the destination system. If installing version on a 2690 or 2700 system, do not enable hardware compression. 2 Back up the source system data, including the TDWM database. This database encompasses configurations for the default performance groups. 3 On the destination system, install SLES Preparing to Move from SLES 10 to SLES 11

55 Chapter 4 Upgrade Paths Migration Scenarios 4 On the destination system, install a version of Teradata Database that is supported on SLES 11 and meets or exceeds the minimum requirements of the hardware. 5 On the destination system, restore the TDWM database. 6 On the destination system, run the post_data_restore script. The post_data_restore script executes the TDWMDIP program, which converts the default SLES 10 performance groups in the TDWM database to SLES 11-compatible workloads based on a pre-defined processing scheme. 7 Bring the destination system to the Logons Enabled state. 8 Use the Workload Designer portlet in Teradata Viewpoint to refine workload settings as necessary. Related Topics System Requirements for SLES 11, on page 11 Understanding the Workload Migration Process, on page 19 Workload Migration from Appliance-Licensed Systems, on page 29 Using the Workload Designer Portlet to Refine Migration Results, on page 57 Preparing to Move from SLES 10 to SLES 11 55

56 Chapter 4 Upgrade Paths Migration Scenarios 56 Preparing to Move from SLES 10 to SLES 11

57 CHAPTER 5 After the Upgrade Using the Workload Designer Portlet to Refine Migration Results After upgrading from SLES 10 to SLES 11, use the Workload Designer portlet in Teradata Viewpoint to review and modify as necessary the results of workload migration. Pertinent activities may vary based on licensing. For detailed information on any of the configuration activities, see Teradata Viewpoint User Guide, as well as the following Orange Books: Teradata Active System Management For Teradata 15.0 with SLES 11, C01 Teradata Active System Management For Teradata with SLES 11, B02 Teradata Integrated Workload Management Appliances and Enterprise Data Warehouse for Teradata Database with SLES 11, B03 License-Independent Post-Upgrade Configuration The following post-upgrade workload-management configuration activities may be pertinent regardless of system licensing. Distributing qualifying workloads to the Tactical tier. This tier should be reserved for single or few-amp, highly critical workloads with response-time requirements of one second or less. Changing the access level assigned to timeshare workloads. Adjusting tactical workload exceptions. Setting planned environment reserve values. Configuration after Upgrading from a SLES 10 Appliance- or PSF-Licensed System If you upgraded from a SLES 10 appliance-licensed or PSF-licensed system, the following post-upgrade workload-management configuration activities may be pertinent, regardless of SLES 11 system licensing. Breaking one or more of the four automatically created timeshare workloads into multiple workloads of your own configuration to achieve finer granularity in such areas as throttling, filtering, monitoring, and reporting. Enabling the timeshare decay option to emulate the functionality of query milestones, which are not maintained upon upgrade. Setting different values for or deleting the throttles that are automatically created to limit system concurrency (that is, GeneralQuery, with a limit of 52, and OneSecondQuery, with a limit of 30). Preparing to Move from SLES 10 to SLES 11 57

58 Chapter 5 After the Upgrade Using the Workload Designer Portlet to Refine Migration Results Configuration after Upgrading to a SLES 11 TASM-Licensed System If your SLES 11 system is licensed for TASM, the following post-upgrade workloadmanagement configuration activities may be pertinent, regardless of SLES 10 system licensing. Distributing qualifying workloads to the SLG tier. This tier should be reserved for workloads that are secondary in importance to tactical workloads but are associated with a short service level goal or service level expectation; require a short response time due to business importance; and do not generally consume a significant amount of CPU resources. Distributing workloads across multiple SLG tiers. By default, only one SLG tier is provided, but you can add tiers up to a total of five. Allocating resources to SLG workloads at an adjusted percentage. You can adjust SLG workload allocation percentages. Before doing so, however, consider that the SLG tier should be reserved for highly critical workloads that consume few resources. If some workloads that you have associated with the SLG tier are less critical to the business than others, consider moving those workloads to the Top access level of the Timeshare tier. Setting planned environment limit values. Creating virtual partitions in addition to the single, default Standard partition, if business conditions demand. In general, multiple virtual partitions should be reserved for dividing workloads based on business unit or geographic region, and not for enforcing priority among peer workloads. Up to 10 virtual partitions are allowed. Moving workloads between virtual partitions. Distributing Workload Resources In SLES 11, you can allocate resources to workloads for each planned environment. 1 Edit or create a ruleset. 2 From the ruleset toolbar, click Workloads. 3 Click the Workload Distribution tab. 4 [Optional] If multiple planned environments or virtual partitions exist, click to select the area you want to manage. 58 Preparing to Move from SLES 10 to SLES 11

59 Chapter 5 After the Upgrade Using the Workload Designer Portlet to Refine Migration Results 5 [Optional] Drag a workload from one management method to another to change resource allocation across planned environments. Direction Tactical to SLG Tier Tactical to Timeshare SLG Tier to Tactical SLG Tier to Timeshare Timeshare to Tactical Timeshare to SLG Tier Results You can select the SLG Tier in the current planned environment. The workload is assigned to the lowest SLG Tier in all other planned environments. Minimum allocation percentage (5%) is assigned to the workload. The allocation comes from unallocated resources remaining for the tier, or from the workload with the highest allocation in the tier. Tactical exception is deleted for the workload. You can select the access level for the workload in the current environment. The access level is changed to medium in all other planned environments. Tactical exception is deleted for the workload. Tactical exception is created for both Tactical CPU Time and Tactical I/O Physical Byte thresholds in the workload. Hard limits are removed for a workload if they were enabled. You can select the access level for the workload in the current environment. The access level is changed to medium in all other planned environments. Hard limits are removed for a workload if they were enabled. Tactical exception is created for both Tactical CPU Time and Tactical I/O Physical Byte thresholds in the workload. You can select the SLG Tier in the current planned environment. The workload is assigned to the lowest SLG Tier in all other planned environments. Preparing to Move from SLES 10 to SLES 11 59

60 Chapter 5 After the Upgrade Using the Workload Designer Portlet to Refine Migration Results Direction Results Minimum allocation percentage (5%) is assigned to the workload. The allocation comes from unallocated resources remaining for the tier, or from the workload with the highest allocation in the tier. 6 [Optional] Under SLG Tier, do any of the following: Option Description Add a tier Next to SLG Tiers, click. Change tier for a workload Change resource allocation for a workload Edit workload resource allocation for the tier (Teradata Database or later) If multiple tiers exist, drag workloads from one tier to another. In Teradata Database or later, if you drag a workload from Tier 1 to a lower tier, SLG expedite is removed if it was enabled. Drag the border of a workload horizontally. Next to a tier name, click. Enable SLG expedite for Tier 1 workloads. Enable Hard limits for workloads in all tiers. Note: It is recommended that hard limits be set no lower than 3% if only a single workload has a limit or no lower than 5% if multiple workloads have limits. Delete the tier Next to the lowest tier name, click. Tier 1 can never be deleted. Only tiers that do not contain workloads can be deleted. Only the lowest tier can be deleted. If the lowest tier does not contain workloads, the tier is automatically deleted when you save the tab settings. 7 [Optional] Under Timeshare, drag a workload from one access level to another to assign the priority of resource allocation for queries in the workload. 8 Click Save. 60 Preparing to Move from SLES 10 to SLES 11

61 Chapter 5 After the Upgrade Using the Workload Designer Portlet to Refine Migration Results SLES 11 Adjusting Tactical Workload Exceptions In SLES 11, when you create a tactical workload, a tactical exception is automatically created to prevent a high-consuming query from depriving tactical workloads of system resources. Tactical exceptions cannot be deleted, but you can modify them if your environment has different needs. Tactical exceptions occur when both threshold criteria are exceeded for either Tactical CPU Time or Tactical I/O Physical Byte. Tactical exceptions trigger an action that moves a highconsuming query to another workload and can trigger other actions, such as issuing an alert or running a program. Tactical exceptions apply to the tactical workloads they are associated with, across all environments. 1 From the ruleset toolbar, click Workloads. 2 Select or create a tactical workload. 3 Click the Tactical Exception tab. 4 Under Criteria, enter thresholds for Tactical CPU Time and Tactical I/O Physical Byte. 5 Under Action, select a workload. Preparing to Move from SLES 10 to SLES 11 61