Doubt in Tablespaces

Hello all,
The production system is on SAP R/3 4.7
oracle 10.2.0.4
windows 2003 enterprise server(32-bit).
I have the following doubts.
1) The tablespaces in the system are dictionary managed tablespces. I have encountered frequent performance problems when the table size is large.
Do i need to change into locally managed tablespace?
2) Are reorganization of tables possible in locally managed tablespace or can it be done in dictionary managed tablespace too?
3) When i reorganize a table do i need to recreate the indexes?
Please clarify.
Regards,
siddhartha.

Hi,
Read these SNOTEs carefully, they will help you.
Note 355771 - Oracle: Explanation of the new tablespace layout
Note 659946 - FAQ: Temporary tablespaces
Note 164925 - Storage parameter of tablespace PSAPTEMP
Note 214995 - Oracle locally-managed tablespaces in the SAP environment
Note 541538 - FAQ: Reorganization
Note 618868 - FAQ: Oracle performance
Note 646681 - Reorganizing tables with BRSPACE
Regards
Bhavik Shroff
Edited by: Bhavik G. Shroff on Nov 13, 2008 6:46 AM

Similar Messages

Doubts in the rollback tablespace

Dear Gurus,
I created a database using dbca to do it...
The creation was fine, but when I looked at the rollback segments at OEM I saw that the tablespace of the rollback is the system tablespace....
Now I have a doubt, the tablespace of the rollback segment wasnÂ´t to be the UNDOTBS1?
Thnks...

rollback segments show the active undo segments used in ur database (database vide), as system segment is created as the database created for system table space undo activities, further the oracle by default create and drop undo segments automatically and will not show in rollback segments , u can view the active created segments in v$rollstat view which are system generated. you can create your custom undo segments but for that u have to set parameters in initial parameter file and have to tell oracle to manage undo segments manually.

Tablespace Doubt

Hi Guys I have one doubt regarding tablespace this may be the basic one, kindly post ur views on this.
I am creating one tablespace as
CREATE TABLESPACE WHMTBS
DATAFILE 'G:\ORACLE10G\TABLESPACE\WHMTBS.dbf' SIZE 500M
SEGMENT SPACE MANAGEMENT AUTO
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 5M
BLOCKSIZE 8K
AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED
when i execute above statement i got an error message as
ORA-02180 Invalid option for create tablespace
I changed my statement as below and executed it works fine
CREATE TABLESPACE WHMTBS
DATAFILE 'G:\ORACLE10G\TABLESPACE\WHMTBS.dbf' SIZE 500M
AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED
SEGMENT SPACE MANAGEMENT AUTO
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 5M
BLOCKSIZE 8K
Do we need to give the statements in sequential order? It is necessary?
kindly clarify the concept behind it..
Thanks
Vijayaraghavan K

Yeah, the problem is that the "AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED" refers to the datafile, not the tablespace. In other words, the thing that you are telling Oracle can be autoextended is the datafile not the tablespace.
Hope that helps,
-Mark

Used part of the tablespace

Hi
I appreciate if anyone can clear my doubts.
create tablespace test datafile
'C:\test.dbf' size 50M
extent management local uniform size 10M
When I check the used space of this tablespace:
I notice that
1-)Even the tablespace is empty, it shows 10M as a used part ?
2-)When I create an empty table in this tablespace, the used part becomes 20M ? Since the table is empty why used part increase? It should increase after the rows inserted into the table? I know 10M of extent allocated for the table, but it should be free for inserts, why does it occupy space in used part?
Thanks

so the below script doesnt show the free blocks inside the extents of segments.
Even it shows there is not available space in the tablespace, there might be space available inside the extents of the segments....
Am I right??
select (select decode(extent_management,'LOCAL','*',' ')
          from dba_tablespaces where tablespace_name = b.tablespace_name) ||
nvl(b.tablespace_name,
             nvl(a.tablespace_name,'UNKOWN')) name,
       kbytes_alloc kbytes,
       kbytes_alloc-nvl(kbytes_free,0) used,
       nvl(kbytes_free,0) free,
       ((kbytes_alloc-nvl(kbytes_free,0))/
                          kbytes_alloc)*100 pct_used,
       nvl(largest,0) largest,
       nvl(kbytes_max,kbytes_alloc) Max_Size,
       decode( kbytes_max, 0, 0, (kbytes_alloc/kbytes_max)*100) pct_max_used
