Create an index on a huge table

hi gurus
I am going to create an index on a very large table(194GB) with the temporary tablespace size is 80G.
I am afraid that during the index creation the temporary tablespace is not enouth to hold the data needed
to create the index,because i only have 80g in temporary tablespace. How do i estimated the size i need to create a such large index and is there an effcient way to do such index creation?
thank u in advance.

Jozsef wrote:
Hi there,
I have done similar things couple of times before and I have used a pretty good method to obtain a rough (and it was really a rough, but enough) estimation.
Sorry folks, it does not work properly for create index...this method only works for SELECT statments, SO IGNORE IT :(
It nearly works in 10g:
| Id | Operation              | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | CREATE INDEX STATEMENT |       | 10000 | 40000 |    10   (0)| 00:00:01 |
|   1 | INDEX BUILD NON UNIQUE| T1_I1 |       |       |            |          |
|   2 |   SORT CREATE INDEX    |       | 10000 | 40000 |            |          |
|   3 |    TABLE ACCESS FULL   | T1    | 10000 | 40000 |     6   (0)| 00:00:01 |
Note
   - estimated index size: 196K bytesThe "Note" tells you Oracle's estimate of the final space allocation needed for the index. There are various reasons why the estimate is not very accurate, and why it's not a good estimate of the space requirement in the TEMP tablespace, but it gives you a figure that is probably in the right ballpark (factor of 2 out, either way, probably).
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"For every expert there is an equal and opposite expert."
Arthur C. Clarke

Similar Messages

Creating an INDEX on an internal table

Hi Folks,
Currently I am dealing with some programs which needs to be optimised.I had came acrossed some queries which are having some fields in the where clause which are neither a primary key nor in any index.As it is not advisable to create as many index as we can in a standard table,I just want to create an index on the internal table.
Will be glad if anyone here can provide me some lead in this.
Thanks,
K.Kiran.

Hi,
There is no need to create the index in the internal table since the primary key of the database table from which you selected the data becomes Primary index for the internal table.
The primary index is distinguished from the secondary indexes of a table. The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database
You can also create further indexes on a table in the ABAP Dictionary. These are called secondary indexes. This is necessary if the table is frequently accessed in a way that does not take advantage of the sorting of the primary index for the access.
You create secondary indexes using the ABAP Dictionary. There you can create its columns and define it as UNIQUE. However, you should not create secondary indexes to cover all possible combinations of fields.
Only create one if you select data by fields that are not contained in another index, and the performance is very poor. Furthermore, you should only create secondary indexes for database tables from which you mainly read, since indexes have to be updated each time the database table is changed. As a rule, secondary indexes should not contain more than four fields, and you should not have more than five indexes for a single database table.
Secondary indexes should contain columns that you use frequently in a selection, and that are as highly selective as possible. The fewer table entries that can be selected by a certain column, the higher that columns selectivity. Place the most selective fields at the beginning of the index. Your secondary index should be so selective that each index entry corresponds to, at most, five percent of the table entries. If this is not the case, it is not worth creating the index. You should also avoid creating indexes for fields that are not always filled, where their value is initial for most entries in the table.
Regards,
Priyanka.

Create Index on a huge table

Hi,
We have a huge table and there is no index on this table, I want to create index on this table, we are working on Oracle 11g/Linux.
Our business users are frequently accessing this table and select statement taking very long time.
Please let me know which index type would be best suited for this and what would the command to create index on it.
Would appreciate your assistance.
Regards.

>
We have a huge table and there is no index on this table, I want to create index on this table, we are working on Oracle 11g/Linux.
Our business users are frequently accessing this table and select statement taking very long time.
Please let me know which index type would be best suited for this and what would the command to create index on it.
>
We need loads of information to suggest anything useful
a) What database version is yours? (if 11g, you have good more options)
b) What type of environment is it? OLTP or Warehouse?
c) How big is the table?
d) How many distinct values are there in that column that you want to index?
e) Would this index undergo lots of inserts/deletes/updates? That is, is this table used mainly for querying or will it undergo continous inserts/updates/deletes?
In case your environment is warehouse type where you load once and then mainly used for queries and more importantly, if that column has very few distinct columns (typical example is a GENDER column where you have only two distinct values), you will be largely benefitted from BITMAP index. If it's an OLTP environment where multiple processes will be inserting into the table, you never ever go near BITMAP index but do only B-Tree index.
Finally, have you arrived at a concrete reason on why you want to build that index now rather than when you designed the table? If you don't need an index for sure, better not have it. If you are on 11g, you can have INVISIBLE index.
Also, if it's a very large table, you may create the index nologging to avoid loads of redo generation (not recommended on production environment though). But you have to be aware that in the event of disaster recovery you will have to recreate the index after you restore the database. Also if you are on Dataguard environment, you have to take necessary precautions while doing NOLOGGING operations.
Edited by: user12035575 on Sep 11, 2011 12:37 PM

