Tablespace with datafiles on many disks

Hello,
I am using Oracle 11g R2 on AIX 7.1
I am planing to create a tablespace where it is datafiles on 4 disks.
How can I specify a datafile to be on a disk while creating the tablespace?
Regards,

NB wrote:
thanks for the info.
No i have no control on the disks.
I am doing that for better performance so I will put each datafile of a tablespace on a disk, and I/O will decrease.
How can I achieve that ?
again if the 4 disks are mounted on a single mount point /u01
Edited by: NB on Mar 17, 2012 11:08 AMRead this.
Consider the Performance Impact_
The number of datafiles contained in a tablespace, and ultimately the database, can have an impact upon performance.
Oracle Database allows more datafiles in the database than the operating system defined limit. The database DBWn processes can open all online datafiles. Oracle Database is capable of treating open file descriptors as a cache, automatically closing files when the number of open file descriptors reaches the operating system-defined limit. This can have a negative performance impact. When possible, adjust the operating system limit on open file descriptors so that it is larger than the number of online datafiles in the database.
Place Datafiles Appropriately_
Tablespace location is determined by the physical location of the datafiles that constitute that tablespace. Use the hardware resources of your computer appropriately.
For example, if several disk drives are available to store the database, consider placing potentially contending datafiles on separate disks.This way, when users query information, both disk drives can work simultaneously, retrieving data at the same time.
Source:-
http://docs.oracle.com/cd/B28359_01/server.111/b28310/dfiles001.htm

Similar Messages

Tablespaces with Multiple Datafiles

I've got a Version 7.3.3.4 tablespace with multiple datafiles. There's a lot of object fragmentation. I want to be able to
drop and recreate many (but not all) of the objects in this tablespace but exercise some control on which objects go to
which datafiles in order to better utilize the available space on each datafile. I've been told that Oracle assigns objects
to datafiles in a "round robin" fashion. I'd like info on exactly how this process works and if I can have a more direct effect
on where objects are placed within the tablespace?
Thanks,
Paul Hargreaves
[email protected]

Hi,
I am interested by having more information about tablespaces and how they are fragmented.
I could, perhaps help you first by telling you that there is a ALTER command for coelescing space in ORACLE 7.3.4 :
ALTER TABLESPACE tablespace COALESCE ;
Of course you should have the permissions (ALTER TABLESPACE)
This command is for the entirely tablespace ...
In fact, i need a query that gives me for each tablespaces, how are they fragmented (with segment_name ..).
Thanx
Steff

Can I fix a disk with this message?-Disk Utility can't repair this disk. Back up as many of your files as possible, reformat the disk, and restore your backed-up files.

Can I fix a disk with this message?
Disk Utility can’t repair this disk. Back up as many of your files as possible, reformat the disk, and restore your backed-up files.

Some problems can indeed be fixed this way. But working from Recovery_HD or Disk Warrior DVDs and working in the restricted environment those provide can be difficult. You can literally spend days working on this problem (while your regular work is unavailable) only to discover the old drive is unsalvageable.
There is no way to know up front whether you are facing a major Hardware failure or a minor software glitch, or something in between. Often you are forced to work from the drive you no longer trust. I continue to recommend you do this work from a different, fully functioning Mac OS X booted from a different drive.
If you have had the foresight to (as The hatter often recommends) clone your virgin install onto another drive for use in such situations, you will be able to recover from such problems in record time. If not, my previous recommendations stands:
Buy a new Drive. Or two. Install Mac OS X from scratch on a new drive, and get your Mac running again. Later, you can use the full power of Mac OS X to attempt to rescue your data, if needed. Then Zero the old drive, to see if it can hold data again reliably.
If the old drive eventually provides some needed data, and is salvageable, Merry Christmas.

Tablespace with too many extents are evil for performance

I think the tablespace with too many extents are not bad for performance after introduction of LMT tablespace?? May be true with DMT tablespace(earlier versions). This is just observation after reading the LMT vs DMT tablespaces.
Experts - Please comment on your thoughts.

