Extract On Restart While In Recovery Runs Slower Using Lots Of Virtual Memory / Disk File Caching
(Doc ID 1478958.1)
Last updated on JANUARY 22, 2018
Applies to:Oracle GoldenGate - Version 10.0.0.0 to 184.108.40.206.3 [Release 10.0.0 to 11.2]
Information in this document applies to any platform.
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: 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"
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 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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!