Teradata Viewpoint Configuration Guide

Transcription

1 Teradata Viewpoint Configuration Guide Release B K October 2012

2 The product or products described in this book are licensed products of Teradata Corporation or its affiliates. Teradata, Active Enterprise Intelligence, Applications-Within, Aprimo, Aprimo Marketing Studio, Aster, BYNET, Claraview, DecisionCast, Gridscale, MyCommerce, Raising Intelligence, Smarter. Faster. Wins., SQL-MapReduce, Teradata Decision Experts, "Teradata Labs" logo, "Teradata Raising Intelligence" logo, Teradata ServiceConnect, Teradata Source Experts, "Teradata The Best Decision Possible" logo, The Best Decision Possible, WebAnalyst, and Xkoto are trademarks or registered trademarks of Teradata Corporation or its affiliates in the United States and other countries. Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc. AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc. Apache, Apache Hadoop, Hadoop, and the yellow elephant logo are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. Axeda is a registered trademark of Axeda Corporation. Axeda Agents, Axeda Applications, Axeda Policy Manager, Axeda Enterprise, Axeda Access, Axeda Software Management, Axeda Service, Axeda ServiceLink, and Firewall-Friendly are trademarks and Maximum Results and Maximum Support are servicemarks of Axeda Corporation. Data Domain, EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation. GoldenGate is a trademark of Oracle. Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company. Hortonworks, the Hortonworks logo and other Hortonworks trademarks are trademarks of Hortonworks Inc. in the United States and other countries. Intel, Pentium, and XEON are registered trademarks of Intel Corporation. IBM, CICS, RACF, Tivoli, and z/os are registered trademarks of International Business Machines Corporation. Linux is a registered trademark of Linus Torvalds. LSI is a registered trademark of LSI Corporation. Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United States and other countries. NetVault is a trademark or registered trademark of Quest Software, Inc. in the United States and/or other countries. Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries. Oracle, Java, and Solaris are registered trademarks of Oracle and/or its affiliates. QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation. Red Hat is a trademark of Red Hat, Inc., registered in the U.S. and other countries. Used under license. SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc. SPARC is a registered trademark of SPARC International, Inc. Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and other countries. Unicode is a registered trademark of Unicode, Inc. in the United States and other countries. UNIX is a registered trademark of The Open Group in the United States and other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN "AS-IS" BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. IN NO EVENT WILL TERADATA CORPORATION BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The information contained in this document may contain references or cross-references to features, functions, products, or services that are not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features, functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions, products, or services available in your country. Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any time without notice. To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please teradata-books@lists.teradata.com. Any comments or materials (collectively referred to as "Feedback") sent to Teradata Corporation will be deemed non-confidential. Teradata Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform, create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services incorporating Feedback. Copyright by Teradata Corporation. All Rights Reserved.

3 Table of Contents List of Figures 9 List of Tables 11 Preface 13 Changes to This Book 13 Purpose 13 Audience 13 Related Documentation 13 Software Download 14 CHAPTER 1 Teradata Viewpoint Requirements 15 Teradata Viewpoint Server 15 Client Machine Recommendations 15 Teradata Viewpoint Server Requirements 15 Supported Teradata Database Versions 16 CHAPTER 2 Start and Stop Teradata Viewpoint Services 17 CHAPTER 3 Teradata System Preparation 19 Set Up TASM and Alerting Tables 19 Set Up Environment to run DBSSetup 19 Run DBSSetup 20 Create a Teradata User for Data Collection 21 CHAPTER 4 Configure Viewpoint to Monitor a Teradata Database System 23 Log On to the Teradata Viewpoint Server 23 Add Teradata Database Systems 23 Enable the Data Collectors 25 Collector Information 26 Account Info 26 Teradata Viewpoint Configuration Guide, Release

4 Alert Request 26 AWT Info 26 Database Space 26 Disk Space 27 Elastic Limit 27 Elastic Usage 27 Lock Info 27 Query Count 27 Resource Usage 28 Sessions 28 SQL Explain 28 System Config 29 System Stats 29 Table Space 29 TASM Config 29 TASM Distribution 30 TASM Exception 30 TASM State 30 TASM Summary 30 Virtual Storage 30 CHAPTER 5 Teradata Aster System Preparation 31 Enable Space Usage Collection 31 CHAPTER 6 Configure Viewpoint to Monitor a Teradata Aster System 33 Log On to the Teradata Viewpoint Server 33 Add Teradata Aster Systems 33 Enable the Data Collectors 34 Collector Information 34 Cluster Status 34 Component Stats 34 Nodes 35 Processes 35 Space Usage 35 Workloads 35 4 Teradata Viewpoint Configuration Guide, Release 14.01

5 CHAPTER 7 Changing a Teradata System Nickname 37 CHAPTER 8 Configure Alerts 39 Migrate Existing Alerts 39 Define New Alerts 39 CHAPTER 9 Teradata Manager Feature Equivalence 41 Uninstall Teradata Manager 41 Configure Viewpoint to Monitor a Managed Server 45 CHAPTER 11 Configure Teradata Viewpoint LDAP 47 Prerequisites 47 Definitions 47 Before You Begin 48 LDAP Data Interchange Format (LDIF) 48 Determine LDAP Configuration Mode 51 Is Username in DN? 53 Number of Bind Patterns 53 LDAP Configuration 53 Standard Configuration and Testing 55 Role-mapping 56 LDAP Over SSL (LDAPS) 57 CHAPTER 12 Configure Teradata Viewpoint Security 59 Control Access to Portlets 59 Control Access within Portlets 59 Add Teradata Viewpoint Roles 59 Add Teradata Viewpoint Users 60 Teradata Viewpoint Configuration Guide, Release

6 CHAPTER 13 Configure Teradata Viewpoint to Log to TVI 61 CHAPTER 14 Back Up Teradata Viewpoint Databases 63 Backup Administration Portlet 63 Third-Party Application Backup 64 CHAPTER 15 Restore a Teradata Viewpoint Database 65 Restore a Database from Teradata Viewpoint Version or Later 65 Restore a Database from Teradata Viewpoint Version or Earlier 66 CHAPTER 16 Migrate to a New Teradata Viewpoint Server 68 CHAPTER 17 Change the Session Timeout and Default Locale 71 CHAPTER 18 Reset the Admin User Password 73 CHAPTER 19 Ports Used by Teradata Viewpoint 74 Incoming Ports 74 Outgoing Ports 74 6 Teradata Viewpoint Configuration Guide, Release 14.01

7 CHAPTER 20 Set Teradata Viewpoint Server Time 75 CHAPTER 21 Configure NTP Time Synchronization 77 CHAPTER 22 Teradata Viewpoint Clustering 79 Cluster Configurations 79 High Availability Configuration: Two Teradata Viewpoint Servers 79 High Usage Configuration: Three or More Teradata Viewpoint Servers 80 Advanced Configuration: Three or More Teradata Viewpoint Servers with Dedicated Cache Database Server 80 Failure Scenarios 81 Data Collection Service Failure (Scenario 1) 81 Cache Database Failure (Scenario 2) 81 Active Teradata Viewpoint Server Failure 82 Create a Teradata Viewpoint Cluster 83 System Preparation 83 Cluster Setup Tool 83 Disable a Teradata Viewpoint Cluster 84 Add Additional Teradata Viewpoint Servers to a Cluster 84 Promote the Standby Cache Database 84 Configure Automatic Promotions 85 Additional Cluster Considerations 86 LAN or WAN 86 Disk Capacity 86 Getting Notifications of Failures and Promotions 87 Load Balancing 87 CHAPTER 23 Configure Teradata Viewpoint SSL Support 88 Configure Teradata Viewpoint for SSL support 88 Configure All Teradata Viewpoint Access to be Over SSL 88 CHAPTER 24 Teradata Viewpoint Properties 89 Available Properties 89 Teradata Viewpoint Configuration Guide, Release

8 Accessing Properties 90 vp-property.sh 90 CHAPTER 25 Installing Teradata Data Lab xx.xx 91 Install Teradata Data Lab 91 Uninstall Teradata Data Lab Package Manually 91 Configuring Notifications 91 CHAPTER 26 Upgrade to Teradata Viewpoint xx.xx 93 Install Teradata Viewpoint for Electronic Software Distribution 93 Upgrades from Teradata Viewpoint xx.xx and Earlier 93 Upgrades from Teradata Viewpoint xx.xx and Earlier 94 Upgrades from Teradata Viewpoint xx.xx and Earlier 94 Download the Teradata Viewpoint Software 95 Install or Upgrade a Standalone Teradata Viewpoint Server 96 Install or Upgrade Using TDPut 96 Install or Upgrade Using Install Script 97 Install or Upgrade a Teradata Viewpoint Cluster 97 Install or Upgrade a Cluster Using TDPut 98 Install or Upgrade a Cluster Using Install Script 98 Handle Failed Upgrades of Teradata Viewpoint 98 Verify the Previous Database Backup 99 Copy SSL Certificates to New Teradata Viewpoint Keystore 99 Set Up New Collectors and Portlets 100 CHAPTER 27 Back Down to a Previous Teradata Viewpoint Version Teradata Viewpoint Configuration Guide, Release 14.01

9 List of Figures Figure 1: Database Setup window Figure 2: Add or Remove Programs Dialog Figure 3: High Availability Configuration Figure 4: High Usage Configuration Figure 5: Advanced Configuration Figure 6: DCS Failure Figure 7: Cache Database Failure Figure 8: Active Teradata Viewpoint Server Failure Teradata Viewpoint Configuration Guide, Release

10

11 List of Tables Table 1: Terms and Definitions Table 2: LDAP Configuration Attributes and Descriptions Table 3: Preconfigured Roles Table 4: Backup Administration Portlet Options Table 5: Available Properties Teradata Viewpoint Configuration Guide, Release

12

13 Preface Changes to This Book Date and Release October Description Updated for the release Purpose This book describes how to configure and upgrade a Teradata Viewpoint server. Audience This document is intended for use by Teradata Viewpoint customers or Teradata Customer Services personnel. Related Documentation Use the Teradata Information Products web site to view or download specific documentation that supplies related or additional information to this book. 1. Go to 2. Under the Online Publications subcategory, click General Search. 3. Search on the title or publication ID. Title Teradata Viewpoint User Guide Describes the Teradata Viewpoint portal, portlets, and system administration features. Teradata Data Lab User Guide Describes how to use Teradata Data Lab portlets. Publication ID B mmyA B mmyA Teradata Viewpoint Configuration Guide, Release

14 Preface Title Teradata Alerts Installation and Configuration Guide Describes how to install, configure, and upgrade Teradata Alerts software. Parallel Upgrade Tool (PUT) Reference Describes how to use PUT to automate software installations and upgrades, system configurations, and Teradata Database configurations, running on Teradata platforms. Teradata Managed Server for Cabinet and Server, Models 4X5, 4X7, and 6X7 Product and Site Preparation Guide Describes the system hardware architecture, system hardware components, and requirements for preparing a site to receive and install a Teradata Managed Server cabinet. Publication ID B mmyA B mmyK B mmyK mmy changes for the month and year of the release. Teradata associates can access the internal publications web site to download documentation for installation, configuration, upgrade, etc: Software Download Location Description External site for access to the Teradata Software Server including patches. Only accessible with an active service contract. Internal site linking to Teradata Software Server that includes patches. 14 Teradata Viewpoint Configuration Guide, Release 14.01

15 CHAPTER 1 Teradata Viewpoint Requirements Teradata Viewpoint Server When the Teradata Viewpoint server arrives at the customer site, it has the necessary software installed and is ready to add Teradata Database systems to monitor and for users to access the portal. The Teradata Viewpoint server is ready if the login screen appears in the browser. Client Machine Recommendations Supported Web Browsers Mozilla Firefox 13 Internet Explorer 8 or 9 Google Chrome 19 Safari 5.1 Recommended Hardware At least 1.8GHz Pentium M, 3GHz Pentium 4, or equivalent CPU At least 1 GB of RAM Monitor or display supporting at least 1024x768 resolution Teradata Viewpoint Server Requirements Dell 2950 with 20GB total RAM Upgrade or R710 Managed Server SuSE Linux 10 Teradata JDK 6 PostgreSQL Server Teradata Viewpoint Configuration Guide, Release

16 CHAPTER 1 Teradata Viewpoint Requirements Supported Teradata Database Versions V2R6.2 (all functionality except Workload Designer) Teradata Viewpoint Configuration Guide, Release 14.01

