Teradata Viewpoint 13.11 database software Configuration Guide
Below you will find brief information for database software Viewpoint 13.11. This configuration guide provides comprehensive instructions for setting up and managing your Teradata Viewpoint 13.11 system, including essential steps like adding Teradata Database systems, configuring data collectors, and managing alerts. You'll also learn how to configure Teradata Viewpoint for security and performance optimization.
Advertisement
Advertisement
Configuration Guide
Release 13.11
B035-2207-120A
December 2010
The product or products described in this book are licensed products of Teradata Corporation or its affiliates.
Teradata, BYNET, DBC/1012, DecisionCast, DecisionFlow, DecisionPoint, Eye logo design, InfoWise, Meta Warehouse,
MyCommerce, SeeChain, SeeCommerce, SeeRisk, Teradata Decision Experts, Teradata Source Experts, WebAnalyst, and You’ve
Never Seen Your Business Like This Before are trademarks or registered trademarks of Teradata Corporation or its affiliates.
Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc.
AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc.
BakBone and NetVault are trademarks or registered trademarks of BakBone Software, Inc.
EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation.
GoldenGate is a trademark of GoldenGate Software, Inc.
Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.
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 and Engenio are registered trademarks 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.
Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries.
QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation.
SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc.
SPARC is a registered trademark of SPARC International, Inc.
Sun Microsystems, Solaris, Sun, and Sun Java are trademarks or registered trademarks of Sun Microsystems, Inc., in the United
States and other countries.
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 collective membership mark and a service mark of Unicode, Inc.
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.
T
HE 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
.
S
OME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED
WARRANTIES
,
SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU
.
I
N NO EVENT WILL
T
ERADATA
C
ORPORATION 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 e-mail: mailto:[email protected].
Any comments or materials (collectively referred to as “Feedback”) sent to Teradata Corporation will be deemed nonconfidential. 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 © 2008-2010 by Teradata Corporation. All Rights Reserved
Table of Contents
CHAPTER 1
Teradata Viewpoint Requirements
Client Machine Recommendations
Teradata Viewpoint Server Requirements
Supported Teradata Database Versions
CHAPTER 2
Start and Stop Teradata Viewpoint Services
CHAPTER 3
Teradata System Preparation
Set Up TASM and Alerting Tables
Create a Teradata User for Data Collection
Set Up Access to Console Utilities
Grant Permissions to the Teradata User for Data Collection
CHAPTER 4
Configure Viewpoint to Monitor a Teradata Database System
Log on to the Teradata Viewpoint Server
20
14
11
12
Teradata Viewpoint Configuration Guide, Release 13.11 3
CHAPTER 5
Changing a Teradata System Nickname
CHAPTER 6
Configure Alerts
Configure Alert Delivery Settings
Configure Run a Program Alerts
Teradata Viewpoint Configuration Guide, Release 13.11
27
28
4
CHAPTER 7
Install Teradata Notification Service for Windows
CHAPTER 8
Install Teradata Notification Service
Configure Teradata Notification Service
Configure Teradata Notification Service with Teradata Viewpoint Clustering
Configure Teradata Notification Service with Teradata Alerting Clustering
CHAPTER 9
Teradata Manager Feature Equivalence
CHAPTER 10
Configure Viewpoint to Monitor a Managed Server
CHAPTER 11
Configure Teradata Viewpoint LDAP
LDAP Data Interchange Format (LDIF)
Determine LDAP Configuration Mode
Standard Configuration and Testing
Teradata Viewpoint Configuration Guide, Release 13.11
38
39
42
45
46
5
CHAPTER 12
Configure Teradata Viewpoint Security
Control Access within Portlets
CHAPTER 13
Configure Teradata Viewpoint to Log to TVI
CHAPTER 14
Back Up Teradata Viewpoint Databases
CHAPTER 15
Restore a Teradata Viewpoint Database
Restore a Database from Teradata Viewpoint Version 13.11 and Later
Restore a Database from Teradata Viewpoint Version 13.10 and Earlier
CHAPTER 16
Change the Session Timeout
CHAPTER 17
Set the Default Locale
CHAPTER 18
Reset the Admin User Password
CHAPTER 19
Ports Used by Teradata Viewpoint
Teradata Viewpoint Configuration Guide, Release 13.11
60
62
63
64
65
6
56
58
59
CHAPTER 20
Set Teradata Viewpoint Server Time
66
CHAPTER 21
Configure NTP Time Synchronization 67
CHAPTER 22
Teradata Viewpoint Clustering 68
High Availability Configuration: Two Teradata Viewpoint Servers
High Usage Configuration: Three or More Teradata Viewpoint Servers
Advanced Configuration: Three or More Teradata Viewpoint Servers with Dedicated Cache Database
Data Collection Service (DCS) Failure (Scenario 1)
Cache Database Failure (Scenario 2)
Active Teradata Viewpoint Server Failure
Create a Teradata Viewpoint Cluster
Set Up Cluster Configuration Files
Add Additional Teradata Viewpoint Servers to the Cluster
Configure Teradata Notification Service for Windows with Teradata Viewpoint Cluster
Set Up Teradata Viewpoint Cluster Configuration Files
Promote the Standby Cache Database
Upgrade PostgreSQL to Enable Clustering
Additional Cluster Considerations
Getting Notifications of Failures
Teradata Viewpoint Configuration Guide, Release 13.11 7
CHAPTER 23
Teradata Alerting Clustering
Alerting Cluster Configurations
Alert Service Failure (Scenario 1)
Messaging Service Failure (Scenario 2)
Cache Database Failure (Scenario 4)
Active Teradata Alerting Server Failure (Scenario 5)
Create a Teradata Alerting Cluster
Set Up Teradata Alerting Cluster Configuration Files
Configure Teradata Notification Service for Windows with Teradata Alerting Cluster
Set Up Teradata Alerting Cluster Configuration Files
Replace a Teradata Alerting Server in the Cluster
Promote the Teradata Alerting Messaging Service
Additional Alerting Considerations
Teradata Alerting Cluster Security
Getting Notifications of Failures
CHAPTER 24
Configure Teradata Viewpoint SSL Support
Configure Teradata Viewpoint for SSL support
[Optional] Configure All Teradata Viewpoint Access to be Over SSL
Create a Self-Signed Certificate
Create a Certificate Signing Request
Install a CA Certificate in Teradata Viewpoint Keystore
CHAPTER 25
Teradata Viewpoint Properties
Accessing Properties vp-property.sh
96
99
86
Teradata Viewpoint Configuration Guide, Release 13.11 8
CHAPTER 26
Portlet Load Times
CHAPTER 27
Upgrade to Teradata Viewpoint 13.11.xx.xx
Install Teradata Viewpoint for Electronic Software Distribution
Teradata Viewpoint Install Script
Download the Teradata Viewpoint 13.11 Software
Verify the Previous Database Backup
Identify the Primary Cache Database Server
Stop the Teradata Viewpoint Services
Copy SSL Certificates to New Teradata Viewpoint Keystore
Set Up New Collectors and Portlets
Install and Uninstall Teradata Viewpoint Packages Manually
Handle Failed Upgrades of Teradata Viewpoint
Install Teradata Viewpoint Packages Manually
Uninstall Teradata Viewpoint Packages Manually
CHAPTER 28
Back Down to a Previous Teradata Viewpoint Version
101
103
110
Teradata Viewpoint Configuration Guide, Release 13.11 9
Audience
This document is intended for Teradata Customer Services, Teradata Professional Services, and customers for configuring Teradata Viewpoint software.
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.
Teradata Viewpoint Configuration Guide, Release 13.11 10
CHAPTER 1
Teradata Viewpoint Requirements
Client Machine Recommendations
Supported web browsers:
• Mozilla Firefox 3.6
• Internet Explorer 6, 7, or 8
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 or R710 Managed Server
• SuSE Linux 10
• Teradata JDK 1.5 (SR8 or later)
• PostgreSQL Server 8.1 or 8.3
Supported Teradata Database Versions
• V2R6.2 (all functionality except Workload Designer)
• 12.0
• 13.0
• 13.10
Teradata Viewpoint Configuration Guide, Release 13.11 11
CHAPTER 2
Start and Stop Teradata Viewpoint
Services
Teradata Viewpoint 13.11 and later includes the following separate services:
• viewpoint
The Teradata Viewpoint portal that provides web browser access.
• dcs
The Data Collection Service that monitors and collects data from Teradata systems.
• tmsmonitor
The Teradata Managed Server Monitor that monitors performance of the Teradata Viewpoint server.
• camactivemq
The Teradata Alerting Message Service that allows for message exchange between the Teradata
Alerting components.
• camalert
The 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 succeeds 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:
/etc/init.d/viewpoint stop
To restart the Data Collection Service:
/etc/init.d/dcs restart
To check if the Teradata Managed Server Monitor is running:
/etc/init.d/tmsmonitor status
To control or check the status of all Teradata Viewpoint services on the current server:
/opt/teradata/viewpoint/bin/vp-control.sh
Teradata Viewpoint Configuration Guide, Release 13.11 12
This script supports the same command arguments as the individual init.d scripts: start, stop, restart
and status.
Teradata Viewpoint Configuration Guide, Release 13.11 13
CHAPTER 3
Teradata System Preparation
Set Up TASM and Alerting Tables
To monitor a Teradata 12 or Teradata 13 database with Teradata Viewpoint 13.11, you must set up TASM and Alerting tables, using one of the following:
• The Teradata Manager setup application
• A Windows setup application either downloaded from 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 setup tables on Teradata 12, use Teradata Manager 12.0. For Teradata 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 12.0 with TASM, and migrating to Teradata 13.0
• When installing a new Teradata 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 including the application and the supporting files are named:
• dbsetup12vp__Windows_i386.12.03.00.00.zip for Teradata 12
• dbsetup13vp__Windows_i386.13.03.00.00.zip for Teradata 13
Set Up the PC
1. Install the 32 bit client communication Windows packages to connect to the database. The following are the required packages:
• 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 13.11 14
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 entering 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 a failure to communicate with the Teradata Database. The HOSTS file is located in the directory where Windows is installed, under system32\drivers\etc
.
• If Domain Name Services (DNS) is not used, ensure that the HOSTS file contains entries similar to the following: 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 with system identification.
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 the Application
1. In the folder where you extracted the .zip file, double-click dbsetup12vp.exe or dbsetup13vp.exe.
The Database Setup window appears.
2. In the System Name field, enter the TDPID of the database to use to setup the tables.
Teradata Viewpoint Configuration Guide, Release 13.11 15
3. In the Super User and Super User Password fields, enter the name and password of a user who has permissions to create tables and grant access to existing DBC tables.
DBC is the recommended user.
4. In the Perm Space field, enter appropriate values. The default values of 50 MB and 100 MB are likely sufficient.
5. [Optional] If you are 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 between 2 and 10 minutes.
On a heavily loaded system, the setup can take longer.
Note: If the setup application has already been run, a confirmation message appears.
Rerunning the setup program does not cause any data to be lost.
7. If an error message appears, review the output and inspect any reported errors.
Typical errors are results of trying to delete items that do not exist, in preparation for the setup. You can find any 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 a set of 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 13.0.1.
The user can be an existing user. The username and the password, viewpoint, is 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. Type the following command, where <perm space> and <spool space> are the respective perm space and spool space to allocate the user: create user viewpoint as perm=<perm space>, spool=<spool space> password=viewpoint;
Teradata Viewpoint Configuration Guide, Release 13.11 16
Set Up Access to Console Utilities
1. Do one of the following:
• If Teradata Manager is not monitoring the target Teradata Database system, type:
• create user console as perm=50000, spool=50000, account='$Hremote-console-use', password=console, fallback; replace macro console.dbscontrol as (;); replace macro console.aborthost as (;); replace macro console.ampload as (;); replace macro console.config as (;); replace macro console.checktableb as (;); replace macro console.dumplocklog as (;); replace macro console.dumplocklogb as (;); replace macro console.ferret as (;); replace macro console.xgtwglobal as (;); replace macro console.lokdisp as (;); replace macro console.cnscons as (;); replace macro console.schmon as (;); replace macro console.qryconfig as (;); replace macro console.qrysessn as (;); replace macro console.rcvmanager as (;); replace macro console.showlocks as (;); replace macro console.tdwmdmp as (;); replace macro console.vprocmanager as (;);
If Teradata Manager is not monitoring the target Teradata Database system, or if Teradata
Manager DBSSetup 7.x or earlier is the latest version run against the target Teradata System, run the following commands to create the default macros used to clean up the DBQL and TASM log tables:
REPLACE MACRO dbcmngr.dcDBQLDeleteOld (AgeDays INTEGER) AS (
DELETE dbc.DBQLSummaryTbl WHERE CAST(CollectTimeStamp AS DATE)
<= (DATE - :AgeDays); DELETE dbc.DBQLStepTbl WHERE
CAST(CollectTimeStamp AS DATE) <= (DATE - :AgeDays); DELETE dbc.DBQLogTbl WHERE CAST(CollectTimeStamp AS DATE) <= (DATE -
:AgeDays); DELETE dbc.DBQLObjTbl WHERE CAST(CollectTimeStamp AS
DATE) <= (DATE - :AgeDays); DELETE dbc.DBQLExplainTbl WHERE
CAST(CollectTimeStamp AS DATE) <= (DATE - :AgeDays); DELETE dbc.DBQLSqlTbl WHERE CAST(CollectTimeStamp AS DATE) <= (DATE -
:AgeDays); );
REPLACE MACRO dbcmngr.dcTDWMDeleteOld (AgeDays INTEGER) AS
(DELETE dbc.TDWMSummaryLog WHERE CAST(BufferTS AS DATE) <=
(DATE - :AgeDays); DELETE dbc.TDWMEventLog WHERE CAST(BufferTS
AS DATE) <= (DATE - :AgeDays); DELETE dbc.TDWMExceptionLog
WHERE CAST(BufferTS AS DATE) <= (DATE - :AgeDays); );
• If Teradata Manager is monitoring the target Teradata Database system, go
Grant Permissions to the Teradata User for Data Collection on page 18.
Teradata Viewpoint Configuration Guide, Release 13.11 17
Grant Permissions to the Teradata User for
Data Collection
Grant permissions to the Teradata user for Teradata Viewpoint Data Collection.
1. Do one of the following:
• If the TDWM database exists on the target Teradata Database system, type the following command, then go to step 2: grant select on TDWM to viewpoint;
• If the TDWM database does not exist, go to step 2.
2. Type the following commands: grant monitor to viewpoint; grant select on DBC to viewpoint; grant select, delete on dbcmngr to viewpoint; grant exec on console.ampload to viewpoint; grant exec on console.dbscontrol to viewpoint; grant exec on console.aborthost to viewpoint; grant exec on console.config to viewpoint; grant exec on console.checktableb to viewpoint; grant exec on console.dumplocklog to viewpoint; grant exec on console.dumplocklogb to viewpoint; grant exec on console.ferret to viewpoint; grant exec on console.xgtwglobal to viewpoint; grant exec on console.lokdisp to viewpoint; grant exec on console.cnscons to viewpoint; grant exec on console.schmon to viewpoint; grant exec on console.qryconfig to viewpoint; grant exec on console.qrysessn to viewpoint; grant exec on console.rcvmanager to viewpoint; grant exec on console.showlocks to viewpoint; grant exec on console.vprocmanager to viewpoint; grant exec on console.tdwmdmp to viewpoint;
3. If the automatic rights granted to the viewpoint user were revoked, run the following commands: grant create table, drop table on viewpoint to viewpoint; grant select, insert on viewpoint to viewpoint;
4. To use the Log Table Clean Up functionality, run the following commands:
• For all databases, type: grant exec on dbcmngr to viewpoint; grant delete on DBC.ResUsageSpma to viewpoint; grant delete on DBC.ResUsageSvpr to viewpoint; grant delete on DBC.ResUsageShst to viewpoint; grant delete on DBC.ResUsageIpma to viewpoint; grant delete on DBC.ResUsageIvpr to viewpoint; grant delete on DBC.ResUsageScpu to viewpoint; grant delete on DBC.ResUsageSldv to viewpoint;
Teradata Viewpoint Configuration Guide, Release 13.11 18
grant delete on DBC.AccLogTbl to viewpoint; grant delete on DBC.EventLog to viewpoint; grant delete on DBC.SW_Event_Log to viewpoint; grant select, delete on dbc.DBQLogTbl TO dbcmngr with grant option; grant select, delete on dbc.DBQLSummaryTbl TO dbcmngr with grant option; grant select, delete on dbc.DBQLStepTbl TO dbcmngr with grant option; grant select, delete on dbc.DBQLObjTbl TO dbcmngr with grant option; grant select, delete on dbc.DBQLExplainTbl TO dbcmngr with grant option; grant select, delete on dbc.DBQLSqlTbl TO dbcmngr with grant option; grant select, delete on dbc.TDWMSummaryLog TO dbcmngr with grant option; grant select, delete on dbc.TDWMExceptionLog TO dbcmngr with grant option; grant select, delete on dbc.TDWMEventLog TO dbcmngr with grant option;
• For Teradata V2R6, type: grant delete on DBC.ResUsageSobj to viewpoint;
• For Teradata databases 12 or later, type: grant delete on DBC.ResUsageSawt to viewpoint; grant delete on DBC.ResUsageSps to viewpoint; grant delete on DBC.ResUsageSpdsk to viewpoint; grant delete on DBC.ResUsageSvdsk to viewpoint;
5. To use the Virtual Storage collector, run the following command: grant execute function on syslib.GetTvsUdfViewpointSummary to viewpoint;
Teradata Viewpoint Configuration Guide, Release 13.11 19
CHAPTER 4
Configure Viewpoint to Monitor a
Teradata Database System
Log on to the Teradata Viewpoint Server
1. Open a browser.
2. Enter the host name or IP address of the Teradata Viewpoint server.
For example: http://viewpoint
3. Log on to Teradata Viewpoint with the username of admin and the password of teradata (default).
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. Enter a SYSTEM NICKNAME (8 characters or less) for the Teradata Database system.
4. [Optional] Select System Enabled to activate the Teradata Database system for monitoring.
5. In the TDPID field, enter 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.
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.
Teradata Viewpoint Configuration Guide, Release 13.11 20
6. In the LOGIN section, create the user logins. a. Enter a user Name. b. Enter a Password. c. [Optional] Enter an Account string to differentiate the user account. d. 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.
The user login must have specific permissions. See
Grant Permissions to the Teradata User for
e. [Optional] Enter a Password for the tdwm user.
This user login is used by the Workload Designer portlet to edit rule sets and to issue activate requests. It cannot be used by any data collectors.
7. [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.
8. In the CHARACTER SET section, set the session and monitor default character sets.
10.
The session character set defaults to UTF8; the monitor character set defaults to ASCII.
9. Click Apply.
[Optional] Enable the SYSTEM HEARTBEAT in CANARY QUERIES.
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 LAN and accesses the appropriate data sources through the Teradata JDBC driver.
Generally, the default values can be used. In fact, 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 collectors except Virtual Storage (Configure in Data Collectors) checkbox was not selected when configuring the new system.
Teradata Viewpoint Configuration Guide, Release 13.11 21
Set data collection parameters or save defaults for:
• Account Info
• Alert Request
• AWT Info
• Database Space
• Disk Space
• Lock Info
• Query Count
• Resource Usage
• Sessions
• System Config
• System Stats
• Table Space
• TASM Config
• TASM Distribution
• TASM Exception
• TASM State
• 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.
Teradata Viewpoint Configuration Guide, Release 13.11 22
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.
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.
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 for Database Space alerting.
Disk Space
The Disk Space collector queries the DiskSpace view in the DBC database to collect disk space usage data.
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 up-todate disk space data.
Lock Info
The Lock Info collector uses Locking Logger (a database utility) to capture a snapshot of lock information and stores this data in the PostgreSQL database. The Lock Viewer portlet uses the data collected by the
Teradata Viewpoint Configuration Guide, Release 13.11 23
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 to 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
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 1 hour. To get the portlets to show more up-to-date query counts, the collection frequency can be increased, 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 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, 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
Teradata Viewpoint Configuration Guide, Release 13.11 24
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.
System Config
The System Config collector determines the version and system type of the Teradata Database. This information is critical 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.
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 CPU. 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 up-to-date 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 collects configuration information about the TDWM version and the active rule set in Teradata from the TDWM database in Teradata. This collector replaces the Workload collector that was available in 13.0.1. This data is used by My Queries, Query Monitor, Workload Health,
Workload Monitor, and Workload Designer.
Teradata Viewpoint Configuration Guide, Release 13.11 25
The TASM Config collector needs to be enabled 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.
TASM Distribution
The TASM Distribution collector collects CPU distribution by workload, by executing schmon –M –p in the Teradata Console partition.
The collected data is used by the Workload Monitor portlet.
TASM Exception
The TASM Exception collector collects TASM Exception data from the DBC.TDWMExceptionLog table.
The collected data is used by the Workload Monitor portlet.
TASM State
The TASM State collector collects system regulation data for Teradata Database version 12.00 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 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 collects 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 collects 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.
Teradata Viewpoint Configuration Guide, Release 13.11 26
CHAPTER 5
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/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.
R
estart the Teradata Viewpoint portal and the DCS.
Teradata Viewpoint Configuration Guide, Release 13.11 27
CHAPTER 6
Configure Alerts
To configure alerts in Teradata Viewpoint, perform the following steps:
1. Configure the wanted alert delivery mechanisms using the Alert Setup portlet.
2. [Optional] Migrate alerts from previous Teradata Manager alerts, using thee Teradata Systems portlet.
3. Define alert action sets and alert groups using the Alert Setup portlet.
4. Define alert rules using the Teradata Systems portlet.
5. View alerts in the Alert Viewer portlet.
Configure Alert Delivery Settings
Configure Email Alerts
You can configure the Alert Service to send alert notifications by email.
The following procedure is more fully described in Teradata Viewpoint online help.
1. From the Admin menu, click Alert Setup.
2. The
Alert Setup
portlet appears.
3. From the SETUP OPTIONS list, click Delivery Settings.
4. From the DELIVERY TYPES list, click Email.
5. Under SMTP Host, type the host address of the outgoing (SMTP) email server.
6. In the Reply-to box, type the email address to use as the Reply-to address in delivered alert email messages.
7. To test your email delivery settings, type a valid recipient email address in the Test Recipient box and click Test.
Teradata Viewpoint Configuration Guide, Release 13.11 28
Configure SNMP Alerts
You can configure the Alert Service to deliver alert notifications to third-party management applications using SNMPv2c.
The following procedure is more fully described in Teradata Viewpoint online help.
1. From the Admin menu, click Alert Setup.
2. The
Alert Setup
portlet appears.
3. From the SETUP OPTIONS list, click Delivery Settings.
4. From the DELIVERY TYPES list, click SNMP.
5. To add an SNMP configuration, click .
6. In the Configuration Name box, type a name for the SNMP configuration.
7. In the Destination box, type the IP address or host name of the destination for SNMP alert
notificatioins.
8. In the Community box, type a name for the SNMP community.
The default is public.
9. To test the SNMP configuration on the specified destination host or hosts, click Test.
Teradata SNMP MIB
The Teradata Alerting SNMP MIB (Management Information Base) is available in:
/opt/teradata/cam/alert/config/teradataCamMib.txt
SNMP Object Identifiers (OIDs) for Teradata Alerting are defined under: iso.org.dod.internet.private.enterprises.teradata.td-products.tdcam
The Teradata Alerting SNMP MIB defines a single trap, tdCamAlertTrap, identified as trap 303 under the tdcam OID.
Configure BTEQ Alerts
You can configure the Alert Service to run BTEQ alert actions.
Prerequisites
The Teradata Notification Service must be installed and running on a Windows server.
BTEQ Configuration
The following procedure is more fully described in Teradata Viewpoint online help.
Teradata Viewpoint Configuration Guide, Release 13.11 29
1. From the Admin menu, click Alert Setup.
2. The
Alert Setup
portlet appears.
3. From the SETUP OPTIONS list, click Delivery Settings.
4. From the DELIVERY TYPES list, click BTEQ.
5. To add a BTEQ configuration, click .
6. In the TDPID box, type the TDPID of the Teradata Database you want to log on to.
Note:
The TDPID must match the configuration in the Teradata Systems portlet.
7. In the boxes, type a valid Username and Password to use to log on to the specified TDPID.
8. To test the BTEQ configuration on the specified TDPID, click Test.
Teradata Notification Service performs a test log on to the specified TDPID.
Installing BTEQ Scripts
The Teradata Alerting software runs BTEQ scripts on the server where the Teradata Notification Service software is installed. Place the BTEQ scripts in the following folder:
[Install Folder]\Teradata\Client\13.10\Teradata Notification
Service\sql
When the Teradata Notification Service is running, it monitors the
sql
folder every 15 seconds. The
Alert Setup portlet reflects any changes to the directory contents.
About Running BTEQ Scripts
When migrating from Teradata Manager alerts to Teradata Alerting, be aware of the following differences:
Teradata Alerting Teradata Manager
Program BTEQ DMTEQ
Supports
.logon… syntax
Where to configure logon credentials
No Yes
Alert Setup portlet, in the BTEQ Delivery
Settings view
Script file location
[Install folder]\Teradata\
Client\13.10\Teradata
Notification Service\sql
Teradata Manager Administration, in the Systems window
[Install folder]\Teradata\
Teradata Manager 13.0\ secure
Teradata Viewpoint Configuration Guide, Release 13.11 30
Note:
Ensure that any SQL scripts you want to use with Teradata Alerting do not contain the
.logon…
command, as BTEQ does not support it. Logon credentials must be defined in the Alert Setup portlet.
Teradata Alerting submits the following BTEQ commands to create a Teradata session and to run a script file when performing a BTEQ alert action:
• .LOGON. The TDPID, username, password, and account credentials defined in the Alert Setup portlet.
• .LOGMECH. If you defined a Logmech Name in the Alert Setup portlet.
• .LOGDATA. If you defined Logmech Name and Logmech Data in the Alert Setup portlet.
• .RUN FILE. The name of the script file selected in the Alert Setup portlet.
• .QUIT
Configure Run a Program Alerts
Prerequisites
You do not need to perform any specific setup or configuration to enable programs to run as alert actions.
However, the programs you intend to run must reside on the Windows server, where the Teradata
Notification Service runs.
Installing Programs to Run
The Teradata Alerting software runs external programs on the server where the Teradata Notification
Service software is installed. Place the programs you want to run in the following folder:
[Install Folder]\ Teradata\Client\13.10\Teradata Notification
Service\usrcmd
When the Teradata Notification Service is running, it monitors the usrcmd folder every 15 seconds.
Changes to the directory contents are reflected in the Alert Setup portlet
.
Configure Alert Time Frames
You can schedule alert actions to run during one or more of the following time frames:
• Core hours
• Evening hours
• Weekend hours
The following procedure is more fully described in Teradata Viewpoint online help.
1. From the Admin menu, click Alert Setup.
Teradata Viewpoint Configuration Guide, Release 13.11 31
2. The
Alert Setup
portlet appears.
3. From the SETUP OPTIONS list, click Alert Presets.
4. From the PRESET OPTIONS list, click Core Hours.
5. Define time frames for core, evening, and weekend hours.
Configure Alert Action Sets
When you have configured the alert delivery settings, configure the alert actions you want to use when an alert occurs.
Alert actions can be combined into action sets. An action set allows you to run multiple alert actions in a single operation.
The following procedure is more fully described in Teradata Viewpoint online help.
1. From the Admin menu, click Alert Setup.
2. The Alert Setup portlet appears.
3. From the SETUP OPTIONS list, click Alert Presets.
4. From the PRESET OPTIONS list, click Action Sets.
5. To add an action set, click .
6. Under Times, select check boxes for the hours of operation during which you want the action set to run.
7. Under Actions, select any of the following actions by selecting the appropriate check box:
• Include in alert log
• Send to person
• SNMP
• BTEQ
• Run a program
Note:
You must configure the delivery settings for an alert delivery mechanism before that option is available.
Configure Alert Groups
When you have configured the alert delivery settings and the action sets, you can configure the alert groups you want to use when an alert occurs. A group allows you to run multiple action sets in a single operation.
Teradata Viewpoint Configuration Guide, Release 13.11 32
The following procedure is more fully described in Teradata Viewpoint online help.
1. From the Admin menu, click Alert Setup.
2. The Alert Setup portlet appears.
3. From the SETUP OPTIONS list, click Alert Presets.
4. From the PRESET OPTIONS list, click Groups.
5. To add an action set, click .
6. In the Group Name box, type a name for the group.
7. Select the action sets you want to include in the group.
Migrate Existing Alerts
When you have configured a Teradata System in Teradata Viewpoint, you can migrate alerts from
Teradata Manager to Teradata Viewpoint. The currently applied alert policy 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 more fully described in Teradata Viewpoint online help.
1. Click Admin >Teradata Systems.
2. The Teradata Systems portlet appears.
3. Select system, alerts, and alert type.
4. Under ALERTS, click Migrate Alerts.
5. Enter a username and password that has permission to read data from the AlertAction, AlertEvent, and
AlertLevel tables in the dbcmngr database on the Teradata System.
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.
Teradata Viewpoint Configuration Guide, Release 13.11 33
The following procedure is more fully described in Teradata Viewpoint online help.
1. Click Admin >Teradata Systems.
The Teradata Systems portlet appears
.
2. Select SYSTEMS>Alerts>ALERT TYPES.
3. Enter 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.
Enter the number of minutes in the Do not run twice in box.
The alert action does not run twice in the time you entered.
View Alerts
The Alert Viewer portlet allows you to view logs of the alerts that have occurred. For the alert logs to show, you must enable the Include in alert log option for the action sets. This is done in the Alert Setup portlet.
The Alert Viewer portlet is more fully described in Teradata Viewpoint online help.
1. From the Add Content menu, go to Monitoring > Alert Viewer.
The
Alert Viewer
portlet appears and displays the alerts that have been triggered.
Use the AlertRequest Table
Any Teradata Database utility or user program can request an alert by inserting a row into the
AlertRequest table in the Teradata dbcmngr database. The Alert Request Data Collector monitors the
AlertRequest table for incoming alert requests. If the row contains valid data, the contents are forwarded to the Alert Service to process the alert action. You can view the details of the alert request in the Alert
Viewer portlet.
The AlertRequest table is defined as follows:
Column Type
ReqDate Date
ReqTime
JobName
Integer
Char(60)
Description Char(120)
Event Value Integer
Description
Request date generated on the Teradata Database
Request time generated on the Teradata Database
Name of the requesting job
Text description of the event (the reason for the alert)
Event value (if appropriate)
Note:
Event value is null if the value is unknown or cannot be represented as a single numeric value.
Teradata Viewpoint Configuration Guide, Release 13.11 34
Column Type Description
ActionCode Char(1)
RepeatPeriod Smallint
Type of action being requested. The action codes are:
'E' - send an email
'L' - write a log entry
'R' - run a program
'S' - send an SNMP trap
'T' - run a BTEQ script
'+' - run an action set or group
Minimum time (in minutes) between alerts for this event. Zero means
‘always run the alert’. This value is ignored if the ActionCode is `+'.
Destination
Message
Char(120) Indicates the destination based on the ActionCode:
'E' – the email address
'R' – the program name to run
'T' – the BTEQ script to run
'S' – ignored – uses the default SNMP configuration for Alert Request
Collector
'+' – the Action Set or Group action to run
Varchar(600) Message to be sent for this alert (for example, email message, or numeric page and callback number.)
Request an Email Alert
The following is an example of an insert statement. It causes an email message to be sent to the user named dba at mysite.com. The action does not repeat within 20 minutes. insert dbcmngr.alertrequest values
(date, time, 'Job1', 'Load job completed', 0, 'e', 20,
'This message indicates that the load job completed!');
Use the MonitorRequest Table
By inserting rows into the MonitorRequest table in the dbcmngr database, any Teradata Database utility or user program can request that Teradata Viewpoint monitor its progress. Each row includes fields that indicate the date and time by which the next row is inserted.
The Alert Request Data Collector monitors the MonitorRequest table. 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. You can view the details of the alert request in the Alert Viewer portlet.
When the job finishes, it inserts a final row containing a 0 (zero) in the ActionCode column. This ends the monitor request. No further alert actions are run.
Teradata Viewpoint Configuration Guide, Release 13.11 35
The MonitorRequest table is defined as follows:
Column Type Description
MonitorId
ActionDate
EventValue
Message
Char(60)
Date
ActionTime Integer
JobName Char(60)
Integer
ActionCode Char(1)
Destination Char(120)
A unique ID for the job:
Date, StartTime, Host ID, and session id is recommended
Date before which the next row for this job is inserted
Time before which the next row for this job is inserted
Name of the requesting job
Any value to be displayed in the Alert Viewer, or included in the alert action. For example, if monitoring a load job, this could be the number of rows inserted so far.
Type of action being requested. The action codes are:
'E' - send an email
'L' - write a log entry
'R' - run a program
'S' - send an SNMP trap
'T' - run a BTEQ script
'+' – run an action set or group
'0' - the job is completed (no alert is run)
Indicates the destination based on the ActionCode:
'E' – the email address
'R' – the program name to run
'T' – the BTEQ script to run
'S' – ignored – uses the default SNMP configuration for Alert Request
Collector
'+' – the Action Set or Group action to run
Varchar(600) Message to be sent for this alert
Monitor a Five-Minute Job
If a job takes five minutes to complete, but sometimes hangs due to lock conflicts, two additional steps can be added as follows:
1. Before the job, run the following: insert dbcmngr.monitorrequest select '20010523100142011234', date, monTime, 'My Job', 0, '+',
'Email Admin', ''
from (select extract(hour from xt)*10000+extract(minute from xt)*100+extract(second from xt), (current_time+interval '10' minute) as xt)
t1(monTime, xt);
Teradata Viewpoint Configuration Guide, Release 13.11 36
2. After the job, run the following: insert dbcmngr.monitorrequest values
('20010523100142011234', date, time, 'My Job', 0, '0', '', '');
This tells the Alert Request Collector to request the alert action Email Admin if the job does not finish within 10 minutes.
Monitor a Long-Running Job
The MonitorRequest feature can also be used to send updated status information on long-running jobs. In this context, the job uses date and time when inserting into the MonitorRequest table, forcing the designated alert action to run. The EventValue or Message fields can be used to indicate current status.
For example, a big load job can notify an administrator of its progress by running the following at regular intervals: insert dbcmngr.monitorrequest values
('20010523100142011234', date, time, 'Load Job', 150000, 'e',
'[email protected]', '');
The value 150000 represents the number of rows loaded so far. Each time the job inserts a row, it inserts the latest row count in the EventValue column.
Teradata Viewpoint Configuration Guide, Release 13.11 37
CHAPTER 7
Install Teradata Notification Service for Windows
To be able to use BTEQ and Run a program alert actions, you must first install the Teradata Notification
Service. Install the service on a Windows server, and configure it with information about your Teradata
Viewpoint server.
Software Dependencies
Teradata Notification Service has the following software dependencies:
• Java JRE SE 5.0
Set the JAVA_HOME environment variable at the System level.
This is important because the Teradata Notification Service runs as a service.
• TTU 13.10
Teradata BTEQ and all its dependencies
Prerequisites
Before installing Teradata Notification Service, ensure the following:
• The Teradata Viewpoint server is set up.
• The Teradata Viewpoint server is running.
• You know the hostname of the Teradata Viewpoint server.
Teradata Viewpoint Configuration Guide, Release 13.11 38
CHAPTER 8
Install Teradata Notification Service
1. Extract the Teradata Notification Service software to your server.
The name of the zip file is:
teradatacam_win32_x86.13.11.xx.xx.zip.
2. Navigate to the DISK1 folder, click setup.exe.
3. Select setup language, and click OK.
4. Follow the Install Shield Wizard, making the following settings: a. Accept the license agreement. b. [Optional] Change the destination folder. c. Specify the system name of your Teradata Viewpoint server. d. Click Install. e. Select Start the Teradata Notification Service now, and click Finish.
Configure Teradata Notification Service
The installation procedure asks to you enter the name of the Teradata Viewpoint Server. If you did not complete this step, you must manually configure the Teradata Notification Service to know the location of the alert processes and the PostgreSQL database.
1. Edit the config\cam-db.properties file as follows:
#cam.db.host=%{activeDatabaseHost}
2. Remove the comment and assign cam.db.host to the server where PostgreSQL is running (the server, on which you installed Teradata Viewpoint and PostgreSQL). cam.db.host=serverName
3. Edit the config\cam-jms.properties file as follows:
#cam.activemq.host=localhost
4. Remove the comment and assign cam.activemq.host to the server where you have installed the
camactivemq-13.11.xx.xx rpm. cam.activemq.host=serverName
Teradata Viewpoint Configuration Guide, Release 13.11 39
Configure Teradata Notification Service with
Teradata Viewpoint Clustering
availability and scalability. For a site that uses Teradata Viewpoint clustering, you must configure Teradata
for details.
Configure Teradata Notification Service with
Teradata Alerting Clustering
that uses Teradata Alerting clustering, you must configure Teradata Notification Service to work with this
Configure TVI Logging
To enable TVI logging for the Teradata Notification Service, do the following:
1. Copy config/tvilogger.properties to the following root folder.
[c:]\opt\teradata\tvilogger\tvilogger.properties
2. Edit the properties as follows: tvilogger.method=queuetable tvilogger.host=<Teradata TDPID containing the queue table> tvilogger.username=<Teradata username as appropriate for the site> tvilogger.password=<password as appropriate for the site>
Service Control
The Teradata Notification Service is installed as a Windows Service using the name Teradata Notification
Service. The default installation sets the service to automatically start on reboot. You can start and stop the service using the Services Administration tool in Windows.
To ensure the Teradata Notification Service is running, follow these steps:
1. Go to Start > Settings > Control Panel > Administrative Services.
2. Locate the Teradata Notification Service.
3. Ensure the Status column for the service displays Started.
4. In the Name column, double-click Teradata Notification Service.
Teradata Viewpoint Configuration Guide, Release 13.11 40
The Teradata Notification Service Properties dialog box appears.
5. Click OK.
If the Service status is not Started, change it as follows: a. Ensure the Startup type is Automatic, and click Apply. b. Click Start to start the service.
Teradata Viewpoint Configuration Guide, Release 13.11 41
CHAPTER 9
Teradata Manager Feature
Equivalence
Teradata Viewpoint 13.03 or later can be used as a replacement for Teradata Manager. Teradata Manager is not supported for Teradata Databases 13.10 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 13.11 42
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 12.0
Teradata Viewpoint Configuration Guide, Release 13.11 43
4. [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. Remove the following registry keys:
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 13.11 44
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 13.0.1 or later staged systems. To install
this package, see Upgrade to Teradata Viewpoint 13.11.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 Teradata Viewpoint online help.
1. From the Admin menu, click Managed Servers.
2. Click Add a System.
3. Enter 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, enter 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:8088.
6. 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: a. Click Test, located at the bottom of the screen.
If the test fails, check the Teradata Viewpoint log file located at:
/opt/teradata/viewpoint/logs/viewpoint.log
8. Click Apply to save the new managed system.
9. [Optional] Select the Server Enabled checkbox to immediately begin monitoring of the system.
Teradata Viewpoint Configuration Guide, Release 13.11 45
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 have 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.
As of Teradata Viewpoint 13.0.1, any changes made to the LDAP configuration using the Teradata
Viewpoint administration portlet, LDAP Servers, are automatically applied to Teradata Viewpoint. You no longer need to configure LDAP using the server.xml file or restart Teradata Viewpoint to apply LDAP configuration changes.
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.
Teradata Viewpoint Configuration Guide, Release 13.11 46
Definitions
Term Definition
Lightweight
Directory Access
Protocol
(LDAP)
LDAP Data
Interchange
Format (LDIF)
Distinguished
Name (DN)
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. Relatively
Distinguished
Name (RDN)
Common Name
(CN)
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
Bind Used for LDAP authentication, binding is an LDAP operation that authenticates a username and a password.
Service Account 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.
Viewpoint
Authenticator
log4j.xml viewpoint.log
Also referred to simply as the Authenticator, this is the component of Teradata
Viewpoint that runs the authentication process against LDAP, among other actions.
The XML file used to configure Teradata Viewpoint's log output detail. The full path is: VIEWPOINT_DIR/common/classes/log4j.xml.
The file where Teradata Viewpoint logs messages by default.
The full path is: VIEWPOINT_DIR/logs/viewpoint.log.
Teradata Viewpoint Configuration Guide, Release 13.11 47
Before You Begin
LDAP Data Interchange Format (LDIF)
1. Ask the LDAP administrator of the customer 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: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: [joe.customer@acme|mailto: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
... b. At least one other future Teradata Viewpoint customer user, preferably in a different region or country.
Teradata Viewpoint Configuration Guide, Release 13.11 48
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 13.11 49
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 on page 50.
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 3.
2. 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
As of Teradata Viewpoint 13.0.1, Teradata Viewpoint authentication is configured in the LDAP Servers portlet of the Admin menu.
Teradata Viewpoint Configuration Guide, Release 13.11 50
Attribute Description
Basic Configuration
Nickname
Enabled
Url
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.
DN Pattern Bind
Pattern
User Search
Service account DN 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. Service account password
Search pattern The LDAP attribute to match against the presented username when searching for a userentry.
If the cn
attribute is the username, then set to (cn={0}). If the sAMAccountName attribute is the username, then set to ( sAMAccountName={0}
).
Search base
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"
Search extent
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.
Key User Information
LDAP first name attribute
LDAP last name 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).
LDAP email attribute The name of the attribute on the user object that specifies the email address of the user.
Auto-Provisioning
Turn on autoprovisioning
Set to true
to enable auto-provisioning.
Set to false
to disable auto-provisioning.
Automatically assign these roles
When auto-provisioning is enabled, the newly provisioned user is automatically added to these roles. This attribute is often set to
User
.
Default email domain If auto-provisioning is enabled and the email address of the user cannot be determined from
Teradata Viewpoint Configuration Guide, Release 13.11 51
Attribute Description
LDAP, the new user's initial email 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.
Role Mapping Global Settings
Group search base 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.
Group search subtree 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.
Group attribute name 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
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.
2. Enter 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.
Teradata Viewpoint Configuration Guide, Release 13.11 52
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
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: +1 888 555 6789 telephoneNumber: +1 888 555 1232 mail: [email protected] 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
• Type: ATTRIBUTE
• Attribute name: memberOf
• LDAP value: cn=DBA,ou=Groups,dc=acme,dc=com
• Viewpoint role: DBA_ROLE
Teradata Viewpoint Configuration Guide, Release 13.11 53
Example 2
1. 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.
If the Certification Authority (CA) of the LDAP server is not trusted by the Teradata Viewpoint server, use the following procedure to store the CA certificate for the LDAP server into a custom keystore on the Teradata
Viewpoint server.
1. Log on to the Teradata Viewpoint server (Linux) as root
.
2. Install the SSL Certificate by typing the following commands:
$JDK5_64_HOME/bin/keytool -import -alias <your_alias> -keystore
/etc/opt/teradata/viewpoint/certs -trustcacerts -file <
your_certificate_filename
>
3. Enter a password of your choosing.
4. When prompted with the “Trust this certificate? [no]” question, enter, yes.
5. Restart Teradata Viewpoint by typing: /etc/init.d/viewpoint restart.
Teradata Viewpoint Configuration Guide, Release 13.11 54
Refer to the Java keytool command documentation for additional configuration steps and options if necessary: http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html
Enable Debug Logging
If using the new test functionality in the LDAP Servers portlet is not sufficient to troubleshoot a specific LDAP issue, Teradata Viewpoint can be configured to output detailed log information to help diagnose the issue.
You can change back the logging levels when the troubleshooting is complete.
1. Make a copy of log4j.xml. For example: log4j.xml.old.
This file is located at: /opt/teradata/viewpoint/common/classes.
2. Insert the following XML stanzas into log4j.xml. Comment out any similar stanzas, if present.
3. Restart Teradata Viewpoint for the logging changes to take effect.
4. View the log output located at VIEWPOINT_DIR/logs/viewpoint.log, for example:
<!--=======================================================================
LDAP / Authentication
==========================================================================-->
<logger name="com.teradata.viewpoint.security.container.tomcat.authn">
<!-- Set the level value to DEBUG to investigate LDAP/JNDI authentication issues.-->
<level value="DEBUG" />
</logger>
<logger name="com.teradata.viewpoint.security.config.XmlConfigLoader">
<!-- Set the level value to DEBUG to investigate LDAP/JNDI authentication issues.-->
<level value="DEBUG" />
</logger>
<logger name="org.apache.catalina.realm">
<!-- Set the level value to DEBUG to investigate LDAP/JNDI authentication issues.-->
<level value="DEBUG" />
</logger>
<logger name="org.apache.catalina.realm.RealmBase">
<!-- Generally leave this level value at WARN, even when investigating LDAP issues.--
>
<level value="WARN" />
</logger>
Teradata Viewpoint Configuration Guide, Release 13.11 55
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
The Roles Manager portlet allows Teradata Viewpoint Administrators to configure what roles have permission to access 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.
The following are the pre-configured roles in Teradata Viewpoint:
Role Description
Administrator Provides all access to all portlets and Teradata systems.
User Provides access to log on to Teradata Viewpoint. It is recommended that no additional permissions be granted to this role.
TD_SE Teradata Solution Engineer. Provides access to all portlets except certain administrative portlets.
TD_TSS Teradata Technical Support Specialist. Provides access to a limited set of portlets that do not expose any customer sensitive data.
Teradata Viewpoint Configuration Guide, Release 13.11 56
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
Monitor a Managed Server on page 45.
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.
Teradata Viewpoint Configuration Guide, Release 13.11 57
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/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/terad/viewpoint/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 13.11 58
CHAPTER 14
Back Up Teradata Viewpoint Databases
The Teradata Viewpoint DCS automatically creates snapshot dumps of the Teradata Viewpoint databases on a daily basis. The backup process can be managed in the Backup administration portlet. The following options can be specified using this portlet.
Property
Name
Description
Enabled When checked, enables the backup process and unchecked, disables it.
Location The location of the backup files, either on the Teradata Viewpoint server or on a networked file server. The location of the local backup files is always
/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 where the backups will be written.
Note: The
PostgreSQ
L (postgres) user on the Teradata Viewpoint server must have write access to this location.
Backup time The time of day that the backup process begins.
Default
Setting
checked
Local
Retention days
The number of days to keep backups before they are removed.
12:00 AM
(midnight)
7
Teradata Viewpoint Configuration Guide, Release 13.11 59
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 13.11 and Later
The following instructions are for restoring a version of the Teradata Viewpoint database that was backed up in version 13.11.xx.xx. Starting with Teradata Viewpoint 13.11, the backup is performed incrementally for the collected data to improve the overall speed of the backup process.
Because data is collected incrementally, this allows us to restore smaller partitions of data as well. Specifically, you can now choose to restore:
• Configuration data: This restores all data in cam, lportal, td_portal, td_portlets, and all data in dcsdb
except collected data. This option drops the databases and creates them again.
CAUTION:
This option will delete all collected data in dcsdb, as it creates a new dcsdb database.
• Current data: This restores only the current collected data in dcsdb. 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 from previous weeks and months. For example, previous weeks and 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 all data in dcsdb. This option drops the databases and creates them again.
1. Stop all services on all Teradata Viewpoint servers.
/
opt/teradata/viewpoint/bin/vp-control.sh stop
2. If the Teradata Notification Service is running on a Windows server, stop this service.
3. 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> 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 b. In the /opt/teradata/dcs/config/dcs.properties file, change the value of the backup.dir property to /data/restore.
Teradata Viewpoint Configuration Guide, Release 13.11 60
c. Ensure the directory and file permissions within /data/restore are readable by the postgres Linux user.
4. Run the restore script.
• For configuration data:
/opt/teradata/dcs/bin/restore.sh conf
• For current data:
/opt/teradata/dcs/bin/restore.sh curr
• For historical data:
/opt/teradata/dcs/bin/restore.sh hist
• Everything (default):
/opt/teradata/dcs/bin/restore.sh
5. 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 this 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.
6. If the Teradata Notification Service is running on a Windows server, start this service.
7. Start all services on all Teradata Viewpoint servers.
/opt/teradata/viewpoint/bin/vp-control.sh start
Restore a Database from Teradata Viewpoint
Version 13.10 and Earlier
The following instructions are for restoring a version of the Teradata Viewpoint database that was backed up in version 13.10.xx.xx and earlier. In these versions, each database was backed up in a single file. These 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 13.11 61
CHAPTER 16
Change the Session Timeout
The default session timeout in Teradata Viewpoint is 90 minutes.
To check the session timeout value, run:
/opt/teradata/viewpoint/bin/vpadmin.sh –t
To set the session timeout, run (where
[timeout]
is the wanted timeout value):
/opt/teradata/viewpoint/bin/vpadmin.sh –T [timeout]
The maximum recommended timeout is 1440 (1 day).
Teradata Viewpoint Configuration Guide, Release 13.11 62
CHAPTER 17
Set the Default Locale
The default locale in Teradata Viewpoint is en_US. To check the default locale value, run:
/opt/teradata/viewpoint/bin/vpadmin.sh –l
To set the default locale, run (where [localecode] is a valid locale code):
/opt/teradata/viewpoint/bin/vpadmin.sh –L [locale]
Changing the default locale affects all Teradata Viewpoint users who have not explicitly set a locale in their user profile.
The valid locale codes are as follows:
Locale Code Language/Country
en_US en_GB
English US
English UK
fr_FR
de_DE
ja_JP
ko_KR
French
German
Japanese
Korean
Teradata Viewpoint Configuration Guide, Release 13.11 63
CHAPTER 18
Reset the Admin User Password
If you ever forget the Teradata Viewpoint admin user password, reset it to teradata by running the following command:
/opt/teradata/viewpoint/bin/vpadmin.sh –R
Teradata Viewpoint Configuration Guide, Release 13.11 64
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 on page 82.
Incoming Ports
• 22 (SSH)
• 80 (HTTP)
• 443 (HTTPS)
• 5432 (Cache Database)
• 8888 (optional for monitoring Teradata Viewpoint server – tmsmonitor)
• 22000-22021 (only required for clustering)
• 61616 (optional for Teradata Alerting)
Outgoing Ports
• 389 (optional for LDAP authentication
• 1025 (JDBC)
• 8888 (optional for monitoring Teradata Managed Servers - tmsmonitor)
• 22000-22021 (only required for clustering)
Teradata Viewpoint Configuration Guide, Release 13.11 65
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
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. Enter 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 13.11 66
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 between the servers needs to be in sync.
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 13.11 67
CHAPTER 22
Teradata Viewpoint Clustering
Starting with Teradata Viewpoint 13.0.1, multiple Teradata Viewpoint servers can be clustered together for purposes of 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
• Creating a Teradata Viewpoint Cluster
• Adding Additional Teradata Viewpoint Servers to the Cluster
• Configuring Teradata Notification Service for Windows with Teradata Viewpoint clustering
• Promoting the Standby Cache Database
• Upgrading PostgreSQL to Enable Clustering
• Additional Considerations
Cluster Configurations
This topic contains the supported Teradata Viewpoint cluster configurations. This includes:
• High Availability configuration
• High Usage configuration
• Advanced configuration
Teradata Viewpoint Configuration Guide, Release 13.11 68
High Availability Configuration: Two Teradata Viewpoint Servers
This is the base configuration for customers that want to set up 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 if 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 takes over data collection when the active DCS goes down. The Teradata Viewpoint servers share a distributed cache so the state between the Teradata Viewpoint portals remains consistent.
High Usage Configuration: Three or More Teradata Viewpoint Servers
This configuration extends the High Availability configuration to allow Teradata Viewpoint to scale to thousands of concurrent users by adding Teradata Viewpoint servers to the cluster. These added Teradata Viewpoint servers only run the Teradata Viewpoint portal and not the DCS or cache database. Instead, they point to the clusterwide cache database to access users, permissions, preferences, and collected data. The two additional Teradata
Viewpoint servers shown in the following diagram are marked optional as they are not required for high availability. Even though these added 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.
Teradata Viewpoint Configuration Guide, Release 13.11 69
Advanced Configuration: Three or More Teradata Viewpoint Servers with
Dedicated Cache Database Server
This configuration is for customers that require better cache database performance because of high use or because multiple large/high use Teradata systems are being monitored.
In this configuration, the Teradata Viewpoint portal is not run on the same machine as the active cache database.
This provides the cache database more system resources.
Failure Scenarios
Data Collection Service (DCS) Failure (Scenario 1)
If the active DCS goes down, the standby DCS automatically takes over data collection and logs an error to TVI and optionally sends out an email. When the standby DCS detects the active DCS is back online, it stops data collection and continues to operate in standby mode.
Teradata Viewpoint Configuration Guide, Release 13.11 70
Cache Database Failure (Scenario 2)
If the DCS detects that the active cache database is down, the DCS logs an error to TVI and optionally sends out an email. 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 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
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.
Active Teradata Viewpoint Server Failure
This failover scenario is the 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 email. 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
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.
Teradata Viewpoint Configuration Guide, Release 13.11 71
Create a Teradata Viewpoint Cluster
This topic describes how to create a Teradata Viewpoint cluster. Two Teradata Viewpoint servers are required.
One is configured with the active cache database and the other is configured with the standby cache database. To add additional Teradata Viewpoint servers to the cluster, see Add Additional Teradata Viewpoint Servers to the
Cluster on page 77.
on page 82.
System Preparation
1. Ensure the Teradata Viewpoint software version installed on both servers. Ensure the installed versions are the same and that the version installed is at least 13.0.1.
If the version numbers are not the same or the installed version is less than 13.0.1, upgrade the servers to
2. Verify the PostgreSQL version compatibility.
Teradata Viewpoint servers staged before the Teradata Viewpoint 13.0.1 release have an older version of
PostgreSQL installed that is incompatible with clustering.
Creating a cluster requires PostgreSQL 8.3.5 be installed on both servers. a. To check the version number of a running PostgreSQL instance, use the following commands: su postgres psql
3. Determine which server is going to host the active cache database and which one 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.
4. Configure NTP time synchronization. See Configure NTP Time Synchronization on page 67.
Set Up Cluster Configuration Files
1. On both servers, copy cluster configuration files to /etc/opt/teradata/viewpoint/ by typing the following commands: cp /opt/teradata/dcs/config/local.cluster.properties
/etc/opt/teradata/viewpoint/ cp /opt/teradata/dcs/config/distributed.cluster.properties
/etc/opt/teradata/viewpoint/ cp /opt/teradata/dcs/config/cluster-protocol-stacks.xml
/etc/opt/teradata/viewpoint/
2. Ensure the owner of the distributed.cluster.properties file is the postgres user. chown postgres /etc/opt/teradata/viewpoint
Teradata Viewpoint Configuration Guide, Release 13.11 72
3. Ensure the file permissions on the copied files and their parent directory, are readable by everyone. chmod 755 /etc/opt/teradata/viewpoint chmod 744 /etc/opt/teradata/viewpoint/*
4. Edit /etc/opt/teradata/viewpoint/distributed.cluster.properties on both servers. a. Set the value of the active.database.host property to the host name or IP address of the active cache database server. b. Set the value of the standby.database.host to the host name or IP address of the standby cache database server.
For example: active.database.host=viewpoint1 standby.database.host=viewpoint2
Note:
You can inspect the contents of the distributed.cluster.properties file at any time to determine which cache database server is currently the active server and which is the standby server.
5. Edit /etc/opt/teradata/viewpoint/local.cluster.properties on both servers. a. Set the value of the cluster.hosts property equal to the host name or IP address of both Teradata
Viewpoint servers separated by a comma. If enabling host authentication (see Additional Cluster
For example: cluster.hosts=viewpoint1,viewpoint2 b. Set the value of the tcp.bind_addr property equal to the public IP address of the host where the file resides. This is the IP address that other servers in the cluster use to connect to this host. Do not set the
IP address to a private server management IP address.
For example: tcp.bind_addr=192.168.0.1
6. Test the cluster configuration. a. Run /opt/teradata/dcs/bin/clustertest.sh on both servers. This command reads in data from the console. b. Enter console input and ensure that when Enter is pressed, the text appears on the other server’s console. c. Enter text on both servers and ensure it appears on the other server when Enter is pressed. If this does not work, ensure that the cluster.hosts property in the configuration
/etc/opt/teradata/viewpoint/local.cluster.properties was set correctly. d. To enable more debug information, set the cluster.debug.enabled property to true in
/etc/opt/teradata/viewpoint/local.cluster.properties and run /opt/teradata/dcs/bin/clustertest.sh again. e. Press Ctrl+D on each console to exit.
7. After the test succeeds of the cluster configuration: a. Edit /etc/opt/teradata/viewpoint/local.cluster.properties on both servers.
Teradata Viewpoint Configuration Guide, Release 13.11 73
b. Set the cluster.enabled property to true.
Server Requirements on page 11.
Note:
All of the Teradata Viewpoint services listed under Start and Stop Teradata Viewpoint
Services on page 12 must be running on both servers with the exception of Teradata
Alerting services (Alert Service and Messaging Service). Teradata Alerting services can be
clustered as shown in Teradata Alerting Clustering on page 86. This is separate from
Teradata Viewpoint clustering. If Teradata Viewpoint is clustered and Teradata Alerting is not, only one Teradata Alerting Alert Service and one Teradata Messaging Service can be running.
Stop and disable the Teradata Alerting service on the standby server typing the following commands:
/etc/init.d/camalert stop
/etc/init.d/camactivemq stop chkconfig camalert off chkconfig camactivemq off
Enable PostgreSQL Replication
1. Enable public-key authentication for the postgres user between both servers. On each server, perform the following commands: a. Become the postgres user by typing the following commands: cd /data su postgres b. Generate a public/private key pair: ssh-keygen -t rsa c. Press Enter three times to accept the defaults. d. Copy public key to alternate server by replacing [host] with an alternate server’s host name by typing the following command. Note that the command must be typed on a single line: scp /var/lib/pgsql/.ssh/id_rsa.pub root@[host]:/var/lib/pgsql/.ssh/authorized_keys e. Accept alternate servers’ authenticity by typing yes and press Enter. f. Enter root password for alternate server. g. Test public-key authentication by replacing [host] with an alternate server’s host name by typing: ssh [host] h. Verify the above command logged on to the alternate host without requiring a password.
•
If that does not work, check the file permissions on the /var/lib/pgsql/.ssh/authorized_keys file on the remote host by typing: chmod 744 /var/lib/pgsql/.ssh/authorized_keys
•
Ensure the file is readable by all.
i. Exit from ssh: exit
Teradata Viewpoint Configuration Guide, Release 13.11 74
j. Exit postgres user: exit
2. Prepare the standby cache database server. The standby cache database server is the one that is being added to the cluster and does not contain the current configuration data and collected data.
CAUTION: Only run the following command on the standby cache database server and NOT on the
active cache database server. Otherwise you will lose all your data! a. Stop PostgreSQL by typing:
/etc/init.d/postgresql stop b. Delete existing data on the standby cache database server: rm -rf /data/postgresql/* rm -rf /data/archive/*
3. On the active cache database server, enable WAL archiving. a. Edit /data/postgresql/postgresql.conf and look for the WRITE AHEAD LOG section:
• Set archive_mode = on and remove "#" comment from beginning of line.
• Set archive_command = '/opt/teradata/dcs/bin/archive.sh %p %f' and remove "#" comment from beginning of line.
• Set archive_timeout = 60 and remove "#" comment from beginning of line. b. Restart postgresql:
/etc/init.d/postgresql restart
4. Ensure the active cache database server WAL logs are being sent to the standby cache database server's
/data/archive folder. a. On the standby cache database, type: ls /data/archive
Files are copied and displayed (with names such as “000000010000000000000000"). b. Open the PostgreSQL log file for the active cache database server located at, where DAY is the current day of the week:
/data/postgresql/pg_log/postgresql.log.DAY c. Look for archive-related errors.
5. Create a base backup of the active cache database on standby cache database server. a. On the active cache database, start the base backup: cd /data su postgres psql
SELECT pg_start_backup('viewpoint');
\q exit b. Copy cache database on active cache database server to standby cache database server. This could take some time, depending on the size of the database.
Teradata Viewpoint Configuration Guide, Release 13.11 75
The rsync command below can be cancelled and restarted at any time; it starts transferring the database where it left off. Replace the [host] value with the standby cache database server [host] name. Note that the rsync through /data/postgresql code must be typed on a single line. cd /data su postgres rsync -avtrz --exclude=pg_xlog/* -e ssh /data/postgresql/
[host]:/data/postgresql exit c. On the active cache database, stop the base backup: cd /data su postgres psql
SELECT pg_stop_backup();
\q exit
6. Start standby cache database in recovery mode. All the following commands must be performed on the standby cache database server. a. On the standby cache database server, set up the recovery configuration file: rm -f /data/postgresql/recovery.done cp /opt/teradata/dcs/config/recovery.conf /data/postgresql/ cp /opt/teradata/dcs/bin/recover.sh /data/postgresql/ b. Ensure the file permissions on the copied files are readable, and that the postgres user is able run them. chmod 744 /data/postgresql/recovery.conf chmod 755 /data/postgresql/recover.sh c. Modify the PostgreSQL init script to not wait for start up.
• Open /etc/init.d/postgresql and remove the -w option from where pg_ctl start is called. d. Disable WAL archiving.
• Open /data/postgresql/postgresql.conf and look for the WRITE AHEAD LOG section.
• Set archive_mode to off. e. Start postgresql:
/etc/init.d/postgresql start f. Open the Postgresql log file for the standby cache database server located at, where DAY is the current day of the week:
/data/postgresql/pg_log/postgresql.log.DAY g. Look for errors. h. Ensure the WAL log files are being restored.
Look for output similar to the following:
Trigger file : /data/postgresql/active
Waiting for WAL file : 000000010000001000000013
WAL file path : /data/archive/000000010000001000000013
Teradata Viewpoint Configuration Guide, Release 13.11 76
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 5 seconds
Max wait interval : 0 forever
Command for restore : ln -s -f
"/data/archive/000000010000001000000013" "pg_xlog/RECOVERYXLOG"
Keep archive history : 000000010000001000000010 and later
If the WAL log files are being restored, then PostgreSQL replication has been configured correctly. i. If using SSL for PostgreSQL connections on the active cache database, follow step 3 in the Cluster
Security section for the new standby cache database. See Cluster Security on page 83.
The creation of a Teradata Viewpoint cluster is now complete. See the next section to add additional Teradata
options.
Add Additional Teradata Viewpoint Servers to the Cluster
After a cluster has been configured with an active and a standby cache database, additional Teradata Viewpoint servers can be added to the cluster to support a growing number of end users.
1. On the server being added to the cluster, stop and disable the DCS by typing the following commands:
/etc/init.d/dcs stop chkconfig dcs off
The DCS runs only on the servers hosting the active and standby cache databases.
2. If the server being added to the cluster is not the active or standby host of a Teradata Alerting cluster, stop and disable the Teradata Alerting Alert Service and the Teradata Alerting Message Service by typing the following commands:
/etc/init.d/camalert stop
/etc/init.d/camactivemq stop chkconfig camalert off chkconfig camactivemq off
3. On each existing server in the cluster, edit /etc/opt/teradata/viewpoint/local.cluster.properties and append a comma to the cluster.hosts property followed by the host names or IP address of the Teradata Viewpoint server being added. If using host authentication (see
Additional Cluster Considerations on page 82)
,
specify the IP address and not the host name.
4. Copy the current cluster configuration from another Teradata Viewpoint server in the cluster. Replace the
[host] value in the following command with the host name or IP address of an existing Teradata Viewpoint server in the cluster. When prompted, enter the root password for the specified host. scp root@[host]:/etc/opt/teradata/viewpoint/*
/etc/opt/teradata/viewpoint /
5. Edit /etc/opt/teradata/viewpoint/local.cluster.properties on the new server.
Set the value of the tcp.bind_addr property equal to the public IP address of the host where the file resides.
This is the IP address that other servers in the cluster use to connect to this host. Do not set the IP address to a private server management IP address.
Teradata Viewpoint Configuration Guide, Release 13.11 77
For example: tcp.bind_addr=192.168.0.1
6. Test communication with the rest of the cluster. a. Run /opt/teradata/dcs/bin/clustertest.sh on all the servers in the cluster. This command reads in data from the console. b. Enter console input and ensure that when Enter is pressed, the text appears on the other server’s console. c. Enter text on each server and ensure it appears on the other servers console when Enter is pressed. If this is does not work, ensure the cluster.hosts property is set correctly. in /etc/opt/teradata/viewpoint/
local.cluster.properties. d.
To enable more debug information, set the cluster.debug.enabled property in
/etc/opt/teradata/viewpoint/local.cluster.properties to true and run
/opt/teradata/dcs/bin/clustertest.sh again. e. Press Ctrl+D on each console to exit.
7. Restart the Teradata Viewpoint portal on the newly configured server.
Configure Teradata Notification Service for
Windows with Teradata Viewpoint Cluster
To use BTEQ and Run a program alert actions, install Teradata Notification Service on a Windows server.
Refer to Install Teradata Notification Service for Windows on page 38, for details.
Teradata Notification Service accesses the Teradata Viewpoint database cache on a Teradata Viewpoint server.
Only one Teradata Notification Service can be run with a Teradata Viewpoint cluster. Perform the following steps on the Windows server to ensure this Notification Service will be connected to the active database cache. When a database cache promotion occurs, the Teradata Notification Service will be automatically re-connected to the new active database cache.
Set Up Teradata Viewpoint Cluster Configuration Files
1. Create the root folder [c:]\etc\opt\teradata\viewpoint
2.
Remote copy the following Teradata Viewpoint cluster configuration files from the
/etc/opt/teradata/viewpoint
directory of the active Viewpoint server to the folder created in step
1 above: distributed.cluster.properties local.cluster.properties cluster-protocol-stacks.xml
Note:
You can inspect the contents of the distributed.cluster.properties file at any time to determine which Teradata Viewpoint server is currently the active server and which is the standby server.
Teradata Viewpoint Configuration Guide, Release 13.11 78
3. Edit the [c:]\etc\opt\teradata\viewpoint\local.cluster.properties file as follows: a. Set the value of the tcp.bind_addr property equal to the public IP address of the local host. This is the IP address that the other server in the cluster uses to connect to this host. Do not set the IP address to a private server management IP address.
For example: tcp.bind_addr=192.168.0.3
4. Edit the
[
Install Folder]\Teradata\Client\13.10\Teradata Notification
Service\config\cam-db.properties
file as follows: a. Comment out the current cam.db.host line. b. Add or uncomment the following line: cam.db.host=%{activeDatabaseHost}
Viewpoint cluster.
Promote the Standby Cache Database
In situations where the active cache database goes down and cannot easily be restarted, 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 starts using the newly promoted cache database.
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/dcs/bin/promote.sh
After the script completes, Teradata Viewpoint is available again. After the promotion, the follow maintenance tasks must be performed.
1. Modify the PostgreSQL init script on the newly promoted server to wait for start up. a. Open /etc/init.d/postgresql b. Add the -w option to the pg_ctl start command on line 131 as follows: pg_ctl start -s -w -p $H -D $DATADIR -o "\"$OPTIONS\""
database. This can be done on the server that was previously hosting the active cache database or on an additional Teradata Viewpoint server.
3. If the standby server was set up on an additional Teradata Viewpoint server already in the cluster, re-enable and start the DCS by typing the following commands: chkconfig dcs on
/etc/init.d/dcs start
4. If the cluster was set up using the Advanced configuration, disable the Teradata Viewpoint portal on the newly promoted cache database host:
/etc/init.d/viewpoint stop chkconfig viewpoint off
Teradata Viewpoint Configuration Guide, Release 13.11 79
5. If the standby server was set up on an additional Teradata Viewpoint server already in the cluster, and
Teradata Alerting clustering was not used, re-enable and start Teradata Alerting services (Alert Service and
Messaging Service) by typing h following commands: chkconfig camalert on chkconfig camactivemq on
/etc/init.d/camaltert start
/etc/init.d/camactivemq start
6. If Teradata Alerting clustering is not used, stop and disable the Teradata Alerting services (Alert Service and
Messaging Service) on the old active database cache host by typing the following commands:
/etc/init.d/camalert stop
/etc/init.d/camactivemq stop chkconfig camalert off chkconfig camactivemq off
Upgrade PostgreSQL to Enable Clustering
Creating a Teradata Viewpoint cluster requires installing PostgreSQL 8.3.5 on the Teradata Viewpoint servers hosting the active and standby cache databases.
Teradata Viewpoint servers staged prior to the release of Teradata Viewpoint 13.0.1 have an older version of
PostgreSQL installed that is not compatible with clustering so the PostgreSQL databases on these servers need to be upgraded.
If the server being upgraded has pre-existing data on it that is used to seed the cluster’s active cache database, this
The destination server must be a properly staged Teradata Viewpoint server with PostgreSQL 8.3.5 installed. Do not upgrade the version of PostgreSQL on the source server until the data migration is complete.
Migrate Pre-Existing Data
This procedure can take a couple of days, depending on how much data has been collected. As a shortcut, skip the DCS collected data migration and only migrate the Teradata Viewpoint users, roles, permissions, preferences, and configuration. Skipping the migration of DCS data makes the migration process relatively quick.
1. Ensure the source and destination servers have the same version of Teradata Viewpoint installed. If the source server has an older version of Teradata Viewpoint installed, upgrade the Teradata Viewpoint software on the source server before continuing with the data migration.
2. On the source server, edit /data/postgresql/pg_hba.conf to allow access from the destination server by adding the following line (replace [IP ADDRESS] with the IP address of the destination server): host all postgres [IP ADDRESS]/32 trust
Note: If it is not the first entry in the pg_hba.conf file, the migration fails.
3. Reload postgresql configuration on the source server by typing:
/etc/init.d/postgresql reload
4. Ensure the Teradata Viewpoint portal and DCS are stopped on the destination server.
Teradata Viewpoint Configuration Guide, Release 13.11 80
5. On the destination server, migrate all of the configuration data from the source server by typing the following command (replace [SOURCE] with the IP address or hostname of the source server):
/opt/teradata/dcs/bin/migrateconfig.sh [SOURCE]
6. On the destination server, run the DCS database setup script:
/opt/teradata/dcs/bin/setupdb.sh
7. Start the Teradata Viewpoint portal and DCS.
Note: If continuing on with the next step, the portal might be slow to function as the data is loaded. During the data migration, historical data slowly starts to appear.
8. [Optional] On the destination server, migrate all of the performance and monitoring data collected by the
DCS on the source server by typing the following command (replace [SOURCE] with the IP address or the hostname of the source server):
/opt/teradata/dcs/bin/migratedata.sh [SOURCE]
Depending on how much data has been collected, this could take a couple of days. You can safely ignore any warnings during the restore.
Upgrade to PostgreSQL 8.3.5
1. Ensure postgresql is stopped by typing:
/etc/init.d/postgresql stop
2. Uninstall postgresql-server: rpm –e postgresql-server
3. Uninstall postgresql: rpm –e postgresql
4. Uninstall postgresql-libs: rpm –e postgresql-libs
5. Obtain the postgresql 8.3.5 packages from one of the following sources:
• Copy packages from Teradata Viewpoint – Open Source Install Packages CD.
• Download packages from the
Teradata Software Server . The Teradata Software Server can be accessed from Teradata @Your Service (log on and click the Teradata Software Server link).
From the downloaded packages: a. Select Certified Configs. b. From the menu on the left, select Software Patches>Teradata Applications. c. Select Sub Category Teradata Viewpoint and Release 13.0.1. d. Click Submit. e. Select the packages specified below and enter the required fields.
Teradata Viewpoint Configuration Guide, Release 13.11 81
The postgresql package includes:
• postgresql-8.3.5-2.1.x86_64.rpm
• postgresql-libs-8.3.5-2.1.x86_64.rpm
• postgresql-server-8.3.5-2.1.x86_64.rpm
• postgresql-contrib-8.3.5-2.1.x86_64.rpm f. Click Submit to download. g. Extract the PostgreSQL packages from the downloaded archive.
6. Install the following postgresql packages:
• rpm -ivh postgresql-libs-8.3.5-2.1.x86_64.rpm
• rpm –ivh postgresql-8.3.5-2.1.x86_64.rpm
• rpm –ivh postgresql-server-8.3.5-2.1.x86_64.rpm
• rpm –ivh postgresql-contrib-8.3.5-2.1.x86_64.rpm
7. From the command prompt, type: chkconfig postgresql on
8. Follow the steps in Create a Teradata Viewpoint Cluster on page 72.
Additional Cluster Considerations
LAN or WAN
The recommended setup of a Teradata Viewpoint cluster is that all cluster members be located on the same LAN.
A Teradata Viewpoint cluster can be set up over a WAN, but a minimum of 16MB of data is transferred between the active cache database and standby cache database every minute. This amounts to about 23GB a day. 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>000000 0 0 /data
The setquota command is available only on staged 13.02 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.
Teradata Viewpoint Configuration Guide, Release 13.11 82
Cluster Security
Encryption and authentication between the hosts in the Teradata Viewpoint cluster is disabled, by default.
To encrypt all communication between hosts in a cluster and restrict the hosts able to join a cluster:
1. Stop all Teradata Viewpoint portals and DCS in the cluster.
2. Enable encryption for messages sent between the hosts in the cluster. a. Open the following file on every server in the cluster:
/etc/opt/teradata/viewpoint/c;uster-protocol-stacks.xml b. Uncomment the following line:
<!-- ENCRYPT encrypt_entire_message="true" sym_init="128"
sym_algorithm="AES/ECB/PKCS5Padding" asym_init="512"
asym_algorithm="RSA" /-->
3. Enable SSL access to the cache database by running the following commands on the Teradata Viewpoint server hosting the active cache database and the standby cache database: a. Change to the postgresql directory: cd /data/postgresql b. Assume the postgres user: su postgres c. Generate a certificate signing request: openssl req –new –text –out server.req d. Enter a PEM pass phrase. It can be anything, but must be at least four characters in length. e. Press Enter to the rest of the questions. There is no need to enter input. f. Generate the server key: openssl rsa –in privkey.pem –out server.key g. Enter the same pass phrase as above. h. Remove privkey.rpm: rm privkey.pem i. Create the certificate: openssl req –x509 –in server.req –text –key server.key –out server.crt j. Change the permissions on the key: chmod og-rwx server.key k. Open and edit /data/postgresql/postgresql.conf and change the line from #ssl = off to ssl = on.
Teradata Viewpoint Configuration Guide, Release 13.11 83
l. Exit postgres user: exit m. Restart postgresql:
/etc/init.d/postgresql restart
4. Enable the use of SSL when Teradata Viewpoint or the DCS connects to the active cache database. a. Open the following file on every server in the cluster.
/etc/opt/teradata/viewpoint/local.cluster.properties
5. Uncomment the following line:
#jdbc.options=ssl\=true&sslfactory\=org.postgresql.ssl.
NonValidatingFactory
6. Enable host authentication to prevent unknown hosts from joining the cluster. a. Open the following file on every server in the cluster:
/etc/opt/teradata/viewpoint/cluster-protocols-stacks.xml b. Uncomment the following line:
<!-- AUTH auth_class="org.jgroups.auth.FixedMembershipToken"
fixed_members_value="${cluster.hosts}" fixed_members_seperator=","
/-->
To enable cluster authentication, the cluster.hosts property in
/etc/opt/teradata/viewpoint/local.cluster.properties must only contain IP addresses and not host names.
7. Test cluster communication with security enabled. a. Run /opt/teradata/dcs/bin/clustertest.sh on all the servers in the cluster. This command reads in data from the
console. b. Enter console input and ensure that when Enter is pressed, the text appears on the other server’s console. c. Enter text on each server and ensure it appears on the other server’s console when Enter is pressed. If this does not work, ensure the cluster.hosts property in /etc/opt/teradata/viewpoint/ local.cluster.properties with the correct IP addresses. d. To enable more debug information, set the cluster.debug.enabled property to true and run
/opt/teradata/dcs/bin/clustertest.sh again. e. Press Ctrl+D on each console to exit.
8. After the cluster communication test succeeds, restart all Teradata Viewpoint portals and DCS in the cluster.
Teradata Viewpoint Configuration Guide, Release 13.11 84
Getting Notifications of Failures
When Teradata Viewpoint detects a failure has occurred that requires the attention of a Teradata Viewpoint administrator, an email can be sent out to a configured list of recipients. Emails 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.
1. To configure email 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 email alerting.
• alert.smtpHost - The hostname of the SMTP server is used to send emails.
• alert.fromAddress – [Optional] Set the return address that appears in the email.
• alert.recipients – A comma-separated list of the email 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 30 seconds, restart the DCS.
An email is sent for the active DCS going down and another one for the active DCS recovering. The standby DCS must be up and running for the alerts to be sent.
Ports Used for Clustering
Besides the normal ports required by Teradata Viewpoint, a Teradata Viewpoint cluster uses the ports in the range 22000 to 22010 for cluster communications.
Load Balancing
To make all Teradata Viewpoint portals in a cluster appear as a single host and to protect end-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 13.11 85
CHAPTER 23
Teradata Alerting Clustering
Teradata Alerting Services run on a Teradata Viewpoint server and include the Messaging Service and the Alert
Service. Starting with release 13.11, these services can be run on a cluster of two servers to provide high availability. One server is designated as the active server, and the other one the standby. This topic covers:
• Cluster Configuration
• Failure Scenarios
• Creating a Teradata Alerting Cluster
• Configuring Teradata Notification Service for Windows with Teradata Alerting clustering
• Replacing a Teradata Alerting Server in the Cluster
• Promoting the Standby Messaging Service
• Additional Considerations
Alerting Cluster Configurations
This is the base configuration for customers that want to set up a Teradata Alerting cluster.
The following diagram shows two Teradata Viewpoint servers configured in a Teradata Alerting cluster. An active
Alert Service runs on the same server as the active Messaging Service. The other server contains the standby
Messaging Service and Alert Service that will take over when their active counterpart goes down.
Note:
For simplicity, the Teradata Viewpoint Portal and Teradata Viewpoint Portal Distributed
Cache component of the Teradata Viewpoint server are omitted from the Teradata
Alerting cluster diagrams. They are not relevant to the operations of a Teradata Alerting cluster.
Teradata Viewpoint Configuration Guide, Release 13.11 86
Failure Scenarios
Alert Service Failure (Scenario 1)
If the active Alert Service goes down, the standby Alert Service automatically takes over the active role and logs an error to TVI. When the standby Alert Service detects the active Alert Service is back online, it relinquishes the active role, and reverts to operate in standby mode.
Teradata Viewpoint Configuration Guide, Release 13.11 87
Messaging Service Failure (Scenario 2)
If the active Messaging Services goes down, and the problem is not trivial to solve, the System Administrator can promote the standby Messaging Service. Promoting the standby Messaging Service makes the standby Messaging
Service become the active Messaging Service. The promotion is broadcasted to all Teradata Viewpoint servers and they are automatically redirected to use the new Messaging Service. The old active Messaging Service becomes the standby. The active and standby Alert Service automatically switch roles.
DCS Failure (Scenario 3)
If the active DCS goes down, the standby DCS automatically takes over and establish a connection with the active
Messaging Service. Alert Service will not be affected by this failure.
Teradata Viewpoint Configuration Guide, Release 13.11 88
Cache Database Failure (Scenario 4)
If the active cache database goes down, the System Administrator can promote the standby cache database. Alert
Service will be automatically redirected to the new active database cache.
Upon cache database failure, independent Promotion of the Messaging Service is recommended as to reduce network traffic.
Active Teradata Alerting Server Failure (Scenario 5)
This failover scenario is the combination of all the above scenarios.
The standby Alert Service automatically takes over the active role and logs an error to TVI. The standby
Messaging Service will not automatically resume the active role. If the server failure problem is not trivial to solve, the System Administrator can promote the standby Messaging Service. The promotion is broadcasted to all
Teradata Viewpoint servers so that they are automatically redirected to use the new Messaging Service at which point the old active Messaging Service becomes the standby. The Alert Service running on the same server as the promoted Messaging Service will be the active service, and the one running on the other server will become the standby.
Note:
The following diagram assumes the standby cache DB has also been promoted. This can be done independently of the Messaging Service promotion.
Teradata Viewpoint Configuration Guide, Release 13.11 89
Create a Teradata Alerting Cluster
This topic describes how to create a Teradata Alerting cluster. Two Teradata Viewpoint servers are required. One is configured with the active Teradata Alerting services and the other is configured with the standby Teradata
Alerting services. These include the Messaging Service and the Alert Service.
Note:
Teradata Alerting services will be installed on all Teradata Viewpoint servers, but a
Teradata Alerting cluster will include only two Teradata Viewpoint servers at any one time. Also a Teradata Alerting cluster operates separately from the Teradata Viewpoint cluster. That is, the active server for the Teradata Alerting cluster needs not be the same as the active server for the Teradata Viewpoint cluster.
Before you proceed with Teradata Alerting clustering configuration, review
Additional Alerting Considerations on page 94.
System Preparation
1. Ensure the Teradata Viewpoint and Teradata Alerting software version installed on both servers. Ensure the installed versions are the same and the version installed is at least 13.11.0
If the version numbers are not the same or the installed version is less than 13.11.0, upgrade the servers to
and Teradata Alerting
versions on all servers in a Teradata Alerting cluster must be identical.
2.
Determine which server is going to host the active Teradata Alerting Messaging Service and which one is going to host the standby Messaging Service. Make sure Teradata Alerting services are enabled on these servers by typing the following commands on each server: chkconfig camactivemq on chkconfig camalert on
3. Configure NTP time synchronization. See Configure NTP Time Synchronization on page 67.
Teradata Viewpoint Configuration Guide, Release 13.11 90
Set Up Teradata Alerting Cluster Configuration Files
1.
On both servers, copy cluster configuration files to /etc/opt/teradata/cam/
by typing the following commands:
cp /opt/teradata/cam/alert/config/amq.distributed.cluster.properties
/etc/opt/teradata/cam/ cp /opt/teradata/cam/alert/config/amq.local.cluster.properties
/etc/opt/teradata/cam/ cp /opt/teradata/cam/alert/config/cluster-protocol-stacks.xml
/etc/opt/teradata/cam/
2. Ensure the file permissions on the copied files and their parent directory are readable by everyone. chmod 744 /etc/opt/teradata/cam chmod 744 /etc/opt/teradata/cam/*
3. Edit /etc/opt/teradata/cam/amq.distributed.cluster.properties on both servers. a. Set the value of the active.amq.host property to the host name or IP address of the active Messaging
Service server. b. Set the value of the standby.amq.host to the host name or IP address of the standby Messaging Service server.
For example: active.amq.host=viewpoint1 standby.amq.host=viewpoint
2
Note:
You can inspect the contents of the amq.distributed.cluster.properties file at any time to determine which Messaging Service server is currently the active server and which is the standby server.
4. Edit /etc/opt/teradata/cam/amq.local.cluster.properties on both servers. a. Set the value of the cluster.hosts property equal to the host names or IP addresses of both Teradata
Alerting servers separated by a comma. If enabling host authentication (see Additional Alerting
Considerations
on page 94), the cluster.hosts property must only include IP addresses and not host names.
For example: cluster.hosts=viewpoint1,viewpoint2 b. Set the value of the tcp.bind_addr property equal to the public IP address of the host where the file resides. This is the IP address that the other server in the cluster uses to connect to this host. Do not set the IP address to a private server management IP address.
For example: tcp.bind_addr=192.168.0.1
5. Test the cluster configuration. a. Run /opt/teradata/cam/alert/bin/amq.clustertest.sh on both servers. This command reads in data from the console.
Teradata Viewpoint Configuration Guide, Release 13.11 91
b. Enter console input and ensure that when Enter is pressed, the text appears on the other server’s console. c. Enter text on both servers and ensure it appears on the other server when Enter is pressed. If this does not work, ensure the cluster.hosts property configuration again in
/etc/opt/teradata/cam/amq.local.cluster.properties was set correctly. d. To enable more debug information, set the cluster.debug.enabled property to true in
/etc/opt/teradata/cam/amq.local.cluster.properties and run /opt/teradata/cam/alert/bin/amq.clustertest.sh again. e. Press Ctrl+ D on each console to exit.
6. After the test succeeds of the cluster configuration: a. Edit /etc/opt/teradata/cam/amq.local.cluster.properties on both servers. b. Set the cluster.enabled property to true.
7. Restart all of the Teradata Viewpoint services.
Note:
If Teradata Viewpoint is not clustered, identical Alert Actions must be created on both
Teradata Viewpoint servers
Configure Teradata Notification Service for Windows with Teradata
Alerting Cluster
To be able to use BTEQ and Run a Program alert actions, Teradata Notification Service must be installed on a
Windows server. Refer to Install Teradata Notification Service for Windows on page 38 for details.
Teradata Notification Service connects to Teradata Messaging Service. Only one Teradata Notification Service can be run with a Teradata Alerting cluster. Perform the following setup on the Windows server to ensure this service will be connected to the active Messaging Service. When a Teradata Alerting Messaging Service promotion occurs, the Teradata Notification Service will be automatically re-connected to the new active Messaging Service
Set Up Teradata Alerting Cluster Configuration Files
1. Create the root folder [c:]\etc\opt\teradata\cam
2.
Copy cluster configuration files from the local config to the above folder
by typing the following commands:
copy [
Install Folder]\Teradata\Client\13.10\Teradata Notification
Service\
config\amq.distributed.cluster.properties [c:]\etc\opt\teradata\cam\ copy [
Install Folder]\Teradata\Client\13.10\Teradata Notification
Service\
config\amq.local.cluster.properties [c:]\etc\opt\teradata\cam\ copy [
Install Folder]\Teradata\Client\13.10\Teradata Notification
Service\
config\cluster-protocol-stacks.xml [c:]\etc\opt\teradata\cam\
3. Edit the [c:]\etc\opt\teradata\cam\amq.distributed.cluster.properties file as follows: a. Set the value of the active.amq.host property to the host name or IP address of the active Messaging
Service server.
Teradata Viewpoint Configuration Guide, Release 13.11 92
b. Set the value of the standby.amq.host to the host name or IP address of the standby Messaging Service server.
For example: active.amq.host=viewpoint1 standby.amq.host=viewpoint2
Note:
You can inspect the contents of the amq.distributed.cluster.properties file at any time to determine which Messaging Service server is currently the active server and which is the standby server.
4. Edit the [c:]\etc\opt\teradata\cam\amq.local.cluster.properties file as follows: a. Set the value of the cluster.hosts property equal to the host names or IP addresses of all Teradata
Alerting servers separated by a comma. If enabling host authentication ( Additional Alerting
For example: cluster.hosts=viewpoint1,viewpoint2,windows1
Note:
The host name of the Windows server must be added to all amq.local.cluster.properties
files in the cluster. b. Set the value of the tcp.bind_addr property equal to the public IP address of the local host. This is the IP address that the other server in the cluster uses to connect to this host. Do not set the IP address to a private server management IP address.
For example: tcp.bind_addr=192.168.0.3
5. Edit the
[
Install Folder]\Teradata\Client\13.10\Teradata Notification
Service\config\cam-jms.properties
file as follows: a. Uncomment the following line:
#cam.activemq.host=%{activeAmqHost} b. Comment out any other cam.activemq.host lines if they exist.
6. Restart Teradata Notification Service as discussed in
Service Control on page 40 to connect it to the Teradata
Alerting cluster.
Teradata Viewpoint Configuration Guide, Release 13.11 93
Replace a Teradata Alerting Server in the Cluster
A Teradata Alerting cluster can have only two servers in it. If a server fails, and there is another Teradata
Viewpoint server available, you have the option of replacing the failed server with the latter. To replace a server in the cluster, remove that server from the cluster, and add in the new server.
1. On the server being remove from the cluster, stop and disable the Teradata Alerting Services by typing the following commands:
/etc/init.d/camalert stop
/etc/init.d/camactivemq stop chkconfig camalert off chkconfig camactivemq off
2. Follow the steps defined in
Alerting Cluster Configurations section on page 86 to reconfigure the cluster with
the one remaining server in the cluster and the new server.
Promote the Teradata Alerting Messaging
Service
In situations where the Teradata Alerting Messaging Service goes down and cannot easily be fixed, the standby
Messaging Service can be promoted to the new active Messaging Service. The promotion is broadcasted to all
Teradata Viewpoint servers so that they are automatically redirected to use the new Messaging Service. The old active Messaging Service becomes the standby. The Alert Service running on the same server as the promoted
Messaging Service will be the active service, and one running on the other server will become the standby.
To promote the standby Messaging Service, log on to the Teradata Viewpoint server hosting the standby
Messaging Service and type the following command to promote the standby Messaging Service:
/opt/teradata/cam/alert/bin/amq.promote.sh
After the script completes, Teradata Alerting is available again.
Additional Alerting Considerations
Teradata Alerting Cluster Security
Encryption and authentication between the hosts in the Teradata Alerting cluster is disabled, by default.
To encrypt all communications between hosts in a cluster and restrict hosts from joining a cluster:
1. Stop all Teradata Alerting services in the cluster.
2. Enable encryption for messages sent between the hosts in the cluster. a. Open the following file on every server in the cluster:
/etc/opt/teradata/cam/cluster-protocol-stacks.xml
Teradata Viewpoint Configuration Guide, Release 13.11 94
b. Uncomment the following line:
<!-- ENCRYPT encrypt_entire_message="true" sym_init="128" sym_algorithm="AES/ECB/PKCS5Padding" asym_init="512" asym_algorithm="RSA" /-->
3. Enable host authentication to prevent unknown hosts from joining the cluster. a. Open the following file on every server in the cluster:
/
etc/opt/teradata/cam/cluster-protocol-stacks.xml
b. Uncomment the following line:
<!-- AUTH auth_class="org.jgroups.auth.FixedMembershipToken" fixed_members_value="${cluster.hosts}" fixed_members_seperator="," /-->
To enable cluster authentication, the cluster.hosts property in
/etc/opt/teradata/cam/amq.local.cluster.properties must only contain IP addresses and not host names.
4. Test cluster communication with security enabled. a. Run /opt/teradata/cam/alert/bin/amq.clustertest.sh on all servers in the cluster. This command reads in data from the console. b. Enter console input and ensure that when you press Enter, the text appears on the other server’s console. c. Enter text on each server and ensure it appears on the other server’s console when you press Enter. If this does not work, ensure the cluster.hosts property in /etc/opt/teradata/cam/amq.local.cluster.properties is set with the correct IP addresses. d. To enable more debug information, set the cluster.debug.enabled property to true and run
/opt/teradata/cam/alert/bin/amq.clustertest.sh again. e. Press CTRL+D on each console to exit.
5. After the cluster communication test succeeds, restart all Alert Services in the cluster.
Getting Notifications of Failures
Teradata Alerting currently does not provide email notification when it detects an alerting failure has occurred that requires the attention of a Teradata Viewpoint administrator.
Ports Used for Clustering
Besides the normal ports required by Teradata Viewpoint and Teradata Viewpoint cluster, a Teradata Alerting cluster uses the ports in the range 22011-22021 for cluster communications.
Teradata Viewpoint Configuration Guide, Release 13.11 95
CHAPTER 24
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:
1. Log on to the Teradata Viewpoint server (Linux) as root
. a. Open the following file:
/opt/teradata/viewpoint/conf/server.xml
2. Search for an XML block similar to the following and uncomment it by removing the surrounding <!--and --
>:
<!--
<Connector port="443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="SSL" algorithm="IbmX509"/>
-->
3. Save the server.xml file.
[Optional] Configure All Teradata Viewpoint
Access to be Over SSL
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 to 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>
Teradata Viewpoint Configuration Guide, Release 13.11 96
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
4. Save the web.xml file.
Create a Self-Signed Certificate
If you already have a trusted certificate from a certificate authority such as VeriSign
®
2. Log on to the Teradata Viewpoint server (Linux) as root
.
3. Enter the following command and then follow the instructions on the screen:
$JDK5_64_HOME/bin/ keytool -genkey -alias tomcat -keyalg RSA
4. Enter the password: changeit.
5. In the What is your first and last name field, enter your server domain name.
6. In the organization unit field, enter your division name.
7. In the organization field, enter your company name.
8. In the city, state, and country fields, enter your city, state, and country.
9. Type yes, and press Enter if the entered information is correct.
10. When prompted for a password, press Enter.
11. Restart Teradata Viewpoint with the following command:
/etc/init.d/viewpoint restart
Access the secure version at https://yourservername
.
Your self-signed certificate is created and installed.
Create a Certificate Signing Request
When using a self signed certificate, a warning message is displayed to end users about the server’s security certificate not being trusted. To avoid this message, you can obtain a trusted certificate by generating a Certificate
Signing Request (CSR) and submitting the request to a trusted Certification Authority (CA).
1. Log on to the Teradata Viewpoint server (Linux) as root
.
2. Create a CSR in a file called viewpoint.csr:
$JDK5_64_HOME/bin/keytool –certreq –alias tomcat –file viewpoint.csr
3. Enter the password: changeit.
Teradata Viewpoint Configuration Guide, Release 13.11 97
4. Submit the generated CSR to a trusted Certification Authority.
5. When you get the trusted certificate, follow the steps in Import a Certificate on page 98.
Import a Certificate
After you have a signed certificate, use the following procedure to import it into the Java keystore. In the steps below, type the keytool command all on one line with a space where the line breaks are shown.
1. Log on to the Teradata Viewpoint server (Linux) as root
.
2. Install the Signed Certificate generated from the Certificate Signing Request:
$JDK5_64_HOME/bin/keytool -import -alias tomcat -keystore
/etc/opt/teradata/viewpoint/certs -trustcacerts -file <
your_certificate_filename
>
3. Enter the password that was previously set for the Teradata Viewpoint keystore. If this is the first certificate installed into the keystore set the password.
Install a CA Certificate in Teradata Viewpoint
Keystore
If you receive any errors when installing the certificate, they are most likely the result of not having the CA certificate installed in the Teradata Viewpoint keystore.
1. Log on to the Teradata Viewpoint server (Linux) as root
.
2. Install the trusted CA certificate:
$JDK5_64_HOME/bin/keytool -import -alias tomcat –keystore
$JDK5_64_HOME/jre/lib/security/cacerts –trustcacerts –file
<
your_certificate_filename
>
3. Enter the password: changeit.
Certificates have different requirements for installation; therefore, refer to the documentation for the Java keytool command for additional configuration steps and options:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html
Teradata Viewpoint Configuration Guide, Release 13.11 98
CHAPTER 25
Teradata Viewpoint Properties
Teradata Viewpoint has a simple key-value properties table which is used to set various configuration options.
Available Properties
Property
viewpoint.shareableportlets. enabledbydefault viewpoint.web.caching.dailyexpiry. enable
Values Default Effect Restart
Required
true or false true or false false
When true
, shareable portlets are enabled by default; that is, it is not necessary for a Teradata Viewpoint Administrator to enable the portlet in the Portlet Library. 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.
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:00 a.m., unless Teradata Viewpoint is restarted. However, this does not change the fact that the browser keeps caching until 2:00 a.m. If caching is disabled,
Teradata Viewpoint frequently checks if caching has been re-enabled.
Enabling caching takes effect immediately.
No
No
Teradata Viewpoint Configuration Guide, Release 13.11 99
Property
viewpoint.session.multiple
Values Default Effect
true or false false
When false
, a user can only be logged on to a single Teradata Viewpoint session under a given username. That is, if the user is already logged on to
Teradata Viewpoint in one browser, and then logs into Teradata Viewpoint with the same username in a second browser, the first browser session terminates.
Restart
Required
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/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
Teradata Viewpoint Configuration Guide, Release 13.11 100
CHAPTER 26
Portlet Load Times
All portlets have a similar load time when they are alone on a page. Load time is similar for Microsoft Internet
Explorer and Mozilla Firefox. When there are several portlets on a page, high-impact portlets slow the load time more than low-impact portlets. Also, Mozilla Firefox loads multiple portlets faster than Microsoft Internet
Explorer.
There is no value in putting more than four portlets on a page because you cannot see them all at once.
Portlets in the medium-impact and high-impact class run time-consuming queries to collect their data. The results are cached to improve load time, but occasionally a user has to wait up to 30 seconds longer than usual if their query is the one loading the cache.
The portlet categories are:
Low Impact
• My Queries
• Query Monitor (unless a very large number of queries is displayed)
• Query Spotlight
• Remote Console
• SQL Scratchpad
• System Health
• Todays Statistics
Medium Impact
• Alert Viewer
• Calendar
• Canary Response Times
• Lock Viewer
• Metrics Analysis
• Node Resources
• Productivity
• Space Usage
• Viewpoint Monitoring
• Workload Health
Teradata Viewpoint Configuration Guide, Release 13.11 101
High Impact
• Capacity Heatmap
• Metrics Graph
• Workload Designer
• Workload Monitor
Teradata Viewpoint Configuration Guide, Release 13.11 102
CHAPTER 27
Upgrade to Teradata Viewpoint
13.11.xx.xx
Install Teradata Viewpoint for Electronic
Software Distribution
If Teradata Viewpoint was purchased under the Teradata Electronic Software Distribution Management (ESDM) program, then 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.
Teradata Viewpoint Install Script
Starting with the Teradata Viewpoint 13.03 release, an install script is available to simplify the upgrade the process. This script does the following:
1. Checks for an appropriate version of Java.
2. Ensures the required packages are located in the same directory as the script.
3. Stops any running Teradata Viewpoint services.
4. Installs the new Teradata Viewpoint packages if they are not already installed.
5. [Optional] Starts Teradata Viewpoint services.
6. [Optional] Uninstalls and cleans up older versions of Teradata Viewpoint.
Upgrade Teradata Viewpoint
The following instructions are for upgrading a single Teradata Viewpoint server as well as clustered Teradata
Viewpoint servers.
1. Download the Teradata Viewpoint 13.11 software and install script on all Teradata Viewpoint servers.
2. Verify that a current database backup has been completed successfully if having a back down procedure is a requirement.
3. [Clustered only] Identify the server running the primary cache database. (This is referred to as the primary server throughout the remainder of this section.)
Teradata Viewpoint Configuration Guide, Release 13.11 103
4. [Clustered only] Stop the Teradata Viewpoint services running on all servers EXCEPT the primary server.
5. Run the install script on the primary server (or the single server in a non-clustered installation).
6. [Clustered only] Run the install script on the remaining servers.
7. Apply any customizations to all servers.
8. Set up any new data collectors.
Download the Teradata Viewpoint 13.11
Software
1. Log on to the Teradata Software Server . The Teradata Software Server can be accessed from Teradata @Your
Service (log on and click the Teradata Software Server link).
2. Select Certified Configs.
3. From the menu on the left, go to Software Patches > Teradata Applications.
4. Select Sub Category Viewpoint and Release 13.11.
5. Click Submit.
6. Check Select all packages for download.
7. Enter your personal User Name, E-Mail, Site ID, and Change Control Number fields.
8. Click Submit.
9. Click Download to download an archive containing the Teradata Viewpoint packages.
10. Extract the Teradata Viewpoint software and install script from the download archive.
Verify the Previous Database Backup
If providing a back down procedure is a concern, verify that a current database backup has completed successfully. Log on to Teradata Viewpoint and open the Backup portlet from the Admin menu. This portlet lists the last backup, the time it completed, and whether or not it was successful.
Identify the Primary Cache Database Server
Only run this step when upgrading a clustered Teradata Viewpoint environment
.
1. On any server, look at the contents of the /etc/opt/teradata/viewpoint/distributed.cluster.properties file. more /etc/opt/teradata/viewpoint/distributed.cluster.properties
2.
The IP address or server name of the primary cache database is listed after the active.database.host
key in the output of the previous step.
Teradata Viewpoint Configuration Guide, Release 13.11 104
Stop the Teradata Viewpoint Services
Only run this step when upgrading a clustered Teradata Viewpoint environment.
1. On all of the servers EXCEPT the primary server, stop the Teradata Viewpoint services. If there are more than two Teradata Viewpoint servers in the cluster, the order of the servers on which this step is performed is irrelevant.
/opt/teradata/viewpoint/bin/vp-control.sh stop
Run the Install Script
Run the following steps on all Teradata Viewpoint servers. In a clustered environment, run these steps on the primary server first. Then proceed to run these steps on all of the remaining servers in the cluster.
1. Place all the downloaded packages and install script in the same folder on the Teradata Viewpoint server.
2. Log on to the Teradata Viewpoint server as the root user and change directory to where the Viewpoint packages and install script are located.
3. Ensure the install script has permission to run (replace
xx
with correct patch version). chmod +x install-viewpoint-13.11.xx.xx.sh
4. Run the install script (replace
xx
with correct patch version).
./install-viewpoint-13.11.xx.xx.sh
5. Press Y for yes or N for no, when prompted about being licensed and current with the appropriate subscriptions for certain packages.
6. Press Y and then Enter when asked to start the Teradata Viewpoint Services.
7. Press Y and then Enter when asked about uninstalling and cleaning up previously installed versions of
Teradata Viewpoint.
8. Before accessing Teradata Viewpoint, clear the cache of the web browser to ensure that new versions of all files will be retrieved.
9. If Teradata Viewpoint is not accessible one minute after start up, do the following: a. Open the Teradata Viewpoint log file located at
/opt/teradata/viewpoint/logs/viewpoint.log b. Look for any errors.
All errors include the keyword ERROR
10. If no data shows up in Teradata Viewpoint, do the following: a. Open the Data Collection log file located at
/opt/teradata/dcs/logs/dcs.log b. Look for any startup or collection errors.
All errors include the keyword ERROR
Teradata Viewpoint Configuration Guide, Release 13.11 105
Apply Customizations
Some custom configuration changes applied in the previous version of Teradata Viewpoint must also be applied to the newly installed version. This includes:
• Enabling SSL (https).
• Installing additional portlets, including TMSM or any other portlet bundles previously installed in Teradata
Viewpoint.
Note:
This is only necessary if upgrading from an earlier release than 13.02.00.03. In
13.02.00.03 and later, deployed portlets are redeployed on upgrade
.
• Changing the session timeout.
Note:
This is only necessary if upgrading from an earlier release than 13.03.00.00. In
13.03.00.00 and later, the session timeout settings remain on upgrade. See
• Setting up TVI logging to a Teradata TVI queue table.
Note:
This is only necessary if upgrading from an earlier release than 13.03.00.00. In
13.03.00.00 and later, the session timeout settings remain on upgrade. See
Teradata Viewpoint to Log to TVI on page 58.
Apply LDAP Customizations
If upgrading from Teradata Viewpoint 13.0.0 or earlier and LDAP authentication is used, the LDAP configuration that was previously stored in server.xml needs to be manually transferred to the LDAP SERVERS view of the new Teradata Viewpoint LDAP Servers portlet.
1. Use the following table to map the old server.xml configuration parameters to the new LDAP Servers portlet fields.
server.xml Parameter LDAP Servers Portlet Field
jndiConnectionURL URL jndiUserPattern jndiConnectionName jndiConnectionPassword jndiUserSearch
Name Matching -> DN Pattern Bind
Name Matching -> User Search -> Service account DN
Name Matching -> User Search -> Service account password
Name Matching -> User Search -> Search pattern jndiUserBase jndiUserSubtree jndiFirstNameAttribute jndiLastNameAttribute jndiEmailAttribute autoProvision autoProvisionRoles
Name Matching -> User Search -> Search base
Name Matching -> User Search -> Search extent
LDAP first name attribute
LDAP last name attribute
LDAP email attribute
Turn on auto-provisioning
Automatically assign these roles
Teradata Viewpoint Configuration Guide, Release 13.11 106
autoProvisionEmailDomain Default email domain jndiUserRoleName Role mapping -> Attribute name jndiRoleMappings Role mapping -> LDAP value & Viewpoint role
Copy SSL Certificates to New Teradata Viewpoint
Keystore
If the Teradata Viewpoint installation being upgraded uses HTTPS or LDAPS, please perform the steps in this section.
Starting with Teradata Viewpoint 13.11, all SSL certificates will be stored in a custom keystore located at
/etc/opt/teradata/viewpoint/certs
. Prior to this version, the certificates were stored in the Java runtime’s cacerts file, which would be replaced any time the version of Java was upgraded. Going forward, the version of Java can be updated on the Teradata Viewpoint server without requiring the certificates to be reapplied. To support this change, all customer-specific certificates currently stored in the cacerts keystore need to be migrated to the Teradata Viewpoint keystore following an upgrade to Teradata Viewpoint 13.11.
1. Determine the aliases of any certificates that need to be migrated. The following command will list all of the certificates in the cacerts file.
$
JDK5_64_HOME/bin/keytool –list –keystore $JDK5_64_HOME/jre/lib/security/cacerts
2. Migrate each certificate to the Teradata Viewpoint keystore.
/opt/teradata/viewpoint/bin/migrateCert.sh <certificate alias>
3. Enter the password for the cacerts keystore. The default password is changeit.
4. Enter the password for the Teradata Viewpoint keystore. If this is the first certificate that is migrated, select a password for the keystore.
5. Type yes to indicate that you wish to trust this certificate.
6. Repeat Steps 2-5 for any additional certificates that need to be migrated.
Set Up New Collectors and Portlets
Teradata Viewpoint 13.11 contains a new Virtual Storage collector that queries the
GetTvsUdfViewpointSummary user defined function. If your Teradata Database system uses Teradata
Virtual Storage, enable this collector to gather the cylinder count data needed by the TVS Monitor portlet. Also, the TVS Monitor portlet is disabled by default. It can be enabled in the Portlet Library that is accessible via the
Admin menu.
If Teradata Viewpoint is monitoring any Teradata systems running version 12.00.01.16 and later, grant the
Teradata Viewpoint user access to the dumplocklogb console utility by running the following commands against the database: replace macro console.dumplocklogb as (;); grant exec on console.dumplocklogb to viewpoint;
Teradata Viewpoint Configuration Guide, Release 13.11 107
Install and Uninstall Teradata Viewpoint
Packages Manually
Handle Failed Upgrades of Teradata Viewpoint
During the installation of the dcs, viewpoint, and camalert RPMs, modifications might be made to the tables and data within the PostgresSQL database. These modifications are necessary to ensure the database is synchronized with the version of the software you are installing.
When installing these RPMs (either manually or using the installation script), ensure that there are no errors reported as a part of any database modifications.
If errors are reported as a part of the installation, uninstall the RPM and fix the situation that caused the error.
The resolution of the error depends upon the problem. The discussion of what the resolution might be is outside the scope of this document.
After you have uninstalled the RPM and solved the problem, install the same RPM again to successfully upgrade the database and the software.
Install Teradata Viewpoint Packages Manually
The install script automatically installs and uninstalls all Teradata Viewpoint packages. If necessary, you can also install the Teradata Viewpoint packages manually. Use the rpm –ivh
command to install each package. For example, to install the 13.03.00.01 version of the camactivemq package, run the following command: rpm -ivh camactivemq__SLES10_x8664.13.03.00.01-1.rpm
Install the packages in the following order:
1. camactivemq
2. camalert
3. dcsopen
4. dcs
5. tmsmonitoropen
6. tmsmonitor
7. viewpointopen
8. viewpoint
9. tdselfsrvportlets
10. camportlets
11. tdmgmtportlets
12. tasmportlets
Teradata Viewpoint Configuration Guide, Release 13.11 108
Note:
With Release 13.11.00.00, the camnotification package no longer exists. If you have upgraded without using the installation script, manually run the following command to remove the camnotification service: chkconfig –del camnotification
Uninstall Teradata Viewpoint Packages Manually
If necessary, you can also uninstall the Teradata Viewpoint packages manually. Use the rpm –e
command to uninstall each package. For example, to uninstall the 13.11.00.00 version of the tasmportlets package, run the following command: rpm -e tasmportlets-13.11.00.00-1
Uninstall the packages in the following order:
1. tasmportlets
2. tdmgmtportlets
3. camportlets
4. tdselfsrvportlets
5. viewpoint
6. viewpointopen
7. tmsmonitor
8. tmsmonitoropen
9. dcs
10. dcsopen
11. camalert
12. camactivemq
13. camnotification (prior to 13.11.00.00)
Teradata Viewpoint Configuration Guide, Release 13.11 109
CHAPTER 28
Back Down to a Previous Teradata
Viewpoint Version
If an upgrade of Teradata Viewpoint produces an undesired or unanticipated effect, the following steps will allow you to back down to the previously installed version of Teradata Viewpoint. Since this procedure involves restoring a database backup, it could take a substantial amount of time to complete, especially if the database is large.
1. Stop all of the Teradata Viewpoint services on all Teradata Viewpoint servers.
/opt/teradata/viewpoint/bin/vp-control.sh stop
2. If the Teradata Notification Service is running on a Windows server, stop this service.
3. Restore the last successful backup of the Teradata Viewpoint databases. Follow the appropriate instructions
against the primary database server.
4. If the Teradata Notification Service is running on a Windows server, uninstall the 13.11 Teradata
Notification Service.
5. Uninstall the Teradata Viewpoint 13.11 RPMs on all Teradata Viewpoint servers. Follow the instructions in
the Uninstall Teradata Viewpoint Packages Manually
6. Reinstall the previous version of Teradata Viewpoint RPMs on all Teradata Viewpoint servers. Follow the instructions in the Install Teradata Viewpoint Packages Manually section, or use the upgrade script if one was provided for that particular version.
7. If the Teradata Notification Service was running on a Windows server, install and configure the previous version of the Teradata Notification Service for Windows. a. Install the previous version of the Teradata Notification Service. Follow the instructions in the Install
Teradata Notification Service for Windows section. b. Move the programs from the current version’s usercmd folder to the previous version’s usercmd folder.
The usercmd folder is located at:
<Install folder>\Teradata\Client\<version>\Teradata Notification
Service\usercmd c. Move the BTEQ scripts from the current version’s sql folder to the previous version’s sql folder. The sql
folder is located at:
<Install folder>\Teradata\Client\<version>\Teradata Notification Service\sql d. Start the previous version of the Teradata Notification Service on the Windows server.
8. Start the previous version of all the Teradata Viewpoint services on all Teradata Viewpoint servers.
/opt/teradata/viewpoint/bin/vp-control.sh start
Teradata Viewpoint Configuration Guide, Release 13.11 110
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.
Document public link
Advertisement
Key features
Monitor Teradata Databases
Configure data collectors
Configure alerts
Install Teradata Notification Service
Configure Viewpoint Security
Backup and restore databases
Configure Teradata Viewpoint Clustering
Configure Teradata Alerting Clustering
Configure SSL Support
Upgrade to Teradata Viewpoint 13.11
Frequently asked questions
The software requires a Dell 2950 or R710 Managed Server, SuSE Linux 10, Teradata JDK 1.5 (SR8 or later), and PostgreSQL Server 8.1 or 8.3.
Log in to the Teradata Viewpoint server, go to Admin > Teradata Systems, then click the ‘Add Teradata System’ icon. Enter a nickname, TDPID, user names, and passwords. Optionally you can enable data collectors and system heartbeat in canary queries.
You can configure alerts for email, SNMP, BTEQ, and run a program. Alerts can be configured for various events, such as database space usage, query performance, and system health.
Go to the Admin > Teradata Viewpoint tab, then click the SSL tab. You can import a certificate, create a self-signed certificate, or create a certificate signing request.
There are three cluster configurations: high availability, high usage, and advanced. The high availability configuration uses two Teradata Viewpoint servers, the high usage configuration uses three or more servers, and the advanced configuration uses three or more servers with a dedicated cache database server.
