Comments on: Oracle GoldenGate Extract Internals, Part II

By: Oracle Golden Gate « Vishal desai’s Oracle Blog

Oracle Golden Gate « Vishal desai’s Oracle Blog — Thu, 24 Feb 2011 00:24:01 +0000

[...] http://www.pythian.com/news/7459/oracle-goldengate-extract-internals-part-ii/ [...]

By: Blogroll Report 22/01/2009 – 29/01/2010 « Coskan’s Approach to Oracle

Blogroll Report 22/01/2009 – 29/01/2010 « Coskan’s Approach to Oracle — Sun, 21 Feb 2010 03:25:37 +0000

[...] 4-Internals of goldengate extract process when ASM is used Alex Fatkulin-Oracle GoldenGate Extract Internals, Part II [...]

By: Oracle GoldenGate Extract Internals, Part III | The Pythian Blog

Oracle GoldenGate Extract Internals, Part III | The Pythian Blog — Wed, 03 Feb 2010 22:29:27 +0000

[...] This is the third post in Oracle GoldenGate Extract Internals series (links to part I and part II). [...]

By: Alex Fatkulin

Alex Fatkulin — Fri, 29 Jan 2010 14:22:20 +0000

Vit,

32K limit sounds like a reasonable assumption as an upper limit for a single call. The stacks when reading from a file system vs ASM are quite different and a small read call is just part of the story as now the Extract have to rely on a dedicated server process to do part of the lifting. There is still an option to sent more than 32K of data by using multiple buffers but this may not yield any tangible improvements unless we’re using network and the latency is high. Alas, the highest value of ASMBUFSIZE is 28672.

Archivelogs are not supported in ALO mode only. Technology-wise I don’t see why there would be any show stoppers in doing this. They also do not support DDL replication in ALO mode so I wonder whether these limitations resulted from a different codepaths used and will be lifted eventually.

By: Vit Spinka

Vit Spinka — Thu, 28 Jan 2010 17:21:32 +0000

I guess the reason for much smaller read in ASM comes from the fact that the :buffer parameter passed to dbms_diskgroup.read is a RAW, and PL/SQL does not support more than 32k (not even for LONG RAW).
And trying using BLOB ends in “ORA-01220: file based sort illegal before database is open”.
Perhaps they could get around this limitations using x$kffxp, but were not brave enough to handle ongoing metadata changes due to rebalances, failover to secondary extents etc.

On a bit different note – GoldenGate does not support ASM for archivelogs, at least per documentation. Any idea, why? dbms_diskgroup seems to work on them fine…