17 CHAPTER 2 Start and Stop Teradata Viewpoint Services Teradata Viewpoint or later includes the following separate services: viewpoint Teradata Viewpoint portal that provides web browser access dcs Data Collection Service that monitors and collects data from Teradata systems tmsmonitor Teradata Managed Server Monitor that monitors performance of the Teradata Viewpoint server tdactivemq Messaging service that allows message exchanges between the Teradata Alerts components camalert Teradata Alerting Alert Service that processes events and alerts Each service has an init script on the Teradata Viewpoint server located in the /etc/init.d directory. The init scripts support the following command arguments: start Starts the service. If the service is already running, a new instance is not started. stop Stops the service. The script completes successfully even when the service is not running. restart Stops and starts the service. status Checks if the service is currently running. For example, to start the Teradata Viewpoint portal, type: /etc/init.d/viewpoint start To stop the Teradata Viewpoint portal, type: /etc/init.d/viewpoint stop To restart the Data Collection Service, type: /etc/init.d/dcs restart To check if the Teradata Managed Server Monitor is running, type: /etc/init.d/tmsmonitor status Teradata Viewpoint Configuration Guide, Release

18 CHAPTER 2 Start and Stop Teradata Viewpoint Services To control or check the status of all Teradata Viewpoint services on the current server, type: /opt/teradata/viewpoint/bin/vp-control.sh This script supports the same command arguments as the individual init.d scripts: start, stop, restart, and status. 18 Teradata Viewpoint Configuration Guide, Release 14.01

19 CHAPTER 3 Teradata System Preparation Set Up TASM and Alerting Tables To monitor a Teradata Database 12 or 13 database using Teradata Viewpoint 14.01, you must set up TASM and Alerting tables, using one of the following: The Teradata Manager setup application A Windows setup application that is either downloaded from the Teradata Software Server or copied from the Teradata Notification Service for Windows media If you have the Teradata Manager application available, perform the setup using the database setup application. To set up tables: For Teradata Database 12, use Teradata Manager 12.0 For Teradata Database 13, use Teradata Manager 13.0 Download the Windows setup application in the following cases: When implementing TASM on an existing Teradata 12.0 or 13.0 When running V2R6.2 with TASM, and migrating to Teradata 12.0 When running Teradata Database 12.0 with TASM, and migrating to Teradata 13.0 When installing a new Teradata Database 12.0 or 13.0 with TASM From the Teradata Software server, download the Windows setup application that matches your version of the Teradata Database. The zip files, which include the application and the supporting files, are named: For Teradata Database 12: dbsetup12vp Windows_i zip For Teradata Database 13: dbsetup13vp Windows_i zip Set Up Environment to run DBSSetup 1. Install the 32-bit client communication Windows packages to connect to the database. The following packages are required: Teradata Call-Level Interface version 2 (CLIv2) for Network Attached Systems Shared ICU Libraries (TDICU) for Teradata Teradata GSS Client (TeraGSS) Teradata Viewpoint Configuration Guide, Release

20 CHAPTER 3 Teradata System Preparation The package version must match the version of the DBSSetup application: TTU 12 for dbsetup12vp and TTU13 for dbssetup13vp. 2. Verify that the PC can communicate with the Teradata Database system by executing the PING command from a Windows DOS window. For example: PING ssscop1, where sss is the Teradata Database name. The system returns the message Reply from xxx.xxx.xxx.xxx, where xxx.xxx.xxx.xxx is the IP address of the database. Do one of the following: If the PING command does not receive a response from the database, contact your network administrator. Note: An incorrect or missing IP address and system name in the HOSTS file on the PC can cause communication with the Teradata Database to fail. The HOSTS file is located in the system32\drivers\etc directory where Windows is installed. If Domain Name Services (DNS) is not used, ensure that the HOSTS file contains entries similar to xxx.xxx.xxx.xxx ssscop1, where xxx.xxx.xxx.xxx is the functional IP address and sss is the Teradata Database name. If DNS is used, contact your network administrator for help in identifying the system. 3. Move the DBSSetup.zip file to an empty folder on the PC. 4. Extract the content of the.zip file to the same folder. Run DBSSetup 1. In the folder where you extracted the.zip file, double-click dbsetup12vp.exe or dbsetup13vp.exe to open the Database Setup window. Figure 1: Database Setup window 20 Teradata Viewpoint Configuration Guide, Release 14.01

21 2. In the System Name field, type the TDPID of the database to use to set up the tables. CHAPTER 3 Teradata System Preparation 3. In the Super User and Super User Password fields, type the name and password of a user who has the necessary permissions to create tables and grant access to existing DBC tables. DBC is the recommended user. 4. In the Perm Space field, type appropriate values. The default values of 50 MB and 100 MB are likely sufficient. 5. [Optional] If migrating from a prior version of TASM (6.2 to 12.0 or 13.0, or 12.0 to 13.0), select the Migrate TDWM Database check box. 6. Click OK and let the application run to completion. Depending on the load on the database, the setup application typically takes 2 to 10 minutes. On a heavily loaded system, the setup procedure can take longer. Note: If the setup application has already run, a confirmation message appears. Running the setup program again does not cause data to be lost. 7. If an error message appears, review the output and inspect any reported errors. Typical errors result from trying to delete items that do not exist, in preparation for the setup. You can locate errors by searching for failed. 8. Close the application. 9. Delete the application and.zip file from your system. 10. [Optional] Remove any packages you installed in step 1. To monitor a Teradata Database system, Teradata Viewpoint requires a Teradata system login with specific permissions. SQL commands can be used to create a user and grant permissions. The Teradata Viewpoint user account must have sufficient spool space to allow Teradata Viewpoint to issue monitoring queries. Also, permanent (perm) space is required by the Lock Information collector that is used by the Lock Viewer portlet starting with Teradata Viewpoint The user can be an existing user. The username and the password, viewpoint, are used in the following procedures as an example. Create a Teradata User for Data Collection Create a Teradata user for Teradata Viewpoint Data Collection. 1. Determine the amount of perm space and spool space to allocate to the Teradata user. These values vary based on several factors, including the size of the Teradata system, the level of activity on the Teradata system, and the amount of data retained in the data dictionary tables queried by Teradata Viewpoint. For Teradata systems of 50 nodes or less, the suggested allocations are 2 GB of perm space and 500 GB of spool space. For Teradata systems larger than 50 nodes, additional perm and spool space might be required. Teradata Viewpoint Configuration Guide, Release

22 CHAPTER 3 Teradata System Preparation 2. Type the following command, where <perm space> and <spool space> are the perm space and spool space to allocate to the user: create user viewpoint as perm=<perm space>, spool=<spool space> password=viewpoint; 3. If the console user does not exist on the target Teradata Database system, run the following command to create the user: create user console as perm=50000, spool=50000, account='$h-remoteconsole-use', password=console, fallback; 22 Teradata Viewpoint Configuration Guide, Release 14.01

23 CHAPTER 4 Configure Viewpoint to Monitor a Teradata Database System Log On to the Teradata Viewpoint Server 1. Open a browser. 2. Type the host name or IP address of the Teradata Viewpoint server. For example: 3. Log on to Teradata Viewpoint using admin for the username and teradata (default) as the password. The password can be changed at any time. Add Teradata Database Systems Add a Teradata Database system using the Teradata Systems admin portlet. Teradata Database systems must be added to the Teradata Systems admin portlet before you can configure the data collectors to monitor the database. The following procedure is more fully described in Teradata Viewpoint online help. 1. Click Admin>Teradata Systems. The TERADATA SYSTEMS view appears. 2. Click to add a system. 3. Select Add Teradata System from the drop down menu. 4. Type a system nickname (8 characters or less) for the Teradata Database system. 5. [Optional] Select Enable System to activate the Teradata Database system for monitoring. 6. In the TDPID field, type the TDPID of your Teradata Database system. Using the TDPID name allows Teradata Viewpoint to connect to multiple gateways. IP addresses are not recommended unless the system is an SMP. Do not use the Teradata Query Directory host name or IP address. Teradata Viewpoint Configuration Guide, Release

24 CHAPTER 4 Configure Viewpoint to Monitor a Teradata Database System If the TDPID cop addresses are not in DNS, define them in the HOSTS file located in the /etc/hosts directory on the Teradata Viewpoint server. 7. In the LOGIN section, create the user logins. a. Type a username. b. Type a password. c. [Optional] Type an account string to differentiate the user account. d. Select the authentication mechanism for the user. DEFAULT is the default authentication mechanism configured on the Teradata Database system for logging in. You can alternatively specify LDAP or TD2 if you know the system supports that mechanism for this user login. Click to add additional login accounts. There is no limit to the number of login accounts associated with a Teradata Database system. Multiple logins are useful for running canary queries using a specific user and account string. e. [Optional] Type a password for the tdwm user. This user login is used by the Workload Designer portlet to save rulesets to the Teradata Database system and to issue activate requests. It cannot be used by any data collectors. 8. Set up the macros and privileges needed for Teradata Viewpoint data collection against the Teradata Database. a. Click the Grant button next to the login that will be used for data collection. b. Ensure the correct Teradata Database version is displayed in the Version select list and click Continue. c. Enter the credentials for a Teradata Database user that has the permissions to execute the SQL commands displayed on the previous screen and click Run. d. Review the results and ensure that all of the commands completed with a status of Success. 9. [Optional] In the PORTLET AUTHENTICATION section, enable mechanisms that will be available for portlets to display to a user. Some portlets require a user to log in to the system and displays the authentication choices to the user for logging in. If no checkbox is enabled, the portlet still allows a user to log in using the DEFAULT authentication mechanism. 10. [Optional] In the COLLECTORS section, select the Enable data collectors except Virtual Storage (Configure in Data Collectors) checkbox to enable the default collectors for the new system. 11. In the CHARACTER SET section, configure the session and monitor default character sets. The session character set defaults to UTF8; the monitor character set defaults to ASCII. 12. [Optional] In the ENHANCED TASM FUNCTIONS section, enable the checkbox if the Teradata Database system that you are monitoring has license entitlement to TASM. This setting only applies to EDW systems running Teradata Database version or later, running on the SLES 11 operating system. This setting is used to determine the level of TASM functionality that will be exposed in the Workload Designer, Workload Monitor, and Workload Health portlets. 13. Click Apply. 24 Teradata Viewpoint Configuration Guide, Release 14.01

25 14. [Optional] Enable the SYSTEM HEARTBEAT in CANARY QUERIES. CHAPTER 4 Configure Viewpoint to Monitor a Teradata Database System Teradata Viewpoint uses the canary query to determine if the Teradata system is operational. You can also enable this query by selecting Enable data collectors except Virtual Storage (Configure in Data Collectors) when creating a new system. Enable the Data Collectors Data collection must be enabled for each Teradata Database system you want to monitor. To enable or disable a Teradata Viewpoint Data Collector, use the Teradata Systems portlet under Admin in Teradata Viewpoint. For more information, see Teradata Viewpoint online help. The Teradata Viewpoint Data Collection Service (DCS) connects to the Teradata Database system through the customer s LAN and accesses the appropriate data sources through the Teradata JDBC driver. Generally, the default values can be used. Using the default values initially and then fine tuning them at a later time is recommended. The setup must still be completed to enable the collectors if the Enable data collectorscheckbox was not selected when configuring the new system. Set data collection parameters or save defaults for: Account Info Alert Request AWT Info Database Space Disk Space Elastic Limit Elastic Usage Lock Info Query Count Resource Usage Sessions SQL Explain System Config System Stats Table Space TASM Config TASM Distribution TASM Exception TASM State Teradata Viewpoint Configuration Guide, Release

26 CHAPTER 4 Configure Viewpoint to Monitor a Teradata Database System TASM Summary Virtual Storage Collector Information Following is a description of each collector, its impact on a Teradata Database system, and how Teradata Viewpoint uses the data collected. Account Info The Account Info collector queries the AccountInfo table in the DBC database and collects a list of account strings. The Queries portlets use this data to list the available account strings for the Change Priority function. The Workload Designer portlet uses this data to provide a list of available account strings when creating classification criteria. Alert Request The Alert Request data collector monitors the dbcmngr.alertrequest table for incoming alert requests. If the table row contains valid data, the contents are forwarded to the Alert Service to process the alert action. The Alert Request data collector also monitors the dbcmngr.monitorrequest table. Any Teradata Database utility or user program can request Teradata Viewpoint to monitor its progress by inserting rows into the dbcmngr.monitorrequest table. Each row includes fields that indicate the date and time by which the next row is inserted. If a new row is not inserted before the specified date and time, the Alert Request collector forwards the contents to the Alert Service to process the alert action. AWT Info AMP Worker Task (AWT) information is collected by running ampload a through the Teradata CONSOLE partition. For Teradata Database version or later, the AWT Info collector uses the MONITOR AWT RESOURCE request of PM/API instead of AMP Load (ampload). The System Health, Node Resources, Metric Analysis, Capacity Heatmap, Metrics Graph, and Todays Statistics portlets use the AWT Info collector. If this collector is not enabled, these portlets do not display AWT information. The AWT Info collector is also required for alerts that depend on AWT information. Database Space The Database Space collector queries the DiskSpace and Databases views in the DBC database to collect database space usage metrics. 26 Teradata Viewpoint Configuration Guide, Release 14.01

27 CHAPTER 4 Configure Viewpoint to Monitor a Teradata Database System The Space Usage, Capacity Heatmap, and Metrics Graph portlets use the data collected by the Database Space collector. If this collector is not enabled, these portlets do not display current database space data. The Workload Designer portlet uses this data to provide a list of databases when creating classification criteria. The Database Space collector is required to generate Database Space alerts. Disk Space The Disk Space collector obtains disk space usage data by querying the Diskspace view in the DBC database. The System Health, Metrics Analysis, Capacity Heatmap, and Metrics Graph portlets use the data collected by the Disk Space collector. If this collector is not enabled, these portlets do not display the most current disk space data. Elastic Limit The Elastic Limit collector should only be enabled for Teradata Database systems leveraging Elastic Performance On Demand. The Elastic Limit collector collects the current System CPU Limit configured for the Active TASM rule set using the Schmon or Schset database utilities. The Elastic Performance portlet uses the data collected by the Elastic Limit collector. Elastic Usage The Elastic Usage collector should only be enabled for Teradata Database systems leveraging Elastic Performance On Demand. The Elastic Usage collector collects usage information from the DBC.ResUsageSPMA table. The Elastic Performance portlet uses the data collected by the Elastic Usage collector. Lock Info The Lock Info collector uses the Locking Logger database utility to capture a snapshot of lock information and stores the data in the cache database. The Lock Viewer portlet uses the data collected by the Lock Info collector. Therefore, the portlet only displays updated lock data for the period of time when the collector is enabled. For the Lock Info collector to run, the LockLogger flag in DBSControl on the Teradata system must be set to TRUE. Query Count Query count and query log data are collected by querying the DBQLogTbl and DBQLSummaryTbl tables in the Teradata DBC database. For a query to be counted, it must be logged in the DBQLogTbl or DBQLSummaryTbl table by enabling query logging in the Teradata Database. When enabling query logging, it is important to manage the size of the DBQL tables. Clearing the DBQL tables nightly is recommended. The queries performed by Teradata Viewpoint against DBQL require an all-row scan. If the size of the DBQL tables is not managed, queries against them can cause unnecessary use of Teradata Teradata Viewpoint Configuration Guide, Release

28 CHAPTER 4 Configure Viewpoint to Monitor a Teradata Database System Database resources. Teradata Professional Services has a Data Collection and Capacity Planning offering that includes the movement and cleanup of DBQL data on a nightly basis. If DBQL is not cleaned up nightly, using the Query Count collector is not recommended. The Productivity portlet uses query count data to show total query counts and query counts by application on an hourly basis. The Todays Statistics portlet also uses the data to show query counts and query log data for the last hour of collected data, grouped by duration. The Capacity Heatmap and the Metrics Graph portlets show query count and query log data collected over the hour. The Workload Designer portlet uses this data to populate several select lists when creating classification criteria. The default collection rate for querying DBQL is one hour. To get the portlets to display the most current query counts, yu can increase the collection frequency, at the cost of using up more Teradata Database resources to query DBQL more frequently. Resource Usage The Resource Usage collector queries the ResUsageSPMA and ResUsageIPMA tables in the DBC database to collect node resource usage data. The collector also queries the ResUsageSVPR table in the DBC database to collect vproc resource usage data. The recommended collection is the rate that this information is logged to these tables in Teradata. You can set this rate in the Admin portlet under TeradataSystems>MonitorRates. This resource usage data is used by the Metrics Analysis, Capacity Heatmap, Metrics Graph, and Node Resources portlets. Sessions Session data is collected by querying the Teradata Monitor partition using the PM/API. Session-level statistics are collected in memory by the Teradata Database at a configurable sample rate. The default option in Teradata Viewpoint collects session data at the same rate as sampled by Teradata Database. Collecting session data more frequently than the session sample rate in the Teradata Database results in duplicate data collection and wasted CPU. You can change the Teradata Database session sample rate in the Admin portlet under TeradataSystems>MonitorRates. My Queries, Query Monitor, Query Groups, and Workload Monitor display session data. The data is also used for the Active Sessions metric in the System Health, Metrics Analysis, Capacity Heatmap, and Metrics Graph portlets. If this collector is not enabled, the Queries portlets always display zero sessions. If this collector is enabled and then disabled, the Queries portlets display stale session data. The Session collector and the System Statistics collector must be enabled for the Active Sessions metric to display data in the System Health, Capacity Heatmap, and Metrics Graph portlets. The Sessions collector is required for Session alerting. SQL Explain SQL Explain data, like Session Data, is collected by querying the Teradata Monitor partition using the PM/API. It gathers SQL explain and query band information from currently running sessions. This collector is dependent on the Session collector running because it uses previously gathered data from the Session Collector. The SQL Explain collector can take a significant amount of time to gather data from Teradata. 28 Teradata Viewpoint Configuration Guide, Release 14.01

29 CHAPTER 4 Configure Viewpoint to Monitor a Teradata Database System My Queries, Query Monitor, Query Groups, SQL Scratchpad, and Workload Monitor display SQL Explain data. System Config The System Config collector determines the version and system type of the Teradata Database. This information is critical in order to ensure the proper functionality of several portlets and other data collectors. Therefore, this collector is always enabled and cannot be disabled. The sample rate and data retention policy for this collector cannot be modified. For Teradata Database version or later, the System Config collector no longer calls VprocManager console partition utility. System Stats System statistics data is collected by querying the Teradata Monitor partition using the PM/API. Physical and virtual resource statistics are collected in memory by Teradata Database at a configurable sample rate. The default option in Teradata Viewpoint collects system statistics data at the same rate as sampled by the Teradata Database. Collecting system statistics data more frequently than the resource sample rate in Teradata Database results in duplicate data being collected and wasted resource usage on the Teradata Database. You can change the Teradata Database resource sample rate in the in the Admin portlet under TeradataSystems>MonitorRates. The System Health, Node Resources, Metrics Analysis, Capacity Heatmap, Metrics Graph, Todays Statistics, Workload Health, and Workload Monitor portlets use the System Stats collector. If this collector is not enabled, these portlets do not display system statistics data. The Workload Designer portlet uses node and vproc counts from this collector to assist with the creation of rule sets. The System Stats collector is required for System, Node, Vproc, and System Health alerting. Table Space The Table Space collector queries the TableSize view in the DBC database to collect table space usage metrics. The Space Usage, Capacity Heatmap, and Metrics Graph portlets use the data collected by the Table Space collector. If this collector is not enabled, these portlets do not display the most current table space data. The Workload Designer portlet uses this data to provide a list of tables when creating classification criteria. TASM Config The TASM Config collector obtains configuration information about the TDWM version and active rule set in Teradata from the TDWM database in Teradata. This collector replaces the Workload collector that was available in The data is used by My Queries, Query Monitor, Query Groups, Workload Health, Workload Monitor, and Workload Designer. The TASM Config collector needs to be enabled in order to use Workload Designer for a new Teradata System. If the collector is not enabled, the TDWM version information is not collected, and the Teradata System does not appear in the list of available Teradata Systems in Workload Designer. Teradata Viewpoint Configuration Guide, Release

30 CHAPTER 4 Configure Viewpoint to Monitor a Teradata Database System TASM Distribution To collect CPU distribution by workload, the TASM Distribution collector executes schmon M p in the Teradata Console partition. Against Teradata Database systems running version or later, the CPU distribution by workload is collected by querying the Teradata Monitor partition using the PM/API. For Teradata Database version or later, the TASM Distribution collector uses the MONITOR WD request of PM/API instead of schmon. The collected data is used by the Workload Monitor portlet. TASM Exception The TASM Exception collector obtains TASM Exception data from the DBC.TDWMExceptionLog table. The collected data is used by the Workload Monitor portlet. TASM State The TASM State collector obtains system regulation data for Teradata Database version and later. For Teradata Database systems earlier than version 12.00, the TASM State collector collects period information from DBC.TDWMSummaryLog. This collector also uses the PM/API to determine the active rule set. The data collected is used by the My Queries, Query Monitor, Workload Designer, Workload Health, and Workload Monitor portlets. You must enable both the TASM Config and TASM State collectors to be able to associate the active workload name with the session information displayed in these portlets. TASM Summary The TASM Summary collector obtains data for each active workload in the Teradata Database. It sends queries to the Teradata Monitor partition using PM/API. The summary data is used by the Workload Health and Workload Monitor portlets. Virtual Storage The Virtual Storage collector obtains cylinder usage data from the Teradata Virtual Storage (TVS) product. This collector uses the GetTvsUdfViewpointSummary user-defined function to collect this data. This function is created by the Teradata Database DIP scripts. The data collected is used by the TVS Monitor portlet. 30 Teradata Viewpoint Configuration Guide, Release 14.01

31 CHAPTER 5 Teradata Aster System Preparation Enable Space Usage Collection Teradata Aster uses a background task to collect data about database and table space usage. By default, this task is disabled. In order to allow Teradata Viewpoint to collect the data, complete the following steps to enable the background task on the Teradata Aster system: 1. Access the queen node of the system. 2. Modify the disabled property in the /home/beehive/config/dbinfocollector_default.cfg file. Set this property to true. Teradata Viewpoint Configuration Guide, Release

32

33 CHAPTER 6 Configure Viewpoint to Monitor a Teradata Aster System Log On to the Teradata Viewpoint Server 3. Open a browser. 4. Type the host name or IP address of the Teradata Viewpoint server. For example: 5. Log on to Teradata Viewpoint using admin for the username and teradata (default) as the password. The password can be changed at any time. Add Teradata Aster Systems Add a Teradata Aster system using the Teradata Systems admin portlet. Teradata Aster systems must be added to the Teradata Systems admin portlet before you can configure the data collectors to monitor the database. The following procedure is more fully described in Teradata Viewpoint online help: 1. Click Admin>Teradata Systems. The TERADATA SYSTEMS view appears. 2. Click to add a system. 3. Select Add Aster System from the drop down menu. 4. Type a system nickname (8 characters or less) for the Teradata Aster system. 5. [Optional] Select Enable system to activate the Teradata Aster system for monitoring. 6. In the Host ID field, type the host name or IP address of the queen node of your Teradata Aster system. 7. In the LOGIN section, create the user logins. a. Type a username. Teradata Viewpoint Configuration Guide, Release

34 CHAPTER 6 Configure Viewpoint to Monitor a Teradata Aster System b. Type a password. 8. [Optional] In the COLLECTORS section, select the Enable all data collectors (Configure in Data Collectors) checkbox to enable the default collectors for the new system. Enable the Data Collectors Data collection must be enabled for each Teradata Aster system you want to monitor. To enable or disable a Teradata Viewpoint Data Collector, use the Teradata Systems portlet under Admin in Teradata Viewpoint. For more information, see Teradata Viewpoint online help. The Teradata Viewpoint Data Collection Service (DCS) connects to the Teradata Database system through the customer s LAN and accesses the Teradata Aster API. Generally, the default values can be used. Using the default values initially and then fine tuning them at a later time is recommended. The setup must still be completed to enable the collectors if the Enable all data collectors (Configure in Data Collectors) checkbox was not selected when configuring the new system. Set data collection parameters or save defaults for: Cluster Status Component Stats Nodes Processes Space Usage Workloads Collector Information Following is a description of each collector and how Teradata Viewpoint uses the data collected. Cluster Status The Cluster Status data collector obtains data on the overall state of the Teradata Aster system. This includes the system status, the replication factor, and the status of the nodes. This data is used by the System Health and Aster Node Monitor portlets. Component Stats The Component Stats data collector obtains metrics for each node of the Teradata Aster system, such as CPU, I/O, network, and memory. This data is used by the System Health, Aster Node Monitor, Metrics Graph, Capacity Heatmap, and Metrics Analysis portlets. 34 Teradata Viewpoint Configuration Guide, Release 14.01

35 CHAPTER 6 Configure Viewpoint to Monitor a Teradata Aster System Nodes The Nodes data collector obtains detailed information for each node of the Teradata Aster system, including the node storage and virtual worker information. This data is used by the System Health and Aster Node Monitor portlets. Processes The Processes data collector obtains data about the sessions and processes that are on the Teradata Aster system. Data for all sessions that are logged onto the system will be collected. For active processes, detailed information about the statement and phases of the process will also be collected. This data is used by the System Health, Query Monitor, and Aster Completed Processes portlets. Space Usage The Space Usage data collector obtains disk usage data about the databases and tables on the Teradata Aster system. This data is used by the System Health and Space Usage portlets. Workloads The Workloads data collector obtains the workload policy and workload service class data from the Teradata Aster system. This data is used by the Query Monitor and Aster Completed Processes portlets. Teradata Viewpoint Configuration Guide, Release

36

37 CHAPTER 7 Changing a Teradata System Nickname To change the nickname associated with a Teradata Database system in Teradata Viewpoint: 1. Stop the Teradata Viewpoint portal and the Data Collection Service (DCS). 2. Run the dcsadmin command: /opt/teradata/viewpoint/dcs/bin/dcsadmin.sh 3. Type renamesystem and press Enter. 4. Type the number of the system to rename and press Enter. 5. Type the new name and press Enter. 6. Verify that the new name is correct. If the name is correct, type Y and press Enter to confirm. If the name is incorrect, type N to cancel and return to step 3. The system is renamed. 7. Type quit and press Enter to exit the dcsadmin shell. 8. Restart the Teradata Viewpoint portal and the DC Teradata Viewpoint Configuration Guide, Release

38

39 CHAPTER 8 Configure Alerts Migrate Existing Alerts When you have configured a Teradata System in Teradata Viewpoint, you can migrate alerts from Teradata Manager to Teradata Viewpoint. Only the alert policy that is currently applied on the Teradata System is migrated. All of the actions in the currently applied alert policy are migrated. Additionally, the alerts on the System, Nodes, Vprocs, DB Space, Sessions, and Combinations tabs in the Teradata Manager Alert Policy Editor are migrated. The alerts from the Events tab are not migrated to Teradata Viewpoint. The configured rates in the Teradata Manager alert policy are also not migrated. Instead, the data collection rates that are configured for the data collectors in the Teradata Systems portlet are used to determine the alert rates. Note: Migrate existing alerts before you create any new alerts. The migration feature is disabled if any alerts are defined for a Teradata System. The following procedure is described in detail in Teradata Viewpoint online help. 1. Click Admin>Teradata Systems. 2. The Teradata Systems portlet appears. 3. Select SYSTEMS>Alerts>ALERT TYPES. 4. Under ALERTS, click Migrate Alerts. 5. Type a username, password, and authentication mechanism that has permission to read data from the AlertAction, AlertEvent, and AlertLevel tables in the dbcmngr database on the Teradata System. Note: Use DEFAULT authentication if you are unsure about which mechanism to choose. Define New Alerts You can configure alerts for seven types of data: system, node, vproc, database space, session, canary queries, and system health. Each alert contains rules that define when the alert is triggered and what actions occur when the rules are true. The following procedure is more fully described in Teradata Viewpoint online help. 1. Click Admin>Teradata Systems. The Teradata Systems portlet appears. Teradata Viewpoint Configuration Guide, Release

40 CHAPTER 8 Configure Alerts 2. Select SYSTEMS>Alerts>ALERT TYPES. 3. Type the number of minutes in the Only trigger if above is met for box. 4. The alert triggers if the rule is true for the number of minutes you entered. 5. Type the number of minutes in the Do not run twice in box. The alert action does not run twice in the time you entered. 40 Teradata Viewpoint Configuration Guide, Release 14.01

41 CHAPTER 9 Teradata Manager Feature Equivalence Teradata Viewpoint or later can be used as a replacement for Teradata Manager, which is not supported for Teradata Databases and later. With the added support for Alerting, and viewing node and vproc information, Teradata Viewpoint supports close to all features of Teradata Manager. The following Teradata Manager features are not available in Teradata Viewpoint: Scheduling. Most operating systems provide scheduling features. In Microsoft Windows, use the Microsoft Task Scheduler. In Linux, use the cron command. Priority Scheduler Administrator. You can use TASM instead. If TASM is not available, use the schmon command. If there are other features missing that are important to you, report them using the Suggestion Box link, located at the bottom of the Teradata Viewpoint portal. Uninstall Teradata Manager Follow this procedure to uninstall Teradata Manager and to clean up directories, tables, and other files you no longer need. 1. Go to Start>Control Panel>Add and Remove Programs. 2. Select Teradata Manager and click Remove. Teradata Viewpoint Configuration Guide, Release

42 CHAPTER 11 Configure Teradata Viewpoint LDAP Figure 2: Add or Remove Programs Dialog 3. [Optional] Delete the following directories: TTU 12.0 C:\Documents and Settings\<user login>\my Documents\Teradata\Teradata Manager C:\Documents and Settings\<user login>\my Documents\Teradata\PMON C:\Documents and Settings\All Users\Application Data\Teradata\Teradata Manager C:\Program Files\Teradata\Teradata Manager 13.0 TTU 13.0 C:\Documents and Settings\<user login>\my Documents\NCR\Teradata Manager C:\Documents and Settings\<user login>\my Documents\NCR\PMON C:\Documents and Settings\All Users\Application Data\NCR\Teradata Manager C:\Program Files\NCR\Teradata Manager [Optional] Teradata Manager does not remove registry keys that you no longer need. They do not do any harm, but you can remove them using the Windows Registry Editor. The following keys can be removed: 42 Teradata Viewpoint Configuration Guide, Release 14.01

43 CHAPTER 11 Configure Teradata Viewpoint LDAP TTU 12.0 HKEY_LOCAL_MACHINE\SOFTWARE\Teradata\TeradataManager HKEY_CURRENT_USER\Software\Teradata\PSA HKEY_CURRENT_USER\Software\Teradata\TeradataManager TTU 13.0 HKEY_LOCAL_MACHINE\SOFTWARE\NCR\TeradataManager HKEY_CURRENT_USER\Software\NCR\PSA HKEY_CURRENT_USER\Software\NCR\TeradataManager 5. [Optional] Teradata Manager also leaves behind tables that you no longer need. You can delete the following tables from the dbcmngr database: Note: Only delete the listed tables. dbcmngr.ampusagesnapshot1 dbcmngr.ampusagesnapshot2 dbcmngr.dbstype dbcmngr.log* (any table in the dbcmngr that starts with Log) dbcmngr.tm* (any table in the dbcmngr that starts with tm) Teradata Viewpoint Configuration Guide, Release

44

45 CHAPTER 10 Configure Viewpoint to Monitor a Managed Server Teradata Viewpoint can be configured to monitor certain system-level metrics for managed servers, including Teradata Viewpoint itself. These metrics include data on CPU usage, memory usage, system load, swap space usage, and I/O activity. Data that is collected from different managed servers can be viewed using the Viewpoint Monitoring portlet. To set up monitoring of a managed server, install the tmsmonitor RPM on the server you want to monitor. This package is already installed on Teradata Viewpoint or later staged systems. To install this package, see Upgrade to Teradata Viewpoint xx.xx. After the RPM has been installed and the service started, open the Viewpoint Managed Servers portlet and follow the steps in this topic to enable Teradata Viewpoint to start collecting data on the managed server. The following procedure is more fully described in the Teradata Viewpoint online help. 1. From the Admin menu, click Managed Servers. 2. Click Add a System. 3. Type a nickname in the MANAGED SYSTEM NAME field. This nickname is used by the Managed Servers portlet to refer to this managed server. 4. [Optional] Select Server Enabled to activate the managed system for monitoring. 5. In the HOSTNAME field, type either an IP address for the managed system or a host name that resolves by DNS to the managed system. If the tmsmonitor service is running on a port other than the default of 8888, also specify the port number in the HOSTNAME field. For example, viewpoint.acme.com: In the LOGIN Name and Password fields, leave the default values unless the login and password for this managed system have been changed to different values. 7. [Optional] Test if the tmsmonitor service is accessible and the login and password are correct: Click Test, located at the bottom of the screen. If the test fails, check the Teradata Viewpoint log file located at: /opt/teradata/viewpoint/portal/logs/viewpoint.log 8. Click Apply to save the new managed system. 9. [Optional] Select the Server Enabled checkbox to monitor the system. Teradata Viewpoint Configuration Guide, Release

46

47 CHAPTER 11 Configure Teradata Viewpoint LDAP When using LDAP with Teradata Viewpoint, the following methods are used to add user accounts: Manually entered without LDAP authentication Manually entered with LDAP authentication Auto-provisioned with LDAP authentication When users are auto-provisioned, the administrator does not need to enter their account into Teradata Viewpoint. The first time these users log on to Teradata Viewpoint, they are validated against the LDAP directory. If their credentials are valid, a Teradata Viewpoint account is created for them. LDAP validation works in conjunction with the Externally Authenticated? flag on the Add User and Modify User dialog boxes in the User Manager portlet. If the Externally Authenticated? check box is selected, the user is authenticated through LDAP when logging on. The Externally Authenticated? check box is automatically selected when a user is created using auto-provisioning. Use the LDAP Servers portlet to: Add and delete an LDAP configuration in Teradata Viewpoint Enable and disable the LDAP after it has been added Use the auto-provisioning feature to automatically add users to Teradata Viewpoint on first login Use the role mapping feature to position the new user in Teradata Viewpoint Prerequisites Have a basic understanding of LDAP The URL of the LDAP server. For example: ldap://ldap.acme.com:389 The username and password of a customer user or availability of that user to test the configuration Definitions Table 1: Terms and Definitions Term Definition Teradata Viewpoint Configuration Guide, Release

48 CHAPTER 11 Configure Teradata Viewpoint LDAP Lightweight Directory Access Protocol (LDAP) LDAP Data Interchange Format (LDIF) Distinguished Name (DN) Relatively Distinguished Name (RDN) Common Name (CN) Bind Service Account Viewpoint Authenticator Technically an application-protocol, LDAP is frequently used to refer to a directory server such as Microsoft Active Directory or OpenLDAP. A standard, plain text data interchange format for representing LDAP directory content and update requests. The full "path" to a user-entry in LDAP. Every user's DN is, by definition, unique. The DN consists of its Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as a full file name and the RDN as a relative filename in a folder. In the following example, the DN is the entire string: cn=joec,ou=northamerica,ou=user Accounts,DC=td,DC=acme,DC=com The part of a DN that distinguishes an entry from others at the same level in the tree. The CN is an attribute of a user-entry that is typically part of the user's DN and very often, but not always, the same value as the user's corporate username. In the following example, the CN is joec. cn=joec,ou=northamerica,ou=user Accounts,DC=td,DC=acme,DC=com Used for LDAP authentication, binding is an LDAP operation that authenticates a username and a password. An LDAP service account is an account (username and password) not associated with a customer user, but existing for the purposes of binding to LDAP to perform a search of the directory. Typically, a service account is required when the DN of an authenticating-user is unknown, and an LDAP search (based on some other attribute of the user-entry such as samaccountname) must first be performed to determine the user's DN. After the user's DN has been determined, a normal bind using the user's DN and password is run. Also referred to simply as the Authenticator, this component of Teradata Viewpoint runs the authentication process against LDAP, among other actions. Before You Begin LDAP Data Interchange Format (LDIF) 1. Ask the customer s LDAP administrator for: a. The user-entry details for the customer user in LDIF form. The following LDIF snippet is an example: dn: cn=joec,dc=user Accounts,dc=acme,dc=com cn: joec givenname: Joe sn: Customer telephonenumber: telephonenumber: Teradata Viewpoint Configuration Guide, Release 14.01

