Does rebuild of indexes uses temp tablespace or system tablespace?

Does rebuild of indexes uses temp tablespace or system tablespace?
If so why?

If you combine the answers from Aman and Burleson, they cover most of the picture.
When rebuilding an index, you may end up sorting a large amount of information. The sort may spill into the temporary tablespace - if you haven't configured your database and users properly, it is possible that the SYSTEM tablespace may be used for the temporary tablespace.
As the new copy of the index is built, it has to be built in the right place (tablespace), and the space used to build it will be marked as a temporary segment as the build takes place. When the build is complete, this temporary segment will take on the name of the origrinal index, and the original index will be re-badged as a temporary segment and dropped. (Again, you might see temporary segments in the SYSTEM tablespace if the index was originally in, or was rebuilt into, the SYSTEM tablespace).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Similar Messages

Temp usage in system tablespace

Hi
I have oracle 9i with dictionary managed tablespaces.
I have put a trigger to capture sql statement which cause temp errors.
Recently, I have found out that the below sql cause:
ORA-1652: unable to extend temp segment by 5394 in tablespace SYSTEM
select distinct i.*
from PREM i, Summ p
WHERE i.Contract_Branch_Id = p.Pol_Branch_Id
AND i.Product_Code = p.Product_Code
AND i.Contract_Pol_No = p.Pol_No
AND p.Transaction_Type = 'V23'
AND p.Accounting_Prd IN
(TO_NUMBER(TO_CHAR(ADD_MONTHS(SYSDATE, -1),'YYYYMM')), TO_NUMBER(TO_CHAR(SYSDATE, 'YYYYMM')))My question is, how come such a sql uses temp segments in System tablespace rather than normal temp tablespace ?

in sqlplus do the following
SET AUTOTRACE TRACEONLY EXPLAIN STATISTICS
select distinct i.*
from PREM i, Summ p
WHERE i.Contract_Branch_Id = p.Pol_Branch_Id
AND i.Product_Code = p.Product_Code
AND i.Contract_Pol_No = p.Pol_No
AND p.Transaction_Type = 'V23'
AND p.Accounting_Prd IN
(TO_NUMBER(TO_CHAR(ADD_MONTHS(SYSDATE, -1),'YYYYMM')), TO_NUMBER(TO_CHAR(SYSDATE, 'YYYYMM')))
post FORMATTED results back here

Rebuild the index form brtools ended with error

Dear all,
I am getting error in db13 Update Stats there error is
BR0884I Statistics collected for table: SAPDEV.TCX00, rows old/new: 24117/24117
BR0986W Index SAPDEV.TCX00~0 is unbalanced - please rebuild the index
I have try to rebuild for brtools
BR0656I Choice menu 354 - please make a selection
Rebuild indexes main menu
1 = Rebuild indexes
2 - Show indexes
3 - Show tablespaces
4 * Exit program
5 - Reset input values and segment infos
Standard keys: c - cont, b - back, s - stop, r - refr, h - help
BR0662I Enter your choice:
BR0280I BRSPACE time stamp: 2009-06-05 16.44.41
BR0663I Your choice: 'c'
BR0259I Program execution will be continued...
BR0280I BRSPACE time stamp: 2009-06-05 16.44.43
BR1039I Selecting information about tables and indexes...
BR0285I This function can take several seconds/minutes - be patient...
BR0280I BRSPACE time stamp: 2009-06-05 16.44.52
BR0814I Number of tables in schema of owner SAPDEV: 44138
BR0280I BRSPACE time stamp: 2009-06-05 16.44.58
BR0815I Number of indexes in schema of owner SAPDEV: 52801
BR0065E Tablespace TCX00~0 not found
BR0182E Checking parameter/option '-s -tablespace' failed
BR0669I Cannot continue due to previous warnings or errors - you can go back to repeat the last action
BR0280I BRSPACE time stamp: 2009-06-05 16.44.58
BR0671I Enter 'b[ack]' to go back, 's[top]' to abort:
Please suggest how to solve the probem
Regards,

Hi,
Please rebuild this index using the SAP report "RSANAORA". Go to SE38, and run this report and you can rebuild the indexes also.
With Regards,
Saurabh

Update Statistics and Rebuild of Indexes

Hi friends,
If I execute the Update statistics for a given table thru DB20 does it have any effect on the indexes of this table or is it necessary to rebuild the index using db02
Regards
Aliila

Updating Statistics does not rebuild index while in update states logs it will show you information regarding which indexes needs to be rebuiled which you can rebuild by brtools or executing rsanaora prg in se38.
Shivam

SYSTEM tablespace full

Hi,
I am new to Oracle database. Currently I am using Oracle 10g version 10.2.0.4. I noticed that the SYSTEM tablespace is 100%, may I know what's the impact to the database server? Will it slow down all the transactions to process?
Thanks.

Your car won't run fast or slow if your gas tank is completely full or half full! The tablespace being full or not completely full won't decide the performance of the database. Since the tablespace is System tablespace which is supposed to store the data dictionary, it being full may hinder the working of the database since there is no more space left the dictionary. But if you would purely do queries without doing any changes at all, those queries performance won't be determined from the tablespace, whichever it may be, being full or not being full.
That said, this is a rather wrong criteria to check the performance. If you want to check performance, first take a feedback from the users and than get a report using Statspack or AWR( if you have license for it) and see what does the report says. If you find anything wrong in it than only imagine it as an issue and try to fix it.
HTH
Aman....

Why does not my query use an index?

I have a table with some processed rows (state: 9) and some unprocessed rows (states: 0,1,2,3,4).
This table has over 120000 rows, but this number will grow.
Most of the rows are processed and most of them also contain a group id. Number of groups is relatively small (let's assume 20).
I would like to obtain the oldest some_date for every group. This values has to be outer joined to a on-line report (contains one row for each group).
Here is my set-up:
Tested on: 10.2.0.4 (Solaris), 10.2.0.1 (WinXp)
drop table t purge;
create table t(
id number not null primary key,
grp_id number,
state number,
some_date date,
pad char(200)
insert into t(id, grp_id, state, some_date, pad)
select level,
     trunc(dbms_random.value(0,20)),
        9,
        sysdate+dbms_random.value(1,100),
        'x'
from dual
connect by level <= 120000;
insert into t(id, grp_id, state, some_date, pad)
select level + 120000,
     trunc(dbms_random.value(0,20)),
        trunc(dbms_random.value(0,5)),
        sysdate+dbms_random.value(1,100),
        'x'
from dual
connect by level <= 2000;
commit;
exec dbms_stats.gather_table_stats(user, 'T', estimate_percent=>100, method_opt=>'FOR ALL COLUMNS SIZE 1');
Tom Kyte's printtab
==============================
TABLE_NAME                    : T
NUM_ROWS                      : 122000
BLOCKS                        : 3834I know, this could be easily solved by fast refresh on commit materialized view like this:
select
grp_id,
min(some_date),
from
t
where
state in (0,1,2,3,4)
grpup by
grp_id;+ I have to create log on (grp_id, some_date, state)
Number of rows with active state will be always relatively small. Let's assume 1000-2000.
So my another idea was to create a selective index. An index which would contain only data for rows with an active state.
Something like this:
create index fidx_active on t (
case state
    when 0 then grp_id
    when 1 then grp_id
    when 2 then grp_id
    when 3 then grp_id
    when 4 then grp_id
end,
case state
    when 0 then some_date
    when 1 then some_date
    when 2 then some_date
    when 3 then some_date
    when 4 then some_date
end) compress 1; so a tuple (group_id, some_date) is projected to tuple (null, null) when the state is not an active state and therefore it is not indexed.
We can save even more space by compressing 1st expression.
analyze index idx_grp_state_date validate structure;
select * from index_stats
@pr
Tom Kyte's printtab
==============================
HEIGHT                        : 2
BLOCKS                        : 16
NAME                          : FIDX_ACTIV
LF_ROWS                       : 2000 <-- we're indexing only active rows
LF_BLKS                       : 6 <-- small index: 1 root block with 6 leaf blocks
BR_ROWS                       : 5
BR_BLKS                       : 1
DISTINCT_KEYS                 : 2000
PCT_USED                      : 69
PRE_ROWS                      : 25
PRE_ROWS_LEN                  : 224
OPT_CMPR_COUNT                : 1
OPT_CMPR_PCTSAVE              : 0Note: @pr is a Tom Kyte's print table script adopted by Tanel Poder (I'm using Tanel's library) .
Then I created a query to be outer joined to the report (report contains a row for every group).
I want to achieve a full scan of the index.
select
case state -- 1st expression
    when 0 then grp_id
    when 1 then grp_id
    when 2 then grp_id
    when 3 then grp_id
    when 4 then grp_id
end grp_id,
min(case state --second expression
        when 0 then some_date
        when 1 then some_date
        when 2 then some_date
        when 3 then some_date
        when 4 then some_date
      end) as mintime
from t
where
case state --1st expression: at least one index column has to be not null
    when 0 then grp_id
    when 1 then grp_id
    when 2 then grp_id
    when 3 then grp_id
    when 4 then grp_id
end is not null
group by
case state --1st expression
    when 0 then grp_id
    when 1 then grp_id
    when 2 then grp_id
    when 3 then grp_id
    when 4 then grp_id
end;-------------
Doc's snippet:
13.5.3.6 Full Scans
A full scan is available if a predicate references one of the columns in the index. The predicate does not need to be an index driver. A full scan is also available when there is no predicate, if both the following conditions are met:
All of the columns in the table referenced in the query are included in the index.
At least one of the index columns is not null.
A full scan can be used to eliminate a sort operation, because the data is ordered by the index key. It reads the blocks singly.
13.5.3.7 Fast Full Index Scans
Fast full index scans are an alternative to a full table scan when the index contains all the columns that are needed for the query, and at least one column in the index key has the NOT NULL constraint. A fast full scan accesses the data in the index itself, without accessing the table. It cannot be used to eliminate a sort operation, because the data is not ordered by the index key. It reads the entire index using multiblock reads, unlike a full index scan, and can be parallelized.
You can specify fast full index scans with the initialization parameter OPTIMIZER_FEATURES_ENABLE or the INDEX_FFS hint. Fast full index scans cannot be performed against bitmap indexes.
A fast full scan is faster than a normal full index scan in that it can use multiblock I/O and can be parallelized just like a table scan.
So the question is: Why does oracle do a full table scan?
Everything needed is in the index and one expression is not null, but index (fast) full scan is not even considered by CBO (I did a 10053 trace)
| Id | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|   1 | HASH GROUP BY     |      |      1 |     85 |     20 |00:00:00.11 |    3841 |
|* 2 |   TABLE ACCESS FULL| T    |      1 |   6100 |   2000 |00:00:00.10 |    3841 |
Predicate Information (identified by operation id):
   2 - filter(CASE "STATE" WHEN 0 THEN "GRP_ID" WHEN 1 THEN "GRP_ID" WHEN 2
              THEN "GRP_ID" WHEN 3 THEN "GRP_ID" WHEN 4 THEN "GRP_ID" END IS NOT NULL)Let's try some minimalistic examples. Firstly with no FBI.
create index idx_grp_id on t(grp_id);
select grp_id,
       min(grp_id) min
from t
where grp_id is not null
group by grp_id;
| Id | Operation             | Name       | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads |
|   1 | HASH GROUP BY        |            |      1 |     20 |     20 |00:00:01.00 |     244 |    237 |
|* 2 |   INDEX FAST FULL SCAN| IDX_GRP_ID |      1 |    122K|    122K|00:00:00.54 |     244 |    237 |
Predicate Information (identified by operation id):
   2 - filter("GRP_ID" IS NOT NULL)This kind of output I was expected to see with FBI. Index FFS was used although grp_id has no NOT NULL constraint.
Let's try a simple FBI.
create index fidx_grp_id on t(trunc(grp_id));
select trunc(grp_id),
       min(trunc(grp_id)) min
from t
where trunc(grp_id) is not null
group by trunc(grp_id);
| Id | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|   1 | HASH GROUP BY     |      |      1 |     20 |     20 |00:00:00.94 |    3841 |
|* 2 |   TABLE ACCESS FULL| T    |      1 |   6100 |    122K|00:00:00.49 |    3841 |
Predicate Information (identified by operation id):
   2 - filter(TRUNC("GRP_ID") IS NOT NULL)Again, index (fast) full scan not even considered by CBO.
I tried:
alter table t modify grp_id not null;
alter table t add constraint trunc_not_null check (trunc(grp_id) is not null);I even tried to set table hidden column (SYS_NC00008$) to NOT NULL
It has no effect, FTS is still used..
Let's try another query:
select distinct trunc(grp_id)
from t
where trunc(grp_id) is not null
| Id | Operation             | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|   1 | HASH UNIQUE          |             |      1 |     20 |     20 |00:00:00.85 |     244 |
|* 2 |   INDEX FAST FULL SCAN| FIDX_GRP_ID |      1 |    122K|    122K|00:00:00.49 |     244 |
Predicate Information (identified by operation id):
   2 - filter("T"."SYS_NC00008$" IS NOT NULL)Here the index FFS is used..
Let's try one more query, very similar to the above query:
select trunc(grp_id)
from t
where trunc(grp_id) is not null
group by trunc(grp_id)
| Id | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|   1 | HASH GROUP BY     |      |      1 |     20 |     20 |00:00:00.86 |    3841 |
|* 2 |   TABLE ACCESS FULL| T    |      1 |    122K|    122K|00:00:00.49 |    3841 |
Predicate Information (identified by operation id):
   2 - filter(TRUNC("GRP_ID") IS NOT NULL)And again no index full scan..
So my next question is:
What are the restrictions which prevent index (fast) fullscan to be used in these scenarios?
Thank you very much for your answers.
Edited by: user1175494 on 16.11.2010 15:23
Edited by: user1175494 on 16.11.2010 15:25

I'll start off with the caveat that i'm no Johnathan Lewis so hopefully someone will be able to come along and give you a more coherent explanation than i'm going to attempt here.
It looks like the application of the MIN function against the case statement is confusing the optimizer and disallowing the usage of your FBI. I tested this against my 11.2.0.1 instance and your query chooses the fast full scan without being nudged in the right direction.
That being said, i was able to get this to use a fast full scan on my 10 instance, but i had to jiggle the wires a bit. I modified your original query slightly, just to make it easier to do my fiddling.
original (in the sense that it still takes the full table scan) query
with data as
select
    case state -- 1st expression
      when 0 then grp_id
      when 1 then grp_id
      when 2 then grp_id
      when 3 then grp_id
      when 4 then grp_id
    end as grp_id,
    case state --second expression
          when 0 then some_date
          when 1 then some_date
          when 2 then some_date
          when 3 then some_date
          when 4 then some_date
    end as mintime
from t
where
    case state --1st expression: at least one index column has to be not null
      when 0 then grp_id
      when 1 then grp_id
      when 2 then grp_id
      when 3 then grp_id
      when 4 then grp_id
    end is not null
and
    case state --second expression
          when 0 then some_date
          when 1 then some_date
          when 2 then some_date
          when 3 then some_date
          when 4 then some_date
    end is not null
select--+ GATHER_PLAN_STATISTICS
grp_id,
min(mintime)
from data
group by grp_id;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'allstats +peeked_binds'));
| Id | Operation        | Name | Starts | E-Rows | A-Rows |      A-Time   | Buffers |
|   1 | HASH GROUP BY        |       |      2 |      33 |       40 |00:00:00.07 |    7646 |
|* 2 |   TABLE ACCESS FULL| T       |      2 |      33 |     4000 |00:00:00.08 |    7646 |
Predicate Information (identified by operation id):
   2 - filter((CASE "STATE" WHEN 0 THEN "GRP_ID" WHEN 1 THEN "GRP_ID" WHEN 2
           THEN "GRP_ID" WHEN 3 THEN "GRP_ID" WHEN 4 THEN "GRP_ID" END IS NOT NULL AND
           CASE "STATE" WHEN 0 THEN "SOME_DATE" WHEN 1 THEN "SOME_DATE" WHEN 2 THEN
           "SOME_DATE" WHEN 3 THEN "SOME_DATE" WHEN 4 THEN "SOME_DATE" END IS NOT
           NULL))
modified version where we prevent the MIN function from being applied too early, by using ROWNUM
with data as
select
    case state -- 1st expression
      when 0 then grp_id
      when 1 then grp_id
      when 2 then grp_id
      when 3 then grp_id
      when 4 then grp_id
    end as grp_id,
    case state --second expression
          when 0 then some_date
          when 1 then some_date
          when 2 then some_date
          when 3 then some_date
          when 4 then some_date
    end as mintime
from t
where
    case state --1st expression: at least one index column has to be not null
      when 0 then grp_id
      when 1 then grp_id
      when 2 then grp_id
      when 3 then grp_id
      when 4 then grp_id
    end is not null
and
    case state --second expression
          when 0 then some_date
          when 1 then some_date
          when 2 then some_date
          when 3 then some_date
          when 4 then some_date
    end is not null
and rownum > 0
select--+ GATHER_PLAN_STATISTICS
grp_id,
min(mintime)
from data
group by grp_id;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'allstats +peeked_binds'));
| Id | Operation           | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|   1 | HASH GROUP BY           |            |      2 |     20 |     40 |00:00:00.01 |      18 |
|   2 |   VIEW                |            |      2 |     33 |   4000 |00:00:00.07 |      18 |
|   3 |    COUNT           |            |      2 |      |   4000 |00:00:00.05 |      18 |
|* 4 |     FILTER           |            |      2 |      |   4000 |00:00:00.03 |      18 |
|* 5 |      INDEX FAST FULL SCAN| FIDX_ACTIVE |      2 |     33 |   4000 |00:00:00.01 |      18 |
Predicate Information (identified by operation id):
   4 - filter(ROWNUM>0)
   5 - filter(("T"."SYS_NC00006$" IS NOT NULL AND "T"."SYS_NC00007$" IS NOT NULL))

