Showing posts with label dba_temp_files. Show all posts
Showing posts with label dba_temp_files. Show all posts

Sunday, June 10, 2012

ORA-01652: unable to extend temp segment

Some time ago, I remember being asked to investigate regular ORA-01652 error messages. I looked on Metalink and found that a number of people had the same problem. Some of them believed that Oracle was not very good at deciding when it was OK to reuse temporary space. I decided to do a test myself to see whether or not I agreed. The worked example below was run on Oracle 9.2.0.5.0 with a block size of 8192. The database only had 1 tempfile of 20 megabytes:

SQL> l
  1  select file_id, tablespace_name, bytes
  2* from dba_temp_files
SQL> /
 
   FILE_ID TABLESPACE_NAME           BYTES
---------- -------------------- ----------
         1 TEMP                   20971520
 
SQL>
 
Nobody was doing any sorting, which was not surprising as I was the only person using the database:

SQL> l
  1  select username, tablespace, blocks
  2* from v$sort_usage
SQL> /
 
no rows selected
 
SQL>
 
I logged in as USER1, did a sort and waited for the output to appear:

SQL> conn user1/user1
Connected.
SQL> set pause on
SQL> select a.table_name
  2  from dba_tables a, dba_tables b
  3  order by 1
  4  /
TABLE_NAME
------------------------------
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
 
Then, in another session, I looked to see how much sort space was being used:
 
SQL> l
  1  select username, tablespace, blocks
  2* from v$sort_usage
SQL> /
 
USERNAME   TABLESPACE          BLOCKS
---------- --------------- ----------
USER1      TEMP                  1536
 
SQL>
 
USER1 was using 1536 x 8192 = 12582912 bytes of sort space. I returned to USER1's session, interrupted the sort output and ran a new query to check the time for later comparison:
 
SQL> conn user1/user1
Connected.
SQL> set pause on
SQL> select a.table_name
  2  from dba_tables a, dba_tables b
  3  order by 1
  4  /
TABLE_NAME
------------------------------
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
ACCESS$
 
13 rows selected.
 
SQL> select to_char(sysdate,'hh24:mi:ss')
  2  time_now from dual
  3  /
TIME_NOW
--------
14:36:15
 
SQL>

At this point, USER1 had no way of restarting the output from the sort so the sort space should no longer be required. I then ran the same query as USER2. If it worked for USER1, it should work for USER2 as the space originally used by USER1 should be reusable:
 
SQL> conn user2/user2
Connected.
SQL> set pause on
SQL> l
  1  select a.table_name
  2  from dba_tables a, dba_tables b
  3* order by 1
SQL> /
 
While this was going on, I watched the sort usage grow and noticed that USER1's space was still allocated:
 
  1  select username, tablespace, blocks
  2* from v$sort_usage
SQL> /
 
USERNAME   TABLESPACE          BLOCKS
---------- --------------- ----------
USER2      TEMP                   384
USER1      TEMP                  1536
 
SQL> /
 
USERNAME   TABLESPACE          BLOCKS
---------- --------------- ----------
USER2      TEMP                   512
USER1      TEMP                  1536
 
SQL> /
 
USERNAME   TABLESPACE          BLOCKS
---------- --------------- ----------
USER2      TEMP                   896
USER1      TEMP                  1536
 
SQL>
 
Eventually, USER2's query failed:
 
SQL> conn user2/user2
Connected.
SQL> set pause on
SQL> l
  1  select a.table_name
  2  from dba_tables a, dba_tables b
  3* order by 1
SQL> /
 
select a.table_name
*
ERROR at line 1:
ORA-01652: unable to extend temp segment by 128 in
tablespace TEMP

SQL>
 
At which point, USER2’s space became available immediately but USER1’s space was still allocated:
 
SQL> l
  1  select username, tablespace, blocks
  2* from v$sort_usage
SQL> /
 
USERNAME   TABLESPACE          BLOCKS
---------- --------------- ----------
USER1      TEMP                  1536
 
SQL>
 
What can you do about this? One site suggests coalescing the tablespace but you cannot do this with a temporary tablespace:
 
SQL> l
  1* alter tablespace temp coalesce
SQL> /
alter tablespace temp coalesce
*
ERROR at line 1:
ORA-03217: invalid option for alter of TEMPORARY
TABLESPACE

SQL>
 
An hour later, the situation was still the same. V$SORT_SEGMENT showed a similar picture:
 
SQL> l
  1  select tablespace_name, total_blocks,
  2  used_blocks, free_blocks
  3* from v$sort_segment
SQL> /
 
TABLESPACE_NAME  TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
---------------- ------------ ----------- -----------
TEMP                     2432        1536         896
 
SQL>
 
I guess the 896 free blocks were created by USER2’s failed query. As soon as USER1 logged out:
 
SQL> show user
USER is "USER1"
SQL> select to_char(sysdate,'hh24:mi:ss')
  2  time_now from dual
  3  /
TIME_NOW
--------
15:33:08
 
SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 – Production
 
The free space returned immediately:
 
SQL> l
  1  select tablespace_name, total_blocks,
  2  used_blocks, free_blocks
 3* from v$sort_segment
SQL> /
 
TABLESPACE_NAME  TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
---------------- ------------ ----------- -----------
TEMP                     2432           0        2432
 
SQL>

So there you have it. If a user interrupts his own sort, Oracle does not realise that his sort space can be reused. However, if a user's sort fails, his sort space is made available again straight away.

Monday, November 14, 2011

ORA-25153

If you try to sort anything other than a small amount of data, and the sort has to use disk space, you may see the following error message:
 
