Re: Golden Gate - cachemgr settings

From: Neil Chandler <>
Date: Wed, 14 Feb 2018 12:26:29 +0000
Message-ID: <HE1PR1001MB12434979FE95C7890825171185F50_at_HE1PR1001MB1243.EURPRD10.PROD.OUTLOOK.COM>

So the main thing about goldengate and memory here is that nothing gets written into a trail file until you type commit. If you have a very large transaction, you're going to need a lot of memory to retain it in RAM. And Goldengate will take that RAM - it's very hungry.

Are you running GG on the database server, or on its own server?

I don't know if GG frees-up memory when writing the transaction down for Bounded Recovery - I'll setup a test case to check that later today - but I suspect it doesn't as when performing a BR recovery from a failed extract it loads from the BR files into memory.

Neil Chandler

From: <> on behalf of Ls Cheng <> Sent: 14 February 2018 10:42
To: Niall Litchfield
Subject: Re: Golden Gate - cachemgr settings


I set it to 4G - 8G. The default value is way too much, a few years ago it caused server swapping and node evictions in one of RAC installations because huge transactions (50 million rows update transaction) are cached in memory which is way too much.


On Wed, Feb 14, 2018 at 11:20 AM, Niall Litchfield <<>> wrote: Hi all

We're in the process of implementing Golden Gate. We've observed that by default on 64bit systems Golden Gate wants 64GB of memory for cache. From " 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 "

Reserving 64G of ram for Golden Gate seems an extraordinarily large amount, especially on a system where multiple GG processes might be running. Similarly allowing this memory to swap out seems to rather negate the purpose of a cache :). There's a repeated warning in the docs not to control this without contacting Oracle Support for guidance. Our engagement with Oracle Support hasn't exactly been stellar - they're happy to look at individual cases, but general guidance isn't really in their remit.

So, for folks out there using GG, do you set the CACHESIZE parameter to control GG memory usage, if so how? Is it really on a case by case basis. If not do you observe GG really using 64g ram for cache?


Niall Litchfield
Oracle DBA

-- Received on Wed Feb 14 2018 - 13:26:29 CET

Original text of this message