Datafile recovery

Hi all,
In one of the database, A datafile lets say datafile 5 got corrupted and not consistent with all other datafiles. The reason is because of the changes i have made are
1. The database was in archivelog mode and i have archived logs till sequence 31.
2. I have offlined datafile 5 for some reason and forget to bring it online
3. I have a need to flashback database until date 09/02/2010 (without taking datafile 5 online) and opened with resetlogs, because of reset logs the archived logs has reset to 1 and I have archive logs from 1 to present.
4. I have tooK offline backup for database after database open with resetlogsid
5.Now all the archivelogs and all backups are invalid as because database is opened with resetlogs. Not realizing the datafile 5 is in offline, I have deleted all archived logs till sequence *31* (old archive logs before resetlogsid)
6. Now the current situation is I have database opened with datafile 5 still offline, If i have to make datafile 5 online i need to recover it first but it is asking to apply archive log sequence 31 which i dont have. and the datafile cannot be online.
Is there any way to recover datafile 5 which is not consistent with other datafiles?
Thanks all in advance...

If you don't have archivelog needed to recover this datafile then it's pretty much a goner.
Do you have full backup of DB before you offline datafile? You can try to restore that copy and get the content back.

Similar Messages

Rman datafile recovery ORA-01178

Hi Team,
I need to suggestion in recovering this file.
SQL> /
NAME STATUS
+DATA_GRP/demo/datafile/test.dbf RECOVER
Here I manually removed the file from asm.
ASMCMD> ls -ltr
Type Redund Striped Time Sys Name
DATAFILE UNPROT COARSE SEP 02 14:00:00 Y SYSAUX.264.695779475
DATAFILE UNPROT COARSE SEP 02 14:00:00 Y SYSTEM.263.695779475
DATAFILE UNPROT COARSE SEP 02 14:00:00 Y UNDOTBS1.266.695779475
DATAFILE UNPROT COARSE SEP 02 14:00:00 Y USERS.262.695779511
DATAFILE UNPROT COARSE SEP 02 15:00:00 Y TEST.271.696521689
N test.dbf => +DATA_GRP/DEMO/DATA
FILE/TEST.271.696521689
ASMCMD> rm -f test.dbf
ASMCMD> ls -ltr
Type Redund Striped Time Sys Name
DATAFILE UNPROT COARSE SEP 02 14:00:00 Y SYSAUX.264.695779475
DATAFILE UNPROT COARSE SEP 02 14:00:00 Y SYSTEM.263.695779475
DATAFILE UNPROT COARSE SEP 02 14:00:00 Y UNDOTBS1.266.695779475
DATAFILE UNPROT COARSE SEP 02 14:00:00 Y USERS.262.695779511
Then I tried to recreate the datafile, But I failed
SQL> alter database create datafile 5;
alter database create datafile 5
ERROR at line 1:
ORA-01178: file 5 created before last CREATE CONTROLFILE, cannot recreate
ORA-01110: data file 5: '+DATA_GRP/demo/datafile/test.dbf'
and also I tried to restore the datafile.same error.
RMAN> restore datafile 5;
Starting restore at 02-SEP-09
using channel ORA_DISK_1
creating datafile fno=5 name=+DATA_GRP/demo/datafile/test.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 09/02/2009 17:50:47
ORA-01178: file 5 created before last CREATE CONTROLFILE, cannot recreate
ORA-01110: data file 5: '+DATA_GRP/demo/datafile/test.dbf'
could anyone suggest me to recover the datafile and my retention policy is set to none.
Thanks & Regards,
Muhammed Thameem. S

You look remarkably close to both toast and a runner up spot on a reality TV show titled "What were you thinking when you ....?"
Open an SR at metalink.

Datafile recovery from corrupted hard disk

Hi Guys,
Im using oracle 8i 8174 on windows 2000 server.
Suddenly out of four hard disks one of them corrupted. No RAID configuration.
This disk is F: drive partition only and having a datafile.
Windows 2000 server is working fine , but database is not opened due to failure of hard disk.
I have export of one day back.
I want to recover datafile file from export which is in corrupted hard disk.
Pls guide me.
Arvind
Edited by: Arvindcbg on Mar 4, 2011 6:10 AM

no redundancy, no physical backup and you have lost complete drive/partition.
But better having something than nothing, you got export dump created from last night.
You need to create a new database and just do the import using last night export dump file.
Also, ZIP all the existing database files, and keep them safe, if you are manage to repair the disk, could be useful to get the data for a day..

Database Datafiles Recovery. ORA-01219: database not open:

Hi,
I have a 10g database running on SuSE Linux server. I mistakenly deleted one of my file system's files that contain some of the database datafiles. I can connect to the database but I am failing to run queries:
SQL> select * from global_name;
select * from global_name
ERROR at line 1:
ORA-01219: database not open: queries allowed on fixed tables/views only
I do weekly cold backups of the server. My database is in NOARCHIVE log mode. What is the best way to recover my data; Is it possible that I restore only the file system or I should should do a complete restore of all file systems??
Regards
Kevin
Edited by: Kevin Honde on Jul 28, 2010 2:55 PM

I mistakenly deleted one of my file system's files that contain some of the database datafiles.Ok
I do weekly cold backups of the server.Great !!
My database is in NOARCHIVE log mode. That's the mistake in my opinion
What is the best way to recover my data; Restore it from the latest available cold backup.
There will be a data loss post weekly consistent cold backup. Which you have to accept because you do not have your database running in Archive Log mode.

Sysaux datafile recovery

Dear all,
10gr2 on windows 2003.
SYSAUX datafile is corrupted in our environment and I don't have the necessary archive logs to recover the datafile. Am planning to create a new database and migrate the data there . I tried
a) full db export and schema level export fails with the below error :
EXP-00056: ORACLE error 376 encountered
ORA-00376: file 3 cannot be read at this time
ORA-01110: data file 3: 'S:\ORACLE\PRODUCT\10.2.0\ORADATA\BICCO\SYSAUX01.DBF'
EXP-00000: Export terminated unsuccessfullyall the data in a single tablespace called users . when am trying to export that tablespace (transportable tablespace) am getting the below error :
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
server uses AL32UTF8 character set (possible charset conversion)
Note: table data (rows) will not be exported
About to export transportable tablespace metadata...
EXP-00008: ORACLE error 1001 encountered
ORA-01001: invalid cursor
ORA-06512: at "SYS.DBMS_SYS_SQL", line 899
ORA-06512: at "SYS.DBMS_SQL", line 19
ORA-06512: at "SYS.DBMS_TTS", line 838
ORA-00376: file 3 cannot be read at this time
ORA-01110: data file 3: 'S:\ORACLE\PRODUCT\10.2.0\ORADATA\BICCO\SYSAUX01.DBF'
ORA-06512: at "SYS.DBMS_PLUGTS", line 1387
ORA-06512: at line 1
EXP-00000: Export terminated unsuccessfullyC:\Documents and Settings\ducadmin>exp transport_tablespace=y tablespaces=USERS file=USERS2_Feb11_4
.27.dmp log=USERS2_Feb11_4.27.log statistics=none
Export: Release 10.1.0.4.2 - Production on Thu Feb 11 16:28:06 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Username: sys as sysdba
Password:
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
server uses AL32UTF8 character set (possible charset conversion)
Note: table data (rows) will not be exported
About to export transportable tablespace metadata...
EXP-00008: ORACLE error 1001 encountered
ORA-01001: invalid cursor
ORA-06512: at "SYS.DBMS_SYS_SQL", line 899
ORA-06512: at "SYS.DBMS_SQL", line 19
ORA-06512: at "SYS.DBMS_TTS", line 838
ORA-00376: file 3 cannot be read at this time
ORA-01110: data file 3: 'S:\ORACLE\PRODUCT\10.2.0\ORADATA\BICCO\SYSAUX01.DBF'
ORA-06512: at "SYS.DBMS_PLUGTS", line 1387
ORA-06512: at line 1
EXP-00000: Export terminated unsuccessfully
How do I proceed in this situation ?.. copying the data manually to other database is hectic as the data is huge.
Please advise ?
Kai

Dear Mark,
I cannot able to export schema level as it is failing with the below error :
S:\Backup\g_BACKUP\feb13>exp system/manager@BICCO file=Feb13_c012006.dmp owner=c012006 statistics=no
ne rows=Y constraints=Y
Export: Release 10.1.0.4.2 - Production on Sat Feb 13 11:57:42 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
Export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
server uses AL32UTF8 character set (possible charset conversion)
About to export specified users ...
. exporting pre-schema procedural objects and actions
. exporting foreign function library names for user C012006
. exporting PUBLIC type synonyms
. exporting private type synonyms
. exporting object type definitions for user C012006
About to export C012006's objects ...
. exporting database links
. exporting sequence numbers
. exporting cluster definitions
EXP-00056: ORACLE error 376 encountered
ORA-00376: file 3 cannot be read at this time
ORA-01110: data file 3: 'S:\ORACLE\PRODUCT\10.2.0\ORADATA\BICCO\SYSAUX01.DBF'
EXP-00000: Export terminated unsuccessfully
Kai

Problem with oracle 11g XE restore is destroyed. Can I use the datafiles to restore information?

Hello,
My home machine (win 7) suffered from hardware failure.
My backup seems to be unusable.
Fortunately I had the data folder on a separate drive so all my database files are safe.
Is it possible to install a fresh 11g XE and use the database files to restore the data?

>> but the tablespace is totaly empty
That is what REUSE does when adding a datafile.
When datafiles from an old instance are available, they can be added to the instance by recreating the controlfile(s), either a) adjust the CONTROL_FILES parameter to point at new filename(s), or b) just move (or remove) all the instance controlfiles, shutdown immediate; startup nomount, do the CREATE CONTROLFILE ... ; DDL, alter database open resetlotgs; and recreate the tempfile(s).
See the post How to and when to recreate control files. for a nice how-to.
Basically the create controlfile steps bring the old instance back to life (aka reincarnate). The important bit can be had by doing an alter database backup controlfile to trace; as mentioned in one of the comments, trace file with the DDL is created in the instance trace folder with the create controlfile... and other bits of info.
One caveat, if the instance was open datafile recovery is required before opening the database, and will require the archivelog files to redo committed transactions and rollback uncommitted transactions. If the instance was not in archivelog mode, the old redo logfiles *might* have enough info for the recovery. Or they may not- that is a risk of noarchivelog mode.

Problem in creating Datafile

Hi all,
I am doing some kind of testing in my test maching and I faced the following situation.
I have a good control file and all the archives starting from the 1st scn. Now I brought down the instance and physically deleted a datafile and tried bringing up the db. This time it couldnt open the db as a file is missing, so I created the datafile and gave the recover database command and things opened up fine. No I backed up the ctrl file to trace and brought down the instance. Now I deleted my controlfile and recreated it successfully by using the script that I got from trace and tried the datafile drop and recreate trick as before, but in this case I couldn't create the datafile. Can anybody explain me why is this behaviour?

