Performance Tuning (creating Descending Indexes)

Hi,
There is a huge table about 70 million Records. Huge data pool happens daily for the sysdate.
For this table there is composite Primary key of c1,c2,c3 and hence the index is created (asc default).
On Online Screen the latest data is queried from this table. Hence the Query is having order by c1 desc, order by c2 desc, order by c3 will there be any performance improvement if the indexes are created for the PK Columns in descending order?
Thanking in anticipation.
Edited by: user505907 on Jan 5, 2010 3:25 AM

The Query returns roughly 2000 Records and display 50 Rows at a time on the screen.
The Optimizer Mode is ALL_ROWS. I'm running the query in Oracle 10g
Here is the Query and the Explain plan for the same. Pls Note that to maintain information integrity I masked the exact table and column names with the dummy names.
SELECT DISTINCT
TABLE01.UNIQU,
TABLE01.SNO,
TO_CHAR(TABLE02.CREATE_DATE,'YYYY-MM-DD'),
TABLE02.TYPE,
TABLE02.RDN,
TABLE02.C_RDN,
TABLE02.UNC_RDN,
TABLE02.UNIQU,
TABLE03.MODEL_ID,
TABLE03.INDI.
TABLE02.RD_DATE
FROM
TABLE01,
TABLE02,
TABLE03,
TABLE04
WHERE
TABLE04.ID = 1234 AND TABLE04.UNIQU =TABLE01.UNIQU AND
TABLE02.UNIQU = TABLE01.UNIQU AND
TABLE02.RD_DATE <=TO_DATE('20101231','YYYY-MM-DD') AND
TABLE01.MODEL_ID = TABLE03L.MODEL_ID
ORDER BY TABLE02.RD_DATE DESC,
TABLE01.UNIQU DESC,
TABLE02.TYPE DESC
SQL> SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY(NULL,NULL,'TYPICAL'));
PLAN_TABLE_OUTPUT
Plan hash value: 2353636552
| Id | Operation | Name | Rows| Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 6 | 516 | 1462 (1) | 00:00:21 |
| 1 | SORT UNIQUE | | 6 | 516 | 1461 (1) | 00:00:21 |
| 2 | TABLE ACCESS BY INDEX ROWID | TABLE02 | 2 | 84 | 1429 (1) | 00:00:21 |
| 3 | NESTED LOOPS | | 6 | 516 | 1460 (1) | 00:00:21 |
| 4 | NESTED LOOPS | | 4 | 176 | 19 (0) | 00:00:01 |
| 5 | NESTED LOOPS | | 4 | 148 | 15 (0) | 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | TABLE04 | 4 | 56 | 7 (0) | 00:00:01 |
|* 7 | INDEX RANGE SCAN |TAB04_IND | 4 | | 3 (0) | 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | TABLE01 | 1 | 23 | 2 (0) | 00:00:01 |
|* 9 | INDEX UNIQUE SCAN |TAB01_IND | 1 | | 1 (0) | 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TABLE03 | 1 | 7 | 1 (0) | 00:00:01 |
|* 11 | INDEX UNIQUE SCAN |TAB03_IND | 1 | | 0 (0) | 00:00:01 |
|* 12 | INDEX RANGE SCAN |TAB02_IND | 1468 | | 4 (0) | 00:00:01 |
Predicate Information (identified by operation id):
7 - access("TABLE04"."ID"=1234)
9 - access(""TABLE04"."UNIQU"="TABLE01"."UNIQU")
11 - access("TABLE01"."MODEL_ID"="TABLE03"."MODEL_ID")
12 - access("TABLE02"."UNIQU"="TABLE01"."UNIQU" AND
"TABLE02"."RD_DATE"<=TO_DATE('20101231','YYYY-MM-DD'))
Edited by: user505907 on Jan 6, 2010 9:02 AM
Edited by: user505907 on Jan 6, 2010 9:06 AM

Similar Messages

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 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

If we create more indexes in what way it decreases performance ??

If we create more indexes in what way it decreases performance

> Even though if u want to do some DML operations
on that table u have to disable the indexes and do
the operations.
Could you prove this or give an example?
Did I do something wrong in the past as I did not observe this?

Tuning by creating / deleting indexes

Hello !
I have a stored procedure which is called once per day to perform some clean up of the database.
To improve it, I would need to create some indexes, but I don't think it is a good idea to create indexes only for a stored procedure called once per day.
So I would like to know if it is a possible solution to create the required indexes before calling my stored procedure and remove them as soon as the job is finished. By "possible solution", I do not mean technically possible, but if this is a good idea. If not, what strategy should I use ?
Some technical points : Oracle 9.2 and the calls are done from java via jdbc.
By the way, I noticed that it doesn't seem to be possible to rollback indexes creation. Am I right ? So my method would not be good from a transactionnal point of view...
Thanks to for your help !

Hello
How important is it that this process completes in a specific amount of time? We have critical billing processes that only run once per month, but they have to run within a 2 hour window, so we are using all available techniques to ensure the process completes in the time limit.
I would start by looking to see if the stored procedures can be improved at all before creating the indexes though. What techniques are you using to perform the cleanup? Are you opening a cursor and looping through it, deleting one row at a time? if so, maybe BULK BINDS could help, or you may be able to convert the PL/SQL loops into straight SQL. If you are using straight SQL to do the deletes, can their execution plans be improved by using different constructs?
If indexes are the best way forward, I would start by doing a benchmark on your test system. Run the stored procedure and store the timings, then create the indexes, analyze the tables and indexes involved and then run the stored procedure again and record the timings. It's then a matter of checking that the extra indexes don't negatively impact any other processes that are insterting or updating the tables that you are cleaning up.
Once you have some reliable metrics to go on, you can make a decision, until then, you're pretty much flying blind. I personally don't think it is a very good idea to be creating indexes on the fly and the dropping them again every day. If you need indexes, you need them, but you need to prove that they will help and they won't hurt the performance of anything else.
Just my two penneth!
HTH
David

Regarding Indexes and performance tuning.

Hi Everyone,
I need some elaborate explanation about indexes and performance tuning.
1. How do you find out whether the select query which I write is utilizing the indexes .
2. Is it true that the sequence in which the indexes are defined in se11
for eg: MANDT
KNUMH
KOPOS
your select query should also have the same sequence in the where clause else the indexes are not utilized well .
3. Is there any precautions/ special method to write select queries for proper utilization of indexes.
Thanks to all reading and answering in advance.
Rgds,
Anu.

Hi
You will find like this
If your select like this
select matnr mtart from mara into<itab>
where matnr = <>..
Go to table and see mara ..if matnr is checked as primary key,then you are using primary index.
Check secondary index tab and see if any fields,if those fields you are using in select then you are using secondary index.
2.Not sequence,check how many fields are checked tick as primary key,all thsoe are index.
3.Always try to use proper primary index in select statment and avoid nested select statements.
Thanks

Bad performance "CREATE BITMAP INDEX"

Hi,
i just create a bitmap index on a fact table with ~90.000.000 entries. The indexed table is the artice dimension with a cardinality of about 900.000 articles.
The process is running since 24 hours with a parallel degree of 4, 3 slaves finished their work, only one is still collecting/sorting. PGA_AGGREGATE_TARGET is 4 GB.
Oralce has allocated a temporary segment in the temp. tablespace which has a size of 760 MB up to now.
Any idea how to speed up the process except increasing the degree for parallel query ?
Is there a space limit for processes allocating main memory in the PGA. Or is it absolutely impossible to setup Oracle memory for workareas in a way, so that such a big bitmap can be created in main memory ? I dont want to switch back to the 8i features CREATE_BITMAP_AREA_SIZE,...
Any hint is welcome, thx in advance...
Paul

Hello,
Please check <Bug:3048661>
Hdr: 3048661 9.2.0.3.0 RDBMS 9.2.0.3.0 RAM INDEX PRODID-5 PORTID-23
Abstract: CREATE BITMAP INDEXES TAKES LONGER IN 9203 WHEN PGA => 2GB
Thanks
Ashish

Performance Tuning Query on Large Tables

Hi All,
I am new to the forums and have a very specic use case which requires performance tuning, but there are some limitations on what changes I am actualy able to make to the underlying data. Essentially I have two tables which contain what should be identical data, but for reasons of a less than optimal operational nature, the datasets are different in a number of ways.
Essentially I am querying call record detail data. Table 1 (refered to in my test code as TIME_TEST) is what I want to consider the master data, or the "ultimate truth" if you will. Table one contains the CALLED_NUMBER which is always in a consistent format. It also contains the CALLED_DATE_TIME and DURATION (in seconds).
Table 2 (TIME_TEST_COMPARE) is a reconciliation table taken from a different source but there is no consistent unique identifiers or PK-FK relations. This table contains a wide array of differing CALLED_NUMBER formats, hugely different to that in the master table. There is also scope that the time stamp may be out by up to 30 seconds, crazy I know, but that's just the way it is and I have no control over the source of this data. Finally the duration (in seconds) can be out by up to 5 seconds +/-.
I want to create a join returning all of the master data and matching the master table to the reconciliation table on CALLED_NUMBER / CALL_DATE_TIME / DURATION. I have written the query which works from a logi perspective but it performs very badly (master table = 200,000 records, rec table = 6,000,000+ records). I am able to add partitions (currently the tables are partitioned by month of CALL_DATE_TIME) and can also apply indexes. I cannot make any changes at this time to the ETL process loading the data into these tables.
I paste below the create table and insert scripts to recreate my scenario & the query that I am using. Any practical suggestions for query / table optimisation would be greatly appreciated.
Kind regards
Mike
-------------- NOTE: ALL DATA HAS BEEN DE-SENSITISED
/* --- CODE TO CREATE AND POPULATE TEST TABLES ---- */
--CREATE MAIN "TIME_TEST" TABLE: THIS TABLE HOLDS CALLED NUMBERS IN A SPECIFIED/PRE-DEFINED FORMAT
CREATE TABLE TIME_TEST ( CALLED_NUMBER VARCHAR2(50 BYTE),
 CALLED_DATE_TIME DATE, DURATION NUMBER );
COMMIT;
-- CREATE THE COMPARISON TABLE "TIME_TEST_COMPARE": THIS TABLE HOLDS WHAT SHOULD BE (BUT ISN'T) IDENTICAL CALL DATA.
-- THE DATA CONTAINS DIFFERING NUMBER FORMATS, SLIGHTLY DIFFERENT CALL TIMES (ALLOW +/-60 SECONDS - THIS IS FOR A GOOD, ALBEIT UNHELPFUL, REASON)
-- AND DURATIONS (ALLOW +/- 5 SECS)
CREATE TABLE TIME_TEST_COMPARE ( CALLED_NUMBER VARCHAR2(50 BYTE),
 CALLED_DATE_TIME DATE, DURATION NUMBER )
COMMIT;
--CREATE INSERT DATA FOR THE MAIN TEST TIME TABLE
INSERT INTO TIME_TEST ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'7721345675', TO_DATE( '11/09/2011 06:10:21 AM', 'MM/DD/YYYY HH:MI:SS AM'), 202);
INSERT INTO TIME_TEST ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'7721345675', TO_DATE( '11/09/2011 08:10:21 AM', 'MM/DD/YYYY HH:MI:SS AM'), 19);
INSERT INTO TIME_TEST ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'7721345675', TO_DATE( '11/09/2011 07:10:21 AM', 'MM/DD/YYYY HH:MI:SS AM'), 35);
INSERT INTO TIME_TEST ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'7721345675', TO_DATE( '11/09/2011 09:10:21 AM', 'MM/DD/YYYY HH:MI:SS AM'), 30);
INSERT INTO TIME_TEST ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'7721345675', TO_DATE( '11/09/2011 06:18:47 AM', 'MM/DD/YYYY HH:MI:SS AM'), 6);
INSERT INTO TIME_TEST ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'7721345675', TO_DATE( '11/09/2011 06:20:21 AM', 'MM/DD/YYYY HH:MI:SS AM'), 20);
COMMIT;
-- CREATE INSERT DATA FOR THE TABLE WHICH NEEDS TO BE COMPARED:
INSERT INTO TIME_TEST_COMPARE ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'7721345675', TO_DATE( '11/09/2011 06:10:51 AM', 'MM/DD/YYYY HH:MI:SS AM'), 200);
INSERT INTO TIME_TEST_COMPARE ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'00447721345675', TO_DATE( '11/09/2011 08:10:59 AM', 'MM/DD/YYYY HH:MI:SS AM'), 21);
INSERT INTO TIME_TEST_COMPARE ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'07721345675', TO_DATE( '11/09/2011 07:11:20 AM', 'MM/DD/YYYY HH:MI:SS AM'), 33);
INSERT INTO TIME_TEST_COMPARE ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'+447721345675', TO_DATE( '11/09/2011 09:10:01 AM', 'MM/DD/YYYY HH:MI:SS AM'), 33);
INSERT INTO TIME_TEST_COMPARE ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'+447721345675#181345', TO_DATE( '11/09/2011 06:18:35 AM', 'MM/DD/YYYY HH:MI:SS AM')
, 6);
INSERT INTO TIME_TEST_COMPARE ( CALLED_NUMBER, CALLED_DATE_TIME,
DURATION ) VALUES (
'004477213456759777799', TO_DATE( '11/09/2011 06:19:58 AM', 'MM/DD/YYYY HH:MI:SS AM')
, 17);
COMMIT;
/* --- QUERY TO UNDERTAKE MATCHING WHICH REQUIRES OPTIMISATION --------- */
SELECT MAIN.CALLED_NUMBER AS MAIN_CALLED_NUMBER, MAIN.CALLED_DATE_TIME AS MAIN_CALL_DATE_TIME, MAIN.DURATION AS MAIN_DURATION,
 COMPARE.CALLED_NUMBER AS COMPARE_CALLED_NUMBER,COMPARE.CALLED_DATE_TIME AS COMPARE_CALLED_DATE_TIME,
 COMPARE.DURATION COMPARE_DURATION
