Skip to main content
Previous sectionNext section

Controlling Data Storage for Productions

This chapter describes how you can control where InterSystems IRIS® stores data. Interoperability-enabled namespaces store data in InterSystems IRIS databases. For general information on how to control InterSystems IRIS database storage, see the System Administration Guide. This chapter provides some supplementary information that is useful for InterSystems IRIS installations.

This chapter contains:

Separate Databases for Routines and Globals

When you create a new namespace, you specify the databases that contain routines (the code) and the globals (the data). For new namespaces, InterSystems recommends that you specify different databases for routines and globals. Many existing namespaces use a single database to store both routines and globals. Although it is possible to split such a database into two separate ones, it is typically not worth the effort, which includes copying the routines from one database to another.

Note:

Some classes, such as Ens.Production and Ens.Rule.Rule, can be updated dynamically but are stored in the routines database. Consequently, if you are mirroring the dynamic data in an interoperability-enabled namespace, you should include the routines database in the mirror.

You should always compile the production on the system that it is running. Although you can compile InterSystems IRIS code on one system and copy the database “pre-compiled” to another system, you should not attempt this with interoperability-enabled namespaces.

Productions and Namespaces

In most cases, productions are defined and run in the same namespace, but you can use InterSystems IRIS package mapping to make a production class visible in a namespace other than the one it is defined in. If you use package mapping and a production is visible in more than one namespace, you should designate only one of these namespaces to compile and run the production, You should not compile, modify, or run the production in any other namespace. If you run or modify the same production in more than one namespace it can cause failures that are hard to diagnose. Under no circumstances should you do this. If you do not use package mapping to map a database to a namespace you do not need to be concerned about this issue.

Where InterSystems IRIS Stores Credentials Passwords

When you create an interoperability production-enabled namespace, InterSystems IRIS creates a separate database to store the credentials passwords for the namespace. By having the passwords in a separate database, you can encrypt this confidential account information without having to incur the overhead of encrypting all of the namespace data.

The credentials password database is created in a subdirectory of the namespace's default database for globals. The database name and subdirectory name is the name of the namespace's default database for globals with "SECONDARY" appended. For example if the default globals database is LABS then the secondary database will be called LABSSECONDARY. The credentials passwords database is protected by a resource named after the database (e.g. %DB_LABSSECONDARY) without public access. Under most conditions no user needs to have privileges to this resource. InterSystems IRIS stores the data in this database under the global ^Ens.SecondaryData.Password.

An exception is that if the USER namespace is enabled for productions,. the secondary database for credentials is not created and the credentials are stored in the USER database.

Note:

If you create the primary InterSystems IRIS database as a mirrored database, then the secondary database for credential passwords is automatically mirrored using the same settings as the primary database. If you add mirroring to an existing InterSystems IRIS database, then you must explicitly add mirroring to the secondary database. For information about mirroring, see the High Availability Guide.

Where InterSystems IRIS Stores Temporary Production Data

InterSystems IRIS creates temporary data while a production is being run; this data is deleted when a production is stopped. In most cases, you do not need to be concerned with this temporary data, but in rare circumstances you may need to deal with it when recovering from error conditions. For new namespaces, InterSystems IRIS by default stores temporary data in a non-journaled database separate from IRISTEMP. The database name and subdirectory name is the name of the namespace's default database for Globals with "ENSTEMP" appended. For example if the default globals database is LABS then the temporary database will be called LABSENSTEMP. This database is be protected by the same resource as that protect the default globals database. For example, InterSystems IRIS stores the following globals in this database:

  • ^IRIS.Temp.EnsRuntimeAppData—contains the temporary data needed to run the production. By default, for new namespaces this global is stored in a database named by appending ENSTEMP to the name of the database used to store the namespace globals. For example, if you create a namespace TEST and specify that the globals are stored in TESTGL, this global is stored in TESTGLENSTEMP.

  • ^IRIS.Temp.EnsJobStatus—an entry is written when the production is started and removed when the production is stopped.

  • ^IRIS.Temp.EnsMetrics—contains production metrics data, such as that displayed by the production monitor.