System Tablespace dropped

Hi Folks,
i accidently dropped my system tablespace & i dont have any backup.
How should i bring up the database???

ok...
So how can i create the database & what will happen
to the existing one?You can say bye-bye to existing database, without a valid backup it's dead fish in the water.
However, please verify how did you 'drop' the system tablespace, as demostrated by Niclolas you can't do that from Oracle.
Or you just deleted the datafiles of system tablespace on OS level.

Similar Messages

System tablespace space not regained when objects are dropped

Mine is a Oracle 10g 10.2 on windows.
I am importing a export file into a user ,It takes some amount of space in SYSTEM and another tablespace .When I drop the user space in system tablespace is not coming back. ANY IDEA WHY
BEFORE IMPORT
SQL> select sum(bytes)/1024/1024 from dba_segments where owner='SYSTEM';
SUM(BYTES)/1024/1024
22.1875
SQL> select sum(bytes)/1024/1024 from dba_segments where owner='SYS';
SUM(BYTES)/1024/1024
544.1875
SQL> select sum(bytes)/1024/1024 from dba_segments where segment_name='SOURCE$';
SUM(BYTES)/1024/1024
41
I use the following commands to import
SQL>create user <username> identified by <password> default tablespace <tsname> quota unlimited on <tsname>;
SQL>grant create session,imp_full_database to <username>;
imp system file=filename.dmp log=logname.log fromuser=<username> touser=<username> statistics=none
AFTER IMPORT
SQL> select sum(bytes)/1024/1024 from dba_segments where segment_name='SOURCE$';
SUM(BYTES)/1024/1024
53
SQL> select sum(bytes)/1024/1024 from dba_segments where owner='SYSTEM';
SUM(BYTES)/1024/1024
22.1875
SQL> select sum(bytes)/1024/1024 from dba_segments where owner='SYS';
SUM(BYTES)/1024/1024
728.375
AFTER DROPPING THE USER/SCHEMA
SQL> select sum(bytes)/1024/1024 from dba_segments where owner='SYS';
SUM(BYTES)/1024/1024
728.375
SQL> select sum(bytes)/1024/1024 from dba_segments where owner='SYSTEM';
SUM(BYTES)/1024/1024
22.1875
SQL> select sum(bytes)/1024/1024 from dba_segments where segment_name='SOURCE$';
SUM(BYTES)/1024/1024
53
I even tried deleting the objects first and then dropping the user
SQL> delete from source$ where obj# in(select object_id from dba_objects where owner='USERNAME');
211252 rows deleted.
SQL> commit;
Commit complete.
SQL> drop user USERNAME cascade;
User dropped.
The space used by the schema on system tablespace is not coming back.

Hi user509593!
Adding objects to a tablespace requires space in that tablespace. This space is managed in segments and extents. If an extent is fully used (that means 100 % usage) a new extent will be added to a segment. Oracle uses a mechanism called "High Water Mark" to mark the last used extent.
Your problem is that oracle don't set this High Water Mark back if you are dropping objects from a tablespace. Once an extent is marked as it it retains marked as used.
Before Adding Objects:
u = used Extent
x = free Extent
| = High Water Mark
uuuuuuxxxxx
...........|
After Adding Objects:
uuuuuuuxxxx
............|
After dropping objects:
uuuuuuuxxxx
............|
The only chance to get your "unused" space back is to reorganized your tablespace. But before you reorganize something please read the documentation to know all about the costs and traps that comes with reorganization.
Hope this help!
null

Want to drop non-system table from system tablespace

My system tablespace was having some user tables , so I moved those tables to user tablespace. Now that tables are showing in both the tablespaces ex. RET_OFF is showing in system as well as users tablespace I want to drop it from system tablespace only . Can I do it . plz help

Hi Florian , plz check the below details . I am working on Oracle 11g on Windows platform.
SQL> alter table REF_VAT_OFF move tablespace vatsoft;
Table altered.
SQL> select owner, table_name, tablespace_name
2 from dba_tables
3 where table_name='REF_VAT_OFF';
OWNER TABLE_NAME     TABLESPACE_NAME
KNVATCEN REF_VAT_OFF     SYSTEM
OWNER TABLE_NAME     TABLESPACE_NAME
KNVAT REF_VAT_OFF     VATSOFT

Migrating SYSTEM tablespace from DMTS to LMTS in Oracle 9.2.0.7

