Partial insert with secondary index

I'd like to use partial inserts (DB_DBT_PARTIAL).
However, I also need secondary indexes. Now when I insert partial data, the secondary index function is immediately called, but still I do not have enough data to calculate the secondary key. I tried to supply some app_data do the DBT, but it does not reach the secondary index function.
Is there any way I can use partial inserts together with secondary indexes?

When writing a partial record to the primary database, here's what we do:
1. Look up the existing record via get()
2. Using the existing record and the partial DBT, construct the new record
3. Pass that newly constructed record to the secondary key generation function
You don't need to do anything special, your callback will receive the full record, even though you passed us a partial DBT. If that's not the case, there's a bug in BDB and we'd need to see your code.
app_data is a private field, you should not try to use it or expect it to work predictably. In this situation, we're passing a brand new DBT to the callback function, not the DBT you gave us. That's why app_data is empty.
Thanks,
Bogdan Coman

Similar Messages

How to rename database with secondary indexes.

Hi,
could somebody advise how to run correct next operation:
I have database with secondary indexes in a single file and I need to rename that db file.
As I understand I have to
1) close and delete all database handles
2) remove from db file all secondary indexes with DbEnv::dbremove
3) rename db file with DbEnv::dbrename
4) create primary db
5) create once again all secondary indexes and associate them with primary db
Appreciate in advance.

Hi,
Your question has two possible cases:
1. A single file contains main DB and its secondary indexes.
2. A file contains several secondary indexes of main DB, another file contains the main DB.
For the first case, the main database could be renamed directly, but all of the secondary databases do not continue to work. That means no new index items will be added automatically into exist secondary databases. So these secondary databases should be removed and created, you could also just run a DB->associate to re-associate it again. But in the later way, the re-associated secondary DB won't automatic index these records that are added before associating.
That means, if main db is renamed and then inserted a record 'A'. Then secondary DB is re-associated to main db. The secondary DB still does not index record 'A'. And currently there is not method to let secondary DB manually index 'A' again. So it is better to remove and create a new secondary DB with DB_CREATE flag. That will make the new secondary DB scan current items and index them.
For the second case, the result is the same, main database could be remained directly. Then all of the secondary databases should be re-created or re-associated. Still for the described reason, we prefer the first way.
And, removing old secondary databases before renaming main database is also work in above cases.
Thanks,
Victor Yang

Select query with secondary index

hi,
i have a report which is giving performance issues on a perticular select query on KONH table.
the select query doesnt use the primary key fields and table already has around 19 million entries.So there was a secondary index created for the fields in the table.
now, KONH is a client specific table, and hence has MANDT as the first field. when the table is not indexed it is sorted according to the order of fields, like first MANDT, then primary key fields and then remaining fields.. (correct me if i am wrong)
but the secondary index created doesnt has MANDT in it..(yea, a mistake! )...
but instead of correccting the secondary index, i am told to change the select query..
so, i used a "client specific" syntax to sort the issue.. but i dont understand whre i should put the "where mandt eq sy-mandt" clause..
should i put it right after all my secondary index fields are over? or what happens to the order of fields which are not present in the list of secondary index?
kindaly help.
thanx.

Hi chinmay kulkarni,
its better if you can ask concerned person to add MANDT field in your index as well....
Indexes and MANDT
If a table begins with the mandt field, so should its indexes. If a table begins with mandt and an index doesn't, the optimizer might not use the index.
Remember, if you will, Open SQL's automatic client handling feature. When select * from ztxlfa1 where land1 = 'US' is executed, the actual SQL sent to the database is select * from ztxlfa1 where mandt = sy-mandt and land1 = 'US'. Sy-mandt contains the current logon client. When you select rows from a table using Open SQL, the system automatically adds sy-mandt to the where clause, which causes only those rows pertaining to the current logon client to be found.
When you create an index on a table containing mandt, therefore, you should also include mandt in the index. It should come first in the index, because it will always appear first in the generated SQL.
Index: Technical key of a database table.
Primary index: 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.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
For Example...
SELECT KUNNR KUNN2 INTO TABLE T_CUST_TERR
FROM KNVP CLIENT SPECIFIED
WHERE MANDT = SY-MANDT " here MANDT shd be first
AND KUNN2 IN S_TERR
AND PARVW LIKE 'Z%'.
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Also pls have a look on below link
http://www.sapfans.com/sapfans/forum/devel/messages/30240.html
Hope it will solve your problem..
Reward points if useful...
Thanks & Regards
ilesh 24x7

Performance problem at bulk insert with spatial index

