High GUI Time - Causing high Response time

Hi All,
Average GUI Response time is approx 400 ms in my ECC 6.0 system, OS - HP UX, Database - Oracle 10.2.0.5.
I expect it should always be approx 200 ms, but as it is high it is contibuting to high overall response time.
I expect there are normally two ways of high GUI time :
1) High network time between Presentation layer( User System) and Application Layer(SAP Server).
2) High amount of time in Loading User Screen
For Option 2 I have checked we are using SAP access menu so there should not any problem with loading of User Access Menu.
Average Response time for session_manager is 2 Secs.
Please suggest me what all other ways available to improve GUI time,
Can there be other reasons of high GUI time and how can we make sure that high GUI time is only because of high Network time.
Please suggest.
Shivam

I believe in case you have multiple roundtrips per step, then the client performance comes into play as well. So if you have slow clients this could be an issue too.
Basically you are already looking in the right place (network connection), but i recommend you also check:
- roundtrips per step and amount of data sent to the client
- are all transactions having high gui times, or only a few?
- how is the situation on the clients?
- if you have clients working on prod and qas check the values on the qas system too
Cheers Michael

Similar Messages

What causes slow response times

In any session, my computer response times slow down and I have to close all apps and restart to get the system to speed up again. Is this a CPU, hard drive or similar problem? Any solutions?

Hi,
I expect the error details in CF9\runtime\logs\coldfusion-out.log will like provide a clue as to problem.
For a more long term plan I think you should do what you can to migrate the ACCESS data to SQL or some other database.
HTH, Carl.

Incorrect Alerts CPU Time and Average Response Time

BUG
My Alert on Web app is consistently behaving incorrectly.
If I set an alert to monitor CPU Time at threshold 1.5 seconds, it's actually set to 1.5 milliseconds even though the graph shows a dotted red line at 1.5 seconds. The alert will trigger at 1.5 milliseconds threshold. So, instead, I have to set threshold
to 1500 seconds - the graph is completely useless showing a red dotted line at ~24 mins but the alert does then go off when CPU time goes above 1500 ms (aka 1.5 seconds).
The original portal alert seems to be fine - this problem is on new portal only. Unaffected by browser type - all browsers do the same thing (Just has to be said before someone asks).
This seems to apply to all metrics using seconds (Average Response Time acts in the same way)

Hii...
Am sure you are much aware " Components Response Time spectrum"
########Analyzing Performance Problems#################
--High wait time: Insufficient number of free work processes
--High roll-wait time: Communication problem with GUI, external system,
or large amount of data requested
--High load and generation time: SAP buffers (Program, CUA or Screen)
too small
--High database request time: CPU/memory bottleneck on database server;
communication problem with database server, expensive SQL statements,
database locks, missing indexes, missing statistics or small database buffer(s)
--High CPU time: Expensive ABAP processing, for example, processing
large tables; inefficient programming
--Processing time more than twice CPU time: CPU bottlenecks
If time aloows look at
Note 0000008963 - Definition of SAP response time/processing time/CPU time
Rgds

CPIC/RFC Time vs Total Response time

Hi experts,
We are experiencing performance issues in our SRM system, when checking the transaction ST03 we have identified a high dialog comsuption time in the Average RFC Interface time (CPIC/RFC), this time is even higher than the Total Average Reponse Time per dialog step.
Could you please let us know if the component Average RFC Interface time (CPIC/RFC) is part of the average response time? We can't understand why this time is almos the double than the
Thanks and best regards,

Hello Sowmya,
I would normally suggest a solution without having detailed background about your system such as SAP kernel, SAP release etc.
But the following SAP Note almost describes your issue.
2071875 - Incorrect Average RFC Interface Time ("CPIC/RFC") in ST03N Workload Overview ("Average time per step in ms")
Hope that helps.
Regards,
Siddhesh

What would cause the response time of Firefox to be very long?

I have been using Firefox for years with few problems. Now Firefox takes seconds to respond to any request. If I use a mouse click before Firefox is read, "not responding" appears on the top line and the little blue revolving circle appears. Firefox finally responds after seconds. Explorer is responding normally, so I don't think it is my Internet connection. I am using Firefox 3.6.10 under Windows 7.

Check the Time Zone support option in Settings > Mail > Calendars > Time Zone Support.

Macbook Pro Boot time and general response time slow.

