Вы находитесь на странице: 1из 7

Samson, Mark Kevin L.

Oracle 2/CS32FB1

Mr. Bernard G. Sanidad 2/13/12

Storage Structure and Relationship In an Oracle database, a tablespace consist of one or more data files. At the operating system level, this is all that you seea bunch of disk files. Like a good book, the real elegance and content is between the covers, that is in the data files themselves. Figure 9-1 shows both the physical and logical structure of the database. As you can see, a tablespace itself is composed of segments, which are made up of extents, which are composed of one or more database blocks. A segment is any object in an Oracle database that requires physical storage, such as a table, index, and so on. Types of Segments Table - The table is the most common segment in any Oracle database. You will usually store your data in tables, which are really a collection of columns and rows. While tables can be clustered or partitioned, a table segment is neither. Any segment of table type stores all of its data in a single tablespace and in no particular order. Oracle itself manages the individual data on the blocks, and the DBA, aside from specifying some parameters for the size of extents and the allocation of free space on a block, has little control over where any particular row is stored. Index - An index segment is used to store physical entries associated with an index key defined on a column or columns of a table. The entries can be stored as a B-tree or a bitmap, and are always used to look up the corresponding rows of a table. An index segment is also stored in a single tablespace, and the DBA has relatively little control over how data at the block level is physically organizedOracle maintains the index itself. Cluster - A cluster is a segment on which rows from two or more tables are stored on the same database block. Using clusters enables a DBA to physically co-locate related rows. For example, if you had an Orders table that stored the bill to and ship to address, as well as order number and other information for a sales order, and you also had an OrderDetails table that stored the individual line items that made up the order, using a cluster you can have both tables data stored on the same physical block. This would improve performance when retrieving data from both the Orders and OrderDetails tables since Oracle would only need to read the block once to get data from both tables. Index-organized table -Introduced in Oracle8, an index-organized table is a merger of an index and a table into a single segment. An index-organized table stores data in the order of the index key, much the same way as an index is organized. However, unlike an index where the leaf level

blocks contain the key value and pointers to rows in a table, the leaf level of an index-organized table stores the key value and the values for all other columns in the row. A full table scan of an index-organized table always returns data in the index order, and also does not have to do a second IO operation to retrieve the rest of the columns valuesthey will be stored in the index itself. Index-organized tables are ideally suited to be used for dimension tables in a data warehousing database. Partitions - Oracle introduced partitions in Oracle8. The idea behind partitions was to allow the DBA to physically break up a single table and store part of the data on different tablespaces. In this way, it would be possible for a DBA to predict which rows would be stored on which tablespace, and, consequently, which data files and physical hard disks. This would then enable the DBA to balance out IO among multiple disk drives, as well as overcome any limitations on the maximum size of a hard disk partition or data file. Essentially, you can now have really big tables with many billions of rows, and predict where those rows will be stored. Rollback segment - One of the great advantages of using Oracle over other databases is the capability for one user to read data that someone else is changing. Naturally, the user reading the data does not see what the other user is changing, but rather gets a copy of the way the data looked prior to the start of the modifications. Support for allowing users to see data that is in the process of being changed is handled by rollback segments. Temporary segment - In any database, when users retrieve data, they may want to have that data sorted in a particular way. Oracle performs a sort whenever an ORDER BY, GROUP BY, SELECT ... DISTINCT, or UNION, INTERSECT, or MINUS clause is used in a SQL statement. Sorts may also take place during other operations, such as creating indexes. Oracle always attempts to perform the sort in memory, but if there is not sufficient memory to perform the entire sort, it has the sort spill to disk into the users temporary tablespace. Temporary segments are created whenever a sort spills to disk. These segments are also sometimes referred to as sort segments. LOB segment - If a table contains columns of BLOB, CLOB, or NCLOB datatype (also known as large objects, or LOBs), Oracle stores the data for those columns in a separate segment away from the rest of the data. Typically, columns of these datatypes store data that is quite large, such as images, MP3 files, or even movies. The storage of data in a separate LOB segment occurs if the DBA has configured Oracle to store all LOB data in a separate segment. Oracle also stores LOB data in a separate segment if the data exceeds 4000 bytes, whether or not the DBA, or table

