How to create indexes using CREATE TABLE statement

Hi,
Can anyone please tell me how to create indexes using CREATE TABLE staement? This point is part SQL Expert exam (1Z0-047) and please guide me to use which books for this particular exam.
Thanks in advance.

Can anyone please tell me how to create indexes using CREATE TABLE staement?e.g. creating a primary key or a unique constraint will generate indexes along with the create table syntax:
SQL> create table t (a integer primary key, b integer unique)
Table created.
SQL> select   index_name, index_type, uniqueness
from   user_indexes
where   table_name = 'T'
INDEX_NAME                     INDEX_TYPE                  UNIQUENES
SYS_C0016575                   NORMAL                      UNIQUE
SYS_C0016574                   NORMAL                      UNIQUE
2 rows selected.

Similar Messages

How to create index for particular table in R3

Hi
My load is taking too much time and it leads to process over due error. Does creating indexes on table in r3 side will solve this issue? If so how can we find out on which table does this particular data source depend. I went to maintain extract structure and findout only one table is supplying data for this data source.
Is there any other factors depend to solve this.
Thanks
kk

Hi,
it will depend on the table.... Having an index created will speed up the loading but slow down the insert therefore slowing some process perhaps...
May I ask which table it is? And which fields would you need to index?
Are you sure that bottleneck is located in R/3? Analyze your loading time in the monitor and see if this is really the case.
Otherwise you can create index for a table in Tx SE11; first check if an index is not already created...
hope this helps,
Olivier.

How many SECONDARY INDEXES are created for CLUSTER TABLES?

how many SECONDARY INDEXES are created for CLUSTER TABLES?
please explain.

There seems to be some kind of misunderstanding here. You cannot 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).

A query related to creating Indexes for a table

Hi ,
I am in a J2EE Banking Project using Oracle 10g as our Database .
We have created Indexes on some tables .
But this this is not called by any of our Java class .
Could anybody please let me know how these Indexes will actually improve the Performance .
Waiting for your replies .
Thanks in advance .