Migrating SYSTEM tablespace from DMTS to LMTS in Oracle 9.2.0.7 using
brspace -f dbcreate
SAP version: 4.6C
Oracle: 9.2.0.7
OS: AIX 5.3
BRTools: 6.40(42)    /** 6.40(10) or (12) will be sufficient according to SAP ***/
IMPORTANT ***************************************
MUST DO:
1. Create a Full Backup of your system
2. Test your Restore and recovery of your backup.
3. Have a copy of all your tablespaces names on hand
4. Know your SYS and SYSTEM passwords
5. Run CheckDB in DB13 to ensure it is completed successfully with no warnings. This reduce the chance of hitting errors in the process
6. Ensure your UNDO tablespace is big enough
7. OSS 400241 Problems with ops$ or sapr3 connect to Oracle
NOTE: OSS 706625(Read this note)
The migration from a dictionary-managed SYSTEM tablespace to a locally-managed tablespace using the PL/SQL procedure DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL is not supported in the SAP environment.
In UNIX, logon as ora<sid>
run command: brspace -f dbcreate
This command will triggers a Menu. The are seven(7) steps to complete the whole process. Do them in sequence, from step 1 to step 7 faithfully. In Step 1, ensure that your settings of PSAPTEMP, PSAPUNDO etc details such as filenames are correct. The rest I leave it as default and they are fine. Do not change redo log group from 8 to 4 even if you only have 4 redo groups. If not, you might need to restore the system! If the seven steps are complete without errors(warnings is acceptable), congrats. Perform a backup again.
Problems I encountered that caused me to restore system:
1./ Problem: I changed the redo group from 8 to 4 and in the later stage after the tablespaces and files are dropped, the system prompted me that 4 is not acceptable! I can't go back then so a restore is performed.
Solution: Leave the default value 8 as it is
2./ I was using wireless network and the network breaks thus process breaks.
Solution: This process in user-interactive and requires you to input confirmation along the way so do it using LAN.
3./ In the process of dropping tablespace PSAP<SID>, I encountered:
BR0301E SQL error -604 at location BrTspDrop-2
ORA-00601: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 22 with name '_SYSSMU22$" too small
Solution: I have not fixed this yet but I think it is because my PSAPUNDO is too small(800M) so I will increase it to a bigger value e.g. 5GB
4. Problem: Unable to start sap after successfully migrated. OPS$user problem
Solution: logon as <sid>adm, run R3trans -x in a directory that <sid>adm has read/write permission. R3trans -x will creates a file call trans.log. Read the details and refer to OSS 400241
Result: I have successfully performed this on one(1) system and doing this on the another one currently but encounter Problem 3. Will update this further if there are more findings.
REFERENCE:
OSS 748434 New BRSPACE function "dbcreate" - recreate database
OSS 646681 Reorganizing tables with BRSPACE
OSS 541538 FAX: Reorganizations
Message was edited by:
        Annie Chan
Message was edited by:
        Annie Chan
Message was edited by:
        Annie Chan

The current one I am implementing is a development system. The database is less than 100GB. 800MB of PSAPUNDO is sufficient for our development usage.
Follow up on Problem 3:
I created another undo tablespace PSAPUNDO2(undodata.dbf) with size of 5GB. I switched undo tablespace to PSAPUNDO2 and placed PSAPUNDO(undo.data1) offline. With PSAPUNDO2 online and PSAPUNDO offline, I started brspace -f dbcreate and encountered the error below at Step 2 Export User tablespace:
BR0301E SQL error -376 at location BrStattabCreate-3
ORA-00376: file 17 cannot be read at this time
ORA-01110: data file 17: '/oracle/DVT/sapdata1/undo_1/undo.data1'
ORA-06512: at 'SYS.DBMS_STATS", line 5317
ORA-06512: at line 1
I aborted the process and verified that SAP is able to run with this settings. I started CheckDB in DB13 and it shows me these messages:
BR0301W SQL error -376 at location brc_dblog_open-5
ORA-00376: file 17 cannot be read at this time
ORA-01110: data file 17: '/oracle/DEV/sapdata1/undo_1/undo.data1'
BR0324W Insertion of database log header failed
I don't understand then. I have already switched the undo tablespace from PSAPUNDO to PSAPUNDO2. Why the message above still appears? Once I put PSAPUNDO online, CheckDB completes successfully without warning.
I did show parameter undo_tablespace and the result is PSAPUNDO2(5GB).
So exactly, what's going on? Can anyone advise?
===============================================
I have managed to clear the message in DB13 after dropping PSAPUNDO tablespace including contents and datafiles. This is mentioned is OSS note 600141 pg 8 as below:
Note: You cannot just set the old rollback-tablespace PSAPROLL to offline instead of deleting it properly. This results in ORA-00376 in connection with ORA-01110 error messages. PSAPROLL must remain ONLINE until it is deleted. (Oracle bug 3635653)
Message was edited by:
        Annie Chan

BRTools or SQLPlus to restore table after unfortunate tablespace drop?