Create/drop index on a busy table

Hello,
It's kind-a of a funny question but how do you create or drop a index on a very busy table? (by making the users wait...)
I tried:
lock table <table> in exclusive mode
then in another session (session2)
update <table> set col1 = 'a';
(this session now waits)
then back a the first session:
create index bla on <table> (col1);
And what happens is that the lock is released immediatelly, and in session2 the update updates and I get the standard "RESOURCE BUSY" error.
Any ideas on how to do that ?
Thanks

Jozsef wrote:
Hi there,
I have done similar things couple of times before and I have used a pretty good method to obtain a rough (and it was really a rough, but enough) estimation.
Sorry folks, it does not work properly for create index...this method only works for SELECT statments, SO IGNORE IT :(
It nearly works in 10g:
| Id | Operation              | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | CREATE INDEX STATEMENT |       | 10000 | 40000 |    10   (0)| 00:00:01 |
|   1 | INDEX BUILD NON UNIQUE| T1_I1 |       |       |            |          |
|   2 |   SORT CREATE INDEX    |       | 10000 | 40000 |            |          |
|   3 |    TABLE ACCESS FULL   | T1    | 10000 | 40000 |     6   (0)| 00:00:01 |
Note
   - estimated index size: 196K bytesThe "Note" tells you Oracle's estimate of the final space allocation needed for the index. There are various reasons why the estimate is not very accurate, and why it's not a good estimate of the space requirement in the TEMP tablespace, but it gives you a figure that is probably in the right ballpark (factor of 2 out, either way, probably).
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"For every expert there is an equal and opposite expert."
Arthur C. Clarke

Can we create secondary index for a cluster table

hi
can we create secondary index for a cluster table

Jyothsna,
There seems to be some kind of misunderstanding here. You <i>cannot</i> create a secondary index on a cluster table. A cluster table does not exist as a separate physical table in the database; it is part of a "physical cluster". In the case of BSEG for instance, the physical cluster is RFBLG. The only fields of the cluster table that also exist as fields of the physical cluster are the leading fields of the primary key. Taking again BSEG as the example, the primary key includes the fields MANDT, BUKRS, BELNR, GJAHR, BUZEI. If you look at the structure of the RFBLG table, you will see that it has primary key fields MANDT, BUKRS, BELNR, GJAHR, PAGENO. The first four fields are those that all cluster tables inside BSEG have in common. The fifth field, PAGENO, is a "technical" field giving the sequence number of the current record in the series of cluster records sharing the same primary key.
All the "functional" fields of the cluster table (for BSEG this is field BUZEI and everything beyond that) exist only inside a raw binary object. The database does not know about these fields, it only sees the raw object (the field VARDATA of the physical cluster). Since the field does not exist in the database, it is impossible to create a secondary index on it. If you try to create a secondary index on a cluster table in transaction SE11, you will therefore rightly get the error "Index maintenance only possible for transparent tables".
Theoretically you could get around this by converting the cluster table to a transparent table. You can do this in the SAP dictionary. However, in practice this is almost never a good solution. The table becomes much larger (clusters are compressed) and you lose the advantage that related records are stored close to each other (the main reason for having cluster tables in the first place). Apart from the performance and disk space hit, converting a big cluster table like BSEG to transparent would take extremely long.
In cases where "indexing" of fields of a cluster table is worthwhile, SAP has constructed "indexing tables" around the cluster. For example, around BSEG there are transparent tables like BSIS, BSAS, etc. Other clusters normally do not have this, but that simply means there is no reason for having it. I have worked with the SAP dictionary for over 12 years and I have never met a single case where it was necessary to convert a cluster to transparent.
If you try to select on specific values of a non-transparent field in a cluster without also specifying selections for the primary key, then the database will have to do a serial read of the whole physical cluster (and the ABAP DB interface will have to decompress every single record to extract the fields). The performance of that is monstrous -- maybe that was the reason of your question. However, the solution then is (in the case of BSEG) to query via one of the index tables (where you are free to create secondary indexes since those tables are transparent).
Hope this clarifies things,
Mark

Index on a huge table

there is a table which has 6844153 rows, i am trying to create an index on 3 columns on that table, it is taking forever..please advice

it is taking foreverHow long is "forever"...really.
Since your table is not very large, I would think it should complete in minutes, not hours (only a guess of course, I don't know your hardware or environment).
Or...creating an index needs to lock the table. Maybe some other session has it locked already and you're just sitting and waiting.

HOW TO CREATE LOCAL INDEX ON BIG PARTITION TABLE

Dear All,
I have one big table 450GB stored on 9 partitions and same partitions I have created for the index. Now the problem is when i am trying to create local index it took one and half day and is still going on...
is there any shortest way to create local index on this table easily.
Database version is 11.2.0.1.0
INDEX SCRIPT IS
CREATE INDEX INDEX_SPACE0_IX_LOCAL ON FINANCE (END_TIME)
INITRANS 2 MAXTRANS
255
LOCAL ( PARTITION INDEX_SPACE01
LOGGING
NOCOMPRESS
TABLESPACE INDEX_SPACE01
PCTFREE 5 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 1M MINEXTENTS 1 MAXEXTENTS
2147483645 BUFFER_POOL
DEFAULT), PARTITION INDEX_SPACE02
LOGGING
NOCOMPRESS
TABLESPACE INDEX_SPACE02 PCTFREE
5 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 1M MINEXTENTS 1 MAXEXTENTS
2147483645 BUFFER_POOL DEFAULT),
PARTITION INDEX_SPACE03
LOGGING
NOCOMPRESS
TABLESPACE
INDEX_SPACE03
PCTFREE 5 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 1M MINEXTENTS 1 MAXEXTENTS
2147483645 BUFFER_POOL DEFAULT),
PARTITION INDEX_SPACE04
LOGGING
NOCOMPRESS
TABLESPACE
INDEX_SPACE04 PCTFREE 5 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 1M MINEXTENTS
1 MAXEXTENTS
2147483645 BUFFER_POOL DEFAULT),
PARTITION INDEX_SPACE05
LOGGING
NOCOMPRESS
TABLESPACE
INDEX_SPACE05 PCTFREE 5 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 1M MINEXTENTS
1 MAXEXTENTS 2147483645 BUFFER_POOL DEFAULT),
PARTITION INDEX_SPACE06
LOGGING
NOCOMPRESS
TABLESPACE INDEX_SPACE06 PCTFREE 5 INITRANS 2
MAXTRANS 255 STORAGE (INITIAL 1M MINEXTENTS 1 MAXEXTENTS 2147483645 BUFFER_POOL
DEFAULT),
PARTITION INDEX_SPACE07
LOGGING
NOCOMPRESS
TABLESPACE INDEX_SPACE07 PCTFREE
5 INITRANS 2
MAXTRANS 255 STORAGE (INITIAL 1M MINEXTENTS 1 MAXEXTENTS 2147483645 BUFFER_POOL
DEFAULT),
PARTITION INDEX_SPACE08
LOGGING
NOCOMPRESS
TABLESPACE INDEX_SPACE08 PCTFREE
5 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 1M MINEXTENTS 1 MAXEXTENTS
2147483645
BUFFER_POOL DEFAULT),
PARTITION INDEX_SPACE09
LOGGING
NOCOMPRESS
TABLESPACE
INDEX_SPACE09 PCTFREE 5 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 1M MINEXTENTS
1 MAXEXTENTS 2147483645 BUFFER_POOL
DEFAULT))
NOPARALLEL;
Thanks in advance......
Thanks,
Edited by: sherkhan on Aug 24, 2011 3:36 AM
Edited by: sherkhan on Aug 24, 2011 3:49 AM