FROM
SELECT CALLED_NUMBER, CALLED_DATE_TIME, DURATION
FROM TIME_TEST
) MAIN
LEFT JOIN
SELECT CALLED_NUMBER, CALLED_DATE_TIME, DURATION
FROM TIME_TEST_COMPARE
) COMPARE
ON INSTR(COMPARE.CALLED_NUMBER,MAIN.CALLED_NUMBER)<> 0
AND MAIN.CALLED_DATE_TIME BETWEEN COMPARE.CALLED_DATE_TIME-(60/86400) AND COMPARE.CALLED_DATE_TIME+(60/86400)
AND MAIN.DURATION BETWEEN MAIN.DURATION-(5/86400) AND MAIN.DURATION+(5/86400);

What does your execution plan look like?

Performance Tuning Question

Greetings,
I did a few searches for any topics related to this and
haven't found anything relevant - if I'm missing something obvious
I apologize.
We are doing some performance tuning of a CFMX 7.0.2 system
running on Solaris. Of the many things we're doing one is to run
truss on the cfmx processes to find out what in fact it's doing.
The following is an excerpt from one of the truss outputs:
stat64("/opt/coldfusionmx7/runtime/../lib/macromedia/jdbc/sqlserver/SQLServerURLParser.cla ss\0",
0x254FB860, 0x254FB9BC) = -1 Err#2
stat64("/opt/coldfusionmx7/runtime/../gateway/lib/macromedia/jdbc/oracle/OracleURLParser.c lass\0",
0x254FB860, 0x254FB9BC) = -1 Err#2
Err #2 means "File not found" in essence
These lines show up quite a bit in the output - and we're
curious as to why it's trying to find those particular classes at
all and why in those locations - there are other entries where it
looks like it's going through a series of paths that it knows about
trying to find these entries. As we use Oracle as our database what
could be the reason it's looking for SQLServer? Finally does anyone
know of a way to stop the attempt to find these classes and save
the system processing time to give us back those cycles for real
work?
Regards,
Scott

