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.
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.
Some classes, such as Ens.ProductionOpens in a new tab and Ens.Rule.RuleOpens in a new tab, 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 Password Credentials
InterSystems IRIS creates a dedicated database for password credentials when you create a new namespace with the following options enabled:
InterSystems IRIS never creates a password database for the USER namespace.
Additionally, InterSystems IRIS for Health and HealthShare do not create password databases by default. You can call the CreateNewDBForSecondary() method of the %Library.EnsembleMgrOpens in a new tab class to create them as needed.
The password database appears in a subdirectory of the directory that contains the default database for globals. Both the password database and corresponding subdirectory are named by appending SECONDARY to the name of the default database for globals. For example, if the default database for globals is named LABS, then the password database and corresponding subdirectory are named LABSSECONDARY.
InterSystems IRIS protects the database with a resource named %DB_database, where database is the name of the password database. For example, the LABSSECONDARY database is protected by the %DB_LABSSECONDARY resource. Typically, users do not require privileges to the resource protecting a password database.
The data in the password database is stored in the ^Ens.SecondaryData.Password global.
By storing passwords in a separate database, InterSystems IRIS enables you to encrypt confidential account information without having to incur the overhead of encrypting all of the namespace data.
If you create the primary InterSystems IRIS database as a mirrored database, then any password database 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 password database. For information about mirroring, see the High Availability Guide.
Where InterSystems IRIS Stores Temporary Production Data
While a production is running, InterSystems IRIS creates temporary data. This data is deleted when the production is stopped. While you can typically ignore temporary data, you may find it useful for recovering from an error condition.
When you create a new namespace with the following options enabled, InterSystems IRIS creates an additional, non-journaled database for temporary data:
InterSystems IRIS never creates databases for temporary data for the USER namespace.
InterSystems IRIS for Health and HealthShare do not create databases for temporary data by default. You can call the createNewDBForEnsTemp() method of the %Library.EnsembleMgrOpens in a new tab class to create them as needed.
The database for namespace-level temporary data is separate from the IRISTEMP database and contains the following globals:
^IRIS.Temp.EnsRuntimeAppData—Includes the temporary data required to run the production.
^IRIS.Temp.EnsJobStatus—Includes an entry each time a production is started, which is removed when a production is stopped.
^IRIS.Temp.EnsMetrics—Includes production metrics similar to the metrics displayed by the production monitor.
The database for temporary data appears in a subdirectory of the directory that contains the default database for globals. Both the temporary data database and corresponding subdirectory are named by appending ENSTEMP to the name of the default database for globals. For example, if the default database for globals is named LABS, then the temporary database and corresponding subdirectory are named LABSENSTEMP.
InterSystems IRIS protects the database with the same resource that protect the default database for globals.