Caché System Management
To configure Caché, you use the Management Portal. The Caché System Administration Guide includes detailed information on how to use the manager, and also highlights the minimum and maximum values for each parameter. Alternatively, you can access Caché’s online help by pressing the <F1> key with a particular field within the utilities selected.
Tips and tricks on basic system configuration:
Check that Maximum # of User Processes equals the total process count of your Caché license, unless you want fewer users to gain access.
Keep your partition size at a sensible level (the default is 1MB), unless your application requires larger values. If you set this value too large, you will use memory and swap space inefficiently. Caché partitions are fixed size and do not expand and contract as do MSM partitions. You cannot dynamically change the partition size because there is no %PARTSIZ equivalent utility in Caché.
In many cases, increasing the number of Global and Routine Buffers is the best and quickest way to improve performance.
See the appendix “MSM and Caché Utilities Catalog” for a list of MSM utilities and their Caché equivalents.
In most cases, devices must first be set up at the operating system level. Once configured at the OS level, you can immediately begin using these devices from within Caché. If you need to set up mnemonic names or numeric aliases for these devices, use the device configuration utility in Management Portal. These Caché-level device configurations are stored in the cache.cpf file. At each Caché startup, the system will read the cache.cpf file and recreate the system level globals in the CACHESYS database.
Tips on configuring devices:
Caché has a set of reserved, built-in device numbers which are generally different from MSM. See the Caché I/O Device Guide for more information.
You only need to enter devices into Caché’s device tables if you want to access them via a mnemonic name, such as SUN, or a numeric alias, such as 100 (common on MSM systems).
Mnemonic names are used by the character-based utility called ^%IS, which is used by utilities such as ^INTEGRIT and ^%G.
Numeric aliases are used directly by Caché’s OPEN, USE, and CLOSE commands. The use of aliases is the best way to get MSM-like device handling.
If you do not require the use of mnemonic names or numeric aliases, you can still access your devices through either the ^%IS utility or through OPEN, USE, and CLOSE commands. For example, the command OPEN "/dev/rmt0":"R" is perfectly valid, provided that /dev/rmt0 is a valid device on your system.
Pipes are a very effective way of accessing printers and other devices on your machine. See the Caché I/O Device Guide for details on setting up and using pipes.
If you use Caché’s SPOOL device, it might be a good idea to store the ^SPOOL global in an isolated location so that it does not take up space in your production environment. You can then reference this global through a namespace configuration.
See the Caché System Administration Guide for information on configuring devices in Caché.
Automating Caché Backups
Caché backups and restorations are designed to run on live systems. These backups can either be system wide, on a per-database basis, or on globals and routines individually. Automating Caché backups from the OS level can be done with a few considerations. There are four recommended strategies:
An OS scheduler can call into Caché’s backup API, performing Caché’s concurrent backup. Any of Caché’s backup strategies are available through this API, including full, cumulative, and incremental backups. This strategy is recommended for live automated backups.
Caché can be brought down via OS scripting, and then an OS level backup can be run.
Caché’s databases can be frozen while an OS level backup is being performed.
An OS level backup can perform a full backup of a live Caché database. For this strategy, a valid cumulative backup must also be performed immediately after to ensure physical integrity. The Caché backup API can be called here to automate the cumulative backup. The steps for this procedure are as follows:
As a pre-backup command, clear incremental bitmaps:
Set x=$$CLRINC^DBACK(1)Copy code to clipboard
Run the OS backup on the live system
As a post-backup command, perform cumulative backup:
Set x=$$BACKUP^DBACK(Arg1,Arg2,...Arg10)Copy code to clipboard
This option requires that your OS-level backup allow files to change while the backup is being performed. Choose your OS backup software with care.
Restoration of system backups is performed via the character-based utility called ^BACKUP. See the Caché System Administration Guide for more information on the basic backup types, and how to perform them.
Journaling in Caché is very similar to what you are used to in MSM. When used in conjunction with backups, it is the best mechanism for bringing a system as up-to-date as possible after a system failure. Journaling is also used to keep track of your application’s transactions. For information on journaling, see the High Availability Guide.
The Before Image Journaling (BIJ) feature is equivalent to the Caché feature called Write Image Journaling (WIJ). This is automatically enabled on Caché systems. It consists of a single file (unlike MSM that has a separate BIJ file for each bullet proofed volume group) named cache.wij, located in the \cachesys\mgr directory. Its size is not fixed and grows as necessary to accommodate modified blocks.
After Image Journaling is also automatically enabled. Unlike MSM, Caché journal files are created as needed and do not have to be defined in advance. Each time Caché is restarted a new journal file is begun. The “age” at which a journal file is automatically deleted is determined by settings that can be modified in the Management Portal.
A process can enable or disable journaling for itself via the ENABLE and DISABLE line tags of ^%SYS.NOJRN, respectively.
Do not use the Journal All Globals option unless you really need to. Choosing this option will journal every global in your database, which can lead to an extraordinarily large journal file, reduced system performance and increased network traffic if Shadow System Journaling is employed. Temporary globals that can be deleted upon system restart should never be journaled.
It is a good idea to switch your journal files after each backup. This process can be automated.
Under a shadow system journaling configuration, a global READ will access only the local version of the global, unless an extended global reference is used.
Shadow System Journaling
While Caché’s Shadow System Journaling is very similar conceptually to MSM’s Cross-System Journaling, you will find that Caché’s Shadow System Journaling is much more feature-rich. For example, in Caché you have two modes of data transfer available to you:
Fast (previously block-mode) Transmission
The shadow connects to the database server via TCP and captures the live journal flat file.
Acquired transactions are optionally applied to the Shadow machine. Choosing not to apply the acquired transaction is a good way to keep redundant journal files.
Since many transactions are captured at once via a binary journal block, block-mode tends to be quicker than record-mode.
Applied transactions are optionally logged in the shadow machine’s local journal file.
Compatible (previously record-mode) Transmission
The shadow connects to the database server via TCP and captures transactions via packaged strings.
Acquired transactions can be programmatically scanned before applying the transactions. You have access to the following information when scanning:
Address of current record
Transaction type, such as SET or KILL
Global reference, if any
New value to which global is set
Since transactions are captured via packaged strings, record-mode tends to be slower than block-mode.
Applied transactions are optionally logged in the shadow machine’s local journal file.
Record mode shadowing can be employed when differing endian systems are to be linked (e.g. Intel and Sun), unlike block mode shadowing, which is limited to transmissions of the same endian type.
The transport and delivery mechanism differs between MSM and Caché. MSM utilizes a “push” mechanism via DDP -- individual sets and kills are applied as regular cross system updates to the shadow server. Caché instead pulls the data from the primary server to the shadow server via TCP/IP.
The Caché use of native TCP results in benefits such as much improved shadowing performance and easier setup of WAN support. It also allows enhanced capabilities such as shadowing across the Internet and the ability to define multiple shadow servers for each primary server.
Shadowing and Switching from MSM to Caché
Given that MSM Cross System Journaling is implemented using simple DDP cross-system sets and kills (i.e. using extended global references), and Caché supports DDP, a MSM server can in fact shadow to a Caché server. This can be a big help in preparing for a switch over with minimal down time of a production system.
For example, consider the following steps when replacing a MSM Primary/Shadow pair with its Caché equivalent:
Take the MSM shadow off line, back it up, enable journaling (or switch journal spaces if already enabled).
Restore the backup onto the Caché server.
Convert the MSM UCIs to Caché databases (see previous chapters).
Configure DDP between Caché and MSM so that MSM can see the Caché databases.
Configure Cross System Journaling on the MSM shadow to point to the correct databases on the Caché primary.
Enable Cross System Journaling on the MSM shadow.
Updates will then begin to arrive on the Caché primary and will continue to do so. Of course a Caché shadow can be created (using the original Caché databases created in #3 above), and connected to the Caché primary.
Once the systems are stable and a switchover date and time has been set, disable all access to the MSM primary server, allow all updates to filter down to the Caché primary, shut down the MSM servers (to be safe), and then give access to the users to the new Caché primary instead of the old MSM one. The last step maybe as simple as changing an IP address of a server or in the client configuration.
Using this technique can result in a total downtime literally measured in minutes.