Hi,
I have a table with SDO_GEOMETRY.
Insert without spatial index is very fast, but with active spatial index it's very slow.
So for the first big import of data, I can drop the index, import the data and again create the index. Thats 10 times faster!
But for an already very big table that is no option.
The 10g1-Users Guide (1) says at 4.1.3 that the spatial index should be set to 'deferred', the data should be inserted and than the index should be synchronized again. That sounds very good, but I can't find this at the 11g1-Users Guide.
I tried it (11g1), but the performance is even worse than with active index!
What could be my mistake? Any hints?
Thank you,
Bjoern Weitzig
create table sggeoptcollection (pt SDO_GEOMETRY);
CREATE INDEX myIdx ON sggeoptcollection (pt) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS('sdo_indx_dims=2, layer_gtype=point, sdo_rtr_pctfree=50');
ALTER INDEX myIdx PARAMETERS ('index_status=deferred');
Big import with batch'ed PreparedStatements
ALTER INDEX myIdx PARAMETERS ('index_status=synchronize sdo_batch_size=500');
1) http://download.oracle.com/docs/html/B10826_01/sdo_index_query.htm#g1010227

Hi,
I have a table with SDO_GEOMETRY.
Insert without spatial index is very fast, but with active spatial index it's very slow.
So for the first big import of data, I can drop the index, import the data and again create the index. Thats 10 times faster!
But for an already very big table that is no option.
The 10g1-Users Guide (1) says at 4.1.3 that the spatial index should be set to 'deferred', the data should be inserted and than the index should be synchronized again. That sounds very good, but I can't find this at the 11g1-Users Guide.
I tried it (11g1), but the performance is even worse than with active index!
What could be my mistake? Any hints?
Thank you,
Bjoern Weitzig
create table sggeoptcollection (pt SDO_GEOMETRY);
CREATE INDEX myIdx ON sggeoptcollection (pt) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS('sdo_indx_dims=2, layer_gtype=point, sdo_rtr_pctfree=50');
ALTER INDEX myIdx PARAMETERS ('index_status=deferred');
Big import with batch'ed PreparedStatements
ALTER INDEX myIdx PARAMETERS ('index_status=synchronize sdo_batch_size=500');
1) http://download.oracle.com/docs/html/B10826_01/sdo_index_query.htm#g1010227

What is syntax for inner join of Select statement with Secondary Index

Hi Genies,
                Here i have created the Secondary index for table COEP and also used for select query but there is no improvement in runtime . taking same time for select query without index as well as with index. my code is
SELECT * INTO CORRESPONDING FIELDS OF TABLE ITAB_COEP FROM COEP AS A
             INNER JOIN COBK AS B ON ( A~BELNR = B~BELNR AND A~KOKRS = B~KOKRS AND A~GJAHR = B~GJAHR )
             WHERE A~OBJNR = OBJNR
             AND A~GJAHR = CURRY
             AND B~GJAHR = CURRY
             AND A~RBEST = ''
             AND A~BEKNZ = 'S'
             AND B~BELNR NE WA_COBK-BELNR
             AND B~AWREF_REV = ''
             AND B~AWORG_REV = ''
             AND B~KOKRS = WA_COIOB-KOKRS
             AND B~BLDAT BETWEEN START_DATE AND END_DATE
             AND B~BLART IN ('SA','KA','KR','AB') %_HINTS ORACLE 'INDEX("COEP" "COEP~ZBU")'.
index name is ZBU.
please any one let me know is there any syntax mistakes? but while checking and during the runtime it does'nt shows any error.
Regards,
        Thangam.P

Hi Genies,
                Here i have created the Secondary index for table COEP and also used for select query but there is no improvement in runtime . taking same time for select query without index as well as with index. my code is
SELECT * INTO CORRESPONDING FIELDS OF TABLE ITAB_COEP FROM COEP AS A
             INNER JOIN COBK AS B ON ( A~BELNR = B~BELNR AND A~KOKRS = B~KOKRS AND A~GJAHR = B~GJAHR )
             WHERE A~OBJNR = OBJNR
             AND A~GJAHR = CURRY
             AND B~GJAHR = CURRY
             AND A~RBEST = ''
             AND A~BEKNZ = 'S'
             AND B~BELNR NE WA_COBK-BELNR
             AND B~AWREF_REV = ''
             AND B~AWORG_REV = ''
             AND B~KOKRS = WA_COIOB-KOKRS
             AND B~BLDAT BETWEEN START_DATE AND END_DATE
             AND B~BLART IN ('SA','KA','KR','AB') %_HINTS ORACLE 'INDEX("COEP" "COEP~ZBU")'.
index name is ZBU.
please any one let me know is there any syntax mistakes? but while checking and during the runtime it does'nt shows any error.
Regards,
        Thangam.P

Drilling down slow - Something wrong with Secondary Indexes