We have had an unfortunate incident after an upgrade here.
I assume something went wrong during the upgrade, which left a lot of tables assigned to a table type which can not be selected and has description «Repositoryswitch tablespace 700». There are four table types with this description; SLDEF, SLEXC, SSDEF and SSEXC.
The table space was dropped a couple of days after the upgrade. However, there were tables in this table space, and some of them had content too, so recreating the tables is not sufficient, we have to get the content back as well. Among the tables were E071K which is vital for the transport system.
Now our basis people have recreated the affected tables in production and restored a backup from before the tablespace drop to our sandbox system. Unfortunately I have been given the task of figuring out how we best can restore data (table contents) from the affected tables into production.
SQLPlus is an option, and currently the one I am leaning towards. However, since BRTools is a dedicated database management tool I have tried to figure out whether it would be possible to do this using BRTools and whether BRTools does some additional administration which will not be done by SQLPlus - giving us new headaches.
To make matters worse they did a full restore of our test system so we don't have any systems where we can test our approach!

Sunny Pahuja wrote:
> First of all how you deleted the tablespace because if tablespace has some data then BRtools should have given you some warning.
Let me just state for the record that it wasn't me
I'm an ABAP and Business Workflow developer, not a basis person.
I've talked to one of the DB experts here, and she will use SQLPlus and select data from the restored tablespace into the production table space.
Stefan Koehler wrote:
> So it is very easy to recover without any additional hacks by using Transporting Tablespaces.
That would probably be our preferred solution if we could be sure that no new data had been created in production after the tables were restored there to reduce the problems for users (program crashes). The mentioned DB expert said this option would overwrite the entire table contents, like a binary copy, so we decided to go for the other solution using selection from one database into another.
Thank you both for your help. Peers are invaluable!

How to remove data file from System tablespace

Hi All,
I have wrongly added data file in SYSTEM tablespace, now I want remove it. I have tried to set datafile offline but it is giving me the error system tableapce can not set offline. so please help me. I am working Oracle 10g .
thanks in advance
sv

In 10gR2, you can drop a datafile from tablespace, as long it's empty (and of course not the last one):
ALTER TABLESPACE tbs_03 DROP DATAFILE 'tbs_f04.dbf';
Otherwise, there's no direct way to get rid of the file. You can just shrink it and move (i.e. "rename") it another location. For a non-system tablespace, move of all segments to another tablespace (and later renaming it) would be an option, but this of course won't work with system tablespace.

Problem with purge temp and system tablespace

hi,
i am purging tablespec with sys user and it seems doing it, but tablespaces are still full
also wanted to drop a datafile
alter tablespace system drop
datafile 'C:\oraclexe\files\sys.bf'
and it giving the following error
Error starting at line 28 in command:
alter database datafile 'C:\oraclexe\files\sys.bf' offline drop
Error report:
SQL Error: ORA-01541: system tablespace cannot be brought offline; shut down if necessary
01541. 00000 - "system tablespace cannot be brought offline; shut down if necessary"
*Cause: Tried to bring system tablespace offline
*Action: Shutdown if necessary to do recovery
but if i shutdown how i drop it? or delete manually the file?
sorry for the 2 question in one thread
thanks

but if i shutdown how i drop it? or delete manually the file?Operate in MOUNT state.
But If you need to resize your system tablespace, You have to check HWM.
On XE, I think it's easy to use full exp -> recreate -> full imp..
Regards,

System tablespace

I have created a table in the system tablespace. I am able to rename the column in the table, add a new column to the table, modify the column in the table. But when I tried to drop the column in the table, the following error is raised.
ORA-12988: cannot drop column from table owned by SYS
The user is connected as a sysdba. What is the logic that goes behind this error, as we are able to create a new table in system tablespace, rename the column, modify the column in the table and add new columns to the table. But we couldn't drop a column in the same table.

I have created a table in the system tablespace. Wrong idea
I am able to rename the column in the table, add a new
column to the table, modify the column in the table.
But when I tried to drop the column in the table, the
following error is raised.
ORA-12988: cannot drop column from table owned by
SYS
Connect as SYS and drop it.
The user is connected as a sysdba. What is the logic
that goes behind this error, as we are able to create
a new table in system tablespace, rename the column,
modify the column in the table and add new columns to
the table. But we couldn't drop a column in the same
table.Creating a new table in system tablespace is one thing. Creating a table connected as SYSDBA is a different thing.
So you have two wrongs to correct.
1. Do not create new tables in system tablespace. Create a new tablespace for users (if you do not have one).
2. Do not connect as sysdba to create new tables. Connect as that user without sysdba.

Does rebuild of indexes uses temp tablespace or system tablespace?

Does rebuild of indexes uses temp tablespace or system tablespace?
If so why?