KRIS wrote:
Version is 11.2.0.1.0
OS is Red Hat Enterprise Linux Server release 5.5
As told earlier I tried to create the deleted datafile and this is the error I got.
13:20:44 SQL> alter database create datafile 4 as '/oracle/abhi/data/users.dbf'; alter database create datafile 4 as '/oracle/abhi/data/users.dbf'
ERROR at line 1:
ORA-01178: file 4 created before last CREATE CONTROLFILE, cannot recreate
ORA-01110: data file 4: '/oracle/abhi/data/users.dbf'
I can understand the error, but I want to understand what happens internally under such circumstances and why such a datafile recovery is not allowed in oracleonly you can re-create datafile without backup in archivelog mode, the datafile creation should be less than the control file creation time.
if you re-create the control file then you cannot use the command "alter database create datafile" .
you can use only for the datafiles created after control file creation time.
check:-
SQL> select creation_time,name from v$datafile;
CREATION_ NAME
17-APR-07 D:\ORACLE\PRODUCT\10.2.0\ORADATA\DEMODB\SYSTEM01.DBF
17-APR-07 D:\ORACLE\PRODUCT\10.2.0\ORADATA\DEMODB\UNDOTBS01.DBF
17-APR-07 D:\ORACLE\PRODUCT\10.2.0\ORADATA\DEMODB\SYSAUX01.DBF
17-APR-07 D:\ORACLE\PRODUCT\10.2.0\ORADATA\DEMODB\USERS01.DBF
27-JUL-11 D:\ORACLE\PRODUCT\10.2.0\ORADATA\DEMODB\EXAMPLE01.DBF
27-JUL-11 D:\ORACLE\PRODUCT\10.2.0\ORADATA\DEMODB\USER02.DBF
6 rows selected.
6 rows selected.
SQL> select controlfile_created from v$database;
CONTROLFI
27-JUL-11

TEMPORARY TABLESPACE에서 TEMPFILE 과 DATAFILE의 차이점 (8.1.X ~ 9I)

제품 : ORACLE SERVER
작성날짜 : 2003-11-27
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 ?

제품 : ORACLE SERVER
작성날짜 : 2003-11-27
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 ?

ORACLE8: RECOVERY MANAGER 사용 방법(RMAN)

제품 : ORACLE SERVER
작성날짜 : 1997-11-17
Oracle 8 NEW : Recovery manager 란 ?
====================================
- 소개
Oracle 8 은 새로운 backup와 recovery 방법인 Recovery manager 를 제공한다.
Recovery manager(이하 RMAN) 는 backup,restore,recover process를 관리하는
tool 이다. Oracle Enterprise Manager 를 통해 GUI mode 로 가능하고,
rman 이라는 command line interface 를 함께 제공한다.
특히, OS device control 기능이 보완 되었기 때문에, 현재 backup catalog 를
유지하고, 이 정보를 이용해 OS level 에서 file 을 auto-restore 해 주기
때문에, database recovery 전에 file 을 manual 하게 restore 할 필요가
없어졌다.
Incremental backup 을 제공하고, backup 이나 restore 중에 current block
detection 을 해 주며(v$backup_corruption, v$copy_corruption 또는 alert
log 에 report), Rman 작업시에 parallelization 을 제공하며, open database
backup 동안 특별한 redo 를 발생하지 않는다.
- 구조
Recovery
manager in OEM(oracle
 enterprise ---> Database
 manager) <--- (catalog)
or RMAN
 /| |
 | |/
DATABASE ---> OS
(target to backup) <--- Device
- 구성 요소 설명
1) recovery manager
Command 를 해석하고, backup, restore, recover 를 실행하기 위해 target
database 로 command 를 전달한다. recovery catalog 를 update 한다. 실행
과정을 조정, 모니터링 한다.
2) Target database
backup,restore,recovery action 이 수행될 데이타베이스
3) Recovery Catalog
Information 저장장소. 즉, target database 의 물리적 스키마, datafile 과
archivelog 의 backup sets 과 pieces, backup script 등을 포함하고 있음.
rman 작업시 recovery catalog 정보를 이용한다.
4) channel
allocation channel 은 target database 의 backup,restore,recover 에 대한
server process 초기화를 한다. 즉, 이 channel 은 disk 를 포함 기타 OS
device 를 지정하게 되며, 이 갯수에 따라 parallelization 의 degree 가 결정
된다.
- recovery catalog 를 사용할 것인지를 결정하기
catalog 없이 RMAN 을 사용할 때의 단점은 recovery catalog 의 overhead 가
없는 대신, Point-In-Time recovery 를 쉽게 할 수 없다. 또한, control file
손상시에 recovery 할 수 없고, stored script 를 사용할 수 없다.
(datafile 이 20개 이상일 경우에는 recovery catalog 사용을 권장한다.)
- Setup
가. Recovery catalog 생성
1. Backup(target) db 외의 별도의 db 생성 (8.0.3 이상)
2. catalog DB 에 분리된 tablespace 생성
create tablespace rcvcat datafile '/oracle/rcvcat/rcvcat01.dbf'
size 20 M;
3. catalog 의 owner 생성과 권한부여
 create user rman identified by rman
 temporary tablespace temp
 default tablespace rcvcat;
 grant dba,connect,resource,recovery_catalog_owner to rman;
4. catalog 저장에 필요한 object 생성
 cd $ORACLE_HOME/rdbms/admin
 sqlplus rman/rman
 @catrman
나. Recovery manager 기동
1. recovery catalog DB 를 사용하는 경우
rman target \"system/manager\" rcvcat \"rman/rman@orabeta1\"
(orabeta1 은 catalog DB 로 접속하는 tnsname 입니다.
즉, sqlplus rman/rman@orabeta1 하면, catalog db 와 접속되어야 합니다.)
2. recovery catalog DB 를 사용하지 않는 경우
rman target system/manager@target nocatalog
위 경우 모두, target database 를 catalog 에 등록해야 한다.
RMAN> register database;
다. Backup 시작
- Backup 은 database 가 open 또는 close(close 후에는 반드시 mount
상태이어야 한다)
- Backup 의 단위
 full database
 tablespace
 datafile
 control file
 archived logs
