School of Computing and Management Sciences © Sheffield Hallam University The slowest task in any record retrieval is reading from disk (It can be 500.

School of Computing and Management Sciences

© Sheffield Hallam University

• The slowest task in any record retrieval is reading from disk (It can be 500 times slower to locate and read from a disk than from the Random Access Memory).

• No matter what the disks spin speed, there will come a point when you need to wait for your turn

• So Oracle will do all it can to reduce trips to the database

Physical Design: Building Blocks

Oracle Building Blocks

Oracle Building Blocks

Instance

Database

mounts

Database

System01.dbf

System Tablespace

Data01.dbf

Users Tablespace

rbs01.dbf

RBS Tablespace

rbs02.dbf

Inx01.dbf

Index Tablespace

Temp01.dbf

Temp TablespaceControl filesCONTROL01.CTLCONTROL02.CTL

Redo LogfilesRedo01.logRedo02.log

Relationship between Tablespaces, datafiles and the Database

System01.dbf

System Tablespace

Control filesCONTROL01.CTLCONTROL02.CTL

Redo LogfilesRedo01.logRedo02.log

SVRMGR> CREATE DATABASE bsms7 2> LOGFILE 'e:\ora817\oradata\bsms7\redo01.log' SIZE 1024K, 3> 'e:\ora817\oradata\bsms7\redo02.log' SIZE 1024K, 4> 'e:\ora817\oradata\bsms7\redo03.log' SIZE 1024K 5> MAXLOGFILES 32 6> MAXLOGMEMBERS 2 7> MAXLOGHISTORY 1 8> DATAFILE 'e:\ora817\oradata\bsms7\system01.dbf' SIZE 264M REUSE AUTOEXTEND ON NEXT 10240K 9> ………..Statement processed.

Init.ora (extract)……...control_files = ("e:\ora817\oradata\bsms7\control01.ctl", "e:\ora817\oradata\bsms7\control02.ctl", "e:\ora817\oradata\bsms7\control03.ctl")……..

Creating the database building blocks

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

Ext

ent

Ext

ent

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 PersonSet 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!