from ( select sum(bytes)/1024 Kbytes_free,
              max(bytes)/1024 largest,
              tablespace_name
       from sys.dba_free_space
       group by tablespace_name ) a,
     ( select sum(bytes)/1024 Kbytes_alloc,
              sum(maxbytes)/1024 Kbytes_max,
              tablespace_name
       from sys.dba_data_files
       group by tablespace_name
       union all
      select sum(bytes)/1024 Kbytes_alloc,
              sum(maxbytes)/1024 Kbytes_max,
              tablespace_name
       from sys.dba_temp_files
       group by tablespace_name )b
where a.tablespace_name (+) = b.tablespace_name
order by &1

Doubt in considering temp tablespace's free space

Hi All,
Database: oracle 11.2
Operating System: AIX
I want to know how much free space available in my temp tablespace
I ran below scripts
select sum((bytes_free)/1024/1024/1024) GB from v$temp_space_header
+52.904296875+
select (tablespace_size)/1024/1024/1024 tablespace_size_in_gb,
+(allocated_space)/1024/1024/1024 allocated_space_in_gb,+
+(free_space)/1024/1024/1024 free_space_in_gb+
from dba_temp_free_space
tablespace_size_in_gb: 98.9990234375
allocated_space_in_gb: 46.0947265625
free_space_in_gb:151.81640625
So my doubt is which one from above two script gives actual free space information ?
Also in dba_temp_free_space view why free space size > tablespace size ?

v$temp_space_header shows you how big the temp tablespace has got since the database was restarted. It doesn't give you the current free/used space.
See the link for dba_temp_free_space, but I think it may be the way it reports free space which is why you're seeing it as more than the actual tablespace. As you can see form the description "space that is currently allocated and available for resuse" is calculated for both allocated space and free space.
http://docs.oracle.com/cd/B28359_01/server.111/b28320/statviews_5056.htm
>
ALLOCATED_SPACE = space that is currently allocated and used + space that is currently allocated and available for reuse
FREE_SPACE = space that is currently allocated and available for reuse + space that is currently unallocated>
I use the below script which I've plagiarised from somewhere ages ago to get the used/free temp space.
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;

Doubt regarding ORA-30036: unable to extend segment by 8 in undo tablespace

I am using 11g Release 1 Database .
I have to analyze the performance of two tables of different designs which serve the same purpose and come up with the design which is efficient .
SQL> desc staging_dict
Name                                      Null?    Type
SNO                                                NUMBER
CODE_FRAGMENTS                                     CLOB
CODE_FRAGMENTS_U                                   CLOB
CODE_FRAGMENTS_D                                   CLOB
CODE_FRAGMENTS_DO                                  CLOB
SQL> desc staging_dict1
Name                                      Null?    Type
SNO                                                NUMBER
CODE_FRAGMENTS                                     CLOB
CODE_FRAGMENTS_UD                                  CLOB
CODE_TYPE                                          VARCHAR2(5 CHAR)Initially I tried inserting a few thousand records into both the tables . Then I did some conversion on one column and I populate the result on other column of the same table . So I update the table in bulk mode and I commit for every thousand records .
I have a undo tablespace of 2G with undo_retention=900 , retention guratantee is not set for the undo tablespace .
When I tried the conversion and update on the first table (STAGING_DICT) it took more time for around 2500 records compared to other table and when I increased the number of records to 10000 it threw an error
ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS'
But I didn't come across this error when I tried the conversion and update on the table for the same 2500 records (STAGING_DICT1) and it was also 10 times faster .
My doubt is does the error ORA-30036 occur because it is saving the undo image of all the four clob columns though I am doing conversion on one column and updating the other column (using only two columns in the update and only one column is affected by update command) ?
Also how is that having less CLOB rows prove more effective by adding one more VARCHAR column which differentiates the code_frament type in the STAGING_DICT1 table than having it as more CLOB columns as in STAGING_DICT table ?