If you combine the answers from Aman and Burleson, they cover most of the picture.
When rebuilding an index, you may end up sorting a large amount of information. The sort may spill into the temporary tablespace - if you haven't configured your database and users properly, it is possible that the SYSTEM tablespace may be used for the temporary tablespace.
As the new copy of the index is built, it has to be built in the right place (tablespace), and the space used to build it will be marked as a temporary segment as the build takes place. When the build is complete, this temporary segment will take on the name of the origrinal index, and the original index will be re-badged as a temporary segment and dropped. (Again, you might see temporary segments in the SYSTEM tablespace if the index was originally in, or was rebuilt into, the SYSTEM tablespace).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Problem after rename datafile belongs to SYSTEM tablespace

Hi
I've renamed one file belongs to SYSTEM tablespace.
Then I brought database online and dropped the old file, now I can open database,
but I can't run backup.
I delete previous one so I can't restore that file from backup, I have the file because I clonned db,
but when I restore file and run recover from RMAN database got recovered.
After that I still can't run backup.
Do you have idea what to do???
SYS@orcl >select * from v$recover_file;
FILE# ONLINE ONLINE_
ERROR CHANGE#
TIME
14 OFFLINE OFFLINE
OFFLINE NORMAL 0

RMAN> report schema;
Report of database schema
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
1 500 SYSTEM YES /u01/app/oracle/oradata/ORCL/datafile/o1_mf_system_48fprop3_.dbf
2 245 UNDOTBS1 YES /u01/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_48fprovo_.dbf
3 260 SYSAUX NO /u01/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_48fpropg_.dbf
4 40 USERS NO /u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_48fprowb_.dbf
5 100 EXAMPLE NO /u01/app/oracle/oradata/ORCL/datafile/o1_mf_example_48fpw04c_.dbf
6 100 DBA1 NO /u01/app/oracle/oradata/ORCL/datafile/dba1.dbf
7 5 TEST NO /u01/app/oracle/oradata/ORCL/datafile/test_reorg0
9 10 UNDO1 YES /u01/app/oracle/oradata/ORCL/datafile/undo01.dbf
10 10 VAL NO /u01/app/oracle/oradata/ORCL/datafile/val.dbf
11 100 INVENTORY NO /u01/app/oracle/oradata/ORCL/datafile/o1_mf_inventor_4tts3q24_.dbf
14 260 SYSAUX NO /u01/app/oracle/oradata/o2_mf_sysaux_48fpropg_.dbf
15 500 SYSTEM YES /u01/app/oracle/oradata/ORCL/datafile/o2_mf_system_48fprop3_.dbf
17 100 RCVCAT NO /u01/app/oracle/oradata/ORCL/datafile/rcvcat01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
1 61 TEMP 32767 /u01/app/oracle/oradata/ORCL/datafile/o1_mf_temp_48fpvnpt_.tmp

SYSTEM tablespace rollback segment

Hi, i had taken a tablespace offline. so the active transactions data will go to SYSTEM rollback segment.
SYSTEM tablespace will use this rollback segments for transactions instead of undo. am i right?
now i dropped the tablespace. so how much time the data which is there in system rollback segments exists? will that data will be overrided because of other transactions on system tablespace?(think that i don't require that tablespace so i dropped it)
thanks in advance

please anybody post the answer

ORA-01251 on system tablespace

hi folks,
(of course we didn't have any backup)
when we try to open our DB we get:
SVRMGR> alter database open;
alter database open
ORA-01122: database file 19 failed verification check
ORA-01110: data file 19: '/tecdata/oradata/INVSID/system08.dbf'
ORA-01251: Unknown File Header Version read for file number 19
SVRMGR>
We find some recovery solution but not in case of system tablespace datafile
we cannot drop the datafile 'couse we are not able to open the database.
there is any solution?
thanks everyone!

Hello,
in dba_temp_files, it shows MAXBYTES as 34359721984, so UNLIMITED apparently does mean 32GB??As Sybrand posted, it depends on your Block Size.
If you use Smallfile Tablespace (the default) then, each of its Datafile is limited to *4 MBlock* (so 4x1024x1024 blocks). So, for a Block Size of 8 Ko it gives (8x1024)x(4x1024x1024) Bytes = *32 GB*. But, you may have up to *1022* Datafiles for your Tablespace.
So, if you want your Tablespace to extend more than 32 GB you may add other datafiles, up to *1022*. So in fact the maximum size for your Tablespace can reach almost *32 TB* (for a block size of 8 Ko). Of course, in this case, you'll have so many datafiles that it won't be easy to manage them.
This is the reason why, starting with Oracle 10.1 you may create Bigfile Tablespace. They have just one datafile but, it can reach *4 GBlock*, so 32 TB for a Block Size of 8 Ko.
Before using Bigfile Tablespace, you should ensure that your OS can support such large file else, the capacity of the Tablespace could be really limited.
Hope this help.
Best regards,
Jean-Valentin

System tablespace gets corrupted.

Hi,
My system tablespace gets corrupted. My Database is not running in archivelog mode and also i dont have any backup. Is there is any solution to recover corrupted blocks in system tablespace;

had the same few weeks ago at one of our customers
SYSTEM tablespace (SYSTEM01.DBF) got corrupted due to power outage/disk error
no archiving, no backup (database for testing purposes, which they update periodically with data from the production database)
tried recovery (as Rafi suggested above), but it didnt work, it said SYSTEM01.DBF needs further recovery, thus open resetlogs wont work
and it was right, resetlogs didnt work :)
so the options:
1. recovery/restore - not possible
2. Oracle has a private tool called Oracle Data Unloader that can get the data from the datafiles - just a test database, doesnt worth the work/time/money
3. open the database with the allowresetlogs_corruption=TRUE hidden parameter, and try a full export
database could be opened with resetlogs by using this parameter
the reward for this action: several ORA-600s per second, instance crashed in 30-60 seconds
at the end we dropped the database and duplicated the production one

How to reduce the size of SYSTEM tablespace?

* Solaris
* Oracle 9.2.0.4.0
* Locally managed database (since SYSTEM is locally managed TS)
I have a Oracle 9i database with is around 7 months old. Over the 7 months it had around 400 schemas at most and SYSTEM tablespace was increased to 850MB. Now it only has around 120 schemas and size of the SYSTEM tablespace still 850MB and its 99% used.
How can I get more free space on system tablespace?
* I have made sure that non-sys(tem) user dont have objects on SYSTEM tablespace.
* I understand that dropping schema does not give you all the space back, since objects are store as row in System tables etc.
Increasing disk is not an option for me. Any tips to free space on system welcome.
Thanks,
Nazrul Islam

Thanks Joel Pérez for trying to help.
SQL> select segment_name, owner from
dba_segments
where owner not in
('SYS','SYSTEM','OUTLN','MDSYS','ORDSYS','WMSYS')
and
TABLESPACE_NAME='SYSTEM';
SEGMENT_NAME                   OWNER
TOAD_PLAN_SQL                  TOAD
TOAD_PLAN_TABLE                TOAD
PLSQL_PROFILER_RUNS            TOAD
PLSQL_PROFILER_UNITS           TOAD
PLSQL_PROFILER_DATA            TOAD
TPSQL_IDX                      TOAD
TPTBL_IDX                      TOAD
SYS_C006895561                 TOAD
SYS_C006895563                 TOAD
SYS_C006895566                 TOAD
10 rows selected.
SQL> select owner from dba_segments where
tablespace_name='SYSTEM'
group by owner;
OWNER
OUTLN
SYS
SYSTEM
TOAD
WMSYSHere is my query (to show TOAD is taking very little
space):r.- That is true, the space used by TOAD is little
>
SQL> select owner, SUM(bytes)/1048576 AS "TOTAL
(MB)"
from dba_segments
where tablespace_name = 'SYSTEM'
group by owner order by "TOTAL (MB)" desc;
OWNER                 TOTAL (MB)
SYS                     820.4375
SYSTEM                      20.5
WMSYS                     3.6875
TOAD                       .6875
OUTLN                       .375Looks like, I have to grow system. Or since I have a
fixed number of schema now, I think I will have to
recreate a DB to reduce SYSTEM size.
Joel one other info that might explain why
this happening. Part of our build process is to drop
4 schemas and roles and recreate them.
e.g.
drop user nislam cascade;
create user nislam ....And we do many builds a day. Maybe Oracle uses more
space in doing that since new userid, better might be
drop objects from the schema. WHAT do you
say?
r.- In theorical lines. Both must give the same results but... I would recommend you to carry out some intensive test about it in a test enviroment testing both methods to monitor the behavior of the growth of the tablespace system. As you said, perhaps dropping the user objects will get better results.
>
Regards,
Nazrul IslamJoel Pérez
http://otn.oracle.com/experts

Temp tablespace drop 관련 질문임다!

temp tablespace가 거의 100%사용이어서, db shutdown하고 다시 살렸는데도
줄지 않아서 (사실 이것도 왜 안주는지 궁금하거등요~!)
우선 old_temp tablespace를 new_temp tablespace를 만들었습니다.
즉,,,제가 한작업들을 개략 적어보면요
1) create temporary tablespace new_temp tempfile~~~~;
2) drop tablespace old_temp;
3) alter database default temporary tablespace new_temp;
하고 나서 모든 유저에 지정되어있는 temporary tablespace를 new_temp로 지정
해줘야 하쟎아요
즉, alter user scott temporary tablespace new_temp; 이렇게요...
근데 이걸 안해줬는데도 에러없이 scott유저는 소트를 수행하드라구요...
이거...정상인건가요????
***추가질문~!
그리고 템프싸이즈가 줄지않고 계속늘어날때의 원인과 체크포인트좀 부탁드립니다.

