Re: Golden Gate - cachemgr settings

From: Ls Cheng <>
Date: Wed, 14 Feb 2018 17:43:07 +0100
Message-ID: <>


We run OGG in the database server. I am not sure if more memory would actually write trails faster, at least when this happened around 3 years ago after using the 8GB it starts write to dirtmp and the performance wasnt bad neither.

On Wed, Feb 14, 2018 at 1:26 PM, Neil Chandler <> wrote:

> 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
> *Cc:* ORACLE-L
> *Subject:* Re: Golden Gate - cachemgr settings
> Hi
> 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.
> Thanks
> 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
> parameters017.htm#GWURF413 " 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 - 17:43:07 CET

Original text of this message