Hi,
I have a cube that on the whole works very well, but periodically when I drill down to some characteristics it runs extremely slowly.
The cube is in a our Test environment and is not being updated with data.
When I go to RSA1[Select Cube] Manage>Performance, the DB indexes are now green after reactivating the cube and recreating the indexes.
Yet, when I drill down to certain characteristics, I can see in SM50 the query is doing a sequential read. It looks as if the secondary index on this dimension is not doing its job or being ignored.
I have tried Checking the Cube Database Indexes in RSRV and all is okay. The Master Data in the relevant dimension all seems to be active.
Any suggestions on how to get to the bottom of this would be much appreciated.
A trace on the SQL is showing the following statement taking excessive time:
Select * from RSDCHABAS where CHABASNM = ? and OBJVERS = ?.
I'm not sure why it's getting stuck on this table and it just list of InfoObjects. It is not reading from the actual cube in this statement.
Regards
Adrian

Hi Adrian,
In BW we are while tranforming data from source system we are using this table to dump the data in table RSDCHABAS. Which is nothing but use as buffer.
Basically this issue is due to low Temporary memory available on the system. Please check Temp memory available in DB02 and send this to your basis team to clear / entend this temp memory.
This will deffinately resolve this error.
Regards,
Mahesh

Performance of insert with spatial index

I'm writing a test that inserts (using OCI) 10,000 2D point geometries (gtype=2001) into a table with a single SDO_GEOMETRY column. I wrote the code doing the insert before setting up the index on the spatial column, thus I was aware of the insert speed (almost instantaneous) without a spatial index (with layer_gtype=POINT), and noticed immediately the performance drop with the index (> 10 seconds).
Here's the raw timing data of 3 runs in each 3 configuration (the clock ticks every 14 or 15 or 16 ms, thus the zero when it completes before the next tick):
                                   truncate execute commit
no spatial index                     0.016   0.171   0.016
no spatial index                     0.031   0.172   0.000
no spatial index                     0.031   0.204   0.000
index (1000 default for batch size) 0.141 10.937   1.547
index (1000 default for batch size) 0.094 11.125   1.531
index (1000 default for batch size) 0.094 10.937   1.610
index SDO_DML_BATCH_SIZE=10000       0.203 11.234   0.359
index SDO_DML_BATCH_SIZE=10000       0.094 10.828   0.344
index SDO_DML_BATCH_SIZE=10000       0.078 10.844   0.359As you can see, I played with SDO_DML_BATCH_SIZE to change the default of 1,000 to 10,000, which does improve the commit speed a bit from 1.5s to 0.35s (pretty good when you only look at these numbers...), but the shocking part of the almost 11s the inserts are now taking, compared to 0.2s without an index: that's a 50x drop in peformance!!!
I've looked at my table in SQL Developer, and it has no triggers associated, although there has to be something to mark the index as dirty so that it updates itself on commit.
So where is coming the huge overhead during the insert???
(by insert I mean the time OCIStmtExecute takes to run the array-bind of 10,000 points. It's exactly the same code with or without an index).
Can anyone explain the 50x insert performance drop?
Any suggestion on how to improve the performance of this scenario?
To provide another data point, creating the index itself on a populated table (with the same 10,000 points) takes less than 1 second, which is consistent with the commit speeds I'm seeing, and thus puzzles me all the more regarding this 10s insert overhead...
SQL> set timing on
SQL> select count(*) from within_point_distance_tab;
COUNT(*)
     10000
Elapsed: 00:00:00.01
SQL> CREATE INDEX with6CDF1526$point$idx
2            ON within_point_distance_tab(point)
3    INDEXTYPE IS MDSYS.SPATIAL_INDEX
4    PARAMETERS ('layer_gtype=POINT');
Index created.
Elapsed: 00:00:00.96
SQL> drop index WITH6CDF1526$POINT$IDX force;
Index dropped.
Elapsed: 00:00:00.57
SQL> CREATE INDEX with6CDF1526$point$idx
2            ON within_point_distance_tab(point)
3    INDEXTYPE IS MDSYS.SPATIAL_INDEX
4    PARAMETERS ('layer_gtype=POINT SDO_DML_BATCH_SIZE=10000');
Index created.
Elapsed: 00:00:00.98
SQL>

Thanks for your input. We are likely to use partioning down the line, but what you are describing (partition exchange) is currently beyond my abilities in plain SQL, and how this could be accomplished from an OCI client application without affecting other users and keep the transaction boundaries sounds far from trivial. (i.e. can it made transparent to the client application, and does it require privileges the client does have???). I'll have to investigate this further though, and this technique sounds like one accessible to a DBA only, not from a plain client app with non-privileged credentials.
The thing that I fail to understand though, despite your explanation, is why the slow down is not entirely on the commit. After all, documentation for the SDO_DML_BATCH_SIZE parameter of the Spatial index implies that the index is updated on commit only, where new rows are fed 1,000 or 10,000 at a time to the indexing engine, and I do see time being spent during commit, but it's the geometry insert that slow down the most, and that to me looks quite strange.
It's so much slower that it's as if each geometry was indexed one at a time, when I'm doing a single insert with an array bind (i.e. equivalent to a bulk operation in PL/SQL), and if so much time is spend during the insert, then why is any time spent during the commit. In my opinion it's one or the other, but not both. What am I missing? --DD

Insert with unique index slow in 10g

Hi,
We are experiencing very slow response when a dup key is inserted into a table with unique index under 10g. the scenario can be demonstrated in sqlplus with 'timing on':
CREATE TABLE yyy (Col_1 VARCHAR2(5 BYTE) NOT NULL, Col_2 VARCHAR2(10 BYTE) NOT NULL);
CREATE UNIQUE INDEX yyy on yyy(col_1,col_2);
insert into yyy values ('1','1');
insert into yyy values ('1','1');
the 2nd insert results in "unique constraint" error, but under our 10g the response time is consistently in the range of 00:00:00.64. The 1st insert only took 00:00:00.01. BTW, if no index or non-unique index then you can insert many times and all of them return fast. Under our 9.2 DB the response time is always under 00:00:00.01 with no-, unique- and non-unique index.
We are on AIX 5.3 & 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production.
Has anybody seen this scenario?
Thanks,
David

It seems that in 10g Oracle simply is doing something more.
I used your example and run following script on 9.2 and 10.2. Hardware is the same i.e. these are two instances on the same box.
begin
for i in 1..10000 loop
    begin
      insert into yyy values ('1','1');
    exception when others then null;
    end;
end loop;
end;
/on 10g it took 01:15.08 and on 9i 00:47.06
Running trace showed that in 9i there was difference in plan of following recursive sql:
9i plan:
select c.name, u.name
from
con$ c, cdef$ cd, user$ u where c.con# = cd.con# and cd.enabled = :1 and
c.owner# = u.user#
call     count       cpu    elapsed       disk      query    current        rows
Parse    10000      0.43       0.43          0          0          0           0
Execute 10000      1.09       1.07          0          0          0           0
Fetch    10000      0.23       0.19          0      20000          0           0
total    30000      1.76       1.70          0      20000          0           0
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 2)
Rows     Row Source Operation
      0 NESTED LOOPS
      0   NESTED LOOPS
      0    TABLE ACCESS BY INDEX ROWID CDEF$
      0     INDEX RANGE SCAN I_CDEF4 (object id 53)
      0    TABLE ACCESS BY INDEX ROWID CON$
      0     INDEX UNIQUE SCAN I_CON2 (object id 49)
      0   TABLE ACCESS CLUSTER USER$
      0    INDEX UNIQUE SCAN I_USER# (object id 11)10g plan
