PERFORMANCE IMPROVEMENT for a DB view
Hi,
There is around 300000 entries with MDBS and we are having very slow access and low performance.
Following is the query.
ima61v internal table does have only single entry in a sample run.
SELECT wemng menge wepos elikz umrez
umren matnr werks lgort pstyp retpo
FROM mdbs
INTO (mdbs-wemng, mdbs-menge, mdbs-wepos, mdbs-elikz,
mdbs-umrez, mdbs-umren, mdbs-matnr, mdbs-werks,
mdbs-lgort, mdbs-pstyp, mdbs-retpo)
WHERE matnr EQ ima61v-matnr
AND werks EQ ima61v-werks
AND loekz EQ space
AND elikz EQ space
AND bstyp IN ('F', 'L').
The following is the ST05 analysis.
Executions - 1
Identical Duration - 0
Records - 0
Time/exec - 21,766,348
Rec/exec. - 0
AvgTime/R. - 21,766,348
MinTime/R. - 21,766,348
Obj. type - MDBS
The SQL explain is as follows.
SELECT STATEMENT ( Estimated Costs = 7 , Estimated #Rows = 1 )
6 TABLE ACCESS BY INDEX ROWID EKET
( Estim. Costs = 3 , Estim. #Rows = 1 )
5 NESTED LOOPS
( Estim. Costs = 7 , Estim. #Rows = 1 )
3 INLIST ITERATOR
2 TABLE ACCESS BY INDEX ROWID EKPO
( Estim. Costs = 4 , Estim. #Rows = 1 )
1 INDEX RANGE SCAN EKPO~1
( Estim. Costs = 3 , Estim. #Rows = 1 )
Search Columns: 6
4 INDEX RANGE SCAN EKET~0
( Estim. Costs = 2 , Estim. #Rows = 1 )
Search Columns: 3
1.The tables are not going for full scan.
2. DB stats are up to date.
3. All indexes show in SQL explain are available at DB
Apart from all these what else we can check to identify what is the problem? if we change the variant for multiple mateirals and if we go for b/g execution it is taking more than 30 min to execute.
and also let me know how to resolve the issue.
Thanks in Advance.
Praneeth
3 simple points:
I am quite sure that you did not run the statement before you did run the trace, please repeat and show the result of the second or third execution.
I guess that is the only point, the explain is so simple that it can no take very long.
And ... there is no record coming back .... I know that there are many executions where no record comes back, but is it really a good point for a discussion of a performance problem? Is this statement never successful?
Number of records:
The view has no records, you must check the two tables EKKE and EKPO, how many records are in these tables.
Similar Messages
-
DMA Performance Improvements for TIO-based Devices
Hello!
DMA Performance Improvements for TIO-based Devices
http://digital.ni.com/public.nsf/websearch/1B64310FAE9007C086256A1D006D9BBF
Can I apply the procedure to NI-DAQmx 9? These ini-files dont seem to exist anymore in the newer version.
Best, ViktorHi Viktor,
this page is 7 years old and doesn't apply to the DAQmx.
Regards, Stephan -
Performance improvement for ALE/IDOC processing
Dear experts,
Could you let me know any information to tune performance?
In our system (SAP R/3 Enterprise 6.20), material master data is distributed from one client to other clients in the same instance. It is because material master is maintained centrally, and is distributed to other clients for member companies.
During the night batch, distributing master data takes more than 2 hours. Although the distribution usually finishes without errors, we would like to explore ways to improve processing performance. Especially, program RBDMIDOC runs long time to create IDOC for MATMAS, even 0 master IDOC is set eventually.
OSS notes of the list for OS/DB/SAP parameters related to ALE/IDOC, tips in organizing batch jobs, etc, will be very appreciated.
Many Thanks,
NoriI'd recommend to profile the program at least once to see where there's possible room for improvements. I.e. an ABAP runtime analysis and SQL trace would be good for a start. You can check out the links in thread Please Read before Posting in the Performance and Tuning Forum, which will give you some references if you need them. Once you have more details, you either know what you need to do or you can provide them and ask a more specific question (and thus you will receive much better answers).
As a general remark though I've seen often poor performance initially on the changer pointer selection, because there are too many entries in the table (due to system generating unnecessary change pointers, which should be disabled or/and lack of proper reorganization, i.e. deletion of old/processed change pointers via BD22). Sounds like this is most likely also the cause of your problem, because otherwise it's hard to explain long run times without generating any master IDocs. You can check the number of change pointers easily via view BDCPV or BDCP2 - it depends how you store your change pointers (most likely you find them via view BDCPV in a 6.20 system, unless somebody switched it to the newer BDCP2).
If you still have them in BDCPV (or the underlying tables to be more precise), check out [OSS note 305462 - MOD: Migration change pointer to table BDCP2|https://service.sap.com/sap/support/notes/305462], which will provide you a general hint how to do that (and thus also improve the performance). However, if you're currently not deleting any old change pointers, you should ensure that a regular job runs for transaction BD22 (program RBDCPCLR). You'll easily find other (possibly relevant) OSS notes by doing a search yourself... -
Performance Improvment for CTE
I have below query which is used in a View which checks duplicate rows and selects it for further processing
with MyCTETable (DefId, CustId,MyId,TacticId,cnt) as
(select BaseTable.DefId ,
BaseTable.MyCustId,
WL.Id,
BaseTable.TacticId ,
COUNT(*)
from WorkList WL
inner Join WorkListMeta WLMeta ON WL.WorkListMetaId = WLMeta.Id
and WLMeta.MyAnswer='1'
Inner Join BaseTable BaseTable ON WL.Id = BaseTable.DefId
and BaseTable.Org = '101'
and BaseTable.State<>'d'
group by BaseTable.DefId,
WL.Id,
BaseTable.MyCustId,
BaseTable.TacticId having COUNT(*)>1)
select list.Id
from MyCTETable,
BaseTable as list
where list.DefId = MyCTETable.DefId
and list.MyCustId =MyCTETable.CustId
and list.MyCustId in
(Select distinct MyCustId
from BaseTable
where DefId =MyCTETable.DefId
and Done<>'0'
and Status <>'d')
Above query is returning 532084 records in around 15 mins.
Just need your opinion, any changes/optimization can be done in query to improve the performance?
Note: Indexes and statistics are all maintained.
-Vaibhav ChaudhariHere is a method that can (depending on some other factors) sometimes gives you a method of eliminating one, maybe both of your self joins, if you're using them just to identify duplicates. It uses the OVER() clause to give you your COUNT(*) as part
of your primary result set.
This is just an example of the possibility, I didn't look closely enough at your code to say for sure it'll help in your case, but on the surface, I bet you could eliminate one of those self joins.
;With X (letter) as (Select 'a' UNION ALL select 'b' UNION ALL select 'b' UNION ALL select 'c')
, Y as (select *, count(letter) over(partition by letter) as count_this_letter from X)
Select * from Y where count_this_letter > 1
You don't have to use the WHERE clause as I did, that was just to show a way to refer to cases where a duplicate existed.
EDIT/Clarification: My mocked up example is just an example. You would tweak your OVER clause probably something like "Count(*) Over(Partition byObDefListPKey, BpaPKey, JobDefid)" to count and group by those fields, while still presenting
the full result set. -
Performance improvement for af:table
My page consists in a table and button. The button displays a popup containing several tabs with trees inside them that allows the user to filter the data. Clicking OK on the button runs the query and refresh the table. The table is configured as followed
autoHeightRows="1000"
fetchSize="The number of rows returned by the query"
contentDelivery="immediate"
immediate="true"
value="call a method returning a List<MyLineBean> from managed bean"
One requirement is to display the table with no scrollbar.
The first issue is that displaying a table with 1000 rows is slow to render, but also makes the browser slow (Chrome in my case). The corresponding js file is about 11MB. I can understand that processing a 11MB JS file can be slow especially with DOM creation.
The other issue I noticed is that the speed to display the popup depends on the size of the table. With a 1000 rows table, I click on the button, the first server request is done after 3s. The JS size is about 20KB and network latency is low. Closing the popup with no processing is also slow (~2s). Now if I do the same experiments with a table of 13 rows (180KB of JS), the popup displays and closes instantaneously.
My priority is to improve the speed of displaying of the popup. Is there any reason why the speed depends on the size of the table?
ADF 11gR1 + WebCenter PortalHi user,
Follow this link GEBS | ADF View Object Performance Tunning Analysis for better performance of table..
Thank You. -
Control Center performance improvement for large (runtime) repositories
Hi all,
I'm currently working on a large OWB project. We have serious performance issues with the Control Center (version 10.2.0.3) I have investigated what happens when you start the Control Center (SQL traces) and have implemented the following:
-- slow query 1
-- also added parent_audit_object_id to this index to help with slow query 3
CREATE INDEX colin_wb_rt_audit_objects_1 ON
wb_rt_audit_objects(audit_object_id, parent_audit_object_id, audit_unit_id, number_of_script_errors, number_of_script_warnings);
-- slow query 2
CREATE INDEX colin_wb_rt_audit_scripts_1 ON
wb_rt_audit_scripts(audit_object_id, audit_script_id);
-- slow query 3
CREATE INDEX colin_wb_rt_audit_objects_2 ON
wb_rt_audit_objects(object_uoid, audit_object_id DESC, audit_unit_id);
CREATE INDEX colin_wb_rt_audit_objects_3 ON
wb_rt_audit_objects(parent_audit_object_id, audit_object_id);The reason this helps is that now the indexes contain all the data needed in the slow queries obviating the need to go to the tables, which in these cases are particularly expensive as the tables contain large LOB columns.
It is very interesting to see that two of the indexes can replace existing indexes that were added in a recent patch!
For the wb_rt_warehouse_objects table I've implemented an alternative solution, and that is to move the storage of 2 of the 3 CLOBs out-of-row:
ALTER TABLE wb_rt_warehouse_objects MOVE
TABLESPACE <xxx>
LOB (creation_script)
STORE AS (
TABLESPACE <xxx>
DISABLE STORAGE IN ROW
LOB (client_info)
STORE AS (
TABLESPACE <xxx>
DISABLE STORAGE IN ROW
;where you should replace <xxx> with the tablespaces of your choice.
I hope this will help some of you with large repositories.
Cheers,
ColinHi David,
I hope these improvements can be implemented! ;-)
We have a runtime repository with some 2300 deployed tables and an equivalent number of mappings.
Total number of rows in wb_rt_warehouse_objects is more than 40,000
I used an SQL trace and tkprof to identify some high cost queries -- individually these queries perform quite reasonably but when executed many times (as happens when starting the Control Center) these can cost many tens of extra seconds.
If you're interested I can send you
* traces
* tkprofs
* the slow queries
and then you can see the before and after explain plans and why this works.
Please contact me at colinthart at the Google mail service :-)
Cheers,
Colin -
Performance improvement for select query
Hi all,
need to improve performace for the below select query as it is taking long time
SELECT vbeln pdstk
FROM vbuk INTO TABLE it_vbuk1 FOR ALL ENTRIES IN it_likp
WHERE vbeln = it_likp-vbeln AND
wbstk = 'C' AND "pdstk = ' ' AND
vbtyp IN gr_delivery AND
( fkstk = 'A' OR fkstk = 'B' ) OR
( fkivk = 'A' OR fkivk = 'B' ).
Regards,
KumarHi,
Check if it_likp is sorted on vbeln.
SELECT vbeln pdstk
FROM vbuk INTO TABLE it_vbuk1 FOR ALL ENTRIES IN it_likp
WHERE vbeln = it_likp-vbeln AND
wbstk = 'C' AND
vbtyp IN gr_delivery AND
( ( fkstk = 'A' OR fkstk = 'B' ) OR <-- check this condition , if ( ) is needed ...
( fkivk = 'A' OR fkivk = 'B' ) ) .
Regards,
Srini. -
Performance Optimization for Cubes
Hi All,
In our project, we have a daily proces chain which will refresh four reporting cube, which is consuming 8-10 hours to complete the refresh. We have suggested to archive the historical data to the new cube to improve the performance of the daily load
In UAT, the performance of the daily load did not improved after we performed the archiving.
Kindly suggest the performance improvement for the cubes.
Regards
Suresh KumarHi,
Before loading the cube , you need to delete the index and once the load is complete recreate the same.For this you have to go to the manage screen of the infocube----> Performance Tab.
Also Create the DB Statistics.For this you have to go to the manage screen of the infocube----> Performance Tab.This will reduce the load time to a considerable amount.
Also increase the Maximum size of the data packet in the Infopackage. For this you have to go to the infopackage-->Scheduler in the menu bar--> Data S. Default Data Transfer.Increase the size to a considerable amount(not very high).Also increase the Number of Data packets per info IDOC. This field will be available just after Maximum size of the data packet in the Infopackage.
Hope It Helps,
Regards,
Amit
Edited by: Amit Kr on Sep 4, 2009 5:37 PM -
Pls help me to modify the query for performance improvement
Hi,
I have the below initialization
DECLARE @Active bit =1 ;
Declare @id int
SELECT @Active=CASE WHEN id=@id and [Rank] ='Good' then 0 else 1 END FROM dbo.Students
I have to change this query in such a way that the conditions id=@id and [Rank] ='Good' should go to the where condition of the query. In that case, how can i use Case statement to retrieve 1 or 0? Can you please help me to modify this initialization?I dont understand your query...May be below? or provide us sample data and your output...
SELECT * FROM dbo.students
where @Active=CASE
WHEN id=@id and rank ='Good' then 0 else 1 END
But, I doubt you will have performance improvement here?
Do you have index on id?
If you are looking for getting the data for @ID with rank ='Good' then use the below:Make sure, you have index on id,rank combination.
SELECT * FROM dbo.students
where id=@id
and rank ='Good' -
Performance improvement in OBIEE 11.1.1.5
Hi all,
In OBIEE 11.1.1.5 reports takes long time to load , Kindly provide me some performance improvement guides.
Thanks,
Haree.Hi Haree,
Steps to improve the performance.
1. implement caching mechanism
2. use aggregates
3. use aggregate navigation
4. limit the number of initialisation blocks
5. turn off logging
6. carry out calculations in database
7. use materialized views if possible
8. use database hints
9. alter the NQSONFIG.ini parameters
Note:calculate all the aggregates in the Repository it self and Create a Fast Refresh for MV(Materialized views).
and you can also do one thing you can schedule an IBOT to run the report every 1 hour or some thing so that the report data will be cached and when the user runs the report the BI Server extracts the data from Cache
This is the latest version for OBIEE11g.
http://blogs.oracle.com/pa/resource/Oracle_OBIEE_Tuning_Guide.pdf
Report level:
1. Enable cache -- change nqsconfig instead of NO change to YES.
2. GO--> Physical layer --> right click table--> properties --> check cacheable.
3. Try to implement Aggregate mechanism.
4.Create Index/Partition in Database level.
There are multiple other ways to fine tune reports from OBIEE side itself:
1) You can check for your measures granularity in reports and have level base measures created in RPD using OBIEE utility.
http://www.rittmanmead.com/2007/10/using-the-obiee-aggregate-persistence-wizard/
This will pick your aggr tables and not detailed tables.
2) You can use Caching Seeding options. Using ibot or Using NQCMD command utility
http://www.artofbi.com/index.php/2010/03/obiee-ibots-obi-caching-strategy-with-seeding-cache/
http://satyaobieesolutions.blogspot.in/2012/07/different-to-manage-cache-in-obiee-one.html
OR
http://hiteshbiblog.blogspot.com/2010/08/obiee-schedule-purge-and-re-build-of.html
Using one of the above 2 methods, you can fine tune your reports and reduce the query time.
Also, on a safer side, just take the physical SQL from log and run it directly on DB to see the time taken and check for the explain plan with the help of a DBA.
Hope this help's
Thanks,
Satya
Edited by: Satya Ranki Reddy on Aug 12, 2012 7:39 PM
Edited by: Satya Ranki Reddy on Aug 12, 2012 8:12 PM
Edited by: Satya Ranki Reddy on Aug 12, 2012 8:20 PM -
MV Refresh Performance Improvements in 11g
Hi there,
the 11g new features guide, says in section "1.4.1.8 Refresh Performance Improvements":
"Refresh operations on materialized views are now faster with the following improvements:
1. Refresh statement combinations (merge and delete)
2. Removal of unnecessary refresh hint
3. Index creation for UNION ALL MV
4. PCT refresh possible for UNION ALL MV
While I understand (3.) and (4.) I don't quite understand (1.) and (2.). Has there been a change in the internal implementation of the refresh (from a single MERGE statement)? If yes, then which? Is there a Note or something in the knowledge base, about these enhancements in 11g? I couldn't find any.
Considerations are necessary for migration decision to 11g or not...
Thanks in advance.I am not quit sure, what you mean. You mean perhaps, that the MVlogs work correctly when you perform MERGE stmts with DELETE on the detail tables of the MV?
And were are the performance improvement? What is the refresh hint?
Though I am using MVs and MVlogs at the moment, our app performs deletes and inserts in the background (no merges). The MVlog-based fast refresh scales very very bad, which means, that the performance drops very quickly, with growing changed data set. -
Why GN_INVOICE_CREATE has no performance improvement even in HANA landscape?
Hi All,
We have a pricing update program which is used to update the price for a Material Customer combination(CMC).This update is done using the FM 'GN_INVOICE_CREATE'.
The logic is designed to loop on customers, wherein this FM will be called passing all the materials valid for that customer.
This process is taking days(Approx 5 days) to get executed and updated for CMC of 100 million records.
Hence we are planning to move towards HANA for better improvement in performance.
We designed the same programs in the HANA landscape and executed it in both systems for 1 customer and 1000 material combination.
Unfortunately, both the systems gave same runtimes around 27 seconds for execution.
This is very disappointing thinking the performance improvement we should have on HANA landscape.
Could anyone throw light on any areas where we are missing out and why no performance improvement was obtained ?
Also is there any configuration related changes to be done on HANA landscape for better performance.?
The details regarding both the systems are as below.
Suite on HANA:
SAP_BASIS : 740
SAP_APPL : 617
ECC
SAP_BASIS : 731
SAP_APPL : 606
Also see the below screenshots of the system details.
HANA:
ECC:
Thanks & regards,
NaseemHi,
just to fill in on Lars' already exhaustive comments:
Migrating to HANA gives you lots of options to replace your own functionality (custom ABAP code) wuth HANA artifacts - views or SQLscript procedures. This is where you can really gain on performance. Expecting ABAP code to automatically run faster on HANA may be unrealistic, since it depends on the functionality of the code and how well it "translates" to a HANA environment. The key to really minimize run time is to replace DB calls with specific HANA views or procedures, then call these from your code.
I wrote a blog on this; you might find it useful as a general introduction:
A practical example of ABAP on HANA optimization
When it comes to SAP standard code, like your mentioned FM, it is true that SAP is migrating some of this functionality to HANA-optimized versions, but this doesn't mean everything will be optimized in one go. This particular FM is probably not among those being initially selected for "HANAification", so you basically have to either create your own functionality (which might not be advisable due to the fact that this might violate data integrity) or just be patient.
But again, the beauty of HANA lies in the brand new options for developers to utilize the new ways of pushing code down to the DB server. Check out the recommendations from Lars and you'll find yourself embarking on a new and exciting journey!
Also - as a good starting point - check out the HANA developer course on open.sap.com.
Regards,
Trond -
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 | -
5 tables Used - Performance Improvement Help Req...
Hello Experts,
I am using 5 table joins to fetch data from query; does this will degrade performance?
Please find below the query used; in this WHERE Clause, 1) le.locker_entry_id is PRIMARY Key column
2) dc.object_type - created a index on this column 3) Created a function based index on this column upper(dt.partner_device_type)
Can any other code improvement be done or view be created ?
Please suggest.
SELECT count(*) FROM locker_entry le;
COUNT(*)
1762
SELECT count(*) FROM digital_compatibility dc;
COUNT(*)
227757
SELECT count(*) FROM digital_encode_profile dep;
COUNT(*)
48
SELECT count(*) FROM device_type dt;
COUNT(*)
421
SELECT count(*) FROM digital_sku dsku;
COUNT(*)
26037
EXPLAIN PLAN FOR
SELECT
/*+ INDEX(dep, DIGITAL_ENCODE_PROFILE_ID_PK) */
DISTINCT le.locker_entry_id AS locker_entry_id,
dep.delivery_type
FROM locker_entry le,
digital_compatibility dc,
digital_encode_profile dep,
device_type dt,
digital_sku dsku
WHERE le.sku_id = dsku.legacy_id
AND le.digital_package_id = dsku.digital_package_id
AND dsku.digital_sku_id = dc.object_id
AND dc.encode_profile_id =dep.digital_encode_profile_id
AND dt.capability_set_id =dc.capability_set_id
AND le.locker_entry_id IN (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20, :21, :22, :23, :24, :25, :26, :27, :28, :29, :30, :31, :32)
AND dc.object_type =:"SYS_B_0"
AND upper(dt.partner_device_type) =:33;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 370 | 481 (3)|
| 1 | HASH UNIQUE | | 1 | 370 | 481 (3)|
| 2 | NESTED LOOPS | | 1 | 370 | 480 (3)|
| 3 | NESTED LOOPS | | 1 | 336 | 479 (3)|
|* 4 | HASH JOIN | | 1 | 193 | 478 (3)|
| 5 | MAT_VIEW ACCESS BY INDEX ROWID | DIGITAL_SKU | 1 | 48 | 5 (0)|
| 6 | NESTED LOOPS | | 16 | 1392 | 5 (0)|
| 7 | INLIST ITERATOR | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID | LOCKER_ENTRY | 32 | 1248 | 1 (0)|
|* 9 | INDEX RANGE SCAN | LOCKER_ENTRY_ID_PK | 32 | | 1 (0)|
| 10 | BITMAP CONVERSION TO ROWIDS | | | | |
| 11 | BITMAP AND | | | | |
| 12 | BITMAP CONVERSION FROM ROWIDS| | | | |
|* 13 | INDEX RANGE SCAN | IDX_DIGITAL_SKU_LEGACY_ID | 1 | | 1 (0)|
| 14 | BITMAP CONVERSION FROM ROWIDS| | | | |
|* 15 | INDEX RANGE SCAN | IDX_DIGITAL_PACKAGE_ID | 1 | | 1 (0)|
|* 16 | MAT_VIEW ACCESS FULL | DIGITAL_COMPATIBILITY | 2098 | 217K| 472 (3)|
|* 17 | INDEX RANGE SCAN | DEVICE_TYPE_IDX | 1 | 143 | 1 (0)|
| 18 | MAT_VIEW ACCESS BY INDEX ROWID | DIGITAL_ENCODE_PROFILE | 1 | 34 | 1 (0)|
|* 19 | INDEX UNIQUE SCAN | DIGITAL_ENCODE_PROFILE_ID_PK | 1 | | 1 (0)|
Predicate Information (identified by operation id):
4 - access("DSKU"."DIGITAL_SKU_ID"=TO_NUMBER("DC"."OBJECT_ID"))
9 - access("LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:1) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:2) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:3) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:4) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:5) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:6) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:7) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:8) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:9) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:10) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:11) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:12) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:13) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:14) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:15) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:16) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:17) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:18) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:19) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:20) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:21) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:22) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:23) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:24) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:25) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:26) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:27) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:28) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:29) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:30) OR
"LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:31) OR "LE"."LOCKER_ENTRY_ID"=TO_NUMBER(:32))
13 - access("LE"."SKU_ID"="DSKU"."LEGACY_ID")
15 - access("LE"."DIGITAL_PACKAGE_ID"="DSKU"."DIGITAL_PACKAGE_ID")
16 - filter("DC"."OBJECT_TYPE"=:SYS_B_0)
17 - access("DT"."CAPABILITY_SET_ID"="DC"."CAPABILITY_SET_ID" AND
UPPER("PARTNER_DEVICE_TYPE")=:33)
19 - access("DC"."ENCODE_PROFILE_ID"="DEP"."DIGITAL_ENCODE_PROFILE_ID")
Note
- 'PLAN_TABLE' is old version
Trace information
=================
recursive calls 17
db block gets 0
consistent gets 239
physical reads 61
redo size 0
bytes sent via SQL*Net to client 742
bytes received via SQL*Net from client 1361
SQL*Net roundtrips to/from client 2
sorts (memory) 5
sorts (disk) 0
Edited by: Linus on Oct 10, 2011 2:44 AMLinus wrote:
Yes Bravid i got regarding the point to remove the hint from the query; unless there is a change in execution plan with index hint.
My concern is; is there any issues by keeping 5 tables on single query and will this degrade performance?
Because as of during the certification practise; i used to overcome some where ,"NOT to use many table joins".
So that is reason i am asking you; sorry if am wrong in any ways.
Thanks...There's nothing inherently wrong with joining lots of tables and there isn't one specific thing that will degrade performance. You could have a query that joins 2 tables performing very badly and a query with 10 tables that performs very well. A lot of it is down to the quality of the decisions the optimiser can make. To get the best decisions out of it you need to make sure it had enough information to work with. So that means making sure stats are available and relevant for the data you're querying and removing any hints unless you have a specific reason to use them.
Earlier this year I had the "joy" of working with a query that had 65 tables in it. It was an INSERT INTO...SELECT FROM and it was a clear example of where a single statement really should have been about 6 or 7 separate statements. The reason in this case was because there were 6 or 7 different sections to the query that had essentially no relationship with each other and they were all outer joined and used lots of analytic functions and case statements to categorise each row and populate the same columns with different values depending on which query block it had originated from.
This is an extreme example but the point is you have to look at the statement and decide whether it does it's job well. My personal preference is to try to avoid big "generic" SQL statements that cater for lots of different scenarios because they can easily become over complicated and difficult to maintain and tune.
HTH
David
Edited by: Bravid on Oct 10, 2011 1:53 PM -
Performance Issue for BI system
Hello,
We are facing performance issues for BI System. Its a preproductive system and its performance is degrading badly everyday. I was checking system came to know program buffer hit ratio is increaasing everyday due to high Swaps. So asked to change the parameter abap/buffersize which was 300Mb to 500Mb. But still no major improvement is found in the system.
There is 16GB Ram available and Server is HP-UX and with Netweaver2004s with Oracle 10.2.0.4.0 installed in it.
The Main problem is while running a report or creating a query is taking way too long time.
Kindly help me.Hello SIva,
Thanks for your reply but i have checked ST02 and ST03 and also SM50 and its normal
we are having 9 dialog processes, 3 Background , 2 Update and 1 spool.
No one is using the system currently but in ST02 i can see the swaps are in red.
Buffer HitRatio % Alloc. KB Freesp. KB % Free Sp. Dir. Size FreeDirEnt % Free Dir Swaps DB Accs
Nametab (NTAB) 0
Table definition 99,60 6.798 20.000 29.532 153.221
Field definition 99,82 31.562 784 2,61 20.000 6.222 31,11 17.246 41.248
Short NTAB 99,94 3.625 2.446 81,53 5.000 2.801 56,02 0 2.254
Initial records 73,95 6.625 998 16,63 5.000 690 13,80 40.069 49.528
0
boldprogram 97,66 300.000 1.074 0,38 75.000 67.177 89,57 219.665 725.703bold
CUA 99,75 3.000 875 36,29 1.500 1.401 93,40 55.277 2.497
Screen 99,80 4.297 1.365 33,35 2.000 1.811 90,55 119 3.214
Calendar 100,00 488 361 75,52 200 42 21,00 0 158
OTR 100,00 4.096 3.313 100,00 2.000 2.000 100,00 0
0
Tables 0
Generic Key 99,17 29.297 1.450 5,23 5.000 350 7,00 2.219 3.085.633
Single record 99,43 10.000 1.907 19,41 500 344 68,80 39 467.978
0
Export/import 82,75 4.096 43 1,30 2.000 662 33,10 137.208
Exp./ Imp. SHM 89,83 4.096 438 13,22 2.000 1.482 74,10 0
SAP Memory Curr.Use % CurUse[KB] MaxUse[KB] In Mem[KB] OnDisk[KB] SAPCurCach HitRatio %
Roll area 2,22 5.832 22.856 131.072 131.072 IDs 96,61
Page area 1,08 2.832 24.144 65.536 196.608 Statement 79,00
Extended memory 22,90 958.464 1.929.216 4.186.112 0 0,00
Heap memory 0 0 1.473.767 0 0,00
Call Stati HitRatio % ABAP/4 Req ABAP Fails DBTotCalls AvTime[ms] DBRowsAff.
Select single 88,59 63.073.369 5.817.659 4.322.263 0 57.255.710
Select 72,68 284.080.387 0 13.718.442 0 32.199.124
Insert 0,00 151.955 5.458 166.159 0 323.725
Update 0,00 378.161 97.884 395.814 0 486.880
Delete 0,00 389.398 332.619 415.562 0 244.495
Edited by: Srikanth Sunkara on May 12, 2011 11:50 AM
Maybe you are looking for
-
I can't save a file to the desktop nor create a new folder
I extracted 2 pages from a PDF file. They are there according to the "open" dialogue but the second one is not there as an icon. I can attach it to an email but the email won't send - it says the attachments are still downloading. I can't create a ne
-
Simple Button not functioning correctly?
The button functions correctly, but for some reason when I launch the flash page, the button shows up with the alpha at 50%. I narrowed it down to the var elasticTween3:Tween = new Tween(my_box,"alpha",Strong.easeOut, 0.5, 1, 1, true); line of co
-
Environment is WLC 2106 with 4 LWAPP access points. Currently running 2 WLANs: 1 using 802.1x authentication with a Windows IAS (RADIUS) server for Active Directory authentication; 1 using basic WEP for guest access that drops the user in it's own se
-
HttpServlet and BPEL processes
Hi! I've created a Http Servlet in my web application (in Jdeveloper, using ADF BC, application is deployed to Oracle AS 10.1.3.3 where BPEL PM is also runnig) that has doPost method implemented. This servlet is 'listening' on defined URL for http PO
-
Hi Friends, we have a PO with a line item that has a certain price. at the time of GR however the amt in local currency is almost 4 times the PO price. i am unable to comprehend the drastic change in price. there is no split valuation for the materi