Performance of Indexes

we are doing some performance testing on Static Groups...we have created a Static Group with around 20k members. and when we
we have created an group with around 20,000 Members and the file looks like this
dn:cn=salaried group,ou=groups,dc=yyyyy,dc=com
objectlcass:top
objectclass:groupofuniquenames
cn:salaried group
uniquemember: uid=test00001,ou=people,dc=yyyy,dc=com
uniquemember: uid=test00002,ou=people,dc=yyyy,dc=com
uniquemember: uid=test20000,ou=people,dc=yyyy,dc=com.
I have imported the above file and then performed the search operation and observed the following results:
1) IF i make a search for "uniquemember=uid=testooo10,ou=people,dc=yyy,dc=com", the search time is around 300ms
2) for the search "uniquemember=test05020,ou=people,dc=yyyyy,dc=com" the searchtime is 800ms
3) for the search "uniquemember=test9999,ou=people,dc=yyyyy,dc=com" the searchtime is 2000ms.
Iam a little bit confused with the way the Indexes operate because,,,,from the results i oberved above....i feel that the values for the uniquemember attribute are stored in the same order as that in the ldif file.... is that how the entry ID for the uniquemember attribtue are created??is there anyway we can know the orded in which the index of an attribtues stores it's values??

Hi
What you are experimenting is not due to the indexes, but with the way DS select entries from the index and then verify that the entry still matches the filter before returing it.
The algorithm used to check filters against an attribute with many values (20K is definitely a lot), combined with the fact that these values are Distinguished Names (ie the DN normalization cost is also high) result in a response time that is linear according to the position of the DN in the array of values.
This can be worked around with the nsslapd-searchtune parameter (and I let you search for the technote about this parameter on this forum).
Alternately, Directory Server 6.0 does contain some major improvements for DNs and Groups, and now scales much better even up to 100,000 members.
Regards,
Ludovic

Similar Messages

ESH_ADM_INDEX_ALL_SC cannot perform initial indexing for all search connectors

Dear SAP Gurus,
We are implementing TREX version 7.10.50 for Talent Management ECC 6.0 - EHP 5.
I'd like to ask you question regarding ESH_ADM_INDEX_ALL_SC program
which used to create search connector for TREX and perform initial indexing for all search connectors.
As we know we can perform indexing using ESH_COCKPIT transaction code or use ESH_ADM_INDEX_ALL_SC.
If I try to perform indexing using ESH_COCKPIT, all search connectors can be indexed ("searchable" column are "checked" and status are changed to "Active" for all search connectors).
However, if I try to perform indexing using ESH_ADM_INDEX_ALL_SC, not all search connectors are indexed.
I've traced the program ESH_ADM_INDEX_ALL_SC using ST01 transaction code and found these error:
- rscpe__error 32 at rscpu86r.c(6;742) "dest buffer overflow" (,)
- rscpe__error 32 at rscpc (20;12129) "convert output buffer overflow"
- rscpe__error 128 at rstss01 (1;178) "Object not found"
Please kindly help me to solve this issue,
Thank you very much
Regards,
Bobbi

Hi Luke,
Please find below connectors and the status after running ESH_ADM_INDEX_ALL_SC:
HRTMC AES Documents Prepared
HRTMC AES Elements Prepared
HRTMC AES Templates Prepared
HRTMC Central Person Prepared
HRTMC Functional Area Prepared
HRTMC Job Prepared
HRTMC Job Family Prepared
HRTMC Org Unit Prepared
HRTMC Person Active
HRTMC Position Prepared
HRTMC Qualification Active
HRTMC Relation C JF 450 Active
HRTMC Relation C Q 031 Active
HRTMC Relation CP JF 744 Active
HRTMC Relation CP P 209 Active
HRTMC Relation CP Q 032 Active
HRTMC Relation CP TB 743 Active
HRTMC Relation FN Q 031 Active
HRTMC Relation JF FN 450 Active
HRTMC Relation JF Q 031 Active
HRTMC Relation P Q 032 Active
HRTMC Relation S C 007 Active
HRTMC Relation S CP 740 Active
HRTMC Relation S JF 450 Active
HRTMC Relation S O 003 Active
HRTMC Relation S O Area of Responsibility Active
HRTMC Relation S P 008 Active
HRTMC Relation S Q 031 Active
HRTMC Relation S S Manager Active
HRTMC Relation SC JF FN Active
HRTMC Structural authority Active
HRTMC Talent Group Prepared
As suggested by OSS, we implement SAP Note 1058533.
Kindly need your help.
Thank you very much
Regards
Bobbi

Do I need to perform Process Index on the cube when measure groups has been processed with full individually?

hi there, I am not sure if I need to perform process Index? Do I have to do that after I process full on measure groups?
thanks
--Currently using Reporting Service 2000; Visual Studio .NET 2003; Visual Source Safe SSIS 2008 SSAS 2008, SVN --

I did process update on all dimensions... after that, I did process full on each measure groups...
In this case, do I need to process index on the whole cube?
Hi Cat_ca,
ProcessFull - Simple to digest, applies all objects which means it discards the storage contents of the object and rebuilds them.
ProcessIndexes - Applies to dimension, cube, measure group, and partition.
Since you did process full on each measure groups, I don't think you need do a processindex, here are some links about process options on Analysis Services for your reference.
Different Kinds of SSAS Processing in simple words
Difference between SSAS ProcessUpdate and ProcessFull
Regards,
Charlie Liao
If you have any feedback on our support, please click
here.
Charlie Liao
TechNet Community Support

Performance - composite index with 'OR' in 'WHERE' clause

I have a problem with the performance of the following query:
select /*+ index_asc(omschact oma_index1) */ knr, projnr, actnr from omschact where ((knr = 100 and actnr > 30) or knr > 100)
and rownum = 1;
(rownum used only for test purpose)
index:
create index on omschact (knr, projnr);
Execution plan:
Id Operation
0 SELECT STATEMENT
1 COUNT STOPKEY
2 TABLE ACCESS BY INDEX ROWID
3 INDEX FULL SCAN
If I'm correct, the 'OR' in the 'WHERE' clause is responsible for the INDEX FULL SCAN, what makes the query slow.
A solution would be then to separate the 'WHERE' clause in 2 separate select's (1 with 'knr = 100 and actnr > 30' and 1 with 'knr > 100' and combine the results with a UNION ALL.
Since it's necessary to have all rows in ascending order (oma_index1) I still have to use an ORDER BY to make sure the order of the rows is correct. This results again in a (too) low performance.
Another solution that does the trick is to create an index with the 2 fields (knr, projnr) concatenated and to use the same in the 'WHERE' clause:
create index oma_index2 on omschact (knr || projnr);
select /*+ index_asc(omschact oma_index2) */ knr, projnr, actnr from omschact where (knr || projnr) > 10030;
I just can't believe this work-around is the only solution, so I was hoping that someone here knows of a better way to solve this.