Don't you think the error OP reported is kind of weird?
Because as you said, Oracle stores "undo" of lob in user tablespace not undo tablespace if the lob is stored out-of-line.
1. If the size of lob was small, small size of undo would be stored into undo tablespace,
and OP would'nt have undo tablespace shortage problem.
(How does small lob flood undo tablespace?)
2. If the size of lob was big, OP would have 01555 error on user tablespace not undo tablespace shortage error.
So, i think there are 2 theories that can explain this abnormality.
1. OP hit the bug of massive undo generation.
2. OP is using securefile which is 11g new feature.
Oracle documents says that undo for securefile lob is stored in "undo" tablespace, not user tablespace.
But unfortunately, i'm not sture about this coz i didn't try it myself

Sql loader and tablespace doubt

while i was inserting the data into a table using sqlloader and then suddenly the datafile gets full and i got sql*loader 605 error and i alloted a new datafile to the tablespace but the data didnt get inserted after that and the error was same sql*loader 605,but when i increase the size of the datafile then the error gets removed....why is it so???

The data didn't get inserted because there was no space in the datafile.
you increased the data file size, but the insert was already stopped because of the error.
The error didn't happen again, because there was enough space in the datafile.
See the log file for more details of the error. This error is not data related. from 605 that all we can understand.
Note:: Please make short statements and ask clearly your questions. I have to read 5 time to kind of understand what you ask for.

Doubt with parameters creating a tablespace and a table

I've created a tablespace and a table with these data:
CREATE TABLESPACE "TAB_FILE"
LOGGING
DATAFILE 'C:\TAB_FILE.ora' SIZE 20M
AUTOEXTEND ON NEXT 5M MAXSIZE 500M
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;
CREATE TABLE FILE
IDFILE NUMBER(16),
VERSION VARCHAR2(5) NOT NULL,
NAME VARCHAR2(40) NOT NULL,
TABLESPACE TAB_FILE,
PCTFREE 20,
PCTUSED 40,
INITRANS 6,
MAXTRANS 12,
STORAGE (INITIAL 1024K NEXT 1024K PCTINCREASE 0 MAXEXTENTS 8);
Is it useless (or not advisable) to write the parameters
PCTFREE,
PCTUSED,
INITRANS,
MAXTRANS and
STORAGE (INITIAL 1024K NEXT 1024K PCTINCREASE 0 MAXEXTENTS 8)
if I've written in the tablespace creation
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO?
Thanks a lot

I've read that autoallocate parameter is worse than uniform size:
"Note - there is an autoallocate option for LMTs that can be used instead of uniform size X. This still slices the file up into uniform chunks (in this case always at 64K), and uses one bit per chunk. However, instead of equating one chunk with one extent, Oracle will consider past history and available gaps to decide what size extent to allocate. The extent will be one of a limited set of sizes - 64K, 1MB, 8MB, 64MB. For relatively small, simple systems where there isn't much information available about proper sizing requirements, this can be a minimum fuss mechanism to adopt; but in general I believe you should stick with uniform sizing.......But why is it so convenient to force every extent in the tablespace to be the same size ? (And at this point, you may appreciate my earlier comment about avoiding autoallocate LMTs, which allow for half a dozen sizes of extents). First, ease of monitoring space; secondly, convenience of data packing, and third, reliability of object rebuilds. "
Is it right? If yes, could anyone tell me with size could be correct? Does it depend on the size of the table, for example? Is there any formula to get the uniform size?
Message was edited by:
user573997

Doubt about SYSTEM tablespaces

Sir,
While creating database can we specify SYSTEM tablespace as
'Locally Managed Autoallocate' and 'Segement Space Managemt Auto'
regards
Mathew

Sir,
Can we execute this command? My db version is 9.0.1.3.0
create database APSDB datafile 'd:\oradata\APSDB\system01.dbf' size 200m extent management local segment space management auto
undo tablespace UNDOTBS datafile 'd:\oradata\APSDB\undotbs01.dbf' size 100m
default temporary tablespace TEMP tempfile 'd:\oradata\APSDB\temp01.dbf' size 200m
logfile group 1 ('d:\oradata\APSDB\redolog1a.log','d:\oradata\APSDB\redolog1b.log') size 300k,
group 2 ('d:\oradata\APSDB\redolog2a.log','d:\oradata\APSDB\redolog2b.log') size 300k
regards
Mathew

How to move Tablespace from One disk group to another disk group in RAC