Indeed, I work in an environment where there is over 50 databases to be administered and so we have lots of DBAs interacting with each other.
I'm stunned by this myth of "reorganization". Most of the DBAs move tables + rebuild indexes regularly generating huge redo on a monthly basis. Also provoking indexes to do all the splits again generating even more redo. They claim "it helps performance a lot" however not one is able to quantify and quite justify it other than "less extents less I/O, good". Even when I bring up the existence of shrink they say "do not like it, prefer the classic move". People really have a way of holding on to their good ol' practices of Oracle 8i.
For full table scans (which should never be done on a OLTP scenario) this extent issue would be relevant IF data on the table is the victim of large deles and Oracle hasn't re-used that space yet. If your multiblock reads is a multiple of your extent size, than there won't be any overhead of I/O call, no matter the number of your extents. For OLTP this is not relevant because Oracle will access the table via ROWID.
I rarely have ever seen an index benefit from a rebuild significantly. In my experience what people often understand as "index fragmentation" is often just an unoptimized execution plan due to cardinality issues where oracle ends up fetching a large percentage of the table via single reads on that index.

10.20.3.0. -- Tablespace creation with datafile of 100GB -- ORA-03206:

Hi All,
Why I get this error and hot fix it? I'm just creating only 100GB datafile!!
Please help..
SQL> CREATE TABLESPACE <<NAME>> datafile '<<NAME WIHT PATH>>>
2 SIZE 1000m AUTOEXTEND ON NEXT 1000m MAXSIZE 100000m
3 SEGMENT SPACE MANAGEMENT AUTO;
CREATE TABLESPACE jmdprd_data datafile ' <<<NAME WITH PATH>>/'
ERROR at line 1:
ORA-03206: maximum file size of (12800000) blocks in AUTOEXTEND clause is out
of range
SQL>
SQL> spool off
not spooling currently
Thanks a lot
Natrajan

Hi All,
Why I get this error and hot fix it? I'm just
creating only 100GB datafile!!
Please help..Just 100gb datafile?
Are you in Datawarehousing env?Its incredibly diffucult to maintaint the Datafiles with high capacity
SQL> CREATE TABLESPACE <<NAME>> datafile '<<NAME WIHT
PATH>>>
2 SIZE 1000m AUTOEXTEND ON NEXT 1000m MAXSIZE
100000m
3 SEGMENT SPACE MANAGEMENT AUTO;
REATE TABLESPACE jmdprd_data datafile ' <<<NAME WITH
PATH>>/'
ERROR at line 1:
ORA-03206: maximum file size of (12800000) blocks in
AUTOEXTEND clause is out
of rangeWhats the OS.
Whats the maximum files size limit of the OS?

HOW TO MOVE DATAFILES FROM ONE DISK RAID TO ANOTHER:PLZ HELP ME :=)

Hi all,
For Tunning reasons : perform The I/O from the Instance to datafiles (database). I decide to move some Index datafiles from One DISK RAID to another.
I'm on Linux Redhat Server and Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
My database 's On PRODUCTION and there 're many web applications updating some databases tables and for sure using Index tablespace. I preapared yet my procedure to move datafiles but I'm posting this to be sure that I will not have BAD EFFECTS on my Oracle database.
So I plan without SHUTDOWN MY DATABASE to these steps :
/*Step1 : */
ALTER TABLESPACE INDX OFFLINE ;
/*Step 2 : move datafiles to new disk raid*/
mv /u01/oraindx/DB01/indx01_05.dbf /u01/oraindx2/DB01/indx01_05.dbf
mv /u01/oraindx/DB01/indx01_06.dbf /u01/oraindx2/DB01/indx01_06.dbf
mv /u01/oraindx/DB01/indx01_07.dbf /u01/oraindx2/DB01/indx01_07.dbf
/*Step 3 : */
ALTER TABLESPACE INDX RENAME DATAFILE '/u01/oraindx/DB01/indx01_05.dbf' TO '/u01/oraindx2/DB01/indx01_05.dbf';
ALTER TABLESPACE INDX RENAME DATAFILE '/u01/oraindx/DB01/indx01_06.dbf' TO '/u01/oraindx2/DB01/indx01_06.dbf';
ALTER TABLESPACE INDX RENAME DATAFILE '/u01/oraindx/DB01/indx01_07.dbf' TO '/u01/oraindx2/DB01/indx01_07.dbf';
/*Step 4 : */
ALTER TABLESPACE INDX ONLINE ;
Please verify my procedure and tell me the precautions that I should take care :=)
regards,

