Managing Tablespaces : #1

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]
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/app/oracle/oradata/ducat/ducat01.dbf' SIZE 50M

• 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
  BLOCKSIZE 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
• 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 file.

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.
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.
• Concurrency and speed of space operations is improved, because space allocations and deallocations modify locally managed resources (bitmaps stored in header files) rather than requiring centrally managed resources such as enqueues Performance is improved, because recursive operations that are sometimes required during dictionary-managed space allocation are eliminated
• When you create a tablespace, if you do not specify extent management, the default is locally managed.

Extent Management

UNIFORM – a specification of UNIFORM means that the tablespace is managed in uniform extents of the SIZE specified.

• 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.
• 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

AUTOALLOCATE - a specification of AUTOALLOCATE instead of UNIFORM, then the tablespace is system managed and you cannot specify extent sizes.

• 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
• Tablespaces with AUTOALLOCATE are allocated minimum extent sizes of 64K with a minimum of 5 database blocks per extent

Advantages of Local Management
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

To create a locally managed tablespace give the following command

SQL> CREATE TABLESPACE ducat DATAFILE '/u01/app/oracle/oradata/ducat/ducat01.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

AUTOALLOCATE causes the tablespace to be system managed with a minimum extent size of 64K.
The alternative to AUTOALLOCATE is UNIFORM. which specifies that the tablespace is managed with extents of uniform size. You can specify that size in the SIZE clause of UNIFORM. If you omit SIZE, then the default size is 1M. The following example creates a Locally managed tablespace with uniform extent size of 256K

SQL> CREATE TABLESPACE ducat DATAFILE '/u01/app/oracle/oradata/ducat/ducat01.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K;

To Create Dictionary Managed Tablespace

SQL> CREATE TABLESPACE ducat DATAFILE '/u01/app/oracle/oradata/ducat/ducat01.dbf' SIZE 50M EXTENT MANAGEMENT DICTIONARY;

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.

• Free lists are lists of data blocks that have space available for inserting rows.
• You must specify and tune the PCTUSED, FREELISTS, and FREELIST GROUPS storage parameters.
• MANUAL is usually NOT a good choice

AUTO:  This uses bitmaps to manage free space within segments.

• This is the default.
• 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.
• Bitmaps allow Oracle to manage free space automatically.
• Specify automatic segment-space management only for permanent, locally managed tablespaces.
• Automatic generally delivers better space utilization than manual, and it is self-tuning.

CREATE TABLESPACE ducat DATAFILE '/u01/app/oracle/oradata/ducat01.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL                                                                                       SEGMENT SPACE MANAGEMENT AUTO;

Dictionary Managed Dictionary Managed With this approach the data dictionary contains tables that store information that is used to manage extent allocation and deallocation manually.
The DEFAULT STORAGE clause enables you to customize the allocation of extents.  This provides increased flexibility, but less efficiency than locally managed tablespaces.this example creates a tablespace using all DEFAULT STORAGE clauses.

CREATE TABLESPACE ducat  DATAFILE '/u01/app/oracle/oradata/ducat01.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.

SMON periodically coalesces free space in a dictionary-managed tablespace, but only if the PCTINCREASE setting is NOT zero.
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.

Bigfile Tablespaces (Introduced in Oracle Ver. 10g)
A bigfile tablespace is a tablespace with a single, but very large (up to 4G blocks) datafile. Traditional smallfile tablespaces, in contrast, can contain multiple datafiles, but the files cannot be as large. Bigfile tablespaces can reduce the number of datafiles needed for a database.

• Normal tablespaces are referred to as Smallfile tablespaces.
• Bigfile tablespaces save space in the SGA and control file because fewer datafiles need to be tracked

To create a bigfile tablespace give the following command
SQL> CREATE BIGFILE TABLESPACE ducat DATAFILE '/u01/app/oracle/oradata/ducat/ducat01.dbf' SIZE 50G;
Extending the Size of Tablespace and Datafiles

