环境

服务器及产品支持情况见：Oracle Fusion Middleware Supported System Configurations

ogg进程内存容量配置：CACHEMGR (oracle.com)

• 此处将ogg12c的内存配置情况，及修改方法贴出：

CACHEMGR

Valid For

Extract and Replicat, all databases except DB2 on z/OS

Description

Use the CACHEMGR parameter to control the amount of virtual memory and temporary disk space that is available for caching uncommitted transaction data.

Caution:

Before changing this parameter from its default cache settings, contact Oracle Support for guidance. The cache manager of Oracle GoldenGate is internally self-configuring and self-adjusting, and most production environments will not require changes to this parameter. You can, however, specify the directory for the page files without assistance.

About Memory Management

Note:

While described as accurately as possible here, the underlying design of the memory management component is always subject to changes that may be required by ongoing product improvements.

Because Oracle GoldenGate replicates only committed transactions, it stores the operations of each transaction in a managed virtual-memory pool known as a cache until it receives either a commit or a rollback for that transaction. One global cache operates as a shared resource of an Extract or Replicat process. The following sub-pools of virtual memory are allocated from the global cache:

• One sub-pool per Extract log reader thread or Replicat trail reader thread for most transaction row data.

• One sub-pool for BLOB data and possibly other large items.

Within each sub-pool, individual buffers are allocated from the global cache. Each buffer contains information that is relative to a transaction that is being processed by Oracle GoldenGate.

The Oracle GoldenGate cache manager takes advantage of the memory management functions of the operating system to ensure that Oracle GoldenGate processes work in a sustained and efficient manner. Within its cache, it makes use of modern virtual memory techniques by:

• Allocating and managing active buffers efficiently.

• Recycling old buffers instead of paging to disk, when possible.

• Paging less-used information to disk, when necessary.

The actual amount of physical memory that is used by any Oracle GoldenGate process is controlled by the operating system, not the Oracle GoldenGate program.

The cache manager keeps an Oracle GoldenGate process working within the soft limit of its global cache size, only allocating virtual memory on demand. (The cache manager does not allocate physical memory, over which it has no control.) System calls to increase the cache size are made only as a last resort and, when used, are always followed by the release of virtual memory back to the system.

The system must have sufficient swap space for each Oracle GoldenGate Extract and Replicat process that will be running. To determine the required swap space:

1. Start one Extract process and one Replicat process.

2. Run GGSCI.

3. View the report file of each running process and find the line PROCESS VM AVAIL FROM OS (min).

4. Round up each value to the next full gigabyte if needed. For example, round up 1.76GB to 2 GB.

5. Multiply the rounded-up Extract value by the number of Extract processes.

6. Multiply the rounded-up Replicat value by the number of Replicat processes.

7. Add the two results, plus any additional swap space required by other Oracle GoldenGate processes and other processes on the system.

   (PROCESS_VM x number_Extracts) + (PROCESS_VM x number_Replicats) +
   (swap_for_other_processes) = max_swap_space_on_system
   

   This sum is the maximum amount of swap space that could be needed for those processes. The actual amount of physical memory that is used by any Oracle GoldenGate process is controlled by the operating system, not the Oracle GoldenGate process. The global cache size is controlled by the CACHESIZE option of CACHEMGR.

Note:

The cache manager is also used internally by Oracle GoldenGate for other purposes besides the BLOB sub-pool and the sub-pool for other transaction data. You may see these additional memory pools when you view the statistics.

When to Adjust CACHEMGR

The memory manager generates statistics that can be viewed with the SEND EXTRACT or SEND REPLICAT command when used with the CACHEMANAGER option. The statistics show the size of the memory pool, the paging frequency, the size of the transactions, and other information that creates a system profile.

Based on this profile, you might need to make adjustments to the memory cache if you see performance problems that appear to be related to file caching. The first step is to modify the CACHESIZE parameter. You might need to use a higher or lower cache size based on the size and type of transactions that are being generated.

It is possible, however, that operating system constraints could limit the effect of modifying any components of the CACHEMGR parameter. In particular, if the operating system has a small per-process virtual memory limit, it will force more file caching, regardless of the CACHEMGR configuration.

See "SEND EXTRACT" and "SEND REPLICAT" for more information.

Viewing Basic Statistics in the Report File

Upon completing its initialization, the cache manager writes the following statistics to the process report file:

CACHEMGR virtual memory values (may have been adjusted)
CACHESIZE: 32G
CACHEPAGEOUTSIZE (normal): 8M 
PROCESS VM AVAIL FROM OS (min): 63.97G
CACHESIZEMAX (strict force to disk): 48G

Where:

• CACHESIZE shows the soft limit of virtual memory that is available to the process for caching transaction data. It is determined dynamically, based on the value of PROCESS VM AVAIL FROM OS (min). It can be controlled with the CACHESIZE option of CACHEMGR.

• PROCESS VM AVAIL FROM OS (min) shows the approximate amount of virtual memory that the process has determined it can use. For internal reasons, this amount may be less than what the operating system shows as being available.

• CACHESIZEMAX (strict force to disk) is derived from PROCESS VM AVAIL FROM OS and CACHESIZE. It can be understood in terms of how the cache manager determines which transactions are eligible to be paged out to disk. Normally, only those whose current virtual memory buffers exceed a specific internal value are eligible to be paged. When the total memory requested exceeds CACHESIZE, the cache manager looks for transactions to write to disk and chooses them from the list of eligible ones. If the eligible ones have been paged to disk already, and the virtual memory in use now exceeds CACHESIZEMAX (strict force to disk), then any transaction that requires additional buffers can be eligible for paging. This guarantees that virtual memory will always be available.

Identifying the Paging Directory

By default, Oracle GoldenGate maintains data that it swaps to disk in the dirtmp sub-directory of the Oracle GoldenGate installation directory. The cache manager assumes that all of the free space on the file system is available. This directory can fill up quickly if there is a large transaction volume with large transaction sizes. To prevent I/O contention and possible disk-related Extract failures, dedicate a disk to this directory. You can assign a name and size to this directory with the CACHEDIRECTORY option of the CACHEMGR parameter. The CACHESIZE option of CACHEMGR sets a soft limit for the amount of virtual memory (cache size) that is available for caching transaction data.

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.

• To use this parameter correctly (other than specifying the directory for the page files), you must know the profile of the system and the kinds of transactions that are being propagated from your applications. In normal environments, you should not need to change this parameter, because the cache manager is self-adjusting. If you feel that an adjustment is warranted, please open an Oracle service request at http://support.oracle.com.

Default

None

Syntax

CACHEMGR {[, CACHESIZE size][, CACHEDIRECTORY path [size] [, ...]]
CACHEMGR CACHEFSOPTION { MS_SYNC | MS_ASYNC } |
}

CACHESIZE size

Sets a soft limit for the amount of virtual memory (cache size) that is available for caching transaction data. On 64-bit systems, the default is 64 GB. On 32-bit systems, the cache size is determined dynamically by the cache manager.

The memory is allocated on demand. By default, the cache manager dynamically determines the amount of virtual memory that is available to it from the operating system and determines the appropriate cache size. The available virtual memory is reported with the PROCESS VM AVAIL FROM OS value in the report file. The CACHESIZE value will be sized down if it is larger than, or sufficiently close to, the amount of virtual memory that is available to the process. However, for systems with large address spaces, the cache manager does no further determination once an internal limit is reached.

The CACHESIZE value will always be a power of two, rounded down from the value of PROCESS VM AVAIL FROM OS, unless the latter is itself a power of two, in which case it is halved. After the specified size is consumed by data, the memory manager will try to free up memory by paging data to disk or by reusing aged buffers, before requesting more memory from the system.

If a transaction's cache virtual memory requirements grow beyond the initial buffer allocation, the additional amount of cache memory that is allocated by the cache manager is determined dynamically based on factors such as the current size of the cached data of this transaction, the size needed for the new data, and the amount of virtual memory that is being used conjointly by all the transactions.

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() system call, such as AIX.

• 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 that which is imposed by the file system, such as maximum file size or number of files. The minimum size is 2 GB, which is enforced. There is no default. Do not use this option unless you must constrain the swap space that is used by Oracle GoldenGate because of resource limitations.

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

CACHEMGR CACHEFSOPTION {MS_SYNC | MS_ASYNC}

Performs synchronous or asynchronous writes of the mapped data in the Oracle GoldenGate memory cache manager.

Example

CACHEMGR CACHESIZE 500MB, CACHEDIRECTORY /ggs/temp 2GB, CACHEDIRECTORY /ggs2/temp 2GB

关于操作系统磁盘空间说明：

来源：1 System Requirements and Preinstallation Instructions (oracle.com)

It is typically more efficient for the operating system to swap to disk than it is for Extract to write temporary files. The default CACHESIZE setting assumes this. Thus, there should be sufficient disk space to account for this, because only after the value for CACHESIZE is exceeded will Extract write transaction cached data to temporary files in the file system name space. If multiple Extract processes are running on a system, the disk requirements can multiply.Allow at least 256 GB of disk space per Extract process for these activities. An allocation of at least 512 GB is preferable.

