What is the element capacity of an eHealth server?

Products

• CA eHealth

Issue/Introduction

Description:

eHealth servers measure capacity as an element count basis. The number of elements an eHealth server can handle is a finite value.

Solution:

The maximum Number of elements in the eHealth Database on Windows is 50K Elements.
The maximum Number of elements in the eHealth Database on Linux is 75K Elements.
The maximum Number of elements in the eHealth Database on Solaris is 100K Elements.

*Elements in the eHealth Database include Polled and Non-Polled elements.
*The Solaris numbers assume the pre-reqs have been met if polling > 50K elements at 5 Minute polling interval (default normal poll).

Prerequisites for polling more than 50,000 elements at 5 minutes with eHealth

Note: This expanded capability is only available on Solaris r6.1.1 and later systems at this time.

System Requirements/Recommendations:

Memory: 16GB RAM and 24GB swap
CPUs: 8 x 2.0 GHz UltraSPARC or SPARC64 VI/VII

eHealth Environment Variable Required Change:

NH_STAT_POLLS_PER_SECOND = 600 (default is 300)

Sizing Procedure:

1. Use the Sizing Wizard (SWIZ) to create an LCF file for a configuration with half the desired number of elements for the desired roll-up schedule (e.g. to size for 80,000 elements, run SWIZ for 40,000).
   
   
2. Edit the LCF file and duplicate the datafiles for the following tablespaces (keeping the same size and path but changing the name of each file):
   
   NH_INDEX
   NH_DATA01
   NH_DATA02
   NH_REG01
   NH_REG02
   NH_REG_INDEX01
   NH_REG_INDEX02
   
   For example (original files are black; new files are Italic):
   
   NH_INDEX 10659M /export/yen02/oradata/{SID}/NH_INDEX01.dbf
   NH_INDEX 10659M /export/yen02/oradata/{SID}/NH_INDEX0 2.dbf
   NH_DATA01 16101M /export/yen03/oradata/{SID}/NH_DATA01a.dbf
   NH_DATA01 16101M /export/yen03/oradata/{SID}/NH_DATA01 b.dbf
   NH_DATA02 4226M /export/yen04/oradata/{SID}/NH_DATA02a.dbf
   NH_DATA02 4226M /export/yen04/oradata/{SID}/NH_DATA02 b.dbf
   NH_REG01 14050M /export/yen04/oradata/{SID}/NH_REG01a.dbf
   NH_REG01 14050M /export/yen04/oradata/{SID}/NH_REG01 b.dbf
   NH_REG02 14050M /export/yen05/oradata/{SID}/NH_REG02a.dbf
   NH_REG02 14050M /export/yen05/oradata/{SID}/NH_REG02 b.dbf
   NH_REG_INDEX01 4501M /export/yen02/oradata/{SID}/NH_REG_INDEX01a.dbf
   NH_REG_INDEX01 4501M /export/yen02/oradata/{SID}/NH_REG_INDEX01 b.dbf
   NH_REG_INDEX02 4501M /export/yen03/oradata/{SID}/NH_REG_INDEX02a.dbf
   NH_REG_INDEX02 4501M /export/yen03/oradata/{SID}/NH_REG_INDEX02 b.dbf
   
   Note: The datafile names must be unique. This is done via a unique suffix in the name of the file. These are shown in BOLD in duplicated files.
   
   CAUTION: The SWIZ utility performs a check to ensure that there is sufficient space on each path. When the LCF file is modified as specified above, a manual check must be performed to ensure that there is sufficient space for the new files. If there is not, alternate paths can be created and used.
   
   
3. Use the new LCF file to create the database as usual.

Environment

Release: LHDEVC99000-6.3-eHealth-Live Health Upgrade Elements
Component: