You are on page 1of 3

The right number of Extents

Administration Tips

The "right" number of Extents


If you are using locally managed tablespace in 8i and above (and you should be!), then none of the following discussion relates to you: in locally managed tablespace, it really doesn't matter whether your table acquires 3, 3000 or 30,000 extents. End of discussion. But if you are still using dictionary managed tablespaces, then the number of extents a table acquires does make a difference -just not the one most people think it does. First the myth: some Oracle documentation produced way back in version 3 (or thereabouts)stated that performance would be improved if a segment (i.e., a table or an index) could be fitted into a single large extent. That claim was dubious then, and its utter nonsense now, but you still get people claiming that "one extent is good". They're wrong (for one thing, striving for 1 extent per segment is likely to mean you adopt oddsized extents within a tablespace, and that's a very bad thing to do, as it practically guarantees tablespace fragmentation). Naturally, there sprang up a school of thought that claimed that the number of extents (remember, in dictionary managed tablespace) was totally irrelevant for performance, except when DDL was performed (for example, a "drop table" command). They're wrong too. The truth is that in dictionary managed tablespace, extents allocated to a segment are recorded as inserts into a data dictionary table called UET$ ('used extents'), and as deletions from FET$ ('free extents'). So if a segment acquires a million extents, UET$ has one million new rows added, and 1 million deletes take place on FET$ (and deletes are quite expensive in terms of the amount of rollback and redo they generate). Now millions of rows in any table makes working with it potentially troublesome, but in these two tables there is an immediate problem. Performing DDL on a table (such as dropping it) will require those million rows to be deleted... which means that a 'drop table' command will likely take hours or days to complete. So lots of extents slows down DDL, true enough. But it's worse than that. The UET$ table is actually contained within a cluster (called C_FILE#_BLOCK#). Whenever any cluster is created, it uses a 'size' parameter to estimate the number of complete row sets relating to one cluster key that it will be able to store within an Oracle block. This particular cluster acquires its 'size' parameter when the database is first created, from a script called sql.bsq. Here's the extract from that script, as shipped by Oracle:
CREATE CLUSTER C_FILE#_BLOCK#(TS# NUMBER, SEGFILE# NUMBER, SEGBLOCK# NUMBER)

225 /* CLUSTER STORAGE (INITIAL 20K)


SIZE
Copyright Howard Rogers 2001

KEY

~ 25,

SIZEOF(SEG$)

~ 50, 5 *

SIZEOF(UET$)

/*

AVOID SPACE MANAGEMENT DURING

~ 150 */ IOR I */
Page 1 of 3

29/10/2001

The right number of Extents

Administration Tips

Here we see Oracle (this happens to be a Version 9i sql.bsq, so it may have changed from previous versions) expecting each entry in the cluster to take 225 bytes thats 25 bytes for the cluster key, 50 bytes for the segment record itself, plus 30 bytes per extent entry for that segment, with an assumption that each segment will have no more than 5 extents. Now if there is only one segment per cluster block, then potentially a 4K block could house around 130 extents for that segment (25 bytes for the cluster key, 50 bytes for the segment record itself, plus 130 x 30 bytes for the extent entries in UET$. Thats 3975 bytes in total). Similar maths suggests an 8K system could store around 270 extents In a cluster block if there was only one segment to worry about. To achieve that number of extents within a cluster block, however, youd have to create a segment and allocate all its extents in one sitting, and make sure that nothing else was going on elsewhere in the database. Its therefore unlikely that you would ever be able to squeeze the theoretical maximum number of extents into a single cluster block. The precise number you could manage would depend on the exact circumstances the database encountered during the creation of various segments. Yet the design of the cluster is based around an assumption of 5 extents under whatever Oracle thinks of as typical conditions. So somewhere between 5 and 130 for a 4K system, or 5 and 270 for an 8K system, and the cluster can cope. But if the number of extents exceeds these admittedly vague values, then you'll induce chaining on the cluster. Row chaining is what happens when a single record can't fit within a single Oracle block and it means you have to perform additional I/O to retrieve the full record. Additional I/O means poorer performance. So a humungous number of extents does impact performance, not because the segment acquiring the extents gives a damn, because it doesn't, but because the data dictionary requires additional I/Os to read the relvant cluster efficiently. Now, it is true that you could manually edit sql.bsq before attempting to create a database, and thereby minimise this problem. That's a fairly risky thing to do, though, and most people don't do it, content as they are to accept defaults which Oracle has planned and designed into the system. But even if you did customise sql.bsq, there's another aspect to consider: this data about what extents a segment has is read into the Data Dictionary Cache of the Shared Pool whenever a SQL statement referencing that segment is issued against the database. The Dictionary Cache is of finite size, so Oracle has an ageing mechanism (an LRU List) to determine which segment definitions get aged out in which order. The presence in that cache of a large record from the C_FILE#_BLOCK# cluster will tend to cause space pressure in the Dictionary Cache for starters, and will, on average, cause that record to remain at the MRU end of the cache's LRU List -causing other records to be aged out unnecessarily. Basically, a large number of extents for a segment will distort the normal workings of the

Copyright Howard Rogers 2001

29/10/2001

Page 2 of 3

The right number of Extents

Administration Tips

Data Dictionary Cache -and that will slow down performance for everyone, as their Parse phases take longer to complete. So, aiming for 1 extent is just a waste of time. But exceeding 270 extents or so (for an 8K system) is going to affect things... and the more you exceed 270, the bigger the effect is going to be (300 extents probably won't kill you, but 600 might well be noticeable). There's yet another aspect to consider: way back in Version 6 of Oracle, the maximum number of extents a segment could acquire was absolutely fixed. For a 2K system, it was impossible to acquire more than 121 extents. For a 4K system, the number was 255. And for an 8K system, the maximum was 504 extents. Although the maximum possible number of extents was made unlimited from Version 7 onwards, there were actually good reasons for the old fixed numbers. The problem is the extent map of the segment, which is contained within the segment header block for every segment. That map is consulted whenever DML is performed against a segment, and therefore being able to read it in one I/O has distinct performance advantages over having to read it in multiple I/Os. Guess what: the old hard limits were arrived at precisely because those numbers of extents could be fitted into one Oracle block (hence the reason why the maximum permitted number of extents used to depend on block size). So exceeding the old hard limits is perfectly possible, but doing so slows down DML, because the extent map for that segment now has to be read in multiple passes, not one. In conclusion, therefore, we can say that: 1 extent might be nice, but is totally unnecessary to strive for. The dictionary cluster mechanism suggests that around 5 extents under typical conditions is ideal, but that you can stretch up to possibly 270 extents (for an 8K system). But around 500 extents (again for an 8K system) should be considered an absolute maximum, because of the segment header extent map size issue.

So there is no precise right number of extents its all a bit vague. But its somewhere between 1 and a few hundred. Anything more than that, and performance trouble will be encountered.

Copyright Howard Rogers 2001

29/10/2001

Page 3 of 3

You might also like