select c.name, u.name
from
con$ c, cdef$ cd, user$ u where c.con# = cd.con# and cd.enabled = :1 and
c.owner# = u.user#
call     count       cpu    elapsed       disk      query    current        rows
Parse    10000      0.21       0.20          0          0          0           0
Execute 10000      1.20       1.31          0          0          0           0
Fetch    10000      2.37       2.59          0      20000          0           0
total    30000      3.79       4.11          0      20000          0           0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 2)
Rows     Row Source Operation
      0 HASH JOIN (cr=2 pr=0 pw=0 time=301 us)
      0   NESTED LOOPS (cr=2 pr=0 pw=0 time=44 us)
      0    TABLE ACCESS BY INDEX ROWID CDEF$ (cr=2 pr=0 pw=0 time=40 us)
      0     INDEX RANGE SCAN I_CDEF4 (cr=2 pr=0 pw=0 time=27 us)(object id 53)
      0    TABLE ACCESS BY INDEX ROWID CON$ (cr=0 pr=0 pw=0 time=0 us)
      0     INDEX UNIQUE SCAN I_CON2 (cr=0 pr=0 pw=0 time=0 us)(object id 49)
      0   TABLE ACCESS FULL USER$ (cr=0 pr=0 pw=0 time=0 us)So in 10g it had hash join instead of nested loop join at least for this particular select. Probably time to gather stats on sys tables?
The difference in time wasn't so big though 4.11 vs 1.70 so it doesn't explain all the time taken.
But you can probably check whether you haven't more difference.
Also you can download Thomas Kyte runstats_pkg and run it on both environments to compare whether some stats or latches haven't very big difference.
Gints Plivna
http://www.gplivna.eu

Partial fields of Secondary index being used by the DB Optimizer