Method #1

You can extend the size of a tablespace by increasing the size of an existing datafile by typing the following command

SQL> alter database ducat DATAFILE '/u01/app/oracle/oradata/ducat/ducat01.dbf' resize 100M;
This will increase the size from 50M to 100M

Method #2

You can also extend the size of a tablespace by adding a new datafile to a tablespace. This is useful if the size of existing datafile is reached o/s file size limit or the drive where the file is existing
does not have free space. To add a new datafile to an existing tablespace give the following command.

SQL> alter tablespace ducat add datafile '/u01/app/oracle/oradata/ducat/ducat02.dbf' size 50M;

Method #3

You can also use auto extend feature of datafile. In this, Oracle will automatically increase the size of a datafile whenever space is required. You can specify by how much size the file should increase and
Maximum size to which it should extend.
To make a existing datafile auto extendable give the following command

SQL> alter database datafile '/u01/app/oracle/oradata/ducat/ducat02.dbf' auto extend ON next 5M maxsize 500M;

You can also make a datafile auto extendable while creating a new tablespace itself by giving the following command.

SQL> create tablespace ducat datafile '/u01/app/oracle/oradata/ducat/ducat02.dbf' size 50M auto extend ON next 5M maxsize 500M;

To decrease the size of a tablespace

You can decrease the size of tablespace by decreasing the datafile associated with it. You decrease a datafile only up to size of empty space in it. To decrease the size of a datafile give the following
command

SQL> alter database datafile '/u01/app/oracle/oradata/ducat/ducat02.dbf'  resize 30M;

Coalescing Tablespaces

A free extent in a dictionary-managed tablespace is made up of a collection of contiguous free blocks. When allocating new extents to a tablespace segment, the database uses the free extent closest in size to the required extent. In some cases, when segments are dropped, their extents are deallocated and marked as free, but adjacent free extents are not immediately recombined into larger free extents. The result is fragmentation that makes allocation of larger extents more difficult.
You should often use the ALTER TABLESPACE ... COALESCE statement to manually coalesce any adjacent free extents. To Coalesce a tablespace give the following command

SQL> alter tablespace ducat coalesce;

Introduction of Tablespace

Oracle stores data logically in tablespaces and physically in datafiles associated with the corresponding tablespace.
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  undo segments that may be retained beyond a transaction, but are basically used to:
Provide read consistency for SELECT statements that access tables that have rows that are in the process of being modified.
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.

SYSTEM Tablespace

The SYSTEM tablespace is used by the Oracle server to manage the database.
It contains the data dictionary and tables that contain administrative information about the database. These are all contained in the SYS schema and can be accessed only by the SYS user or other administrative users with the required privilege.
Every Oracle database contains a tablespace named SYSTEM, which Oracle creates automatically when the database is created.

• The SYSTEM tablespace is always online when the database is open.
• 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 always contains the data dictionary tables for the entire database.
• This is a permanent tablespace.

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.

SYSAUX Tablespace

This is an auxiliary tablespace to the SYSTEM tablespace. Some components and products that used the SYSTEM tablespace or their own tablespaces in earlier releases of Oracle Database now use the SYSAUX tablespace. Every Oracle Database 10g (or later release) database must have a SYSAUX tablespace.
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.
• ike 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.

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. Each database needs to have a specified default temporary tablespace. If one is not specified, then any user account created without specifying a TEMPORARY TABLESPACE clause is assigned a temporary tablespace in the SYSTEM tablespace!.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.
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.

Undo Tablespaces

This is the undo tablespace used by the database server to store undo information. If a database uses Automatic Undo Management, then it can only use a single undo tablespace at any given time. This tablespace is created at database creation time.
An undo tablespace cannot be dropped if it is being used by any instance or contains any undo information needed to recover transactions
More than one UNDO tablespace can exist in DB, but only one can be active at a time

USERS, DATA and INDEXES Tablespaces

