Re: Golden Gate - cachemgr settings

From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Wed, 14 Feb 2018 08:40:47 -0600
Message-ID: <CAP79kiRjrOQuW+9O2X_5wY3z=Zhaj9RPJu0aU262LsS8yj1ggw_at_mail.gmail.com>



Interesting that you're looking into this as I ran across a metalink note while investigating our GGate setup and severe lag on the EXTRACT.

Goldengate Extract Process appears Stalled Doc ID: 1288165.1

So, I started to set it but then reading about the parameter I became more confused. That doc id recommended a 16G cachemgr size for that issue.

Apparently there's a relationship to cachemgr and the dirtmp area but I'm not sure what it is.

Let us know what you find out.

Chris

On Wed, Feb 14, 2018 at 4:20 AM, Niall Litchfield < niall.litchfield_at_gmail.com> 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
> https://docs.oracle.com/goldengate/1212/gg-winux/
> GWURF/gg_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
> http://www.orawin.info
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Feb 14 2018 - 15:40:47 CET

Original text of this message