Oracle Tablespaces
Every Oracle Utilities Network Management System must have its own Oracle tablespace set. In general, the tablespaces consist of the following:
 
Tablespace
Description
Production
The production tablespace (nms_db) contains all of the production data for Oracle Utilities Network Management System. This includes model data, outages, and data that is produced by operations performed in Oracle Utilities Network Management System.
Production Temporary (Optional)
The production temporary tablespace (nms_tmp) temporarily stores operating data prior to insertion into the production tablespace. The default Oracle TEMP tablespace should be the designated temporary tablespace for the system. Oracle is more efficient when managing temporary data in this way. Make sure that a sufficient amount of space is allotted to TEMP.
Production Index
(Obsolete) The production index tablespace (nms_idx) contains all of the indexes for the production tablespace. The nms user’s .nmsrc file may contain the NMS_INDEX_TABLESPACE environment variable referencing this tablespace. Note that on a modern RDBMS (with solid state storage), it should generally not be necessary to set this variable.
Customer Data
The customer data tablespace ([project]_customers_db) belongs to the customer. It is populated with the entire customer database by the CIS extraction process. Public synonyms are assigned to the customer tables and selectability is granted to production Oracle users so that the necessary table joins can be created.
 
Each tablespace should be located on a separate disk to enhance performance and decrease bottlenecks due to high volumes of input/output. Note that if the RDBMS uses solid state storage this is generally irrelevant and can be ignored.
It is key that the tablespaces are provided with sufficient disk space and are monitored regularly for growth. When a tablespace runs out of disk space, operational data will be lost and Oracle Utilities Network Management System services will discontinue to function properly.
Oracle Instances
For performance, scalability and simplicity there is normally only one Oracle instance on a production machine. It is not generally recommended that a production machine have multiple Oracle instances on the same machine. An exception would be where a cluster is used; you may want an Oracle instance installed on both sides of the cluster (production on the primary side, Model Build, Test, or Oracle Utilities Analytics on the secondary side). Under normal circumstances there would only be one instance of Oracle on each side – if one side of the cluster fails you could end up with two instances on the surviving node. In general, try to keep it simple.
You should consult with your Oracle Utilities Network Management System Professional Services technical team to develop an appropriate solution to meet your specific needs.
Oracle Utilities Network Management System uses an Oracle Wallet and the environment variables RDBMS_ADMIN and RDBMS_HOST to create a connection to the Oracle database. The wallet stores the database users and passwords in encrypted form. RDBMS_ADMIN and RDBMS_HOST are different tnsnames aliases for the same database, each of which points the Oracle client software to the correct user/password pair within the wallet (RDBMS_ADMIN for the admin user and RDBMS_HOST for the read/write user). The wallet and related environment variables are created and maintained by running the script nms‑env‑config as the NMS administrative user.
Each instance of Oracle Utilities Network Management Systems (for example, production, test, model build) must have a unique database owner/schema with its own tablespaces. Using the same database owner/schema for two implementations will result in corrupted data.
Note: Two or more Oracle Utilities Network Management System instances on a single machine can be acceptable (depending on machine resources) for testing, training and model build environments.
It may be necessary to tune the Oracle RDBMS for the specific environment it will be operating on. Typically a qualified DBA can perform the necessary tuning and modifications. Often this is an iterative process that requires running the full Oracle Utilities Network Management System on the production machines and capturing statistics for analysis.
Other Environment Variables
Other Oracle-specific environment variables may need to be different between systems, but these are due to how the DBA has constructed the environments. Other than the NLS specific environment variables noted below, these are listed in one of the example tables in chapter five.
When Oracle is loaded onto a given platform, the Oracle instance itself will generally have a default National Language Support (NLS) setting. Oracle Utilities Network Management System client applications (like DBService) which utilize the Oracle Call Interface (OCI) need to know what NLS settings to use for inserting and interpreting result sets from Oracle. Presently, the easiest way to do this is as follows:
1. Add the following environment variable to your .nmsrc file: NLS_LANG
Note: For a US configuration, Oracle believes the NLS_LANG environment variable (as far as OCI is concerned) typically defaults to AMERICAN_AMERICA.AL32UTF8. Thus if a customer sets their Oracle NLS to something other than this value (inside of Oracle during instance setup) - and does not specify the NLS_LANG environment variable to appropriately match, DBService will not start. You will see a note in the DBService log file indicating a mismatch that must be rectified.
2. The following process should work for setting NLS_LANG:
Set NLS_LANG to
[NLS_DATE_LANGUAGE]_[NLS_TERRITORY].[NLS_CHARACTERSET]
where each "NLS component" needs to match the values returned by this query:
SELECT * FROM v$nls_parameters WHERE parameter IN
( ‘NLS_DATE_LANGUAGE’,
‘NLS_CHARACTERSET’, ‘NLS_TERRITORY’)
For example, we have NLS_LANG=AMERICAN_AMERICA.AL32UTF8, and our query returns:
PARAMETER VALUE
------------------- ----------
NLS_DATE_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CHARACTERSET AL32UTF8