Hello,
I have written the following Query to select an std. SAP Index from GLPCA~1. However, when i run the SQL trace although the index is selected by the DB optimizer the results say that only 3 matching columns were used.
bold Index GLPCA~1. bold
KOKRS
RYEAR
RPRCTR
RVERS
RACCT
    SELECT rldnr
           rrcty
           rvers
           ryear
           rtcur
           rpmax
           rbukrs
           rprctr
           rfarea
           kokrs
           racct
           hslvt
           hsl01
           hsl02
           hsl03
           hsl04
           hsl05
           hsl06
           hsl07
           hsl08
           hsl09
           hsl10
           hsl11
           hsl12
           kslvt
           ksl01
           ksl02
           ksl03
           ksl04
           ksl05
           ksl06
           ksl07
           ksl08
           ksl09
           ksl10
           ksl11
           ksl12
           FROM glpct
           INTO TABLE i_glpct
           WHERE kokrs = 'BFS'
              AND ryear = p_gjahr
              AND rprctr IN r_prctr
              AND rvers = '000'
              AND racct IN r_acct.
Now i am not sure which of the above 3 fields of the where condition are being selected but probably KOKRS and RVERS are not being used by the optimizer.
Any pointers on how to make the optimizer utilize all 5 fields would be greatly appreciated.
Thanks,
Minhaj.

Hello,
I have written the following Query to select an std. SAP Index from GLPCA~1. However, when i run the SQL trace although the index is selected by the DB optimizer the results say that only 3 matching columns were used.
bold Index GLPCA~1. bold
KOKRS
RYEAR
RPRCTR
RVERS
RACCT
    SELECT rldnr
           rrcty
           rvers
           ryear
           rtcur
           rpmax
           rbukrs
           rprctr
           rfarea
           kokrs
           racct
           hslvt
           hsl01
           hsl02
           hsl03
           hsl04
           hsl05
           hsl06
           hsl07
           hsl08
           hsl09
           hsl10
           hsl11
           hsl12
           kslvt
           ksl01
           ksl02
           ksl03
           ksl04
           ksl05
           ksl06
           ksl07
           ksl08
           ksl09
           ksl10
           ksl11
           ksl12
           FROM glpct
           INTO TABLE i_glpct
           WHERE kokrs = 'BFS'
              AND ryear = p_gjahr
              AND rprctr IN r_prctr
              AND rvers = '000'
              AND racct IN r_acct.
Now i am not sure which of the above 3 fields of the where condition are being selected but probably KOKRS and RVERS are not being used by the optimizer.
Any pointers on how to make the optimizer utilize all 5 fields would be greatly appreciated.
Thanks,
Minhaj.

Performance issue when inserting into spatial indexed table with JDBC

We have a table named 'feature' which has a "sdo_geometry" column, and we created spatial index on that column,
CREATE TABLE feature ( id number, desc varchar, oshape sdo_gemotry)
CREATE INDEX feature_sp_idx ON feature(oshape) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
Then we executed the following SQL to insert about 800 records into that table(We tried this by using DB visualizer and
our Java application, both of them were using JDBC driver to connect to the oracle 11gR2 database) .
insert into feature(id,desc,oshape) values (1001,xxx,xxxxx);
insert into feature (id,desc,oshape) values (1002,xxx,xxxxx);
insert into feature (id,desc,oshape) values (1800,xxx,xxxxx);
We encoutered the same problem as this topic
Performance of insert with spatial index
It takes nearly 1 secs for inserting one record,compare to 50 records inserted per sec without spatial index,
which is 50x drop in peformance when doing insertion with spatial index.
However, when we copy and paste those insertion scripts into Oracle Client(same test and same table with spatial index), we got a totally different performance result:
more than 50 records inserted in 1 secs, just as fast as the insertion without building spatial index.
Is it because Oracle Client is not using JDBC? Perhaps JDBC was got something wrong when updating those spatial indexed tables.
Edited by: 860605 on 19/09/2011 18:57
Edited by: 860605 on 19/09/2011 18:58
Edited by: 860605 on 19/09/2011 19:00

Normally JDBC use auto-commit. So each insert can causes a commit.
I don't know about Oracle Client. In sqlplus, insert is just a insert,
and you execute "commit" to explicitly commit your changes.
So maybe this is the reason.

Secondary Index with or without MANDT field

HI ABAP Guru's,
What is necessary to add field MANDT while creation of secodary index in DBS.
But i some body my superiors challanged to me with out using MANDT our secoday index won't works.
But i tested few scenarios i am not get differnce.
please advice me exactly which scenarios it is mandatory.
Below are the Time taken with deffrent scnarios i created one test program to get the time with secondary index with out secodary index secondary index with mndat fiels
**&with out creation of seconday index
*1st time -57,103,681
2nd Time-55,388,294
**before creation of seconday index with out mandt
I1st time execution-324,119
2nd time progrm execution--391,134
3rd time progrm execution-327,046
4th time progrm execution336,774
5th time progrm execution359,100
6t time progrm execution-328,027
*before creation of seconday index with mandtiI1st time execution-367,623
2nd time progrm execution365,139
3rd-352,328
4th-369,122
5th-352,236
6th380,590
7th466,810
Thanks In Advance,
Kandula.
Edited by: Thomas Zloch on Nov 18, 2011 1:08 PM