- Backup 의 예
--full database
run {
allocate channel dev1 type disk;
allocate channel dev2 type disk;
backup full filesperset 2
(database format '/user7/ora8/backup.%n_%p') ;
release channel dev1;
release channel dev2;
-- tablespace
run {
allocate channel dev_1 type disk ;
backup incremental level 0
filesperset 1
(tablespace system channel dev_1 format '/vol312/net8%d_%u');
release channel dev_1;
-- datafile
run{
allocate channel dev1 type disk;
copy datafile "/vo3/orabeta6/backup/copy_tools.dbf"
to "/vo3/orabeta6/oradata/orabeta6/tools01.dbf"
tag "org_tools";
release channel dev1;
-- archived logs
create script beta_arch_full {
allocate channel dev1 type disk;
allocate channel dev2 type disk;
backup full filesperset 10
(archivelog all delete input
format '/vo3/orabeta6/backup/beta_arch.%s_%p') ;
release channel dev1;
release channel dev2;
-- backup to tape
run {
allocate channel t1 type 'sbt_tape';
backup
format 'dbfull_sunday_s%s_t%t'
tag 'Sunday full backup'
(database);
라. Restore
- Backup 으로 부터 원래 위치로 복원
- Archive log file 은 manual 하게 restore 할 수도 있고, 필요하다면
recovery 시 자동으로 restore 된다.
restore (archivelog all| like <filename | <archivelog range>);
- restore 명령
database : restore (database);
tablespace : restore (tablespace <name>,...,<name>);
datafile : restore (datafile <name>,...,<name>);
control file : restore control file to location;
- recovery 시에 database 는 어떤 상태에 있어야 하는가 ?
1) control file restore - not mount
 SVRMGRL> startup nomount
2) whole database, or system tablespace - not open
 SVRMGRL> startup mount
3) tablespace or datafile - open but tablespace or datafile offline
 SVRMGRL> alter tablespace user_data offline temporary;
 SVRMGRL> alter database datafile '/oracle/file/user_data1.dbf' offline;
마, Recovery
- Recoervy 는 file restore 후의 과정이다.
1) Archive log mode : complete recovery, incomplete recovery 가 가능하다
2) No archive log mode : consistent whole database backup 으로 부터
restore 하는 것이 유일한 option 이다.
- whole database recovery 의 예
svrmgrl
connect internal
shutdown abort
startup mount
rman target \"system/manager\" rcvcat \"rman/rman@orabeta1\"
run {
allocate channel dev1 type disk;
allocate channel dev2 type disk;
restore database;
recover database;
release channel dev1;
release channel dev2;
or
run {
allocate channel dev1 type disk;
allocate channel dev2 type disk;
restore tablespace 'SYSTEM';
restore tablespace 'USERS';
recover tablespace 'SYSTEM';
recover tablespace 'USERS';
sql "alter database open ";
release channel dev1;
release channel dev2;
- datafile 하나가 사용할 수 없을 경우의 recovery
가정) full backup set 이 있을 경우
ORA-01157: cannot identify data file 3 - file not found
ORA-01110: data file 3: '/user7/ora8/oradata/ORA8/temp01.dbf'
SVRMGR> startup mount
rman target \"system/manager\" rcvcat \"rman/rman@orabeta1\"
RMAN> run {
allocate channel dev1 type disk;
restore database;
recover database;
release channel dev1;
};

Check the TSM logs for errors, the error stack here doesn't show any useful information (only informational messages and an undefined exit code). This is an 8i problem, later releases transfer much better messages from the media management software.

Can not open database. Also can not perform recovery

Hi Experts,
I scheduled a daily incremental backup of whole database and after doing a back up tried to restore whole back up. This was done in dev. system to perform documentation. But when I tried to recovery from back up ..i got errors. I tried to restart oracle services and even restarted server ..no joy.
In the EM i am getting the below error -
"The database status is currently unavilable. It is possible that the database is mount or nomount state. Click 'Startup' to obtain the current status and open the database. If database can not be opended, 'Perform Recovery' to perform appropriate recovery operation."
Then tried to startup database - got the below status message. Could not start up
Current Status : Mounted
Operation : Open the database
Then tried to perform recovery - I got the below error - (I could only do datafile recovery)
Restore error
ORA-16038: log 2 sequence#29178 can notbe archived
ORA-19809: Limit exceeded for recovery files
ORA-00312: online log 2 thread 1: 'C;\ORACLE\PRODUCT\10.1.0\ORADATE\ZUMA\RED0O2.LOG
Can anyone help to open my database ???
Regards,
Ranjith

Hi ,
Thanks very much for the quick reply. I have increased the db_recovery_file_dest_size to 5 GB.
My Recovery folder structure is like this -
Path: C:\oracle\product\10.1.0\flash_recovery_area\ZUMA
ARCHIVELOG
- 2009_02_22 - has many files
- 2009_02_23 - has many files
- 2009_02_24 - no files
AUTOBACKUP
2009_02_22 - One file
DATAFILE
- No files
FLASHBACK
- Many files under this directory
Perform Recovery: Credentials
Information
The database is currently down. Enter the host OS credentials and the database credentials to continue.
Current Database Information
ARCHIVELOG Mode - ARCHIVELOG
Current Status - MOUNTED
Perform Recovery: Point-in-time
Step 1 of 4
Database zuma
Object Type Whole Database
Operation Type Restore and Recover
Perform Recovery: Review
Step 4 of 4
Database zuma
Object Type Whole Database
Operation Type Restore and Recover
Backup The most recent backup
Point-in-time Recover to the current time
Click on the 'Edit RMAN Script' button to view or edit the RMAN script before submitting the operation.
RMAN Script
RMAN Script run { restore database; recover database; alter database open; }
Recovery Manager: Release 10.1.0.2.0 - Production
Copyright (c) 1995, 2004, Oracle. All rights reserved.
RMAN>
connected to target database: ZUMA (DBID=966845288)
using target database controlfile instead of recovery catalog
RMAN> 2> 3> 4> 5>
Starting restore at 25-FEB-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=154 devtype=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/25/2009 21:47:14
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore
RMAN>
Recovery Manager complete.
This is the error I get when I execute recovery. But when I try to startupdatabase ..it again goes to the same start up page.
Regards,
Ranjith

Audit file - media recovery

After shutdown our 8.1.7.4 database had a datafile change to the audit_data_01.dbf file. (4 hours later). Unfortunately, we were moving the database to a new server the next day and are now unable to bring the database back up. Error is that the file (51337) is smaller than the correct size of 64k. Actual size of file is 420mb. Original server has the file at the same size as moved so old and new are still identical. What happened and what can I do to bring the database back up?
All processes were down prior to the move.
Audit init file parameter was set to true.

apparently there is not a cron that could have affected the file so it must have been a backup or a transfer/tar failure. I'll have to check tomorrow when I go in to see if the audit file is in a separate tablespace. I didn't create these databases, they've been around for several years. It is not named consistently with the other appication files so we are not sure how it was created. Losing the data/change after the shutdown will not be an issue. It looks at this time like we're facing either a recover database until time x recovery, a datafile recovery or a database recovery tomorrow morning. Any advice on which to try first? or which is most likely to work without causing further damage? or alternatives?

Resize datafile when database is mount

Hello,
I need resize datafile when database is mount not open(I recover database).
Is it posible?

Try making the tablespace offline, opening the database and resizing the datafile. After you resize the datafile, recover the tablespace or just the datafile.
In Oracle documentation: Backup & Recovery Guide, you can find more details of these options:
=>RECOVER TABLESPACE Statement
RECOVER TABLESPACE performs media recovery on all datafiles in the tablespaces listed. For example, enter the following at the SQL prompt to recover tablespace TBS_1:
RECOVER TABLESPACE tbs_1
The tablespaces must be offline to perform the recovery. Oracle indicates an error if none of the files require recovery.
=> RECOVER DATAFILE Statement
RECOVER DATAFILE lists the datafiles to be recovered. For example, enter the following at the SQL prompt to recover datafile /oracle/dbs/tbs_22.f:
RECOVER DATAFILE '/oracle/dbs/tbs_22.f'
The database can be open or closed, provided that you can acquire the media recovery locks. If the database is open in any instance, then datafile recovery can only recover offline files.
Hope it helps.
Eliane

Backup_restore problem with sapdb

Hello,
i'm searching a way to backup my sapdb of my content server.
And I'm using dbmcli at the moment.
so i made 2 backup_media stores with the following instruction
dbmcli -d SDB -u superdba,admin backup_media_put datafiles J:\Backup_content\data\data.backup FILE DATA 0 8 YES
dbmcli -d SDB -u superdba,admin backup_media_put logfiles J:\Backup_content\log\log.backup FILE DATA 0 8 YES
after that i say he must make backups to those backup media's
dbmcli -d SDB -uUTL -u superdba,admin -o J:\Backup_content\savestate.log backup_save_state
dbmcli -d SDB -uUTL -u superdba,admin -o J:\Backup_content\datafilebackup.log backup_save datafiles recovery data
dbmcli -d SDB -uUTL -u superdba,admin -o J:\Backup_content\logilebackup.log backup_save logfiles recovery log
after that i check my backup
dbmcli -d SDB -uSRV -u superdba,admin backup_restore_check datafiles data
all is working well until this point
when i want to restore it
i'm using the following instruction
dbmcli -d SDB -uUTL -u superdba,admin backup_restore datafiles data
and its giving me an error message
ERR
-24988,ERR_SQL: sql error
-3014,Invalid end of SQL statement
I looked at the help.sap.com and i found the following
backup_restore <medium> <type> [ExternalBackupID <external_backup_ID>] [<nnn>] [UNTIL <date> <time>]
With this command you read a backup.
<medium>
Medium from which the backup is to be read.
When restoring a backup made on several media at the same time, you must enter the name of the backup media group here.
<type>
Type of backup to be imported: DATA, PAGES or LOG
<nnn>
Actual backup version on the backup carrier that is being checked; relevant only for media of type FILE .
UNTIL <date> <time>
For log backups you can enter an exact time up to which the log backups are to be read.
ExternalBackupID <external_backup_ID>
1. I'm thinking i need to fill in the <nnn> field but what do i have to fill in?
2. Am I making a good backup?

Hi,
an important thing to note: to be able to restore/recover you need to put the db instance in admin/cold:
(version MaxDB 7.4, 7.5)
dbmcli -d <SID> -u <dbm-user>,<pwd> db_admin
(version SAP DB 7.3)
dbmcli -d <SID> -u <dbm-user>,<pwd> db_cold
I don't believe you need to use the <nnn> part in your case.
If you still get an error message, please let me know which exact error you got and its context.
Regards,
Roland

ORACLE PARALLEL SERVER (OPS)

제품 : ORACLE SERVER
작성날짜 : 2004-08-13
ORACLE PARALLEL SERVER (OPS)
==============================
PURPOSE
다음은 OPS(ORACLE PARALLEL SERVER) 의 구조에 대해서 알아본다.
SCOPE
Standard Edition 에서는 Real Application Clusters 기능이 10g(10.1.0) 이상 부터 지원이 됩니다.
Explanation
1. Parallel Server Architecture
OPS는 다수의 Loosely Coupled System들 간의 원활한 Resource
Sharing을 위해 제공하는 DLM(PCM)을 이용하여 동시에 다수의
사용자가 각 Node를 통해 한 Database를 Access함으로써 System의
가용성과 전체적인 성능을 극대화시키기 위한 다중처리 System
구성이다.
(1) Loosely Coupled System
SMP Machine과 같이 Tightly Coupled System들 간에 Data Files,
Print Queue 같은 Resource를 공유하기 위한 Shared Disk
Architecture로 Node간의 정보전송은 Common High-Speed Bus를
이용한다.
(2) Distributed Lock Manager(DLM)
Loosely Coupled System에서 Resource Sharing을 조정,관리하는
Software로 Application들이 같은 Resource에 대해 동시에 Access를
요구할 때 서로간의 Synchronization을 유지하며 Conflict가
발생하지 않도록 하는 기능을 담당한다.
다음은 DLM의 주요 Service이다
- Resource에 대한 Current "ownership" 유지 관리
- Application Process들의 Resource Request Accept
- 요구한 Resource가 가용할 경우 해당 Process에 공지
- Resource에 대한 Exclusive Access 허용
(3) Parallel Cache Management(PCM)
Data File내의 하나 이상의 Data Block을 관리하기 위해
할당되는 Distributed Lock을 PCM Lock이라 하며 어떤 Instance가
특정 Resource를 Access하기 위해서는 반드시 그 Resource의 Master
Copy의 "owner"가 되어야 한다.
이는 곧 그 Resource를 Cover하는 Distributed Lock의 "owner"가
됨을 의미한다. 이러한 "owner ship"은 다른 Instance가 동일
Data Block 또는 그 PCM Lock에 의해 Cover되고 있는 다른 Data
Block에 대한 Update 요구가 있을때까지 계속 유지된다.
"owner ship"이 한 Instance에 다른 Instance로 전이 되기 전에
변경된 Data Block은 반드시 Disk로 "write"하므로 각 Node의
Instance간 Cache Coherency는 철저하게 보장된다.
2. Parallel Server의 특성
- Network상의 각 Node에서 Oracle Instance 기동 가능
- 각 Instance는 SGA + Background Processes로 구성
- 모든 Instance는 Control File과 Datafile들을 공유
- 각 Instance는 자신의 Redo Log를 보유
- Control File, Datafiles, Redo Log Files는 하나 이상의
Disk에 위치
- 다수의 사용자가 각 Instance를 통해 Transaction 실행 가능
- Row Locking Mode 유지
3. Tuning Focus
서로 다른 Node를 통해서 하나의 Database 구성하의 Resource를
동시에 사용하는 OPS 환경에서 Data의 일관성과 연속성을 위한
Instance간의 Lock Managing은 불가피한 현실이다. 즉, 위에서
언급한 Instance간의 Resource "owner ship"의 전이(pinging 현상)
와 같은 Overhead를 최소화하기 위해선 효율적인 Application
Partition(Job의 분산)이 가장 중요한 현실 Factor이다.
다시 말해 서로 다른 Node를 통한 동일 Resource에의 Cross-Access
상황을 최소화해야 함을 의미한다.
다음은 OPS 환경에서 Database Structure 차원의 Tuning Point로서
PCM Lock 관련 GC(Global Constant) Parameters와 Storage에 적용할
Options 및 기타 필요한 사항이다.
(1) Initial Parameters
OPS 환경에서 PCM Locks를 의해 주는 GC(Global Constant)
Parameters는 Lock Managing에 절대적인 영향을 미치며 각 Node마다
반드시 동일한 Value로 설정(gc_lck_procs 제외)되어야 한다.
일반적인 UNIX System에서 GC Parameters로 정의하는 PCM Locks의
총합은 System에서 제공하는 DLM Configuration 중 "Number of
Resources"의 범위 내에서 설정 가능하다.
- gc_db_locks
PCM Locks(DistributedLocks)의 총합을 정의하는 Parameter로
gc_file_to_locks Parameter에 정의한 Locks의 합보다 반드시
커야 한다.
너무 작게 설정될 경우 하나의 PCM Lock이 관리하는 Data Blocks가
상대적으로 많아지므로 Pinging(False Pinging) 현상의 발생
가능성도 그만큼 커지게 되며 그에 따른 Overhead로 인해 System
Performance도 현격히 저하될 가능성이 크다. 따라서 가능한
최대의 값으로 설정해야 한다.
- False Pinging
하나의 PCM Lock이 다수의 Data Blocks를 관리하므로 자신의
Block이 아닌 같은 PCM 관할하의 다른 Block의 영향으로 인해
Pining현상이 발생할 수 있는 데 이를 "False Pinging"이라 한다.
Database Object별 발생한 Pinging Count는 다음과 같이 확인할 수
있으며 sum(xnc) > 5(V$PING) 인 경우에 더욱 유의해야 한다.
- gc_file_to_locks
결국 gc_db_locks에 정의된 전체 PCM Locks는 각 Datafile 당
적절히 안배가 되는데 전체 Locks를 운용자의 분석 결과에 의거
각 Datafile에 적절히 할당하기 위한 Parameter이다.
운용자의 분석 내용은 각 Datafile 내에 존재하는 Objects의 성격,
Transaction Type, Access 빈도 등의 세부 사항을 포함하되 전체
PCM Locks 대비 Data Blocks의 적절하고도 효율적인 안배가
절대적이다.
이 Parameter로 각 Datafile당 PCM Locks를 안배한 후 Status를
다음의 Fixed Table로 확인할 수 있다.
Sample : gc_db_locks = 1000
gc_file_to_locks = "1=500:5=200"
X$KCLFI ----> 정의된 Bucket 확인
Fileno Bucket
1 1
2 0
3 0
4 0
5 2
X$KCLFH ----> Bucket별 할당된 Locks 확인
Bucket Locks Grouping Start
0 300 1 0
1 500 1 300
2 200 1 800
gc_files_to_locks에 정의한 각 Datafile당 PCM Locks의 총합은 물론
gc_db_locks의 범위를 초과할 수 없다.
다음은 각 Datafile에 할당된 Data Blocks의 수를 알아보는 문장이다.
select e.file_id id,f.file_name name,sum(e.blocks) allocated,
f.blocks "file size"
from dba_extents e,dba_data_files f
where e.file_id = f.file_id
group by e.file_id,f.file_name,f.blocks
order by e.file_id;
- gc_rollback_segments
OPS로 구성된 각 Node의 Instance에 만들어진 Rollback Segment
(Init.ora의 rollback_segments에 정의한)의 총합을 정의한다.
다수의 Instance가 Rollback Segment를 공용으로 사용할 수는 있으나
OPS 환경에서는 그로 인한 Contention Overhead가 엄청나므로 반드시
Instance당 독자적인 Rollback Segment를 만들어야 하며 Instance간
동일한 이름의 부여는 불가하다.
select count(*) from dba_rollback_segs
where status='ONLINE';
위의 결과치 이상의 값으로 정해야 한다.
- gc_rollback_locks
하나의 Rollback Segment에서 동시에 변경되는 Rollback Segment
Blocks에 부여하는 Distributed Lock의 수를 정의한다.
Total# of RBS Locks = gc_rollback_locks * (gc_rollback_segments+1)
위에서 "1"을 더한 것은 System Rollback Segment를 고려한 것이다.
전체 Rollback Segment Blocks 대비 적절한 Locks를 정의해야 한다.
다음은 Rollback Segment에 할당된 Blocks의 수를 알아보는 문장이다.
select s.segment_name name,sum(r.blocks) blocks
from dba_segments s,dba_extents r
where s.segment_name = r.segment_name
and s.segment_type = 'ROLLBACK'
group by s.segment_name;
- gc_save_rollback_locks
특정 시점에서 어떤 Tablespace 내의 Object를 Access하고 있는
Transaction이 있어도 그 Tablespace를 Offline하는 것은 가능하다.
Offline 이후에 발생된 Undo는 System Tablespace내의 "Differred
Rollback Segment"에 기록, 보관 됨으로써 Read Consistency를
유지한다. 이 때 생성되는 Differred Rollback Segment에 할당하는
Locks를 정의하는 Parameter이다.
일반적으로 gc_rollback_locks의 값과 같은 정도로 정의하면 된다.
- gc_segments
모든 Segment Header Blocks를 Cover하는 Locks를 정의한다. 이 값이
작을 경우에도 Pinging 발생 가능성은 그 만큼 커지므로 해당
Database에 정의된 Segments 이상으로 설정해야 한다.
select count(*) from dba_segments
where segment_type in ('INDEX','TABLE','CLUSTER');
- gc_tablespaces
OPS 환경에서 동시에 Offline에서 Online으로 또는 Online에서
Offline으로 전환 가능한 Tablespace의 최대값을 정의하는 것으로
안전하게 설정하기 위해서 Database에 정의된 Tablespace의 수만큼
설정한다.
select count(*) from dba_tablespaces;
- gc_lck_procs
Background Lock Process의 수를 정하는 것으로 최대 10개까지
설정(LCK0-LCK9)할 수 있다. 기본적으로 하나가 설정되지만 필요에
따라 수를 늘려야 한다.
(2) Storage Options
- Free Lists
Free List는 사용 가능한 Free Blocks에 대한 List를 의미한다.
Database에서 새롭게 가용한 Space를 필요로 하는 Insert나
Update시엔 반드시 Free Space List와 관련 정보를 가지고 있는
Blocks Common Pool을 검색한 후 필요한 만큼의 충분한 Blocks가
확보되지 않으면 Oracle은 새로운 Extent를 할당하게 된다.
특정 Object에 동시에 다수의 Transaction이 발생한 경우 다수의
Free Lists는 그만큼 Free Space에 대한 Contention을 감소시킨다.
결국 Free List의 개수는 Object의 성격과 Access Type에 따라
적절히 늘림으로써 커다란 효과를 거둘 수 있다.
예를 들면 Insert나 크기가 늘어나는 Update가 빈번한 Object인
경우엔 Access 빈도에 따라 3 - 5 정도로 늘려줘야 한다.
- freelist groups
Freelist group의 수를 정의하며 전형적으로 OPS 환경에서
Instance의 수만큼 설정한다. 특정 Object의 Extent를 특정
Instance에 할당하여 그 Instance에 대한 Freelist Groups를
유지하므로 Instance별 Free List 관리도 가능하다.
(3) 기타
- Initrans
동시에 Data Block을 Access할 때 필요한 Transaction Entries에
대한 초기치를 의미하며 Entry당 23Byte의 Space를 미리 할당한다.
기본값은 Table이 "1" 이고 Index와 Cluster는 "2" 이다. Access가
아주 빈번한 Object인 경우 Concurrent Transactions를 고려하여
적절히 설정한다.
4. Application Partition
OPS Application Design의 가장 중요한 부분으로 Partitioning의
기본 원리는 다음과 같다.
. Read Intensive Data는 Write Intensive Data로부터 다른
Tablespaces로 분리한다.
. 가능한 한 하나의 Application은 한 Node에서만 실행되도록
한다. 이는 곧 다른 Application들에 의해 Access되는 Data에
대한 Partition을 의미한다.
. 각 Node마다 Temporary Tablespaces를 할당한다.
. 각 Node마다 Rollback Segments를 독립적으로 유지한다.
5. Backup & Recovery
일반적으로 OPS 환경의 Sites는 대부분 24 * 365 Online 상황이므로
전체적인 Database 운영은 Archive Log Mode & Hot Backup으로 갈
수에 없으며 Failure 발생시 얼마나 빠른 시간 안에 Database를
완벽하게 복구 할 수 있는 지가 최대 관건이라 하겠다.
모든 Backup & Recovery에 관한 일반적인 내용은 Exclusive Mode
Database 운영 환경에서와 동일하다.
(1) Backup
- Hot Backup Internal
Archive Mode로 DB를 정상적으로 운영하며 Online Data Files를
Backup하는 방법으로 Tablespace 단위로 행해진다.
alter tablespace - begin backup이 실행되면 해당 Tablespace를
구성하는 Datafiles에 Checkpoint가 발생되어 Memory상의 Dirty
Buffers를 해당 Datafiles(Disk)에 "Write"함과 동시에 Hot Backup
Mode에 있는 모든 Datafiles의 Header에 Checkpoint SCN을 Update
하는데 이는 Recovery시에 중요한 Point가 된다.
또한 alter tablespace - end backup이 실행되기 전까지 즉,
Hot Backup이 행해지는 동안 해당 Datafiles는 "fuzzy" Backup
Data가 생성되며 특정 Record의 변형 시에도 해당 Block이 Redo
Log에 기록 되므로 다수의 Archive File이 더 생성되는 것을 볼 수
있다. 따라서 Admin이 해당 Datafiles를 모두 Backup하고도 end
backup을 실행하지 않으면 전체 인 System 성능에 심각한 영향을
미치게 되므로 특히 주의해야 한다.
Hot Backup 중인지의 여부는 다음 문장을 통해 확인할 수 있다.
select * from v$backup; -> status 확인
- Hot Backup Step (Recommended)
① alter system archive log current
② alter tablespace tablespacename begin backup
③ backup the datafiles,control files,redo log files
④ alter tablespace tablespacename end backup
⑤ alter database backup controlfile to 'filespec'
⑥ alter database backup controlfile to trace noresetlogs(safety)
⑦ alter system archive log current
(2) Recovery
- Instance Failure시
OPS 환경에서 한 Instance의 Failure시 다른 Instance의 SMON이
즉시 감지하여 Failed Instance에 대한 Recovery를 자동으로
수행한다. 이 때 운영중인 Instance는 Failed Instance가 생성한
Redo Log Entries와 Rollback Images를 이용하여 Recovery한다.
Multi-Node Failure시엔 바로 다음에 Open 된 Instance가 그 역할을
담당하게 된다. 아울러 Failed Instance가 Access하던 모든 Online
Datafiles에 대한 Recovery도 병행되는 데 이런 과정의 일부로
Datafiles에 관한 Verification이 실패하여 Instance Recovery가 되지
않을 경우엔 다음 SQL Statement를 실행시키면 된다.
alter system check datafiles global;
- Media Failure시
다양한 형태로 발생하는 Media Failure시엔 Backup Copy를
Restore한 후 Complete 또는 Incomplete Media Recovery를 행해야
하며 이는 Exclusive Mode로 Database를 운영할 때와 전혀 다르지
않다.
Node별 생성된 즉, Thread마다 생성된 모든 Archived Log Files는
당연히 필요하며 많은 OPS Node 중 어디에서든지 Recovery 작업을
수행할 수 있다.
- Parallel Recovery
Instance 또는 Media Failure시 ORACLE 7.1 이상에서는 Instance
Level(init.ora) 또는 Command Level(Recover--)에서 Parallel
Recovery가 가능하다. 여러 개의 Recovery Processes를 이용하여
Redo Log Files를 동시에 읽어 해당 After Image를 Datafiles에
반영시킬 수 있다. Recovery_Parallelism Parameter는 Concurrent
Recovery Processes의 수를 정하며 Parallel_Max_Servers Parameter의
값을 초과할 수는 없다.
(3) 운영 시 발생 가능한 Error
- ORA-1187 발생
ORA-1187 : can not read from file name because it
failed verification tests.
(상황) 하나의 Node에서 create tablespace ... 한 상태에
정상적으로 운영하던 중 다른 Node를 통해 특정 Object를
Access하는데 ORA-1187 발생.
(원인) 다른 Node에서 raw disk의 owner, group, mode 등을
Tablespace가 생성된 후 뒤늦게 전환.
(Admin의 Fault)
(조치) SQL> alter system check datafiles global;
Reference Documents
--------------------

hal lavender wrote:
Hi,
I am trying to achieve Load Balancing & Failover of Database requests to two of the nodes in 8i OPS.
Both the nodes are located in the same data center.
Here comes the config of one of the connection pools.
<JDBCConnectionPool CapacityIncrement="5" ConnLeakProfilingEnabled="true"
DriverName="oracle.jdbc.driver.OracleDriver" InactiveConnectionTimeoutSeconds="0"
InitialCapacity="10" MaxCapacity="25" Name="db1Connection598011" PasswordEncrypted="{3DES}ARaEjYZ58HfKOKk41unCdQ=="
Properties="user=ts2user" Targets="ngusCluster12,ngusCluster34" TestConnectionsOnCreate="false"
TestConnectionsOnRelease="false" TestConnectionsOnReserve="true" TestFrequencySeconds="0"
TestTableName="SQL SELECT 1 FROM DUAL" URL="jdbc:oracle:thin:@192.22.11.160:1421:dbinst01" />
<JDBCConnectionPool CapacityIncrement="5" ConnLeakProfilingEnabled="true"
DriverName="oracle.jdbc.driver.OracleDriver" InactiveConnectionTimeoutSeconds="0"
InitialCapacity="10" MaxCapacity="25" Name="db2Connection598011" PasswordEncrypted="{3DES}ARaEjYZ58HfKOKk41unCdQ=="
Properties="user=ts2user" Targets="ngusCluster12,ngusCluster34" TestConnectionsOnCreate="false"
TestConnectionsOnRelease="false" TestConnectionsOnReserve="true" TestFrequencySeconds="0"
TestTableName="SQL SELECT 1 FROM DUAL" URL="jdbc:oracle:thin:@192.22.11.161:1421:dbinst01" />
<JDBCMultiPool AlgorithmType="Load-Balancing" Name="pooledConnection598011"
PoolList="db1Connection598011,db2Connection598011" Targets="ngusCluster12,ngusCluster34" />
Please let me know , if you need further information
HalHi Hal. All that seems fine, as it should be. Tell me how you
enact a failure so that you'd expect one pool to still be good
when the other is bad.
thanks,
Joe

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 컬럼이 안들어가서
수정하였습니다. 죄송합니다.

Datafile recovery

Similar Messages

Maybe you are looking for