padders,
I'll give the real data instead of the example. The index I really use consists of 4 fields. In this table the fields are just numbers, but in other tables I need to use char-fields in indexes, so that's why I concatenate instead of using formula's (allthough I would prefer the latter).
SQL> desc omschact
Name Null? Type
KNR NOT NULL NUMBER(8)
PROJNR NOT NULL NUMBER(8)
ACTNR NOT NULL NUMBER(8)
REGELNR NOT NULL NUMBER(3)
REGEL CHAR(60)
first methode:
SQL> create index oma_key_001(knr,projnr,actnr,regelnr);
Index created.
SQL> select /*+ index_asc(omschact oma_key_001) */ * from omschact where
2 (knr > 100 or
3 (knr = 100 and projnr > 30) or
4 (knr = 100 and projnr = 30 and actnr > 100000) or
5 (knr = 100 and projnr = 30 and actnr = 100000 and regelnr >= 0));
Execution Plan
Plan hash value: 1117430516
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 11M| 822M| 192K (1)| 00:38:26 |
| 1 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 11M| 822M| 192K (1)| 00:38:26 |
|* 2 | INDEX FULL SCAN | OMA_KEY_001 | 11M| | 34030 (1)| 00:06:49 |
Predicate Information (identified by operation id):
2 - filter("KNR">100 OR "KNR"=100 AND "PROJNR">30 OR "KNR"=100 AND "PROJNR"=30
AND "ACTNR">100000 OR "ACTNR"=100000 AND "KNR"=100 AND "PROJNR"=30 AND
"REGELNR">=0)
second method (same index):
SQL> select * from (
2 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr > 100
3 union all
4 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr = 100 and projnr > 30
5 union all
6 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr = 100 and projnr = 30 and actnr > 100000
7 union all
8 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr = 100 and projnr = 30 and actnr = 100000 and regelnr > 0)
9 order by knr, projnr, actnr, regelnr;
Execution Plan
Plan hash value: 292918786
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 11M| 1203M| | 477K (1)| 01:35:31 |
| 1 | SORT ORDER BY | | 11M| 1203M| 2745M| 477K (1)| 01:35:31 |
| 2 | VIEW | | 11M| 1203M| | 192K (1)| 00:38:29 |
| 3 | UNION-ALL | | | | | | |
| 4 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 11M| 822M| | 192K (1)| 00:38:26 |
|* 5 | INDEX RANGE SCAN | OMA_KEY_001 | 11M| | | 33966 (1)| 00:06:48 |
| 6 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 16705 | 1272K| | 294 (1)| 00:00:04 |
|* 7 | INDEX RANGE SCAN | OMA_KEY_001 | 16705 | | | 54 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 47 | 3666 | | 4 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | OMA_KEY_001 | 47 | | | 3 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 1 | 78 | | 4 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | OMA_KEY_001 | 1 | | | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
5 - access("KNR">100)
7 - access("KNR"=100 AND "PROJNR">30)
9 - access("KNR"=100 AND "PROJNR"=30 AND "ACTNR">100000)
11 - access("KNR"=100 AND "PROJNR"=30 AND "ACTNR"=100000 AND "REGELNR">0)
third method:
SQL> create index oma_test(to_char(knr,'00000000')||to_char(projnr,'00000000')||to_char(actnr,'00000000')||to_char(regelnr,'000'));
Index created.
SQL> select /*+ index_asc(omschact oma_test) */ * from omschact where
2 (to_char(knr,'00000000')||to_char(projnr,'00000000')||
3 to_char(actnr,'00000000')||to_char(regelnr,'000')) >=
4 (to_char(100,'00000000')||to_char(30,'00000000')||
5* to_char(100000,'00000000')||to_char(0,'000'))
Execution Plan
Plan hash value: 424961364
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 553K| 55M| 1712 (1)| 00:00:21 |
| 1 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 553K| 55M| 1712 (1)| 00:00:21 |
|* 2 | INDEX RANGE SCAN | OMA_TEST | 99543 | | 605 (1)| 00:00:08 |
Predicate Information (identified by operation id):
2 - access(TO_CHAR("KNR",'00000000')||TO_CHAR("PROJNR",'00000000')||TO_CHAR("
ACTNR",'00000000')||TO_CHAR("REGELNR",'000')>=TO_CHAR(100,'00000000')||TO_CHAR(3
0,'00000000')||TO_CHAR(100000,'00000000')||TO_CHAR(0,'000'))

Performance Problems - Index and Statistics

Dear Gurus,
I am having problems lossing indexes and statistics on cubes ,it seems my indexes are too old which in fact are not too old just created a month back and we check indexes daily and it returns us RED on the manage TAB.
please help

Dear Mr Syed ,
Solution steps I mentioned in my previous reply itself explains so called RE-ORG of tables;however to clarify more on that issue.
Occasionally,ORACLE Cost-Based Optimizer may calculate the estimated costs for a Full Table Scan lower than those for an Index Scan, although the actual runtime of an access via an index would be considerably lower than the runtime of the Full Table Scan,Some Imperative points to be considered in order to perk up the performance and improve on quandary areas such as extensive running times for Change runs & Aggregate activate & fill ups.
Performance problems based on a wrong optimizer decision would show that there is something serious missing at Database level and we need to RE_ORG the degenerated indexes in order to perk up the overall performance and avoid daily manual (RSRV+RSNAORA)activities on almost similar indexes.
For Re-organizing degenerated indexes 3 options are available-
1) DROP INDEX ..., and CREATE INDEX 
2)ALTER INDEX <index name> REBUILD (ONLINE PARALLEL x NOLOGGING)
3) ALTER INDEX <index name> COALESCE [as of Oracle 8i (8.1) only]
Each option has its Pros & Cons ,option 2 seems to be having lot of advantages to
Advantages- option 2
1)Fast storage in a different table space possible
2)Creates a new index tree
3)Gives the option to change storage parameters without deleting the index
4)As of Oracle 8i (8.1), you can avoid a lock on the table by specifying the ONLINE option. In this case, Oracle waits until the resource has been released, and then starts the rebuild. The "resource busy" error no longer occurs.
I would still leave the Database tech team be the best to judge and take a call on these.
These modus operandi could be institutionalized for all fretful cubes & its indexes as well.
However,I leave the thoughts with you.
Hope it Helps
Chetan
@CP..

Select query performance improvement - Index on EDIDC table

Hi Experts,
I have a scenario where in I have to select data from the table EDIDC. The select query being used is given below.
SELECT docnum
          direct
          mestyp
          mescod
          rcvprn
          sndprn
          upddat
          updtim
INTO CORRESPONDING FIELDS OF TABLE t_edidc
FROM edidc
FOR ALL ENTRIES IN t_error_idoc
WHERE
upddat GE gv_date1 AND
upddat LE gv_date2 AND
updtim GE p_time AND
status EQ t_error_idoc-status.
As the volume of the data is very high, our client requested to put up some index or use an existing one to improve the performance of the data selection query.
Question:
4.    How do we identify the index to be used.
5.    On which fields should the indexing be done to improve the performance (if available indexes donu2019t cater to our case).
6.    What will be the impact on the table performance if we create a new index.
Regards ,
Raghav

Question:
1.    How do we identify the index to be used.
Generally the index is automatically selected by SAP (DB Optimizer ) ( You can still mention the index name in your select query by changing the syntax)
For your select Query the second Index will be called automatically by the Optimizer, ( Because the select query has u2018Updatu2019 , u2018uptimu2019 in the sequence before the u2018statusu2019 ) .
2.    On which fields should the indexing be done to improve the performance (if available indexes donu2019t cater to our case).
(Create a new Index with MANDT and the 4 fields which are in the where clause in sequence )
3.    What will be the impact on the table performance if we create a new index.
( Since the index which will be newly created is only the 4th index for the table, there shouldnu2019t be any side affects)
After creation of index , Check the change in performance of the current program and also some other programs which are having the select queries on EDIDC ( Various types of where clauses preferably ) to verify that the newly created index is not having the negative impact on the performance. Additionally, if possible , check if you can avoid into corresponding fields .
Regards ,
Seth

Not able to perform baseline index - ProductCatalogSimpleIndexingAdmin

