0% found this document useful (0 votes)
10 views

Tablespaces guide

Oracle Tablespaces Guide
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views

Tablespaces guide

Oracle Tablespaces Guide
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

Tablespaces vs.

Datafiles
An Oracle database is comprised of tablespaces.

Tablespaces logically organize data that are physically stored in


datafiles.
 A tablespace belongs to only one database, and has at least one
datafile that is used to store data for the associated tablespace.
 The term "tablespaces" is misleading because a tablespace can
store tables, but can also store many other database objects such as
indexes, views, sequences, etc.
 Because disk drives have a finite size, a tablespace can span disk
drives when datafiles from more than one disk drive are assigned to a
tablespace. This enables systems to be very, very large.
 Datafiles are always assigned to only one tablespace and, therefore,
to only one database.

As is shown in the figure below, a tablespace can span datafiles.

Tablespace Types
There are three types of tablespaces: (1) permanent, (2) undo, and (3)
temporary.
 Permanent – These tablespaces store objects in segments that are
permanent – that persist beyond the duration of a session or
transaction.
 Undo – These tablespaces store segments that may be retained
beyond a transaction, but are basically used to:
o Provide read consistency for SELECT statements that access
tables that have rows that are in the process of being modified.
o Provide the ability to rollback a transaction that fails to commit.
 Temporary – This tablespace stores segments that are transient and
only exist for the duration of a session or a transaction. Mostly, a
temporary tablespace stores rows for sort and join operations.

How Many Tablespaces Are Needed for a Database?


Beginning with Oracle 10g, the smallest Oracle database is two
tablespaces. This applies to Oracle 11g.
o SYSTEM – stores the data dictionary.
SYSAUX – stores data for auxiliary applications

In reality, a typical production database has numerous tablespaces. These


include SYSTEM and NON-SYSTEM tablespaces.

SYSTEM – a tablespace that is always used to store SYSTEM data that


includes data about tables, indexes, sequences, and other objects – this
metadata comprises the data dictionary.
 Every Oracle database has to have a SYSTEM tablespace—it is the
first tablespace created when a database is created.
 Accessing it requires a higher level of privilege.
 You cannot rename or drop a SYSTEM tablespace.
 You cannot take a SYSTEM tablespace offline.
 The SYSTEM tablespace could store user data, but this
is not normally done—a good rule to follow is to never allow allow the
storage of user segments in the SYSTEM tablespace.
 This tablespace always has a SYSTEM Undo segment.
The SYSAUX tablespace stores data for auxiliary applications such as
the LogMiner, Workspace Manager, Oracle Data Mining, Oracle Streams,
and many other Oracle tools.
 This tablespace is automatically created if you use the Database
Creation Assistant software to build an Oracle database.
 Like the SYSTEM tablespace, SYSAUX requires a higher level of
security and it cannot be dropped or renamed.
 Do not allow user objects to be stored in SYSAUX. This tablespace
should only store system specific objects.
 This is a permanent tablespace.
All other tablespaces are referred to as Non-SYSTEM. A different
tablespace is used to store organizational data in tables accessed by
application programs, and still a different one for undo information storage,
and so on. There are several reasons for having more than one
tablespace:

 Flexibility in database administration.


 Separate data by backup requirements.
 Separate dynamic and static data to enable database tuning.
 Control space allocation for both applications and system users.
 Reduce contention for input/output path access (to/from
memory/disk).

CREATE TABLESPACE Command


To create a tablespace you must have the CREATE TABLESPACE
privilege.

The full CREATE TABLESPACE (and CREATE TEMPORARY


TABLESPACE) command syntax is shown here.

CREATE TABLESPACE tablespace


[DATAFILE clause]
[MINIMUM EXTENT integer[K|M]]
[BLOCKSIZE integer [K]]
[LOGGING|NOLOGGING]
[DEFAULT storage_clause ]
[ONLINE|OFFLINE]
[PERMANENT|TEMPORARY]
[extent_management_clause]
[segment_management_clause]

As you can see, almost all of the clauses are optional. The clauses are
defined as follows:

TABLESPACE: This clause specifies the tablespace name.


 DATAFILE: This clause names the one or more datafiles that will
comprise the tablespace and includes the full path, example:

DATAFILE
'/u01/student/dbockstd/oradata/USER350data01.dbf' SIZE
10M

 MINIMUM EXTENT: Every used extent for the tablespace will be a


multiple of this integer value. Use either T, G, M or K to specify
terabytes, gigabytes, megabytes, or kilobytes.
 BLOCKSIZE: This specifies a nonstandard block size – this clause
can only be used if the DB_CACHE_SIZE parameter is used and at
least one DB_nK_CACHE_SIZE parameter is set and the integer
value for BLOCSIZE must correspond with one of the
DB_nK_CACHE_SIZE parameter settings.
 LOGGING: This is the default – all tables, indexes, and partitions
within a tablespace have modifications written to Online Redo Logs.
 NOLOGGING: This option is the opposite of LOGGING and is used
