DECODE Vs CASE Performance Issue

Hi,
The comparison is on basis of performance. There are billions of records to be processed and millions to be updated.
Please go through the folowing queried to have general idea because the actual query is 2 page long.
DECODE(EXP,1,VAL1,VAL2)
Vs
CASE WHEN EXP=1
THEN VAL1
ELSE
VAL2
END
Update table1
set column=( select query)
where (item) IN (select item from table2 )
Please give inputs in term of performance.
Regards
Nitin Bajaj

Hu... I can understand your point also but it is not
diff to find the solution in the thread, you don't
need to read the whole thread.Even if you see that there are no entries in the duplicate postings, whenever you are using the search function, those will also be shown.
but put yourself in his position, he might be in need
of desparate help right...
Think in two ways...And posting the same problem again and again solves this?
cd

Similar Messages

CAS performance issue

On Exchange 2010, where we have CAS+HUB server role installed on single virtual server. The server is having 4 cores and 16 GB of RAM.
The recommended memory for CAS+HUB role is 2 GB per core. As per our config, we should have 8 GB per core. Is 16 GB helping our servers or is it being wasted?
Thanks,

Hi,
What’s the version of your Exchange Server, are they update to date now?
Does the UT of the memory always remain at around 90%?
Thanks,
Simon Wu
TechNet Community Support

RE: Case 59063: performance issues w/ C TLIB and Forte3M

Hi James,
Could you give me a call, I am at my desk.
I had meetings all day and couldn't respond to your calls earlier.
-----Original Message-----
From: James Min [mailto:jminbrio.forte.com]
Sent: Thursday, March 30, 2000 2:50 PM
To: Sharma, Sandeep; Pyatetskiy, Alexander
Cc: sophiaforte.com; kenlforte.com; Tenerelli, Mike
Subject: Re: Case 59063: performance issues w/ C TLIB and Forte 3M
Hello,
I just want to reiterate that we are very committed to working on
this issue, and that our goal is to find out the root of the problem. But
first I'd like to narrow down the avenues by process of elimination.
Open Cursor is something that is commonly used in today's RDBMS. I
know that you must test your query in ISQL using some kind of execute
immediate, but Sybase should be able to handle an open cursor. I was
wondering if your Sybase expert commented on the fact that the server is
not responding to commonly used command like 'open cursor'. According to
our developer, we are merely following the API from Sybase, and open cursor
is not something that particularly slows down a query for several minutes
(except maybe the very first time). The logs show that Forte is waiting for
a status from the DB server. Actually, using prepared statements and open
cursor ends up being more efficient in the long run.
Some questions:
1) Have you tried to do a prepared statement with open cursor in your ISQL
session? If so, did it have the same slowness?
2) How big is the table you are querying? How many rows are there? How many
are returned?
3) When there is a hang in Forte, is there disk-spinning or CPU usage in
the database server side? On the Forte side? Absolutely no activity at all?
We actually have a Sybase set-up here, and if you wish, we could test out
your database and Forte PEX here. Since your queries seems to be running
off of only one table, this might be the best option, as we could look at
everything here, in house. To do this:
a) BCP out the data into a flat file. (character format to make it portable)
b) we need a script to create the table and indexes.
c) the Forte PEX file of the app to test this out.
d) the SQL staement that you issue in ISQL for comparison.
If the situation warrants, we can give a concrete example of
possible errors/bugs to a developer. Dial-in is still an option, but to be
able to look at the TOOL code, database setup, etc. without the limitations
of dial-up may be faster and more efficient. Please let me know if you can
provide this, as well as the answers to the above questions, or if you have
any questions.
Regards,
At 08:05 AM 3/30/00 -0500, Sharma, Sandeep wrote:
James, Ken:
FYI, see attached response from our Sybase expert, Dani Sasmita. She has
already tried what you suggested and results are enclosed.
++
Sandeep
-----Original Message-----
From: SASMITA, DANIAR
Sent: Wednesday, March 29, 2000 6:43 PM
To: Pyatetskiy, Alexander
Cc: Sharma, Sandeep; Tenerelli, Mike
Subject: Re: FW: Case 59063: Select using LIKE has performance
issues
w/ CTLIB and Forte 3M
We did that trick already.
When it is hanging, I can see what is doing.
It is doing OPEN CURSOR. But not clear the exact statement of the cursor
it is trying to open.
When we run the query directly to Sybase, not using Forte, it is clearly
not opening any cursor.
And running it directly to Sybase many times, the response is always
consistently fast.
It is just when the query runs from Forte to Sybase, it opens a cursor.
But again, in the Forte code, Alex is not using any cursor.
In trying to capture the query,we even tried to audit any statementcoming
to Sybase. Same thing, just open cursor. No cursor declaration anywhere.==============================================
James Min
Technical Support Engineer - Forte Tools
Sun Microsystems, Inc.
1800 Harrison St., 17th Fl.
Oakland, CA 94612
james.minsun.com
510.869.2056
==============================================
Support Hotline: 510-451-5400
CUSTOMERS open a NEW CASE with Technical Support:
http://www.forte.com/support/case_entry.html
CUSTOMERS view your cases and enter follow-up transactions:
http://www.forte.com/support/view_calls.html

Earthlink wrote:
Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline procedure. Am I missing something? Well, we're missing a lot here.
Like:
- a database version
- how did you test
- what data do you have, how is it distributed, indexed
and so on.
If you want to find out what's going on then use a TRACE with wait events.
All nessecary steps are explained in these threads:
HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
Another nice one is RUNSTATS:
http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701

Interested by performance issue ? Read this ! If you can explain, you're a master Jedi !

This is the question we will try to answer...
What si the bottle neck (hardware) of Adobe Premiere Pro CS6
I used PPBM5 as a benchmark testing template.
All the data and log as been collected using performance counter
First of all, describe my computer...
Operating System
Microsoft Windows 8 Pro 64-bit
CPU
Intel Xeon E5 2687W @ 3.10GHz
Sandy Bridge-EP/EX 32nm Technology
RAM
Corsair Dominator Platinum 64.0 GB DDR3
Motherboard
EVGA Corporation Classified SR-X
Graphics
PNY Nvidia Quadro 6000
EVGA Nvidia GTX 680 // Yes, I created bench stats for both card
Hard Drives
16.0GB Romex RAMDISK (RAID)
556GB LSI MegaRAID 9260-8i SATA3 6GB/s 5 disks with Fastpath Chip Installed (RAID 0)
I have other RAID installed, but not relevant for the present post...
PSU
Cosair 1000 Watts
After many days of tests, I wanna share my results with community and comment them.
CPU Introduction
I tested my cpu and pushed it at maximum speed to understand where is the limit, can I reach this limit and I've logged precisely all result in graph (See pictures 1).
Intro : I tested my E5-XEON 2687W (8 Cores Hyperthread - 16 threads) to know if programs can use the maximum of it. I used Prime 95 to get the result. // I know this seem to be ordinary, but you will understand soon...
The result : Yes, I can get 100% of my CPU with 1 program using 20 threads in parallel. The CPU gives everything it can !
Comment : I put 3 IO (cpu, disk, ram) on the graph of my computer during the test...
(picture 1)
Disk Introduction
I tested my disk and pushed it at maximum speed to understand where is the limit and I've logged precisely all result in graph (See pictures 2).
Intro : I tested my RAID 0 556GB (LSI MegaRAID 9260-8i SATA3 6GB/s 5 disks with Fastpath Chip Installed) to know if I can reach the maximum % disk usage (0% idle Time)
The result : As you can see in picture 2, yes, I can get the max of my drive at ~ 1.2 Gb/sec read/write steady !
Comment : I put 3 IO (cpu, disk, ram) on the graph of my computer during the test to see the impact of transfering many Go of data during ~10 sec...
(picture 2)
Now, I know my limits ! It's time to enter deeper in the subject !
PPBM5 (H.264) Result
I rendered the sequence (H.264) using Adobe Media Encoder.
The result :
My CPU is not used at 100%, the turn around 50%
My Disk is totally idle !
All the process usage are idle except process of (Adobe Media Encoder)
The transfert rate seem to be a wave (up and down). Probably caused by (Encrypt time.... write.... Encrypt time.... write...) // It's ok, ~5Mb/sec during transfert rate !
CPU Power management give 100% of clock to CPU during the encoding process (it's ok, the clock is stable during process).
RAM, more than enough ! 39 Go RAM free after the test ! // Excellent
~65 thread opened by Adobe Media Encoder (Good, thread is the sign that program try to using many cores !)
GPU Load on card seem to be a wave also ! (up and down) ~40% usage of GPU during the process of encoding.
GPU Ram get 1.2Go of RAM (But with GTX 680, no problem and Quadro 6000 with 6 GB RAM, no problem !)
Comment/Question : CPU is free (50%), disks are free (99%), GPU is free (60%), RAM is free (62%), my computer is not pushed at limit during the encoding process. Why ???? Is there some time delay in the encoding process ?
Other : Quadro 6000 & GTX 680 gives the same result !
(picture 3)
PPBM5 (Disk Test) Result (RAID LSI)
I rendered the sequence (Disk Test) using Adobe Media Encoder on my RAID 0 LSI disk.
The result :
My CPU is not used at 100%
My Disk wave and wave again, but far far from the limit !
All the process usage are idle except process of (Adobe Media Encoder)
The transfert rate wave and wave again (up and down). Probably caused by (Buffering time.... write.... Buffering time.... write...) // It's ok, ~375Mb/sec peak during transfert rate ! Easy !
CPU Power management give 100% of clock to CPU during the encoding process (it's ok, the clock is stable during process).
RAM, more than enough ! 40.5 Go RAM free after the test ! // Excellent
~48 thread opened by Adobe Media Encoder (Good, thread is the sign that program try to using many cores !)
GPU Load on card = 0 (This kind of encoding is GPU irrelevant)
GPU Ram get 400Mb of RAM (No usage for encoding)
Comment/Question : CPU is free (65%), disks are free (60%), GPU is free (100%), RAM is free (63%), my computer is not pushed at limit during the encoding process. Why ???? Is there some time delay in the encoding process ?
(picture 4)
PPBM5 (Disk Test) Result (Direct in RAMDrive)
I rendered the same sequence (Disk Test) using Adobe Media Encoder directly in my RamDrive
Comment/Question : Look at the transfert rate under (picture 5). It's exactly the same speed than with my RAID 0 LSI controller. Impossible ! Look in the same picture the transfert rate I can reach with the ramdrive (> 3.0 Gb/sec steady) and I don't go under 30% of disk usage. CPU is idle (70%), Disk is idle (100%), GPU is idle (100%) and RAM is free (63%). // This kind of results let me REALLY confused. It's smell bug and big problem with hardware and IO usage in CS6 !
(picture 5)
PPBM5 (MPEG-DVD) Result
I rendered the sequence (MPEG-DVD) using Adobe Media Encoder.
The result :
My CPU is not used at 100%
My Disk is totally idle !
All the process usage are idle except process of (Adobe Media Encoder)
The transfert rate wave and wave again (up and down). Probably caused by (Encoding time.... write.... Encoding time.... write...) // It's ok, ~2Mb/sec during transfert rate ! Real Joke !
CPU Power management give 100% of clock to CPU during the encoding process (it's ok, the clock is stable during process).
RAM, more than enough ! 40 Go RAM free after the test ! // Excellent
~80 thread opened by Adobe Media Encoder (Lot of thread, but it's ok in multi-thread apps!)
GPU Load on card = 100 (This use the maximum of my GPU)
GPU Ram get 1Gb of RAM
Comment/Question : CPU is free (70%), disks are free (98%), GPU is loaded (MAX), RAM is free (63%), my computer is pushed at limit during the encoding process for GPU only. Now, for this kind of encoding, the speed limit is affected by the slower IO (Video Card GPU)
Other : Quadro 6000 is slower than GTX 680 for this kind of encoding (~20 s slower than GTX).
(picture 6)
Encoding single clip FULL HD AVCHD to H.264 Result (Premiere Pro CS6)
You can look the result in the picture.
Comment/Question : CPU is free (55%), disks are free (99%), GPU is free (90%), RAM is free (65%), my computer is not pushed at limit during the encoding process. Why ???? Adobe Premiere seem to have some bug with thread management. My hardware is idle ! I understand AVCHD can be very difficult to decode, but where is the waste ? My computer want, but the software not !
(picture 7)
Render composition using 3D Raytracer in After Effects CS6
You can look the result in the picture.
Comment : GPU seems to be the bottle neck when using After Effects. CPU is free (99%), Disks are free (98%), Memory is free (60%) and it depend of the setting and type of project.
Other : Quadro 6000 & GTX 680 gives the same result in time for rendering the composition.
(picture 8)
Conclusion
There is nothing you can do (I thing) with CS6 to get better performance actually. GTX 680 is the best (Consumer grade card) and the Quadro 6000 is the best (Profressional card). Both of card give really similar result (I will probably return my GTX 680 since I not really get any better performance). I not used Tesla card with my Quadro, but actually, both, Premiere Pro & After Effects doesn't use multi GPU. I tried to used both card together (GTX & Quadro), but After Effects gives priority to the slower card (In this case, the GTX 680)
Premiere Pro, I'm speechless ! Premiere Pro is not able to get max performance of my computer. Not just 10% or 20%, but average 60%. I'm a programmor, multi-threadling apps are difficult to manage and I can understand Adobe's programmor. But actually, if anybody have comment about this post, tricks or any kind of solution, you can comment this post. It's seem to be a bug...
Thank you.

Patrick,
I can't explain everything, but let me give you some background as I understand it.
The first issue is that CS6 has a far less efficient internal buffering or caching system than CS5/5.5. That is why the MPEG encoding in CS6 is roughly 2-3 times slower than the same test with CS5. There is some 'under-the-hood' processing going on that causes this significant performance loss.
The second issue is that AME does not handle regular memory and inter-process memory very well. I have described this here: Latest News
As to your test results, there are some other noteworthy things to mention. 3D Ray tracing in AE is not very good in using all CUDA cores. In fact it is lousy, it only uses very few cores and the threading is pretty bad and does not use the video card's capabilities effectively. Whether that is a driver issue with nVidia or an Adobe issue, I don't know, but whichever way you turn it, the end result is disappointing.
The overhead AME carries in our tests is something we are looking into and the next test will only use direct export and no longer the AME queue, to avoid some of the problems you saw. That entails other problems for us, since we lose the capability to check encoding logs, but a solution is in the works.
You see very low GPU usage during the H.264 test, since there are only very few accelerated parts in the timeline, in contrast to the MPEG2-DVD test, where there is rescaling going on and that is CUDA accelerated. The disk I/O test suffers from the problems mentioned above and is the reason that my own Disk I/O results are only 33 seconds with the current test, but when I extend the duration of that timeline to 3 hours, the direct export method gives me 22 seconds, although the amount of data to be written, 37,092 MB has increased threefold. An effective write speed of 1,686 MB/s.
There are a number of performance issues with CS6 that Adobe is aware of, but whether they can be solved and in what time, I haven't the faintest idea.
Just my $ 0.02

Performance issues with dynamic action (PL/SQL)

Hi!
I'm having perfomance issues with a dynamic action that is triggered on a button click.
I have 5 drop down lists to select columns which the users want to filter, 5 drop down lists to select an operation and 5 boxes to input values.
After that, there is a filter button that just submits the page based on the selected filters.
This part works fine, the data is filtered almost instantaneously.
After this, I have 3 column selectors and 3 boxes where users put values they wish to update the filtered rows to,
There is an update button that calls the dynamic action (procedure that is written below).
It should be straight out, the only performance issue could be the decode section, because I need to cover cases when user wants to set a value to null (@) and when he doesn't want update 3 columns, but less (he leaves '').
Hence P99_X_UC1 || ' = decode(' || P99_X_UV1 ||','''','|| P99_X_UC1 ||',''@'',null,'|| P99_X_UV1 ||')
However when I finally click the update button, my browser freezes and nothing happens on the table.
Can anyone help me solve this and improve the speed of the update?
Regards,
Ivan
P.S. The code for the procedure is below:
create or replace
PROCEDURE DWP.PROC_UPD
(P99_X_UC1 in VARCHAR2,
P99_X_UV1 in VARCHAR2,
P99_X_UC2 in VARCHAR2,
P99_X_UV2 in VARCHAR2,
P99_X_UC3 in VARCHAR2,
P99_X_UV3 in VARCHAR2,
P99_X_COL in VARCHAR2,
P99_X_O in VARCHAR2,
P99_X_V in VARCHAR2,
P99_X_COL2 in VARCHAR2,
P99_X_O2 in VARCHAR2,
P99_X_V2 in VARCHAR2,
P99_X_COL3 in VARCHAR2,
P99_X_O3 in VARCHAR2,
P99_X_V3 in VARCHAR2,
P99_X_COL4 in VARCHAR2,
P99_X_O4 in VARCHAR2,
P99_X_V4 in VARCHAR2,
P99_X_COL5 in VARCHAR2,
P99_X_O5 in VARCHAR2,
P99_X_V5 in VARCHAR2,
P99_X_CD in VARCHAR2,
P99_X_VD in VARCHAR2
) IS
l_sql_stmt varchar2(32600);
p_table_name varchar2(30) := 'DWP.IZV_SLOG_DET';
BEGIN
l_sql_stmt := 'update ' || p_table_name || ' set '
|| P99_X_UC1 || ' = decode(' || P99_X_UV1 ||','''','|| P99_X_UC1 ||',''@'',null,'|| P99_X_UV1 ||'),'
|| P99_X_UC2 || ' = decode(' || P99_X_UV2 ||','''','|| P99_X_UC2 ||',''@'',null,'|| P99_X_UV2 ||'),'
|| P99_X_UC3 || ' = decode(' || P99_X_UV3 ||','''','|| P99_X_UC3 ||',''@'',null,'|| P99_X_UV3 ||') where '||
P99_X_COL ||' '|| P99_X_O ||' ' || P99_X_V || ' and ' ||
P99_X_COL2 ||' '|| P99_X_O2 ||' ' || P99_X_V2 || ' and ' ||
P99_X_COL3 ||' '|| P99_X_O3 ||' ' || P99_X_V3 || ' and ' ||
P99_X_COL4 ||' '|| P99_X_O4 ||' ' || P99_X_V4 || ' and ' ||
P99_X_COL5 ||' '|| P99_X_O5 ||' ' || P99_X_V5 || ' and ' ||
P99_X_CD || ' = ' || P99_X_VD ;
--dbms_output.put_line(l_sql_stmt);
EXECUTE IMMEDIATE l_sql_stmt;
END;

Hi Ivan,
I do not think that the decode is performance relevant. Maybe the update hangs because some other transaction has uncommitted changes to one of the affected rows or the where clause is not selective enough and needs to update a huge amount of records.
Besides that - and I might be wrong, because I only know some part of your app - the code here looks like you have a huge sql injection vulnerability here. Maybe you should consider re-writing your logic in static sql. If that is not possible, you should make sure that the user input only contains allowed values, e.g. by white-listing P99_X_On (i.e. make sure they only contain known values like '=', '<', ...), and by using dbms_assert.enquote_name/enquote_literal on the other P99_X_nnn parameters.
Regards,
Christian

Performance issue in procedure

Hi All
i have a performance issue with below procedure it is taking 10-15 hrs .custom table has 2 lacks record .
PROCEDURE update_summary_dollar_amounts( p_errbuf OUT VARCHAR2
,p_retcode OUT NUMBER) IS
v_customer_id NUMBER := NULL;
pymt_count NUMBER := 0;
rec_count NUMBER := 0;
v_number_late NUMBER;
v_number_on_time NUMBER;
v_days_late NUMBER;
v_avg_elapsed NUMBER;
v_avg_elapsed_US NUMBER;
v_percent_prompt NUMBER;
v_percent_late NUMBER;
v_number_open NUMBER;
v_last_payment_amount NUMBER;
v_last_payment_date DATE;
v_prev_payment_amount NUMBER;
v_prev_payment_date DATE;
v_last_sale_amount NUMBER;
v_last_sale_date DATE;
v_mtd_sales NUMBER;
v_ytd_sales NUMBER;
v_prev_year_sales NUMBER;
v_prev_receipt_num VARCHAR2(30);
v_last_sale VARCHAR2(50);
c_current_year VARCHAR2(4);
c_previous_year VARCHAR2(4);
c_current_month VARCHAR2(8);
/* ====================================================================== */
/* CURSOR Customer Cursor (Main Customer) LOOP */
/* ====================================================================== */
CURSOR customer_cursor IS
SELECT cst.customer_id customer_id
,cst.customer_number customer_number
,cst.org_id org_id
FROM zz_ar_customer_summary_all cst
ORDER by cst.customer_id;
/* ====================================================================== */
/* CURSOR Payments Cursor LOOP */
/* Note: This logic is taken from the Customer Credit Snapshot */
/* Report - ARXCCS */
/* ====================================================================== */
CURSOR payments_cursor IS
SELECT cr.receipt_number receipt_num
,NVL(cr.amount,0) amount
,crh.gl_date gl_date
FROM ar_lookups
,ar_cash_receipts_all cr
,ar_cash_receipt_history_all crh
,ar_receivable_applications_all ra
,ra_customer_trx_all ct
WHERE NVL(cr.type,'CASH') = ar_lookups.lookup_code
AND ar_lookups.lookup_type = 'PAYMENT_CATEGORY_TYPE'
AND cr.pay_from_customer = v_customer_id
AND cr.cash_receipt_id = ra.cash_receipt_id
AND cr.cash_receipt_id = crh.cash_receipt_id
AND crh.first_posted_record_flag = 'Y'
AND ra.applied_customer_trx_id = ct.customer_trx_id(+)
ORDER BY cr.creation_date DESC
,cr.cash_receipt_id DESC
,ra.creation_date DESC;
customer_record customer_cursor%rowtype;
payments_record payments_cursor%rowtype;
BEGIN
p_errbuf := NULL;
p_retcode := 0;
c_current_year := TO_CHAR(SYSDATE,'YYYY');
c_current_month := TO_CHAR(SYSDATE,'YYYYMM');
c_previous_year := TO_CHAR(TO_NUMBER(c_current_year) - 1);
FOR customer_record IN customer_cursor LOOP
/* Get Days Late and Average Elapsed Days */
/* Note: This logic is taken from the Customer Credit Snapshot */
/* Report - ARXCCS */
BEGIN
v_customer_id := customer_record.customer_id;
BEGIN
SELECT DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.trx_date) / COUNT(cr.deposit_date))) avgdays
,DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.due_date) / COUNT(cr.deposit_date))) avgdayslate
,NVL(SUM(DECODE(SIGN(cr.deposit_date - ps.due_date),1, 1, 0)), 0) newlate
,NVL(SUM( DECODE(SIGN(cr.deposit_date - ps.due_date),1, 0, 1)), 0) newontime
INTO v_avg_elapsed
,v_days_late
,v_number_late
,v_number_on_time
FROM ar_receivable_applications_all ra
,ar_cash_receipts_all cr
,ar_payment_schedules_all ps
WHERE ra.cash_receipt_id = cr.cash_receipt_id
AND ra.applied_payment_schedule_id = ps.payment_schedule_id
AND ps.customer_id = v_customer_id
AND ra.apply_date BETWEEN ADD_MONTHS(SYSDATE, -12) AND SYSDATE
AND ra.status = 'APP'
AND ra.display = 'Y'
AND NVL(ps.receipt_confirmed_flag,'Y') = 'Y';
EXCEPTION
WHEN NO_DATA_FOUND THEN
v_days_late := NULL;
v_number_late := NULL;
v_avg_elapsed := NULL;
v_number_on_time := NULL;
END;
IF (v_number_on_time + v_number_late) > 0
THEN
v_percent_prompt := ROUND(v_number_on_time/(v_number_on_time + v_number_late),2) * 100;
v_percent_late := ROUND(v_number_late/(v_number_on_time + v_number_late),2) * 100;
ELSE
v_percent_prompt := 0;
v_percent_late := 0;
END IF;
/* C2# 49827 */
/* Get new average elapsed days for US use only */
v_avg_elapsed_us := NULL;
IF NVL(customer_record.org_id,-999) = 114
THEN
v_avg_elapsed_us := 0;
BEGIN
SELECT ROUND(SUM(NVL(ra.amount_applied,0) * (cr.deposit_date - ps.trx_date)) / DECODE(SUM(NVL(ra.amount_applied,0)),0,1,SUM(NVL(ra.amount_applied,0)))) avg_elapsed_us
INTO v_avg_elapsed_us
FROM ar_receivable_applications_all ra
,ar_cash_receipts_all cr
,ar_payment_schedules_all ps
WHERE ra.cash_receipt_id = cr.cash_receipt_id
AND ra.applied_payment_schedule_id = ps.payment_schedule_id
AND ps.customer_id = v_customer_id
AND ra.apply_date BETWEEN ADD_MONTHS(SYSDATE, -06) AND SYSDATE
AND ps.status = 'CL'
AND ra.status = 'APP'
AND ra.display = 'Y'
AND nvl(ps.receipt_confirmed_flag,'Y') = 'Y'
AND ra.amount_applied <> 0;
v_avg_elapsed_us := NVL(v_avg_elapsed_us,0);
EXCEPTION
WHEN NO_DATA_FOUND THEN
v_avg_elapsed_us := NULL;
END;
END IF;
END;
/* Get MTD, YTD, Prev Year Sales */
/* Note: This logic is taken from the Customer Credit Snapshot */
/* Report - ARXCCS */
BEGIN
SELECT NVL(SUM(DECODE(TO_CHAR(ps.trx_date,'YYYYMM'),c_current_month,amount_due_original,0)),0) mtd_sales
,NVL(SUM(DECODE(TO_CHAR(ps.trx_date,'YYYY'),c_current_year,amount_due_original,0)),0) ytd_sales
,NVL(SUM(DECODE(TO_CHAR(ps.trx_date,'YYYY'),c_previous_year,amount_due_original,0)),0) prev_sales
,SUM(DECODE(ps.status,'OP',(DECODE(SIGN(amount_due_original),1,1,0)),0)) number_open
INTO v_mtd_sales
,v_ytd_sales
,v_prev_year_sales
,v_number_open
FROM ar_payment_schedules_all ps
WHERE ps.customer_id = v_customer_id
AND ps.class != 'PMT';
EXCEPTION
WHEN NO_DATA_FOUND THEN
v_mtd_sales := NULL;
v_ytd_sales := NULL;
v_prev_year_sales := NULL;
END;
/* Get Last and Previous Payments */
pymt_count := 0;
v_last_payment_date := NULL;
v_prev_payment_date := NULL;
v_last_payment_amount := NULL;
v_prev_payment_amount := NULL;
v_prev_receipt_num := NULL;
FOR payments_record IN payments_cursor LOOP
BEGIN
IF payments_record.receipt_num = v_prev_receipt_num
THEN
NULL;
ELSIF pymt_count = 0
THEN
v_last_payment_date := payments_record.gl_date;
v_last_payment_amount := payments_record.amount;
pymt_count := pymt_count +1;
v_prev_receipt_num := payments_record.receipt_num;
ELSIF pymt_count = 1
THEN
v_prev_payment_date := payments_record.gl_date;
v_prev_payment_amount := payments_record.amount;
EXIT;
ELSE
EXIT;
END IF;
END;
END LOOP;
/* Get Last Sale Date and Amount */
/* Note: This logic is taken from the Customer Credit Snapshot */
/* Report - ARXCCS */
BEGIN
SELECT MAX(TO_CHAR(ct.trx_date,'YYYYDDD')||ps.amount_due_original)
INTO v_last_sale
FROM ra_cust_trx_types_all ctt
,ar_payment_schedules_all ps
,ra_customer_trx_all ct
WHERE ps.customer_trx_id = ct.customer_trx_id
AND ct.cust_trx_type_id = ctt.cust_trx_type_id
AND ct.bill_to_customer_id = v_customer_id
AND ps.class || '' = 'INV'
ORDER BY ct.trx_date DESC
,ct.customer_trx_id DESC;
EXCEPTION
WHEN NO_DATA_FOUND
THEN
v_last_sale := NULL;
END;
IF v_last_sale IS NOT NULL
THEN
v_last_sale_date := TO_DATE(SUBSTR(v_last_sale,1,7),'YYYYDDD');
v_last_sale_amount := SUBSTR(v_last_sale,8,15);
ELSE
v_last_sale_date := NULL;
v_last_sale_amount := NULL;
END IF;
/* Update Values into ZZ_AR_CUSTOMER_SUMMARY_ALL */
BEGIN
UPDATE zz_ar_customer_summary_all
SET sales_last_year = v_prev_year_sales
,sales_ytd = v_ytd_sales
,sales_mtd = v_mtd_sales
,last_sale_date = v_last_sale_date
,last_sale_amount = v_last_sale_amount
,last_payment_date = v_last_payment_date
,last_payment_amount = v_last_payment_amount
,previous_payment_date = v_prev_payment_date
,previous_payment_amount = v_prev_payment_amount
,prompt = v_percent_prompt
,late = v_percent_late
,avg_elapsed_days = v_avg_elapsed
,avg_elapsed_days_us = v_avg_elapsed_us -- C2# 49827
,days_late = v_days_late
,number_open = v_number_open
WHERE customer_id = customer_record.customer_id;
EXCEPTION
WHEN PROGRAM_ERROR THEN NULL;
WHEN DUP_VAL_ON_INDEX THEN NULL;
WHEN STORAGE_ERROR THEN NULL;
WHEN OTHERS THEN NULL;
END;
rec_count := rec_count + 1;
IF rec_count = 10000
THEN
COMMIT;
rec_count := 0;
fnd_file.put_line(fnd_file.output,'Commit at customer_id = ' || TO_CHAR(customer_record.customer_id) || ' ' || TO_CHAR(SYSDATE, 'DD-MON-YYYY HH24:MI:SS'));
fnd_file.new_line(fnd_file.output,1);
END IF;
END LOOP;
COMMIT;
EXCEPTION
WHEN others THEN
ROLLBACK;
p_retcode := 2;
p_errbuf := SQLERRM;
END update_summary_dollar_amounts;
Thanks,
Anu

Based on my initial assessment of the code, it looks like you are utilizing the "slow by slow" method. It is often termed "slow by slow" because it is one of the most INefficient ways of doing data processing. The "slow by slow" method uses CURSOR FOR LOOPs to loop through entire record sets and process them one at a time. In your case it looks like you are using NESTED FOR LOOPs which could exacerbate the problem.
I recommend you re-think your approach and try and do everything in a single, or a few SQL statements if possible and avoid the procedural logic.
If you can post your business requirements, and sample data we may be able to help you achieve your goal.
HTH!

Performance issue with a Custom view

Hi ,
I am pretty new to performance tuning and facing a performance issue with a custom view.
Execution time for view query is good but as soon as I append a where caluse to view query ,the execution time increases.
Below is the view query:
CREATE OR REPLACE XXX_INFO_VIEW AS
SELECT csb.system_id license_id,
cst.name license_number ,
csb.system_type_code license_type ,
csb.attribute3 lac , -- license authorization code
csb.attribute6 lat , -- license admin token
csb.attribute12 ols_reg, -- OLS Registration allowed flag
l.attribute4 license_biz_type ,
NVL (( SELECT 'Y' l_supp_flag
FROM csi_item_instances cii,
okc_k_lines_b a,
okc_k_items c
WHERE c.cle_id = a.id
AND a.lse_id = 9
AND c.jtot_object1_code = 'OKX_CUSTPROD'
AND c.object1_id1 = cii.instance_id||''
AND cii.instance_status_id IN (3, 510)
AND cii.system_id = csb.system_id
AND a.sts_code IN ('SIGNED', 'ACTIVE')
AND NVL (a.date_terminated, a.end_date) > SYSDATE
AND ROWNUM < 2), 'N') active_supp_flag,
hp.party_name "Customer_Name" , -- Customer Name
hca.attribute12 FGE_FLAG,
(SELECT /*+INDEX (oklt OKC_K_LINES_TL_U1) */
nvl(max((decode(name, 'eSupport','2','Enterprise','1','Standard','1','TERM RTU','0','TERM RTS','0','Notfound'))),0) covName --TERM RTU and TERM RTS added as per Vijaya's suggestion APR302013
FROM OKC_K_LINES_B oklb1,
OKC_K_LINES_TL oklt,
OKC_K_LINES_B oklb2,
OKC_K_ITEMS oki,
CSI_item_instances cii
WHERE
OKI.JTOT_OBJECT1_CODE = 'OKX_CUSTPROD'
AND oklb1.id=oklt.id
AND OKI.OBJECT1_ID1 =cii.instance_id||''
AND Oklb1.lse_id=2
AND oklb1.dnz_chr_id=oklb2.dnz_chr_id
AND oklb2.lse_id=9
AND oki.CLE_ID=oklb2.id
AND cii.system_id=csb.system_id
AND oklt.LANGUAGE=USERENV ('LANG')) COVERAGE_TYPE
FROM csi_systems_b csb ,
csi_systems_tl cst ,
hz_cust_accounts hca,
hz_parties hp,
fnd_lookup_values l
WHERE csb.system_type_code = l.lookup_code (+)
AND csb.system_id = cst.system_id
AND hca.cust_account_id =csb.customer_id
AND hca.party_id= hp.party_id
AND cst.language = USERENV ('LANG')
AND l.lookup_type (+) = 'CSI_SYSTEM_TYPE'
AND l.language (+) = USERENV ('LANG')
AND NVL (csb.end_date_active, SYSDATE+1) > SYSDATE)
I have forced an index to avoid Full table scan on OKC_K_LINES_TL and suppressed an index on CSI_item_instances.instance id to make the view query fast.
So when i do select * from XXX_INFO_VIEWit executes in a decent time,But when I try to do
select * from XXX_INFO_VIEW where active_supp_flag='Y' and coverage_type='1'
it takes lot of time.
Execution plan is same for both queries in terms of cost but with WHERE clause Number of bytes increases.
Below are the execution plans:
View query:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
 10 COUNT STOPKEY
 9 NESTED LOOPS
 7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
 5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
 2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
 1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
 4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
 3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
 6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
 8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
 12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
 11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
 28 SORT AGGREGATE Bytes: 169 Cardinality: 1
 27 NESTED LOOPS
 25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
 23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
 20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
 17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
 14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
 13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
 16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
 15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
 19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
 18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
 22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
 21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
 24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
 26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
 43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
 41 NESTED LOOPS
 39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
 37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
 32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
 30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
 29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
 31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
 36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
 35 HASH JOIN
 33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
 34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
 38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
 40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
 42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918
Execution plan for view query with WHERE clause:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
 10 COUNT STOPKEY
 9 NESTED LOOPS
 7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
 5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
 2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
 1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
 4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
 3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
 6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
 8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
 12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
 11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
 28 SORT AGGREGATE Bytes: 169 Cardinality: 1
 27 NESTED LOOPS
 25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
 23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
 20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
 17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
 14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
 13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
 16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
 15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
 19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
 18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
 22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
 21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
 24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
 26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
 44 VIEW VIEW APPS.WRS_LICENSE_INFO_V Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
 43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
 41 NESTED LOOPS
 39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
 37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
 32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
 30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
 29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
 31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
 36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
 35 HASH JOIN
 33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
 34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
 38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
 40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
 42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918

Hi,
You should always try using primary index fields, if not possible then secondary index fields.
Even if you cannot do anything from either of the two then try this,
Use Less distinct fields on the top.
In your case , you can use bukrs ,gjahr ,werks on the top in the where condition..then followed by less distinct values..
Even when you use secondary index if you have 4 fields in your sec index and you are using only two fields from the top then the index is useful only upto that two fields provided they are in sequence.

Pivot - Performance Issue with large dataset

Hello,
Database version : Oracle 10.2.0.4 - Linux
I'm using a function to return a pivot query depending on an input "RUN_ID" value
For example, i consider two differents "RUN_ID" (e.g. 119 and 120) with exactly the same dataset
I have a performance issue when i run the result query with the "RUN_ID"=120.
Pivot:
SELECT   MAX (a.plate_index), MAX (a.plate_name), MAX (a.int_well_id),
         MAX (a.row_index_alpha), MAX (a.column_index), MAX (a.is_valid),
         MAX (a.well_type_id), MAX (a.read_index), MAX (a.run_id),
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC190', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC304050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC306050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC30050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC3011050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC104050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC106050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC10050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC1011050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC204050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC206050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC20050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC2011050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC80050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'CALC70050301', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'RAW0', a.this_value,
                      NULL
         MAX (DECODE (a.value_type || a.value_index,
                      'RAW5030', a.this_value,
                      NULL
         MAX (a.dose), MAX (a.unit), MAX (a.int_plate_id), MAX (a.run_name)
    FROM vw_well_data a
   WHERE a.run_id = :app_run_id
GROUP BY a.int_well_id, a.read_index
Run the query :
SELECT Sql_FullText,(cpu_time/100000) "Cpu Time (s)",
                (elapsed_time/1000000) "Elapsed time (s)",
                fetches,buffer_gets,disk_reads,executions
FROM v$sqlarea
WHERE Parsing_Schema_Name ='SCHEMA';
With results :
SQL_FULLTEXT     Cpu Time (s)     Elapsed time (s)     FETCHES     BUFFER_GETS     DISK_READS     EXECUTIONS
query1 (RUN_ID=119)      22.15857     3.589822     1     2216     354     1
query2 (RUN_ID=120)      1885.16959     321.974332     3     7685410     368     3
Explain Plan for RUNID 119_
PLAN_TABLE_OUTPUT
Plan hash value: 3979963427
| Id | Operation                          | Name                 | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                   |                      |   261 | 98397 |   434   (2)| 00:00:06 |
|   1 | HASH GROUP BY                     |                      |   261 | 98397 |   434   (2)| 00:00:06 |
|   2 |   VIEW                             | VW_WELL_DATA         |   261 | 98397 |   433   (2)| 00:00:06 |
|   3 |    UNION-ALL                       |                      |       |       |            |          |
|* 4 |     HASH JOIN                      |                      |   252 | 21168 |   312   (2)| 00:00:04 |
|   5 |      NESTED LOOPS                  |                      |   249 | 15687 |   112   (2)| 00:00:02 |
|* 6 |       HASH JOIN                    |                      |   249 | 14442 |   112   (2)| 00:00:02 |
|   7 |        TABLE ACCESS BY INDEX ROWID | PLATE                |    29 |   464 |     2   (0)| 00:00:01 |
|* 8 |         INDEX RANGE SCAN           | IDX_PLATE_RUN_ID     |    29 |       |     1   (0)| 00:00:01 |
|   9 |        NESTED LOOPS                |                      | 13286 |   544K|   109   (1)| 00:00:02 |
| 10 |         TABLE ACCESS BY INDEX ROWID| RUN                  |     1 |    11 |     1   (0)| 00:00:01 |
|* 11 |          INDEX UNIQUE SCAN         | PK_RUN               |     1 |       |     0   (0)| 00:00:01 |
| 12 |         TABLE ACCESS BY INDEX ROWID| WELL                 | 13286 |   402K|   108   (1)| 00:00:02 |
|* 13 |          INDEX RANGE SCAN          | IDX_WELL_RUN_ID      | 13286 |       |    46   (0)| 00:00:01 |
|* 14 |       INDEX UNIQUE SCAN            | PK_WELL_TYPE         |     1 |     5 |     0   (0)| 00:00:01 |
| 15 |      TABLE ACCESS BY INDEX ROWID   | WELL_RAW_DATA        | 26361 |   540K|   199   (2)| 00:00:03 |
|* 16 |       INDEX RANGE SCAN             | IDX_WELL_RAW_RUN_ID | 26361 |       |    92   (2)| 00:00:02 |
| 17 |     NESTED LOOPS                   |                      |     9 |   891 |   121   (2)| 00:00:02 |
|* 18 |      HASH JOIN                     |                      |     9 |   846 |   121   (2)| 00:00:02 |
|* 19 |       HASH JOIN                    |                      |   249 | 14442 |   112   (2)| 00:00:02 |
| 20 |        TABLE ACCESS BY INDEX ROWID | PLATE                |    29 |   464 |     2   (0)| 00:00:01 |
|* 21 |         INDEX RANGE SCAN           | IDX_PLATE_RUN_ID     |    29 |       |     1   (0)| 00:00:01 |
| 22 |        NESTED LOOPS                |                      | 13286 |   544K|   109   (1)| 00:00:02 |
| 23 |         TABLE ACCESS BY INDEX ROWID| RUN                  |     1 |    11 |     1   (0)| 00:00:01 |
|* 24 |          INDEX UNIQUE SCAN         | PK_RUN               |     1 |       |     0   (0)| 00:00:01 |
| 25 |         TABLE ACCESS BY INDEX ROWID| WELL                 | 13286 |   402K|   108   (1)| 00:00:02 |
|* 26 |          INDEX RANGE SCAN          | IDX_WELL_RUN_ID      | 13286 |       |    46   (0)| 00:00:01 |
| 27 |       TABLE ACCESS BY INDEX ROWID | WELL_CALC_DATA       |   490 | 17640 |     9   (0)| 00:00:01 |
|* 28 |        INDEX RANGE SCAN            | IDX_WELL_CALC_RUN_ID |   490 |       |     4   (0)| 00:00:01 |
|* 29 |      INDEX UNIQUE SCAN             | PK_WELL_TYPE         |     1 |     5 |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("WELL_RAW_DATA"."RUN_ID"="WELL"."RUN_ID" AND
              "WELL"."INT_WELL_ID"="WELL_RAW_DATA"."INT_WELL_ID")
   6 - access("PLATE"."RUN_ID"="WELL"."RUN_ID" AND "PLATE"."INT_PLATE_ID"="WELL"."INT_PLATE_ID")
   8 - access("PLATE"."RUN_ID"=119)
11 - access("RUN"."RUN_ID"=119)
13 - access("WELL"."RUN_ID"=119)
14 - access("WELL"."WELL_TYPE_ID"="TSF_LAYOUT_WELL_TYPE"."WELL_TYPE_ID")
16 - access("WELL_RAW_DATA"."RUN_ID"=119)
18 - access("WELL"."RUN_ID"="WELL_CALC_DATA"."RUN_ID" AND
              "WELL"."INT_WELL_ID"="WELL_CALC_DATA"."INT_WELL_ID")
19 - access("PLATE"."RUN_ID"="WELL"."RUN_ID" AND "PLATE"."INT_PLATE_ID"="WELL"."INT_PLATE_ID")
21 - access("PLATE"."RUN_ID"=119)
24 - access("RUN"."RUN_ID"=119)
26 - access("WELL"."RUN_ID"=119)
28 - access("WELL_CALC_DATA"."RUN_ID"=119)
29 - access("WELL"."WELL_TYPE_ID"="TSF_LAYOUT_WELL_TYPE"."WELL_TYPE_ID")
Explain Plan for RUNID 120_
PLAN_TABLE_OUTPUT
Plan hash value: 599334230
| Id | Operation                           | Name                      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                           |     2 |   754 |    24   (5)| 00:00:01 |
|   1 | HASH GROUP BY                      |                           |     2 |   754 |    24   (5)| 00:00:01 |
|   2 |   VIEW                              | VW_WELL_DATA              |     2 |   754 |    23   (0)| 00:00:01 |
|   3 |    UNION-ALL                        |                           |       |       |            |          |
|* 4 |     TABLE ACCESS BY INDEX ROWID     | WELL_RAW_DATA             |     1 |    21 |     3   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                   |                           |     1 |    84 |     9   (0)| 00:00:01 |
|   6 |       NESTED LOOPS                  |                           |     1 |    63 |     6   (0)| 00:00:01 |
|   7 |        NESTED LOOPS                 |                           |     1 |    58 |     6   (0)| 00:00:01 |
|   8 |         NESTED LOOPS                |                           |     1 |    27 |     3   (0)| 00:00:01 |
|   9 |          TABLE ACCESS BY INDEX ROWID| RUN                       |     1 |    11 |     1   (0)| 00:00:01 |
|* 10 |           INDEX UNIQUE SCAN         | PK_RUN                    |     1 |       |     0   (0)| 00:00:01 |
| 11 |          TABLE ACCESS BY INDEX ROWID| PLATE                     |     1 |    16 |     2   (0)| 00:00:01 |
|* 12 |           INDEX RANGE SCAN          | IDX_PLATE_RUN_ID          |     1 |       |     1   (0)| 00:00:01 |
|* 13 |         TABLE ACCESS BY INDEX ROWID | WELL                      |     1 |    31 |     3   (0)| 00:00:01 |
|* 14 |          INDEX RANGE SCAN           | IDX_WELL_RUN_ID           |    59 |       |     2   (0)| 00:00:01 |
|* 15 |        INDEX UNIQUE SCAN            | PK_WELL_TYPE              |     1 |     5 |     0   (0)| 00:00:01 |
|* 16 |       INDEX RANGE SCAN              | IDX_WELL_RAW_DATA_WELL_ID |     2 |       |     2   (0)| 00:00:01 |
|* 17 |     TABLE ACCESS BY INDEX ROWID     | WELL_CALC_DATA            |     1 |    36 |     8   (0)| 00:00:01 |
| 18 |      NESTED LOOPS                   |                           |     1 |    99 |    14   (0)| 00:00:01 |
| 19 |       NESTED LOOPS                  |                           |     1 |    63 |     6   (0)| 00:00:01 |
| 20 |        NESTED LOOPS                 |                           |     1 |    58 |     6   (0)| 00:00:01 |
| 21 |         NESTED LOOPS                |                           |     1 |    27 |     3   (0)| 00:00:01 |
| 22 |          TABLE ACCESS BY INDEX ROWID| RUN                       |     1 |    11 |     1   (0)| 00:00:01 |
|* 23 |           INDEX UNIQUE SCAN         | PK_RUN                    |     1 |       |     0   (0)| 00:00:01 |
| 24 |          TABLE ACCESS BY INDEX ROWID| PLATE                     |     1 |    16 |     2   (0)| 00:00:01 |
|* 25 |           INDEX RANGE SCAN          | IDX_PLATE_RUN_ID          |     1 |       |     1   (0)| 00:00:01 |
|* 26 |         TABLE ACCESS BY INDEX ROWID | WELL                      |     1 |    31 |     3   (0)| 00:00:01 |
|* 27 |          INDEX RANGE SCAN           | IDX_WELL_RUN_ID           |    59 |       |     2   (0)| 00:00:01 |
|* 28 |        INDEX UNIQUE SCAN            | PK_WELL_TYPE              |     1 |     5 |     0   (0)| 00:00:01 |
|* 29 |       INDEX RANGE SCAN              | IDX_WELL_CALC_RUN_ID      |   486 |       |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("WELL_RAW_DATA"."RUN_ID"=120)
10 - access("RUN"."RUN_ID"=120)
12 - access("PLATE"."RUN_ID"=120)
13 - filter("PLATE"."INT_PLATE_ID"="WELL"."INT_PLATE_ID")
14 - access("WELL"."RUN_ID"=120)
15 - access("WELL"."WELL_TYPE_ID"="TSF_LAYOUT_WELL_TYPE"."WELL_TYPE_ID")
16 - access("WELL"."INT_WELL_ID"="WELL_RAW_DATA"."INT_WELL_ID")
17 - filter("WELL"."INT_WELL_ID"="WELL_CALC_DATA"."INT_WELL_ID")
23 - access("RUN"."RUN_ID"=120)
25 - access("PLATE"."RUN_ID"=120)
26 - filter("PLATE"."INT_PLATE_ID"="WELL"."INT_PLATE_ID")
27 - access("WELL"."RUN_ID"=120)
28 - access("WELL"."WELL_TYPE_ID"="TSF_LAYOUT_WELL_TYPE"."WELL_TYPE_ID")
29 - access("WELL_CALC_DATA"."RUN_ID"=120)I need some advice to understand the issue and to improve the performance.
Thanks,
Grégory

Hello,
Thanks for your response.
Stats are computed recently with DBMS_STATS package (case 2) and we have histogramm on 'RUN_ID' columns.
I tried to use the deprecated "analyze" method (case 1) and obtained better results!
DECLARE
   -- Get tables used in the view vw_well_data --
   CURSOR c1
   IS
      SELECT table_name, last_analyzed
        FROM user_tables
       WHERE table_name LIKE 'WELL%';
BEGIN
   FOR r1 IN c1
   LOOP
      -- Case 1 : Analyze method : Perf is good --
      EXECUTE IMMEDIATE    'analyze table '
                          || r1.table_name
                          || ' compute statistics ';
      -- Case 2 : DBMS_STATS --
      DBMS_STATS.gather_table_stats ('SCHEMA', r1.table_name);
   END LOOP;
END;The explain plans are the same as before
Any explanations, suggestions ?
Thanks,
Gregory

Report performance Issue in BI Answers

Hi All,
We have a performance issues with reports. Report is running more than 10 mins. we took query from the session log and ran it in database, at that time it took not more than 2 mins. We have verified proper indexes on the where clause columns.
Could any once suggest to improve the performance in BI answers?
Thanks in advance,

I hope you dont have many case statements and complex calculations that you do in the Answers.
Next thing you need to monitor is how many rows of data that you are trying to retrieve from the query. If the volume is huge then it takes time to do the formatting on the Answers as you are going to dump huge volumes of data. Database(like teradata) returns initially like 1-2000 records if you hit show all records then even db is gonna fair amount of time if you are dumping many records
hope it helps
thanks
Prash

Performance Issues with 10.6.7 and External USB Drives

I've had a few performance issues come up with the latest 10.6.7 that seem to be related to external USB drives. I have a 2TB USB drive tha I have my iMovie content on this drive and after 10.6.7 update, iMovie is almost unusable. Finder even seems slow when browsing files on this drive as well. It seems like any access to the drive is delayed in all applications. Before the update, the performance was acceptable, but now it almost unusable. Most of the files on this drive are large dv files.
Anyone else experience this?

Matt,
If you want help, please start your own thread here:
http://discussions.apple.com/forum.jspa?forumID=1339&start=0
And if your previous thread you aren't getting sufficient help for your iPhone, post a new topic here:
http://discussions.apple.com/forum.jspa?forumID=1139
You'll get a wider audience, and won't confuse the original poster. Performance issues can be caused by numerous issues as outlined in my FAQ*
http://www.macmaps.com/Macosxspeed.html
If every person who had a performance issue posted to this thread, we'd never find a solution for the initial poster. Let's isolate each case one by one. It is NOT necessarily the same issue, even if the symptoms are the same. There are numerous contributing factors at work with computers, and if we don't isolate them, we'll never get to the root cause.

Performance Issues with Acrobat Reader 11.0.0.2 when secure mode is enabled

Hello All,
We are experiencing sporadic issues with Acrobat 11.0.0.2 across our domain, users are reporting performance issues when opening PDF documents whether locally or from a network share.
We have found that turning off Secure Mode helps towards reducing this delay and in the cases it doesn't we are repairing the installation and/or reinstalling the application.
Due to the security implications we need to leave this turned on, I am wondering if anyone has encountered this issue and what steps were taken towards resolving it?
I also wonder whether the white list function in the new release 11.0.0.3 would be a solution to this issue?
Kind Regards,
Ryan McCarty

No probelm, so....
We had no problems with Adobe Reader 9 and 10, we encountered the issues when upgrading to 11.0.0.2.
Initially we found that turning off the Protected Mode, helped but did not resolve the issue.
We tried;
1. Turn off protected mode - issue still present
2. Clearing the recent file registry using the below registry path and deleting the keys underneath it.
HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\11.0\AVGeneral\cRecentFiles (this does not turn recent files off permanently). - works but needs clearing regularly
3. Turning off welcome screen by creating - HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\11.0\FeatureLockDown\cWelcomeScreen - works to improve app open speed.
4. uninstall/reinstall of 11.0.0.2 - works most likley due to the recent files being cleared.
5. upgrade to 11.0.0.3 - issue still present
Following reboots the issue is still present.
When Adobe Reader is the only application open this issue is still present.
As mentioned I have no systems available which I could test this issue using 11.0.0.1 as we have fixed them, albeit temporarily using the reinstall method.
I am concious that this issue is going to reoccur once that cache (recent files) builds back up because the fix above (#2) is clearing the recent files cache NOT disabling it.

Performance issues with pipelined table functions

I am testing pipelined table functions to be able to re-use the base_query function. Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline procedure. Am I missing something? The processor function is from [url http://www.oracle-developer.net/display.php?id=429]improving performance with pipelined table functions .
Edit: The underlying query returns 500,000 rows in about 3 minutes. So there are are no performance issues with the query itself.
Many thanks in advance.
CREATE OR REPLACE PACKAGE pipeline_example
IS
 TYPE resultset_typ IS REF CURSOR;
 TYPE row_typ IS RECORD (colC VARCHAR2(200), colD VARCHAR2(200), colE VARCHAR2(200));
 TYPE table_typ IS TABLE OF row_typ;
 FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
 RETURN resultset_typ;
 c_default_limit CONSTANT PLS_INTEGER := 100;
 FUNCTION processor (
 p_source_data IN resultset_typ,
 p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
 RETURN table_typ
 PIPELINED
 PARALLEL_ENABLE(PARTITION p_source_data BY ANY);
 PROCEDURE with_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ);
 PROCEDURE no_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ);
END pipeline_example;
CREATE OR REPLACE PACKAGE BODY pipeline_example
IS
 FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
 RETURN resultset_typ
 IS
 o_resultset resultset_typ;
 BEGIN
 OPEN o_resultset FOR
 SELECT colC, colD, colE
 FROM some_table
 WHERE colA = ArgA AND colB = argB;
 RETURN o_resultset;
 END base_query;
 FUNCTION processor (
 p_source_data IN resultset_typ,
 p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
 RETURN table_typ
 PIPELINED
 PARALLEL_ENABLE(PARTITION p_source_data BY ANY)
 IS
 aa_source_data table_typ;-- := table_typ ();
 BEGIN
 LOOP
 FETCH p_source_data
 BULK COLLECT INTO aa_source_data
 LIMIT p_limit_size;
 EXIT WHEN aa_source_data.COUNT = 0;
 /* Process the batch of (p_limit_size) records... */
 FOR i IN 1 .. aa_source_data.COUNT
 LOOP
 PIPE ROW (aa_source_data (i));
 END LOOP;
 END LOOP;
 CLOSE p_source_data;
 RETURN;
 END processor;
 PROCEDURE with_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ)
 IS
 BEGIN
 OPEN o_resultset FOR
 SELECT /*+ PARALLEL(t, 5) */ colC,
 SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
 SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
 SUM (CASE WHEN colD = colE AND colD != '0' THEN '1' END) de_one,
 SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
 FROM TABLE (processor (base_query (argA, argB),100)) t
 GROUP BY colC
 ORDER BY colC
 END with_pipeline;
 PROCEDURE no_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ)
 IS
 BEGIN
 OPEN o_resultset FOR
 SELECT colC,
 SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
 SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
 SUM (CASE WHEN colD = colE AND colD != '0' THEN 1 END) de_one,
 SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
 FROM (SELECT colC, colD, colE
 FROM some_table
 WHERE colA = ArgA AND colB = argB)
 GROUP BY colC
 ORDER BY colC;
 END no_pipeline;
END pipeline_example;
ALTER PACKAGE pipeline_example COMPILE;Edited by: Earthlink on Nov 14, 2010 9:47 AM
Edited by: Earthlink on Nov 14, 2010 11:31 AM
Edited by: Earthlink on Nov 14, 2010 11:32 AM
Edited by: Earthlink on Nov 20, 2010 12:04 PM
Edited by: Earthlink on Nov 20, 2010 12:54 PM

Earthlink wrote:
Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline procedure. Am I missing something? Well, we're missing a lot here.
Like:
- a database version
- how did you test
- what data do you have, how is it distributed, indexed
and so on.
If you want to find out what's going on then use a TRACE with wait events.
All nessecary steps are explained in these threads:
HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
Another nice one is RUNSTATS:
http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701

Performance issues with Homesharing?

I have a Time Capsule as the base station for my wireless network, then 2 Airport Express setup to extend the network around the house, an iMac i7 as the main iTunes Library and couple of iPads, and a couple of Apple TVs. Everything has the latest software, but I have several performance issues with Home sharing. I've done several tests making sure nothing is taking additional bandwidth, so here are the list of issues:
1) With nothing else running, trying playing a movie via home sharing in an iPad 2 which is located on my iMac, it stops and I have to keep pressing the play button over and over again. I typically see that the iPad tries to download part of the movie first and then starts playing so that it deals with the bandwidth, but in many cases it doesn't.
2) When trying to play any iTunes content (movies, music, photos, etc) from my Apple TV I can see my computer library, but when I go in on any of the menus, it says there's no content. I have to reboot the Apple TV and then problem fixed. I's just annoying that I have to reboot.
3) When watching a Netflix movie on my iPad and with Airplay I send the sound to some speakers via Airplay through an Airport Express. At time I lose the connection to the speakers.
I've complained about Wifi's instability, but here I tried to keep everything with Apples products to avoid any compatibility issues and stay within N wireless technology, which I understood it was much more stable.
Has anyone some suggestions?

Hi,
you should analyze the db after you have loaded the tables.
Do you use sequences to generate PKs? Do you have a lot of indexex and/or triggers on the tables?
If yes:
make sure your sequence caches (alter sequence s cache 10000)
Drop all unneeded indexes while loading and disable trigger if possible.
How big is your Redo Log Buffer? When loading a large amount of data it may be an option to enlarge this buffer.
Do you have more then one DBWR Process? Writing parallel can speed up things when a checkpoint is needed.
Is it possible using a direct load? Or do you already direct load?
Dim

Performance issues ..with apex in reports version 3.1

Hello All,
I am using apex 3.1 oracle 10g.
I am facing with performance issues with apex . I am generating iteractive reports with apex and the number of records are huge - running in 30 to 40 thousands of records and the reports is taking almost 30 minutes.
How I can improve the performance of this kind of report. I am using apex collections.
How apex works in terms of retrieving the records -?
Please let me know .
Thanks/kumar
Edited by: kumar73 on Jun 18, 2010 10:21 AM

Hello Tony ,
The following are the sequence of steps to run the test case.
Note:- All the schemas , tables and variables are populated from database.
From Schema and Relations tab choose the following:
1)     Select P3I2008Q4 as schema.
2)     Choose Relation as query path.
3)     Select ECLA, ECLB, MTAB as relations.
From Variables choose the following:
4)     Choose the variables AGE_SEXA,CLODESCA,ALCNO from ECLA relation.
5)     Choose the variables AGE_SEXB, ALCNO, CLODESCB from ECLB relation.
6)     Choose the variables EXPNAME, ALCNO, COST_, COST from MTAB relation.
From Conditions: Click the Run Report button this generated standard report ( Total no of records in report – 30150 )
Click on Interactive report button –to generate an interactive report. ( Error occurred )
We are using return sql statement in generationg the standard report and collections for interactive report.
thanks/kumar

Performance issues with version enable partitioned tables?

Hi all,
Are there any known performance issues with version enable partitioned tables?
Ive been doing some performance testes with a large version enable partitioned table and it seems that OCB optimiser is choosing very expensive plans during merge operations.
Tanks in advance,
Vitor
Example:
 Object Name Rows Bytes Cost Object Node In/Out PStart PStop
UPDATE STATEMENT Optimizer Mode=CHOOSE 1 249
UPDATE SIG.SIG_QUA_IMG_LT
NESTED LOOPS SEMI 1 266 249
PARTITION RANGE ALL 1 9
TABLE ACCESS FULL SIG.SIG_QUA_IMG_LT 1 259 2 1 9
VIEW SYS.VW_NSO_1 1 7 247
NESTED LOOPS 1 739 247
NESTED LOOPS 1 677 247
NESTED LOOPS 1 412 246
NESTED LOOPS 1 114 244
INDEX RANGE SCAN WMSYS.MODIFIED_TABLES_PK 1 62 2
INDEX RANGE SCAN SIG.QIM_PK 1 52 243
TABLE ACCESS BY GLOBAL INDEX ROWID SIG.SIG_QUA_IMG_LT 1 298 2 ROWID ROW L
INDEX RANGE SCAN SIG.SIG_QUA_IMG_PKI$ 1 1
INDEX RANGE SCAN WMSYS.WM$NEXTVER_TABLE_NV_INDX 1 265 1
INDEX UNIQUE SCAN WMSYS.MODIFIED_TABLES_PK 1 62
/* Formatted on 2004/04/19 18:57 (Formatter Plus v4.8.0) */
UPDATE /*+ USE_NL(Z1) ROWID(Z1) */sig.sig_qua_img_lt z1
SET z1.nextver =
SYS.ltutil.subsversion
(z1.nextver,
SYS.ltutil.getcontainedverinrange (z1.nextver,
'SIG.SIG_QUA_IMG',
'NpCyPCX3dkOAHSuBMjGioQ==',
4574,
4575
4574
WHERE z1.ROWID IN (
(SELECT /*+ ORDERED USE_NL(T1) USE_NL(T2) USE_NL(J2) USE_NL(J3)
INDEX(T1 QIM_PK) INDEX(T2 SIG_QUA_IMG_PKI$)
INDEX(J2 WM$NEXTVER_TABLE_NV_INDX) INDEX(J3 MODIFIED_TABLES_PK) */
t2.ROWID
FROM (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j1,
sig.sig_qua_img_lt t1,
sig.sig_qua_img_lt t2,
wmsys.wm$nextver_table j2,
(SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j3
WHERE t1.VERSION = j1.VERSION
AND t1.ima_id = t2.ima_id
AND t1.qim_inf_esq_x_tile = t2.qim_inf_esq_x_tile
AND t1.qim_inf_esq_y_tile = t2.qim_inf_esq_y_tile
AND t2.nextver != '-1'
AND t2.nextver = j2.next_vers
AND j2.VERSION = j3.VERSION))

Hello Vitor,
There are currently no known issues with version enabled tables that are partitioned. The merge operation may need to access all of the partitions of a table depending on the data that needs to be moved/copied from the child to the parent. This is the reason for the 'Partition Range All' step in the plan that you provided. The majority of the remaining steps are due to the hints that have been added, since this plan has provided the best performance for us in the past for this particular statement. If this is not the case for you, and you feel that another plan would yield better performance, then please let me know and I will take a look at it.
One suggestion would be to make sure that the table was been recently analyzed so that the optimizer has the most current data about the table.
Performance issues are very hard to fix without a reproducible test case, so it may be advisable to file a TAR if you continue to have significant performance issues with the mergeWorkspace operation.
Thank You,
Ben

DECODE Vs CASE Performance Issue

Similar Messages

Maybe you are looking for