Werner,
If this is an active databases (indexes are used),
you cannot set offline the index tablespace.you can offline it.
DAB user:
SQL>create tablespace inds datafile '/oracle/newdb/mydb/inds01.dbf' size 10m;
Tablespace created.
Scott user:
SQL>create table t2 (col1 date, id number) tablespace users;
Table created.
SQL>create index t2_ind on t2(id) tablespace inds;
Index created.
SQL>insert into t2 values (sysdate,1);
1 row created.
SQL>insert into t2 values (sysdate,2);
1 row created.
SQL>insert into t2 values (sysdate,10);
1 row created.
DBA user:
SQL>select segment_name,segment_type,tablespace_name
2 from dba_segments
3 where owner='SCOTT' and segment_name like 'T2%';
SEGMENT_NAME                   SEGMENT_TYPE       TABLESPACE_NAME
T2                             TABLE              USERS
T2_IND                         INDEX              INDS
SQL>alter tablespace inds offline;
Tablespace altered.
SQL>!mv /oracle/newdb/mydb/inds01.dbf /oracle/newdb/mydb/inds0001.dbf
SQL>alter tablespace inds rename datafile '/oracle/newdb/mydb/inds01.dbf' to
2 '/oracle/newdb/mydb/inds0001.dbf';
Tablespace altered.
SQL>alter tablespace inds online;
Tablespace altered.
scott user:
SQL>insert into t2 values (sysdate,20);
1 row created.
SQL>
SQL>select * from t2;
COL1              ID
22-NOV-07          1
22-NOV-07          2
22-NOV-07         10
22-NOV-07         20
SQL>commit;
Commit complete.

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 ?

Flex Time error: Too many disk I/) tasks (Elastic Audio)...

I've been using flex time to take a sample in straight time and make it swing, but I've been having playback issues. I get two different error windows 1) Extreme compress factor detected during playback (Elastic Audio) (-10025) and 2) Too many disk I/O tasks (Elastic Audio). Also, I occasionally get a loud static sound when playing the sample. I don't have this issue when in Flex mode if I only loop the sample twice, but if I try to loop it more than twice, I'll get the errors and/or the static sound. At no point do the stretches make the audio color red, so I don't think I'm over-stretching or over-compressing the audio Is there any way to solve this? Does flex time have limitations to the number of markers used?

Yeah, the I/O error is because you're basically pushing it too hard, it can't read what you're doing fast enough to process it. I got this the other day when I was trying to use flex within a take folder over multiple comped takes.
If you want to swing the audio, why don't you cut it into regions, send it to the EXS 24 and then quantise the samples with swing in the piano roll. That way you're not putting so much pressure on the processor.

Database Performance (Tablespaces and Datafiles)

Hi guys!
What's the best for performance in database, tablespace with various datafiles distribuited in diferents filesystems or tablespaces with various datafiles in only one filesystem?
Thanks,
Augusto

It depends on contents of the tablespaces, tablespace level LOGGING/NOLOGGING and env such as either OLTP or OLAP and LUN presentation to the server with RAID or without RAID and SAN Read per second and write per second.
In general, tablespace with various datafiles distribuited in diferents filesystems/LUN's is in practice for non dev/system test databases.
Moreover using ASM is better then standard filesystems.
Regards,
Kamalesh

Tablespace or datafile creation during recovery

Hello
During recovery,
If there is new tablespace or datafile added in archivelogs or redologs I have to manually issue:
alter database create datafile .. as ..
Why doesnt oracle automatically create the datafiles ?