Most Oracle databases will have a USERS permanent tablespace.
This tablespace is used to store objects created by individual users of the database.
This tablespace is used to store user objects and data. If no default tablespace is
specified when a user is created then the USERS tablespace is the default tablespace for all objects created by that user. For the SYS and SYSTEM users, the default permanent
tablespace is SYSTEM.
For large applications, it is often a practice to create a seprate tablespace to store data for the application. In this case the tablespace may be named whatever name is appropriate to describe the objects stored in the tablespace accurately.
Oracle databases having a DATA (or more than one DATA) tablespace will also have an accompanying INDEXES tablespace.

• The purpose of separating tables from their associated indexes is to improve I/O efficiency.
• The DATA and INDEXES tablespaces will typically be placed on different disk drives thereby providing an I/O path for each so that as tables are updated, the indexes can also be updated simultaneously.

Data Dictionary

The Oracle data dictionary is the metadata of the database and contains the names and attributes of all objects in the database. The creation or modification of any object causes an update to the data dictionary that reflects those changes. This information is stored in the base tables that are maintained by the Oracle database, but you access these tables by using predefined views rather than reading the tables directly.

The data dictionary:

• Is used by the Oracle database server to find information about users, objects, constraints,and storage
• Is maintained by the Oracle database server as object structures or definitions are modified
• Is available for use by any user to query information about the database
• Is owned by the SYS user
• Should never be modified directly using SQL

The Data Dictionary consists of two components:

Base Tables: These tables store descriptions of objects in the database.

• These are the first objects created in the data dictionary.These are created when the oracle RDBMS software runs a special script named sql.bsq when a database is created by the CREATE DATABASE command – you do not see the sql.bsq script execute, but it does.
  You should never attempt to write to these tables – never use DML commands to attempt to update base tables directly.
  An example Base Table is IND$ that stores index information.

User-Accessible Views: These views summarize information in the base tables in order to make the information easier for a DBA to use.

• These views are created by the catalog.sql script.
• Using the Oracle Universal Installer to create a database, then the catalog.sql and catproc.sql scripts are run automatically.
• An example data dictionary user-accessible view is TABS – it stores information about tables you create as a system user. TABS is a synonym for the view ALL_TABLES.

The Data Dictionary stores information about all database objects created by system users and information systems professionals including tables, views, indexes, clusters, procedures, functions, synonyms, sequences, triggers and the like. For each object, the Data Dictionary stores:

• Disk space allocation (usually in bytes).
• Integrity constraint information.
• Default values for columns.
• Oracle user names (accounts)
• Privilege and role information for users.
• Auditing information – who has accessed/updated objects.

Data Dictionary Usage

The Data Dictionary is used by the Oracle RDBMS as illustrated in the figure shown below.

DBA: These views display information about objects stored in all schemas (a schema is a logical organization of objects belong to an individual system user). These views are named DBA_xxx where xxx is the object name.Because these views belong to the DBA and were created by the owner SYS so these views not access by public .
Example:
SELECT owner, object_name, object_type
FROM SYS.DBA_OBJECTS;

ALL: These views display "all" information that an individual user of the database is authorized to access – this will include information about your objects as well as information about objects for which you have access permissions.
If you connect to the database, the ALL_xxx views will display all information about objects of all database schemas (if you have access permissions).

SELECT owner, object_name, object_type FROM ALL_OBJECTS;

USER: These views display information that you would most likely want to access.

• These USER_xxx views refer to your own objects in your own schema.
• These views display only rows pertinent to you as a user.
• These views are a subset of the ALL views.
• These rows do not usually display the OWNER column.
  

          SELECT object_name, object_type  FROM USER_OBJECTS;

In general, Data Dictionary Views answer questions about:

• when an object was created,
• Is the object part of another objects,
• who owns the object,
• what privileges do you have as a system user,what restrictions are on an object.

