A common discussion around Teradata Viewpoint is whether one Viewpoint appliance is enough. Consider a significant advantage of Teradata Viewpoint is its ability to manage multiple Teradata systems even if those systems are running different Teradata Database versions, on different Teradata platforms, and even with different underlying Operating Systems. That being the case, wouldn't one Viewpoint appliance be sufficient? Maybe not ... so let's discuss the factors that may drive consideration of having more than one Teradata Viewpoint appliance at your site. 

1) High Availability

Redundancy will likely be the most prominent reason to consider another Viewpoint appliance in your infrastructure. It is true that Teradata Viewpoint being down does not impact Teradata Database availability. However not having access to Viewpoint will certainly make the life of the DBA and Teradata users less joyous to say the least. As more management solutions migrate to Viewpoint and the Teradata community self-service usage of Viewpoint increases, so does the importance of having Viewpoint available 7x24x365. So it only made sense to offer a HA redundancy and clustering solution as we did in the June 2009 Viewpoint 13.0.1 release. Each Teradata Viewpoint appliance in a cluster shares the same users, roles, permissions, preferences, and collected data from monitored Teradata systems. For high availability, you have a typical primary/standby configuration as shown below.

As the importance of Viewpoint in your environment increases so will the number of Viewpoint clusters for High Availability. Redundancy is also a key ingredient in the Teradata Multi System Management (TMSM) dual/multi system configurations. As TMSM utilizes Viewpoint for their user interface, this will also be a common place for multiple Viewpoint appliances leveraging the HA configuration option.

2) Test Environment / Portlet Development

Another reason for consideration of an additional Viewpoint Appliance may be as a test environment. This test environment is most likely for one of two reasons. First, a customer may want to test new Teradata releases in an isolated controlled environment before implementing in Production. For instance, an additional Viewpoint appliance connected to a dedicated Teradata test system for full certification of any new variable, whether it is a Teradata Database release, a new application, or a new Viewpoint version.

The other possibility is having a full Viewpoint instance to test custom portlets you've built or obtained from other sources like Professional Services or another Teradata customer perhaps. The Portlet Development Kit (PDK) does offer a Viewpoint instance for development that could be used for test but a customer may have a preference to have a fully configured Viewpoint for this purpose. This second Viewpoint appliance could certainly be used to address the combination of these two test needs.

3) Number of Teradata Systems

One Viewpoint appliance is capable of managing multiple Teradata systems but obviously this is not an infinite number. Like any application server, one will need to balance the load with the available resources of the underlying server ... too much activity utilizing CPU will impact performance, too much system data will limit the duration of history that can be maintained. So what is the number of Teradata systems that can be adequately supported by Viewpoint? The current general recommendation is ten Teradata systems per Viewpoint appliance but there are a number of variables that really should be considered for a more intelligent configuration decision.

The Teradata system factors impacting the amount of data being collected are:

  • Average number of concurrent sessions
  • Average number of rows written to DBQL per day (dbqlogtbl and dbqlsummarytbl)
  • Total number of accounts
  • Number of locks logged per day
  • Total number of databases
  • Total number of tables
  • Total number of vprocs
  • Total number of nodes

With this information, Teradata can work through system monitoring scenarios to determine the extent of history data you would be able to maintain on Teradata Viewpoint for all the Teradata systems planned for monitoring.

There were also tools added in the June 2009 Viewpoint 13.0.1 release that will help you monitor and manage your Viewpoint appliance resources. Data Collection Service (DCS) disk usage visualization was added to the Admin menus. If you're interested in that, check out the Viewpoint DCS Usage blog that discusses this.

The "Viewpoint Monitoring" portlet was part of the new tools introduced providing visualization, over time, of how resources are being utilized on one or more Teradata Viewpoint appliances. Here's an example view of that portlet.

So there are proactive steps that can be taken for Viewpoint capacity planning as well as monitoring tools to manage growth of an active Viewpoint environment.

4) Self-Service User Concurrency

Another factor that will drive additional Viewpoint instances is the increase of self service usage of Viewpoint. From engineering trials, the current estimate for Viewpoint concurrency limits is that a single Viewpoint appliance can support up to 350 concurrent users. This of course is heavily dependent on user usage patterns. So if the self service aspect of Teradata Viewpoint is heavily embraced, then you may need to consider additional Viewpoint appliances to absorb hundreds of concurrent users especially if they are actively using multiples of portlets. The clustering solution in the June 2009 Viewpoint 13.0.1 release also provided strategies for spreading the user community across multiple Viewpoint instances. The differences in the Viewpoint clustering implementations are whether the DCS is enabled or not, and if so, as a primary or standby and whether the Viewpoint portal is enabled or not. Viewpoint appliances dedicated to serving users could have the DCS fully disabled. The example below has the primary Viewpoint appliance dedicated to managing the DCS (portal disabled) and two Viewpoint appliances dedicated to serving users (DCS disabled). We are also allowing the Viewpoint standby DCS appliance to serve users ... so the entire configuration could support 3x350 users for a total of 1050 concurrent users.


5) Network Connectivity

Lastly network connectivity may also be a driving factor for consideration of additional Viewpoint instances. If you have multiple data centers in different geographical locations and want to isolate the network traffic, then another Viewpoint instance may need to be considered. There could also be firewall or private networking implications that would drive additional Viewpoint instances to support a certain group of users or network connectivity to the necessary Teradata systems. The network connectivity consideration is much more likely a customer network topology aspect then a bandwidth issue.

So in the end, you may be just fine with having just one Viewpoint appliance but for the considerations discussed here, multiple Viewpoint appliances will certainly be a common occurrence. The most important thing is to get that first Viewpoint appliance up and running.


geethareddy 145 comments Joined 10/11
10 Jul 2012

Hello Gary,

We recently set up the High Availability Clustering configuration on our Viewpoint Servers. We clustered the DEV(active) and TEST (standby) environments viewpoints servers together. I have question regarding the services on Active and Standby servers. I know the services should be active on ACTIVE VP server. But the services should be stopped on STANDBY VP Server right? I think, there is no point in running the services on STANDBY VP server, when we have the clustering in place and ACTIVE VP server is already collecting the data. Do you have any comments on my understanding?

The services I am talking about is:
Teradata ActiveMQ,
Teradata Alert Service,
PostgreSQL etc



gryback 151 comments Joined 12/08
10 Jul 2012


You need to follow the guidelines in the Viewpoint Configuration Guide for setting up clustering. Within that chapter, it specifically states the following:

All of the Teradata Viewpoint services listed under Start and Stop Teradata Viewpoint Services on page 17 (Chapter 2) must be running on both servers with the exception of Teradata Alerting services.

The Viewpoint Configuration Guide can be found at:

geethareddy 145 comments Joined 10/11
10 Jul 2012

Thanks Gary.
I read that manually before, just to concentrate on my questions, I extracted the below paragraph on high availability configuration and i have few questions here, can you please help me to understand this correctly.

""Both Teradata Viewpoint instances point at the same active cache database.
A standby cache database is kept up to date with the last minute of data in the event a failure occurs.
An active Data Collection Service (DCS) runs on the same Teradata Viewpoint server as the active cache database.
The other Teradata Viewpoint server contains a standby DCS that assumes data collection should the active DCS fail.
The Teradata Viewpoint servers share a distributed cache to ensure that the state between the Teradata Viewpoint portals remains

***MY Questions:***
Q1)when the VP servers share a distributed cache to ensure that the state between the both the VP portals remains consistent,
why we need to run the services on standby side.
Q2) The statement below stating that the DCS runs on one VP (ACTIVE VP) server where the active cache db running,
and other VP server (i.e.STANDBY) server assumes the DCS active once the ACTIVE VP goes fail. This sentence is kind of confusing to me.
"An active Data Collection Service (DCS) runs on the same Teradata Viewpoint server as the active cache database.The other Teradata Viewpoint server contains a standby DCS
that assumes data collection should the active DCS fail."


You must sign in to leave a comment.