But in our safety database (huge & ofcourse Oracle), we use indexes just because to avoid duplicates, improve data retrieval and so on.As you pointed out indexes can do 2 things for you: enforce uniqueness and (hopefully) improve data retrieval. Enforcing uniqueness is pretty basic, but indexes don't always improve performance. Under the wrong condtions indexes can hurt performance. The ideas below refer to B-TREE indexes; other kinds of indexes have other considerations
Indexes add overhead to insert, delete, and (hopefully not - updating index columns is a Bad Idea), enough so that if you're inserting a lot of rows into a large table it is sometimes helpful to drop the indexes, load the data, and recreate the indexes when done to help performance. The more indexes a table has the more overhead DML statements need to maintain them.
Indexes help query performance under a couple of conditions. When using them as join keys to retrieve a small percentage of rows in a table (< 20% maybe; there is no firm number) indexes can help. When a query can read its columns from an index only (such as counts against a primary key index) index access can be faster than table access.
Indexes can hurt performance by adding overhead for maintenance if the index is never actually used or if used to read most of the rows in a table when a full table scan would be more efficient (why go through the extra effort to read the index and then table when you'll have to read most of the rows in the table anyway?).

When do I really need to create indexes for a table?

Once I was talking to a dba in a conference.
He told me that not always I have to create indexes for a single table, it depends of its size.
He said that Oracle read registers in blocks, and for a small table Oracle can read it fully, in a single operation, so in those cases I don't need indexes and statistcs.
So I would like to know how to calculate it.
When do I really need to create indexes for a table?
If someone know any documment that explain that, or have some tips, I'd aprecciate.
Thanks.
P.S.: The version that I'm using is Oracle 9.2.0.4.0.

Hi Vin
You mentioned so many mistakes here, I don't know where to begin ...
vprabhu_2000 wrote:
There are different kinds of Index. B-tree Index is by default. Bit map index, function based index,index organized table.
B-tree index if the table is large This is incorrect. Small tables, even those consisting of rows within just one block, can benefit from an index. There is no table size too small in which an index might not be benefical. William Robertson in his post references links to my blog where I discuss this.
and if you want to retrieve 10 % or less of data then B-tree index is good. This is all wrong as well. A FTS on a (say) million row table could very well be more efficient when retrieving (say) just 1% of data. An index could very well be more efficient when retrieving 100% of data. There's nothing special about 10% and there is no such magic number ...
>
Bit Map Index - On low cardinality columns like Sex for eg which could have values Male,Female create a bit map index. Completely and utterly wrong. A bitmap index might be the perfect type of index, better than a B-Tree, even if there are (say) 100,000 distinct values in the table. That a bitmap index is only suitable for low cardinality columns is just not true. And what if it's an OLTP application, with lot's of concurrent DML on the underlining table, do you really think a bitmap index would be a good idea ?
>
You can also create an Index organized table if there are less rows to be stored so data is stored only once in index and not in table. Not sure what you mean here but an IOT can potentially be useful if you have very large numbers of rows in the table. The number of rows has nothing to do with whether an IOT is suitable or not.
>
Hope this info helps. Considering most of it is wrong, I'm not sure it really helps at all :(
Cheers
Richard Foote
http://richardfoote.wordpress.com/

Creating Indexes in Cluster Tables

Hi,
I want to enable the index for the a cluster table..how is it possible..As we see for transparent tables like MSEG ,index tab is enabled but tables like BSEG the option is disabled..Please help me find a solution..
Regards
Maria

You cannot create index on cluster table in SAP.
BSEG is a cluster table, so no index, but hopefully there are "database indexes" on BSEG, which are actual database table : BSIS, BSAS, BSID, BSAS, and so on.
BSEG Access
BSAD Accounting: Secondary index for customers (cleared items)
BSAK Accounting: Secondary index for vendors (cleared items)
BSAS Accounting: Secondary index for G/L accounts (cleared items)
BSID Accounting: Secondary index for customers
BSIK Accounting: Secondary index for vendors
BSIM Secondary Index, Documents for Material
BSIS Accounting: Secondary index for G/L accounts
Create index on these tables.
Look also at
Re: Selecting data from BSEG.
Regards

Why should we create index on the table after inserting data ?

Please tell me the Reason, why should we create index on the table after inserting data .
while we can also create index on the table before insertion of the data.

The choice depends on a number of factors, the main being how many rows are going to be inserted in the table as a percentage of the existing rows, or the percentage growth.
Creating index after a table has been populated works better when the tables are large or the inserts are large for the following reasons
1. The sort and creation of index is more efficient when done in batch and written in bulk. So works faster.
2. When the index is being written blocks get acquired as more data gets written. So, when a large number of rows get inserted in a table that already has an index , the index data blocks start splitting / chaining. This increases the "depth" of the inverted b-tree makes and that makes the index less efficient on I/O. Creating index after data has been inserted allows Orale to create optical block distribution/ reduce splitting / chaining
3. If an index exists then it too is routed through the undo / redo processes. Thats an overhead which is avoided when you create index after populating the table.
Regards

Why Oracle not using the correct indexes after running table stats

I created an index on the table and ran the a sql statement. I found that via the explain plan that index is being used and is cheaper which I wanted.
Latter I ran all tables stats and found out again via explain plan that the same sql is now using different index and more costly plan. I don't know what is going on. Why this is happening. Any suggestions.
Thx

I just wanted to know the cost using the index.
To gather histograms use (method_opt is the one that causes the package to collect histograms)
DBMS_STATS.GATHER_SCHEMA_STATS (
ownname => 'SCHEMA',
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
block_sample => TRUE,
method_opt => 'FOR ALL COLUMNS SIZE AUTO',
degree => 4,
granularity => 'ALL',
cascade => TRUE,
options => 'GATHER'
);

Things to consider while Creating Indexes in the tables

Hi All,
We have some application slow issues becasue of the tables which it is calling are Heap. There are Primary keys created on few tables though. I have to think and design the indexing on those tables. What are different things need to check to design the Indexes?
Thanks
Swapna

Hi All,
We have some application slow issues becasue of the tables which it is calling are Heap. There are Primary keys created on few tables though. I have to think and design the indexing on those tables. What are different things need to check to design the Indexes?
Thanks
Swapna
Adding to what others have said create an index and check execution plan whether it is being used by optimizer or not if it is used and query runs fast that index can be kept
You should also take help of DMV
sys.dm_index_usage_stats to see whether index is being utilized or not. refer to user seek user update and user scan col. If Update is very much greater that seek/scan index is probably not utilized , you can consider removing it
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it.
My TechNet Wiki Articles

Problem while creating index for temporary table...

Hi,
i have created index for a temporary table and this script should used by multiusers.So when second user connecting to it is giving index i mean object already exists.
So what i need is when the second user connected the script should create one more index on temporary table.Will sql server provide any random way of creating indexes if the index exists already with that name??
Thank You,

Nope..
SQL Server is cleaver enough to handel this situation.
When you create a index or constraint on the Temp Table, eventhough the index name is duplicate it will allow.
But it only possible on temp tables (prefixed with single #).
To Test this,
Open Two window,
Execute the below window on the opened 2 window..
create table #test
id int
Insert Into #test values(1);
Insert Into #test values(2);
Create clustered index testindex on #test(id)
Now you wont get any error on any of the window. Rite?
To fetch the created index details, execute the below code on any one of the window..
select * from sysindexes where name like '%test%'
Now you can see the 2 rows with same indexname but refereing with different table. Yes. all the temp tables (#) will be suffixed with unique number to avoid the object already found error while multiple users connects.

Creating indexes in temprory table

Guys here is my temp table
-- Create table
create global temporary table EMP_TEMP
EMP_NO NUMBER(4),
EMP_SALARY NUMBER(7),
EMP_NAME VARCHAR2(30),
on commit preserve rows;
Now how can I created indexes on EMP_SALARY or EMP_NAME .I am not looking for primary or unique keys but just indexes.
I tried create index command but it say it is unsupported for temporory table.
please help.
thx

manushetty,
Index on temporary table, like data from temporary table, is not persistant. Also you cannot have storage clause, or tablespace...
From my index which I created above :
1 select index_name,tablespace_name,pct_free,
2         ini_trans,max_trans,initial_extent,min_extents,max_extents
3 from dba_indexes
4* where index_name = 'TOTI'
SQL> /
INDEX_NAME                     TABLESPACE_NAME                  PCT_FREE
INI_TRANS MAX_TRANS INITIAL_EXTENT MIN_EXTENTS MAX_EXTENTS
TOTI                                                                  10
         2        255
SQL> As you can see, there is no tablespace, and no storage clause (extent)
If I create the same index on a permanent table, all these parameters are not null :
SQL> create index toti on emp(sal);
Index created.
1 select index_name,tablespace_name,pct_free,
2         ini_trans,max_trans,initial_extent,min_extents,max_extents
3 from all_indexes
4* where index_name = 'TOTI'
SQL> /
INDEX_NAME                     TABLESPACE_NAME                  PCT_FREE
INI_TRANS MAX_TRANS INITIAL_EXTENT MIN_EXTENTS MAX_EXTENTS
TOTI                           SYSTEM                                 10
         2        255          65536           1 2147483645HTH,
Nicolas.

Creating index using XMLIndex, changes the result set when querying

Hi there,
I was tasked with populating an Oracle 11Gr2 database with data from 800,000 XML files. I used the Oracle documentation, and in about 2 days I had the data loaded into a simple table.
Queries of this table were SLOW, so this morning I read about using XMLIndex to index the table... I did this, and it works great -- the queries got a LOT faster.
However -- a "column" from my XML data is supposed to return values of 2000-4000 characters. It worked fine, until I created my index -- after I created the XMLIndex, the data is being truncated to 80 chars in my query.
CREATE TABLE TEST_XMLTABLE OF XMLType; /* XML data has a "node" called TEXT which can be up to 4000 chars */
SELECT to_number( extractValue(OBJECT_VALUE, 'newsitem/@itemid')) as ITEM_ID, Text.text <----- value here will contain full text body up to 4k chars
FROM TEST_XMLTABLE KTX,
XMLTABLE('/newsitem' PASSING ktx.Object_Value columns "TEXT" clob PATH 'text') TEXT
/* now create the index */
CREATE INDEX IDX_xmlindex ON TEST_XMLTABLE (OBJECT_VALUE) INDEXTYPE IS XDB.XMLIndex;
Now, run my query again, and TEXT.TEXT is truncated to only 80 chars!?!?!
I'm not sure what to do next... my users need the full text, so for now I have dropped the XMLIndex... the queries are slow, but they are getting all the data.
Thanks in advance for any help or ideas.
Keith

I still do not have an answer back from Oracle, regarding if this is a "bug" or not....
but for now, I have a "workaround" that seems to fix the problem. After I create the XMLIndex, I can remove the troublesome "path" from the index by doing an index rebuild, as shown:
ALTER INDEX IDX_xmlindex REBUILD PARAMETERS ('PATHS (EXCLUDE ADD (/newsitem/text))');
After I rebulld the index, I get all the chars in my TEXT node properly. However, the performance of the queries is noticably slower than before I did the ALTER INDEX.. albeit still faster than with no index at all.

When to create index on partitioned table ?

Hi,
The original table TEST1 contain one index called INDX_HIREDATE on field HIREDATE
CREATE TABLE TEST1(
COD NUMBER PRIMARY KEY,
HIREDATE DATE);
CREATE INDEX INDX_HIREDATE ON TEST1 (HIREDATE);
I created a example partitioned table as below:
CREATE TABLE TEST2_PART(
COD NUMBER PRIMARY KEY,
HIREDATE DATE)
PARTITION BY RANGE (HIREDATE)(
PARTITION P2003 VALUES LESS THAN (TO_DATE('01/01/2004','DD/MM/YYYY')),
PARTITION P2004 VALUES LESS THAN (TO_DATE('01/01/2005','DD/MM/YYYY')),
PARTITION P3000 VALUES LESS THAN (MAXVALUE));
INSERT /*+ APPEND */ INTO TEST2 SELECT * FROM TEST1;
Questions:
Need i to create the index on TEST2 table the same way done on the TEST1 table?
ex: CREATE INDEX INDX_HIREDATE ON TEST2 (HIREDATE);
or have i need to create the global/local index on each partition?
The Primary Key index is a global for partitions??
What is the best way?
Thanks

Index creation on partitioned tables is similar to the non-partitioned tables. There is no special syntax unless you need to create LOCAL indexes. For creating local indexes, add LOCAL key word at the end of the "create index...." command.
To create local primary key index you may need to use different syntax the one used in your create table command. Refer to SQL Reference manual for actual syntax. (remember manuals are the best place for getting quick answers). All the manuals are available online (at otn.oracle.com).

Creating a better update table statement

Hello,
I have the following update table statement that I would like to make more effecient. This thing is taking forever. A little background. The source table/views are not indexed and the larger of the two only has 150k records. Any ideas on making more effecient would be appreciate.
Thanks.
Ryan
Script:
DECLARE
V_EID_CIV_ID SBI_EID_W_VALID_ANUM_V.SUBJECT_KEY%TYPE;
V_EID_DOE     DATE;
V_EID_POE     SBI_EID_W_VALID_ANUM_V.POINT_OF_ENTRY%TYPE;
V_EID_APPR_DATE DATE;
V_CASE_CIV_ID     SBI_DACS_CASE_RECORDS.CASE_EID_CIV_ID%TYPE;
V_CASE_DOE     DATE;
V_CASE_POE SBI_DACS_CASE_RECORDS.CASE_CODE_ENTRY_PLACE%TYPE;
V_CASE_APPR_DATE           DATE;
V_CASE_DEPART_DATE           DATE;
V_SBI_UPDATE_STEP SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP%TYPE;
V_SBI_CIV_ID SBI_DACS_CASE_RECORDS.SBI_CIV_ID%TYPE;
CURSOR VALID_CIV_ID_FROM_EID IS
     SELECT EID.SUBJECT_KEY,
          TO_DATE(EID.PROCESS_ENTRY_DATE),
          EID.POINT_OF_ENTRY,
          TO_DATE(EID.APPREHENSION_DATE),
          DACS.CASE_EID_CIV_ID,
          TO_DATE(DACS.CASE_DATE_OF_ENTRY,'YYYYMMDD'),
          DACS.CASE_CODE_ENTRY_PLACE,
          TO_DATE(DACS.CASE_DATE_APPR,'YYYYMMDD'),
          TO_DATE(DACS.CASE_DATE_DEPARTED,'YYYYMMDD'),
          DACS.SBI_UPDATE_STEP,
          DACS.SBI_CIV_ID
     FROM SBI_EID_W_VALID_ANUM_V EID,
SBI_DACS_CASE_RECORDS DACS
WHERE DACS.CASE_NBR_A = EID.ALIEN_FILE_NUMBER;
     BEGIN
          OPEN VALID_CIV_ID_FROM_EID;
SAVEPOINT A;
          LOOP
               FETCH VALID_CIV_ID_FROM_EID INTO V_EID_CIV_ID, V_EID_DOE, V_EID_POE,V_EID_APPR_DATE,V_CASE_CIV_ID, V_CASE_DOE,V_CASE_POE,V_CASE_APPR_DATE,V_CASE_DEPART_DATE,V_SBI_UPDATE_STEP,V_SBI_CIV_ID;
DBMS_OUTPUT.PUT_LINE('BEFORE');
               EXIT WHEN VALID_CIV_ID_FROM_EID%FOUND;
DBMS_OUTPUT.PUT_LINE('AFTER');
          UPDATE SBI_DACS_CASE_RECORDS
SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_CASE_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 1
WHERE V_CASE_CIV_ID IS NOT NULL
AND V_CASE_CIV_ID <> 0;
UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 2
WHERE V_SBI_CIV_ID IS NULL AND V_SBI_UPDATE_STEP = 0
               AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE = V_CASE_POE
               AND V_EID_APPR_DATE = V_CASE_APPR_DATE
               AND V_EID_APPR_DATE = V_CASE_DEPART_DATE;
               UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 3
WHERE V_SBI_UPDATE_STEP = 0
               AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE = V_CASE_POE
               AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 4
WHERE V_SBI_UPDATE_STEP = 0
               AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE = V_CASE_POE
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4 ;
     UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 5
WHERE V_SBI_UPDATE_STEP = 0
               AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE <> V_CASE_POE
               AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 6
WHERE V_SBI_UPDATE_STEP = 0
               AND V_EID_POE = V_CASE_POE
               AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 7
WHERE V_SBI_UPDATE_STEP = 0
     AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
          UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 8
WHERE V_SBI_UPDATE_STEP = 0
AND V_EID_DOE = V_CASE_DOE
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4;
               UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 9
WHERE V_SBI_UPDATE_STEP = 0
AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE = V_CASE_POE;
          UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 10
WHERE V_SBI_UPDATE_STEP = 0
AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4;
          END LOOP;
          CLOSE VALID_CIV_ID_FROM_EID;
     COMMIT;
     END;
-----Thats it. Thanks for your help.
Ryan

Please use [ code] or [ pre] tags to format code before posing:
DECLARE
     V_EID_CIV_ID SBI_EID_W_VALID_ANUM_V.SUBJECT_KEY%TYPE;
     V_EID_DOE DATE;
     V_EID_POE SBI_EID_W_VALID_ANUM_V.POINT_OF_ENTRY%TYPE;
     V_EID_APPR_DATE DATE;
     V_CASE_CIV_ID SBI_DACS_CASE_RECORDS.CASE_EID_CIV_ID%TYPE;
     V_CASE_DOE DATE;
     V_CASE_POE SBI_DACS_CASE_RECORDS.CASE_CODE_ENTRY_PLACE%TYPE;
     V_CASE_APPR_DATE DATE;
     V_CASE_DEPART_DATE DATE;
     V_SBI_UPDATE_STEP SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP%TYPE;
     V_SBI_CIV_ID SBI_DACS_CASE_RECORDS.SBI_CIV_ID%TYPE;
     CURSOR VALID_CIV_ID_FROM_EID IS
          SELECT EID.SUBJECT_KEY,
           TO_DATE(EID.PROCESS_ENTRY_DATE),
           EID.POINT_OF_ENTRY,
           TO_DATE(EID.APPREHENSION_DATE),
           DACS.CASE_EID_CIV_ID,
           TO_DATE(DACS.CASE_DATE_OF_ENTRY,'YYYYMMDD'),
           DACS.CASE_CODE_ENTRY_PLACE,
           TO_DATE(DACS.CASE_DATE_APPR,'YYYYMMDD'),
           TO_DATE(DACS.CASE_DATE_DEPARTED,'YYYYMMDD'),
           DACS.SBI_UPDATE_STEP,
           DACS.SBI_CIV_ID
          FROM SBI_EID_W_VALID_ANUM_V EID,
           SBI_DACS_CASE_RECORDS DACS
          WHERE DACS.CASE_NBR_A = EID.ALIEN_FILE_NUMBER;
BEGIN
     OPEN VALID_CIV_ID_FROM_EID;
     SAVEPOINT A;
LOOP
     FETCH VALID_CIV_ID_FROM_EID INTO V_EID_CIV_ID, V_EID_DOE,
          V_EID_POE,V_EID_APPR_DATE,V_CASE_CIV_ID, V_CASE_DOE,
               V_CASE_POE,V_CASE_APPR_DATE,V_CASE_DEPART_DATE,V_SBI_UPDATE_STEP,V_SBI_CIV_ID;
     DBMS_OUTPUT.PUT_LINE('BEFORE');
     EXIT WHEN VALID_CIV_ID_FROM_EID%FOUND;
     DBMS_OUTPUT.PUT_LINE('AFTER');
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_CASE_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 1
     WHERE V_CASE_CIV_ID IS NOT NULL
      AND V_CASE_CIV_ID <> 0;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 2
     WHERE V_SBI_CIV_ID IS NULL AND V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE = V_CASE_POE
        AND V_EID_APPR_DATE = V_CASE_APPR_DATE
         AND V_EID_APPR_DATE = V_CASE_DEPART_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 3
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE = V_CASE_POE
        AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 4
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE = V_CASE_POE
        AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
         AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4 ;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 5
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE <> V_CASE_POE
        AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 6
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_POE = V_CASE_POE
       AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 7
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 8
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
        AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 9
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE = V_CASE_POE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 10
     WHERE V_SBI_UPDATE_STEP = 0
      AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
       AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4;
END LOOP;
CLOSE VALID_CIV_ID_FROM_EID;
COMMIT;
END;Peter D.

Unable to create Indexes on F table

Hi
We are unable to create Indexes on one of our Cube's fact table...I tried creating with Process chain , Batch and also tried with SE11 ...table name ... Indexes ...Activate...
Its showing active object generated but the warning msg Index does not exist in database system MSSQL still exist and not creating indexes...When I activate the indexes its not showing this warning for all other cubes...Please advice
regards

Hi Sam,.
The index creation on F table is taken care by the system itself. When you activate the cube, the DIM and F table are created and at the same time, indexes are created.
To create your own indes, though, go to se11...>F Table name-->Indeexes-it will show you system created indexes.
There will be a create sign....click there... and give the name of the index(like 1, 2). It will open up the maintain index page, where you have to mention all the parameter.
Thanbks...
Shambhu

How to create indexes using CREATE TABLE statement

Similar Messages

Maybe you are looking for