Sizing Extents Administration Tips

Copyright © Howard Rogers 2001 10/18/2001 Page 1 of 2

Should all extent sizes be the same? Within a given tablespace, the answer to this question is an unqualified and resounding "yes!". Obviously, the SALES table (average new inserts = 10,000 rows per day) should not come in the same sized extents as the STATES_OF_AUSTRALIA table (containing just 8 rows, and last updated approximately 100 years ago!). The former probably could do with 10Mb extents as a minimum; the latter can manage with a single 16K extent (2 blocks being the smallest possible initial extent, and assuming an 8K block database). But if SALES and PURCHASES are stored within the one tablespace, then both ought to have 10Mb extents, otherwise there is a risk of future tablespace fragmentation (see my tip on "What causes tablespace fragmentation, and how do I fix it?"). The sensible rule is simply this: all extents for all segments within a single tablespace should be of exactly the same size. In Oracle 7, this is difficult to achieve, because the tablespace's DEFAULT STORAGE clause will be ignored any time a segment is created with its own, operative, STORAGE clause. In Oracle 8.0, things are a bit easier, because the MINIMUM EXTENT clause cannot be overridden by the segment's STORAGE clause: if a table requests 53K, it gets the MINIMUM EXTENT size instead. Unfortunately, it's not perfect: if a segment requests an extent size larger than the MINIMUM EXTENT, it gets the next biggest multiple of the MINIMUM EXTENT -which again means you now have different extent sizes within the same tablespace. In 8i and above, it's not a problem at all, provided you use Locally Managed tablespaces, with a UNIFORM SIZE clause. Such tablespaces can only allocate same-size extents, whatever the table actually requests. If the request is for 800K when the UNIFORM SIZE is 500K, then the table will acquire two 500K extents -which still leaves all extents at 500K. It doesn't help that Oracle's default PCTINCREASE for a segment (that is, the amount by which successive extents for the same segment will increase by) is 50%. That guarantees odd-sized extents, and thus practically guarantees eventual fragmentation (quite why Oracle ever thought 50% was a sensible default, I'll never know). Never, ever let the default PCTINCREASE apply. Set it to 0 every time you create a tablespace (in the DEFAULT STORAGE clause) or a segment (in the STORAGE clause). Yet another benefit of Locally Managed tablespaces in 8i is that PCTINCREASE can NOT be set -it's zero by implication. So in 8i, provided you are using Locally Managed tablespaces, you don't need to worry about it. There's no particular performance benefit in having consistent extent sizes within a tablespace -it's all to do with simply avoiding fragmentation. And fragmentation is an issue of wasting disk space, not of performance problems. However, the quicker (and more

Sizing Extents Administration Tips

Copyright © Howard Rogers 2001 10/18/2001 Page 2 of 2

inefficiently) you chew through your disk space, the sooner User's start getting errors to the effect that 'SALES is unable to acquire a NEXT EXTENT' -and User's being unable to enter new sales data because the table has (unnecessarily) run out of space is a performance nightmare, big time.