8i에서는 tempfile이란 개념은 있었으나 default temporary tablespace라는
개념은 없었습니다. 그래서 유저에게 직접 default tablespace를 지정해주어야
했었습니다.
하지만.. 9i부터는 alter database default temporary tablespace new_temp;
명령을 하기만 하면 모든 유저의 default temporary tablespace가 default로
지정되어 있지 않으면 new_temp로 됩니다.
물론 이 경우에도 수동으로 temp를 지정할 수 있으니 실제로 유저가
temp공간을 어디에 사용하는지는..
select username, temporary_tablespace from dba_users; 를 통해서
확인해야 합니다.
scott유저는 default temporary tablespace로 지정되어서 그 쪽 temp를
사용하게 되니, 에러가 나지 않겠죠.
default temporary tablespace가 무엇으로 지정되어 있는지는,
select * from database_properties; 또는 select * from sys.props$; 로 조회하면
temporary tablespace라는 이름으로 어떤 값이 들어가 있는지 보입니다.
그리고 temp는 DB를 내렸다가 올리면 smon프로세스가 clear시켜줍니다.
temp는 아시다 싶이 당연히 sort를 해서 발생하는 것이구요. 그렇다면..
temp가 계속해서 full이 난다면.. temp를 사용하는 세션을 확인하고
temp를 사용하는 세션의 쿼리를 뽑아낸다면 쉽게 해결이 되겠죠.
아래는 제가 경험해서 처리한 것입니다.
저는 temporary tablespace가 full 났는데 도대체 쿼리를 못잡는 것이었습니다.
그래서 어떻게 했을까요? Secure CRT에 세션로그를 걸어두고 모니터링을 했죠.
vi stat.sh
interval=30 # Sleep interval in seconds
reps=1000000 # n times
j=1 # Loop variable
while [ $j -le ${reps} ]
do
echo " ----cycle ${j} / ${reps} --------"
sqlplus -s system/패스워드<<EOF
@sw.sql ${j}
exit
EOF
cat sess_${j}.dat >> sw.dat
rm sess_${j}.dat
sleep ${interval}
j=`expr ${j} + 1`
done
exit 0
vi sw.sql
set line 150
set concat "+"
col username format a10
col osuser format a10
col tablespace format a15
spool sess_&1.dat
SELECT b.tablespace,
b.segfile#,
b.segblk#,
b.blocks,
a.sid,
a.serial#,
c.spid,
a.username,
a.osuser,
a.status,
a.sql_hash_value
FROM v$session a,
v$sort_usage b,
v$process c
WHERE a.saddr = b.session_addr and a.paddr=c.addr
ORDER BY b.tablespace, b.segfile#, b.segblk#, b.blocks;
spool off
stats.sh 를 수행하고 PC킨 상태로 그냥두고 다음날 왔더니 아래처럼 temp를
계속 쓰는 넘이 나온거죠..
딱걸렸습니다.ㅎㅎ
TEMP 93 2550817 13824 92 58284 3193 PVB oracle ACTIVE 1126923165
----cycle 1792 / 1000000 --------
TEMP 93 2550817 43008 92 58284 3193 PVB oracle ACTIVE 1126923165
----cycle 1793 / 1000000 --------
TEMP 93 2550817 72192 92 58284 3193 PVB oracle ACTIVE 1126923165
----cycle 1794 / 1000000 --------
TEMP 93 2550817 101376 92 58284 3193 PVB oracle ACTIVE 1126923165
----cycle 1795 / 1000000 --------
TEMP 93 2550817 131072 92 58284 3193 PVB oracle ACTIVE 1126923165
----cycle 1796 / 1000000 --------
TEMP 93 2416673 18944 123 5171 3197 PVB oracle ACTIVE 1126923165
TEMP 93 2550817 159744 92 58284 3193 PVB oracle ACTIVE 1126923165
----cycle 1797 / 1000000 --------
TEMP 93 2416673 48128 123 5171 3197 PVB oracle ACTIVE 1126923165
TEMP
sql_hash_value값이 1126923165 이니 아래 쿼리에다가 넣으면 full 쿼리가 나오죠..
결국엔 개발자가 모든 소스코드에서 변경을 했어야 했는데.. 그렇게 하지 않아서
일부 웹서버에서의 쿼리가 이상하게 where조건없이 수행되었고 그래서 temp가
full 났던 것이랍니다.
vi sidhashsql.sql
set pages 1000
col sql_text format a120
select sql_text from v$sqltext_with_newlines
where hash_value=&hash_value order by piece;
SQL> @sidhashsql
Enter value for hash_value: 1126923165
old 2: where hash_value=&hash_value order by piece
new 2: where hash_value=1126923165 order by piece
SQL_TEXT
boan~~~~!!
아래 너무 자세하게 나와있죠?
No. 18484
TEMPORARY TABLESPACE에서 TEMPFILE 과 DATAFILE의 차이점 (8.1.X ~ 9I)
============================================================
PURPOSE
이 문서에서는 Oracle 7.3부터 사용되어 오던 create tablespace ... temporary
형태와, 8i부터 사용되는 create temporary tablespace... 의 차이점을 정리해
본다.
tablespace의 temporay type과 permanent type에 대한 비교는 <Bulletin#: 11938>
를 참조하도록 하고 여기에서는 permanent에 대해서는 논외로 한다.
Explanation
temporary segment가 생성 가능한 tablespace의 type과 temporary tablesapce에서
datafile과 tempfile의 차이점을 설명한다.
1. temporary segment를 생성가능한 tablespace type 정리
temporary tablespace의 tempfile과 datafile을 비교하기 전에, tablespace의
type들을 확인해 보고, 이 중 temporary segment가 생성될 수 있는 tablespace
type을 version별로 정리해본다.
tablespace는 7.2까지는 permanent type으로 dictionary managed방식으로
space를 할당/해제하던 방식만이 존재했다. db user의 temporary tablespace로
임의의 tablespace를 지정가능하였고, 해당 db user의 sort operation은
지정된 tablespace에서 발생하며, 다른 tablespace와 특별히 구분되는 것은
없었다.
이후, 7.3에 temporary type이 추가되고, 8i에서 locally managed type과 일반
datafile이 아닌 tempfile이 소개되면서 8i를 기준으로 기본적으로 다음과 같이
4가지 형태의 tablespace 형태가 가능하다.
이중 (1) ~ (3)번까지는 일반 datafile형태이고, (4)번의 경우는 이 문서에서
자세히 살펴볼 tempfile이다.
(locally managed와 dictionary managed의 차이점 및 사용 방법은
<Bulletin #: 18261>과 <Bulletin #: 11860> 참조)
(1) permanent-dictionary managed
(2) permanent-locally managed
(3) temporary-dictionary managed
(4) tempfile-locally managed
[주의] 위의 종류에 temporary datafile에 locally managed 형태의 tablespace는
없는것에 주의한다.
그리고 만약 system tablespace가 locally managed로 이미 생성된 경우에는
이후 모든 tablespace는 locally managed로 생성이 가능하고, dictionary
managed 형태는 생성하면 ORA-12913 (Cannot create dictionary managed
tablespace) 오류가 발생하게 된다.
이러한 여러가지 type의 tablespace중 temporary segment를 생성할 수 있는
tablespace에 제약이 존재한다.
- 8i: 어떠한 형태의 tablespace라도 db user의 temporary tablespace로 지정
가능하다. 단, permanent-locally managed 형태의 tablespace에 sort가
발생하게 되면 ORA-3212 (Temporary Segment cannot be created in
locally-managed tablespace) 오류가 발생하게 된다.
SQL> alter user scott temporary tablespace PERM_LOCAL;
User altered.
connect scott/tiger
SQL> select * from dept order by 1;
ORA-03212: Temporary Segment cannot be created in locally-managed
tablespace
- 9i: db user의 default temporary tablespace 지정 자체가 다음 두 가지
type만이 가능한다.
-temporary-dictionary managed
-tempile-locally managed
만약 permanent type의 tablespace를 db user의 tempoary tablespace로
지정하면, ORA-12911 (permanent tablespace cannot be temporary tablespace)
오류가 발생한다.
2. tempfile과 datafile의 비교
아래에서 tablespace지정시 tempfile과 datafile형태를 비교하게 되는데,
단, datafile형태의 경우 permanent type에 대해서는 언급하지 않는다.
(1) tempile의 특징
Oracle7.3에서 tablespace에 생성시 temporary option을 이용하여 생성되는
tablespace를 구성하는 화일은 datafile이다. 단지 이것이 기존의 permanent
type과 구별되는것은 이 tablespace에 생성되는 segment들이 매번 sort
operation마다 별도로 생성되는 대신, 하나의 segment로 만들어지면서
다른 session에서의 sort operation이 같은 segment를 공유하는 것이다.
(자세한 것은 <Bulletin#: 11938> 참조)
Oracle8.1부터 추가된 tempfile형태의 중요한 특징은 tempfile에 발생하는
변경사항은 redo log file에 기록되지 않는다는 것이다. tempfile에
checkpoint정보도 기록하지 않고 이에 따라 datafile recovery시에도
tempfile에 대해서는 recovery가 필요없게 된다.
이와 같은 이유로 standby database에서 read-only mode로 open하고
조회시 sort가 발생하여 tempfile이 변경되는것은 문제가 되지 않아
사용이 가능하다.
그리고 이미 앞에서 설명한 것과 같이 tempfile은 항상 locally managed
type으로만 생성이 되며, datafile형태의 temporary tablespace는 다음과
같이 locally managed type으로 생성 자체가 불가능하다.
SQL> create tablespace temp_datafile_local
2 DATAFILE '/ora/oradata/V920/temp_data.dbf' size 100M
3 TEMPORARY
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;
ORA-25144: invalid option for CREATE TABLESPACE with TEMPORARY contents
(2) temporary tablespace 생성 방법 비교
- tempfile형태의 경우
tempfile로 temporary tablespace를 생성하는 경우는 다음과 같이
생성하여야 하며, 반드시 locally managed 형태로만 생성 가능하다.
SQL> create TEMPORARY tablespace temp_tempfile_local
2 TEMPFILE '/ora/V920/temp_temp.dbf' size 100M
3 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;
아래 명령어에서 3번 line을 제거하고 생성하여도 default로 locally
managed로 생성이 되며, dictionary managed 형태로 생성하고자
3번 line대신 storage option을 추가하면
ORA-2180 (invalid option for CREATE TABLESPACE) 오류가 발생한다.
- datafile형태의 경우
다음과 같은 형태로 생성하게 되면, dictionary managed type의
temporary datafile형태로 tablespace가 만들어진다. 단, 9i의 경우
이미 앞에서 언급한대로 system tablespace가 locally managed인 경우에는
이와 같은 dictionary managed tablespace 생성은 ORA-12913이 발생하면서
불가능하게 된다.
SQL> create tablespace temp_datafile_dict
2 datafile '/ora/oradata/V920/temp_data.dbf' size 100M
3 TEMPORARY;
(3) dictionary view 의 차이
먼저 dba_tablespaces를 통해
SQL> select tablespace_name, contents, extent_management,
allocation_type from dba_tablespaces;
TABLESPACE_NAME CONTENTS EXTENT_MAN ALLOCATIO
TEMP_TEMPFILE_LOCAL TEMPORARY LOCAL UNIFORM
TEMP_DATAFILE_DICT TEMPORARY DICTIONARY
- tempfile의 경우
SQL> select STATUS, ENABLED, NAME from v$tempfile;
STATUS ENABLED NAME
ONLINE READ WRITE /ora/V920/temp_temp.dbf
SQL> select FILE_NAME, TABLESPACE_NAME from dba_temp_files;
FILE_NAME TABLESPACE_NAME
/ora/V920/temp_temp.dbf TEMP_TEMPFILE_LOCAL
- datafile 형태의 경우
다음과 같이 v$datafile과 dba_data_files를 통해 조회한다.
SQL> select STATUS, ENABLED, NAME from v$datafile;
STATUS ENABLED NAME
ONLINE READ WRITE /ora/oradata/V920/temp_data.dbf
SQL> select FILE_NAME, TABLESPACE_NAME from dba_data_files;
FILE_NAME TABLESPACE_NAME
/ora/oradata/V920/temp_data.dbf TEMP_DATAFILE_DICT
(4) tempfile의 삭제에 대해서
datafile의 경우 tablespace를 삭제하지 않고 datafile만 삭제하는 방법은
존재하지 않는다. 물론 alter database datafile 'filename' offline drop;
과 같은 command가 있지만 이것도 datafile을 데이타베이스에서 지워주는
것이 아니며 이렇게 offline drop된 datafile을 포함하는 tablespace는
recovery가 불가능한 경우라면 tablespace자체를 삭제해야 한다.
그런데 tempfile의 경우는 temporary tablespace는 그대로 유지한 채,
tempfile만 삭제하는 것이 가능하다.
SQL> alter database tempfile '/oradata/V817/temp_temp01.dbf'
2 drop;
8i의 경우라면 이와 같은 명령어 후 실제 directory로 이동하여 직접
tmep_temp01.dbf를 삭제하여야 한다.
9i에서는 drop뒤에 including datafiles 라는 option을 추가하여 tempfile의
drop시 바로 os상에서도 삭제되도록 할 수 있다.
SQL> alter database tempfile '/oradata/V817/temp_temp01.dbf'
2 drop including contents;
만약 이러한 방법으로, tempfile을 해당 temporary tablespace에서 모두
삭제한 경우, 실제 해당 tablespace에 disk sort가 필요하게 되면,
그때는 ORA-25153 (Temporary Tablespace is Empty) 오류가 발생하게 된다.
이때는 다음과 같이 임의의 tempfile을 다시 추가할 수 있다.
SQL> alter tablespace TEMP_TEMPFILE_LOCAL
2 add tempfile '/oradata/V817/temp_temp02.dbf';
Reference Documents
<Note:160426.1> TEMPORARY Tablespaces : Tempfiles or Datafiles ?
글 수정:
민천사 (민연홍)
글 수정:
민천사 (민연홍)
가장 중요한 v$session의 sql_hash_value 컬럼이 안들어가서
수정하였습니다. 죄송합니다.

System Tablespace dropped

Similar Messages

Maybe you are looking for