Parallel creation of partitionned index and tablespace Temp size

Hi,
I'am not able to find the information if when building in parallel a locally partitionned index, Oracle will iterate on all the partition and then use temp tbs for one partitionned or it will compute for all the partitionned simultaneously ?
Thanks for your help

If I understand your question correctly, the temp tablespace is used for sorting, but there are temp segments created in the tablespaces where the indices will actually belong. See the demo on how to work it out for yourself: http://hemantoracledba.blogspot.com/2008/05/temporary-segments-in-dataindex.html
Also find Randolf's blog for some other interesting factoids: http://oracle-randolf.blogspot.com/2011/02/parallel-dml-conventional-non-direct.html

Similar Messages

Error in creation of text indexes and synching with user datastore

Hi
has any body encountered error in creating text indexes on 9.2.0.1 with user datastore. you can create them only with no-populate option. however once created after checking-in documents the indexes cannot be synched using ctx_ddl command manually.

The only thing that I have seen similar to this was worked around by updating the column to itself, then sync...not sure if this is the same thing you are running into, but it may be worth a try. See the Oracle Text FAQ - take special note of step c:
===============================
Creates the index without populating it.
SQL > CREATE INDEX GLOBALINDEXEDBLOB_I
ON ODMM_CONTENTSTORE ("GLOBALINDEXEDBLOB" ) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS (' stoplist CTXSYS.DEFAULT_STOPLIST storage IFS_DEF_STORAGE section group IFS_SECTION_GROUP wordlist IFS_DEF_WORDLIST memory 32000000 filter IFS_DEF_FILTER format column FORMAT charset column CHARACTERSET lexer IFS_GLOBAL_LEXER language column LANGUAGE nopopulate');
b. Mark globalindexedblob column in every row as updated.
SQL > update odmm_contentstore set globalindexedblob = globalindexedblob;
c. Sync the index. If you skipped the previous step, then this step does not index content that existed prior to index creation in step a.
SQL > exec ctx_ddl.sync_index('GLOBA[i]Long postings are being truncated to ~1 kB at this time.

Buffering and creation of secondary indexes.

Hi All,
I have a table that has more than 6 million records, due to which performance is slow during the transaction search, kindly let me know if Buffering and creation of secondary indexes will help me.
I am given to understand that creation of seconary indexes and full buffering may not always improve performance. Kindly let me know when it is advised to go for full buffering.
Regards,
Thiru

Hi,
create secondary index for the table
check below link
http://help.sap.com/saphelp_nw70/helpdata/en/cf/21eb20446011d189700000e8322d00/content.htm
Regards,
Madhu

Question about the partition index

Hi, all, I have some questions about partitioned index.
And I get from oracle documents that oracle's partition index can be clarified as local partition index and global partition index.
And local partition index can be clarified as prefix local partition index and non-prefix local partition index. And I also the word "global prefix partition index".
But, I can not get what the exact meaning after I consulted many documents and notes from website.
Can anyone give me one example to cover these topic?
You help is very thankful!
Thanks and best regards!

Hi,
Local index search by partition.
Local Indexes: A local index is an index on a partitioned table which is partitioned in the exact same manner as the underlying partitioned table. Each partition of a local index corresponds to one and only one partition of the underlying table.
Global Partitioned Indexes: A global partitioned index is an index on a partitioned or non-partitioned table which is partitioned using a different partitioning-key from the table. Global-partitioned indexes can only be partitioned using range partitioning. For example, a table could be range-partitioned by month and have twelve partitions, while an index on that table could be range-partitioned using a different partitioning key and have a different number of partitions.
Global Non-Partitioned Indexes: A global non-partitioned index is essentially identical to an index on a non-partitioned table. The index structure is not partitioned.
Maybe this links help you:
http://www.oracle.com/technology/products/oracle9i/datasheets/partitioning.html
http://asktom.oracle.com/pls/ask/f?p=4950:8:12026637104196321871::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:678824574412
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:1612281449571
Cheers

Index and partition not visible !!!

Hello,
I am creation a table with partition by range and primary key constraint like
CREATE TABLE employees
(employee_id NUMBER(4) NOT NULL,
last_name VARCHAR2(10),
department_id NUMBER(2),
CONSTRAINT SUP_EMP_PK
PRIMARY KEY
(employee_id,department_id)
PARTITION BY RANGE (department_id)
(PARTITION employees_part1 VALUES LESS THAN (10) TABLESPACE DATA_003_P001_HUB3);
but when I query the user_ind_partitions as
select * from user_ind_partitions where partition_name='employee_part1';
it returns nothing
Why is this problem coming up?
Help..
Regards
Abhinav

Actually the problem statement is:
I have table as :
CREATE TABLE SUPERVISION_BPS
ID NUMBER NOT NULL,
servicetype NUMBER NOT NULL,
type VARCHAR2(6 BYTE) NOT NULL,
insertDate DATE NOT NULL,
filename VARCHAR2(100 BYTE) NOT NULL,
numberOK NUMBER NOT NULL,
numberKO NUMBER NOT NULL,
numberCRE NUMBER NOT NULL,
numberUPD NUMBER NOT NULL,
numberDEL NUMBER NOT NULL,
CONSTRAINT SUP_BPS_PK
PRIMARY KEY
(ID, servicetype, type)
using index local
TABLESPACE DATA_003_P001_HUB3
PARTITION BY RANGE (InsertDate)
PARTITION "PARTITION_LAST" VALUES LESS THAN (MAXVALUE)
create sequence seq_sup_bps start with 1 increment by 1;
The problem is whenever I am deleting a partition as
alter table &1 drop partition &2;
and rebuilding the partition as:
alter index &1 parallel;
alter index &1 rebuild partition &2 compute statistics;
alter index &1 noparallel;
based on unused indexes
select user_ind_partitions.index_name || '|' || user_ind_partitions.partition_name
from user_indexes, user_ind_partitions
where user_indexes.index_name=user_ind_partitions.index_name
and user_ind_partitions.status='UNUSABLE'
and upper(user_indexes.table_name)='&2';
Now when the entry for the same primary key takes place, it gives an error putting the same value again.
Kindly help
Tried all bit have not found the solution.
Note: have tried removing UNUSABLE check but how to get it done as per the need.
Regards
Abhinav
Edited by: user8744860 on Jul 2, 2012 2:35 AM

Create index without using temp tablespace

Hello,
i have a great table with over 2.000.000.000 rows. Therefor i want to create an index on column1:
CREATE INDEX "SCHEMA"."INDEX_TABLE1" ON "SCHEMA"."TABLE1" ("STR1")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS NOCOMPRESS LOGGING
STORAGE( INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ;
If i execute this my temp tablespace will be used and if its full (max 20gb) the creation will be aborted.
Where is my fault to create the index?
With best

bladepit wrote:
The table description:
CREATE TABLE "SCHEMA"."TABLE1"
(     "STR1" VARCHAR2(20 BYTE),
     "STR2" VARCHAR2(20 BYTE),
     "VAL" NUMBER
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ;
And i want to get the values like this:
select str1,str2,val from SCHEMA.TABLE1 where str1 = 'TEST1' or str2 = 'TEST1'
If this is the complete definition of the table, and if (str1, str2) are unique, and this really is the only way you use the table, then it looks as if your STRATEGIC move would be to rebuild the table as a hash partitioned IOT with something like 128 partitions. Since you probably can't do that in the short-term you could create a hash partitioned index on the table (assuming you have paid the partitioning licence) with enough partitions that you can create each one separately. Something like:
SQL> create index t1_i1 on t1(n1, n2, n3) unusable global partition by hash (n1, n2) partitions 4;
Index created.
SQL> select index_name, partition_name from user_ind_partitions;
INDEX_NAME           PARTITION_NAME
T1_I1                SYS_P8713
T1_I1                SYS_P8712
T1_I1                SYS_P8711
T1_I1                SYS_P8710
4 rows selected.
SQL> alter index t1_i1 rebuild partition sys_p8713 online;
Index altered.
-- repeat for each partition in turnRegards
Jonathan Lewis

How to partition tables and indexes in this scenario?

So our situation is pretty simple. We have 3 tables.
A, B and C
the model is A->>B->>C
Currently A, B and C are range partitioned on a key created_date however it's typical that only C is every qualfied with created date. There is a foreign key from B -> A and C -> B
we have many queries where the data is identified by state that is indexed currently non partitioned on columns in A ... there are also indexes on the foreign keys that get from C -> B -> A. Again these are non partitioned indexes at this time.
It is typical that we qualify A on either account or user or both. There are indexes (non partitioned) on these
We have a problem now because many of the queries use leading wildcards ie. account like '%ACCOUNT' etc. This often results in large full table scans. Our solution has been to remove the leading wildcard but this isn't always possible.
We are wondering how we can benefit from partitioning and or sub partitioning table A. since it's partitioned on created_date but rarely qualify by that.
We are also wondering where and how we can benefit from either global partitioned index or local partitioned indexes on tables A. We suspect that the index on the foreign key from C to B could be a local partitioned index.
I am also wondering what impact pushing the state from A that's used to qualify A down to C would have any advantage.
C is the table that currently we qualify with the partition key so I figure if you also pushed down the state from A that's used to qualify the set of C's we want based on the set of B's we want based on the set of A thru qualfying on columns within A.
If we push down some of those values to C and simply use C when filtering I'm wondering what the plans will look like compared to having to work all the way up from the bottom to the top before it begins qualifying A.
Edited by: steffi on Jan 14, 2011 11:36 PM

We are wondering how we can benefit from partitioning and or sub partitioning table A. since it's partitioned on >created_date but rarely qualify by that. Very good question. Why did you partition on it? You will never have INSERTS on these partitions, but maybe deletes and updates? The only advantage (I can think of) would be to set these partitions in a read only tablespace to ease backup... but that's a weired reason.
we have many queries where the data is identified by state that is indexed currently non partitioned on columns in >A ... there are also indexes on the foreign keys that get from C -> B -> A. Again these are non partitioned indexes at >this time.Of course. Why should they be partitioned by Create_date?
It is typical that we qualify A on either account or user or both. There are indexes (non partitioned) on these
We have a problem now because many of the queries use leading wildcards ie. account like '%ACCOUNT' etc. This >often results in large full table scans. Our solution has been to remove the leading wildcard but this isn't always possible.I would suspect full index scan. Isn't it?
We are also wondering where and how we can benefit from either global partitioned index or local partitioned >indexes on tables A. We suspect that the index on the foreign key from C to B could be a local partitioned index.As A is not accessed by any partition, why should C and B profit? You should look to partition by the key you are using to access. But, you are looking to tune your SQLs where the access is like '%ACCOUNT' on A. Then when there is a match. ORACLE joins via your index and nested loop (right?) to B and C.
I am also wondering what impact pushing the state from A that's used to qualify A down to C would have any >advantage.Why should it. It just makes the table and indexes larger => more IO.
C is the table that currently we qualify with the partition key so I figure if you also pushed down the state from A >that's used to qualify the set of C's we want based on the set of B's we want based on the set of A thru qualfying >on columns within A.If the access from A to C would be .. AND A.CREATE_DATE =C.CREATE_DATE and c.key like '%what I want%' which does not qualifify for a FK ;-) then, as that could be resulting in a partition scan, you could "profit". But, I'm sure that's not your model.
If we push down some of those values to C and simply use C when filtering I'm wondering what the plans will look >like compared to having to work all the way up from the bottom to the top before it begins qualifying A.So you want to denormalize A,B,C and into one table? With the same access is like '%ACCOUNT' you would get a full scan on an index as before, just the objects would be larger due to redundance and harder to maintain. In the end you would have a bad and slower design.
Maybe you explain what the problem is.
Full index scan can not be avoided, but that can be made faster by e.g. parallel query, and then the join to B and C should be a "snip" if you just identify a small subset of rows in these tables.

How to simply create a locally partitioned index with a dedicated tablespac

Dears,
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64biSuppose you have a range partitioned table t on date d with n partitions p1, p2,....pn
If you create a locally partitioned index using the following script
create index ind_loc on t(d) local;all the partitioned indexes will be created on the same default tablespace.
Is there a simple creation script (not that where we have to add each partition and each tablespace) to use in order to associate each partitioned index to a given tablespace?
Best Regards
Mohamed Houri

Suppose you have a range partitioned table t on date d with n partitions p1, p2,....pn
If you create a locally partitioned index using the following script
create index ind_loc on t(d) local;all the partitioned indexes will be created on the same default tablespace.
Is there a simple creation script (not that where we have to add each partition and each tablespace) to use in order to associate each partitioned index to a given tablespace?
Hi Mohamed ,
AFAIK , there is no such script . If you want partition to be stored in different tablespaces, then you will have to specify partition name along with tablespace name in create index command.
Regards
Rajesh

Re-org oracle 11.1.0.7 partitioned and sub partitioned index not validiting

Hi,
As part of maintenance i did the following thing on the oracle 11.1.0.7 on windows (no archive log mode);
     Re-orgnaized the tables in application- data tablespace - done
     Re-orgnaized large table in SYSAUX tablespace - only one table (alter table sys.WRI$_OPTSTAT_HISTGRM_HISTORY move tablespace sysaux
alter index sys.I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST rebuild nologging;
alter index sys.I_WRI$_OPTSTAT_H_ST rebuild nologging;)
     Re-built the indexes on applicaton index tbs- done
     Re-built the partition indexes on application index tbs - done
     rebuilding of indexes in SYSAUX - done since it was invalid
     Run the analyze job –
     Re-claim the space at database level and OS level
but i have the issues of partitioned and subpartition indexes are not validating..how to validate the indexes i am using the below querires but:
ORA-14287: cannot REBUILD a partition of a Composite Range partitioned i

i am using the below sqls:
set head off
set linesize 200
select 'alter index '||index_owner||'.'||index_name||' rebuild partition '||partition_name||' ; ' from dba_ind_partitions where status <> 'VALID' and index_owner not in ('SYS','SYSTEM')
set head off
set linesize 200
select 'alter index '||index_owner||'.'||index_name||' rebuild subpartition '||subpartition_name||' ;'
from dba_ind_subpartitions
where status <> 'VALID'

Separate tablespaces for indexes and LOBs

I have modeled my db tables with jDeveloper. Now I would like to store my tables in default tables, my indexes in a separate tablespace, and LOBs in a 3rd tablespace.
How can I best add the tablespace definitions to the table creation sql? I can't find such functionality in jDeveloper.
If jDev does not support this, does Oracle have some other tools which could do this?
Or can I set some ALTER SESSION parameter before creating the tables which would make my indexes and LOBs go to the correct tablespaces by default?

I see jDeveloper 11g has a possibility for specifying tablespaces for the tables and LOBs.
I cant figure out how to set tablespaces for indexes though. I can tell there is definately no way to set tablespace settings for primary key / foreign key indexes.
So jDev 11g does not seem to solve my problem either.

Index issue with or and between when we set one partition index to unusable

Need to understand why optimizer unable to use index in case of "OR" whenn we set one partition index to unusable, the same query with between uses index.
“OR” condition fetch less data comparing to “BETWEEN” still oracle optimizer unable to use indexes in case of “OR”
1. Created local index on partitioned table
2. ndex partition t_dec_2009 set to unusable
-- Partitioned local Index behavior with “OR” and with “BETWEEN”
SQL> CREATE TABLE t (
2    id NUMBER NOT NULL,
3    d DATE NOT NULL,
4    n NUMBER NOT NULL,
5    pad VARCHAR2(4000) NOT NULL
6 )
7 PARTITION BY RANGE (d) (
8    PARTITION t_jan_2009 VALUES LESS THAN (to_date('2009-02-01','yyyy-mm-dd')),
9    PARTITION t_feb_2009 VALUES LESS THAN (to_date('2009-03-01','yyyy-mm-dd')),
10    PARTITION t_mar_2009 VALUES LESS THAN (to_date('2009-04-01','yyyy-mm-dd')),
11    PARTITION t_apr_2009 VALUES LESS THAN (to_date('2009-05-01','yyyy-mm-dd')),
12    PARTITION t_may_2009 VALUES LESS THAN (to_date('2009-06-01','yyyy-mm-dd')),
13    PARTITION t_jun_2009 VALUES LESS THAN (to_date('2009-07-01','yyyy-mm-dd')),
14    PARTITION t_jul_2009 VALUES LESS THAN (to_date('2009-08-01','yyyy-mm-dd')),
15    PARTITION t_aug_2009 VALUES LESS THAN (to_date('2009-09-01','yyyy-mm-dd')),
16    PARTITION t_sep_2009 VALUES LESS THAN (to_date('2009-10-01','yyyy-mm-dd')),
17    PARTITION t_oct_2009 VALUES LESS THAN (to_date('2009-11-01','yyyy-mm-dd')),
18    PARTITION t_nov_2009 VALUES LESS THAN (to_date('2009-12-01','yyyy-mm-dd')),
19    PARTITION t_dec_2009 VALUES LESS THAN (to_date('2010-01-01','yyyy-mm-dd'))
20 );
SQL> INSERT INTO t
2 SELECT rownum, to_date('2009-01-01','yyyy-mm-dd')+rownum/274, mod(rownum,11), rpad('*',100,'*')
3 FROM dual
4 CONNECT BY level <= 100000;
SQL> CREATE INDEX i ON t (d) LOCAL;
SQL> execute dbms_stats.gather_table_stats(user,'T')
-- Mark partition t_dec_2009 to unusable:
SQL> ALTER INDEX i MODIFY PARTITION t_dec_2009 UNUSABLE;
--- Let’s check whether the usable index partition can be used to apply a restriction: BETWEEN
SQL> SELECT count(d)
    FROM t
    WHERE d BETWEEN to_date('2009-01-01 23:00:00','yyyy-mm-dd hh24:mi:ss')
                AND to_date('2009-02-02 01:00:00','yyyy-mm-dd hh24:mi:ss');
SQL> SELECT * FROM table(dbms_xplan.display_cursor(format=>'basic +partition'));
| Id | Operation               | Name | Pstart| Pstop |
|   0 | SELECT STATEMENT        |      |       |       |
|   1 | SORT AGGREGATE         |      |       |       |
|   2 |   PARTITION RANGE SINGLE|      |    12 |    12 |
|   3 |    INDEX RANGE SCAN     | I    |    12 |    12 |
--- Let’s check whether the usable index partition can be used to apply a restriction: OR
SQL> SELECT count(d)
    FROM t
    WHERE
    (d >= to_date('2009-01-01 23:00:00','yyyy-mm-dd hh24:mi:ss') and d <= to_date('2009-01-01 23:59:59','yyyy-mm-dd hh24:mi:ss'))
    or
    (d >= to_date('2009-02-02 01:00:00','yyyy-mm-dd hh24:mi:ss') and d <= to_date('2009-02-02 02:00:00','yyyy-mm-dd hh24:mi:ss'))
SQL> SELECT * FROM table(dbms_xplan.display_cursor(format=>'basic +partition'));
| Id | Operation           | Name | Pstart| Pstop |
|   0 | SELECT STATEMENT    |      |       |       |
|   1 | SORT AGGREGATE     |      |       |       |
|   2 |   PARTITION RANGE OR|      |KEY(OR)|KEY(OR)|
|   3 |    TABLE ACCESS FULL| T    |KEY(OR)|KEY(OR)|
----------------------------------------------------“OR” condition fetch less data comparing to “BETWEEN” still oracle optimizer unable to use indexes in case of “OR”
Regards,
Sachin B.

Hi,
What is your database version????
I ran the same test and optimizer was able to pick the index for both the queries.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for 32-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL>
SQL> set autotrace traceonly exp
SQL>
SQL>
SQL> SELECT count(d)
2 FROM t
3 WHERE d BETWEEN to_date('2009-01-01 23:00:00','yyyy-mm-dd hh24:mi:ss')
4              AND to_date('2009-02-02 01:00:00','yyyy-mm-dd hh24:mi:ss');
Execution Plan
Plan hash value: 2381380216
| Id | Operation                 | Name | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT          |      |     1 |     8 |    25   (0)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE           |      |     1 |     8 |            |          |       |       |
|   2 |   PARTITION RANGE ITERATOR|      | 8520 | 68160 |    25   (0)| 00:00:01 |     1 |     2 |
|* 3 |    INDEX RANGE SCAN       | I    | 8520 | 68160 |    25   (0)| 00:00:01 |     1 |     2 |
Predicate Information (identified by operation id):
   3 - access("D">=TO_DATE(' 2009-01-01 23:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "D"<=TO_DATE(' 2009-02-02 01:00:00', 'syyyy-mm-dd hh24:mi:ss'))
SQL> SELECT count(d)
2 FROM t
3 WHERE
4 (
5 (d >= to_date('2009-01-01 23:00:00','yyyy-mm-dd hh24:mi:ss') and d <= to_date('2009-01-01 23:59:59','yyyy-mm-dd hh24:mi:ss'
6 or
7 (d >= to_date('2009-02-02 01:00:00','yyyy-mm-dd hh24:mi:ss') and d <= to_date('2009-02-02 02:00:00','yyyy-mm-dd hh24:mi:ss'
8 );
Execution Plan
Plan hash value: 3795917108
| Id | Operation                | Name | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT         |      |     1 |     8 |     4   (0)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE          |      |     1 |     8 |            |          |       |       |
|   2 |   CONCATENATION          |      |       |       |            |          |       |       |
|   3 |    PARTITION RANGE SINGLE|      |    13 |   104 |     2   (0)| 00:00:01 |     2 |     2 |
|* 4 |     INDEX RANGE SCAN     | I    |    13 |   104 |     2   (0)| 00:00:01 |     2 |     2 |
|   5 |    PARTITION RANGE SINGLE|      |    13 |   104 |     2   (0)| 00:00:01 |     1 |     1 |
|* 6 |     INDEX RANGE SCAN     | I    |    13 |   104 |     2   (0)| 00:00:01 |     1 |     1 |
Predicate Information (identified by operation id):
   4 - access("D">=TO_DATE(' 2009-02-02 01:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "D"<=TO_DATE(' 2009-02-02 02:00:00', 'syyyy-mm-dd hh24:mi:ss'))
   6 - access("D">=TO_DATE(' 2009-01-01 23:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "D"<=TO_DATE(' 2009-01-01 23:59:59', 'syyyy-mm-dd hh24:mi:ss'))
       filter(LNNVL("D"<=TO_DATE(' 2009-02-02 02:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
              LNNVL("D">=TO_DATE(' 2009-02-02 01:00:00', 'syyyy-mm-dd hh24:mi:ss')))
SQL> set autotrace off
SQL>Asif Momen
http://momendba.blogspot.com

Does dropping bitmap index and creation of b- index cause any dead locks

Does dropping a bitmap index on table which is being used continuously for DML operations and creation of b- index cause any dead locks on a table
in oracle 10g database
( 10.1.0.4.0 - 64bi).
we have seen alert log file which has dead lock occurrence.. would index change/re-creation resulted dead lock or some other reason?
Could you please give us info or help us on this.. thanks in advance..

Bitmap indexes can be the cause of deadlocks on busy systems.
Dropping indexes may cause some locking.
Creating indexes may cause some locking.
You haven't given any traces or scripts or lock information, so difficult to say which one (if any) was the cause of your deadlocks.
It would be better to do this activity when the system is not busy.

SDO_UTIL.PREPARE_FOR_TTS and Partitioned Indexes

Does this procedure work with partitioned indexes?
After executing this procedure on tablespace that contains the first partition of the partition index, the table SDO_INDEX_TTS_METADATA$ is empty. In addition, I can only run this procedure once, it fails for each subsequent tablespace which has a partition.
When I execute the procedure on a tablespace with a non partitioned index the SDO_INDEX_TTS_METADATA$ table is populated.

Thanks Dear ,
for your immediate reply .....
As u suggest I have tried all the following combitation but still it does not work;
SDO_UTIL.INITIALIZE_INDEX*ES*FORTTS;
SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS;
SDO_UTIL.INITIALIZE_INDEX_FOR_TTS;
it gives same error....
Thanks & Regards
Chandrakishore Bankhede

MS SQL Server 2014: Error inserting into Temp table with index and identity field

In this thread, I mentioned a problem with SQL Server 2014:
SQL Server 2014: Bug with IDENTITY INSERT ON
The question was answered, it is a bug. To keep you informed on this issue, I open this discussion.
Problem:
The code below works perfectly fine on MS SQL Server 2008 R2 and MS SQL Server 2012, but gives an error every second time the proc is executed on MS SQL Server 2014. If I do not define any index on the temp table, the problem disappears. Defining the index
after the insert, does not help.
SET NOCOUNT ON
GO
IF EXISTS (SELECT 1 FROM sys.procedures WHERE name = 'usp_Test') DROP PROC dbo.usp_Test;
GO
CREATE PROC dbo.usp_Test AS
BEGIN
SET NOCOUNT ON
CREATE TABLE #Source(ID integer NOT NULL);
INSERT INTO #Source VALUES (1), (2), (3);
CREATE TABLE #Dest (ID integer IDENTITY(1,1) NOT NULL);
CREATE INDEX #IDX_Dest ON #Dest (ID);
PRINT 'Check if the insert might cause an identity crisis';
SELECT 'Source' AS SourceTable, * FROM #Source;
SELECT 'Destination' AS DestTable, * FROM #Dest;
SET IDENTITY_INSERT #Dest ON;
PRINT 'Do the insert';
INSERT INTO #Dest (ID) SELECT ID FROM #Source;
PRINT 'Insert ready';
SET IDENTITY_INSERT #Dest OFF;
SELECT * FROM #Dest;
DROP TABLE #Source;
DROP TABLE #Dest;
END;
GO
PRINT 'First execution of the proc, everything OK';
EXEC dbo.usp_Test;
PRINT '';
PRINT 'Second execution of the proc, the insert fails.';
PRINT 'Removing the index #IDX_Dest causes the error to disappear.';
EXEC dbo.usp_Test;
GO
DROP PROC dbo.usp_Test;
GO

There is some progress. Communication from a former Microsoft employee tells us this:
Shivendra Vishal
Engineer at Microsoft
I am no longer with MS, and I do not have code access, however from the public symbols, I could make out following:
sqlmin!SetidentI2I4+0x1f3:
000007fe`f4d865d3 488b10 mov rdx,qword ptr [rax] ds:00000000`00000000=????????????????
ExceptionAddress: 000007fef4d865d3 (sqlmin!SetidentI2I4+0x00000000000001f3)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000000
Attempt to read from address 0000000000000000
This is a read AV and from registers it is clear that we were trying to move the value of location pointed by qword of register rax which is not valid:
rax=0000000000000000 rbx=0000000000000038 rcx=0000000000001030
rdx=0000000000000006 rsi=00000001f55def98 rdi=00000000106fd070
rip=000007fef4d865d3 rsp=00000000106fcf40 rbp=00000000106fcfe9
r8=0000000000000000 r9=00000001f55def60 r10=00000001f55defa0
r11=00000000106fcd20 r12=0000000000000000 r13=0000000000000002
r14=00000001f49c3860 r15=00000001f58c0040
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
The stack is:
# Child-SP RetAddr Call Site
00 00000000`106fcf40 000007fe`f30c1437 sqlmin!SetidentI2I4+0x1f3
01 00000000`106fd050 000007fe`f474e7ce sqlTsEs!CEsExec::GeneralEval4+0xe7
02 00000000`106fd120 000007fe`f470e6ef sqlmin!CQScanUpdateNew::GetRow+0x43d
03 00000000`106fd1d0 000007fe`f08ff517 sqlmin!CQueryScan::GetRow+0x81
04 00000000`106fd200 000007fe`f091cebe sqllang!CXStmtQuery::ErsqExecuteQuery+0x36d
05 00000000`106fd390 000007fe`f091ccb9 sqllang!CXStmtDML::XretDMLExecute+0x2ee
06 00000000`106fd480 000007fe`f08fa058 sqllang!CXStmtDML::XretExecute+0xad
07 00000000`106fd4b0 000007fe`f08fb66b sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x427
08 00000000`106fd5f0 000007fe`f08fac2e sqllang!CMsqlExecContext::FExecute+0xa33
09 00000000`106fd7e0 000007fe`f152cfaa sqllang!CSQLSource::Execute+0x86c
0a 00000000`106fd9b0 000007fe`f152c9e8 sqllang!CStmtExecProc::XretLocalExec+0x25a
0b 00000000`106fda30 000007fe`f152a1d8 sqllang!CStmtExecProc::XretExecExecute+0x4e8
0c 00000000`106fe1e0 000007fe`f08fa058 sqllang!CXStmtExecProc::XretExecute+0x38
0d 00000000`106fe220 000007fe`f08fb66b sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x427
0e 00000000`106fe360 000007fe`f08fac2e sqllang!CMsqlExecContext::FExecute+0xa33
0f 00000000`106fe550 000007fe`f0902267 sqllang!CSQLSource::Execute+0x86c
10 00000000`106fe720 000007fe`f0909087 sqllang!process_request+0xa57
11 00000000`106feee0 000007fe`f2bf49d0 sqllang!process_commands+0x4a3
12 00000000`106ff200 000007fe`f2bf47b4 sqldk!SOS_Task::Param::Execute+0x21e
13 00000000`106ff800 000007fe`f2bf45b6 sqldk!SOS_Scheduler::RunTask+0xa8
14 00000000`106ff870 000007fe`f2c136ff sqldk!SOS_Scheduler::ProcessTasks+0x279
15 00000000`106ff8f0 000007fe`f2c138f0 sqldk!SchedulerManager::WorkerEntryPoint+0x24c
16 00000000`106ff990 000007fe`f2c13246 sqldk!SystemThread::RunWorker+0x8f
17 00000000`106ff9c0 000007fe`f2c13558 sqldk!SystemThreadDispatcher::ProcessWorker+0x3ab
18 00000000`106ffa70 00000000`775d59ed sqldk!SchedulerManager::ThreadEntryPoint+0x226
19 00000000`106ffb10 00000000`7780c541 kernel32!BaseThreadInitThunk+0xd
1a 00000000`106ffb40 00000000`00000000 ntdll!RtlUserThreadStart+0x21
Unassembling the function:
000007fe`f4d8658e 4c8b10 mov r10,qword ptr [rax]
000007fe`f4d86591 4533e4 xor r12d,r12d
000007fe`f4d86594 410fb7d5 movzx edx,r13w
000007fe`f4d86598 4533c9 xor r9d,r9d
000007fe`f4d8659b 4533c0 xor r8d,r8d
000007fe`f4d8659e 488bc8 mov rcx,rax
000007fe`f4d865a1 4489642420 mov dword ptr [rsp+20h],r12d
000007fe`f4d865a6 41ff5230 call qword ptr [r10+30h]
000007fe`f4d865aa 8b5597 mov edx,dword ptr [rbp-69h]
000007fe`f4d865ad 4c8b10 mov r10,qword ptr [rax]
000007fe`f4d865b0 4489642438 mov dword ptr [rsp+38h],r12d
000007fe`f4d865b5 4489642430 mov dword ptr [rsp+30h],r12d
000007fe`f4d865ba 458d442401 lea r8d,[r12+1]
000007fe`f4d865bf 4533c9 xor r9d,r9d
000007fe`f4d865c2 488bc8 mov rcx,rax
000007fe`f4d865c5 c644242801 mov byte ptr [rsp+28h],1
000007fe`f4d865ca 4488642420 mov byte ptr [rsp+20h],r12b
000007fe`f4d865cf 41ff5250 call qword ptr [r10+50h]
000007fe`f4d865d3 488b10 mov rdx,qword ptr [rax] <=================== AV happened over here
000007fe`f4d865d6 488bc8 mov rcx,rax
000007fe`f4d865d9 4c8bf0 mov r14,rax
000007fe`f4d865dc ff5268 call qword ptr [rdx+68h]
000007fe`f4d865df 488d55e7 lea rdx,[rbp-19h]
000007fe`f4d865e3 4c8b00 mov r8,qword ptr [rax]
000007fe`f4d865e6 488bc8 mov rcx,rax
000007fe`f4d865e9 41ff5010 call qword ptr [r8+10h]
000007fe`f4d865ed f6450a04 test byte ptr [rbp+0Ah],4
I remember few issues with scan2ident function, I am not sure if they have fixed it however it appears that this is intoduced to SQL 2014 and we need help from MS to get this resolved as it needs code analysis.
It is not getting simulated for other versions of SQL apart from SQL 2014.
Also to add, interestingly, the value of rax is not visibly changed and it was successfully passed on to rcx, which has a valid value, so something should have changed the value of rax inside call to function using call qword ptr [r10+50h], and looking at this
it appears that it might be a list of functions and we are going at particular offset [50h]. So, bottom line is that the call to function qword ptr [r10+50h], should be changing something in rax, and debugging/analyzing this code might give us some more idea.

ORA-29857: domain indexes and/or secondary objects exist in the tablespace

I tried to drop tablespace APPS_TS_TX_DATA using drop tablespace APPS_TS_TX_DATA including contents and datafiles cascade constraints.
I got error ORA-29857: domain indexes and/or secondary objects exist in the tablespace.
After I have dropped all domain indexes, then tried to drop tablespace again, I still got the same error. I have searched metalink regarding this error, there is no hit.
What exactly objects in the tablespace are prevenng dropping the tablespaces?

BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
ILMU88>
ILMU88> SELECT COUNT(*)
2 FROM dba_segments
WHERE tablespace_name = 'APPS_TS_TX_DATA';
3
COUNT(*)
14190
drop tablespace APPS_TS_TX_DATA including contents and datafiles cascade constraints;
drop tablespace APPS_TS_TX_DATA including contents and datafiles cascade constraints
ERROR at line 1:
ORA-29857: domain indexes and/or secondary objects exist in the tablespace

Parallel creation of partitionned index and tablespace Temp size

Similar Messages

Maybe you are looking for