Practice selecting information from the following three views: dba_objects, all_objects, user_objects. You may wish to use the SQL*Plus command DESC to describe the views.Additional queries you may wish to execute to practice accessing parts of the data dictionary:
SELECT table_name, comments
FROM dictionary
WHERE table_name LIKE '%SEGMENTS%';

Dynamic Performance Tables and Views

The Oracle Server records database activity to the Dynamic Performance Tables.
These are complemented by Dynamic Performance Views - virtual tables that exist only in memory when the database is running.

• The tables provide real-time condition information about database operation.
• DBAs use these tables—most ,users should not be able to access these tables.
• The tables cannot be altered – they are fixed and are owned by the user SYS.
• All Dynamic Performance Tables have names that begin with the letters V_$.
• Views of these tables are created along with synonyms that begin with the letters V$.
• Information about the database's datafiles and information about all of the dynamic performance tables and views.

Examples Dynamic Performance Table views:
V$CONTROLFILE: Lists the names of the control files
V$DATABASE: Contains database information from the control file.
V$DATAFILE: Contains datafile information from the control file
V$INSTANCE: Displays the state of the current instance
V$PARAMETER: Lists parameters and values currently in effect for the session
V$SESSION: Lists session information for each current session
V$SGA: Contains summary information on the system global area (SGA)
V$SPPARAMETER: Lists the contents of the SPFILE
V$TABLESPACE: Displays tablespace information from the control file
V$THREAD: Contains thread information from the control file
V$VERSION: Version numbers of core library components in the Oracle server

The DUAL Table

Oracle maintains a table named DUAL that is used by Oracle and by user programs to produce a guaranteed known result such as the production of a value through use of an Oracle defined function.
The table has one column named DUMMY and one row containing the value X.
SYS owns the DUAL table, but all users can select from it.
Selecting from DUAL is useful for computing a constant expression with a SELECT statement, since DUAL has only one row, the constant is returned only once.

Example

SQL> select 1+4 from dual;
       1+4
----------
         5

How the Data Dictionary Is Used

Oracle (internally) accesses information about users, schema objects, and storage structures.
This is done to validate a query executed by a system user.
Validates permission and security.
Verifies that referenced objects in queries actually exist.
Oracle modifies the data dictionary for each DDL statement executed.
Oracle users access the data dictionary as a read-only reference.

General Overview
– DICTIONARY, DICT_COLUMNS

• Schema objects
– DBA_TABLES, DBA_INDEXES, DBA_TAB_COLUMNS,
DBA_CONSTRAINTS

• Space allocation
– DBA_SEGMENTS, DBA_EXTENTS

• Database structure
– DBA_TABLESPACES, DBA_DATA_FILES

Modifying the Data Dictionary:

Only Oracle (SYS) should ever modify the data dictionary.During upgrades to new release versions of the Oracle RDBMS, scripts are provided to upgrade the data dictionary.

Row Chaining and Migrating

Whenever  DML operation performed in oracle database ,there are two situations where a data row may not fit into a single data block:

Row chaining The row is too large to fit into one data block when it is first inserted, or the table contains more than 255 columns (the maximum for a row piece).In this case, Oracle stores the data for the row in a chain of data blocks (one or more) reserved for that segment.Row chaining most often occurs with large rows, such as rows that contain a column of datatype LONG or LONG RAW.Row chaining in these cases is unavoidable.Due to  insertion of a large row in a data block. The row is too large for the left block, so the database chains the row by placing the first row piece in the left block and the second row piece in the right block.

Row Migration  A row that originally fit into one data block has one or more columns updated so that the overall row length increases, and the block's free space is already completely filled.
In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit in a new block.
Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row.The rowid of a migrated row does not change.The left block contains a row that is updated so that the row is now too large for the block. The database moves the entire row to the right block and leaves a pointer to the migrated row in the left block.

When a row is chained or migrated, I/O performance associated with this row decreases because Oracle must scan more than one data block to retrieve the information for the row.

• Row chaining is typically caused by INSERT operation.
• Row migration is typically caused by UPDATE operation