High Update Response Time

Hi folks,
how could I to check the High Update Response Time
Thanks.

Hi Carlos,
Goto ST03 and check from there.
That link was posted by mistake.
Divyanshu

Similar Messages

High Update Response Time ticket from solman

Hi Experts,
We have monitoring setup from solman. We are getting an alert for ECC prod that the there is High Update Response Time. Can you please let me know how to fix it?
Thanks,
Asad

Hi Asad ,
How many update work process do you have . See a high amount of wait time for the update process
You may increase their number if you have enough memory .
Go to SM13 , Go to -> Administration of update system
Goto - > Statistics
Response Times: Rules of Thumb - CCMS Monitoring - SAP Library
Less than 1 second is the recommended , though sometimes you may breach it .
Thanks ,
Manu

High RFC response time in SAP BW system

Hello all,
How to analyze and fine tune high RFC response time in SAP BW system ?
Regards,
Archana

Hi
Kindly Check follows
1. Check the RFC connections are correctly Configured or not? You can execute the program “RSRFCTRC” and get a full log of the RFC connections details
2 you can check the BW queries are right optimized? Is this any network issues?
3. In which time are you facing the high rfc response? (During the 24 hours which time)?
4. Kindly refer the SCN & SAP Notes for overall system performance
Short Notes on PERFORMANCE MONITORING - ABAP Development - SCN Wiki
1063061 - Information about response time in STAD/ST03
948066 - Performance Analysis: Transactions to use
Regards
Sriram

High Avg Response time for logon requests via CMS

Hi Team ,
We are continuously receiving observing high Average reponse time for logon requests to the BO system via Central Management Server.
We observe response time up to 25043 ms .
Currently we are on SAP BO 4.0 SP7 patch 9 (4.0.7.9)
DB = SQL server 2008 R2
App Server = SAP NW 7.31 SP 7.
Also the size of our CMS DB is around 15 GB .
What could be the possible reasons ?
Regards ,
Abhinav

Hi Abhinav,
As one of the issues has been raised as a bug which is resolved in BI 4.1 so you can upgrade to resolve this bug. Also if the CMS database size is large then CMS has to search for objects through huge number of rows hence that will affect overall performance. So you can try to reduce this size as per my previous upate.
Apart this you can try following steps
Try to ping CMS DB server from BO servers and confirm the response is coming in 1 ms. Run tracert <DB servers name> from CMD and check the number of hops. If response time is not 1 ms or there are more number of hops then ask your network team to resolve network latency issue
You can increase the "System database connections" for each CMS from server properties. It is set to 14 by default which means the CMS will establish 14 connections to CMS database at any time. You can increase this value, however please make sure that the system database allows more connections than default 14 from DB side. This needs to be confirmed from your DBA.
Please add CMS cluster members in platformservices.properties file under Tomcat folder. Please refer following SAP KBA for steps to add the cluster members
       http://service.sap.com/sap/support/notes/1668515
       http://service.sap.com/sap/support/notes/1766935
   4. Also please confirm number of users simultaneously login to system at peak time. Usually one           CMS is capable of handling around 500 requests. So if you have more then 1000 users then add           another new CMS on same nodes if there is enough free memory on the server
Regards,
Hrishikesh

High Dialog response time

Hi,
We have a solman 4.0 system. The average dialog response time of the system is very high. What can be done to bring down this response time??
Thanks in Advance
Amit.

Hi Amit,
Please check out the breakdown of dialog response time in Workload Monitor. Also, use the Time Profile to check if this high response time is at specific timings.
regards, Shantanu

High CPU response times, altough low CPU utilization

Hi Friends,
We have a performance problem after we migrate our basis system,
The current system is :
Database server : Sun SPARC Enterprise T5240 Server - 2 CPU's with 6 core, 8 thread, 1.2 Ghz
32 GB RAM
and we use another identical configured server as an application server.
Database is Oracle 10.2.0 and operating system is Solaris 10.
The problem is average CPU response time is 450 ms, and max. CPU load is %5 percent.
Pre-migration configuration with old servers, we had CPU response : 150 ms and max CPU load: 50%.
Has anyone of you, have experinced a similar problem with this new CPU's?
Thanks in advance

> I am aware that there might be lots of reasons, but what I guess is, there should be a parameter wrong with the CPU settings. This SPARC server CPU is a new tech. 6 core 8 thread one, which is expected to work much faster than the old simple dual core CPU.
Is it?
ABAP is basically a virtual machine and what is most important: ABAP runs single threaded. This means in consequence that the processing time of a program relies on the single processing power of one core. More cores means more parallelism but the speed of the single statement always relies on the power of one core and how fast it can get the data over the bus and back. So the significant number for speed is basically the Mhz (for ABAP, Java is very different).
Your old machine may have had a DualCore SPARC 1,2 Ghz and the new machine has one 1,4 Ghz 6core CPU (assuming so).
> However its response time is very high, although it is never utilized more than %5 percent.
see above.
> The problem might be at database settings(Oracle 10.2.0) or at Solaris ? ? ?
Well - no - I don't think so
Since ABAP is a single threaded application it can't leverage the CPU power due to the fact, that a parallelism in the program itself does not take place and hence the machine scales not linear with the number of cores. So you may have factually a machine with about 1 dot something CPUs and not 6 as you would expect.
This is not specific to SPARC CPU design but for all multi-core systems. A single threaded application is only as fast as the CPU speed. ABAP programs tend to be huge so you will also see effects of cache displacement and bus congestions. Less cores and more physical CPUs perform much better than any multicore CPU.
For Java the world is very different because Java works as one process (in the SAP case jlaunch) which has many many threads that can be executed in parallel on different pipelines on the CPU.
Unfortunately this is a design problem and there's not much you can do about it.
Markus

Virtual Machine - high disk response time

Hi Everyone,
Got something strange happening in our lab at the moment and was wondering if anyone had experienced the same thing (and maybe has a solution).
Our lab environment in a nutshell:
2x Windows 2012 Hyper hosts cluster connected to a "home-made" SAN based on Windows 2012 iSCSI target.
Each Hyper-V host has two 1Gbps network cards to connect to the SAN via the Microsoft iSCSI initiator, with MPIO in load-balancing mode (least queue depth).
The SAN (Windows 2012 server with iSCSI target) has 4x 1Gbps cards, teamed two by two, so presenting two IP addresses used by each hosts to connect to it (via MPIO).
The disk subsystem on the Windows 2012 SAN is an external HP storage works with 25x HP 500 SATA disks, connected to the server via an INTEL RAID controller with 2x 240GB SSD caching enabled for read/write.
The iSCSI network is on a dedicated HP switch, with flow-control and jumbo frame enabled (tested ok).
Now the problem:
I've built a few virtual machines on the two hyper-v nodes and I'm getting very bad disk response time as soon as there is an increase in the disk traffic.
When the virtual server is doing very little, I get a normal 6-8ms, but I soon as I increase the traffic (by for example copying a big file, or installing an application), this figure shoots up to 200ms, 300ms and more!
So I first thought that it was my disk subsystem (and the SAN server), but while the spikes are happening within the virtual machine, the disks on the SAN Server are sitting at about 10ms, with some spikes to about 20ms (which is pretty good and what I would
expect to see within the VM because of the SSD cache).
I then thought it could be the network, but during those times of activity, the network does not get saturated at all. Barely 150Mbps to 200Mbps per link.
I even tried to disable MPIO and run everything across one Ethernet link, but still the same result.
Am I missing something here? doing something wrong? or is this expected behaviour?
Thank you,
Stephane

Hi,
VR38DETT is right, if you want to use more ISCSI bandwidth or redundancy you must use the MPIO method, Multipath I/O (MPIO) is a feature that provides support for using multiple
data paths to a storage device. Multipathing increases the availability of storage resources by providing path failover from a server or cluster to a storage subsystem.
More information:
Multipath I/O Overview
http://technet.microsoft.com/en-us/library/cc725907.aspx
Support for Multipath I/O (MPIO)
http://technet.microsoft.com/en-us/library/cc770294.aspx
Hope this helps.
Alex Lv