Vishnu Tallapragada wrote:
So if you are maintaining multiple client data on the same database, then not adding MANDT to index will have undesirable effects as any select based on secondary index may return records that are not belonging to this client and deletes and additions on the index from multiple clients will lead to data integrity issues.
Wrong!
WHERE clause decides about data being selected, deleted or what-ever.
Index decides only about HOW data is accessed (if used), not WHAT data is accessed.
If your database returns a different result depending on the indexdefinition,
you should log a call at your DB vendor immediately, because this is a bug.
In general, as the client has usually only a small number of distinct values, it is not a good field,
to convince the database, that this index is a good idea. But on high volume tables it can be very selective
as far as the number of result records is concerned (might cut down 50% when 2 clients!).
In addition it is a very short field, so it should not cost much storage (esp. when compressable).
Szenario:
MANDT+IDX-Field with two clients and lets say 5000 record per client (so that idx access will be interesting),
assuming a given IDX value will return 50 records (25 in each client).
So the select will be
... WHERE MANDT=sy-mandt AND IDX=value
Accesing the index with only IDX will result in stepping down the index-tree (say 3 blocks) and then reading leafblocks
to get the 50 hits for IDX-value (assuming 30 records per leafblock -> 2 leafblocks required to gret the 50 records)
Right now you have accessed 5 blocks to get the address of 50 records that still need to be checked against MANDT.
So there is need to get 50 blocks (may be less, depending on clustering) to do a filter on MANDT
and get the final 25 records for the result.
If you put the MANDT field into the index it might require more space, so that we assume 20 records per leaf block now.
But since you can now filter MANDT already on the index blocks, you will again only need to get 5 blocks and
have the adress of the required 25 target records.
So getting the result is 55 blockinspections without MANDT in index and 30 blockinspections with MANDT in index in this case.
Now you can start pushing around values and statistics an calculate at what amount of data and average
size of resultsets it becomes right or wrong to include MANDT. It may turn out both ways, allthough I think
with MANDT being small, it is usually loss of brain cycles to calculate around for this.
You simply include it, it will cost only little space and it will never be wrong.
You leave it out, you will gain little space, but might end up with performance loss.
If you have only one client in the system, you can safely go with the saving space strategie, as long as you do not need
a UNIQUE secondary index.
Volker

Constantly inserting into large table with unique index... Guidance?

Hello all;
So here is my world. We have central to our data monitoring system an oracle database running Oracle Standard One (please don't laugh... I understand it is comical) licensing.
This DB is about 1.7 TB of small record data.
One table in particular (the raw incoming data, 350gb, 8 billion rows, just in the table) is fed millions of rows each day in real time by two to three main "data collectors" or what have you. Data must be available in this table "as fast as possible" once it is received.
This table has 6 columns (one varchar usually empty, a few numerics including a source id, a timestamp and a create time).
The data is collect in chronological order (increasing timestamp) 90% of the time (though sometimes the timestamp may be very old and catch up to current). The other 10% of the time the data can be out of order according to the timestamp.
This table has two indexes, unique (sourceid, timestamp), and a non unique (create time). (FYI, this used to be an IOT until we had to add the second index on create time, at which point a secondary index on create time slowed the IOT to a crawl)
About 80% of this data is removed after it ages beyond 3 months; 20% is retained as "special" long term data (customer pays for longer raw source retention). The data is removed using delete statements. This table is never (99.99% of the time) updated. The indexes are not rebuilt... ever... as a rebuild is about a 20+ hour process, and without online rebuilds since we are standard one, this is just not possible.
Now what we are observing is that the inserts into this table
- Inserts are much slower based on a "wider" cardinality of the "sourceid" of the data being inserted. What I mean is that 10,000 inserts for 10,000 sourceid (regardless of timestamp) is MUCH, MUCH slower than 10,000 inserts for a single sourceid. This makes sense to me, as I understand it that oracle must inspect more branches of the index for uniqueness, and more different physical blocks will be used to store the new index data. There are about 2 million unique sourceId across our system.
- Over time, oracle is requesting more and more ram to satisfy these inserts in a timely matter. My understanding here is that oracle is attempting to hold the leafs of these indexes perpetually buffers. Our system does have a 99% cache hit rate. However, we are seeing oracle requiring roughly 10GB extra ram per quarter to 6 months; we're at about 50gb of ram just for oracle already.
- If I emulate our production load on a brand new, empty table / indexes, performance is easily 10x to 20x faster than what I see when I do the same tests with the large production copies of data.
We have the following assumption: Partitioning this table based on good logical grouping of sourceid, and then timestamp, will help reduce the work required by oracle to verify uniqueness of data, reducing the amount of data that must be cached by oracle, and allow us to handle our "older than 3 month" at a partition level, greatly reducing table and index fragmentation.
Based on our hardware, its going to be about a million dollar hit to upgrade to Enterprise (with partitioning), plus a couple hundred thousand a year in support. Currently I think we pay a whopping 5 grand a year in support, if that, total oracle costs. This is going to be a huge pill for our company to swallow.
What I am looking for guidance / help on, should we really expect partitioning to make a difference here? I want to get that 10x performance difference back we see between a fresh empty system, and our current production system. I also want to limit oracles 10gb / quarter growing need for more buffer cache (the cardinality of sourceid does NOT grow by that much per quarter... maybe 1000s per quarter, out of 2 million).
Also, please I'd appreciate it if there were no mocking comments about using standard one up to this point :) I know it is risky and insane and maybe more than a bit silly, but we make due with what we have. And all the credit in the world to oracle that their "entry" level system has been able to handle everything we've thrown at it so far! :)
Alright all, thank you very much for listening, and I look forward to hear the opinions of the experts.

