Transcript datablocksetc - the Sheffield Hallam University homepage

Physical Design: Building Blocks
• 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
School of Computing and Management Sciences
© Sheffield Hallam University
Oracle Building Blocks
Oracle Building Blocks
I
n
s
t
a
n
c
e
mounts
Database
Relationship between Tablespaces, datafiles and the Database
System Tablespace
System01.dbf
Control files
CONTROL01.CTL
CONTROL02.CTL
Users Tablespace
Data01.dbf
Index Tablespace
Inx01.dbf
RBS Tablespace
rbs01.dbf
rbs02.dbf
Temp Tablespace
Temp01.dbf
Redo Logfiles
Redo01.log
Redo02.log
Database
Creating the database building blocks
System Tablespace
System01.dbf
Init.ora (extract)
……...
control_files =
("e:\ora817\oradata\bsms7\control01.ctl",
"e:\ora817\oradata\bsms7\control02.ctl",
"e:\ora817\oradata\bsms7\control03.ctl")
……..
Control files
CONTROL01.CTL
CONTROL02.CTL
Redo Logfiles
Redo01.log
Redo02.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.
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.
Temp Tablespace
Temp01.dbf
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
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
create table grades(g_id integer, Grade varchar2(12)) PCTFREE 20 PCTUSED 60;
• 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
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.
Freed up space
• 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
Data blocks
Update Person
Set Address2 = ‘37 Meadow Drive’
Row 1 [before update]
Address2 = null
• 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!