Extract On Restart While In Recovery Runs Slower Using Lots Of Virtual Memory / Disk File Caching (Doc ID 1478958.1)

Last updated on OCTOBER 03, 2016

Applies to:

Oracle GoldenGate - Version 10.0.0.0 to 11.2.1.0.3 [Release 10.0.0 to 11.2]
Information in this document applies to any platform.

Symptoms

Extract runs slower on restart and uses lots of virtual memory (swap) / disk file caching.

-- ggsci> send <extract name>, status would indicate "In recovery"

Sending STATUS request to EXTRACT EJ1 ...
EXTRACT EJ1 (PID 8581)
  Current status: In recovery[1]: Processing data with empty data queue

-- ggsci> send <extract name>, cachemgr cst would indicate "vm current" higher than the "cache size",
"disk caching" a non-zero value, "Cumulative Stats For Cache Pool" a high value for "trans active"

eg.

GGSCI (zzipdb01.apple.com) 1> send ej1 cachemgr cst
Sending CACHEMGR request to EXTRACT EJ1 ...

CACHE MANAGER VM USAGE
vm current     =  55.99G   vm anon queues =      0
vm anon in use =  55.98G   vm file        =   5.82M
vm used max    =  55.99G   ==> CACHE BALANCED

CACHE CONFIGURATION
cache size       =  32G   cache force paging = 55.99G
buffer min       =  64K   buffer highwater   =   4M
pageout eligible size =   4M

CACHE File Caching
disk current   =      0    disk total  =      0
disk caching   =  10.32M   file cached =   4.83M
file retrieves =   3.36M

CUMULATIVE STATS FOR CACHE POOL #8
POOL INFO   group: ej1  id: p8581_ORA-LOB-MEMPOOL  instance: 0  tid: (nil)
trans active  =    2.88M  trans concurrent (max) =     0

Issue is seen when there are lots of committed transactions between "Recovery Checkpoint" and "Current Checkpoint" for tables with LOBS.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms