Poor Response Time

The issue:
Two servers setup with a BO cluster (BoxA and BoxB).
Content switch setup to round-robin users to BoxA or BoxB. (E.g.: first
user request is sent to BoxA. Second user request is sent to BoxB, etc.).
Sticky bit is turned on.
When BoxA is running the CMS server, all requests sent to BoxA run
perfectly.
Requests sent to BoxB have poor response time. Our thought is that the
request gets sent to BoxB and then has to talk to BoxA for processing (since
this is the primary CMS server in charge). The communication between the
two machines is causing a significant lag time.
Please advise on the best way to setup the server and the content switch
to alleviate this issue.

Hi Ray,
can you please check the priority order of the NICs on both your clusters?
My Network Places->Properties->Advanced->Advanced Settings
Make sure that the NICs which the network traffic of the BOBJ cluster passes through get the highest priority. In your case choose one subnet you want to get your trafic through and set the highest priority for the NICs that connecte to the choosen subnet on both nodes.
If you have to change the order of the NICs then please restart the BO services on both nodes if possible.
Regards,
Stratos
Edited by: Efstratios Karaivazoglou on Jun 9, 2009 7:20 PM

Similar Messages

Poor Response Time- Total on a column for n number of rows

I have a table with column cost on my custom OAF page.
When I query for configuration it returns me many rows. so I have set the default rows for table = 10 and then I neatly have next button to go to other rows.
I have enabled totalling on cost column.
Row for Total appears showing sum for the costs only on that page( for only 10 rows). I click for next from drop down , and I see total for the costs for the second page.
Ex:
table has 17 rows and
page 1 :
total row at the end saying 1000.00
page 2 :
total = 1500.00
I want to display Total Cost by summing up the costs for say 300 items returned by the query on all the pages , in above case 2500.00.
I thought of a way to do it ;
I added a sumVO with query "select sum(...) from table" .
Added a new region in my page , added a messageStyleText based on the sumVO, and pulled the total cost in.
It shows me the right result, but my problem is performance.
It is getting very slow. I am using the same query as for displaying the results in table, but summing on cost column.
Can I avoid writing the sum query and do it programmatically in OAF ??
Thanks in advance.

Even if you use programmatic approach, what do you think program will do?
Program has to fetch all the rows in the middle tier and sum it up using for loop. No way its going to solve your problem.
First find out the reason for the slow performance using Trace option. and fix the query.
If your not able to fix it, try materialized view for the summation query.
To take sql trace for OAF page refer this link infor http://prasanna-adf.blogspot.com/2009/01/sql-trace.html
--Prasanna

Alert based on response time of user possible?

Hello,
I'm just wondering if the following is possible in SAP (R/3, CRM, BW, etc...)
Lets say I have a user that is getting poor response times on occasion. Normally, I would run a trace in ST12 when they are having a problem. But what I'd really like to do is have the system watch said user, regardless of the transaction(s) they are running, and then, based on their response time, initiate a trace for that user for the duration of their problem and then send me an alert that a trace has been captured or is currently underway. Is this possible, whether through CCMS or some other function?
I ask this because oftentimes, when a specific user is having a problem, by the time I'm notified, 9 times out of 10 the problem has resolved itself and it is difficult to go back and see what happened.
Thanks,
Tom

Hi
It is possible through CCMS alert monitor. In RZ20 you have dialog user monitor in which you can monitor response time too.
http://help.sap.com/SAPHELP_NW04S/helpdata/EN/2c/abb2e7ff6311d194c000a0c93033f7/content.htm.
Refer above link to get email of CCMS
Thanks
Hetal

ASM & Average Response Time

Greetings All, I was hoping that others may have some insight into DB Control and how is reports ASM Disk response times.
First my environment:
Oracle RAC 11g R1 Standard Edition, Patchset 12
Two Node Cluster
Windows x64 2003 R2 DataCenter Edition.
I am leveraging DB Control to monitor the ASM instances along with the db instances. My issue is regarding how db control gathers metrics to report on average response time for the DISKS that make up the Disk Group.
I have two issues:
1.) The overall response time reported in db control for my disk group "DATA" does not jive with the average I calculate based on the numbers being reported by db control. E.g.) I have ten LUNS in my DATA disk group and if I calculate the mean avg response time from each individual disk as reported by db control I don't get the same number being reported by db control. The numbers differ by as much as 20%.
2.) The numbers reported by ASM for avg response time for each LUN in the disk group are not the same from disk to disk. E.g.) In my current production environment here are the Avg Response Times for each LUN in the group:
8.73, 11.38, 5.22, 4.13, 3.04, 15.84, 12.71, 12.91, 10.51, 9.25.
I would have expected that these disks would have had the same avg response time because ASM is working to guarantee that each disk has the same number of I/O's.
The disk array has identical disks for all 10.
Further, the average for all disks as being reported by db control is : 7.28.
If I do the math I get an average of 9.38, the % diff between these two numbers is 28%
I have heard that db control does a poor job of reporting on ASM disk metrics but this is just people grumbling. I was hoping that someone out there may have some solid facts regarding db control and ASM.

hey....
maybe its be better off to open a generel discussion task on metalink....
*T

Response time of form

I developed a form with triggers like key-up,key-down, post-query, on-lock in three blocks. It works fine in client server environment but when I run the form from the web server it slows down and a job that it has to do on one click of a button actually does when clicked three times.
In master detail blocks which are both in tabular form I have placed an additional field which works as a current record indicator and when I scroll through the records the current record indicator lacks behind.
I even have removed most of the triggers but still the response time is very very poor.
I am using form server with Appachi web server.

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Ahmar Mirza ([email protected]):
I developed a form with triggers like key-up,key-down, post-query, on-lock in three blocks. It works fine in client server environment but when I run the form from the web server it slows down and a job that it has to do on one click of a button actually does when clicked three times.
In master detail blocks which are both in tabular form I have placed an additional field which works as a current record indicator and when I scroll through the records the current record indicator lacks behind.
I even have removed most of the triggers but still the response time is very very poor.
I am using form server with Appachi web server.
<HR></BLOCKQUOTE>
null

Measure DS response times

The etime values in the access log are in units of seconds, so almost all the entries in my logs have an etime of 0. Is there any way to get higher resolution measures of server response times?
Are there tools that people are using to do test searches and measure the performance?
I'm looking for a way to measure the performance both over the short term (eg: once a minute, triggering an alarm if the response times are poor) and long term (eg: monthly trends in response times).

If you want to have microsecond resolution for etime in the access log, enter a value of 131328 (256+131072) in the nsslapd-accesslog-level configuration attribute.

RFC response times deteriorate with time

Hi
We notice that every time our system is restarted, performance is much improved for a the first few weeks. I can appreciate this from the fact that it is a huge system and things can 'clog up' after a while but we have been trying to isolate any specific cause / memory leaks etc.
One thing we have noticed is that although average dialog and background response times appear to increase gradually with time, RFC response times increase substantially. The first few days after a restart we see times of 2, 3 seconds, by the first week 7-10 seconds and by week two and beyond they are over 20 seconds.
We have 15 application servers and all the RFC traffic is load balanced using a RZ12 group that does not include the Central Instance; the same applies in SMQR & SMQS. We still do see some RFC traffic on the CI though... some of the application servers are on a different site, but we cannot see any differences in response times across sites...
Any ideas what's causing this and how we can keep these RFC response times down? The system is very busy and deals with a lot of RFC traffic, when users start complaining about poor performance we can usually see the system flooded with RFCs....
Due to size and nature of this system we can only arrange a restart every couple of months.
Thanks
Ross

Hi Markus, good question, but no, haven't noticed... not sure how I'd check either? There are hundreds (if not thousands) of different transactions ran each month, I'll try sorting the transactions by time for each day and see if there are any common longer runners that have increased, but think it'll be like looking for a needle in a haystack...

Management Services Response Time; per Role or per Deployment? Broken?

Management Services, Alert on Response Time, appears to be incorrect.
Can you help me understand why the Response Time charts for each Role in a deployment are identical? is this a bug?
My Testing
I have 3 Roles in my Cloud Service Deployment. A Web Role, a worker Role, and an extra Worker Role for this test.
Web Role: Light load 0 to 10 requests per hour.
Worker Role: Generates massive net work traffic. Constantly making web service calls to 3rd party data services & running a Distributed Azure Data Cache.
Extra Worker Role: No load. I added it to test this problem. It does nothing other than respond to Management Services Alert pings.
I created 3 Alerts to Track response time. One to each of the 3 roles, testing from within the same data center; San Jose to San Jose. Then added 3 more to test from Singapore to San Jose.
The Result (over several Months)
A. The San Jose charts are identical for each role.
B. The Singapore charts are identical for each role.
C. The set of Singapore charts are very similar to the San Jose set of charts. With slight variations likely due to internet latency & extra load at Singapore.
D. (most Important). The latency is directly correlated to the network load created by the Worker Role. When I turn it off or throttle it, Response Time on all boxes drops. When working at "full speed" network response time rises
to 10 - 30 secs. (very bad)
Conclusion
The Network Monitoring Response Time Alert is not working as designed. It does not show the Response Time for that Role. But seems to be displaying the Response Time for the whole deployment.
My Request
Can you assist me to understand if this is "By Design". If my testing is flawed? or what is going on.
My Goal
Alert the Azure dev team to this so that maybe they can fix it to function as I expected it to. (or for them to explain why my expectations are unreasonable.)
Why is this important?
Poor Network Perf is a showstopper bug that is preventing us from moving into production. I may be able to solve this with multiple instances. But as I lack the granularity to track even at the Role level. I'm stuck.

Thank you for your reply.
I forgot to update this with the answer.
It turned out that Azure Portal's Create Alert/monitoring UI has a bug.
The monitoring service is only capable of pining your public endpoints. ie: your Web Roles. Yet it lets you think you can create an Alert to monitor any of the roles within your solution. To make things worse, it shows a chart that suggests it actually is
pinging your worker roles, when it is actually only pinging the public Web Role.
That is why all the Roles in your solution display identical metrics regardless of their load. Even stopping your worker roles will not affect their ping response times.
If your worker role fails, Azure Alerts don't tell you about it.
NB: Using Application Insights to create alerting does not have this issue. But only because it doesn't attempt to monitor your web roles, not because it can alert you to any issues.

Hard drive passes all tests but extremely high response times causing major performance issues.

I have a HP Compaq Presario CQ62-360TX pre-loaded with Windows 7 home premium (64-bit) that I purchased just under a year ago.
Recently my experience has been interrupted by stuttering that ranges from annoying in general use to a major headache when playing music or videos from the hard drive.
The problem appears to be being caused by extremely hard drive high response times (up to 10 seconds). As far as I know I didn't install anything that might have caused the problems before this happened, and I can't find anything of note looking back through event viewer.
In response to this I've run multiple hard drive scans for problems (chkdsk, scandsk, test through BIOS, test through HP software and others) all of which have passed with no problems. The only thing of any note is a caution on crystaldiskinfo due to the reallocated sector count but as none of the other tests have reported bad sectors I'm unsure as to whether this is causing the problem. I've also updated drivers for my Intel 5 Series 4 Port SATA AHCI Controller from the Intel website and my BIOS from HP as well as various other drivers (sound, video etc), as far as I can tell there are none available for my hard drive directly. I've also wanted to mess with the hard drive settings in the BIOS but it appears those options are not available to me even in the latest version.
System Specs:
Processor: Intel(R) Pentium(R) CPU P6100 @ 2.00GHz (2 CPUs), ~2.0GHz
Memory: 2048MB RAM
Video Card: ATI Mobility Radeon HD 5400 Series
Sound Card: ASUS Xonar U3 Audio Device or Realtek High Definition Audio (both have problem)
Hard Drive: Toshiba MK5065GSK
Any ideas?
Edit: The drive is nowhere near full, it's not badly fragmented and as far as I can tell there's no virus or malware.

Sounds like failing sectors are being replaced with good spares sucessfully so far, this is done on the fly and will not show in any test, you have a failing drive, I would back up your data and replace the hard drive.
Sector replacement on the fly explains the poor performance also, replacing sectors with spares is normal if it is just a few over many years, but crystal is warning you there are too many, a sign of drive failure is around the corner.

Unable to capture the Citrix network response time using OATS Load testing.

Unable to capture the Citrix network response time using OATS Load testing. Here is the scenario " in our project users logs into Citrix network and select the Hyperion application and does the Transaction and the Clients wants us to simulate the same scenario for load testing. We have scripted starting from Citrix Login and then launching Hyperion application. But the time taken to launch the Hyperion Application from Citrix network has not been captured whereas Hyperion Transaction time have been recorded. Can any help to resolve this issue ASAP?

Hi keerthi,
1. I have pasted the code for the first issue
web
                         .button(
                                   122,
                                   "/web:window[@index='0' or @title='Manage Network Targets - Oracle Communications Order and Service Management - Order and Service Management']/web:document[@index='0' or @name='1824fhkchs_6']/web:form[@id='pt1:_UISform1' or @name='pt1:_UISform1' or @index='0']/web:button[@id='pt1:MA:0:n1:1:pt1:qryId1::search' or @value='Search' or @index='3']")
                         .click();
                    adf
                    .table(
                              "/web:window[@index='0' or @title='Manage Network Targets - Oracle Communications Order and Service Management - Order and Service Management']/web:document[@index='0' or @name='1c9nk1ryzv_6']/web:ADFTable[@absoluteLocator='pt1:MA:n1:pt1:pnlcltn:resId1']")
                    .columnSort("Ascending", "Name" );
     }

HP Pavilion hard drive response time is very slow but tests pass (evenutally)

I have owned a HP Pavilion M1199a originally running Windows XP, but has been running Windows Vista 32-bit for the last 3 years or more.
The PC started to lock up for 30 seconds or more (2 weeks ago), with the disk light constantly on then go again for no apparent reason. These lock ups have become more frequent and for longer durations. I removed anti-virus software, and a few other applications/services but generally this computer is fairly clean as I use it as a media center PC.
I have tried checking the disk (SATA) for errors, and it passes although the tests take a lot longer than they should. The resource monitor shows no excess CPU usage and there is plenty of memory available. The disk monitor shows response times of 5000-20000 ms.
What is the best way to proceed from here? Is there a SATA controller or motherboard (ASUS PTGD1-LA) test? Should I buy another SATA drive and try that? I suspect that it is either the drive, drive controller and/or the motherboard that is failing but I don't know how to isolate the problem. The computer hardware configuration has remained the same for years.
The OS has the automatic updates enabled and I uninstalled the recent ones in case they were somehow causing an issue.

tr3v wrote:
Thanks for replying.
1/ No, but I am running Vista, so assume this will be the same? Or should I just look at the tmp and temp environment variables to see what folders are being used?
In Vista type temp in the Search programs and files box and double click on the temp files icon that appears above. Delete all the files in the folder that you can. It is safe as they are exactly what they are called and that is temporary files. If you haven't done this ever or in quite a while there should be a noticeable increase in the operating system's response time.
2/ Yes. It completes after a very long time.
5/ No - but will try this out too.
****Please click on Accept As Solution if a suggestion solves your problem. It helps others facing the same problem to find a solution easily****
2015 Microsoft MVP - Windows Experience Consumer

SAP GoLive : File System Response Times and Online Redologs design

Hello,
A SAP Going Live Verification session has just been performed on our SAP Production environnement.
SAP ECC6
Oracle 10.2.0.2
Solaris 10
As usual, we received database configuration instructions, but I'm a little bit skeptical about two of them :
1/
We have been told that our file system read response times "do not meet the standard requirements"
The following datafile has ben considered having a too high average read time per block.
File name -Blocks read - Avg. read time (ms) -Total read time per datafile (ms)
/oracle/PMA/sapdata5/sr3700_10/sr3700.data10 67534 23 1553282
I'm surprised that an average read time of 23ms is considered a high value. What are exactly those "standard requirements" ?
2/
We have been asked to increase the size of the online redo logs which are already quite large (54Mb).
Actually we have BW loading that generates "Chekpoint not comlete" message every night.
I've read in sap note 79341 that :
"The disadvantage of big redo log files is the lower checkpoint frequency and the longer time Oracle needs for an instance recovery."
Frankly, I have problems undertanding this sentence.
Frequent checkpoints means more redo log file switches, means more archive redo log files generated. right ?
But how is it that frequent chekpoints should decrease the time necessary for recovery ?
Thank you.
Any useful help would be appreciated.

Hello
>> I'm surprised that an average read time of 23ms is considered a high value. What are exactly those "standard requirements" ?
The recommended ("standard") values are published at the end of sapnote #322896.
23 ms seems really a little bit high to me - for example we have round about 4 to 6 ms on our productive system (with SAN storage).
>> Frequent checkpoints means more redo log file switches, means more archive redo log files generated. right?
Correct.
>> But how is it that frequent chekpoints should decrease the time necessary for recovery ?
A checkpoint is occured on every logswitch (of the online redologfiles). On a checkpoint event the following 3 things are happening in an oracle database:
Every dirty block in the buffer cache is written down to the datafiles
The latest SCN is written (updated) into the datafile header
The latest SCN is also written to the controlfiles
If your redologfiles are larger ... checkpoints are not happening so often and in this case the dirty buffers are not written down to the datafiles (in the case of no free space in the buffer cache is needed). So if your instance crashes you need to apply more redologs to the datafiles to be in a consistent state (roll forward). If you have smaller redologfiles more log switches are occured and so the SCNs in the data file headers (and the corresponding data) are closer to the newest SCN -> ergo the recovery is faster.
But this concept does not really fit the reality because of oracle implements some algorithm to reduce the workload for the DBWR in the case of a checkpoint.
There are also several parameters (depends on the oracle version) which control that a required recovery time is kept. (for example FAST_START_MTTR_TARGET)
Regards
Stefan

After IOS 8 update, the screen is jerky and the response time is really, really slow... Using a PC to submit this!

Is there a solution to a jerky screen and a slow response time after updating to IOS 8?

Try some basic troubleshooting:
(A) Try reset iPad
Hold down the Sleep/Wake button and the Home button at the same time for at least ten seconds, until the Apple logo appears
(B) Try reset all settings
Settings>General>Reset>Reset All Settings
(C) Setup as new (data will be lost)
Settings>General>Reset>Erase all content and settings

Is there a way to speed up the response time from the dock

Is there a way to speed up the response time for external hard drives from the dock? I have three external HDs but when I click on the alias in the dock there is always hesitation before it opens. I'm leaning towards the fact that it is just a result of the fact that the speed of the Mac is what it is. But, maybe there is something I can do to speed it up. The drives are plugged via usb directly to the Mac and they have there own power source. The curious thing is that they once were plugged into a large separately powered USB hub and I don't recall a lag like I have now. Any thoughts? Thanks...
Message was edited by: gfann18

Have you got the drives set up to spin down when not in use?
Have a look at the Energy Saver settings in System Preference on the Mac.
Make sure the "Put the Hard Discs to sleep when possible" box is not ticked.

SQL tune (High response time)