Please try:
Create View View3
As
SELECT a.Col1, a.Col2
From dbo.TableA A
WHERE NOT Exists (SELECT 1 From dbo.TableB B With(NoLock) WHERE A.Col1 = B.Col1)
UNION
SELECT Col1, Col2 From dbo.TableB
Also, please make sure that INDEXes on Col1 on both tables are NOT fragmented and your STATISTICS are also up tp date.
Best Wishes, Arbi; Please vote if you find this posting was helpful or Mark it as answered.

Performance tuning Issue

Hi folks,
I having a problem with performance tuning ... Below is a sample query
SELECT /*+ PARALLEL (K 4) */ DISTINCT ltrim(rtrim(ibc_item)), substr(IBC_BUSINESS_CLASS, 1,1)
FROM AAA K
WHERE ltrim(rtrim(ibc_item)) NOT IN
select /*+ PARALLEL (II 4) */ DISTINCT ltrim(rtrim(THIRD_MAINKEY)) FROM BBB II
WHERE SECOND_MAINKEY = 3
UNION
SELECT /*+ PARALLEL (III 4) */ DISTINCT ltrim(rtrim(BLN_BUSINESS_LINE_NAME)) FROM CCC III
WHERE BLN_BUSINESS_LINE = 3
The above query is having a cost of 460 Million. I tried creating index but oracle is not using index as a FT scan looks better. (I too feel FT scan is the best as 90% of the rows are used in the table)
After using the parallel hint the cost goes to 100 Million ....
Is there any way to decrease the cost ...
Thanks in advance for ur help !

