Oracle Scratchpad

OC Glossary

Addenda and Errata for Oracle Core Glossary

Back to Index



p.247  granule (also memory granule): apart from the granule sizes that I listed at 4MB, 8MB, 16MB and 64MB, Charles Hooper has reported 32MB, 128MB and 256MB in; the actual sizes available (and the break points in the size of SGA where the different granule sizes appear) may be highly dependent on platform and Oracle version.


Back to Index


  1. On page 247 the glossary indicates that the possible granule sizes are one of 4MB, 8MB, 16MB, and 64MB depending on the Oracle Database version and the size of the SGA. The statement in the book is more accurate than what is provided by the Oracle Database documentation for 11.2 which states that the granule size is either 4MB or 16MB depending on the size of the SGA. However, limited testing ( ) in Oracle Database indicates that the granule size increases from 64MB to 128MB when the SGA_TARGET parameter is set to 1 byte greater than 32G, and jumps to 256MB when the SGA_TARGET parameter is set to 1 byte greater than 64G. A granule size of 32MB is possible when the SGA_TARGET was set to a value between 8G + 1 byte to 16G. It is completely understandable that the book must be concise in explanations, however, the wording in the book gives the appearance that there are only four possible granule sizes.

    Comment by Charles Hooper — December 27, 2011 @ 11:11 am BST Dec 27,2011 | Reply

    • Charles,

      Thanks for that link.

      I was a little more careful in Chapter 5 where I first mentioned granule sizing and the effects of version and SGA size – I pointed out that there may be other options that I had not yet seen. Since (in the smaller cases) the public redo threads shared a granule with the “fixed SGA” component, it would be interesting to see how large the memory allocations were when the granule size is 256MB.

      On one hand, 256MB is only 0.4% “wasted” memory, on the other hand 256MB does sound quite a lot in absolute terms.

      Comment by Jonathan Lewis — December 28, 2011 @ 8:32 pm BST Dec 28,2011 | Reply

      • Jonathan

        I’ve mentioned that in Glossary comments. Redo log (and other memory regions like java pool) becomes very large with extra-large SGA.

        PS. I think that a second reading of the book before publishing – especially with proper formatting in place – would have eliminated most of the corrections. Not that there’re many of them (which is really great), but it would decrease it to an absolute minimum. Please think about that for the next parts of CBO book :) which, BTW, I would also love to proof-read or author-read or whatever it’s called.
        PPS. And Happy New Year!

        Comment by Timur Akhmadeev — December 29, 2011 @ 8:31 am BST Dec 29,2011 | Reply

        • Timur,

          You’re right, of course. I’ve just re-read your notes on the Glossary and seen your comment about larger granules and 200MB log buffer allocations. I really should have managed to get that back into Chapter 5 and the Glossary, possibly even into Chapter 2.

          I did actually get a chance to re-read the chapters after they had been typeset – with the directive “here’s the next four chapters, could you sign them off by tomorrow evening”. I think a number of the outstanding errors come from my brain knowing what ought to be there even as my eyes read something that was wrong (e.g. cursor_spare_for_time in chapter 7).

          Comment by Jonathan Lewis — December 29, 2011 @ 12:21 pm BST Dec 29,2011

RSS feed for comments on this post.

Comments and related questions are welcome.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Powered by