49 mail: samaccountname: customerjoe objectclass: inetorgperson memberof: cn=sales,ou=groups,dc=acme,dc=com memberof: cn=dba,ou=groups,dc=acme,dc=com... CHAPTER 11 Configure Teradata Viewpoint LDAP b. At least one other future Teradata Viewpoint customer user, preferably in a different region or country. Teradata Viewpoint Configuration Guide, Release

50

51 CHAPTER 11 Configure Teradata Viewpoint LDAP Determine LDAP Configuration Mode 1. Read the following flowchart to determine which Teradata Viewpoint authentication configuration mode to use: DN pattern bind User search w/bind Teradata Viewpoint Configuration Guide, Release

52

53 CHAPTER 11 Configure Teradata Viewpoint LDAP Is Username in DN? To bind to LDAP, Teradata Viewpoint authentication must know the DN of Joe Customer. When logging on, Joe presents a corporate username, which is usually, part of the DN. Using the following DN as an example: cn=joec,dc=user Accounts,dc=acme,dc=com 1. If the corporate username for Joe is joec and the username is in the DN, perform a DN pattern bind. 2. If the corporate username for Joe is customerjoe, that is the samaccountname attribute from the LDIF snippet, the username is not in DN. Search the LDAP tree for a user entry where the attribute matches the username value presented by Joe Customer. 3. Proceed to Number of Bind Patterns. Number of Bind Patterns After establishing Joe's DN and verifying the username for Joe is part of the DN string, bind to LDAP using the DN and password for Joe. As a reminder, following is the DN for Joe: cn=joec,dc=user Accounts,dc=acme,dc=com 1. Are all users in Joe's company located at the same Base DN in LDAP? That is, do all user DNs have the following pattern? cn=<<username>>,dc=user Accounts,dc=acme,dc=com If yes, the number of bind patterns is 1. Proceed to step 4. However, if users are located at multiple Base DNs, proceed to step If users are located at multiple Base DNs, you need to get this information from the LDAP administrator for the customer. For example, at Joe's company, there might be the following users: cn=joec,dc=user Accounts,dc=acme,dc=com cn=janedoe,dc=contractors,dc=user Accounts,dc=acme,dc=com cn=kaizers,dc=europe,dc=user Accounts,dc=acme,dc=com If there are multiple DN patterns, the Teradata Viewpoint Authenticator iterates over each of the patterns until it finds one that matches the username presented. If it does not match, it fails to authenticate. Therefore, if the number of patterns grows to seven or more, it might be faster to perform a user search. 3. Select one of the following in the LDAP Servers portlet: If there are less than 7 DN patterns, select the DN Pattern Bind option. If there are 7 or more DN patterns, select the User Search option. LDAP Configuration Teradata Viewpoint authentication is configured in the LDAP Servers portlet of the Admin menu. Teradata Viewpoint Configuration Guide, Release

54 CHAPTER 11 Configure Teradata Viewpoint LDAP Table 2: LDAP Configuration Attributes and Descriptions Attribute Basic Configuration Description Nickname Enabled Url DN Pattern Bind The short name by which this LDAP configuration is referred to in the LDAP Servers portlet. This name must be 8 characters or less. When checked, enables this LDAP configuration as part of the Teradata Viewpoint authentication process. Unchecked it disables this LDAP configuration as part of the Teradata Viewpoint authentication process. One or more URLs for this LDAP configuration. The URL must include the appropriate protocol (ldap:// or ldaps://) as well as the port. For example, ldap://ldap.acme.com:389. Only enter more than one URL if all of the URLs point to a similarly-configured LDAP server. This might be the case if you have replicated LDAP servers or a failover LDAP server that should be used if the primary one is unreachable. Pattern User Search Service account DN Service account password Search pattern Search base Search extent Key User Information The DN pattern(s) to perform the LDAP user bind attempt with. The patterns are invoked in the order specified, so it is recommended to put the patterns that match the most users before those that match fewer users. For example: cn={0},ou=user Accounts,DC=acme,DC=com The DN of the LDAP service account. The DN must not be surrounded by parentheses. The password of the LDAP service account specified in the Service account DN field above. The LDAP attribute to match against the presented username when searching for a user-entry. If the cn attribute is the username, then set to (cn={0}). If the samaccountname attribute is the username, then set to (samaccountname={0}). The entry that is the base of the subtree containing users. If not specified, the search base is the top-level context. For example: OU=User Accounts,DC=acme,DC=com When checked, searches the entire subtree rooted at the Search base entry. Unchecked, requests a single-level search including only the top level. LDAP first name attribute LDAP last name attribute LDAP attribute The name of the attribute on the LDAP user entry that specifies the first name of the user (given name). The name of the attribute on the LDAP user entry that specifies the last name of the user (surname). The name of the attribute on the user object that specifies the address of the user. Auto-Provisioning 54 Teradata Viewpoint Configuration Guide, Release 14.01

55 CHAPTER 11 Configure Teradata Viewpoint LDAP Attribute Description Turn on autoprovisioning Automatically assign these roles Default domain Role Mapping Global Settings Set to true to enable auto-provisioning. Set to false to disable auto-provisioning. When auto-provisioning is enabled, the newly provisioned user is automatically added to these roles. This attribute is often set to User. If auto-provisioning is enabled and the address of the user cannot be determined from LDAP, the new user's initial address is created in this domain. Set this to the domain of the customer. For example, acme.com. Usually this attribute does not have to be specified. Group search base Group search subtree Group attribute name The entry that is the base of the subtree containing groups. This field only needs to be specified if role mappings of type GROUP are used. When checked, searches the entire subtree rooted at the Group search base entry. Unchecked, requests a single-level search including only the top level. This field only needs to be specified if role mappings of type GROUP are used. The name of the attribute on the LDAP group entry that contains the DNs of the users in the group. Role Mapping Individual Settings Type Attribute name LDAP value Viewpoint role Set to ATTRIBUTE to perform a mapping from a LDAP user s entry value to a Teradata Viewpoint role. Set to GROUP to perform a mapping from an LDAP group to a Teradata Viewpoint role. The name of a LDAP attribute in the user's entry that specifies LDAP group and role membership for the purpose of mapping to Teradata Viewpoint roles. This setting is only applicable to mappings of type ATTRIBUTE. The value of the attribute specified in the Attribute name field that should be mapped to the role specified in the Viewpoint role field. For more details, see Role-mapping. The role in Teradata Viewpoint to which users are mapped. Standard Configuration and Testing The nickname, URLs, name matching (either DN Pattern Bind or User Search), and key user information sections are all part of the standard configuration for Teradata Viewpoint LDAP authentication. After these sections are completed in the LDAP Servers portlet, you can test these settings before saving the changes. Any changes made to the LDAP configuration are instantly applied to the Teradata Viewpoint authentication process; therefore it is highly recommended you test the functionality before saving any changes. To test the current LDAP configuration, perform the following steps in the LDAP Servers portlet. The following procedure is more fully described in Teradata Viewpoint online help. 1. Click Test in the SETTINGS TEST section. Teradata Viewpoint Configuration Guide, Release

56 CHAPTER 11 Configure Teradata Viewpoint LDAP 2. Type a username and password exactly as you would if you were logging on to Teradata Viewpoint. 3. Click Run. After the test is complete, an icon appears indicating if the authentication against LDAP was successful. If the authentication is successful, details of the test user are displayed in the SETTINGS TEST section. If the authentication was not successful, an error message displays. Role-mapping The examples below detail the two different types of role mapping available in Teradata Viewpoint. For both types of role mapping, the following characteristics apply: The Teradata Viewpoint role being mapped must be created beforehand by the Teradata Viewpoint Administrator. If a user is mapped into a role and logs out, each role-mapping is re-examined the next time they log on. If they are no longer a member of that LDAP group and role, they are removed from the mapped Teradata Viewpoint role. However, in the time between logging out and logging back on again, they are listed in Teradata Viewpoint as a member of that role. Example 1 Configure the Teradata Viewpoint Authenticator to map authenticated LDAP users into Teradata Viewpoint roles based on group membership recorded on a user entry: As a reminder, following is the LDIF for Joe: dn: cn=joec,dc=user Accounts,dc=acme,dc=com cn: joec givenname: Joe sn: Customer telephonenumber: telephonenumber: mail: joe.customer@acme.com samaccountname: customerjoe objectclass: inetorgperson memberof: cn=sales,ou=groups,dc=acme,dc=com memberof: cn=dba,ou=groups,dc=acme,dc=com The memberof attribute is used to specify Joe's membership in two groups whose names are specified with a full DN: (cn=sales,ou=groups,dc=acme,dc=com and cn=dba,ou=groups,dc=acme,dc=com). To map those two groups onto two Teradata Viewpoint roles, SALES_ROLE and DBA_ROLE, the XML would be as follows: First role mapping Type: ATTRIBUTE Attribute name: memberof LDAP value: cn=sales,ou=groups,dc=acme,dc=com Viewpoint role: SALES_ROLE Second role mapping 56 Teradata Viewpoint Configuration Guide, Release 14.01

57 CHAPTER 11 Configure Teradata Viewpoint LDAP Type: ATTRIBUTE Attribute name: memberof LDAP value: cn=dba,ou=groups,dc=acme,dc=com Viewpoint role: DBA_ROLE Example 2 Configure the Teradata Viewpoint Authenticator to map authentic LDAP users into Teradata Viewpoint roles based on group membership maintained in a static group. A static group is a separate entity in LDAP that maintains its own list of members. Assume the following is the LDIF for a static group Sales : dn: cn=sales,dc=groups,dc=acme,dc=com cn: sales objectclass: groupofuniquenames uniquemember: cn=joec,dc=user Accounts,dc=acme,dc=com uniquemember: cn=janed,dc=user Accounts,dc=acme,dc=com... The uniquemember attribute is used to specify two members of the group with full DNs of: (cn=joec,dc=user Accounts,dc=acme,dc=com) and (cn=janed,dc=user Accounts,dc=acme,dc=com). To map these two users into the Teradata Viewpoint role SALES_ROLE, the configuration would be as follows: Role mapping global settings Group search base: ou=groups,dc=acme,dc=com Group search subtree: (unchecked) Group attribute name: uniquemember Role mapping Type: GROUP LDAP value: cn=sales,ou=groups,dc=acme,dc=com Viewpoint role: SALES_ROLE LDAP Over SSL (LDAPS) For LDAP over SSL (also knows as LDAPS) support, ensure the URL in the LDAP Servers portlet reads ldaps://ldap.acme.com:636. The prefix is ldaps instead of ldap, and the port number is 636 instead of 389. Teradata Viewpoint Configuration Guide, Release

58 CHAPTER 11 Configure Teradata Viewpoint LDAP If the Certification Authority (CA) of the LDAP server is not trusted by the Teradata Viewpoint server, install the SSL Certificate by accessing the Certificates portlet in Teradata Viewpoint. This portlet is available to Teradata Viewpoint administrators via the Admin > Viewpoint Config menu. Use the Certificate Authority section of this portlet to install any CA certificates needed to facilitate secure communications for LDAPS. Note: If clustering is used, perform this step on all Teradata Viewpoint servers in the cluster. The certificates are not automatically shared between clustered Teradata Viewpoint servers. 58 Teradata Viewpoint Configuration Guide, Release 14.01

59 CHAPTER 12 Configure Teradata Viewpoint Security Control Access to Portlets The Portlet Library allows administrators to globally enable or disable portlets. This setting takes precedence over every other portlet permission level. You can browse the list of installed portlets by category, name, and software version, and see if the portlet is enabled or disabled. To enable or disable portlets, see Teradata Viewpoint online help. Control Access within Portlets Teradata Viewpoint Administrators can use the Roles Manager portlet to configure roles and assign permissions to specific functionality for a specific system in each portlet. To enable or disable permissions, see Teradata Viewpoint online help. Add Teradata Viewpoint Roles Teradata Viewpoint allows System Administrators to assign permissions by creating classes of users called roles. Various roles are created and each user is assigned to a role, allowing each portlet to be controlled with a high level of granularity. For example, a DBA can have permission to abort a query in the My Queries portlet, but other classes of users do not have permission. Teradata Viewpoint includes four pre-configured roles called Administrator and User. Each role can be tailored as needed and additional roles can be added. Teradata Viewpoint Configuration Guide, Release

60 CHAPTER 14 Back Up Teradata Viewpoint Databases The following are the preconfigured roles in Teradata Viewpoint: Table 3: Preconfigured Roles Role Administrator User TD_SE TD_TSS Description Provides all access to all portlets and Teradata systems. Provides access to log on to Teradata Viewpoint. It is recommended that no additional permissions be granted to this role. Teradata Solution Engineer. Provides access to all portlets except certain administrative portlets. Teradata Technical Support Specialist. Provides access to a limited set of portlets that do not expose any customer sensitive data. Roles can also be modified, deleted, or copied and then modified. To modify, delete, or copy a role, see Teradata Viewpoint online help. To add a role, assign users to a role, and then enable portlets for a role, see Teradata Viewpoint online help. Add Teradata Viewpoint Users Before assigning a role to a user, verify the role and user exists. Users can be assigned to roles using either the Roles Manager or User Manager portlets. You can also use the LDAP interface. 60 Teradata Viewpoint Configuration Guide, Release 14.01

61 CHAPTER 13 Configure Teradata Viewpoint to Log to TVI The default TVI logging configuration assumes Teradata Viewpoint is running on a managed server. If this is the case, no special configuration is needed for logging Alert/Event information, but it is recommended that you configure TVI to log errors. If Teradata Viewpoint is running on an unmanaged server, or if you want to log asset information, TVI logging must be configured to send information to TVI through a queue table. Before starting, contact the administrator who set up the TVI Administration Software (TAS) for your system. Ask if the system supports logging to TVI using a queue table. If a queue table has been set up for your system, ask for the login information for this queue table. 1. Locate the file tvilogger.properties within the /opt/teradata/viewpoint/dcs/config directory. 2. Copy this properties file to /etc/opt/teradata/tvilogger/tvilogger.properties. 3. If Teradata Viewpoint is running on an unmanaged server, or if asset logging is required, you must modify the properties to specify login information for queue table logging. Follow the instructions provided within the properties file. 4. Restart the Teradata Viewpoint services for the changes in the properties file to take effect. 5. Do the following: a. Open the Teradata Viewpoint log file located at: /opt/teradata/viewpoint/portal/logs/viewpoint.log b. Look for messages that state the following: TVILogger will write to queue table Serious errors in Teradata Viewpoint are sent through TVI. Teradata Viewpoint Configuration Guide, Release

62

63 CHAPTER 14 Back Up Teradata Viewpoint Databases You can use the Backup administration portlet in Teradata Viewpoint to make a daily backup of the Teradata Viewpoint databases. You can use third-party applications to backup the Teradata Viewpoint backup files to a networked file server or secondary storage like a tape or disk. Backup Administration Portlet The Teradata Viewpoint server automatically creates a daily backup of the Teradata Viewpoint databases. You can manage the backup process by specifying the following options in the Backup administration portlet. Table 4: Backup Administration Portlet Options Property Name Description Default Setting Enabled When checked, enables the backup process and unchecked, disables it. checked Location Backup time Retention days Location of the backup files on the Teradata Viewpoint server or on a networked file server. Local backup file location: /data/backup. If local backups are performed, keep a copy of the files off the Teradata Viewpoint server to prevent data loss in the event of a catastrophic failure. For a networked backup, enter the host name or IP address of the NFS server and the absolute path to the Viewpoint backed up data set. The PostgreSQL (postgres) user on the Teradata Viewpoint server must have write access to the NFS server. Time of day that the backup process begins. Number of days to keep backups before they are removed. 7 Local 12:00 AM (midnight) Teradata Viewpoint Configuration Guide, Release

64 CHAPTER 14 Back Up Teradata Viewpoint Databases Third-Party Application Backup You can schedule third-party applications to backup the Teradata Viewpoint backup files. See the vendorspecific documentation for instructions on how to install the client and configure and run backup jobs. Teradata Viewpoint supports the following third-party applications for backup: Symantec NetBackup IBM Tivoli Storage Manager Quest NetVault 1. The third-party application s client software must be installed on the server where the Teradata Viewpoint backup files reside. Check the Backup administration portlet for the configured backup location, and install the backup application s client software in the following location: Local: Install the client software on the Viewpoint server Network: Install the client software on the networked file server. 2. Check the Backup administration portlet for the time of day that the last successful backup completed and schedule the third-party backup jobs after the Teradata Viewpoint database backup is completed. This check ensures that you get the latest backed up data set and avoid resource contention. 64 Teradata Viewpoint Configuration Guide, Release 14.01

65 CHAPTER 15 Restore a Teradata Viewpoint Database When restoring a backup in a clustered environment, only perform the following restoration steps on the primary server. Restore a Database from Teradata Viewpoint Version or Later The following instructions are for restoring a version of the Teradata Viewpoint database that was backed up in version xx.xx or later. Starting with Teradata Viewpoint 13.11, the backup is performed incrementally for the collected data to improve the overall speed of the backup process. Starting with Teradata Viewpoint 14.00, the backup for the cam database is also performed incrementally. Because data is collected incrementally, smaller portions of the data can be restored. Specifically, you can now choose to restore: Configuration data: This restores all data in lportal, td_portal, td_portlets, and all data in cam and dcsdb, except collected data. Current data: This restores only the current collected data in dcsdb and cam. For example, for each collected data s current week or month partition. Previous weeks and months and years worth of data is not restored. Historical data: This restores only the collected data in dcsdb and cam from previous weeks and months. For example, previous weeks, months, and years worth of data is restored. Current weeks and months data is ignored. Everything (default): This restores all data in cam, lportal, td_portal, td_portlets, and dcsdb. This option drops the databases and creates them again. 3. Stop all services on all Teradata Viewpoint servers. /opt/teradata/viewpoint/bin/vp-control.sh stop 4. If the Teradata Notification Service is running on a Windows server, stop this service. 5. If the backup files are located on network storage, perform the following steps: a. Mount the remote host directory on the Teradata Viewpoint server. The <remote directory> should be the root directory for the backups and should contain the database directories (cam, dcsdb, td_portal, etc.). mkdir /data/restore mount <remote host>:<remote directory> /data/restore Teradata Viewpoint Configuration Guide, Release

66 CHAPTER 14 Migrate to a New Teradata Viewpoint Server b. In the /opt/teradata/viewpoint/dcs/config/dcs.properties file, change the value of the backup.dir property to /data/restore. c. Ensure the directory and file permissions within /data/restore are readable by the postgres Linux user. 6. If the backup files are located on a third-party application s backup server, perform the following steps: a. Make a directory on the Teradata Viewpoint server to store the files from the backup server. mkdir /data/restore b. Copy the files from the backup server to this directory on the Teradata Viewpoint server. This directory should contain the database directories (cam, dcsdb, td_portal, etc.) c. In the /opt/teradata/viewpoint/dcs/config/dcs.properties file, change the value of the backup.dir property to /data/restore. d. Ensure the directory and file permissions within /data/restore are readable by the postgres Linux user. 7. Run the restore script. For configuration data: /opt/teradata/viewpoint/bin/restore.sh conf For current data: /opt/teradata/viewpoint/bin/restore.sh curr For historical data: /opt/teradata/viewpoint/bin/restore.sh hist Everything (default): /opt/teradata/viewpoint/bin/restore.sh 8. Validate that the script completed successfully by looking for the message RESTORATION OF VIEWPOINT ON <server> COMPLETED SUCCESSFULLY! If the restoration process failed, an error message is displayed instead of the success message. If the restoration process fails or is interrupted in any manner, fix the problem that caused the failure and execute these steps again. 9. If the backup files are located on network storage in the /opt/teradata/viewpoint/dcs/config/dcs.properties file, change the value of the backup.dir property back to /data/backup. 10. If the Teradata Notification Service is running on a Windows server, start this service. 11. Start all services on all Teradata Viewpoint servers. /opt/teradata/viewpoint/bin/vp-control.sh start Restore a Database from Teradata Viewpoint Version or Earlier The following instructions are for restoring a version of the Teradata Viewpoint database that was backed up in version xx.xx or earlier. In these versions, each database was backed up in a single file. These 66 Teradata Viewpoint Configuration Guide, Release 14.01

67 instructions are applicable when restoring a previous backup as part of backing down to a previous Teradata Viewpoint release. The following databases are stored on a Teradata Viewpoint server: lportal td_portal td_portlets dcsdb cam Each database has its own nightly backup file. 1. Navigate to the directory where the database backup files are located. 2. Type the following commands: su postgres pg_restore --clean d <database_name> <name_of_backup_file> Teradata Viewpoint Configuration Guide, Release

68 CHAPTER 16 Migrate to a New Teradata Viewpoint Server At times it might become necessary to migrate from one Teradata Viewpoint server to a different Teradata Viewpoint server. The following steps describe the most efficient way to complete this process so that the amount of down time is kept to a minimum. Due to the way in which the data is partitioned in the cache database, this entire process should be completed in a single week, where the week runs from Monday morning at 12:00 AM to Sunday evening at 11:59 PM. These times are based on the time set on the Teradata Viewpoint server, which could be in either UTC or the local time zone. Perform the following steps to restore the historical data on the target server. During this process, the source server can be actively running all Teradata Viewpoint services. 1. Check the software version of Teradata Viewpoint that is installed on the source and target server. Ensure the installed versions are the same and that the version is at least On the target server, create the restore directory: mkdir /data/restore chown postgres /data/restore 3. On the target server, stop all Teradata Viewpoint services: /opt/teradata/viewpoint/bin/vp-control.sh stop 4. Copy the backup files from the source server to the target server. This could take some time, depending on the size of the backup. The rsync command can be cancelled and restarted at any time; it starts transferring the database where it left off. Replace the [host] value with the target server s host name. Execute the following commands on the source server: cd /data/backup su postgres rsync -avtrz -e ssh /data/backup/ [host]:/data/restore exit 5. After the rsync in the previous step is complete, change the value of the backup.dir property to /data/restore in the /opt/teradata/viewpoint/dcs/config/dcs.properties file on the target server. 6. On the target server, ensure all files in the restore directory have the correct permissions: chmod -R 755 /data/restore 7. Restore the historical data on the target server. This could take some time, depending on the size of the backup. /opt/teradata/viewpoint/bin/restore.sh hist Perform the following steps to restore the configuration and current data on the target server. During this process, neither the source server nor the target server can be running any Teradata Viewpoint services. A Teradata Viewpoint Configuration Guide, Release

69 CHAPTER 18 Configure NTP Time Synchronization variety of factors can impact the overall time to execute the following steps. However, in most situations these steps should take no more than one hour to complete. 1. On the source server, stop all Teradata Viewpoint services: /opt/teradata/viewpoint/bin/vp-control.sh stop 2. Copy any modified files from the source server to the target server. Since the rsync command only copies files that have been modified, this should be a significantly quicker operation than the copy in the previous section. The rsync command can be cancelled and restarted at any time; it starts transferring the database where it left off. Replace the [host] value with the target server s host name. Execute the following commands on the source server: cd /data/backup su postgres rsync -avtrz -e ssh /data/backup/ [host]:/data/restore exit 3. Restore the configuration and current data on the target server. /opt/teradata/viewpoint/bin/restore.sh conf /opt/teradata/viewpoint/bin/restore.sh curr 4. In the /opt/teradata/dcs/config/dcs.properties file on the target server, change the value of the backup.dir property back to /data/backup. 5. Start all Teradata Viewpoint services on the target server: /opt/teradata/viewpoint/bin/vp-control.sh start Teradata Viewpoint Configuration Guide, Release

70

71 CHAPTER 17 Change the Session Timeout and Default Locale To change the default session timeout and default locale, from the Admin menu select the Viewpoint Config category and the General portlet. The default session timeout in Teradata Viewpoint is 90 minutes. The default locale in Teradata Viewpoint is en_us. Changing the default locale affects all Teradata Viewpoint users who have not explicitly set a locale in their user profile. Teradata Viewpoint Configuration Guide, Release

72

73 CHAPTER 18 Reset the Admin User Password If you forget the Teradata Viewpoint admin user password, reset it to teradata by running the following command: /opt/teradata/viewpoint/portal/bin/vpadmin.sh R Teradata Viewpoint Configuration Guide, Release

74 CHAPTER 19 Ports Used by Teradata Viewpoint Following is a list of ports used by Teradata Viewpoint. Additional ports are required for Teradata Viewpoint clustering. See Additional Cluster Considerations. Incoming Ports 22 (SSH) 80 (HTTP) 443 (HTTPS) 5432 (Cache Database) 8888 (optional for monitoring Teradata Viewpoint server tmsmonitor) (Teradata Alerting) Outgoing Ports 22 (SSH) For clustering and Elastic Performance uploads. 389 (optional for LDAP authentication) 1025 (JDBC) 5432 (Cache Database) When clustering is enabled (optional for monitoring Teradata Managed Servers tmsmonitor) Teradata Viewpoint Configuration Guide, Release

75 CHAPTER 20 Set Teradata Viewpoint Server Time The preferred way to set the Teradata Viewpoint server time is to use NTP. See Configure NTP Time Synchronization. Caution: If setting the time manually, shut down the DCS before changing the time to prevent possible data loss that could result if the date is set incorrectly. Ensure the date is correct before restarting the DCS. 1. Type the following command: yast timezone 2. Select the region using the arrow key. 3. Tab to the Time Zone field and use the arrow key to select the appropriate time zone. 4. Tab to the Change Time or Date field and press Enter. 5. Tab to the appropriate time and date entries and use the Backspace key to delete the old value. 6. Type the new value. 7. Tab through the subsequent entries until finished. 8. Tab to Apply and press Enter. 9. Tab to Accept and press Enter to accept the change. Teradata Viewpoint Configuration Guide, Release

76

77 10. CHAPTER 21 Configure NTP Time Synchronization To ensure the time on the Teradata Viewpoint server is always accurate, you can configure NTP time synchronization. This is especially important if setting up a Teradata Viewpoint cluster because the time on the servers needs to be synchronized. This setup assumes a time server is available on the LAN. If no time server is available, then time is only synchronized between the Teradata Viewpoint servers in a cluster and not a master time source. Use the following procedure for each Teradata Viewpoint server. 1. Enable the NTP service by typing: chkconfig ntp on 2. If the customer has a time server: a. Open and edit /etc/ntp.conf. b. Add the following line to the end of the file where [host] is the host name of the time server: server [host] 3. If Teradata Viewpoint is configured in a cluster: a. Open and edit /etc/ntp.conf. b. Add the following line to the end of the file for each Teradata Viewpoint server in the cluster, excluding the current host, where [address] is the IP address of another Teradata Viewpoint server: peer [address] 4. Start the ntp service by typing: /etc/init.d/ntp start Teradata Viewpoint Configuration Guide, Release

78

79 CHAPTER 22 Teradata Viewpoint Clustering Starting with Teradata Viewpoint , multiple Teradata Viewpoint servers can be clustered together to ensure high availability and scalability. Each Teradata Viewpoint server in a cluster shares the same users, roles, permissions, preferences, and collected data from monitored Teradata systems. This topic covers: Cluster Configurations Failure Scenarios Create a Teradata Viewpoint Cluster Disable a Teradata Viewpoint Cluster Add Additional Teradata Viewpoint Servers to a Cluster Promote the Standby Cache Database Configure Automatic Promotions Additional Clustering Considerations Cluster Configurations This topic contains the supported Teradata Viewpoint cluster configurations. This includes: High Availability configuration High Usage configuration Advanced configuration High Availability Configuration: Two Teradata Viewpoint Servers A High Availability configuration is the base configuration for customers implementing a Teradata Viewpoint cluster. The following diagram shows two Teradata Viewpoint servers configured in a cluster. Both Teradata Viewpoint instances point at the same active cache database. A standby cache database is kept up to date with the last minute of data in the event a failure occurs. An active Data Collection Service (DCS) runs on the same Teradata Viewpoint server as the active cache database. The other Teradata Viewpoint server contains a standby DCS that assumes data collection should the active DCS fail. The Teradata Viewpoint servers share a distributed cache to ensure that the state between the Teradata Viewpoint portals remains consistent. Teradata Viewpoint Configuration Guide, Release

80 CHAPTER 22 Teradata Viewpoint Clustering Figure 3: High Availability Configuration High Usage Configuration: Three or More Teradata Viewpoint Servers A High Usage configuration extends the High Availability configuration by adding Teradata Viewpoint servers to the cluster. This allows Teradata Viewpoint to scale to thousands of concurrent users. The additional Teradata Viewpoint servers only run the Teradata Viewpoint portal and not the DCS or cache database. Instead, they point to the cluster-wide cache database to access users, permissions, preferences, and collected data. The two additional Teradata Viewpoint servers shown in the following diagram are optional and are not required for high availability. Even though these additional servers only run the Teradata Viewpoint portal, they are staged the same as any Teradata Viewpoint server and have the DCS and cache database installed, but not enabled. Figure 4: High Usage Configuration Advanced Configuration: Three or More Teradata Viewpoint Servers with Dedicated Cache Database Server The Advanced configuration is for customers requiring enhanced cache database performance. This additional requirement may be due to high usage or a situation where multiple large/high-use Teradata systems are monitored. 80 Teradata Viewpoint Configuration Guide, Release 14.01

81 CHAPTER 22 Teradata Viewpoint Clustering In this configuration, the Teradata Viewpoint portal is not run on the same machine as the active cache database. This provides the cache database with additional system resources. Figure 5: Advanced Configuration Failure Scenarios Data Collection Service Failure (Scenario 1) If the active Data Collection Service (DCS) fails, the standby DCS automatically assumes data collection, logs an error to TVI, and optionally sends out an . When the standby DCS detects the active DCS is back online, it stops data collection and continues to operate in standby mode. Figure 6: DCS Failure Cache Database Failure (Scenario 2) If the DCS detects that the active cache database has failed, the DCS logs an error to TVI and optionally sends out an . If the problem is not trivial to solve, the System Administrator can promote the standby cache database. Promoting the standby cache database makes the standby cache database become the active cache database. The promotion is broadcast to all Teradata Viewpoint servers and they are Teradata Viewpoint Configuration Guide, Release

82 CHAPTER 22 Teradata Viewpoint Clustering automatically redirected to the new active cache database. The standby DCS automatically becomes the new active DCS. After the standby machine is promoted, a new standby cache database needs to be set up by the System Administrator. See Create a Teradata Viewpoint Cluster. If the cluster is set up using the advanced configuration, stop the Teradata Viewpoint portal on the new active cache database server so that it continues to run on a dedicated machine. Figure 7: Cache Database Failure Active Teradata Viewpoint Server Failure This failover scenario is a combination of scenario 1 and 2. The standby DCS detects that the active DCS and cache database are down and logs an error to TVI and optionally sends out an . If the problem is not trivial to solve, the System Administrator can promote the standby cache database to the active cache database. A notification is broadcast to all Teradata Viewpoint portals so that they are automatically redirected to the new active cache database. The standby DCS becomes the new active DCS. After the standby machine is promoted, a new standby cache database needs to be set up by the System Administrator. See Create a Teradata Viewpoint Cluster. If the cluster is set up using the advanced configuration, stop the Teradata Viewpoint portal on the new active cache database server so that it continues to run on a dedicated machine. Figure 8: Active Teradata Viewpoint Server Failure 82 Teradata Viewpoint Configuration Guide, Release 14.01

83 Create a Teradata Viewpoint Cluster CHAPTER 22 Teradata Viewpoint Clustering To create a Teradata Viewpoint cluster, two Teradata Viewpoint servers are required. One is configured with the active cache database and the other with the standby cache database. Additional Teradata Viewpoint servers can be added to the cluster at the time of initial setup or see Add Additional Teradata Viewpoint Servers to a Cluster to add additional servers at a later time. Before setting up the Teradata Viewpoint clustering configuration, review Additional Cluster Considerations. System Preparation 1. All servers being added to the cluster must have Teradata Viewpoint or later installed and must have the same patch revision. 2. All servers must have the same time and timezone and be accurate within a few minutes. See Configure NTP Time Synchronization. 3. Determine which server is going to host the active cache database and which is going to host the standby cache database. The server that is going to host the active cache database can already have existing users, roles, permissions, preferences, and collected data from monitored Teradata systems that is shared by all Teradata Viewpoint servers in the cluster. Any data on the server hosting the standby cache database is lost. Cluster Setup Tool Starting with 14.01, there is a new simple command-line tool for creating a Teradata Viewpoint Cluster. The setup tool clusters both Teradata Viewpoint and Teradata Alerts. To create a cluster, run the following command on the server that will host the active cache database: /opt/teradata/viewpoint/bin/clustersetup.sh Next select option 1 to create a cluster. The cluster setup tool only takes a few minutes to create the cluster as it performs the following actions: Asks a few simple questions about what hosts will comprise the cluster Verifies that the software versions and times on the servers match Stops all the Teradata Viewpoint services in the cluster Configures Teradata Viewpoint and Teradata Alerts for clustering Configures PostgreSQL for clustering Restarts all Teradata Viewpoint services in the cluster After the cluster setup tool is run to create a cluster, the setup of the standby cache database is handled automatically in the background. The cluster setup progress is displayed in the new Notification Banner within the Teradata Viewpoint portal. The Cluster Setup Notification Banner is only displayed to Admin Teradata Viewpoint Configuration Guide, Release

84 CHAPTER 22 Teradata Viewpoint Clustering users by default. Cluster Setup Notification Banner permissions can be modified in the Roles Manager Portlet. Disable a Teradata Viewpoint Cluster The same cluster setup tool that was used to create a cluster can also be used to disable a cluster. To disable a cluster, run the following command on the server that is currently hosting the active cache database: /opt/teradata/viewpoint/bin/clustersetup.sh Next, select option 1 to disable a cluster. After the disable command is complete, each Viewpoint server will point to its own local cache database and perform its own data collection. Add Additional Teradata Viewpoint Servers to a Cluster If a cluster is already configured with an active and a standby cache database, additional Teradata Viewpoint servers can be added to the cluster to support additional end users. The same cluster setup tool that was used to create a cluster can also be used to add a server to the cluster. To add a server to the cluster, run the following command on the server that is currently hosting the active cache database. /opt/teradata/viewpoint/bin/clustersetup.sh Next select option 2 to add a server to the cluster. The cluster setup tool only takes a few minutes to add the server to the cluster as it performs the following actions: Asks a few simple questions about what hosts to add to the cluster Verifies that the software versions and times on the new servers match Stops all the Teradata Viewpoint services in the cluster Configures Teradata Viewpoint and Teradata Alerts with information about the new server(s) Restarts all Teradata Viewpoint services in the cluster Promote the Standby Cache Database In situations where the active cache database fails and cannot be restarted easily, the standby cache database can be promoted to the new active cache database. After the standby cache database is promoted to the active cache database, the Teradata Viewpoint portals in the cluster and the active DCS automatically start using the newly promoted cache database. 84 Teradata Viewpoint Configuration Guide, Release 14.01

85 CHAPTER 22 Teradata Viewpoint Clustering To promote the standby cache database, log on to the Teradata Viewpoint server hosting the standby cache database and type the following command to promote the standby cache database: /opt/teradata/viewpoint/bin/promote.sh To configure promotions to automatically occur when a failure is detected, see the Configure Automatic Promotions section. After the script completes, Teradata Viewpoint will become available again. Whenever the standby cache database is promoted to become the active cache database, there is no longer a standby cache database in the cluster. The old active cache database does not automatically become the new standby. To create a new standby cache database after a promotion, use the cluster setup tool to add a standby server back into the cluster. To add a server to the cluster, run the following command on the server that is currently hosting the active cache database. /opt/teradata/viewpoint/bin/clustersetup.sh Next select option 1 to add a standby server. The cluster setup tool only takes a few minutes to add the standby server to the cluster as it performs the following actions: Asks a few simple questions about what host should become the standby. Verifies that the software versions and times on the servers match. Stops all the Teradata Viewpoint services in the cluster. Configures Teradata Viewpoint and Teradata Alerts with information about the new standby server. Restarts all Teradata Viewpoint services in the cluster. After the cluster setup tool is run to add the standby server, the setup of the standby cache database is handled automatically in the background. The cluster setup progress is displayed in the new Notification Banner within the Teradata Viewpoint portal. The Cluster Setup Notification Banner is only displayed to Admin users by default. Cluster Setup Notification Banner permissions can be modified in the Roles Manager Portlet. Configure Automatic Promotions Starting with Viewpoint 14.01, the standby cache database can automatically be promoted to become the active cache database when the active cache database becomes unavailable. This capability is enabled by the installation and configuration of a new vpclustermonitor package. This package should be installed on a TMS server co-located with the Teradata Viewpoint server hosting the active cache database, to prevent automatic promotions occurring as the result of temporary network outages. If the active and standby Viewpoint servers are separated by a WAN, then a third TMS server that is co-located with the active Teradata Viewpoint server is required. Below are the steps to install and configure automatic promotions. 1) Install the vpclustermonitor package available on TSS. Teradata Viewpoint Configuration Guide, Release

