.1
CSCI315 Database Design and Implementation
Experiment 3.1
How to create and how to manage tablespaces ?
Experimented and described by Dr. Janusz R. Getta
School of Computer Science and Software Engineering, University of Wollongong, Australia,
Bldg. 3, room 210, phone +61 02 42214339, fax +61 02 42214170,
e-mail: jrg@uow.edu.au, Web: http://www.uow.edu.au/∼jrg, Msn: jgetta, Skype: jgetta007
Table of contents
Step 0 How to begin and what you need to know before you start ?
Step 1 How to find the parameters of a tablespace ?
Step 2 How to create a database object in a tablespace ?
Step 3 How to change a status of a tablespace ?
Step 4 How to make a tablespace unavailable to the database users ?
Step 5 How to find the operating system files a tablespace consists of ?
Step 6 How to make a tablespace autoexensible ?
Step 7 How to determine the parameters of an autoexensible file ?
Step 8 How to find the size of a segment (relational table, index) ?
Step 9 How to clean up after the experiment ?
References
Actions
Step 0 How to begin and what you need to know before you start ?
0
These are the specifications of the homeworks in a subject Database Design and Implementation
(CSCI315) delivered in January 2009 at Singapore Institute of Management by Dr. Janusz R. Getta
3-1
Experiment 3.1: How to create and how to manage tablespaces ?
3-2
A printable copy of this experiment in pdf format is available here .A tablespace is a logical
component of a database. The system stores the database objects such as relational tables,
indexes, materialized views, clusters, etc in the tablespaces. A tablespace is implemented as
a collection of one or more operating system files. A data file is associated with only one
tablespace and with only one database. The system automatically creates a data file when
a tablespace is created. The system automatically extends a data file when a tablespace is
extended and it shrinks a data file when a tablespace is shrinked. An amount of persistent
storage (disk space) allocated for a data file is equal to amount of disk space required for
a tablespace plus an overhead required for a file header. All data included in the database
objects (relational tables, indexes, etc) in a tablespace is physically stored in one or more of
the data files that form a tablespace. There is no direct relationship between the database
objects and the specific data files. For example, a relational table can be stored in many data
files whose disk space contributes to the total area of a tablespace. When a relational table
grows then the new rows can be located in any of the data files depending on the available
space. This why it is possible that database objects span over one or more data files. The
internal storage structures of a sample UNIVERSITY database are visualised here .The system supports 3 types of tablespaces: (1) permanent tablespaces, (2) temporary tablespaces,
and (3) undo tablespaces. ”Permanent tablespaces” are used to store the database objects
like relational tables, indexes, clusters, materialized views, etc. ”Temporary tablespaces” are
used to store the database objects only for a period of ”lifetime” of the database transactions
that created the objects. For example, a temporary tablespace may contain the intermediate
results from the query processing. The intermediate results are removed when the processing of a query is finished. ”Undo tablespaces” are used to store undo data created by the
database transactions that change the contents of a database, For example, all rows deleted
from a relational table are stored in undo tablespace because a user may wish to reverse
the deletions with ROLLBACK statement. At a logical level all permanent tablespaces are the
containers for the database objects. However, a way how different types of tablespaces are
implemented and how persistent storage is allocated and managed within the tablespaces is
different for each type of permanent tablespaces. The system supports 2 types of permanent tablespaces: (1) locally managed tablespaces and (2) dictionary managed tablespaces.
A ”locally managed tablespace” stores all information about the allocated and free extents
of persistent storage it consists of inside the tablespace itself. All extents (components) of
persistent storage are of the same fixed size in a locally managed tablespace. The bitmaps
are used used to determine a status (either free or allocated) of the extents. A ”dictionary
managed tablespace” stores all information about the allocated and free extents of persistent storage it consists of inside a data dictionary. To determine a status (either free or
allocated) of an extents the system must access a data dictionary, It ”costs” the execution
of one or more SELECT statement. This is why, the access to dictionary managed tablespaces
is slower than access to locally managed tablespaces. On the other hand, dictionary managed tablespaces allow for allocation of variable size extents of persistent storage and allow
for specificaton of the individual storage allocation strategies for each tablespace. In this
subject we shall use only ”locally managed tablespaces”. Every database must have two
Experiment 3.1: How to create and how to manage tablespaces ?
3-3
mandatory tablespaces: SYSTEM and SYSAUX . A tablespace SYSTEM is permanent and it contains data dictionary. A tablespace SYSAUX is also permanent and it contains information
additional to data dictionary about the database applications and operational data for the
internal performance evaluation tools. Both SYSTEM and SYSAUX tablepaces are treated by
the system in a different way from the other tablespaces, e.g. they cannot be renamed or
dropped. Information about all tablespaces and the data files they consist of is included in
a data dictionary view DBA_TABLESPACES . It is explained in the next step how to access
this information.A tablespace can be in either ONLINE , or OFFLINE , or READ ONLY state.
If a tablespace is in ONLINE state then it is available for both read and write operations.
Obviously, a status READ ONLY means that no write operations are allowed on a tablespace.
For example. a tablespace should be in a read only state in a situation when it is backed up
in order to avoid the possible inconsistencies. If a status is OFFLINE then a tablespace it is
not accessible at all. For example, a tablespace is put in an offline state in a sitiation when
it is transported between the persistent storage devices. Turn the system on. Download and
uncompress SQL scripts used in Homework 3. Use cd command to navigate to a folder
where the downloaded and uncompressed SQL scripts are located. Start SQL*Plus client
in a way described in either Experiment 1.1 for XP operating system or in Experiment 1.2
for Linux operating system or use SQL Developer in a way described in Experiment 1.3.
Connect as a user STUDENT . A password is: student .A script file creatbs.sql contains the
following CREATE TABLESPACE statement:
CREATE TABLESPACE TBS_LOCAL
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 64K
SEGMENT SPACE MANAGEMENT MANUAL
DATAFILE ’C:\ORACLE\ORADATA\SIMDB\TBS_LOCAL01.DBF’
SIZE 2M AUTOEXTEND OFF,
’C:\ORACLE\ORADATA\SIMDB\TBS_LOCAL02.DBF’
SIZE 3M AUTOEXTEND ON NEXT 1M MAXSIZE 10M;
The statement creates a locally managed tablespace TBS_LOCAL .If a type of a tablespace is
not explicitly determined in CREATE TABLESPACE statement then by default it is a locally
managed tablespace. The tablespace consists of two files TBS_LOCAL01.DBF and TBS_LOCAL02.DBF .
Size of the first file is 2 Mbytes and the file is not autoexensible. It means that the file cannot be automatically extended by the system when a tablespace has to grow and the file is
full. Size of the second file ie 3 Mbytes and the file is autoexensible in 1 Mbyte chunks, and
the maximum size of the file is 10 Mbytes. While connected as a user STUDENT , execute a
script file creatbs.sql to create a tablespace TBS_LOCAL .While connected as a user STUDENT ,
execute a script grantquota.sql to grant yourself (a user you are connected as) 5 Mbytes
quota on a tablespace TBS_LOCAL .Finally, while connected as a user STUDENT , execute a
script uquotas.sql to list your nonzero quotas on the existing tablespaces. When prompted,
enter a name of user you are connected as.
Experiment 3.1: How to create and how to manage tablespaces ?
3-4
Step 1 How to find the parameters of a tablespace ?
Information about all parameters of tablespaces is stored in a data dictionary view DBA_TABLESPACES .A
script listalltbs.sql contains a statement that lists the parameters of all tablespaces created in
the system. The script selects the following columns from DBA_TABLESPACES data dictionary
view:
SELECT TABLESPACE_NAME,
BLOCK_SIZE,
STATUS,
CONTENTS,
EXTENT_MANAGEMENT,
ALLOCATION_TYPE,
SEGMENT_SPACE_MANAGEMENT
FROM DBA_TABLESPACES;
While connected as a user STUDENT , execute a script listalltbs.sql . The script lists the
names, block sizes, statuses, contents and some other parameters (we shall ignore them for
a while) of all tablespaces controlled by a database server you are connected to.
Step 2 How to create a database object in a tablespace ?
To create a relational table and to locate it in a given tablespace, a database user must
either make the tablespace his/her default tablespace or attach a clause TABLESPACE to
CREATE TABLE statement. If a tablespace is a default tablespace of a user then each time the
user creates a database object without TABLESPACE clause then such object is located in the
user’s default tablespace. If an object is created with TABLESPACE clause then it is located
in the indicated tablespace. While connected as a user STUDENT , execute the following
CREATE TABLE statement to create a relational table SAMPLE1 in a tablespace TBS_LOCAL .
CREATE TABLE SAMPLE1(
COLUMN1 VARCHAR(30),
COLUMN2 NUMBER(6),
COLUMN3 CHAR(2000),
COLUMN4 CHAR(2000),
COLUMN5 CHAR(2000) ) TABLESPACE TBS_LOCAL;
To verify a location of relational table SAMPLE1 execute a statement:
Experiment 3.1: How to create and how to manage tablespaces ?
3-5
SELECT TABLE_NAME, TABLESPACE_NAME
FROM USER_TABLES;
Remain connected as a user STUDENT . To create an index on the first column of a relational
table SAMPLE1 and to store an index in the user’s default tablespace execute a statement:
CREATE INDEX SAMPLE1_IDX ON SAMPLE1(COLUMN1);
To find a location of index SAMPLE1_IDX execute a statement:
SELECT INDEX_NAME, TABLESPACE_NAME
FROM USER_INDEXES;
To verify that a tablespace listed above is a default tablespace of a user STUDENT execute a
script auser.sql .
Step 3 How to change a status of a tablespace ?
Remain connected as a user STUDENT . To change a status of a tablespace TBS_LOCAL to
READ ONLY execute the following statement:
ALTER TABLESPACE TBS_LOCAL READ ONLY;
To verify the results execute a script listtbs.sql and enter a name of tablespace TBS_LOCAL when
prompted. Next, try to insert a row into a relational table SAMPLE1 located in READ ONLY tablespace:
SELECT *
FROM SAMPLE1;
The system should reply with a message that such and such file cannot be modified at
this time. Remain connected as a user STUDENT . To change a status of a tablespace
TBS_LOCAL back to read/write execute a statement:
ALTER TABLESPACE TBS_LOCAL READ WRITE;
To verify the results execute a script listtbs.sql again to check the present status of the
tablespace. The tablespace should be back in ONLINE state. A tablespace should be placed in
READ ONLY status when we do not want to accidentally destroy data stored in the tablespace
Experiment 3.1: How to create and how to manage tablespaces ?
3-6
or when a table or a group of tables located in the tablespace is about to be exported to
a data file. In the second case READ ONLY status prevents the updates on the tables being
exported and it also preserves the consistency of exported data.
Step 4 How to make a tablespace unavailable to the database users ?
In some situations a tablespace must be excluded from a collection of tablespaces available
to the users. For example, when the files a tablespace consists of should be moved to another
disk drive with a higher capacity we have to block all operations on the tablespace being
moved. Remain connected as a user STUDENT . To take a tablespace OFFLINE , i.e. to make
it unavailable to the users, execute the following statement:
ALTER TABLESPACE TBS_LOCAL OFFLINE;
To verify the results execute a script listalltbs.sql . Next try to select all rows from a
relational table SAMPLE1 located in a tablespace being OFFLINE :
SELECT *
FROM SAMPLE1;
The system should reply with a message that such and such file cannot be read at this time.
To change a status of a tablespace TBS_LOCAL back to ONLINE execute a statement:
ALTER TABLESPACE TBS_LOCAL ONLINE;
Step 5 How to find the operating system files a tablespace consists of ?
A data dictionary view DBA_DATA_FILES contains information about the data file components
of the tablespaces. A script file listfiles.sql lists the paths, names of files, and parameters of
files a given tablespace consists of. While connected as a user STUDENT , execute the script to
list information about the files of a tablespace TBS_LOCAL . For example SELECT statement
given below lists full paths to and the names of files each a tablespace TBS_LOCAL consists
of, internal file identifiers, size of each file, and amount of storage available in each file.
SELECT TABLESPACE_NAME,
FILE_NAME,
FILE_ID,
Experiment 3.1: How to create and how to manage tablespaces ?
3-7
BYTES,
BLOCKS,
AUTOEXTENSIBLE,
MAXBYTES,
MAXBLOCKS,
INCREMENT_BY
FROM DBA_DATA_FILES
WHERE
TABLESPACE_NAME = ’TBS_LOCAL’;
The columns BYTES and BLOCKS determine the size of file. A file can be marked as autoexensible or fixed. If a file is autoexensible then it is automatically extended whenever there is not
enough disk space in a tablespace. Otherwise, it is not extended and an error message is reported to a user. A value of autoexensible indicator is kept in a column AUTOEXTENSIBLE (either YES or NO). If a file is autoextensible then the columns MAXBYTES and MAXBLOCK determine its maximum size and a column INCREMENT_BY determines the size of increment.
Step 6 How to make a tablespace autoexensible ?
Autoextensibilty of a tablespace means that whenever a tablespace is too small to accommodate a new or updated database object then it is automatically extended. In fact it is
not a tablespace, which is extended but one or more of the files it consists of. A value of
AUTOEXTENSIBLE parameter of a data file can be changed with ALTER DATABASE statement.
While connected as a user STUDENT , execute a statement given below to change a value of
AUTOEXTENSIBLE parameter of one of the files a tablespace TBS_LOCAL consists of.
ALTER DATABASE DATAFILE ’C:\ORACLE\ORADATA\SIMDB\TBS_LOCAL01.DBF’
AUTOEXTEND ON;
Execute a script listfiles.sql to verify the results.
Step 7 How to determine the parameters of an autoexensible file ?
It is possible to determine the parameters that more precisely determine the properties of an
autoexensible data file. These parameters include an increment size and maximum size of
an autoexensible file. While connected as a user STUDENT , execute the following statement:
ALTER DATABASE DATAFILE ’C:\ORACLE\ORADATA\SIMDB\TBS_LOCAL01.DBF’
AUTOEXTEND ON
NEXT 2M
MAXSIZE 100M;
Experiment 3.1: How to create and how to manage tablespaces ?
3-8
The statement above makes a data file TBS_LOCAL01.DBF autoexensible with an increment
size equal to 20 Mbytes and the total file size not exceeding 100 Mbytes. Execute a script
listfiles.sql to verify the results.
Step 8 How to find the size of a segment (relational table, index) ?
A tablespace consists of segments of the following types: (1) data segments (relational tables),
(2) index segments (indexes), (3) rollback/undo segments (storage used to keep modified and
uncommitted modified data blocks), and (4) temporary segments (storage used to keep the
results of intermediate operations, sorting, grouping, etc). There is no direct mapping of
segments into operating system files. A segment can be scattered over many data files and
each data file can include many segments. A data dictionary view DBA_SEGMENTS contains
information about the current size of the segment measured as the total number of bytes
and the total number of data blocks and location of a segment in one of the tablespaces. A
script listsegsize.sql finds the total size and location of a given segment. While connected
as a user STUDENT , execute the script to find the size of a relational table ORDERS owned by
a user CSCI315 .For instance, the script uses the following statement to find the total size of
a segment ORDERS owned by a user CSCI315 :
SELECT SEGMENT_NAME,
OWNER,
SEGMENT_TYPE,
BYTES,
BLOCKS
FROM SYS.DBA_SEGMENTS
WHERE SEGMENT_NAME = ’ORDERS’ AND
OWNER = ’CSCI315’;
Execute a script listsegsize.sql to find the size of a relational table SAMPLE1 owned by a
user STUDENT .Execute a script file insrows.sql to insert few rows into a relational table
SAMPLE1 .Re-run a script listsegsize.sql to find the size of a relational table SAMPLE1 .Next,
execute the statements:
DELETE FROM SAMPLE1;
COMMIT;
to delete all rows from a relational table SAMPLE1 and to commit the deletions. Again,
re-run a script listsegsize.sql to find the size of a relational table SAMPLE1 table after the
deletions. Surprise, surprise ! The size of an empty table SAMPLE1 is not zero and even
the size of the segment did not change after the committed deletions ! This is because
Experiment 3.1: How to create and how to manage tablespaces ?
3-9
CREATE TABLE statement pre-allocates certain amount of storage for housekeeping information related to the table and initial amount of storage for data. In an extreme case it is
possible to pre-allocate all storage needed to implement a table if its size can be estimated
in advance. These problems will be more thoroughly discussed in the future.
Step 9 How to clean up after the experiment ?
At the end of the experiment we remove the database objects created so far. While connect
as a user STUDENT execute the following statement:
DROP TABLESPACE TBS_LOCAL INCLUDING CONTENTS AND DATAFILES;
to drop a tablespace TBS_LOCAL . A clause INCLUDING CONTENTS means that all database
objects stored in a tablespace should be dropped before a tablespace is deleted. A clause
AND DATAFLES means the system should delete all data files a tablespace consists of.
References
SQL Reference, CREATE TABLESPACE statement
SQL Reference, ALTER TABLESPACE statement
SQL Reference, DROP TABLESPACE statement
SQL Reference, ALTER USER statement
SQL Reference, CREATE TABLE statement
SQL Reference, CREATE INDEX statement
SQL Reference, INSERT statement
SQL Reference, ALTER DATABASE statement
SQL Reference, SELECT statement
SQL Reference, DELETE statement
Reference, DBA TABLESPACES view
Reference, DBA DATA FILES view
Reference, DBA SEGMENTS view