owner, has told it to do so. This is done to ensure that large objects do not decrease performance on full table scans and data reads if the LOB columns are not being referenced. Nested table In Oracle8 and Oracle8i, one of the objects that can be defined in a column of a table is another table, which is known as a nested table. A nested table is only associated with its parent table and cannot be addressed separately. However, because it is a table, Oracle creates a separate segment to store the nested table data. Bootstrap segment - Whenever you boot your computer, there is something called a boot loader that determines where the operating system is and then reads that portion to start the OS and get your computer up and running. Oracles bootstrap segment serves a similar purpose in your database. In each database the bootstrap segment, which is always located in the SYSTEM tablespace, is created by the SQL.BSQ script that is run when you issue the CREATE DATABASE command. It contains information and program units that help to initialize the data dictionary cache and place other information in the SGA when the instance is started. Extent Whenever you create a tablespace, in each of the files that belong to the tablespace Oracle allocates a header blockto store information about the status of the file and the last time it was updated, among other informationand a single free extent for all of the remaining space in the datafile. An extent is one or more contiguous database blocks in a data file. When you create segments, you are allocating space from the free extents of a datafile. Once the space has been allocated to a segment, the extent becomes a used extent and the space within the extent is managed by Oracle as the data for the segment grows. If you DROP or TRUNCATE a segment, the extents that were allocated for it in the datafile are added to the pool of free extents. A single datafile may have many used extents and many free extents at the same time. Frequent allocation and de-allocation of extents can cause fragmentation in the datafile and lead to small free extents that cannot be used by any segmentsa kind of Swiss cheese effect. Automatic and manual allocation of extents Oracle automatically allocates extents to segments when the data for that segment grows and cannot fit into the existing extentsthat is, there is no more room for the data in the existing extent. In order for the new extent to be allocated, Oracle locks the segment while allocating the new extent. While the segment is locked as extent allocation takes place, no users can access its data for read or write

operations until the extent allocation completes. This process of allocating extents automatically can have negative performance consequences and should generally be avoided. Block Space Utilization The smallest unit of storage in Oracle is the database block. A database block can be anywhere from 2KB to 32KB (64KB for a very small number of platforms) and is comprised of one or more operating system blocksusually more. The size of each database block in all tablespaces and datafiles is set at database creation time by the value of the DB_BLOCK_SIZE initialization parameter. The size of the database block cannot be changed after the database is createdif you need to do so, you will need to re-create the database after having exported all of the data. Database block contents Each database block in Oracle is made up of three parts, as shown in Figure 9-3. The first part of the database block is the block header, which consists of the database block address, a list of tables stored on the block (data from more thanone table can be stored on the block if the table was created on a cluster), a list of rows stored on the block, and transaction slots that indicate which transactions are active on which rows on the block. The block header is the top part of the block and grows from the top down, if necessary.

Block space utilization parameters Up to this point you have learned that you can control and configure the allocation of extents for each segment by specifying storage parameters at the tablespace or segment level. Dynamic allocation of extents can be avoided and this will reduce fragmentation at the tablespace level. Oracle also allows you to minimize row chaining and ensure efficient utilization of database blocks for table and index segments (including partitions) by configuring the INITRANS, MAXTRANS, PCTFREE, and PCTUSED block space utilization parameters. Block space utilization parameters must be specified in the STORAGE clause of a segment and cannot be specified in the DEFAULT STORAGE clause of a tablespace. This is because each table or index has different characteristics and, unless your tablespace contains only one table or index, it does not make sense to have the same settings for all segments on the tablespace. You should determine the optimal setting of these parameters before creating the segment. INITRANS - The INITRANS parameter for an index or table segment specifies the initial number of transaction slots to allocate in each block header for the segment. The default value is 1 for a data segment (table, partition, index, and so on) and 2 for a rollback segment. Each transaction that needs to modify data on the block requires a transaction slot, regardless of the number of rows being changed. MAXTRANS - If more transactions need to perform changes to the block than there are available transaction slots as configured using the INITRANS parameter, Oracle allocates additional transaction slots from the free space up to a defined limit set by the value of the MAXTRANS block space utilization parameter. The default and maximum value for MAXTRANS is 255. In fact, the actual real maximum value for MAXTRANS is the physical number of rows that you can fit into a database block since any transaction making changes to data acquires an exclusive lock on the row prohibiting anyone else from making changes to the same block. PCTFREE - In many cases you may create tables that have columns defined using the VARCHAR2 or NVARCHAR2 datatype. These columns, unlike CHAR or NCHAR that always occupy the amount of space on a block specified when the table was created, only require as much space as is needed to store the data. If you make changes to the data using an UPDATE statement, Oracle increases the size of the row and takes some of the space in the free space of the block for the new value. If there is insufficient space left on the block, Oracle chains the row. The PCTFREE block space utilization parameter enables you to define a certain percentage of the space in the block to be left empty so that updates to variable-length columns does not cause a row to be chained. The default value for PCTFREE is 10, that is, Oracle will leave ten percent of the block

