Problem size tablespaces different datafile

I have a problem, the space of tablespaces is different from the datafile, and it is shrinking from the console of the Oracle tablespaces, the datafile remains in the same space at all.
example i have a tablespaces of 500m and the datafile of 1gb...
Oracle 9i RAC (9.2.0.8)
Window 2003
you have a solution?
thanks

THIS IS SQL TO ORACLE........................................
TABLESPACE_NAME FILE_NAME BYTES
AMC_INDICI L:\ORADATA\AMM\AMC_INDICI01.DB 5767168000
F
AMC_LAVORO L:\ORADATA\AMM\AMC_LAVORO01.DB 9437184000
F
CICLOPASSIVO L:\ORADATA\AMM\CICLOPASSIVO01 52428800
CIPAFATTURE_DAT L:\ORADATA\AMM\CIPAFATTURE_DAT 525336576
I I.DBF
CIPAFATTURE_IND L:\ORADATA\AMM\CIPAFATTURE_IND 157286400
TABLESPACE_NAME FILE_NAME BYTES
ICI ICI.DBF
CWMLITE L:\ORADATA\AMM\CWMLITE01.DBF 20971520
DRSYS L:\ORADATA\AMM\DRSYS01.DBF 20971520
EMPOWER_DATI L:\ORADATA\AMM\EMPOWER_DATI01. 209715200
DBF
EMPOWER_INDICI L:\ORADATA\AMM\EMPOWER_INDICI0 104857600
1.DBF
EXAMPLE L:\ORADATA\AMM\EXAMPLE01.DBF 125829120
TABLESPACE_NAME FILE_NAME BYTES
GESTIONE_ACCOUN L:\ORADATA\AMM\GESTIONE_ACCOUN 524288000
T T01.DBF
INDICI L:\ORADATA\AMM\INDICI_1.DBF 2621440000
INDX L:\ORADATA\AMM\INDX01.DBF 26214400
LAVORO L:\ORADATA\AMM\LAVORO_1.DBF 7340032000
LAVORO L:\ORADATA\AMM\LAVORO_2.DBF 7340032000
ODM L:\ORADATA\AMM\ODM01.DBF 20971520
PAGHECUD L:\ORADATA\AMM\PAGHECUD1.DBF 2097152000
RSTAMPA L:\ORADATA\AMM\RSTAMPA1.DBF 104857600
SAM_DATA L:\ORADATA\AMM\SAM_DATA_1.DBF 146800640
TABLESPACE_NAME FILE_NAME BYTES
SAM_INDX L:\ORADATA\AMM\SAM_INDX_1.DBF 157286400
SCRIPTA L:\ORADATA\AMM\SCRIPTA01.DBF 1048576000
SCRIPTA_NDX L:\ORADATA\AMM\SCRIPTA_NDX01.D 524288000
BF
SYSTEM L:\ORADATA\AMM\SYSTEM01.DBF 450887680
TELECOM L:\ORADATA\AMM\TELECOM.DBF 1258291200
TOOLS L:\ORADATA\AMM\TOOLS01.DBF 10485760
UNDOTBS1 L:\ORADATA\AMM\UNDOTBS01.DBF 314572800
UNDOTBS2 L:\ORADATA\AMM\UNDOTBS02.DBF 524288000
UNDOTBS3 L:\ORADATA\AMM\UNDOTBS03.DBF 524288000
TABLESPACE_NAME FILE_NAME BYTES
USERS L:\ORADATA\AMM\USERS01.DBF 31457280
XDB L:\ORADATA\AMM\XDB01.DBF 47185920
Selezionate 30 righe.
THIS IS DIR DOS TO WINDOWS
30/07/2009 09:45 47.194.112 XDB01.DBF
22/06/2010 15:47 31.465.472 USERS01.DBF
06/09/2010 11:03 17.007.910.912 UNDOTBS03.DBF
07/05/2010 10:02 15.041.830.912 UNDOTBS02.DBF
25/10/2010 11:24 314.580.992 UNDOTBS01.DBF
30/07/2009 09:38 10.493.952 TOOLS01.DBF
04/11/2010 12:27 21.297.635.328 TEMP01.DBF
07/12/2009 10:46 1.572.872.192 TELECOM.DBF
19/11/2010 15:10 450.895.872 SYSTEM01.DBF
30/07/2009 09:52 3.584 SPFILEAMM.ORA
21/03/2010 11:20 524.296.192 SCRIPTA_NDX01.DBF
21/03/2010 11:20 1.048.584.192 SCRIPTA01.DBF
18/06/2010 12:10 157.294.592 SAM_INDX_1.DBF
18/06/2010 12:10 146.808.832 SAM_DATA_1.DBF
06/10/2009 14:03 104.865.792 RSTAMPA1.DBF
16/01/2010 16:17 2.097.160.192 PAGHECUD1.DBF
30/07/2009 09:38 20.979.712 ODM01.DBF
31/05/2010 13:20 7.340.040.192 LAVORO_2.DBF
05/10/2009 09:37 10.485.768.192 LAVORO_1.DBF
30/07/2009 09:38 26.222.592 INDX01.DBF
05/10/2009 15:47 9.437.192.192 INDICI_1.DBF
25/01/2010 10:36 1.048.584.192 GESTIONE_ACCOUNT01.DBF
30/07/2009 09:38 125.837.312 EXAMPLE01.DBF
10/06/2010 09:04 104.865.792 EPOWER_INDICI01.DBF
10/06/2010 09:03 209.723.392 EPOWER_DATI01.DBF
10/06/2010 09:25 104.865.792 EMPOWER_INDICI01.DBF
10/06/2010 09:26 209.723.392 EMPOWER_DATI01.DBF
30/07/2009 09:38 20.979.712 DRSYS01.DBF
30/07/2009 09:38 20.979.712 CWMLITE01.DBF
30/07/2009 09:38 12.247.040 CONTROL03.CTL
30/07/2009 09:38 12.247.040 CONTROL02.CTL
30/07/2009 09:38 12.247.040 CONTROL01.CTL
06/08/2009 14:37 524.296.192 CIPAFATTURE_INDICI.DBF
06/08/2009 14:37 1.048.584.192 CIPAFATTURE_DATI.DBF
01/06/2010 10:06 52.436.992 CICLOPASSIVO01
30/07/2009 09:52 10.486.272 AMM_REDO3_2.LOG
30/07/2009 09:52 10.486.272 AMM_REDO3_1.LOG
30/07/2009 09:52 10.486.272 AMM_REDO2_2.LOG
30/07/2009 09:52 10.486.272 AMM_REDO2_1.LOG
30/07/2009 09:38 10.486.272 AMM_REDO1_2.LOG
30/07/2009 09:38 10.486.272 AMM_REDO1_1.LOG
01/06/2010 08:34 9.437.192.192 AMC_LAVORO01.DBF
01/06/2010 08:36 5.767.176.192 AMC_INDICI01.DBF