Have you verified that 'n' Index partition segments have got created so far ? (they would apepar as TEMPORARY segments only till the full index creation is completed). Have you monitored the session statistics and waits and confirmed that it is not waiting on something horrible ?
A CREATE INDEX can well be NOLOGGING instead of LOGGING. It could also use PARALLEL but I always recommend setting it back to NOPARALLEL immediately after the CREATE is completed.
You can also "quickly" build an empty index and then gradually create (i.e. build) each partition
CREATE INDEX INDEX_SPACE0_IX_LOCAL ......... UNUSABLE ;
ALTER INDEX INDEX_SPACE0_IX_LOCAL REBUILD PARTITION PARTITION INDEX_SPACE01;
ALTER INDEX INDEX_SPACE0_IX_LOCAL REBUILD PARTITION PARTITION INDEX_SPACE02;
...Hemant K Chitale

Procedure for creating an Index on SAP standard table

Hi,
I need to create an Index on a SAP standard table. Please help me out with the process of doing so.
Regards,
Sharadendu

Please search the forum. You will find lots of related threads:
how to create an index
how to create secondary index

Impossible to create an index with an object table

Is it possible to use object tables with Oracle Spatial ?
With Oracle 8.1.7.0.0, here is the example where I encounter a problem (this example works of course with an equivalent relational table) :
create or replace type zonegeo as object (
id integer, definitionGeo MDSYS.SDO_GEOMETRY
create table essaigeo of zonegeo (id PRIMARY KEY)
OBJECT ID PRIMARY KEY;
INSERT INTO USER_SDO_GEOM_METADATA
VALUES ('ESSAIGEO','DEFINITIONGEO',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', 47680.000, 1197822.000, 0.005),
MDSYS.SDO_DIM_ELEMENT('Y', 1620431.000, 2677441.000, 0.005)
NULL -- SRID
CREATE INDEX ESSAIGEO_SPATIAL_IDX
ON ESSAIGEO(DEFINITIONGEO)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('SDO_LEVEL = 6);
ERREUR ` la ligne 1 :
ORA-29855: erreur d'exicution de la routine ODCIINDEXCREATE
ORA-13203: ichec de lecture de la table USER_SDO_GEOM_METADATA
ORA-13203: ichec de lecture de la table USER_SDO_GEOM_METADATA
ORA-06512: ` "MDSYS.SDO_INDEX_METHOD", ligne 8
ORA-06512: ` ligne 1

In Oracle 8.1.7 you cannot embed a geometry type in another type and index it.
In 9i, you can , but not in the way you've defined it, i.e. you have to create a regular
table, and have a column of type zonegeo, and make a few other changes, i.e.:
create or replace type zonegeo as object (
id integer, definitionGeo MDSYS.SDO_GEOMETRY
create table essaigeo (zone zonegeo);
INSERT INTO USER_SDO_GEOM_METADATA
VALUES ('ESSAIGEO','ZONE.DEFINITIONGEO',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', 47680.000, 1197822.000, 0.005),
MDSYS.SDO_DIM_ELEMENT('Y', 1620431.000, 2677441.000, 0.005)
NULL -- SRID
CREATE INDEX ESSAIGEO_SPATIAL_IDX
ON ESSAIGEO(ZONE.DEFINITIONGEO)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('SDO_LEVEL = 6);

Bitmap index or Composite index better on a huge table

Hi All,
I got a question regarding the Bitmap index and Composite Index.
I got a table which has got only two colums CUSTOMER(group_no NUMBER, order_no NUMBER)
This is a 100Million+ record table and here I got 100K Group_nos and and unique 100Million order numbers. I.E Each group should have 1000 order numbers.
I tested by creating a GLOBAL Bitmap index on this huge table(more than 1.5gb in size) and the GLOBAL Bitmap index that got created is under 50MB and when I query for a group number say SELECT * FROM CUSTOMER WHERE group_no=67677; --> 0.5 seconds to retrive all the 1000 rows. I checked for different groups and it is the same.
Now I dropped the BitMap Index and re-created a Composite index on( group_no and order_no). The index size more than the table size and is around 2GB in size and when I query using the same select statment SELECT * FROM CUSTOMER WHERE group_no=67677; -->0.5 seconds to retrive all the 1000 rows.
My question is which one is BETTER. BTree or BITMAP Index and WHY?
Appreciate your valuable inputs on this one.
Regars,
Madhu K.

Dear,
Hi All,
I got a question regarding the Bitmap index and Composite Index.
I got a table which has got only two colums CUSTOMER(group_no NUMBER, order_no NUMBER)
This is a 100Million+ record table and here I got 100K Group_nos and and unique 100Million order numbers. I.E Each group should have 1000 order numbers.
I tested by creating a GLOBAL Bitmap index on this huge table(more than 1.5gb in size) and the GLOBAL Bitmap index that got created is under 50MB and when I query for a group number say SELECT * FROM CUSTOMER WHERE group_no=67677; --> 0.5 seconds to retrive all the 1000 rows. I checked for different groups and it is the same.
Now I dropped the BitMap Index and re-created a Composite index on( group_no and order_no). The index size more than the table size and is around 2GB in size and when I query using the same select statment SELECT * FROM CUSTOMER WHERE group_no=67677; -->0.5 seconds to retrive all the 1000 rows.
My question is which one is BETTER. BTree or BITMAP Index and WHY?
Appreciate your valuable inputs on this one.First of all, bitmap indexes are not recommended for write intensive OLTP applications due to the locking threat they can produce in such a kind of applications.
You told us that this table is never updated; I suppose it is not deleted also.
Second, bitmap indexes are suitable for columns having low cardinality. The question is how can we define "low cardinality", you said that you have 100,000 distincts group_no on a table of 100,000,000 rows.
You have a cardinality of 100,000/100,000,000 =0,001. Group_no column might be a good candidate for a bitmap index.
You said that order_no is unique so you have a very high cardinality on this column and it might not be a candidate for your bitmap index
Third, your query where clause involves only the group_no column so why are you including both columns when testing the bitmap and the b-tree index?
Are you designing such a kind of index in order to not visit the table? but in your case the table is made only of those two columns, so why not follow Hermant advise for an Index Organized Table?
Finally, you can have more details about bitmap indexes in the following richard foot blog article
http://richardfoote.wordpress.com/2008/02/01/bitmap-indexes-with-many-distinct-column-values-wotsuh-the-deal/
Best Regards
Mohamed Houri

How can I create index(uniqie index) for a existed table?

Hi guys,
I want to create a index for a existed table, it should be unique index. I did it using se11, "indexes," and select the radio button "unqiue index", of course the fields as well. But when I activate it, I get a waring and therefore can not create this index. But if I select radio button "non-uniqe index", it works.
However I have to reate a unqiue index.
How can I do it?
Thanks in advance
Regards,
Liying

HI Wang
You can create your index via SE11, enter the table name, click change, choose Go To, Indexes. Here create your index with the key fields that you want. To use the index, your select statement WHERE clause, you must have the key fields of the index in the order that they appear in the index. The "optimizer" will choose the index depending on your fields of the WHERE clause.
One thing to remember is that when you create indexes for tables, the update or insert of these tables may have a slower response then before, I for one have never seen a big problem as of yet.
this Document may help u on primary and secondary indexes :
http://jdc.joy.com/helpdata/EN/cf/21eb20446011d189700000e8322d00/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eb47446011d189700000e8322d00/content.htm
If it helps Reward the points
Regards,
Rk
Message was edited by:
Rk Pasupuleti

One can create an index on a non-existent column in a table

I am using Oracle 10.2.0.3 on Windows 2003. I wanted to create an index on columnb of
Tablea. When I use statement like:
Create index index1 on tablea (‘columnb’) …
Oracle created index: index1. However, when I looked tat the column in user_ind_columns it had some weird colculn like SYS_NCxxxx. For sometime, I had
No idea what was going on. My index was not being used in queries at all. Then it dawned on me that I should not put single quotes around columnb. Once I removed quotes, things worked as expected.
But why does Oracle allow index on a non-existent column?

we cannot create the index on nonexistent column of table We can. Its called a function-based index. Here's how we do it.
Also read Howard's reply, right above yours.
SQL> desc t
Name                                      Null?    Type
OWNER                                     NOT NULL VARCHAR2(30)
OBJECT_NAME                               NOT NULL VARCHAR2(30)
SUBOBJECT_NAME                                     VARCHAR2(30)
OBJECT_ID                                 NOT NULL NUMBER
DATA_OBJECT_ID                                     NUMBER
OBJECT_TYPE                                        VARCHAR2(19)
CREATED                                   NOT NULL DATE
LAST_DDL_TIME                             NOT NULL DATE
TIMESTAMP                                          VARCHAR2(19)
STATUS                                             VARCHAR2(7)
TEMPORARY                                          VARCHAR2(1)
GENERATED                                          VARCHAR2(1)
SECONDARY                                          VARCHAR2(1)
SQL> create index t_idx on t( substr(object_name, 1, 5));
Index created.
SQL> select column_name from user_ind_columns where index_name = 'T_IDX';
COLUMN_NAME
SYS_NC00014$
SQL> select index_type from user_indexes where index_name = 'T_IDX';
INDEX_TYPE
FUNCTION-BASED NORMAL
SQL>

Problem creating index on global temporary table

Running Oracle DB Oracle9i Release 9.2.0.7.0.
I'm trying to create 3 indexes on a temporary table, the first index creates fine but the other remaining 2 result in the following error:
ERROR at line 1: ORA-00600: internal error code, arguments: [kftts2bz_many_files], [0], [20], [], [], [], [], []
Have tried searching with not much success, any pointers, tips, hints would be appreciated, below is the table and the indexes:-
create global temporary TABLE contacts (
ID VARCHAR2(20) NOT NULL,
DOB VARCHAR2(8),
HH_LASTNAME VARCHAR2(90),
PERSON VARCHAR2(10) NOT NULL,
CONT_JOB VARCHAR2(90) NOT NULL,
SOURCE VARCHAR2(8) NOT NULL,
ADS VARCHAR2(8) NOT NULL,
CONT VARCHAR2(8) NOT NULL,
SRCPERSONID VARCHAR2(15),
FIRSTNAME VARCHAR2(90),
MIDDLENAME VARCHAR2(90),
LASTNAME VARCHAR2(90),
FULLNAME VARCHAR2(90),
TITLE VARCHAR2(50),
SALUTATION VARCHAR2(90),
) on commit delete rows;
create index i_contact_1 on contacts(dob, soundex(hh_lastname ));
create index i_contact_pk on contacts(id, person, cont_job, source, ads, cont);
create index i_contact_2 on contacts(srcpersonid, source);

Bug 3238525 - Upgrade from 9.0 can leave corruptdata for global temporary table indices
ORA-600 [kftts2bz_many_files]
Doc ID: 285592.1

Creating local indexes

Hi,
we are using db partitioning (Daily partition, Range partition) for sub_eve (partitioned on timestamp field) table. the daily partition contains 173millians on rows daily 40gb. i want to create local indexes for on partitioned key field.
1 suggest me the beset way to create indexes on this huge table.
2 is there a way i can create indexes for perticular partitions only.
my setup looks below.
OS : solaris X64
DB : 10.2.0.1
we are using ASM for datafiles.
regards
sachin

user990143 wrote:
Thanks for the response, yes you said correct regarding indexes on single partition. I don't want my loading should be affected bcos of indexes. I load partitions using CTAS.
To explain - I have a self rolled generic package that takes SQL statement, partition table and partition name as input. This package then create a staging table, add the same (local) indexes to it as on the partition table, and then replace the source partition with the contents of the table using a partition exchange. After which the staging table is dropped and purged.
The reason for this method that, in my case, it is horribly expensive to refresh a partition with new data - i.e. a delete of the partition contents, followed by an insert.
What is faster is a truncate of the partition and then the insert. But as the table is used 24x7, any process querying data for that partition during this partition update period, will run into an empty and truncated partition. I need the partition data to be there until the very last second when the fresh data can be made available.
Thus the CTAS of a staging table, adding indexes, and then doing a partition exchange that includes indexes and requires no validation. This is typically a sub-second DDL - allowing me to replace a partition (containing millions of rows and GB's in size) with a new data set near instantaneously. Minimal impact to production and customers running queries against the data. No index rebuilding required.

Gc quiesce wait event on creating an index

Hi,
We're running Oracle 10.2.0.3 in a 2-node RAC.
Today we encountered something strange:
On creating an index on an empty table the session ended up in the 'waiting' state. The event was: 'gc quiesce wait'.
In an attempt to solve it we stopped 1 instance. This didn't help a bit.
Killing the session and restarting the index creation had the same result.
Eventually we bounced the database and then things went fine.
Can anyone explain what might have caused this? I've tried to find an explanation on the internet but can’t really find anything on this wait event.
I’m a newbie on RAC and would like to learn from this…
Regards,
René

Mladen Gogala wrote once:
To "quiesce" database means to suspend it for a brief period of time.
In RAC context, GC quiesce probably means to quiesce a resource Database.
This is an educated guess, only. If this table is heavily in use,
the instance you're inserting into may be pulling huge numbers of
blocks from the other nodes and becoming their master. You are waiting
for remastering. Make sure that all inserts are being done on the same
instance.
Look at the list of bugs in the heavenly patchset, the one that will be
released week after the judgment day, 10.2.0.4. The list of bug fixes is
available in the doc id: 401436.1.
Also, dump systemstate, level 12 when you observe such waits, send it to
Oracle Corp. and work with them. Using HANGANALYZE might not be a bad idea
in this situation.
K. Gopalakrishnan, the author of the RAC book might be having to say about
that, as well. I don't have his book right here and I can't look into it.
I looked into Gopal and Kirti's "Oracle10g Wait Event" book, but there is
nothing in there.
Mladen Gogala
http://mgogala.freehostia.com

Create an index on a huge table

Similar Messages

Maybe you are looking for