Physical attributes for index on temp tables (using physical model)

I need create index on temp tables.
When I generate DDL, it includes physical attributes like ‘LOGGING NOCOMPRESS NOPARALLEL’.
I get error "ORA – 14451 (unsupported feature w/temporary tables)"
I’ve to use physical model in OSDM. How do I get rid of physical attributes in DDL for index?

Hi,
Thanks for reporting this problem.
You can remove the LOGGING clause by opening the Properties dialog for the Index in the Physical model and setting its Logging property to the blank option.
However it's not possible to suppress the NOCOMPRESS and NOPARALLEL at the moment.
I've logged a bug on this.
As a workaround, you could do a global edit on the DDL file to remove all instances of NOCOMPRESS and NOPARALLEL.
David

Cannot use system rollback segment for non-system tablespace 'TEMP

Hi everyone!
I encountered this error: "Cannot use system rollback segment for non-system tablespace 'TEMP"
So this is what I did to check if the undo stuffs are online.
SQL> select tablespace_name,status from dba_tablespaces;
TABLESPACE_NAME                STATUS
SYSTEM                         ONLINE
UNDO                           ONLINE
SYSAUX                         ONLINE
TEMP                           ONLINE
LARGEDATA                      ONLINE
LARGEINDEXES                   ONLINE
MEDIUMDATA                     ONLINE
MEDIUMINDEXES                  ONLINE
SMALLDATA                      ONLINE
SMALLINDEXES                   ONLINE
XSMALLDATA                     ONLINE
TABLESPACE_NAME                STATUS
XSMALLINDEXES                  ONLINE
XXSMALLTABS                    ONLINE
USERS                          ONLINE
CONVTABLES                     ONLINE
UNDO_02                        ONLINE
16 rows selected.
SQL> SELECT tablespace_name, sum((bytes/1024)/1024) free FROM DBA_FREE_SPACE gr
oup by tablespace_name;
TABLESPACE_NAME                      FREE
LARGEDATA                      18.3105469
SMALLDATA                        10.46875
SYSAUX                           106.5625
UNDO_02                            67.125
XXSMALLTABS                    13.0078125
CONVTABLES                     170.039063
MEDIUMDATA                             22
USERS                           37.265625
SYSTEM                             55.875
LARGEINDEXES                   30.5175781
XSMALLINDEXES                    17.34375
TABLESPACE_NAME                      FREE
UNDO                             546.9375
MEDIUMINDEXES                       33.25
SMALLINDEXES                    31.015625
XSMALLDATA                     23.6328125
15 rows selected.
SQL> select file#,status from v$datafile;
     FILE# STATUS
         1 SYSTEM
         2 ONLINE
         3 ONLINE
         4 ONLINE
         5 ONLINE
         6 ONLINE
         7 ONLINE
         8 ONLINE
         9 ONLINE
        10 ONLINE
        11 ONLINE
     FILE# STATUS
        12 ONLINE
        13 ONLINE
        14 ONLINE
        15 ONLINE