Hello,
Here is a link to a blog article that will give you the right questions and answers which apply to your case:
http://jonathanlewis.wordpress.com/?s=delete+90%25
As far as you are deleting 80% of your data (old data) based on a timestamp, then don't think at all about using the direct path insert /*+ append */ as suggested by one of the contributors to this thread. The direct path load will not re-use any free space made by the delete. You have two indexes:
(a) unique index (sourceid, timestamp)
(b) index(create time)
Your delete logic (based on arrival time) will smatch your indexes as far as you are always deleting the left hand side of the index; it means you will have what we call a right hand index - In other words, the scattering of the index key per leaf block is certainly catastrophic (there is an oracle iternal function named sys_op_lidbid that will allow you to verify this index information). There is a fairly chance that your two indexes will benefit from a coalesce as already suggested:
           ALTER INDEX indexname COALESCE;This coalesce should be investigated to be done on a regular basis (may be after each 80% delete) You seem to have several sourceid for one timestamp. If the answer is yes you should think about compressing this index
    create index indexname (sourceid, timestamp) compress;
or
    alter index indexname rebuild compress;     You will do it only once. Your index will have a smaller size and may be more efficient than it is actually. The index compression will add an extra CPU work during an insert but it might help improving the overal insert process.
Best Regards
Mohamed Houri

Secondary Index Picked with one field short in select query

Hi,
We have a select query as follows
select single lgort       vgbel        vgpos
    into   (lips-lgort,lips-vgbel,lips-vgpos)
    from    lips
   where         vbeln          Eq p_zlcpp-vbeln
     and         matnr          Eq p_zlcpp-matnr
     and         charg          Eq p_zlcpp-charg
The secondary index ZB has the fields as follows:
MANDT     Client
MATNR     Material Number
CHARG     Batch Number
BWART     Movement Type (Inventory Management)
When seen in the trace it seems the select query picks this secondary index. Whether it is correct? since i find no BWART in the select query. Because of this index the query take large time. I used the Hint statement as follows:
select single lgort       vgbel        vgpos
    into   (lips-lgort,lips-vgbel,lips-vgpos)
    from    lips
   where         vbeln          Eq p_zlcpp-vbeln
     and         matnr          Eq p_zlcpp-matnr
     and         charg          Eq p_zlcpp-charg   %_HINTS ORACLE 'INDEX("LIPS" "LIPS~0")' .
and it now works fast. Please advice the best way to make the select query work on itself without using the hint statement to pick the index LIPS~0 instead of the invalid secondary index ZB.
Thanks & Regards,
Selvakumar M.
Edited by: Selva on Jun 17, 2011 7:35 PM

Hello Selva,
your problem here is the decision of the optimizer that does not exactly know the selectivity of the fields.
If your deliveries are normally small (not too many items), then selecting via the document number will be relatively fast.
And selecting via the material number + batch will be slow in case if many deliveries are having same product from the same batch delivered.
I assume that the latest is the case in your system. That's why the selection with ZB index is slow.
If the data distribution is as I described above, then your hint is quite OK and I advise you to stick to the hint.
From my PoV this is the better solution rather changing the coding and throwing out MATNR field from the WHERE clause to filter later in ABAP.
Another solution would be trying to play with histograms. But you'll need %SUBSTITUTE VALUES% or %SUBSTITUTE LITERALS% hint anyway, so I find your solution better.
So, please stay with hint. Even SAP standard development does it for some select statements.
Regards,
Yuri

