But before we get there, we need to bridge the gap between D&T and blocks.
That bridge comes in the form of two logical constructs that build off of the block physical layer.
Those constructs are SEGMENTS and EXTENTS.
Easy ways to think of these two are as mapping tools. They don't actually store data, they just keep it organized and accessible. In that way, they are not very dissimilar from tablespaces (just at a more granular level).
SEGMENTS
When you type in the syntax to create a table, one thing you have to provide (among others) is a table name. That table name along with the "create table" keywords gives Oracle everything it needs to create a segment.
A segment is registered with the tablespace as the traffic cop for the table. Like a tablespace, a segment has no real space of its own; it is the sum of its parts. However, one thing you can do with a segment is put a limit of how big it can ever get by limiting its extents.
The segment is a critical part of the RDBMS, but it is not one you lose a lot of sleep over right now. You will, over time, find that you want to give some better instructions or definition to your segments, but most of these can be accomplished via ALTER TABLE statements. For now, just try to think of segments as the logical controller of a table (or index, etc.). There are different segment types, but don't worry about those now.
EXTENTS
If segments are the traffic cops, you can think of extents as parking lot attendants and data blocks as actual parking spaces.
So, the traffic cops tell you which parking lot to use and the parking lot attendant tells you where to park in that lot.
(SEGMENT-> EXTENT-> BLOCK)
Now the job of your parking attendant (extents) is to make it easy to park your car.
If the parking lot attendant were a workaholic and liked to operate in crisis mode, he would just tell each car that entered "You park here, you park way over there, you go up to the next level."
But a good parking attendant will want to make life easier for himself and his customers. If you were part of a caravan, you would probably want to park next to other members of your caravan. And the parking attendant would want to make his life easier by handling cars in groups (like maybe 10 at a time) and say "you next ten cars park in slot 1-10" ( parking attendants don't like to start with zero).
This improves allocation. You see, as Oracle puts it "an extent is a specific number of contiguous data blocks allocated for storing a specific type of information."
So instead of allocating space one data block at a time, extents let you allocate a group of datablocks at a time. Though those blocks get allocated (reserved) for a segment (hence a tablespace), they don't actually contain data until you INSERT data into your table (segment).
If you use DICTIONARY MANAGED TABLESPACES (DMT's) you have lots of options on what your initial extent size is (basically how many blocks), what you want your next extent size to be (when you outgrow your current allocation and need room for new rows) and if you want your new extents to grow in a certain pattern (using PCTINCREASE). This does not change the size of extents you've already allocated, just new ones (unless you rebuild using MOVE or something).
So, if you had INTIAL =32k, NEXT=64k, PCTINCREASE=100
then your first extent would be 32k in size, your second would be 64k, your third would be 128k, and your fourth would be 256k, and so on and so on.
As you can see, you would have many different extents of different sizes which can lead to fragmentation and even the possibility that you won't have enough room to even create your next extent (because the size requirement keeps doubling even if you just wanted to add a single row).
Wow, that sounds like it can cause problems, doesn't it? Well, it often does. So why does Oracle allow this to happen?
Because Oracle is an incredibly flexible piece of software. Oracle doesn't give you all these options because the developers (developers wrote it, not DBA's) couldn't figure out what would work best, they did it because they wanted to give you the ability to build your database the way you want to based on your needs.
Unfortunately, too many people don't bother to learn the basics or analyze the implications, they just follow a script they saw somewhere or make some guesses without reviewing them for impact.
Properly used, this flexibility is incredibly powerful. But DMT's have inherent issues that DBA's cannot address. This is basically because of the serial nature in which things HAVE to be allocated.
Oracle has relieved most of this allocation contention by moving allocation management from the entire database to the individual datafiles (where the lines could be a lot shorter). For that and other reasons, almost everybody now uses LOCALLY MANAGED TABLESPACES (LMT's).
---------------------------
To summarize, table data management is the responsibility of the table's SEGMENT (logical) which employs EXTENTS (logical) to marshal BLOCKS(physical).
So, how do segments and extents relate to tablespaces and datafiles?
We know that datafiles and blocks are physical constructs while the other three are logical constructs.
Datafiles consist of one or more blocks (I've never seen a single block datafile, but I guess it's possible).
Tablespaces contain one or more segments (a tablespace can contain many tables and indexes).
If you've studied "create tablespace" and "create table" statements, you've seen that each allows for the storage clause (INITIAL, NEXT, MINEXTENTS, MAXEXTENTS, and PCTINCREASE, etc.). This is so you can setup defaults for all tables at the tablespace level or customize storage at the table level.
Extents always belong directly to the segment, but since segments reside in a tablespace, you have this option to set up storage parameters at the tablespace level if you want.
Ok, hopefully this was understandable because we are about to get to the last piece that will enable us to really start understanding most of what you'll ever need to know about how Oracle works (data blocks). Sounds too good to be true? Stay tuned.
Of course, we will come back to these topics again, but by then you'll be a master.
No comments:
Post a Comment