Creating Caché Databases and Namespaces
To create a Caché database and access its data, use the Management Portal, which provides a convenient wizard that creates the physical volume and namespace, if needed.
Creating Database Files
A Caché database can be one of two formats — 2KB block size or 8KB block size. InterSystems strongly recommends (for performance and ECP networking reasons) that you convert your MSM databases to the 8KB database format.
A Caché database is consists of a file named CACHE.DAT, representing a logical database which can grow to 32 terabytes, assuming that the host operating system can support files large enough for this. The database is referenced by the directory path of the CACHE.DAT file.
The absolute limit on the number of databases per Caché instance is 15,998, but the practical limit is likely to be much lower. See Configuring Databases in the “Configuring Caché” chapter of the Caché System Administration Guide for more information about the maximum number of databases per instance.
Some key points to consider while creating databases are:
Creating as large a database as possible will aid in combating fragmentation issues at the operating system level.
You can reference a database that physically exists on another system. For this to happen, you must first have a working Caché network configured between the two systems.
Currently, database names, which are mapped to physical locations, are internally translated to all uppercase and do not allow punctuation.
See the Caché System Administration Guide for detailed instructions on creating, editing, and deleting databases.
Creating a Namespace Configuration
You do not typically work within a database in Caché, but rather in a namespace, which is a virtual environment.
It is important to understand the differences between the concept of a Caché namespace and an MSM UCI. Simply put, a namespace is roughly equivalent to an MSM UCI plus its relevant translation table. This translation table also implicitly includes locations of both % globals and % routines. By default, all % globals and % routines exist in either the CACHESYS, CACHELIB or CACHETEMP databases, but they can in fact live in any database that you choose, as long as the namespace mapping is first set correctly.
During a Caché upgrade, the CACHESYS, CACHELIB and CACHETEMP databases can be purged of globals and/or routines, or even completely replaced by a new version.
Thus, it can be considered dangerous to simply load any user written % routines into the Caché manager. Unless you completely understand the ramifications of using the Caché manager databases, it is much safer to define the namespace mappings to store your % routines and globals elsewhere, or modify your application to use non-% names for application specific globals and routines.
In Caché, unlike MSM, the concept of % globals and routines is a naming convention only, and has no hard “mapping” implications. See the chapter on “Converting MSM Globals” for tips on how to handle extended global references from your MSM application.
Once your databases are defined, you will add them to your namespace configuration. Through namespace mapping you will be able to access data from all of your databases from one logical location. To create Caché namespaces, you use the Management Portal.
Some useful facts on namespaces:
Namespaces allow you to break the old 16-gigabyte physical limitation of a single database for your system.
Mapping globals to different databases is an effective way to balance the load on your machines. You should always consider different database layouts for optimal I/O performance.
The ^%CD utility allows you to list and change namespaces (enter a question mark at the prompt to list all available namespaces). See the “Changing Namespaces” section in the “Introduction to the Terminal” chapter of Using Terminal for more detailed information on navigating Caché namespaces.
You can see the active namespace mappings by running either ^%NSP or ^%SYS.GXLINFO.
As with databases, namespace names currently are translated internally to all uppercase.
The CACHETEMP Database
This database has special characteristics that are designed to give higher performance and make it easier to clean up temporary globals.
The CACHETEMP database is purged automatically by the system on restart. Because the database is primarily used for temporary working files, the system will attempt to retain in memory any database blocks that are scheduled to be written to it for as long as possible. Data blocks are only flushed to disk in cases of clean buffer starvation in the buffer pool. This feature can relieve the workload on the system and lead to superior performance and scalability.
To make use of CACHETEMP and the benefits that it brings, simply configure global mapping for the relevant globals (using wildcards where possible) to point to the CACHETEMP database.