"Windows 8 using 100% of HDD with high average response times and low read/write speed"

Turns out this is a fairly well known windows 8.1 issue that has been plaguing users since at least 2013 and there is no one simple fix, so it may not be *entirely* hp's fault; but I've had two of these laptops, both the same model, the first one needing to be returned and exchanged for an entirely unrelated issue (hardware failure: ethernet port nonfunctional with lights stuck on). Both are refurbished. Both have been extreemly slow and unresponsive even compared to a lesser Brazos powered laptop I had before, but I've only recently decided to investigate why.
So if there is something HP specific going on here, I hope there is one simple fix. My average response time has gone up as far as well over a minute (>60,000ms), so I may be an outlier case here compared to the typical windows 8.1 hardrive responsiveness/bandwidth problem.
Edit: there is a case with another HP pavilion laptop (intel powered though, so it may be an intel storage driver issue described in the first link) being much, much worse.
This question was solved.
View Solution.

Guess what just now happened again
So using DISM did _not_ fix it.

Performance Issue - Update response time

Hi,
I am trying to get the equipment data and I have to link with asset. The only way I could find is through m_equia view. I select the equipment number from m_equia passing the key as asset no and from there i go to equi and get the other data.
But when i am trying to select from m_equia the database time is more. So, can some one suggest me a better option for this other than the m_equia to get the equipment details with asset as the key. I also have cost center details with me.
Thanks,

Hi,
Please find the select on m_equia and further select on it.
Get asset related data from the view
IF NOT i_asset[] IS INITIAL.
   SELECT anlnr
          equnr
     FROM m_equia
     INTO TABLE i_asst_equi
     FOR ALL ENTRIES IN i_asset
     WHERE anlnr = i_asset-anln1 AND
           anlun = i_asset-anln2 AND
           bukrs = i_asset-bukrs.
   IF sy-subrc = 0.
     SORT i_asst_equi BY equnr.
   ENDIF.
ENDIF.
Get Equipment related data
IF NOT i_asst_equi[] IS INITIAL.
   SELECT equi~equnr
          herst
          typbz
          eqart
          mapar
          serge
          iwerk
     FROM equi
     INNER JOIN equz
     ON equiequnr = equzequnr
     INTO TABLE i_equipment
     FOR ALL ENTRIES IN i_asst_equi
     WHERE equi~equnr = i_asst_equi-equnr.
   SORT i_equipment BY equnr.
ENDIF.
Thanks.
Message was edited by:
        lakshmi

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

Reduce Dialogue response Time

Hi Friends,
ST03N transaction is showing very high dialogue response time for my ERP system.
On doing further analysis in STAD , i found the SQL queries (DB response) time is fine. Is there any way i can reduce the time. Increasing the CPU capacity is not an option.
Please advice.

Hello,
Performance tuning can be a complex thing, you have to find where the bottleneck is e.g.:
-Memory/paging (OS)
-SAP buffers (ST02)
-to few work processes (SM51)
-user behaviour
-disk I/O
Take a look at:
http://wiki.sdn.sap.com/wiki/display/ABAP/Performance+Tuning
There are also some good SAP Press books about this available.
regards
Christian

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.

New Display coming out with a higher contrast ratio & response time?

Is there a New 30" or better Display coming out with a higher contrast ratio & response time?
I'm very used to using crt monitors and the quality of the current 30inch is nice but blacks are not quite as black and colors are not as rich.
Apple seems to be right on with what they have. Just hoping for an update to their displays soon.
Thanks ahead for your reply.
-Line

Apple reseller in Sydney today said that new Apple HD displays are 6- 8 weeks away and that Apple is running down stocks of the existing displays.
No idea of the veracity of this claim, just what I was told.
2GHz dual G5, ATI X800 XT, 2 X 500Gb HD, LaCie D2 1Tb, 3.5Gb RAM , 23" HD Panel Mac OS X (10.4.9)

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

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 Update Response Time

Similar Messages

Maybe you are looking for