Transport indexes created on a table?

Hi All,
I have created indexes on one of the database tables (/bic/azmm_o0200 active table of ODS), is it transportable? or is it something we create in production?
if it is transportable, please explain how to transport this to QA?
Thanks,
Sirish..

It depends on whether you created the indices on the application side (in ODS change screen) or directly at the database level (SE14).
If created through application, these changes need to be transported. On other hand if you have created indices directly on the table in the database, they are created in manually in each system. Hope this helps!

Similar Messages

Table with FK with no Index created will LOCK TABLE during DML ?

Hi all,
Know that always create index for FK on table as FK's value will 99.9% be use in Where query on table.
Had seen info with regards to the above and had not been successfull trying to simulate the above using:
DROP TABLE "TABLE2";
CREATE TABLE "TABLE2"
   (     "A2" VARCHAR2(10 BYTE),
      CONSTRAINT "PK_A2" PRIMARY KEY ("A2") ENABLE
Insert into TABLE2 (A2) values ('AAA');
Insert into TABLE2 (A2) values ('BBB');
Insert into TABLE2 (A2) values ('CCC');
DROP TABLE "TABLE1";
CREATE TABLE "TABLE1"
   (     "A1" VARCHAR2(10 BYTE),
     "A2" VARCHAR2(10 BYTE),
     "A3" VARCHAR2(10 BYTE),
      CONSTRAINT "PK_A1" PRIMARY KEY ("A1"),
      CONSTRAINT "FK_A1_A2" FOREIGN KEY ("A2")
       REFERENCES "LSD"."TABLE2" ("A2") ENABLE
Insert into TABLE1 (A1,A2,A3) values ('111','AAA','yyy');
Insert into TABLE1 (A1,A2,A3) values ('222','BBB','ZZZ');
When i UPDATE A3 in TABLE1 using '111' record in SQLPlus without COMMIT,
I was able to UPDATE A3 using '222' in another SQLPlus session, so it does not seems like table is LOCK.
Questions.
1. Am using 10GR2, is the above not applicable to 10G ?
2. Or had understand the above concept wrongly ?
Thanks In Advance
Zack

Hi Legatti,
I was able to UPDATE A3 using '222' in another SQLPlus session, so it does not seems like table is LOCK.   Thought that when updating more than 1 record in TABLE1 will caused TABLE1 to be LOCK.
Now, try to perform an update on the TABLE1 like below:    SQL>update table1 set A3='aaa' where A1=111;
And open an another session and perform this SQL below    SQL>delete from table2 where A2='BBB'; -- now it's hangs
Yes !!! Very interesting, it hangs until i do a COMMIT on the UPDATE
and DELETE session shows ORA-02292 Integrity Constraint violated as child record found.
Now, when i create a index for A2 on TABLE1, it DOES NOT HANG and shows ORA-2292 immediately.
So, is this the result of having no index for FK column (A2) on TABLE1 and when doing DML ,
before COMMIT, will result in TABLE2 to be hang upon doing DML on TABLE2 ?
Thanks for the valuable lesson learned.
Zack

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

Index for a PSA table is not in the "customer" namespace

Hi,
While loading data through infosource 0CO_OM_WBS_1 to
data target 0IMFA_1 loading failes and the reason given is that the system reads data from PSA table /BIC/B0001060000 of 0IM_FA_IQ_9 and the index generated for this table supplied return code 14.
I found no notes in the subject - with the syntax :
Index for a PSA table is not in the "customer" namespace.
thanks in advance for your help.

Hi,
I think you need to speak to your basis guys / DBA as index created on PSA table is not in your tablespace. He should be able to help you.
Vikash

Transport of secondary index on /BIC/P table

Hi All,
I have created a secondary index on '/BIC/P table and it is not allowing me to assign a transport object as the table itself is temporary and it gets created automatically in the target system when we activate the info-object.
Is there any way to transport the secondary index directly on the /BIC/P table ?
Its urgent.
Thanks
Soumya

Soumya,
Sorry for not being clear enough: you can change the package of this index and transport it but since the P table could be regenerated automatically by the BW application when you change your IObj you may now get into troubles when importing a change.
Indeed having now a local $TMP table with a non-local object underneath may not please your target system and even not your DEV system...
One can always bypass SAP BW application; for instance creating indexes directly in the database; but this is at its own risk!
hoping this will explain a bit further your issue
Olivier.

Creating a bit map index on a partitioned table

Dear friends,
I am trying to create a bitmap index on a partitioned table but am receiving the following ORA error. Can you please let me know on how to create a local bit map index as the message suggests?
ERROR at line 1:
ORA-25122: Only LOCAL bitmap indexes are permitted on partitioned tables
Trying to use the keyword local in front leads to wrong syntax.
Thanks in advance !!
Somnath

ORA-25122 Only LOCAL bitmap indexes are permitted on partitioned tables
Cause: An attempt was made to create a global bitmap index on a partitioned table.
Action: Create a local bitmap index instead
Example of a Local Index Creation
CREATE INDEX employees_local_idx ON employees (employee_id) LOCAL;
Example is about btree and I think it will work for bitmap also.

New tables & indexes created do not show up in dba_segments view

Dear all,
I have created 3 tables and some indexes, but these objects do not show up in dba_segments view. Is this a normal behaviour? Previously, with dictionary managed tablespace, I can specify the minimum extent to create, when the table/index is created. But I'm not sure how the locally managed tablespace work. Please do advice. Thank you very much in advance.
I'm using Oracle 11g R2 (11.2.0.1.0) for Microsoft Windows (x64), running on Windows 7.
For the purpose of reproducing this issue, I have created the tablespaces as follow:
CREATE TABLESPACE CUST_DATA
DATAFILE 'd:\app\asus\oradata\orcl11gr2\CUST_DATA01.DBF' SIZE 512K
AUTOEXTEND ON NEXT 256K MAXSIZE 2000K
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
SEGMENT SPACE MANAGEMENT AUTO;
CREATE TABLESPACE CUST_INDX
DATAFILE 'd:\app\asus\oradata\orcl11gr2\CUST_INDX.DBF' SIZE 256K
AUTOEXTEND ON NEXT 128K MAXSIZE 2000K
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K
SEGMENT SPACE MANAGEMENT AUTO;
CREATE TABLE CUSTOMER_MASTER (CUST_ID VARCHAR2 (10),
CUST_NAME VARCHAR2 (30),
EMAIL VARCHAR2 (30),
DOB DATE,
ADD_TYPE CHAR (2) CONSTRAINT CK_ADD_TYPE CHECK (ADD_TYPE IN ('B1','B2','H1','H2')),
CRE_USER VARCHAR2 (5) DEFAULT USER,
CRE_TIME TIMESTAMP (3) DEFAULT SYSTIMESTAMP,
MOD_USER VARCHAR2 (5),
MOD_TIME TIMESTAMP (3),
CONSTRAINT PK_CUSTOMER_MASTER PRIMARY KEY (CUST_ID) USING INDEX TABLESPACE CUST_INDX)
TABLESPACE CUST_DATA;
SQL> SELECT TABLE_NAME, TABLESPACE_NAME
2 FROM USER_TABLES
3 WHERE TABLE_NAME LIKE 'CUST%';
TABLE_NAME TABLESPACE_NAME
CUSTOMER_MASTER CUST_DATA
SQL> SELECT INDEX_NAME, TABLESPACE_NAME
2 FROM USER_INDEXES
3 WHERE TABLE_NAME LIKE '%CUST%';
INDEX_NAME TABLESPACE_NAME
PK_CUSTOMER_MASTER CUST_INDX
SQL> SELECT SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, BYTES
2 FROM USER_SEGMENTS;
no rows selected

Prior to 11g, when you created a table or whatever, you automatically allocated one extent.
This is now no longer true and depends on a parameter I don't remember.
dba_segments is a summary of dba_extents.
Obviously, if there is no extent allocated, the table (view is defined with inner join) will not show up.
You could qualify this is as a bug and submit a SR to Oracle. But then the performance impact may be huge.
Sybrand Bakker
Senior Oracle DBA

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

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

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

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

While dropping table, INDEXES created by us, note, not by oracle, does not drop.

Hellow Friends,
I want to know when we drop the table, the indexes created on it does not drop with it. Offcourse I know the indexes which are created when we give constraints on columns drops.
Have you got my point, I am talking about those indexes which are created by us time to time according to our needs.
Thankyou
Sumeet

Hellow Armold,
I tried
drop table <table_name>;
ThankYou
Sumeet

Creating Local partitioned index on Range-Partitioned table.

Hi All,
Database Version: Oracle 8i
OS Platform: Solaris
I need to create Local-Partitioned index on a column in Range-Partitioned table having 8 million records, is there any way to perform it in fastest way.
I think we can use Nologging, Parallel, Unrecoverable options.
But while considering Undo and Redo also mainly time required to perform this activity....Which is the best method ?
Please guide me to perform it in fastest way and also online !!!
-Yasser

YasserRACDBA wrote:
3. CREATE INDEX CSB_CLIENT_CODE ON CS_BILLING (CLIENT_CODE) LOCAL
NOLOGGING PARALLEL (DEGREE 14) online;
4. Analyze the table with cascade option.
Do you think this is the only method to perform operation in fastest way? As table contain 8 million records and its production database.Yasser,
if all partitions should go to the same tablespace then you don't need to specify it for each partition.
In addition you could use the "COMPUTE STATISTICS" clause then you don't need to analyze, if you want to do it only because of the added index.
If you want to do it separately, then analyze only the index. Of course, if you want to analyze the table, too, your approach is fine.
So this is how the statement could look like:
CREATE INDEX CSB_CLIENT_CODE ON CS_BILLING (CLIENT_CODE) TABLESPACE CS_BILLING LOCAL NOLOGGING PARALLEL (DEGREE 14) ONLINE COMPUTE STATISTICS;
If this operation exceeds particular time window....can i kill the process?...What worst will happen if i kill this process?Killing an ONLINE operation is a bit of a mess... You're already quite on the edge (parallel, online, possibly compute statistics) with this statement. The ONLINE operation creates an IOT table to record the changes to the underlying table during the build operation. All these things need to be cleaned up if the operation fails or the process dies/gets killed. This cleanup is supposed to be performed by the SMON process if I remember correctly. I remember that I once ran into trouble in 8i after such an operation failed, may be I got even an ORA-00600 when I tried to access the table afterwards.
It's not unlikely that your 8.1.7.2 makes your worries with this kind of statement, so be prepared.
How much time it may take? (Just to be on safer side)The time it takes to scan the whole table (if the information can't read from another index), the sorting operation, plus writing the segment, plus any wait time due to concurrent DML / locks, plus the time to process the table that holds the changes that were done to the table while building the index.
You can try to run an EXPLAIN PLAN on your create index statement which will give you a cost indication if you're using the cost based optimizer.
Please suggest me if any other way exists to perform in fastest way.Since you will need to sort 8 million rows, if you have sufficient memory you could bump up the SORT_AREA_SIZE for your session temporarily to sort as much as possible in RAM.
-- Use e.g. 100000000 to allow a 100M SORT_AREA_SIZE
ALTER SESSION SET SORT_AREA_SIZE = <something_large>;
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

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 another schema table stored in my table

Hi,
I want to create index on a table column which is in another schema from my schema and the index to be stored in my schema.
ex: current user 'hr'
sql>create index idx1 on scott.emp(eno);
Does the above query works??
thanks,
Sri

Why cant you give a try?
Are you getting any error message?
See below..
SQL> show user
USER is "SCOTT"
SQL> grant select on emp to hr;
Grant succeeded.
SQL> conn
Enter user-name: hr@***
Enter password:
Connected.
SQL> show user
USER is "HR"
SQL> create index ndx on scott.emp(sal);
create index ndx on scott.emp(sal)
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> conn
Enter user-name: system@*******
Enter password:
Connected.
SQL> create index ndx on scott.emp(sal);
Index created.
SQL> drop index ndx;
Index dropped.
SQL> grant create any index to hr;
Grant succeeded.
SQL> conn
Enter user-name: hr@*******
Enter password:
Connected.
SQL> create index ndx on scott.emp(sal);
Index created.Edited by: jeneesh on Oct 8, 2012 3:53 PM

Transport indexes created on a table?

Similar Messages

Maybe you are looking for