SQL> select a.table_name, b.table_name
  2  from dba_tables a, dba_tables b
  3  order by 1;
from dba_tables a, dba_tables b
     *
ERROR at line 2:
ORA-25153: Temporary Tablespace is Empty
 
SQL>
 
This will happen if you:
 
(1)    Copy the datafiles from a source to a target database.
(2)    Recreate the target database’s control file.
(3)    Forget to add a file to its temporary tablespace.
 
You can diagnose this fault as follows. First you have to find the name(s) of the target database’s temporary tablespace(s). In this example there is only one:
 
SQL> select distinct temporary_tablespace
  2  from dba_users
  3  /
 
TEMPORARY_TABLESPACE
------------------------------
TEMP
 
SQL>
 
Then you have to see if it contains any temp files:
 
SQL> select file_name from dba_temp_files
  2  where tablespace_name = 'TEMP'
  3  /
 
no rows selected
 
SQL>
 
If it doesn’t, you have to add one. On this occasion, there was still an old tempfile so I was able to reuse it:
 
  1  alter tablespace temp add tempfile
  2  'test10/andrew/temp_files/temp01.dbf'
  3* reuse
SQL> /
 
Tablespace altered.
 
SQL>
 
Then the sort should work:
 
SQL> col table_name format a25
SQL> l
  1  select a.table_name, b.table_name
  2  from dba_tables a, dba_tables b
  3* order by 1
SQL> /
 
TABLE_NAME                TABLE_NAME
------------------------- -------------------------
ACCESS$                   AQ$_ALERT_QT_H
ACCESS$                   WRI$_DBU_FEATURE_USAGE
ACCESS$                   WRI$_ALERT_HISTORY
ACCESS$                   AQ$_ALERT_QT_T
ACCESS$                   WRH$_FILESTATXS_BL
ACCESS$                   AQ$_ALERT_QT_G
ACCESS$                   AQ$_ALERT_QT_I
ACCESS$                   WRH$_FILESTATXS
ACCESS$                   WRH$_WAITSTAT
ACCESS$                   WRH$_TEMPSTATXS
ACCESS$                   WRH$_SQLSTAT
Etc

Sunday, January 09, 2011

Drop Database


In version 10g, Oracle introduced the drop database SQL statement. This removes all datafiles, online redo log files, control files and server parameter files. I created a database with the Database Configuration Assistant so that I could try out this new command. To make it easier to demonstrate, I put the datafiles, online redo log files and control files all in the same directory:

SQL> col file_name format a55
SQL> select file_name from dba_data_files;

FILE_NAME
-------------------------------------------------------
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\USERS01.DBF
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\SYSAUX01.DBF
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\UNDOTBS01.DBF
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\SYSTEM01.DBF

SQL> select file_name from dba_temp_files;

FILE_NAME
-------------------------------------------------------
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\TEMP01.DBF
  
SQL> col member format a50
SQL> select member from v$logfile;

MEMBER
--------------------------------------------------
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\REDO03.LOG
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\REDO02.LOG
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\REDO01.LOG

SQL> col name format a55
SQL> select name from v$controlfile;

NAME
-------------------------------------------------------
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\CONTROL01.CTL
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\CONTROL02.CTL
C:\DOCUMENTS AND SETTINGS\ANDREW\TEST10\CONTROL03.CTL

SQL>


It’s easier to see in the screen print below (click to enlarge it):
   

The server parameter file was in a different directory:

SQL> col value format a50
SQL> select value from v$parameter where name = 'spfile';

VALUE
--------------------------------------------------
C:\ORACLE\PRODUCT\10.2.0\DB_1\DBS\SPFILETEST10.ORA

SQL>


Then I tried to drop the database:

SQL> set lines 60
SQL> drop database;
drop database
*
ERROR at line 1:
ORA-01586: database must be mounted EXCLUSIVE and not open for this operation

SQL>


I followed the instructions and tried again: 

C:\Documents and Settings\Andrew>set ORACLE_SID=TEST10

C:\Documents and Settings\Andrew>sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Fri Dec 24 09:35:34 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

SQL> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount exclusive
ORACLE instance started.

Total System Global Area 612368384 bytes
Fixed Size 1250452 bytes
Variable Size 176163692 bytes
Database Buffers 432013312 bytes
Redo Buffers 2940928 bytes
Database mounted.
SQL> drop database;
drop database
*
ERROR at line 1:
ORA-12719: operation requires database is in RESTRICTED mode

SQL>


Then putting the database into restricted session mode appeared to have the desired effect:

SQL> alter system enable restricted session;

System altered.

SQL> drop database;

Database dropped.
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL>


The datafiles were removed:

C:\Documents and Settings\Andrew\test10>dir
Volume in drive C has no label.
Volume Serial Number is 18E4-B972

Directory of C:\Documents and Settings\Andrew\test10

24/12/2010 10:01 <DIR> .
24/12/2010 10:01 <DIR> ..
              0 File(s) 0 bytes
              2 Dir(s) 11,539,795,968 bytes free

C:\Documents and Settings\Andrew\test10>


And so was the spfile:

C:\oracle\product\10.2.0\db_1\dbs>dir
Volume in drive C has no label.
Volume Serial Number is 18E4-B972

Directory of C:\oracle\product\10.2.0\db_1\dbs

24/12/2010 10:00 <DIR> .
24/12/2010 10:00 <DIR> ..
              0 File(s) 0 bytes
              2 Dir(s) 11,539,415,040 bytes free

C:\oracle\product\10.2.0\db_1\dbs>