space, minus the header, free for future updates. Essentially, what Oracle does is remove the block from the freelist (a list of blocks that can be used for INSERT operations). PCTUSED - Once a block has been taken off the freelist because the amount of free space in the block has fallen below the value configured by the PCTFREE block space utilization parameter, the block will not be placed back on a freelist unless the percentage of used space (that is, space with row data) falls below the value specified by the PCTUSED parameter. The default value for PCTUSED is 40, which means that if the amount of used space on a block falls below 40 percent of the size of the block, less the header, then Oracle places the block on the freelist and allows INSERT operations to occur once again. Any block placed on the freelist as a result of PCTUSED being crossed goes to the top of the freelist and becomes the first one to which INSERT operations will be performed. In this way, Oracle ensures that all of the currently allocated extents for a segment are full of data before allocating new extents. Planning the Location of Segments As a DBA, one of your duties is to ensure that segments are properly placed on tablespaces and that a sufficient number of tablespaces with proper DEFAULT storage clauses exist. The DEFAULT STORAGE clause for each tablespace should be configured to ensure that the segments created on the tablespace inherit appropriate storage parameters. If you use the Database Configuration Assistant, it will automatically create an Optimal Flexible Architecturecompliant database with six tablespaces. This is a good practice to follow because each tablespace should contain data of a similar type. In other words, it is not a good idea to store table segments and index segments on the same tablespace. When you create a database, you should create one tablespace of each of the following type to hold your data: SYSTEMthe SYSTEM tablespace is automatically created with the CREATE DATABASE command. It should not hold any other segments except the data dictionary and other system segments, such as the bootstrap segment and the system rollback segment. DATAYou will create one or more tablespaces to hold table data. These same tablespaces may also be used for clusters and partitioned tables. It is likely that you will create more than one data tablespace as you should keep large tables apart from small tables, as well as those heavily accessed apart from other tables that are also heavily accessed. INDEXAs mentioned earlier, you should keep index segments on separate tablespaces from data segments. In fact, index tablespaces should have datafiles on separate physical disks from the data tablespace datafiles. In this way, you will have more efficient use of disk drives and less chance of the disk becoming a bottleneck.

ROLLBACKRollback segments in an OLTP environment have a lot of activity. For this reason you should have one or more rollback segment tablespaces whose data files are away from the index and data tablespaces, datafiles.

TEMPTemporary segments created when a sort spills to disk, or a temporary table is populated with data, should be created on a tablespace that has been designated as temporary (that is, created with the CREATE TEMPORARY TABLESPACE command). If temporary segments are created on a tablespace designed to hold permanent segments (tables, indexes,and so on), it can potentially cause a lot of fragmentation because they will be created and dropped fairly regularly. Temporary tablespaces should be stored on disk away from DATA, INDEX, and ROLLBACK segments tablespaces.

TOOLSMany applications that run on Oracle need to create segments to support their operation. These segments rarely change after creation and are quite stable. A separate tablespace should be created to hold these segments but, because of the stability of the segments on it, the tablespaces datafiles can be created on the same disk as another tablespace, including SYSTEM.

Different tablespaces, due to the nature of the segments created on them, have different fragmentation characteristics, as shown in Table 9-3. Fragmentation occurs when a segment is dropped or truncated and storage is released back to the tablespace. Because this can have a negative effect on performance, it is generally recommended that tablespaces with high fragmentation propensity be stored on separate physical disks from other tablespaces of the same propensity. Also, segments with high fragmentation propensity should be on tablespaces away from those with a low fragmentation propensity

Вам также может понравиться