I'm running 10.9 Mavericks.
Yesterday as I was doing my every day activites I realized randomly my macbook pro began preforming extremely poorly.
My problems:
Boot time now takes 2-3 minutes.
Applications take 2-3 minutes to open.
Applications will say they're open sometimes but will not display.
Applications will take several tries to quit.
Applications, especially Safari, will randomly crash.
Everything is slower and takes a while to do, even opening a simple folder will take a minute.
The things I have tried:
I ran a Hardware test and the results showed it is not a hardware problem.
I have reset the SMC and PRAM and the problems still occur.
I have Verified and repaired the Disk/Permissions, however it seems to stop mid-way through (after about an hour).
I can't seem to figure out what's wrong with it. I can re-install the OS but with my internet it is estimated to take 8 hours.
Any suggestions?

Your disk may be failing. Do not attempt to resintall the OS until your disk is healthy.
Backup your data immediately:
Before proceeding you should make sure you have a current backup. If it has been getting slower over time your disk could be a failing slowly. SATA drives have two retry modes: short and long. They can continue operating as read errors are increasing. The long retry cycle is very long and can cause significant performance degradation. If it has started long retries then it is likely to get worse and eventually fail. SSDs also have a failure mode where the fail slowly.
Time Machine Basics: http://support.apple.com/kb/ht1427
Most commonly used backup methods:
https://discussions.apple.com/docs/DOC-3045
Methodology to protect your data. Backups vs. Archives. Long-term data protection:
https://discussions.apple.com/docs/DOC-6031
Make a Genius Bar reservation http://www.apple.com/retail/geniusbar/ .
or find an Apple Authorized Service Provider https://locate.apple.com/country
If it is a failing disk, consider an upgrade to a 1 TB, 7200 RPM disk. Check out a one terabyte HGST 7K1000 7200 rpm, SATA III drive from OWC or consider an SSD.

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.

Slow Response Time on iPhone 3G

On or about r4.0 coming out I started experiencing significant Response Time delays moving between key's on my iPhone and not sure why. I believe this to be a Processor issue... anybody else out there experiencing this issue.
Example:
Select Setting icon on Home Screen... reasonable response time of 1-sec
Select General icon tab... 3-4 sec delay in response
Select another tab on General screen... another 3-4 sec delay before new screen appears.
Hit Home button to close General window... 3-4 sec delay...
Select Messaging icon... goes to white screen and 3-4 sec delay before messaging dialogue screen comes up
Keep in mind that there aren't any other app's running in the background that causes response time delays
The response time delays occur, regardless whether I am on Edge, Wi-fi or 3G.. I do not believe this to be a Networking issue...
Also, I only have 3- menu screens with maybe 23 app icons showing... most of which are iPhone apps like iTunes, Messaging, Settings, Mail, Safari, Stocks, weather, camera, contacts, calendar, pix, Maps, no games!!
I have done master reboot on phone... Network Reset... & Restore...
on rare occasions I will resume a 1-1.5 sec response time between my selections, otherwise, returning to 3-4 sec delays.
Coincidently, around the time this issue occurred, I had upgraded iTunes to 9.2 but doubt this created issues...I eventually downloaded r4.0 thinking a bug fix may have been included... but issue continued...
Any feedback? Thx

Well, to all those queing in on my question-observation... let me provide you an update.
True to form, APPLE provided me great support and Customer Satisfaction.
I did my due diligence and called into Apple Care and an app't was made for me at the Genius Bar the next day.
They assessed my situation and despite informing me it was the nature of the beast (3G), they happily exchanged my 3G out for a new 3G and guess what... with no app's sync'd to it as yet, right out of the box, not r4.0 the response time was the same.
Bottom line is 3G processor's are slow... especially compared against the 3GS and iP4... and loading r4.0 didn't impact it. With my contract expiring in a few days I bit the bullet and have a new iP4 and now enjoy almost instantaneous response to my key selections, etc.... oh, and no dropped calls due to antenna.

Query Tuning - Response time Statistics collection

Our Application is Load tested for a period of 1 hour with peak load.
For this specific period of time, say thousands of queries gets executed in the database,
What we need is say for one particular query " select XYZ from ABC" within this span of 1 hour, we need statistics like
Number of times Executed
Average Response time
Maximum response time
minimum response time
90th percentile response time ( sorted in ascending order, 90th percentile guy)
All these statistics are possible if i can get all the response times for that particular query for that period of 1 hour....
I tried using sql trace and TKPROF but unable to get all these statistics...
Application uses connection pooling, so connections are taken as and when needed...
Any thoughts on this?
Appreciate your help.