Insert problem using a SELECT from table with a index by function TRUNC

I came across this problem when trying to insert from a select statement, the select returns the correct results however when trying to insert the results into a table, the results differ. I have found a work around by forcing an order by on the select, but surely this is an Oracle bug as how can the select statements value differ from the insert?
Platform: Windows Server 2008 R2
Oracle 11.2.3 Enterprise edition
(I have not tried to replicate this on other versions)
Here are the scripts to create the two tables and source data:
CREATE TABLE source_data
ID                 NUMBER(2),
COUNT_DATE      DATE
CREATE INDEX IN_SOURCE_DATA ON SOURCE_DATA (TRUNC(count_date, 'MM'));
INSERT INTO source_data VALUES (1, TO_DATE('20120101', 'YYYYMMDD'));
INSERT INTO source_data VALUES (1, TO_DATE('20120102', 'YYYYMMDD'));
INSERT INTO source_data VALUES (1, TO_DATE('20120103', 'YYYYMMDD'));
INSERT INTO source_data VALUES (1, TO_DATE('20120201', 'YYYYMMDD'));
INSERT INTO source_data VALUES (1, TO_DATE('20120202', 'YYYYMMDD'));
INSERT INTO source_data VALUES (1, TO_DATE('20120203', 'YYYYMMDD'));
INSERT INTO source_data VALUES (1, TO_DATE('20120301', 'YYYYMMDD'));
INSERT INTO source_data VALUES (1, TO_DATE('20120302', 'YYYYMMDD'));
INSERT INTO source_data VALUES (1, TO_DATE('20120303', 'YYYYMMDD'));
CREATE TABLE result_data
ID                 NUMBER(2),
COUNT_DATE      DATE
);Now run the select statement:
SELECT id, TRUNC(count_date, 'MM')
FROM source_data
GROUP BY id, TRUNC(count_date, 'MM')You should get the following:
1     2012/02/01
1     2012/03/01
1     2012/01/01Now insert into the results table:
INSERT INTO result_data
SELECT id, TRUNC(count_date, 'MM')
FROM source_data
GROUP BY id, TRUNC(count_date, 'MM');Select from that table and you get:
1     2012/03/01
1     2012/03/01
1     2012/03/01The most recent month is repeated for each row.
Truncate your table and insert with the following statement and the results should now be correct:
INSERT INTO result_data
SELECT id, TRUNC(count_date, 'MM')
FROM source_data
GROUP BY id, TRUNC(count_date, 'MM')
ORDER BY 1, 2;If anyone has encountered this behavior before could you please let me know, I can't see that I am making a mistake as the selects results are correct they should not differ from what is being inserted.
Edited by: user11285442 on May 13, 2013 5:16 AM
Edited by: user11285442 on May 13, 2013 6:15 AM

Hi,
welcome to the forum. I cannot reproduce the same behavior.
Could you please post the SQLPlus output while executing all commands, like it has been done by S10390?
Also post the output of the following command:
SELECT * FROM v$version;When you put some code or output please enclose it between two lines starting with {noformat}{noformat}
i.e.:
{noformat}{noformat}
SELECT ...
{noformat}{noformat}
Formatted code is easier to read.
Regards.
Al

BizTalk 2006 Event Log Warnings - Cannot insert duplicate key row in object 'dta_MessageFieldValues' with unique index 'IX_MessageFieldValues'.

We have been seeing the following 'warnings' in the event log of our BizTalk machine since upgrading to BTS 2006. They seem to occur randomly 6 or 8 times per day.
Does anyone know what this means and what needs to be done to clear it up? we have only one BizTalk server which is running on only one machine.
I am new to BizTalk, so I am unable to find how many tracking host instances running for BizTalk server. Also, can you please let me know that we can configure only one instance for one server/machine?
Source: BAM EventBus Service
Event: 5
Warning Details: Execute batch error. Exception information: TDDS failed to batch execution of streams. SQLServer: bizprod, Database: BizTalkDTADb.Cannot insert duplicate key row in object 'dta_MessageFieldValues'
with unique index 'IX_MessageFieldValues'. The statement has been terminated..

Other than ensuring that there exists a separate and single tracking host instance, you're getting an error about duplicate keys.. which implies that you're trying to Create a BAM Activity twice with the same data.
I suggest you have a in-depth examination of the BAM (TPE or API) associated with the orchestration. In TPE ensure that the first binding you select is the "Instance Id" or "Message Id" before going ahead to map the ports or others.
Regards.

Partial insert with secondary index

Similar Messages

Maybe you are looking for