Similar Messages

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 !

File SIZES are Different ?

Hi Experts,
I have implemented ESR By pass Scenario.
The problem is we are getting the file sizes are differently in Source folder and Target folder
How can we resolve this issue
Please Guide Me
Thanks and Regards,
Ravi Teja.

Refer to question no. 2 under the below wiki and see if that configuration helps.
Sender File Adapter Frequently Asked Questions - Process Integration - SCN Wiki

Maximun size for a datafile

Hi,
Oracle Version :10.2.0.1
Operating system:Linux
Can any please tell me what is the maximum size that a datafile can grow and the maximum size for tablespace.
Here i am having one tablespace which is having 4 datafile in that 2 datafile are 33 gb and the other 2 datafile size are 1gb and 400 mb.But in my OEM it is showing that your tablespace ECA_DATA is 88 percent full.
I think there is no maximum size for the tablespace but why it is how it is showing the my tablespace is 88 percent full.

Hi,
Here is the output of the query which you have given.Can you pleas tell me what is the
FILE_ID|FILE_NAME|ALLOCATED|USED|FREE
1|/u02/oradata/eca/system01.dbf|901775360|894435328|7274496
2|/u02/oradata/eca/undotbs01.dbf|4881121280|47841280|4833214464
3|/u02/oradata/eca/sysaux01.dbf|713031680|698744832|14221312
4|/u02/oradata/eca/users01.dbf|13851688960|595197952|13256425472
5|/u03/oradata/eca/ECAPROD_01.dbf|131072||65536
6|/u03/oradata/eca/ECA_DATA_01.dbf|34358951936|31995723776|2363097088
7|/u02/oradata/eca/ECA_INDX_01.dbf|17028874240|6012272640|11016536064
8|/u02/oradata/eca/ECAUAT_01.dbf|104857600||104792064
9|/u02/oradata/eca/ECAPREPROD|106496||65536
10|/u02/oradata/eca/ECA_DATA2|34358951936|33730527232|628293632
11|/u02/oradata/eca/ecadump.dbf|12582912||12517376
12|/u02/oradata/eca/ecaread.dbf|18517721088|12014845952|6502809600
13|/u03/oradata/eca_80504.dbf|104857600||104792064
14|/u03/oradata/eca_80505.dbf|104857600||104792064
15|/u03/oradata/ECAVAPDL.dbf|104857600|4784128|100007936
16|/u02/oradata/eca/ECA_DATA3|1048576000|1048313856|196608
17|/u02/oradata/eca/ecadump1.dbf|419430400||419364864
18|/u02/oradata/eca/ECA_DATA3.dbf|419430400|419364864|
19|/u02/oradata/eca/CKM_PROD_P2.dbf|11943804928|11925979136|17760256
20|/u02/oradata/eca/CKM_PROD_p3.dbf|12575178752|12431785984|143327232
21|/u02/oradata/eca/CKM_PROD_p4.dbf|13187809280|13187743744|Here my tablespace ECA_DATA contains datafile are
FILE_ID|FILE_NAME|ALLOCATED|USED|FREE
6|/u03/oradata/eca/ECA_DATA_01.dbf|34358951936|31995723776|2363097088
10|/u02/oradata/eca/ECA_DATA2|34358951936|33730527232|628293632
16|/u02/oradata/eca/ECA_DATA3|1048576000|1048313856|196608
18|/u02/oradata/eca/ECA_DATA3.dbf|419430400|419364864|Edited by: SIDDABATHUNI on Nov 30, 2009 2:29 AM

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