most often when large direct loads of clean data are done during
database creation for systems that are being ported from another file
system or DBMS to Oracle.
 DEFAULT storage_clause: This specifies default parameters for
objects created inside the tablespace. Individual storage clauses can
be used when objects are created to override the specified
DEFAULT.
 OFFLINE: This parameter causes a tablespace to be unavailable
after creation.
 PERMANENT: A permanent tablespace can hold permanent
database objects.
 TEMPORARY: A temporary tablespace can hold temporary
database objects, e.g., segments created during sorts as a result of
ORDER BY clauses or JOIN views of multiple tables. A temporary
tablespace cannot be specified for EXTENT MANAGEMENT LOCAL
or have the BLOCKSIZE clause specified.
 extent_management_clause: This clause specifies how the extents
of the tablespace are managed and is covered in detail later in these
notes.
 segment_management_clause: This specifies how Oracle will
track used and free space in segments in a tablespace that is using
free lists or bitmap objects.
 datafile_clause: filename [SIZE integer [K|M] [REUSE]
[ AUTOEXTEND ON | OFF ]
filename: includes the path and filename and file size. .
REUSE: specified to reuse an existing f

NEXT: Specifies the size of the next extent.


 MAXSIZE: Specifies the maximum disk space allocated to the
tablespace. Usually set in megabytes, e.g., 400M or specified as
UNLIMITED.

Tablespace Space Management


Tablespaces can be either Locally Managed to Dictionary
Managed. Dictionary managed tablespaces have been deprecated (are
no longer used--are obsolete) with Oracle 11g; however, you may
encounter them when working at a site that is using Oracle 10g.

When you create a tablespace, if you do not specify extent management,


the default is locally managed.

Locally Managed
The extents allocated to a locally managed tablespace are managed
through the use of bitmaps.
 Each bit corresponds to a block or group of blocks (an extent).
 The bitmap value (on or off) corresponds to whether or not an extent
is allocated or free for reuse.
Local management is the default for the SYSTEM tablespace beginning
with Oracle 10g.
 When the SYSTEM tablespace is locally managed, the other
tablespaces in the database must also be either locally managed or
read-only.
 Local management reduces contention for the SYSTEM tablespace
because space allocation and deallocation operations for other
tablespaces do not need to use data dictionary tables.
 The LOCAL option is the default so it is normally not specified.

 With the LOCAL option, you cannot specify any DEFAULT


STORAGE, MINIMUM EXTENT, or TEMPORARY clauses.

Extent Management
 UNIFORM – a specification of UNIFORM means that the tablespace
is managed in uniform extents of the SIZE specified.
o use UNIFORM to enable exact control over unused space and
when you can predict the space that needs to be allocated for an
object or objects.
o Use K, M, G, T, etc to specify the extent size in kilobytes,
megabytes, gigabytes, terabytes, etc. The default is 1M; however,
you can specify the extent size with the SIZE clause of
the UNIFORM clause.
o For our small student databases, a good SIZE clause value
is 128K.
o You must ensure with this setting that each extent has at least 5
database blocks.
 AUTOALLOCATE – a specification of AUTOALLOCATE instead
of UNIFORM, then the tablespace is system managed and you
cannot specify extent sizes.
o AUTOALLOCATE is the default.
 this simplifies disk space allocation because the database
automatically selects the appropriate extent size.
 this does waste some space but simplifies management of
tablespace.
o Tablespaces with AUTOALLOCATE are allocated minimum extent
sizes of 64K with a minimum of 5 database blocks per extent.

Advantages of Local Management: Basically all of these advantages


lead to improved system performance in terms of response time,
particularly the elimination of the need to coalesce free extents.
Local management avoids recursive space management
operations. This can occur in dictionary managed tablespaces if
consuming or releasing space in an extent results in another
operation that consumes or releases space in an undo segment or
data dictionary table.
 Because locally managed tablespaces do not record free space in
data dictionary tables, they reduce contention on these tables.
 Local management of extents automatically tracks adjacent free
space, eliminating the need to coalesce free extents.
 The sizes of extents that are managed locally can be determined
automatically by the system.
 Changes to the extent bitmaps do not generate undo information
because they do not update tables in the data dictionary (except for
special cases such as tablespace quota information).

Example CREATE TABLESPACE command – this creates a locally


managed Inventory tablespace with AUTOALLOCATE management of
extents.

CREATE TABLESPACE inventory


DATAFILE
'/u02/student/dbockstd/oradata/USER350invent01.dbf'
SIZE 50M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

Example CREATE TABLESPACE command – this creates a locally


managed Inventory tablespace with UNIFORM management of extents
with extent sizes of 128K.
CREATE TABLESPACE inventory
DATAFILE
'/u02/student/dbockstd/oradata/USER350invent01.dbf'
SIZE 50M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;

Possible Errors
You cannot specify the following clauses when you explicitly specify
EXTENT MANAGEMENT LOCAL:
o DEFAULT storage clause
o MINIMUM EXTENT
o TEMPORARY

Segment Space Management in Locally Managed Tablespaces


Use the SEGMENT SPACE MANAGEMENT clause to specify how free
and used space within a segment is to be managed. Once established,
you cannot alter the segment space management method for a tablespace.

MANUAL: This setting uses free lists to manage free space within
segments.
o Free lists are lists of data blocks that have space available for
inserting rows.
o You must specify and tune the PCTUSED, FREELISTS, and
FREELIST GROUPS storage parameters.
o MANUAL is usually NOT a good choice.
AUTO: This uses bitmaps to manage free space within segments.
o This is the default.
o A bitmap describes the status of each data block within a
segment with regard to the data block's ability to have
additional rows inserted.
o Bitmaps allow Oracle to manage free space automatically.
o Specify automatic segment-space management only for
permanent, locally managed tablespaces.
o Automatic generally delivers better space utilization than
manual, and it is self-tuning.

Example CREATE TABLESPACE command – this creates a locally


managed Inventory tablespace with AUTO segment space management.
CREATE TABLESPACE inventory
DATAFILE
'/u02/student/dbockstd/oradata/USER350invent01.dbf'
SIZE 50M
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;

Dictionary Managed
With this approach the data dictionary contains tables that store information
that is used to manage extent allocation and deallocation manually.

NOTE: Keep in mind you will NOT be able to create any tablespaces
of this type in your 11g database. This information is provided in the
event you have to work with older databases.

The DEFAULT STORAGE clause enables you to customize the allocation


of extents. This provides increased flexibility, but less efficiency than
locally managed tablespaces.

Example – this example creates a tablespace using all DEFAULT


STORAGE clauses.

CREATE TABLESPACE inventory


DATAFILE
'/u02/student/dbockstd/oradata/USER350invent01.dbf'
SIZE 50M
EXTENT MANAGEMENT DICTIONARY
DEFAULT STORAGE (
INITIAL 50K
NEXT 50K
MINEXTENTS 2
MAXEXTENTS 50
PCTINCREASE 0);

 The tablespace will be stored in a single, 50M datafile.


 The EXTENT MANAGEMENT DICTIONARY clause specifies the
management.
 All segments created in the tablespace will inherit the default storage
parameters unless their storage parameters are specified explicitly to
override the default.

The storage parameters specify the following:


 INITIAL – size in bytes of the first extent in a segment.
 NEXT – size in bytes of second and subsequent segment extents.
 PCTINCREASE – percent by which each extent after the second
extent grows.
o SMON periodically coalesces free space in a dictionary-
managed tablespace, but only if the PCTINCREASE setting is
NOT zero.
o Use ALTER TABLESPACE <tablespacename>
COALESCE to manually coalesce adjacent free extents.
 MINEXTENTS – number of extents allocated at a minimum to each
segment upon creation of a segment.
 MAXEXTENTS – number of extents allocated at a maximum to a
segment – you can specify UNLIMITED.

UNDO Tablespace
The Undo tablespace is used for automatic undo management. Note the
required use of the UNDO clause within the CREATE command shown in
the figure here.
More than one UNDO tablespace can exist, but only one can be active at a
time.

A later set of notes will cover UNDO management in detail.

TEMPORARY Tablespace
A TEMPORARY tablespace is used to manage space for sort
operations. Sort operations generate segments, sometimes large
segments or lots of them depending on the sort required to satisfy the
specification in a SELECT statement's WHERE clause.
Sort operations are also generated by SELECT statements that join rows
from within tables and between tables.

Note the use of the TEMPFILE instead of a DATAFILE specification for a


temporary tablespace in the figure shown below.

 Tempfiles are also in a NOLOGGING mode.


 Tempfiles cannot be made read only or be renamed.
 Tempfiles are required for read-only databases.
 Tempfiles are not recovered during database recovery operations.
 The UNIFORM SIZE parameter needs to be a multiple of
the SORT_AREA_SIZE to optimize sort performance.
 The AUTOALLOCATE clause is not allowed for temporary
tablespaces.
 The default extent SIZE parameter is 1M.

Default Temporary Tablespace

Each database needs to have a specified default temporary


tablespace. If one is not specified, then any user account created without
specifying aTEMPORARY TABLESPACE clause is assigned a temporary
tablespace in the SYSTEM tablespace!

This should raise a red flag as you don't want system users to execute
SELECT commands that cause sort operations to take place within the
SYSTEM
tablespace.

If a default temporary tablespace is not specified at the time a database is


created, a DBA can create one by altering the database.

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;

After this, new system user accounts are automatically allocated temp as
their temporary tablespace. If you ALTER DATABASE to assign a new
default temporary tablespace, all system users are automatically
reassigned to the new default tablespace for temporary operations.

Limitations:
 A default temporary tablespace cannot be dropped unless a
replacement is created. This is usually only done if you were moving
the tablespace from one disk drive to another.
 You cannot take a default temporary tablespace offline – this is done
only for system maintenance or to restrict access to a tablespace
temporarily. None of these activities apply to default temporary
tablespaces.
 You cannot alter a default temporary tablespace to make it
permanent.

You might also like