I don't think v$sqlarea can help me out with the exact stats i needed, but certainly it has lot of other stats to take. B/w there is no dictionary view called v$sqlstats.
There are other applications which share the same database where i am trying to capture for my application, so flushing cache which currently has 30K rows is not feasible solution.
Any more thoughts on this?

"Time stamp, Response time and Completion time" in CRM_DNO_MONITOR

Hi,
We have configured Service desk functionality in Solution Manager 4.0.
In CRM_DNO_MONITOR we were able to see all the data except "Time stamp(0), Response time(00:00:00) and Completion time(00:00:00)" of Service desk message.
Kindly let us know, how to configure so that "Time stamp, Response time and Completion time" should be displayed in CRM_DNO_MONITOR.
Best regards,
Bhaskar

Hi,
Do u want this for SLA?
In the service desk you have to assign the date profile to the SLFN transaction type.
For this you can use the standard date profile SLFN_HEADER.
award point if it helps you.
regards,
mahantesh

ACE 4710: Find out the response time of a real server

Hi to everyone,
I have a couple of ACE 4710 and I need to find out what is the response time of a real server.
Is there a way for this?
Thank you for any answer!
giorgio romano

Hi,
Kindly add the following line in your serverfarm configuration:
predictor response syn-to-synack
Suppose your serverfarm looks like this:
serverfarm host AAA_FARM
predictor response syn-to-synack
probe HTTP_PROBE
probe TCP9001_PROBE
rserver SC106
inservice
rserver SC107
inservice
rserver SC108
inservice
rserver SC109
inservice
rserver SC110
inservice
rserver SC111
inservice
rserver SC112
inservice
rserver SC113
inservice
rserver SC114
inservice
rserver SC120
inservice
rserver SC131
inservice
And then use the following command to see the average response time from your rserver as follows:
ACE1/prod# show serverfarm AAA_FARM detail
serverfarm     : AAA_FARM, type: HOST
total rservers : 11
active rservers: 11
description    : ServerFarm AAA
state          : ACTIVE
predictor      : RESPONSE
method            : syn-to-synack
samples           : 8
failaction     : -
back-inservice    : 0
partial-threshold : 0
num times failover       : 0
num times back inservice : 0
total conn-dropcount : 0
Probe(s) :
HTTP_PROBE, type = HTTP
TCP9001_PROBE, type = TCP
----------connections-----------
real                  weight state        current    total      failures
---+---------------------+------+------------+----------+----------+---------
rserver: SC106
x.x.x.x.:0        8      OPERATIONAL 2          1125       0
max-conns            : 4000000   , out-of-rotation count : 0
min-conns            : 4000000
conn-rate-limit      : -         , out-of-rotation count : -
bandwidth-rate-limit : -         , out-of-rotation count : -
retcode out-of-rotation count : -
load value           : 0
average response time (usecs) : 81   ----> thats what you might be looking for
From other day :
rserver: SC114
x.x.x.x:0        8      OPERATIONAL 70         10903      2
max-conns            : 4000000   , out-of-rotation count : 0
min-conns            : 4000000
conn-rate-limit      : -         , out-of-rotation count : -
bandwidth-rate-limit : -         , out-of-rotation count : -
retcode out-of-rotation count : -
load value           : 0
         average response time (usecs) : 1334                       ----> thats what you might be looking for
For Serverfarm BBB_FARM
serverfarm     : BBB_FARM, type: HOST
total rservers : 1
active rservers: 1
description    : ServerFarm BBB
state          : ACTIVE
predictor      : RESPONSE
method            : syn-to-synack
samples           : 8
failaction     : -
back-inservice    : 0
partial-threshold : 0
num times failover       : 1
num times back inservice : 1
total conn-dropcount : 0
Probe(s) :
----------connections-----------
real                  weight state        current    total      failures
---+---------------------+------+------------+----------+----------+---------
rserver: SC208
x.x.x.x:0        8      OPERATIONAL 0          0          0
max-conns            : 4000000   , out-of-rotation count : 0
min-conns            : 4000000
conn-rate-limit      : -         , out-of-rotation count : -
bandwidth-rate-limit : -         , out-of-rotation count : -
retcode out-of-rotation count : -
load value           : 0
         average response time (usecs) : 0   ----> thats what you might be looking for