Be aware too Nalla, that the PARALLEL hint will rule out the use of an index if Oracle adheres to it.
This is what I would try:
SELECT /*+ PARALLEL (K 4) */ DISTINCT TRIM(ibc_item), substr(IBC_BUSINESS_CLASS, 1,1)
FROM AAA K
WHERE NOT EXISTS (
SELECT 1
    FROM BBB II
WHERE SECOND_MAINKEY = 3
      AND TRIM(THIRD_MAINKEY) = TRIM(K.ibc_item))
AND NOT EXISTS (
SELECT 1
    FROM CCC III
WHERE BLN_BUSINESS_LINE = 3
    AND TRIM(BLN_BUSINESS_LINE_NAME) = TRIM(K.ibc_item))But I don't like this at all: TRIM(K.ibc_item), and you never need to use DISTINCT with NOT IN or NOT EXISTS.
Try this:
SELECT DISTINCT TRIM(ibc_item), substr(IBC_BUSINESS_CLASS, 1,1)
FROM AAA K
WHERE NOT EXISTS (
SELECT 1
    FROM BBB II
WHERE SECOND_MAINKEY = 3
      AND TRIM(THIRD_MAINKEY) = K.ibc_item
AND NOT EXISTS (
SELECT 1
    FROM CCC III
WHERE BLN_BUSINESS_LINE = 3
    AND TRIM(BLN_BUSINESS_LINE_NAME) = K.ibc_itemThis may not work though, since you may have whitespaces in K.ibc_item.

Performance tuning: lite sessions and local ServletContext

I have been doing some research on iPlanet performance tuning. In our
current production environment (iAS6.0 SP1B, iWS4.1 SP2 on Solaris), since
we don't use clustering there should be a couple of performance improvements
we can make immediately:
1. Use lite sessions (<session-impl>lite</session-impl> in ias-web.xml) - I
believe that if you use lite sessions, the session data is stored in the kjs
process space as opposed to the kxs process space. This, of course, means
that if a kjs dies the user's on it will lose their session information but
it will provide a performance improvement by reducing kxs/kjs communication.
2. Use local ServletContexts (<distributable>false</distributable> in
web.xml) - This should cause the ServletContext to only be stored in the
originating JVM. So again, if a kjs dies, the user will lose their
ServletContext but again we will get a performance improvement by reducing
kxs/kjs communcation.
What I want to understand is how our load balancing configuration will
effect our production environment if we use this configuration. Right now
we use sticky load balancing on all our servlets but we don't have our JSPs
registered and therefore sticky load balancing cannot always be trusted to
return users to the iAS they came from. We make up for this by using
hardware load balancing that keeps the majority of our users sticky.
However, using lite sessions and local ServletContexts will require that a
user not only stick to an iAS, but to a specific kjs as well. Using sticky
load balancing would ensure that, but since we also rely on our hardware
load balancers, could they create a problem? If a user gets sent back to
the iAS they came from by our hardware load balancers, will the kxs process
be smart enough to return them to the kjs they came from? If so, then I
think that means that we can safely switch to lite sessions and local
ServletContexts, but if not, I think many users will lose their sessions.
Thanks,
Linc

Please follow thru this link for your answers
http://developer.iplanet.com/viewsource/char_tuningias/index.jsp
Thanks
Shital Patel
Lincoln wrote:
I have been doing some research on iPlanet performance tuning. In our
current production environment (iAS6.0 SP1B, iWS4.1 SP2 on Solaris), since
we don't use clustering there should be a couple of performance improvements
we can make immediately:
1. Use lite sessions (<session-impl>lite</session-impl> in ias-web.xml) - I
believe that if you use lite sessions, the session data is stored in the kjs
process space as opposed to the kxs process space. This, of course, means
that if a kjs dies the user's on it will lose their session information but
it will provide a performance improvement by reducing kxs/kjs communication.
2. Use local ServletContexts (<distributable>false</distributable> in
web.xml) - This should cause the ServletContext to only be stored in the
originating JVM. So again, if a kjs dies, the user will lose their
ServletContext but again we will get a performance improvement by reducing
kxs/kjs communcation.
What I want to understand is how our load balancing configuration will
effect our production environment if we use this configuration. Right now
we use sticky load balancing on all our servlets but we don't have our JSPs
registered and therefore sticky load balancing cannot always be trusted to
return users to the iAS they came from. We make up for this by using
hardware load balancing that keeps the majority of our users sticky.
However, using lite sessions and local ServletContexts will require that a
user not only stick to an iAS, but to a specific kjs as well. Using sticky
load balancing would ensure that, but since we also rely on our hardware
load balancers, could they create a problem? If a user gets sent back to
the iAS they came from by our hardware load balancers, will the kxs process
be smart enough to return them to the kjs they came from? If so, then I
think that means that we can safely switch to lite sessions and local
ServletContexts, but if not, I think many users will lose their sessions.
Thanks,
Linc

Invalid statement in Performance Tuning Guide

Oracle® Database Performance Tuning Guide
10g Release 2 (10.2)
Part Number B14211-01
13 The Query Optimizer
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#sthref1324
excerpt:
"You can specify fast full index scans with the initialization parameter OPTIMIZER_FEATURES_ENABLE or the INDEX_FFS hint. Fast full index scans cannot be performed against bitmap indexes."
Emphasis mine - Gints
Here is counterexample:
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL> create table blah (sex varchar2(1) not null, data varchar2(4000));
Table created.
SQL> insert into blah select 'F', lpad('a', 4000, 'a') from user_objects where rownum<=10;
10 rows created.
SQL> insert into blah select 'M', lpad('a', 4000, 'a') from user_objects where rownum<=10;
10 rows created.
SQL> commit;
Commit complete.
SQL> create bitmap index sexidx on blah(sex);
Index created.
SQL> exec dbms_stats.gather_table_stats(user, 'blah', cascade=>true)
PL/SQL procedure successfully completed.
SQL>
SQL> set autot traceonly expl
SQL> set lines 100
SQL> select count(*) from blah where sex = 'F';
SQL> /
Execution Plan
Plan hash value: 1028317341
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 2 | 1 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 2 | | |
| 2 | BITMAP CONVERSION COUNT | | 10 | 20 | 1 (0)| 00:00:01 |
|* 3 | BITMAP INDEX FAST FULL SCAN| SEXIDX | | | | |
Predicate Information (identified by operation id):
 3 - filter("SEX"='F')
SQL> set autot off
SQL> alter session set events '10046 trace name context forever, level 12';
Session altered.
SQL> select count(*) from blah where sex = 'F';
COUNT(*)
 10
SQL> disconn
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining optionsand here is relevant section from tkprofed trace file assuring that bitmap index fast full scan really was performed.
select count(*)
from
blah where sex = 'F'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.02 0 0 0 0
Execute 1 0.00 0.03 0 0 0 0
Fetch 2 0.00 0.00 0 3 0 1
total 4 0.00 0.05 0 3 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 60
Rows Row Source Operation
 1 SORT AGGREGATE (cr=3 pr=0 pw=0 time=74 us)
 1 BITMAP CONVERSION COUNT (cr=3 pr=0 pw=0 time=55 us)
 1 BITMAP INDEX FAST FULL SCAN SEXIDX (cr=3 pr=0 pw=0 time=43 us)(object id 98446)Gints Plivna
http://www.gplivna.eu

Hello Gints. I've reported this to the writer responsible for the Performance Tuning Guide. One of us will get back to you with the resolution.
Regards,
Diana

Performance Tuning Tips

Dear All,
In our project we are facing lot of problems with the Performance, users are compaining about the poor performance of the few reports and all, we are in the process of fine tuning the reports by following the all methods/suggestions provided by SAP ( like removing the select queries from Loops, For all entries , Binary serach etc )
But still I want to know from you people what can we check from BASIS percpective ( all the settings ) and also ABAP percpective to improve the performance.
And also I have one more query that what is " Table Statistics " , what is the use of this ...
Please give ur valueble suggestions to us in improving the performance .
Thanks in Advance !

Hi
Ways of Performance Tuning
1. Selection Criteria
2. Select Statements
 Select Queries
 SQL Interface
 Aggregate Functions
 For all Entries
Select Over more than one Internal table
Selection Criteria
1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.
2. Select with selection list.
Points # 1/2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
 SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
 SBOOK_WA-CONNID = '0400'.
Select Statements Select Queries
1. Avoid nested selects
2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
3. When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.
4. For testing existence , use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.
5. Use Select Single if all primary key fields are supplied in the Where condition .
Point # 1
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
 WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
 FROM EKKO AS P INNER JOIN EKAN AS F
 ON PEBELN = FEBELN.
Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.
Point # 2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
 SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
 SBOOK_WA-CONNID = '0400'.
Point # 3
To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields . In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.
Point # 4
SELECT * FROM SBOOK INTO SBOOK_WA
UP TO 1 ROWS
WHERE CARRID = 'LH'.
ENDSELECT.
The above code is more optimized as compared to the code mentioned below for testing existence of a record.
SELECT * FROM SBOOK INTO SBOOK_WA
 WHERE CARRID = 'LH'.
EXIT.
ENDSELECT.
Point # 5
If all primary key fields are supplied in the Where condition you can even use Select Single.
Select Single requires one communication with the database system, whereas Select-Endselect needs two.
Select Statements contd.. SQL Interface
1. Use column updates instead of single-row updates
to update your database tables.
2. For all frequently used Select statements, try to use an index.
3. Using buffered tables improves the performance considerably.
Point # 1
SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
SFLIGHT_WA-SEATSOCC =
 SFLIGHT_WA-SEATSOCC - 1.
UPDATE SFLIGHT FROM SFLIGHT_WA.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
UPDATE SFLIGHT
 SET SEATSOCC = SEATSOCC - 1.
Point # 2
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE CARRID = 'LH'
 AND CONNID = '0400'.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE MANDT IN ( SELECT MANDT FROM T000 )
 AND CARRID = 'LH'
 AND CONNID = '0400'.
ENDSELECT.
Point # 3
Bypassing the buffer increases the network considerably
SELECT SINGLE * FROM T100 INTO T100_WA
BYPASSING BUFFER
WHERE SPRSL = 'D'
 AND ARBGB = '00'
 AND MSGNR = '999'.
The above mentioned code can be more optimized by using the following code
SELECT SINGLE * FROM T100 INTO T100_WA
WHERE SPRSL = 'D'
 AND ARBGB = '00'
 AND MSGNR = '999'.
Select Statements contd Aggregate Functions
 If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Consider the following extract.
 Maxno = 0.
 Select * from zflight where airln = LF and cntry = IN.
 Check zflight-fligh > maxno.
 Maxno = zflight-fligh.
 Endselect.
The above mentioned code can be much more optimized by using the following code.
Select max( fligh ) from zflight into maxno where airln = LF and cntry = IN.
Select Statements contdFor All Entries
 The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
 The plus
 Large amount of data
 Mixing processing and reading of data
 Fast internal reprocessing of data
 Fast
 The Minus
 Difficult to program/understand
 Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES Check that data is present in the driver table
 Sorting the driver table
 Removing duplicates from the driver table
Consider the following piece of extract
Loop at int_cntry.
 Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
 Select * from zfligh appending table int_fligh
 For all entries in int_cntry
 Where cntry = int_cntry-cntry.
Endif.
Select Statements contd Select Over more than one Internal table
1. Its better to use a views instead of nested Select statements.
2. To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.
3. Instead of using nested Select loops it is often better to use subqueries.
Point # 1
SELECT * FROM DD01L INTO DD01L_WA
WHERE DOMNAME LIKE 'CHAR%'
 AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T INTO DD01T_WA
 WHERE DOMNAME = DD01L_WA-DOMNAME
 AND AS4LOCAL = 'A'
 AND AS4VERS = DD01L_WA-AS4VERS
 AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
The above code can be more optimized by extracting all the data from view DD01V_WA
SELECT * FROM DD01V INTO DD01V_WA
WHERE DOMNAME LIKE 'CHAR%'
 AND DDLANGUAGE = SY-LANGU.
ENDSELECT
Point # 2
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
 WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
 FROM EKKO AS P INNER JOIN EKAN AS F
 ON PEBELN = FEBELN.
Point # 3
SELECT * FROM SPFLI
INTO TABLE T_SPFLI
WHERE CITYFROM = 'FRANKFURT'
 AND CITYTO = 'NEW YORK'.
SELECT * FROM SFLIGHT AS F
 INTO SFLIGHT_WA
 FOR ALL ENTRIES IN T_SPFLI
 WHERE SEATSOCC < F~SEATSMAX
 AND CARRID = T_SPFLI-CARRID
 AND CONNID = T_SPFLI-CONNID
 AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
The above mentioned code can be even more optimized by using subqueries instead of for all entries.
SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
 WHERE SEATSOCC < F~SEATSMAX
 AND EXISTS ( SELECT * FROM SPFLI
 WHERE CARRID = F~CARRID
 AND CONNID = F~CONNID
 AND CITYFROM = 'FRANKFURT'
 AND CITYTO = 'NEW YORK' )
 AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
Internal Tables
1. Table operations should be done using explicit work areas rather than via header lines.
2. Always try to use binary search instead of linear search. But dont forget to sort your internal table before that.
3. A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.
4. A binary search using secondary index takes considerably less time.
5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.
6. Modifying selected components using MODIFY itab TRANSPORTING f1 f2.. accelerates the task of updating a line of an internal table.
Point # 2
READ TABLE ITAB INTO WA WITH KEY K = 'X BINARY SEARCH.
IS MUCH FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY K = 'X'.
If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
Point # 3
READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
Point # 5
LOOP AT ITAB INTO WA WHERE K = 'X'.
ENDLOOP.
The above code is much faster than using
LOOP AT ITAB INTO WA.
CHECK WA-K = 'X'.
ENDLOOP.
Point # 6
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.
The above code is more optimized as compared to
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1.
7. Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably
8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to LOOP-APPEND-ENDLOOP.
10. DELETE ADJACENT DUPLICATES accelerates the task of deleting duplicate entries considerably as compared to READ-LOOP-DELETE-ENDLOOP.
11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to DO -DELETE-ENDDO.
Point # 7
Modifying selected components only makes the program faster as compared to Modifying all lines completely.
e.g,
LOOP AT ITAB ASSIGNING <WA>.
I = SY-TABIX MOD 2.
IF I = 0.
 <WA>-FLAG = 'X'.
ENDIF.
ENDLOOP.
The above code works faster as compared to
LOOP AT ITAB INTO WA.
I = SY-TABIX MOD 2.
IF I = 0.
 WA-FLAG = 'X'.
 MODIFY ITAB FROM WA.
ENDIF.
ENDLOOP.
Point # 8
LOOP AT ITAB1 INTO WA1.
READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.
IF SY-SUBRC = 0.
 ADD: WA1-VAL1 TO WA2-VAL1,
 WA1-VAL2 TO WA2-VAL2.
 MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.
ELSE.
 INSERT WA1 INTO ITAB2 INDEX SY-TABIX.
ENDIF.
ENDLOOP.
The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by
LOOP AT ITAB1 INTO WA.
COLLECT WA INTO ITAB2.
ENDLOOP.
SORT ITAB2 BY K.
COLLECT, however, uses a hash algorithm and is therefore independent
of the number of entries (i.e. O(1)) .
Point # 9
APPEND LINES OF ITAB1 TO ITAB2.
This is more optimized as compared to
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 10
DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.
This is much more optimized as compared to
READ TABLE ITAB INDEX 1 INTO PREV_LINE.
LOOP AT ITAB FROM 2 INTO WA.
IF WA = PREV_LINE.
 DELETE ITAB.
ELSE.
 PREV_LINE = WA.
ENDIF.
ENDLOOP.
Point # 11
DELETE ITAB FROM 450 TO 550.
This is much more optimized as compared to
DO 101 TIMES.
DELETE ITAB INDEX 450.
ENDDO.
12. Copying internal tables by using ITAB2[ ] = ITAB1[ ] as compared to LOOP-APPEND-ENDLOOP.
13. Specify the sort key as restrictively as possible to run the program faster.
Point # 12
ITAB2[] = ITAB1[].
This is much more optimized as compared to
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 13SORT ITAB BY K. makes the program runs faster as compared to SORT ITAB.
Internal Tables contd
Hashed and Sorted tables
1. For single read access hashed tables are more optimized as compared to sorted tables.
2. For partial sequential access sorted tables are more optimized as compared to hashed tables
Hashed And Sorted Tables
Point # 1
Consider the following example where HTAB is a hashed table and STAB is a sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE HTAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
This runs faster for single read access as compared to the following same code for sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE STAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
Point # 2
Similarly for Partial Sequential access the STAB runs faster as compared to HTAB
LOOP AT STAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
This runs faster as compared to
LOOP AT HTAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
Reward if usefull

In sap bi performance tuning option is considered in cube not in ods, why?

details about
indexes,partitions,aggregates,compression,roll up
how these are helping to increase system performance
why ods is not suitable?

Hi,
Generally we do performance tuning on the cubes as most of the reportings are done on the cubes hpowever in case of DSO also we can increase the performance by creating indexes of deactivating SID generation flag if there is no reporting on the DSO.
Following 2 links will show you different aspects of performance tuning :-
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/404544e7-83c9-2e10-7b80-a24d5099ce3f
For LID and High Cardinality
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/005f3197-d3da-2e10-1a94-a5c62342f2aa
You may create aggregates on the cube if some of IO are being used in the query very frequently to enhance the performce of query execution.
Navesh

Performance Tuning for BAM 11G

Hi All
Can anyone guide me for any documents or any tips realted to performance tuning for BAM 11G on on Linux

It would help to know if you have any specific issue. There are number of tweaks all they way from DB to Browser.
Few key things to follow:
1. Make sure you create index on DO. If there are too much old data in the DO and not useful then periodically delete it. Similar to relational database indexes, defining indexes in Oracle BAM creates and maintains an ordered list of data object elements for fast retrieval.
2. Ensure that IE setup to do automatic caching. This will help with reducing server round trips.
3. Tune DB performance. This would typically require DBA. Identify the SQL statements most likely to be causing the waits by looking at
the drilldown Top SQL Statements Ordered by Wait Time. Use SQL Analyze, EXPLAIN PLAN, or the tkprof utility to tune the queries that were identified.
Check the Dataobject tables involved in the query for missing indexes.
4. Use batching (this is on by default for most cases)
5. Fast network
6. Use profilers to look at machine load/cpu usage and distribute components on different boxes if needed.
7. Use better server AND client hardware. BAM dashboard are heavy users of ajax/javascript logic on the client

Performance Tuning (creating Descending Indexes)

Similar Messages

Maybe you are looking for