Hi All,
I have 11gR2 RAC env on Linux.
As ofnow I have problem with disk group. I have 3 disk group which is almost full - 98%. I have added one NEW disk group and want to move some of the Tablespace(TBS) from OLD disk group to NEW diskgroup and make some free space in OLD disk group.
Can any one suggest me how to move TBS from one disk group to another disk grup without shutting down the instance.
DB is in Noarchive mode.
Thanks...

user12039625 wrote:
Hi Helios,
Thanks for doc id but I am looking for noarchive mode solution. becaues I got ORA-
"ORA-01145: offline immediate disallowed unless media recovery enabled " when run alter database datafile '...' offline.
Hence I am trying something and findout below steps but not sure how useful it is:
1- put tablespace offine
2- Copy the file to new diskgroup using Either RMAN or DBMS_FILE_TRANSFER.
3- Rename the file to point to new location.
4- Recover the file.
5- Bring the file online.
I had move 240M TBS from OLE to NEW.
These steps run successfully so I think this is valid for noarchive mode.Hence want to confirm..so inform me please.
Thanks :)I have doubt in my mind:
1. You database is in noarchivelog mode
2. You're taking tablespace offline
3. Suppose you're moving a file of size 10GB(or any larger filesize) to another disk group
4. Now after moving the file, you're trying to bring the tablespace online............NOW
tablespace will need recovery. if the required data is inside the SGA then it is ok. But if the data has been flushed, then?
if step 2 and 3 has taken significant time, then most probably you'll not be able to bring that tablespace online.
Regards,
S.K.

To determine the amount of space currently used in each tablespace

I am preparing for OCA and came through a question.
QUESTION 389
You need to determine the amount of space currently used in each tablespace.
You can retrieve this information in a single SQL statement using only one DBA view in
the FROM clause providing you use either the _______ or _______ DBA view.
A. DBA_EXTENTS.
B. DBA_SEGMENTS.
C. DBA_DATA_FILES.
D. DBA_TABLESPACES.
Answer mentioned: A, C.
My doubt is that DBA_EXTENTS, DBA_SEGMENT,DBA_DATA_FILES all three contained column "BYTES" which shows size in bytes. Then why B is not an option.
Plz help.
Thanx
Ashutosh

Of these 4 answers, I'd say A and B will give the info asked for in the question.
DBA_DATA_FILES only tells you the file size. That's not of much value because it doesn't tell you how much space is consumed by objects (there may be none).
DBA_TABLESPACES has no storage info.
DBA_EXTENTS and SEGMENTS show the amount of space consumed by objects.
Even then, I'd say none of the above and use: DBA_TABLESPACE_USAGE_METRICS

How do i know if my query using SORT_AREA_SIZE   or temporary tablespace ?

Good Morning Everyone !
My DB version is 10.2.0.1
I have large table exactly 3 million records.
SQL> select count(*) from tab1;
COUNT(*)
   300000
SQL> select * from tab1 order by no DESC;
sorting ... in process
300000 rows selected.
in Terminal 2 : I tried to find sorting details -   ( No rows selected - why ? )
SQL> select USERNAME , USER , TABLESPACE , SQL_ID from v$tempseg_usage ;
no rows selected
SQL> /
no rows selected
When i google i have seen this ;
If Oracle cannot do the sort in memory (SORT_AREA_SIZE initialisation parameter), space will be allocated in a temporary tablespace for doing the sort operation.
REF_LINK : TEMPORARY Tablespaces and TEMPFILES | Oracle FAQ
MY DOUBT QUESTION :   How do i know if my query using SORT_AREA_SIZE or temporary tablespace ?
Thanks in advance.

@ JohnWatson
I have seen some articles from ORA - FAQ. Good.
SQL> select USERNAME , USER , TABLESPACE , SQL_ID from v$tempseg_usage;
USERNAME                       USER   TABLESPACE                      SQL_ID
   SCOTT                               SYS          TEMP                            fh9vqgyd6m0d1
PGA management means that sorting only 300000 rows may well occur in memory
            Is this (3 million rows) - standard value for 10g version ?
Thanks JohnWatson

DOUBT IN CRETAING DATAFILES

Hello,
i have one doubt in creating datafile if suppose i have created a TABLESPACE T1.
with DATAFILE X.
CREATE TABLESPACE T1 DATAFILE 'D:\ORACLE\ORADATA\ORCL\X1.DBF' SIZE 1024M
Now if suppose that i wan't to increase the tablespace size fot that i have two options
1.resize the existing datafile
or
2.Adding another datafile
my doubt is which is the best option in the above two
regards,
lakshmi