Can we decrease the size of existing datafile?

Hi,
can we decrease the size of existing datafile?
Thanks,

It is a very nice script.
But it does not deal with something that appears to be being 'pushed' by some contributors (OK, one, really) to this forum as a suitable 'fix' for some performance problems: using multiple block sizes in one database. It's not surprising the script doesn't deal with this, though, because Tom Kyte has never particularly approved of using multiple blocksizes like that.
Being specific, the script at Ask Tom queries for the setting of db_block_size parameter and uses that to work out what a datafile can be shrunk to. If you have datafiles using non-standard block sizes, however, then that script will not work correctly for them.
It's always potentially dangerous making use of 5-year old scripts found on the internet, even somewhere as good as Ask Tom.
It's also a good demonstration as to why, for at least one reason, it's potentially dangerous following Mr. Burleson's advice on multiple block sizes.

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 ?

Reduce size of system datafile?

Hi all,
An old Oracle box was just about out of disk space. Investigating, I saw that the SYSTEM tablespace's datafile is sized at 4090 MB... but only 265 MB is actually being used.
I'd like to shrink it to 1 GB or even 500 MB. but when I tried
ALTER DATABASE DATAFILE '/export/home/sw/oracle/eedb/817/u01/oradata/devdb/system01.dbf'
RESIZE 1024M;
I got:
ORA-03297: file contains used data beyond requested RESIZE value
I was able to run the statement using 2048 MB, but is there any way to get back the last gig or so?
Thanks,
Natasha

you know that inside tablespaces can be fragmentation and the used size does not represent that the rest is free because there blocks used and unused blocks in no continous way. You can see the fragmentation of a tablespace mapping it in OEM.
you can probe doing this and after resize it:
SQL> alter tablespace system coalesce;
Tablespace altered.
SQL>
try to resize little by little until Oracle tell you that it is not more possible.
Joel P�rez

Spooling of a query generates different file sizes for different databases

Please help me regarding a problem with spooling. I spooled a query output to a file from two different database. In both the databases the table structure is the same and the output produced only one row. But the file size is different for the databases. How can this problem occur? Is there any database parameter need to be checked? Both the databases are in same version 10.2.0.1.0.
before running the spool i did a
sql> set head off feedback off echo off verify off linesize 10000 pages 0 trims on colsep ' '
on both the sessions.
In one database the filesize is *1463 bytes* and on the other the filesize is *4205 bytes*.
Please help me to find out these discrepancies.

hi Mario,
I think you are not getting my point. Both the files contain the same output but their sizes are different. This is due to the no of blank spaces between columns. I wanted to clarify why there is a difference between two filesize when the query output is the same.

SIZE TABLESPACE

I'm make a import, but get next errors:
ORA-01659: unable to allocate MINEXTENTS beyond 1 in tablespace OPC_DATOS
ORA-01658: unable to allocate INITIAL for segment in tablespace OPC_DATOS
I 'm created like;
CREATE TABLESPACE OPC_DATOS DATAFILE 'C:\BASES\OPC_DATOS.DBF' SIZE 500M AUTOEXTEND ON NEXT 500 MAXSIZE 7000M;
i dont know allocate size for parameters of tablespaces, i refer MINEXTENTS, INITIAL , MAXEXTENDS, PCTINCRESE