86 CHAPTER 22 Teradata Viewpoint Clustering rpm -ivh vpclustermonitor xx.xx.rpm 2) Run the vpclustermonitor setup script. /opt/teradata/viewpoint/vpclustermonitor/bin/vpclustermonitor-setup.sh 3) Answer the questions about which server is hosting the active cache database and which server is host the standby cache database. 4) When the setup script completes, you can tail the vpclustermonitor log file to make sure it begins monitoring the active cache database. /opt/teradata/viewpoint/vpclustermonitor/logs/vpclustermonitor.log It is recommended to configure alerts so that you get notifications when an automatic promotion occurs. See the Additional Cluster Considerations section for more details. Also review the Promote the Standby Cache Database section for information on what to do after an automatic promotion occurs. Additional Cluster Considerations LAN or WAN A Teradata Viewpoint cluster can be set up over a WAN. All the data collected by the active Teradata Viewpoint server is sent asynchronously to the standby Teradata Viewpoint server. Depending on the number and activity of the Teradata systems being monitored, the amount of data transferred has the potential of approching 1 GB an hour. Only consider setting up a Teradata Viewpoint cluster spanning a WAN if there is adequate bandwidth available. Disk Capacity The disk capacity available to different generations of Teradata Viewpoint servers might be different. When clustering, if the active cache database has more disk capacity than the standby cache database, set a disk quota so that the active cache database does not use up more space than is available on the standby cache database. To ensure the capacity is available to the cache database, run df h /data. If the capacity on the active cache database is greater than on the standby cache database, run the following command on the active cache database server to limit the capacity used (replace <number of GBs> with the limit, in Gigabytes, for the drive): setquota -u postgres 0 <number of GBs> /data The setquota command is available only on staged Teradata Viewpoint servers and later. All Teradata Viewpoint servers staged prior to this time had the same disk capacity; therefore it is not necessary to run the setquota command on those machines. Later releases always have a larger disk capacity. 86 Teradata Viewpoint Configuration Guide, Release 14.01

