My TEMPORARY TABLESPACE DATAFILE was lost

I completely lost temporary tablespace datafile,
what should I do?
(there is no backup)

It is just a temporary tablespace, who cares. Just drop the tablespace and re-create it.

Similar Messages

  • My datafile was lost No backup and No archivelog mode

    Hi,
    My data file was lost in physical Location but it show's at logical side(Tablespace),
    I have no backup of physical or logical . How can i recover or how can i drop or how can i offline perticular datafile to avoid the work on tablespace.
    Could u plz give to us to u valuable suggestion
    Thanks & regards,
    Srinivasa Rao

    Are you running on Linux?
    Check this one, maybe it helps;
    Linux way of Flashback; how to restore back a dropped datafile
    http://tonguc.wordpress.com/2007/09/04/linux-way-of-flashback-how-to-restore-back-a-dropped-datafile/

  • How to recover data if one datafile was lost

    if i have a tablespace with 5 datafiles 9i or 10g...
    it's a fictional scenario :)
    one was lost during db start up
    and other 4 was still thre
    if no backup avail for restore and no archivelog for recreating the datafile
    how do i recovery data in this tablesapce ??
    thanks in advance!!
    br/ricky

    i know it's against my own statements
    just saying that i'm lazy , and don't want to write those PL/SQL to recovery the data
    alright , here is the story of why i asked this :
    Data source ------- Regional DB ------- Global DB----people
    i'm manaing regional DB which fetchs data from it's source
    and global db fetch's some key data from regional every hour
    so if one datafile in regional db was broken ,
    i don't really care about the data , most of them was already in global db ,
    and people only views report from global db
    and i can just as easy get the lost data from data source ( keeps 3 days )
    so basically what i care most is let the tables back to work ASAP ,
    and not those historical data , it does not matter that much , i only keep 2 weeks of them anyway
    it might appear strange to many DBA that protect the data as treasure....
    as a second thought , this is a somewhat silly question ;)
    thanks anyway ...

  • Temporary tablespace questions

    I have an Oracle 9.2.0.1.0 database running on a Windows 2000 server. I'm encountering several problems with its temporary tablespace. Here is how the temporary tablespace is created:
    create database testdb
    datafile 'd:\oradb\testdb\datafiles\testdbsys1.dbf'
    size 200M AUTOEXTEND ON NEXT 10M
    default temporary tablespace temporary
    tempfile 'd:\oradb\testdb\datafiles\tmp1.dbf'
    size 16400K reuse autoextend on next 16400K
    undo tablespace undotbs
    datafile 'd:\oradb\testdb\datafiles\testdbrbs1.dbf'
    size 100M reuse autoextend on next 10M maxsize unlimited;
    Questions:
    1- Despite the fact that the temporary tablespace datafile is specified "autoextend on", it autoextends up to 4 Gb then it fails. The exact error is ORA-0652: unable to extend temp segment by 64 in tablespace TEMPORARY. If I manually extend it beyond 4 Gb, everything works fine. Is this a bug or is it something I do wrong ? If so, what should I do to correct this ?
    2- I can't figure out what statement of my application makes the temporary tablespace grow so big. I looked at all the trace files in UDUMP and I noticed it's always the same statement that is logged when the "autoextend" error occurs. But when I run the statement on its own in SQLPlus, nothing special happens to the temporary tablespace. What is the best way to track what statement uses what resources of the temporary tablespace ?
    3- I don't know if this is what happens, but it looks like space isn't reused in the temporary tablespace. Is this possible ? If so, how can I tell Oracle to reuse it ?
    Thanks.

    1-You can try to modify the maxsize for datafaile to UNLIMITED. I am not sure it shall work, but it's worth a try
    2-Probably it's a statement that uses an order by on a large result set
    3-You can try to force the wakeup of SMON process that would free the unused extents of temporary tablespace.
    Try http://www.ixora.com.au/tips/admin/stray_temp.htm
    There is also a script to force the wakeup of smon

  • TEMPORARY TABLESPACE에서, TEMPFILE을 사용할지, DATAFILE을 사용 할지 결정에 필요한 지침

    제품 : ORACLE SERVER
    작성날짜 : 2003-02-24
    TEMPORARY TABLESPACE에서, 임시 파일을 사용할지, 데이터파일을 사용 할지 결정에 필요한 지침
    ===========================================================================================
    PURPOSE
    이 문서는, TEMPORARY TABLESPACE에서 임시 파일과 데이터파일의 차이점을
    소개하는 데 목적이 있다.
    Explanation
    | TEMPORARY | Tablespace |
    | tablespace | TEMPORARY |
    | Locally | Dictionary |
    | managed | managed |
    | Datafiles | impossible | Y |
    | Tempfiles | Y | impossible |
    ------------------------------------------+
    다른 조합은 허용되지 않는다.
    1. TEMPORARY Tablespace / Tablespace TEMPORARY 와 PERMANENT tablespace 비교
    1) Tablespace TEMPORARY는 오라클 7.3 이상 버젼에서 사용가능하다.
    => Tablespace TEMPORARY는 다음과 같은 명령을 사용하여 생성한다.
    CREATE TABLESPACE .. TEMPORARY
    이 경우 데이터파일만을 사용한다.
    2) TEMPORARY tablespac는 오라클 8i 이상 버젼에서 사용 가능하다
    => TEMPORARY tablespace는 다음과 같은 명령을 사용하여 생성한다
    CREATE TEMPORARY TABLESPACE .. TEMPFILE
    이 경우 tempfile만 사용할 수 있다.
    3) Tablespace TEMPORARY/TEMPORARY tablespace는 DBA_TABLESPACES의
    CONTENTS 값이 TEMPORARY로 나타난다.
    4) Tablespace TEMPORARY/TEMPORARY tablespace 는 PERMANENT
    tablespace와 다르며 (DBA_TABLESPACES.CONTENTS 값이 PERMANENT임)
    permanent segment를 생성 할 수 없다. 예를 들어, permanent table이나
    index, cluster, rollback segment등을 Tablespace TEMPORARY/TEMPORARY
    tablespace에 생성할 수 없다.
    5) Tablespace TEMPORARY/TEMPORARY tablespace 에서는, 단일한
    temporary segment를 제공하며, 이 세그먼트는 다음과 같은
    요구사항을 가진 모든 사용자에 의해 공유된다.
    => sort 작업에 따른 sort extents를 필요로 하는 사용자
    => GLOBAL TEMPORARY TABLE에 필요한 temporary extents
    이와 같은 고유한 temporary segment는 동시에 많은 양의 sort 작업이
    수행되거나, 여러 트랜잭션이 동일한 temporary table을 사용할 때,
    permanent tablespace에서 작업하는 overhead를 피하고, 오라클의
    공간 관리 작업의 부하를 피하는데 도움을 준다.
    6) Temporary segment는 인스턴스 구동후 사용자가 sort extent나
    sort run, 또는 global temporary table 생성등의 요청에 따라
    자동적으로 생성된다.
    7) Temporary segment는 인스턴스 shutdown시 자동적으로 drop 된다.
    8) Temporary Content를 저장하는 테이블스페이스에 대한
    세그먼트의 공간 할당/할당 해제 관련 정보는 V$SORT_SEGMENT와
    V$SORT_USAGE 뷰를 사용하여 확인해 볼 수 있으며, sort segment
    등에 현재 sort를 진행하는 사용 정보를 보여준다.
    9) 위와 같은 작업을 수행하는데 PERMANENT tablespace 보다는
    tablespace TEMPORARY를 사용하는 것이 유리한 점은 <Bulletin No:
    11938>에 자세히 기술되어 있따.
    10) 오라클 8i에서는, 사용자별 default temporary tablespace가 어떤
    종류라도 상관이 없으나, PERMANENT locally managed 방식의 테이블
    스페이스는 지정할 수 없다. 다음은 PERMANENT locally managed 방식의
    테이블스페이스를 default temporary tablespace로 지정하여 발생하는
    에러이다.
    SQL> alter user x temporary tablespace PERM_LOCAL;
    User altered.
    SQL> select * from dba_tables order by 3,2,6,4,7,9,1,5;
    select * from dba_tables order by 3,2,6,4,7,9,1,5
    ERROR at line 1:
    ORA-03212: Temporary Segment cannot be created in locally-managed tablespace
    오라클 9i에서는 사용자별 default temporary tablespace가
    어떤 TEMPORARY 타입이라도 무방하다.
    => TEMPORARY tablespace locally managed
    => tablespace TEMPORARY dictionary managed
    PERMANENT locally-managed 타입의 테이블스페이스를 사용자의
    TEMPORARY tablespace으로 지정할 때 다음과 같은 에러가 발생한다.
    SQL> alter user x temporary tablespace PERM_LOCAL;
    alter user x temporary tablespace PERM_LOCAL
    ERROR at line 1:
    ORA-12911: permanent tablespace cannot be temporary tablespace
    2. TEMPORARY Tablespace/Tempfiles 대비 Tablespace TEMPORARY/Datafile
    1) 공간관리
    공간 관리는, locally managed tablespace에서 훨씬 단순하고, 또
    효율적이기 때문에, TEMPORARY tablespace를 사용하는 것이
    바람직하다. Local managedment 방식에서 사용 가능한 유일한
    방식이 temporary tablespace 방식이다.
    SQL> create tablespace temp1
    2 DATAFILE '/ora/ora817/32/oradata/V817/temp1.dbf' size 100M
    3 TEMPORARY
    4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;
    create tablespace temp1
    ERROR at line 1:
    ORA-25144: invalid option for CREATE TABLESPACE with TEMPORARY contents
    Dictionary-managed tablespace 대비 locally-managed tableapce의 장점은
    <Bulletin No: 18261>에 자세히 기술되어 있다.
    오라클 8i에서는, sort segment가 locally managed permanent tablespace에
    생성될 수 없으므로, locally managed TEMPORARY tablespace를 사용하여야
    한다.
    Locally managed temporary tablespace는 tempfile을 사용하며, temporary
    tablespace 바깥 데이터에 전혀 영향을 주지 않으면서, temporary tablespace
    관련 데이터에 대한 redo정보가 생성되지 않는다.
    이 테이블스페이스는, standby database나 read-only database에서도
    사용 가능하다.
    2) View
    TEMPORARY tablespace 와 연관된 파일 목록은 V$TEMPFILE 과
    DBA_TEMP_FILES 뷰를 통해 확인할 수 있다.
    SQL> select * from dba_tablespaces;
    TABLESPACE_NAME CONTENTS EXTENT_MAN
    TEMP_TEMPFILE_LOCAL TEMPORARY LOCAL
    TEMP_DATAFILE_DICT TEMPORARY DICTIONARY
    SQL> select STATUS, ENABLED, NAME from v$tempfile;
    STATUS ENABLED NAME
    ONLINE READ WRITE /tcase/oradata/V901/temp_temp01.dbf
    SQL> select FILE_NAME, TABLESPACE_NAME from dba_temp_files;
    FILE_NAME TABLESPACE_NAME
    /tcase/oradata/V901/temp_temp01.dbf TEMP_TEMPFILE_LOCAL
    위 내용은 tablespace TEMPORARY 환경에서 V$DATAFILE 와
    DBA_DATA_FILES를 사용하는 것에 비길 수 있다.
    SQL> select STATUS, ENABLED, NAME from v$datafile;
    STATUS ENABLED NAME
    ONLINE READ WRITE /tcase/oradata/V901/temp_data01.dbf
    SQL> select FILE_NAME, TABLESPACE_NAME from dba_data_files;
    FILE_NAME TABLESPACE_NAME
    /tcase/oradata/V901/temp_data01.dbf TEMP_DATAFILE_DICT
    3) 권한
    Temporary tablespace 또는 tablespace temporary 생성을 위해서는
    CREATE TABLESPACE system privilege가 필요하다.
    4) TEMPORARY Tablespace 생성
    SQL> create TEMPORARY tablespace temp_tempfile_local
    2 TEMPFILE '/ora/V817/temp_temp.dbf' size 100M
    3 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;
    참고: 일부 OS에서는 tempfile block이 실제 액세스 되기
    전 까지 tempfile이 실제로 생성되지 않는다. 이와 같은
    파일 생성 작업이 지체되어 처리 되는 것은, tempfile의
    생성과 크기 조정이 신속하게 처리되는데 도움이 된다.
    그러나, tempfile이 나중에 생성되더라도, 생성 가능한
    충분한 디스크 공간이 있어야 하겠다.
    사용중인 O/S에서 tempfile이 실제 생성되는 시점은
    플랫폼별 매뉴얼에 기술되어 있다.
    Tablespace TEMPORARY의 생성
    SQL> create tablespace TEMP_DATAFILE_DICT
    2 datafile '/tcase/oradata/V901/temp_data.dbf' size 100M
    3 TEMPORARY;
    Tablespace created.
    5) Tempfile/Datafile 제거
    a. 테이블스페이스를 drop 하기 전까지 테이블스페이스의 datafile을
    제거할 수 없다.
    참고: 오라클 9i에서 DROP TABLESPACE 명령에 추가된
    INCLUDING CONTENTS AND DATAFILES 절을 사용하면, OS로 부터
    관련 데이터파일도 삭제하는 작업을 자동화 할 수 있다.
    b. Temporary tablespace로 부터 tempfile을 삭제하고, 논리 구조를
    비어 있는 상태로 유지할 수 있다.
    => 오라클 8i:
    SQL> alter tablespace TEMP_TEMPFILE_LOCAL
    2 add tempfile '/oradata/V817/temp_temp01.dbf';
    Tablespace altered.
    SQL> alter database tempfile '/oradata/V817/temp_temp01.dbf'
    2 drop;
    Database altered.
    SQL> !ls /oradata/V817/temp_temp01.dbf
    /oradata/V817/temp_temp01.dbf
    위 명령을 수행 한 후, tempfile을 시스템으로 부터 삭제하고,
    나중에 다시 추가 시킬 수 있다.
    SQL> alter tablespace TEMP_TEMPFILE_LOCAL
    2 add tempfile '/oradata/V817/temp_temp01.dbf';
    Tablespace altered.
    => 오라클 9i: OS 파일을 삭제 하기 위해 INCLUDING DATAFILES
    절을 사용할 수 있다.
    SQL> alter database tempfile '/oradata/V901/temp_temp01.dbf'
    2 drop including datafiles;
    Database altered.
    SQL> !ls /oradata/V901/temp_temp01.dbf
    /oradata/V901/temp_temp01.dbf not found
    Temporary tablespace로 부터 모든 tempfile을 삭제하면,
    다음과 같은 에러가 발생할 수 있다.
    SQL> alter table olap.test add primary key (c);
    alter table olap.test add primary key (c)
    ERROR at line 1:
    ORA-25153: Temporary Tablespace is Empty
    ORA-25153
    25153, 00000, "Temporary Tablespace is Empty"
    // *Cause: An attempt was made to use space in a temporary tablespace with
    // no files.
    // *Action: Add files to the tablespace using ADD TEMPFILE command.
    이 에러 메시지는 동시 작업 수행시 디스크를 실제 액세스 하여야
    할 경우 발생하게 된다.
    Example
    Reference Documents
    <Note:132663.1> ORA-03296 Resizing Temporary Locally Managed Tablespace
    <Note:131769.1> ORA-03212 at Instance Startup
    <Note:102339.1> Temporary Segments: What Happens When a Sort Occurs
    <Note:160426.1> TEMPORARY Tablespaces : Tempfiles or Datafiles

  • How do we know when datafile was added to a tablespace

    HI experts,
    I wanted to know how do we know when datafile was added to a tablespace.
    Actually i need to monitor how much space was used for a month for a tablespace
    thanks in advance

    Which could be turned into an external table and queried at will:
    Demo of the alert log as a table at:
    http://www.psoug.org/reference/externaltab.html
    Just a quick note with respect to background_dump_dest for anyone starting into 11g. It is deprecated and BDUMP and UDUMP no longer exist: Read the docs.

  • 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 ?

  • FIXED     ORA-02180 when Creating a Temporary Tablespace

    I am using Oracle 9i on a Win 2003 machine.
    I have just performed a recovery of all my datafiles and have successfully opened the database using ALTER DATABASE OPEN;
    I have been using THIS as a guide and am now at the stage of creating a new temp tablespace and dropping the old one (step 8.).
    I use the following SQL,
    CREATE TEMPORARY TABLESPACE temp02 TEMPFILE 'c:\oracle\oradata\bcs\temp02.dbf' SIZE 100mb AUTOEXTEND OFF EXTENT MANAGEMENT LOCAL;
    However it returns the following error:
    ERROR at line 1:
    ORA-02180: invalid option for CREATE TABLESPACE
    Having googled the error it just says to make sure I am specifying a vaild option such as a datafile. I thought that is what I am doing!?
    Could anyone please point out where I am going wrong and suggest a solution. It would be greatly appreciated.
    Regards
    Toby
    Message was edited by:
    redeye

    Hi,
    CREATE TEMPORARY TABLESPACE temp02 >TEMPFILE 'c:\oracle\oradata\bcs\temp02.dbf' SIZE 100mb AUTOEXTEND OFF
    EXTENT MANAGEMENT LOCAL;i think above creating temporary tablespace syntax may be wrong
    why r u using AUTOEXTEND OFF?
    plz try the following syntax
    CREATE TEMPORARY TABLESPACE temp02 TEMPFILE 'c:\oracle\oradata\bcs\temp02.dbf' SIZE 100mb
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10m;
    Regards ...

  • Bigfile Temporary Tablespace?

    Hi,
    --------------------------Oracle 11G Release 11.1.0.6.0, Windows XP 32------------------------------------
    I've tried to find out but not successful. Can I create BIGFILE TEMPORARY TABLESPACE like I've created normal BIGFILE TABLESPACE.
    Secondly, If it is not possible then will creating multiple temporary files will effect performance will doing the sorting?
    ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
    select inst_id, tablespace_name, total_blocks, used_blocks, free_blocks
          from gv$sort_segment;
       INST_ID TABLESPACE_NAME                 TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
             1 TEMP                                12582144           0    12582144
    I've created 3 temp files of 30G each and get above error i.e unable to extend. adding a temp file will solve this issue, but I was thinking to create one bigfiel temporary file instead of adding files, that might decrease lot of performance.
    Thanks
    Regards

    kam555 wrote:
    Hi,
    --------------------------Oracle 11G Release 11.1.0.6.0, Windows XP 32------------------------------------
    I've tried to find out but not successful. Can I create BIGFILE TEMPORARY TABLESPACE like I've created normal BIGFILE TABLESPACE.
    Secondly, If it is not possible then will creating multiple temporary files will effect performance will doing the sorting?
    ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
    select inst_id, tablespace_name, total_blocks, used_blocks, free_blocks
    from gv$sort_segment;
    INST_ID TABLESPACE_NAME                 TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
    1 TEMP                                12582144           0    12582144I've created 3 temp files of 30G each and get above error i.e unable to extend. adding a temp file will solve this issue, but I was thinking to create one bigfiel temporary file instead of adding files, that might decrease lot of performance.
    Thanks
    RegardsBigfile tablespaces are supported only for locally managed tablespaces with automatic segment space management, with three exceptions: locally managed undo tablespaces, temporary tablespaces, and the SYSTEM tablespace.
    There is no performance overhead if you have multiple datafiles in a tablespace. That is structure of Oracle: Tablespace may consist of multiple datafiles.

  • ORA-03217: invalid option for alter of TEMPORARY TABLESPACE

    Hi all
    I have a database with 300 Users approximantely.
    Suddenly I was reported about slowly connection and looked to my database. And I saw that Temporary tablespace with name MUVTEMP is 0% used and in it there is no .dbf file
    Then I do ls on my data files directory and saw there MUVTEMP01.dbf!
    But it's not using it. Then I want to add another .dbf file. It created this file physically but not joined it to my temporary tablespace.
    Then I did it with Oracle EM, clicked on "Show SQL" and there was written
    ALTER TABLESPACE "MUVTEMP"
    ADD
    DATAFILE '/home/oracle/OraHome1/oradata/linux/test.dbf' SIZE
    5M
    I run it from EM it gave this error
    ORA-03217: invalid option for alter of TEMPORARY TABLESPACE
    Then I run this SQL in sqlplus
    ALTER TABLESPACE "MUVTEMP"
    ADD
    TEMPFILE '/home/oracle/OraHome1/oradata/linux/test.dbf' SIZE
    5M
    it created file physically, but I can't see this file as temporary tablespace's file. It's not using....
    Where is my mistake???
    Thanks...

    Hi,
    try this query:
    select s.sid || ',' || s.serial# sid, s.username, u.tablespace, substr(a.sql_text, 1, (instr(a.sql_text, ' ')-1)) sql_text,
      round(((u.blocks*p.value)/1024/1024),2) size_mb
    from v$sort_usage u, v$session s, v$sqlarea a, v$parameter p
    where s.saddr = u.session_addr
      and a.address (+) = s.sql_address
      and a.hash_value (+) = s.sql_hash_value
      and p.name = 'db_block_size'
    group by s.sid || ',' || s.serial#, s.username, substr(a.sql_text, 1, (instr(a.sql_text, ' ')-1)), u.tablespace, round(((u.blocks*p.value)/1024/1024),2);

  • Temporary tablespace not cleared

    Hi,
    I have a temporary tablespace in one of my Oracle 9i databases that does not ever get cleared of data. I have altered the tablespace to autoextend by a few megabytes each time but I was wondering why a temp tablespace remains full even after all sessions are done. Its grown larger than my datafiles and I need a solution. Any ideas?
    Thanks in advance.
    James.

    Hi James,
    You need to alter your temporary tablespace with adding a fresh new (small) tempfile, and when done, you need to put your other 'old' tempfiles offline so that you can delete them afterwards.
    Your temporary tablespace will not shrink/release the space even when you bounce your DB (the undo tbs will)
    Regards,
    Thierry

  • Temporary Tablespace not shrinking automatically after restarting the DB.

    I had a Database with 2GB tempfile. It gave me an error that it's unable to extend the temporary segment. I added a new tempfile of 500MB. Within a few min the new file was filled. In process of shrinking the temporary files, I shutdown the DB, and restarted it. But the Tempfiles were still filled to the max. I still don't understand why? Then I attached a new tempfile of 1GB to the Temp Tablespace, but it didn't use the new tempfile. I repeated the restart process again but still the output was same.
    1. Both datafiles were filled to the max
    2. It didn't use the new (3rd) attached tempfile.
    Finally I've created a new tablespace with new Tempfiles, and it's working now. But I'm still confused. Please suggest me with the possibilities. How can i shrink the Temporary Tablespace/Tempfiles.
    Thanks & Regards
    Vikas Verma
    Manager (IT) / Sr. DBA
    Hero Cycle Group,
    India

    It all depends from what you understand by shrinking:
    If you would like to shrink tempfile for tablespace I would suggest using following procedure:
    Find out to which size you can shrink tempfile
    select extent_size,current_users,total_extents,used_extents,free_extents
    from v$sort_segment
    where tablespace_name='TEMP';
    alter database tempfile 'XXXX' resize YYM;
    YY is the size which can be found by above query.
    But Ithink you are more interested in following procedure:
    create new
    make this new one the default temporary tablespace for the database
    drop old
    ps. Yoogesh ask you about DB version
    you can find bd version by:
    select *
    from v$version
    select *
    from product_component_version
    Best Regards
    Krystian Zieja / mob

  • Undo Tablespace and Temporary Tablespace - autoextend ?

    - In general, should I allow the Undo Tablespace to grow (autoextend)?
    - In general, should I allow the Temporary Tablespace to grow (autoextend)?

    The size of undo tablespace should always keeps in mind otherwiase you eill get ORA-1555 or out of space errors.
    This paper is to help DBA’s in calculating the size of UNDO tablespace by using a simple formula.
    It is tough to know about the number of transactions and subsequently number of rows changed per second.
    So I suggest having a “big undo tablespace” to start with and based on load, after doing some calculations and resize your UNDO tablespace.
    In my case one of the applications was going to production (live), and I had no idea that how many transactions will happen against this database. All what I was told that there will be optimum (transactional) activity on this database.
    So I started with UNDO tablespace with size of 3GB and datafiles with autoextend “on” .
    Note:
    In production, you must be very careful in using this (autoextend on) as the space may grow to inifinity very fast. So my advice is either dont use this option, or use with "maxsize" or continuously monitor space (which is tough).
    I month later, I noticed the activity from V$undostat.
    Here is the step by step approach:
    Step 1: Longest running query.
    SQL> select max(maxquerylen) from v$undostat;
    MAX(MAXQUERYLEN)
    1793
    This gives you ideal value for UNDO_RETENTION. To be on the safer size you should add few more seconds to get the right value. So in my case, the size of undo retention should be say 2000 secs.
    Step 2: Size of UNDO tablespace.
    Size of UNDO needed = UNDO_RETENTION x [UNDO block Generation per sec x DB_BLOCK_SIZE] + Overhead(30xDB_BLOCK_SIZE)
    Out of these we know UNDO_RETENTION and DB_BLOCK_SIZE
    All we need is to find out “UNDO Blocks per second”
    Which can be easily fetched from v$undostat
    SQL> SELECT (SUM(undoblks))/ SUM ((end_time - begin_time) * 24*60*60) "UPS"
    2 FROM v$undostat;
    UPS
    8.11985583
    V$undostat stores data for every 10 mins and begin/end times are start/end time of those intervals. We multiplied it with 24*60*60 because the difference between two dates will be in days and to get to seconds, we need it to multiply with 24hrs*60mins*60secs
    So now we have all the values needed.
    Undo size needed = [8.12 x 2000 x 8192] + [30 x 8192] = 133283840 bytes = 127.11 MB

  • Although my temporary tablespace is enough space,the error occurs ORA-01652

    Hello,
    Although my temporary tablespace is enough space ,i am taking an error ORA-01652 and some dbfs in the tablespace are looks like as offline and it’s size looks like as 0 byte.
    So that i am changing status of these datafiles to online with this command as follows;
    ALTER DATABASE TEMPFILE '/QDBP/q023/q023/temp/qt_lm_tmp01.dbf' ONLINE;
    Also, The disk that exist these datafiles was 0 in availibility.
    When i issued the command df –k as follows
    Filesystem kbytes used avail capacity Mounted on
    /dev/vx/dsk/qdbpdg/volq23 20971520 20971520 0 100% /QDBP/q023
    is pointed.
    And then i have released space from disk
    The current review is
    /dev/vx/dsk/qdbpdg/volq14 157286400 21731141 127083885 15% /QDBP/q014
    My queries and results are for the hint of about the problem:
    SELECT A.tablespace_name TABLESPACE, D.mb_total,
    SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
    D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free
    FROM v$sort_segment A,
    SELECT B.NAME, C.block_size, SUM (C.bytes) / 1024 / 1024 mb_total
    FROM v$tablespace B, v$tempfile C
    WHERE B.ts#= C.ts#
    GROUP BY B.NAME, C.block_size
    ) D
    WHERE A.tablespace_name = D.NAME
    GROUP BY A.tablespace_name, D.mb_total;
    TABLESPACE |MB_TOTAL| MB_USED| MB_FREE
    QT_LM_TMP |61440 |12| 61428 --temporary
    TS_TEMP_SDPA |15360 |0| 15360 –temporary
    Separately,i want to see you a view about alert log like points below.
    KCF: write/open error block=0x1b6e0a online=1
    file=3 /QDBP/q014/q014/temp/qt_lm_tmp03.dbf
    error=27063 txt: 'SVR4 Error: 28: No space left on device
    Additional information: -1
    Additional information: 8192'
    Automatic tempfile offline due to write error on
    file 3: /QDBP/q014/q014/temp/qt_lm_tmp03.dbf
    With sum,i have some question like below:
    1)Although there is enough space on temporary tablespace why i take error ORA-01652?
    2)Although there is enough space on temporary tablespace why databasefiles have offline status suddenly?
    3) is it important fully rate of disk on operating system if there is enough space on temporary tablespace which has extend properties.
    Best regards
    Oya YALÇIN

    Hi,
    i don't make tablespaces offline mode.But neverthless i don't understant although there is enough space on tablespace why tablespaces are being offline status mode itself?
    When i look at ‘ select file_name,status from dba_temp_files ‘ query on the database now.The result is like below;
    FILE_NAME|STATUS
    /QDBP/q023/q023/temp/qt_lm_tmp01.dbf|AVAILABLE
    /QDBP/q023/q023/temp/qt_lm_tmp02.dbf|AVAILABLE
    /QDBP/q014/q014/temp/qt_lm_tmp03.dbf|AVAILABLE
    /QDBP/q023/q023/temp/ts_temp_sdpa01.dbf|AVAILABLE
    /QDBP/q023/q023/temp/ts_temp_sdpa02.dbf|AVAILABLE
    /QDBP/q014/q014/temp/qt_lm_tmp04.dbf|AVAILABLE
    /QDBP/q014/q014/temp/qt_lm_tmp05.dbf|AVAILABLE
    But when i look at first 3 dbf by orderly from tab of scripts about tablespaces on toad tool
    i see that like below;
    ALTER DATABASE TEMPFILE '/QDBP/q023/q023/temp/qt_lm_tmp01.dbf' OFFLINE;
    ALTER DATABASE TEMPFILE '/QDBP/q023/q023/temp/qt_lm_tmp02.dbf' OFFLINE;
    ALTER DATABASE TEMPFILE '/QDBP/q014/q014/temp/qt_lm_tmp03.dbf' OFFLINE;
    And their size is look like 0 .
    Regards
    Oya.

  • RMAN duplicate target database for standby from active fails to create newname for system tablespace/datafile

    When executing 'duplicate target database for standby from active'  the system tablespace/datafile (datafile 1)  is not cloned.  All other datafiles clone successfully.  The RMAN process aborts with the following errors while attempting to clone the system tablespace/datafile.
    ORA-19558: error de-allocating device
    ORA-19557: device error, device type: DISK, device name:
    ORA-17627: ORA-01041: internal error. hostdef extension doesn't exist
    ORA-17627: ORA-01041: internal error. hostdef extension doesn't exist
    ORA-03135: connection lost contact
    Here are the details:
    Primary is 11.2.0.2 RAC database  on an Exadata platform
    Standby is 11.2.0.2 Single Instance database (same patch level as primary) on a Red Hat Linux box
    This is an ASM to ASM duplication.
    This is not unique to this database.  We tried another database and go the same behavior - all datafiles clone successfully with the exception of the system tablespace/datafile.
    We have traced the RMAN execution and it seems to fail when it is trying to assign a NEWNAME to the system tablespace/datafile.
    We even issued an explicit SET NEWNAME command but RMAN ignored it.
    We also shutdown the primary and started is up in mount mode thinking that something had ahold of the System Tablespace/datafile.
    We also opened up the network firewall to allow permit any,any traffic.
    We increased the max_server_processes
    and added TCP.NODELAY=yes to the sqlnet.ora file.
    There seems to be some artifact present in our Primary System tablespace/data file that is preventing it form being cloned.
    checked all alert files grid, asm,  and dbhome - no abnormal messages.
    We are in the process of restoring the database from a backup but we would prefer to get this working using the 'Active Database' methodology

    I successfully created the standby database using RMAN backup and recovery.
    I started the managed recovery.  Archive logs are being sent from the primary to the standby ( I can see them in ASM), but the standby is not applying them.
    I get the following messages in the standby alert log...
    Fetching gap sequence in thread 2, gap sequence 154158-154257
    Tue Nov 26 16:19:58 2013
    Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
    Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
    Tue Nov 26 16:20:01 2013
    Fetching gap sequence in thread 2, gap sequence 154158-154257
    Tue Nov 26 16:20:11 2013
    Fetching gap sequence in thread 2, gap sequence 154158-154257
    Tue Nov 26 16:20:22 2013
    Fetching gap sequence in thread 2, gap sequence 154158-154257
    Tue Nov 26 16:20:32 2013
    Fetching gap sequence in thread 2, gap sequence 154158-154257
    I don't see any MRP processes:
    select process,
    status,
        thread#,
        sequence#,
       block#,
      blocks
      7     from v$managed_standby;
    PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
    ARCH      CLOSING               2     154363          1        132
    ARCH      CONNECTED             0          0          0          0
    ARCH      CONNECTED             0          0          0          0
    ARCH      CONNECTED             0          0          0          0
    ARCH      CONNECTED             0          0          0          0
    ARCH      CONNECTED             0          0          0          0
    ARCH      CONNECTED             0          0          0          0
    ARCH      CONNECTED             0          0          0          0
    RFS       IDLE                  0          0          0          0
    RFS       IDLE                  1     145418        121          1
    RFS       IDLE                  0          0          0          0
    PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
    RFS       IDLE                  0          0          0          0
    12 rows selected.
    SQL>  SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;
       THREAD#  SEQUENCE# APPLIED
             2     154356 NO
             2     154357 NO
             1     145411 NO
             2     154358 NO
             2     154360 NO
             2     154361 NO
             1     145414 NO
             1     145415 NO
             2     154362 NO
             2     154363 NO
             1     145416 NO
    11 rows selected.
    I do have the archive logs that cover sequences 154158-154257
    Crosschecked 38 objects
    Crosschecked 62 objects
    Finished implicit crosscheck backup at 26-NOV-13
    Starting implicit crosscheck copy at 26-NOV-13
    using channel ORA_DISK_1
    using channel ORA_DISK_2
    Crosschecked 2 objects
    archived log file name=+RECO_XORA/nmuasb00/archivelog/2013_11_26/thread_2_seq_154377.344.832521989 RECID=29 STAMP=832521990
    validation succeeded for archived log
    archived log file name=+RECO_XORA/nmuasb00/archivelog/2013_11_26/thread_2_seq_154378.346.832521991 RECID=31 STAMP=832521993
    Crosschecked 31 objects

Maybe you are looking for