Temp01.dbf Temp Tablespace Creating the database building blocks SVRMGR> REM ********** TABLESPACE FOR ROLLBACK ********** SVRMGR> CREATE TABLESPACE RBS DATAFILE 'e:\ora817\oradata\bsms7\rbs01.dbf' SIZE 520M REUSE 2> AUTOEXTEND ON NEXT 5120K 3> MINIMUM EXTENT 512K 4> DEFAULT STORAGE ( INITIAL 512K NEXT 512K MINEXTENTS 8 MAXEXTENTS 4096); Statement processed. SVRMGR> SVRMGR> REM ********** TABLESPACE FOR USER ********** SVRMGR> CREATE TABLESPACE USERS DATAFILE 'e:\ora817\oradata\bsms7\users01.dbf' SIZE 150M REUSE 2> AUTOEXTEND ON NEXT 1280K 3> MINIMUM EXTENT 128K 4> DEFAULT STORAGE ( INITIAL 128K NEXT 128K MINEXTENTS 1 MAXEXTENTS 4096 PCTINCREASE 0); Statement processed. SVRMGR> SVRMGR> REM ********** TABLESPACE FOR TEMPORARY ********** SVRMGR> CREATE TABLESPACE TEMP DATAFILE 'e:\ora817\oradata\bsms7\temp01.dbf' SIZE 72M REUSE 2> AUTOEXTEND ON NEXT 640K 3> MINIMUM EXTENT 64K 4> DEFAULT STORAGE ( INITIAL 64K NEXT 64K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0) TEMPORARY; Statement processed.
Displaying Tablespaces in DBA Studio ALTER TABLESPACE "USERS" ADD DATAFILE 'D:\ORA92\ORADATA\EASTLEA9\USERS02.ora' SIZE 10M
Displaying Datafiles in DBA Studio Note the two USERSnn.??? Files for tablespace USERS
Tablespace building blocks Tablespace Segment Extent Data blocks
Tablespace building blocks Four Types of Segment: –Data Segment Each table has a data segment (excluding clustered). All of the table's data is stored in the extents of its data segment. With partitioned tables, each partition has a data segment. –Temporary Segment as a workspace for and intermediate stages of SQL statement parsing and execution –Rollback Segments holds the old values of data changed by transactions, and provides read consistency –Index Segment does what it says on the box
Tablespace building blocks An Extent is made up from several adjacent data blocks. When Oracle manages the space required by objects within the data file, it does so in Extents, not blocks. When an object, such as a table, is first created, an Extent of the size set using INITIAL (or taking the default from the tablespace settings) is allocated. Set the initial size to be large and you may feel confident that all rows in a table will be stored on contiguous data blocks. This results in rapid data extraction, particularly when a query requires a full table scan. BUT, think of the wasted space! Once allocated, Extents are only relinquished after the table is dropped or truncated (DROP table or TRUNCATE table). If a table is rarely full-table scanned, it makes no difference in terms of query performance whether the table has one Extent or several Extents.
Tablespace building blocks Data blocks are the finest level of granularity A data block is the smallest unit of Input/Output (I/O) used by the database. The block size itself will depend upon several things, including the OS block size, and is set when the database is created and is not altered thereafter. The data block size should be a multiple of the operating system's block size. For a decision support system (DSS) application, it is suggested that you choose a large value for the DB_BLOCK_SIZE. For an OLTP type application, a lower value (e.g., 2k or 4k) is suggested. There is no point in bringing back 32K of data from a disk if the user only needs 2K!
Data blocks Regardless of what the block is being used to store (it could be part of an Extent in a table segment, or an index segment, or any other segment) the data block will be of a set format. The overhead: information about the block (type, count of entries, timestamp, pointers to items in the block, etc.). This is often no more than 100 bytes in size. The data section (or Row Data): contains the rows from the table, or branches of an index. Free Space: the area in a block not yet taken by row data.
Data blocks PCTFREE parameter tells Oracle to stop inserting data when the free space reduces to 20% of fillable space Free space = Block size-overhead-row data Fillable space = Block size-overhead The block is now unusable for insertions, and will remain so until enough rows are deleted to bring the percentage of the block that is filled with rows below the PCTUSED parameter setting. You do not have to set either parameter: Oracle defaults to 10% for PCTFREE and 40% for PCTUSED PCTFREE+PCTUSED < 100 create table grades(g_id integer, Grade varchar2(12)) PCTFREE 20 PCTUSED 60;
Data blocks The free space is contiguous initially, but deletions and updates can fragment the free space in the block. The free space is coalesced by the Oracle when it can. Blocks that are available (free space greater than PCTFREE) have an entry in the “Free list” For an INSERT, Oracle checks a free list for the first available data block and uses it if possible. If the free space in that block is not large enough to accommodate the INSERT statement, and the block >= PCTUSED, Oracle takes the block off the free list After a DELETE or UPDATE statement, checks to see if the space being used in the block is now < PCTUSED. If it is, the block goes on free list Freed up space
Data blocks Row 1 [before update] Address2 = null Update Person Set Address2 = ‘37 Meadow Drive’ Chaining happens when an inserted or updated row is too large to fit in one block. results in multiple block gets for one row of data, causing performance degradation Chaining can happen for very large rows, but you can’t do much about that if your block size is otherwise appropriate!
Data blocks If a row can’t expand because there isnt enough free space it results in row migration Update to Row2 Oracle looks for a block that will take take the entire row and moves the entire row to that block. Rowid remains the same, but a pointer “chains” from the old block to the new one. Requires multiple block gets for one row of data, causing performance degradation Migration can indicate problems with PCTFREE.
Strategy for dealing with Migrates rows Use ANALYZE to establish chained rows Copy those rows out to another temporary table Delete those rows from the original table Insert rows from temporary table back into original table This eliminates migrated rows as migration doesn’t happen on Insert, but only on update Removing chained rows can improve performance, but getting PCTFREE right is more important
Fragmented tablespaces Strategy for managing fragmented tablespace: –Backup the Tablespace –Export the Tablespace objects --->.DMP file –Delete the Tablespace Objects –Recreate objects (with revised storage parameters if required) –Import the object data <---.DMP file Decision to do this is a balance: –Can be problematic in high availability scenarios because the Tablespace needs to be off-line –However, performance gains can be significant
Data blocks Summary of Advantages/ Disadvantages Small (2KB-4KB) + Reduces block contention. - Has relatively large overhead. + Good for small rows, or lots of random access. Medium (8KB) + If rows are of medium size, you can bring a number of rows into the buffer cache with a single I/O. - Space in the buffer cache will be wasted if you are doing random access to small rows and have a large block size. For example, with an 8KB block size and 50 byte row size, you are wasting 7,950 bytes in the buffer cache when doing random access. Large (16KB-32KB) + There is relatively less overhead, thus more room to store useful data. + Good for sequential access, or very large rows. - Large block size is not good for index blocks used in an OLTP type environment,
Sensible design Generally it is good practice to have similar object types in one tablespace, and for those objects to adopt the default storage settings. This eliminates free-space fragmentation When objects of different extent sizes are DROPed, irregular pockets of blocks scatter the tablespace, and need to be coalesced Same size Extents mean all freed space will be immediately reusable Adding the TEMPORARY clause to your Temp tablespace effectively creates a single sort segment. Extent size should be >= SORT_AREA_SIZE memory allocation in init.ora OLD WIVES TALE: Having many extents for one object is bad –Actually, performance can improve because of the spreading of I/O If in doubt: TEST!