Skip to main content

Controlling Ensemble Data Storage

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

This chapter contains:

For information on where Ensemble stores DICOM data, see “Configuring a DICOM Production to Control the Storage Location” in the Ensemble DICOM Development Guide.

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 Ensemble 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 Ensemble 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 Caché code on one system and copy the database “pre-compiled” to another system, you should not attempt this with Ensemble namespaces.

Productions and Namespaces

In most cases, productions are defined and run in the same namespace, but you can use Caché 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 Ensemble Stores Credentials Passwords

When you create a namespace, Ensemble 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. Ensemble stores the data in this database under the global ^Ens.SecondaryData.Password. See the compatibility note “New Global and Database Used to Store Credentials Passwords” in the Ensemble Release Notes.


If you create the primary Ensemble 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 Ensemble database, then you must explicitly add mirroring to the secondary database. For information about mirroring, see the Caché High Availability Guide.

Where Ensemble Stores Temporary Data

Ensemble 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, Ensemble by default stores temporary data in a non-journaled database separate from CACHETEMP. 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, Ensemble stores the following globals in this database:

  • ^CacheTemp.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.

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

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

FeedbackOpens in a new tab