Use more detials for response predictor:
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/rsfarms.html#wp1068831
Configuring the Application Response Predictor
To instruct the ACE to select the server with the lowest average response time for the specified response-time measurement based on the current connection count and server weight (if configured), use the predictor response command in server farm host or redirect configuration mode. This predictor is considered adaptive because the ACE continuously provides feedback to the load-balancing algorithm based on the behavior of the real server.
To select the appropriate server, the ACE measures the absolute response time for each server in the server farm and averages the result over a specified number of samples (if configured). With the default weight connection option configured, the ACE also takes into account the server's average response time and current connection count. This calculation results in a connection distribution that is proportional to the average response time of the server.
The syntax of this command is as follows:
predictor response {app-req-to-resp | syn-to-close | syn-to-synack}[samples number]
The keywords and arguments are as follows:
•app-request-to-resp—Measures the response time from when the ACE sends an HTTP request to a server to the time that the ACE receives a response from the server for that request.
•syn-to-close—Measures the response time from when the ACE sends a TCP SYN to a server to the time that the ACE receives a CLOSE from the server.
•syn-to-synack—Measures the response time from when the ACE sends a TCP SYN to a server to the time that the ACE receives the SYN-ACK from the server.
•samples number—(Optional) Specifies the number of samples over which you want to average the results of the response time measurement. Enter an integer from 1 to 16 in powers of 2. Valid values are 1, 2, 4, 8, and 16. The default is 8.
For example, to configure the response predictor to load balance a request based on the response time from when the ACE sends an HTTP request to a server to when the ACE receives a response back from the server and average the results over four samples, enter:
host1/Admin(config)# serverfarm SFARM1
host1/Admin(config-sfarm-host)# predictor response app-req-to-resp
samples 4
To reset the predictor method to the default of round-robin, enter:
host1/Admin(config-sfarm-host)# no predictor
To configure an additional parameter to take into account the current connection count of the servers in a server farm, use the weight connection command in server farm host predictor configuration mode. By default, this command is enabled. The syntax of this command is as follows:
weight connection
For example, enter:
host1/Admin(config)# serverfarm SF1
host1/Admin(config-sfarm-host)# predictor response app-request-to-resp
samples 4
host1/Admin(config-sfarm-host-predictor)# weight connection
To remove the current connection count from the calculation of the average server response time, enter:
host1/Admin(config-sfarm-host-predictor)# no weight connection
You can use threshold milliseconds parameter which is optional Specifies the required minimum average response time for a server. If the server response time is greater than the specified threshold value, the ACE removes the server from the load-balancing decision process (takes the server out of service).
Enter an integer from 1 to 300000 milliseconds (5 minutes). The default is no threshold (servers are not taken out of service).
In case if you have measures the response time from when the ACE sends a TCP SYN to a server to the time that the ACE receives a CLOSE from the server use syn-to-close      (already discussed previously)
If you have to measures the response time from when the ACE sends a TCP SYN to a server to the time that the ACE receives the SYN-ACK from the server use syn-to-synack   (already discussed previously)
SAMPLES parameter is optional and specifies the number of samples that you want to average from the results of the response time measurement and response time is used to select the server with the lowest response time for the requested response-time measurement. If you do not specify a response-time measurement method, the ACE uses the HTTP app-req-to-response method.
Whenever a server's load reaches zero, by default, the ACE uses the autoadjust feature to assign a maximum load value of 16000 to that server to prevent it from being flooded with new incoming connections. The ACE periodically adjusts this load value based on feedback from the server's SNMP probe and other configured options.
Using the least-loaded predictor with the configured server weight and the current connection count option enabled, the ACE calculates the final load of a real server as follows:
final load = weighted load Ã— static weight Ã— current connection count
where:
â€¢weighted load is the load reported by the SNMP probe
â€¢static weight is the configured weight of the real server
â€¢current connection count is the total number of active connections to the real server
The ACE recalculates the final load whenever the connection count changes, provided that the (config-sfarm-host-predictor) weight connection command is configured. If the (config-sfarm-host-predictor) weight connection command is not configured, the ACE updates the final load when the next load update arrives from the SNMP probe.
If two servers have the same lowest load (either zero or nonzero), the ACE load balances the connections between the two servers in a round-robin manner.
HTH
Plz rate if u find it useful.
Sachin

Benchmark response times using BIA.

Hi all
I ran some queries using BIA and logged their processing times. Now, I want to compare these processing times with "benchmark response times using BIA" just to make sure that these queries are performing optimally. Could you pls provide pointers/links to the same.
Regards
Niranjana