Post results of
SELECT * from v$version;
DICTIONARY or LOCAL Managed tablespace?

After duplicate operation, file sizes(Checkpoint file size) are different

HI
I have a some questions.
We are testing a 4-way Replication. After duplicate operation, file sizes(Checkpoint file size) are different in OS command(du -sh).
Is the normal?
TimesTen Version : TimesTen Release 7.0.5.0.0 (64 bit Solaris)
OS Version : SunOS 5.10 Generic_141414-02 sun4u sparc SUNW,SPARC-Enterprise
[TEST17A] side
[TEST17A] /mmdb/DataStore # du -sh ./*
6.3G ./SAMPLE
410M ./SAMPLE_LOG
[TEST17A] /mmdb/DataStore/SAMPLE # ls -lrt
total 13259490
-rw-rw-rw- 1 timesten other 501 Aug 14 2008 SAMPLE.inval
-rw-rw-rw- 1 timesten other 4091428864 Jan 29 02:13 SAMPLE.ds1
-rw-rw-rw- 1 timesten other 4113014784 Jan 29 02:23 SAMPLE.ds0
[TEST17A] /mmdb/DataStore/SAMPLE # ttisql sample
Command> dssize ;
PERM_ALLOCATED_SIZE: 8388608
PERM_IN_USE_SIZE: 36991
PERM_IN_USE_HIGH_WATER: 36991
TEMP_ALLOCATED_SIZE: 524288
TEMP_IN_USE_SIZE: 5864
TEMP_IN_USE_HIGH_WATER: 6757
[TEST17B] side
[TEST17B] /mmdb/DataStore # du -sh ./*
911M ./SAMPLE
453M ./SAMPLE_LOG
[TEST17B] /mmdb/DataStore/SAMPLE # ls -lrt
total 1865410
-rw-rw-rw- 1 timesten other 334 Dec 11 2008 SAMPLE.inval
-rw-rw-rw- 1 timesten other 4091422064 Jan 29 02:25 SAMPLE.ds1
-rw-rw-rw- 1 timesten other 4091422064 Jan 29 02:25 SAMPLE.ds0
[TEST17B] /mmdb/DataStore/SAMPLE # ttisql sample
Command> dssize;
PERM_ALLOCATED_SIZE: 8388608
PERM_IN_USE_SIZE: 432128
PERM_IN_USE_HIGH_WATER: 432128
TEMP_ALLOCATED_SIZE: 524288
TEMP_IN_USE_SIZE: 5422
TEMP_IN_USE_HIGH_WATER: 6630
[TEST18A] side
[TEST18A] /mmdb/DataStore # du -sh ./*
107M ./SAMPLE
410M ./SAMPLE_LOG
[TEST18A] /mmdb/DataStore/SAMPLE # ls -lrt
total 218976
-rw-rw-rw- 1 timesten other 4091422064 Jan 29 02:22 SAMPLE.ds0
-rw-rw-rw- 1 timesten other 4091422064 Jan 29 02:32 SAMPLE.ds1
[TEST18A] /mmdb/DataStore/SAMPLE # ttisql sample
Command> dssize;
PERM_ALLOCATED_SIZE: 8388608
PERM_IN_USE_SIZE: 36825
PERM_IN_USE_HIGH_WATER: 37230
TEMP_ALLOCATED_SIZE: 524288
TEMP_IN_USE_SIZE: 6117
TEMP_IN_USE_HIGH_WATER: 7452
[TEST18B] side
[TEST18B] /mmdb/DataStore # du -sh ./*
107M ./SAMPLE
411M ./SAMPLE_LOG
[TEST18B] /mmdb/DataStore/SAMPLE # ls -lrt
total 218976
-rw-rw-rw- 1 timesten other 4091422064 Jan 29 02:18 SAMPLE.ds1
-rw-rw-rw- 1 timesten other 4091422064 Jan 29 02:28 SAMPLE.ds0
[TEST18B] /mmdb/DataStore/SAMPLE # ttisql sample
Command> dssize;
PERM_ALLOCATED_SIZE: 8388608
PERM_IN_USE_SIZE: 36785
PERM_IN_USE_HIGH_WATER: 37140
TEMP_ALLOCATED_SIZE: 524288
TEMP_IN_USE_SIZE: 5927
TEMP_IN_USE_HIGH_WATER: 7199
Thank you very much.
GooGyum