87 CHAPTER 22 Teradata Viewpoint Clustering Getting Notifications of Failures and Promotions When Teradata Viewpoint detects a situation that requires the attention of a Teradata Viewpoint administrator, an can be sent out to a configured list of recipients. s are sent out for the following conditions: The active DCS is down The active DCS is restored The active cache database is down The active cache database is restored Cache database replication is not working The standby cache database is promoted 1. To configure alerts, modify the following properties in the /etc/opt/teradata/viewpoint/local.cluster.properties file on the active and standby cache database servers. alert.enabled Set to true to turn on alerting alert.smtphost The hostname of the SMTP server is used to send s alert.fromaddress [Optional] Set the return address that appears in the alert.recipients A comma-separated list of addresses that receive alerts 2. Test if notifications are working. Note: Firing a test alert is not available. a. Stop the active DCS. b. After 3 minutes, restart the DCS. An is sent for the active DCS that is failing and another one for the active DCS that is recovering. The standby DCS must be up and running for the alerts to be sent. Load Balancing To make all Teradata Viewpoint portals in a cluster appear as a single host and to protect users from a single host failure, a third-party load balancer can be set up to split traffic between the running Teradata Viewpoint portals. Configuration of a third-party load balancer is outside the scope of this guide. Teradata Viewpoint Configuration Guide, Release

88 CHAPTER 23 Configure Teradata Viewpoint SSL Support Enable users to access the Teradata Viewpoint server using an HTTPS connection. If clustering is used, perform this step on all Teradata Viewpoint servers in the cluster. Configure Teradata Viewpoint for SSL support To allow HTTPS communication to the Teradata Viewpoint server on port 443, install the SSL Certificate by accessing the Certificates portlet in Teradata Viewpoint. This portlet is available to Teradata Viewpoint administrators via the Admin > Viewpoint Config menu. Use the HTTPS Config section of this portlet to install any certificates needed to facilitate secure communications for LDAPS. Note: If clustering is used, perform this step on all Teradata Viewpoint servers in the cluster. The certificates are not automatically shared between clustered Teradata Viewpoint servers. Configure All Teradata Viewpoint Access to be Over SSL [Optional] To force all users of Teradata Viewpoint to access the server using HTTPS: 1. Log on to the Teradata Viewpoint server (Linux) as root. 2. Open /opt/teradata/viewpoint/conf/web.xml. 3. Add the following XML block near the end of the file, immediately before the existing </web-app> tag at the end of the file: <security-constraint> <web-resource-collection> <web-resource-name>viewpoint</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>confidential</transport-guarantee> </user-data-constraint> </security-constraint> 4. Save the web.xml file. Teradata Viewpoint Configuration Guide, Release

89 CHAPTER 24 Teradata Viewpoint Properties Teradata Viewpoint has a simple key-value properties table that is used to set various configuration options. Available Properties Table 5: Available Properties Property Values Default Effect Restart Required viewpoint.shareableportlets. enabledbydefault true or false false When true, shareable portlets are enabled by default; it is not necessary for a Teradata Viewpoint Administrator to enable the portlet in the Portlet Library. No viewpoint.web.caching. dailyexpiry.enable true or false true When set to true, web assets such as JS and CSS are given an expiration date of 2:00 a.m. the next morning. The browser does not check again for those assets until that time. No When set to false, expiration caching is disabled. When disabling caching (for example, before upgrading Teradata Viewpoint), the web assets change, but the browser does not check for new assets because of the expired tag. When caching is enabled, Teradata Viewpoint only checks this property (to determine whether caching should be disabled) at the switchover time (that is, every day at 2:00 a.m.). Disabling caching only takes effect after 2:00am, unless Teradata Viewpoint is restarted. Teradata Viewpoint Configuration Guide, Release

90 CHAPTER 24 Teradata Viewpoint Properties Property Values Default Effect Restart Required viewpoint.session.multiple true or false false However, this does not change the fact that the browser keeps caching until 2:00am. If caching is disabled, Teradata Viewpoint frequently checks if caching has been re-enabled. Enabling caching takes effect immediately. When false, a user can only be logged on to a single Teradata Viewpoint session under a given user name. If the user is already logged on to Teradata Viewpoint in one browser, and then logs into Teradata Viewpoint with the same user name in a second browser, the first browser session terminates. Yes Accessing Properties These Teradata Viewpoint properties (specifically the property table in the td_portal database) can be accessed programmatically using a Java DAO or a command-line utility. vp-property.sh The vp-property.sh script in the /opt/teradata/viewpoint/portal/bin directory is a utility to read, write, delete, list, and load Teradata Viewpoint properties. Run vp-property.sh help for extensive online help. For example, to determine if the default multiple session value has been overridden, run vp-property.sh read viewpoint.session.multiple To set the multiple session value, run vp-property.sh write viewpoint.session.multiple true 90 Teradata Viewpoint Configuration Guide, Release 14.01

91 CHAPTER 25 Installing Teradata Data Lab xx.xx Install Teradata Data Lab Use the rpm ivh command to install the Teradata Data Lab package. For example, to install the version of the Teradata Data Lab package, run the following command: rpm -ivh tddatalabsportlets SLES10_x noarch.rpm The RPM automatically stops the Teradata Viewpoint portal if it is running. After the RPM has been installed, the Teradata Viewpoint portal needs to be manually started. The Teradata Data Lab package can also be installed by TDPut. Uninstall Teradata Data Lab Package Manually If necessary, you can use the rpm e command to uninstall the Teradata Data Lab package manually. For example, to uninstall the version of the tddatalabsportlets package, run the following command: rpm -e tddatalabsportlets Configuring Notifications In order to send notifications. Teradata Data Lab requires that version or higher of Teradata Alerts be installed and running on the Teradata Viewpoint server. Installation instructions can be found in Teradata Alerts Installation and Configuration Guide. Additionally, the Alert Setup portlet must be used to configure the SMTP delivery settings for . Teradata Data Lab notifications for a Teradata Viewpoint user are sent to the address set for the user in the Profile portlet or the User Manager portlet. Teradata Viewpoint Configuration Guide, Release

92

93 CHAPTER 26 Upgrade to Teradata Viewpoint xx.xx Install Teradata Viewpoint for Electronic Software Distribution If Teradata Viewpoint was purchased under the Teradata Electronic Software Distribution Management (ESDM) program, the Teradata Viewpoint packages have not yet been installed on the Teradata Viewpoint server. Follow the instructions below for the initial installation for Teradata Viewpoint purchased under the ESDM program. Upgrades from Teradata Viewpoint xx.xx and Earlier In order to upgrade from Teradata Viewpoint xx.xx or earlier to Teradata Viewpoint xx.xx or later, two intermediate upgrades must be performed. If the version of Teradata Viewpoint is xx.xx or earlier, you must upgrade to Teradata Viewpoint Once that upgrade is complete, follow the steps in the next section Upgrades from Teradata xx.xx and Earlier. Some custom configuration changes applied in the previous version of Teradata Viewpoint must also be applied to the newly installed version. This includes: Installing additional portlets, including TMSM or any other portlet bundles previously installed in Teradata Viewpoint Note: This is only necessary if upgrading from a release earlier than In or later, deployed portlets are redeployed following the upgrade process. Changing the session timeout Note: This is only necessary if upgrading from a release earlier than In or later, the session timeout settings are persisted during the upgrade process. See Change the Session Timeout. Setting up TVI logging to a Teradata TVI queue table Note: This is only necessary if upgrading from a release earlier than In or later, the session timeout settings are persisted during the upgrade process. See Configure Teradata Viewpoint to Log to TVI. Teradata Viewpoint Configuration Guide, Release

94 CHAPTER 26 Upgrade to Teradata Viewpoint xx.xx Upgrades from Teradata Viewpoint xx.xx and Earlier In order to upgrade from Teradata Viewpoint xx.xx or earlier to Teradata Viewpoint xx.xx or later, an intermediate upgrade must be performed. If the version of Teradata Viewpoint is xx.xx or earlier, you must upgrade to Teradata Viewpoint Once that upgrade is complete, follow the steps in this document to upgrade Teradata Viewpoint to Teradata Viewpoint xx.xx or later. Some custom configuration changes applied in the previous version of Teradata Viewpoint must also be applied to the newly installed version. This includes: Installing additional portlets, including TMSM or any other portlet bundles previously installed in Teradata Viewpoint Note: This is only necessary if upgrading from a release earlier than In or later, deployed portlets are redeployed following the upgrade process. Changing the session timeout Note: This is only necessary if upgrading from a release earlier than In or later, the session timeout settings are persisted during the upgrade process. See Change the Session Timeout. Setting up TVI logging to a Teradata TVI queue table Note: This is only necessary if upgrading from a release earlier than In or later, the session timeout settings are persisted during the upgrade process. See Configure Teradata Viewpoint to Log to TVI. Upgrades from Teradata Viewpoint xx.xx and Earlier When upgrading from Viewpoint xx.xx and earlier to Viewpoint xx.xx, the PostgreSQL database must be upgraded to PostgreSQL All Viewpoint upgrades, whether script-based or PUT based, will automate the upgrade of PostgreSQL. PostgreSQL upgrades to a different major version require data to be backed up from the old version and restored into the new version. During the upgrade to Teradata Viewpoint 14.01, an incremental backup since the last backup is automatically taken. To limit the time that is required to perform an upgrade, a recent backup should be available in the /data/backup folder. The time a Teradata Viewpoint upgrade takes is proportional 2x the time it took to perform the last incremental backup. The duration of the last backup can be determined by looking at the Admin Backup portlet and subtracting the finish time from the configured start time. During the upgrade only configuration is restored. Historical data is migrated in the background after the Viewpoint services start up. The progress of the historical data migration is visible in Teradata Viewpoint s new notification banner at the top of the portal. Historical data is restored from newest to oldest. The notification banner displays percent complete and the oldest date for which historical data has been restored. The data migration notification banner is visible to all Teradata Viewpoint users by default. What users are able to see the Data Migration Notification Banner is configurable in the Roles Manager Portlet. Users 94 Teradata Viewpoint Configuration Guide, Release 14.01