操作系统交换到磁盘通常比 Extract 写入临时文件更有效。默认的 CACHESIZE 设置假定了这一点。因此，应该有足够的磁盘空间来解决这个问题，因为只有在超过 CACHESIZE 的值之后，Extract 才会将事务缓存数据写入文件系统名称空间中的临时文件。如果系统上正在运行多个 Extract 进程，则磁盘需求可能会成倍增加。每个 Extract 进程至少需要 256 GB 的磁盘空间用于这些活动。最好分配至少 512 GB。 

本文使用环境： 

• ogg服务器：Linux7×64，IP：192.168.10.90，主机名：OggServer
• ogg版本： Oracle GoldenGate Manager for Oracle Version 19.1.0.0.4 OGGCORE_19.1.0.0.0_PLATFORMS_191017.1054 Linux, x64, 64bit (optimized), Oracle 19c on Oct 17 2019 15:21:16
• Oracle db1（源端）：Linux7×64，IP：192.168.10.99，主机名：db1
• Oracle db2（目标端）：Linux7×64，IP：192.168.10.98，主机名：db2
• Oracle版本：源端：19.3，目标端：19.3

场景

在单独服务器上安装部署ogg服务，将db1端的Oracle数据实时同步至db2端，包括DML,DDL。

OGG环境部署

1 服务安装

安装包下载位置：https://www.oracle.com/middleware/technologies/goldengate-downloads.html

1.1 创建用户和目录

组

> groupadd oinstall

用户

> useradd -g oinstall oracle
> passwd oracle

目录

> mkdir /ogg/oraclient -p
> mkdir /ogg/ogg191
> mkdir /ogg/oraInventory
> chown oracle:oinstall -R /ogg
> chmod 775 -R /ogg

2.2 配置环境变量

#Oracle客户端安装目录，环境变量名必须为ORACLE_HOME，ogg默认读取此环境变量
export ORACLE_HOME=/ogg/oraclient/instantclient_11_2
#ogg服务
export GG_HOME=/ogg/ogg191
#ogg服务ggsci运行需要的lib包位置，环境变量名需为LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$ORACLE_HOME:$GG_HOME
export PATH=$ORACLE_HOME:$GG_HOME:$PATH
#ogg连接登录数据库别名配置，此文不采用此方法，直接明文配置，故此处环境变量可无
#alias ggsci='cd GG_HOME; ggsci'

2.3 Oracle客户端静默安装

#免安装，解压版直接使用方式
> unzip -d /ogg/oraclient instantclient-basic-linux.x64-11.2.0.4.0

2.4 OGG静默安装

> unzip 19.1.0.0.4-for-Oracle-on-Linux x86-64

> vi /home/oracle/fbo_ggs_Linux_x64_shiphome/Disk1/response/oggcore.rsp#数据库版本
INSTALL_OPTION=ORA19c
#ogg安装位置
SOFTWARE_LOCATION=/ogg/ogg191
START_MANAGER=
MANAGER_PORT=
DATABASE_LOCATION=
#ogg安装日志目录
INVENTORY_LOCATION=/ogg/oraInventory
#ogg安装用户组
UNIX_GROUP_NAME=oinstall

#进入ogg安装目录
> ./runInstaller -silent -showProgress -responseFile /home/oracle/fbo_ggs_Linux_x64_shiphome/Disk1/response/oggcore.rsp

startup mount
alter database archivelog;

2.2 开启强制日志

alter database force logging;

ps：作为目标端，不需要向ogg提供日志数据，不需要配置

2.3 开启数据库最小附加日志

alter database add supplemental log data;

ps：作为目标端，不需要向ogg提供日志数据，不需要配置

1.4 配置参数

alter system set enable_goldengate_replication=true;

1.5 创建OGG用户和表空间

create tablespace ggtbs datafile '+DATA' size 1g autoextend on;

create user ggadmin identified by ggadmin default tablespace ggtbs quota unlimited on ggtbs;

grant connect,resource to ggadmin;
grant alter session to ggadmin;
grant select any dictionary to ggadmin;
grant select any transaction to ggadmin;
grant select any table to ggadmin;
grant flashback any table to ggadmin;
grant alter any table to ggadmin;
exec dbms_goldengate_auth.grant_admin_privilege('GGADMIN','*',TRUE)

> edit param mgr

PORT  7809DYNAMICPORTLIST 7809-8000AUTORESTART EXTRACT *,RETRIES 5,WAITMINUTES 3PURGEOLDEXTRACTS ./dirdat/,usecheckpoints, minkeepdays 3--ACCESSRULE, PROG *, IPADDR 192.168.10.*, ALLOWLAGREPORTHOURS 1
LAGINFOMINUTES 30
LAGCRITICALMINUTES 45

> start mgr

> info all