The datafile doesn't exist in the control file. The control file maintains the physical structure of the database. During the RECOVERy phase, Oracle reads the ArchiveLogs to identify what updates are to be done -- these are mapped in terms of file, block and row. If the file doesn't exist in the controlfile, the rollforward cannot be applied.
Therefore, the ALTER DATABASE CREATE DATAFILE ... AS .... allows Oracle to "add' the file to the controlfile and then proceed with the rollforward.
Oracle doesn't automatically create the datafile because it can't know what the target file name is.
In your backup your datafiles may have been spread across /u01/oradata/MYDB, /u02/oradata/MYDB, /u03/oradata/MYDB and this file may have been in /u03/oradata/MYDB. However, in your target (restored) location the files may be at only two, differently named, mountpoints : /oradata1/REPDB, /oradata/REPDB. Oracle can't decide for you where the new datafile (which was in /u03/oradata/MYDB) should be created -- should it be in /oradata1/REPDB or /oradata/REPDB or, you might have avaialable /oradata3/REPDB which the database instance isn't aware of !

Use of backing up a single tablespace or datafile

Hello,
I am reading the RMAN manual and I'm quite familiar with backup up a tablespace or datafile, but I can find very few uses for that. Backup up a tablespace is useful for TPITR, but since that needs another instance its of very little use in most production environments. I think you cannot restore an old version of tablespace in a normal database, unless the tablespace has long been made read-only, in which case RMAN's optimizations will do the trick.
Even less use I can find for datafile backup. I have absolutely no idea what you can do with a single datafile.
Can you please clarify me on the uses of these RMAN features?
Thank you.

Dear Albi!
Think of the following scenario:
You have a very large (let's say 1 Terabyte) production database that is split into n tablespaces. This database is in archivelog mode and a full backup of the hole database would take more than 10 hours.
scenario end.
In such a scenario I think you will not take a full database backup very often. Therfore you can backup portions (tablespaces and datafiles) of your database. This will take less time then a hole DBbackup.
If you have to restore your DB then RMAN will take all the files it needs from all your backup. RMAN uses always the most actual version of your datafiles. After the restore RMAN will take the archivelogs to recover all datafiles to the most actual point in time. And that's the point why partial backups of your db are not only usefull for TSPITR.
I hope I could make clear what the operative point is with partial backups.
Yours sincerely
Florian W.

Too Many disk I/O tasks (-10022) error playing song after edits

I have been fighting Logic 9 throwing the "Too Many disk I/O tasks (Elastic Audio) (-10022)" error when playing back a song with 12 tracks of audio AFTER I cut across 8 tracks (of drums) and move regions around. The Disk I/O indicator never shows more than 1-2 bars, tops when this error is thrown. While writing this up and troubleshooting, the problem has seemed to sort itself out, but only after doing some peculiar steps.
*System is MacPro 2x2.26 Quad-Core, 8GB RAM, Mackie Onyx 1620 recording to 500GB WD MyBook Pro over FW800. I/O Buffer = 128.
1) Grouped the 8 tracks of drums (there are 3 takes on each track). Play back song. No problems.
2) Cut the drums at bars 73, 81, 105 and 109.
3) Drag-copied the regions from bars 105-109 to 73-81.
4) Playback song, error thrown at bar 70
5) Increase buffer size to 256.
6) Playback song, error thrown at bar 70
7) Increase buffer size to 512.
8) Playback song, error thrown at bar 70
- Thought this might be a disk problem.
9) I copied the project with all the files to the internal Seagate and open the project.
10) Playback song, error thrown at bar 70
- Thinking this is not a disk problem.
11) Open the project on the original WD external drive.
12) Mute all regions an all drum tracks except the kick.
13) The song plays back normally.
14) Un-mute regions on 1 track and playback and repeat for each track.
15) The song plays back normally until the 8th drum track is un-muted, then the error is thrown.
16) Mute and un-mute the regions on 8th drum track.
17) The song now plays back normally. Error no longer thrown.
Looks like after making the edits, muting all the regions and un-muting them 1 by one might have cleared this up right away.
Is anyone else is experiencing something similar? If so, how are you working around this?