Hi!
I am not being able to perform the baseline index, when i execute it on component 'ProductCatalogSimpleIndexingAdmin' i get the exception below.
Cold anyone give a help on how to configure the ATG/Endeca properly to perform the baseline index?
Thank you very much!
SEVERE: Error starting baseline crawl 'lojamococaen-last-mile-crawl'.
Occurred while executing line 11 of valid BeanShell script:
[[ 8| Dgidx.cleanDirs();
9|
10| // run crawl and archive any changes in dvalId mappings
11| CAS.runBaselineCasCrawl("lojamococaen-last-mile-crawl");
12| CAS.archiveDvalIdMappingsForCrawlIfChanged("lojamococaen-last-mile-crawl");
13|
14| // archive logs and run the indexer
Oct 16, 2014 1:27:14 PM com.endeca.soleng.eac.toolkit.Controller execute
SEVERE: Caught an exception while invoking method 'run' on object 'BaselineUpdate'. Releasing locks.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.endeca.soleng.eac.toolkit.Controller.invokeRequestedMethod(Controller.java:931)
at com.endeca.soleng.eac.toolkit.Controller.execute(Controller.java:269)
at com.endeca.soleng.eac.toolkit.Controller.main(Controller.java:137)
Caused by: com.endeca.soleng.eac.toolkit.exception.AppControlException: Error executing valid BeanShell script.
at com.endeca.soleng.eac.toolkit.script.Script.runBeanShellScript(Script.java:179)
at com.endeca.soleng.eac.toolkit.script.Script.run(Script.java:127)
... 7 more
Caused by: com.endeca.soleng.eac.toolkit.exception.CasCommunicationException: Error starting baseline crawl 'lojamococaen-last-mile-crawl'.
at com.endeca.eac.toolkit.component.cas.ContentAcquisitionServerComponent.startBaselineCasCrawl(ContentAcquisitionServerComponent.java:447)
at com.endeca.eac.toolkit.component.cas.ContentAcquisitionServerComponent.runBaselineCasCrawl(ContentAcquisitionServerComponent.java:355)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at bsh.Reflect.invokeMethod(Unknown Source)
at bsh.Reflect.invokeObjectMethod(Unknown Source)
at bsh.Name.invokeMethod(Unknown Source)
at bsh.BSHMethodInvocation.eval(Unknown Source)
at bsh.BSHPrimaryExpression.eval(Unknown Source)
at bsh.BSHPrimaryExpression.eval(Unknown Source)
at bsh.BSHBlock.evalBlock(Unknown Source)
at bsh.BSHBlock.eval(Unknown Source)
at bsh.BSHBlock.eval(Unknown Source)
at bsh.BSHIfStatement.eval(Unknown Source)
at bsh.Interpreter.eval(Unknown Source)
at bsh.Interpreter.eval(Unknown Source)
at bsh.Interpreter.eval(Unknown Source)
at com.endeca.soleng.eac.toolkit.script.Script.runBeanShellScript(Script.java:165)
... 8 more
Caused by: Crawl failed to start: Error retrieving attributes from the config repository: Unable to create JSON output for merge request: validation errors:
ERROR: failure to add '/sites/lojamococaen/attributes/product.category' to merged output: missing property 'mergeAction'.
. See config repository log for more details.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

Hi,
Update the <app>/config/index_config/index-config.json with "mergeAction" property for the product.category.
Ex:
"product.category" : {
 "propertyDataType" : "ALPHA",
 "jcr:primaryType" : "endeca:property",
 "mergeAction" : "UPDATE"
 "isRecordFilterable" : true
Then run the command from <app>/control index_config_cmd.bat set-config -f C:\Endeca\apps\CRS\config\index_config\index-config.json -o all
I hope this helps.
Thanks,
Ravinder Pogulakonda

Using GUIDs : Performance of Indexes/Queries?

Hi,
We are building a new database. The database tables is coupled together with key values which are GUIDs. The database size may grow to in excess of 2Billion records in a few months.
I am not sure here about how would Oracle Indexes perform given the very random nature of values of GUIDs. If I create an Index on a GUID column, would Oracle really use the Index when I have queries with the GUIDs in the where clause? Or would it do a full table scan for those millions of rows? Please let me know your views.
If anyone know of some best practices surrounding GUIDs or some good article on using GUIDs and possible issues associated with that, how to plan such huge database with keys with are GUIDs in nature, etc.., then even that would help me out.
Thanks a lot!
Biren.

Hi Biren,
By GUID, are you referring to the Oracle Portal product?

Performance Issue - Index is not used when a zero padded string is queried

Hi All,
I have a table T1 which has many columns. One such column say C1 is a varchar2(20). T1 has 10 million rows and there is an index called I1 on C1. Stats are current for both tables and indexes. These are the scenarios:
Scenario 1
select *   from T1 where C1 = '0013206263' --Uses index I1
187 ms
Scenario 2
select *   from T1 where C1 = '8177341863' --Uses index I1
203 ms
*Scenario 3*
*select *   from T1 where C1 = '0000000945' --Uses Fulll Table Scan --Very Slow*
*45 seconds*
When I force the sql to use the index through a hint, it is working fine:
Scenario 4
select /*+ INDEX (t1 i1) */ *   from T1 where C1 = '0013206263' --Uses index I1
123 ms
Scenario 5
select /*+ INDEX (t1 i1) */ *   from T1 where C1 = '8177341863' --Uses index I1
201 ms
*Scenario 6*
*select /*+ INDEX (t1 i1) */ *   from T1 where C1 = '0000000945' --Uses index I1*
*172ms*Is there any reason for this performance issue? Why does the optimizer goes for FTS in Scenario 3?
Edited by: user539954 on May 14, 2009 12:22 PM
Edited by: user539954 on May 14, 2009 12:32 PM

user539954 wrote:
Please see the replies below:
- How many distinct values for C1 out of that 10 million rows? I'm guessing that histograms were created for C1, correct?
=>7 million distinct c1 values. I have not gathered a histogram yet. Should I try that?
SQL> explain plan for select * from T1 where C1 = '0000000954';
| Id | Operation         | Name           | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT |                |   244K|    19M| 26228   (5)|
|   1 | TABLE ACCESS FULL| T1 |   244K|    19M| 26228   (5)|
SQL> explain plan for select * from T1 where C1 = '0033454555';
| Id | Operation                   | Name               | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT            |                    |   532 | 43624 |   261   (0)|
|   1 | TABLE ACCESS BY INDEX ROWID| T1     |   532 | 43624 |   261   (0)|
|   2 |   INDEX RANGE SCAN          | I1 |   532 |       |     2   (0)|
It's possible you do have a histogram, even though you didn't plan on creating it, if you're running 10g.
In the absence of a histogram and with 7M distinct keys in 10M rows, Oracle should have predicted 2 rows for both queries, not 244,000 and 532.
If you do have a histogram, you probably need to get rid of it.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.

Change Data type column - Performance of Index in Oracle 10g

Hi,
I have a table with too many rows (over 2000000 rows) . I have changed datatype (NUMBER to VARCHAR2) of an indexed column (the index is only for this column), using a temporay backup table:
CREATE TABLE BKTABLE AS SELECT FIELD, ROWID AS IDROW FROM ORIGNALTABLE;
UPDATE ORIGNALTABLE SET FIELD = NULL;
ALTER ORIGNALTABLE MODIFY FIELD VARCHAR2(256);
UPDATE ORIGNALTABLE A SET FIELD = (SELECT FIELD FROM BKTABLE B WHERE B.IDROW = A.IDROW);
This way worked OK.
There is any performance knowed issue over an index of ORIGNALTABLE? Need rebuild this index?
Thks!

Need rebuild this index? YES
ALWAYS
Post Operating System (OS) name & version for DB server system.
Post results of
SELECT * from v$version
or post Oracle version to 4 decimal places

Query performance - dynamic indexing?

Hi Experts,
I have a query like this:
WITH /*+materialize*/ A AS (SELECT A.NAME,
 B.pname,
 B.ptype,
DECODE(C.ttype,'L','Lab','Non-Lab') ttype
,(CASE WHEN(C.ttype = 'L') THEN C.RES_CODE ELSE NULL END) RES_CODE
,(SELECT (first_name|| ' ' ||last_name) FROM resources WHERE name=C.ROLE)ROLE_desc
,D.currency Bill_curr
,D.TOTALCOST Bill_cost
,E.currency Home_curr
,E.TOTALCOST Home_cost
,C.role role_code
,(C.HOURS) AS HRS
,(D.TOTALAMOUNT)
,(E.TOTALAMOUNT) Home_amount
FROM WORKPROG C
,WORKPROG_VAL D
,WORKPROG_VAL E
,PROJECTS A
,periods B
WHERE C.TNO=D.TNO
AND C.TNO=E.TNO
AND D.CURR_TYP='BILL'
AND E.CURR_TYP='HM'
AND A.NAME=C.PROJ_CODE
AND C.PROJ_CODE LIKE 'JA%'
AND C.TDATE BETWEEN b.start_date AND b.end_date AND b.ptype ='SMON'
SELECT
name,b.pname,b.ptype,ttype,res_code,role_desc,role_code,Bill_curr,SUM(Bill_cost),Home_curr,SUM(Home_cost),SUM(hrs),SUM(totalamount),SUM(Home_amount)
FROM A
GROUP BY name,b.pname,b.ptype,ttype,res_code,role_desc,role_code,Bill_curr,Home_currThe problem is - the WITH part takes no time to run, its very fast. But the group by part takes ages. This is because the WITH part returns millions of records.
Is ther eany way that I can dynamically index the result set of WITH query so that the group by runs faster.
Thanks.

Caitanya wrote:
Thanks Someone.
By ages... I mean it kept running for 45 minutes after which I aborted it.
The indexes are being used and there is no 'FULL TABLE ACCESS' in the explain plan. We are using Oracle 9i.It is quite unlikely (although possible) that getting millions of rows is done effectively by using indexes, you should actually look for performing full table scans. Only if the tables contained billions of rows it would be reasonable for the optimizer to choose an index access, but it will take hours to get millions of rows via index lookup and the corresponding single row random access to the tables.
I assume that the statistics are not up to date because a query that returns millions of rows probably won't have a realistic cost of 102. That would mean that Oracle estimates that it takes him the time of 102 single block reads to complete the query - if you take a conservative guess of 10ms per random single block access then this means roughly 1 second.
So please post your explain plan here, and if possible can you get the total number of rows in the tables accessed by the query and the approx. number of rows the query is supposed to return as base information.
Here are some (generic) instructions how to generate a reasonable EXPLAIN PLAN output:
Could you please post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your statement. Please use the \[code\] tag before and \[code\] after or {noformat}{{noformat}code{noformat}}{noformat} before and after to enhance readability of the output provided:
In SQL*Plus:
SET LINESIZE 130
EXPLAIN PLAN FOR <your statement>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Note that the package DBMS_XPLAN.DISPLAY is only available from 9i on.
In previous versions you could run the following in SQL*Plus (on the server) instead:
@?/rdbms/admin/utlxplsA different approach in SQL*Plus:
SET AUTOTRACE ON EXPLAIN
<run your statement>;will also show the execution plan.
In order to get a better understanding where your statement spends the time you might want to turn on SQL trace as described here:
[When your query takes too long|http://forums.oracle.com/forums/thread.jspa?threadID=501834]
and post the "tkprof" output here, too.
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/

Performance issue - Index not being used

Hi,
I have the following scenario
- I have a table Account with a PK -Account_ID, for which there is a index PK_ACCOUNT_ID_IDX
- Another table Account_fact has a PK - Account_ID, Month_Year, for which there is a index PK_ACCOUNT_FACT_IDX
I have a join in these two table. The query is
select a.ACCOUNT_ID, b.Cost
From Account a, Account_fact b
Where a.account_id = b.Account_id
and a.Include_flag = 'Y'
The explain plan for this query tells me its doing a Full table scan and not using the index and the cost of query is very high.
Can any one suggest what is wrong here.
Regards
Deepak

>> Shud I be creating a bit map index.
Bit map index is not for this case.
http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96533/data_acc.htm#8131
Also bitmaps are very dangerous for Transactional tables. They are not meant for them.
As I told you in this case create index on all the columns you are using in the query.
For example INCLUDE_FLAG, ACCOUNT_ID in ACCOUNT table
ACCOUNT_ID, COST in the other table.
But keep in mind that if you are selecting any other column from these tables then again it might opt for full table scan......

Performance tuning -index on big table on date column

Hi,
I am working on Oracle 10g with Oracle Apps 11i on Sun.
we have a large non-partition table "GL_JE_HEADERS" with 7 million rows.
Now we want to run the query for selecting rows using between clause on date column.
I have created Btree index on the this table.
Now how can I tune the query? Which hint should I use for the query?
Thanks,
rane

Hi Rane,
Now how can I tune the query?Indexes on DATE datatypes are tricky, as the SQL queries must match the index!
For example, an index on ship_date would NOT match a query:
WHERE trunc(ship_date) > trunc(sysdate-7);
WHERE to_char(ship_date,’YYYY-MM-DD’) = ‘2004-01-04’;
You may need to create an function-basd index, so that the DATE reference in your SQL matches the index:
http://www.dba-oracle.com/oracle_tips_index_scan_fbi_sql.htm
To start testing, go into SQL*Plus and "set autotrace on" and run the queries.
Then confirm that your index is being used.
Which hint should I use for the query?Hints are a last resort!
Your query is fully tuned when it fetches the rows you need with a minimum of block touches (logical reads, consistent gets).
See here for details:
http://www.dba-oracle.com/art_sql_tune.htm
Hope this helps . . .
Donald K. Burleson
Oracle Press author
Author of "Oracle Tuning: The Definitive Reference"
http://www.rampant-books.com/book_2005_1_awr_proactive_tuning.htm

TREX indexing on content server performance

Hi guys,
Our Portal is integrated with SAP CRM (using webdav) that manages documents stored in SAP content server. We use TREX to index these documents such that users in Portal can search for these documents. Currently we're evaluating the performance of indexing and searching, thus if we have a heavy load of documents to index, would it affect the SAP CRM/Content server that is the document repository? (such as memory consumption, performance, etc..)
Thanks,
ZM

Hi Chris,
do you use the ContentServer in the DMS application? If yes, you need to index documents stored in the DMS_PCD1 docu category.
Regards,
Mikhail

Performance of Creating Spatial Indexes

I have a spatial database with about 75GB of data in it. When I load this data initially it takes about 6 hours to load using 6 processes. To get this performance level I did not create any of the indexes or contsraints. So after the load I have to run the scripts to create the indexes and constraints.
To improve the performance of this I have written a script on UNIX which parses my SQL files and runs each create or alter statement in a separate process. The script makes sure that there are only a certain number of concurrent processes (10).
Creating the indexes is taking longer than the database load itself. There is one point layer in particular which has serveral hundred million rows which takes around 6 hours to complete. Are the any ways you can improve the performance of index creation. I did try the parallel option once but it did not reliably complete when I did my testing.
Does using Oracle Partitioning improve the performance of index creation? I do have a mapsheet attribute which could be used for the partitioning.
Paul

Hi Paul,
Parallelism should have reliably helped. I've heard a lot of good things about it more recently (i.e. if you tested on an earlier version you may want to upgrade/patch and check it out).
Partitioning should improve index creation speed as well. If you tend to query by an attribute, use that attribute as the partition key. If you tend to query by location (spatial query), try to use a partition key that reflects location (state, county, etc).
When you first create the index, create it local (partitioned) as unusable, then create each partition's index separately in parallel - you can use the script you've already written to do this.
Since it is point data, make sure to use layer_gtype=point
Here is a quick example:
CREATE INDEX partn_table_sidx ON partn_table(geom)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('LAYER_GTYPE=POINT')
LOCAL (
PARTITION P1 PARAMETERS (TABLESPACE=’P1_TBS’),
PARTITION P2 PARAMETERS (TABLESPACE=’P2_TBS’),
PARTITION P3 PARAMETERS (TABLESPACE=’P3_TBS’),
PARTITION P4 PARAMETERS (TABLESPACE=’P4_TBS’))
UNUSABLE;
ALTER INDEX partn_table_sidx REBUILD PARTITION P1;
ALTER INDEX partn_table_sidx REBUILD PARTITION P2;
ALTER INDEX partn_table_sidx REBUILD PARTITION P3;
ALTER INDEX partn_table_sidx REBUILD PARTITION P4;

Performance of Indexes

Similar Messages

Maybe you are looking for