Index to Improve SQL Performance
Please provide a link to information about how to use an Index to enhance SQL performance with Oracle 10g database.
user8973820 wrote:
I would like information regarding the use of clustered versus non-clustered indexes.The documentation is your friend :)
[Overview of Indexed Clusters|http://download.oracle.com/docs/cd/E11882_01/server.112/e10713/tablecls.htm#CFABHBAG]
[Indexes and Index-Organized Tables|http://download.oracle.com/docs/cd/E11882_01/server.112/e10713/indexiot.htm#BABHJAJF]
HTH!
Similar Messages
-
Connect by prior with the hint index not improving the performance
Hi
I have a table ORDERS (transaction table) with a parent order and multiple child orders with a field called orig_tid which track it back to main order.Child order can be further amended it will have mapping to immediate parent and immediate parent will have mapping to its parent.
I want find out al the order associated with main order using connect by prior.
I have created an index on required fileds but still those are not reducing the bytes. It is foing full index scan which are involving big bytes.
[code]
create index idx_test on orders decode(length(nvl(orig_tid,0)),9,substr(tran_no,6),orig_tid)
SELECT /*+ (mmd IDX_TEST) */ *
FROM ORDERS mmd
connect by prior tid=decode(length(nvl(orig_tid,0)),9,substr(tran_no,6),orig_tid)
start_with or_number='13454566654553'
[/CODE]
Explain Plan
ID | OPERATION | NAME | ROWS | BYTES | COST
0 | SELECT STATEMENT | | 9768 | 5093K | 6944
1|CONNECT BY WITH FILTERING| | | |
2|TABLE ACCESS BY INDEX ROWID|ORDERS | 1 |534| 319K
3| INDEX FULL SCAN| IDX_TEST| 976K| | 5652
4|NESTED LOOPS| | | |
5|CONNECT By PUMP | | | |
6| TABLE ACCESS BY INDEX ROWID| ORDERS| 9768 | 5093K| 6944
7| INDEX FULL SCAN | IDX_TEST | 3907| | 5689
Message was edited by: NikhilJunejapost EXPLAIN PLAN for SQL
-
Help needed in SQL performance - Using CASE in SQL statement versus 2 query
Hi,
I have a requirement to find count from a bunch of tables.
The SQL I have gives the count of all members.
I have created 2 queries to find count of active and inactive members.
The key difference is only the active dates.
Each query takes 20 seconds to execute.
I modified the SQL to use CASE statement in the SELECT.
So after the data is fetched the CASE statement will evaluate the active date and gives 2 counts (active and inactive)
Is it advisable to use this approach. Will CASE improve SQL performance ? I have to justify this.
Please let me know your thoughts.
Thanks,
JHi,
If it can be done in single SQL do it in single SQL.
You said:
Will CASE improve SQL performance There can be both cases to prove if the performance is better or worse.
In your case you should tell us how it is.
Regards,
Bhushan -
How can we improve the performance while fetching data from RESB table.
Hi All,
Can any bosy suggest me the right way to improve the performance while fetching data from RESB table. Below is the select statement.
SELECT aufnr posnr roms1 roanz
INTO (itab-aufnr, itab-pposnr, itab-roms1, itab-roanz)
FROM resb
WHERE kdauf = p_vbeln
AND ablad = itab-sposnr+2.
Here I am using 'KDAUF' & 'ABLAD' in condition. Can we use secondary index for improving the performance in this case.
Regards,
HimanshuHi ,
Declare intenal table with only those four fields.
and try the beloe code....
SELECT aufnr posnr roms1 roanz
INTO table itab
FROM resb
WHERE kdauf = p_vbeln
AND ablad = itab-sposnr+2.
yes, you can also use secondary index for improving the performance in this case.
Regards,
Anand .
Reward if it is useful.... -
Need help in improving the performance for the sql query
Thanks in advance for helping me.
I was trying to improve the performance of the below query. I tried the following methods used merge instead of update, used bulk collect / Forall update, used ordered hint, created a temp table and upadated the target table using the same. The methods which I used did not improve any performance. The data count which is updated in the target table is 2 million records and the target table has 15 million records.
Any suggestions or solutions for improving performance are appreciated
SQL query:
update targettable tt
set mnop = 'G',
where ( x,y,z ) in
select a.x, a.y,a.z
from table1 a
where (a.x, a.y,a.z) not in (
select b.x,b.y,b.z
from table2 b
where 'O' = b.defg
and mnop = 'P'
and hijkl = 'UVW';987981 wrote:
I was trying to improve the performance of the below query. I tried the following methods used merge instead of update, used bulk collect / Forall update, used ordered hint, created a temp table and upadated the target table using the same. The methods which I used did not improve any performance. And that meant what? Surely if you spend all that time and effort to try various approaches, it should mean something? Failures are as important teachers as successes. You need to learn from failures too. :-)
The data count which is updated in the target table is 2 million records and the target table has 15 million records.Tables have rows btw, not records. Database people tend to get upset when rows are called records, as records exist in files and a database is not a mere collection of records and files.
The failure to find a single faster method with the approaches you tried, points to that you do not know what the actual performance problem is. And without knowing the problem, you still went ahead, guns blazing.
The very first step in dealing with any software engineering problem, is to identify the problem. Seeing the symptoms (slow performance) is still a long way from problem identification.
Part of identifying the performance problem, is understanding the workload. Just what does the code task the database to do?
From your comments, it needs to find 2 million rows from 15 million rows. Change these rows. And then write 2 million rows back to disk.
That is not a small workload. Simple example. Let's say that the 2 million row find is 1ms/row and the 2 million row write is also 1ms/row. This means a 66 minute workload. Due to the number of rows, an increase in time/row either way, will potentially have 2 million fold impact.
So where is the performance problem? Time spend finding the 2 million rows (where other tables need to be read, indexes used, etc)? Time spend writing the 2 million rows (where triggers and indexes need to be fired and maintained)? Both? -
How to improve Query performance on large table in MS SQL Server 2008 R2
I have a table with 20 million records. What is the best option to improve query performance on this table. Is partitioning the table into filegroups is a best option or splitting the table into multiple smaller tables?
Hi bala197164,
First, I want to inform that both to partition the table into filegroups and split the table into multiple smaller tables can improve the table query performance, and they are fit for different situation. For example, our table have one hundred columns and
some columns are not related to this table object directly (for example, there is a table named userinfo to store user information, it has columns address_street, address_zip,address_ province columns, at this time, we can create a new table named as Address,
and add a foreign key in userinfo table references Address table), under this situation, by splitting a large table into smaller, individual tables, queries that access only a fraction of the data can run faster because there is less data to scan. Another
situation is our table records can be grouped easily, for example, there is a column named year to store information about product release date, at this time, we can partition the table into filegroups to improve the query performance. Usually, we perform
both of methods together. Additionally, we can add index to table to improve the query performance. For more detail information, please refer to the following document:
Partitioning:
http://msdn.microsoft.com/en-us/library/ms178148.aspx
CREATE INDEX (Transact-SQL):
http://msdn.microsoft.com/en-us/library/ms188783.aspx
TechNet
Subscriber Support
If you are
TechNet Subscription user and have any feedback on our support quality, please send your feedback
here.
Allen Li
TechNet Community Support -
How can I improve below SQL performance.
Hi,
How can I improve below SQL performance. This SQL consumes CPU and occures wait events. It is running every 10 seconds. When I look at the session information from Enterprise Manager I can see that "Histogram for Wait Event: PX Deq Credit: send blkd"
I created some indexes. I heard that the indexes are not used when there is a NULL but when I checked the xecution plan It uses index.
SELECT i.ID
FROM EXPRESS.invoices i
WHERE i.nbr IS NOT NULL
AND i.EXTRACT_BATCH IS NULL
AND i.SUB_TYPE='COD'
Explain Plan from Toad
SELECT STATEMENT CHOOSECost: 77 Bytes: 6,98 Cardinality: 349
4 PX COORDINATOR
3 PX SEND QC (RANDOM) SYS.:TQ10000 Cost: 77 Bytes: 6,98 Cardinality: 349
2 PX BLOCK ITERATOR Cost: 77 Bytes: 6,98 Cardinality: 349
1 INDEX FAST FULL SCAN INDEX EXPRESS.INVC_TRANS_INDX Cost: 77 Bytes: 6,98 Cardinality: 349
Execution Plan from Sqlplus
| Id | Operation | Name | Rows | Bytes | Cost | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 349 | 6980 | 77 | | | |
| 1 | PX COORDINATOR | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 349 | 6980 | 77 | Q1,00 | P->S | QC (RAND) |
| 3 | PX BLOCK ITERATOR | | 349 | 6980 | 77 | Q1,00 | PCWC | |
|* 4 | INDEX FAST FULL SCAN| INVC_TRANS_INDX | 349 | 6980 | 77 | Q1,00 | PCWP | |
Predicate Information (identified by operation id):
4 - filter("I"."NBR" IS NOT NULL AND "I"."EXTRACT_BATCH" IS NULL AND "I"."SUB_TYPE"='COD')
Note
- 'PLAN_TABLE' is old version
- cpu costing is off (consider enabling it)
Statistics
141 recursive calls
0 db block gets
5568 consistent gets
0 physical reads
0 redo size
319 bytes sent via SQL*Net to client
458 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00
Redo NoWait %: 100.00
Buffer Hit %: 99.70
In-memory Sort %: 100.00
Library Hit %: 99.81
Soft Parse %: 99.77
Execute to Parse %: 63.56
Latch Hit %: 90.07
Parse CPU to Parse Elapsd %: 0.81
% Non-Parse CPU: 98.88
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
latch: library cache 12,626 16,757 1,327 62.6 Concurrency
CPU time 5,712 21.Mar
latch: session allocation 1,848,987 1,99 1 07.Nis Other
PX Deq Credit: send blkd 1,242,265 981 1 03.Tem Other
PX qref latch 1,405,819 726 1 02.Tem Other
The database version is 10.2.0.1 but we haven't installed the patch 10.2.0.5. yet.
I am waiting your comments.
Thanks in advanceWelcome to the forum.
I created some indexes. I heard that the indexes are not used when there is a NULL but when I checked the xecution plan It uses index. What columns are indexed?
And what do:
select i.sub_type
, count(*)
from express.invoices i
where i.nbr is not null
and i.extract_batch is null
group by i.sub_type; and
select i.sub_type
, count(*)
from express.invoices i
group by i.sub_type; return?
Also, try use the {noformat}{noformat} tag when posting examples/execution plans etc.
See: HOW TO: Post a SQL statement tuning request - template posting for more tuning instructions.
It'll make a big difference:
SELECT i.ID
FROM EXPRESS.invoices i
WHERE i.nbr IS NOT NULL
AND i.EXTRACT_BATCH IS NULL
AND i.SUB_TYPE='COD'
Explain Plan from Toad
SELECT STATEMENT CHOOSECost: 77 Bytes: 6,98 Cardinality: 349
4 PX COORDINATOR
3 PX SEND QC (RANDOM) SYS.:TQ10000 Cost: 77 Bytes: 6,98 Cardinality: 349
2 PX BLOCK ITERATOR Cost: 77 Bytes: 6,98 Cardinality: 349
1 INDEX FAST FULL SCAN INDEX EXPRESS.INVC_TRANS_INDX Cost: 77 Bytes: 6,98 Cardinality: 349
Execution Plan from Sqlplus
| Id | Operation | Name | Rows | Bytes | Cost | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 349 | 6980 | 77 | | | |
| 1 | PX COORDINATOR | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 349 | 6980 | 77 | Q1,00 | P->S | QC (RAND) |
| 3 | PX BLOCK ITERATOR | | 349 | 6980 | 77 | Q1,00 | PCWC | |
|* 4 | INDEX FAST FULL SCAN| INVC_TRANS_INDX | 349 | 6980 | 77 | Q1,00 | PCWP | |
Predicate Information (identified by operation id):
4 - filter("I"."NBR" IS NOT NULL AND "I"."EXTRACT_BATCH" IS NULL AND "I"."SUB_TYPE"='COD')
Note
- 'PLAN_TABLE' is old version
- cpu costing is off (consider enabling it)
Statistics
141 recursive calls
0 db block gets
5568 consistent gets
0 physical reads
0 redo size
319 bytes sent via SQL*Net to client
458 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00
Redo NoWait %: 100.00
Buffer Hit %: 99.70
In-memory Sort %: 100.00
Library Hit %: 99.81
Soft Parse %: 99.77
Execute to Parse %: 63.56
Latch Hit %: 90.07
Parse CPU to Parse Elapsd %: 0.81
% Non-Parse CPU: 98.88
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
latch: library cache 12,626 16,757 1,327 62.6 Concurrency
CPU time 5,712 21.Mar
latch: session allocation 1,848,987 1,99 1 07.Nis Other
PX Deq Credit: send blkd 1,242,265 981 1 03.Tem Other
PX qref latch 1,405,819 726 1 02.Tem Other -
Index don't improve the performance
Hello everyone,
I've a problem on improving the performance of XMLType Column. In fact, I've created a table with tow column a Number column and a XMLType column and found out that the retreival time is quite unexceptal for the following SQL Statement:
Select id, extractValue(data, '/requestor/name') From
requestor Where extractValue(data, '/requestor/name')
= 'Req1640'
So I have created an Index like this:
create index req_name_index on requestor
extractValue(data, '/requestor/name')
but it don't improve the performance.
What's wrong?
ThanksHi David,
Once you had defined the 2 entries for the Browsing Index, have you rebuilt the indexes for the database ?
You can either use db2index or export and re-import the data.
Regards,
Ludovic. -
Hi All,
This is a continuation of the below given link (which died unanswered)
Row to column - SQL performance improvement
I was working on some logic and came up with an SQL posted below:
SELECT *
FROM
(SELECT NULL no_of_cols,
NULL brand_name,
NULL model,
NULL make,
NULL assetno,
NULL RACNO,
NULL branch,
LTRIM (SUBSTR (SYS_CONNECT_BY_PATH (b, ' | '), 2), ' | ' ) config_det,
NULL status,
NULL code
FROM
(SELECT 1 sno,
mst.prod_id,
prod_name b,
DENSE_RANK () OVER (ORDER BY hierarchy_key, mst.prod_id) rn
FROM appl_common_cat_mst,
appl_prod_cat_map MAP,
appl_common_prod_mst mst
WHERE ID = cat_id
AND MAP.prod_id = mst.prod_id
AND ID = 3
WHERE CONNECT_BY_ISLEAF = 1
START WITH rn = 1
CONNECT BY PRIOR rn = rn - 1
AND PRIOR sno = sno
UNION
SELECT DISTINCT rn no_of_cols,
model,
brand_name,
make,
assetno,
RACNO,
br_name branch,
LTRIM (SUBSTR (SYS_CONNECT_BY_PATH ((NVL (inv_descr, '-') ), ' | ' ), 2 ), ' | ' ) config_det,
sts,
code
FROM
(SELECT model,
br_name,
make,
brand_name,
assetno,
RACNO,
PROD_ID,
INV#,
ASSET_GRP,
LTRIM(SYS_CONNECT_BY_PATH(inv_descr, ', '),', ') inv_descr,
RN,
STS,
CODE ,
CNT
FROM
(SELECT ROW_NUMBER() OVER (PARTITION BY ASSETNO, ASSET_GRP, RN ORDER BY ASSETNO, ASSET_GRP, RN) INV_RN,
T1.*
FROM
(SELECT model,
MAX (br_name) OVER (PARTITION BY listofprod.assetno ORDER BY listofprod.assetno)br_name,
make,
brand_name,
listofprod.assetno,
MAX (racno) OVER (PARTITION BY listofprod.assetno ORDER BY listofprod.assetno) racno,
listofprod.prod_id,
inv#,
asset_grp,
inv_descr,
DENSE_RANK () OVER (PARTITION BY listofprod.assetno ORDER BY hierarchy_key, listofprod.prod_id) rn,
STS,
CODE ,
COUNT(inv_descr) over (partition BY asset_grp, code,listofprod.assetno order by asset_grp, code,listofprod.assetno) cnt
FROM
(SELECT brand_name,
inv_hdr.model,
inv_hdr.make,
asset_hdr.assetno,
racno,
inv_hdr.inv#,
inv_hdr.prod_id,
DBMS_LOB.SUBSTR (INV_DESCR, 4000, 1 ) INV_DESCR,
br_name
FROM APPL_ASSET_HDR_ACTL ASSET_HDR,
APPL_INVENTORY_HDR_ACTL INV_HDR,
appl_branch_mst brch_mst
WHERE inv_hdr.assetno = asset_hdr.assetno
AND ASSET_HDR.CAT_ID = 3
AND branch_code = br_code
AND BRANCH_CODE = 'MU'
) CONFIG,
(SELECT DISTINCT assetno,
listofprod.prod_id,
asset_grp,
sts,
code,
hierarchy_key
FROM
(SELECT DISTINCT asset_hdr.assetno,
asset_hdr.cat_id asset_grp,
inv_hdr.prod_id,
cmn_mst.VALUE sts,
cmn_mst.code code
FROM appl_asset_hdr_actl asset_hdr,
appl_inventory_hdr_actl inv_hdr,
appl_common_mst cmn_mst
WHERE inv_hdr.assetno = asset_hdr.assetno
AND asset_hdr.cat_id = 3
AND inv_hdr.current_sts = cmn_mst.code
) config,
(SELECT mst.prod_id,
hierarchy_key
FROM appl_common_cat_mst,
appl_prod_cat_map MAP,
appl_common_prod_mst mst
WHERE ID = cat_id
AND MAP.prod_id = mst.prod_id
AND ID = 3
) listofprod
ORDER BY assetno,
hierarchy_key,
LISTOFPROD.PROD_ID
) LISTOFPROD
WHERE CONFIG.ASSETNO (+)= LISTOFPROD.ASSETNO
AND CONFIG.PROD_ID (+) = LISTOFPROD.PROD_ID
)T1
)T2
WHERE connect_by_isleaf = 1
AND CNT <> 0
CONNECT BY prior INV_RN = INV_RN -1
AND PRIOR assetno = assetno
AND prior ASSET_GRP = ASSET_GRP
AND PRIOR RN = RN
START WITH INV_RN = 1
)X
WHERE connect_by_isleaf = 1
AND cnt <> 0
START WITH RN = 1
CONNECT BY PRIOR rn = rn - 1
AND PRIOR assetno = assetno
AND prior ASSET_GRP = ASSET_GRP
ORDER BY 1 ASC nulls FIRST
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
"CORE 11.2.0.1.0 Production"
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - ProductionWhich works perfectly on one machine (which is a win XP, c2d, 3gb ram machine), it gives result in less than 2 seconds . The result of
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);isPlan hash value: 2219017987
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 685 | 1505K| | 2170 (16)| 00:00:27 |
| 1 | VIEW | | 685 | 1505K| | 2170 (16)| 00:00:27 |
| 2 | SORT UNIQUE | | 685 | 1416K| 3656K| 1863 (100)| 00:00:23 |
| 3 | UNION-ALL | | | | | | |
|* 4 | FILTER | | | | | | |
|* 5 | CONNECT BY WITH FILTERING | | | | | | |
|* 6 | FILTER | | | | | | |
| 7 | COUNT | | | | | | |
| 8 | VIEW | | 2 | 86 | | 5 (20)| 00:00:01 |
| 9 | WINDOW SORT | | 2 | 40 | | 5 (20)| 00:00:01 |
| 10 | NESTED LOOPS | | 2 | 40 | | 4 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 2 | 16 | | 2 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | APPL_PROD_CAT_MAP | 2 | 12 | | 2 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | PK_PROD_MAP | 2 | | | 1 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | APPL_COMMON_PROD_MST | 1 | 12 | | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | | | 0 (0)| 00:00:01 |
|* 17 | HASH JOIN | | | | | | |
| 18 | CONNECT BY PUMP | | | | | | |
| 19 | COUNT | | | | | | |
| 20 | VIEW | | 2 | 86 | | 5 (20)| 00:00:01 |
| 21 | WINDOW SORT | | 2 | 40 | | 5 (20)| 00:00:01 |
| 22 | NESTED LOOPS | | 2 | 40 | | 4 (0)| 00:00:01 |
| 23 | NESTED LOOPS | | 2 | 16 | | 2 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
| 25 | TABLE ACCESS BY INDEX ROWID | APPL_PROD_CAT_MAP | 2 | 12 | | 2 (0)| 00:00:01 |
|* 26 | INDEX RANGE SCAN | PK_PROD_MAP | 2 | | | 1 (0)| 00:00:01 |
| 27 | TABLE ACCESS BY INDEX ROWID | APPL_COMMON_PROD_MST | 1 | 12 | | 1 (0)| 00:00:01 |
|* 28 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | | | 0 (0)| 00:00:01 |
| 29 | COUNT | | | | | | |
| 30 | VIEW | | 2 | 86 | | 5 (20)| 00:00:01 |
| 31 | WINDOW SORT | | 2 | 40 | | 5 (20)| 00:00:01 |
| 32 | NESTED LOOPS | | 2 | 40 | | 4 (0)| 00:00:01 |
| 33 | NESTED LOOPS | | 2 | 16 | | 2 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
| 35 | TABLE ACCESS BY INDEX ROWID | APPL_PROD_CAT_MAP | 2 | 12 | | 2 (0)| 00:00:01 |
|* 36 | INDEX RANGE SCAN | PK_PROD_MAP | 2 | | | 1 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | APPL_COMMON_PROD_MST | 1 | 12 | | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | | | 0 (0)| 00:00:01 |
|* 39 | FILTER | | | | | | |
|* 40 | CONNECT BY WITH FILTERING | | | | | | |
|* 41 | FILTER | | | | | | |
| 42 | COUNT | | | | | | |
| 43 | VIEW | | 683 | 1416K| | 1550 (2)| 00:00:19 |
|* 44 | FILTER | | | | | | |
|* 45 | CONNECT BY WITH FILTERING | | | | | | |
|* 46 | FILTER | | | | | | |
| 47 | COUNT | | | | | | |
| 48 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 49 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 50 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 51 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 52 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 53 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|* 54 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 55 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 56 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|* 57 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 58 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|* 59 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 60 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|* 61 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 62 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|* 64 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 65 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 67 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 68 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 69 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|* 70 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|* 71 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|* 72 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 73 | TABLE ACCESS BY INDEX ROWID| APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
|* 75 | HASH JOIN | | | | | | |
| 76 | CONNECT BY PUMP | | | | | | |
| 77 | COUNT | | | | | | |
| 78 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 79 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 80 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 81 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 82 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 83 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|* 84 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 85 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 86 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|* 87 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 88 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|* 89 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 90 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|* 91 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 92 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|* 93 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|* 94 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 95 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|* 96 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 97 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 98 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 99 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|*100 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|*101 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|*102 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 103 | TABLE ACCESS BY INDEX ROWID| APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|*104 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
| 105 | COUNT | | | | | | |
| 106 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 107 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 108 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 109 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 110 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 111 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|*112 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 113 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 114 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|*115 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 116 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|*117 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 118 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|*119 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 120 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|*121 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|*122 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 123 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|*124 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 125 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 126 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 127 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|*128 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|*129 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|*130 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 131 | TABLE ACCESS BY INDEX ROWID | APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|*132 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
|*133 | HASH JOIN | | | | | | |
| 134 | CONNECT BY PUMP | | | | | | |
| 135 | COUNT | | | | | | |
| 136 | VIEW | | 683 | 1416K| | 1550 (2)| 00:00:19 |
|*137 | FILTER | | | | | | |
|*138 | CONNECT BY WITH FILTERING | | | | | | |
|*139 | FILTER | | | | | | |
| 140 | COUNT | | | | | | |
| 141 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 142 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 143 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 144 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 145 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 146 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|*147 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 148 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 149 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|*150 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 151 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|*152 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 153 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|*154 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 155 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|*156 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|*157 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 158 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|*159 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 160 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 161 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 162 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|*163 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|*164 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|*165 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 166 | TABLE ACCESS BY INDEX ROWID| APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|*167 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
|*168 | HASH JOIN | | | | | | |
| 169 | CONNECT BY PUMP | | | | | | |
| 170 | COUNT | | | | | | |
| 171 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 172 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 173 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 174 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 175 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 176 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|*177 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 178 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 179 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|*180 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 181 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|*182 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 183 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|*184 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 185 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|*186 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|*187 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 188 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|*189 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 190 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 191 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 192 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|*193 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|*194 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|*195 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 196 | TABLE ACCESS BY INDEX ROWID| APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|*197 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
| 198 | COUNT | | | | | | |
| 199 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 200 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 201 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 202 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 203 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 204 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|*205 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 206 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 207 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|*208 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 209 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|*210 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 211 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|*212 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 213 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|*214 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|*215 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 216 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 | -
How to improve my pls/sql performance tunning skills
Hi All , I would like to learn more about pl/sql performance tunning , where or how can i get more knowledge in this area ?
Is there any tutorials which can help me to understand the Explain plan, Dbms_Profiler, Dbms_Advisor more etc ........Thanks . BcjExplain plan
http://www.psoug.org/reference/explain_plan.html
DBMS_PROFILER (10g)
http://www.psoug.org/reference/dbms_profiler.html
DBMS_HPROF (11g)
http://www.psoug.org/reference/dbms_hprof.html
DBMS_ADVISOR
http://www.psoug.org/reference/dbms_advisor.html
DBMS_MONITOR
http://www.psoug.org/reference/dbms_monitor.html
DBMS_SUPPORT
http://www.psoug.org/reference/dbms_support.html
DBMS_TRACE
http://www.psoug.org/reference/dbms_trace.html
DBMS_SQLTUNE
http://www.psoug.org/reference/dbms_sqltune.html -
SQL Performance - Looking for a hint or suggestion on how to improve performance.
I've linked several tables for the Sales Order, Delivery, and Invoicing. In essence, a query to show shipments and invoicing to a sales order.
Throughput is poor....60 + seconds, so I am looking for a solution...perhaps /* + hints*/ techinques to improve the performance of this code.
Here is a functional version of the code....
/* Functionally tested join between OM, WSH, AR Tables */
Select oeh.order_number
, trx_number as invc_no
, rctl.line_number as invc_line_no
, rctl.inventory_item_id rctl_inventory_item_id
, rctl.sales_order_line as SO_Line_No
, oel.line_id
, rctl.line_type
, oel.ship_from_org_id as oel_ship_from_org_id
, rctl.warehouse_id
, oel.ordered_quantity
, oel.shipped_quantity
, oel.invoiced_quantity
, rctl.UNIT_SELLING_PRICE
, rctl.extended_amount
, rctl.revenue_amount
, wdd.delivery_detail_id
, wnd.delivery_id
, rctl.interface_line_attribute1 -- Sales Order Number
, rctl.interface_line_attribute3 -- delivery_id (wsh)
, rctl.interface_line_attribute6 -- Sales Order Line Id
From apps.oe_order_headers_all oeh
, apps.oe_order_lines_all oel
, apps.wsh_delivery_details wdd
, apps.wsh_new_deliveries wnd
, apps.wsh_delivery_assignments wda
, apps.ra_customer_trx_all rct
, apps.ra_customer_trx_lines_all rctl
Where oeh.header_id = oel.header_id
and wdd.source_header_id = oeh.header_id
and wdd.source_header_id = oel.header_id
and wdd.source_line_id = oel.line_id
and wdd.SOURCE_CODE = 'OE'
and wdd.delivery_detail_id = wda.delivery_detail_id
and wda.delivery_id = wnd.delivery_id
and rctl.interface_line_attribute1 = to_char(oeh.order_number)
and rctl.interface_line_attribute6 = to_char(oel.line_id) --this is where explain plan cost is high!
and rctl.org_id = oel.org_id
and rctl.interface_line_attribute3 = to_char(wnd.delivery_id)
and rctl.customer_trx_id = rct.customer_trx_id
and rct.interface_header_context = 'ORDER ENTRY'
and oeh.order_number = '99999' --enter desired sales order here....
Order by 1,2,3,4;Can you provide your explain?
Also, can you do an "set autotrace traceonly" and run it again and post results? The results of that would help people here provide more reasonable suggestions.
(Mine so far is only: avoid hints - that's a crutch and not solving the real problem).
Are your statistics up to date?
select table_name, last_analyzed from dba_tables
where table_name in (
'OE_ORDER_HEADERS_ALL OEH','OE_ORDER_LINES_ALL OEL','WSH_DELIVERY_DETAILS WDD',
'WSH_NEW_DELIVERIES WND','WSH_DELIVERY_ASSIGNMENTS WDA','RA_CUSTOMER_TRX_ALL RCT',
'RA_CUSTOMER_TRX_LINES_ALL RCTL' ); -
Re: How to Improve the performance on Rollup of Aggregates for PCA Infocube
Hi BW Guru's,
I have unresolved issue and our team is still working on it.
I have already posted several questions on this but not clear on how to reduce the time on Rollup of Aggregates process.
I have requested for OSS note and searching myself but still could not found.
Finally i have executed one of the cube in RSRV with the database selection
"Database indexes of an InfoCube and its aggregates" and got warning messages i was tried to correct the error and executed once again but still i found warning message. and the error message are as follows: (this is only for one info cube we got 6 info cubes i am executing one by one).
ORACLE: Index /BI0/IACCOUNT~0 has possibly degenerated
ORACLE: Index /BI0/IPROFIT_CTR~0 has possibly degenerated
ORACLE: Index /BI0/SREQUID~0 has possibly degenerated
ORACLE: Index /BIC/D1001072~010 has possibly degenerated
ORACLE: Index /BIC/D1001132~010 has possibly degenerated
ORACLE: Index /BIC/D1001212~010 has possibly degenerated
ORACLE: Index /BIC/DGPCOGC062~01 has possibly degenerated
ORACLE: Index /BIC/IGGRA_CODE~0 has possibly degenerated
ORACLE: Index /BIC/QGMAPGP1~0 has possibly degenerated
ORACLE: Index /BIC/QGMAPPC2~0 has possibly degenerated
ORACLE: Index /BIC/SGMAPGP1~0 has possibly degenerated
i don't know how to move further on this can any one tell me how to tackle this problem to increase the performance on Rollup of Aggregates (PCA Info cubes).
every time i use to create index and statistics regularly to improve the performance it will work for couple of days and again the performance of the rollup of aggregates come down gradually.
Thanks and Regards,
Venkathi,
check in a sql client the sql created by Bi and the query that you use directy from your physical layer...
The time between these 2 must be 2-3 seconds,otherwise you have problems.(these seconds are for scripts that needed by Bi)
If you use "like" in your sql then forget indexes....
For more informations about indexes check google or your Dba .
Last, i mentioned that materialize view is not perfect,it help a lot..so why not try to split it to smaller ones....
ex...
logiacal dimensions
year-half-day
company-department
fact
quantity
instead of making one...make 3,
year - department - quantity
half - department - quantity
day - department - quantity
and add them as datasource and assign them the appropriate logical level at bussiness layer in administrator...
Do you use partioning functionality???
i hope i helped....
http://greekoraclebi.blogspot.com/
/////////////////////////////////////// -
How to improve SQL table perfomance
Hi,
I have one table having 5lacks recording during the select operation the query is very slow. The table is in third normal form having primary key and index.Is there any other way to improve table performance....Generally consider indexing ON clause and WHERE clause columns.
Also make sure the WHERE clause predicates are SARGable:
http://www.sqlusa.com/bestpractices/sargable/
Optimizaton: http://www.sqlusa.com/articles/query-optimization/
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014 -
How to improve the performance of the abap program
hi all,
I have created an abap program. And it taking long time since the number of records are more. And can anyone let me know how to improve the performance of my abap program.
Using se30 and st05 transaction.
can anyone help me out step by step
regds
harithaHi Haritha,
->Run Any program using SE30 (performance analysis)
Note: Click on the Tips & Tricks button from SE30 to get performance improving tips.
Using this you can improve the performance by analyzing your code part by part.
->To turn runtim analysis on within ABAP code insert the following code
SET RUN TIME ANALYZER ON.
->To turn runtim analysis off within ABAP code insert the following code
SET RUN TIME ANALYZER OFF.
->Always check the driver internal tables is not empty, while using FOR ALL ENTRIES
->Avoid for all entries in JOINS
->Try to avoid joins and use FOR ALL ENTRIES.
->Try to restrict the joins to 1 level only ie only for tables
->Avoid using Select *.
->Avoid having multiple Selects from the same table in the same object.
->Try to minimize the number of variables to save memory.
->The sequence of fields in 'where clause' must be as per primary/secondary index ( if any)
->Avoid creation of index as far as possible
->Avoid operators like <>, > , < & like % in where clause conditions
->Avoid select/select single statements in loops.
->Try to use 'binary search' in READ internal table. -->Ensure table is sorted before using BINARY SEARCH.
->Avoid using aggregate functions (SUM, MAX etc) in selects ( GROUP BY , HAVING,)
->Avoid using ORDER BY in selects
->Avoid Nested Selects
->Avoid Nested Loops of Internal Tables
->Try to use FIELD SYMBOLS.
->Try to avoid into Corresponding Fields of
->Avoid using Select Distinct, Use DELETE ADJACENT
Check the following Links
Re: performance tuning
Re: Performance tuning of program
http://www.sapgenie.com/abap/performance.htm
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp
check the below link
http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm
See the following link if it's any help:
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp
Check also http://service.sap.com/performance
and
books like
http://www.sap-press.com/product.cfm?account=&product=H951
http://www.sap-press.com/product.cfm?account=&product=H973
http://www.sap-img.com/abap/more-than-100-abap-interview-faqs.htm
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp
Performance tuning for Data Selection Statement
http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm
Debugger
http://help.sap.com/saphelp_47x200/helpdata/en/c6/617ca9e68c11d2b2ab080009b43351/content.htm
http://www.cba.nau.edu/haney-j/CIS497/Assignments/Debugging.doc
http://help.sap.com/saphelp_erp2005/helpdata/en/b3/d322540c3beb4ba53795784eebb680/frameset.htm
Run Time Analyser
http://help.sap.com/saphelp_47x200/helpdata/en/c6/617cafe68c11d2b2ab080009b43351/content.htm
SQL trace
http://help.sap.com/saphelp_47x200/helpdata/en/d1/801f7c454211d189710000e8322d00/content.htm
CATT - Computer Aided Testing Too
http://help.sap.com/saphelp_47x200/helpdata/en/b3/410b37233f7c6fe10000009b38f936/frameset.htm
Test Workbench
http://help.sap.com/saphelp_47x200/helpdata/en/a8/157235d0fa8742e10000009b38f889/frameset.htm
Coverage Analyser
http://help.sap.com/saphelp_47x200/helpdata/en/c7/af9a79061a11d4b3d4080009b43351/content.htm
Runtime Monitor
http://help.sap.com/saphelp_47x200/helpdata/en/b5/fa121cc15911d5993d00508b6b8b11/content.htm
Memory Inspector
http://help.sap.com/saphelp_47x200/helpdata/en/a2/e5fc84cc87964cb2c29f584152d74e/content.htm
ECATT - Extended Computer Aided testing tool.
http://help.sap.com/saphelp_47x200/helpdata/en/20/e81c3b84e65e7be10000000a11402f/frameset.htm
Just refer to these links...
performance
Performance
Performance Guide
performance issues...
Performance Tuning
Performance issues
performance tuning
performance tuning
You can go to the transaction SE30 to have the runtime analysis of your program.Also try the transaction SCI , which is SAP Code Inspector.
edited by,
Naveenan -
Improving the performance of Stored Procedure
need to improve the performance of this SP that is hitting two tables that holds about 24000 rowsUSE [trouble_database]
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
ALTER PROCEDURE [dbo].[the_trouble_StoredProcedure]
@troubleMedicatiotrouble_durationl int
as
declare @trouble_refil table
( troubleMedicatiotrouble_durationl int,
trouble_durationl int
declare @nRefillDispense int
if exists (select ml.lid from trouble_MedicaticDirectmd
inner join trouble_Medicatication ml on ml.troubleMedicatiotrouble_durationl=md.lID
where isnull(md.trouble_bRefillDisp,0)=1
and ml.lID <>(Select MIN(lID) from trouble_Medicatication where troubleMedicatiotrouble_durationl=@troubleMedicatiotrouble_durationl)
begin
select @nRefillDispense = isnull(nRefillDispense,9) from trouble_MedicaticDirect where lID=@troubleMedicatiotrouble_durationl
insert @trouble_refil (trouble_durationl)
select
Case szIncrement
when 'Day(s)' then isnull(trouble_durationl,0)
when 'Week(s)' then isnull(trouble_durationl,0) * 7
when 'Month(s)' then isnull(trouble_durationl,0) * 30
when 'Year(s)' then isnull(trouble_durationl,0) * 365
else 0
end as trouble_durationl
from
trouble_Medicatication where
troubleMedicatiotrouble_durationl=@troubleMedicatiotrouble_durationl
and lID<>(Select min(lID) from trouble_Medicatication where troubleMedicatiotrouble_durationl=@troubleMedicatiotrouble_durationl)
select @nRefillDispense as nRefillDispense, sum(trouble_durationl)as trouble_durationl from @trouble_refil
end
else
select 0 as nRefillDispense,0 as trouble_durationl
kyou can use Execution plain
http://stackoverflow.com/questions/7359702/how-do-i-obtain-a-query-execution-plan
and add index.
Index according to the fields you ask queries can improve performance greatly larger!
You can use the statistics for building indexes:
http://www.mssqltips.com/sqlservertip/2979/querying-sql-server-index-statistics/
Tzuri Ben Ezra | My Certifications:
CompTIA A+ ,Microsoft MCP, MCTS, MCSA, MCITP |
FaceBook: Tzuri FaceBook | vCard:
Tzuri vCard |
Microsoft ID:
Microsoft Transcript
|
Maybe you are looking for
-
PLEASE HELP iTUNES WONT RUN!!!
I have uninstalled and downloaed iTunes numerous times. Before it just would not open. I thought it might be a virus so i went out and spent another $50 on virus protection program. I reinstalled iTunes again, installed service pack 2, and installed
-
android version 4.42 Kit Kat model sm n900t Samsung note 3 skype version Skype 4.9.0.45564 Phone does not ring on incoming calls Phone does not always hook up to bluetooth connection but t-mobile phone connection always work. Phone mic dosent work m
-
Hello, I recently tried to update my ipod to the new update for the ipod touch and it had to restore my ipod, it ersed all my data! Please help!
-
Can i retrieve a photo that i took with my iphone, had in my camera roll, but sent to trash?
I took a phot with my iphone, it was saved in the camera roll, but I accidentally sent it to the trash. Can I somhow retrieve it?
-
Sparks/lights inside WRT54GL v1.1
I have a WRT54GL v1.1 router that had been working for a while. It recently stopped working, and my attempts to re-flash the router seem to have made things worse. Current status: - The following lights are on immediately after powering on the router