Introducing IBM Tivoli Service Level Advisor Sg246611

Front cover
Introducing IBM Tivoli Service Level Advisor

Achieve proactive SLA management ensuring service quality Generate reports and identify trends toward SLA violations Manage Service Level and meet customer expectations
Edson Manoel J.B. Baker Filippo Giannelli Frans Sadie Sarie Weber
ibm.com/redbooks
International Technical Support Organization Introducing IBM Tivoli Service Level Advisor July 2002
SG24-6611-00
Take Note! Before using this information and the product it supports, be sure to read the general information in Notices on page xvii.
First Edition (July 2002) This edition applies to the IBM Tivoli Service Level Advisor Version 1.1 and Tivoli Enterprise Data Warehouse Version 1.1 products. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 2002. All rights reserved. Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Part 1. All about IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 IT Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Service Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Ensuring service quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 Service Level Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.6 Why bother with Service Level Management . . . . . . . . . . . . . . . . . . . . . . 14 Chapter 2. IBM Tivoli Service Level Advisor general overview . . . . . . . . 17 2.1 Overview of IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . 18 2.2 IBM Tivoli Service Level Advisor components . . . . . . . . . . . . . . . . . . . . . 19 2.2.1 ITSLA Task Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.2 ITSLA Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.3 ITSLA Reports Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.4 ITSLA Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.5 Tivoli Enterprise Data Warehouse Server . . . . . . . . . . . . . . . . . . . . . 25 2.2.6 Tivoli Enterprise Data Warehouse Control Center . . . . . . . . . . . . . . 25 2.2.7 IBM Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.8 ITSLA ETL programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3 Important ITSLA concepts and terminology . . . . . . . . . . . . . . . . . . . . . . . 26 2.4 A glimpse into Tivoli Enterprise Data Warehouse . . . . . . . . . . . . . . . . . . . 34 2.5 IBM Tivoli Service Level Advisor Target ETLs . . . . . . . . . . . . . . . . . . . . . 37 2.5.1 ITSLA Registration ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.5.2 ITSLA Process ETL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.6 The SLA Management process of ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . 40
Copyright IBM Corp. 2002
iii
2.6.1 Step 1: Define and agree on Service Level Agreements . . . . . . . . . 42 2.6.2 Step 2: Select applications for source data . . . . . . . . . . . . . . . . . . . . 43 2.6.3 Step 3: Populate the ITSLA Database . . . . . . . . . . . . . . . . . . . . . . . 43 2.6.4 Step 4: Define schedules and create offerings . . . . . . . . . . . . . . . . . 43 2.6.5 Step 5: Define customers and create orders. . . . . . . . . . . . . . . . . . . 44 2.6.6 Step 6: Populate the ITSLA Measurement Data Mart database . . . . 44 2.6.7 Step 7: Evaluate data for violations and trends. . . . . . . . . . . . . . . . . 45 2.6.8 Step 8: Notification of SLA violations and trends . . . . . . . . . . . . . . . 45 2.6.9 Step 9: Access SLA reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.7 Applications providing measurement data . . . . . . . . . . . . . . . . . . . . . . . . 46 2.7.1 Becoming an ITSLA-enabled application . . . . . . . . . . . . . . . . . . . . . 46 Chapter 3. Implementation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.1 IBM Tivoli Service Level Advisor data flow . . . . . . . . . . . . . . . . . . . . . . . . 53 3.2 Planning for supporting applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.1 IBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.2 IBM DB2 Universal Database Enterprise Edition . . . . . . . . . . . . . . . 57 3.2.3 Tivoli Enterprise Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.3 Planning for IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . 61 3.3.1 Physical considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.3.2 Architecture considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.3.3 Planning considerations for source applications . . . . . . . . . . . . . . . . 69 3.4 Planning for event notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.4.1 SNMP Trap notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.4.2 TEC Event notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.4.3 E-mail notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.5 Planning worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Chapter 4. Getting IBM Tivoli Service Level Advisor up and running . . . 79 4.1 Example scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.2 Setting up the TEDW Server machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2.1 IBM DB2 UDE Server for UNIX installation . . . . . . . . . . . . . . . . . . . . 82 4.2.2 TEDW Central Warehouse and TEDW Data Mart installation . . . . . 86 4.3 Setting up the ITSLA Database Server machine. . . . . . . . . . . . . . . . . . . . 88 4.3.1 Creating the ITSLA Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.4 Setting up the TEDW Control Center machine . . . . . . . . . . . . . . . . . . . . . 90 4.4.1 IBM DB2 UDE Server for Windows installation . . . . . . . . . . . . . . . . . 91 4.4.2 Tivoli Enterprise Data Warehouse Control Center installation . . . . . 92 4.4.3 ITSLA ETL programs installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.4.4 Source ETLs installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.4.5 TEDW Control Center basic configuration . . . . . . . . . . . . . . . . . . . 100 4.4.6 Configuring the ODBC connections . . . . . . . . . . . . . . . . . . . . . . . . 103 4.5 Setting up the ITSLA Server machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
iv
4.5.1 IBM DB2 Client installation on AIX . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.5.2 Cataloging the ITSLA Databases . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.5.3 TEDW Reports Interface installation . . . . . . . . . . . . . . . . . . . . . . . . 109 4.5.4 ITSLA Server component installation . . . . . . . . . . . . . . . . . . . . . . . 113 4.5.5 ITSLA Task Drivers installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.6 Setting up the ITSLA Reports machine . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.6.1 IBM WebSphere installation and configuration . . . . . . . . . . . . . . . . 127 4.6.2 ITSLA Reports Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Chapter 5. Administering IBM Tivoli Service Level Advisor . . . . . . . . . . 133 5.1 Source ETLs management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.1.1 ETL Warehouse Target and Sources configuration . . . . . . . . . . . . 134 5.1.2 Schedule and run Source ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5.2 Target ETLs management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 5.2.1 Registration Target ETL management . . . . . . . . . . . . . . . . . . . . . . 142 5.2.2 Process Target ETL management . . . . . . . . . . . . . . . . . . . . . . . . . 150 5.3 User creation and management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 5.3.1 IBM SLA Console user management . . . . . . . . . . . . . . . . . . . . . . . 158 5.3.2 ITSLA Report users management. . . . . . . . . . . . . . . . . . . . . . . . . . 163 5.4 Management of ITSLA components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.4.1 Management of offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.4.2 Management of orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 5.5 Timing considerations for the ITSLA environment . . . . . . . . . . . . . . . . . 193 5.5.1 Scheduling ETLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 5.5.2 ITSLA evaluation schedule and time zone considerations . . . . . . . 195 5.6 Trace and message log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 5.6.1 Handler configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 5.6.2 Message log files management . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 5.6.3 Trace log files management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 5.7 Startup and shutdown procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 5.7.1 IBM Tivoli Service Level Advisor components startup . . . . . . . . . . 205 5.7.2 ITSLA components shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 5.8 Backup and restore of ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 5.8.1 Backing up the ITSLA environment. . . . . . . . . . . . . . . . . . . . . . . . . 210 5.8.2 Restoring the ITSLA environment . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Chapter 6. Service level Reports with ITSLA . . . . . . . . . . . . . . . . . . . . . . 217 6.1 Logging into Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 6.1.1 Default Reports users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 6.1.2 The Ranking algorithm and categories . . . . . . . . . . . . . . . . . . . . . . 221 6.2 Using Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 6.2.1 Reporting categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 6.2.2 Viewing Reports using different search criteria . . . . . . . . . . . . . . . . 229
Contents
6.2.3 Additional features of Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 6.3 Administrating Reports users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 6.3.1 Creating Reports users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 6.3.2 Listing and deleting Reports users . . . . . . . . . . . . . . . . . . . . . . . . . 239 6.3.3 Disabling Reports user authentication . . . . . . . . . . . . . . . . . . . . . . 240 6.4 Reports customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 6.4.1 Integrating Reports with existing Web sites . . . . . . . . . . . . . . . . . . 242 6.4.2 Customizing the appearance of Reports . . . . . . . . . . . . . . . . . . . . . 250 6.4.3 Alternative methods for authenticating users . . . . . . . . . . . . . . . . . 255 6.5 Viewing Reports with third-party software . . . . . . . . . . . . . . . . . . . . . . . . 257 6.5.1 Using BrioQuery Designer with Reports . . . . . . . . . . . . . . . . . . . . . 257 6.5.2 Viewing Reports using Seagate Crystal Reports . . . . . . . . . . . . . . 269 6.5.3 Using BusinessObjects with Reports . . . . . . . . . . . . . . . . . . . . . . . 277 Chapter 7. Performance maximization techniques . . . . . . . . . . . . . . . . . 289 7.1 Initial considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 7.2 ITSLA Database Server tuning considerations . . . . . . . . . . . . . . . . . . . . 291 7.3 IBM DB2 Performance tuning considerations . . . . . . . . . . . . . . . . . . . . . 291 7.3.1 Small environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 7.3.2 Medium environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 7.3.3 Large environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 7.4 IBM WebSphere performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 7.5 IBM HTTP Server performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 295 7.6 Presentation Services Web Console tuning . . . . . . . . . . . . . . . . . . . . . . 295 7.6.1 Medium environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 7.6.2 Large environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 7.7 Operating system performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 296 7.7.1 Windows environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 7.7.2 AIX environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Chapter 8. Troubleshooting the ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 8.1 IBM DB2 Universal Database Enterprise Edition . . . . . . . . . . . . . . . . . . 300 8.1.1 Installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 8.1.2 Databases creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 8.1.3 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 8.1.4 Important initial IBM DB2 commands . . . . . . . . . . . . . . . . . . . . . . . 311 8.2 Tivoli Enterprise Data Warehouse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 8.2.1 TEDW installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . 312 8.2.2 TEDW administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 8.3 IBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 8.3.1 Installation and configuration issues . . . . . . . . . . . . . . . . . . . . . . . . 315 8.3.2 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 8.4 IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
vi
8.4.1 Installation issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 8.4.2 Configuration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 8.4.3 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 8.4.4 Un-installation issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 8.5 IBM Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 8.5.1 Logon problems (UNIX platforms). . . . . . . . . . . . . . . . . . . . . . . . . . 338 8.5.2 Administration problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 8.6 TEDW Source ETLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 8.6.1 Installation issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 8.6.2 Configuration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 8.6.3 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 8.7 IBM Tivoli Service Level Advisor Reports . . . . . . . . . . . . . . . . . . . . . . . . 344 8.7.1 Accessing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 8.7.2 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 8.7.3 Workarounds for ITSLA Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Part 2. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Appendix A. Hints and tips for un-installing ITSLA . . . . . . . . . . . . . . . . . 353 Un-installing the ITSLA core components . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Un-installing ITSLA Task Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Un-installing ITSLA Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Un-installing ITSLA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Un-installing the ITSLA Target ETL programs . . . . . . . . . . . . . . . . . . . . . . . . 359 Remove the ITSLA Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Un-installing the support applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Appendix B. Service Management according to the ITIL . . . . . . . . . . . . 365 The ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Service Delivery disciplines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Availability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Cost Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 Contingency Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Measuring service quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 The role of Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . 385 The objectives of Service Level Management . . . . . . . . . . . . . . . . . . . . . 386 Specifying service levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Service Support disciplines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Help Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Contents
vii
Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Software Control and Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Appendix C. IBM Tivoli Service Level Advisor Databases . . . . . . . . . . . 403 The ITSLA Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 The ITSLA Measurement Data Mart database. . . . . . . . . . . . . . . . . . . . . . . . 407 Appendix D. Command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Introduction to the ITSLA CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 General usage overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Default bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Basic CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Useful commands for ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 ETL commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Offering and order commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Escalation commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Appendix E. Source ETLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Introduction to the Source ETLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 IBM Tivoli Business Systems Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 TBSM Source ETL objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 TBSM Source ETL process description . . . . . . . . . . . . . . . . . . . . . . . . . . 421 TBSM Source ETL measurement types . . . . . . . . . . . . . . . . . . . . . . . . . . 421 IBM Tivoli Enterprise Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 TEC Source ETL objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 TEC Source ETL processes descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 422 TEC Source ETL measurement types . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 IBM Tivoli Monitoring for Transaction Performance (TWSM) . . . . . . . . . . . . . 423 TWSM Source ETL objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 TWSM Source ETL processes description . . . . . . . . . . . . . . . . . . . . . . . . 424 TWSM Source ETL measurement types. . . . . . . . . . . . . . . . . . . . . . . . . . 425 IBM Tivoli Distributed Monitoring (DM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 DM Source ETL objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 DM Source ETL processes descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 425 DM measurement types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Related publications . . . . . . . . . . . . . . . . . . . . . . IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other resources . . . . . . . . . . . . . . . . . . . . . . . . Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . IBM Redbooks collections . . . . . . . . . . . . . . . . . ...... ...... ...... ...... ...... ...... ....... ....... ....... ....... ....... ....... ...... ...... ...... ...... ...... ...... . . . . . . 429 429 429 430 431 431
viii
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Contents
ix
Figures
1-1 1-2 1-3 1-4 1-5 1-6 2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 3-1 3-2 4-1 4-2 4-3 4-4 4-5 4-6 4-7 4-8 4-9 4-10 4-11 4-12 4-13 4-14 4-15 4-16 4-17 4-18 4-19 4-20 4-21 IT Service perceived by the end user and in reality . . . . . . . . . . . . . . . . . 6 Service Delivery life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Service Delivery in context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Point-solution based management infrastructure . . . . . . . . . . . . . . . . . 10 Customer, service provider, and service management . . . . . . . . . . . . . 11 Service Level Management iterative process . . . . . . . . . . . . . . . . . . . . 12 ITSLA core and logical components relationship . . . . . . . . . . . . . . . . . . 20 ITSLA Database component access . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 ITSLA Measurement Data Mart access . . . . . . . . . . . . . . . . . . . . . . . . . 24 A typical TEDW environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 ITSLA Registration ETL process model . . . . . . . . . . . . . . . . . . . . . . . . . 38 ITSLA Process ETL process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 How TSLA collects and stores measurement data . . . . . . . . . . . . . . . . 40 End-to-Eend SLA Management process flow . . . . . . . . . . . . . . . . . . . . 41 A typical Service Level Management process flow . . . . . . . . . . . . . . . . 42 ITSLA data flow scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 ITSLA architecture component placement . . . . . . . . . . . . . . . . . . . . . . . 65 Installation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Install DB2 V7 - DB2 UDB Enterprise Edition . . . . . . . . . . . . . . . . . . . . 83 Create DB2 Services - DB2 Instance db2inst1 . . . . . . . . . . . . . . . . . . . 84 Administration Server screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Install type dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Select features dialogue window - TEDW Central Data Warehouse . . . 87 TEDW Central Data Warehouse and Data Mart installation . . . . . . . . . 88 Select DB2 Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Select features dialogue window - TEDW control server . . . . . . . . . . . . 93 TEDW control server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Path to the installation media for the ITSLA ETL programs . . . . . . . . . . 96 ITSLA ETL programs installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 TEDW Source ETLs setup type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Path to the installation media for the application packages . . . . . . . . . . 99 TEDW Source ETLs installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 TWH_MD as control database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 DYK_PROC_DYK_DM_TARGET user ID information . . . . . . . . . . . . 102 ODBC configuration - System DSN tab . . . . . . . . . . . . . . . . . . . . . . . . 103 Install DB2 V7 - DB2 Administration Client . . . . . . . . . . . . . . . . . . . . . 107 Create DB2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Install type dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
xi
4-22 4-23 4-24 4-25 4-26 4-27 4-28 4-29 4-30 4-31 4-32 4-33 4-34 4-35 4-36 4-37 4-38 4-39 4-40 4-41 4-42 5-1 5-2 5-3 5-4 5-5 5-6 5-7 5-8 5-9 5-10 5-11 5-12 5-13 5-14 5-15 5-16 5-17 5-18 5-19 5-20 5-21 5-22
Select features dialogue window - TEDW Report Interface . . . . . . . . . 110 Tivoli Presentation Services ports panel . . . . . . . . . . . . . . . . . . . . . . . 111 TEDW Report Interface installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 ITSLA Server component installation. . . . . . . . . . . . . . . . . . . . . . . . . . 114 ITSLA Database dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 ITSLA Measurement Data Mart database dialogue window . . . . . . . . 116 Port information for the ITSLA Server installation . . . . . . . . . . . . . . . . 117 ITSLA event notifications window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Configuring SNMP Trap event notification . . . . . . . . . . . . . . . . . . . . . . 119 Configuring Tivoli Enterprise Console event notification . . . . . . . . . . . 120 Configuring e-mail notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Configuring e-mail notification - Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . 122 ITSLA Server installation confirmation window . . . . . . . . . . . . . . . . . . 123 ITSLA Task Drivers component installation . . . . . . . . . . . . . . . . . . . . . 124 ITSLA Task Drivers communication ports . . . . . . . . . . . . . . . . . . . . . . 125 ITSLA Task Drivers installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 IBM WebSphere Application Server configuration panel . . . . . . . . . . . 128 IBM WebSphere configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 ITSLA Reports component installation. . . . . . . . . . . . . . . . . . . . . . . . . 130 Specify a node name for you ITSLA Report Server . . . . . . . . . . . . . . . 131 ITSLA Report Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Properties window of Warehouse Sources . . . . . . . . . . . . . . . . . . . . . 135 Tables of Warehouse Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Processes folder of TAPM Subject Areas . . . . . . . . . . . . . . . . . . . . . . 139 Set to Production mode TAPM Source ETL steps . . . . . . . . . . . . . . . . 141 Select schedule for Registration ETL. . . . . . . . . . . . . . . . . . . . . . . . . . 145 Registration ETL Schedule window . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Work in Progress selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Immediately run the first step of the Registration ETL . . . . . . . . . . . . . 148 See log information for failed ETL Registration step . . . . . . . . . . . . . . 149 Configuration of Notification for the Registration ETL . . . . . . . . . . . . . 150 Select Schedule for Process ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Define Schedule for Process ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Start Work in Progress tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Manually run the first step of the Process Target ETL . . . . . . . . . . . . . 155 Start Notification dialogue for Process ETL . . . . . . . . . . . . . . . . . . . . . 156 IBM Web Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 User creation task in the General window . . . . . . . . . . . . . . . . . . . . . . 161 Service offering specialist role selection . . . . . . . . . . . . . . . . . . . . . . . 162 IBM Console starting page for service offering specialist user . . . . . . 163 Log in with user Sawyer to ITSLA Reports . . . . . . . . . . . . . . . . . . . . . 166 Manage Offerings window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Create Schedule window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
xii
5-23 5-24 5-25 5-26 5-27 5-28 5-29 5-30 5-31 5-32 5-33 5-34 5-35 5-36 5-37 5-38 5-39 5-40 5-41 5-42 5-43 5-44 5-45 5-46 5-47 6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 6-10 6-11 6-12 6-13 6-14 6-15 6-16 6-17 6-18
Create Period window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Select Schedule window with a new schedule defined . . . . . . . . . . . . 172 Resource Type tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Select QoS ROUNDTRIPTIME metric to configure . . . . . . . . . . . . . . . 174 SLO Configuration dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Configuration dialogue window for SLO breach values . . . . . . . . . . . . 177 Create Customized Offering Components window . . . . . . . . . . . . . . . 178 Confirm Offering window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Manage Orders window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Select Customer dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Create Customer window with a new realm defined . . . . . . . . . . . . . . 182 Select Customer dialogue window with new customer defined . . . . . . 183 Assign Resources to order offering component . . . . . . . . . . . . . . . . . . 184 Include Resources dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Select Resource Definition Type dialogue window . . . . . . . . . . . . . . . 186 Select Resources window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Include Resources window with a new component defined. . . . . . . . . 188 Assign Resources window with a complete offering component . . . . . 189 The Manage Orders screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 SLA State screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 View Violation screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Data Flow in the ITSLA environment . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Configure logging for IBM Console environment . . . . . . . . . . . . . . . . . 199 Properties dialogue window for tracing handler . . . . . . . . . . . . . . . . . . 200 Enable trace logging on the IBM Console . . . . . . . . . . . . . . . . . . . . . . 204 Reports sign-on screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Customer user view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Executive user view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Operations user view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Operations user ranking categories . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Trends Report screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Violations Report screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Results Report screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Time Period drop-down menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 SLA Type drop-down menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 The Search field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Maximum rows to display feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Additional Web links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Report graph using Results Report category . . . . . . . . . . . . . . . . . . . . 236 Graph Data page view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 BrioQuery Database Connection Wizard . . . . . . . . . . . . . . . . . . . . . . . 259 Query screen for DYK_CAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Dragging Violationview to the Content window . . . . . . . . . . . . . . . . . . 261
Figures
xiii
6-19 6-20 6-21 6-22 6-23 6-24 6-25 6-26 6-27 6-28 6-29 6-30 6-31 6-32 6-33 6-34 6-35 6-36 6-37 6-38 6-39 6-40 6-41 6-42 6-43 6-44 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8 B-9 B-10
Adding the selected items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Limiting the items for query processing . . . . . . . . . . . . . . . . . . . . . . . . 263 Query results for limited Violationview . . . . . . . . . . . . . . . . . . . . . . . . . 264 New report screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Report results table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Two-dimensional graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Three-dimensional graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Report gallery with Custom button selected . . . . . . . . . . . . . . . . . . . . 270 Choose SQL Table window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Insert fields and report design page. . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Select Expert being used to limit the violation dates . . . . . . . . . . . . . . 273 The preview screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Chart Expert box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 The Data tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Report preview screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Define Universe Parameters window . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Parameters of database connection window . . . . . . . . . . . . . . . . . . . . 279 Second step of Universe creation process . . . . . . . . . . . . . . . . . . . . . 280 Select Universe as data access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Query Panel - Report for SLA violations Universe . . . . . . . . . . . . . . . . 282 Business Object Report for max violations . . . . . . . . . . . . . . . . . . . . . 283 Apply templates to report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 BusinessObject customized report . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Create a condition in a BusinessObjects query . . . . . . . . . . . . . . . . . . 286 List of consumer names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 BusinessObjects window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 The Service Management disciplines . . . . . . . . . . . . . . . . . . . . . . . . . 368 Key relationships among Service Management disciplines . . . . . . . . . 371 Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 Service Delivery quality perception . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Levels of service and customer satisfaction . . . . . . . . . . . . . . . . . . . . 384 Service level specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Incident priority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Cycles of change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 The Change Advisory Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 The SC&D process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
xiv
Tables
3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 3-9 3-10 3-11 4-1 4-2 4-3 5-1 5-2 5-3 5-4 5-5 5-6 5-7 5-8 5-9 5-10 6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 7-1 8-1 8-2 8-3 C-1 Default TCP/IP port numbers used by the TEDW . . . . . . . . . . . . . . . . . 60 Ports used by the ITSLA components . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Hardware requirements for ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Single machine installation hardware requirements for ITSLA . . . . . . . 63 Software requirements for ITSLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 ITSLA Web browser support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Supported source Tivoli applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Planning worksheet for IBM WebSphere Application Server . . . . . . . . . 76 Planning worksheet for databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Planning worksheet for ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Planning worksheet or event notification . . . . . . . . . . . . . . . . . . . . . . . . 78 ITSLA Databases installation scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Measurement source codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Tivoli source databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 IBM Tivoli source application and Warehouse Source and Targets . . 134 Subject Areas and related Tivoli applications . . . . . . . . . . . . . . . . . . . 138 IBM SLA roles and associated tasks on the IBM Web Console . . . . . 159 View values and authorization levels for Report users . . . . . . . . . . . . 164 User manipulation commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Local times for SLA evaluation and peak period start times . . . . . . . . 196 Locations of message log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Available ITSLA trace loggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Commands to start ITSLA components . . . . . . . . . . . . . . . . . . . . . . . . 206 Commands to shutdown ITSLA components. . . . . . . . . . . . . . . . . . . . 208 Users and associated ranking categories . . . . . . . . . . . . . . . . . . . . . . 223 Included JSP files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Available query and display classes . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Available filter parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Available input field names for searching . . . . . . . . . . . . . . . . . . . . . . 248 Available parameters for maximum rows to display. . . . . . . . . . . . . . . 250 Customizable table column parameters. . . . . . . . . . . . . . . . . . . . . . . . 251 Customizable table properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Customizable graph properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Definition of small, medium, and large ITSLA environment . . . . . . . . . 290 /etc/systems parameters on Sun Solaris . . . . . . . . . . . . . . . . . . . . . . . 301 Parameters for a Sun Solaris IBM DB2 server . . . . . . . . . . . . . . . . . . 302 IBM DB2 command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 DYK_CAT database tables for the DB2ADMIN schema . . . . . . . . . . . 404
xv
C-2 C-3 C-4 D-1 D-2
DYK_CAT database tables for the MM schema . . . . . . . . . . . . . . . . . 405 DYK_CAT database views for the DB2ADMIN schema . . . . . . . . . . . 406 DYK_DM database tables for the DYK schema . . . . . . . . . . . . . . . . . 407 Order commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Offering commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
xvi
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.
xvii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX DB2 DB2 Universal Database IBM Informix Netfinity NetView Perform pSeries Redbooks Redbooks(logo) RETAIN RS/6000 SP SP2 Tivoli Tivoli Enterprise Tivoli Enterprise Console TME WebSphere xSeries
The following terms are trademarks of International Business Machines Corporation and Lotus Development Corporation in the United States, other countries, or both: Lotus Notes Word Pro
The following terms are trademarks of other companies: ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.
xviii
Preface
IBM Tivoli Service Level Advisor Version 1.1 is a Service Level Management solution for providers of IT Services. It simplifies and automates the process of managing service level agreements, enabling IT organizations to proactively manage and report on service levels from across the management infrastructure. In a nutshell, IBM Tivoli Service Level Advisor Version 1.1 enables you to: Define services from a user perspective, including response time and availability metrics. Automate service level agreement validation and receive alerts for service level agreement violations. Identify and fix performance and availability problems before they occur. Provide flexible, Web-based reports to clients, executives, and IT staff. The primary objective of this Redbook is to introduce the new IBM Tivoli offering for defining and managing service level agreements, and is targeted at the technical professional responsible for providing services in an IT organization. It can be used as a reference book upon the deployment of IBM Tivoli Service Level Advisor Version 1.1 guiding you during the planning, installation, configuration, administration, and troubleshooting, as well as general product usage phases, with focus on how to effectively deploy this product in a way that quickly generates real business value for customers. This redbook is a valuable addition to existing product documentation and should be read in conjunction with the official product documentation, which complements some of the concepts explained in this book. General knowledge of the Tivoli Framework, general Tivoli applications, Business Intelligence and database implementation, and Web application servers is assumed.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center.
xix
Edson Manoel is a Software Engineer at IBM Corporation - International Technical Support Organization, Austin Center. He applies his extensive field experience as an IT Specialist to his work at the ITSO in the Systems Management area. Prior to joining the ITSO, Edson worked in the IBM Software Group as a Tivoli Technology Ambassador and in IBM Brasil Professional Services Organization as a Certified IT Specialist. He was involved in numerous projects, designing and implementing systems management solutions for IBM customers and Business Partners. Edson holds a BSc degree in Applied Mathematics from Universidade de Sao Paulo, Brazil. J.B. Baker is a Software Engineer for the IBM Tivoli Software Group in Research Triangle Park, North Carolina. He holds a degree in Psychology and Anthropology from the University of North Carolina at Chapel Hill. Upon graduation, he joined IBM in 1999 where he served as a Systems Administrator for the e-Business Web Content Hosting Group, until joining IBM Tivoli in 2000. He is a Cisco Certified Network Associate and is currently pursuing a Certification for Information System Security Professional (CISSP). Filippo Giannelli is an IT Specialist at IBM Integrated Technology Services, Italy. He has three years of experience in the Information Technology field. He has worked at IBM for three years. He holds a Masters degree in Electronic Engineering from Universita La Sapienza in Rome. His areas of expertise include the architecture and implementation of Tivoli Solutions in the Configuration and Operation area, in the Application Management area, and the Web Services, Management area. Frans Sadie is an Advisory IT Specialist at IBM Integrated Technology Services, South Africa. He has six years of experience in the Information Technology field. He holds a Bachelors of Commerce degree in Industrial Psychology from the Rand Afrikaans University and a Honours Bachelors of Commerce Degree in Business Management from the University of South Africa. His areas of expertise include the architecture, design, and implementation of Tivoli systems management solutions, as well as business process design and re-engineering. His product experience includes the Tivoli Core products and the Tivoli Manager for product suite on the AIX and Windows platforms. He is a Certified Tivoli Consultant in Tivoli Framework, Tivoli Inventory, and Tivoli Distributed Monitoring. Sarie Weber is an IT Specialist from Pretoria, South Africa. She joined IBM South Africa in 1997 and is currently working in IBM Integrated Technology Services. She has experience in the Information Technology field. She holds a Honours BSc degree in Computer Science from the Potchefstroom University. Her areas of expertise include the Tivoli range of core products, AIX, and Windows. She is certified in Tivoli Framework, Tivoli Distributed Monitoring, and Tivoli Inventory.
xx
Thanks to the following people for their contributions to this project: International Technical Support Organization, Austin Center Bart Jacob, Morten Moeller, Chris Blatchley, Julie Czubik IBM Tivoli Service Level Advisor Development, Performance, and Quality Assurance teams Kathy Hebblethwaite, Bryan Ellington, Ping Chang, Jayne Regan, Chris Karstens, Kevin Kuhner, Eswara Kosaraju, Steve Tremper, Brian Jeffrey IBM Tivoli Early Support Programs Jon O Austin and Gary Forghetti IBM Tivoli Market Management Business Impact & Event Solutions Michael Tabron IBM Tivoli Worldwide Sales Enablement David Hobbs Technical Evangelism, EMEA Product Management Lewis Troke
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
Preface
xxi
We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:

redbook@us.ibm.com
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493
xxii
Part 1
Part
All about IBM Tivoli Service Level Advisor

In this part we provide a great deal of information on all aspects of IBM Tivoli Service Level Advisor concepts, architecture, planning, installation, configuration, product administration, and product usage.
Chapter 1.
Introduction
The primary topics of the discussions in this chapter are the principles behind Service Level Management from an IT Service Delivery organization standpoint, as close as possible to those presented in the Information Technology Infrastructure Library (ITIL) published by the British governments Central Computing and Telecommunications Agency (CCTA), and from those in the context of the IBM approach to Service Level Management with IBM Tivoli Service Level Advisor. This chapter contains the following topics: IT Services Service Delivery Service Management Service Level Management Service Level Agreements
1.1 Overview
In the context of delivering services in a complex IT environment, accomplishing a high level of customer satisfaction requires the IT function of an organization to have a full understanding of and insight into the different aspects of its operation and performance in terms of efficiency and effectiveness. When the IT organization fails to ensure operational performance the business may turn to an outsourcer that may quickly, accurately, and economically meet its needs. To prevent this defection, an IT organization must improve service delivery while spending less money. Service Level Management can offer IT organizations the ability to deliver the level of service that will keep their businesses competitive. Running a customer focused, cost conscious information technology (IT) organization is not an easy task. Today an increasing number of businesses are putting pressure on their IT departments to think of themselves as competitive corporate allies. This originates primarily from three main reasons: 1. Desire to reduce costs Businesses are constantly seeking ways to reduce costs, and IT costs are not immune. This has given rise to an increasing number of outsourcing service providers, each promising to deliver reliable service while off-loading the costly burdens of staffing, procuring, and maintaining an IT organization. Enterprises that do not outsource are demanding more accountability from their IT organizations as well as demanding that IT aligns with business goals, not the other way around. In both cases, there is the concept of a service level agreement, which represents a contract of service delivery between IT and its customers. As a result, IT departments need management services that focus on and support business processes and service delivery rather than just simple monitoring of the IT resources, such as disk space monitoring and server availability. 2. Use of IT Services to gain a competitive advantage Businesses have recognized that electronic and online services can be a significant competitive weapon. Beating competition is almost always achieved through speed to market. Therefore IT teams need to be able to respond quickly in deploying services such as online procurement, consumer purchasing mechanisms, and supply-chain delivery in response to the aggressive goals of their companies.
Given that there often are significant amount of money at risk (win if the IT department deploys successfully, and lose if the services become unavailable or inaccessible) there must be a flexible but very robust set of management tools and services deployed as part of the IT infrastructure. Systems like this involve networks, servers, and application management to succeed, as well as focus on the overall service delivery. 3. Increased pace of change Competition continues to quicken the pace of change. As companies turn more and more to the network in order to market, sell, and deliver their products and services, they must now focus on quick delivery from IT. These requirements force IT organizations to continuously improve productivity and reduce costs while maintaining and delivering a consistent high level of service. IT organizations are being forced to improve alignment with their internal customers and developing a competitive mind set using the concept of Service Level Management. Service Level Management can also provide the tool that enables IT to match the service delivered to the real business need. Before jumping into the details of Service Level Management, we will take a look at the concepts of IT Services, Service Delivery, and Service Management. We will stay as close as possible to the definitions provided by the ITIL, as it provides the best practices for the management of an IT infrastructure. Appendix B, Service Management according to the ITIL on page 365, provides a great deal of information on service management in terms of the ITIL.
1.2 IT Services
For the purpose of the current discussion, the following definition of IT Service will be used in this redbook: A set of related functions provided by IT systems that supports one or more business areas and facilitates the achievement of corporate objectives and business goals in a timely and cost-effective manner. This service can be made up of IT and non-IT facilities and fulfills one or more needs of the customer. Such services should be perceived by the customers as being a self-contained, coherent whole. Examples are software, hardware, and communication facilities. Figure 1-1 on page 6 shows a customer receiving IT Services without realizing that there is an entire structure in place working together in order to fulfill the customers requirements.
Chapter 1. Introduction
Monitoring
Troubleshooting
Implementing
IT Services
Planning
Customer
Figure 1-1 IT Service perceived by the end user and in reality
There are a couple of questions that come from the above definition: Who does provide the service? In order to provide a service in a timely and cost-effective manner, the service provider is required to provide all the equipment, skills, procedures, and documentation required to support the service, and ensure that the service is reliable, efficient, and correct. This may be very costly and resource-consuming to overcome, so instead of realizing all of the above within the IT department, more and more companies choose to acquire one or more sub-services from external providers. In this case the IT department is still the service provider to the users, but the IT department itself may be also be the receiver the true provider of the service. This lets us know that a service can rely on other services and still be perceived by the end receiver of the service as a hole entity. Who pays for the service? Another question raised by the definition is that of accountability. The word service suggests that the users of the service are customers, and this in turn suggests that the service provider is paid to provide the service. In the context of IBM Tivoli Service Level Advisor, a customer is a party that enters into an agreement with the service provider on the level the service will be delivered.
Customers can be given access to the results of those agreements. Customers can be internal (members of a department within the enterprise) or external (a member, department, or company) associated with a service provider.
1.3 Service Delivery

Delivering an IT Service requires careful planning of deploying, monitoring, supporting, and reporting. The main motivation to perform all these tasks is that customers expectations must be met. This also supports the decision-making while planning the service delivery. The actual execution of the tasks is taken care of by processes in the Service Support area. However, the responsibility of ensuring that the required infrastructure, capacity, and operational procedures are in place lies within the Service Delivery area. Refer to Service Delivery disciplines on page 371 for additional details. The IT Service Delivery life cycle does not vary from that of other services. See Figure 1-2.
Service Delivery
an an P Pl
lv sso Di e
STO P
t t or po ep Re
Figure 1-2 Service Delivery life cycle
an an P Pl
y plo De
Plan
Service Support
Once the various components have been deployed they must be monitored to verify that the targets are met. If this is not the case, corrections have to be applied in order to meet the targets, and of course it must be verified that the corrections have no impacts other than those anticipated. Pro-active monitoring of the components is not the only way of identifying problems that might put the service delivery in jeopardy. The end users play an important role by reporting irregularities and disturbances to the Service Delivery. A Help Desk must be established to receive, register, and (if possible) answer calls from end users, which are often known as incidents. If no solution to the problem is available, the Problem Management processes will be used to provide one. In addition to problems reported by end users, the Help Desk may also receive incidents generated by the tools monitoring the components that make up a service. Most of these automatically generated incidents can be associated with well-known solutionstasks recovering or circumventing the problematic situation. Some of these well-known solutions may be invoked automaticallyeither directly by the monitoring tools generating the incident, or by the tools used by the Help Desk. Other incidents may require manual intervention or authorization before the well-known solutions can be applied. Finally, the last group of incidents has no known solutions associated with them. These incidents are handled by the Help Desk and passed on to Problem Management for problem diagnosis and resolution, Change Management for authorization, and finally to the group responsible for deploying the change for implementation.
problem
Help Desk
incident solution Change request
change
Delivery report
Problem Management
Approved Change request
Software Delivery & Control
Change Management
Figure 1-3 Service Delivery in context
It is evident that in order to keep a consistently high level of any service, changes that effect the providers ability to deliver the service must be authorized, planned, and executed thoroughly. The service provider must have procedures in place to help assess the impact of a change to any component in the service hierarchy. Also, procedures to apply the changes securely and to verify that the change actually had the desired impact are needed.
1.4 Ensuring service quality

Providing a service requires a dedicated and focused infrastructure consisting of hardware, software, communication equipment and facilities, documentation, and skills required to support the provision of the IT Service. In order to monitor the components of a service, general and/or service-specific monitoring tools have to be deployed either as an integral part of the service deployment or as independent, self-contained service. These monitors are typically implemented as part of the service components themselves or as integral part of component-specific tools used to manage the components. The capabilities of the monitoring tools mayor may notsupport management and operation of the service from, and reporting to, a central command center. This functionality, however, is a necessity when delivering services, partly because of the need to allow the support staff to fulfill their mission, and partly to enable centralized diagnosis and reporting of all the components of a service.
In other words, an extra layer of service has to be established in order to provide functions and facilities that enable managing of the service from a central command center. These functions must include monitoring, event forwarding and escalation, measurement data gathering, and status reporting from the service components, and allow for operation and configuration of the components from the central command center. This service layer is called the management services layer.
Server Service Server Service Server Service I Server System Mgmt. Subsystem Server System Mgmt. Subsystem Service I System Mgmt. Tools
monitoring events reporting service III service II service I service III operation configuration service II service I
Client System Mgmt. Subsystem Client System Mgmt. Subsystem Client I System Mgmt. Tools Client Service Client Service Client Service I
Figure 1-4 Point-solution based management infrastructure
It goes without saying that the general management service of choice must be so versatile that the majority ofif not allservices delivered are supported. The management service will have to have a modular structure to enable deployment of special functions for specific services, while reusing the basic functions provided by the management service. In this way the basic management can be extended to fit the specific needs of a given mix of services - operating systems, subsystems, networking, and applications alike. Based on this, we define Service Management as: The management of an IT infrastructure of hardware, software, communications equipment and facilities, documentation, and skills used to provide the required service at the required level of quality.
10
According to this definition, service management relies upon the internal IT infrastructure management and the technical environment, as well as managing third-party contractors.
IT Service Management
IT Service Provision
Customer Hardware Service Provider Third-Party management
IT infrastructure management Skills Software Documentation
Figure 1-5 Customer, service provider, and service management
1.5 Service Level Management

Service Level Management is the process of negotiating, defining, and managing the levels of IT Service that are required and cost-justified. The Service Management goal is important because it emphasizes the quantification of services. Therefore, when defining the objectives for the Service Level Management processes, the deliverable should be specified in quantifiable terms. Examples of such definitions are as follows: IT Services are catalogued. IT Services are quantified in terms that both customer and IT provider understand. Internal and external targets of IT Services are defined and agreed upon. Achievement of agreed service targets is reached.
11
The quantification of objectives applies to all three parts of the scope of the Service Level Management process and involves the management of IT Services between the customer organization and the IT Services organization, the IT Services organization and its external suppliers, and the IT Services organization and its internal departments. According to this we can define Service Level Management (SLM) as follows: The iterative, disciplined, proactive methodology and procedures used to ensure that adequate levels of service are delivered to all IT users in accordance with business priorities and at acceptable cost.
Negotiate/Define
implementation
Review
Manage
Figure 1-6 Service Level Management iterative process
A key to the success of Service Level Management is correctly quantifying the services being provided. Unless there is an agreed-upon method of how services are to be measured, there is no way of knowing whether targets have been met or not. Service Level Management is responsible for understanding and documenting the customer requirements and translating them into a set of understandable measures.
12
Service Level Management is a means for the lines of business (LOB) and IT organization to explicitly set their mutual expectations for the content and extent of IT Services. It also allows them to determine in advance what steps will be taken if these conditions are not met. The concept and application of Service Level Management allows IT organizations to provide a business-oriented, enterprise-wide service by varying the type, cost, and level of service for the individual LOB. In order to accomplish Service Level Management and really manage the quality of service provided by an internal IT organization or by an external service provider, establishing Service Level Agreements is a must. For the context of this redbook, we define Service Level Agreement (SLA) as follows: An agreement or contract between a service provider and a customer of that service, which sets expectations for the level of service with respect to availability, performance, and other measurable objectives. There are various types of Service Level Agreements. From an IT organization standpoint, the most common are: Internal or in-house SLAs These are agreements negotiated between the service provider, such as an IT department, and an in-house user or department. These kinds of SLAs are sometimes used by the company as an important selling point to external customers, ensuring the high quality of the company products. External SLAs These are agreements that a company may establish when purchasing services from an external provider. For example, company A may hire an Internet services provider (ISP) to host its Web site requiring 100 percent availability. If company A gets less than acceptable service from its ISP, without this SLA in place, company A may not have many options to force the ISP to address the problem or to terminate their contract without penalties. There are a number of components that make up an SLA, including the following: Term Defines the period of time the SLA will cover. Scope Defines the services covered in the agreement. Limitations Define what must happen in order for the requested service levels to be provided.
13
Service level objectives Define the level of services that both the customer and the service provider agree on. This is a specification of a metric that is associated with a guaranteed level of service. Service level indicators Define the means by which the service level objectives can be measured. Non-performance Defines what happens if the service provider does not meet the objectives. Exclusions Specifies what is not covered in the SLA. Reviews Establish scheduled reviews between the customer and the service provider. Reporting is the most important way this can be accomplished and is a key component of Service Level Management. Once established, Service Level Agreements help with the following: Allows for the IT organization to better understand customer service requirements Controls customer expectations for levels of service to be delivered Allows for a clear understanding of priorities when handling service problems
1.6 Why bother with Service Level Management

There are six compelling reasons to establish a Service Level Management discipline in your company or with your service provider: Satisfying clients The IT Service provider must understand what the customer perceives as good service. The customer must understand what is reasonable to expect from the IT Service provider given limitations in hardware, network performance, staff, and so on. Communication between an IT service provider and a customer is an essential part of Service Level Management. There must be an agreement of what constitutes acceptable service against which service levels can be measured. When IT service providers meet expectations, customers can clearly see their expectations are being met and confidence increases.
14
Managing expectations Often, customers who were satisfied with service yesterday want better service today, and even better tomorrow. Some savvy ones may just want to maintain service levels knowing that more users are receiving IT Services. To manage such a situation, an IT service provider and customer must negotiate a SLA. Both parties may later renegotiate the agreement as needed. Regulating resources When both the IT service provider and customer monitor service levels closely, they can become aware of developing problems in overcapacity or lack of resources and can be proactive by taking corrective actions. Marketing internal IT Services In the old days, the only contact between the IT service provider and customers happened when something went wrong. This situation was always seen as a roadblock to achieving business goals. With a Service Level Management process in place, an IT service provider can document the fact that it is providing good services supporting the business. Controlling costs With a Service Level Management process in place, IT service providers can clarify which areas if of its services need improvement and requires investment, and which areas still perform at satisfactory levels. This helps with the decision-making process and justification as to whether investments are necessary to upgrade service levels. Establishing a defensive strategy IT service providers can demonstrate in measurable terms that they are worth the customers investments. With precise SLA and effective reporting, customers perceptions of a good service can be eased and most likely customers will be less likely to purchase IT Services from a different IT service provider. In the case of an internal IT organization, it can disperse arguments for outsourcing.
15
16
Chapter 2.
IBM Tivoli Service Level Advisor general overview

IBM Tivoli Service Level Advisor (ITSLA) Version 1.1 is a Service Level Management solution for providers of IT Services. It simplifies and automates the process of managing service level agreements, enabling IT organizations to proactively manage and report on service levels from across the management infrastructure. Our approach to introducing IBM Tivoli Service Level Advisor Version 1.1 in this chapter is to: Give an overview of ITSLA. Explain the ITSLA product core components as well as all the additional components that are required by ITSLA Explain the main concepts, terms, and definitions used by the product. Give a brief introduction to the Tivoli Enterprise Data Warehouse (TEDW) and explain how it is leveraged by ITSLA. Explore the functionality of ITSLA. Explain which Tivoli applications are providing data to be used by ITSLA, as well as how third-party applications can participate in the Service Level Management. Detail the end-to-end SLA Management process of ITSLA.
17
2.1 Overview of IBM Tivoli Service Level Advisor

Service Level Management is one of the many processes involved in the delivery of IT Services. It is intended to improve client satisfaction by facilitating the management of client expectations and ensuring IT service delivery. IBM Tivoli Service Level Advisor Version 1.1 is a Service Level Management solution that enables providers of IT Services in an enterprise to manage service level agreements. The following are the main characteristics of IBM Tivoli Service Level Advisor: Simplifies and automates the Service Level Management by providing a way to define and record service level agreements based on the definitions of service level objectives. Facilitates the development of a customer-service oriented culture within the IT service organization. Provides a line of business for an enterprise with service delivery information based on the Service Level Management definition. Analyzes trends and tendencies so that potential problems can be identified and corrected before they occur. Makes use of existing Tivoli applications deployed and can be extended to use non-Tivoli applications to provide an end-to-end enterprise picture of service level agreement compliance. Sends alerts for violations or trends toward violations so that notification of problems or potential problems can be integrated into an automated help desk or Change Management process. Helps you to understand the business characteristics and needs of the clients and the service components required to fulfill those needs. Automatically prepares a variety of Web-based reports on violations and trends, with drill-down capability, which saves on manpower required to gather and report statistics. ITSLA also allows you to make use of third-party reporting tools, providing extra flexibility on Service Level Management reporting. Aids in maintaining a baseline for IT Service capabilities. Automates service level agreement validation and receives alerts for service level agreement violations. IBM Tivoli Service Level Advisor allows you to leverage your existing investment in performance and availability monitoring applications and reduce your cost of Service Level Management while you align your IT management with business needs. Currently, it is common for enterprises to have various distributed
18
performance and availability monitoring applications deployed that collect measurement data and provide some type of threshold management, central event management with correlation and escalation, and other basic monitoring functions. IBM Tivoli Service Level Advisor uses the data provided by those applications and enables you to: Define offerings that can be offered with differentiated service levels based on a set of service level objectives. Create customer profiles and associate them with specific service level agreements. Set up a schedule for the collection, evaluation, and analysis of the data at customized intervals. Analyze the data to detect violations of service level agreements or trends toward future violations. Send notifications when violations or trends are detected, enabling support personnel to take preventive action and maintain agreed-upon levels of performance and availability across your enterprise. Provide regular Web-based reports of evaluation results that might indicate a need for corrective action or to verify that levels of service are being maintained.
2.2 IBM Tivoli Service Level Advisor components

IBM Tivoli Service Level Advisor can be categorized in three core functional units: ITSLA Task Drivers ITSLA Server ITSLA Reports Server There are also several other logical components that are used to complete the IBM Tivoli Service Level Advisor solution. They are: ITSLA Database Server; hosting both the ITSLA Database and the ITSLA Measurement Data Mart databases Tivoli Enterprise Data Warehouse (TEDW) Server Tivoli Enterprise Data Warehouse Control Center, also known as Data Warehouse Center or Control Server IBM Console Server ITSLA Extract, Transform, and Load data (ETL) programs Source Application ETL programs
Chapter 2. IBM Tivoli Service Level Advisor general overview
19
Figure 2-1 shows the relationship between the core and the logical components of IBM Tivoli Service Level Advisor.
Source Application Databases ITSLA Server

Source ETLs ITSLA ETL ITSLA Database
ITSLA Reports Server
TEDW Control Center
TEDW Server
TEDW Central Warehouse
ITSLA ETL
ITSLA Measurement Data Mart
ITSLA Database Server
ITSLA Task Drivers and IBM Console
Figure 2-1 ITSLA core and logical components relationship
The following sections are dedicated to explaining each of the IBM Tivoli Service Level Advisor components. Certain terms and concepts used throughout the following sections will also de defined in the context of IBM Tivoli Service Level Advisor. Section 2.3, Important ITSLA concepts and terminology on page 26, as well as the official product documentation, can be used as an additional source of reference.
2.2.1 ITSLA Task Drivers

The ITSLA Task Drivers component of IBM Tivoli Service Level Advisor is used to perform the following administrative tasks: Define service level offerings as well as specify breach values for associated metrics. Define orders and manage those that are active. Define schedules states once a level of service is defined. Schedule states can be specified as peak, standard, prime, off-hours, and so on. Schedule evaluation and trend analysis of measurement data, as well as the frequency of their execution.
20
The ITSLA Task Drivers component leverages the IBM Console for all its tasks and must be installed on the same machine where the IBM Console Server components are installed. There are two versions of the IBM Console: The Java Console and the Web Console. The Web-based version of the IBM Console is used primarily for all administrative tasks, except for the viewing of message logs and tracing enablement. For these tasks, the ITSLA Task Drivers utilize the IBM Java-based Console. For additional information on viewing message logs and enabling the tracing function using the Java-based console, refer to Chapter 5, Administering IBM Tivoli Service Level Advisor on page 133. For additional information on the IBM Console Server see 2.2.7, IBM Console Server on page 25.
2.2.2 ITSLA Server

The ITSLA Server component provides the core functions required for Service Level Management practices. These functions include processing the service level agreement orders, evaluation and trend analysis, and storing the analysis results. The ITSLA Server can also be used to send notifications of service level agreement violations or trends toward a service level agreement violation. Measurement data that is stored in the ITSLA Measurement Data Mart database is accessed by the ITSLA Server in order to perform trend analysis, with the results being stored in the ITSLA Database. Section 2.6, The SLA Management process of ITSLA on page 40, provides details on how data is handled by the ITSLA Server.
2.2.3 ITSLA Reports Server

The ITSLA Reports Server component is composed of Java-based servlets running on the IBM WebSphere Application Server, which accesses data stored in the ITSLA Database to provide service level reports. Depending on the access rights of a user, a predetermined Web portal page will be assigned after a successful login, providing the user with access to SLA results and summary reports in the form of tables and graphs. Chapter 6, Service level Reports with ITSLA on page 217, provides a great deal of information regarding ITSLA reports.
21
2.2.4 ITSLA Database Server

The ITSLA Database Server component consists of an IBM DB2 Universal Database Enterprise Edition Server hosting both the ITSLA Database and the ITSLA Measurement Data Mart databases. It is not a requirement to have both databases installed on the same machine or even located in the same DB2 instance. For more information when planning the ITSLA Database environment refer to 3.3, Planning for IBM Tivoli Service Level Advisor on page 61.
ITSLA Database
Data that is stored in the ITSLA Database can be organized into the following three categories: Information needed to create offerings and orders, such as resources, measurement types, component names, and attributes The actual offerings and orders that make up the defined service level agreements Evaluation and trend analysis data for report creation Figure 2-2 on page 23 depicts how each of the ITSLA components utilizes the ITSLA Database. Each component uses the ITSLA Database in the following way: ITSLA Task Drivers for creating and storing offerings and orders ITSLA Server for storing data evaluation and trend analysis results ITSLA Reports for viewing the results of data evaluation and trend analysis Data is inserted in the ITSLA Database via the Target ITSLA ETL Registration, which is run through the Tivoli Enterprise Data Warehouse Control Center. For more information regarding the Registration Target ETL, refer to 2.5, IBM Tivoli Service Level Advisor Target ETLs on page 37.
22
ITSLA Server
Evaluation data Trend analysis
offering and orders
ITSLA Task Drivers
ITSLA Database

Registration ETL Reporting data
TEDW Control Center
Figure 2-2 ITSLA Database component access

Generally speaking, a data mart contains a subset of corporate data that is of value to a specific business unit, department, or set of users. This subset consists of historical, summarized, and possibly detailed data captured from transaction processing systems or from a central enterprise database. In the context of IBM Tivoli Service Level Advisor, the ITSLA Measurement Data Mart is the persistent data storage for the summarized performance and availability monitoring application data that is obtained from the Tivoli Enterprise Data Warehouse database. Figure 2-3 on page 24 shows which IBM Tivoli Service Level Advisor components use the ITSLA Measurement Data Mart database.
23
Process ETL
TEDW Control Center
ITSLA Database
ITSLA Server
Figure 2-3 ITSLA Measurement Data Mart access
There are two types of data that are pulled from the Tivoli Enterprise Data Warehouse database and stored in the ITSLA Measurement Data Mart database: Measurement data that applies to the enabled data types specified in the ITSLA Database Resources that are of interest to currently active service level agreements Once this data has been inserted in the ITSLA Measurement Data Mart database, the ITSLA Server evaluates the data for violations or trends toward violations and stores the results in the ITSLA Database. Data is inserted in the ITSLA Measurement Data Mart database via the Target ITSLA ETL Process ETL, which is run through the Tivoli Enterprise Data Warehouse Control Center. For more information regarding the Process Target ETL, refer to 2.5, IBM Tivoli Service Level Advisor Target ETLs on page 37.
24
2.2.5 Tivoli Enterprise Data Warehouse Server

A data warehouse is a structured extensible database environment designed for the analysis of consistent data. The data that is inserted in a data warehouse is logically and physically transformed from multiple source applications, updated and maintained for a long time period, and summarized for quick analysis. The Tivoli Enterprise Data Warehouse (TEDW) server is an IBM DB2 Universal Database Enterprise Edition server that contains the TEDW Central Data Warehouse databases. These databases are populated with operational data from Tivoli and/or other third-party applications for historical analyses and evaluated by IBM Tivoli Service Level Advisor.
2.2.6 Tivoli Enterprise Data Warehouse Control Center

The Tivoli Enterprise Data Warehouse Control Center is the IBM DB2 Universal Database Enterprise Edition server containing the TEDW control database (TWH_MD) that manages the Tivoli Enterprise Data Warehouse environment. From the Tivoli Enterprise Data Warehouse Control Center, you can also manage all databases located in your ITSLA environment.
2.2.7 IBM Console Server

The IBM Console is a distributed, device-independent, and platform-independent presentation layer for most of the Tivoli products, enabling the user to perform numerous ITSLA administrative tasks through an easy to use graphical user interface. As explained in 2.2.1, ITSLA Task Drivers on page 20, the IBM Console has two versions: The Java-based version and the Web-based version. The IBM Java Console can only be run from the machine where Tivoli Presentation Services is installed. The IBM Web Console can be accessed by any machine in the company intranet by connecting to the IBM Console Server machine using a supported Web browser. Each of the two IBM Console types is used for different tasks: The IBM Web Console for performing administrative tasks in the ITSLA environment, such as managing users and creating orders The IBM Java Console for message log viewing and enabling tracing
2.2.8 ITSLA ETL programs

ETL is an acronym for Extract, Transform, and Load. These are processes that extract data from a source database, transform the data to fit a generic schema, and load the data into a target database.
25
There are two types of ETLs necessary to make data from source databases ITSLA-enabled: Source ETL Sometimes referred as Warehouse Enablement Packs, these are the ETL processes that extract the raw data from the source application databases and load it into the TEDW Central Data Warehouse database. There is a specific Source ETL for each IBM Tivoli Service Level Advisor enabled application. The list of the ITSLA-enabled Tivoli applications can be found in 2.7, Applications providing measurement data on page 46. The Tivoli Source ETLs are shipped on a separate CD with the IBM Tivoli Service Level Advisor installation media. Target ETL Also referred to as Data Mart ETL, these are programs that extract data from the TEDW Central Data Warehouse Database for further processing. In IBM Tivoli Service Level Advisor there are two Target ETLs, as follows: Registration ETL The Registration ETL extracts information about the types of measurement data available and loads it into the ITSLA Database. Process ETL The Process ETL extracts all performance and availability data from the TEDW Central Data Warehouse database and loads it into the ITSLA Measurement Data Mart database for evaluation. The ITSLA Target ETLs are shipped on a separate CD with the IBM Tivoli Service Level Advisor installation media.
2.3 Important ITSLA concepts and terminology

This section provides you with an important list of terms and definitions, in the IBM Tivoli Service Level Advisor context. This is a glossary that will be used throughout this redbook. Availability Measurement of how often a service is accessible to a defined customer set, measured as a percentage of up-time versus total time. Scheduled outages (no-service periods) are not counted against the availability measurement. (Note that a service may be unavailable even though the components used to provide the service are all available, and vice-versa.)
26
Breach value This is the value at which a service level objective is considered as not being met. A service level agreement is violated if a breach value for one or more of its service level objectives is exceeded. Business schedule or Schedule A timeline of the operations of a business, with the timeline segmented into different operational states. Valid states include peak, off-hours, and no-service (scheduled downtime for maintenance). Change An action to modify the properties of a customer order. Component The basic unit of service used to create a service offering. A component is an entity about which measurements are collected for reporting purposes. For example, a component can be a specific Web site or a particular application running on a Web application server. Component type In the IBM Tivoli Service Level Advisor environment, a grouping mechanism to group similar types of system resources (firewalls, servers, routers, etc.) that have common metrics. Each component type in the data model has a set of metrics and attributes that apply to all components of that type. The Tivoli Enterprise Data Warehouse includes many types of monitoring data. In IBM Tivoli Service Level Advisor, you can selectively filter for those component types of interest. The component type specifies the kind of enterprise resource that is evaluated by the service level objective. Configure service level objective The process of customizing a customer order by selecting the resources to include in the service level agreement according to the type of measurements specified in the service level objective definition. Customer A party that enters into a service level agreement with the provider of a particular service. Customers are associated with available service level agreement orders. Customers can be given access to the results of service level agreement evaluation and trend analyses to validate their service level agreements. Customers can be internal (members of a department within the enterprise) or external (a member, department, or company) associated with a service provider.
27
Customer order This is the action of setting up a service level agreement by associating customers with service offerings. Data collection The process of obtaining performance and availability metric data from source applications for storage and later evaluation. Dependency The relationship between service level agreements in which the validation of one service level agreement is dependent upon the validation of another service level agreement. Typically used when one or more service level agreements internal to a service provider organization are monitored for the purpose of guaranteeing an external customer's service level agreement. End time In IBM Tivoli Service Level Advisor, the end time of a defined period in the schedule that is associated with a particular state of peak, standard, or no-service hours. Evaluation The examination of performance and availability data from one or more monitoring applications to determine if a violation or a trend toward violation of a service level agreement has occurred. Frequency In IBM Tivoli Service Level Advisor this can have one of the following meanings: In business schedules How often the associated period is active In metric evaluation How often the evaluation is to be performed Measurement and Metric A standard of measurement or a measurable quantity, associated with guaranteed service levels to create service level objectives. Metrics evaluate performance, availability, or utilization of resources. For example, response time, CPU and disk utilization.
28
Measurement source The source application from where a measurement originates. Performance and availability measurements are collected by the source application and written to a central data warehouse for later processing. A measurement source can provide measurement for one or more components. The following are examples of measurement sources: IBM Tivoli Monitoring for Transaction Performance (TAPM) IBM Tivoli Monitoring for Transaction Performance (TWSM) IBM Tivoli Business Systems Manager IBM Tivoli Enterprise Console IBM Tivoli Monitoring
For additional information on how the above applications are providing SLA data, refer to 2.7, Applications providing measurement data on page 46. No-service The state of a period in a business schedule in which service level agreements are not evaluated. This time is typically used for down time" or maintenance hours that do not count against the service level objectives established in service level agreements. Offering In IBM Tivoli Service Level Advisor, this describes a service with guaranteed service levels. Offerings are associated with business schedules and form the building blocks for customer orders and service level agreements. Offerings can be differentiated to provide service level choices to customers (like "Gold," "Silver," and "Bronze" levels of service). An offering must be in the published state to be included in a service level agreement order. Offering component This supplies the metrics for offerings and customer orders. At the time of an offering creation, one or more offering components are selected. IBM Tivoli Service Level Advisor checks to determine the number of measurement sources for a component.
29
Offering state In IBM Tivoli Service Level Advisor, the state of a service offering. Valid values include: Draft The offering is being created. It is not yet published and available to be included in a customer order. Published The offering has been defined and is made available for inclusion in customer orders. Withdrawn A previously published offering that has been removed from the list of available offerings and can no longer be included in customer orders. Order In IBM Tivoli Service Level Advisor, the process by which an SLA is entered into the Tivoli Service Level Management solution. Includes customer information, a service offering, and the specific elements that make up the SLA. For example, customer Accounting signs up for the Gold offering for the www.000.com/accounting Web site. Order ID The assigned identification number that distinguishes one customer order from another. Peak The state of a period in a business schedule that defines hours in which levels of service are the most critical to the customer during peak business hours. Typically defines a more severe level of service than that specified for standard hours. Period A component of a business schedule that divides the timeline into named intervals, such as critical, peak, prime, standard, low impact, off-hours, and no-service. The general meaning of those intervals is defined by the customer during service level agreement negotiations. For example, you may define different service level objectives (thresholds) for each period, depending on how critical that particular period is for the business. Published offering This is an offering that is complete and is made available to customers to be included in a service level agreement.
30
Realm In IBM Tivoli Service Level Advisor, a grouping of customers that is used to organize customer information and, in some cases, to control access to that information. Customers might be grouped by region, by company, by a division within a company, or by some other logical grouping. Customers can be assigned to one or more realms. Reports Reports summarize the evaluated measurement data for a service level agreement. IBM Tivoli Service Level Advisor provides three types of reports, as follows: Results reports show monitoring information for the peak or standard states of a specified metric in an order. Violations reports display the service level agreement violations during a specified period of time. Trends reports display trends towards the violation of breach values, that is, tendencies to violate service level agreements. Refer to Chapter 6, Service level Reports with ITSLA on page 217 for detailed information on IBM Tivoli Service Level Advisor reports. Resource A hardware, software, or data entity that is managed by Tivoli management software. In IBM Tivoli Service Level Advisor, the entity is monitored by performance and availability monitoring applications. Rollback Refers to the capability of IBM Tivoli Service Level Advisor to return to the last valid state if there is a failure during customer order deployment or cancellation, enabling failed orders to be restarted or deleted. Service Any task performed by one person or group for another person or group. Refer also to the definition provided in 1.2, IT Services on page 5. Service element A component that provides a piece of an overall service. Service elements are the building blocks used to construct service offerings and customer orders.
31
Service level agreement (SLA) In IBM Tivoli Service Level Advisor, an agreement or contract between a service provider and a customer of that service, which sets expectations for the level of service with respect to availability, performance, and other measurable objectives. Service level objective (SLO) This is a specification of a metric that is associated with a guaranteed level of service that is defined in a service level agreement. The service level objective is part of an offering and is associated with a business schedule so that different breach values can be set for each schedule period. Choices include peak, critical, standard, prime, off-hours, and no-service. Service Level Management (SLM) The disciplined, proactive methodology and procedures used to ensure that adequate levels of service are delivered to all IT users in accordance with business priorities and at acceptable cost. Effective Service Level Management requires the IT organization to thoroughly understand each service it provides, including the relative priority and business importance of each. Service Level Management is the continuous process of measuring, reporting, and improving the quality of service provided by the IT organization to the business. For additional information refer to 1.4, Ensuring service quality on page 9. Service offering In IBM Tivoli Service Level Advisor, a defined level of service that associates a business schedule, including specified peak, standard, and no-service periods, with particular metrics to be evaluated. Service provider A person or organization that provides a service to a customer based on a service level agreement.
32
SLA state The state of an active service level agreement. An SLA state can assume one of the following values: Violation One or more breach values have been exceeded, indicating that the agreed-upon level of service is not being met. Steady All levels of service are currently being met and there is no detected trend toward a violation of the SLA. Trend A trend toward a future violation of an SLA has been detected. None The SLA has not yet been fully processed. This is an initial state. Standard The state of a period in a business schedule that defines hours in which levels of service are not as critical as they are during peak business hours. Start time In IBM Tivoli Service Level Advisor, start time may have one of the following meanings: In defining business schedules, this is the start time of a defined period in the schedule that is associated with a particular state of peak, standard, or no-service hours. In defining the schedule for metric evaluation, this is the time that the evaluation will be initiated. Trend Trend is a series of related measurements that indicates a defined direction or a predictable future result. Trend analysis The examination of related measurements to determine whether a breach level for a level of service is being approached, so that corrective action can be taken to prevent a violation of a service level agreement. View The display of the details of a business schedule, period, offering, customer, or realm.
33
Violation The state of a service level agreement when one or more service level objectives are not met. Service level agreement violations can be used to trigger a remediation policy for affected customers. Web report Service level agreement results made available through a series of Java servlets. Each report servlet can be integrated independently into the service provider's existing Web content. Using Web server authentication, report data can be restricted by customer or realm. Displayed on a user's Web browser showing the results of evaluation and trend analysis of service level agreement data to validate a service level agreement or to assist in identifying problem areas and taking corrective action. Withdrawn order An order that has been removed from the list of active orders that is being managed to guarantee levels of service. It is important to note that withdrawn orders are not deleted, but are no longer active. Withdrawn offering An offering that had been published, but which has since been withdrawn and is not available to customers for inclusion in a service level agreement.
2.4 A glimpse into Tivoli Enterprise Data Warehouse

As explained in 2.2.5, Tivoli Enterprise Data Warehouse Server on page 25, the Tivoli Enterprise Data Warehouse is an application used to collect and manage data from various Tivoli and non-Tivoli system management applications. The data is imported into the TEDW databases through ETLs from the source application databases, stored in the TEDW Central Warehouse Database, and further processed for historical analysis and evaluation. It is IBM Tivolis strategy to have most of its products providing ETLs so that the TEDW Central Data Warehouse database can be populated with meaningful systems management data. The IBM Tivoli Service Level Advisor Version 1.1 is the first product to fully leverage and utilize Tivoli Enterprise Data Warehouse.
34
Customers can benefit from using Tivoli Enterprise Data Warehouse in various ways, such as: TEDW collects historical data from many applications into one central place. TEDW collects the underlying data about customers network devices/connections, desktops/servers, applications/software, and the problems and activities that have gone on to manage the infrastructure. This allows the customers to construct an end-to-end view of their enterprise and view the components independent of specific applications used to monitor and control resources. TEDW adds value to raw data. TEDW performs data aggregation (such as daily, weekly) and allows the user to restrict the amount of data stored in the central data repository. The data is also cleaned and consolidated in order to allow the data model of the central repository to share common dimensions. For example, TEDW ensures that time, host name, and IP address are the same dimensions across all the applications. TEDW allows the correlation of information from many Tivoli applications. TEDW can also be used to derive added value by correlating data from many Tivoli applications. It allows reports to be written, which correlate cross application data. TEDW uses open, proven interfaces for extracting, storing, and sharing the data. TEDW can extract data from any application (Tivoli and non-Tivoli) and store it in a common central database. TEDW also provides transparent access for third-party BI solutions (CWM standard), such as IBM DB2 OLAP, Crystal Decisions, Cognos, BusinessObjects, Brio Technology, Microsoft OLAP Server. CWM stands for Common Warehouse Metadata, an industry standard specification for metadata interchange defined by the Object Management Group (see http://www.omg.org). TEDW provides a Web-based reporting front end, called the Reporting Interface, but the open architecture provided by the TEDW allows other BI front ends to be used to access the data in the central warehouse. The value here is flexibility. Customers can use the reporting application of their choice; they are not limited to any one. TEDW provides robust security mechanism. TEDW provides a robust security mechanism by allowing data marts to be built with data from subsets of managed resources. By providing database level authorization to access those data marts, TEDW can address most of the security requirements related to limiting access to specific data to those customers/business units with a need to know.
35
TEDW provides a scalable architecture. Since TEDW depends on the proven and industry standard RDBMS technology, it provides a scalable architecture for storing and retrieving the data. Figure 2-4 depicts a typical Tivoli Enterprise Data Warehouse configuration with IBM Tivoli Service Level Advisor.
Source Applications
ITM
Business Intelligence and Reporting Tools TEDW Environment
IBM
TEC ETL
Data Mart Data Mart
BRIO
TAPM
ETL ETL
TEDW Central Data Warehouse
ETL
Data Mart
Business Objects
Data Mart
Data Mart
TWSM
Crystal Reports
TBSM
Cognos
TEDW Control (Metadata)
TEDW Control Center

Others
Third Party
Figure 2-4 A typical TEDW environment
The TEDW Control Center is the system that contains the TEDW Control database, which contains metadata for Tivoli Enterprise Data Warehouse and from which you manage all of your TEDW environment. The default internal name for the TEDW Control database is TWH_MD. The TEDW Control Center also manages the communication between the various components, such as the TEDW Central Data Warehouse, the data marts, and the Report Interfaces.
36
The TEDW stores raw historical data from all Tivoli and third-party application databases in the TEDW Central Data Warehouse database. The internal name of the TEDW Central Data Warehouse database is TWH_CDW. Once the data has been inserted into the TWH_CDW database, it is available for either the TEDW ETLs to load to the TEDW Data Mart database (the internal name of the TEDW Data Mart database is TWH_MART) or to any other application-specific ETL to process the data and load the application-specific Data Mart database. In the context of IBM Tivoli Service Level Advisor, the ITSLA Target ETL programs move all applicable data from the TWH_CDW database to both the ITSLA Database and the ITSLA Measurement Data Mart databases. For the IBM Tivoli Service Level Advisor, the internal name of the ITSLA Measurement Data Mart database is DYK_DM and the ITSLA Database is DYK_CAT. The following section goes into more detail on the ITSLA Target ETL programs.
2.5 IBM Tivoli Service Level Advisor Target ETLs

As explained in 2.2.8, ITSLA ETL programs on page 25, the two Target ETLs that ITSLA uses are the Registration ETL and the Process ETL. These ETLs are processes scheduled and run from within the TEDW Control Center interface.
2.5.1 ITSLA Registration ETL

The Registration Target ETL is responsible for transferring measurement type data and component type information from the TEDW Central Data Warehouse database to the ITSLA Database (the internal default name of the ITSLA Database is DYK_CAT). The Registration Target ETL is run once after IBM Tivoli Service Level Advisor is installed and periodically thereafter when new measurement data types are added to the TEDW Central Data Warehouse database. The Registration Target ETL is made up of different SQL steps, as shown in Figure 2-5 on page 38.
37
Figure 2-5 ITSLA Registration ETL process model
The Registration Target ETL scheduling is configured through the TEDW Control Center interface. It is very important to schedule this ETL to run on a daily basis to ensure both that the ITSLA Database contains the most updated version of your measurement data and that all new measurement data types will be added to your environment. It is also worthwhile to mention that the Registration ETL is the very first ITSLA ETL program to run and should always run prior to the Process Target ETL interface. Chapter 5, Administering IBM Tivoli Service Level Advisor on page 133, provides more information on how, why, and when to run the Registration ETL.
2.5.2 ITSLA Process ETL

The primary purpose of the Process Target ETL is to transfer data from the TEDW Central Data Warehouse database to the ITSLA Measurement Data Mart database (the internal default name of the ITSLA Measurement Data Mart is DYK_DM). The Process Target ETL must run daily and can be scheduled to run
38
with either the TEDW Control Center scheduler or by the Central Data Warehouse administrator tool. Chapter 5, Administering IBM Tivoli Service Level Advisor on page 133, provides more information on how, why, and when to run the Process ETL. The Process Target ETL is comprised of different SQL steps, as shown in Figure 2-6.
Figure 2-6 ITSLA Process ETL process flow
Being that the data inside the ITSLA Measurement Data Mart database is used for the service level agreement evaluation and trend analysis, there are two important considerations to make when running the Process Target ETL: The Process Target ETL should not run until after all Source Application ETLs have inserted their data inside the TEDW Central Data Warehouse database. The Process Target ETL must finish processing before the ITSLA Server starts the data evaluation process, otherwise the evaluation process might not give consistent results.
39
2.6 The SLA Management process of ITSLA

IBM Tivoli Service Level Advisor, as a product, does not gather or store any performance, availability, or Service Level Management applicable data. It relies instead on other Tivoli and third-party performance and availability applications to collect and store this data in their own separate databases. For instance, Tivoli Web Services Manager might monitor transaction times for a specified Web site and store this data continuously in its database. IBM Tivoli Service Level Advisor would then use this database as a source for Service Level Management analysis. All data is then transferred and formatted by the source application Source ETLs into the TEDW Central Warehouse database repository. After this has completed, the two ITSLA Target ETLs are then run separately and consecutively to populate their respective databases with the applicable data. IBM Tivoli Service Level Advisor can then analyze and evaluate the data and generate reports of service level violations or trends toward potential service level violations. Figure 2-7 gives an overview of how ITSLA works.
ITSLA Environment
Source Applications Environment

Source Appl 1
So urc eE
ITSLA Server
TL 1
tration Regis ETL
Source Appl 2
Sourc eE
TL 2
TEDW Central Warehouse

E TL N
ITSLA Database
Pro ce ss E T L
Source Appl N
ce ur So
ITSLA Task Drivers and IBM Console
Figure 2-7 How TSLA collects and stores measurement data
After the ITSLA Server has completed its data evaluation and trend analysis, you may view the evaluation results provided by the ITSLA Reports Server through a supported Web browser. Now, let us take a close look at the overall Service Level Management process of ITSLA, as it is depicted in Figure 2-8 on page 41.
40
1 1 12 10 9 8 7 6
1 2 3 4 5 10 9 8 7 6 5 11 12 1 2 3 4
1
Agree SLAs
3
Populate ITSLA Database Registration ETL
4
Define Schedules & Create Offerings Define Customers & Create 5 Orders
Select source data
Access Reports via Web browser
1 1 10 9 8 7
1 2
1 2 3 4 5
11 10 9
12
1 2 3 4
or
ITSLA Database
Warehouse Center Scheduler
Warehouse Center Administrator
SLA violation and trend Evaluation
Populate ITSLA Measurement Data Mart Process ETL
8
Event Escalation and Notification
Figure 2-8 End-to-Eend SLA Management process flow
The steps are numbered in the diagram above and are explained further in the sections below. The SLA Management process can be explained in the following steps: Step 1: Define and agree on Service Level Agreements with your customers. Step 2: Select the applications that will provide source data. Step 3: Populate the ITSLA Database with measurement and resource type information. Step 4: Define schedules and create offerings. Step 5: Define customers and create orders. Step 6: Populate the ITSLA Measurement Data Mart database with data from the TEDW Central Warehouse database. Step 7: Evaluate the data for violations and trends.
41
Step 8: Notification of SLA violations and trends toward potential violations. Step 9: Access the SLA reports through a supported Web browser.
2.6.1 Step 1: Define and agree on Service Level Agreements

Before service level agreements can be managed they must be agreed upon by you and your customers. This can be a written agreement or a verbal agreement and must include details like peak hours and off-peak hours and service levels applicable to each timeframe.
Implement
Review
Manage
Figure 2-9 A typical Service Level Management process flow
The following are the basic steps for Service Level Management: 1. Implement the service level agreement. Create a draft service level agreement Negotiate the service level with the customer Agree on the final service level that will be provided 2. Manage the service being delivered against the agreement. Continually monitor and analyze achieved service levels Report frequently on achieved service levels and service level violations 3. Review the service level agreement with your customer based on the results from step 2 and update where applicable.
42
4. Begin with step 1 again. Service Level Management is an ongoing process requiring continuous maintenance. Refer to 1.3, Service Delivery on page 7, for more information on service delivery management.
2.6.2 Step 2: Select applications for source data

After defining a service level agreement, you must decide which source applications will be used to provide measurement data and populate the TEDW Central Data Warehouse database. Select only the applications that can provide meaningful data for service level analysis. This will optimize your IBM Tivoli Service Level Advisor solution, as time will not be wasted on moving redundant data to the TEDW Central Data Warehouse database, or data that cannot be used for Service Level Management. As no data is initially enabled to be transferred from the TEDW Central Data Warehouse database to the ITSLA Databases, you will need to enable every application you plan to use with IBM Tivoli Service Level Advisor. Refer to 5.2, Target ETLs management on page 142 for more information on enabling source applications.
2.6.3 Step 3: Populate the ITSLA Database

The Registration Target ETL is used to populate the ITSLA Database with information about the types of measurement data available in the TEDW Central Data Warehouse database. This process collects data associated with the source applications that you enabled in step 2. The Registration Target ETL extracts the data from the TEDW Central Data Warehouse database, transforms and formats the data so that it is compatible with the ITSLA Database schema, and then loads the information into the ITSLA Database. The Registration Target ETL is run either manually by the TEDW Data Warehouse administrator, or scheduled to run within the TEDW Control Center.
2.6.4 Step 4: Define schedules and create offerings

Once the ITSLA Database has been populated with the types of measurement data available in the TEDW Central Data Warehouse database, you will need to create an offering. This is done by accessing the IBM Console and doing the following: 1. Create an offering by inserting the offering name, a description of the offering, and the SLA type related to the offering.
43
2. Select an existing schedule or create a new schedule that defines the business hours of operation, such as peak hours, standard hours, and others. 3. Add one or more offering components to the offering. The available list will depend on the measurement and resource type information available in the ITSLA Database. 4. Define the service level objectives for the various metrics associated with each offering component, specifying minimum, maximum, and average breach values for each metric. 5. Define evaluation and trend analysis schedules. 6. Publish the offering to make it available for use. Refer to 5.4.1, Management of offerings on page 167, for more information on creating offerings.
2.6.5 Step 5: Define customers and create orders

The next step is to define which customers will be associated with the offerings, thereby creating an order. The customers you define can be grouped into realms in the cases that you would like to separate their data and reports according to their locations, divisions, companies, and so on. Select an offering from the list of published offerings and select specific resources in the enterprise for which the customer wants service levels to be managed. The list of available resources can potentially be very large and can be filtered to enable you to quickly select the desired resource. After the order has been created, you can submit the order to IBM Tivoli Service Level Advisor, where it will be scheduled for evaluation based on the times provided for the selected resources. For more information regarding the order creation process, refer to 5.4.2, Management of orders on page 179.
2.6.6 Step 6: Populate the ITSLA Measurement Data Mart database

The next step consists of populating the ITSLA Measurement Data Mart database with data from the TEDW Central Data Warehouse database via the Process Target ETL. This process will transform the source application data into a format that is suitable for the ITSLA Measurement Data Mart database. Evaluations will then run directly against the data that is located in the ITSLA Measurement Data Mart database.
44
The Process Target ETL is either run manually by the TEDW Data Warehouse administrator or scheduled to run within the TEDW Control Center component. For more information regarding the Process ETL and populating the ITSLA Measurement Data Mart database, refer to 5.2, Target ETLs management on page 142.
2.6.7 Step 7: Evaluate data for violations and trends

When an order is submitted to IBM Tivoli Service Level Advisor for evaluation, it includes the schedules that were defined in Step 4: Define schedules and create offerings on page 43. Data from the ITSLA Measurement Data Mart database will then be extracted by the ITSLA Server and evaluated, based on the selected resources and breach values defined in the order. IBM Tivoli Service Level Advisor will analyze the data for violations against the defined service levels and will search for trends toward potential violations, storing the results in the ITSLA Database. For more information regarding measurement data evaluation and analysis, refer to Chapter 5, Administering IBM Tivoli Service Level Advisor on page 133.
2.6.8 Step 8: Notification of SLA violations and trends

When IBM Tivoli Service Level Advisor is installed, you have the option of configuring event notification in case violations or trends toward future violations are received. These event notification methods include SNMP Traps, TEC Event forwarding, and e-mail. If any of these options were not chosen during installation, they can be configured from the IBM Tivoli Service Level Advisor command line interface. Depending on the method you select, notification will be sent to the desired personnel you choose during configuration, who can then take the necessary corrective action. Refer to 4.5.4, ITSLA Server component installation on page 113, for details on how to enable events notification.
2.6.9 Step 9: Access SLA reports

All service level agreement reports can be accessed through the ITSLA Reports Server using a Java-enabled Web browser. These reports can be graphical or in table format, and can be filtered to display only vital information with selected time intervals. The reports are based on WebSphere servlets and can be integrated into your current Web environment. Report users are defined in the IBM Console and access can be restricted to allow required views only.
45
Chapter 6, Service level Reports with ITSLA on page 217, provides a great deal of information on IBM Tivoli Service Level Advisor reporting mechanisms and options.
2.7 Applications providing measurement data

You will find that the Service Level Management process is often more successful when a variety of data is collected from several source applications, often referred to as measurement source applications. The Tivoli Enterprise Data Warehouse effectively combines data from multiple source applications, such as IBM Tivoli Monitoring for Transaction Performance, with other Legacy or third-party applications an enterprise may have already deployed. The generic schema provided by Tivoli Enterprise Data Warehouse facilitates this combining and storing of data, allowing the data to be cross-referenced, and thereby providing a more comprehensive and informative look at your source application measurement data. IBM Tivoli Service Level Advisor takes advantage of service level measurements collected by measurement source applications. The following are examples of measurement sources provided by Tivoli: IBM Tivoli Monitoring for Transaction Performance (TAPM) IBM Tivoli Business Systems Manager IBM Tivoli Enterprise Console IBM Tivoli Monitoring IBM Tivoli Monitoring for Transaction Performance (TWSM) When an application provides data to participate in the Service Level Management process, it is referred to as an ITSLA-enabled application. Any application that already collects some sort of measurement data can also become a measurement source application, therefore ITSLA-enabled. The following section explains the methodology on how applications may become ITSLA-enabled.
2.7.1 Becoming an ITSLA-enabled application

This section provides a brief description on the steps one may perform in order to make an application ITSLA-enabled. There are three main steps required for this process: 1. Develop the application-specific Source ETL. 2. Configure the connection to the source database. 3. Enable the application in the ITSLA Server.
46
Developing the application-specific Source ETL

This section gives a brief description of the major steps required for the Source ETL development. These steps are based on the IBM manuals Tivoli Enterprise Data Warehouse Enabling an Application Version 1.1, GC32-0745, and Introduction to Tivoli Enterprise Data Warehouse, SG24-6607. Assume that an IBM Tivoli Service Level Advisor environment is already functional. While a detailed description of each of these steps is outlined in the mentioned references, below is a list of the steps: 1. Initial data analysis. Applications may collect a wide variety of data types and store them in different formats, such as relational databases and log files. It must be determined what data types are needed to be stored in the Tivoli Enterprise Data Warehouse database, and thus into the ITSLA Database. 2. Get acquainted with the Tivoli Enterprise Data Warehouse database generic schema. The Tivoli Enterprise Data Warehouse database consists of several tables that need to be updated by the ETL process. A very thorough understanding of the logical design of such tables allows a smooth ETL development. The following tables should be carefully researched. A table description along with the actual table name is provided: Component (COMP) Component attribute (COMPATTR) Component relationship (COMPRELN) Measurement (MSMT) Extract control (EXTRACT_CONTROL) Extract log (EXTRACT_LOG) Prune measurement control (PRUNE_MSMT_CONTROL)
3. Use the Tivoli Enterprise Data Warehouse application enablement template. This step establishes how application data should be mapped into the Tivoli Enterprise Data Warehouse database table, ensuring that applications follow the specifications when storing data in the Tivoli Enterprise Data Warehouse database. 4. Follow the Tivoli Enterprise Data Warehouse naming conventions. In order to prevent object name conflicts, a requirement for naming conventions has been established. The initial step is to decide on an application-specific product code, known as measurement source code, which consists of three characters, including at least one number (for example, MM3). Once the product code is decided for the application, the naming convention provides guidelines for all the application-specific objects that need to be created. These guidelines are fully described in Tivoli Enterprise Data Warehouse Enabling an Application Version 1.1, GC32-0745.
47
5. Develop scripts to insert static data. These SQL scripts are used during the installation of the Source ETL and enable application-specific static data to be properly placed into the Tivoli Enterprise Data Warehouse database. 6. Review extract control design. The extract control method enables measurement data to be extracted from the application-specific data repository on an incremental basis. 7. Review timestamps. All time values inserted into the Tivoli Enterprise Data Warehouse must be in Universal Time Coordinated (UTC) format. Ensure that the application provides time information using UTC. 8. Review Tivoli Enterprise Data Warehouse common tasks. There are common tasks that applications must perform when inserting data into the Tivoli Enterprise Data Warehouse database. Tivoli Enterprise Data Warehouse Enabling an Application Version 1.1, GC32-0745, provides a complete description for all these tasks. 9. Develop the Source ETL code. These are SQL scripts that query the application-specific data repository and populate the Tivoli Enterprise Data Warehouse database according to the guidelines provided by the application enablement templates. A process in the Tivoli Enterprise Data Warehouse Control Center should also be defined.
Configure the connection to the source database

Consider that a database connection must be set between the TEDW Central Data Warehouse database and the source application database. In order to create such a connection, you must install on the TEDW Control Center machine the source application database client and configure it to communicate with the source application database server. An Open Database Connectivity (ODBC) connection must then be created and configured in order to be able to transfer the data from the source application database to the TEDW Central Data Warehouse.
Enabling the application in the ITSLA Server

Once the Source ETL has populated the Tivoli Enterprise Data Warehouse database with application-specific measurement data, IBM Tivoli Service Level Advisor should be notified of the existence of the new set of data, so that the Target ETLs can move the data into both the ITSLA Database and the ITSLA
48
Measurement Data Mart databases. The information on which application must be included during data collection is determined based on the application-specific three digit product code. The complete description of this task is found in 5.2, Target ETLs management on page 142.
49
50
Chapter 3.
Implementation planning
IBM Tivoli Service Level Advisor is dependent on a number of supporting applications and components, making planning an essential task in order to ensure a successful deployment. Before installing IBM Tivoli Service Level Advisor into your enterprise environment, you should consider the hardware and software requirements, the physical locations of where you want to install the various functional pieces of IBM Tivoli Service Level Advisor, and their dependencies on the other applications that support the IBM Tivoli Service Level Advisor solution. IBM Tivoli Service Level Advisor and its supporting applications can be installed on a single machine in your enterprise, or across multiple machines with certain dependencies.
51
The main topics concerning planning discussed in this chapter are: Description of an ITSLA data flow scenario Planning for supporting applications Planning for IBM Tivoli Service Level Advisor Physical considerations Architecture considerations Source applications considerations Planning for event notification Planning worksheets
52
3.1 IBM Tivoli Service Level Advisor data flow

In order to better understand how to plan an IBM Tivoli Service Level Advisor environment implementation, we will describe a typical ITSLA data flow scenario with all the components making up the IBM Tivoli Service Level Advisor solution. The scenario will help in understanding the main constraints to be considered during the project implementation phase. Possible areas of consideration are as follows: The single points of failure in the IBM Tivoli Service Level Advisor environment The network load and the configuration of communication among the IBM Tivoli Service Level Advisor solution components The hardware requirements The synchronization between the different activities in an IBM Tivoli Service Level Advisor environment, for example, the Source ETL and Target ETL data transfer, the IBM Tivoli Service Level Advisor evaluation of service level agreements, and the access to the IBM Tivoli Service Level Advisor reports provided by the ITSLA Reports Server component The scenario described is shown in Figure 3-1 on page 55. The legend used in that scenario is related to a specific activity and explained as follows:
A1, A2, ..., An
These letters represent the data transfer activity performed by the Source ETLs, moving data from the source application databases to the TEDW Central Warehouse database. This potentially large data transfer is initiated, executed, and managed by the TEDW Control Center component. If the TEDW Control Center is installed on a separate machine from the TEDW Central Warehouse database, the data passes from the source application databases through the TEDW Control Center machine to arrive at the TEDW Central Warehouse database, resulting in a dramatic increase in network traffic. The Source ETLs must not run concurrently, as the data transfer could fail. This letter represents the data transfer executed by the Target Registration ETL, which moves the data from the TEDW Central Warehouse database to the ITSLA Database. The data flow is initiated, executed, and managed by the TEDW Control Center component. If the TEDW Control Center is installed on a separate machine from the TEDW Central Warehouse database, the data passes from the TEDW Central Warehouse database
Chapter 3. Implementation planning
53
through the TEDW Control Center machine to the ITSLA

Database, resulting in an increase in network traffic. C This letter represents the data transfer executed by the Target Process ETL, which moves the data from the TEDW Central Warehouse database to the ITSLA Measurement Data Mart database. The ITSLA Server analyzes this data to find SLA violations and trends that might indicate a violation is imminent. The data flow is initiated, executed, and managed by the TEDW Control Center. If the TEDW Control Center is installed on a separate machine from the TEDW Central Warehouse database, the data passes from the TEDW Central Warehouse database through the TEDW Control Center machine to the ITSLA Measurement Data Mart database, resulting in an increase in network traffic. These letters represent the ITSLA Web Console and Java Console data flow. All administrative tasks are performed through the ITSLA Web Console, while the trace and message logging configuration and viewing are ITSLA Java Console tasks. The ITSLA Task Drivers component is responsible for managing the ITSLA Console data movement. Keep in mind that the ITSLA Java Console can only be accessed on the machine where the ITSLA Task Drivers component is installed, while the ITSLA Web Console can be accessed by any machine with a supported Web browser. One area that must be taken into consideration is the network traffic generated between the ITSLA Task Drivers machine and the ITSLA Database Server machine. The ITSLA Task Drivers component is responsible for inserting the defined offerings and orders into the ITSLA Database. The ITSLA Server performs the service level agreements evaluation on the data stored into the ITSLA Measurement Data Mart database and stores the results in the ITSLA Database. The amount of data transferred is dependent on the amount of data analyzed during the evaluation process.
D, E
54
H, I
When the service level evaluation performed by the ITSLA Server has completed, users will be able to connect to the ITSLA Reports Server through a Web browser to view the evaluation results and do reporting. The ITSLA Reports Server accesses the SLA violations and trend analysis data stored in the ITSLA Database through an IBM DB2 database client and creates the customized reports for the end users. The number of users connected to the ITSLA Reports Server is a very important parameter to take into consideration during the planning phase.
Source ETLs
Target ETLs ITSLA Reports Console (Web Browser)
TEDW Control Center (DB2 Server) Source Application 1 Database
A1
ITSLA Database
H I
A2
Source Application 2 Database
TEDW Server TEDW Central Warehouse (DB2 Server)
C
An
ITSLA Database Server (DB2 Server)
ITSLA Reports Server (WebSphere)
Source Application N Database
ITSLA Task Drivers (Tivoli Presentation Services)
D
ITSLA Server
ITSLA Java Console
ITSLA Web Console (Web Browser)
Figure 3-1 ITSLA data flow scenario
In the next sections the supporting applications required by the numerous IBM Tivoli Service Level Advisor components are described, along with their software and hardware requirements. Recommendations for the placement of each supporting application is also included.
55
3.2 Planning for supporting applications

This section gives a brief introduction into planning for supporting applications. For specific information, refer to the product support manuals and related publications for each application. As explained in 2.2, IBM Tivoli Service Level Advisor components on page 19, IBM Tivoli Service Level Advisor uses the following supporting applications, which must be correctly installed and configured before installation of IBM Tivoli Service Level Advisor can commence: IBM WebSphere Application Server IBM DB2 Universal Database Enterprise Edition Tivoli Enterprise Data Warehouse
3.2.1 IBM WebSphere Application Server

The IBM Tivoli Service Level Advisor Reports Server component runs in the same environment as the IBM WebSphere Application Server. The IBM WebSphere Application Server is used for the publishing of reports servlets, allowing them to be accessed through a supported Web browser. IBM Tivoli Service Level Advisor ships with the media and a single license for IBM WebSphere Application Server Advanced Edition Single-Server 4.0.1. Entitlement for this license is for the IBM Tivoli Service Level Advisor environment only.
Hardware and software requirements

The hardware and software requirements depend on the number of users accessing the ITSLA Reports Server component, as well as whether the ITSLA Reports Server component shares the same hardware with any other IBM Tivoli Service Level Advisor components (distributed installation). In any case, the hardware requirement is the same one indicated for the ITSLA Reports Server component. If you have already deployed a the IBM WebSphere Application Server production environment in your enterprise, for performance reasons, we recommended that you do not share it with the IBM Tivoli Service Level Advisor environment and use a brand new installation of IBM WebSphere Application Server. Generally you may use the IBM WebSphere Application Server Advanced Edition Single-Server 4.0.1 licence provided and install it on the same machine as the ITSLA Reports Server component.
56
For more information concerning hardware and software requirements and on optimizing the IBM WebSphere Application Server, visit the WebSphere Infocenter at the following link:
http://www-3.ibm.com/software/webservers/appserv/infocenter.html
Network considerations
The IBM WebSphere Application Server utilizes two specific TCP/IP ports when used with IBM Tivoli Service Level Advisor: 9090 9080 Port used by IBM WebSphere Application Server for administration purposes Port used by IBM WebSphere Application Server for communication with the ITSLA Reports Server component
Logical design considerations

If you already have an IBM WebSphere Application Server infrastructure in place, IBM Tivoli Service Level Advisor may be integrated into this existing environment. The following are IBM WebSphere Application Server versions currently supported by IBM Tivoli Service Level Advisor: IBM WebSphere Application Server SE 3.5 IBM WebSphere Application Server Advanced Edition (AE), Version 4.0.1, 4.0.2 IBM WebSphere Application Server Advanced Edition Single-Server (AES), Versions 4.0.1, 4.0.2
3.2.2 IBM DB2 Universal Database Enterprise Edition

The Tivoli Enterprise Data Warehouse and IBM Tivoli Service Level Advisor databases runs in an IBM DB2 Universal Database Enterprise Edition Version 7.2 (Fixpack 5 included) environment. IBM Tivoli Service Level Advisor ships with the media and a single license for IBM DB2 Universal Database Enterprise Edition Version 7.2. Entitlement for this license is for the IBM Tivoli Service Level Advisor environment only.

For hardware and software requirements for IBM DB2 Universal Database Enterprise Edition Version 7.2, visit the IBM DB2 Universal Database Enterprise Edition online support page at the following link:
http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7pubs.d2w/ en_main
57
Note: The IBM DB2 Universal Database Enterprise Edition Data Warehouse Center component can run only on either Windows NT or Windows 2000; therefore, the TEDW Control Center component, which depends on the IBM DB2 Universal Database Enterprise Edition Data Warehouse Center, will only run on those operating systems.
If you intend to run the IBM DB2 Universal Database Enterprise Edition instances and databases for the TEDW Central Warehouse on a Windows NT or Windows 2000 platform, you can eliminate network traffic between the TEDW Control Center and the TEDW Central Warehouse components by having them installed on the same machine. For a detailed list of the TCP/IP ports used by IBM DB2 Universal Database Enterprise Edition refer to Tivoli Enterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744.

If you already have an IBM DB2 Universal Database Enterprise Edition Version 7.2 environment in your enterprise, the TEDW Central Warehouse and IBM Tivoli Service Level Advisor databases can be installed in the current environment. You may also have the option to upgrade the current environment to Version 7.2 (Fixpack 5 included). All source applications providing data for IBM Tivoli Service Level Advisor ETLs (also known as Warehouse Enablement Packs or warehouse packs), as well as the ITSLA ETL programs (Process and Registration ETLs), must be installed on the same physical machine as the TEDW Control Center component. All the data being transferred from the source applications databases to the TEDW Central Warehouse database, as well as from the TEDW Central Warehouse database to the ITSLA Database and ITSLA Measurement Data Mart, passes though the TEDW Control Center machine. It is very important to understand this when planning for the database placement in your environment. For planning information on IBM DB2 Universal Database Enterprise Edition, refer to DB2 UDB Administration Guide: Planning Version 7, SC09-2946.
58
3.2.3 Tivoli Enterprise Data Warehouse

When planning for your Tivoli Enterprise Data Warehouse installation, be sure to take into account not only the space required for the Tivoli Enterprise Data Warehouse application files, but also the following: The accumulation of large amounts of historical data generated by the source applications in the TEDW Central Warehouse database. As this data will grow over time, allocate space generously, keeping in mind that the data warehouse contains a purge utility to help you manage your warehouse content and space. Space for TEDW Data Marts and Reports, both prepackaged with warehouse packs and those created or customized by your company. Space for report output, which is stored in the control database (TWH_MD database) on the TEDW Control Center component. Space for each warehouse pack, making sure to account for both the installed files and the additional historical data that might be collected by the warehouse pack. Consider that the TEDW Data Mart database (TWH_MART database) is not used by the IBM Tivoli Service Level Advisor solution, as IBM Tivoli Service Level Advisor has its own data mart database, the ITSLA Measurement Data Mart database. The TEDW Data Mart database, however, may be used for other applications. Refer to the Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, for placement and sizing considerations for the TEDW Data Mart database.

Refer to Tivoli Enterprise Data Warehouse Release Notes Version 1.1, GI11-0857, for information about hardware prerequisites, specific database and operating system support, and product prerequisites.
You must allocate TCP/IP port numbers for Tivoli Enterprise Data Warehouse for the following purposes: Communication between the TEDW Control Center and the remote TEDW Central Warehouse database Communication between the TEDW Control Center and the remote ITSLA Database Server machine Communications for the IBM Console Secure Sockets Layer (SSL) encryption connections to the IBM Console (optional)
59
Note: You must pay attention when specifying TCP/IP port numbers during the Tivoli Enterprise Data Warehouse installation, as specifying port numbers that are already in use by other programs causes the installation to lock up. Table 3-1 lists the default port numbers used by the Tivoli Enterprise Data Warehouse, the names of the ports during the install process, descriptions of what the ports are used for, and whether the default values can be changed:
Table 3-1 Default TCP/IP port numbers used by the TEDW
Default port number 50000 Name of port in InstallShield Wizard Database port for TEDW Control Center Database port for TEDW Central Data Warehouse Database port for the TEDW Data Mart 80 IBM HTTP Server port IBM HTTP Server port used by Tivoli Presentation Services HTTP Server for HTTP communications Used by Tivoli Presentation Services HTTP Administration Used by Server for IBM Console (part of Tivoli Presentation Services) Used by Web Services for the IBM Console (part of Tivoli Presentation Services) Used by Web Services for the IBM Console (part of Tivoli Presentation Services) Used by the IBM Console (part of Tivoli Presentation Services) Description Can the default be changed?
In a distributed installation, used by the TEDW Data Mart server, TEDW Central Data Warehouse server, and TEDW report server to communicate with the TEDW Control Center server
Yes, during IBM DB2 Universal Database Enterprise Edition Server installation. Refer to the IBM DB2 Universal Database Enterprise Edition installation documentation for more information. Yes, during installation of the TEDW Reports Interface.
8008 8010
IBM HTTP Administration port Server For IBM Console IPC port Web Console port
Yes, during installation of the TEDW Reports Interface. Yes, during installation of the TEDW Reports Interface. Yes, during installation of the TEDW Reports Interface. Yes, during installation of the TEDW Reports Interface. Yes, during installation of the TEDW Reports Interface.
8007
8040
Web Console IPC port IBM Console IPC port
8030
60
Default port number 8050
Name of port in InstallShield Wizard Not applicable
Description
Can the default be changed?
Used by Server for IBM Console (part of Tivoli Presentation Services) Used by Tivoli Presentation Services HTTP Server for secure HTTP communications (HTTPS)
No.
443
Not applicable
Yes, using Tivoli Presentation Services HTTP Administration.

You can deploy Tivoli Enterprise Data Warehouse one of two ways: As a single system installation, with all the components installed on a single system. This cannot be done on a UNIX platform, as the TEDW Control Center component can only run on the Windows platform. This is convenient for demonstrations, as an educational or test platform, and for companies that do not plan to have many users concurrently analyzing data and that do not need to capture and analyze large amounts of data in the warehouse. As a distributed installation, with the components installed on multiple systems and platforms in your enterprise, including UNIX servers. Multiple components can be installed on one system, provided that the operating system supports those components. An important consideration is for users to be able to access your warehouse data in more than one way, as follows: Using a Web browser and the IBM Console graphical user interface, users can create, customize, and run reports that access data marts through the report interface. Using other reporting, OLAP, and analytical tools, users can access data in the data marts using an interface that is already in use in your business. Refer to Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, for more information on Tivoli Enterprise Data Warehouse components placement, as well as Web browser and security considerations.
3.3 Planning for IBM Tivoli Service Level Advisor

In this section we will discuss the physical and the architectural considerations for IBM Tivoli Service Level Advisor planning.
61
As described in 2.2, IBM Tivoli Service Level Advisor components on page 19, IBM Tivoli Service Level Advisor has three core components to install and configure: ITSLA Server ITSLA Reports Server ITSLA Task Drivers Any of these three components can be installed separately, or in any possible combination with another to form a distributed installation. The components communicate with each other using the TCP/IP ports described in Table 3-2.
Table 3-2 Ports used by the ITSLA components
Port number 9990 Purpose Command line interface port Description The Command Line Interface (CLI) service port used to communicate with the ITSLA Server, the ITSLA Reports Server, and the ITSLA Task Drivers. The CLI Service is installed with the ITSLA Server component. Used for communication between the ITSLA Server and the ITSLA Task Drivers.
9980
ITSLA Server Communication port
3.3.1 Physical considerations

The following section describes the hardware, software, and Web browser requirements for IBM Tivoli Service Level Advisor. As this is for reference only, consult IBM Tivoli Service Level Advisor Release Notes Version 1.1, GI11-0908, for detailed information.
Hardware requirements
Each component of the IBM Tivoli Service Level Advisor has the minimum hardware requirements described in Table 3-3.
Table 3-3 Hardware requirements for ITSLA
Hardware and operating system CPU Memory HDD
IBM eServer pSeries (RS/6000) - AIX

IBM eServer xSeries (Netfinity) and other Intel Pentium brands Microsoft Windows or Linux
375 MHz or higher

650 MHz or higher
1 GB or higher
1 GB or higher
1 GB or higher
1 GB or higher
62
Hardware and operating system Sun SPARC - Solaris
CPU 400 MHz or higher
Memory 1 GB or higher
HDD 1 GB or higher
Note: Large configurations significantly increase the amount of memory required for the Reports Server and Web-based console. For example: 512 MB may only support 10 - 15 concurrent users 1 GB may only support 25 - 30 concurrent users If all components in your environment will be installed on a single machine, we recommend the information shown in Table 3-4.
Table 3-4 Single machine installation hardware requirements for ITSLA
CPU Dual Processor 1 GHz or higher Memory 2 GB or higher HDD 2 GB or higher
Hardware and operating system IBM eServer xSeries (Netfinity) and other Intel Pentium brands Microsoft Windows
Software requirements
Table 3-5 describes the software requirements of IBM Tivoli Service Level Advisor in terms of supported operating systems, relational databases, and Java runtime environment.
Table 3-5 Software requirements for ITSLA
Platform ITSLA Server Operating system Windows NT 4.0 SP 6+ Windows 2000 Advanced Server Edition SP2+ Windows 2000 Server SP2+ Linux RedHat 7.1 Linux SuSE 7.1 AIX 4.33, 5.1 Solaris 2.7, 2.8 1.3.1_01 Java Runtime Environment 1.3.0 SR10 Database 7.2 Client with Fixpack 5
63
Platform ITSLA Reports Server
Operating system Windows NT 4.0 SP 6+ Windows 2000 Advanced Server Edition SP2+ Windows 2000 Server SP2+ Linux RedHat 7.1 Linux SuSE 7.1 AIX 4.33, 5.1 Solaris 2.7, 2.8
Java Runtime Environment 1.3.0 SR10
Database 7.2 Client with Fixpack 5
1.3.1_01 1.3.0 SR10 7.2 Client with Fixpack 5
ITSLA Task Drivers
Windows NT 4.0 SP 6+ Windows 2000 Advanced Server Edition SP2+ Windows 2000 Server SP2+ Linux RedHat 7.1 Linux SuSE 7.1 AIX 4.33, 5.1 Solaris 2.7, 2.8
1.3.1_01 1.3.0 SR10 7.2 Server with Fixpack 5
Windows NT 4.0 SP 6+ Windows 2000 Advanced Server Edition SP2+ Windows 2000 Server SP2+ AIX 4.33, 5.1 Solaris 2.7, 2.8
1.3.1_01
Web browser support

IBM Tivoli Service Level Advisor supports the Web browsers for the listed operating systems and language locales shown in Table 3-6.
Table 3-6 ITSLA Web browser support
Operating system Windows NT 4.0 SP6+ Windows 2000 Advanced Server SP2+ Locale jp, zh_CN, zh_TW ko Others Internet Explorer 5.x, 6.0 5.x, 6.0 5.x, 6.0 Netscape 4.78 None 4.6x, 4.7x
64
Operating system AIX 4.33, 5.1 Solaris 2.7, 2.8 Linux RedHat 7.1 Linux SuSE 7.1
Locale All
Internet Explorer None
Netscape 4.6x, 4.7x
3.3.2 Architecture considerations

IBM Tivoli Service Level Advisor and its components are normally deployed inside the back office of the enterprise, protected behind firewalls. This eliminates the need for an additional security infrastructure to be deployed. The IBM Tivoli Service Level Advisor source applications and their databases may reside elsewhere in the enterprise or in the same protected infrastructure. Figure 3-2 gives a graphical overview of a possible IBM Tivoli Service Level Advisor deployment.
Source Application Databases ITSLA Server

Source ETLs ITSLA ETL ITSLA Database
TEDW Control Center
TEDW Server
TEDW Central Warehouse Source ETLs
ITSLA ETL
Source Application Databases
ITSLA Task Drivers IBM Console ITSLA Reports Server
Web Server
Web Server
Web browser clients ITSLA Administrators
Firewall 2
Web browser clients
Firewall 1
Back office
DMZ
Internet
More Secure
Less Secure
Figure 3-2 ITSLA architecture component placement
65
As a speculation in the above scenarios, if the ITSLA Reports component whereas installed on one of the Web Servers in the DMZ, and not on a server in the back office, ports 9090 and 9080 would need to be opened on Firewall 2, as shown in Figure 3-2 on page 65, to allow communication between the Web browsers in the back office area and the ITSLA Reports Server. In addition to that, in order to allow communication between the ITSLA Reports Server and the ITSLA Database Server, the ports used for database communication will need to be opened in the same firewall (the DB2 UDB default ports used for server-client communication are 50000 and 50001). Also, in order to allow CLI communication between the ITSLA Server, ITSLA Task Drivers, and the ITSLA Reports Server, you will need to open the ITSLA CLI port chosen during the installation process in the firewall (the default ITSLA CLI port is 9990).
Architectural considerations for the ITSLA Server

The ITSLA Server is the management server for IBM Tivoli Service Level Advisor and can be installed on a machine in the back office intranet, which satisfies the hardware and software requirements. During the time period when service level agreement evaluations are being performed by the ITSLA Server, you must consider the potentially heavy network traffic between the ITSLA Server and the ITSLA Measurement Data Mart database. All service level agreements evaluations are scheduled based on the time zone of the ITSLA Server, which must be taken into consideration for a distributed installation across time zones. Section 5.5.2, ITSLA evaluation schedule and time zone considerations on page 195, provides additional information on scheduling service level agreement evaluations and time zone considerations. If the ITSLA Server is installed on a different physical machine from the ITSLA Database and ITSLA Measurement Data Mart database, then you must install and configure IBM DB2 Universal Database Enterprise Edition Client on the machine with the ITSLA Server, as this component is responsible for performing SLA evaluation on the data stored in the ITSLA Measurement Data Mart database and inserting the results into the ITSLA Database. Section 4.5, Setting up the ITSLA Server machine on page 106, provides additional information on how to catalog the ITSLA Databases.
Architectural considerations for the ITSLA Reports Server

By providing Java-based report servlets, the ITSLA Reports Server enables a customer to access IBM Tivoli Service Level Advisor service level reports via a supported Web browser.
66
The ITSLA Reports Server component runs in the same environment as the IBM WebSphere Application Server and must be installed on the same physical machine. If your current infrastructure utilizes IBM WebSphere Application Server SE Version 3.5 or IBM WebSphere Application Server AE (any version), then the reports servlets will have to be manually integrated into the IBM WebSphere Application Server environment. It is recommended that you use IBM WebSphere Application Server AES 4.0.1 or later. The ITSLA Reports Server component runs on top of the IBM HTTP Server, which is installed along with the ITSLA Reports Server component. If you already have other Web Server software like Microsoft IIS or IBM Apache server up and running on the same physical machine, you will need to change the default installation port numbers for the ITSLA Reports IBM HTTP Server. Note: if there is already a Web server such as Microsoft IIS on the system where you plan to install the ITSLA Report Server, you must uninstall or disable that Web server, or specify different port numbers for the HTTP Server port and HTTP Administration port for Tivoli Presentation Services during the Reports Interface installation During the installation of the ITSLA Reports Server you will be asked for the node name of where the IBM WebSphere Application Server is running. This name is assigned during IBM WebSphere Application Server installation and might be the short name or the fully qualified name of the machine. If the ITSLA Reports Server component is installed on a different physical machine from the ITSLA Database and ITSLA Measurement Data Mart databases, then you must install and configure IBM DB2 Universal Database Enterprise Edition client on the ITSLA Reports Server machine. Section 4.5, Setting up the ITSLA Server machine on page 106, provides additional information on how to catalog the ITSLA Databases.
Architectural considerations for the ITSLA Task Drivers

The ITSLA Task Drivers are one of the components of the ITSLA installation and integrates into the IBM Console Server. These task drivers provide a Web-based graphical user interface from which administration tasks are performed through the IBM Web Console and the IBM Java Console. The ITSLA Task Drivers component is installed on the same physical machine running the three main pieces of Tivoli Presentation Services and are installed during TEDW Report Interface component installation: Server for IBM Console Web Services for IBM Console and IBM Console
67
Note: The Server for IBM Console, the Web Services for IBM Console, and the IBM Console are all referred to as the IBM Console Server. If the ITSLA Task Drivers and the IBM Console Server are installed on a different physical machine from the ITSLA Database and ITSLA Measurement Data Mart database, then you must install and configure IBM DB2 Universal Database Enterprise Edition client on the machine with the ITSLA Task Drivers. Section 4.5, Setting up the ITSLA Server machine on page 106, provides additional information on how to catalog the ITSLA Databases.
Architectural considerations for the Target ETL

IBM Tivoli Service Level Advisor ships with two ETL programs constituted of two different steps: The Target Registration ETL and the Target Process ETL. The ITSLA Target ETLs must be installed on the same physical machine as the TEDW Control Center. The ITSLA Database and Measurement Data Mart databases (whose default names are DYK_CAT and DYK_DM, respectively) should be installed and created, and the TEDW Control Center configured before the Target ETLs are installed. As described in Section 3.1, IBM Tivoli Service Level Advisor data flow on page 53, the Target ETLs are responsible for the data flow between the TEDW Central Warehouse database and the ITSLA Databases. If the TEDW Control Center, TEDW databases, and ITSLA Databases are all installed on separate machines, consider the impact on network performance the Target ETLs data movement could have.
Architectural considerations for the ITSLA Databases

The ITSLA Databases can be created on the same physical machine or on separate machines. They can be created on the same physical machine as the Data Warehouse or even in the same IBM DB2 Universal Database Enterprise Edition instance, depending on scalability, performance, and availability considerations. It is recommended, though not necessary, that separate instances are created for the TEDW Central Warehouse, ITSLA Database, and ITSLA Measurement Data Mart databases for the following reasons: Installation of the ITSLA Database and ITSLA Measurement Data Mart databases requires the stopping, starting, and termination of the instance, which will interrupt any other applications connected to that instance. The ITSLA solution performs better when separate instances are used.
68
The databases are better protected from data loss. Maintenance and backup purposes. Tip: For each IBM Tivoli Service Level Advisor database you create, approximately 30 to 50 MB of space is initially required to hold the database tables. Approximately the same amount of memory is also required.
3.3.3 Planning considerations for source applications

IBM Tivoli Service Level Advisor currently supports the Tivoli products (listed in Table 3-7) as default source applications able to insert data in the Tivoli Enterprise Data Warehouse databases.
Table 3-7 Supported source Tivoli applications
Product IBM Tivoli Monitoring IBM Tivoli Monitoring for Transaction Performance (TWSM) IBM Tivoli Monitoring for Transaction Performance (TAPM) IBM Tivoli Enterprise Console IBM Tivoli Business Systems Manager Version 3.7 1.7 2.1 3.7.1 1.5 Patches required 3.7-DMN-0018 1.7-WSM-0003 N/A N/A 1.5-BSM-0034
The Source ETLs for the above applications are shipped with the source application installation media, while the ITSL Target ETLs can be found on the IBM Tivoli Service Level Advisor installation media. As described in 4.4, Setting up the TEDW Control Center machine on page 90, all ETL programs are installed from their respective installation media through the TEDW installation process. If you already have source application databases defined in your environment, you will need to configure an ODBC connection on the machine where the TEDW Control Center component is installed in order to allow communication between the source applications ETL and the TEDW Central Warehouse database. In order to ensure connectivity, a database client must be installed on the TEDW Control Center machine for all source databases. For example, if the IBM Tivoli Monitoring (Distributed Monitoring TDS) source database uses an Oracle
69
database, and the IBM Tivoli Enterprise Console source database uses an Informix database, then both the Oracle client and the Informix client must be installed and configured on the TEDW Control Center machine, as well as the ODBC connections to those databases. For more information on changing your ODBC connection information, refer to 4.4.6, Configuring the ODBC connections on page 103. Consider that the data transfer from the source application databases to the TEDW Central Data Warehouse is the heaviest in the IBM Tivoli Service Level Advisor environment, and the time it takes strongly depends on the amount of data to transfer, and from the network speed. The source application ETLs perform this data transfer and it is advisable to not run them concurrently, otherwise the data movement process could fail.
IBM Tivoli Monitoring

In order for IBM Tivoli Service Level Advisor to use IBM Tivoli Monitoring (ITM) data, the Tivoli Decision Support (TDS) product with the Server Performance Prediction guide has to be installed and configured in your enterprise. For more information on installing and configuring TDS, refer to the Tivoli Decision Support Installation Guide, GC32-0438, and Tivoli Decision Support for Server Performance Prediction TDS_Guide_for_SPP_21 , which is provided with the IBM Tivoli Monitoring Source ETL installation media. Some considerations on the IBM Tivoli Monitoring Source ETL follow: The source database for the IBM Tivoli Monitoring Source ETL is the Tivoli Decision Support database for which the RIM object SPR_RIM is configured. Patch 3.7-DMN-0018 is required for the IBM Tivoli Monitoring application and must be installed prior to running the IBM Tivoli Monitoring Source ETL. For more information, refer to Tivoli Distributed Monitoring Warehouse Enablement Pack: Implementation Guide, which is provided with the IBM Tivoli Monitoring Source ETL installation media.
IBM Tivoli Monitoring for Transaction Performance (TWSM)

Some considerations for the IBM Tivoli Monitoring for Transaction Performance (TWSM) Source ETL follow: The source database for the IBM Tivoli Monitoring for Transaction Performance (TWSM) Source ETL is the WebServices Courier database.
70
Patch 1.7-WSM-0003 along with eFix 1.7-WSM-0003e is required for the IBM Tivoli Monitoring for Transaction Performance (TWSM) application and must be installed prior to running the IBM Tivoli Monitoring for Transaction Performance (TWSM) Source ETL. The eFix can be downloaded at the following site by using the anonymous user:
ftp://ftp.tivoli.com/support/patches/LA/1.7-WSM-0003E.almondbutter
For more information, refer to Tivoli Web Services Manager Warehouse Enablement Pack: Implementation Guide, which is provided with the IBM Tivoli Monitoring for Transaction Performance (TWSM) Source ETL installation media.
IBM Tivoli Monitoring for Transaction Performance (TAPM)

Some considerations for the IBM Tivoli Monitoring for Transaction Performance (TAPM) Source ETL follow: The source database for the IBM Tivoli Monitoring for Transaction Performance (TAPM) Source ETL is the TAPM database for which the TAPM RIM object is configured. No additional patches are required for IBM Tivoli Monitoring for Transaction Performance (TAPM). For more information, refer to Tivoli Application Performance Manager Warehouse Enablement Pack: Implementation Guide, which is provided with the IBM Tivoli Monitoring for Transaction Performance (TAPM) Source ETL installation media.
IBM Tivoli Enterprise Console

Some considerations for the IBM Tivoli Enterprise Console Source ETL follow: The source database for the IBM Tivoli Enterprise Console Source ETL is the TEC Event database for which the TEC RIM object is configured. No additional patches are required for the IBM Tivoli Enterprise Console. For more information, refer to Tivoli Enterprise Console Warehouse Enablement Pack: Implementation Guide, which is provided with the IBM Tivoli Enterprise Console Source ETL installation media.
IBM Tivoli Business Systems Manager

Some considerations for the IBM Tivoli Business Systems Manager Source ETL follow: The source database for the IBM Tivoli Business Systems Manager Source ETL is the TBSM Microsoft SQL database.
71
Patch 1.5-BMS-0034 is required for the IBM Tivoli Business Systems Manager application and must be installed prior to running the IBM Tivoli Business Systems Manager Source ETL. For more information, refer to Tivoli Business Systems Manager Warehouse Enablement Pack: Implementation Guide, which is provided with the IBM Tivoli Business Systems Manager Source ETL installation media.
3.4 Planning for event notification

When IBM Tivoli Service Level Advisor evaluates measurement data, an event notice can be sent to alert management or support personnel when violations or potential violations have been discovered, enabling them to take corrective action to maintain agreed-upon levels of service to the customer. The IBM Tivoli Service Level Advisor event notification function also provides information on IBM Tivoli Service Level Advisor application problems. Any of the following notification methods can be used, either separately or concurrently: SNMP Trap TEC Event E-mail The event notification method is specified during the IBM Tivoli Service Level Advisor installation, but can be activated, changed, or configured through a set of IBM Tivoli Service Level Advisor CLIs.
3.4.1 SNMP Trap notification

You can configure IBM Tivoli Service Level Advisor to send notification events in the form of SNMP Traps to Tivoli NetView or any other SNMP managers. In order to configure ITSLA to send a SNMP Trap, you will need to provide during the following information during installation: Destination host name This is the fully qualified host name of the destination machine acting as the receiving SNMP management station for SNMP Traps. This is the SNMP Trap destination port number. A default value of 162 is provided. Specify a different port number if needed. This is an optional field containing the SNMP Trap service community name. A default value of public is provided.
Destination port
Community name
72
Since IBM Tivoli Service Level Advisor does not filter SNMP Traps sent to the configured SNMP manager, you must either configure for SNMP ITSLA traps to be sent, or not to be sent at all. Because of this, you must configure a filter on your SNMP manager in order to discard SNMP Traps being sent by IBM Tivoli Service Level Advisor that you do not need. For more information on the MIB that is used to format the SNMP Traps for ITSLA events, see the SNMP Trap event notification section of Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. In addition, you will have to configure the ITSLA SNMP Trap definition on your SNMP manager. If your SNMP Trap receiver is NetView for Windows NT, IBM Tivoli Service Level Advisor traps can be created and formatted by using the example provided in Event escalation on page 325.
3.4.2 TEC Event notification

By using the non-TME connection method, IBM Tivoli Service Level Advisor can be configured to send a TEC Event if you already have a functional TEC Server in your environment. As IBM Tivoli Service Level Advisor itself cannot directly execute a program or a task as a response to an event, you can configure the event to be forwarded to TEC, where rules can then be written to execute the desired program or task. The TEC Event Server must be configured to receive IBM Tivoli Service Level Advisor events. To configure IBM Tivoli Service Level Advisor to send a TEC Event, you will need the following information: TEC Event server host name This is the fully qualified host name where the Tivoli Enterprise Console event server is installed. If the event server is installed on a Windows machine, enter the port number that the event server uses to listen on for events. The typical port value is 5529.
TEC Event server port
IBM Tivoli Service Level Advisor provides a baroc file, SLM.baroc, located in the ITSLA_Inst_Dir/tec directory, where ITSLA_Inst_Dir is the ITSLA Server installation directory. SLM.baroc is the SLA Event class definition file for the TEC server, with the defined event classes listed below: SLA-Base-Event SLA-Violation-Event SLA-Trend-Event SLA-Trend-Cancel-Event
73
The SLM.baroc file must be imported and compiled in the TEC rule base in order to enable the IBM Tivoli Service Level Advisor events reception on the TEC server. The content of the SLM.baroc file is given in Example 3-1 on page 74. For more information on how to import and compile baroc files on the TEC server, consult the TEC documentation.
Example 3-1 Contents of the SLM.baroc file
TEC_CLASS: SLA-Base-Event ISA EVENT DEFINES { source: default = "IBM Tivoli Service Level Advisor"; sub_source: default = "Service Level Agreement Manager"; metricName: STRING; componentName: STRING; componentLongName: STRING; consumerName: STRING; customerOrderID: STRING; offeringName: STRING; realm: STRING; accountID: STRING; serviceElementName: STRING; scheduleState: STRING; }; END TEC_CLASS: SLA-Violation-Event ISA SLA-Base-Event DEFINES { startDate: STRING; endDate: STRING; minMetricValue: STRING; minBreachValue: STRING; maxMetricValue: STRING; maxBreachValue: STRING; avgMetricValue: STRING; avgBreachValue: STRING; }; END TEC_CLASS: SLA-Trend-Event ISA SLA-Base-Event DEFINES { elementInstanceID: STRING; minProjectedDate: STRING; maxProjectedDate: STRING; avgProjectedDate: STRING; }; END
74
TEC_CLASS: SLA-Trend-Cancel-Event ISA SLA-Base-Event DEFINES { elementInstanceID: STRING; }; END
TEC_CLASS: SLM-Application-Event ISA EVENT DEFINES { source: default = "IBM Tivoli Service Level Advisor"; }; END
IBM Tivoli Service Level Advisor provides a sample TEC rule that automates the closing of IBM Tivoli Service Level Advisor trend events. However, if you want to receive only certain types of events, you must create and configure your own TEC rule to discard the undesired events, as IBM Tivoli Service Level Advisor does not filter the events sent to TEC. The TEC rule file name is slm.rls and is located in the same directory as the SLM.baroc file. The content of the slm.rls file is given in Example 3-2.
Example 3-2 Contents of the slm.rls file
rule: trend_cancel: ( event: _event of_class 'SLA-Trend-Cancel-Event' where [ status: equals 'OPEN' , metricName: _metricName , elementInstanceID: _elementInstanceID , componentName: _componentName, scheduleState: _scheduleState ] , reception_action: ( all_instances(event: _trn_ev of_class 'SLA-Trend-Event' where [ metricName: equals _metricName, elementInstanceID: equals _elementInstanceID, componentName: equals _componentName, scheduleState: equals _scheduleState, status: outside ['CLOSED'] ] ),
75
change_event_status(_trn_ev, 'CLOSED'), drop_received_event ) ).
3.4.3 E-mail notification

If you would like to notify specific support and management personnel when SLA violations or trends occur, or when the IBM Tivoli Service Level Advisor application experiences problems, IBM Tivoli Service Level Advisor can be configured to send multiple e-mails based on the information regarding violation, trend, or application events. To configure IBM Tivoli Service Level Advisor to send an e-mail, you will need to decide on the following information: SMTP Server host name To-list e-mail addresses This is the fully qualified host name of the SMTP Server to handle the e-mail messages. Here you have the list of e-mail addresses, separated by commas, for the people you want notifications to be sent to. Here you add one or more e-mail addresses, separated by commas, for additional people you want to notify on the message. This might be reserved for supervisory personnel or other people who may not deal directly with the violation or trend information, but who want to stay informed.
CC-list e-mail addresses
3.5 Planning worksheets

The following tables provide some planning worksheets to aid the planning and installation of IBM Tivoli Service Level Advisor and supporting applications.
Table 3-8 Planning worksheet for IBM WebSphere Application Server
Planning for IBM WebSphere Application Server Node name of IBM WebSphere Application Server Host name and IP address of IBM WebSphere Application Server
76
Planning for IBM WebSphere Application Server Currently installed IBM WebSphere Application Server version IBM WebSphere Application Server installation directory
Table 3-9 Planning worksheet for databases

Planning for databases TEDW Control Center component host name and IP address TEDW Server host name and IP address TEDW Central Warehouse instance name TEDW Central Warehouse instance user name/password ITSLA Measurement Data Mart Server host name and IP address ITSLA Measurement Data Mart database instance name ITSLA Measurement Data Mart database instance user name/password ITSLA Database Server host name and IP address ITSLA Database instance name ITSLA Database instance user name/password
Table 3-10 Planning worksheet for ITSLA

Planning for IBM Tivoli Service Level Advisor ITSLA Server host name and IP address ITSLA Reports Server host name and IP address (must be installed on the IBM WebSphere Application Server machine) ITSLA Task Drivers server host name and IP address (must be installed on the Tivoli Presentation Services machine)
77
Table 3-11 Planning worksheet or event notification

Planning for event notification Notification by SNMP Trap Destination host name Destination port Community name (optional) Notification by TEC Event TEC Server host name TEC Server port Notification by e-Mail SMTP server host name To-list of e-mail addresses CC-list of e-mail addresses (optional)
78
Chapter 4.
Getting IBM Tivoli Service Level Advisor up and running

This chapter describes the installation and configuration procedures in order to have IBM Tivoli Service Level Advisor (ITSLA) up and running. The installation process will be presented using a typical environment as example. The installation and configuration of the following ITSLA components and prerequisite applications are discussed in this chapter: IBM DB2 Universal Database Enterprise Edition Tivoli Enterprise Data Warehouse Server Tivoli Enterprise Data Warehouse Control Center IBM WebSphere Application Server IBM Console Server ITSLA Database Server ITSLA Task Drivers ITSLA Server ITSLA Reports Server ITSLA ETL programs
79
4.1 Example scenario

In this section we present the scenario used to describe the installation process of the various components and prerequisite applications of an ITSLA environment. This may be used as a start point to anyone responsible for the deployment of the IBM Tivoli Service Level Advisor Version 1.1 product. We also assume no preexisting components will be used, and describe the steps of a brand new installation. Please refer to Chapter 3, Implementation planning on page 51, for hardware and software requirements, as well as for tips and hints on how to best design your ITSLA environment and leverage existing production environments.
AIX 4.3.3 DB2 Server TEDW Central Data Warehouse TEDW Data Mart
AIX 4.3.3 DB2 Server ITSLA Databases creation
TEDW Server
TWH_CWD
DYK_DM
DYK_CAT
TWH_MART
ITSLA Database
Central Control
3
Windows 2000 DB2 Server TEDW Control Center ITSLA ETLs Source ETLs
offering and orders
Trend analysis
Reporting data
4
AIX 4.3.3 DB2 Client TEDW Reports Interface (IBM Console) ITSLA Server ITSLA Task Drivers AIX 4.3.3 DB2 Client IBM WebSphere ITSLA Reports Server
TWH_MD
TEDW Control Center
ITSLA Server
ITSLA Reports
Figure 4-1 Installation scenario
As shown in Figure 4-1, our environment is composed of five machines, as follows: 1. TEDW Server machine a. RS6000 running AIX 4.3.3
80
b. IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) c. Tivoli Enterprise Data Warehouse Central Data Warehouse d. Tivoli Enterprise Data Warehouse Data Mart 2. ITSLA Database Server machine a. RS6000 running AIX 4.3.3 b. IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) c. ITSLA Databases creation 3. TEDW Control Center machine a. PC Server running Windows 2000 ASE SP2 b. IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) c. Tivoli Enterprise Data Warehouse Control Center d. ITSLA ETL programs (Process and Registration ETLs) e. All Source ETL programs 4. ITSLA Server machine a. RS6000 running AIX 4.3.3 b. IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) c. IBM Console Server d. ITSLA Server e. ITSLA Task Drivers 5. ITSLA Reports machine a. RS6000 running AIX 4.3.3 b. IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) c. IBM WebSphere Application Server d. ITSLA Reports Server The installation process for each of the above machines will be explained in the following sections.
Chapter 4. Getting IBM Tivoli Service Level Advisor up and running
81
Note: We provide the installation steps for each one of the above components on IBM AIX 4.3.3 and Microsoft Windows 2000 Advanced Server Edition only. If you are planning to use any other operating system platform, you should refer to the official product documentation.
4.2 Setting up the TEDW Server machine

This machine will serve as the host of the Central Warehouse Repository database. The following components are needed: IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) Tivoli Enterprise Data Warehouse Central Data Warehouse Tivoli Enterprise Data Warehouse Data Mart
4.2.1 IBM DB2 UDE Server for UNIX installation

This section describes the IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) installation process on AIX. Note: Use the DB2 installation media provided with the Tivoli Enterprise Data Warehouse product. This ensures that you get the correct version and Fixpack of DB2 installed. 1. Log in as a user with root authority, move to the directory where the DB2 7.2 Server for AIX CDROM is mounted, and start the DB2 setup utility, as follows:
# ./db2setup
2. The Install DB2 V7 screen, as shown in Figure 4-2 on page 83, appears. Select the DB2 UDB Enterprise Edition option.
82
Figure 4-2 Install DB2 V7 - DB2 UDB Enterprise Edition
3. A New DB2 instance should be created for the TEDW databases. We specified the DB2 instance name db2inst1, as shown in Figure 4-3 on page 84.
83
Figure 4-3 Create DB2 Services - DB2 Instance db2inst1
4. Next the DB2 Warehouse Control Database screen appears. Select Set up DB2 Warehouse Control Database. We used the default name for the DB2 Warehouse Control database, dwcntrl. 5. Figure 4-4 on page 85 shows the values we used on the option Create the Administration Server.
84
Figure 4-4 Administration Server screen
6. The installation process creates and sets the values of several environment variables, DB2SYSTEM, for example. 7. At the end of the installation process, you may check the installation log file created at /tmp/db2setup.log. 8. The installed JDBC code level needs to be upgraded to Version 2.0. You should log on to the system with a valid DB2 user ID, and issue the following commands: For bash, Bourne, or Korn shell:
# . INSTHOME/sqllib/db2profile # cd /INSTHOME/sqllib/java12/ # . ./usejdbc2
Where INSTHOME is the home directory of the instance. Verify that the JDBC level is correct by entering the following command:
# echo $CLASSPATH
The output must include the following path:

INSTHOME/sqllib/java12/db2java.zip
85
4.2.2 TEDW Central Warehouse and TEDW Data Mart installation

In this section we describe the steps to install the TEDW Central Warehouse and TEDW Data Mart components on AIX. 1. From the directory where the TEDW CDROM is mounted, enter the following command to start the installation wizard:
# ./setup_unix.sh
2. The InstallShield Wizard dialogue window for Tivoli Enterprise Data Warehouse Installation is the first window to appear. Click Next. 3. The dialogue window for the type of installation appears as shown in Figure 4-5. Select Custom/Distributed and the directory name where you want to install TEDW. In our environment, we used the default value /opt/TWH.
Figure 4-5 Install type dialogue window
4. From the Select features for TEDW dialogue window, as shown in Figure 4-6 on page 87, select Central Data Warehouse and Data Mart. Click Next.
86
Figure 4-6 Select features dialogue window - TEDW Central Data Warehouse
5. The host name dialogue window appear. Verify that this is the correct host name for the installation. Enter the fully qualified host name of the TEDW Central Data Warehouse machine. Click Next. 6. The installation process asks for a valid DB2 user ID in order to create the required TEDW databases. In our example it is db2inst1. This machine will host the following databases, as shown in Figure 4-1 on page 80: TWH_CWD TWH_MART Enter the valid DB2 user ID and password that was created during the DB2 installation and type in the fully qualified host name of the TEDW Server; then verify that the database port number is correct. Click Next. 7. The installation setup program prompts for a valid DB2 user ID and password to be used to access the TEDW Control Center machine. We used db2admin. It also asks for the fully qualified host name and TCP/IP communication port. 8. The overview of selected features dialogue window appear, as shown in Figure 4-7 on page 88. Click Install to start the installation.
87
Figure 4-7 TEDW Central Data Warehouse and Data Mart installation
9. The InstallShield Wizard window appears and informs you of whether the installation was successful. Verify that the installation was successful by making sure there is no error massage in the installation window. Also, check the TWH.log file to ensure all warning messages can safely be ignored. Click Finish to exit the wizard.
4.3 Setting up the ITSLA Database Server machine

This machine will serve as a DB2 database server hosting all databases used by ITSLA. The following steps need to be performed in order to have the ITSLA Database Server machine installed: 1. Install IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) for UNIX. 2. Create ITSLA Databases. The installation of the IBM DB2 Universal Database Enterprise Edition Server should follow the steps provided in 4.2.1, IBM DB2 UDE Server for UNIX installation on page 82. The following section describes the ITSLA Databases creation process.
88
4.3.1 Creating the ITSLA Databases

The creation of all ITSLA Databases should be performed manually. ITSLA provides scripts to accomplish this task for several different platforms, such as SUN Solaris, Linux, Windows, and IBM AIX. The scripts that will create the databases are on the ITSLA CD in the following directories: IBM AIX Sun Solaris Linux Windows
cdrom_dir/database/scripts/aix4-r1 cdrom_dir/database/scripts/solaris2 cdrom_dir/database/scripts/linux_ix86 cdrom_dir :\database\scripts\w32-ix86
Table 4-1 shows the DB2 database to be created and the associated script.
Table 4-1 ITSLA Databases installation scripts
ITSLA Database name DB2 Database name Script (.sh or .bat)
ITSLA Database ITSLA Measurement Data Mart
DYK_CAT DYK_DM
dyk_cat_dbinst dyk_dm_dbinst
The following steps were used to create the ITSLA Databases on AIX: 1. Log in as a DB2 instance owner. 2. Navigate to the db2_instance_dir/sqllib directory, where db2_instance_dir is the home directory of the DB2 instance. 3. Source the DB2 environment variables:
# . db2profile
4. Insert the ITSLA product CD in the CD-ROM drive and mount the CD. 5. Start the database creation scripts from the appropriate directory by entering the following command: For the DYK_CAT database:
# ./CDROM_Dir/database/scripts/aix4-r1/dyk_cat_dbinst.sh
For the DYK_DM database:

# ./CDROM_Dir/database/scripts/aix4-r1/dyk_dm_dbinst.sh
6. Each of the scripts is interactive and prompts you for the following information (we used most of the provided defaults values): The DB2 instance owner user ID. In our case we used db2inst1. The password for your DB2 user ID.
89
The name for the ITSLA Database and ITSLA Measurement Data Mart databases. The default values are DYK_CAT and DYK_DM, respectively. The home directory of the DB2 instance of the DYK_CAT or the DYK_DM database. Default value: /home/db2inst1. The territory used for data entered into the DYK_CAT or the DYK_DM database. Default value is US. The fully qualified path of the file you would like the output of the script to be directed to. We used /tmp/dyk_cat.log and /tmp/dyk_dm.log. The fully qualified path of the file you would like the table verification output to be directed to. We used /tmp/dyk_cat_ver.log and /tmp/dyk_dm_ver.log. It prompts you if an old version of the ITSLA Databases should be dropped. As a new installation the default value is N. Make sure you choose to enable LOGRETAIN for recovery on the DYK_CAT and DYK_DM databases. 7. Check the log files in the directories you have specified for any errors that may have occurred during the database creation. 8. Check the log files in the directories you have specified to verify that all of the database tables were successfully created. For the DYK_CAT database a total of 75 tables are created (53 tables and views with the one schema and 22 tables with the other schema), and for the dyk_dm database a total of nine tables are created. For additional details on DYK_CAT and DYK_DM databases, refer to Appendix C, IBM Tivoli Service Level Advisor Databases on page 403.
4.4 Setting up the TEDW Control Center machine

This machine will serve as the control center of our environment. It will use the TEDW control database containing the metadata for Tivoli Enterprise Data Warehouse (TWH_MD) and will be used to manage our ITSLA ETLs and the data warehouse environment. The following are the components that need to be installed in this machine: IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) for Windows Tivoli Enterprise Data Warehouse Control Center ITSLA ETL programs (Process and Registration ETLs) All Source ETL your environment may require. Set up the ODBC connections
90
The following sections describe the installation and configuration steps in order to have the TEDW Control Center machine up and running.
4.4.1 IBM DB2 UDE Server for Windows installation

This section describes the IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) installation process on Windows. Note: Use the DB2 installation media provided with the IBM Tivoli Service Level Advisor product. This ensures that you get the correct version and Fixpack of DB2 installed. 1. Load the DB2 installation media provided with ITSLA. 2. Select Start -> Run. Type in D:\setup.exe and click OK to start the installation. From the Installation window, select Install. 3. The Select Products window opens. From this window you can select the component(s) of DB2 for Windows you would like to install. Select DB2 Enterprise Edition as shown in Figure 4-8. Click Next.
Figure 4-8 Select DB2 Enterprise Edition
4. The Select Installation Type window opens. Select the installation type you prefer. We selected Typical. 5. For the destination directory, we used C:\SQLLIB.
91
6. For the DB2 administrative user ID, we selected db2admin. 7. After a few minutes the Install OLAP Starter Kit window opens. Select Do not install the OLAP Starter Kit and then Finish. 8. Install the IBM DB2 eFix. In addition to the installation steps, it is necessary to apply the DB2 eFix. (APARs JR16650 and JR16766). The e-fixes are available on the following Tivoli Enterprise Data Warehouse support Web site, under the Tivoli Enterprise Data Warehouse category:
http://www.ibm.com/software/sysmgmt/products/support
The eFix consists of two files: iwh2exp2.exe and iwh2imp2.exe. We need to copy these files over the ones installed by the DB2 installation, as follows: a. Rename D:\sqllib\bin\iwh2exp2.exe to D:\sqllib\bin\iwh2exp2.exe.old. b. Rename D:\sqllib\bin\iwh2imp2.exe to D:\sqllib\bin\iwh2imp2.exe.old. c. xcopy iwh2exp2 D:\sqllib\bin. d. xcopy iwh2imp2 D:\sqllib\bin. 9. Update Java. The installed JDBC code level needs to be upgraded to Version 2.0. You should open a DOS-command prompt window and issue the following commands:
cd DB2_DIR\java12 usejdbc2
Where DB2_DIR is the DB2 installation directory. The usejdbc2 command will copy the appropriate version of db2java.zip into the DB2_DIR\java12 directory. 10.Reboot the machine.
4.4.2 Tivoli Enterprise Data Warehouse Control Center installation

In this section we describe the steps to install the TEWD Control Center component on Windows. 1. Select Start -> Run. Type in D:\setup.exe and click OK to start the installation. 2. The dialogue box for the type of installation appears. Select Custom/Distributed and the directory name where you want to install TEDW. In our environment, we used C:\TWH. 3. From the Select features for TEDW dialogue window, as shown in Figure 4-9 on page 93. Select Tivoli Enterprise Data Warehouse control server. Click Next.
92
Figure 4-9 Select features dialogue window - TEDW control server
4. The host name dialogue window appears. Verify that this is the correct host name for the TEDW Control Center machine. Click Next. 5. The local system DB2 configuration dialogue window appear. The installation process asks for a valid DB2 user ID in order to create the required TEDW database. Enter the valid DB2 user ID and password that was created during the DB2 installation on your local system. In our case, we used db2admin. This machine will host the database TWH_MD, as shown in Figure 4-1 on page 80. Click Next. 6. The overview of selected features dialogue window appears as shown in Figure 4-10 on page 94. Click Install to start the installation.
93
Figure 4-10 TEDW control server installation
7. The complete installation window appears. Select No, I will restart my system at a later time. Click Next. 8. The InstallShield Wizard window appears informing you as to whether the installation was successful. Verify that the installation was successful by making sure there are no error massages in the installation window. Also, check the TWH.log file to ensure all warning messages can safely be ignored. Click Finish to exit the wizard. 9. Reboot your system.
4.4.3 ITSLA ETL programs installation

As explained in 2.5, IBM Tivoli Service Level Advisor Target ETLs on page 37, ITSLA uses Process and Registration ETLs. The following steps are required to install the ITSLA ETL programs. In this section we describe the steps 1 and 2, as steps 3 and 4 are described in detail in 5.2, Target ETLs management on page 142. 1. Import the ITSLA ETLs into the TEDW Control Center machine. 2. Provide the TEDW Control Center with correct user information for proper source and target database access. 3. Enable source applications data collection. 4. Enable and schedule ITSLA ETL programs to run.
94
Importing the ITSLA ETL programs

All ITSLA ETL programs must be imported into the TEDW Control Center machine. You need both the Tivoli Enterprise Data Warehouse and the IBM Tivoli Service Level Advisor products installation media. 1. Select Start -> Run. Type in D:\setup.exe and click OK to start the installation, where D is the CDROM directory. 2. When the InstallShield Wizard dialogue window for Tivoli Enterprise Data Warehouse Installation appears, click Next. 3. The dialogue window for the type of installation appears. Select Application installation only and the directory name where the TEDW components are installed. We used C:\TWH. Click Next to continue. 4. The host name dialogue window appears. Verify that this is the correct host name for the TEDW Control Center machine. Click Next. 5. The local system DB2 configuration dialogue window appears. The installation process asks for a valid DB2 user ID. Enter the valid DB2 user ID and password that were created during the DB2 installation on your local system. In our case, we used db2admin. Click Next. 6. The path to the installation media for the application packages dialogue window appears, as shown in Figure 4-11 on page 96. You should provide the location of the ITSLA ETLs programs. Change the TEDW CD in the CD-ROM drive with the ITSLA installation CD. Specify the path to the twin_app_install_list.cfg file (by default in the CD_drive:\tedw_apps\dyk\ directory) on the ITSLA CD in the directory name field. Leave the Now (prevents typing errors) option checked to verify that the source directory is immediately accessible and that it contains the correct files. Click Next.
95
Figure 4-11 Path to the installation media for the ITSLA ETL programs
7. The overview of selected features dialogue window appears as shown in Figure 4-12. Click Install to start the installation.
Figure 4-12 ITSLA ETL programs installation
96
8. Once the installation is finished, check the log files for any errors.
4.4.4 Source ETLs installation

As explained in 2.7, Applications providing measurement data on page 46, there are five Tivoli applications providing service level measurement data to ITSLA. In our environment scenario, use used the following applications: IBM Tivoli Enterprise Console IBM Tivoli Business Systems Manager IBM Tivoli Monitoring for Transaction Performance (TAPM and TWSM) IBM Tivoli Monitoring Each application above provides its own Source ETL, also known as warehouse packs, installation and configuration processes. In order to avoid confusion, we provide in this section a generic installation procedure and recommend that the installation instructions for each specific Source ETL should also be followed. Also see Tivoli Enterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744, for additional information. The following steps provide a typically Source ETL installation: 1. Use the Tivoli Enterprise Data Warehouse installation program to install the Source ETLs. Click Next. 2. The dialogue window for the type of installation appears, as shown in Figure 4-13 on page 98. Select Application installation only and the directory name where the TEDW components are installed. We used C:\TWH. Click Next to continue.
97
Figure 4-13 TEDW Source ETLs setup type
3. The host name dialogue window appears. Verify that this is the correct host name for the TEDW Control Center machine. Click Next. 4. The local system DB2 configuration dialogue window appears. The installation process asks for a valid DB2 user ID. Enter the valid DB2 user ID and password that were created during the DB2 installation on your local system. In our case, we used db2admin. Click Next. 5. The path to the installation media for the application packages dialogue window appears, as shown in Figure 4-14 on page 99. You should provide the location of the source application ETL program. In order to install the Source ETLs provided by ITSLA, change the TEDW CD installation media with the IBM Tivoli Service Level Advisor Version 1.1 Source ETL installation media. Specify the path to the twh_app_install_list.cfg file. If you intend to install all Source ETLs provided by ITSLA, then use the path CD_drive:\, where CDROM_Dir is the CDROM drive containing the IBM Tivoli Service Level Advisor Version 1.1 Source ETL installation media. You can also install individual Source ETL applications by providing the path CD_Drive:\MCODE, where MCODE is the standard three-letters measurement source code. Table 4-2 on page 99 provides the measurement source code for all Tivoli applications.
98
Table 4-2 Measurement source codes

Tivoli application Measurement source code
IBM Tivoli Monitoring for Transaction Performance (TAPM) IBM Tivoli Enterprise Console IBM Tivoli Business Systems Manager IBM Tivoli Monitoring IBM Tivoli Monitoring for Transaction Performance (TWSM)
APF ECO GTM DMN BWM
Leave the Now (prevents typing errors) option checked to verify that the source directory is immediately accessible and that it contains the correct files. Click Next.
Figure 4-14 Path to the installation media for the application packages
6. The overview of selected features dialogue window appears, as shown in Figure 4-14. Click Install to start the installation.
99
Figure 4-15 TEDW Source ETLs installation
7. Once the installation is finished, check the log files for any errors. 8. Perform any pre-installation configuration steps specified by the Source ETL documentation. For example, this might include tasks such as: Creating additional tables in an existing database. Installing additional product patches. Configuring the source database user name and password. Follow the steps provided in Providing user ID information to the various databases on page 101. Establishing an ODBC connection. This will be discussed in the next section.
4.4.5 TEDW Control Center basic configuration

This section gives instructions for the basic configuration steps for the TEDW Control Center machine.
Specifying the Meta Data database to the TEDW Control Center

You need to specify which Meta Data database will be used. In our environment scenario, the TEDW Control Center machine hosts the TWH_MD database, which will serve as the Meta Data database.
100
Perform the steps as follows: 1. Start the IBM DB2 Control Center utility by selecting Start -> Programs -> IBM DB2 -> Control Center. 2. On the IBM DB2 Control Center utility, start the IBM DB2 Data Warehouse Center utility by selecting Tools -> Data Warehouse Center. 3. The Data Warehouse Center logon windows appears. Select Advanced. Verify that the Control database field contains TWH_MD, as shown in Figure 4-16.
Figure 4-16 TWH_MD as control database
Providing user ID information to the various databases

You should inform the TEDW Control Center of user access information for every Target and Source ETL installed. For the IBM Tivoli Service Level Advisor, Target, Registration, and Process ETLs. The procedure presented here must also be used for any new Source ETL installed in the TEDW Control Center. The following steps should be followed: 1. Start the IBM DB2 Control Center utility by selecting Start -> Programs -> IBM DB2 -> Control Center.
101
2. On the IBM DB2 Control Center utility, start the IBM DB2 Data Warehouse Center utility by selecting Tools -> Data Warehouse Center. The Data Warehouse Center logon windows appears. 3. Log into the IBM DB2 Data Warehouse Center utility using the local DB2 administrator user ID. In our case, db2admin. 4. In the Data Warehouse Center window, expand the Warehouse Targets folder. There are two entries for the ITSLA ETL programs that need to be configured, as follows: DYK_REG_DYK_CAT_TARGET for the Registration ETL DYK_PROC_DYK_DM_TARGET for the Process ETL 5. You should edit the properties of each one of the above entries. In order to do that, right click it and select Properties and then select the Database tab. Fill in the user ID information. For our environment the values are shown in Figure 4-17, using the DYK_PROC_DYK_DM_TARGET as an example.
Figure 4-17 DYK_PROC_DYK_DM_TARGET user ID information
6. For the Source ETLs, in the Data Warehouse Center window, expand the Warehouse Source folder, right click the appropriate Source ETL, select Properties and then select the Database tab. Fill in the user ID information.
102
This step is described in detail in 5.1.1, ETL Warehouse Target and Sources configuration on page 134.
4.4.6 Configuring the ODBC connections

Since the TEDW Control Center machine hosts all the ETLs, it needs to have access to the various databases as follows: TEDW databases (TWH_CWD and TWH_MART) ITSLA Databases (DYK_CAT and DYK_DM) All source application databases ODBC connections on the TEDW Control Center machine should be created as described in the following sections.
ODBC connections with the TEDW databases

The TEDW Control Center installation program automatically creates the ODBC connections to the TWH_CWD and TWH_MART databases. You can check the ODBC connection as follows: 1. On Microsoft Windows 2000, select Start -> Programs -> Administrative Tools -> Data Sources (ODBC). 2. Click the System DSN tab, as shown in Figure 4-18. Click Add.
Figure 4-18 ODBC configuration - System DSN tab
103
ODBC connections with the ITSLA Databases

The ITSLA product provides scripts for creating the ODBC connections with the ITSLA Databases. The dyk_dm_odbc.bat script catalogs an ODBC data source to the DYK_DM database and the dyk_cat_odbc.bat script catalogs an ODBC data source to the DYK_CAT database. These scripts are located in the CD_drive:\database\scripts\w32_ix86 directory, where CD_drive is the CDROM containing the ITSLA installation media. You should only modify the scripts if you need to change the TCPIP port that the DB2 instance running on the TEDW Control Center machine uses to communicate with the remote DB2 server running on the ITSLA Database Server machine to a value different from 50000.
ODBC connections with the source applications

As described in 4.4.4, Source ETLs installation on page 97, we have installed in our environment all the source applications ETLs provided by Tivoli. Table 4-3 gives the names of the databases in which Tivoli applications store measurement data. ODBC connections to these databases in the TEDW Control Center machine should be created so that the respective Source ETL can process the data.
Table 4-3 Tivoli source databases
Source applications Source database
IBM Tivoli Monitoring for Transaction Performance (TAPM) IBM Tivoli Enterprise Console IBM Tivoli Business Systems Manager IBM Tivoli Monitoring IBM Tivoli Monitoring for Transaction Performance (TWSM)
TAPM_RIM TEC GTM_DB DMN_RIM BWM_TWSM
Each one of the above applications Source ETL comes with its own installation and configuration process. The ODBC connections for some may be created during the Source ETL installation. In addition to that, if you have developed in-house Source ETLs, those also provides their own source database that needs to be accessed by the TEDW Control Center machine during the ETL execution. If you need to manually create ODBC connections to a source database, you may use the script shown in Example 4-1 on page 105.
104
Example 4-1 ODBC creation script: TEDW_odbc.bat

@echo off echo This program catalogs an ODBC datasource on the TEDW Control Server machine echo . setlocal rem -- ------------------------------------------------------ -rem -- PLEASE EDIT THE VARIABLES BELOW FOR YOUR INSTALLATION -rem Set the name of the odbc datasource set GEN_DATASRC=%1 rem Set the hostname of the database server containing the SOURCE database set DB2SRVRNAME=%2 rem Set the alias of the cataloged database manager instance node set NODE_ALIAS=CAT_ODBC rem Set the port DB2 uses to communicate with the remote db server set SRVR_PORT=50000 if "%GEN_DATASRC%" == "" goto ABEND if "%DB2SRVRNAME%" == "" goto ABEND rem -- ------------------------- -rem -- Start the ODBC cataloging -db2 catalog tcpip node %NODE_ALIAS% remote %DB2SRVRNAME% server %SRVR_PORT% db2 catalog database %GEN_DATASRC% at node %NODE_ALIAS% db2 catalog system odbc data source %GEN_DATASRC% goto TERMINATE echo got to local rem db2 catalog system odbc data source %GEN_DATASRC% goto FIN :ABEND cls echo Usage: echo "TEDW_odbc data_source remote_hostname" goto END :TERMINATE db2 terminate :END endlocal
105
4.5 Setting up the ITSLA Server machine

The ITSLA Server machine in our environment will combine all the core Service Level Management functions performed by both the ITSLA Server and ITSLA Task Drivers components, such as orders and offerings definitions, data evaluation and trend analysis, and so on. The ITSLA Server machine will host the following components: IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) for UNIX TEDW Reports Interface (ITSLA uses the IBM Console Server component of the TEDW Reports Interface) ITSLA Server component ITSLA Task Drivers component The installation of the above components will be discussed in the following sections.
4.5.1 IBM DB2 Client installation on AIX

This section describes the IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack included) installation process on AIX. Note: Use the DB2 installation media provided with the IBM Tivoli Service Level Advisor product. This ensures that you get the correct version and Fixpack of DB2 installed. 1. Log in as a user with root authority, move to the directory where the DB2 7.2 Server for AIX CDROM is mounted, and start the DB2 setup utility as follows:
# ./db2setup
2. The Install DB2 V7 screen, as shown in Figure 4-19 on page 107, appears. Select the DB2 Administration Client option.
106
Figure 4-19 Install DB2 V7 - DB2 Administration Client
3. A new DB2 instance should be created. We kept all the default values for the user name, group name, and home directory, as shown in Figure 4-20.
Figure 4-20 Create DB2 Services
107
4. The DB2 Setup Utility screen appears. The installation process creates and sets the values of several environment variables. 5. At the end of the installation process you may check the installation log file created at /tmp/d2setup.log. 6. The installed JDBC code level needs to be upgraded to Version 2.0. You should log on to the system with a valid DB2 user ID and issue the following commands: For bash, Bourne, or Korn shell:
# . INSTHOME/sqllib/db2profile # cd . /INSTHOME/sqllib/java12/ # . ./usejdbc2
Where INSTHOME is the home directory of the instance. Verify that the JDBC level is correct by entering the following command:
# echo $CLASSPATH
The output must include the following path:

INSTHOME/sqllib/java12/db2java.zip
4.5.2 Cataloging the ITSLA Databases

Since the ITSLA Server machine contains both the ITSLA Server and the ITSLA Task Drivers components, it needs access to the databases hosted by the ITSLA Database Server machine as follows: DYK_DM DYK_CAT ITSLA provides the dyk_catalog.sh script to accomplish this task for all the supported platforms. The scripts that will catalog the remote server containing the ITSLA Databases and the ITSLA Databases can be found on the ITSLA installation CD in the following directories: IBM AIX Sun Solaris Linux
cdrom_dir/database/scripts/aix4-r1 cdrom_dir/database/scripts/solaris2 cdrom_dir/database/scripts/linux_ix86
Where cdrom_dir is the directory where the ITSLA installation media is mounted.
108
The script is interactive and prompts you for the following information. In our environment scenario, we used the provided defaults. The host name of the systems that contain the ITSLA Databases: In our case, the ITSLA Database Server machine. A local alias name for the remote node that contains the ITSLA Databases. Default value: dyk_node. The TCP/IP port number or service name for communication with the DB2 server. Default value is 50000. The name for the ITSLA Database and ITSLA Measurement Data Mart databases. The default values are DYK_CAT and DYK_DM, respectively. The local alias of the cataloged ITSLA Database and ITSLA Measurement Data Mart databases. The default values are DYK_CAT and DYK_DM, respectively The fully qualified path of the file you would like the output of the script to be directed to. We used /tmp/dyk_catalog.log.
4.5.3 TEDW Reports Interface installation

The installation of the TEDW Reports Interface is required in order to have the IBM Console presentation layer deployed. This presentation layer is also know as Tivoli Presentation Services. The IBM Console will enable execution of ITSLA administrative tasks in our environment. When installing the TEDW Reports Interface, both versions of the IBM Console (Java-based and Web-based) will be installed during the Tivoli Presentation Services installation step. The following steps describe the installation process of the TEDW Reports Interface on an AIX system. 1. From the directory where the TEDW CD-ROM is mounted, enter the following command to start the installation wizard:
# ./setup_unix.sh
2. The InstallShield Wizard dialogue window for Tivoli Enterprise Data Warehouse Installation is the first window to appear. Click Next. 3. The dialogue window for the type of installation appears, as shown in Figure 4-21 on page 110. Select Custom/Distributed and the directory name where you want to install TEDW. In our environment, we used the default value /opt/TWH.
109
Figure 4-21 Install type dialogue window
4. From the Select features for TEDW dialogue window, as shown in Figure 4-22, select Report interface. Click Next.
Figure 4-22 Select features dialogue window - TEDW Report Interface
110
5. The host name dialogue window appears. Verify that this is the correct host name for the installation on the local system. Enter the fully qualified host name of the TEDW Reports Interface machine. Click Next. 6. The installation process asks for a valid DB2 user ID. Enter the valid DB2 user ID and password that was created during the local machine DB2 Client installation. In our case, db2inst1. Click Next. 7. The Tivoli Presentation Services dialogue window appears, as shown in Figure 4-23. Confirm that none of the default ports are being used by another application.
Figure 4-23 Tivoli Presentation Services ports panel
Note: If you change the directory name for the Tivoli Presentation Services, do not specify a directory name that has a blank in it. The default directory name is /opt/PS on UNIX systems. If any of these ports are being used by another application, change the values and choose Next. 8. The Install additional languages dialogue window appears. Leave this box unchecked and click Next. 9. The installation setup program prompts for a valid DB2 user ID and password to be used to access the TEDW Control Center machine. We used db2admin. It also asks for the fully qualified host name and TCP/IP communication port.
111
10.The remote system DB2 configuration for the TEDW Central Data Warehouse server dialogue window appears. Enter the valid DB2 user ID and password that were created during the DB2 installation on the TEDW Central Data Warehouse server. We used db2inst1. Type in the fully qualified host name of the TEDW Central Data Warehouse server, and verify that the database port number is correct. Click Next. 11.The remote system DB2 configuration for the TEDW Data Mart server dialogue window appears. Enter the valid DB2 user ID and password that were created during the DB2 installation on the TEDW Data Mart server. We used db2inst1. Type the fully qualified host name of the TEDW Data Mart server (in our example, the host name is the same as the TEDW Central Data Warehouse server) and verify that the value for the database port number is correct. Click Next. 12.The overview of selected features dialogue window appears, as shown in Figure 4-24. Click Install to start the installation.
Figure 4-24 TEDW Report Interface installation
13.The InstallShield Wizard window appears informing you as to whether the installation was successful. Verify that the installation was successful by making sure there are no error messages in the installation window. Also check the TWH.log file to ensure that all warning messages can safely be ignored. Click Finish to exit the wizard. 14.Even though the installation process showed you the installation results in the previous step, you must wait for the Tivoli Presentation Services help set to be
112
rebuilt. The help set contains the user assistance for the IBM Console. This process happens asynchronously and might not be completed by the time the wizard has finished the installation of the remaining components of TEDW the Reports Interface. Do not restart the system until the help set is complete. To determine whether the help set rebuild is complete, look for the completion message in the Tivoli Presentation Services installation log. This log is in the file PS_directory/log/fwp_mcr/stdoutn, where PS_directory is the Tivoli Presentation Services installation directory. In our case, /opt/PS. Look for the message (Example 4-2) in the most recent stdoutn file. In some cases, the message can be in the second most recent stdoutn file.
Example 4-2 Successful Presentation Services help setup completion message
FWP1734I The utility that was started by the Management Component Repository to build the help set has completed successfully.
This process may take up to 30 or 40 minutes. 15.Reboot the machine.
4.5.4 ITSLA Server component installation

In order to have the ITSLA Server component installed you should perform the following steps: 1. From the directory where the ITSLA CD-ROM is mounted, enter the following command to start the installation wizard:
# ./install.sh
2. The InstallShield Wizard dialogue window for IBM Tivoli Service Level Advisor installation is the first window to appear. Click Next. 3. The dialogue window for the ITSLA Server installation directory appears. We used the default value /opt/TSLA. Click Next. 4. The ITSLA installation options dialogue window appears, as shown in Figure 4-25 on page 114. Uncheck the SLM Reports and the SLM Task Drivers options and make sure that only the IBM Tivoli Service Level Advisor 1.1 and SLM Server options are selected. Click Next.
113
Figure 4-25 ITSLA Server component installation
5. The dialogue window for the ITSLA Database appears as shown in Figure 4-26 on page 115. In the dialogue window you are prompted to provide the information below. We kept all the default values. Database name User ID Specifies the name of the ITSLA Database. Default value is dyk_cat. The DB2 user information for remote access to the ITSLA Databases installed in the ITSLA Database Server machine. Default value is db2inst1. This is the sign-on password for the above user ID. This is the fully qualified host name of the machine that contains the ITSLA Database component. This is the communication port number or the service name of the database manager instance that contains the ITSLA Database component. Default value is 50000.
Password DB Server host name
DB Server port number
114
Remote database instance
This is an optional field that specifies the name of the server instance that contains the ITSLA Database component.
Click Next to continue.
Figure 4-26 ITSLA Database dialogue window
6. The dialogue window for the ITSLA Measurement Data Mart appears as shown in Figure 4-27 on page 116. In the dialogue window you are prompted to provide the information below. We kept all the default values. Database name Specifies the name of the ITSLA Measurement Data Mart database. Default value is dyk_dm. The DB2 user information for remote access to the ITSLA Databases installed on the ITSLA Database Server machine. Default value is db2inst1. This is the sign-on password for the above user ID. This is the fully qualified host name of the machine that contains the ITSLA Measurement Data Mart component.
User ID
115
This is the communication port number or the service name of the server database manager instance that contains the ITSLA Database component. Default value is 50000. This is an optional field that specifies the name of the server instance that contains the ITSLA Measurement Data Mart component.
Remote database instance
Figure 4-27 ITSLA Measurement Data Mart database dialogue window
7. Next you will be presented with a dialogue window prompting you for the home directory of the DB2 instance on the local machine. We used the default value /home/db2inst1. Click Next. 8. The port numbers dialogue window for the ITSLA Server communication port and command line interface port appear. Only change the default values if there is a conflict with port number in your system. As shown in Figure 4-28 on page 117, you should specify the following information: ITSLA communication port This port will be used for communication between the ITSLA Server and the ITSLA Task Drivers components. Default value is 9980.
116
Command line interface port CLI password protection
This port will be used for command line interface procedures. Default value is 9990. Specify whether or not you want your command line interface commands to be password protected. If you select this option, CLI commands that are issued must be entered by specifying an additional parameter, -p password.
Figure 4-28 Port information for the ITSLA Server installation
9. The dialogue window for notification of ITSLA events (violation, trend, trend cancelled, and application events) appears as shown in Figure 4-29 on page 118. If you want to enable event notification, check one or more of the check boxes. Click Next to provide additional configuration information for each of your selected notification methods.
117
Note: ITSLA event notification can also be configured after installation using the scmd escalate command. For additional information refer to Chapter 5, Administering IBM Tivoli Service Level Advisor on page 133, and the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
Figure 4-29 ITSLA event notifications window
10.By selecting the SNMP Trap option for event notification, SNMP, the configuration window as shown in Figure 4-30 on page 119, will appear. You will be prompted to provide the following information: Destination host name This is the fully qualified host name of the destination machine acting as the receiving SNMP management station for SNMP Traps. This is the SNMP Trap destination port number. A default value of 162 is provided. Specify a different port number if needed. This is an optional field containing the SNMP Trap service community name. A default value of public is provided.
Destination port
Community name
118
Figure 4-30 Configuring SNMP Trap event notification
Click Next to continue. 11.By Selecting the TEC Event option for event notification, the TEC configuration window, as shown in Figure 4-31 on page 120, will appear. You will be prompted to provide the following information: TEC Event Server host name This is the fully qualified host name where the Tivoli Enterprise Console event server is installed. TEC Event Server port If the event server is installed on a Windows machine, enter the port number that the event server uses to listen on for events. The typical port value is 5529.
119
Figure 4-31 Configuring Tivoli Enterprise Console event notification
Click Next to continue. 12.By selecting the E-mail option to send e-mail messages to one or more addresses when an event occurs, the configuration window, as shown in Figure 4-32 on page 121, will appear. Provide the following information: SMTP Server host name This is the fully qualified host name of the SMTP Server to handle the e-mail messages. This is a required field. Here you add one or more e-mail addresses, separated by commas, for the people you want notifications to be sent to. This is a required field. No error checking is performed on the e-mail addresses entered here.
To-list e-mail addresses
120
CC-list e-mail addresses
Here you add one or more e-mail addresses, separated by commas, for additional people you want notify with the message. This might be reserved for supervisory personnel or other people who may not deal directly with the violation or trend information, but who want to stay informed. No error checking is performed on the e-mail addresses entered.
Click Next to continue with the configuration of the e-mail notification method.
Figure 4-32 Configuring e-mail notification
13.You will be prompted to format the e-mail notifications as shown in Figure 4-33 on page 122. Specify the following: E-mail subject line Violation message This is a subject line for the e-mail message. This is the text of the e-mail message that is sent when a service level agreement violation is detected. This is the text of the message that is sent when a trend toward a potential violation has been detected.
Trend message
121
Trend canceled message This is the text of the message that is sent when a previously identified trend toward a violation no longer exists.
Figure 4-33 Configuring e-mail notification - Part 2
Click Next to continue with the installation. 14.The confirmation dialogue window of the various ITSLA features that you intend to install appear as shown in Figure 4-34 on page 123. Click Next to start the installation.
122
Figure 4-34 ITSLA Server installation confirmation window
15.The InstallShield Wizard window appears after a few minutes informing you as to whether the installation of ITSLA was successful. Click Finish to exit the wizard.
4.5.5 ITSLA Task Drivers installation

The IBM Tivoli Service Level Advisor Task Drivers must be installed on the same machine as the IBM Console. In order to have the ITSLA Tasks Drivers component installed, perform the following steps: 1. From the directory where the ITSLA CD-ROM is mounted, enter the following command to start the installation wizard:
# ./install.sh
2. The InstallShield Wizard dialogue window for IBM Tivoli Service Level Advisor installation is the first window to appear. Click Next. 3. The dialogue window for the ITSLA Server installation directory appears. We used the default value /opt/TSLA. Click Next.
123
4. The ITSLA installation options dialogue window appears, as shown in Figure 4-35. Uncheck the SLM Server and the SLM Reports options and make sure that only the IBM Tivoli Service Level Advisor 1.1 and SLM Task Drivers options are selected. Click Next.
Figure 4-35 ITSLA Task Drivers component installation
5. The dialogue window for the ITSLA Database appears as shown in Figure 4-26 on page 115. In the dialogue window you are prompted to provide the information below. We kept all the default values. Database name User ID Specifies the name of the ITSLA Database. Default value is dyk_cat. The DB2 user information for remote access to the ITSLA Databases installed on the ITSLA Database Server machine. Default value is db2inst1. This is the sign-on password for the above user ID. This is the fully qualified host name of the machine that contains the ITSLA Database component.
124
This is the communication port number or the service name of the server database manager instance that contains the ITSLA Database Server. Default value is 50000.
Click Next to continue. 6. The Installation proceeds by asking the fully qualified host name and communication port for the ITSLA Server machine. You should provide the values used during the installation of the ITSLA Server component, as shown in Figure 4-36. ITSLA Server host name The fully qualified host name of the machine on which the ITSLA Server is located. The default value of 9980.
ITSLA Server communication port Click Next to continue.
Figure 4-36 ITSLA Task Drivers communication ports
7. The confirmation dialogue window appears as shown in Figure 4-37 on page 126. Click Next to start the installation.
125
Figure 4-37 ITSLA Task Drivers installation
8. A dialogue window appears after a few minutes informing you as to whether the installation of ITSLA Task Drivers was successful. It also informs you that the installation program will attempt to restart Tivoli Presentation Services. Click Next to continue. 9. The InstallShield Wizard window appears informing you that it has successfully installed ITSLA. Click Finish to exit the wizard. Do not restart your system right away. It may take some time for the Tivoli Presentation Services to come back up.
4.6 Setting up the ITSLA Reports machine

The ITSLA Reports machine will serve our environment by performing all the core functions for Service Level Management reporting. The ITSLA Reports machine will host the following components: IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) for UNIX IBM WebSphere Application Server ITSLA Reports Server
126
The installation of the IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) for UNIX has already been discussed in 4.5.1, IBM DB2 Client installation on AIX on page 106. The installation of all the other components will be discussed in the following sections.
4.6.1 IBM WebSphere installation and configuration

The IBM WebSphere Application Server will provide the support environment for the Java-based servlets of the ITSLA Reports Server component. For our environment, we decided to use the IBM WebSphere Application Server AES 4.0.1, as it allows us to have an automated integration of the reports servlets. If you decide to use any other supported version of IBM WebSphere Application Server, the ITSLA Reports servlets must be integrated manually. Please refer to Getting Started with IBM Tivoli Service Level Advisor Version 1.1, SC32-0834, for instructions. In this section we describe the IBM WebSphere Application Server installation steps on AIX. In order to install IBM WebSphere Application Server AES 4.0.1, perform the following steps: 1. Logged in as a user with root authority, issue the following command from the directory where the IBM WebSphere Application Server CD-ROM is mounted:
# ./install.sh.
2. You are then prompted to select the type of installation. We have selected Typical Installation, as it will automatically install all the required components, such as the WebSphere Application Assembly Tool (AAT). If you decide to use a different installation method, make sure you select the AAT option. 3. On the following screen you need to specify the installation directories. We used the default values /usr/WebSphere/AppServer and /usr/HTTPServer. 4. A final installation window informs you that the setup program has finished. 5. When the installation of WebSphere completes successfully, the screen, shown in Figure 4-38 on page 128 appears. Select Start the Application Server.
127
Figure 4-38 IBM WebSphere Application Server configuration panel
6. Open a Web Browser and type in the following URL:

http://WebSphere_Server:9090/admin
Where WebSphere_Server can either be the WebSphere servers host name or IP address. 7. On the Administrator Console window, shown in Figure 4-39 on page 129, expand Resources -> JDBC Drivers -> Db2JdbcDriver. Click Db2JdbcDriver. Update the Server Class Path with the fully qualified path of the DB2 file db2java.zip. The path is the same specified during the JDBC code level upgrade described in 4.5.1, IBM DB2 Client installation on AIX on page 106. Click Save.
128
Figure 4-39 IBM WebSphere configuration
8. You should recycle the IBM WebSphere Application Server by issuing the following commands:
# cd /WebSphere_AppServer_Install_Directory/bin # ./stopServer.sh # ./startServer.sh
Where WebSphere_AppServer_Install_Directory is the directory where you installed the IBM WebSphere Application Server. 9. The IBM WebSphere Application Server runs as root and requires access to the IBM DB2 environment. You should insert the following at the end of roots .profile file:
./home/db2inst1/sqllib/db2profile
Assuming that the db2inst1 is the IBM DB2 instance owner.
129
4.6.2 ITSLA Reports Server installation

The IBM Tivoli Service Level Advisor Reports Server components must be installed on the same machine as the IBM WebSphere. In order to have the ITSLA Reports Server component installed, perform the following steps: 1. From the directory where the ITSLA CD-ROM is mounted, enter the following command to start the installation wizard:
# ./install.sh
2. The InstallShield Wizard dialogue window for IBM Tivoli Service Level Advisor installation is the first window to appear. Click Next. 3. The dialogue window for the ITSLA Server installation directory appears. We used the default value /opt/TSLA. Click Next. 4. The ITSLA installation options dialogue window appears as shown in Figure 4-40. Uncheck the SLM Server and the SLM Task Drivers options and make sure that only the IBM Tivoli Service Level Advisor 1.1 and SLM Reports options are selected. Click Next.
Figure 4-40 ITSLA Reports component installation
5. The dialogue window for specifying the installation directory location of the IBM WebSphere Application Server appears. As described in the previous section, we used the provided default value /usr/WebSphere/AppServer. Click Next to continue.
130
6. The dialogue window for specifying the IBM WebSphere Application Server node name appears, as shown in Figure 4-41. You need to specify the name that the IBM WebSphere Application Server assigned to the node that identifies the machine on which WebSphere is running. Note: This name is not necessarily your machine host name. It might be either the short name or the fully qualified name for the machine that was assigned during the WebSphere installation. Be sure to look this name up and do not assume it is your machine host name. Note also that this node name is case-sensitive.
Figure 4-41 Specify a node name for you ITSLA Report Server
7. The dialogue window for the ITSLA Database appears as shown in Figure 4-26 on page 115. In the dialogue window you are prompted to provide the information below. We kept all the default values. Database name User ID Specifies the name of the ITSLA Database. Default value is dyk_cat. The DB2 user information for remote access to the ITSLA Databases installed on the ITSLA Database Server machine. Default value is db2inst1.
131
This is the sign-on password for the above user ID. This is the fully qualified host name of the machine that contains the ITSLA Database component. This is the communication port number or the service name of the server database manager instance that contains the ITSLA Database component. Default value is 50000.
Click Next to continue. 8. The confirmation dialogue window of the various ITSLA features that you intend to install appears as shown in Figure 4-42. Click Next to start the installation.
Figure 4-42 ITSLA Report Server installation
9. The InstallShield Wizard window appears after a few minutes informing you as to whether the installation of ITSLA was successful. Click Finish to exit the wizard.
132
Chapter 5.
Administering IBM Tivoli Service Level Advisor

This chapter provides an overview of the administrative tasks to be performed in order to manage the IBM Tivoli Service Level Advisor environment. The following topics are discussed: Source ETLs management Target ETLs management User creation and management Management of ITSLA components Timing considerations for the ITSLA environment Trace and message log files Startup and shutdown procedures Backup and restore of ITSLA
133
5.1 Source ETLs management

The Source ETL process is required by the Tivoli Enterprise Data Warehouse for applications wanting to make their data available in the TEDW Central Warehouse database. The entire Source ETL process comprises the extraction of application data from the local application source tables, the transformation of such data through various calculations, and the storage of the resulting data into the TEDW Central Warehouse database target tables. The ITSLA administrator is responsible for running the Source ETL process through the DB2 Warehouse Center Interface. Source ETLs management is made up of three main activities: Verifying the correct configuration of ETL Warehouse Targets and Sources Scheduling and running the ETL Notifying of the ETL result The next sections will provide information on how to correctly configure the ETLs, describe how to schedule and run the ETLs, and how to be notified of the ETLs results.
5.1.1 ETL Warehouse Target and Sources configuration

Before running the ETL processes, you must make sure that the Warehouse Sources and the Warehouse Targets specific to the Tivoli application are correctly defined (user name, password, host name, system data source). The Warehouse Sources, Warehouse Targets, and each related Tivoli source application that are ITSLA-enabled are shown in Table 5-1.
Table 5-1 IBM Tivoli source application and Warehouse Source and Targets
Tivoli application Warehouse sources name Warehouse targets name
IBM Tivoli Monitoring for Transaction Performance (TAPM) IBM Tivoli Business Systems Manager IBM Tivoli Monitoring for Transaction Performance (TWSM) IBM Tivoli Monitoring IBM Tivoli Enterprise Console
APF_TAPM_Source GTM_OBJECT_Source BWM_TWSM_Source DMN_RIM_Source ECO_TEC_Source
APF_TWH_CDW_Target GTM_TWH_CDW_Target BWM_TWH_CDW_Target DMN_TWH_CDW_Target ECO_TWH_CDW_Target
134
The ETL Warehouse Sources configuration

To define the Warehouse Sources, open the DB2 Warehouse Center from the Tools menu, expand the Warehouse Sources folder, right click each Warehouse Source shown in Table 5-1 on page 134 and select Properties. In the Properties window select the Data Source tab. Figure 5-1 shows an example of the configuration for the TAPM Warehouse Source. Verify that the following parameters are correct: Data source name (the database name of where the Tivoli application stores its data) System name (the host name of the database where the data resides) User ID and password (used to access the database where the Tivoli application stores its data)
Figure 5-1 Properties window of Warehouse Sources
Chapter 5. Administering IBM Tivoli Service Level Advisor
135
In addition to that, you must also do the following for the Warehouse Sources: 1. From the Data Warehouse Center window, expand the Warehouse Sources folder and then the item related to the Tivoli Application you have chosen (i.e: for the TAPM, the item is APF_TAPM_Source). 2. Click the Tables folder. The tables in the warehouse source are displayed on the right-hand side of the window. 3. If the Schema property is empty and the Name of the tables include the schema name, right click each table and select Properties. The Properties window opens. 4. On the Source Table page, modify the Table Schema and Table name properties with the values of the Tivoli Application database source. (This depends on how you created the Tivoli Application database. Refer to the Tivoli Application related documentation for further details). For the IBM Tivoli Monitoring for Transaction Performance (TAPM) application, the table name should be the table name without the word TAPM to prevent problems when exporting the metadata to an ETL interchange file (*.tag), which can be imported into another Data Warehouse Center. Important: The source application database must exist and be cataloged as an ODBC System DSN in order to correctly configure the Data Source parameters in the Properties window (Figure 5-1 on page 135). See Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, for information about configuring ODBC connections for source application databases.
The ETL Warehouse Targets configuration

To ensure the correct definition of the Warehouse Targets do the following: 1. Open the DB2 Data Warehouse Center from the Tools menu, and expand the Warehouse Targets folder. 2. Right click each Warehouse Target, as shown in Table 5-1 on page 134, and select Properties. 3. From the Properties window, select the Database tab and verify that the following parameters are correct: Database name (the name of the Central Data Warehouse) System name (the name of the DB2 system that hosts the TEDW Central Warehouse) User ID and password (the parameters used to access the TEDW Central Warehouse) Figure 5-2 on page 137 displays the Warehouse Target table screen.
136
Figure 5-2 Tables of Warehouse Targets
5.1.2 Schedule and run Source ETL

This section describes the SQL processes that compose a Source ETL for the Tivoli applications and how to schedule and run a Source ETL process using the IBM Tivoli Monitoring for Transaction Performance (TAPM) as an example. The basic steps described here for TAPM are valid for all other Tivoli source applications, whether differently specified or not. A Source ETL is responsible for transferring data from the source application database to the TEDW Central Warehouse Target tables. Different SQL processes exist for each Tivoli source application that implements the Source ETL functionality. To locate these SQL processes, open the DB2 Data Warehouse Center, and expand the Subject Areas folder on the left side of the window. The mapping between the Subject Areas items and the Tivoli source
137
applications is shown in Table 5-2. Expanding any of the Subject Areas will reveal a Processes folder containing the SQL processes for implementing the Source ETL process. Each SQL Process is made up of different steps, which you can see by expanding the process item.
Table 5-2 Subject Areas and related Tivoli applications
Subject Area Tivoli application
APF_TivoliApplicationPerformanceManagement_v1.1.0_ Subject_Area BWM_TivoliWebServicesManager_v1.7.0_Subject_Area DMN_ApplicationEnablement_v3.7.0_Subject_Area ECO_Tivoli_Enterprise_Console_v3.7.1_Subject_Area GTM_Tivoli_Business _System_Manager_v1.5_Subject_Area
IBM Tivoli Monitoring for Transaction Performance (TAPM Version 2.1) IBM Tivoli Monitoring for Transaction Performance (TWSM Version 1.7) IBM Tivoli Monitoring (Classic Edition Version 3.7) IBM Tivoli Enterprise Console Version 3.7.1 IBM Tivoli Business Systems Manager Version 1.5
In order to schedule and run the ETL Source Processes for IBM Tivoli Monitoring for Transaction Performance (TAPM), perform the following steps: 1. From the Data Warehouse Center window, expand the Subject Areas folder. 2. Expand the item related to the Tivoli source application TAPM, that is APF_TivoliApplicationPerformanceManagement_v1.1.0_Subject_Area. 3. Expand the Processes item, as shown in Figure 5-3 on page 139.
138
Figure 5-3 Processes folder of TAPM Subject Areas
4. Inside the Processes folder there are two different processes: APF_c05_Initialize_Process This is an initialization process that has one step: APF_c05_s010_init. The APF_c05_s010_init step resets the values of the Tivoli Enterprise Data Warehouse Extract_Control and Prune_Msmt_Control tables, which are used respectively to incrementally extract the ETL processes and to remove old data from the MSMT table by a warehouse process. After you run this step, all TAPM-related data will be loaded in the TEDW Central Warehouse database through the APF_c10_CDW_Process process. Therefore, it should be run only once.
139
APF_c10_CDW_Process This process is made up of five steps that load the TAPM data first from the RIM database into the Tivoli Enterprise Data Warehouse staging tables and then inside the TEDW Central Warehouse database. This process populates the component, component attribute, and measurement tables. It should be run on a periodical basis (daily, weekly, or monthly, depending on the amount of data to transfer). 5. To schedule APF_c05_Initialize_Process, right click it and select Schedule. Schedule it to run only once, and click Add>. Then click Notification and configure how to be notified of the process result. Click OK to finish the schedule. 6. In order for the schedule to be accepted, the APF_c05_Initialize_Process process must be changing from Development mode to Production mode. To set the APF_c05_s010_init step to Production mode, right click it and select Mode -> Production. 7. To schedule APF_c10_CDW_Process, right click it and select Schedule. Define the schedule you desire, and click Add>. Then click Notification and configure how to be notified of the process result. Click OK to finish the schedule. 8. To set the APF_c10_CDW_Process steps, select all the steps by holding the CTRL key, right clicking the selection, and selecting Mode -> Production, as shown in Figure 5-4 on page 141. Important: If you want to modify the ETL scheduling, you must set the SQL steps to the Development or Test mode. If the SQL steps are in Production mode, you will not be able to modify the schedule settings. Additionally, if there is a need to change an existing ETL schedule, it will be quicker for you to change from Production mode to Test mode, instead of going back to Development.
140
Figure 5-4 Set to Production mode TAPM Source ETL steps
Note: This section describes how to schedule the processes for TAPM. Inside the IBM Tivoli Business Systems Manager ETL Processes folder, there is only one process: GTM_co5_LOBState_Process. This process is responsible for both the initialization and the load process. To schedule this process, right click it and select Schedule. Define the schedule in the Schedule window and click OK. The Source ETL processes will run according to the given schedule. The time needed to perform the Source ETL process depends on the network bandwidth, the power of the machine involved hosting both the TEDW Central Warehouse and the Tivoli source applications databases, the Tivoli application load during
141
the Source ETL process, and the amount of data to be transferred. Remember that the Source ETL processes must complete their processing before the Target ETLs are run, in order to populate the ITSLA Databases with the latest available data.
5.2 Target ETLs management

Target ETLs are responsible for transferring data from the TEDW Central Warehouse database to the ITSLA local databases by extracting, transforming, and loading the data. This data includes data measurements from source applications, along with information regarding the various types of data that are available for use in defining and creating SLAs. As explained in 2.5, IBM Tivoli Service Level Advisor Target ETLs on page 37, these Target ETLs are referred to as the Process Target ETL and the Registration Target ETL.
5.2.1 Registration Target ETL management

The Registration Target ETL is in charge of moving the measurement data type, component name, and attribute information of the Tivoli source application from the TEDW Central Warehouse database to the ITSLA Database (DYK_CAT). The Registration Target ETL is typically run when it is first installed to populate the ITSLA Database with measurement types already present in the TEDW Central Warehouse database, and any time new measurement types are added to the TEDW Central Warehouse database. Registration Target ETL management consists of the following: Source application data collection enablement Scheduling and running the Registration ETL Notification on the results of the Registration ETL processes The next sections provide information on how to perform these activities.
Source application data collection enablement

You can define which source applications can move their data from the TEDW Central Warehouse database to the ITSLA Database through a set of CLI commands. IBM Tivoli Service Level Advisor initially comes with no source applications enabled; therefore, you must define these enabled applications before the Registration Target ETL is run.
142
In order to list the available source applications and to see if they are enabled for data collection, perform the following steps: Source the ITSLA environment, dependent on your operating system: For Windows, run the slmenv.bat file from the ITSLA installation directory. For UNIX, execute . ./slmenv.sh from the ITSLA installation directory. Run the following command from an ITSLA command line on the ITSLA Server:
scmd etl getApps
You will obtain an output similar to that found in Example 5-1.

Example 5-1 scmd etl getApps command output
# scmd etl getApps Measurement Source Code: BWM Application Name: Tivoli Web Services Manager Flag: Y Measurement Source Code: APF Application Name: Tivoli Application Performance Management Flag: Y Measurement Source Code: DMN Application Name: Distributed Monitoring Classic Edition Flag: Y Measurement Source Code: GTM Application Name: Tivoli Business System Manager Flag: Y Measurement Source Code: ECO Application Name: Tivoli Enterprise Console Flag: N #
If you have developed your own Source ETL for use with a third-party application and do not see your application listed in the command output (Example 5-1), you must run the following command so that data can be transferred from the TEDW Central Warehouse database:
scmd etl addApplicationData Source_Code Application_Name
143
There are five Tivoli source applications that come already defined in the ITSLA Database. If you want to enable a source application that has already been defined, type the following command:
scmd etl enable Measurement Source Code
The Measurement Source Code is a three letter designation, which for the Tivoli source applications, can be found with the scmd etl getApps command output. By default all source applications are disabled. If you want to disable a source application that you mistakenly enabled or no longer need, issue the following command:
scmd etl disable Measurement Source Code
Important: You cannot disable a source application if data for that application is currently being used in a defined customer offering or order. In order to list which offerings and orders are associated with the source application in question, issue the scmd etl disable Source_Code list command. More detailed information on scmd commands can be found either in the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833, or in the Appendix D, Command reference on page 409. Note: The information for which source applications must be included in the Registration ETL process is written inside the Extract_Filter table in the ITSLA Database. The Registration ETL uses this table to define which source applications to include.
Scheduling and running the Registration Target ETL

The Registration Target ETL extracts data from the TEDW Central Warehouse database, transforms these records to a format suitable for IBM Tivoli Service Level Advisor, and loads the data into the ITSLA Database (DYK_CAT). It must run prior to the Process Target ETL, due to the fact that the Process Target ETL reads data from inside the ITSLA Database to decide which types of measurement data are needed. Being the Registration Target ETL responsible for placing this information inside the ITSLA Database, running the Process Target ETL before the Registration Target ETL will result in a loss of data or updated information not to be inserted. The Registration Target ETL needs to be scheduled daily, in order to insert any new measurement data collected by the Tivoli source applications into the ITSLA Database. To schedule the Registration ETL do the following steps: 1. From the DB2 Warehouse Center window, expand the Subject Areas folder.
144
2. Expand DYK_IBMTivoliServiceLevelAdvisor_v1.1.0_Subject_Area and the Processes folder. 3. Right click the DYK_m05_Populate_Registration_Datamart_Process process and select Schedule, as shown in Figure 5-5.
Figure 5-5 Select schedule for Registration ETL
4. The Schedule window is shown in Figure 5-6 on page 146. Configure the Interval, Frequency, Day, Start Date and Time, End Date and Time parameters, and click Add.
145
Figure 5-6 Registration ETL Schedule window
5. Click OK to accept the Registration ETL schedule. 6. The process steps are located on the right-hand side of the Data Warehouse Center window. They are in the form *_snnn_*, where nnn is the step number. Holding the CTRL key, select all the steps, right click the selected items, and choose Mode -> Production. This will set the ETL into production mode, enabling the schedule you just created. Now that the Registration ETL is scheduled, you can decide to either wait for the process to start at the scheduled time, or to run the Registration Target ETL immediately by performing the following steps: 1. From the Data Warehouse Center window, select Warehouse -> Work in Progress, as shown in Figure 5-7 on page 147.
146
Figure 5-7 Work in Progress selection
2. Find the first step of the Registration Target ETL scheduled to run. The first step of the Registration ETL is labeled DYK_m05_s010_Populate_Stage_Data, and its Status column value must be Scheduled. Right click it and select Run now, as shown in Figure 5-8 on page 148.
147
Figure 5-8 Immediately run the first step of the Registration ETL
3. The Work in Progress window shows the ETL steps status. 4. Wait for the ETL steps to complete successfully. If one of the steps fails, right click it and then select Show Log, as shown in Figure 5-9 on page 149.
148
Figure 5-9 See log information for failed ETL Registration step
5. Examine the log details message window. Refer to 8.6.3, Administration issues on page 343, for guidance on how to determine the problem.
Registration ETL results notification setup

To be notified of the Registration ETL result, perform the following steps: 1. From the DB2 Warehouse Center window, expand the Subject Areas folder. 2. Expand DYK_IBMTivoliServiceLevelAdvisor_v1.1.0_Subject_Area and the Processes folder. 3. Right click the DYK_m05_Populate_Registration_Datamart_Process process and select Notification. The Notification window opens, as shown in Figure 5-10 on page 150.
149
Figure 5-10 Configuration of Notification for the Registration ETL
4. Choose which Registration Target ETL result you would like to be notified for (success, failure, and/or completion), the users to notify, the Mail server to use, and the content of the e-mail. 5. Click OK to complete the Notification task.
5.2.2 Process Target ETL management

The Process Target ETL is in charge of moving measurement data from the TEDW Central Warehouse database into the ITSLA Measurement Data Mart database (DYK_DM). The Process Target ETL also reads from the ITSLA Database the measurement type data to insert in the ITSLA Measurement Data Mart database. The Process Target ETL implements an incremental extract feature, transferring only the latest data that was inserted since the last time the Process Target ETL was run. The Process Target ETL should run only after all enabled Source Application ETLs have inserted their data inside the TEDW
150
Central Warehouse database and after the initial run of the Registration Target ETL. More considerations regarding the scheduling of the Process Target ETL are discussed in 5.5, Timing considerations for the ITSLA environment on page 193. Process Target ETL management consists of the following: Scheduling and running the Process Target ETL Notification of the Process Target ETL results Expiration of measurement data management
Scheduling and running the Process Target ETLs

The Process Target ETL is in charge of moving data from the TEDW Central Warehouse database (TWH_CDW) to the ITSLA Data Mart database (DYK_DM). The data stored in the ITSLA Measurement Data Mart database is used to perform the SLA evaluation. In order to have a consistent and reliable SLA evaluation, the Process Target ETL must run daily for the latest available information to be inserted in the ITSLA Database. Being that the SLA evaluation frequency for IBM Tivoli Service Level Advisor has a minimum value of one per day, the Process Target ETL must run at least once a day in order to provide the data for the evaluation process. It must run after the completion of the Registration Target ETL in order to extract relevant source application information from the ITSLA Database to insert to the ITSLA Measurement Data Mart database. In order to schedule the Process Target ETL, perform the following steps: 1. From the DB2 Warehouse Center window, expand the Subject Areas folder. 2. Expand DYK_IBMTivoliServiceLevelAdvisor_v1.1.0_Subject_Area and the Processes folder. 3. Right click the DYK_m10_Populate_Measurement_Datamart_Process process and select Schedule, as shown in Figure 5-11 on page 152.
151
Figure 5-11 Select Schedule for Process ETL
4. The Schedule Window is shown in Figure 5-12 on page 153. Configure the Interval, Frequency, Day, Start Date and Time, End Date and Time parameters, and click Add.
152
Figure 5-12 Define Schedule for Process ETL
5. Click OK to accept the Registration ETL schedule. 6. The process steps are located on the right-hand side of the Data Warehouse Center window. They are in the form *_snnn_*, where nnn is the step number. Holding the CTRL key, select all steps, right click the selected items, and choose Mode -> Production. Now that the Process ETL is scheduled, you can decide to either wait for the process starting at the scheduled time, or you can run the Process ETL immediately by performing the following steps: 1. From the Data Warehouse Center window, select Warehouse -> Work in Progress, as shown in Figure 5-13 on page 154.
153
Figure 5-13 Start Work in Progress tool
2. Find the first step of the Process Target ETL scheduled to run. The first step of the Process Target ETL is labeled DYK_m10_s010_Populate_SLM_Msmt_Staging, and its Status column value must show Scheduled. Right click it and select Run now, as shown in Figure 5-14 on page 155.
154
Figure 5-14 Manually run the first step of the Process Target ETL
3. The Work in Progress window shows the ETL step status. 4. Wait for the ETL to complete successfully. If one of the steps fails, right click it and select Show Log. 5. Examine the log details message window. Refer to 8.6.3, Administration issues on page 343, for guidance on how to determine the problem.
Process ETL results notification setup

In order to be notified of the Process ETL result, perform the following steps: 1. From the DB2 Warehouse Center window, expand the Subject Areas folder. 2. Expand DYK_IBMTivoliServiceLevelAdvisor_v1.1.0_Subject_Area and the Processes folder.
155
3. Right click the DYK_m10_Populate_Measurement_Datamart_Process process and select Notification. The Notification window opens, as shown in Figure 5-15.
Figure 5-15 Start Notification dialogue for Process ETL
4. Choose which Process Target ETL result you would like to be notified for (Success, Failure, Completion), the users to notify, the mail server to use, and the content of the e-mail. 5. Click OK to complete the Notification task.
156
Expiration of measurement data management

IBM Tivoli Service Level Advisor analyzes availability and performance measurement data stored in the ITSLA Measurement Data Mart database. The ITSLA Measurement Data Mart database can grow very quickly, depending on the amount of data your applications capture and insert into the TEDW Central Warehouse database. Data inside the ITSLA Measurement Data Mart is initially set to be deleted after a default expiration interval of 63 days. This time interval is customizable through CLI commands. In order to customize the expiration time interval, perform the following steps: 1. Open a command prompt interface (or a shell window) on the ITSLA Server machine. 2. Type in the following command to obtain the set expiration time interval:
scmd etl getDataExpiration
The output of this command is shown in Example 5-2.

Example 5-2 scmd etl getDataExpiration command output
# scmd etl getDataExpiration The data is set to expire every 63 days #
3. To change the time interval expiration data to 30 days, type the following command:
scmd etl setData Expiration 30
More detailed information on scmd commands can be found either in the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833, or Appendix D, Command reference on page 409.
5.3 User creation and management

In the IBM Tivoli Service Level Advisor solution, there are two different types of users who can be managed by the ITSLA administrator as follows:
IBM SLA Console users are responsible at different levels to define and
manage the service level agreements in the company.
157
Through the IBM Web Console, depending on their authorization level, they may perform one or more of the following tasks: Manage schedules Manage offerings Manage customers Manage orders Manage realms
IBM SLA Report users have access to IBM SLA reports, which can be accessed through a supported Web browser. They can be created and customized through a set of CLI commands executed on the ITSLA Server. They have no access to the IBM Console and cannot perform any of the administration tasks used by the IBM ITSLA Console users.
In the following sections, information on how to manage IBM SLA Console users and SLA Report users is provided.
5.3.1 IBM SLA Console user management

The ITSLA administrator is in charge of creating, defining, and customizing the users depending on their responsibilities in managing the service levels of the company. IBM Tivoli Service Level Advisor uses the same role-based concept for access control to administer its security features as the Tivoli Enterprise Data Warehouse product. For more information on the concept of a role-based security policy, refer to Introduction to Tivoli Enterprise Data Warehouse, SG24-6607. During the installation process, IBM Tivoli Service Level Advisor creates the following predefined portfolio roles in the IBM Console: SLA administrator Grants the user access to all tasks related to managing and creating offerings, orders, schedules, customers, and realms. Further, the SLA administrator can perform administrative tasks, such as the back up and restore of product code and measurement data, and logging and tracing functions. Creates service offerings and associated schedules, making them available for customer orders. Able to create and manage customers and realms and can associate customers with defined service offerings.
Service ordering specialist
Customer order specialist
158
Mapping between the SLA predefined roles and SLA tasks is indicated in Table 5-3.
Table 5-3 IBM SLA roles and associated tasks on the IBM Web Console
IBM SLA role Task group and associated tasks
Service offering specialist
Administer service offering. Manage schedules. Manage offerings. Administer customer orders. Manage realms. Manage customers. Manage orders. Administer SLM. Manage schedules. Manage offerings. Manage realms. Manage customers. Manage orders. Administer users and roles. Work with Reports.
Customer order specialist
SLA administrator
ITSLA user creation and customization

The creation and customization of ITSLA users is achieved through the IBM Web Console. In the following steps we show how to create a user with the service offering specialist role in our environment. Note: There are two different versions of the IBM Console included with IBM Tivoli Service Level Advisor. The icon located on the desktop labeled IBM Console is Java-based and is used primarily for turning the tracing function on and off and viewing the message logs. The Web-based IBM Console should be used for all administrative purposes, such as what is covered in the following sections. 1. Open a supported Web browser and enter the following URL:
http://hostname:port/IBMConsole
Where hostname is the machine where Web Services for IBM Console Server is running and port is the appropriately assigned port. 2. Log on as the superadmin user, where the default password is password. The superadmin user has full access to all resources and is granted all roles. 3. The IBM Web Console is shown in Figure 5-16 on page 160.
159
Figure 5-16 IBM Web Console
4. On the left side of the console, you will find the task groups available to the user. You can perform any task inside the task groups, since the superadmin user has been used to log in with. 5. Click the Administer Users and Roles task group to expand it, and then click the Create a User task. On the right side of the window, the Create a user dialogue window opens in the General window, as shown in Figure 5-17 on page 161.
160
Figure 5-17 User creation task in the General window
6. Enter the values your prefer in the designated fields. For our example, the user name will be set to Michael and password to default. 7. Click the Roles tab to define the level of authorization to give to the user. 8. The IBM Console User role is assigned by default and is necessary to access the IBM Console. For our example, the service offering specialist role was also assigned to the user, as shown in Figure 5-18 on page 162. Note: The Primary role defines only which banner and welcome page are shown on the IBM Console for that user.
161
Figure 5-18 Service offering specialist role selection
9. Click OK to create the user. 10.Now sign off the IBM Web Console and log on as user Michael, password default. 11.The IBM Web Console is shown in Figure 5-19 on page 163. As depicted, the user Michael has access only to the Administer Service Offering task group and can perform the Manage Schedules and Manage Offerings tasks.
162
Figure 5-19 IBM Console starting page for service offering specialist user
The mapping between the ITSLA predefined roles, task groups, and tasks are shown in Table 5-3 on page 159.
5.3.2 ITSLA Report users management

After the ITSLA Server evaluates the violations and trends of measurement data against the defined service levels agreements, the evaluation results are aggregated into reports that can be accessed through a supported Web browser. Chapter 6, Service level Reports with ITSLA on page 217, provides a great deal of information on ITSLA reports. Depending on the assigned authentication level, an ITSLA user can be provided with very broad or very limited access to report data.
163
The level of authentication assigned to the user depends on the four different variables defined below: Consumer Also known as a customer, the ITSLA user can be associated with a consumer and will only be able to see the reports for that specific consumer. A realm is a group of customers, as defined in 5.4.2, Management of orders on page 179. The Web Report user can view only reports regarding these groups of customers. The initial Web page that the user views after a successful login to the reports server. There are three possible values: executive.jsp, customer.jsp, and operations.jsp. These values are Web portal pages located on the ITSLA Reports Server. This variable sets the authorization level of the users and can assume three different values (1, 2, and 3). The values and their associated authorization levels are described in Table 5-4.
Realm
Portal page
View
Table 5-4 View values and authorization levels for Report users
View value Authorization level
1 2 3
Unrestricted: A user can see reports for any customer or realm. Restricted: A user can access reports of a specific customer or a specific realm, or both. External: A user can access reports of a specific customer or a specific realm, or both. However, a user cannot view data marked for internal use only.
For more information regarding a Report users authorization level, refer to 6.3.1, Creating Reports users on page 237. The installation creates three default user IDs with the view value set to unrestricted, as follows: Executive This user accesses reports starting from the executive.jsp portal page, which displays the Customer Ranking view. Default user password is password. This user accesses reports starting from the customer.jsp portal page, which displays the Customer Order Ranking view. Default user password is password.
Customer
164
Operations
This user accesses reports starting from the operations.jsp portal page, which displays the Offering Component Ranking view. Default user password is password.
ITSLA Report user creation

The following steps define the process to create a new ITSLA Reports user: 1. On the ITSLA Server machine, open a command prompt (or shell window) and source the ITSLA environment by running the slmenv script from the ITSLA installation directory. 2. Type the following command to list the current users of ITSLA Reports:
scmd sla listUser
The output of the command is shown in Example 5-3.

Example 5-3 scmd sla listUser command output
# scmd sla listUser name view consumer realm page -------------------------------------------------------------------------------------------customer unrestricted customer.jsp?fsd=mtd executive unrestricted executive.jsp?fsd=mtd operations unrestricted operations.jsp?fsd=r7d #
3. For our example, a user will be defined with an ID of Sawyer, a password of Jack, and data access for only the MyCompany consumer and realm Test. The user is created with the following command:
scmd sla AddUser -name Sawyer -password Jack -view 2 -consumer MyCompany -realm Test -page customer.jsp
The output of the command is shown in Example 5-4.

Example 5-4 scmd sla AddUser command output
# scmd sla AddUser -name Sawyer -password Jack -view 2 -consumer MyCompany -realm Test -page customer.jsp DYKSL0017I A user was added successfully. Authority=2:restricted user, userID=Sawyer, password=Jack consumer=MyCompany, realm=Test, page=customer.jsp #
4. Logging in to the ITSLA Report server as user Sawyer will display a screen like that shown in Figure 5-20 on page 166.
165
Figure 5-20 Log in with user Sawyer to ITSLA Reports
Table 5-5 contains a list of commands used to manage the ITSLA Report users. For further information refer to Appendix D, Command reference on page 409, or the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
Table 5-5 User manipulation commands
Web Report user command Description
scmd sla listUser scmd sla addUser
Lists the users and their characteristics. Creates a new user able to access reports when logging in to the ITSLA Reports Server. Changes the permissions of a user Deletes a user.
scmd sla changeUser scmd sla deleteUser
166
5.4 Management of ITSLA components

In this section we will describe how to create and manage the ITSLA elements that form a service level agreement contract. The IBM Tivoli Service Level Advisor elements that comprise a service level agreement contract are offerings, schedules, orders, customers, and realms. These elements definitions and relation to the ITSLA environment have already been covered in 2.3, Important ITSLA concepts and terminology on page 26. In this section, information regarding the creation, configuration, and customization of the ITSLA elements through the IBM Console is discussed.
5.4.1 Management of offerings

An offering is a template used to outline one or more services that are part of a defined service level agreement. Offerings must be associated with a business schedule that define when and how in the business timeline the service level objectives are evaluated. The following steps describe how to create an offering through the IBM Web Console. 1. Log on to the IBM Web Console as a user with the service offering specialist role or SLM Administrator role (for information on the ITSLA user roles, see 5.3.1, IBM SLA Console user management on page 158). For our example, the superadmin user is used. 2. After the IBM Web Console opens, select the Task Group Administer Service Offerings to view the available tasks, and click the Manage Offerings task. The Manage Offering window is shown in Figure 5-21 on page 168. 3. Click the Create button. 4. Insert the offering name, a description of the offering, and the SLA type related to the offering. There are three SLA types available for use: External Refers to service levels provided to your end users by the service provider. Reports for the service level evaluation results can be accessed by the end users. Refers to internal service levels in your company that cannot be accessed by external end users. Refers to the user of a service and the service provider. In the event that the service provider is a customer who is using ITSLA, and whose SLA services are being monitored by another provider, no evaluation or monitoring of metric values by ITSLA will result for the customer.
Internal Outsourced
167
Select the SLA type you prefer and click Next. For our example, the External SLA Type was selected.
Figure 5-21 Manage Offerings window
5. The Select Schedule window opens. Use an existing schedule by clicking the related radio button, or create a new schedule by clicking Create Schedule. 6. After the Create Schedule window opens, as shown in Figure 5-22 on page 169, insert a schedule name and decide on the period you would like to assign to the schedule. As the period table is initially empty, create a new period by clicking Create Period. Note: A schedule is made up of periods that divide the timeline into specific intervals, with all periods having a specific state (critical, prime, standard, off-hours, no impact, or no-service). Each period defines the importance of the time frame for the metrics evaluation. For instance, the no-service state is usually defined for a maintenance period or any other period when you do not want metric evaluations to take place.
168
Figure 5-22 Create Schedule window
7. The Create Period window is displayed, as shown in Figure 5-23 on page 170.
169
Figure 5-23 Create Period window
Insert the following parameters: a. Select the desired period state. There are seven available period states, each described below: Critical Indicates a time interval during which there is a very high usage of the business application. Service level objective (SLO) values may need to be set higher than usual during this time period. Indicates a time interval during which the provided service level is of high importance. The SLO values may be set to a higher than usual value, but lower than the Critical period value.
Peak
170
Prime
During this time interval, the business application performance is important, but is not as critical as the previously defined states. Consider setting the SLO values to a value slightly higher than what would be considered normal for the respective business application. Denotes a time interval during which the business application must provide an acceptable level of service. The values for each SLO may represent a normal setting for the business application. Indicates a time interval during which there is a low usage of the particular business application. Service Level Objective values may be set to a lower than normal value during this period. During this time period, the business application will not experience much usage, therefore setting the Service Level Objectives to a very low value is acceptable. Maintenance periods are usually placed within this time period. During this interval, ITSLA will continue to collect data, but Service Level Objectives can not be defined because ITSLA evaluations will not occur.
Standard
Low-impact
Off-hours
No-service
b. Select the desired Time Interval parameters: Start time of the period End time of the period Appropriate time zone
c. Define the repeating frequency: Single date, daily, weekly, monthly. d. Click OK. Note: The time zone chosen for the period is relative to the local time zone where the ITSLA Server is located. For more information on the time zone considerations, refer to 5.5, Timing considerations for the ITSLA environment on page 193.
8. Your new schedule is shown as being available, as displayed in Figure 5-24 on page 172. Click Next to continue.
171
Figure 5-24 Select Schedule window with a new schedule defined
9. The Create Customized Offering Components window opens, containing the available metrics for the offering. Click Create to create and configure a new offering component.
172
Figure 5-25 Resource Type tree
10.The Create Offering Component dialogue window is displayed. Expand the Resource Type Tree to view the source application components that are available to choose from, as shown in Figure 5-25. Components that are available will be shown in bold. Be sure to fully expand each component section so that all available components can be viewed. If an application has not been enabled, it will not appear in the this list. Refer to Source application data collection enablement on page 142, for more information. 11.Selecting one of the available components will insert the name of the chosen component into the Selected Resource Type form. For our example, the Tivoli Web Services Manager QoS Job was chosen as the offering component to configure. Click Next to continue.
173
Figure 5-26 Select QoS ROUNDTRIPTIME metric to configure
12.The Select Metrics window opens, displaying the available metrics for the chosen component. For our example, the ROUNDTRIPTIME metric was chosen, as shown in Figure 5-26. Click Configure after selecting the desired metric. 13.The Configure Service Level Objective screen appears, as shown in Figure 5-27 on page 176. The parameters available for the SLO configuration are as follows: Include metric in offering: Check this box to include the metric in the offering. Internal use only: Check this box if the metric data is for internal use only. Checking this box will cause the associated metric data to not be included in the SLA Reports that users can view through the ITSLA Report Interface.
174
Interval for SLO evaluation: This parameter sets the SLO evaluation frequency, which determines how often data inside the ITSLA Databases are analyzed for SLO violations. Available values are daily, weekly, and monthly. Start time Hours and Minutes for the SLO evaluation: Start time of the SLO evaluation. Time Zone for SLO evaluation: Local times for the start time of the SLO evaluation. Consider that the time zone specified is relative to the ITSLA Server time zone. For more information on time zone issues, refer to Chapter 5.5, Timing considerations for the ITSLA environment on page 193. Interval for SLO trend analysis: This parameter sets the SLO trend analysis frequency, determining how often data inside the ITSLA Databases is analyzed to find trends toward potential SLO violations. Available values are daily, weekly, and monthly. Note: The evaluation is performed on data collected from the day before the evaluation start date.
175
Figure 5-27 SLO Configuration dialogue window
14.Click the Breach Values tab. The Breach values screen is displayed, as shown in Figure 5-28 on page 177. Each parameter is defined as follows: Minimum, Maximum and Average: These values set the threshold for the chosen metric. Performance and availability data collected by the source applications are inserted in the TEDW Central Warehouse in an hourly format. Depending on the source application data, the maximum, minimum, and average value is weighted over a one hour period and is then inserted into the TEDW Central Warehouse. During SLA violation processing, the maximum and minimum values are evaluated to the highest and lowest single hourly value reported, respectively, during the evaluation period. These values must be defined for any period in the schedule.
176
Note: Certain source applications will not have the minimum, maximum, and average field, but instead will only have an average field. For instance, the IBM Tivoli Business Systems Manager application metrics has only the average value. In the drop-down menu, determine if the violation will occur when the actual average is higher than the supplied average or is lower than the actual average. For example, if you would like to receive a violation notice when the average response time of a Web application is greater than a certain value, choose actual average greater than supplied average and insert the desired value in the Average field. Another example may be if you want to receive a violation when a servers disk free-space is under a certain value. In this case, you would choose actual average less than supplied average and would insert the desired value in the Average field.
Figure 5-28 Configuration dialogue window for SLO breach values
177
15.Click OK when the SLO breach value configuration is complete. You can configure all the remaining metrics following the same steps. When you are finished configuring the metrics, click Next in the Select Metrics window. 16.The Define Component Information window opens. This component name and its description will appear at the time of creating the customer order. Insert a name and a description and click Finish to complete the offering component creation.
Figure 5-29 Create Customized Offering Components window
17.The Create Customized Offering Components window opens, as shown in Figure 5-29. If you would like to add additional components to your offering, click the Create button, and follow the same steps starting with step 10 on page 173. When you are finished adding components, click Next. 18.The Confirm Offering dialogue window displays, as shown in Figure 5-30 on page 179. At this time you can choose to save the offering as a draft in order to work on it later, or to publish the offering so that is available for customers. Click Finish to complete the offering creation.
178
Figure 5-30 Confirm Offering window
5.4.2 Management of orders

The offerings and their related schedule creation processes have been defined in 5.4.1, Management of offerings on page 167. You may now complete the SLA creation process by associating customers and realms with previously created offerings and schedules. This association, along with the specification of particular resources to include in the SLA contract, is called an order.
Order creation
The order creation process consists of the following steps: 1. Log on to the IBM Web Console with the customer order specialist, or SLM Administrator role (see 5.3, User creation and management on page 157, for further details).
179
2. Click the Administer Customer Orders task group to expand it and click Manage Orders to start the order creation process. The Manage Orders window opens, as shown in Figure 5-31. Click Create.
Figure 5-31 Manage Orders window
3. The Select Customer dialogue window displays, as shown in Figure 5-32 on page 181. Click Create Customer to associate a new customer with the order or select from an existing customer in the provided list.
180
Figure 5-32 Select Customer dialogue window
4. The Create Customer window opens. Choose an existing realm from the Realms table or click Create Realm to define a new one. 5. If you decide to create a new realm, insert a realm name and description and click OK. For our example, the All XYZ Customers realm is used.
181
Figure 5-33 Create Customer window with a new realm defined
6. After creating the realm you are presented with the Create Customer screen, as shown in Figure 5-33. The new realm is now present in the Realms table. Select one of the realms and insert a customer name and description. For our example, the Second XYZ Customer is defined as the new customer. Click OK.
182
Figure 5-34 Select Customer dialogue window with new customer defined
7. The Select Customer window opens, as shown in Figure 5-34. After selecting the desired customer click Next to continue. 8. The Select Offering window opens. Choose the offering that is to be associated with the customer and click Next.
183
Figure 5-35 Assign Resources to order offering component
9. The Assign Resources window opens, as shown in Figure 5-35. The offering components table is displayed in the window. For each offering component you must assign the resources that will be evaluated for this customer order. Select the desired component and click Assign. For our example, the Tivoli Web Services Manager QoS Job was selected.
184
Figure 5-36 Include Resources dialogue window
10.The Include Resources window opens, as shown in Figure 5-36. Initially, the Resources table will appear empty. You must add the resources to the chosen offering component that will be included in the service level evaluation. Click Add. 11.The Select Resource Definition Type window opens, allowing you to choose a filter to create a list of resources. There are three filtering criteria: Specifying a resource name: The fully qualified path names you specify are used to create the static resources list. If you choose to use a wild card character (*), all the component resources are displayed in the list. Specifying resource attributes: The resource attribute names you specify are used to create a static list of resources.
185
Specifying a resource list rule: If you choose a wild card value, a list of all resources that match the wild card value will be inserted in the resources list of the offering component. If a new resource is inserted in the ITSLA Databases and matches the wild card value, then new associated resources will be automatically added to the list. For our example, the Specify a resource name filter option is selected, as shown in Figure 5-37. Click Next.
Figure 5-37 Select Resource Definition Type dialogue window
12.In the Filter Resources by Name dialogue window, specify the resource name filter. For our example, the wild card (*) character is used, which will display all resources. Click Next to display the resource list.
186
Figure 5-38 Select Resources window
13.The Select Resources window displays the resources that can be included in the service level evaluation. In this dialogue window, each resource monitored by the different Tivoli applications is displayed. For our example, a specific Web site being monitored by the IBM Tivoli Monitoring for Transaction Performance (TWSM) application is selected, as shown in Figure 5-38. You may select as many resources here as you would like. Click Finish.
187
Figure 5-39 Include Resources window with a new component defined
14.The Include Resources window opens with the new resource defined, as shown in Figure 5-39. If you would like to add a new resource to the resource table, go back to step 9 on page 172. When you finish, click OK.
188
Figure 5-40 Assign Resources window with a complete offering component
15.The Assign Resources window opens, displaying the new offering component whose state is complete, as shown in Figure 5-40. If you would like to assign additional resources, click the Assign button. If not, click Next. 16.The last window of the order creation process opens. Review the order details and then click Submit to activate the Service Level Agreement.
Viewing an orders SLA state

Once the order has been submitted, it is placed in the Complete state. When an order is in this state, the associated SLA is ready for analysis and the results will be made available for reporting following the evaluation. If you are logged in to the IBM Web Console with a user who has the customer order specialist or Administrator role assigned, you can view and manage the available submitted orders by expanding the Administer Customer Orders task and selecting Manage Orders. Figure 5-41 on page 190 displays the Manage Orders screen.
189
Figure 5-41 The Manage Orders screen
A great deal of information regarding your orders can be found on this screen, such as the order ID, the customer name, the offering that is associated with the particular order, the SLA state, the order state, and the date on which the order was last modified. If you would like to find out more information for a particular order, select the order and click View at the bottom of the screen. You will now be presented with the View Order screen. This screen will provide you with most of the information located on the Manage Orders screen, but with some additional functionality. On the left side of the View Order screen, under the General heading, you can choose from three additional views: SLA State, Order State, and Offering Components. If the order you selected to view is in the Violation state, you can click the SLA State tab to view the violations that have been received. Figure 5-42 on page 191 shows what the SLA State screen may display.
190
Figure 5-42 SLA State screen
You can view when the violation was detected and for what metric and component the violation was received. To see the actual metric and breach values that caused the violation, select the violation you wish to view and click the View Violation button located under the table. The View Violation screen is shown in Figure 5-43 on page 192. Click the Close button to leave this screen and return to the View Order screen. By clicking the Order State tab on the View Order screen, you can view the state of the selected order along with the state of the associated offering components. Click the Close button to leave this screen. Clicking the Offering Components tab on the View Order screen will display the offering components that are part of the order. You can drill down deeper into each component by selecting it and clicking the View Resources button. Through the next series of screens, you can view the settings you made when creating each offering component.
191
Figure 5-43 View Violation screen
Order deletion
It is possible to delete customer orders once they have been submitted if the defined SLA is no longer needed. However, the following criteria must be first met before an order can be deleted: The order state of the order you would like to delete must be Canceled, Failed, or Deploy Failed. In the ITSLA Database, there can be no violation or trend data associated with the order you want to delete. If it is necessary to delete an order that does not meet the above criteria, contact Tivoli Customer Support.
192
5.5 Timing considerations for the ITSLA environment

The basic data flow in the IBM Tivoli Service Level Advisor environment is shown in Figure 5-44. Source ETLs are responsible for transferring and transforming source application data into the format required by the Tivoli Central Data Warehouse. Refer to 2.7, Applications providing measurement data on page 46, for how to enable an application to insert data into the Tivoli Data Warehouse and become ITSLA-enabled. The Registration Target ETL and Process Target ETL are the ITSLA Target ETL processes that transfer data, respectively, from the TEDW Central Warehouse database to the ITSLA Database and the ITSLA Measurement Data Mart databases.
ET L
Source ETL
Source Application Database
R eg
is tra t
ITSLA Database
io n
s es oc Pr L ET
Figure 5-44 Data Flow in the ITSLA environment
When the latest available data is inserted in the ITSLA Databases, IBM Tivoli Service Level Advisor can begin evaluating and analyzing the data for service level agreement violations and for possible violation trends. In the following sections, information is provided regarding the scheduling of ETLs and the ITSLA evaluation process.
193
5.5.1 Scheduling ETLs

In order for all source application data to be transferred efficiently, the source application administrator and the Tivoli Enterprise Data Warehouse administrator must devise a common data transfer policy. It is the responsibility of the Tivoli Enterprise Data Warehouse administrator to choose a time period that is most suitable for the scheduling and running of the Source ETLs, so that the data transfer process will experience optimal network performance. This will depend not only on the network capacity, but also on the amount of data being transferred by the Source ETLs. The following rules should be considered when scheduling the ETLs: The Source ETL data transfer must complete before the Registration Target ETL begins processing. The Registration Target ETL must run and complete its SQL steps before the Process Target ETL begins its processing. The Registration Target ETL populates the ITSLA Database with data from the TEDW Central Warehouse, and the Process Target ETL reads data from the ITSLA Database to determine what data is to be transferred to the ITSLA Measurement Data Mart. The Process Target ETL must start its data transfer after the Registration Target ETL completes, so that the most recent source application data is available. Furthermore, the Process Target ETL transfers data from the TEDW Central Warehouse database to the ITSLA Measurement Data Mart database, where IBM Tivoli Service Level Advisor then evaluates this data against the defined service level agreement. The Process Target ETL must be scheduled to run daily, so that the latest data available can be included in the evaluation process. The Registration Target ETL must run when new measurement data types are inserted by the Source ETLs into the TEDW Central Warehouse database, or when new source applications add their data into the TEDW Central Warehouse database. In a complex environment with many different source applications and many new data measurement types being added daily to the TEDW Central Warehouse database, it is advisable to run the Registration Target ETL daily. Because of this, the source application administrator must communicate to the Tivoli Enterprise Data Warehouse administrator any changes in the data collection policy.
194
5.5.2 ITSLA evaluation schedule and time zone considerations

IBM Tivoli Service Level Advisor evaluates the data inside its data marts in order to determine violations and trends toward potential violations for SLOs configured during order creation (see 5.4.2, Management of orders on page 179). The start time and the frequency of the SLO evaluation and trend analysis is determined during the configuration of the service level objectives (see step 12 on page 174). At the configured start time, IBM Tivoli Service Level Advisor begins the evaluation process, where the time interval of the analysis depends on the following frequencies: Daily frequency In the case of a daily evaluation frequency, the evaluation begins on the day before the evaluation starts. For instance, a daily frequency time interval defines the start time as 12:00 AM on the previous day and the end time as 11:59 PM on the current evaluation day. In the case of a weekly evaluation frequency, the time range of the evaluation begins at 12:00 AM on the Sunday of the previous week and ends at 11:59 PM on the Sunday of the current week. In the case of a monthly evaluation frequency, the time range of the evaluation begins at 12:00 AM on the first day of the previous month and ends at 11:59 PM on the last day of the previous month.
Weekly frequency
Monthly frequency
In the evaluation scheduling process you must also consider the topic of time zones. Time zones are specified during the SLO evaluation and trend analysis configuration, and should be kept in mind when defining the business schedule periods (see step 7 on page 169). The following time zone issues must be considered when defining a service level agreement: The time zone of the customer that has a SLA with your company The time zone used by the ITSLA Server component The time zone of the ITSLA administrator (the administrator might be located in a different time zone from the ITSLA Server) Consider that when you define a time zone on the ITSLA Server, it is always relative to the ITSLA Servers time zone. For example, if you set an evaluation starting at 1:00 AM Eastern Standard Time (EST), and the ITSLA Server is located in Los Angeles using Pacific Standard Time (PST), then the evaluation start time will be set for 10:00 PM (EST is three hours ahead of PST). Keep in mind that when you set a daily evaluation frequency for a SLO, the evaluation will
195
occur on the day before the ITSLA evaluation start date. For example, if there is an evaluation start date set for Tuesday at 1:00 AM EST, and the ITSLA Server is using PST, the evaluation will begin on Monday at 10:00 PM PST and will analyze data for the day before Monday, being Sunday.
Time zone example

Consider the following example scenario to better understand the time zone issue, keeping in mind the business schedule: The ITSLA Server is located in Rome (GMT + 01:00). The ITSLA administrator manages the ITSLA Server from a Web browser located in New York (GMT - 05:00). The SLA contract is with a customer located in Tokyo (GMT + 09:00). The SLA contract with the customer in Tokyo contains a business schedule that defines a peak period starting at 8:00 AM and ending at 11:00 AM Tokyo time, which the ITSLA administrator in New York will define using the Tokyo time zone via the ITSLA Web interface. The evaluation frequency is daily, and the start time is set by the administrator to 4:00 AM Rome time, since the ITSLA Server is in Rome and the evaluation period is to begin at 12:00 AM in Tokyo. Because the evaluation needs a certain amount of time to complete (depending on the amount of data to analyze and the available bandwidth), for example, up to one hour, the customer will be able to access reports starting at 1:00 AM Tokyo time. In this scenario, the business schedule has been customized based on customer needs, but sometimes the schedule is defined in the context of a service, and not for a specific customer. Keep in mind, the business schedule of a service must always refer to the time zone where the customers of the service area are located.
Table 5-6 Local times for SLA evaluation and peak period start times
Location Evaluation start time Peak period start time
Rome New York Tokyo
4:00 AM 10:00 PM 12:00 AM
12:00 AM 6:00 PM 8:00 AM
5.6 Trace and message log files

In an ITSLA environment, two types of log files exist: Message text Trace data log files
196
They are both collected by loggers, which are IBM Tivoli Service Level Advisor software objects. Data collected by loggers are directed to log files by software objects called handlers.
5.6.1 Handler configuration

You can determine how you would like to log trace and message data through the handler configuration. There are three types of handlers: Multi-file handler Serial file handler Console handler The message and trace data is sent to a rotating set of log files. The message and trace data is sent to a serial log file. Writes messages to the console or system.out.
The handler object name of the trace log files is trcFile.slm, while the handler object name of the message log files is msgFile.slm. There are three different environments for which you are able to configure handlers: ITSLA Server ITSLA Reports IBM Console Through the handler configuration you can define the number of log files and their dimensions for each environment.
Handler configuration for the ITSLA Server environment

In order to change the number of log files and their dimensions, perform the following steps on the ITSLA Server machine: 1. Initialize and source the ITSLA CLI environment by performing the following: For Windows, from the ITSLA installation directory, run the slmenv.bat file. For UNIX, from the ITSLA installation directory, execute . ./slmenv.sh. 2. To change the maximum size of the message log files, run the following commands:
scmd log handler msgFile.slm -set maxFileSize=dimension_of_log_file
If you want to change the maximum size of the trace data log files, run the following command:
scmd log handler trcFile.slm -set maxFileSize=dimension_of_log_file
Where maxFileSize is the key needed to change the dimension, and the dimension_of_log_file parameter is a numeric value that expresses the log file dimension in KB. The default dimension of log files is 512 KB.
197
3. To change the maximum number of message log files run the following command:
scmd log handler msgFile.slm -set maxFiles=max_number_of_log _files
And to change the maximum number of trace log files run the following command:
scmd log handler trcFile.slm -set maxFiles=max_number_of_log _files
Where maxFiles is the key needed to change the number, and the max_number_of_log_files parameter is a numeric value that expresses the maximum number of log files. For more information regarding the scmd log handler command, refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
Handler configuration for the ITSLA Reports environment

Configuring the handler for the ITSLA Reports environment follows the same steps outlined in the previous section. You can replicate the steps provided in the previous section, substituting the scmd log handler command with the logutil handler command. The command examples remain the same, as shown below:
logutil handler msgFile.slm -set maxFileSize=1024 logutil handler trcFile.slm -set maxFileSize=2048
For more information on the logutil handler command, refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
Handler configuration for the IBM Console environment

In order to configure handlers for the IBM Console environment, perform the following steps: 1. Log on to the IBM Java Console as the superadmin user. 2. From the task groups on the left-hand side of the screen, expand Administer Logging, click Configure Logging, and select Handlers, as shown in Figure 5-45 on page 199. 3. Locate the trcFile.slm and the msgFile.slm handlers on the right side of the window. 4. Right click the handler you want to configure and select Edit Properties. For our example, the trcFile.slm handler is chosen.
198
Figure 5-45 Configure logging for IBM Console environment
5. The trcFile.slm properties dialogue window is displayed, as shown in Figure 5-46 on page 200. From here you can decide the maximum size of the log files and the number of trace log files. 6. Stop and restart the Server for IBM Console and Web Services for IBM Console processes (see 5.7, Startup and shutdown procedures on page 204, for more information on starting and shutting down the IBM Tivoli Service Level Advisor components).
199
Figure 5-46 Properties dialogue window for tracing handler
5.6.2 Message log files management

Message log files for the IBM Tivoli Service Level Advisor environment are available for the ITSLA Server, ITSLA Reports, and ITSLA Task Drivers (IBM Console) components environment. There are two message log file name formats: SLMMessagex.log The message logger inserts message data starting from the SLMMessage1.log file. When the file reaches its maximum dimension, it is renamed SLMMessage2.log and a new SLMMessage1.log file is created and populated. The maximum dimension of the message log files and their number is decided during the msgFile.slm handler configuration (see 5.6.1, Handler configuration on page 197).
200
SLMSerialMessagex.log
The message logger inserts message data with the same process described in the previous point. This is a serialized format log file, and its contents can be viewed using the log viewer function of the IBM Java Console.
The location of each message log file type is shown in Table 5-7, where ITSLA_Install_Dir is the installation directory of ITSLA, and PS_Dir is the directory where the Tivoli Presentation Services is installed.
Table 5-7 Locations of message log files
ITSLA component Location
ITSLA Server ITSLA Reports ITSLA Task Drivers (IBM Console)
ITSLA_Install_Dir/log/SLMServer ITSLA_Install_Dir/log/SLMReport PS_Dir/log/fwp_mcr, PS_Dir/log/fwp_wc
There are two separate log file directories for the ITSLA Task Drivers, with fwp_mcr representing the MCR component of the Server for IBM Console, and fwp_wc representing the WC component of Web Services for IBM Console. There are a number of ways to view the ITSLA message logs, dependent on your operating system: For UNIX, you may use the command tail -f message_log to view the message logs. For Windows, you can use the Notepad or your preferred text editor. The IBM Java Console may also be used to view the message logs. For more information on using the IBM Java Console for viewing message logs, refer to the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
5.6.3 Trace log files management

Trace log files for the ITSLA environment are available for the ITSLA Server, ITSLA Reports, and the ITSLA Task Drivers (IBM Console) components environment. The trace log files are activated to diagnose problems and are used mainly by IBM support personnel. In the following section, information is provided to help you activate the different trace logger for the specific environments and to provide meaning for the different available trace loggers.
201
The trace log files are located in the same directories as the message log files (see 5.6.2, Message log files management on page 200), with a naming format of SLMTracey.log, where y can be a number from 1 to 3. The SLMTrace1.log file always contains the most recent information. The SLMTracey.log file has a maximum dimension determined by the handler configuration (see 5.6.1, Handler configuration on page 197). When the SLMTrace1.log file has reached its maximum size, it is renamed to SLMTrace2.log and a new SLMTrace1.log file is created and filled with trace data. Table 5-8 lists the available IBM Tivoli Service Level Advisor trace loggers, along with their associated subcomponents and descriptions.
Table 5-8 Available ITSLA trace loggers
Trace logger group name Subcomponent Description
dykal
adapter ds cli cm cfg log
Trace logger for the adapter layer. The subcomponents are shown for the adapter, the data source (ds), the CLI Service (cli), Configuration Management (cm), configuration (cfg), and logging (log). Trace logger for the data collector. Trace logger for the ETL processes. Trace logger for the GUI. Trace logger for Database API Code.
dylws dyket dykgu dyktik dykme common mem scheduler
Trace logger for the Metric Evaluator Manager and its components. Trace logger for the Order Manager. Trace logger for the Report Server.
dykom dykrp dyksd dyksl dykut sdml
Trace logger for the Service Definition Catalog. Trace logger for the Service Level Agreement component. Trace logger for the Common code.
202
In order to activate the tracing activity for the ITSLA Server and Reports environments, perform the following steps: 1. Initialize and source the ITSLA CLI environment by performing the following: a. For Windows, from the ITSLA installation directory, run the slmenv.bat file. b. For UNIX, from the ITSLA installation directory, execute . ./slmenv.sh. 2. List the available trace loggers: a. For the ITSLA Server environment, type the following command:
scmd log trace -list
b. For the ITSLA Reports environment, type the following command:

logutil trace -list
3. Enable the trace loggers: a. For the ITSLA Server environment, use the output listed from the command given in Step 2a above and type the following:
scmd log trace -g [group/subcomponent] -set isLogging=true
b. For the ITSLA Reports environment, use the output listed from the command given in Step 2b above and type the following:
logutil trace -g [group/subcomponent] -set isLogging=true
Where group and subcomponent are chosen from Table 5-8 on page 202. In order to turn on tracing for the ITSLA Task Drivers (IBM Console), perform the following steps: 1. Log in to the IBM Java Console as the superadmin user. 2. Select Administer Logging -> Configure Logging. 3. Under Types of Logging Elements, select Trace Loggers. 4. Right click of the trace loggers available for the IBM Console and select Enable, as shown in Figure 5-47 on page 204. 5. Stop and restart the Server for IBM Console and Web Services for IBM Console services.
203
Figure 5-47 Enable trace logging on the IBM Console
The trace loggers available for the IBM Console environment are: dykgu, dyksd, dyktik, dykut, dykal, dykal.cm, dykal.adapter, and dykal.ds. For more information about the trace log format and filtering masks configuration, refer to the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
5.7 Startup and shutdown procedures

Startup and shutdown procedures are described in Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. A compact reference is included in the following sections for the steps necessary to startup and shutdown components in the ITSLA environment for both the UNIX and the Windows environment.
204
5.7.1 IBM Tivoli Service Level Advisor components startup

Table 5-9 on page 206 lists the commands necessary to start the IBM Tivoli Service Level Advisor components. Each component is shown in the order in which it must be started. If there is more than one way to start the ITSLA component, each startup option is listed as well.
Windows environment
In a Windows environment, the IBM Tivoli Service Level Advisor components can be started a number of ways, each of which is explained in Table 5-9 on page 206. You may start each component by using one of the following: The appropriate command line interface (CLI) If it was installed as a service, through Services in the Control Panel By selecting the application, if available, through Start -> Programs -> Application_Name Table 5-9 on page 206 includes the following variables, which are described here:
PS_Dir ITSLA_Server_Inst_Dir IBM_Console_Machine IBM_HTTP_Port WebSphere_Dir db2_inst_dir HTTP_Dir
Directory where Tivoli Presentation Services is installed Directory where the ITSLA Server is installed Host name of the machine where the IBM Console Server is installed Port used by the IBM HTTP server Directory where WebSphere is installed Home directory of the database administrator who created the instance Directory where the IBM HTTP Server is installed
The variable definitions remain the same as in Table 5-10 on page 208.
UNIX environment
In a UNIX environment, you may need to source the IBM DB2 profile. From a command prompt, navigate to the DB2_Inst_Home/sqllib directory and run the following command:
. ./db2profile
205
Table 5-9 Commands to start ITSLA components

Component Windows start commands UNIX start command
Server for IBM Console Services
Access the Windows Services administration tool, right click Server for IBM Console and select Start. At a command prompt, access the PS_Dir\bin\w32-ix86 directory and execute the command mcr.bat. At a command prompt, execute the command net start ps_mcr. Access the Windows Services administration tool, right click Web Services for IBM Console and select Start. At a command prompt, access the PS_Dir\bin\w32-ix86 directory and execute the command wc.bat. At a command prompt, execute the command net start ps_wc. Access the Windows Services administration tool, right click IBM Tivoli Service Level Advisor and select Start. At a command prompt, execute the command net start tslm. Select Start -> Programs -> IBM WebSphere -> Application Server -> Start Application Server. At a command prompt, access the WebSphere_Dir\bin directory and execute the command startServer.bat.
Run ps -ef | grep mcr to see if the mcr.sh process is started. If it is not started, navigate to PS_Dir/bin/generic_unix and execute the command ./mcr.sh.
Web Services for IBM Console
Run ps -ef | grep wc to see if the wc.sh process is started. If it is not started, navigate to PS_Dir/bin/generic_unix and execute the command ./wc.sh.
ITSLA Server
Navigate to the ITSLA_Inst_Dir/bin and execute the command ./slm_service_start.sh.
IBM WebSphere Application Server AES 4.0 and 4.01
Source the DB2 Profile and from a command prompt navigate to the WebSphere_Dir\bin directory and execute the command ./startServer.sh.
206
Component
Windows start commands
UNIX start command
IBM WebSphere Application Server SE 3.5
Select Start -> Programs -> IBM WebSphere -> Application Server V3.5 -> Start Application Server. At a command prompt, access the WebSphere_Dir\bin directory and execute the command startServer.bat.
From a command prompt, navigate to the WebSphere_Dir/bin directory and execute the command ./startServer.sh.
IBM HTTP Server
Access the Windows Services administration tool, right click IBM HTTP Server and select Start. At a command prompt, execute the command net start IBM HTTP Server.
From a command prompt, navigate to the HTTP_Dir/bin directory and execute the command . ./apachectl start.
IBM HTTP Administration Server
Access the Windows Services administration tool, right click IBM HTTP Administration and select Start. At a command prompt execute the command net start IBM HTTP Administration.
From a command prompt, navigate to the HTTP_Dir/bin directory and execute the command . ./adminctl start.
The ITSLA environment has three main consoles that you can work with. Each console may be started in the following ways: ITSLA Web Console This is the main ITSLA console that is accessed through the following URL:
http://IBM_Console_Machine:IBM_HTTP_Port/IBMConsole
The default user with the ITSLA administrative role is superadmin and the default password is password. ITSLA Java Console This console is used mainly for reviewing message logs and turning tracing on and off. You can access this console in a Windows environment by double clicking the IBM Console icon on the Windows Desktop. In a UNIX environment, locate and run the jc.sh script.
207
WebSphere Admin Console This console is used primarily to administer the WebSphere and ITSLA Report Server. In order to access this console in a Windows environment select Start -> Programs -> IBM WebSphere -> Application Server -> Administrators Console. To access this console in a UNIX environment, navigate to the WebSphere_Dir/bin directory and execute the following command:
. ./adminclient.sh hostname_of_WebSphere_Server_machine
5.7.2 ITSLA components shutdown

Table 5-10 lists the commands necessary to shut down the ITSLA components. Each component is shown in the order in which it must be shut down. If there is more than one way to shut down the ITSLA components, each shutdown option is listed as well.
Table 5-10 Commands to shutdown ITSLA components
Component Windows shutdown commands UNIX shutdown command
IBM HTTP Server
Access the Windows Services administration tool, right click IBM HTTP Server and select Stop. At a command prompt execute the command net stop IBM HTTP Server. Access the Windows Services administration tool, right click IBM HTTP Administration and select Stop. At a command prompt execute the command net stop IBM HTTP Administration. At a command prompt, access the WebSphere\bin directory and execute the command stopServer.bat.
From a command prompt navigate to the HTTP_Dir/bin directory and execute the command . ./apachectl stop.
IBM HTTP Administration Server
From a command prompt navigate to the HTTP_Dir/bin directory and execute the command . ./adminctl stop.
IBM WebSphere Application Server SE 3.5 and IBM WebSphere Application Server 4.0 and 4.01
From a command prompt navigate to the WebSphere_Dir/bin directory and execute the command . ./stopServer.sh.
208
Component
Windows shutdown commands
UNIX shutdown command
ITSLA Server
Access the Windows Services administration tool, right click IBM Tivoli Service Level Advisor and from the context menu select Stop. At a command prompt execute the command net stop tslm. Access the Windows Services administration tool, right click Web Services for IBM Console and select Stop. At a command prompt, access the PS_Dir\bin\w32-ix86 directory and execute the command stopwc.bat. At a command prompt execute the command net stop ps_wc. Access the Windows Services administration tool, right click Server for IBM Console and select Stop. At a command prompt, access the PS_Dir\bin\w32-ix86 directory and execute the command stopmcr.bat. At a command prompt execute the command net stop ps_mcr.
Navigate to the ITSLA_Server_Inst_Dir/bin directory and execute the command ./slm_service_stop.sh.
Web Services for IBM Console
Run ps -ef | grep wc to check if the wc.sh process is running. If it is running, navigate to the PS_Dir/bin/generic_unix directory and execute the command . ./stopwc.sh.
Server for IBM Console Services
Run ps -ef |grep mcr to see if the mcr.sh process is running. If it is running, navigate to PS_Dir/bin/generic_unix and execute the command . ./stopmcr.sh.
5.8 Backup and restore of ITSLA

The IBM Tivoli Service Level Advisor environment maintenance is assured by regular backups in order to have an updated image of the environment if problems occur. A backup and restore procedure is provided if your company does not already have a backup strategy in place.
209
The IBM Tivoli Service Level Advisor environment components that should be backed up are listed below: ITSLA Server ITSLA Task Drivers ITSLA Report ITSLA Databases, which are the ITSLA Database and the ITSLA Measurement Data Mart Tivoli Enterprise Data Warehouse databases WebSphere customized report servlets for the ITSLA environment Before starting any backup or restore procedure, be sure to unschedule the Registration Target ETL in order to produce consistent backups. If the Registration Target ETL happens to run during a backup procedure, the ITSLA environment may become inconsistent. Be sure to shut down the ITSLA Server, ITSLA Reports, and ITSLA Task Drivers prior to the back up or restore. Following these procedures, reschedule the Registration Target ETL and restart the ITSLA components. In this section, information regarding backup and restore procedures for the IBM Tivoli Service Level Advisor components is provided. To ensure a successful backup and restore, follow the order defined in the following sections.
5.8.1 Backing up the ITSLA environment

In order to obtain a successful backup of the IBM Tivoli Service Level Advisor environment, perform the steps in the following sections.
Unschedule the Registration Target ETL

To unschedule the Registration Target ETL, you must place the ETL in Test Mode, which will remove the currently defined schedule (refer toScheduling and running the Registration Target ETL on page 144, for information about the Registration Target ETL schedule).
ITSLA installation directories backup

IBM Tivoli Service Level Advisor has three components that must be backed up: ITSLA Server ITSLA Reports Server ITSLA Task Drivers
210
A backup can be made for each of the installation directories by running the slmbackup script. In the case of a distributed install, the slmbackup script must be run on each machine simultaneously where an ITSLA component is installed. For example, if the ITSLA Server and ITSLA Reports Server are installed on the same machine, and the ITSLA Task Drivers are installed on another machine, you will need to run the slmbackup script on both machines, with the backup being stored locally. Before executing the slmbackup command, the ITSLA environment must be initialized by running the slmenv.bat or slmenv.sh scripts, depending on your operating system. The backup script is located in the ITSLA installation directory and has the following syntax:
slmbackup {backup_directory [-auto] | -start}
Where backup_directory is the directory that will contain the backup image. If you are creating a backup directory on UNIX, ensure that the directory is write-enabled. The -auto option forgoes user confirmation before the backups, while the -start option is used to restart ITSLA after the backup has completed. As an example, we will make a backup of the ITSLA Task Drivers, which is installed on a Windows machine. A directory labeled ITSLA Backup is created and will contain the backup images. From a command line with the ITSLA environment variables sourced, the following command is run:
slmbackup C:\ITSLA Backup
The script executes the following actions: 1. The ITSLA components are stopped in order to be backed up. 2. In order to have a consistent backup of each ITSLA component, the script reminds you to shut down the ITSLA components not installed on the machine and to run the slmbackup command on the other machines in order to synchronize the backup for the other ITSLA components, as shown in Example 5-5.
Example 5-5 Output of slmbackup script
C:\Program Files\ITSLA>slmbackup "C:\ITSLA Backup" DYKUT0100I -- Starting backup of IBM Tivoli Service Level Advisor. -DYKUT0186W ** WARNING: To successfully back up IBM Tivoli Service Level Advisor, the SLM Server, IBM Console Server including the SLM Task Drivers, and the SLM Report Server must be shutdown and remain shutdown. This process will properly shutdown each server as necessary to run the backup procedures. Do not attempt to run IBM Tivoli Service Level Advisor until all backup operations have complete. DYKUT0152I The directory C:\ITSLA Backup\DYK\200205101538 does not exist. It will be created now.
211
DYKUT0102I IBM Tivoli Service Level Advisor will be backed up to C:\ITSLABackup\DYK\200205101538\200205101538.zip. DYKUT0108I -- Stopping the IBM Console Server including the SLM Task Drivers. -The Web Services for IBM Console service is not started. More help is available by typing NET HELPMSG 3521. The Server for IBM Console service is not started. More help is available by typing NET HELPMSG 3521. DYKUT0109I -- Stopping the SLM Server. -The IBM Tivoli Service Level Advisor service is not started. More help is available by typing NET HELPMSG 3521. DYKUT0111I The three IBM Tivoli Service Level Advisor servers, the SLM Server, the IBM Console Server including the SLM Task Drivers and the SLM Report Server are required to be shut down to continue. DYKUT0112I The following IBM Tivoli Service Level Advisor servers are not located on this installation and need to be shutdown: the SLM Reports. DYKUT0116I This backup procedure, slmbackup, must be performed on each machine where the SLM Server, SLM Task Drivers or SLM Reports options of IBM Tivoli Service Level Advisor are installed to verify each is shutdown before obtaining synchronized backup images. Issue the slmbackup command on the machine containing the installation of the SLM Reports. When all slmbackup procedures have reached this point, press the Enter key to continue. DYKUT0125I -- IBM Tivoli Service Level Advisor Installation Directory Backup. -DYKUT0184I -- Performing backup of the IBM Tivoli Service Level Advisor installation directory for the SLM Task Drivers and SLM Server. -DYKUT0157I Completed IBM Tivoli Service Level Advisor Installation Directory backup for the SLM Task Drivers and SLM Server with the file C:\ITSLA Backup\DYK\200205101538\200205101538.zip. DYKUT0127I To complete all IBM Tivoli Service Level Advisor installation directory backups, the backup image of the installation directories for the SLM Reports need to complete. Allow the backup of those servers to complete before restarting IBM Tivoli Service Level Advisor. DYKUT0123I The IBM Console Server was found on this machine at C:\PS. Backup procedures for the IBM Console Server and SLM Database should be performed before restarting IBM Tivoli Service Level Advisor. DYKUT0138I -- IBM Tivoli Service Level Advisor Installation Directory Backup Complete. -C:\Program Files\ITSLA>
212
3. The ITSLA Task Drivers installation directories are backed up and placed in a zipped format in the following directory path:
C:/ITSLA Backup/DYK/200205101538/200205101538.zip
Where 200205101538 is the backup timestamp. If you want to restart the ITSLA components after the backup completes, execute the following command:
slmbackup -start
Keep in mind that during the backup process, the ITSLA components must not be active, and only when all the ITSLA environment components (ITSLA Database Server, Tivoli Enterprise Data Warehouse, WebSphere reports servlets) have been backed up can you restart the ITSLA components.
ITSLA Database component backup

In order to back up the ITSLA Database component, you must use the db2 backup command on the ITSLA Database Server machine. Perform the following steps to create a backup: 1. Open an IBM DB2 command line. 2. Execute the following command:
db2 backup database ITSLA_DB_Name user Admin_User using Admin_Password to backup_directory
Where: ITSLA_DB_Name is the ITSLA Database name chosen during the ITSLA installation (DYK_CAT, for example). Admin_User is a DB2 user with administrative privileges. Admin_Password is the password of the administrative user. Backup_Dir is the directory where database backup images will be located. This directory must be created prior to running the backup. If you receive a message when trying to back up a database that states the database is currently in use, use the db2 terminate or db2 force application all command to free the databases from current activity. Note the timestamp after the database backup has completed, as this will be used in the case that a restore is necessary. Consult your database administrator in order to schedule and develop a common backup strategy.
Restarting the ITSLA environment

After you have backed up the ITSLA components, you can restart the ITSLA environment by following the instructions given in the 5.7, Startup and shutdown procedures on page 204.
213
The Registration Target ETL must be rescheduled in order for the ITSLA environment to function properly. Refer to 5.2.1, Registration Target ETL management on page 142, for information on how to schedule the Registration Target ETL.
5.8.2 Restoring the ITSLA environment

In order to restore the IBM Tivoli Service Level Advisor environment from an existing backup, the Registration Target ETL must first be unscheduled and the ITSLA components must be shut down. Refer to 5.8.1, Backing up the ITSLA environment on page 210, for more information. If irreparable damage has occurred to the ITSLA Server, and you must reinstall the environment, be sure to use the same naming conventions for all directories where the product was initially installed. If the machine itself is damaged, and you must reinstall on another machine, make sure that the new machine is configured with the same host name and disk partition configuration. The restore procedure is made up of a number of steps, as described in the following sections.
ITSLA installation directories and report servlets restore

The IBM Tivoli Service Level Advisor components installation directories contain the configuration information needed to restore the ITSLA environment. If the ITSLA components have all been installed on the same machine, the restore procedure is to be executed only on that machine. If the ITSLA components are installed on separate machines, the restore procedure must be executed on each machine where the installation directories are located. The timestamp of the backup must be the same for each component restored, otherwise the restore procedure will not be successful. The slmrestore and slmrestorestart scripts are used to restore the ITSLA installation directories. If the ITSLA components are installed on different machines, you must execute the following steps on each machine: 1. From the ITSLA product CD, execute the following command:
slmrestore directory timestamp
Where directory is the directory where the backup is located, and timestamp is the timestamp of the backup (refer to ITSLA installation directories backup on page 210).
214
2. The slmrestore utility analyzes the system to determine which ITSLA components are installed before shutting them down. If other components are installed on other machines, slmrestore prompts you to shut down the other components and start the slmrestore on the other machines in order to have a consistent restore. 3. The installation directories are restored. 4. The ITSLA Report servlets for IBM WebSphere Application Server Versions 4.0 and 4.0.1 are automatically restored. For other IBM WebSphere Application Server versions, a manual restore must be performed, as described in Getting Started with IBM Tivoli Service Level Advisor Version 1.1, SC32-0834. Important: On the ITSLA Server machine, the ITSLA_Inst_Dir/cfg directory must be removed before starting the restore procedure. This step is not required if you have recently reinstalled the ITSLA Server. If this step is necessary, stop the ITSLA Server and Reports Server before removing the cfg directory, if these components are located on the same machine.
ITSLA Databases restore

The databases to be restored in a IBM Tivoli Service Level Advisor environment are the ITSLA Database (DYK_CAT) and the Tivoli Enterprise Data Warehouse databases. This section describes the process for the ITSLA Database. For instructions on the Tivoli Enterprise Warehouse databases, please refer to Tivoli Enterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744. To list all of the backups available for restore, run the following command from a DB2 command prompt:
db2 list history backup all for db_name
Where db_name is the database previously backed up. In the command output you will find the start time of the backups and the locationtwo values that must be used during a restore. Important: The ITSLA Database restore must be executed using a backup performed at the same time period of the ITSLA directories backup, otherwise the restore procedure will not be successful. The ITSLA Database restore is achieved through the IBM DB2 command listed below:
db2 restore database db_name user DB2_user using DB2_password from backup_directory taken at DB2_timestamp>\
215
Where:
db_name
Is the name of the database to be restored. In our case, the database name is the ITSLA Database, whose default name is DYK_CAT. Is the DB2 user chosen to execute the restore procedure. You must choose a user with administrative privileges, usually db2admin or db2inst1 by default. Is the DB2_user password. Is the directory where the database backup is located. The value of this parameter is equal to the location variable for the ITSLA Database backup, obtained through the db2 list history backup command previously executed. Is the backup timestamp. The value of this parameter is the value of the start time variable for the ITSLA Database, obtained with the db2 list history backup command previously executed.
DB2_user
DB2_password backup_directory
DB2_timestamp
Restarting the ITSLA environment

When the restore procedure has successfully completed, you can restart the ITSLA components and reschedule the Registration Target ETL and Process Target ETL. To restart the ITSLA components, refer to the relevant procedures indicated in 5.7.1, IBM Tivoli Service Level Advisor components startup on page 205, or you can execute the command slmrestorerestart on any machine where the ITSLA components are installed. You must also reschedule and run the Registration Target ETL and Process Target ETL. To do this, refer to 5.2, Target ETLs management on page 142.
216
Chapter 6.
Service level Reports with ITSLA

IBM Tivoli Service Level Advisor provides a reports feature that allows the viewing of violation and trend data stored in the ITSLA Database. Depending on the users role who is responsible for accessing the reports, there are a number of customizable features for this Web-based component. Whether you would like to view violations for a single customer over the past week, or the customer ranking for a group of customers covering the previous quarter, IBM Tivoli Service Level Advisor can provide these features and more with the single click of a button. In the following sections you will learn more about the different features and functions of IBM Tivoli Service Level Advisor Reports, such as: Logging into Reports Using Reports Administrating Reports users Reports customization Viewing Reports with third-party software
217
6.1 Logging into Reports

In order to log into IBM Tivoli Service Level Advisor Reports, you must know the name of your ITSLA Reports Server, and the port that IBM WebSphere is using for reports. Unless you have manually changed the port definition, the default is set to 9080. Enter the following URL in your desired Web browser to connect to Reports:
http://ITSLA_Reports_Server:port/SLMReport
In Figure 6-1 the Report Sign on screen is shown. As you will notice, in order to access the features of Reports, you must supply this page with a user name and password. The following section provides information concerning the default users created during the installation of IBM Tivoli Service Level Advisor Reports.
Figure 6-1 Reports sign-on screen
218
6.1.1 Default Reports users

There are three users set up by default for Reports, those being customer, executive, and operations, with the password set to password. Each user is initially configured with a different Report view; however, all default users have been created with unrestricted view access, meaning they are able to see information regarding all customers across all realms. Each user and default view are defined below: The customer user will initially see the Customer Order Ranking view via the customer.jsp page, as shown in Figure 6-2. This view displays all order IDs with their associated customers, the number of violations and trends for that customer, and the customers rank in descending order in a month-to-date time period. More information concerning order ranking can be found in 6.1.2, The Ranking algorithm and categories on page 221.
Figure 6-2 Customer user view
Chapter 6. Service level Reports with ITSLA
219
The executive user will initially see the Customer Ranking view by logging into the executive.jsp page, as shown in Figure 6-3. This view displays the same information within the same time period as the customer view, minus the order IDs.
Figure 6-3 Executive user view
The operations user will initially see the Offering Component Ranking view by using the operations.jsp page, as shown in Figure 6-4 on page 221. The offering components, the number of violations and trends associated with each offering component, and the offering component ranking are displayed on this page in a rolling seven-day time period.
220
Figure 6-4 Operations user view
6.1.2 The Ranking algorithm and categories

When viewing reports, you will notice that the last column in every view has a customer-associated number labeled Rank. Along with this, you may discover that dependent upon the view you are using, you have different choices to select from under the Category heading. These two Reports features are expanded upon in the following sections.
221
Understanding the ranking algorithm

When viewing the reports using any of the ranking categories, you will see that they are placed in order according to their rank. This ranking feature is compiled by an algorithm that prioritizes the SLA items using a number of variables, such as the number of violations, the number of trends, and the number of customer orders. The algorithm is defined below:
Ranking = (Mult1 + NumOfViolations) + (Mult2 + NumOfTrends) + CustOrders
Each variable of the ranking algorithm is defined below: Mult1 NumOfViolations Mult2 NumOfTrends CustOrders This weighting factor is set to 4000 for external SLOs, or 2000 for internal SLOs. The number of violations. This weighting factor is set to 3000 for external SLOs, or 1000 for internal SLOs. The number of trends. The number of customer orders.
Take for example the following scenario. A customer has six violations and two trends across a total of four customer orders with all external SLOs. The customer rank would be as follows:
Ranking = (4000 * 6) + (3000 * 2) + 4 = 30004
An SLO is determined to internal or external depending on whether or not during the service level objective configuration the particular metric was chosen to be included in the external customer reports. If the appropriate box was checked during the SLO configuration, the SLO is external; if the box was not checked, the SLO is internal. When ranking customer orders, the algorithm used is only slightly different, with CustOrders always equal to 1. Also, NumOfViolations and NumOfTrends is equal to the number of violations and trends associated only with that particular violation or order. Using the same scenario as described previously, with Order 1000 having three violations and one trend, Order 1001 having two violations and one trend, and Order 1002 having one violation and no trends, the customer order ranking would be as follows:
Order 1000 Ranking = (4000 * 3) + (3000 * 1) + 1 = 15001 Order 1001 Ranking = (4000 * 2) + (3000 * 1) + 1 = 11001 Order 1002 Ranking = (4000 * 1) + (3000 * 0) + 1 = 4001
222
Ranking categories
Each of the three default users created by Reports is associated with three separate, unique views. Depending on which of the three default users you log in with, you will have a different selection of ranking categories to select from when viewing the reports. Table 6-1 lists the available ranking categories for each default user.
Table 6-1 Users and associated ranking categories
User Category
Customer Executive
Customer Order Ranking Customer Ranking Customer Order Ranking Realm Ranking SLA Type Ranking
Operations
Customer Ranking Customer Order Ranking Offering Component Ranking Resource Ranking SLA Type Ranking Realm Ranking
Each ranking category details different information regarding customers and their orders. A definition of each ranking category is included below: Customer ranking Each customer, along with the associated number of trends and violations, are displayed. These are ordered in descending order according to their rank. For those logging into the executive.jsp page, this is the default view. Each customer order ID, customer, number of trends and violations, and rank are displayed by this category. The order IDs are listed in order of each orders rank. When logging into the customer.jsp page, this is the only ranking category available.
Customer Order ranking
223
Offering Component ranking Each offering component is listed separately, along with its associated violations, trends, and rank. This is the default ranking category when logging into the operations.jsp page. Resource ranking Each resource selected in an order is listed in this ranking, along with the associated violations and trends. The rank for each resource is calculated across all orders with which the resource is associated. Each SLA type (external, internal, and outsourced) is shown with the numbers of trends and violations associated with all the SLA types orders. They are listed according to their rank. Each realm is listed separately, along with the number of trends and violations for every customer and order belonging to that realm. Each realm is listed in descending order according to its rank, which is calculated for all customers and orders in the particular realm.
SLA Type ranking
Realm ranking
In Figure 6-5 on page 225 you see the ranking categories available for the default operations user. These ranking categories will be different depending on the default user you logged in with or the user roles you have been assigned.
224
Figure 6-5 Operations user ranking categories
6.2 Using Reports

After logging into Reports and exploring the different ranking category views, you are now ready to explore the different features of IBM Tivoli Service Level Advisor Reports. In the following sections you will learn how to effectively use Reports and how to utilize its many different features.
6.2.1 Reporting categories

When signing in to the executive.jsp or operations.jsp page, there are additional selections under the Category drop-down box. For the default executive user, there is only one additional selection, entitled Overall Report.
225
For the default operations user, there are three additional selections, as listed below: Trends Report Violations Report Results Report Overall Report A description of each report category is given below: Trends Report This report provides a wealth of information concerning all trends that have been detected. Not only does it display the breach value and its associated order resource, but this reporting category also shows the SLA type, customer and order id, the associated metric, schedule state, and the projected violation date, which predicts when another violation will occur. Figure 6-6 shows what this screen may look like.
226
Figure 6-6 Trends Report screen
Violations Report
The violations report displays the same type of information as the Trends Report, but focuses only on all violations received. There are a total of 11 columns containing violation-specific information, ranging from SLA Type and Metric to the Breach Value and Actual Value. A portion of the Violations Report screen is shown in Figure 6-7.
227
Figure 6-7 Violations Report screen
Results Report
This report category lists particular metric and order information according to the order ID. Information included in this report screen is the customer, order id, metric, resource, offering component, schedule state, offering, breach value, actual value, and error percentage. See Figure 6-8 on page 229 for more details on this screen. A collection of the above three reports.
Overall Report
228
Figure 6-8 Results Report screen
6.2.2 Viewing Reports using different search criteria

Using the different reporting categories will provide you with in-depth information concerning the status of your SLAs. But by using different search criteria, you will have the ability to locate your SLA information covering any time period, from the last 24 hours to the previous 365 days. Along with searching by time period, you may also search for results according to the configured SLA type. These areas are covered in detail in the following sections.
229
Specifying time periods

There are a number of time periods that can be selected when viewing Reports. The Time Period drop-down menu is located under the Filter Criteria heading near the top of the page. Figure 6-9 on page 231 shows a portion of the Time Period drop-down menu. The time periods available to select from are included in the following list: All Dates Today Yesterday Last Week Last Month Last Quarter Last Year Week to date Month to date Quarter to date Year to date Rolling 24 hours Rolling 7 days Rolling 4 weeks Rolling 30 days Rolling 365 days
230
Figure 6-9 Time Period drop-down menu
In order to select a specific time period with which to filter the search criteria, click the drop-down menu and select the desired time period. Those periods that include the term rolling are defined from the present time to the time period specified in the criteria. For example, if on Friday at 18:00 EST you specify Rolling 24 hours for your search criteria, the results starting from Thursday 18:00 EST to the present time will be displayed. After selecting the time period, the Go button to view the results.
Specifying SLA type

Aside from the time period, you may also search for results by filtering on the SLA Type. This drop-down menu is located to the right of the Time Period drop-down menu.
231
There are four selections to chose from when filtering on the SLA Type, as listed below: All Internal External Outsourced Figure 6-10 shows the SLA Type drop-down menu. After selecting the desired SLA type, click the Go button to view your results.
Figure 6-10 SLA Type drop-down menu
6.2.3 Additional features of Reports

There are a number of other features related to IBM Tivoli Service Level Advisor Reports that are included in the following sections. These features allow you to locate the desired results you are searching for more quickly and will also aid you in performing everyday tasks.
232
Using the Search field to locate specific results

When viewing results using the ranking categories, you may narrow your search to include only a specific customer or a particular customer order ID by using the Search field, located just above the report table. The search function is available for all ranking categories, with the exception of the SLA Type Ranking and the Offering Component Ranking categories. For example, when viewing results using the Customer Order Ranking category, you may further filter your results by including the order ID number in the Search field. After entering what you want to search for, click the Search button to return your results. Figure 6-11 shows how the Search field appears on the Reports page.
Figure 6-11 The Search field
233
Changing the number of displayed rows

When viewing results on the Reports page, a default number of 10 rows is displayed on the screen. If you have a large amount of customers, orders, or offering components, you may want to change the number of rows shown so that you are able to view them all on one page. The Web link entitled Maximum rows to display, located just above the report table, will enable you to perform this task. Click the number of rows you would like to display and wait for the screen to refresh. An example is shown in Figure 6-12 below.
Figure 6-12 Maximum rows to display feature
Using the provided Web links

There are three additional Web link features located in the upper right corner of the Reports page that allow you to perform various functions. The description of each Web link is given below: Print Tips When clicked, this Web link will open an additional Web page that provides you with useful printing tips when using Microsoft Internet Explorer. Click this Web link to refresh the current Reports page. If for any reason you would like to sign off from the current Reports page, clicking this Web link will sign you off and return you to the initial log on screen.
Refresh Sign Off
Figure 6-13 on page 235 displays the additional Web links.
234
Figure 6-13 Additional Web links
Using graphs in Reports

When using the Results Report category to filter your results, you will notice that the numbers located in the Actual Values column are highlighted as Web links. Clicking each of these values will take you to another screen containing graphical data related to the specific metric and value you selected. You may also change the time period associated with the graphical data by using the Time Period drop-down menu located just above the results table and graph. Figure 6-14 on page 236 gives an example of a graph for the ROUNDTRIPTIME metric in which the assigned maximum value has been violated. The time period for this graph was set to Last Month.
235
Figure 6-14 Report graph using Results Report category
Just below the graph is a Web link entitled Graph Data. By clicking this link you will be taken to another page displaying each evaluation time and related actual value associated with the metric you chose from the Results Report view page. Figure 6-15 on page 237 shows the page that is displayed by clicking the Graph Data link.
236
Figure 6-15 Graph Data page view
6.3 Administrating Reports users

It may become necessary for additional Reports users to be created, rather than having to rely on the default users provided during installation. In the following sections, you will learn not only how to create additional Reports users but also how to customize these users profiles to better suit your environment.
6.3.1 Creating Reports users

There are many options to choose from when creating Reports users. You may decide some users need access to all reports, covering all customers and realms. Other users may need to be restricted, so that they can only view reports dealing with a particular customer and realm ID. Additionally, external users may
237
be created to view only external data for a particular customer and realm. You may also change the users profile at any time via the command line. The information you need to create and change users is included in the following sections.
Using the command line to create a Reports user

You have many available options when creating a Reports user using the scmd sla addUser command. The syntax for this command is as follows:
scmd [ -p current_password] sla addUser -name user_name [-password password] -view {1 | 2 | 3} [-consumer consumer] [-realm realm] [-page page]
Each available option is described below: -p current_password -name name -password password If password protection has been enabled, you must supply directly after scmd to run this command. This is the user name you assign the user to log into the Reports page. Specifies the password for the user being created, or, if left blank, a password will be automatically generated and passed back to you. Each view is associated with a particular privilege for the user. View 1 allows unrestricted access to all viewable reports. View 2 provides restricted access, allowing only the viewing of specified customers and realms. View 3 provides external access to users, allowing the user to view only customers and realms specified whose data has been flagged as not internal. If no view is specified, the user will have no restrictions to viewing reports. Specifies an already defined customer whose reports the user will be allowed to view. If no consumer is specified, the user will be able to view reports for all customers specified in the -realm flag. If no consumer or realm is specified, the user will be allowed access to all customers and realms. An already defined realm ID is specified in this option. If no consumer is specified in the -consumer flag, using the -realm flag will allow the user to view all customers reports across this particular realm ID.
-view {1 | 2 | 3}
-consumer consumer
-realm realm
238
-page page
Specifies the page view to be used after successfully logging in. Three options are associated with this command flag: customer.jsp, executive.jsp, and operations.jsp. The operations.jsp page is used if no page is specified. Refer to 6.1.1, Default Reports users on page 219, for more information concerning the contents of these pages.
Using the command line to change a users access

There may come a time when you would like to change a users access privileges, whether it be allowing a user to view all reports or restricting the user to viewing only a certain customers reports in a particular realm. Whatever the case may be, the command syntax used to change a user contains the exact same flags as the scmd sla addUser command; only the initial command is different. The command syntax is as follows:
scmd [ -p current_password] sla changeUser -name user_name [-password password] -view {1 | 2 | 3} [-consumer consumer] [-realm realm] [-page page]
For more information regarding each flag, refer to Using the command line to create a Reports user on page 238.
6.3.2 Listing and deleting Reports users

Listing and deleting Reports users is simple using the command line. The following sections provide information on how to perform each of these steps.
Listing Reports users

Use the following command syntax to list all available Reports users. You must use the -p flag if password protection is enabled:
scmd [-p password] sla listUser
239
Example 6-1 displays what the command output may look like.
Example 6-1 scmd sla listUser command output
# scmd sla listUser name view consumer realm page -------------------------------------------------------------------------------------------customer unrestricted customer.jsp?fsd=mtd executive unrestricted executive.jsp?fsd=mtd operations unrestricted operations.jsp?fsd=r7d Sawyer restricted MyCompany Test customer.jsp Martir restricted MyCompany Test customer.jsp #
Deleting Reports users

Use the following command syntax to delete a Reports user:
scmd [-p password] sla deleteUser -name name
You must use the -p flag if password protection is enabled. You must also specify the user name of the user you would like to delete after the -name flag. For more information regarding the commands you have seen in this section, please refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
6.3.3 Disabling Reports user authentication

User authentication is turned on by default for IBM Tivoli Service Level Advisor. In order to turn this function off, there are a number of steps to perform, as listed below: 1. Before doing anything, you must stop the IBM WebSphere Application Server by issuing the stopServer command. 2. Locate and edit the web.xml file, which can be found in the following directories, depending on your WebSphere version: For IBM WebSphere Application Server AES and AE:
WAS_Dir/installedApps/SLMReport.ear/SLMReport.war/WEB-INF
For IBM WebSphere Application Server 3.5:

WAS_Dir/hosts/default_hosts/SLMReport/web
3. Add the lines in bold to the web.xml file, as shown in Example 6-2.
240
Example 6-2 Disabling user authentication

<?xml version= 1.0 encoding= UTF=8?> <!DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd> <web-app id=WebApp_ID> <display-name>SLM Report Servlets</display-name> <description>IBM Tivoli Service Level Advisor reporting servlets</description> <servlet id=Servlet_1> <servlet-name>slmReport</servlet-name> <servlet-class>com.tivoli.managed.gui.report.servlets.SLMReport </servlet-class> <init-param id=InitParam_1> <param-name>slm.configLocation</param-name> <param-value>d:/Tslm/cfg</param-value> </init-param> <init-param id=InitParam_2> <param-name>slm.logLocation</param-name> <param-value>d:/Tslm/log/SLMReport</param-value> </init-param>  <load-on-startup>5</load-on-startup> </servlet> <welcome-file-list id=WelcomeFileList_1> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app>
4. After saving and closing the web.xml file, restart the IBM WebSphere Application Server with the startServer command. For more information regarding disabling user authentication, refer to the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
241
6.4 Reports customization

IBM Tivoli Service Level Advisor provides the user the ability to customize the look and feel of Reports as needed. Even though Reports is ready for immediate use, customization may be desired in order to better suit a given environment. The following sections will address a number of Reports features that may be customized, including login, Reports appearance, and search components. For more information regarding the customization of Reports, refer to the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
6.4.1 Integrating Reports with existing Web sites

IBM Tivoli Service Level Advisor Reports can be viewed using its own set of Web pages or can be integrated into an existing customer Web site. The following sections will introduce you to the Java Server Pages (JSP files) that are utilized by Reports and will provide you with the information necessary to integrate Reports into your own Web site.
Reports and JSP files

In order to make the integration of Reports into a customers Web site easier, IBM Tivoli Service Level Advisor Reports uses Java Server Pages (JSP files). These files can be modified as needed by the user, dependent on the changes they would like to make. The files are located in the following directory path, where WAS_Dir is the installation directory of IBM WebSphere Application Server:
WAS_Dir/AppServer/installedApps/SLMReport.ear/SLMReport.war
Table 6-2 provides a list of the JSP files included with IBM Tivoli Service Level Advisor. This table can also be found in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
Table 6-2 Included JSP files
JSP file Description
graph.jsp custGraph.jsp opGraph.jsp index.jsp
Displays the bar graph linked to the Results Report. Input filters are available to restrict the data to specific metrics, offering components, customers, orders, offerings, metric value type (min., max, average), schedule, period, start and end dates, and SLA type (internal, external, outsourced). Displays the login screen and prompts the user for a user ID and password in order to access reports.
242
JSP file
Description
index2.jsp links.jsp custlinks.jsp execLinks.jsp periods.jsp
Java Beans-based user authentication. Displays the drop-down selection box at the top of most JSPs, enabling the user to jump from page to page by selecting it from the drop-down list.
Displays the drop-down selection box at the top of some JSPs, enabling the user to customize the time period for the report display. Displays the Report Details Report tables, including results, trends, and violations, all in one page. The custReportDetail.jsp and opCustReportDetail.jsp display five report tables: Order information Business schedule Service level objective results Violations Trends Displays the Results Report table. Determines the type of SLA: Internal, external, or outsourced. Displays the Trends Report table. Displays the Violations Report table. Create Web links in the upper-right portion of the Web page labelled Print Tips, Refresh, and Sign Off. Create category drop-down menus for different user roles. Category.jsp is for operations users, custCategory.jsp is for customer users, and execCategory.jsp is for executive users. Create drop-down lists for Time Period and SLA Type selection. Displays the filter values. The filterValues.jsp file is for all of the pages except the graph. The graphFilterValues.jsp file is used for the graph page only.
custReportDetail.jsp execReportDetail.jsp opCustReportDetail.jsp opReportDetail.jsp
resultsDetail.jsp slaTypes.jsp trendsDetail.jsp violationsDetail.jsp printRefreshOff.jsp category.jsp custCategory.jsp execCategory.jsp filterCriteria.jsp filterValues.jsp graphFilterValues.jsp
243
JSP file
Description
maximumRowsToDisplay.jsp
Displays the link enabling the user to specify the number of rows to display, such as 10, 20, 30, 40, or 50 rows at a time. Gets the filters passed in from the previous page and re-displays them when the user clicks Go next to the Category, Time Period, or SLA Type drop-down menus. Gets the filters and sets them into a session for the printRefreshOff.jsp file to use.
xxxFormRedirect.jsp
getFilters.jsp
Understanding and using the Report servlets

To integrate Reports into your existing Web site, you must actually embed the provided Report servlets into your HTML code. When doing this, there are a total of three servlets that will be imbeddedone main class named SLMReport, which calls the other two classes. One of the remaining classes issues a call to the database to retrieve the data and the other class will display the retrieved data for viewing. A JSP include statement will appear (as shown in Example 6-3) in the appropriate JSP file.
Example 6-3 JSP include statement
<jsp:include page=/servlet/com.tivoli.managed.gui.report.servlets.SLMReport ?qi=com.tivoli.managed.gui.report.servlets.SLMFilterRankQuery &di.com.tivoli.managed.gui.report.servlets.SLMFilterRankDisplay &filter=fco &link=custReportDetail.jsp &fontcolor=black &fontsize=2 &titlefontsize=2 &bgcolor=#EDEDEB &tablewidth=500 flush=true/>
If you are operating in a non-English environment, you should include the UTF-8 character set in the JSP, as shown below:
<%@ page contentType=text/html; charset=UTF-8 %>
As a side note, the include statement in Example 6-3 will appear in a single, continuous line, as opposed to the separate line format.
244
Directly under the first line in Figure 6-3, you will notice the next two lines begin with ?qi and &di. These two entries represent the query interface and display interface parameters, respectively. There are a number of parameters that may be substituted in their place, depending on the default view you prefer when viewing the results. Table 6-3 lists the available query and display classes. This table may also be found in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
Table 6-3 Available query and display classes
Query class Display class Link needed?
SLMResultsDataQuery SLMViolationsQuery SLMTrendsQuery SLMResultsQuery SLMResultsQuery SLMFilterRankQuery SLMOrderInfoQuery SLMScheduleDataQuery
SLMResultsDetailTable SLMViolationsDetailTable SLMTrendsDetailTable SLMResultsGraph SLMGraphDetailTable SLMFilterRankDisplay SLMOrderInfoTable SLMScheduleDetailTable
Yes No No No No Yes No No
For the classes with a Yes in the Link Needed? column, you must use a link parameter (in Example 6-3 on page 244), which will specify which Web page or JSP file will be visited next. An example of this link parameter follows:
&link=custReportDetail.jsp
As shown in Figure 6-3 on page 244, the SLMFilterRankQuery and SLMFilterRankDisplay classes were used, which display the trends, violations, and ranking of each customer. This results listing is specified in the filter=fco line, directly below where the display class is specified. You may change this value if you wish to use other filters instead of the customer filter. The following are the filters that you may choose: fcu fst fco frn fslatype fsrc
245
Table 6-4 on page 246 includes the complete list of filters. This table can also be found in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
Using different filtering parameters

Numerous filtering parameters may be used when querying the ITSLA Database. Use of a particular filter will display data, if desired, for specific customers, orders, resources, metrics, and other areas. For example, when using the executive.jsp file, the fcm filter parameter is used when searching on a particular customer. A portion of the executive.jsp file is included in Example 6-4.
Example 6-4 The fcm filter specified in the executive.jsp file
<form action=servlet/com.tivoli.managed.gui.report.servlets.SLMFilterSearch method=GET> <%=rsc.getString(CustomerSearchRequest)%><br> <a href=executive.jsp?<%rowViewParam%>><%=rsc.getString(Customerviewall) %> </a><br><br> <LABEL for=execCustomerSearch><%=rsc.getString(CustomerSearch)%></LABEL> <tr><td valign=top><font face=Arial size=2> <input type=text name=fcm size=22 id=execCustomerSearch> <input type=submit value=<%rsc.getString(Search)%>> </form>
When searching on a particular customer, this search will query the database using the fcm parameter. Table 6-4 lists all available filter parameters. This table can also be found in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
Table 6-4 Available filter parameters
Filter parameter Parameter name
Customer Customer order Metric name Resource Offering component Schedule state Service offering Start date End date
fcu fco fmn frsc fst fss fso fsd fed
246
Filter parameter
Parameter name
Customer match (searching) Resource match Customer order match Offering component match SLA type match Realm match Value type SLA type Filter (used in customer.jsp, executive.jsp, operations.jsp, and all filterRanking.jsp) Realm name
fcm frscm fcom focrm fslam frm fvt (min=1; avg=2; max=3); for example, fvt=3 fslatype (external=1; internal=2; outsource=3; all=0) filter (available values: fcu, fco, fst, fslatype, frn, frsc)
frn
Implementing the Refresh feature

If you would like to include the Refresh feature in your own Web site, use the HTML code shown Example 6-5 when placing it in the printRefreshOff.jsp file:
Example 6-5 Refresh feature
<table width=100% border=0 cellspacing=0 cellpadding=0> <tr><td width=99% valign=bottom align=right><font size=2 face=Arial> <a href=printTips.jsp target=blank><%=rsc.getString(PrintTips)%></a>  <! -- For refreshing, pass in the filters to keep the same query. Do not pass in the page parameter so that the servlet will know that it needs to go to the database again. --> <a href=<%=currentPage*?*filters*allRowViewParams.toString()%>> <%=rsc.getString(Refresh)%></a>
When clicking the Refresh link, a query is reissued against the database, causing the information in the results table to be updated.
Integrating the Logout link

You may include the Logout link in your Web site, which the user can use to log out of the current Reports session. Refer to Example 6-6 to include this link.
247
Example 6-6 Example of the Logout link

<a href=servlet/com.tivoli.managed.gui.report.servlets.SLMLogout ?link-../index.jsp&tablewidth=450><%rsc.getString(SignOff)%></a> <td width=l%><br>
It is very important to include the link to the index.jsp page in the above code, as when invoking the Logout servlet, the current session will be invalidated. The index.jsp directory path is relative to the location of the servlet directory.
Integrating the Search function

Users have the ability to search for certain components, such as customers, orders, realms, or resources, in some of the JSP files. By passing the SLMFilterSearch class, the search HTML form can be found in the executive.jsp file, as shown in Example 6-7.
Example 6-7 Using the Search function
<table border=0 width=600 bgcolor=#C6D1DC cellpadding=3 cellspacing=0> <tr><td><font face=Arial size=2> <form action=servlet/com.tivoli.managed.gui.report.servlets.SLMFilterSearch method=GET> <%=rsc.getString(CustomerSearchRequest)%><br> <a href=executive.jsp?<%=rowViewParam%><%=rsc.getString(Customerviewall) %></a> <br><br> <LABEL for=execCustomerSearch><%=rsc.getString(CustomerSearch)%></LABEL> <tr><td valign=top><font face=Arial size=2> <input type=text name=fcm size=22 id=execCustomerSearch> <input type=submit value=<%=rsc.getString(Search)%><> </form>
As you may notice, fcm is defined for the Input field name, which means that a customer will be searched for. There are additional field names that may be specified when implementing this search function. Table 6-5 shows the available field names. You may also find this table in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
Table 6-5 Available input field names for searching
Searching for Input field name
Customers Resources Customer orders
fcm frscm fcom
248
Searching for
Input field name
Realm names
frm
Using maximum rows to display

As shown in Figure 6-12 on page 234, the Reports results table includes a feature that allows the user to display a chosen number of rows per page. These settings are set in the maximumRowsToDisplay.jsp file, as shown in Example 6-8.
Example 6-8 The maximum rows to display Java code
<%0 page contentType=text/html; charset-UTF-8 %> <%0 page import=com.tivoli.managed.gui.repot.servlets.SLMReportJSPResources%> <%0 page import=java.utilResourceBundle %> <%0 page import=com.tivoli.managed.gui.report.servlets.SLMReportData %> <jsp:include page=getFilters.jsp flush=true/> <% //Get the current page name String currentPage = request.getParameter(page); String rowStr = request.getParameter(row); String valueType = request.getParameter(fvt);//for graph pages String rowView = null; //get filters SLMReportData repData = (SLMReportData)session.getAttribute(filters); String filters = null; if(repData != null) filters = repData.getFilters(); if(valueType != null && !valueType.equals(**)) filters = filters + &fvt=+valueType; //resources ResourceBundle rsc = null; if (rsc == null) rsc = ResourceBundle.getBundle(com.tivoli.managed.gui.report.servlets. SLMReportJSPResources, request.getLocale()); //Get row view if(rowStr != null){ rowView = request.getParameter(rowStr); } //display maximum row numbers int lastRowView = 50; int rowViewInt = 10; if(rowView!=null)
249
rowViewInt = Integer.parseInt(rowView); for(int i=10; i<=lastRowView; i=i+10){ if(rowViewInt==i) out.println(<font size=2 face=Arial color=black>+i+</font> |); else out.println(<a href=+currentPage+?+filters+&+rowStr+=+i+>+i+</a> |); }//end for
You can call the maximumRowsToDisplay.jsp file from a main page, such as opCusotmerRanking.jsp, as shown below:
<jsp:include page=maximumRowsToDisplay.jsp?page=opCustomerRanking.jsp&row=rrow flush=true/>
This includes the available parameters to control the maximum number of rows to be displayed for various reports. This table can also be found in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
Table 6-6 Available parameters for maximum rows to display
Row parameter Defined parameter name
Result Reports Trend Reports Violations Reports Graph Cusotmer, order ID, resource, realm, SLA type, and offering component
rsltrow trndrow viorow grow (for graph data table) rrow
6.4.2 Customizing the appearance of Reports

There are many different options available when customizing the appearance features of the IBM Tivoli Service Level Advisor Reports. Whether you would like to include your own company logo or change the appearance of certain Reports buttons, the follow sections help you change the appearance of Reports to your liking.
250
Using your own company logo

If you would like to replace the graphic that is provided at the top of the Web page with your own company logo, replace the SLMbanner1.gif line in Example 6-9 with the name of your own graphic image.
Example 6-9 HTML code for inserting a company logo
 <table width=1000 height=78 border=0 cellspacing=0 cellpadding=0> <tr><td align=top><img src=SLMbanner1.gif alt=Banner> </table>
Back and Next button substitution

You have the option to change the appearance of the Back and Next buttons in Reports. Replace the backButton.gif and nextButton.gif files with the graphic files of your choosing, but keep the file names the same.
Changing the appearance of the Reports results table

When viewing the Reports results, the actual results are organized within different columns in a table. The names of these columns and the order in which they are displayed is controlled by a single Report servlet. You may alter the names of these columns by including the new parameter name in the customer.jsp file. Table 6-7 includes the label parameters matched with their associated parameter names. You can also find this table and related information in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
Table 6-7 Customizable table column parameters
Label parameter Parameter name
Customer Order ID Metric Resource Offering component Schedule state Offering Detection date Projected violation date
lcu lco lmn lrsc lst lss lso ldd lpvd
251
Label parameter
Parameter name
Breach value Violation value Violation date Mean value Graph Projected state State Number of trends Actual value Max (maximum metric value type) Avg (average metric value type) Min (minimum metric value type) %Error (confidence factor) Evaluation time SLA type Realm Rank Number of violations Internal use only Start time End time Frequency Time zone Details Units
lbv lvv lvd lmv lg lps ls ltn lmav lmax (such as max in the results report under the Metric Value column) lavg lmin lcf lget lsla lrn lrk lvn liu lstt lett lfq ltz lsd lmu
252
If you would like to change the Customer column heading to My Customer, locate the customer.jsp file and at the bottom of the page, under the !----insert servlet below----- heading, edit the lines seen in bold in Example 6-10.
Example 6-10 Changing the default column name
<jsp:include page=/servlet/com.tivoli.managed.gui.report.servlets.SLMReport ?qi=com.tivoli.managed.gui.report.servlets.SLMFilterRankQuery &di=com.tivoli.managed.gui.report.servlets.SLMFilterRankDisplay &filter=fco &link=custReportDetail.jsp &fontcolor=black &fontsize=2 &titlefontsize=2 &bgcolor=#EDEDEB &tablewidth=500 &lcu=My+Customerflush=true/>
Denote a space in the changed column name with the + symbol. In addition to changing the names of the columns, you may also change the appearance of the actual results table. Whether you would like to change the font size, the font color, or even the table cell spacing, you may add these values to the same line in the customer.jsp file as shown in Example 6-10 on page 253. Table 6-8 gives a listing of the available table properties that may be changed.
Table 6-8 Customizable table properties
Table property Parameter specified Default value
Table background color Font size Font color Font face Title font size Title font color Title font face Title background color Table width Table border Table cell spacing
bgcolor fontsize fontcolor fontface titlefontsize titlefontcolor titlefontface titlebgcolor tablewidth border cellspacing
#EDEDEB 2 Black Arial 2, always bold Black Arial #CFDAE3 100 percent 0 2
253
Table property
Parameter specified
Default value
Table cell padding
cellpadding
Follow the same convention as used in Example 6-10 on page 253 by using the & character to separate each property to append. Each separate line is actually contained within one long continuous line in the customer.jsp file, so the & character must be used to space each parameter entered, as shown below:
&fontcolor=blue&cellspacing=0&tabelwidth=450
This information and more can be found in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
Changing the appearance of the data graphs

Just as you may change the appearance of the Reports results table, you may also alter the appearance of the data graphs that are displayed when selecting certain metric data from the Results table. Locate the graph.jsp file and follow the same alteration format as described previously by using the & character to separate each additional entry. Alterations to the graph are made under the !-------Graph Chart --------- section in the graph.jsp file. Table 6-9 displays the graph properties that may be customized.
Table 6-9 Customizable graph properties
Customized property Parameter for the property
Chart area background Plot area background Chart background Legend visible Header text Graph encoder Grid visible Grid color Chart type Chart height
chartAreaBg (for example, chartAreaBg=blue) plotAreaBg (color name only) chartBg (color name only) legendVisible (true or false; for example, legendVisible=true) headerText (name of header; for example, headerText=graph+title) ge (png or jpeg) gridVisible (true or false) gridColor (color name only) data1ChartType (area, bar, plot) chartHeight (integer; for example, chartHeight=400)
254
Customized property
Parameter for the property
Chart width
chartWidth (integer)
There are a total of 13 colors to choose from when changing the graph properties. Below is a list of these colors, as also listed in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835: Black Blue Cyan Dark gray Gray Green Light gray Magenta Orange Pink Red White Yellow
6.4.3 Alternative methods for authenticating users

If you already have a user authentication method set up for your Web server, you can use a Java Bean to authenticate your users. If this is the case, the ITSLA Database will not be used for this purpose, and it will be up to you to determine how each user is matched with the appropriate view, consumer, portal page, and realm. In order to use a Java Bean for user authentication, perform the following steps: 1. With the user currently logged on to the Web server, provide the view, consumer, portal page, and realm values to the Java Bean. 2. Call the SLMBeanAuthentication servlet class by creating an HTML form button called View Reports. This form will maintain the appropriate level of user access while the user is signed in by using the view, consumer, portal page, and realm properties for user access control. You can find examples of these customization steps in the index2.jsp file, which is shipped with IBM Tivoli Service Level Advisor.
Setting authentication values in a Java Bean

The user authentication values can be set in a Java Bean by following the sample code provided in Example 6-11.
255
Example 6-11 Sample code for setting user authentication values

<jsp:useBean id=Login class=com.tivoli.managed.gui.report.servlets.SLMUserInfoImpl scope=session /> <jsp:setProperty name=Login property=consumer value=<%=consumer%>/>  <jsp:setProptery name=Login property=realm value=<%realm%>/> <jsp:setProtpery name=Login property=view value=<%view%>/> <jsp:setProperty name=Login property=portalPage value=<%=portalPage%>/>
In this example, the SLMUserInfoImpl class is called and passes the values for consumer, realm, portal page, and view. To set the property directly without using a variable, follow Example 6-12.
Example 6-12 Setting the property directly
<jsp:useBean id=Login class=com.tivoli.managed.gui.report.servlets.SLMUserInfoImpl scope=session/> <jsp:setProperty name=Loginproperty=viewvalue=restricted />
Sample code for HTML form button

In order to create a View Reports button, follow the code in Example 6-13.
Example 6-13 Creating a View Reports button
<FORM action=servlet/com.tivoli.managed.gui.report.servlets.SLMBeanAuthentication method=POSI> <INPUT type=submit name=submit value=<%rsc.getString(ViewReports)%>> </FORM>
When this button is clicked, the user names authentication values will be passed to the Java Bean and the authentication level for that user will be set for the current session. Whatever reports page is specified by the customer will then be displayed.
256
6.5 Viewing Reports with third-party software

If you would like to view IBM Tivoli Service Level Advisor Reports results in a different viewing format than the one provided, there are a number of third-party reporting applications that can be used. By inserting different tables, graphs, and executive summaries into your report, you will be able to better understand how your IBM Tivoli Service Level Advisor environment is functioning. The following sections will introduce you to several third-party applications that the Redbooks team used and will provide you with examples of each. Before continuing, you must know that there are three default views provided by Reports for viewing results with the desired third-party software. These views are as follows: Resultview: Uses SLO results information to build a report. Violationview: Uses information gathered from all violations to build a report. Trendview: Trend-related information is used to build a report. The three third-party applications that were used for this redbook were BrioQuery Designer, Seagates Crystal Reports, and BusinessObjects. As a general rule, if you are not currently using one of these three applications, refer to the following: 1. Create a connection through your software to the ITSLA Database (DYK_CAT). 2. When asked to select the components to include in your report, select of the three views discussed previously, as shown in the list below: Resultview Violationview Trendview 3. If you chose the Resultview, you may notice a component in that view labeled Evaluator Type. An average of all the average values is shown if the evaluator type is set to 4; if the evaluator type is 5, then you are viewing a sum of all the average values. 4. Using the desired format, create the report.
6.5.1 Using BrioQuery Designer with Reports

There are a number of options you may choose from when using BrioQuery Designer to create and view your reports. In the following sections, you will learn about the different features offered by BrioQuery Designer and how to create reports by using this tool.
257
Note: For the following sections, we used Brio Enterprise Version 6.0. BrioQuery Designer is just one component of the Brio.Enterprise package. Additionally, this section of the redbook is not meant to be used as a concise informational resource for the Brio product. For more information regarding your level of Brio products, please refer to the appropriate documentation that was shipped with the product.
Required steps before report creation

Before actually creating your report, there are a number of steps that must be performed. You must first create a connection to the DYK_CAT database, choose one of the available three views you wish to include in the query, and finally process that query so that you can create a report from its results. Each step is expanded on in the following sections.
Creating a database connection

The following steps describe how to create a database connection. 1. When first starting BrioQuery Designer, you will be presented with a screen asking you if you would like to create a new document or work with an existing document. Under the Create a New Document section, select the A New Database Connection File radio button and click OK. 2. The Database Connection Wizard will appear on the next screen, as shown in Figure 6-16. Assuming that you already have an ODBC connection to the ITSLA Database (DYK_CAT), under the What connection software do you want to use? section, select ODBC from the drop-down menu. Directly under that, in the What type of database do you want to connect to? section, choose DB2 from the drop-down menu and click Next.
258
Figure 6-16 BrioQuery Database Connection Wizard
3. The next screen will ask you to connect to the data source. You must supply the fields with your DB2 user name and password, along with the database you would like to connect to, which in this case will be DYK_CAT. The database selection is located in the Host drop-down menu, and the selections are chosen from your ODBC connection information. Click Next to continue. 4. The Meta Connection Wizard screen appears next and asks you to choose between opening the wizard on the current connection or using a different connection. The On the Current Connection radio button is selected for you as default. Click Next. 5. Accept the defaults on the next screen and click Next. The last screen will ask you to click Finish to save your settings as a connection file, which can be modified later if desired. This file is saved with a .oce extension. Click Yes when it asks if you would like to save the settings, and name the file something recognizable so that you will not forget later.
Choosing a view and query processing

After saving the database connection file, the Query screen will appear, as shown in Figure 6-17.
259
Figure 6-17 Query screen for DYK_CAT
In the bottom left-hand corner, you will notice an expandable section labeled Tables, which contains all the tables located in the DYK_CAT database. Click the + sign to expand this section. Scrolling through the tables will reveal the three views described in Viewing Reports with third-party software on page 257. These views are located near the bottom of the selections. Follow the steps below to choose a view and to query that process. 1. Select either Resultview, Trendview, or Violationview and drag it to the Content window, as shown in Figure 6-18.
260
Figure 6-18 Dragging Violationview to the Content window
2. After dragging the view (which is now considered a Topic) to the content window, you should see a list of items related to that view. As shown in Figure 6-18, there are 17 items related to the Violationview. Right click in the top of the view where the view name is located and select Add Selected Items. Each item located in the views list will appear at the top the screen in the Request section, as shown in Figure 6-19 on page 262. You can right click each of these items in the Request section and remove them if you do not want to include them in the query. Note: After adding all the selected items, we also added the Val item again to prepare for the chart we will create later. This item will appear as Val2 in the Request section at the top of the page. Reasons for doing this will be explained in Creating a graph on page 266.
261
Figure 6-19 Adding the selected items
3. If you would like to limit the information that will later be processed in the query, select the item in the views list, right click, and select Limit. You will then be presented with a Limit box for the item you selected. In this window, click the Show Values box to list the values associated with the selected item. For example, in Figure 6-20 on page 263 we only want to see the violations for one customer. After selecting and right clicking the Consumer Name item, we clicked the Show Values box to list the customers who have violations. From the list of customers, we selected the Home Banking customer so that only their violations will be processed in the query. After clicking OK, you should see in the top right-hand corner of the page the Limits link now appearing as Limits(1). You can click this link to display all the limits you have selected.
262
Figure 6-20 Limiting the items for query processing
4. You are now ready to process the query. At the top of the screen in the toolbar, click the Process button. After the processing has completed, you will receive a screen similar to the one shown in Figure 6-21 on page 264. There are a number of features to point out concerning this screen. The results from your query will be displayed in the Contents window. You can view all items that were included in the query in the bottom left-hand corner of the screen under Query. Under Sections in the upper left-hand corner of the screen, you can toggle between the Query and Results views by clicking each. If you would like to limit your query even more, do so from the Query section. If you feel that you did not limit your query sufficiently before processing, in the Results section click inside the column you wish to limit, right click, and select Limit. You can then choose which values you wish to show in your report, as described in step 3 on page 262. You can also select the entire column and remove the ones you do not wish to view.
263
Figure 6-21 Query results for limited Violationview
Choosing and creating your report

After the query has been processed, you are now ready to choose the type of information that will be included in your report. At the top of the screen, clicking the Insert menu will provide you with a list of tools you can to use to compile a report. In this example, we will be creating a report on IBM Tivoli Business Systems Manager (TBSM) violations received for the Home Banking customer, which will include a report table and a vertical bar graph.
Creating a report table

Perform the following steps to create a new report.
264
1. To create your report, click the Insert menu at the top of the screen and select New Report. A screen similar to the one shown in Figure 6-22 will appear. Notice that in the upper left-hand corner of the screen under Sections, a Report section has appeared.
Figure 6-22 New report screen
2. In the bottom left-hand corner of the screen you will see all the items listed from the query results. Drag the items you would like to include in the table to the appropriate panels at the bottom of the screen labeled Report Group1, Table Dimensions, and Table Facts. In our example, we chose to include the Consumer Name for Report Group 1, along with Metric Name, Viol Date, Val, and Breach Avg Val for the Table Dimensions. This table will include TBSM LOB state green metric violations received for the week of 04/23/02 for the Home Banking customer. Figure 6-23 on page 266 displays the resulting table.
265
Figure 6-23 Report results table
3. You may add any number of results items to the panels at the bottom of the screen. Any item added to the Table Facts panel will result in an additional row placed at the bottom of the table displaying an arithmetic function of that item. For example, you could include a sum of all Violations received or an average of the breach values. For our example, this was not necessary.
Creating a graph
You can also choose to include a graph in your report. For our example, we will construct a bar graph that corresponds with the values located in the report table that we just created. The steps needed to create a graph are listed below. 1. Click the Insert menu at the top of the screen and select New Chart. You will be taken to a blank screen with three panels located at the bottom labeled Y-facts, Z-categories, and X-categories. A Chart section will also appear in the upper left-hand corner of the screen under Sections.
266
2. You will find that creating the graph is similar to creating the report table, by dragging the items listed in the bottom left-hand corner of the screen to the appropriate panel. For our example, we placed Val in the Y-Facts panel, with Viol Date and Val2 in the X-Categories panel. Figure 6-24 displays the result.
Figure 6-24 Two-dimensional graph
Tip: Be sure to place an item with a value in the Y-Facts panel. Items placed in this panel will provide the bars with their values. The main reason a second Val item was added to the query was so that we could have one Val in the Y-Facts panel, while Val2 provides the violation values on the X axis. This is not necessary, but it helps add more description to the graph.
267
3. The graph can also be made to appear three-dimensional by adding an item to the Z-Categories panel. In Figure 6-25 we added the Val2 item to make the graph three-dimensional.
Figure 6-25 Three-dimensional graph
4. You can add text to the graph by double clicking each title. For example, when a graph is initially created, the title Chart will appear at the top the page. Double click this title and add the desired text in the text box. You can do this for each title that appears in the contents window. 5. The type of graph that is created can be changed by clicking the Format menu at the top of the page and selecting Chart Type. From there you can choose from a number of different types of charts.
Including a graph into the report

After you have finished constructing your graph, you may now integrate it into your report. Perform the following steps to add your graph to the report page.
268
1. Select the Results view under Section in the upper left-hand corner of the page. 2. In the Query box located in the bottom left-hand corner of the screen, scroll down until you notice an icon labeled Chart. Select Chart and drag it to the Contents window, directly under the reports table you created earlier. If the chart seems too small, you may resize it by clicking it and pulling the handles to the desired width and height. Double clicking the graph will take you back to the Chart view where you can make additional changes to the graph. These changes automatically show up in the Reports view. 3. You can now save and print the file. Each BrioQuery file will be saved with a *.bqy extension.
6.5.2 Viewing Reports using Seagate Crystal Reports

Seagate Crystal Reports provides you with the ability to include a number of different report and chart types to help enhance the viewing of your IBM Tivoli Service Level Advisor results.
Creating a report
The reporting format used by Crystal Reports is much different from the format implemented by BrioQuery and BusinessObjects. Included in this section are required steps to begin creating your report. Note: For our examples, we used Seagate Crystal Reports Version 7 Professional. If you are using a different version or need more information than what is supplied here, please consult the product documentation. 1. Open the Report Designer and click the New icon in the top left-hand corner of the screen. A screen labeled Report Gallery will open, providing you with a list of report experts that will help you design your report. Click the Custom button in the bottom right-hand corner of the screen. This will open another panel, shown in Figure 6-26 on page 270, allowing you to choose from different custom reports and data types. Click the SQL/ODBC button.
269
Figure 6-26 Report gallery with Custom button selected
2. The Log On Server box appears, from which you will need to choose the DYK_CAT ODBC data source and click OK. The contents of this window include sample sources created by Crystal Reports, along with the ODBC data sources you have defined on your machine. 3. If you have not already set up a connection to this database, you may be prompted for a user name and password. After entering these, the Choose SQL Table screen will appear. From this list you may choose one of the three views as described in 6.5, Viewing Reports with third-party software on page 257. For our example, we will choose the Violationview, as shown in Figure 6-27 on page 271. Click OK after choosing your view.
270
Figure 6-27 Choose SQL Table window
4. An Insert Fields box will appear in front of the report design page. Choose as many fields as you would like, and drag them to a position on the Report Design page. When dragging the fields, place them in the Details section of the page, as shown in Figure 6-28 on page 272. Their names will also appear in the Page Header section, which will appear as column headings after building the report. Click Close after inserting the desired fields.
271
Figure 6-28 Insert fields and report design page
5. You may adjust the section in the design page as necessary to make more or less room for the fields you just inserted. If you prefer to include only information for one customer or violations just for a specific day, select the field you just inserted, right click and choose Select Expert. In this box, as shown in Figure 6-29 on page 273, you have a wide variety of options to choose from when limiting your data. For example, if you would like to include only violations that were received over the weekend, choose the is one of option from the drop-down menu and then choose your dates in the second drop-down menu that appears. You may even choose other fields to limit by clicking the New button.
272
Figure 6-29 Select Expert being used to limit the violation dates
6. If you would like to place text in any of the other sections of the report, such as in the report header or report footer, you can use the text object feature by either clicking the icon in the toolbar (ab) or by selecting Insert -> Text Object. Drag the text box to the section where you would like to place the text. If your design page is now set up the way you want it, you can view a preview of your report by clicking the lightning bolt in the toolbar or pressing the F5 key. When you do this, a new tab will appear in the top left-hand corner of the design page, labeled Preview. Click this tab to see a preview of your report. An example is shown in Figure 6-30 on page 274.
273
Figure 6-30 The preview screen
7. If you do not like the way the data appears in the preview screen, you can go back to the design tab and readjust the columns. After making changes, refresh the data each time for your changes to take effect.
Building a chart
After refreshing the text portion of your report, you can now insert a chart. Follow the steps listed below to begin building a chart. 1. Click the Chart button in the toolbar or select Insert -> Chart. 2. The Chart Expert screen will appear, as shown in Figure 6-31 on page 275. From this screen you can choose from a variety of charts to insert. For our example, the bar chart was chosen.
274
Figure 6-31 Chart Expert box
3. There are five tabs located in the Chart Expert box. After selecting the type of chart you would like to use, click the Data tab to select what data you would like to include in your chart. Figure 6-32 on page 276 shows the Data tab of the Chart Expert box. To select the data to include, click the available field and click the arrow to the right of the box, depending on where you would like to move the field. The top box on the right side of the Data tab represents the X-axis. Data that is placed here should represent a category, such as consumer name or violation date. There is also a drop-down menu just above the box that provides you with two options: On change of and For each record. These selections determine how your values are plotted in the chart. For our example, we chose Consumer_Name and Viol_Date. The bottom box, labeled Show Value(s):, represents the Y-axis. Data that represents a value should be placed in this box. For our example, we chose Val, the violation value for average. If you do not want the data to be summarized, select the field you placed in the box and place a check-mark in the Dont summarize values box.
275
Figure 6-32 The Data tab
4. On the Axes tab, you can decide how the chart displays each axis in terms of gridlines, data values, and number of divisions. 5. On the Options tab, chart customization features are displayed, allowing you to change the chart color, the way the data values are displayed, and the visibility and placement of the legend. The legend is useful when using dates for the data points. 6. You can add titles, subtitles, and footnotes to your chart on the Text tab. 7. After configuring your chart, click the OK button in the Chart Expert to view a preview of your chart. If you do not like the way it appears, you can right click the chart and go back to the Chart Expert to change the data values. A preview of our example appears in Figure 6-33 on page 277.
276
Figure 6-33 Report preview screen
8. You will notice on the Design tab, that the chart is automatically placed in the Report Header section. If you would like to place this chart somewhere else, drag the chart to the desired section. You may need to resize the sections if this is the case.
6.5.3 Using BusinessObjects with Reports

The BusinessObjects product used in the IBM Tivoli Service Level Advisor environment is useful in consolidating the SLA violation data in an elaborated report form. In this section we provide some examples of how to integrate the BusinessObjects User module technology with IBM Tivoli Service Level Advisor data. The BusinessObjects platform allows you to elaborate the IBM Tivoli Service Level Advisor data in such a way to personalize the information to be used at different levels in the enterprise.
277
Business Object integration with ITSLA

In order to integrate the BusinessObjects product with IBM Tivoli Service Level Advisor you have to create a BusinessObjects Universe. A Universe is a business-oriented mapping of the data structure found in databases, such as tables, columns, and joins, and can represent any specific application, system, or group of users. In the BusinessObjects User module, Universes enable end users to build queries from which they can generate and perform analysis and reports. Therefore, it is important to build the Universe in such a way as to obtain all the data needed to create the desired reports.
Creating a Universe
The following steps describe Universe creation: 1. In the Windows environment, select Start -> Programs -> BusinessObjects 5.1 -> Designer. 2. Click the Quick Design Wizard icon on the control bar. The Quick Design Wizard screen opens. Click Begin.
Figure 6-34 Define Universe Parameters window
278
3. The Quick Design Wizard - Step 1 of 4 window opens, as shown in Figure 6-34. In this dialogue window you have to enter the Universe name (we chose the name Report for SLA Violations) and choose an existing database connection or create a new one. We created a new connection to the ITSLA Database (DYK_CAT), which contains the SLA violations data. To create a new connection, perform the following steps: a. Click New. b. From the Add a Connection dialogue window, Select the IBM DB2 CAE network driver and click OK to define the parameters for the connection. Note: In our case, BusinessObjects is installed on the same machine where the ITSLA Database is located. View the BusinessObjects documentation for information regarding the software and configuration requirements for the connection to the database.
Figure 6-35 Parameters of database connection window
c. The IBM DB2 CAE window opens, as shown in Figure 6-35. Supply the following fields with the relevant connection information for the ITSLA Database: Choose a name for the connection.
279
From the Database engine drop-down menu select DB2 UDB v7. Insert the user name and the password of an administrative user of the ITSLA Database (we chose the user db2admin). Select DYK_CAT from the Data source name field and click Test to test the connection. If the connection is successful, click OK.
Figure 6-36 Second step of Universe creation process
4. Click Next. The Create Initial Classes and Objects window opens, as shown in Figure 6-36. In this step you select the tables, views, and columns that you want to use for your reports. After expanding the DB2ADMIN folder, click RESULTVIEW, TRENDVIEW, and VIOLATIONVIEW. These views contain the violation and trend data for ITSLA. Click Add>> to choose the tables as Universe classes and objects. Click Next. 5. The Create Measure Objects window opens. In this step you are asked to create calculations (called measure objects) that will be useful in defining and creating your report. For example, if you want to know the number of violations of the maximum value defined for the Service Levels Objectives, do the following steps: a. In the VIOLATIONVIEW table, select the MAX_VAL column. b. Click Count>>. c. On the left side of the window, the measure object Number of Max Val displays.
280
d. Create as many measure objects as your report requires. We chose to also insert the measure object Number of Val. 6. Select Next and then click Finish to complete the Universe creation.
Report creation examples

In the following sections, we will create two example reports using BusinessObjects, which will show the capability of the BusinessObjects/ITSLA integration.
First example
For our first example, we would like to find out how many violations for a service level objective maximum value per customer occurred since the beginning of the service. The production of this report is achieved through the following steps: 1. Open the BusinessObjects interface, selecting Start -> Programs -> BusinessObjects 5.1 -> BusinessObjects. The BusinessObjects window opens, and the create reports wizard automatically starts. 2. Choose the Generate Standard Reports radio button and click Begin.
Figure 6-37 Select Universe as data access
281
3. The Specify Data Access window opens, as shown in Figure 6-37. In this dialogue window you specify in which way you would like to access the data. We chose to access the data by using the Universe we just created. 4. The Select Universe dialogue window opens. We select the Report for SLA violations Universe that we created in Business Object integration with ITSLA on page 278. Click Finish.
Figure 6-38 Query Panel - Report for SLA violations Universe
5. The Query Panel of the chosen Universe displays, as shown in Figure 6-38. The Query Panel allows you to build the SQL queries to access data. You can find the classes and objects of the Universe on the left-hand side of the screen. 6. Expand the Violationview folder, select the Consumer Name and Viol Date objects, and double click them. Expand the Reports for SLA violations Measures folder, select Number of Max Val calculation, and double click it. Note: Number of Max Val is the calculation defined during the Universe creation, and it is the number of violations of a maximum value set for the service level objectives.
282
7. Click Run. The BusinessObjects default report displays, as shown in Figure 6-39 on page 283.
Figure 6-39 Business Object Report for max violations
8. To customize the report, right click Report 1 in the lower left-hand side of the window and select Apply Templates, as shown in Figure 6-40 on page 284.
283
Figure 6-40 Apply templates to report
9. When the Apply a Template window opens, you must select one of the templates. The BusinessObjects product allows you to easily customize the graphics. We have obtained, with some customization, the report shown in Figure 6-41 on page 285.
284
Figure 6-41 BusinessObject customized report
The created report can be saved in a BusinessObjects format, an HTML document, or as a PDF file.
Second example
In this example, we show how to obtain a report for a single customer, focusing on which component (in the customer order) has the highest number of SLA violations. Execute steps 1 through 5 from the previous First example on page 281. The Query Panel displays, as shown in Figure 6-38 on page 282. Execute the following steps to customize the report: 1. Expand the ViolationView folder, select and then double click the following objects: Consumer Name, Component Name, Viol Date Val objects. Expand the Reports for SLA violations Measures folder and double click the Number of Val object.
285
2. If you would like to initiate a query on a specific customer, you must create a condition. To create a condition execute the following steps: a. Drag and drop the Consumer Name object to the Conditions window, as shown in Figure 6-42.
Figure 6-42 Create a condition in a BusinessObjects query
b. In the Operators window on the left, double click the Matches pattern operator. From the Operands window, double clicking Show list of values will display a list of customer names, as shown in Figure 6-43 on page 287. We chose the Home Banking consumer name. Click OK. By creating this condition, the query retrieves data belonging only to the Home Banking consumer.
286
Figure 6-43 List of consumer names
3. Click Run to execute the query. The BusinessObjects window displays, as shown in Figure 6-44 on page 288.
287
Figure 6-44 BusinessObjects window
4. You may customize your report in this window. The information contained within this report refers to the violations received for a sole customer from only one component. You will notice in Figure 6-44 that the Home banking LOB component has been selected, along with the Val object, which indicates the percentage of uptime for the Home banking application.
288
Chapter 7.
Performance maximization techniques

IBM Tivoli Service Level Advisor is dependent on a number of supporting applications and components that need to be tuned up for proper performance. This chapter gives tips and hints for performance enhancement of critical components and supporting applications of an IBM Tivoli Service Level Advisor environment. The focus regarding performance tuning discussed in this chapter are for the following components: ITSLA Database Server IBM DB2 Universal Database Enterprise Edition IBM WebSphere Application Server IBM HTTP Server Tivoli Presentation Services Supported Operating Systems
289
7.1 Initial considerations

The following sections provide performance tuning tips for small, medium, and large configurations. As these may not be the best settings for your environment, a suggested approach would be to use these values as a starting point and then to monitor system performance, making changes where necessary. For the purposes of this chapter, a small, medium, and large environment is defined as described in Table 7-1.
Table 7-1 Definition of small, medium, and large ITSLA environment
ITSLA components Small Medium Large
Customers Realms Offerings Schedules Customer orders Metric evaluators Metric evaluations Component types Component resources
10 1 3 10 100 100 300 10 100
100 10 25 50 2000 4000 12000 10 1000
500 20 50 100 5000 10000 30000 10 5000
For more information on tuning your respective applications, refer to the following publications and URLs:
Database Performance on AIX for DB2 UDB and Oracle Environments Redbook, SG24-5511 DB2 UDB Version 7.1 Performance Tuning Guide Redbook, SG24-6012
http://www.db2mag.com/db_area/archives/2001/q1/hayes.shtml http://www.db2mag.com/db_area/archives/2001/q4/hayes.shtml
290
7.2 ITSLA Database Server tuning considerations

In order to prevent database connection failure errors on the ITSLA Database Server, you may need to change the value of the maxConnections parameter. This value should be equal to or less than the MAXAGENTS value defined in the database schema. In order to find the MAXAGENTS value, issue the following command from a DB2 command line:
db2 get dbm cfg | grep MAXAGENTS
For all operating systems, the maxConnections value is defined in the datasource properties file in the following locations, with a default value set to 25: For the ITSLA Server sdc datasource
/$SLM_BASEDIR/cfg/default/com/tivoli/managed/spi/host_name/ds/sdc/.properti es
For the ITSLA Server dmt datasource

/$SLM_BASEDIR/cfg/default/com/tivoli/managed/spi/host_name/ds/dmt/.properti es
For the Presentation Services Server sdc datasource

/PS_DIR/cfg/fwp_ps/com/tivoli/managed/spi/host_name/ds/sdc/.properties
7.3 IBM DB2 Performance tuning considerations

Depending on the size of your environment, there are many options available when tuning your IBM DB2 Universal Database Enterprise Edition servers performance. Follow the recommendations given in the following sections to help maximize your DB2 servers potential.
7.3.1 Small environments

If your environment can be categorized as a small environment according to Table 7-1 on page 290, consider making the following changes to your IBM DB2 Universal Database Enterprise Edition servers: Specify the amount of memory allocated for the database system monitor data, in 4 KB pages:
db2 update dbm cfg using mon_heap_sz 50
Change the average number of active applications connecting to the DYK_CAT database:
db2 connect to dyk_cat user DB2_user using DB2_password db2 update db cfg for DYK_CAT using avg_appls 5
Chapter 7. Performance maximization techniques
291
Specify the number of asynchronous page cleaners for the DYK_DM database:
db2 connect to dyk_dm user DB2_user using DB2_password db2 update db cfg for DYK_DM using num_iocleaners 2
The following values can be set to prevent transaction failure with an out of transaction space on the DB error. The logfilsiz parameter specifies the amount of disk storage in pages that is allocated to the log files that are used for data recovery. The logprimary and logsecond parameters determine the number of primary and secondary log files that will be used for database recovery. Their size is determined by the number specified when setting the logfilsiz parameter.
db2 update db cfg for DYK_DM using logfilsiz 2500 db2 update db cfg for DYK_DM using logprimary 10 db2 update db cfg for DYK_DM using logsecond 40
For more information on the database and database manager parameter configurations, refer to DB2 UDB Command Reference Version 7, SC09-2951.
7.3.2 Medium environments

If your environment is categorized as a medium-sized environment according to Table 7-1 on page 290, consider making the changes listed below to your IBM DB2 Universal Database Enterprise Edition servers. In a medium environment, it is also recommended that you take advantage of multiple hard disks, which will allow you to define multiple ioservers and iocleaners. Specify the amount of memory allocated for the database system monitor data, in 4 KB pages:
db2 update dbm cfg using mon_heap_sz 80
Make the following changes to the DYK_CAT database configuration:

db2 db2 db2 db2 db2 db2 db2 db2 connect to dyk_cat user DB2_user using DB2_password update db cfg for DYK_CAT using avg_appls 5 update db cfg for DYK_CAT using dbheap 10000 update db cfg for DYK_CAT using sortheap 8000 update db cfg for DYK_CAT using num_iocleaners 6 update db cfg for DYK_CAT using num_ioservers 5 update db cfg for DYK_CAT using dft_prefetch_sz 32 alter bufferpool IBMDEFAULTBP size 25000
Make the following changes to the DYK_DM database configuration:

db2 db2 db2 db2 connect to dyk_dm update db cfg for update db cfg for update db cfg for user DB2_user using DB2_password DYK_DM using dbheap 2000 DYK_DM using num_iocleaners 5 DYK_DM using num_ioservers 4
292
db2 db2 db2 db2
update db cfg for DYK_DM using dft_prefetch_sz 32 alter bufferpool IBMDEFAULTBP size 10000 alter bufferpool DM_BUFF2 size 10000 alter tablespace DM_RGLR prefetchsize 64
The following values can be set to prevent transaction failure with an out of transaction space on the DB error. The logfilsiz parameter specifies the amount of disk storage in pages that is allocated to the log files used for data recovery. The logprimary and logsecond parameters determine the number of primary and secondary log files that will be used for database recovery. Their size is determined by the number specified when setting the logfiles parameter.
db2 db2 db2 db2 connect to dyk_dm update db cfg for update db cfg for update db cfg for user DB2_user using DB2_password DYK_DM using logfilsiz 2500 DYK_DM using logprimary 10 DYK_DM using logsecond 118
In order to optimize your IBM DB2 Universal Database Enterprise Edition environment for querying, perform the following: 1. Execute the runstats and reorgchk commands on the DYK_DM database, as it will significantly improve performance. The runstats command will provide statistics on particular database tables and indexes. The reorgchk utility will provide you with the amount of free space available and the amount of space being used. For more information on these two commands, refer to Chapter 8, Troubleshooting the ITSLA on page 299. 2. Create a new temporary tablespace using one SMS container on a different operating system file system located on a separate physical disk. Drop the original temporary tablespace so that the new temporary tablespace is used. By simply moving the temporary tablespace to a different physical disk, elapsed time for a query can be cut by almost 25 percent. 3. Use a TEMPSPACE tablespace with four container directories. Place the containers on disks that are not otherwise being used by the database. 4. The standard DB2 EXTENTSIZE and PREFETCHSIZE for the TEMPSPACE is 32 - 4 KB pages. DB2 has the ability to prefetch data asynchronously in anticipation of the CPU's ability to process it, thus minimizing the impact of I/O service delays. PREFETCHSIZE dictates the quantity of data to asynchronously retrieve for each prefetch request. Generally, PREFETCHSIZE should be a multiple of EXTENTSIZE, and the multiple should be equal to the number of containers. 5. Enable intrapartition parallelism using the following command:
db2 update dbm cfg using INTRA_PARALLEL YES
Set the default degree of parallelism for the database to X# (where X# equals the number of system processors) using the following command:
293
db2 update db cfg for DBNAME using DFT_DEGREE X#
7.3.3 Large environments

If your environment is categorized as a large environment according to Table 7-1 on page 290, follow the recommendations in Medium environments on page 292, and make the following additional changes: Make the following changes to the DYK_DM database configuration:
db2 alter bufferpool STG_BUFF size 1000 db2 alter bufferpool IBMDEFAULTBP size 10000
Make the following change to the TWH_CDW database configuration:

db2 alter tablespace USERSPACE1 prefetchsize 64
Enable parallel I/O for every table space by issuing the following command:
db2set DB2_PARALLEL_IO=*
In addition to these configuration changes, you may also want to consider assigning multiple physical hard disks to the IBM Tivoli Service Level Advisor databases.
Notes on DB2 and large systems

The DYK_DM default log file size will support up to 450 k data points. When running large ETL extracts over 450 k data points, be sure to increase the amount of log file space (1130 bytes per data point). Each data point in DYK_DM increases the size of the database by approximately 500 bytes, but during ETL processing, the size may increase by as much as 2500 bytes per data point being extracted. For more information regarding the topics found in the DB2 performance tuning section, refer to the following manuals:
DB2 UDB Version 7.1 Performance Tuning Guide, SC09-2945 DB2 UDB Administration Guide: Implementation Version 7, SC09-2944 DB2 UDB Command Reference Version 7, SC09-2951
7.4 IBM WebSphere performance tuning

The default values and setup of IBM WebSphere Application Server are suitable for small environments, and no changes are necessary. For medium and large environments, we recommend that you change the value of the parameter maximumHeapSize to 768 MB. This value is defined in the server-cfg.xml file, which is located in the /$WAS_HOME/config directory.
294
We also recommend that you follow the instructions provided in the IBM WebSphere Application Server product documentation.
7.5 IBM HTTP Server performance tuning

For small, medium, and large configurations, we recommend that you change the following options in the httpd.conf file. httpd.conf is located in the /http_server_dir/conf directory:
Example 7-1 http.conf parameters
KeepAlive Off MinSpareServer 2 MaxSpareServer 10 StartServers 2 MaxClients 150
7.6 Presentation Services Web Console tuning

Depending on the size of your environment, consider making the changes as listed below. For a small environment, the provided default values are appropriate and no change is recommended.
7.6.1 Medium environments

For medium environments, we recommend that you set the maximum heap size to 512 MB by performing the following, depending upon your operating system: On a Windows platform: a. Select Start -> Run, and type in regedit in the Run box. b. From the regedit screen, navigate through the path HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> pc_wc -> Parameters. c. Double click the jvmOption8 value and change it to -Xmx512m.
295
On a UNIX platform: a. Locate the wc.sh file in the /PS_Dir/bin/private/generic_unix directory path. b. Change the $JVMARG = $JVMARG -Xmx384m value to $JVMARG = $JVMARG -Xmx512m.
7.6.2 Large environments

For large environments, we recommend that you set the maximum heap size to 768 MB by performing the following, depending upon your operating system: On a Windows platform: a. Select Start -> Run, and type in regedit in the Run box. b. From the regedit screen, navigate through the path HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> pc_wc -> Parameters. c. Double click the jvmOption8 value and change it to -Xmx768m. On a UNIX platform: a. Locate the wc.sh file in the /PS_Dir/bin/private/generic_unix directory path. b. Change the $JVMARG = $JVMARG -Xmx384m value to $JVMARG = $JVMARG -Xmx768m.
7.7 Operating system performance tuning

Depending on your operating system, consider making the following changes to enhance the performance of your IBM Tivoli Service Level Advisor environment. As we have only worked with Windows and AIX environments in the ITSO lab, we do not provide performance suggestions for the other supported platforms. For additional information on performance optimizations, refer to the official operating system documentation.
7.7.1 Windows environments

If you are using a Windows NT or Windows 2000 server for the ITSLA Reports Server with IBM WebSphere Application Server, you can significantly improve performance by optimizing your system traffic instead of file sharing.
296
Perform the following steps to make these changes: 1. Navigate through the path Start -> Settings -> Control Panel -> Network and Dial-up Connections -> Local Area Connection. 2. Click Properties on the Local Area Connection screen, and select File and Printer Sharing for Microsoft Networks. 3. Select the option Maximize data throughput for networking applications.
7.7.2 AIX environments

In order to enable large file support, ensure that the Soft FILE size value is set to -1 for the IBM DB2 Universal Database Enterprise Edition administrative user. This parameter defines the largest soft file size, in 512-byte blocks, that this user can create or extend when invoking a process. Perform the following steps to make this change: From the SMIT menu, navigate through the path Security & Users -> Users -> Change/Show Characteristics of a User. Type in the name of the IBM DB2 administrative user in the entry field. Scroll down to the Soft FILE size line and change the value listed to -1.
297
298
Chapter 8.
Troubleshooting the ITSLA

During the course of setting up and configuring an IBM Tivoli Service Level Advisor environment, you may encounter various error codes and situations that could add significant time to deployment of this solution. This chapters intent is to address the potential problems one may come across and to provide solutions that will remedy these issues. Some of this information can be found in the numerous documents included with the product, but all have been included in this redbook to provide an all-in-one reference point. The main topics of discussion concerning possible trouble areas are as follows: IBM DB2 Universal Database Enterprise Edition Tivoli Enterprise Data Warehouse IBM WebSphere Application Server IBM Tivoli Service Level Advisor IBM Console TEDW Source ETLs IBM Tivoli Service Level Advisor Reports
299
8.1 IBM DB2 Universal Database Enterprise Edition

At the core of the IBM Tivoli Service Level Advisor lies the IBM DB2 Universal Database Enterprise Edition. In this section you will find pertinent information that will help you install, configure, and administer your IBM DB2 environment.
8.1.1 Installation and configuration

This section includes troubleshooting hints and tips that may be useful when installing and configuring IBM DB2 Universal Database Enterprise Edition.
User and group setup

Prior to installing IBM DB2 on UNIX systems, be sure to set up the IBM DB2 administrative user and group. The group should include the database administrator, root, and sys users. To not be confusing, the IBM DB2 administrative user name should be indicative of its purpose and should have the newly created IBM DB2 group assigned as its primary group.
IBM DB2 Java Database Connectivity (JDBC) levels

The JDBC 1.1 drivers are loaded by default during the IBM DB2 installation. When implementing an IBM Tivoli Service Level Advisor environment, JDBC 2.0 drivers are required. If the IBM DB2 server and client drivers are at different levels, unexpected results may occur. To verify whether the correct JDBC drivers are being used, perform the following steps for your respective operating system: For Windows, navigate to the DB2_DIR\java directory, where DB2_DIR is the IBM DB2 location, and note the size of the db2java.zip file. If the size of the file is 1,347 KB, you are running JDBC level 2.0. If the file size is equal to 1,132 KB, then JDBC level 1.0 is installed and you must upgrade to JDBC 2.0. Refer to Manually updating the JDBC level on page 301 for more information. For UNIX, log in as the database instance owner and source db2profile located in the DB2_INST_DIR/sqllib directory, where DB2_INST_DIR is the instance home of the ITSLA Databases. Check the CLASSPATH variable by running the following command:
echo $CLASSPATH
If DB2_INST_DIR /sqllib/java12/db2java.zip is included in the command output, the JDBC level is 2.0. If DB2_INST_DIR/sqllib/java/db2java.zip is located in the command output, you are running JDBC level 1.0 and must update to JDBC level 2.0. Refer to Section , Manually updating the JDBC level on page 301 for more information.
300
Manually updating the JDBC level

The JDBC level is automatically updated when IBM Tivoli Service Level Advisor is installed. If, after following the above steps your JDBC level is still at level 1.0, perform the following steps, dependent upon the operating system, to update to JDBC level 2.0. For Windows, issue the following command from the DB2_DIR\java 12 directory, where DB2_DIR is the IBM DB2 installation location:
usejdbc2
The correct version of db2java.zip should now be copied into the DB2_DIR\java directory. For UNIX, find the userprofile script in the DB2_DIR/sqllib directory and add the following line:
. DB2_DIR/sqllib/java12/usejdbc2
If the userprofile script does not exist, add the above line to the end of the db2profile script located in the DB2_DIR/sqllib directory. After you have completed the above steps, run the steps described in IBM DB2 Java Database Connectivity (JDBC) levels on page 300 to verify that the JDBC level was updated correctly.
Sun Solaris specific changes

If the IBM DB2 server is being installed on a Sun Solaris system, additional changes will have to be made to the /etc/system file in order for the database server and client to function correctly. The values that need to be changed on the Solaris IBM DB2 client are listed in Table 8-1.
Table 8-1 /etc/systems parameters on Sun Solaris
Parameter Value
msgsys:msginfo_msgmax msgsys:msginfo_msgmnb msgsys:msginfo_msgseg msgsys:msginfo_msgssz
65535 65535 8192 16
Chapter 8. Troubleshooting the ITSLA
301
There are a couple of points that need to be made concerning the provided chart. First, the parameters msgsys:msginfo_msgmax and msgsys:msginfo_msgmnb must be set to 65535 or higher. It is very important that the chart is followed exactly or fatal errors may occur to the Solaris system. Secondly, in order for these changes to take effect, the system must be rebooted. In order to update these values, the appropriate lines must be added to the /etc/system file. The appropriate command syntax is given below:
set parameter_name=value
Where parameter_name represents the parameter you want to change and value is the number you would like to assign to that parameter. To set the parameter msgsys:msginfo_msgmnb to a value of 65535, add the following line to the end of the /etc/system file:
set msgsys:msginfo_msgmnb = 65535
The values that must be added to a Solaris IBM DB2 server are slightly different and are based on the amount of memory installed. Table 8-2 gives the information to be used when installing the IBM DB2 Universal Database on Solaris.
Table 8-2 Parameters for a Sun Solaris IBM DB2 server
Kernel parameter 64 - 128 MB 128 - 256 MB 256 - 512 MB 512 MB +
msgsys:msginfo_msgmax msgsys:msginfo_msgmnb msgsys:msginfo_msgmap msgsys:msginfo_msgmni msgsys:msginfo_msgssz msgsys:msginfo_msgtql msgsys:msginfo_msgseg
65535 65535 130 128 16 256 8192
65535 65535 258 256 16 512 16384
65535 65535 258 256 16 1024 32768
65535 65535 258 256 16 1024 32768
shmsys:shminfo_shmmax shmsys:shminfo_shmseg shmsys:shminfo_shmmni
67108864 16 300
134217728 16 300
268435456 16 300
536870912 16 300
semsys:seminfo_semmni
128
256
512
1024
302
Kernel parameter
64 - 128 MB
128 - 256 MB
256 - 512 MB
512 MB +
semsys:seminfo_semmap semsys:seminfo_semmns semsys:seminfo_semmnu semsys:seminfo_semume
130 256 256 50
258 512 512 50
514 1024 1024 50
1026 2048 2048 50
The values for the shmsys:shminfo_shmmax parameter should be set to the suggested value in the given table or 90 percent of the physical memory in bytes, whichever is higher. For example, if you have 512 MB of physical memory in your Solaris system, set the shmsys:shminfo_shmmax parameter to 48183821 (512 * 0.9 * 1024 * 1024). To set the values for the given parameters, use the syntax given below in the /etc/system file:
set shmsys:shminfo_shmmax = 184968806
Remember to reboot the system in order for the kernel parameter changes to take effect.
Instance creation failure on UNIX platforms

You may create the IBM DB2 instance manually if you receive an error while creating the instance during the initial IBM DB2 setup on UNIX systems. Perform the following steps in order to manually create the IBM DB2 instance: 1. Verify that the IBM DB2 administrative user and group have been created successfully with the appropriate privileges. 2. Depending on your operating system, change to the following directory: For AIX: /usr/lpp/db2_07_01/instance For Solaris: /opt/IBMdb2/V7.1/instance For Linux: /usr/IBMdb2/V7.1/instance 3. Issue the following command, where dbadmin_name is the name of the database administrative account, and new_instance_name is the name of the new instance, which should be identical to the db2admin_name parameter:
db2icrt -a SERVER|CLIENT -u db2admin_name new_instance_name
8.1.2 Databases creation

This section includes error codes and messages that may be encountered when attempting to create an IBM Tivoli Service Level Advisor database or when trying to connect to an existing database. Critical information concerning the following error messages can be found in the dyk_cat.log and dyk_dm.log files.
303
Failure when running database creation scripts

The following errors may be seen during database creation.
SQL1005N message
The error message is as follows:
SQL1005N: The database alias already exists in either the local database directory or system database directory.
Before trying to re-add the databases with the provided scripts, perform the following steps: 1. Run the following command from the IBM DB2 command line:
db2 list db directory
2. If either or both the DYK_CAT and DYK_DM databases are not included in the listing, perform with the following steps: a. Issue the following command, where missing_db is the missing database and any_db is a generic catalog entry:
db2 catalog db missing_db as any_db
b. Make sure the any_db you catalogued was created successfully by running the following command:
db2 list db directory
c. After you verify that the catalog was successful, drop the database:
db2 drop db any_db
d. If you receive a failure when attempting to drop the database, uncatalog the database and then terminate all connections:
db2 uncatalog db any_db db2 terminate
3. Attempt to run the database creation scripts again.
SQL1032N message
SQL1032N: No start database manager command was issued SQLSTATE=57019
This error usually means that the database manager is currently not operative. Attempt to start the IBM DB2 server by issuing the db2start command.
SQL1403N message
SQL1403N: The username and/or password supplied is incorrect SQLSTATE=08004
304
If the user name and password used during the database creation were incorrect, or if the user does not have the appropriate privileges to run the creation scripts, you may receive this error. Check the user name and password combination, or check the users privileges before running the creation scripts again.
Connecting to databases
When attempting to connect to the IBM Tivoli Service Level Advisor databases, you may encounter the error codes or messages in the following section. If the provided solutions do not resolve the problem, please refer to the DB2 UDB Troubleshooting Guide Version 7, GC09-2850.
SQL1224N message
This error code can contain many different meanings within an IBM Tivoli Service Level Advisor environment. Typically, this error code indicates that all shared memory segments for IBM DB2 have been exhausted. You may also see this error if any of the IBM Tivoli Service Level Advisor components are installed on the same machine as the ITSLA Database Server component. The meaning of this error code differs if the IBM DB2 server is located on an AIX or Solaris system. If you get the SQL1224N message on AIX, you may need to configure IBM DB2 to use extended shared memory if the IBM Tivoli Service Level Advisor databases reside on the same machine as any of the other IBM Tivoli Service Level Advisor installation options. To enable extended shared memory on AIX, perform the following steps: 1. Add EXTSHM=ON to the /etc/environment file. 2. Run the following command from an IBM DB2 command line:
db2set DB2ENVLIST=EXTSHM
3. Add the following lines to sqllib/db2profile:

EXTSHM=ON export EXTSHM
4. Reboot the machine for the changes to take effect. If you get the SQL1224N message on Solaris, an incorrect configuration on the Solaris database server may exist. Use Table 8-2 on page 302 to confirm the correct kernel parameter values in the /etc/system file. These values must be entered exactly as shown in order for IBM DB2 to function as expected. More information on these values can be found in DB2 UDB Quick Beginnings for UNIX Version 7, GC09-2970.
305
SQL30081N message
When attempting to connect to remote IBM Tivoli Service Level Advisor databases, this error code indicates that the IBM DB2 client or server is not set up correctly to communicate with other IBM DB2 systems. The steps below are provided to help troubleshoot the above error message. 1. Verify that the IBM DB2 system to be reached can be pinged by the DNS host name and IP address. 2. If a connection is still unable to be established, issue the following commands to ensure that the IBM DB2 server is functioning properly: a. From a IBM DB2 command line, run the following command:
db2 get dbm cfg
Check the SVCENAME parameter in the above commands output. If no value exists, more than likely the instance was created manually, and there is no value associated with IBM DB2 in the services file. If there is a value associated with SVCENAME, continue on to step b. The services file is located in the following areas, dependent upon operating system: For Windows, WIN_DIR\system32\drivers\etc. For UNIX, /etc directory.
If there is no value in the services file, add the following lines to the end of the file:
db2cinstance_name 50000/tcp #Connection port for instance_name db2iinstance_name 50001/tcp #Interrupt port for instance_name
For example, if your instance name is db2admin, the first line would look like this:
db2cdb2admin 50000/tcp #Connection port for db2admin
The interrupt line would follow the same format as the connection line, with only the port being changed. Below is an example of the interrupt line:
db2idb2admin 50001/tcp #Interrupt port for db2admin
After adding the appropriate lines to the services file, you will need to switch to the IBM DB2 administrative user and issue the following command:
db2 update dbm cfg using svcename connection entry in services file
For example, if your connection line entry was db2cdb2admin, the command would be as follows:
db2 update dbm cfg using svcename db2cdb2admin
306
After issuing the above command, the IBM DB2 instance must be stopped and restarted. The instance should now be listening on TCP/IP port 50000. b. Search on the port assigned to IBM DB2 in the services file to verify that no other application is using the same port. You may check the ports status by using the following command:
netstat -a |grep port_number
If any application is found utilizing the IBM DB2 port specified in the services file, there are a number of options available to resolve this issue: i. End the service that is using the port. ii. Reboot the machine to clear the port from use. iii. Choose another port and configure IBM DB2 to use that port following the instructions above. If you do decide to configure another port for IBM DB2, remember to delete the old entries in the services file, as conflicting services will cause IBM DB2 to function improperly. c. After the above steps have been completed and verified, check the DB2COMM environment variable by issuing the following command from a IBM DB2 command line:
db2set
Output from this command should contain a number of IBM DB2 environment variables. The DB2COMM variable is specific to IBM DB2 communication and is the variable to be searched for in the db2set commands output. You should see DB2COMM=TCPIP (if TCP/IP is the communication protocol being used). If the correct information is not provided in the output, run the following command from the same window:
db2set DB2COMM = TCPIP
This will set the IBM DB2 communication protocol to TCP/IP. If you are using another protocol, check the DB2 UDB Command Reference Version 7, SC09-2951, for more details. d. Stop and restart the IBM DB2 server using the following commands:
db2 stop force db2start
If you have set everything up correctly, a SQL1063N message should be found after the IBM DB2 server has been restarted. If you do not see this message, and instead see a SQL1054N message in your logs, your IBM DB2 server is still not functioning properly. Refer back to the above steps and recheck the values entered, or consult DB2 UDB Administration Guide: Implementation Version 7, SC09-2944, for additional assistance.
307
IBM Console or Reports user interface unresponsive

There may be a IBM DB2 connection problem if no control is returned when selecting links in either the IBM Console or Reports. Whenever network connectivity is lost, the IBM DB2 client may appear to be hung when trying to communicate with the IBM DB2 server. Try to ping the IBM DB2 server to verify connectivity by issuing the following command:
ping db2_server_hostname
If you are unable to ping the server, contact the appropriate system administrator for additional assistance, or refer to the TCP/IP Problems section in the DB2 UDB Troubleshooting Guide Version 7, GC09-2850.
8.1.3 Administration issues

This section includes numerous errors one may receive while administrating the IBM DB2 Universal Database Enterprise Edition environment and covers different scenarios to help improve the performance of your IBM DB2 server.
Verifying ODBC data sources

If you have not done so already, run the following command from a IBM DB2 command line to verify the creation of the ODBC data sources for the IBM Tivoli Service Level Advisor databases:
db2 list system odbc data sources
The DYK_CAT and DYK_DM databases should be included in the above commands output. If they are not listed, you can create the data sources manually, as described in 4.4.6, Configuring the ODBC connections on page 103. To further verify the successful creation of the ODBC data sources, attempt to connect to the IBM Tivoli Service Level Advisor databases by issuing the following command for each database:
db2 connect to db_name user userid using password
Where db_name is either DYK_CAT or DYK_DM, userid is the IBM DB2 administrative user name, and password is the IBM DB2 administrative users password.
308
If errors are received when running the above commands, verify each of the following steps: Verify that the remote host name can be reached. Issue the following command where remote_host is the host name used in the ODBC data source:
ping remote_host
If you cannot reach the host, or you need to reconfigure the remote host to be defined, run the following commands from an IBM DB2 command line:
db2 db2 db2 db2 uncatalog node ODBC_node uncatalog db db_name uncatalog system odbc data source datasource_name terminate
After completing the above steps, rerun the ODBC data source creation scripts as described in 4.4.6, Configuring the ODBC connections on page 103. The local database server and remote database node must be configured to use the same port number in order for the ODBC data sources to function properly. The ODBC data source creation scripts that are packaged with IBM Tivoli Service Level Advisor default to port 50000. If the ports are not the same on the two systems, you will never be able to connect to the ODBC data source. To change this port number, refer to 4.4.6, Configuring the ODBC connections on page 103.
Exceeding maximum connections

If you receive an error in your IBM DB2 logs stating that the maximum number of connections has been reached, your IBM DB2 server has reached its maximum limit for allowing database connections. Every time a Sample Contents operation is used within the IBM DB2 Control Center, a connection is opened to that database. This connection remains open until the IBM DB2 Control Center is shut down. Once the maximum number of connections has been met, IBM Tivoli Service Level Advisor and other applications will not be allowed to access the database. By default, IBM DB2 allows a maximum of 40 database connections at one time. There are two ways to alleviate this problem: Shutting down the IBM DB2 Control Center to terminate the applications, or Increasing the level of MAXAPPLS in the database configuration To increase the MAXAPPLS parameter value, perform the following from a IBM DB2 command line:
db2 update db cfg for db_name using maxappls new_total
309
Where db_name is the database name to be altered, and new_total is the new number of maximum connections to be assigned. Increasing the maximum number of database connections can also be performed via the IBM DB2 Control Center graphical user interface. From the IBM DB2 Control Center, do the following: 1. Right click the database to change and select Configure. 2. Select the Applications tab and click Maximum number of applications. 3. Enter the new value in the Value field and click OK. All applications must disconnect from the database for the changes to take effect.
Optimizing performance with runstats

Within an IBM Tivoli Service Level Advisor environment, data is constantly being added and removed from the TWH_CDW and DYK_DM databases. All of this activity can take its toll on a database and, in the long run, can severely hamper query speed and performance. The runstats command is executed to provide the user with accurate information concerning current statistics for specific database tables and indexes. The tables that are most affected in the IBM Tivoli Service Level Advisor environment are the TWG.MSMT table in the TEDW Central Warehouse database, and the DYK.MSMT_TOT and DYK.MSMT_MMA tables in the ITSLA Measurement Data Mart database. Usually, runstats is run on the TWG.MSMT table after the Source ETLs have run, and on the DYK.MSMT_TOT and DYK.MSMT_MMA tables once after the Registration and Process ETLs have run, and periodically thereafter. Appendix C, IBM Tivoli Service Level Advisor Databases on page 403, offers a description of the IBM Tivoli Service Level Advisor database tables. Note that due to the query performance requirements for ITSLA Reports, it is not advised to run runstats on the ITSLA Database (DYK_CAT). Refer to IBM Tivoli Service Level Advisor Release Notes Version 1.1, GI11-0908 , for more information. To execute runstats on the tables described above, perform the following steps: 1. Start an IBM DB2 command line and connect to the desired database:
db2 connect to db_name user db_user using db_password
2. Run runstats on the TWG.MSMT table after the source ETLs have finished their processing:
db2 runstats on table twg.msmt
310
3. Run runstats on the DYK.MSMT_TOT and DYK.MSMT_MMA tables after the Registration and Process ETLs have finished:
db2 runstats on table dyk.msmt_tot db2 runstats on table dyk.msmt_mma
Analyzing table organization with reorgchk

Internal gaps may be left in database tables when certain SQL operations are performed. By utilizing the reorgchk facility, the physical organization of the IBM DB2 tables and indexes can be determined, along with how much space is being used and how much free space is currently available. To run the reorgchk utility, issue the following command:
db2 reorgchk [current statistics] on table schema, table_name
Where schema is the name of the schema in which the table_name was created. If [current statistics] is not specified in the command, reorgchk will call runstats to retrieve the latest table statistics. If by accident you run runstats or reorgchk on the DYK_CAT database, you can issue the following commands to lower the default query optimization level to 1:
db2 connect to dyk_cat user db2user using db2password db2 update db config for dyk_cat using dft_queryopt 1 db2 disconnect dyk_cat
8.1.4 Important initial IBM DB2 commands

Table 8-3 is meant to be used as a one-stop reference point for the most common IBM DB2 commands. The command and its basic purpose is included for ease of use. Please refer to DB2 UDB Command Reference Version 7, SC09-2951, for more complete listings.
Table 8-3 IBM DB2 command reference
Command Usage
db2icrt -a SERVER|CLIENT -u db2_user db2_instance db2level
Creates the IBM DB2 instance. Provides the IBM DB2 software level; for ITSLA, the level should be 7.1.0.55. Adds a TCP/IP node entry to the node directory. Lists the contents of the node directory.
db2 catalog tcpip node node remote hostname db2 list node directory
311
Command
Usage
db2 catalog db db_name as db_name at node nodename
Stores database location information in the system database directory. Lists all databases either local or remote. Connects to the specified database. Lists tables for the currently connected database. Returns values of individual entries in the database manager configuration file. Modifies entries in the database manager configuration file. Sets the DB2COMM variable to the desired communication protocol. Used to stop and restart DB2. Displays helpful information concerning particular error codes.
db2 list db directory db2 connect to db user user_name using password db2 list tables db2 get dbm cfg
db2 update dbm cfg using parameter value db2set DB2COMM=comm_protocol db2terminate, db2 stop force, db2start db2 ? error_code
8.2 Tivoli Enterprise Data Warehouse

In the following sections you will find troubleshooting information covering the Tivoli Enterprise Data Warehouse product. More information regarding Tivoli Enterprise Data Warehouse can be found in Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, and Tivoli Enterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744.
8.2.1 TEDW installation and configuration

In this section you will find hints and tips to aid you in installing and configuring Tivoli Enterprise Data Warehouse.
312
Failure installing after un-installation

If your installation fails after you have un-installed the Tivoli Enterprise Data Warehouse, remove the vpd.properties file from the following locations, depending on your operating system: For Windows, the vpd.properties file is located under the C:\WINNT directory. For UNIX, the file is located in the /usr/lib/objrepos directory. Try reinstalling Tivoli Enterprise Data Warehouse again after removing this file.
Unexpected communication error

If you receive the following error when trying to log in to the TEDW Control Center, make sure both TEDW services are running:
DWC06200E An unexpected communications error has occurred. Connection refused: no further information RC = 6200 RC2 = 0
Look in the Services panel and verify that the Warehouse Logger and Warehouse Server services are both running on the TEDW Control Center machine. After verifying their status, try logging in again.
Unable to retrieve IBM DB2 user

If the connection between the TWH_MD database and the TEDW Control Center machine has been broken, you may receive the error shown in Example 8-1.
Example 8-1 Unable to retrieve IBM DB2 user
DWC07035E The warehouse server was unable to retrieve user db2admin. The error occurred in response to an authentication request from client <hostname>. [IBM][CLI Driver][DB2/NT] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032 RC = 7035 RC2 = 2014.
Make sure the Warehouse Logger and Warehouse Server services are running by verifying their status in the Services panel on the TEDW Control Center machine. Try to connect to the TWH_MD database if restarting the Warehouse services does not fix the problem. The command is as follows:
db2 connect to twh_md user db_user using password
313
Database specified does not match

Your control database may be configured incorrectly if you receive the following error during login:
DWC01007E Logon Failed. The Database specified by the user does not match the database used by the warehouse server. RC = 1007 RC2 = 0
Perform the following steps to resolve this problem: 1. Click Advanced... from the Data Warehouse Center login screen. 2. Enter TWH_MD in the Control Database field. 3. Click OK and try to log in again.
TEDW Control Center lacking warehouse services

If you notice that one or both of the warehouse services are missing after an IBM DB2 Universal Database Enterprise Edition Version 7 Fixpack 5 installation, perform the following steps: 1. Select Warehouse Control Database Management from Start -> Programs -> IBM DB2. 2. Enter TWH_MD in the New control database field. 3. Click OK after entering your IBM DB2 user ID and password. 4. Click cancel after the processing has completed.
8.2.2 TEDW administration issues

The following sections provide troubleshooting information related to Tivoli Enterprise Data Warehouse administration.
Correct user metric data not recorded in warehouse

When using IBM Tivoli Monitoring for Transaction Performance (TAPM), the user metrics data is not supported in IBM Tivoli Service Level Advisor.
Increasing File system After log file Size Alteration

Verify that you can still connect to the TWH_CDW database after changing the log file size for this database. Issue the following command to verify this connectivity:
db2 connect to twh_cdw user db2_user using password
The /home file system may need to be increased in order to accommodate the larger file size.
314
8.3 IBM WebSphere Application Server

In the following sections, information is provided that will assist you in troubleshooting and administrating your version of IBM WebSphere Application Server.
8.3.1 Installation and configuration issues

Below you will find problems you may encounter when installing the IBM WebSphere Application Server.
Disable IIS prior to install

If during the installation of IBM WebSphere Application Server the installation hangs at 37 percent, IIS may not have been disabled. Disable the IIS service and attempt to install the IBM WebSphere Application Server again. Check LOG_FILE_NAME for more information.

While administering the IBM WebSphere Application Server with IBM Tivoli Service Level Advisor, you may come across some errors, which will be discussed in the following sections.
SQL failure in _adminServerFatalError file message

Check the _adminServerFatalError file if you have problems starting IBM WebSphere Application Server (Example 8-2).
Example 8-2 _adminServerFatalError file
[02.03.15 14:27:46:017 CET] 7fc10ca7 DBMgr F SMTL0026E: Failure to create a data source: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL0901N The SQL statement failed because of a non-severe system error. Subsequent SQL statements can be processed. (Reason Invalid Request Type for DB2 Admin Server.)
If you do receive this error, make sure that the IBM DB2 server where the DYK_CAT database is located has been started. Perform the following steps to correct this error: 1. Stop the IBM WebSphere Application Server with the following command:
WebSphere_Dir/AppServer/bin/stopServer
315
2. Using the IBM DB2 administrative user ID, log in to the IBM DB2 server where the DYK_CAT and DYK_DM databases are located and start the IBM DB2 Admin Server from an IBM DB2 command line with the following command:
db2admin start
3. From the same command line, start the IBM DB2 server:
db2start
4. After the IBM DB2 Admin Server and IBM DB2 server have started, restart WebSphere with the following command:
WebSphere_Dir/AppServer/bin/startServer
SDC errors in IBM WebSphere Application Server log

If you are experiencing troubles creating SDC Data Sources in the IBM WebSphere Application Server, check the WebSphere_Dir/logs/default_server_stdout.log file for the following errors:
DYKAL3013E Error loading driver COM.ibm.db2.jdbc.app.DB2Driver DYKAL1054E Component nvtest_servlet:DS:1 failed startup with the following error: DYKAL3002E An error occurred for sdc during DataSource creation.
If you see these errors in the log file, verify that the location of the IBM DB2 application driver is configured properly in IBM WebSphere Application Server. Refer to 8.3.2, Administration issues on page 315, for more details. In addition, make sure that db2profile is sourced in the same window from where WebSphere is started, and that the appropriate JDBC level is being used. You can verify both of these by running the following command:
echo $CLASSPATH
8.4 IBM Tivoli Service Level Advisor

In this section you will find troubleshooting topics covering all facets of the IBM Tivoli Service Level Advisor deployment process. For more details regarding the information read here, refer to the official product documentation.
8.4.1 Installation issues

Below you will find numerous hints and tips regarding the installation of the IBM Tivoli Service Level Advisor.
316
Blank install window or incomplete text

If during the course of installing IBM Tivoli Service Level Advisor you experience blank install screens or windows with incomplete text, try resizing the current window. All text should be displayed after the window refresh.
Install screen fonts not readable

When installing IBM Tivoli Service Level Advisor on AIX using the DE_DE language, some fonts in the install dialogue may not be readable. To resolve the issue, perform the following steps: 1. Copy all contents from the IBM Tivoli Service Level Advisor CD to a temporary directory. 2. Rename the following file:
java/aix4-r1/jre/lib/font.properties.UTFB
To the following:
java/aix4-r1/jre/lib/font.properties.UTFB.bak
3. From the temporary directory, run the installation.
Cleaning up temporary ISMP directories

A number of directories preceded by ismp* may be created under your temp directory (/tmp on UNIX or %TEMP% on Windows) when installing IBM Tivoli Service Level Advisor. These directories may be removed after completing the installation in order to conserve disk space.
8.4.2 Configuration issues

In the following sections we provide a number of solutions to common IBM Tivoli Service Level Advisor configuration problems.
Host name not fully qualified

Receiving either of the following error messages may indicate that your system is not configured to return fully qualified host names: When trying to run a scmd, you receive the following error: DYKAL2030E Unable to connect to the Command Line Interface service on port 9990. Checking SLMMessagex.log may reveal the following:
DYKAL0009E The server host name hostname is not a fully qualified host name. DYKAL1020I Component startup activities have completed:0 started, 0 timed out, 0 failed.
317
These errors may occur if your ITSLA Server is not configured to use a fully qualified host name. Wherever the ITSLA Server, ITSLA Task Drivers, and ITSLA Reports Servers are installed, the machines they reside on must be set up to resolve fully qualified names.
No connection to the ITSLA Databases from the ITSLA Server

If you receive the following error message in the SLMMessagex.log file, you may be experiencing issues connecting to the ITSLA Database or the ITSLA Measurement Data Mart databases:
DYKAL1054E Component yourmachine.somecompany.com:DS:1 failed startup with the following error:DYKAL3002E An error occurred for sdc during DataSource creation.
This error may also be received if only the rcc, log, and slm bundles are listed in the scmd list command output. The following explanations cover the most common causes for receiving the above error: If the db2start command has not been issued on the database server, you may receive the following error message in the SLMMessagedx.log file:
DYKAL3014E Error connecting to the database. Reason: [IBM][CLI Driver] SQL1032N No start database manager command was issue SQLSTATE=57019
If you see this error message, verify that the db2start command has been issued on the database server machine. The following error message may be received if the d2java.zip file has not been configured in the system CLASSPATH: DYKAL3013E Error loading driver COM.ibm.db2.jdbc.app.DB2Driver Make sure the IBM DB2 server or client is installed on the machine and perform the following steps, dependent on your operating system: For Windows, enter the following at a command prompt:
set classpath
Ensure that the path of the db2java.zip file is correct in the command output. If the value is not set correctly, make the appropriate changes in the Windows environment variable dialogue under System in the Control Panel. After committing the changes, restart the ITSLA Server. For UNIX, verify the db2profile and usejdbc2 script paths in the TSLA_DIR/bin/private/generic_unix/runscripts/slmdbsetup.sh file, where TSLA_DIR is the location where IBM Tivoli Service Level Advisor was installed. If the values are not correct, enter the correct paths in the file and restart the ITSLA Server.
318
Verify the network connectivity to the database server by using the ping command. Refer to Connecting to databases on page 305 or Accessing Reports on page 344 for related information.

While administering IBM Tivoli Service Level Advisor, you may encounter some of the issues described in the following sections. This section includes tips covering the different aspects of IBM Tivoli Service Level Advisor administration.
Creating offerings and orders

The following are known issues related to creating offerings and orders. Some of them were encountered during the writing of this redbook.
No selectable resources
When attempting to create an offering, you may notice that there are no resources to select from in the Resource Type tree of the Create Offering Component dialog. Listed below are several instances that may cause this problem: The Registration ETL has not run successfully. No source applications have been enabled, even after the Registration ETL has run successfully. The data in the TEDW Central Warehouse database has not yet been registered by the ITSLA Server in the DYK_CAT database, even after the source applications have been enabled. Resolve these problems by performing the following steps: 1. Make sure that the desired source applications have been enabled by using either the scmd etl enable or the scmd etl addApplicationData CLI command. 2. Ensure that the DYK_m05_Populate_Registration_Datamart process has run successfully. If you see in the IBM DB2 Data Warehouse Center that this step has failed, attempt to run it again. If the process fails again, examine the following log files for more detailed information:
SQLLIB_DIR\logging\dyk_m05_s010_Populate_STAGE_Data.log SQLLIB_DIR\ogging\dyk_m05_s020_Populate_Reg_Datamart.log
3. Allow at least 10 minutes for the ITSLA Server to register the data in the TEDW Central Warehouse database. The ITSLA Server utilizes a 10 minute time span to check for any successful run of the Registration ETL.
319
No component type sources available during offering creation

After installing IBM Tivoli Service Level Advisor or rebuilding the DYK_CAT database, you may receive the following error when clicking Next in the Select Resource Type dialogue box when creating an offering:
DYKGU0071E There are no measurement sources available for the component type component_type_name
There are two possible causes of this error, the first being that the source application may have been disabled with the scmd etl disable command. It is possible for the source application to be disabled and for it to show up in bold text in the Select Resources list when creating an offering. This resource should be used in the creation of any offerings until the Registration ETL is run again. If this is the case, there is no need to continue with this troubleshooting section. The second possible cause of this error may be that the IBM Tivoli Service Level Advisor has not registered the appropriate data from the TEDW Central Warehouse database. Not all data is transferred when the Registration ETL is run, as the SDC requires the time necessary to register its own data. Perform the following steps to further diagnose this problem: 1. To verify the existence of the Service Elements in the ITSLA Database, issue the following command:
scmd sdc displayActiveServiceElements
2. If no output is received from the above command, you can manually attempt to register the warehouse data with the following:
scmd sdc registerWarehouseData
3. Repeat step 1 again to verify the output:

scmd sdc displayActiveServiceElements
4. If you still do not see any Service Elements, verify that the Registration ETLs have run. 5. You can also determine if the data exists in the ITSLA Database by examining a table in the ITSLA Database by performing the following steps: a. Dependent upon your operating system, set up an IBM DB2 environment: For Windows, select Start -> Run and enter db2cmd. For UNIX, source the db2profile with the following command:
. ./db2_instance_dir/sqllib/db2profile
b. Reconnect to the ITSLA Database with the following command:

db2 connect to dyk_cat user db2_user using db2_password
320
c. Issue the following command:

db2 select * from svc_scop
If the table is empty, this may be the reason for the DYKGU0071E message. d. Disconnect from the ITSLA Database with the following command:
db2 disconnect from dyk_cat
Internal error during offering, order, customer, or realm creation

If you receive a message stating an Internal error occurred when trying to create a realm, customer, offering, or order, check for the message shown in Example 8-3 in the log file.
Example 8-3 Internal error message log file listing
DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0803N One or more values in the INSERT statement, UPDATE, statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by 1 constrains table DB2INST1.REALM from having duplicate rows for those columns. SQLSTATE=23505
You will receive this error when IBM Tivoli Service Level Advisor attempts to assign an existing objects ID with a newly created one. As new objects are created, the ID_GENERATOR table tracks their creation. Incorrect IDs may be assigned to new objects if you restored or imported database tables without including the ID_GENERATOR table. Run the following command to resolve this issue:
scmd sdc adjustIdGenerators
This command is used by IBM Tivoli Service Level Advisor to adjust the mechanism that determines each newly generated ID. If this problem persists, please contact Tivoli Customer Support. For more information regarding the use of the scmd sdc adjustIdGenerators command, refer to Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
Unable to submit orders

If there are no resources available to submit an order against when creating an order, an error may have occurred during the registration of warehouse data into the ITSLA Server. If you find exceptions or errors in the ITSLA Server message logs dealing with the building of component paths, issue the following CLI command:
scmd sdc registerWarehouseData
321
Contact Tivoli Customer Support if errors continue to be logged. Otherwise, try resubmitting the order.
Problem in Create Like Schedule window

There are a few windows in IBM Tivoli Service Level Advisor that ask you to enter text in a field and select items in a table. To ensure that the text does not revert to its previous entry, select or deselect table items before entering content in the text field. You should follow this tip when working in the following windows: Create Like Schedule Create Customer Create Schedule
Name space hinders table filtering

If spaces are included in the names of objects, table filtering will not work. This problem can be worked around by not placing a space in your filter, or supplying your search with the HTML character for space, &nbsp.
Last character duplicated for TAPM

When selecting IBM Tivoli Monitoring for Transaction Performance (TAPM) resources during an order creation, you may notice that the last letter of every entry has been duplicated. This does not effect the functioning of IBM Tivoli Service Level Advisor, as all measurements are properly reported. You may want to add these duplicated letter or use * when filtering.
Breach values not preserved when metric is disabled

When creating a draft offering, the breach values you set for the offering will not be preserved if you later remove the metric from the offering. You must reconfigure the breach values for the service level objectives if you decide to use the metric in the same draft offering.
SLA data value issues

The following are known issues related to SLA data value. Some of them were encountered during the writing of this redbook.
Evaluation of partial or missing data

Schedules established in the agreed-upon service level agreement determine when data is retrieved for the purpose of evaluation and trend analysis. If a source application failed or only part of the data was reported by the source application during the scheduled evaluation time, some data may not be available in the ITSLA Measurement Data Mart database.
322
Periodically, a retry process runs, attempting to retain the data that is stored in the ITSLA Measurement Data Mart database following the evaluation time. Every time the retained data is not available for processing, an entry is created and placed in the active retry state. When the retries have surpassed the configurable number of attempts, the entry is then changed to the stopped retry state. If you believe that not all of your data is being reported, check to see if the source application is reporting partial data by issuing the following command:
scmd mem showStoppedRetry
Any entries that are in the active retry or stopped retry state will be included in the above commands output. After verifying that the source application in question is reporting data correctly, two options are available: Run the following command if the data is finally reported by the source application to force the processing of evaluations and trends for all entries:
scmd mem retryMissedIntervals -all
If the data was lost by the source application, or if you feel that the data will not be reported for some reason, remove those stopped entries by issuing the following command:
scmd mem removeStoppedRetryEntries
For more information on the above commands, refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
No data points received for specific customer order

If no data points were received for a specific customer order or resource within the allotted evaluation period, perform the following steps: 1. Issue the following command, where Cust_OID is the customer order ID containing no data points:
scmd mem ShowMetricEvaluators -co Cust_OID
Outlook will look similar to Example 8-4.

Example 8-4 scmd mem ShowMetricEvaluators command output
customer order ID 1005 Listing Metric Evaluators for Service Element InstanceID: 1028 Metric Evaluator Instance Identifier 48:1028:97 customer order ID 1005 Resource Name /fvtsol17/slmfvt8 job3 Component Identifier 48 Evaluator Type EVAL_TYPE_A
323
Metric Evaluator Instance Identifier 50:1028:97 customer order ID 1005 Resource Name /fvtaix18.domain.com/slmfvt9 job_name1 Component Identifier 50 Evaluator Type EVAL_TYPE_A Listing Metric Evaluators for Service Element InstanceID:1029 Metric Evaluator Instance Identifier 49:1029:97 customer order ID 1005 Resource Name /SLMFVT5.domain.com/slmfvt5_sti playback Component Identifier 49 Evaluator Type EVAL_TYPE_A
2. With the above Customer Order, note the resource names whose values are as follows: /fvtsol17/slmfvt8 job3 /fvtaix18.domain.com/slmfvt9 job_name1 /SLMFVT5.domain.com/slmfvt5_sti playback 3. Search for the message shown in Example 8-5 in the SLMMessageX.log file.
Example 8-5 SLMMesageX.log file listing - 1
DYKME9064W 0 datapoints have been collected for the evaluation period: Evaluation period start time - Evaluation period end time ComponentName/MeasurementType/CustomerID: Resource Name/ Measurement Type/ Customer Order ID This may not be expected
4. Compare the values for customer order ID and resource name. In this example, the output may appear as in Example 8-6.
Example 8-6 SLMMesageX.log file listing - 2
2002.02.15 11:06:41.095 DYKME9064W 0 datapoints have been collected for the evaluation period: Tue Feb 12 00:00:00 EST 2002-Tue Feb12 23:59:59 EST 2002. ComponentName/MeasurementType/CustomerID: /fvtaix18.domain.com/slmfvt9 job_name/97/1005. This may not be expected.
If the resources and customer order ID match, refer to Section 8.2.2, TEDW administration issues on page 314.
No-service schedule state assigned to time frame

When a schedule state is set to No Service, no results will be published for that time period. This schedule state allows businesses to bring down their resources without having to worry about false violations and trends being generated.
324
Verify this schedule state is configured correctly within the schedule periods for the particular customer order.
DYKME9034E error when trying to publish service monitor results

If the ITSLA Server is experiencing difficulty writing SLA data results to DYK_CAT, you may receive the error shown in Example 8-7 in the SLMMessageX.log file.
Example 8-7 SLMMesageX.log file listing - DYKME9034E
DYKME9034E An attempt was made to publish service monitoring results and a failure occurred. The monitoring results will be stored locally.
This error message may mean that the ITSLA Database was down when the ITSLA Server attempted to write the data results to the database. If this is the case, the data results are stored locally. To resolve this issue, run the following command after restoring the connection between the ITSLA Server and the ITSLA Database:
scmd mem flushEvents
If you do not see another DYKME9034E error message in the log file, the data was stored in the ITSLA Database.
Event escalation
The following are known issues related to ITSLA event escalation. Some of them were encountered during the writing of this redbook.
Testing e-mail substitution variables

Perform the following steps to test the substitution variables in e-mail notification messages: 1. Use the following command to verify whether e-mail notification is enabled and if the recipients and SMTP server have been defined:
scmd escalate view
2. If they are not enabled and defined, issue the following command to configure e-mail notification:
scmd escalate enable Email -to email addresses [-cc email addresses -smtp SMTP_Server
For example:
scmd escalate enable Email -to bob@mycompany.com -smtp mailserver.mycompany.com
325
3. Run the following command to test the e-mail notification:

scmd escalate test
This command will send four sample e-mails to the users in the e-mail addresses above. 4. Verify that the e-mails reached their destination and examine each of the three following e-mail types for defined substitution variables: SLO violation SLO trend SLO trend cancelled By definition, substitution variables are character strings beginning with a dollar sign ($); however, when the above procedure is working correctly, the dollar signs will be replaced by sample text. If the substitution does not occur, follow the instructions in the next section to correct the problem.
Correcting problems with e-mail substitution variables

Perform the following steps if you are experiencing problems with the e-mail substitution variables: 1. Use the following command to determine if each message type (SLO violation, SLO trend, and SLO trend cancelled) has been associated with an e-mail message:
scmd escalate view
If any of the messages display all blanks, issue the following command, setting the message content to default and the event_type to either violation, trend, or cancelled:
scmd escalate customize Email -event event_type -content default
2. Issue the following command to determine the available substitution variables:

scmd escalate help
The variables shown in Example 8-8 are included in the English language version. The actual variables will differ with other languages.
326
Example 8-8 E-mail substitution variables

$MetricName $CustomerName $CustomerOrderId $ComponentName $ServiceOfferingName $RealName $ScheduleState $TrendProjectedDetail $ViolationDetail
Two notes concerning the above substitution variables: $TrendProjectedDetail is only used in SLO trend messages. $ViolationDetail is only used in SLO violation messages. 3. Use the following command to display all current e-mail message templates that contain substitution variables:
scmd escalate view
Within the above commands output, note any e-mail that does not contain the allowable substitution variables as described in the above example. If you do find any e-mail messages that do not contain an appropriate substitution variable, correct the e-mail with the customize command as described in step 1. You may customize the wording of the e-mail message by using the following command:
scmd escalate customize Email -event violation -content content
You may use any message you would like in the content section, as long as it is enclosed in double quotes and contains the appropriate substitution variable. You can display the command syntax by issuing the following:
scmd escalate customize help
4. Test the e-mail notification again after making the appropriate changes.
Error forwarding TEC Event

If either of the following error messages are received, events may be experiencing difficulty reaching the Tivoli Enterprise Control server: DYKSL1102E Error occurred while forwarding the Tivoli Enterprise Console event to the Tivoli Enterprise Control Server. DYKSL1104E Unable to send the event to the Tivoli Enterprise Console Server.
327
There could be several reasons why you are experiencing this problem: A network connection may not exist. The Tivoli Enterprise Control Server may be down. Escalation may not be correctly configured. The SLM.baroc file may not have been imported properly into the TEC Server. Perform the following steps to further diagnose this issue: 1. Issue the scmd escalate test command to test the Tivoli Enterprise Console escalation configuration. Proceed to step 2 if you receive a DYKSL1102E error, otherwise, proceed to step 4. 2. Verify that the Tivoli Enterprise Console Server is running. 3. If the Tivoli Enterprise Console Server is running, check to see if the SLM.baroc file was imported successfully. 4. Verify the escalation configuration by performing the following steps: a. Verify that the Tivoli Enterprise Console Server is configured correctly by issuing the scmd escalate view command. b. Ping the Tivoli Enterprise Console Server by using the address returned in step 2. If a network connection cannot be made, make sure that the Tivoli Enterprise Console Server name is correct. If the server name is not correct issue the scmd escalate enable -tec command to modify the Tivoli Enterprise Console Server name. c. Verify that the Tivoli Enterprise Control Server port being used is correct. If the port that is configured is incorrect, run the scmd escalate enable -tec command to modify the port number. 5. Once the Tivoli Enterprise Console Server is reachable, check to see if any Tivoli Enterprise Console Server events are cached locally by issuing the scmd escalate checkCache command. If the events are being stored locally, the ITSLA Server will attempt on an hourly basis to resend the events to the Tivoli Enterprise Console Server. You can use the scmd escalate flush command to retry sending the events immediately and the scmd escalate checkCache command to verify the events were sent. Refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833, for more details regarding the scmd escalate command.
328
SNMP notification problems

There is no way to determine if SNMP Traps reach their destination, since the traps use the UDP protocol to transverse the network. It is quite commonly assumed that the traps do reach their destination, unless an error is received concerning the inability of the SNMP API to open a socket on the local host. Use the CLI to verify connectivity between the trap daemon and IBM Tivoli Service Level Advisor; however, the ITSLA Database does not store test traps.
SNMP Trap definition missing

The enterprise OID used in all traps sent by IBM Tivoli Service Level Advisor is 1.3.6.1.4.1.2.6.168.2.3, as described in the SNMP Trap event notification section of the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. IBM Tivoli Service Level Advisor specifies four trap types for its events: Specific Type #1 = Violation Specific Type #2 = Trend Detect Specific Type #3 = Trend Cancel Specific Type #4 = Application Event If your SNMP Trap receiver is NetView for Windows NT, IBM Tivoli Service Level Advisor traps can be created and formatted using the addTrap example scripts shown in Example 8-9.
Example 8-9 addTrap example script
Example 1:Violation addtrap -l violation -n TSLA -i 1.3.6.1.4.1.2.6.168.2.3 -g 6 -s 1 -S 2 -o A -t 0 -c Application Alert Events -f - -F CustomerOrder=$1, Consumer=$2, Realm=$3, OfferingComponent=$4, Resource=$5, Offering=$6, StartDate=$7, EndDate=$8, BreachValue(Min)=$9, MetricValue(Min)=$10, BreachValue(Max)=$11, MetricValue(Max)=$12, BreachValue(Avg/Total)=$13, MetricValue(Avg/Total)=$14, ScheduleState=$15. Example 2: Trend Detect addtrap -l trend_warning -n TSLA -i 1.3.6.1.4.1.2.6.168.2.3 -g 6 -s 2 -S 2 -o A -t 0 -c Application Alert Events -f - -F CustomerOrder=$1, Consumer=$2, Realm=$3, OfferingComponent=$4, Resource=$5, Offering=$6, BreachValue(Min)=$7, ProjectedDate(Min)=$8, BreachValue(Max)=$9, ProjectedDate(Max)=$10, BreachValue(Avg/Total)=$11, ProjectedDate(Avg/Total)=$12, ScheduleState=$13. Example 3: Trend Cancel addtrap -l trend_cancel -n TSLA -i .3.6.1.4.1.2.6.168.2.3 -g 6 -s 3 -S 2 -o A -t 0 -c Application Alert Events -f - -F CustomerOrder=$1, Consumer=$2, Realm=$3, OfferingComponent=$4, Resource=$5, Offering=$6 Example 4: Application Event
329
addtrap -l app_event .3.6.1.4.1.2.6.168.2.3 -g 6 -s 4 -S 4 -o A -t 0 -c Application Alert Events -f - -F Failing Component = $1, $2
Additional modifications to these scripts may be required if NetView is being run on a different platform from Windows NT. Check the syntax of the addTrap command in your NetView documentation.
Backup and restore

The following are known issues related to ITSLA backup and restore. Some of them were encountered during the writing of this redbook.
No backup in UNIX destination directory

If your destination directory is empty after performing a backup on a UNIX machine, make sure that the destination directory is write-enabled. You may change the directory permissions, if needed, by issuing the following command:
chmod 777 dest_directory
SQL1116N when connecting to ITSLA Database

If you receive this error, the database you are trying to connect to is in a backup pending state. Connections to this database will not be allowed until a backup has been performed. Major configuration changes to a database will cause this error.
SQL1117N when connecting to ITSLA Database

If you receive this error, the database you are attempting to connect to is in a roll forward pending state. Connections to this database will not be allowed until the database is rolled forward. If the database receives a recover database command or a major database system event has occurred, this error message will be seen.
DYKUT168E when running backup and restore commands

When running the slmbackup, slmbackup -start, and slmrestorerestart commands, IBM WebSphere Application Server Versions 4.0 AE and 3.5 SE may be inadvertently stopped and restarted. IBM WebSphere Application Server Version 4.0 AES is currently the only IBM WebSphere Application Server version used by IBM Tivoli Service Level Advisor that supports the automatic startup and shutdown procedures during a backup and restore procedure. Refer to the backup and restore procedures described in the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835, for more information.
330
CLI Service issues

The following are known issues related to CLI Service issues. Some of them were encountered during the writing of this redbook.
Disable source application failure

If you receive an error message when trying disable a source application by using the scmd etl disable command, that source application may have results tied to an existing customer order. You can only disable a source application if the source application data evaluations have not resulted in a violation or a trend. This is because once the violation or trend has been evaluated, the customer offering and order associated with these monitoring results cannot be removed from the ITSLA Database.
No connection to CLI Service

There may be a connectivity problem between the CLI client interface and the CLI Service if you receive the following error message when issuing a scmd command:
DYKAL2030E Unable to connect to the CLI service on port CLI_client_port_number
Perform the following steps: 1. Search for the following error message in the stdout or SLMMessagen.log file:
DYKAL2020I: The CLI service was created and listing on port CLI_Server_port_number
If this message is found in the above log files, the CLI client may be the problem. For later use, note the port_number. If the message was not found in the above log files, the CLI Service may not have started correctly. Proceed to step 3 if this is the case. 2. In the case that the problem stems from the CLI client, perform the following steps to check the CLI port configuration: a. Recall the CLI_client_port number that was displayed in the DYKAL2030E error message. b. Recall the CLI_Server_port_number that was displayed in the DYKAL2020I error message. If you did not record this port number, run the following command on the ITSLA Server machine:
cliutil getPort
331
c. If the two ports are the same, the problem may be related to temporary network connectivity issues. If the ports are different, match the two port numbers by running the following command on the CLI client machine:
cliutil setport CLI_Server_port_number
Verify if the problem is resolved by issuing the original scmd command. d. If it is determined that it is not a network connectivity issue, and you are still experiencing the error, contact Tivoli Customer Support. 3. Check the ITSLA Server stderr or the SLMMessagen.log file for the following error message if you did not receive the DYKAL2020I error as described in step 1:
DYKAL1054E: Component localhost.CLI:y failed setup with the following error: x
The ITSLA Servers fully qualified host name should be located in the localhost field above, with y representing an integer value, and x being the related error message. Proceed to step 4 if you do not see this error in the above-mentioned log files. If you do find the above error, this means that the CLI Service was not correctly started. The CLI Service startup will soon be attempted again by the ITSLA Server. If you notice the problem persists, recall the error message denoted by x in the above output and look up specific explanations and recovery procedures for this error. 4. Search for the following messages in the stdout and SLMessagen.log files if you did not find the DYKAL1054E error message in step 3:
DYKAL1020I Component startup activities have completed: DYKAL1000I Starting component localhost:CLI:Y.
Contact Tivoli Customer Support if you do not find the DYKAL100I message but do find the DYKAL1020I message. This means that the CLI Service is not registered to start up. 5. It may be possible that the CLI Service has not finished starting up. Wait and reissue the original scmd command once the DYKAL1000I message is displayed in the log files. If the CLI Service still cannot be started, restart the ITSLA Server and try again. If this message never shows up in the log files, contact Tivoli Customer Support. You may receive different messages relating to the CLI Service not being able to start. Refer to the following example if this is the case and take the corrective action as displayed in the error messages.
Example 8-10 CLI Service example
DYKAL2045E Unable to create the CLI service on port port_number. The CLI service has not been started.
332
DYKAL2046E Unable to create the CLI service on port port_number. The port is already in use. The CLI service has not been started. DYKAL2047E Unable to create the CLI service on port port_number. The CLI service has not been started. DYKAL2011E The CLI service could not be created on port port_number. The CLI service could not be started. DYKAL2012E The CLI service was not started properly.
Refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833, for further information on the cliutil commands and the CLI Service.
Host name not fully qualified

Configure your system to use fully qualified host names if you receive either of the two following error messages: When issuing a scmd command:
DYKAL2030E Unable to connect to the CLI service on port 9990.
If you find the following message in the SLMMessagen.log file:

DYKAL0009E The server host name hostname is not a fully qualified host name. DYKAL1020I Component startup activities have completed:0 started, 0 timed out, 0 failed.
Necessary services related to the ITSLA Server may not be started if the machine is not configured with a fully qualified host name. Any machine on which the ITSLA Server, ITSLA Task Drivers, and ITSLA Reports reside must be set up with fully qualified host names.
Only rcc, log, and slm bundles show when issuing scmd list
The ITSLA Server may not be able to connect to the ITSLA Measurement Data Mart if only the rcc, log, and slm bundles are reported as being available when issuing the scmd list command. Check the SLMMessagen.log file for the following error message:
DYKAL1054E Component yourmachine.some.company.com:DS:1 failed startup with the following error: DYKAL3002E An error occurred for sdc during DataSource creation.
333
Below are the most common causes for this problem: You may see the following error in the ITSLA Server stderr or the SLMMessagen.log file if the db2start command has not been issued on the database server:
DYKAL3014E Error connecting to the database. Reason:[IBM][CLI Driver] SQL1032N No start database manager command was issued. SQLSTATE=57019
Verify that the db2start command has been issued on the database server. You may see the following error in the ITSLA Server stderr or the SLMMessagen.log file if the db2java.zip file is not located in the system CLASSPATH:
DYKAL3013E Error loading driver COM.ibm.db2.jdbc.app.DB2Driver
If you do receive the above error, verify the following steps, dependent on your operating system: For Windows, issue the following command from a command prompt:
set classpath
Ensure that the db2java.zip file path is correct in the above commands output. If the location is not correct, correct the value in the Windows environment variable dialogue and restart the ITSLA Server. For UNIX, verify the paths for the db2profile and usejdbc2 scripts in the TSLA_Dir/bin/private/generic_unix/runscripts/slmdbsetup.sh file, where TSLA_Dir is the installation location of IBM Tivoli Service Level Advisor. Ping the database server to verify network connectivity.
CLI Service password reset

You may use the cliutil script if the CLI Service password has been forgotten or corrupted. It is located in the TSLA_Dir\bin directory, where TSLA_Dir is the installation location of IBM Tivoli Service Level Advisor, and may be run as shown below:
cliutil resetpassword
This command initially sets the CLI Service password to password. The scmd setPassword command must then be used to set the password to a desired value.
Modifying the CLI port

In order to retrieve the port being used by the CLI Service or to change the port number, you may use the cliutil script. Issue the following command to list the current port number:
cliutil getport
334
To modify the CLI Service port, run the following command:

cliutil setport port
Use an available port value for port.
Updating the ITSLA Server and Administration Server port

Issue the following command to display the communication port being used by IBM Tivoli Service Level Advisor on the ITSLA Server machine:
scmd rcc getport
You may modify this port number by running the following command:
scmd rcc setport port
If you would like to modify the communication port on the IBM Tivoli Service Level Advisor Administration Server machine, issue the following command, which is located in the TSLA_Dir/bin directory, where TSLA_Dir is the installation location of IBM Tivoli Service Level Advisor:
rcomutil hostname port
The hostname entry should be replaced with the fully qualified host name of the Administration Server machine.
ITSLA service issues

The following are known issues related to ITSLA services issues. Some of them were encountered during the writing of this redbook.
Out of Java memory

You may perform the following steps if you notice that your Java memory is running low: For Windows, you may perform either of the following procedures: Alter the registry by using the regedit command: Enter regedit in the Start -> Run box. Locate the following path:
My Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ tslm\Parameters
Locate the following:

Name: jvmOption5
Change the -Xmx384m parameter to a larger number, such as 512 or 1024.
335
You can also modify the tslmconfig file as shown in the following: Shut down the ITSLA Server with the net stop tslm command. Locate the following directory on the ITSLA Server machine, where TSLA_Dir is the installation location:
TSLA_Dir\bin\common
Modify the -Xmx384m parameter in the tslmconfig file, by changing the number 384 to something larger, such as 512 or 1024. Go back to the TSLA_Dir\bin directory. Temporarily remove the IBM Tivoli Service Level Advisor service by running the following command from a command line:
jservice -u TSLA_Dir\bin\common\tslmconfig
Restore the IBM Tivoli Service Level Advisor service by issuing the following command from a command line:
jservice -u TLSA_Dir\bin\common\tslmconfig
Start the ITSLA Server with the net start tslm command.
For UNIX, perform the following: Stop the ITSLA Server on the ITSLA Server machine by running the following command, where TSLA_Dir is the installation location:
./slm_service_stop.sh
Edit the slm_start.sh file in the TSLA_Dir/service_util directory by changing the 384 value in the -Xmx384m parameter to a larger number, such as 512 or 1024. Run the following command to restart the ITSLA Server:
./slm_service_start.sh
Performance concerns on multi-processor systems

If you are running IBM Tivoli Service Level Advisor on a multi-processor machine and notice that during specified evaluation times some of your processors are idle, contact Tivoli Customer Support to help configure your multi-processor system.
ITSLA Server starts no components on multi-homed hosts

If your ITSLA Server machine is configured with two or more network addresses or is connected to two separate local area networks, the ITSLA Task Drivers machine may attempt to use the wrong IP address when trying to connect to the ITSLA Server machine. If you receive a DYKGU0087E error message when attempting to submit an order, check the errors within the above error message.
336
Check the IP address in the referenced message if you notice that errors indicate a refusal of connection or an inability to reach the host. Perform the following steps if the ITSLA Task Drivers cannot access the referenced IP address in the error message: For Windows, perform the following: a. Enter regedit in the Start -> Run text box. b. Locate the following:
My Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tslm\ Parameters
c. Create a new string value name jvmOption6. d. Use the fully qualified host name of the ITSLA Server when modifying the following data value:
-Djava.rmi.server.hostname=SLM_Server_Hostname
e. Restart the ITSLA Server. For UNIX, perform the following: a. Locate the slm_start.sh file in the TSLA_Dir/service_util directory. b. Add the following JVMARGS environment variable, using the fully qualified ITSLA Server host name:
-Djava.rmi.server.hostname=SLM_Server_Hostname
c. Restart the ITSLA Server.
8.4.4 Un-installation issues

Below you can find a troubleshooting tip that may help you if you decide to un-install IBM Tivoli Service Level Advisor. For more information on IBM Tivoli Service Level Advisor un-installation procedures, consult Getting Started with IBM Tivoli Service Level Advisor Version 1.1, SC32-0834.
Un-installing ITSLA install options

If when un-installing IBM Tivoli Service Level Advisor you find that the provided un-install script does not work, you may run the following command to perform the un-install, but only if you have a Java runtime environment locally installed:
java -jar _uninst/uninstall.jar
337
8.5 IBM Console

The IBM Console serves as the core portal for entering IBM Tivoli Service Level Advisor. In the following sections you will find suggestions for troubleshooting possible logon issues and administration steps for the IBM Console. For more information regarding the IBM Console, refer to Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.
8.5.1 Logon problems (UNIX platforms)

If you experience problems logging onto the IBM Console, check to see if the problem you are having is included in the following sections.
Logon screen hangs (UNIX platforms)

Try the following steps if you are on a UNIX platform and the logon to the IBM Console hangs: 1. On the machine that is running the Web Services for IBM Console, verify that X-Windows is running. 2. Make sure that there is a functional, physical console attached to the same machine. 3. Edit the PS/bin/private/generic_unix/wc.sh file and add the following lines to the top of the file, right after the comments:
DISPLAY=hostname:0 export DISPLAY
4. Make the same changes to the PS/bin/private/generic_unix/mcr.sh file. 5. Stop the Web Console process by issuing the stopsrc -s tcwebsvcs command. You can check to see if the process has stopped by running ps -ef |grep java and looking for the WcOrbletApp process. 6. Stop the MCR process using the stopsrc -s tcserver command. You can check to see if it has stopped by issuing ps -ef |grep java and looking for the McOrbletApp process. 7. After the two above processes have stopped, restart the MCR process using the startsrc -s tcserver command. To check to see if MCR is up, issue the netstat -na |grep 8010 command and see if the port is LISTENING. 8. Start the Web Console by using the startsrc -s tcwebsvcs command. Perform the same netstat command as above to verify that the Web Console is up and running.
338
9. Verify that both PS processes have a display argument of localhost:0 by issuing the ps -ef |grep java command and searching for the following output:
-Dcom.tivoli.pf.display.name=localhost:0
8.5.2 Administration problems

In the following sections, tips for administering the IBM Console are included.
Optimizing screen resolution

If windows displayed by the IBM Console do not appear to be displayed properly, try setting your screen resolution to 1024 x 768.
Help information not available in Task Assistant

When trying to open the Task Assistant in the Web Console, user assistance may not be available if the machine was rebooted before the original help set build had completed. You can manually build the help set by running the following commands, depending upon your operating system: For Windows:
PS\bin\w32-ix86\rebuildHelp.bat
For UNIX:
PS/bin/generic_unix/rebuildHelp.sh
Building the help set could take anywhere from 30 to 60 minutes for an English-only installation, and possibly longer for non-English installations.
Changing IP addresses
You may experience an excessive usage of CPU resources if you change IP addresses after installing IBM Tivoli Service Level Advisor. If you are experiencing this problem, replace your old IP address with your new IP address in the following file, where PS is the PS installation directory:
PS/ibmhttpd/conf/httpd.conf
Out of memory
If you find memory errors in any of the logs in the PS/logs/fwp_wc directory, you can resolve the issue with the steps found below, depending on your operating system. For Windows: 1. Enter regedit in the Start -> Run text box.
339
2. Locate the following path:

My Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ps_wc\ Parameters
3. Find the following values:

Name: jvmOption8 Type: REG_SZ
4. Change the number 384 in the Value: -Xmx384m parameter to a larger number, such as 512 or 1024. This value size varies, depending upon the amount of memory you have in your system. For UNIX: 1. Edit the file PS/bin/private/generic_unix/wc.sh. 2. Locate the following line and change the 384 value to a higher number, such as 512 or 1024, depending on the amount of memory in your system:
JVMARGS=$JVMARGS -Xmx384m
Authorization for password changes

Only those users with the following roles are allowed to change the password for the IBM Console: Administration Authorized Tasks Administration portfolio entries Note that access to these user roles should be limited to only certain administrators. Those users that have these roles are able to manage all user accounts, as well as change the password for any user.
Language mix in console

If you are seeing mixed language messages in the IBM Console, you may not have the IBM Tivoli Service Level Advisor language packs installed. If you set your local browser to a non-English language, you will see translated information in the base IBM Console, as translation support is included with the IBM Console. The IBM Tivoli Service Level Advisors graphical user interface items will not be translated, as they plug into the IBM Console and require the installation of the language pack. To resolve this issue, set your local browser to English if you have not yet installed the language pack and before you log into the IBM Console. After installing the language pack, you may set your local browser to any language you wish.
340
8.6 TEDW Source ETLs

In the following sections we present the known issues with Source ETLs or warehouse packs.
8.6.1 Installation issues

If you encounter problems when trying to install the TEDW Source ETLs, also referred to as Warehouse Enablement Packs, refer to the following section on installation failure.
Installation failure
You may receive the following error when trying to install the Target ETL:
CDWIA0002W General errors were detected. Review the installation logs to ensure that messages indicate conditions that are acceptable.
On the Windows machine where the Control Server was installed, search the following log files for the given errors below, where %TEMP% represents Windows TEMP environment variable: %TEMP%\tmptedw_1_1_install\TWHInstall.log Search for the following error:
CDWIA0092E Cannot import the metadata into the DB2 Warehouse Center using the .tag file.
%TEMP%\dyk_dwc_data.log Search the very bottom of this file for the text shown n Example 8-11.
Example 8-11 dyk_dwc_data.log sample
Import ended for tag file:C:/TWH/apps/dyk/v110/etl/dyk_dwc_data.tag Return Code/subCode = 13702/0 Method:DataResource_addRel Message:DWC13702E A primary key already exists and cannot be updated. The import process cannot continue. Chkpid completed = 920 Stop time: 03/01/02 15:56:09
If you do see these errors, the IBM DB2 APARs for Tivoli Enterprise Data Warehouse have not yet been installed. The importing of ETLs require these fixes.
341
Consult the following Web site for more information regarding the download and install procedures for APARs JR16650 and JR16766:
http://www.ibm.com/software/sysmgmt/products/support/ TivoliEnterpriseDataWarehouse.html
Try again to install the Warehouse Enablement Pack after downloading and installing the above APARs.
8.6.2 Configuration issues

After installing the Warehouse Enablement Packs, refer to the following section if you experience difficulty when configuring the enablement packs.
Error promoting ETL to production mode

If you receive IBM DB2 error codes DWC02015E with an SQLSTATE of 01517 when trying to change the ETL mode to production, you may need to change your DB2CODEPAGE environment variable. If your Warehouse Center machine is using a non-English language, follow the below steps to resolve this issue. The steps are slightly different for Windows NT and Windows 2000. For Windows NT, perform the following: 1. Right click My Computer on your desktop and select Properties. 2. On the System Properties tab, select Environment. 3. Define a system variable called DB2CODEPAGE with a value of 1208. There will be other variables listed there such as DB2INSTANCE and DB2TEMPDIR. 4. After you assign the variable with its value, click Set and then OK. 5. Reboot your machine for the changes to take effect. For Windows 2000, perform the following: 1. Right click My Computer on your desktop and select Properties. 2. Click the Advanced tab on the System Properties panel. 3. Click the Environment Variables button. 4. Under the System variables box, click New and define a variable name of DB2CODEPAGE with a variable value of 1208. 5. Close each box by clicking the OK button. 6. Reboot your machine for the changes to take effect.
342
Logging into Tivoli Enterprise Data Warehouse

If you are unable to log onto the IBM DB2 Data Warehouse Center, try restarting the following processes from the Service control panel: Warehouse Logger Warehouse Server These services may have been disconnected if the Tivoli Enterprise Data Warehouse database server was stopped by the dyk_dm_dbinst and dyk_cat_dbinst scripts.

In this section you will find a number of troubleshooting hints and tips covering the administration of the Warehouse Enablement Packs.
ETL step failed

If you notice a failed ETL status in the IBM DB2 Data Warehouse Center Work in Progress window, examine the appropriate log file in the DB2_Dir\sqllib\logging directory, where DB2_Dir is the installation location of IBM DB2. The failed steps name will be located in the log file title. Do the following steps to verify database connectivity: 1. Ensure that the TWH_CDW, DYK_CAT, and DYK_DM ODBC data sources have been created successfully. 2. Verify that the correct user IDs and passwords have been entered for the Warehouse source and target databases. 3. For each database preceded by DYK, expand the warehouse source and target folders and attempt to sample a tables contents. 4. Issue the following command from an IBM DB2 command line to verify that a database connection exists:
db2 connect to db_name user user_id using password
Refer to Getting Started with IBM Tivoli Service Level Advisor Version 1.1, SC32-0834, for more information on manually creating ODBC data sources.
ETL failure recovery

You may experience problems if either of the following situations occur: A Target ETL is run while a Source ETL is still running. After a Source ETL completes, a Target ETL is run multiple times, causing the retrieval of duplicate data.
343
Perform the following steps to recover from the above situations: 1. You can rebuild the DYK_DM database by rerunning the dyk_dm_dbinst script. 2. Reset the EXTRACT_CONTROL values in the TWH_CDW database by running the following commands from a IBM DB2 command prompt:
db2 connect to twh_cdw user db2_user using password db2 update twg.extract_control set (EXTCTL_FROM_INTSEQ, EXTCTL_TO_INTSEQ) = (0,0) where EXTCTL_SOURCE=TWG.MSMT and EXTCTL_TARGET=DYK.STAGE_MSMT db2 disconnect twh_cdw
You can now repopulate the DYK_DM database by scheduling the Process ETL after completing the above steps.
Cannot list installed Warehouse Packs

You may have to edit the twh_app_install_list.cfg file if you receive the following error message when trying to list the installed Warehouse packs:
==> Reading Config File (twh_app_install_list.cfg) (F) CDWIC0005E Error. Property APPLICATION_TO_DELETE not found in config file.
If you do receive this error, locate the twh_app_install_list.cfg file and place an X in the APPLICATION_TO_DELETE= field. When you run the command again, you should receive a list of the installed Warehouse packs.
8.7 IBM Tivoli Service Level Advisor Reports

In this section you will find numerous troubleshooting hints and tips regarding ITSLA Reports. For more information concerning ITSLA Reports, refer to the Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835, and the IBM Tivoli Service Level Advisor Release Notes Version 1.1, GI11-0908.
8.7.1 Accessing Reports

When signing into ITSLA Reports, you may experience difficulty connecting to the ITSLA Databases if you receive an HTTP 500 Error (the page cannot be displayed) or the following error message:
DYKAL3003E A Data Source for sdc was not found in my ITSLA Reports message log.
344
Perform the following steps to resolve these errors: 1. On the ITSLA Reports Server, search for the following error messages in the stderr and the SLMMessageX.log files: DYKAL1054E Component yourmachine.somecompany.com_servlet:DS:1 failed startup with the following error:DYKAL3002E An error occurred for sdc during Data Source creation. If the IBM DB2 server has not been started, you may receive this error. Make sure the db2start command has been issued on the database server. DYKAL3013E Error loading driver COM.ibm.db2.jdbc.app.DB2Driver. If the db2java.zip file is not located in the CLASSPATH variable, you may see this error. Refer to 4.6.1, IBM WebSphere installation and configuration on page 127, for how to configure the JDBC level. You should see the following messages in the ITSLA Reports SLMMessagex.log file after recovering from this error:
DYKAL3005I Driver loaded successfully. DYKAL3001I Data Source successfully created for sdc. DYKAL1001I Started component yourcomputer.somecompany.com_servlet:DS:1
2. Dependent on your IBM WebSphere Application Server version, open the web.xml file: For IBM WebSphere Application Server SE 3.5, the file should be located in the following directory if all suggested defaults were taken when deploying the SLMReport.war file:
WebSphere_Dir/AppServer/hosts/default_host/SLMReport/servlet/Web-inf
For IBM WebSphere Application Server AE or AES, Version 4.0.1 or 4.0.2, the file is located in the following directory:
WebSphere_Dir/AppServer/installedApps/SLMReport.ear/SLMReport.war/Web-in f
Edit the web.xml file using a text editor, verifying that the file names associated with slm.configLocation and slm.logLocation point to the correct configuration and log locations. For example, if the ITSLA Server is installed in C:\TSLA, the log location will be C:\TSLA\log\SLMReport and the configuration location will be C:\TSLA\cfg. The specific code in the web.xml file will appear similar to the following:
<init-param id=InitParam_1> <param-name>SLM.configLocation</param-name> <param-value>c:\Tsla\cfg</param-value> </init-param> <init-param id=InitParam_2> <param-name>SLM.logLocation</param-name>
345
<param-value>c:\Tsla\log\SLMReport</param-value> </init-param>
Save and close the file when finished. 3. If the web.xml file is correct, look for detailed errors in the following log files: For IBM WebSphere Application Server SE 3.5: stdout.log For IBM WebSphere Application Server 4.0.1 or 4.0.2: Default_Server_stdout.log Possible errors included in the above log files may be: Database tables missing Incorrect user name or password used when connecting to the database Use the dsutil utility to verify that the user ID and password are correct if you receive the error DYKAL3014E in any of the above log files. Refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833, for more details on running the dsutil utility.
Accessing Reports - IBM WebSphere SE 3.5

When signing into ITSLA Reports running on IBM WebSphere Application Server SE 3.5, you may receive the following error message:
HYKRP0009E Empty database results returned. Please report this error to Administrator.
This error can be corrected by following these steps: 1. Make sure the db2java.zip file is included in the CLASSPATH variable. If it is not, do the following: a. Select the Web application name under Nodes SLMReport servlet engine on the WebSphere server screen. b. Select the Advanced tab, and under Classpath, make sure the db2java.zip file directory path is included. If it is not, enter the directory path in the empty row and click Apply. For example, the directory path may appear as follows:
C:\DB2\java\db2java.zip
2. Stop the application server by performing the following: a. Right click the report server name (for example, SLMReportServer) in the Administrators Console and click Start if the Start option is enabled.
346
b. Run the following commands from the command line:

C:\>wscp
After you receive the wscp> prompt, enter the following:

wscp>ApplicationServer start /Node:your hostname/Application Server:ReportServerName/
For example, enter the following all on the same line:

wscp>ApplicationServer start /Node:myHost/ApplicationServer:SLMReportServer
3. Try to view the ITSLA Reports again. More error information can be found in the stdout.txt and stderr.txt files that were created during the ITSLA Reports integration.
Accessing Reports with IBM WebSphere AES 4.0

An incorrectly specified node name will cause you to experience problems when trying to access ITSLA Reports when using IBM WebSphere Application Server AES 4.0. Check for the following error message in the TSLMInstall.log file:
CommandExecutionException: Unable to select node: the requested node is not available.
You can correct this error message by performing the following steps: 1. On the ITSLA Report server, find the ITSLA_Install_Dir/bin/aes40reportgenplugin script file, where ITSLA_Install_Dir is the location where ITSLA was installed. 2. Using a text editor, open the aes40reportgenplugin file and locate the NODE_NAME parameter. 3. Edit the NODE_NAME parameter, if needed, save that, and execute the script. 4. Verify that the WebSphere_dir/config/plugin-cfg.xml file contains the following line, where WebSphere_dir is the WebSphere installation directory:
<Uri Name=/SLMReport/>
5. Save and close the XML file. 6. Stop and restart the WebSphere Application server. You should now be able to access ITSLA Reports from your Web browser.

Below you will find a couple of pointers to help when administering ITSLA Reports.
347
Cleaning up after installation failure

If the installation of ITSLA Reports fails, and you are running WebSphere AES, the WebSphere_dir/AppServer/installedApps/SLMReport.ear folder must be deleted manually. Navigate to the WebSphere_dir/AppServer/bin directory and run the following command, dependent on the operating system: For Windows:
SEAppInstall - uninstall SLM Report Application Server -delete true
For UNIX:
./SEAppInstall.sh -uninstall SLM Report Application Server -delete true
IIS
If you install ITSLA Reports on a Windows system that has IIS enabled, you must disable IIS before WebSphere is installed. This will release port 80 to be used by WebSphere, also allowing ITSLA Reports to be viewed using the same port.
8.7.3 Workarounds for ITSLA Reports

In the following section you will find important information regarding known workarounds and limitations for ITSLA Reports. For more information, refer to the IBM Tivoli Service Level Advisor Release Notes Version 1.1, GI11-0908.
Log files not deleted during un-install

After un-installing ITSLA Reports, you may notice that you are unable to delete the ITSLA Reports log files. In order to permanently delete these files, you must first shut down the WebSphere Application Server. You should not receive any more sharing violations after doing this.
Limitations with printing reports

If you notice that some of the data is being cut off when trying to print ITSLA reports, perform the following steps to remedy this problem: 1. Set your print paper orientation to landscape.
348
2. Dependent on the browser used, set all print page margins to the following values: 0.5 inches for Netscape 0.7 inches for Microsoft Internet Explorer Different printers may require different procedures.
Multiple Report sessions providing unexpected results

Unexpected results may occur if more than one ITSLA Reports screen is started on the same client machine. When opening additional report screens on the same machine when using Netscape, any settings that were set on the previous sessions will be overwritten. When using Microsoft Internet Explorer, if one screen is logged off, the same may occur to all sessions opened from the same window. Perform the following steps to guard against these issues: For Microsoft Internet Explorer, open any additional session by using the shortcut on the desktop or from Start Programs on Internet Explorer. For Netscape, only use one browser when connecting to ITSLA Reports.
Issues with non-alphanumeric characters

When a single quote character () appears in a customer name, resource name, realm name, or offering component name, you may receive the following error message:
DYKRP0009E Empty database results were returned. Please report this error to the administrator.
To resolve this problem, type 27% following every occurrence of 27% in the URL address field of your Web browser, and then press Enter to load the page. Using the refresh button (Internet Explorer) or reload (Netscape) button will not work, as it will reload the original URL.
349
350
Part 2
Part
Appendixes
351
352
Appendix A.
Hints and tips for un-installing ITSLA

This appendix will cover the un-installation of an IBM Tivoli Service Level Advisor environment from your enterprise environment with focus on the following tasks: Un-install the ITSLA core components ITSLA Server ITSLA Reports ITSLA Task Drivers Un-install the ITSLA ETL application packages. Process Target ETL Registration Target ETL Remove the ITSLA Databases ITSLA Database (DYK_CAT) ITSLA Measurement Data Mart database (DYK_DM)
353
Un-installing the ITSLA core components

When you run the un-install command, it will start the InstallShield Wizard for the IBM Tivoli Service Level Advisor program. This program does not allow you to do a selective un-install. You will have to take the following into consideration when preparing your un-install: If all the ITSLA components are on the same machine and in the same directory, all the features installed in that directory will be un-installed after running the un-install process once. If all the ITSLA components are on the same machine but in different directories (which can be done if you run the installation program on the same machine specifying a different install directory for each of the install options), the un-install process must be run against each directory where each installed feature is located. The un-install program may not be able to remove all of the files in the ITSLA install directories. You will have to manually delete these files, and then delete the directories. You might have the ITSLA Server, ITSLA Reports, and ITSLA Task Drivers components all installed on one machine, or on different machines. If the components are installed on different machines, you have to un-install them in the following order: 1. Un-install ITSLA Task Drivers. 2. Un-install ITSLA Reports. 3. Un-install ITSLA Server. During the un-installation, a log file is created for each ITSLA component that you un-install. The log file is located in the install directory (for example, C:\TSLA on Windows and /opt/TSLA on UNIX) for each of the features. You can browse through the file TSLMUninstall.log to see if any errors occurred during the un-install.
Un-installing ITSLA Task Drivers

To un-install the ITSLA Task Drivers component, perform the following steps: 1. Make sure that the Server for IBM Console service is running. Issue the following command to start the service if it is not running: On Windows NT/2000:
net start ps_mcr
354
On UNIX, from a command prompt, navigate to the PS_Dir/bin/generic_unix directory, where PS_Dir is the directory where Tivoli Presentation Services is installed, and run the following command:
./mcr.sh
2. Issue the following command from the ITSLA Task Drivers install directory (for example, C:\TSLA on Windows and /opt/TSLA on UNIX) to start the InstallShield Wizard for IBM Tivoli Service Level Advisor: On Windows NT/2000:
uninstall.bat
On UNIX:
./uninstall.sh
3. During the un-install the InstallShield wizard program will try to stop and restart the Web Services for IBM Console service. If an errors occur and you have to do it manually, issue the following commands: On Windows NT/2000:
net stop ps_wc net start ps_wc
On UNIX, from a command prompt, navigate to the PS_Dir/bin/generic_unix directory, where PS_Dir is the directory where Tivoli Presentation Services is installed, and run the following command:
./stopwc.sh ./wc.sh
4. Removing ITSLA Task Drivers does not remove the installed files and the ITSLA install directory automatically. You have to remove these manually.
Un-installing ITSLA Reports

To completely un-install the ITSLA Reports component, do the following: 1. Issue the following command from the ITSLA Reports install directory (for example, C:\TSLA on Windows and /opt/TSLA on UNIX) to start the InstallShield Wizard for IBM Tivoli Service Level Advisor for the un-install: On Windows NT/2000:
uninstall
On UNIX:
./uninstall.sh
2. Un-installing ITSLA Reports does not remove the installed files and the ITSLA install directory. You have to remove these manually.
Appendix A. Hints and tips for un-installing ITSLA
355
During the installation of ITSLA Reports on the IBM WebSphere Application Server machine, if ITSLA Reports was automatically integrated into the IBM WebSphere Application Server AES environment, the un-install process will automatically remove the ITSLA Reports component.
IBM WebSphere Application Server AES

If you need to remove ITSLA Reports manually from IBM WebSphere Application Server AES, do the following: 1. Navigate to the WebSphere_DIR /bin directory, where WebSphere_DIR is the directory where IBM WebSphere Application Server AES was installed (for example, C:\WebSphere\AppServer on Windows and /usr/WebSphere/AppServer on UNIX). Stop the IBM WebSphere Application Server AES by issuing the following command: On Windows NT/2000:
stopServer.bat
On UNIX:
./stopServer.sh
2. Run the following command from the same directory as in the previous step: On Windows NT/2000:
SEAppInstall -uninstall SLM Report Application Server -delete true -nodeName node
On UNIX:
./SEAppInstall.sh -uninstall SLM Report Application Server -delete true -nodeName node
Where node is the IBM WebSphere Application Server AES node name that was specified during installation.
356
IBM WebSphere Application Server AE

If you are running IBM WebSphere Application Server AE Version 4.0, you will have to remove the ITSLA Reports manually, as follows: 1. Start the IBM WebSphere Admin Server for IBM WebSphere Application Server Version AE 4.0 by doing the following: For Windows NT/2000: From a command prompt, navigate to the WebSphere_Dir\bin directory, where WebSphere_Dir is the directory where WebSphere was installed (for example, C:\WebSphere\AppServer), and run the following command:
startupServer.bat
For UNIX: Verify that you are logged on as the root user. From a command prompt, navigate to the directory WebSphere_Dir/AppServer/bin, where WebSphere_Dir is the directory where IBM WebSphere Application Server AE was installed, and run the following command:
./startupServer.sh
IBM WebSphere Application Server SE

If you are running IBM WebSphere Application Server SE Version 3.5, you will have to remove the ITSLA Reports manually, as follows: 1. Start the IBM WebSphere Admin Server for IBM WebSphere Application Server SE Version 3.5 by doing the following: For Windows, do any of the following: Select Start -> Programs -> IBM WebSphere -> Application Server V3.5 - > Start Admin Server. From the Services control panel (Start -> Settings -> Control Panel -> Services) right click IBM WebSphere Admin Server and select Start from the context menu. From a command prompt, navigate to the WebSphere_Dir\bin directory, where WebSphere_Dir is the directory where IBM WebSphere Application Server was installed (for example, C:\WebSphere\AppServer), and run the following command:
startupServer.bat
For UNIX, do the following: Verify that you are logged on as the root user.
357
From a command prompt, navigate to the directory WebSphere_Dir/AppServer/bin, where WebSphere_Dir is the directory where IBM WebSphere Application Server was installed, and run the following command:
./startupServer.sh
Un-installing ITSLA Server

To un-install the ITSLA Server feature, do the following: 1. Shut down the ITSLA Server by stopping the IBM Tivoli Service Level Advisor service. Issue the following command: On Windows NT/2000:
net stop tslm
On UNIX: Navigate to the ITSLA_Server_Install_Dir/bin directory, where ITSLA_Server_Install_Dir is the location where the ITSLA Server was installed. Issue the following command:
./slm_service_stop.sh
2. Issue the following command from the ITSLA Server install directory (for example, C:\TSLA on Windows and /opt/TSLA on UNIX) to start the InstallShield Wizard for IBM Tivoli Service Level Advisor for the un-install: On Windows NT/2000:
uninstall.bat
On UNIX:
./uninstall.sh
3. Un-installing ITSLA Server does not remove the installed files and the ITSLA install directory. You have to remove it manually. 4. After the un-install script has completed, reboot your machine if you un-installed from Windows. This will fully remove IBM Tivoli Service Level Advisor from the list of system services and remove files that may have been in use during the un-install.
358
Un-installing the ITSLA Target ETL programs

As part of un-installing IBM Tivoli Service Level Advisor from your enterprise environment, you have to un-install the Target ETL. The process of un-installing the ITSLA Target ETL programs is the same as un-installing any ETL from the TEDW Control Center machine. In this section, we describe the steps to perform to un-install any ETL warehouse pack (Target or Source ETLs), depending on the product code that you enter in the config file. The following command line utility is available to help with the un-install:
TWH_TOPDIR\install\bin\twh_app_deinstall.sh
Where TWH_TOPDIR is the directory where you installed TEDW Control Center. Un-installing an application package deletes the application pack files and related database objects. The files for each warehouse pack are located in the installation directory TWH_TOPDIR\apps\Product_Code, where TWH_TOPDIR is the directory where you installed TEDW Control Center and Product_Code is the unique three-character identifier for the application. The following items are deleted during the application pack un-installation: Application pack files and directories Report interface data marts (not applicable for the ITSLA Target ETLs) Tables in the TEDW Data Mart database Star schemas used to define TEDW Data Marts TEDW Report Interface reports (not applicable for the ITSLA Target ETLs) Saved report output ETL processes for the application pack Staging tables used by the ETL processes in the TEDW Central Warehouse database TEDW Data Marts can contain star schemas created by more than one application pack. Therefore, the un-installation program checks star schema relationships before un-installing and does not un-install an application pack if any of its star schemas are used in a data mart from another application pack. You must manually resolve the applicable star schema relationships before you can un-install the application pack. You will find a list of the application packages you can un-install in the TWH_TOPDIR \apps directory. Each application package has to be un-installed separately, one at a time.
359
A list of the product codes for the applications are: dyk apf bwm dmn eco gtm ITSLA Target ETLs IBM Tivoli Monitoring for Transaction Performance (TAPM) IBM Tivoli Monitoring for Transaction Performance (TWSM) IBM Tivoli Monitoring Classic Edition IBM Tivoli Enterprise Console IBM Tivoli Business Systems Manager
Perform the following steps to un-install application packages: 1. On the TEDW Control Center machine, edit the twh_app_deinstall.cfg file in the TWH_TOPDIR/install/bin directory by doing the following: a. Add the product code of the application package (for example, dyk for the ITSLA Target ETL) you want to un-install in the UNINSTALL ME section of the file, as shown in Example A-1.
Example: A-1 UNINSTALL ME section of twh_app_deinstall.cfg
############ UNINSTALL ME ########################################### # Below, specify the application package to uninstall. This is the # directory name in the (TEDW TOP product top)/apps tree that # relates to the product you want to delete. APPLICATION_TO_DELETE=dyk
b. Add the password for the DB2 user on the local machine next to the DB2PASS field in the file, as shown in Example A-2.
Example: A-2 Add the password for the DB2 user on the local machine
# DB2 connection information # For a single machine install, this is the DB2 user information for # that system. For a distributed install, this is always the local host # DB2 user and password. DB2USER=db2admin # DB2 User ID DB2PASS=db2admin # DB2 Password
c. Add the password for the DB2 user on the TEDW Control Center next to the COPT_CTRL_DB2PASS field in the file, as shown in Example A-3.
Example: A-3 Add the password for the DB2 user on the TEDW Control Center
# # # # # For a single machine install, the user and password should be the same as the DB2USER and DB2PASS above and the host and port information will be to the local DB2 database. For distributed, the user and password are the user and pass to the Control server.
360
COPT_CTRL_DB2HOST=w2kaspc3.itsc.austin.ibm.com COPT_CTRL_DB2PORT=null COPT_CTRL_DB2USER=db2admin COPT_CTRL_DB2PASS=db2admin
d. Add the password for the DB2 user on the TEDW Central Warehouse server next to the COPT_CDW_DB2PASS field in the file, as shown in Example A-4.
Example: A-4 DB2 user on the TEDW Central Warehouse server
# For a single machine install, the user and password should be the same # as the DB2USER and DB2PASS above and the host and port information # will be to the local DB2 database. # For distributed, the user and password are the user and pass to # the CDW server. COPT_CDW_DB2HOST=w2kaspc3.itsc.austin.ibm.com COPT_CDW_DB2PORT=null COPT_CDW_DB2USER=db2admin COPT_CDW_DB2PASS=db2admin
e. Add the password for the DB2 user on the TEDW Data Mart server next to the COPT_MART_DB2PASS field in the file, as shown in Example A-5 on page 361.
Example: A-5 Add the password for the DB2 user on TEDW Data Mart server
# For a single machine install, the user and password should be the same # as the DB2USER and DB2PASS above and the host and port information # will be to the local DB2 database. # For distributed, the user and password are the user and pass to # the Mart server. COPT_MART_DB2HOST=w2kaspc3.itsc.austin.ibm.com COPT_MART_DB2PORT=null COPT_MART_DB2USER=db2admin COPT_MART_DB2PASS=db2admin
2. Save the changes you have made to the twh_app_deinstall.cfg file and run the application pack un-installation program. Use the bash shell on machines running Microsoft Windows, and the bourne shell, located in the /bin/sh directory, on machines running UNIX. Run the following command from the TEDW_Install_Dir/install/bin directory:
twh_app_deinstall.sh -c twh_app_deinstall.cfg
361
As an alternative to un-installing an application pack, you can disable the scheduling of the application pack ETL processes. You can stop importing data to the TEDW Central Warehouse database, or stop creating or updating the TEDW Data Marts without the risk of losing customized data marts that depend on the application pack. Refer to Chapter 10 in Tivoli Enterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744, for more information about disabling the scheduling of the application ETL processes.
Remove the ITSLA Databases

In order to complete the un-installation process, you may need to drop the ITSLA Databases and the ITSLA Measurement Data Mart databases and remove them from your environment. Do the following on the machine where the ITSLA Databases and the ITSLA Measurement Data Mart reside: 1. If the ITSLA Database Server resides on UNIX, do the following: a. Log on as a valid DB2 user. b. Source the db2profile file locally by navigating to the db2_instance_directory/sqllib directory, where db2_instance_directory is the database instance directory, and issue the following command:
. db2profile
2. If the ITSLA Database Server resides on Windows NT/2000, perform the following: a. Open a DB2 command window: Start -> Programs -> IBM DB2 -> Command Window. b. Run the following commands from the command line interface:
db2stop force db2start db2 drop db db_name
Where db_name is the name of the database you want to drop. Then terminate the session:
db2 terminate
362
Un-installing the support applications

This section only provides references to the un-install procedure for ITSLA-supported applications. Please refer to the following sources of information if you need to un-install any of the ITSLA-support applications: Tivoli Enterprise Data Warehouse See Chapter 10 in Tivoli Enterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744. IBM WebSphere Application Server Visit the IBM WebSphere Application Server InfoCenter Web site at:
IBM DB2 Universal Database Enterprise Edition See the Appendixes in DB2 UDB Quick Beginnings for Windows Version 7, GC09-2971, for information about un-installing DB2 for Windows and Chapter 10 in DB2 UDB Quick Beginnings for UNIX, GC09-2970, for information about un-installing DB2 for UNIX.
363
364
Appendix B.
Service Management according to the ITIL

This appendix discusses the various components and definitions behind Service Management in Information Technology Infrastructure Library (ITIL) terms and should be used as reference to anyone involved in the Service Level Management process. This appendix contains the following topics: Service Management overview The ITIL Service Support model The ITIL Service Delivery model The ITIL Service Level Management model
365
The ITIL
The Information Technology Infrastructure Library (ITIL) is essentially a series of documents that are used to aid the implementation of a framework for IT Service Management. This customizable framework defines how Service Management is applied within an organization. Although ITIL was originally created by the Central Computing and Telecommunications Agency (CCTA), a UK Government agency, it is now becoming more popular and has been adopted and used across the world as the defacto standard for best practice in the provision of IT Service. Although the ITIL covers a number of areas, its main focus is on IT Service Management. ITIL is organized into a series of sets, which themselves are divided into two main areas: Service Support and Service Delivery. Service Support is the practice of those disciplines that enable IT Services to be provided effectively. Service Delivery covers the management of the IT Services themselves. It involves a number of management practices to ensure that IT Services are actually provided as agreed-upon between the service provider and the customer. Each of these two areas contain a number of disciplines, which themselves stipulate the ITIL practices/requirements. Refer to the following Web sites for details on what ITIL is and what it can provide: http://www.itsmf.com http://www.itil.co.uk http://www.ccta.gov.uk The IT systems management forum Web site The official ITIL Web site The CCTA official Web site
Service Management
Today, the service management revolution is well on its way. Almost every IT organization is moving toward business-oriented service delivery. That is, IT is being called upon to participate as a partner in the corporate mission, which requires their functioning as a pro-active group that is responsive to their customers.
366
Adopting this mind-set is difficult for internal service providers, who face an increasingly less captive audience. The corporate IT organization is now challenged to operate like a stand-alone business but without the corrective forcesprofit orientation and threat of losing customerswhich are present for companies operating in a free market. In the absence of these forces, IT organizations are embracing a new competitive mind-set: Service Level Management. It is through the process of establishing a Service Level Management orientation that IT organizations can engage customers, just as if they were driven by market forces. Service Level Management is a means for the lines of business (LOB) and IT organization to explicitly set their mutual expectations for the content and extent of IT Services. It also allows them to determine in advance what steps will be taken if these conditions are not met. The concept and application of Service Level Management allows IT organizations to provide a business-oriented, enterprise-wide service by varying the type, cost, and level of service for the individual LOB. In order for the IT organization to be able to make and use the service level agreements with the LOBs as a tool for decision making, the IT organization needs to organize itself accordingly and establish internal procedures that support the SLA Management. Service Level Management is not an isolated activity. It interacts with, and draws upon, all the other disciplines that are part of the IT infrastructure management. There is no point in agreeing to delivering a service if the basic tools and processes needed to deploy, manage, monitor, correct, and report the service level achieved have not been established. All of these activities are grouped into two major disciplines: Service Delivery and Service Support.
Appendix B. Service Management according to the ITIL
367
Service Delivery
Cost Management
Contingency Planning Service Level Management
Capacity Management
Availability Management
Configuration Management
Change Management Help Desk Problem Management
Software Control and Distribution
Service Support
Figure B-1 The Service Management disciplines
The primary objective of the Service Delivery discipline is pro-active, and consists primarily of planning and ensuring that the service is delivered according to plan and, in turn, the Service Level Agreement. The tasks that have to be accomplished to make this happen are: Service Level Management Managing customer expectations and negotiating service delivery agreements. This involves finding out the customers requirements and determining how these can best be met within the agreed-upon budget. Work together will all IT disciplines and departments to plan and ensure delivery of services. This involves setting measurable performing targets, monitoring performance, and taking action where targets are not met. Cost Management Register and maintain cost accounts related to the usage of IT Services. Deliver cost statistics and reports to Service Level Management to assist in obtaining the right balance between service cost and delivery. Assist in pricing the services in the Service Catalogue and Service Level Agreements.
368
Contingency Planning Plan and ensure the continuing delivery, or minimum outage, of the service by reducing the impact of disasters, emergencies, and major incidents. This work is done in close collaboration with the companys business continuity management, which is responsible for protection of all aspects of the companys business, including IT. Capacity Management Planning and ensuring that adequate capacity with the expected performance characteristics is available to support the service delivery. Deliver capacity usage, performance and workload management statistics, and trend analysis to Service Level Management. Availability Management Planning and ensuring the overall availability of the services. Providing management information in the form of availability statistics, including security violations, to Service Level Management. This discipline may also include negotiating underpinning contracts with external suppliers, and defining maintenance windows and recovery times. The disciplines in the Service Support group are mainly reactive and concerned with implementing the plans and providing management information regarding the levels of service achieved. Configuration Management Responsible for registering all components in the IT Service, including customers, contracts, SLAs, hardware and software components, and more, and maintaining a repository of configurable attributes and relationships among the components. Help Desk Acts as the main point-of-contact for the users of the service. Registers incidents, allocates severity, and coordinates the efforts of the support teams to ensure timely and correct resolution of problems. Escalation times are noted in the SLA and are, as such, agreed upon between the customer and the IT department. Provides statistics to Service Level Management to demonstrate the service levels achieved. Problem Management Implements and uses procedures to perform problem diagnosis and identify solutions that correct problems. Registers solutions in the configuration repository.
369
Agree on escalation times internally with Service Level Management during the SLA negotiation. Provide problem resolution statistics to support Service Level Management. Change Management Ensure that the impact of a change to any component of a service is well known, and the implications regarding service level achievements are minimized. This includes changes to the SLA documents and the Service Catalog, as well as organizational changes and changes to hardware and software components. Software Control and Distribution Manage the master software repository and deploy software components of services. Deploy changes upon the request of Change Management. Provide management reports regarding deployment. The key relationships among the disciplines are shown in Figure B-2 on page 371.
370
Deliverables: Deliverables: Quality services Quality services
Requirements: Requirements: Budget Budget Performance Performance Availability Availability Disaster Disaster
Service Level Management
Requirements Requirements Quality services Quality services
Deliverables: Deliverables: Costs Costs Performance Performance Availability Availability Recovery Recovery
Requirements: Requirements: Availability Availability
Problems: Problems: Problem reports Problem Questions reports Questions Inquiries Inquiries
Planning:
Support:
Contingency Management Help Desk
Cost Management
Capacity Management
Change Management
Problem Management
Deliverables: Deliverables: Configuration data Configuration data Software installations Software installations Configurations: Configurations: Capacity Capacity Equipment Equipment Components Components etc. etc.
Requests: Requests: IT infrastructure IT infrastructure improvements improvements
Infrastructure:
Figure B-2 Key relationships among Service Management disciplines
To fully understand the responsibilities of each of the disciplines and the relationships among them, both the Service Delivery and the Service Support disciplines will be discussed briefly in the following sections.
Service Delivery disciplines

Service Delivery is a discipline that needs to be mastered in most enterprises. One way or another, every enterprise provides services to their customers either as the main business idea or as a supplement to the goods provided by the company.
371
Even though services from different industries are very different, all providers of services have to answer two basic questions before commencing service delivery: What is the service that will be delivered? How will the service be delivered? To support the answering process, a number of related questions needs to be addressed as well. Some of them are: Why are we delivering the service? Why will customers buy the service? Where and when will the service be delivered, in what quantities, and at what quality? What resources are needed to deliver sufficient quantities of service at the desired quality, place(s), and time(s) of usage? What is the cost of delivering sufficient quantities of the service at the quality, place(s), and time(s) of usage? How is service delivery assured? How is stopping unauthorized usage of the service assured? Who will support the delivery? What is the price customers will have to pay to make use of the service? Many services are standard, off-the-shelf services, that are well defined and are applicable to a huge number of different customers. Other services share the same attributes, but may be tailored to specific geographies, industries, businesses, or types of customers, and yet other services are highly customized to meet the needs of specific customers. In general, IT Services are grouped into three categories of service, each one reflecting the need for particular adjustments fulfill the requirements of the users:
Off-the-shelf Volume customization One-of-a-kind
Standard; no adjustment Standard versions; adjusted to fit similar groups of customers Made to order to fit the unique needs of one particular customer
372
It goes without saying that the cost of delivering a one-of-a-kind service properly is much higher than the cost of delivering a standard service, and the price the customer pays reflects the cost. To determine the cost, and thereby predefine the price the customer has to pay, all of the questions concerning who, why, what, where, when, and how have to be answered; in other words, the service has to be defined in such detail as there can be no misinterpretations about any of the following: The deliverable Quantities and quality of the deliverable Prerequisites and requirements for the delivery Division of roles and responsibilities between customer and provider How, where, and when the delivery takes place The penalties for not delivering Benefits/penalties for increased delivery And finally, when all the above have been defined: The price. Discussing Service Level Management in the context of IT Services typically applies to volume-customization and one-of-a-kind services. Within the enterprise, the IT organization will provide the same basic services to all LOBs (mail, office applications, Internet access, etc.) and fulfill particular needs for each LOB by providing specialized services designed solely for this purpose (for example, accounts payable/receivable, payroll, procurement, and so on). Likewise, an external network service provider wants to sell similar networking services to many customers and perhaps design special services for customers with special needs. In the Service Management organization the responsibility of defining the services is that of Service Level Management. Service Level Management is also responsible for managing customer demand and negotiating the SLAs. Once the services have been established and delivery has begun, service providers need to assure that the service is delivered as expected, and ensure the continuing delivery, which is also the responsibility of Service Level Management. To do this, Service Level Management needs assistance from other disciplines focusing on various aspects of the Service Delivery processes and the overall mission of the IT department:
Capacity Management
Deals with the daily monitoring and reporting of workloads, resource usage, and component performance. Capacity Management is also responsible for capacity planning by identifying trends and predicting future needs.
373
Ensures that the services are available to the users that are authorized to use those services, when they are needed. This is primarily achieved by ensuring the availability of each of the components that is part of the service. Manages the IT budgets and negotiates contracts with suppliers. Cost Management also plays a key role in determining the cost of a service (often based on resource usage), thus assisting Service Level Management with pricing the service. Ensuring that the IT Services delivery may continue, or be reestablished quickly, after a disaster. IT Services are often required to perform business transactions, so the IT organization has to have completed and tested plans and procedures for disaster recovery and related subjects.
Cost Management
Contingency Planning
We will briefly explore these four disciplines and their association with Service Level Management in the following sections.
Capacity Management
Insufficient capacity will often lead to bottlenecks, performance problems, and finally, loss of availability, all of which contribute to degrading the service delivery. Looking at a typical client-server service, it is evident that since more components make up the service, as it is perceived by the end-user, the capacity of each individual component has to be balanced according to the capacity of the other components. The perception of the service delivered is directly related to the capacity available to the service. Given a definition of capacity as the maximum performance or output of a component, we could say that in order to manage capacity of a service, it is just as important to manage the workloads of the service to be able to forecast the need for capacity and know what workloads run where and when, and under what circumstances. In general, this means that the primary objective of Capacity Management is to ensure that the appropriate technology is used and that it is used in the best way possible, where the word appropriate is determined by the level of service that is to be provided to the business at all times, and best way is determined by how well any given technology supports the business requirements of the users.
374
Change Management is divided into eight sub-disciplines, as follows: 1. Capacity Management Database Maintain the data related to Capacity Management. The type of information that is stored in the Capacity Management Database is technical, business, and cost data required by Capacity Management to produce technical and management reports depicting usage and trends. 2. Performance Management The main objective of Performance Management is to ensure that the agreed-upon service level is maintained. It is also responsible for ensuring that each hardware, software, and networking component delivers the expected capacity. This is a day-to-day task that involves monitoring the capacity delivered to be able to quickly identify problems or bottlenecks. The data gathered for monitoring purposes is stored in the Capacity Management Database to keep information about the past and to help determine trends. Service Level Management delivers the required service levels to achieve Performance Management. These are in the form of thresholds for each component that have to be met in order to provide the agreed-upon level of service. If these thresholds are not met, or indicators show that they will not be met in the near future, Performance Management will investigate the reason, identify actions to tune the systems to meet the thresholds, and implement the tuning activities, as depicted in Figure B-3 on page 376.
375
tuning
implementation
analysis
monitoring
Service Level thresholds
Capacity Management Database
Service Level Exception Reports
Figure B-3 Performance Management
3. Workload Management Workload Management has three main objectives: Understand and document all workloads. Establish interfaces with relevant parties in the IT department for interchange of information. Implement an effective workload forecasting system. Breaking down a service into individual workloads that execute on one or more components in the IT infrastructure is crucial to understanding and defining the capacity needs for any one component. 4. Application Sizing Predict service levels, as well as cost and resource implications, of future applications or major modifications to existing applications.
376
Application Sizing is of particular interest in the early stages of the life of a service. As part of determining the cost of providing the service, a clear picture of the required capacity is needed. Capacity Management therefore supports Service Level Management through the Application Sizing activities in the preliminary cost and business implications analysis. 5. Modeling The Modeling activities involve estimating or predicting the performance of a system under a given volume and variety of work. Modeling is, so to speak, the Application Sizing of hardware and networking components. 6. Resource Management Understanding the IT infrastructure to ensure that the organization uses the technologies available that best suit the business. 7. Demand Management Prioritize customer demand for the usage of component resources without adding more capacity. 8. Capacity Planning Predict when components reach their saturation point and identify the action to be taken to prevent it.
Availability Management includes planning, implementation, management, and optimization of IT Services so that they can be used where and when the business requires them. Availability Management, as defined by ITIL, is involved with much more than availability of systems. Availability Management focuses on entire services, and makes sure that the services are available where and when they are needed. Availability Management deals with: The complexity of the services The reliability of the IT components and environmental services The level of maintenance provided by suppliers or elements of self-maintenance The infrastructure upon which the services are built The configuration of the infrastructure used to provide the service
377
When conducting Availability Management, the following key elements (combined for all the components that are part of the service) must be observed: Availability Reliability Maintainability Serviceability Security
Availability
The availability is one of the main attributes of the quality of Service Delivery perceived by the users. The availability of components to meet user requirements as stipulated in the Service Level Agreement depends on: Reliability of components Resilience to failure Quality of maintenance and support Quality of operating procedures In order to optimize the availability of the service, all of these factors have to be taken into account for all components of the service. In this context it is important to remember that the users perception of the service is dependent upon the availability of the hardware, software, and networking components, as well as the availability of the data that is used. A service that meets the required availability may be characterized as a service that has minimal interrupts, yet when an incident occurs, it is recovered quickly and efficiently.
Reliability
From a quality service point of view, reliability can be defined as freedom from operational failure. Reliability is often measured as mean time between failure (MTBF), mean time between system incidents (MTBSI), or the number of breaks in a period. All of these help determine the reliability of a component to perform a required function under stated conditions for a stated period of time. The reliability of a service is determined partly by the amount of resilience built into the service, and partly by the pervasive management applied with the aim of preventing failures from occurring. Service resilience is the ability of the service to continue to provide an operation service when components of the infrastructure are non-operational.
378
Maintainability
Maintainability defines the ability of an IT Service to be maintained in or restored to a satisfactory operational state. Maintaining or restoring a service involves five separate stages: Anticipating failures Detecting failures Diagnosing failures Resolving failures Recovering from failures
Serviceability
Serviceability, as used by ITIL, defines the reliability, maintainability, and maintenance support of components for which external suppliers are responsible. When an external party assumes complete responsibility for an entire IT Service and its support (as when a service is outsourced) availability is equivalent to serviceability.
Security
Availability Management bears the responsibility of the last letter in the basic security CIA principle:
Confidentiality Integrity Availability

From the perspective of Availability Management, the following security considerations must be addressed, amongst others: Services must only be available to authorized personnel. After failure, services must be recoverable without compromising confidentiality. Services must be recoverable without contravening IT security policies. Access for contractors to hardware and software should be clearly identifiable. Data must be available to authorized personnel only, and only at agreed-upon times as specified in the SLA.
379
Cost Management
While IT Services are seen as essential in many organizations, the cost of providing these services is only realized by a small number of people. This may lead to accusations that IT is not providing value for the money spent, leading the users to demand for a higher level of service, requiring more capacity, which, in turn, leads to a higher cost of providing the service. The objective of Cost Management is to break this vicious cycle by: Identifying all costs necessary to provide the service Establishing fair means of recovering these costs from the business This places IT in line with the rest of the business, making users aware that they pay a fair price for the services they receive. The tasks performed by Cost Management are costing and charging:
Costing Charging
Identifying and accounting for the costs of running the IT department and providing IT Services. Recovering costs of IT Service provisions in a fair and equitable way, relating to how the services are used.
The costing and charging mechanisms used to align the IT infrastructure more closely to the business objectives is referred to as the Cost Management system. This has to be an integral part of the overall financial management system of the organization. The objectives for the Cost Management system are to: Provide assistance in developing a sound investment strategy that evaluates the available technological options in the light of business strategy and objectives. Set targets for financial performance and measure the performance: Budgeted versus actual costs. Provide a basis for prioritizing resource usage. Ensure sound stewardship of all assets employed in the organization. Provide information for managements decision-making and planning requirements. Provide a flexible and fast response to changing business circumstances.
380
The way Cost Management meets these objectives varies slightly, depending on the nature of the IT department, whether it is a profit center or a cost center. Following ITIL, the two may be defined as:
Profit center
A Computer Services Business Center that operates as a separate business entity, but with its business objectives set by the organization. It provides clearly identified products that are sold to a market. Each of the services provided carries a price tag. A Utility Cost Center that provides services to other cost centers. Performance is not measured in terms of projected or anticipated return, but on how effectively and efficiently it provides services to its users.
Cost center
Contingency Planning
It is essential that IT Services are quickly recovered and delivered to the agreed quality, even if disaster strikes the IT infrastructure. Contingency Planning undertakes this by reducing the impact of major incidents, emergencies, and disasters. When a disruption affects critical business processes, the consequences can be severe and can include substantial financial loss, embarrassment, and loss of credibility or goodwill for the organization concerned. The consequential damage can extend much wider, impacting staff welfare, customers, suppliers, taxpayers, shareholders, and the general public. Contingency Planning (CP) is considered a part of the overall Business Continuity Management (BCM) that is the responsibility of senior management in any organization. Both CP and BCM are concerned with managing risks to ensure that at all times an organization can continue to operate toward a predetermined, minimum level. The risks that are addressed by BCM and CP are those that could result in a sudden and serious disruption to the business. For example: Damage or denial of access to premises, perhaps as a result of fire, flood, or other disasters Loss of critical underpinning services such as telecommunications and power Failure or non-performance of critical suppliers, distributors, or other third parties, particularly when key business functions have been outsourced Human error, technical, or environmental breakdown Fraud, sabotage, extortion, or commercial espionage Infiltration of IT systems by viruses and other forms of malicious software Industrial action or other unavailability of key staff
381
Contingency Planning and Business Continuity Management possess objectives to reduce or avoid identified risks, to plan for the recovery of business processes if the business is disrupted, and to transfer the risk to a third party. All business units (BU) or lines of business (LOB) within an enterprise should develop and maintain plans for continuing business in case of a disaster. Since the LOBs rely on IT Services to perform their business, the IT department is heavily involved in this process. The IT department should, just like any other business unit, develop and maintain a set of plans to be used in case of an emergency.
Service Level Management

Conducting Service Level Management does not in itself guarantee high quality in the service delivery. It is clear from the previous sections that a number of disciplines have to be in place and working satisfactory in order to support Service Level Management, both by providing information needed to define and plan the service and the deliverable levels of service, and by providing feed-back to indicate what levels of service have been achieved. Some users of a service may feel that they receive the best service, while other users are very discontent with the same quality of service, and, at the same time, the IT department providing the service feels that the quality delivered is satisfactory. In most companies, the quality of service is an arbitrary issue, causing the judgement of the quality of service to become a subjective matter based on personal, and often short term, criteria. This is why customers can be satisfied one week and demand the resignation of the entire IT department the next. Before going into Service Level Management, we will briefly go over service quality and customer satisfaction.
Measuring service quality

Obviously, quality is an issue closely related to expectations. Figure B-4 depicts the relationship between the actual performance, in terms of quality, of an IT department as opposed to the way its performance is perceived by its customers. The picture also shows that sustained improvements in the quality of service delivered increases the quality perceived by the users even more so than the improvements made. This continues until the users feel that they are receiving a higher quality of service than what is actually being delivered. In addition, the picture also shows that even if the quality of service delivered remains the same and no improvements are made, users perceive the quality as declining.
382
100
80
Level of Quality
60
40
20
0
Time
User perception of IT Performance IT Performance
Figure B-4 Service Delivery quality perception
Providing quality service is not enough, as the service must consistently be of the same high quality both in actual delivery and in the eyes of the users. In order to fulfill this goal, quality must be defined. In the ITIL context quality is a long-term strategic issue that defines exactly what standards will be used to measure ITs contribution to the business. In order words, quality is the achievement of the specified levels of service. Following this definition of quality, a quality service is defined as meeting the specified levels of serviceneither high levels nor low levels, but the levels specified by the customers during the SLA negotiations. The IT department simply has to provide the quality of service demanded by the customers.
Service levels and customer satisfaction

Consistent delivery of the quality service defined may lead to unhappy customers, since they perceive the service as degrading. One way to keep the customers happy is to keep them satisfied. Constant high customer satisfaction means that the service is good, but it does not reveal anything about the quality of service.
383
Figure B-5 Levels of service and customer satisfaction
Figure B-5 shows how customer satisfaction of a delivered service may be grouped: Generic The most basic service. All services of this type can be easily recognized because they are all based on the same generic type. Expected This is the level of service that the customer has come to expect from a specific supplier or chain. Generous This level of service offers more than the customer expects, often for the same price or less than is normally the case. Total The level of service is of such a standard that it would be impossible to improve it further.
384
Determining the right level to deliver is part of Service Level Management, and working with intangibles like expectations makes it a very difficult task.
The customer
In ITIL terms, the customer is defined as follows. Also notice the definition of a customer in the context of IBM Tivoli Service Level Advisor in 2.3, Important ITSLA concepts and terminology on page 26.
Customer
The recipient of an IT Service, who carries the responsibility for the cost of IT either directly through a charge-out system or indirectly in terms of demonstrated business need.
According to this definition, the customer both uses and pays for the service. In business organizations, it is not practical to negotiate service delivery on a person-by-person basis. Services are typically delivered to departments or LOBs and are paid for by the organization, sometimes with the one paying not necessarily having use for the service. In this case, the one responsible for the cost is the sponsor, while the users, who are not financially responsible, are called consumers. Usually, during the negotiations between the sponsor and the provider, the service quality gets adjusted to meet the needs for both parties. This adjustment often leads to degradations in both service quality and service price without readjustment of the expectations of the users. When the provider delivers the agreed level of service, the users are disappointed, because they get a poorer level of service that expected; however, the sponsor satisfaction is as expected, because the sponsor receives the expected level of service.
The role of Service Level Management

From the previous sections it is clear that Service Level Management (SLM) is concerned with managing the customers expectations of the IT department. In this external role, SLM tries to determine the customers requirements and meet these within the budgetary constraints of the business. Service Level Management, however, also has an internal role of working together with all IT disciplines and departments to ensure that these levels of service can be delivered. This involves setting measurable performance targets, monitoring performance, and taking action when targets are not met. In the internal role, Service Level Management works to make every person involved with service provision aware of what is expected of them and to ensure business success. This means that every member of the IT team is aware of what they need to do to perform well, and how their individual performance may affect the overall business.
385
Consequently, Service Level Management works to build recognition by all parties supplying and receiving services. This is achieved through preparation, agreement, and maintenance of formal Service Level Agreements (SLAs), which document all the relevant details of the service. In this way, Service Level Management bridges customers and suppliers in the following ways: SLM identifies and integrates the elements that make up service provisions. SLM packages these into an easy-to-understand service. SLM expresses that service in terms the customer can understand.
The objectives of Service Level Management

Service Level Management is the process of negotiating, defining, and managing the levels of IT Service that are required and cost-justified. The Service Management goal is important, because it emphasizes the quantification of services. Therefore, when defining the objectives for the Service Level Management processes, the deliverable should be specified in quantifiable terms. Examples of such definitions are as follows: IT Services are catalogued. IT Services are quantified in terms that both the customer and the IT provider understand. Internal and external targets of IT Services are defined and agreed upon. Achievement of agreed-upon service targets is reached. The quantification of objectives applies to all three parts of the scope of the Service Level Management process and involves the management of IT Services between the customer organization and the IT Services organization, the IT Services organization and its external suppliers, and the IT Services organization and its internal departments. A key to the success of Service Level Management is correctly quantifying the services being provided. Unless there is an agreed-upon method of how services are to be measured, there is no way of knowing whether targets have been met or not. Service Level Management is responsible for understanding and documenting the customer requirements and translating them into a set of understandable measures.
386
The process of identifying and quantifying services consists of four steps: 1. Understanding and documenting customer requirements The basis for any service is to understand the customers demands and requirements. Through this process, Service Level Management gets detailed knowledge of the customer environment and requirements. This understanding is a prerequisite for defining the service, estimating the capacity needs, and defining the measurements needed to support the service delivery. 2. Specifying external standards Having the basic understanding of the customers requirements and demands, Service Level Management can define the external standards. These standards specify the planned deliverable, both in terms of functionality and capacity, and the measurements used to quantify these to the customer, by using customer terminology. Before completing the external standards, Service Level Management will have to negotiate them with the customer. The external standards specify the functions and capacities that will be delivered and the way in which they will be measured. All of these will naturally have to be accepted by the customer; however, the external standards cannot be finalized without consent from all the teams in the IT department that are going to deliver on the promise. This consent is obtained by Service Level Management using the internal standards. 3. Translating to internal standards Once the external standards have been defined, or rather during the specification and negotiation processes, they need to be translated into a set of standards to be used internally by the IT department. The internal standards specify, in IT terms, the functional and capacity-related requirements that the IT department has to fulfil in order to support the delivery, as well as the ways the delivery will be measured, and optionally charged. These specifications are negotiated among Service Level Management and the other disciplines of Service Management. Each of the other disciplines commit to provide the specified levels of service. The internal standards are produced by Service Level Management and will have to be revised and renegotiated when the external standards change. 4. Producing contracts and agreement Finally, when both the internal and the external negotiations are finalized, the external and internal standards are used to create the final documents: Contracts and agreements. Service Level Management produces a set of contracts and agreements designed for the customer.
387
For internal standards, this set includes the following documents: Service level requirements External specifications Service Level Agreement Service Catalogue
For external standards, this set includes the following documents: Service Quality Plan Internal specifications Operational Level Agreement Underpinning contracts
Specifying service levels

When the customers expectations have been identified through the Service Level Requirements, the next logical step is to specify the detailed requirements to meet those expectations. The goals for this specification are as follows: An unambiguous and detailed description of an IT Service and its components A specification of how the service is to be delivered to meet the agreed-upon targets A specification of the quality control measures to consistently be able to meet the specified demands, thereby achieving customer satisfaction There are two documents that support the service specification process, as follows: External specification sheet The external specification sheet contains information concerning customer demands, which are quantified as measurable targets. Responsibilities for delivery and the assurance of the quality of service are also defined. Internal specification sheet The internal specification sheet contains all the information relating to the building, controlling, and monitoring of the components that make up the service. The use of such specification sheets is very helpful to the Service Level Agreement design process. The purpose of a specsheet is to specify, in detail, what the customer wants (externally) and what consequences this has for the service provider (internally). Specsheets do not require signatures, but are subject to document control.
388
The Service Level Agreement and the Service Catalogue are built from specsheets. When a Service Level Requirements document is changed, the specsheets will have to be updated. This will in turn lead to a rebuilding of the Service Level Agreement. The specsheets can then be used to keep internal quality targets in line with the external demands. Figure B-6 on page 389 shows the service level specifications using internal and external specsheets.
Service Level Requirements
External Specsheets
Internal Specsheets
Corporate Level
Agreements
Customer Level
Service Level
Figure B-6 Service level specifications
After completion of the specsheets, the business demands should be successfully transformed into IT deliverables. It is now possible to draft the formal Service Level Management documents. They are: Service Catalogue This document provides an overview of the services available to the customers of the IT organization. As a marketing tool, the Service Catalogue presents a profile of the IT organization as a service provider and shows customers exactly what the IT organization can do. This will also help the IT organization manage the expectations of a business more effectively.
389
Service Level Agreement The format of each Service Level Agreement will depend on a number of factors including the physical, cultural, and business aspects of the organization. Where the organization consists of a number of fairly independent business units, these should be seen as independent customers. Operational Level Agreement This document is used only by the IT department and servers as an internal SLA, specifying the IT Services, responsibilities, terms, and conditions. Underpinning Contracts All underpinning contracts should be reviewed regularly, both to accommodate changing Service Level Requirements and as a routine issue. Underpinning contracts have to be easily accessible for all participants in the Service Level Management process. Underpinning services supplied in-house are also vital to the service, as it is just as important to review these and, if they are not already in place, introduce Operational Level Agreements to safeguard the supporting services. Service Quality Plan Once the Service Level Agreement has been negotiated and signed, the difficult task of delivering on the promise begins. Even more difficult is the ongoing monitoring and reviewing of the services delivered to the customer. This can only be accomplished with a full understanding of the total IT Service Delivery situation in terms of the capabilities of the IT Service, the agreed service levels, and the demands for internal and external suppliers. The objective of a Service Quality Plan document is to balance the customer requirements with the IT organization. The Service Quality Plan achieves this by specifying the process parameters, the required management information, and the key performance indicators.
Service Support disciplines

The main purpose of the disciplines grouped in the Service Support group is to provide the means to implement and monitor the plans defined by the Service Delivery disciplines. Even if an IT organization has not embraced the ideas of Service Level Management, it will certainly have parts of the disciplines in place in the Service Support group. Certain components of these disciplines are simply a prerequisite for managing client-server systems and the vast amount of desktop computers found in any business today.
390
Dependent on many factors, size being one of the major ones, the disciplines may or may not be fully implemented, and the same persons within the IT organization may have roles and responsibilities for more than one discipline. These factors should be taken into account when designing the procedures governing the incident, change and Problem Management processes, and especially the interfaces between each of the disciplines. Having more capacity makes it very easy to skip the defined procedures and, implement work-flow tools to ensure compliance with the defined processes, which may be too rigid to make the daily work flow smoothly. However, because of the dramatic impact IT Services outages may have on the business, it is very important that the processes are well defined, documented and followed, and are in-line with the priorities of the business. Like in many other aspects of business, strict compliance with the rules may not always be required, but if something goes wrong, you may be much better off if the rules and regulations have been closely followed. During the life cycle of an IT Service, it passes through the following phases: Planning Deployment Usage Monitoring Correction Verification Disintegration Each of these phases can be regarded as a change to the existing environment. The term change may be most applicable to the activities that go on inside the usage phase, though it still applies to all of the phases. In each of them, there is a need for information regarding the environment, components, status, operational attributes, users, and so on. Likewise, it is necessary to know where the roles and responsibilities of different activities involved with Service Support are placed within the support organization. During all the phases of the life cycle, the IT organization as a whole should be able to answer the following question: Who does what to which componentwhere, when, why, how, and authorized by whom? Providing the answer requires contributions from all the disciplines in the Service Support group.
Configuration Management Help Desk Problem Management
Answers the where and which . Should be in a position to answer why. Responsible for the what and the how.
391
Change Management Software Control and Distribution
Takes care of the when and whom. Dependent upon the nature of the change, who is often placed here.
Change requests may originate from sources other than Problem Management and Help Desk. If, for example, a request to increase the size of a file system has been issued from Capacity Management, the change request is passed directly to Change Management without the knowledge of Help Desk. However, each change request should be registered with and governed by Configuration Management, so Help Desk would be able to find the answer to why, even though the change did not address a specific incident received by the Help Desk.
For both day-to-day incident, problem, and change handling and deployment of new services, information about all the components that are related to delivery of a service is vital. It is the responsibility of Configuration Management to provide and maintain this information, as it is perhaps one of the most difficult tasks related to Service Management. Configuration Management, as a discipline of Service Support, is not restricted to the Configuration Management aspects of development. If it applies to the specific environment, development aspects are included, but Configuration Management includes all of the components within the IT infrastructure that are related to delivery of a service. Particularly, Configuration Management should be applied throughout the organization and should not be restricted to IT related items. The four main activities of Configuration Management are: Identification Control Status accounting Verification
Identification
This involves identifying all the configuration items (CIs) in the IT infrastructure, as well as defining the information to hold about each of the CIs and the relationships between configuration items. Additionally, baselines should be defined and variants identified. The responsibility of this task can be summarized as: To define policies regarding the type and level of information that is maintained in the organization.
392
Performing this task requires a huge effort, not only for identifying, gathering, and storing the information initially, but maintaining the information, which may be even worse. The basic principles for identifying the CIs are: CIs must be uniquely identified. The indoctrination must be prominent and clearly visible. Identities must be as meaningful as possible. Versioning must be supported. Growth must be catered for.
Control
This activity handles maintenance, updates, and access to the Configuration Repository. Many of the other Service Management disciplines support this effort, but this requires that adequate control procedures are in place: Specification of CIs are agreed-upon and frozen. Only changes, authorized through predefined Change Management procedures, can be allowed.
Status accounting
Since the Configuration Repository is used by all System Management disciplines, it is vital that the information is correct and timely. The Configuration Repository holds active, as well as historical, configuration data, and therefore attributes need to be defined and maintained to be able to track the configuration of CIs over time. These attributes must support the state of acquisition, development, testing, or implementation of the CIs, and must be recorded as soon as they happen. Another way of expressing the responsibilities of this activity is to record and
report all current and historical data for all CIs.

Some useful reports could be: Number of incidents from a particular CI in a particular period Change history for a CI in particular period Total amount spent with a particular supplier over a particular period
393
Verification
Finally, the contents of the Configuration Repository will have to be audited, verifying that the Repository reflects the actual configuration of the IT infrastructure. This can be accomplished by the Configuration Management staff themselves, or some of the operational procedures (for example, related to incident reception in the Help Desk). The consistency of the Configuration Repository should be reviewed regularly. The accuracy of the Configuration Repository may be easier if: The Configuration Repository is active rather than passive. The Configuration Repository is updated automatically whenever possible. Configuration Management activities are integrated into other relevant operational procedures. Automatic audits are built into the system.
Help Desk
The primary purpose of the Help Desk is to provide a main point of contact for the users of the services. Whenever the users experience problems, have questions, or need information regarding the use of the services, they should contact the Help Desk. On the other hand, the Help Desk is also responsible for notifying the users of service disruptions, planned outages, and availability of new functions. The Help Desk serves as a two-way conveyer of information between the service users and the staff supporting the service. For the remainder of this discussion, we will focus on the one-way information flow from user to staff. Providing quality service requires processes and procedures to detect and rectify problems as quickly as possible. Detection is either done by programs that monitor specific resources of the hardware and software components of the IT infrastructure, or by the users of the service. When a problem is reported, it is recorded centrally with the Help Desk as an incident. This central incident control is required partly to ensure that the problem is taken care of, and partly to ensure that the same problem is handled only once, even if more incidents may have been opened against the problem. When the problem is reported, the Help Desk is responsible for providing a solution to the problem. The Help Desk may, but is not required to, identify, test, and apply the solution, but it is the responsibility of the Help Desk to keep track of the incident to ensure that the problem is solved within the time agreed-upon in the SLA, and to escalate the problem if necessary.
394
If Help Desk cannot identify a solution to the problem on their own, the incident is escalated to a problem, which is stored in the Configuration Repository. Now Problem Management assumes responsibility by providing a solution to the problem, and by accepting the problem and recording it as a known error. When a solution is available, it may require changes to the CI for which the incident was opened, or another CI within the infrastructure on which the failing CI relies. The Help Desk is now required to open a request for change, in order for Change Management to access the impact and authorize the change. Once authorized, Software Control and Distribution may take over to perform the actual implementation of the change. During this process, each of the Service Support disciplines is responsible for recording status information in the Configuration Repository, and it is the responsibility of the Help Desk to keep the user informed through all the stages in the life cycle of the incident. Upon completion, Help Desk must confirm that the problem has been resolved, record the solution to the known error, and close the incident. When a problem is reported, the Help Desk captures the data needed to open a new incident. This data must include an ID of the person, or proxy, who submitted the problem report, and the ID of the CI suffering the problem. With this information the Help Desk can query the Configuration Repository to investigate whether the CI exists in the repository, and if any outstanding problems, changes, or other incidents are active for that particular CI. It should also be checked if the particular problem was reported earlier. If there are no indicators showing that the problem is being addressed, the incident must be categorized. A type is assigned to the incident as well as an impact code. This must not be confused with priority or severity. The meaning of the three terms are:
Impact Severity Priority
Impact of the incident to the achievement of business objectives Impact of an incident to service provision Order of handling incidents
Using the above definitions, it is clear that an incident can have a very high impact on the achievement of business objectives and yet have an insignificant impact on the provision of the service, and vice versa. The priority depends primarily on the impact it will have on the business, and secondly, on the impact to the service. But since the business relies on the service, incidents with a high service impact quickly impacts the business as well. The priority of the incident will be determined from both a business and a service perspective.
395
severity
medium Service impact
high
low
medium
impact Business impact
Figure B-7 Incident priority
Having categorized the incident, initial investigation may be carried out. This involves searching the Configuration Repository for similar or related problems in order to identify the cause of the incident as a known error. If this is the case, the Help Desk can inform the user of the status of the problem, when to expect the problem to be fixed, or any actions the user can take to circumvent the problem. If no solution can be found, the incident becomes a problem, and a solution has to then be provided by the Problem Management discipline. When the Help Desk has passed the problem on to Problem Management, the responsibility of keeping track of the problem still lies with the Help Desk. The Help Desk is now responsible for keeping the user informed about the progress, as well as escalating the problem if the times for problem resolution set in the Service Level Agreement cannot be met.
Problem Management
The activities performed by Problem Management are very similar to those of the Help Desk. Problems are received, accepted, diagnosed, and assessed for severity, a cycle known as the problem control process. Then solutions are developed or identified, tested, verified, and recorded; all part of the error control process. The Problem Control process is concerned with identifying the real causes of incidents to prevent future reoccurrences. This process is made up of five phases: 1. Initial investigation of the nature of the problem
396
2. 3. 4. 5.
Accepting the problem Assigning severity (impact on service delivery) Allocating support effort Performing further investigation and diagnosis
Once the problem has been accepted it is recorded in the Configuration Repository as a known error. Basically, there are two types of known errors: Accepted problems that have not yet been rectified Accepted problems for which a resolution or circumvention is available Allocating the support effort to find a solution to a problem is very important. Depending on the nature, impact, and severity of the problem, it may prove more productive to the business as a whole to live with the problem, rather than using all available support staff and all the budget for external support to diagnose and rectify a problem. To make a decision like this requires detailed impact analysis and acceptance from the Service Level Manager, as well as the sponsor, and may lead to renegotiation of the SLA. When the cause of the problem has been identified and a decision to provide a solution has been approved, Error Control takes over. The primary objective of this function is to eliminate all known errors by providing solutions to the problems and ensuring that they are implemented on all CIs where the problem has occurred or may occur. To meet this objective, Error Control and Change Management go hand-in-hand, since Change Control is responsible for approving any changes made to any CI. The verification of solutions is extremely important. To begin with, it should be verified that the proposed solution actually targets the source of the problem rather than removing the symptoms. Secondly, it is absolutely vital to ensure that implementation of the solution does not result in any undesired side effects. If this is the case, the solution implementation may lead to other, possibly worse, problems that could harm the overall service delivery. All of the disciplines in Service Support should work together to avoid the vicious cycle of change. Much too often, solutions, changes, and implementations are rushed through without proper testing, thus leading to even more severe incidents of higher impact. This requires an even quicker resolution, hence the solution is not tested properly and new incidents are the result. This is depicted on the left side of Figure B-8 on page 398.
397
incident
incident problem
problem
implementation
change change
implementation
Figure B-8 Cycles of change
On the right side of Figure B-8, Error Control has had enough time to assess the impact of the solution. Change Management has had adequate time to assess the impact of the change, and the implementation contained all of the foreseen implications. The source of the problem was eliminated, and the technical support staff can start working on the next problem.
Change Management
Next to Configuration Management, this discipline is the most important in order to assure the delivery of quality service. The responsibility of Change Management is to manage changes to the following: Hardware Software Communication equipment and software Production application software All documentation, plans, and procedures relevant to running, supporting, and maintaining the production systems Environmental equipment People
398
By using the term production, it is meant that changes to equipment and applications used for development and testing purposes are not normally the responsibility of Change Management. The processes that are used to manage changes involve: 1. 2. 3. 4. 5. 6. 7. 8. Change initiation Change reception - logging and filtering Initial change prioritization Change assessment and scheduling Change building Change testing Change implementation Change review
To support the processes, a number of players must be involved. In the typical IT organization, a dedicated Change Manager is appointed. It is the responsibility of the Change Manager to receive, access, approve, and manage the changes. To assist the Change Manager, a Change Advisory Board (CAB) is appointed. This Board consists of members from all the support groups within the organization, including Help Desk, Networking, Space Management, and Platform Support, as well as representatives of the business. The Board is responsible for assessing proposed changes for impact and estimating the resource requirements needed to design, build, test, implement, and review a change. The CAB will also advise the Change Manager in change acceptance matters and assist with scheduling changes. The Change Advisory Board may be divided into sub-committees that handle changes in specific areas. The LOB representative from Finance does not necessarily have to attend the meeting when changes to the production control software are discussed, and presence of the Networking representative is not always required when changes to the central disk configuration are handled. There will also be appointed a super-committee, designated as the Change Advisory Board/ Executive Committee. The purpose of this committee is to be able to authorize urgent changes on very short notice. Because of the size of the Change Advisory Board, it would be very impractical to have to convene a full meeting in order to handle urgent changes. The Change Manager may or may not be authorized to accept some urgent changes, as it may be dangerous to do so without consideration of other key personnel. The CAB Executive Committee is made up of the Change Manager and three key staff members from the Change Advisory Board and acts as the safety net for the Change Manager. The selection of members of the Executive Committee is a matter of preference and the nature of the change, but the Change Manager should always be a board member.
399
LOB representative
IT Manager Security
LOB representative
Operations
Networking
Systems Support
Help Desk
Development
LOB representative
Subsystems
Solutions
Change Advisory Board
Change Manager
Change Advisory Board Executive Committee
Figure B-9 The Change Advisory Board

As Configuration Management is responsible for managing the logical aspects of CIs, including software CIs, Software Control and Distribution (SC&D) is responsible for the physical aspects. The main types of software that are to be controlled are: Application programs developed in-house Third-party application software and utilities System software provided by suppliers All of this software will have to be stored in a common, secure software library called the Definitive Software Library (DSL). This library contains the definitive, quality controlled versions of all the software CIs defined in the Configuration Repository. Ideally, the DSL is one single library, set apart from other parts of the environment. The DSL is usually contained in one single location, but it may be practical to use more than one physical location and format, along with backup storage, as part of the contingency plan.
400
The main tasks performed by SC&D are: Physically storing, protecting, distributing, and implementing all software Controlling access to authorized versions, along with the supporting of Change Control in the release of software for distribution for further work Ensuring that only correctly released and authorized versions of software are in use Distributing software to remote locations Implementing the software Managing the organizations rights and obligations regarding software The SC&D processes include elements that are concerned solely with development, and other elements that are focused on the production environment. Both are managed to ensure that the required standards are met when the service is delivered, and to control the way the software is being used in the production environment. This is why the SC&D is regarded as a Service Management discipline. The details of the SC&D process are shown in Figure B-10 on page 401.
Quality Assurance Performance Testing
Test
System Testing
DSL
Build
Function Testing Rework
Distribution
Implementation
Figure B-10 The SC&D process
401
The left side of Figure B-10 on page 401 shows the tasks related to verifying and ensuring the functionality and quality of the new software CIs, either developed in-house or third-party. This is the Control part of the SC&D. Once the required specifications are met, the software is registered in the Configuration Repository and stored in the DSL. The right side of Figure B-10 on page 401 shows the functions related to distribution. The software is coped from the DSL and the build, a process that may include a simple copying or a complete compilation and linkage. The main issue is to test and verify that the output from the build process can be distributed and implemented successfully. This has to be tested before any actual distributions and implementations can be initiated.
402
Appendix C.
IBM Tivoli Service Level Advisor Databases

This appendix contains a reference to the databases created during the installation of IBM Tivoli Service Level Advisor Version 1.1, as follows: ITSLA Database ITSLA Measurement Data Mart
403
The ITSLA Database

As explained in Chapter 4, Getting IBM Tivoli Service Level Advisor up and running on page 79, the ITSLA Database is created using the dyk_cat_dbinst script. This script defines and creates a database called DYK_CAT for both the default instance (DB2ADMIN) and measurement (MM) schemas. Table C-1 provides a description of the DYK_CAT database tables for the DB2ADMIN schema.
Table C-1 DYK_CAT database tables for the DB2ADMIN schema
Table name Description
ACCOUNT AGREEMENT_VIOL CONSUMER CONSUMER_REALM CUST_ORDER ELMT_PROP ID_GENERATOR METRIC METRIC_DEF MONITORING_RESULT OFFERING_ORDER OFFRG_ELMT OFFRG_ELMT_LCLE OFFRG_PROP ORDER_PROP ORDER_ELMT OUTAGE PROP_DEF REALM SCHEDULE
Account information table Agreement violation table Consumer information table Consumer-to-realm association table Customer order table Base service element property table Database ID generation table Metric property table Metric property definition table Monitoring results data table Service offering to customer order association table Service offering element instance table Service offering element instance local table Service offering property table Customer order property table Customer order element instance table Outage information table Property definition table Realm table Business schedule table
404
Table name
Description
SCHEDULE_LCLE SCHEDULE_MILESTONE SCHEDULE_PERIOD SD_TXN SO_LISTENER SPEC_DEF SVC_ELMT SVC_ELMT_MANAGER SVC_OFFRG SVC_OFFRG_LCLE SVC_SCOPE TREND USER_INFO
Business schedule local table Business schedule milestone table Business schedule period table Transaction management table Service offering update listener table Specification property definition table Base service element table Service element manager table Service offering table Service offering local table Service scope table Trend data table Report user information table
Table C-2 provides a description of the DYK_CAT database tables for the MM schema.
Table C-2 DYK_CAT database tables for the MM schema
ATTRDOM ATTRRUL ATTRTYP COMP COMPATTR COMPPATH COMPRELN COMPTYP EXTRACT_FILTER HISTORY
Attribute domain table Attribute rule table Attribute type table Component table Component attribute table Component path table Component relationship table Component type table Extract control filter table Registration history table
Appendix C. IBM Tivoli Service Level Advisor Databases
405
Table name
Description
MGRP MGRPMBR MGRPTYP MSMTRUL MSMTTYP MSRC MUNIT MUNITCAT RELNRUL RELNTYP SCHEMA_VER TRANSLATED_TERM
Measurement group table Measurement group member table Measurement group type table Measurement rule table Measurement type table Measurement source table Measurement unit table Measurement unit category table Component type relationship rules table Relationship types table Schema version table Translated terms table (for NLS)
Table C-3 provides a description of the DYK_CAT database views for the DB2ADMIN schema.
Table C-3 DYK_CAT database views for the DB2ADMIN schema
BASE_ELMT_PROPS ELMT_MPROP_OFFRGID_VIEW ELMT_MPROP_VIEW ELMT_PROP_VIEW METRIC_DEF_VIEW MSCHED_VIEW OFFRG_DEF_VIEW
Base service element with specification properties view Base service element with metric property definitions and offering element IDs view Offering service elements with metric properties view Base service element with specification properties and definitions view Base service element with metric property definitions view Metric property with schedule view Service offering element with specification properties and definitions view
406
Table name
Description
OFFRG_ELMT_PROPS OFFRG_PROP_SHOWSUBSCRIBER OFFRG_PROP_VIEW OFFRG_DEF_VIEW ORDER_ELMT_PROPS ORDER_PROP_VIEW PROP_DEF_VIEW SCOPE_PROP_SPEC_VIEW SCOPE_PROP_VIEW SCOPE_SE_VIEW
Service offering element with specification properties view Service offering elements with "show to subscriber" properties view Service offering specification properties view Customer order element with specification properties and definitions view Customer order element with specification properties view Customer order specification properties view Base service element with service scope and specification property definition view Service scope with specification property definition view Service scope with property definition view Service scope with service element view
The ITSLA Measurement Data Mart database

As explained in Chapter 4, Getting IBM Tivoli Service Level Advisor up and running on page 79, the ITSLA Measurement Data Mart database is created using the dyk_dm_dbinst script. This script defines and creates a database called DYK_DM for the DYK schema. The following table provides a description of the DYK_DM database tables for the DYK schema.
Table C-4 DYK_DM database tables for the DYK schema
COMPPATH DATA_EXP EVALUATOR_TABLE EXP_LOG
Component path table Data expiration configuration table Evaluator type mapping table Data expiration log table
Appendix C. IBM Tivoli Service Level Advisor Databases
407
Table name
Description
EXTRACT_LOG MSMT_MMA MSMT_TOT SCHEMA_VER STAGE_MSMT
Extract control log table Measurement table for min/max/average measurements Measurement table for totals measurements Schema version table Measurement data staging table
408
Appendix D.
Command reference
Up to this point, you have been presented with the information necessary to create and manage your own IBM Tivoli Service Level Advisor environment. The purpose of this appendix is to provide you with commands that may assist you in administering ITSLA. This is by no means a comprehensive list of all supported commands for ITSLA, but rather serves as a complement to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833, where you can find the entire list of all supported commands. This appendix will cover the following topics: Introduction to the ITSLA CLI Useful commands for ITSLA
409
Introduction to the ITSLA CLI

Before getting into the actual commands that will assist you in administering your ITSLA environment, you will be presented with a general overview of the ITSLA CLI and the basic steps needed to begin working with the ITSLA CLI. As mentioned previously, it is not the intention of this appendix to cover all areas of the CLI Service, but to be used rather as a source to help you get started using the basic features of this service. For more information regarding the CLI Service, refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
General usage overview

Before using the ITSLA CLI, there are some basic areas that must be covered to help you understand how the CLI commands are grouped and what must be alone in order for them to function properly. This section will provide information regarding the different types of CLI commands, the parameters that make up a CLI command, and what steps must be performed before CLI usage.
CLI command types

The two types of CLI commands are listed below, along with a description of each:
Administrative
Used primarily for configuring the product and for normal day-to-day operation. The majority of these commands are issued from the ITSLA Server in order to help monitor the environment. Used for gaining additional information in the event that errors are received. They can also be used for determining the nature of the problem being experienced. Caution must be used when executing these commands, as the system state is vulnerable to alteration upon command execution.
Error-related
If you experience a problem that cannot be resolved by a CLI command, or are reluctant to use the error-related commands as described above, contact Tivoli Customer Support.
CLI command parameters

There are a number of parameters that must be specified when executing a CLI command. The CLI command format is shown below, along with a description of each parameter.
scmd [-p password] [bundle] method [options]
410
-p password
If the password feature has been enabled, you must specify the -p flag along with the appropriate password. More information on setting a CLI password can be found in the following section. There are a total of 10 bundle names from which you may select when specifying this parameter. You may also use no bundle name at all if you would like to receive general CLI Service information. All bundles are listed in Basic CLI commands on page 413. The particular action you would like to take associated with the bundle name specified is substituted for this parameter. Use this parameter if there are additional options you would like to pass with the command. For example, you can use the list or help options if you would like more information on the command specified.
bundle
method
options
Sourcing the ITSLA environment

Before executing a CLI command, you must source the ITSLA environment by running the slmenv command from your ITSLA installation directory. Depending on your operating system, you may execute this command by performing the following step from the ITSLA installation directory: For Windows:
slmenv
For UNIX:
. ./slmenv.sh
This command sets the CLI communication port to 9990 and sources the appropriate Java and ITSLA directories needed for proper command execution.
Default bundles
ITSLA comes with 10 default bundle names that can be used when executing the CLI command. Each bundle is listed below along with a description.
escalate
Escalation bundles. Used to enable, disable, and configure the notification methods selected during installation. If you did not specify a notification method during the time of installation, you may configure the desired method with this bundle.
Appendix D. Command reference
411
etl
Extract, Transform, and Load bundles. This bundle name can be used to enable, disable, or list relevant information concerning the ETLs that are being used. More information on these commands can be found in 5.1, Source ETLs management on page 134, and 5.2, Target ETLs management on page 142. Logging and Tracing bundle. Used to configure messages and trace logging features. More information on these commands can be found in 5.6, Trace and message log files on page 196. Order Manager bundle. If you are experiencing problems with the processing of customer orders, this bundle can be used to help diagnose the problem. Metric Evaluator Manager bundle. Use this bundle to receive information regarding your customer orders. Remote Communication bundle. Using this bundle you are able to display or configure the port being used by the ITSLA Server. ITSLA Database bundle. Provides the user with a wealth of information regarding the objects located in the ITSLA Database, such as in-depth offering and order information. Web Report User bundle. As described in Chapter 6, Service level Reports with ITSLA on page 217, this bundle is used to configure the users who access the ITSLA Reports Server. Component Management bundle. Specifying this bundle name will list information regarding the components being used by ITSLA. You may also request the ITSLA Server status with this bundle, as well as shut down the Server it needed. Warehouse Data Collection bundle. This bundle reports various types of information regarding the TEDW data collection interface.
log
om
mem rcc
sdc
sla
slm
wdccli
To list the available commands for each bundle, include the desired bundle in the scmd bundle_name list command. For a description of what each bundle method represents, issue the scmd bundle_name help command.
412
Basic CLI commands

There are a few basic commands that will help you when using the ITSLA CLI, either by providing detailed information for the command you wish to use, or by restricting access to the CLI commands with a password. Each command is listed below, along with a description.
scmd help
Provides you with general CLI syntax information and lists the bundle names that are available for use. If help is used with a specific bundle name, the methods that can be used with the bundle will be listed, along with a description of each.
scmd list
Displays a list of the bundles that are available for use. If you use specify the list option with a specific bundle name, the available methods that can be used with that bundle will be listed.
scmd setPassword
There may be instances when you do not want every user to have access to the CLI commands. You can use the following command to set a password for the CLI Service:
scmd -p current_password setPassword new_password
If you have never used the password feature before, use password for the current_password parameter and specify your desired password for the new_password parameter. The password you choose must be between six and sixteen characters in length.
scmd setPasswordEnabled
This command allows you to turn the password feature on and off. Even if you have never used the password feature, the -p flag must be specified as shown in the command syntax below:
scmd -p current_password setPasswordEnabled [true | false]
To enable the password feature, specify the true flag at the end of the command; to disable the CLI password feature, specify the false flag. If passwords are enabled, you must specify the -p flag along with the password whenever any CLI command is issued.
413
Useful commands for ITSLA

In the following sections, you will be presented with commands that will assist you in performing various ITSLA administrative tasks described in the this redbook. These sections will not cover every available command for ITSLA, just the ones that are relevant to the subject matter covered in the previous chapters. For a list of all the available commands and for more information regarding the content in the following sections, refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
ETL commands
The following commands can be used to determine how long data is set to stay in the ITSLA Data Mart database and to change the date if you prefer a shorter or longer time period. After sourcing the ITSLA environment, issue the following command to determine when data will expire:
scmd etl getDataExpiration
By default, the command output will appear as follows:

The data is set to expire every 63 days.
If you would like to shorten or lengthen this time period, issue the following command:
scmd setDataExpiration number_of_days
Where number_of_days represents how long you would like the data to stay in the ITSLA Data Mart database until it expires. The scmd etl enable, scmd etl disable, scmd etl getApps, and scmd etl addApplicationData commands were covered in Source ETLs management on page 134, and 5.2, Target ETLs management on page 142.
Offering and order commands

The ITSLA CLI provides a number of ways for users to view in-depth information regarding their offerings and orders. Each section below includes numerous commands that will help you better understand what is contained in each order and offering. For the entire list of available commands, refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.
414
Order commands
There are a number of available commands to help you explore each order that has been created. Table D-1 provides a couple of commands that provide detailed information about each order.
Table D-1 Order commands
Command scmd sdc displayAllCustomerOrders Description
Displays the order ID, state, customer name, and the associated service offering information Displays all metrics that have been configured for an order by the order ID
scmd mem showMetricEvaluators
Offering commands
A list of helpful offering commands is shown in Table D-2, along with a description of each commands output.
Table D-2 Offering commands
Command scmd sdc displayAllServiceOfferings Description
Displays all offerings that have been created, along with the service elements that were included in the offering.
By specifying the service offering ID, all elements associated with the offering, along with their breach values, are displayed.
scmd sdc displayOfferingElementList Offering_ID
Escalation commands
There are a number of commands that you can use to enable or customize your notification methods. For this section, numerous commands are presented that will allow you to enable a notification method and view the parameters for all notification methods that you have configured. An additional command also provided will allow you test the notification methods you have configured.
Enabling a notification method

If you did not enable a notification method during installation, you can do so easily with the ITSLA CLI. Each command related to its notification method is listed below.
415
E-mail notification
For the e-mail notification method, issue the following command:
scmd [-p password] escalate enable email -to email_addresses [-cc email_addresses] -smtp SMTP_Server
Where email_addresses represents the email addresses that will be sent notifications (separate with a space if more than one) and SMTP_Server represents the fully qualified host name of the SMTP server. For example, if you would like to send e-mail notifications to the recipient john@company.com, carbon copy the recipient mary@company.com, through the smtpsrvr.mm3.company.com SMTP Server, issue the following command:
scmd escalate enable email -to john@company.com -cc mary@company.com -smtp smtpsrvr.mm3.company.com
The above command assumes the password feature has not been enabled.
Tivoli Enterprise Console (TEC) notification

For the TEC notification method, issue the following command:
scmd [-p password] escalate enable TEC -server server [-port port]
Where server represents the fully qualified host name of the Tivoli Enterprise Console machine and port represents the port being used to receive events.
SNMP Trap notification

For the SNMP Trap notification method, issue the following command:
scmd [-p password] escalate enable SNMP -dest trap_destination -port port [-community community_name]
Where trap_destination represents the fully qualified host name or IP address. Where the SNMP receiver is running, port is the port being used, and community_name represents the community name of the SNMP events. The community_name parameter is optional for this command, and is defaulted to public when this method is configured during installation. Issue the following command to enable application problem events escalation:
scmd escalate enable ApplicationEvent
Viewing the configured notification parameters

After configuring the desired notification methods, you may issue the following command to view the parameters you configured for each method, whether enabled or disabled:
scmd [-p password] escalate view
416
Output will appear similar to that shown in Example D-1.

Example: D-1 scmd escalate view command output
email is enabled. email recipients =john@company.com,doe@company.com email cc recipients =mary@company.com email SMTP server =smtpsrvr.mm3.company.com email violation message: email trend message =The $MetricName in state $ScheduleState is predicted to be exceeded at $TrendProjectedDate for customer $CustomerName from order $CustomerOrderID. The service component that will cause the violation is $ComponentName. email cancelled message: SNMP is enabled. SNMP destination =12.34.56.789 SNMP port =162 SNMP community name: tec is enabled. tec server=tecsrvr.city.company.com tec port=65535
Testing the configured notification methods

You can issue the following command to test the notification methods that you have configured and enabled:
scmd [-p password] escalate test
417
418
Appendix E.
Source ETLs
A great deal of information was covered in Chapter 5, Administering IBM Tivoli Service Level Advisor on page 133, for the IBM Tivoli Monitoring for Transaction Performance source application (formerly Tivoli Application Performance Management). It is the intention of this appendix to provide a general introduction to the four additional Source ETLs that are provided with IBM Tivoli Service Level Advisor. The following topics and Source ETLs will be discussed: Introduction to the Source ETLs IBM Tivoli Business Systems Manager IBM Tivoli Enterprise Console IBM Tivoli Monitoring for Transaction Performance (TWSM) IBM Tivoli Distributed Monitoring (DM)
419
Introduction to the Source ETLs

The Source ETLs are primarily responsible for extracting information from source databases, transforming the data so that its fits the target schema, and loading the data in the TEDW Central Warehouse database. Each Source ETL that is provided with the IBM Tivoli Service Level Advisor solution follows the same steps, yet how each ETL performs these steps may be drastically different. All data that is eventually transferred to the TEDW Central Warehouse database is inserted in an hourly format; however, different source applications aggregate their data in different ways. While some source applications aggregate their data in hourly formats prior to the running of the Source ETL, data from other source applications is actually transformed by the Source ETL so that it fits the required hourly format in the TEDW Central Warehouse database. Each Source ETL, with the exception of IBM Tivoli Monitoring for Transaction Performance (TAPM), which was covered in Chapter 5, Administering IBM Tivoli Service Level Advisor on page 133, is described in the following sections. It is the intention of this appendix to give a general overview of the objective for each ETL, what processes are executed, and the measurement types that are associated with the source data. It is by no means to be used as an all-inclusive source. For those who would like more information concerning the ETLs, you can find the relevant implementation guide in the following directory for each Source ETL:
TWH_Dir/apps/ETL_Source_Code/v(***)/doc
IBM Tivoli Business Systems Manager

The following sections include a description of the IBM Tivoli Business Systems Manager (TBSM) Source ETL process and its steps, as well as what the TBSM Source ETL is responsible for. For more information, refer to the Tivoli Business Systems Manager Warehouse Enablement Pack: Implementation Guide, which is included in the Source ETL installation directory.
TBSM Source ETL objective

It is the primary purpose of the TBSM Source ETL to extract the LOB-relevant data from the source database and aggregate the LOB percentages into an hourly format. Each related ETL step is described below:
Extract
The LOB changes and LOB state transition data are extracted from the TBSM source database.
420
Transform
LOB state transitions data is transformed to fit the Central Data Warehouse schema, with the LOB state percentage calculated in a hourly format. The results from the transform step are loaded in the Central Data Warehouse, along with any LOB changes that may have been made, such as name or deletion changes.
Load
TBSM Source ETL process description

Located in the DB2 Data Warehouse Center, you will find that there is only one process labeled GTM_c05_LOBState_Process under GTM_Tivoli_Business_Systems_Manager_v1.5_Subject_Area. Four separate steps make up this sole process, each of which is responsible for transferring the relevant TBSM data from the source database to the TEDW Central Warehouse database. The four separate steps are listed below: GTM_c05_s010_LoadLOBStage GTM_c05_s020_LoadLOBCDW GTM_c05_s030_Stage_LobPrcState GTM_c05_s040_Msmt This process should be scheduled daily so that the latest TBSM data is available for the SLA evaluation.
TBSM Source ETL measurement types

There are a total of four TBSM measurement types that may be used when creating a service offering. Each is listed below: LOB LOB LOB LOB state unknown state green state yellow state red
Data received for the above measurement types is recorded as a percentage, with the average for each LOB state equalling 100 percent.
Appendix E. Source ETLs
421
IBM Tivoli Enterprise Console

In the following sections you will find pertinent information regarding the Tivoli Enterprise Console Source ETL. For a more in-depth look at this ETL, refer to the Tivoli Enterprise Console Installation, Usage, and Interface Guide for Tivoli Enterprise Data Warehouse manual, located in the TEC Source ETL installation directory.
TEC Source ETL objective

Whenever an event is closed in the Tivoli Enterprise Console it is added to a specific table in the TEC source database. Each closed event is categorized according to the time taken to close the event, anywhere from one minute to 24 hours or more. It is the responsibility of the TEC Source ETL to transfer this data from the TEC source database to the TEDW Central Warehouse.
TEC Source ETL processes descriptions

There are two processes associated with the TEC ETL located under ECO_Tivoli_Enterprise_Console_v3.7.1_Subject_Area. Each process is described in the following sections.
ECO_c05_ETL1_Process
The primary purpose of this process is to extract the closed events data from the TEC source database and load it in the Central Data Warehouse. It should be scheduled initially to run after the ECO_c10_Create_Archive_Process, and daily by itself thereafter. There are three steps located in ECO_c05_ETL1_Process, as shown below: ECO_c05_s010_Extract ECO_c05_s020_Transform ECO_c05_s030_Load
ECO_c10_Create_Archive_Process
This process is mainly responsible for creating the tec_t_archive table, along with the tec_close_trigger database trigger. When ECO_c05_ETL1_Process runs, the data that it extracts is located in the tec_t_archive table. Since this table is not initially present, it is important for ECO_c10_Create_Archive_Process to be run only once, prior to ECO_c05_ETL1_Process. There is only one step used for ECO_c10_Create_Archive_Process, which is labeled ECO_c010_s010_Create_Archive.
422
If you are using the Tivoli Decision Support for Event Management Guide, the tec_t_archive table may already exist. If this is the case, this process step does not have to be run. Keep in mind that this table may become very large, depending on the amount of archived data you would like to store. For more information concerning this, refer to the Tivoli Enterprise Console Installation, Usage, and Interface Guide for Tivoli Enterprise Data Warehouse manual located in the TEC Source ETL installation directory.
TEC Source ETL measurement types

There are a total of eight measurement types for TEC that may be included when creating a service offering. Each is listed below: Events Events Events Events Events Events Events Events closed in less than 15 minutes closed in 15 to 30 minutes closed in 30 to 60 minutes closed in 1 to 2 hours closed in 2 to 4 hours closed in 4 to 8 hours closed in 8 to 24 hours closed in 24 or more hours
Data that is associated with the above measurement types represents the total number of events that have been closed in the given time period.
IBM Tivoli Monitoring for Transaction Performance (TWSM)

Information regarding the TWSM Source ETL can be found in the following sections. For more information regarding this ETL, refer to the Tivoli Web Services Manager Installation, Usage, and Interface Guide for Tivoli Enterprise Data Warehouse manual, located in the TWSM Source ETL installation directory.
TWSM Source ETL objective

Data located in the TWSM source database is transferred to the Central Data Warehouse via the TWSM Source ETL. Five specific tasks are performed by this ETL, as described below: 1. After data has been loaded in the TWSM source database, static data is inserted in the Central Data Warehouse by the Source ETL. 2. Staging tables for the Source ETL are created.
423
3. Available data is then aggregated into an hourly format. 4. The minimum, maximum, and average data values are calculated. 5. The results from steps 3 and 4 are loaded in the Central Data Warehouse.
TWSM Source ETL processes description

There are a total of two processes located under BWM_TivoliWebServicesManager_v1.7.0_Subject_Area. Each process is described below.
BWM_c05_Initialize_Process
This process is responsible for loading the initial TWSM data in the Central Data Warehouse. It consists of nine individual steps, as listed below: BWM_c05_s010_comp BWM_c05_s020_init_extract_qos BWM_c05_s030_transform_qos BWM_c05_s040_qos_bst BWM_c05_s050_qos_prt BWM_c05_s060_qos_rtt BWM_c05_s070_init_extract_sti BWM_c05_s080_transform_sti BWM_c05_s090_sti_rtt This process should be scheduled to run for one time only, prior to BWM_c10_Load_Warehouse_Process.
BWM_c10_Load_Warehouse_Process
After the initial loading of the TWSM data, this process provides the Central Data Warehouse with the daily TWSM data. Nine steps make up this process, as listed below: BWM_c010_s010_comp BWM_c010_s020_extract_qos BWM_c010_s030_transform_qos BWM_c010_s040_qos_bst BWM_c010_s050_qos_prt BWM_c010_s060_qos_rtt BWM_c010_s070_extract_sti BWM_c010_s080_transform_sti BWM_c010_s090_sti_rtt This process should be run after BWM_c05_Initialize_Process is run for the first time, and by itself daily thereafter.
424
TWSM Source ETL measurement types

There are a total of three TWSM measurement types that may be included when creating a service offering. Each type is listed below: Roundtriptime Servicetime Pagerendertime Data associated with the above measurement types is categorized by an hourly-based minimum, maximum, and average value.
IBM Tivoli Distributed Monitoring (DM)

Information related to the IBM Tivoli Monitoring Source ETL can be found in the following sections. For more information regarding this ETL, refer to the Tivoli Distributed Monitoring Warehouse Enablement Pack: Implementation Guide, located in the DM Source ETL installation directory.
DM Source ETL objective

Depending on your operating system, monitors in the OS-specific DM profile are used to collect DM data every five minutes, which is then aggregated nightly into an hourly format in the DM_Metrics table. The DM Source ETL process extracts data from this table in the source database and loads it into the Central Data Warehouse.
DM Source ETL processes descriptions

There are a total of two processes associated with the DM Source ETL. Each process is described in the following sections.
DMN_c05_initDMData_Process
This process will execute an initial load of the DM data that is located in the DM source database. There are two steps located within this process: DMN_c05_s010_initDMData DMN_c05_s020_processDMData This process should be scheduled to run one time only, prior to DMN_c10_loadDMData_Process.
425
DMN_c10_loadDMData_Process
The primary role for this process is to incrementally extract DM data each day from the DM source database. There are two steps associated with this process: DMN_c10_s010_loadDMData DMN_c10_s020_processDMData This process should be initially scheduled to run after the DMN_c05_initDMData_Process, and by itself daily thereafter.
DM measurement types
There are a total of 67 measurement types for DM that may be included when creating a service offering. The data associated with each measurement type is categorized by an hourly minimum, maximum, and average value. To view the list of these measurement types, refer to the Tivoli Distributed Monitoring Warehouse Enablement Pack: Installation Guide, located in the DM Source ETL installation directory.
426
Abbreviations and acronyms

AE AES BCM BI BU CDE CDW CLI CP CWM DB2 DDL DM ETL GNOME IBM ISP ITM ITSLA ITSO JDBC JSP KDE LOB ODBC
Advanced Edition Advanced Edition Single-Server Business Continuity Management Business Intelligence Business unit Common Desktop Environment Central Data Warehouse Command line interface Contingency Planning Common Warehouse Metadata IBM DB2 Universal Database Enterprise Edition Data definition language Tivoli Distributed Monitoring Extract, transform, and load GNU Network Object Model Environment International Business Machines Corporation internet services provider IBM Tivoli Monitoring IBM Tivoli Service Level Advisor International Technical Support Organization Java Database Connectivity Java Server Pages K Desktop Environment Lines of business Open Database Connectivity
ODS OLAP OLTP ROLAP SLA SLM SLO TAPM TBSM TDS TEC TEDW TWH TWSA TWSM UDB UTC
Operational data source Online Analytical Processing Online Transaction Processing Relational Online Analytical Processing Service Level Agreement Service Level Management Service Level Objective IBM Tivoli Monitoring for Transaction Performancet IBM Tivoli Business Systems Manager Tivoli Decision Support IBM Tivoli Enterprise Console Tivoli Enterprise Data Warehouse Tivoli Warehouse Tivoli Web Services Analyser IBM Tivoli Monitoring for Transaction Performance Universal Database Universal Time Coordinated
427
428
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see How to get IBM Redbooks on page 431.
DB2 UDB Version 7.1 Performance Tuning Guide, SG24-6012 Introduction to Tivoli Enterprise Data Warehouse, SG24-6607
Other resources
These publications are also relevant as further information sources:
Administrators Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835 Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833 Database Performance on AIX for DB2 UDB and Oracle Environments, SG24-5511 DB2 UDB Administration Guide: Implementation Version 7, SC09-2944 DB2 UDB Administration Guide: Performance Version 7, SC09-2945 DB2 UDB Administration Guide: Planning Version 7, SC09-2946 DB2 UDB Command Reference Version 7, SC09-2951 DB2 UDB Quick Beginnings for UNIX, GC09-2970 DB2 UDB Quick Beginnings for Windows Version 7, GC09-2971 Getting Started with IBM Tivoli Service Level Advisor Version 1.1, SC32-0834 IBM Tivoli Service Level Advisor Release Notes Version 1.1, GI11-0908 Tivoli Enterprise Data Warehouse Enabling an Application Version 1.1, GC32-0745 Tivoli Enterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744
429
Tivoli Enterprise Data Warehouse Release Notes Version 1.1, GI11-0857 Tivoli Decision Support Installation Guide, GC32-0438
Referenced Web sites

These Web sites are also relevant as further information sources: DB2 UDB online support
http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7pubs. d2w/en_main
eFix 1.7-WSM-0003e download

ftp://ftp.tivoli.com/support/patches/LA/1.7-WSM-0003E.almondbutter
IBM DB2 magazine

http://www.db2mag.com
IBM WebSphere Application Server InfoCenter

ITIL-related Web sites

http://www.itsmf.com http://www.itil.co.uk http://www.ccta.gov.uk
Java information
http://java.sun.com/
Object Management Group

http://www.omg.org
Tivoli Enterprise Data Warehouse support

http://www.ibm.com/software/sysmgmt/products/support
Tuning information
http://www.db2mag.com/db_area/archives/2001/q1/hayes.shtml http://www.db2mag.com/db_area/archives/2001/q4/hayes.shtml
WebSphere Infocenter
430
How to get IBM Redbooks

You can order hardcopy Redbooks, as well as view, download, or search for Redbooks at the following Web site:
ibm.com/redbooks
You can also download additional materials (code samples or diskette/CD-ROM images) from that site.
IBM Redbooks collections

Redbooks are also available on CD-ROMs. Click the CD-ROMs button on the Redbooks Web site for information about all the CD-ROMs offered, as well as updates and formats.
Related publications
431
432
Index
Symbols
_adminServerFatalError 315 change management 370, 398 change users access 239 changing data graphs 254 CLASSPATH 300 CLI command parameters 410 CLI command types 410 CLI issues 331 Cognos 35 coherent whole 5 Common Warehouse Metadata 35 community name 72, 416 company logo 250 component 27, 140 component attribute 47, 140 component relationship 47 component type 27 component type sources 320 configuration items 392 configuration management 369, 392 Console handler 197 consumer 164, 255 consumers 385 contingency planning 369, 374, 381 contracts underpinning 390 Control Server 36 correlation 35 cost center 381 cost management 368, 374, 380 create a reports user 238 creating orders 179 critical state 170 Crystal Decisions 35 Crystal Reports 257, 269 customer 6, 27, 164, 237, 385 customer creation troubleshooting 321 customer order 28 customer order issues 323 customer order ranking 223 customer ranking 223 customer satisfaction 383 customers 167 customizing reports 250 CWM standard 35
A
administrative CLI 410 algorithm 222 analytical tools 61 APARs JR16650 and JR16766 342 APF_TAPM_Source 134, 136 APF_TWH_CDW_Target 134 application sizing 377 application source tables 134 authenticating users 255 availability 26 availability management 369, 374, 377
B
backup 69 baroc file for ITSLA 74 becoming ITSLA enabled 46 blank install screen 317 bottlenecks 374 breach value 27 Brio Technology 35 BrioQuery Designer 257 building a chart 274 Business Objects 35, 257, 277 Business Objects Universe 278 business processes 4 business schedule 27 button substitution 251 BWM_TWH_CDW_Target 134 BWM_TWSM_Source 134
C
capacity management 369, 373 capacity planning 377 categories 221 CCTA 3, 366 central warehouse repository 82 change 27
433
cycle of change 397
D
data collection 28 data collection enablement Target ETL data collection 142 data flow scenario 53 data graphs 254 data mart definition 23 Data Mart ETL 26 data warehouse 25 database performance 291 DB2 fixpack 82 DB2 instance 83 DB2 Warehouse Control 84 DB21034E 321 DB2COMM 307 db2java.zip 300, 318 db2profile 301 DE_DE language 317 default bundles 411 deleting orders 192 deleting reports users 240 demand management 377 dependency 28 deploying services 4 development mode 140 disable IIS 315 disabling reports user 240 disintegration 391 display interface 245 distributed installation 56 DM measurement types 426 DM Source ETL 425 DMN_RIM_Source 134 DMN_TWH_CDW_Target 134 DWC02015E 342 DYK schema 407 DYK_CAT 37, 68, 89, 108, 404 dyk_cat.log 303 dyk_cat_dbinst script 343 dyk_cat_odbc.bat 104 DYK_DM 37, 68, 89, 108, 294, 407 dyk_dm.log 303 dyk_dm_dbinst script 343 dyk_dm_odbc.bat 104 DYKAL0009E 333 DYKAL1000I 332
DYKAL1020I 332 DYKAL2020I 331 DYKAL2030E 331, 333 DYKAL3003E 344 DYKAL3013E 318 DYKAL3014E 318 DYKGU0071E 320321 DYKGU0087E 336 DYKME9034E 325 DYKME9064W 324 DYKSL1102E 327 DYKSL1104E 327 DYKUT168E 330
E
ECO_TEC_Source 134 ECO_TWH_CDW_Target 134 eFix 71 e-mail notification 72 e-mail notification method 416 enabling notification method 415 end time 28 end-to-end view 35 error control 397 error-related CLI 410 escalate 411 escalation commands 415 ETL 25, 412 ETL management 142 ETL production mode 140 ETL schedule 194 ETL scheduling 140 evaluation 28 evaluator type 257 event escalation troubleshooting 325 event notification 72, 118 Exclusions 14 executive 164 executive summaries 257 expected service 384 EXTENTSIZE 293 external SLA 13 external SLA type 167 external specsheet 388 extract control 47 extract control design 48 extract log 47 Extract, Transform and Load 25
434
extraction of application data 134
I
IBM Console 25 IBM Console issues 338 IBM Console server 67 IBM DB2 commands 311 IBM DB2 fixpack 82 IBM DB2 instance 83 IBM DB2 troubleshooting 300 IBM Java Console 25 IBM WebSphere Application Server troubleshooting 315 Informix 70 instance 83 internal error 321 internal SLA in-house SLA 13 Internal SLA type 167 Internal specsheet 388 internet services provider 13, 427 IP address 35 ISMP directories 317 ISP 13 IT organization 4 IT Services 5 ITIL 3, 366 ITSLA administration issues 319 ITSLA backup issues 330 ITSLA CLI 410 ITSLA components 19 ITSLA configuration issues 317 ITSLA Database 22, 43, 404 ITSLA Database Server 22 ITSLA enabled application 46 ITSLA ETL programs 94 ITSLA ETL scheduling 144, 151 ITSLA ETLs data collection 142 ITSLA event notification 118 ITSLA listUser 165 ITSLA Measurement Data Mart 23, 44, 407 ITSLA Reports Server 21 ITSLA restore issues 330 ITSLA Server 21 ITSLA services issues 335 ITSLA Task Drivers 20 ITSLA TCP/IP ports 62 ITSLA TEC baroc file 74 ITSLA TEC rule set 75 ITSLA troubleshooting 316 ITSLA user creation 165
F
fcm filter 246 features for security 158 filtering masks 204 filtering parameters 246 final service level 42 fixpack for DB2 82 formating data 144 frequency 28 functions for tracing 159 fwp_mcr 201
G
gathering measurement data 10 general management service 10 generic service 384 generous service 384 good service 14 graphs 235 group of customers 164 group of incidents 8 GTM_c05_LOBState_Process 421 GTM_co5_LOBState_Process 141 GTM_OBJECT_Source 134 GTM_TWH_CDW_Target 134 guaranteed level of service 14
H
handlers console 197 multi-file 197 serial file 197 handling service problems 14 hardware requirements 56 Help Desk 8 help desk 394 HELPMSG 212 hierarchy of services 9 high level of service 5 high usage 170 historical data 35 hole entity 6 hostname 35 HTTP Server port 67 HYKRP0009E 346
Index
435
J
Java bean 255 Java code 249 Java Server Pages 242, 427 Java-based console 159 Java-based servlets 21 jc.sh script 207 JDBC 2.0 300 JDBC code level 85 JDBC level 316 JDBC levels 300 JSP files 242 JVMARGS 337
measurement schema 404 measurement source 29 measurement source applications 46 measurement source code 47, 99, 144 measurement tables 140 metadata interchange 35 methods for authenticating 255 metric 28 metrics 246 Microsoft SQL 71 modeling 377 MTBF 378 MTBSI 378 Multi-file handler 197
L
life cycle 7 Limitations 13 lines of business 13, 367, 427 link parameter 245 Linux 89, 108 listing ITSLA users 165 LOB 13, 367, 420 LOB states 421 location variable 216 log file for TEDW 88 log files 196 logfilsiz 292 loggers 197 logical design 57 logout link 247 logutil command 198 low impact state 171 lowest single hourly value 176
N
naming convention 47 nbsp 322 network considerations 57 network speed 70 no service 29, 324 no service state 171 notification method 415
O
Object Management Group 35 ODBC connection 48, 70 ODBC connections 104 ODBC data sources 308 ODBC System DSN 136 off hours state 171 offering 29 offering commands 415 offering component 29 offering component ranking 224 offering creation troubleshooting 321 offering state 30 offerings 167 OLAP 61 open interface 35 operations 165 optimizing DB2 performance 310 Oracle 70 order 30 order commands 415 order creation 179 order deletion 192 order ID 30, 190
M
maintainability 378 management services layer 10 managing Process ETL 150 managing Registration ETL 142 managing Target ETL 142 MAXAGENTS 291 maximum connections 309 maximum rows 250 McOrbletApp process 338 mean time between failure 378 mean time between system incidents 378 measurement 28 measurement data 46
436
order state view,viewing orders state 189 orders 167, 246 orders creation troubleshooting 321 orders submission troubleshooting 321 Outsourced SLA type 167 overall report 226, 228
P
parallel I/O 294 peak 28, 30 peak state 170 performance management 375 performance tips 290 period 30 planning for supporting applications 56 planning worksheets 76 portal page 164, 255 PREFETCHSIZE 293 prepackaged 59 presentation layer 25 Presentation Services tuning 295 prime state 171 print tips 234 pro-active monitoring 8 problem management 370, 396 Process ETL 26, 38, 94 Process ETL management 150 Process ETL scheduling 151 process flow 41 production mode 140 profit center 381 prune measurement control 47 published offering 30
raw data 35 rcc 318 RDBMS 36 realm 31, 164, 237 realm creation troubleshooting 321 realm values 255 realms 167 Redbooks Web site 431 Contact us xxii refresh feature 247 Registration ETL 26, 37, 94 Registration ETL management 142 Registration ETL scheduling 144 reliability 378 reorgchk 293, 311 report servlets 244 reporting categories 225 reports 31 reports results 251 reports users 237 resilience to failure 378 resource 31 resource management 377 resource ranking 224 resource type 185 resource type tree 173 results report 226, 228 results table 251 Resultview 257 Reviews 14 rollback 31 rule set 75 runstats 293, 310
Q
QoS Job 173, 184 QoS ROUNDTRIPTIME 174 quality of service 10 quantifiable terms 11 quantification of services 11 query interface 245 query performance 310 quick delivery from IT 5
S
schedule 27 schedules 167 scmd commands escalate 118 escalate view 325 etl addApplicationData 143, 319 etl disable 144, 320, 331 etl enable 144, 319 etl getApps 143 etl getDataExpiration 157, 414 etl setData Expiration 157 list 318 log handler 197
R
ranking 222 ranking categories 223
Index
437
log trace 203 mem flushEvents 325 mem removeStoppedRetryEntries 323 mem retryMissedIntervals 323 mem ShowMetricEvaluators 323 mem showMetricEvaluators 415 mem showStoppedRetry 323 rcc getport 335 rcc setport 335 sdc adjustIdGenerators 321 sdc displayActiveServiceElements 320 sdc displayAllCustomerOrders 415 sdc registerWarehouseData 320 setPassword 334 setPasswordEnabled 413 sla AddUser 165 sla listUser 165 Scope 13 SDC 320 sdc 412 SDC Data Sources 316 SDC errors 316 Seagates Crystal Reports 257 search function 248 security 378 security features 158 selectable resources 319 Serial file handler 197 server for IBM Console 67 Server Performance Prediction guide 70 server-cfg.xml file 294 Service Catalogue 389 expected 384 generic 384 generous 384 Level Agreement 390 Quality Plan 390 total 384 service 31 Service Catalogue 389 service deliver 366 Service Delivery 7 service delivery discipline 371 service element 31 service elements 320 Service Level Agreement 386, 390 service level agreement 13, 32 service level indicators 14
Service Level Management external role 385 internal role 385 service level management 5, 11, 13, 18, 32, 367368, 382, 385 service level management process 46 service level objective 32, 222, 427 service level objectives 14, 19 service level violations 42 Service Management 10 service management 366 service offering 32 service provider 6, 32 service quality 9 Service Quality Plan 390 service quality plan 388 service support 366 serviceability 378 shared memory segments 305 shutdown ITSLA 208 single system installation 61 SLA 13 SLA data value troubleshooting 322 SLA management 40, 367 SLA results 21 SLA state 33 SLA type 231 SLA type ranking 224 SLA types 167 SLA violations 45 SLM 1213 slm 412 SLM.baroc 74, 328 slm.rls 75 slmbackup command 211 slmenv 411 SLMMessage1.log 200 slmrestore 214 slmrestorestart script 214 SLO 222 SNMP API 329 SNMP event notification 72 SNMP events 416 SNMP notification issues 329 SNMP notification method 416 software control and distribution 370 software requirements 56 Source ETL 26 Source ETLs 419
438
specsheet external 388 internal 388 sponsor 385 SPR_RIM 70 SQL processes 137 SQL0803N 321 SQL1005N 304 SQL1032N 304, 318 SQL1054N 307 SQL1063N 307 SQL1116N 330 SQL1117N 330 SQL1224N 305 SQL1403N 304 SQL30081N 306 standard 33 standard state 171 start ITSLA 205 start time 33 status accounting 393 steady 33 Sun Solaris 108 SVCENAME 306
T
table organization 311 TAPM RIM 71 TAPM Warehouse Source 135 Target ETL 26 Target ETL management 142 TBSM measurement types 421 TBSM Source ETL 420 TCP/IP port numbers 60, 62 TEC event notification 72 TEC event troubleshooting 327 TEC measurement types 423 TEC notification 416 TEC notification method 416 TEC RIM 71 TEC rule set for ITSLA 75 TEC Source ETL 422 TEC Source ETL processes 422 TEDW Control Center 25 TEDW installation failure 312 TEDW TCP/IP port numbers 60 Term 13 test mode 140
third-party application 143 third-party reporting 257 time frame 324 time period 230 time span 319 time zones example 196 timestamp 213 timestamps 48 Tivoli Decision Support 70, 423 Tivoli Enterprise Data Warehouse 25 Tivoli Presentation Services 111 Total service 384 tracing functions 159 trcFile.slm 199 trend 33 trend analysis 33 trends 21 trends report 226 Trendview 257 Troubleshooting 299 TSLMUninstall.log 354 tuning databases 291 tuning tips 290 TWH.log file 88 twh_app_deinstall.cfg 360 TWH_CDW 37, 294 TWH_CWD 87 TWH_MART 37, 59, 87 TWH_MD 25, 36, 59, 93 TWSM measurement types 425 TWSM source database 423 TWSM Source ETL 423 TWSM Source ETL process 424
U
UDP 329 underpinning contracts 390 understanding time zone issues 196 uninstall ITSLA databases 362 ITSLA Reports 355 ITSLA Server 358 ITSLA Target ETLs 359 ITSLA Task Drivers 354 Universe 278 unrestricted view 164 unscheduling ETLs 210 up and running 79
Index
439
update JDBC level for DB2 85 updating JDBC level 301 user creation 157, 165 user ID views 164 user management 157
V
vicious cycle of chance 397 view 33, 164 view violation 191 violation 3334 violations notification 72 violations report 226227 Violationview 257, 270
W
warehouse logger 313 warehouse packs 59 warehouse server 313 WcOrbletApp process 338 wdccli 412 Web Browser support 64 web report 34 Web services for IBM Console 67 web.xml 345 web-based report 18 WebServices Courier 70 WebSphere performance 294 whole services self-contained services 5 withdrawn offering 34 withdrawn order 34 workload management 376 worksheets for planning 76
X
X-categories 266 xcopy 92
Y
Y-facts 266
Z
Z-categories 266
440
Back cover

Achieve proactive SLA management ensuring service quality Generate reports and identify trends toward SLA violations Manage Service Level and meet customer expectations
The IBM Tivoli Service Level Advisor Version 1.1 is a new product addressing the needs of enterprise customers. This product will be the first to integrate with other management products to provide both a mechanism to report on Service Level Management issues, and also to forecast trends to allow an enterprise to consistently sustain service levels. The primary objective of this redbook is to introduce the new IBM Tivoli offering for defining and Managing Service Level Agreements, and is targeted at the technical professional responsible for providing services in an IT organization. It can be used as a reference book for the deployment of IBM Tivoli Service Level Advisor Version 1.1, guiding you during the planning, installation, configuration, administration, troubleshooting, and general product usage phases, with focus on how to effectively deploy this product in a way that quickly generates real business value for customers. This redbook is a valuable addition to existing product documentation and should be read in conjunction with the official product documentation, which complements some of the concepts explained in this book. .
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

SG24-6611-00 ISBN 0738427063

Introducing IBM Tivoli Service Level Advisor Sg246611

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Introducing IBM Tivoli Service Level Advisor Sg246611

Hochgeladen von

Copyright:

Verfügbare Formate

Front cover

Introducing IBM Tivoli Service Level Advisor

Copyright IBM Corp. 2002

Introducing IBM Tivoli Service Level Advisor

Introducing IBM Tivoli Service Level Advisor

Introducing IBM Tivoli Service Level Advisor

Introducing IBM Tivoli Service Level Advisor

Copyright IBM Corp. 2002

Introducing IBM Tivoli Service Level Advisor

Introducing IBM Tivoli Service Level Advisor

Copyright IBM Corp. 2002

C-2 C-3 C-4 D-1 D-2

Introducing IBM Tivoli Service Level Advisor

Copyright IBM Corp. 2002

Introducing IBM Tivoli Service Level Advisor

The team that wrote this redbook

Copyright IBM Corp. 2002

Introducing IBM Tivoli Service Level Advisor

Become a published author

Send your comments in an Internet note to:

Introducing IBM Tivoli Service Level Advisor

All about IBM Tivoli Service Level Advisor

Copyright IBM Corp. 2002

Introducing IBM Tivoli Service Level Advisor

Copyright IBM Corp. 2002

Introducing IBM Tivoli Service Level Advisor

Figure 1-1 IT Service perceived by the end user and in reality

Introducing IBM Tivoli Service Level Advisor

1.3 Service Delivery

Figure 1-2 Service Delivery life cycle

Introducing IBM Tivoli Service Level Advisor

Approved Change request

Software Delivery & Control

Figure 1-3 Service Delivery in context

1.4 Ensuring service quality

Figure 1-4 Point-solution based management infrastructure

Introducing IBM Tivoli Service Level Advisor

Customer Hardware Service Provider Third-Party management

IT infrastructure management Skills Software Documentation

Figure 1-5 Customer, service provider, and service management

1.5 Service Level Management

Figure 1-6 Service Level Management iterative process

Introducing IBM Tivoli Service Level Advisor

1.6 Why bother with Service Level Management

Introducing IBM Tivoli Service Level Advisor

Introducing IBM Tivoli Service Level Advisor

IBM Tivoli Service Level Advisor general overview

Copyright IBM Corp. 2002

2.1 Overview of IBM Tivoli Service Level Advisor

Introducing IBM Tivoli Service Level Advisor

2.2 IBM Tivoli Service Level Advisor components

Chapter 2. IBM Tivoli Service Level Advisor general overview

Source Application Databases ITSLA Server

ITSLA Reports Server

TEDW Control Center

TEDW Central Warehouse

ITSLA Measurement Data Mart

ITSLA Database Server

ITSLA Task Drivers and IBM Console

Figure 2-1 ITSLA core and logical components relationship

2.2.1 ITSLA Task Drivers

Introducing IBM Tivoli Service Level Advisor

2.2.2 ITSLA Server