In your case, it doesn't matter you add a new datafile or increase the size to an existing datafile.
However, if the size of an existing datafile is notable high, it is better to add a new datafile.
As it will prevent single point failure and also increases your backup and recovery timing.
Jaffar

Tablespace level backup using data pump

Hi,
Im using 10.2.0.4 on RHEL 4,
I have one doubt, can we take a tablespace level backup using data pump,
bt i dnt wnt to use it for transportable tablespace.
thanks.

Yes, you can only for the tables in that tablespace only.
Use the TABLESPACES option to export list of tablespaces.*here all the tables in that tablespaces will be exported*.
and you must have the EXP_FULL_DATABASE role to use tablespace mode.
Have a look at this,
http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10825/dp_export.htm#i1007519
Thanks
Edited by: Cj on Dec 12, 2010 11:48 PM

Doubt about database point in time recovery using rman

Hi Everyone,
I have been practising various rman restore and recovery scenarios . I have a doubt regarding database point in time recovery using rman. Imagine i have a full database backup including controlfile scheduled to run at 10 PM everyday. today is 20th dec 2013. imagine i want to restore the database to a prior point in time ( say 18th dec till 8 AM). so i would restore all the datafiles from 17th night's backup and apply archives till 8 AM of 18th dec . in this scenario should i restore the controlfile too from 17th dec bkp ( i am assuming yes we should ) or can we use the current controlfile ( assuming it is intact). i found the below from oracle docs.
Performing Point-in-Time Recovery with a Current Control File
The database must be closed to perform database point-in-time recovery. If you are recovering to a time, then you should set the time format environment variables before invoking RMAN. The following are sample Globalization Support settings:
NLS_LANG = american_america.us7ascii
NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"
To recover the database until a specified time, SCN, or log sequence number:
After connecting to the target database and, optionally, the recovery catalog database, ensure that the database is mounted. If the database is open, shut it down and then mount it:
2. SHUTDOWN IMMEDIATE;
3. STARTUP MOUNT;
4.
Determine the time, SCN, or log sequence that should end recovery. For example, if you discover that a user accidentally dropped a tablespace at 9:02 a.m., then you can recover to 9 a.m.--just before the drop occurred. You will lose all changes to the database made after that time.
You can also examine the alert.log to find the SCN of an event and recover to a prior SCN. Alternatively, you can determine the log sequence number that contains the recovery termination SCN, and then recover through that log. For example, query V$LOG_HISTORY to view the logs that you have archived.
RECID      STAMP      THREAD#    SEQUENCE# FIRST_CHAN FIRST_TIM NEXT_CHANG
         1 344890611          1          1      20037 24-SEP-02      20043
         2 344890615          1          2      20043 24-SEP-02      20045
         3 344890618          1          3      20045 24-SEP-02      20046
Perform the following operations within a RUN command:
Set the end recovery time, SCN, or log sequence. If specifying a time, then use the date format specified in the NLS_LANG and NLS_DATE_FORMAT environment variables.
If automatic channels are not configured, then manually allocate one or more channels.
Restore and recover the database.
The following example performs an incomplete recovery until November 15 at 9 a.m.
RUN
SET UNTIL TIME 'Nov 15 2002 09:00:00';
# SET UNTIL SCN 1000;       # alternatively, specify SCN
# SET UNTIL SEQUENCE 9923; # alternatively, specify log sequence number
RESTORE DATABASE;
RECOVER DATABASE;
If recovery was successful, then open the database and reset the online logs:
5. ALTER DATABASE OPEN RESETLOGS;
I did not quiet understand why the above scenario is using current controlfile as the checkpoint scn in the current controlfile and the checkpoint scn in the datafile headers do not match after the restore and recovery. Thanks in Advance for your help.
Thanks
satya

Thanks for the reply ... but what about the checkpoint scn in the controlfile . my understanding is that unless the checkpoint scn in the controlfile and datafiles do not match the database will not open. so assuming the checkpoint scn in my current controlfile is 1500 and i want to recover my database till scn 1200. so the scn in the datafiles (which is 1200) is not not matching with the scn in the controlfile(1500). so will the database open in such cases.
Thanks
Satya

Doubt in Tablespaces

Similar Messages

Maybe you are looking for