You don't really give much detail on what operations were performed and in what sequence (e.g. duplicate from where to where...) nor if there was any workload running when you did the duplicate. In general checkpoint file sizes amongst replicas will not be the same / remain the same because:
1. Replicas are logical replicas not physical replicas. Replication transfers logical operations and applies logical operations and even if you try and do exactly the same thing at both sides in exactly the same order there are internal operations etc. that are not necessarily synchronised which will cause the size of the files to vary somewhat.
2. The size of the file as reported by 'ls -l' represents the maximum offset that has so far been written to in the file but the current 'usage' of the file may be less than this at present.
3. Checkpoint files are 'sparse' files (unless created with PreAllocate=1) and so the space used as reported by 'du' will in general not correspond ot the size of the file as reported by 'ls -l'.
Unless you are seeing some kind of problem I would not be concerned at an apparent difference in size.
Chris

I have a few hundred duplicates in my iPhoto library, but the file sizes are different. So one is 1.3mb and one is 567kb. I want to delete the smaller ones, but short of comparing each duplicate, is there a way to do this?

I have a few hundred duplicates in my iPhoto library, but the file sizes are different. So one is 1.3mb and one is 567kb. I want to delete the smaller ones, but short of comparing each duplicate, is there a way to do this? I've been looking at Duplicate Annhilator but I don't think it can do it.
Thanks!

I just ran a test with iPhoto Library Manager, Duplicate Annihilator, iPhoto Duplicate Cleaner, Duplifinder and Photodedupo. I imported a folder of 5 photos into a test library 3 times, allowing iPhoto to import duplicates. I then ran the 5 photos thru resizer to reduce their jpeg compression but all other aspects of the file the same.
None of the duplicate removal apps found set that was reduced in the file resizer. That's probably due to the fact that the file creation date was being used as a criteria and the resized photo would have a different file creation date even though the Image Capture date was the same.
They all found the 3 regular duplicates and some of them would mark two and leave the 3rd unmarked. iPhoto Duplicate Cleaner can sort the found duplicates by file size but if the file was edited to get the reduced file size it might not be found as it would have a different file creation/modification date.
iPhoto Library Manage was able to find all duplicates and mark them as such if the file names were the same the the filename option was selected. Otherwise it also missed the modified, resized version. It allowed one to select the one photo to save before going to work on the library.
So if a photo has been reduced in image quality or pixel size it will not be considered a duplicate.
OT

Using iMovie 7.1.4 on an iMac w/ Snow Leopard; HD video imported with a Firewire cable transfers fine, but audio arrives with major static; problem persists w/ different cameras

Using iMovie 7.1.4 on an iMac w/ Snow Leopard; HD video imported with a Firewire cable transfers fine, but audio arrives with major static; problem persists w/ different cameras & Firewire cables; source DV tape has no audfio static.

I forgot to write down my computer specs:
iMac 27 Mid 2011
2.7 GHz Intel Core i5
4 GB 1333 MHz DDR3
AMD Radeon HD 6770M 512 MB
OS X 10.9.2

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.

Is it possible to have same file size for different dpi?

I changed one.TIFF file (300dpi, 1024X1332) to .jpg files of four different dpi. But when I checked the four result jpg files, I found out that they are all in same file size and quality.( I also have checked the property of the files in the Windows.)
I think more DPI means more data and more file size. Am I wrong?
I use Photoshop CS 5.1(64bit, WINDOWS) - which is part of my Adobe Master Collection CS5.5.
TIFF(300dpi, 1024X1332) ->
1. JPG(72dpi, 1024X1332) : 306KB
2. JPG(108dpi, 1024X1332) : 306KB
3. JPG(144dpi, 1024X1332) : 306KB
4. JPG(600dpi, 1024X1332) : 306KB
I tested a few times more with different files. and same result comes out.(same file size for different dpi)
Thanks in advance.

Yes absolutely. Great observation. PPI does not control the number of pixels, just how big they are.
Now, if you change the PPI in the Image Size dialog with Resample checked.. then, that is a different story. In that case you will be changing the pixel dimension of an image (i.e.,changing the total number of pixels making up the image) while keeping its print size.
In your test files, you will notice all the print sizes are different, because all you were telling Photoshop to do was change the size of the pixels (if or when the image is ever printed), which is really just a bit of metadata of the file.

Problem size tablespaces different datafile

Similar Messages

Maybe you are looking for