Following are the steps we do in order to get the benchmark data.
Assume you have Indexed a cube in BIA.
Without BIA:
1. Goto transaction RSRT2-->Select the query and click "Execute + Debug"
2. Under section "BIA Server"-->Check "Donot user BIA Index"
3. Under section "Others"--> Check "Display statistics data" and "Do not user cache"
4. Execute....After query complete click on Back button to see the statistics
5. Sum up the "Duration column" and Subtotal by column "Event Text"
6. We are interested on the item "datamanager" - note down the value
With BIA:
7. Goto transaction RSRT2-->Select the same query and click "Execute + Debug"
8. Under section "BIA Server"-->DONOT Check "Donot user BIA Index"
9. Under section "Others"--> Check "Display statistics data" and "Do not use cache"
10. Execute....After query complete click on Back button to see the statistics
11. Sum up the "Duration column" and Subtotal by column "Event Text"
12. We are interested on the item "datamanager" - note down the value
13. Click on "Aggregation layer"-->You should note the on the "aggregation" column the cube name should be suffixed with "$X" ( which indicates it uses BIA)
14. Here "viewed at" is sum of other two front columns...
In the above way you can benchmark between non-BIA vs BIA query performance. if you see even with BIA the performance is slow...then it could be bcoz of OLAP time...lot of calculation in the frontend etc...
In general we see the performance of BIA is fantastic...except sometimes the numbers are not matching between BIA and non-BIA queries...where we need to rebuild the indexes.
Hope it helps
Gopi

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.

High GUI time in ST03

I found high GUI time in ST03.
Example: In last minute's load --> workload overview -->
Start of interval 27.10.2008 07:43:00
End of interval    27.10.2008 07:58:00
Time period        0   Day(s) 00:15:01
I found 1280ms Roll wait time and 1280 GUI time. It seems too high. How can I find what cause it? how can I locate the root case?
Please advise. Thanks so much.
James

Hi,
Here are the few things to check when the GUI time is high.
1. Check in ST03--> Transaction Profile the Tx SESSION_MANAGER may be on top id yes, the load caused by the transaction SESSION_MANAGER, combined with the high roll in + wait time could indicate that the SAP Easy Access menu might not be configured correctly and should be tuned to improve overall response times. It is also possible that your users have been assigned disproportionately large user menus. We advise you to ensure there are a reasonable number of entries (nodes) in the User Menu.
Generally, its recommended that users should have no more than 1000 and as an absolute maximum 2000 menu nodes configured, (for comparison, the complete SAP menu contains 70,000 entries). A high number of entries may lead to high memory consumption on the server and to long response times for the menu. Refer to SAP Notes 203617 and 203994 for details
2. ST06 --> Detail Analysis Menu --> Lan check by Ping with more than 10 Presentation
servers.
See the Average and Loss coloumn and check wether is there any problem exits.
However, review the following recommendations to identify any network issues. Given below are the response times which are thresholds for a good network performance.
Recommendation: Characteristic response times are:
- In a local area network (LAN) : <20 milliseconds
- In a "fast" Wide Area Network (WAN) (for example, 256 or 384 KBit/sec):   < 50 milliseconds
- In a "slow" wide area network (WAN) (For example, 128 KBit/sec or less): < 250 milliseconds
- Losses of data packets ("Loss") should not occur at all.
Review SAP Notes 203924 (under subheading 'General Performance Analysisu2019), 8963 and 578118 for further information on SAP GUI and response time components.
In case of long response times due to performance problems in the network (in particular when using SAPGUI in WAN), you should use configuration "Low Speed Connection" in SAPLOGON. As a result, menus are only transferred on request, and the quantity of the transferred data is reduced correspondingly. This measure reduces the network load significantly. You can find this setting option under: SAPLOGON -> PROPERTIES -> ADVANCED.
Option for a low speed connection:
On a low speed connection (LSC) to the network, the benefits of the improved interaction design may be outweighed by increased response times due to the heavier network traffic. To counterbalance this effect, SAP has introduced the option for a low speed connection to the network in Release 4.6. A flag can be set in the options of an SAP logon connection item or on the SAP GUI command line. This action has the following effects:
- Menus are loaded only on demand as before
- Background Bitmaps are not transferred (depending on the application)
- The list control transfers only the lines that are visible on the screen
- The application can query the flag to react to the network condition individually.
Examine the following SAP Notes and verify that the SAP recommendations contained are fully implemented:
- SAP Note Number 161053   Low Speed Connection is in use
- SAP Note Number 164102   Network load between application servers +camera front end
- SAP Note Number   62418   Network Load of SAPGUI Frontend Communication (Required Bandwidth).
Please let me know if the performance improves.
Thank you,
Tilak

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}

High GUI Time - Causing high Response time

Similar Messages

Maybe you are looking for