GoldenGate FUNCTIONSTACKSIZE: The Parameter You’ve Never Heard Of

Every so often, Oracle GoldenGate throws an error at you that makes you stop and say, “Wait… what parameter?” That happened to me recently, and the culprit was a parameter called FUNCTIONSTACKSIZE. If you spend your days replicating small, narrow tables, odds are you’ll never run into it. But the moment you work with a wide table, this little-known parameter can stop an extract dead in its tracks.

What is FUNCTIONSTACKSIZE?

FUNCTIONSTACKSIZE is a parameter that is valid for both Extract and Replicat processes. Its job is to control the size of the memory stack that GoldenGate uses when processing column-conversion functions. Think of it as a scratchpad in memory that holds the arguments being passed to and from GoldenGate while it works through the columns of a record.

A few quick facts about it:

• It works with both Extracts and Replicats
• The default value is 200
• Oracle’s documentation says you should never need to adjust it

That last point is what makes this parameter interesting. “Never” turns out to be a strong word.

How I Ran Into It

I was working with a client on unloading data to an EXTFILE. Nothing fancy — a straight data dump, all inserts, no transformations, no mappings, no functions of any kind. Then the extract abended with this message:

Not enough stack space. Specify FUNCTIONSTACKSIZE greater than 200

My first reaction was confusion. I had never seen this message before, and when I checked the documentation, the reference to “column-conversion functions” only added to it. We weren’t converting anything. No SQLEXEC, no @functions in the parameter file, nothing.

So we took a step back and looked at the table itself. That’s where the answer was hiding: the table had more than 230 columns.

The Misleading Part of the Error

Here’s the thing that tripped me up, and it will probably trip you up too. When you read “column-conversion functions,” you naturally assume GoldenGate is complaining about some transformation you’ve defined. In reality, GoldenGate uses that internal function stack simply to process the columns on the record — effectively, it’s counting columns.

So the mental translation is simple:

• “Column-conversion function” = column processing
• More columns on the table = more stack space needed
• More than ~200 columns with the default setting = abend

The default of 200 lines up suspiciously well with a 230+ column table blowing past it.

The Fix

The fix was refreshingly simple. We added one line to the extract parameter file:

FUNCTIONSTACKSIZE 1000

After restarting the extract, everything processed cleanly. By raising the stack size, we gave GoldenGate enough memory to hold all 230+ columns during processing, and the data unload completed without further issue.

Here’s roughly what the flow looked like:

Wide table (230+ cols) --> Extract --> FUNCTIONSTACKSIZE stack (default 200) --> ABEND

Wide table (230+ cols) --> Extract --> FUNCTIONSTACKSIZE 1000 --> EXTFILE (success)

Takeaways for the DBA

A few things worth filing away from this experience:

• FUNCTIONSTACKSIZE exists, defaults to 200, and applies to both Extracts and Replicats
• The “column-conversion functions” wording in the error is misleading — you don’t have to be using any conversion functions to hit it
• Wide tables (roughly 200+ columns) are the real trigger
• The fix is a one-line parameter change and a restart

Even parameters Oracle says you’ll “never need to adjust” have their day. If you’re replicating or unloading wide tables with GoldenGate, keep FUNCTIONSTACKSIZE in your back pocket.

Enjoy!

Please follow and like: