CACHEMGR

Valid For

Extract for all databases.

Description

Use the CACHEMGR parameter to specify a non-default file system location for the temporary files needed to hold uncommitted transaction data. The CACHEMGR parameter can also be used to control the amount of virtual memory and temporary disk space that is available for caching uncommitted transaction data. Both of these latter uses are discouraged.

Caution:

Do not change this parameter without consulting Oracle Support. CACHEMGR is internally self-configuring and self-adjusting. It is rare that this parameter requires modification. Doing so unnecessarily may result in performance degradation. It is best to acquire empirical evidence before opening an Oracle Service Request and consulting with Oracle Support.

However, you can specify the directory for the temporary files without assistance

Oracle GoldenGate only replicates committed transactions. Until a COMMIT is received, any transactional data is stored in an area of virtual memory known as a cache. This cache is managed by the CACHEMGR. If the amount of transaction data becomes too great for the virtual memory, then the CACHEMGR writes some of the cached data to temporary files on disk.

Your systems should have sufficient operating system swap and page file space. Oracle recommends a minimum of 512GB.

Identifying the Paging Directory

By default, Oracle GoldenGate maintains the transaction data that it swaps to disk a sub-directory of the Oracle GoldenGate installation directory. CACHEMGR assumes that all of the free space on the file system is available. This directory may fill up quickly if there is a large transaction volume with large transaction sizes. To prevent I/O contention and possible disk-related failures, dedicate a disk to this directory. You can assign directory location with the CACHEDIRECTORY option of the CACHEMGR parameter. A size can also be assigned. However, this is discouraged and should only be done after consulting Oracle Support.

Guidelines for Using CACHEMGR

  • This parameter is valid for all databases supported by Oracle GoldenGate.

  • At least one argument must be supplied. CACHEMGR by itself is invalid.

  • Parameter options can be listed in any order.

  • Only one CACHEMGR parameter is permitted in a parameter file.

Default

None

Syntax

CACHEMGR {
[CACHEDIRECTORY path [size] [, CACHEDIRECTORY path [size] [, ...],]
CACHESIZE size
}
CACHEDIRECTORY path [size]

Specifies the name of the directory to which Oracle GoldenGate writes transaction data to disk temporarily when necessary. The default without this parameter is the dirtmp sub-directory of the Oracle GoldenGate installation directory. Any directory for temporary files can be on an Oracle Database file system, but cannot be on a direct I/O or concurrent I/O mounted file system that does not support the mmap() or MapViewOfFile() system calls, like AIX.

On Microservices Architecture (MA), the temporary file location is $OGG_VAR_HOME/temp.

On Classic Architecture, the temporary file location is $OGG_HOME/dirtmp.

  • path is a fully qualified directory name.

  • size sets a maximum amount of disk space that can be allocated to the specified directory. The upper limit is imposed by the file system, such as the maximum file size or number of files. The minimum size is 2 GB, which is enforced. There is no default. Oracle discourages the use of the size option and you should only it when in consultation with Oracle Support.

You can specify more than one directory by using a CACHEDIRECTORY clause for each one. The maximum number of directories is 100.

The value can be specified in bytes or in terms of gigabytes, megabytes, or kilobytes in any of the following forms:

GB | MB | KB | G | M | K | gb | mb | kb | g | m | k

CACHESIZE size

Sets a soft limit for the amount of virtual memory (CACHESIZE) that is available for caching transaction data. You can internally adjust the CACHESIZE using CACHEMGR as necessary.

If you feel that the default CACHEMGR configuration and internal self-adjustment is adversely affecting your system performance, then you should open a Service Request with Oracle Support. It is best to have acquired empirical data showing the problem symptoms in question to aid in configuring a new default.

The memory used by COM, whether or not limited by CACHESIZE size, will not get released back to the OS after it is allocated to the Extract process.

For example, if a large transaction causes 64GB of memory to be taken by COM, this memory will not get released back to the OS. However, if it is not actively being used by Extract, then the operating system could choose to swap it out, but there must be sufficient swap configured to make it work.

Example

CACHEMGR CACHEDIRECTORY /net/d4atd/ggs/temp