Idea Details

High Available Database (Postgres) for Introscope

Last activity 19 days ago
prakash.panchatcharam's profile image
05-10-2016 06:06 AM

APM 10.x brings in Team Center with perspectives which improves Triaging, however it also makes the database critical than before for Introscope-only Operations. The maps are built dynamically based on the application transactions and the various perspectives present maps in a sensible view based on owner/application/location,etc , these perspectives require the application users to supply one time input such as Owner, Location, region for each of the application groups to aid traiging with the user perspectives.


These user defined parameters are stored under the APM database, therefore in the event of losing the database due to unexpected failure or corrupted database files affects the user perspectives & Triaging.


Ideally this requires Introscope to use an high-available Postgres solution, the only supported high available database solution is using Oracle (RAC) which will add the implementation/operational costs for Introscope Only environment while postgres offers high available solution too but its the matter of time CA to engineer/test Postgres with high available solution for its use.


06-13-2017 02:01 PM

Yes, it will continue to be an issue for all until this single point of failure is addressed.

It's even more critical now with TC.

01-03-2017 08:10 AM

Thanks Billy. The APM Database is the brains (memory) of APM. So continuous operation is important. Will ask PM if they wish to comment.

01-03-2017 08:03 AM

Over the last several years, the topic of HA for APM has been brought up:   MOM Failover   Postgresql Failover   MOM Failover


From what I can remember of these discussions, it boils down to how important high availability is.  An idea "MOM Failover without relying on OS/HW" received 34 votes up and was back in 2012, but the idea "Fail Over - Protect the MoM, the Collectors can deal" got only 4 votes up in 2015.



The APM database is becoming the corner stone to the HA structure with the CEM and team center data.  Without the APM database, which I assume postgres is majority, the EPIC starts to crumble.  Now the experts are investing in trying to determine what the problem is, where it started in order to focus effort on a fix or workaround, either on the APM or without the APM and on the business application that APM is responsible to provide information on.


Our current APM solution is hosted on ESX, virtual hosts and the same host co-shares other production servers.  We lost the ESX hosting the postgres APM DB, then we should be able to move the APM DB or MOM in sort order, but those hosts would be low on the recover/re-hosting list.  The APM enterprise managers are on separate ESX hosts so hopefully we would only lose one enterprise manager.  If the ESX host with the MOM on it fails or has an issue, then the APM would be inaccessible.  


If the MOM is inaccessible, there isn't a way for the APM to protect the experts.



05-10-2016 06:16 AM

Hi Hal,

I am currently exploring the Postgres options and I have setup Postgres in Master/Standy (hot_standby) mode, it allows replication from the master to standby (read-only), thus giving me an option to switch standby as master in the event of failure but this is manual. However the challenge is with the reconfiguration of MOM/Data Collectors to point to the standby database when it got promoted as master..

05-10-2016 06:11 AM

Hi Prakash:

     Are you exploring/using a third-party solution to current do this or some of Postgres' built-in functionality?



Hal German