By -
Temporary Tablespaces. Temporary tablespaces are used for special operations, particularly for sorting data results on disk and for hash joins in SQL. For SQL with millions of rows returned, the sort operation is too large for the RAM area and must occur on disk. The temporary tablespace is where this takes place. Adding a File to the Tablespace. There’s two ways to do this via the GUI. We can, from the Actions or Tree Context Menu: Edit the tablespace; Add a datafile; Because I like the ability to see what’s going on whilst I add files, I’m going to show you #1. Click on the Actions button in the editor toolbar, or right-click on the tablespace in.
Check Tablespace Growth in Oracle March 10, 2020 March 10, 2020 Seydi Korurer Leave a comment previously I have realized DBATABLESPACEUSAGEMETRICS view and used for my reports.
Originally authored by Roger Schrag of Database Specialists in 2007, this post was updated in August, 2018.
Sooner or later, every Oracle DBA will encounter the issue of an exhausted temporary tablespace. At least one database session will be affected, and the ‘ORA-1652: unable to extend temp segment’ error message will appear in the alert log. If the error isn’t corrected, the issue will shortly be noticed in other sessions in the database.
Handling temporary tablespace issues is a little different than working with permanent tablespaces. First, it is a shared resource among all users in the database. If one session uses up all the temporary tablespace, all other users that require it for some operation that are assigned to that temporary tablespace will be affected and will eventually get the ORA-1652 error. Second, temporary tablespaces are not recorded in the control file; they can be recreated from a mounted database anytime. They are not needed for recovery.
This white paper will describe what’s behind the temporary tablespace, and how best to manage them, and how to avoid the ORA-1652 error.
What is temporary tablespace and what is it used for?
A temporary tablespace is a special set of files associated with an Oracle database that contain data that is not required for read-consistency or for recovery. There are a few different ways that Oracle utilizes temporary tablespace. The most obvious is for sorting datasets that are too large to fit into memory (the PGA, or Program Global Area), but it is also used for other operations that require non-permanent storage. It is also used for storing information in global temporary tables, which are described later in this paper.
In this paper, we will first briefly review how Oracle manages sorting operations. Next, we’ll discuss how a database administrator can determine if any statements on the database have failed because the temporary tablespace ran out of space, including present two techniques a DBA can use to understand how space in the temporary tablespace is being used and how users are being impacted by a full temporary tablespace. Finally, we’ll describe methods of adding space and trimming temporary tablespaces.
Oracle sorting basics
Oracle sessions begin sorting data in memory. If the amount of data being sorted is small enough, the entire sort will be completed in memory (PGA) with no intermediate data written to disk. When Oracle needs to store data in a global temporary table or build a hash table for a hash join, Oracle also starts the operation in memory and completes the task without writing to disk if the amount of data involved is small enough. While populating a global temporary table or building a hash is not a sorting operation, we will lump all of these activities together in this paper because they are handled in a similar way by Oracle.
If an operation uses up a threshold amount of memory, then Oracle breaks the operation into smaller ones that can each be performed in memory. Partial results are written to disk in a temporary tablespace. The threshold for how much memory may be used by any one session is controlled by instance parameters. If the WORKAREA_SIZE_POLICY parameter is set to AUTO, then the PGA_AGGREGATE_TARGET parameter indicates how much memory can be used collectively by all sessions for activities such as sorting and hashing. Oracle will automatically assess and decide how much of this memory any individual session should be allowed to use. If the WORKAREA_SIZE_POLICY parameter is set to MANUAL, then instance parameters such as SORT_AREA_SIZE, HASH_AREA_SIZE, and BITMAP_MERGE_AREA_SIZE dictate how much memory each session can use for these operations.
Each database user has a temporary tablespace (or temporary tablespace group in Oracle 10g+) designated in their user definition. Whenever a sort operation grows too large to be performed entirely in memory, Oracle will allocate space in the temporary tablespace designated for the user performing the operation. You can see a user’s temporary tablespace designation by querying the DBA_USERS view.
Temporary segments in temporary tablespaces—which we will call “sort segments”—are owned by the SYS user, not the database user performing a sort operation. There typically is just one sort segment per temporary tablespace, because multiple sessions can share space in one sort segment. Users do not need to have quota on the temporary tablespace to perform sorts on disk. In fact, quotas on temporary tablespaces are ignored by Oracle.
Temporary tablespaces cannot hold normal segments like tables or indexes (unless it’s a Global Temporary table). Oracle’s internal behavior is optimized for this fact. For example, writes to a sort segment do not generate redo or undo. Also, allocations of sort segment blocks to a specific session do not need to be recorded in the data dictionary or a file allocation bitmap. Why? Because data in a temporary tablespace does not need to persist beyond the life of the database session that created it.
One SQL statement can cause multiple sort operations, and one database session can have multiple SQL statements active at the same time—each potentially with multiple sorts to disk. When the results of a sort to disk are no longer needed, its blocks in the sort segment are marked as no longer in use and can be allocated to another sort operation.
A sort operation will fail if a sort to disk needs more disk space and there are 1) no unused blocks in the sort segment, and 2) no space available in the temporary tablespace for the sort segment to allocate an additional extent. This will most likely cause the statement that prompted the sort to fail with the Oracle error, ORA-1652: unable to extend temp segment. As mentioned, this error message also gets logged in the alert log for the instance.
It is important to note that not all ORA-1652 errors indicate temporary tablespace issues. For example, moving a table to a different tablespace with the ALTER TABLE…MOVE statement will cause an ORA-1652 error if the target tablespace does not have enough space for the table.
Identifying SQL statements that fail due to lack of temporary space
It is helpful that Oracle logs ORA-1652 errors to the instance alert log as it informs a database administrator that there is a space issue. The error message includes the name of the tablespace in which the lack of space occurred, and a DBA can use this information to determine if the problem is related to sort segments in a temporary tablespace or if there is a different kind of space allocation problem.
Unfortunately, Oracle does not identify the text of the SQL statement that failed. Thus we are informed that a problem has occurred but we are not given tools with which to identify the cause of the problem nor measure the user impact of the statement failure.
However, Oracle does have a diagnostic event mechanism that can be used to give us more information whenever an ORA-1652 error occurs by causing Oracle server processes to write to a trace file. This trace file will contain a wealth of information, including the exact text of the SQL statement that was being processed at the time that the ORA-1652 error occurred. This diagnostic event imposes very little overhead on the system, because Oracle only writes information to the trace file when an ORA-1652 error occurs.
You can set a diagnostic event for the ORA-1652 error in your individual database session with the following statement:
ALTER SESSION SET EVENTS '1652 trace name errorstack';
You can set the diagnostic event instance-wide with the following statement:
ALTER SYSTEM SET EVENTS '1652 trace name errorstack';
The above statement will affect the current instance only and will not edit the server parameter file. That is to say, if you stop and restart the instance, the diagnostic event setting will no longer be active. I don’t recommend setting this diagnostic event on a permanent basis, but if you want to edit your server parameter file, you could use a statement like the following:
ALTER SYSTEM SET EVENT = '1652 trace name errorstack' SCOPE = SPFILE;
You can also set diagnostic events in another session (without affecting all sessions instance-wide) by using the “oradebug event” command in SQL*Plus.
You can deactivate the ORA-1652 diagnostic event or remove all diagnostic event settings from the server parameter file with statements such as the following:
ALTER SESSION SET EVENTS '1652 trace name context off';
ALTER SYSTEM SET EVENTS '1652 trace name context off';
ALTER SYSTEM RESET EVENT SCOPE = SPFILE SID = '*';
If a SQL statement fails due to lack of space in the temporary tablespace and the ORA-1652 diagnostic event has been activated, then the Oracle server process that encountered the error will write a trace file to the directory specified by the user_dump_dest instance parameter. The entry in the instance alert log that indicates an ORA-1652 error occurred will also indicate that a trace file was written. An entry in the instance alert log will look like this:
Tue Jan 2 17:21:14 2007
Errors in file /u01/app/oracle/admin/rpkprod/udump/rpkprod_ora_10847.trc:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
The top portion of a sample trace file is as follows:
Oracle Database 10g Release 10.2.0.2.0 - 64bit Production
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_2
System name: SunOS
Node name: rpk
Release: 5.8
Version: Generic_108528-27
Machine: sun4u
Instance name: rpkprod
Redo thread mounted by this instance: 1
Oracle process number: 18
Unix process pid: 10847, image: oracle@rpk (TNS V1-V3)
*** ACTION NAME:() 2007-01-02 17:21:14.871
*** MODULE NAME:(SQL*Plus) 2007-01-02 17:21:14.871
*** SERVICE NAME:(SYS$USERS) 2007-01-02 17:21:14.871
*** SESSION ID:(130.13512) 2007-01-02 17:21:14.871
*** 2007-01-02 17:21:14.871
ksedmp: internal or fatal error
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
Current SQL statement for this session:
SELECT 'A1'.'INVOICE_ID', 'A1'.'INVOICE_NUMBER', 'A1'.'INVOICE_DAT
E', 'A1'.'CUSTOMER_ID', 'A1'.'CUSTOMER_NAME', 'A1'.'INVOICE_AMOUNT',
'A1'.'PAYMENT_TERMS', 'A1'.'OPEN_STATUS', 'A1'.'GL_DATE', 'A1'.'ITE
M_COUNT', 'A1'.'PAYMENTS_TOTAL'
FROM 'INVOICE_SUMMARY_VIEW' 'A1'
ORDER BY 'A1'.'CUSTOMER_NAME', 'A1'.'INVOICE_NUMBER'
----- Call Stack Trace -----
From the trace file you can clearly see the full text of the SQL statement that failed. You can also see when it failed along with attributes of the database session such as module, action, and service name. It is important to note that the statements captured in trace files with this method may not themselves be the cause of space issues in the temporary tablespace. For example, one query could run successfully and consume 99.9% of the temporary tablespace due to a Cartesian product, while a second query fails when trying to allocate just a small amount of sort space. The second query is the one that will get captured in a trace file, while the first query is more likely to be the root cause of the problem.
The trace file will contain additional information, including a call stack trace and a binary stack dump. This information is not likely to be useful, unless perhaps you want to learn more about Oracle internals.
The diagnostic event facility has been built into the Oracle database product for a very long time, but it is not widely documented. Oracle Support’s position appears to be that you should not use this facility unless directed to do so by Oracle Support. There are certain widely-known diagnostic events such as 10046 for extended SQL trace and 10053 for tracing the cost-based optimizer, and there are certain events that can alter Oracle’s behavior significantly. In general, you absolutely should not try setting diagnostic events in a production database unless you have a very good idea of what they do.
Although I am not aware of an Oracle Support document that officially blesses setting diagnostic event 1652 for identifying SQL statements that fail due to lack of sort space, there are bulletins on Metalink that do show how to set events to dump an error stack for basic Oracle errors. Metalink document 217274.1, for example, shows how to set a diagnostic event for the ORA-942 (“table or view does not exist”) error. We are doing the exact same thing here for the ORA-1652 error, and therefore it seems like a relatively safe thing to do.
Like most debugging or diagnostic facilities, you should only use the ORA-1652 diagnostic event to the extent you really need to. If you regularly get ORA-1652 errors in one batch job and you can add an ALTER SESSION statement to the beginning of the batch job, then doing so would be preferable to setting the diagnostic event at the instance-level. Typically there shouldn’t be a need to set this diagnostic event at the instance level on a permanent basis or in the server parameter file.
Monitoring temporary space usage
Instead of waiting for a temporary tablespace to fill and for statements to fail, you can monitor temporary space usage in the database in real time. At any given time, Oracle can tell you about all of the database’s temporary tablespaces, sort space usage on a session basis, and sort space usage on a statement basis. All of this information is available from v$ views, and the queries shown in this section can be run by any database user with DBA privileges.
Checking for temporary space allocated and in-use
This query (version 12+) will show the current size, allocated space, and free space for all temporary tablespaces in the database.
Version 12:
SELECT * FROM DBA_TEMP_FREE_SPACE;
TABLESPACE_NAME TABLESPACE_SIZE ALLOCATED_SPACE FREE_SPACE
------------------------------ --------------- --------------- ----------
TEMP 20971520 14680064 19922944
Temporary segments
The following query displays information about all sort segments in the database. (As a reminder, we use the term “sort segment” to refer to a temporary segment in a temporary tablespace.) Typically, Oracle will create a new sort segment the very first time a sort to disk occurs in a new temporary tablespace. The sort segment will grow as needed, but it will not shrink and will not go away after all sorts to disk are completed. A database with one temporary tablespace will typically have just one sort segment.
Pre version 11:
SELECT A.tablespace_name tablespace, D.mb_total,
SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free
FROM v$sort_segment A,
(
SELECT B.name, C.block_size, SUM (C.bytes) / 1024 / 1024 mb_total
FROM v$tablespace B, v$tempfile C
WHERE B.ts#= C.ts#
GROUP BY B.name, C.block_size
) D
WHERE A.tablespace_name = D.name
GROUP by A.tablespace_name, D.mb_total;
The query displays for each sort segment in the database the tablespace the segment resides in, the size of the tablespace, the amount of space within the sort segment that is currently in use, and the amount of space available. Sample output from this query is as follows:
TABLESPACE MB_TOTAL MB_USED MB_FREE
------------------------------- ---------- ---------- ----------
TEMP 10000 9 9991
This example shows that there is one sort segment in a 10,000 MB tablespace called TEMP. Right now, 9 MB of the sort segment is in use, leaving a total of 9,991 MB available for additional sort operations. (Note that the available space may consist of unused blocks within the sort segment, unallocated extents in the TEMP tablespace, or a combination of the two.)
Sort space usage by session
The following query displays information about each database session that is using space in a sort segment. Although one session may have many sort operations active at once, this query summarizes the information by session. This query will need slight modification to run on Oracle 8i databases, since the dba_tablespaces view did not have a block_size column in Oracle 8i.
SELECT S.sid || ',' || S.serial# sid_serial, S.username, S.osuser, P.spid, S.module,
S.program, SUM (T.blocks) * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
COUNT(*) sort_ops
FROM v$sort_usage T, v$session S, dba_tablespaces TBS, v$process P
WHERE T.session_addr = S.saddr
AND S.paddr = P.addr
AND T.tablespace = TBS.tablespace_name
GROUP BY S.sid, S.serial#, S.username, S.osuser, P.spid, S.module,
S.program, TBS.block_size, T.tablespace
ORDER BY sid_serial;
The query displays information about each database session that is using space in a sort segment, along with the amount of sort space and the temporary tablespace being used, and the number of sort operations in that session that are using sort space. Sample output from this query is as follows:
SID_SERIAL USERNAME OSUSER SPID MODULE PROGRAM MB_USED TABLESPACE SORT_OPS
---------- -------- ------ ---- ------ --------- ------- ---------- --------
33,16998 RPK_APP rpk 3061 inv httpd@db1 9 TEMP 2
This example shows that there is one database session using sort segment space. Session 33 with serial number 16998 is connected to the database as the RPK_APP user. The connection was initiated by the httpd@db1 process running under the rpk operating system user, and the Oracle server process has operating system process ID 3061. The application has identified itself to the database as module “inv.” The session has two active sort operations that are using a total of 9 MB of sort segment space in the TEMP tablespace.
Sort space usage by statement
The following query displays information about each statement that is using space in a sort segment. This query will need slight modification to run on Oracle 8i databases, since the dba_tablespaces view did not have a block_size column in Oracle 8i.
SELECT S.sid || ',' || S.serial# sid_serial, S.username,
T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
T.sqladdr address, Q.hash_value, Q.sql_text
FROM v$sort_usage T, v$session S, v$sqlarea Q, dba_tablespaces TBS
WHERE T.session_addr = S.saddr
AND T.sqladdr = Q.address (+)
AND T.tablespace = TBS.tablespace_name
ORDER BY S.sid;
The query displays information about each statement using space in a sort segment, including information about the database session that issued the statement and the temporary tablespace and amount of sort space being used. Sample output from this query is as follows:
SID_SERIAL USERNAME MB_USED TABLESPACE ADDRESS HASH_VALUE
---------- -------- ------- ---------- ---------------- ----------
SQL_TEXT
--------------------------------------------------------------------------------
33,16998 RPK_APP 8 TEMP 000000038865B058 3641290170
SELECT * FROM NOTIFY_MESSAGES NM WHERE NM.AWAITING_SENDING = 'y' AND NOT EXISTS
( SELECT 1 FROM NOTIFY_MESSAGE_GROUPS NMG WHERE NMG.MESSAGE_GROUP_ID = NM.MESSAG
E_GROUP_ID AND NMG.INCOMPLETE = 'y' ) ORDER BY NM.NOTIFY_MESSAGE_ID
33,16998 RPK_APP 1 TEMP 00000003839FFE20 1874671316
select * from rpk_stat where sample_group_id = :b1 order by stat#, seq#
This example shows that session 33 with serial number 16998, connected to the database as the RPK_APP user, has two statements currently using sort segment space in the TEMP tablespace. One statement is currently using 8 MB of sort segment space, while the other is using 1 MB. The text of each statement, along with its hash value and address in the shared SQL area are also displayed.
Global temporary tables
When a permanent table is updated in any way, it creates quite a bit of overhead – it generates undo, and it generates redo, and it takes up space in a permanent tablespace. Often there is a need for a ‘work’ table that contains temporary results of an operation that doesn’t need to persist between sessions or database restarts. Global temporary tables are very good for this role with the caveat that enough space needs to be free in the target temporary tablespace.
One interesting note on global temporary tables – use of them does not affect PGA memory (verified on Oracle RDBMS v12.1.0.2); it uses exclusively temporary space.
To create them, decide which temporary tablespace the table should reside, and then use this:
SQL> create global temporary table work_temp
(master_id number)
on commit delete rows tablespace temp;
PL/SQL collections and variables
Oracle PL/SQL stored procedures can allocate variables, and these can contain collections, which is a list of records. When these are allocated, the only space used is in the PGA – no TEMPORARY space is used for these at all. If the PGA_LIMIT is exceeded, the error returned is ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT.
Managing temporary tablespaces (version 10+)
From the administration side, Temporary tablespaces in Oracle RDBMS version 10+ have the ability to shrink space, to add space, and to assign users to different temporary tablespaces.
To create a temporary tablespace, the following SQL is used: this will create a temporary tablespace called MYTEMP in the DATA ASM diskgroup.
SQL> create temporary tablespace MYTEMP datafile '+DATA' size 1G autoextend on maxsize unlimited;
If there is one particular account that is frequently filling up temporary space which affects other accounts, it is possible to assign different temporary tablespaces to different users – or, several groups of users can share one temporary tablespace. To assign a user to their own temporary tablespace, first create the temporary tablespace (in the case below one called ‘newtemp’, and then assign it to the user (myuser in this case) with:
SQL>Alter user myuser temporary tablespace newtemp;
To add space to a temporary tablespace, assuming that all tempfiles have MAXSIZE=UNLIMITED, a new file will need to be added. Syntax varies for this depending on if the database is using OFM (Oracle File Management), but the basic syntax is:
Oracle Alter Temp Tablespace
SQL> alter tablepace temp add tempfile autoextend on maxsize unlimited;
If a session fills up a temporary tablespace, which will cause it to expand as much as it can, that space is not automatically reclaimed when that session goes away. This can cause the temporary tablespace to use much more disk space than necessary. To shink it, query the view DBA_TEMP_FREE_SPACE, and then shink the tablespace. This command will shrink it as much as possible:
SQL> alter tablespace temp shrink space;
This syntax will shrink it, but keep a given amount:
SQL> alter tablespace temp shrink space keep 1G;
If you wish to drop a tempfile (which is usually not needed), and that file is not in use, use this:
SQL> alter tablespace tempfile ‘/oradata/temp03.dbf’ drop including datafiles;
Conclusion
When an operation such as a sort, hash, or global temporary table instantiation is too large to fit in memory, Oracle allocates space in a temporary tablespace for intermediate data to be written to disk. Temporary tablespaces are a shared resource in the database, and you can’t set quotas to limit temporary space used by one session or database user. If a sort operation runs out of space, the statement initiating the sort will fail. It may only take one query missing part of its WHERE clause to fill an entire temporary tablespace and cause many users to encounter failure because the temporary tablespace is full.
It is easy to detect when failures have occurred in the database due to a lack of temporary space. With the setting of a simple diagnostic event, it is also easy to see the exact text of each statement that fails for this reason. There are also v$ views that DBAs can query at any time to monitor temporary tablespace usage in real time. These views make it possible to identify usage at the database, session, and even statement level.
Oracle DBAs can use the techniques outlined in this paper to diagnose temporary tablespace problems and monitor sorting activity in a proactive way. These tactics can be helpful for addressing both chronic and intermittent shortages of temporary space.
Our certified DBAs provide the deep expertise you need to manage MySQL, Oracle and Microsoft SQL Server and optimize their performance.Your mission-critical Oracle databases are in expert hands at Rackspace. From emergency troubleshooting to planning for scaling and disaster recovery, everything our certified Oracle professionals do is about keeping your databases up and running at peak performance.
Even if you are a developer, or Linux sysadmin, sometimes you might still end-up dealing with Oracle database in your organization.
One of the essential Oracle DBA task is to manage the tablespace.
This tutorial covers everything that you need to know to effectively manage both your tablespaces and datafiles in an Oracle database.
The following are covered in this tutorial:
- Create Tablespace with an Example
- Create Tablespace with Additional Storage Parameters
- Add New Datafile to Increase the Size of a Tablespace
- Add New Datafile with Storage Parameters
- How to Increase Size of an Existing Datafile
- View Tablespace and datafile Information
- Tablespace Extent Management
- Calculate the Size of your Tablespace (Both Total Space and Free Space Available)
- Bigfile Tablespace Management
- Rename Tablespace
- Drop Tablespace
- Drop a Specific datafaile from a Tablespace
- Bring Tablespace Online or Offline
- Set a Tablespace as Read-Only Temporarily
- Rename or Move Datafile to a Different Folder
1. Create Tablespace Basic Example
The following command will create a new tablespace called “thegeekstuff” with /u02/oradata/tgs/thegeekstuff01.dbf as the datafile. The initial size of the datafile will be 100M.
Note: It is recommended that you keep the name of your datafile the same as the tablespace name. Sine this is the first datafile in this table, it is called as thegeekstuff01.dbf. When you add a 2nd file to this tablespace, call that as thegeekstuff02.dbf, etc.
2. Create Tablespace with Extra Parameters
The following command will create a new tablespace but this specifies some additional storage related parameters.
In the above command:
- Datafile – The above creates thegeekstuff tablespace with thegeekstuff01.dbf as the datafile.
- Size 100M – The initial size of this dbf file will be 100M.
- AUTOEXTEND ON NEXT 1M – When it runs out of space, it will automatically extend this dbf file by 1M whenever required.
- MAXSIZE 2G – This will keep extending the size of this particular dbf file until it reaches 2GB.
3. Add New Datafile to Increase the Size of a Tablespace
After a tablespace is created, you can also add more datafile using ALTER TABLESPACE command as shown below.
The above command will add a 2nd datafile called thegeekstuff02.dbf to the existing thegeekstuff tablespace. The initial size of this tablespace will be 100M.
Some of the commands explained here can be modified slightly modified to work with other types oracle tablespace like undo tablespace, temp tablespace, system tablespace, etc.
4. Add New Datafile with Extra Parameters
You can enable or disable automatic file extension for existing datafiles, or manually resize a datafile, using the ALTER DATABASE statement. For a bigfile tablespace, you are able to perform these operations using the ALTER TABLESPACE statement.
The following example enables automatic extension for a datafile added to the users tablespace. The value of NEXT is the minimum size of the increments added to the file when it extends. The value of MAXSIZE is the maximum size to which the file can automatically extend.
The following command will add a new datafile to an existing tablespace with some additional storage related parameters.
Oracle 12c Increase Tablespace Temp Size
In the above:
- ADD DATAFILE – thegeekstuff02.dbf file will be added to the existing tablespace
- SIZE 100M – Initial size of this datafile will be 100M
- AUTOEXTEND ON – The automatic extension for this datafile is enabled. This will keep extending this datafile whenever space is required.
- NEXT 512K – When it runs out of space, this will extend the size by 512K
- MAXSIZE 2G – thegeekstuff02.dbf file will keep growing upto maximum of 2GB in size.
5. Increase Size of an Existing Datafile
When you don’t have the autoextend on, you can also increase the size of a particular datafile as shown below.
The above command will resize thegeekstuff01.dbf file to 200MB.
If the dbf file is currently only 100MB in size, then the above command will increase the size.
If the dbf file is currently 500MB (or anything more than 200MB), then the above command will decrease the size if possible. It will decrease the size of the dbf file only if the existing content is less than 200MB.
6. View Tablespace and datafile Information
You can view all the tablespace in your system from the dba_tablespace as shown below.
To view all the datafiles of a particular tablespace, execute the following command.
This command will display all the datafiles that as currently associated with thegeekstuff tablespace. This will also display the size of the datafiles in MB.
column file_name format A50;
The following is the output:
Also, you’ll see these two dbf files physically on your filesystem as shown below:
Both the dba_tablespaces and dba_data_files have lot of additional columns that can give you more useful information about your tablespace and datafiles
7. Tablespace Extent Management
The following are two methods that tablespace uses to manage their extents. Extents are nothing but the unit in which a tablespace allocates space.
Locally managed Tablespaces – In this method, extents are automatically managed by the tablespace itself.
Dictionary managed tablespace – In this method, extents are managed by the data dictionary.
In the latest version of oracle, when you create a tablespace, by default, it will use locally managed tablespace, which is highly recommended. Don’t use dictionary managed, unless you know what you are doing.
Use the following query to identify whether your tablespace is using dictionary or locally managed.
The following is the output:
As you see above, in this example, thegeekstuff tablespace is using locally managed tablespace for extent management.
In the older version of Oracle, by default it might create a tablespace in dictionary managed. In that case, if you want to specify the extent management during the tablespace create command, you can use “EXTENT MANAGEMENT LOCAL” in the create tablespace command as shown below.
Note: The Segment space management can either be AUTO or MANUAL. AUTO is the recommended method.
You can also specify uniform size for locally managed tablespace as shown below. The following will create thegeekstuff tablespace with locally managed tablespace with a uniform extent size of 128k.
Note: You can see this in the ALLOCATION_TYPE column on dba_tablespaces. The value can be either UNIFORM or SYSTEM (which is default)
Note: Typically you don’t have to worry about specifying any of these extra options. Just create the tablespace with default option, and let the database do the locally managed tablespace with all default values.
8. Calculate the Size of Tablespace (Both Total Space and Free Space Available)
The following command will display the total space used, and the free space available in your tablespace.
The following output indicates that this particular tablespace still have 34% of free space (i.e around 867MB free space is available for new data)
9. Bigfile Tablespace Management
Typically you can add as many datafiles you want to a specific tablespace.
But, in a bigfile tablespace will have only one datafile.
An oracle bigfile tablespace will allow you to create a tablespace with a single datafile that can grow really large.
The advantage is that you don’t have to worry about managing datafiles, you’ll simply manage the bigfile tablespace.
Use create bigfile tablespace command as shown below to create a bigfile tablespace.
In the above example, there will be only one datafile called thegeekstuffbig.dbf, with initial size of 50GB.
For size, you can also specify K (for kilobytes), or M (for megabytes), or G (for gigabytes), or T (for terabytes).
The following query will display whether a particular tablespace is a bigfile tablespace or not.
The following is the output:
Later if you want to extent the size of the bigfile tablespace even further, all you have to do is, use alter tablespace command as shown below. This will resize the single datafile thegeekstuffbig.dbf from 50G to 100G
You can also use the autoextend on and specify the next next as shown below. This will automatically extent that single datafile by 10G whenever more space is required.
While this is obvious, it is worth mentioning, you cannot add more datafile to the bigfile tablespace. It will display the following error message.
The following is the output:
If the default tablespace type was set to BIGFILE at database creation, but you want to create a traditional (smallfile) tablespace, then specify a CREATE SMALLFILE TABLESPACE statement to override the default tablespace type for the tablespace that you are creating.
You can also set the default tablespace type in your database to BIGFILE, in which case, you can simply use “CREATE TABLESPACE” command instead of “CREATE BIGFILE TABLESPACE”.
In that case (when your default tablespace type is BIGFILE), and if you want to create the traditional tablespace, when you have to use “CREATE SMALLFILE TABLESPACE” as shown below.
10. Rename Tablespace
Using the RENAME TO clause of the ALTER TABLESPACE, you can rename a permanent or temporary tablespace. For example, the following statement renames the users tablespace:
You can change the name of an existing tablespace using alter tablespace command as shown below.
This will change the tablespace name from thegeekstuff to tgs.
Now, the tablespce is renamed:
Just like renaming a regular tablespace, you an also rename SYSTEM tablespace, or SYSAUX tablespace, or temporary tablespace, or an undo tablespace.
11. Drop Tablespace
To drop a tablespace, you should have DROP TABLESPACE privilege.
The following command will drop (delete) thegeekstuff tablespace.
Oracle Temporary Tablespace
Keep in mind that the above command will work only if the tablespace that is getting deleted is empty. If the tablespace has something, it will thrown the following error message.
The following is the error message:
So, if you want to drop the tablespace along with all the objects (tables, indexes, etc) in it, then use the following DROP command with “INCLUDING CONTENTS”.
When you drop a tablespace, the datafiles will still be there. You have to remove them manually using rm command from the command line.
Or, the following command will drop the tablespace along with all the objects AND will automatically remove the associated datafiles form the operating system.
Warning: Needless to say, be extra careful with drop tablespace command. You don’t want to use the “INCLUDING” clause unless you are absolutely sure that you don’t want anything from that particular tablespace.
12. Drop a Specific datafaile from a Tablespace
Instead of deleting the whole tablespace, you also have the option of deleting a specific datafile using the drop datafile as shown below.
This command will drop thegeekstuff02.dbf file (both from the tablespace and from the operating system level).
The above command will thrown an error message, if that particular datafile has any data in it.
13. Bring Tablespace Online or Offline
The following will make thegeekstuff tablespace unavailable for all the users. Every other tablespace in the database will be operational except this one. When successful, you’ll get “Tablespace altered.” message.
The status for this tablespace will now be OFFLINE as shown below.
Sometimes this is helpful when you want to just backup a tablespace using rman command.
Note: when you don’t specify a clause, it will use the normal offline mode. The following command is same as the above command.
The following are three offline modes for tablespace:
- NORMAL – This is the default. This will take the tablespace offline only when none of the datafile has any errors associated with it.
- TEMPORARY – This will take the tablespace offline even if there are any errors associated with any of the datafiles for this tablespace.
- IMMEDIATE – This will take the tablespace offline immediately even when there are errors, and even without anything any checkpoint of the datafiles. Don’t use this unless you know exactly what you are doing.
To bring a tablespace back online, execute the following command.
Similar to taking the whole database offline, you can also take a specific datafile offline and later bring it back online as shown below.
14. Set a Tablespace as Read-Only Temporarily
All tablespaces are initially created as read/write. Use the READ ONLY clause in the ALTER TABLESPACE statement to change a tablespace to read-only. You must have the ALTER TABLESPACE or MANAGE TABLESPACE system privilege.
By default, you can both read and write to a tablespace. This means that you can create any new objects (tables, etc) on the tablespace, insert data to it, and also select from the table, etc.
But, you can also make an existing tablespace read only. This means that you cannot create new object, or insert/delete/update/etc on the existing object. The only thing you can do is read the data.
The following will put thegeekstuff tablespace in read only mode.
Now, the status of this tablespace will be read only as shown below.
The following command will put the database back to the regular read write mode.
Note: When it is in read/write mode, the status will simply say “ONLINE”.
15. Rename or Move Datafile to a Different Folder
Use the rename datafile as shown below, to simply rename a particular data file.
In this example, we are simply rename the file from thegeekstuff02.dbf to tgs02.dbf
Note: If the file is currently in use, you’ll get the following error message:
If you want to physically move the location of the datafile from one folder to another folder, do the following:
First, take the tablespace offline as shown below:
Next, copy the files to the new location manually at the operating system level:
Finally, execute the rename datafile command with the new location in the “TO” as shown below.
In this example, the file is getting moved from u02 to u03 mount point.
If you enjoyed this article, you might also like..
Next post: 10 MySQL Load Data Infile Examples to Upload Text File Data to Tables
Previous post: Howto Setup Apache Zookeeper Cluster on Multiple Nodes in Linux