Hi,
I am writing the following function which is causing high response time. Can you please help? Please SBMS_SQLTUNE advise.
GENERAL INFORMATION SECTION
Tuning Task Name : BFG_TUNING1
Tuning Task Owner : ARADMIN
Scope : COMPREHENSIVE
Time Limit(seconds) : 60
Completion Status : COMPLETED
Started at : 01/28/2013 15:48:39
Completed at : 01/28/2013 15:49:43
Number of SQL Restructure Findings: 7
Number of Errors : 1
Schema Name: ARADMIN
SQL ID : 2d61kbs9vpvp6
SQL Text : SELECT /*+no_merge(chg)*/ chg.CHANGE_REFERENCE,
chg.Customer_Name, chg.Customer_ID, chg.Contract_ID,
chg.Change_Title, chg.Change_Type, chg.Change_Description,
chg.Risk, chg.Impact, chg.Urgency, chg.Scheduled_Start_Date,
chg.Scheduled_End_Date, chg.Scheduled_Start_Date_Int,
chg.Scheduled_End_Date_Int, chg.Outage_Required,
chg.Change_Status, chg.Change_Status_IM, chg.Reason_for_change,
chg.Customer_Visible, chg.Change_Source,
chg.Related_Ticket_Type, chg.Related_Ticket_ID,
chg.Requested_By, chg.Requested_For, chg.Site_ID, chg.Site_Name,
chg.Element_id, chg.Element_Type, chg.Element_Name,
chg.Search_flag, chg.remedy_id, chg.Change_Manager,
chg.Email_Manager, chg.Queue, a.customer as CUSTOMER_IM,
a.contract as CONTRACT_IM, a.cid FROM exp_cm_cusid1 a, (sELECT *
FROM EXP_BFG_CM_JOIN_V WHERE CUSTOMER_ID = 14187) chg WHERE
a.bfg_con_id IS NULL AND a.bfg_cus_id = chg.customer_id AND
NOT EXISTS (SELECT a.bfg_con_id FROM exp_cm_cusid1 a WHERE
a.bfg_con_id IS NOT NULL AND a.bfg_cus_id = chg.customer_id
AND a.bfg_con_id = chg.contract_id ) UNION SELECT
/*+no_marge(chg)*/ chg.CHANGE_REFERENCE, chg.Customer_Name,
chg.Customer_ID, chg.Contract_ID, chg.Change_Title,
chg.Change_Type, chg.Change_Description, chg.Risk, chg.Impact,
chg.Urgency, chg.Scheduled_Start_Date, chg.Scheduled_End_Date,
chg.Scheduled_Start_Date_Int, chg.Scheduled_End_Date_Int,
chg.Outage_Required, chg.Change_Status, chg.Change_Status_IM,
chg.Reason_for_change, chg.Customer_Visible, chg.Change_Source,
chg.Related_Ticket_Type, chg.Related_Ticket_ID,
chg.Requested_By, chg.Requested_For, chg.Site_ID, chg.Site_Name,
chg.Element_id, chg.Element_Type, chg.Element_Name,
chg.Search_flag, chg.remedy_id, chg.Change_Manager,
chg.Email_Manager, chg.Queue, a.customer as CUSTOMER_IM,
a.contract as CONTRACT_IM, a.cid FROM exp_cm_cusid1 a, (sELECT *
FROM EXP_BFG_CM_JOIN_V WHERE CUSTOMER_ID = 14187) chg WHERE
a.bfg_cus_id = chg.customer_id AND a.bfg_con_id =
chg.contract_id AND a.bfg_con_id IS NOT NULL
FINDINGS SECTION (7 findings)
1- Restructure SQL finding (see plan 1 in explain plans section)
The predicate REGEXP_LIKE ("T100"."C536871160",'^[[:digit:]]+$') used at
line ID 26 of the execution plan contains an expression on indexed column
"C536871160". This expression prevents the optimizer from selecting indices
on table "ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
2- Restructure SQL finding (see plan 1 in explain plans section)
The predicate TO_NUMBER(TRIM("T100"."C536871160"))=:B1 used at line ID 26 of
the execution plan contains an expression on indexed column "C536871160".
This expression prevents the optimizer from selecting indices on table
"ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
3- Restructure SQL finding (see plan 1 in explain plans section)
The predicate REGEXP_LIKE ("T100"."C536871160",'^[[:digit:]]+$') used at
line ID 10 of the execution plan contains an expression on indexed column
"C536871160". This expression prevents the optimizer from selecting indices
on table "ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
4- Restructure SQL finding (see plan 1 in explain plans section)
The predicate TO_NUMBER(TRIM("T100"."C536871160"))=:B1 used at line ID 10 of
the execution plan contains an expression on indexed column "C536871160".
This expression prevents the optimizer from selecting indices on table
"ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
5- Restructure SQL finding (see plan 1 in explain plans section)
The predicate REGEXP_LIKE ("T100"."C536871160",'^[[:digit:]]+$') used at
line ID 6 of the execution plan contains an expression on indexed column
"C536871160". This expression prevents the optimizer from selecting indices
on table "ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
6- Restructure SQL finding (see plan 1 in explain plans section)
The predicate TO_NUMBER(TRIM("T100"."C536871160"))=:B1 used at line ID 6 of
the execution plan contains an expression on indexed column "C536871160".
This expression prevents the optimizer from selecting indices on table
"ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
7- Restructure SQL finding (see plan 1 in explain plans section)
An expensive "UNION" operation was found at line ID 1 of the execution plan.
Recommendation
- Consider using "UNION ALL" instead of "UNION", if duplicates are allowed
or uniqueness is guaranteed.
Rationale
"UNION" is an expensive and blocking operation because it requires
elimination of duplicate rows. "UNION ALL" is a cheaper alternative,
assuming that duplicates are allowed or uniqueness is guaranteed.
ERRORS SECTION
- The current operation was interrupted because it timed out.
EXPLAIN PLANS SECTION
1- Original
Plan hash value: 1047651452
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT|
| 0 | SELECT STATEMENT | | 2 | 28290 | 567 (37)| 00:00:07 | | |
| 1 | SORT UNIQUE | | 2 | 28290 | 567 (37)| 00:00:07 | | |
| 2 | UNION-ALL | | | | | | | |
|* 3 | HASH JOIN RIGHT ANTI | | 1 | 14158 | 373 (5)| 00:00:05 | | |
| 4 | VIEW | VW_SQ_1 | 1 | 26 | 179 (3)| 00:00:03 | | |
| 5 | NESTED LOOPS | | 1 | 37 | 179 (3)| 00:00:03 | | |
|* 6 | TABLE ACCESS FULL | T100 | 1 | 28 | 178 (3)| 00:00:03 | | |
|* 7 | INDEX RANGE SCAN | I1451_536870913_1 | 1 | 9 | 1 (0)| 00:00:01 | | |
| 8 | NESTED LOOPS | | 1 | 14132 | 193 (5)| 00:00:03 | | |
|* 9 | HASH JOIN | | 1 | 14085 | 192 (5)| 00:00:03 | | |
|* 10 | TABLE ACCESS FULL | T100 | 1 | 28 | 178 (3)| 00:00:03 | | |
| 11 | VIEW | EXP_BFG_CM_JOIN_V | 3 | 42171 | 13 (24)| 00:00:01 | | |
| 12 | UNION-ALL | | | | | | | |
|* 13 | HASH JOIN | | 1 | 6389 | 5 (20)| 00:00:01 | | |
| 14 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 15 | REMOTE | PROP_CHANGE_INVENTORY_V | 1 | 410 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 16 | HASH UNIQUE | | 1 | 6052 | 6 (34)| 00:00:01 | | |
|* 17 | HASH JOIN | | 1 | 6052 | 5 (20)| 00:00:01 | | |
| 18 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 19 | REMOTE | PROP_CHANGE_INVENTORY_V | 1 | 73 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 20 | HASH UNIQUE | | 1 | 5979 | 3 (34)| 00:00:01 | | |
| 21 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 22 | TABLE ACCESS BY INDEX ROWID| T1451 | 1 | 47 | 1 (0)| 00:00:01 | | |
|* 23 | INDEX RANGE SCAN | I1451_536870913_1 | 1 | | 1 (0)| 00:00:01 | | |
| 24 | NESTED LOOPS | | 1 | 14132 | 193 (5)| 00:00:03 | | |
|* 25 | HASH JOIN | | 1 | 14085 | 192 (5)| 00:00:03 | | |
|* 26 | TABLE ACCESS FULL | T100 | 1 | 28 | 178 (3)| 00:00:03 | | |
| 27 | VIEW | EXP_BFG_CM_JOIN_V | 3 | 42171 | 13 (24)| 00:00:01 | | |
| 28 | UNION-ALL | | | | | | | |
|* 29 | HASH JOIN | | 1 | 6389 | 5 (20)| 00:00:01 | | |
| 30 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 31 | REMOTE | PROP_CHANGE_INVENTORY_V | 1 | 410 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 32 | HASH UNIQUE | | 1 | 6052 | 6 (34)| 00:00:01 | | |
|* 33 | HASH JOIN | | 1 | 6052 | 5 (20)| 00:00:01 | | |
| 34 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 35 | REMOTE | PROP_CHANGE_INVENTORY_V | 1 | 73 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 36 | HASH UNIQUE | | 1 | 5979 | 3 (34)| 00:00:01 | | |
| 37 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 38 | TABLE ACCESS BY INDEX ROWID | T1451 | 1 | 47 | 1 (0)| 00:00:01 | | |
|* 39 | INDEX RANGE SCAN | I1451_536870913_1 | 1 | | 1 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
3 - access("ITEM_0"="EXP_BFG_CM_JOIN_V"."CUSTOMER_ID" AND "ITEM_1"="EXP_BFG_CM_JOIN_V"."CONTRACT_ID")
6 - filter("C536871050" LIKE '%FMS%' AND REGEXP_LIKE ("C536871160",'^[[:digit:]]+$') AND ("C536871088" IS NULL
OR REGEXP_LIKE ("C536871088",'^[[:digit:]]+$')) AND TO_NUMBER(TRIM("C536871088")) IS NOT NULL AND
TO_NUMBER(TRIM("C536871160"))=:SYS_B_0 AND "C536871160" IS NOT NULL AND "C536871050" IS NOT NULL AND "C7"=0)
7 - access("C536870913"="C536870914")
9 - access("EXP_BFG_CM_JOIN_V"."CUSTOMER_ID"=TO_NUMBER(TRIM("C536871160")))
10 - filter("C536871050" LIKE '%FMS%' AND REGEXP_LIKE ("C536871160",'^[[:digit:]]+$') AND ("C536871088" IS NULL
OR REGEXP_LIKE ("C536871088",'^[[:digit:]]+$')) AND TO_NUMBER(TRIM("C536871088")) IS NULL AND
TO_NUMBER(TRIM("C536871160"))=:SYS_B_0 AND "C536871160" IS NOT NULL AND "C536871050" IS NOT NULL AND "C7"=0)
13 - access("CHG"."PRP_CHG_REFERENCE"="INV"."PRP_CHG_REFERENCE")
17 - access("CHG"."PRP_CHG_REFERENCE"="INV"."PRP_CHG_REFERENCE")
23 - access("C536870913"="C536870914")
25 - access("EXP_BFG_CM_JOIN_V"."CUSTOMER_ID"=TO_NUMBER(TRIM("C536871160")) AND
"EXP_BFG_CM_JOIN_V"."CONTRACT_ID"=TO_NUMBER(TRIM("C536871088")))
26 - filter("C536871050" LIKE '%FMS%' AND REGEXP_LIKE ("C536871160",'^[[:digit:]]+$') AND ("C536871088" IS NULL
OR REGEXP_LIKE ("C536871088",'^[[:digit:]]+$')) AND TO_NUMBER(TRIM("C536871088")) IS NOT NULL AND
TO_NUMBER(TRIM("C536871160"))=:SYS_B_1 AND "C536871160" IS NOT NULL AND "C536871050" IS NOT NULL AND "C7"=0)
29 - access("CHG"."PRP_CHG_REFERENCE"="INV"."PRP_CHG_REFERENCE")
33 - access("CHG"."PRP_CHG_REFERENCE"="INV"."PRP_CHG_REFERENCE")
39 - access("C536870913"="C536870914")
Remote SQL Information (identified by operation id):
14 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
15 - SELECT "PRP_CHG_REFERENCE","SIT_ID","SIT_NAME","ELEMENT_SUMMARY","PRODUCT_NAME" FROM
"PROP_OWNER2"."PROP_CHANGE_INVENTORY_V" "INV" (accessing 'ARS_BFG_DBLINK.WORLD' )
18 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
19 - SELECT "PRP_CHG_REFERENCE","SIT_ID","SIT_NAME" FROM "PROP_OWNER2"."PROP_CHANGE_INVENTORY_V" "INV"
(accessing 'ARS_BFG_DBLINK.WORLD' )
21 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
30 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
31 - SELECT "PRP_CHG_REFERENCE","SIT_ID","SIT_NAME","ELEMENT_SUMMARY","PRODUCT_NAME" FROM
"PROP_OWNER2"."PROP_CHANGE_INVENTORY_V" "INV" (accessing 'ARS_BFG_DBLINK.WORLD' )
34 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
35 - SELECT "PRP_CHG_REFERENCE","SIT_ID","SIT_NAME" FROM "PROP_OWNER2"."PROP_CHANGE_INVENTORY_V" "INV"
(accessing 'ARS_BFG_DBLINK.WORLD' )
37 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
-------------------------------------------------------------------------------

Please review the following threads:
{message:id=9360002}
{message:id=9360003}

Poor Response Time

Similar Messages

Maybe you are looking for