15 rows selected.
SQL> select segment_name, tablespace_name, initial_extent,status
2 from dba_rollback_segs;
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
SYSTEM                         SYSTEM                                 102400
ONLINE
_SYSSMU1$                      UNDO                                   131072
OFFLINE
_SYSSMU2$                      UNDO                                   131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU3$                      UNDO                                   131072
OFFLINE
_SYSSMU4$                      UNDO                                   131072
OFFLINE
_SYSSMU5$                      UNDO                                   131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU6$                      UNDO                                   131072
OFFLINE
_SYSSMU7$                      UNDO                                   131072
OFFLINE
_SYSSMU8$                      UNDO                                   131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU9$                      UNDO                                   131072
OFFLINE
_SYSSMU10$                     UNDO                                   131072
OFFLINE
_SYSSMU11$                     UNDO_02                                131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU12$                     UNDO_02                                131072
OFFLINE
_SYSSMU13$                     UNDO_02                                131072
OFFLINE
_SYSSMU14$                     UNDO_02                                131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU15$                     UNDO_02                                131072
OFFLINE
_SYSSMU16$                     UNDO_02                                131072
OFFLINE
_SYSSMU17$                     UNDO_02                                131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU18$                     UNDO_02                                131072
OFFLINE
_SYSSMU19$                     UNDO_02                                131072
OFFLINE
_SYSSMU20$                     UNDO_02                                131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU21$                     UNDO_02                                131072
OFFLINE
22 rows selected.How should I be bringing them online?
I tried this but didn't work for me.
SQL> alter rollback segment _SYSSMU1$ online;
alter rollback segment _SYSSMU1$ online
ERROR at line 1:
ORA-00911: invalid character
SQL> alter rollback segment '_SYSSMU1$' online;
alter rollback segment '_SYSSMU1$' online
ERROR at line 1:
ORA-02245: invalid ROLLBACK SEGMENT name
SQL> alter rollback segment _SYSSMU21$ online;
alter rollback segment _SYSSMU21$ online
ERROR at line 1:
ORA-00911: invalid character
SQL> alter rollback segment SYSSMU21$ online;
alter rollback segment SYSSMU21$ online
ERROR at line 1:
ORA-01534: rollback segment 'SYSSMU21$' doesn't exist
SQL> alter rollback segment '_SYSSMU21$' online;
alter rollback segment '_SYSSMU21$' online
ERROR at line 1:
ORA-02245: invalid ROLLBACK SEGMENT name
SQL> alter rollback segment "_SYSSMU21$" online;
alter rollback segment "_SYSSMU21$" online
ERROR at line 1:
ORA-30017: segment '_SYSSMU21$' is not supported in MANUAL Undo Management mode
SQL> ALTER SYSTEM SET UNDO_MANAGEMENT=AUTO SCOPE=SPFILE;
System altered.Should I be bringing every segment online separately? Please guide me.
Nith
Edited by: user645399 on Feb 23, 2011 2:52 PM

SQL> select segment_name, tablespace_name, initial_extent,status
2 from dba_rollback_segs;
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
SYSTEM                         SYSTEM                                 102400
ONLINE
_SYSSMU1$                      UNDO                                   131072
ONLINE
_SYSSMU2$                      UNDO                                   131072
ONLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU3$                      UNDO                                   131072
ONLINE
_SYSSMU4$                      UNDO                                   131072
ONLINE
_SYSSMU5$                      UNDO                                   131072
ONLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU6$                      UNDO                                   131072
ONLINE
_SYSSMU7$                      UNDO                                   131072
ONLINE
_SYSSMU8$                      UNDO                                   131072
ONLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU9$                      UNDO                                   131072
ONLINE
_SYSSMU10$                     UNDO                                   131072
ONLINE
_SYSSMU11$                     UNDO_02                                131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU12$                     UNDO_02                                131072
OFFLINE
_SYSSMU13$                     UNDO_02                                131072
OFFLINE
_SYSSMU14$                     UNDO_02                                131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU15$                     UNDO_02                                131072
OFFLINE
_SYSSMU16$                     UNDO_02                                131072
OFFLINE
_SYSSMU17$                     UNDO_02                                131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU18$                     UNDO_02                                131072
OFFLINE
_SYSSMU19$                     UNDO_02                                131072
OFFLINE
_SYSSMU20$                     UNDO_02                                131072
OFFLINE
SEGMENT_NAME                   TABLESPACE_NAME                INITIAL_EXTENT
STATUS
_SYSSMU21$                     UNDO_02                                131072
OFFLINEStill undo_02's segments are offline.

Quaries using temp tablespace

Dear all,
Is there any script which gives the
list of quaries which heavily uses temp tablespace.Because my temp tablespace size is 32 gb , some times usage will go till 28gb , and it will reset to 0,
i need to know what quary it is running when the usage is at 28 gb.
Please help me regard this,
Regards,
Vamsi.

Check with below query.
SELECT
b.tablespace tablespace_name
, a.username username
, a.sid sid
, a.serial# serial_id
, b.contents contents
, b.segtype segtype
, b.extents extents
, b.blocks blocks
, (b.blocks * c.value) bytes
FROM
v$session a
, v$sort_usage b
, (select value from v$parameter
where name = 'db_block_size') c
WHERE
a.saddr = b.session_addr
========= output =======================
Tablespace Name Username SID Serial# Contents Segment Type Extents Blocks Bytes
TEMP SYS 128 9 TEMPORARY LOB_DATA 1 128 1,048,576
SYS 137 1 TEMPORARY DATA 1 128 1,048,576
sum 2 256 2,097,152

My iphoto 09 keeps on downloading duplicates to a temp folder without asking when I drag a photo from firefox over to iphoto to import it. It does not happen when using safari. can some one please help?

My iphoto 09 keeps on downloading duplicates to a temp folder without asking when I drag a photo from firefox over to iphoto to import it. It does not happen when using safari. can some one please help?

You're in the wrong forum. Post to iPhoto for iLife, not iPhoto for iOS.

Reasons to use separate temp tablespace for user tablespace

Hi,
I know that guideline says is not use system tablespace for user tables. But need i create for user tablespace separate TEMP teblespace or i can use same TEMP tablespace for all tablespaces?

Hi,
>>But need i create for user tablespace separate TEMP tablespace or i can use same TEMP tablespace for all tablespaces?
You can use one temp tablespace for a database , Temp tablespace usage are for sorting the data.
for more detail you can go with :Creating Tablespaces
HTH

Does BI 7.0 use bit map join indexes?

I have seen several threads on SDN which show that SAP BI is using bit map indexes with Oracle database. However, it is not clear whether BI utilizes bit map join indexes or just bit map index. Bit map index is on a single table whereas bitmap join index is on a join of two or more tables.
It will make sense for SAP BI to use bit map join indexes with star transformations where a join is done among fact and dimension tables.

> Thanks. Another question, are bit map indexes used both for F and E fact tables or just for F. I am not using real-time cubes (where SAP BI uses B-Tree indexes for F table to avoid dead locks).
Why don't you simply check this in your BI system yourself?
And, yes, of course it uses bitmap indexes for both fact table types.
E-fact tables are the same as F-Facttables except that they contain the compressed/rolled up data.
regards,
Lars

Error When Creating OR Rebuilding Oracle Text index using Lexer Keyword

Hi All,
I am getting following error when i creating oracle text index using lexer & stoplist keyword.
Pls Help me if any body know.
Thanks in Advance.
Error starting at line 1 in command:
CREATE INDEX TXT_INX_TEXT_SEARCH ON TEXT_SEARCH (BFILE_DOC)
Post INDEXTYPE IS "CTXSYS"."CONTEXT" LOCAL (
PARTITION "BEFORE_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)') ,
PARTITION "Q1_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q2_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q3_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q4_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q1_2008" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q2_2008" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q3_2008" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q4_2008" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q1_2009" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q2_2009" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q3_2009" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q4_2009" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "THE_REST" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)')
Error at Command Line:1 Column:13
Error report:
SQL Error: ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: Oracle Text error:
DRG-11000: invalid keyword LEXER
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 365
29855. 00000 - "error occurred in the execution of ODCIINDEXCREATE routine"
*Cause: Failed to successfully execute the ODCIIndexCreate routine.
*Action: Check to see if the routine has been coded correctly.
Regards,
Jack R.

Hi,
it works if you put an extra PARAMETERS clause at the end so the creation looks like:
CREATE INDEX TXT_INX_TEXT_SEARCH ON TEXT_SEARCH (BFILE_DOC)
INDEXTYPE IS "CTXSYS"."CONTEXT" LOCAL (
PARTITION "BEFORE_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)') ,
PARTITION "Q1_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q2_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q3_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q4_2007" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q1_2008" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q2_2008" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q3_2008" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q4_2008" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q1_2009" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q2_2009" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q3_2009" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "Q4_2009" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)'),
PARTITION "THE_REST" PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)')
PARAMETERS ('LEXER dd_lexer STOPLIST dd_stoplist SYNC (ON COMMIT)') <== Added
Hope this helps
Herald ten Dam

Error while rebuilding the index

HI
can any one help me with this.
while i am trying to drop and rebuild an index i got the error like...
ORA-01652: unable to extend temp segment by 8091 in tablespace SYSTEM
what have to be done....
Thanks in advance...

user8884944 wrote:
HI
can any one help me with this.
while i am trying to drop and rebuild an index i got the error like...
ORA-01652: unable to extend temp segment by 8091 in tablespace SYSTEM
what have to be done....
Thanks in advance...It wasn't the direct cause of your error, but what were you doing trying to build an index in the SYSTEM tablespace?
As for the error itself
http://lmgtfy.com/?q=ORA-01652

How much time it take to rebuild an index for a table with 20 millions rows

Hi all,
i need to rebuild the index of a table containing 20 000 000 row (i don't know why the other people working on this didn't think of rebuilding the index regularly, because i asked and apparently it has never been done :cry: :cry:) i am not a sql developper nor a DBA so i can't mesure how long it take to rebuild the index, does any one have an idea (aproximativly of course :aie:), the other question is there any formula to use in order to calculate how often to rebuild the indexes (i can for example retieve how much rows are delated or inserted daily ...)
Thanks again
Taha

taha wrote:
:aie: that's why i am asking because i don't know (and to be sure which solution is best)
so the table is like this (the columns) :
45 varchar2, 5 timestamp, 30 Number no LOB columns, (15 indexes : 5 unique indexes and that those indexes uses at a maximum 4 columns)15 indexes - 100,000 deletes: this could mean 1,500,000 block visits to maintain index leaf blocks as the table rows are deleted. If you're unlucky this could turn into 1,500,000 physical block read requests; if you're lucky, or the system is well engineered this could be virtually no physical I/O. The difference in time could be huge. At any rate it is likely to be 1,500,000 redo entries at 250 - 300 bytes per entry for a total of about 400MB of redo (so how large are your redo logs and how many log switches are you going to cause).
yes the tables is used by an application so (update, insert ) can take place at any time
for the deletion , there is the batch which does a mass delete on the table ( 4 or 5 time each day)
You haven't answered the question - how long does it take to do a sample batch delete.
If you can enable SQL tracing, or take a before/after snapshot of v$sesstat or v$session_event for the session as it does the delete then you can get some idea of where the time is going - for all you know it might be spending most of its time waiting for a lock to do away.
>
"How many leaf blocks are currently allocated to the index(es) ?" how can i answer to this question ? may be if i check the all_objects table ?
If you keep your statistics up to date then dba_indexes is a good place, cross-checked with dba_segments, and you can use the dbms_space package for more detail. I have a code sample on my blog which allows you to compare the current size of your indexes with the size they would be if rebuilt at some specific percentage: http://jonathanlewis.wordpress.com/index-sizing/ (It's such good code that Oracle Corp. has copied it into MOS note 989186.1)
Regards
Jonathan Lewis

Does rebuild of indexes uses temp tablespace or system tablespace?

Similar Messages

Maybe you are looking for