No, didn't solve it yet, after I'm done completing work to meet a deadline, I will do some experimenting and see what I can figure out. But so far I've had this phasing issue occur in two different sessions on two different rigs (both Mac Pro dual-quad core with lotsa RAM)...
One test that anyone could try... to really max it out... take one single source and record it onto 20 tracks at once... or I guess you could just record one track and then duplicate it 19 times, whatever. Group all these tracks, keep `em all at the same level. Then take a listen to all tracks at once using some good headphones.
Then put all the tracks in flex mode and do some flexing, flex every single quarter note this way and that way for three full measures or so, whatever. Then play it back again with headphones. If you hear ANY hint of phase shifting, then you are experiencing what I am experiencing.
For anyone who might not be familiar with the "phase shifting" sound I speak of, it pretty much will sound as if you are running your tracks through a classic "phase shifter" effect pedal or whatever. If using headphones, it'll seem like the audio starts swirling around in your head like some wacky stereo effect, frequency response will change and shift, etc.
I've noted that I have not always heard phase issues when flexing, it seem to be a bit inconsistent. It may be because I've been working in some very large sessions, maybe in my situations Logic was already being heavily taxed and then the extra flexing just put it over the edge. Don't know. Will do some testing perhaps next week.
But, I'd say everyone should be careful about this before bouncing forever to disk and then maybe deleting all your old raw audio, because if you permanently write in some wacky phase shifting between your group of drum tracks and have no original raw files left, you'll be in very big trouble... I don't think there would be any way to fix that. In a professional level mix, that type of issue would stick out like a sore thumb. I guess one fix would be to apply a phase shifter effect across the entire drum bus... on purpose... as some sort of artistic statement... hey, it might sound cool!
This whole issue has made me realize how incredibly important it is for DAW tracks to remain truly phase locked at all times. Been working with DAWs for years now and never really thought about it. In one regard, this is a lot to ask... to make sure your 30-odd tracks or whatever are always dead in time with each other, to the sample. It's certainly of critical importance, at least for multiple tracks of the same exact source (like when you have 12 mics on a drum kit etc).
Actually, perfect time synch is just as critical for even a mere TWO mics on a given source... any stereo recording. Once one track goes out of "synch" with the other, even by a minute amount, just for a short amount of time, you will HEAR it.,.. and it won't be good... unless you desire a wacky phase shifting effect.

Storage clause for locally manged tablespace with unifom size extents

in oracle 9i PERSONAL EDITION
I HAVE CREATED A TABLESPACE TEST1 AS LOCALLY MANAGED WITH UNIFORM SIZE AS 256K.MY DB_BLOCK_SIZE IS 4K
I HAVE CREATED A TABLE XYX IN THE TEST1 TABLESPACE WITH THE STORAGE (INITIAL 52K NEXT 52K)
WHEN I QUERIED THE DBA_EXTENTS IT SHOWS THE INITAIL EXTENT AS 256 K
BUT WHEN I QUERIED THE DBA_SEGMENTS IT SHOWS THE INITAL_EXTENT AS 52K.
IS THEIR ANY SIGNIFICANCE OF SPECIFYING THE STORAGE CLAUSE IN LOCALLY MANAGED TABLESPACES.

take a example what is effect of set storage parameter in table whoes tablespace is locally manager and have uniform size
i have a tablespace whoes
[b]uniform size is 32k
but when i create a table then i set initial 128k
now when table is create it create 4 extent
of 32 each(32*4=128)
because tablespace uniform size is 32
if we give intial 256 then it create
8 extent(32*8=256)
like
create tablespace tt_check
datafile 'E:\ORACLE\SAFE_DATA\tt_check.dbf' size 10m
extent management local uniform size 32k;
create table tt_1
(no number)
tablespace tt_check
storage(initial 128k
next 128k);
1* select extent_id,segment_name,tablespace_name,bytes from dba_extents where segment_name='TT_1'
QL> /
EXTENT_ID SEGMENT_NAME TABLESPACE_NAME BYTES
0 TT_1 TT_CHECK 32768
1 TT_1 TT_CHECK 32768
2 TT_1 TT_CHECK 32768
3 TT_1 TT_CHECK 32768
hope it will help you
kuljeet pal singh

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

Rebuild ASM Disk - Copying multiple datafiles from one disk to another

Hi,
I have an environment of four 11GR2 Oracle databases on a Linux server. Each database has its own ASM disk.
DB1 -> ASM_DISK1
DB2 -> ASM_DISK2
DB3 -> ASM_DISK3
DB4 -> ASM_DISK4
I need to rebuild one of the ASM disks (ASM_DISK1), but first I need to copy all of the datafiles to another disk (ASM_DISK2). I tried backing up the database using RMAN, but it was taking too long (nearly two days when I cancelled it). So now I am going to copy the files using ASMCMD CP command.
Basically my task is as follows:
1. Shutdown database.
2. Copy all data from ASM_DISK1 to ASM_DISK2.
3. Drop ASM_DISK1.
4. Re-create ASM_DISK1.
5. Copy all data back to ASM_DISK1.
6. Start database.
Database size is 700GB.
I am using the below script to copy the files.
Copy Script
================
asmcmd ls +ASM_DISK1/DB1/DATAFILE >> asm_list.txt
for FILENAME in `cat asm_list.txt`
do
asmcmd >> asm_LOG.log <<EOF
cp ASM_DISK1/DB1/DATAFILE/$FILENAME ASM_DISK2/DB1_BACKUP/DATAFILE/$FILENAME.dbf
EOF
done
================
I will then rename each file in the database like so:
alter database rename file '+ASM_DISK1/DB1/DATAFILE/filename' to '+ASM_DISK1/DB1/DATAFILE/filename.dbf'
My questions are as follows.
Is this approach a valid solution?
Will renaming the files during copy corrupt the files?
When I copy the files back to the original disk after rebuild, then rename them, will the database be able to start?
Rgs,
Rob

rgilligan_tnf wrote:
Hi,
I have an environment of four 11GR2 Oracle databases on a Linux server. Each database has its own ASM disk.
DB1 -> ASM_DISK1
DB2 -> ASM_DISK2
DB3 -> ASM_DISK3
DB4 -> ASM_DISK4
I need to rebuild one of the ASM disks (ASM_DISK1), but first I need to copy all of the datafiles to another disk (ASM_DISK2). I tried backing up the database using RMAN, but it was taking too long (nearly two days when I cancelled it). So now I am going to copy the files using ASMCMD CP command.
And how do you propose to update the controlfile to point to the new location?
unless your datafiles are offline and/or the database is down, you will corrupt them and have an unusable database when you finish.
how were you doing this with RMAN? Depending on the size of your database(700G), it very well could take some time. I have restored databases at a rate of >300G/hr from scratch. You will need to shutdown at some point to relocate the controlfiles and system and redo logfiles.
Just curious, what is the problem with diskgroup ASM_DISK1 that you want to rebuild it?
Basically my task is as follows:
1. Shutdown database.
2. Copy all data from ASM_DISK1 to ASM_DISK2.
3. Drop ASM_DISK1.
4. Re-create ASM_DISK1.
5. Copy all data back to ASM_DISK1.
6. Start database.
Database size is 700GB.
I am using the below script to copy the files.
Copy Script
================
asmcmd ls +ASM_DISK1/DB1/DATAFILE >> asm_list.txt
for FILENAME in `cat asm_list.txt`
do
asmcmd >> asm_LOG.log <<EOF
cp ASM_DISK1/DB1/DATAFILE/$FILENAME ASM_DISK2/DB1_BACKUP/DATAFILE/$FILENAME.dbf
EOF
done
================
I will then rename each file in the database like so:
alter database rename file '+ASM_DISK1/DB1/DATAFILE/filename' to '+ASM_DISK1/DB1/DATAFILE/filename.dbf'
My questions are as follows.
Is this approach a valid solution?
Will renaming the files during copy corrupt the files?
When I copy the files back to the original disk after rebuild, then rename them, will the database be able to start?
Rgs,
Rob

Tablespace with datafiles on many disks

Similar Messages

Maybe you are looking for