Response Time BPEL Fault

Hi everybody,
i have the following Problem:
create a simple composite with one Mediator wiring to one simple BPEL Process.
The BPEL throws his own Business Fault define within the WSDL.
The Mediator propagate this Fault to the inital caller.
Everthing works fine but...
The Response Time for the normal request and response of the BPEL is 300 - 400ms.
If the BPEL throws the Fault, the response Time is over 6 Seconds!!
Has anyone an idea why the Response Time from the BPEL Fault is so much higher?
Thanks a lot
regs Stefan

Hi Neeraj,
the Problem is identified. The long Response Time comes from our internal Company Network.
The Response Times if calling the Service from hosted Environment is OK.
Regards Stefan
Edited by: stisiman on 27.03.2013 14:57

Similar Messages

BPEL fault policy takes more time, when rethrowing

Hi All,
I have a scenario where BPEL fault policy is taking more time to re-throw the fault back to BPEL
Scenario:
1) Partner link service throws as business exception
2) This exception is first caught by BPEL fault policy, this in-turn will invoke "oracle.apps.aia.core.eh.BPELJavaAction" & then it is re-throw's back to BPEL process. Then time while rethrow'n back to BPEL process it taking too much time.
Environment:
SOA suite : Version 10.1.3.4.0 with AIA
Hi all , any updates on this
Edited by: user535670 on Aug 19, 2009 7:43 PM

Abap team debugged and found out that there was an issue with RFC in ECC system.
RFC connection was not working. it was causing the flow to wait for 1 mins. Basis fixed the issue to make RFC working. now interface works without connection time out.

BPEL faults do not generate response.

Hi,
I have a BPEL process that catches some faults, performs a transformation and rethrows a slightly different fault. I was expecting that the rethrow would generate a response with soap fault to the client automatically. However, what really happens is that the process is marked as faulted in the BPEL console and the client never receives a response.
Is this the expected behavior? I was expecting, just like in java, that on throwing a fault, a response will be generated with the appropriate soap fault type. Is this not a valid assumption? Please clarify.
Thanks!

In your catch handler you should reply back the the fault in case this is an synchronous BPEL process, in that case you should define the <fault> in your WSDL as well.
http://orasoa.blogspot.com

"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.

Increase synchronous process response time

hi all
From my sycn BPEL process I am calling CRM sycn’ly .
Response from CRM is coming very lately for that I am getting time out error .
Can we achieve a scenario where my sync BPEL process will wait for a longer time .
Its not possible to make it async delayed response also.
Keeping it Sync only how can I increase in response time period?
i am using SOA 10.1.3.4 version.
thx in advance ..

Go to the BPEL Properties in EM, then advanced BPEL properties, find the property syncMaxWaitTime And increase it to 240 may be...
Also increase the JTA timeout in weblogic console....keep this value more than 240

Response time increase in OSB

Dear all,
While performing the Load test, during initial 2 - 3 hrs performance is very good. after 2 -3 hrs response time increasing and there by throughput going down 4 times.
when i check in GC Log, i found all OC's. generally i used to find many YC's and very less OC's. but this time its deferent. not sure why this behaviour.
Below is snap shot of my gc.log.
Following are my startManagedweblogic java options.
JAVA_OPTIONS="${JAVA_OPTIONS} -Xverbose:memory -Xmx:6144m -Xms:6144m -Xns:3072m -Xverbosetimestamp -Xgcprio:pausetime -Xverboselog:/usr/home/WEBADM/blq2gsbl/BLQRYSBDM/bin/gc.log -Xverbose:gcreport -XlargePages -XXgcThreads:8 -XXtlasize:min=2k,preferred=16k -XXnoSystemGC"
please note that i have enough memory to increase till 12 gb also. i found better performance with 6g so i kept it as 6.
[WARN ] Use of -Djrockit.optfile is deprecated and discouraged.
[memory ][Mon Aug 12 12:34:11 2013][16261] Running with 32 bit heap and compressed references supporting 32GB heap.
[memory ][Mon Aug 12 12:34:11 2013][16261] Using 256MB pages for Java heap.
[memory ][Mon Aug 12 12:34:12 2013][16261] GC mode: Garbage collection optimized for short pausetimes, strategy: Generational Concurrent Mark & Sweep.
[memory ][Mon Aug 12 12:34:12 2013][16261] Heap size: 6291456KB, maximal heap size: 6291456KB, nursery size: 3145728KB.
[memory ][Mon Aug 12 12:34:12 2013][16261] <start>-<end>: <type> <before>KB-><after>KB (<heap>KB), <time> ms, sum of pauses <pause> ms.
[memory ][Mon Aug 12 12:34:12 2013][16261] <start> - start time of collection (seconds since jvm start).
[memory ][Mon Aug 12 12:34:12 2013][16261] <type>   - OC (old collection) or YC (young collection).
[memory ][Mon Aug 12 12:34:12 2013][16261] <end>    - end time of collection (seconds since jvm start).
[memory ][Mon Aug 12 12:34:12 2013][16261] <before> - memory used by objects before collection (KB).
[memory ][Mon Aug 12 12:34:12 2013][16261] <after> - memory used by objects after collection (KB).
[memory ][Mon Aug 12 12:34:12 2013][16261] <heap>   - size of heap after collection (KB).
[memory ][Mon Aug 12 12:34:12 2013][16261] <time>   - total time of collection (milliseconds).
[memory ][Mon Aug 12 12:34:12 2013][16261] <pause> - total sum of pauses during collection (milliseconds).
[memory ][Mon Aug 12 12:34:12 2013][16261]            Run with -Xverbose:gcpause to see individual phases.
[memory ][Mon Aug 12 12:49:59 2013][16261] [YC#1] 947.689-948.011: YC 3426740KB->1274833KB (6291456KB), 0.323 s, sum of pauses 322.080 ms, longest pause 322.080 ms.
[memory ][Mon Aug 12 12:50:18 2013][16261] [YC#2] 966.433-966.521: YC 3700241KB->1381022KB (6291456KB), 0.088 s, sum of pauses 87.355 ms, longest pause 87.355 ms.
[memory ][Mon Aug 12 12:50:33 2013][16261] [YC#3] 981.691-981.734: YC 3806640KB->1448962KB (6291456KB), 0.043 s, sum of pauses 42.316 ms, longest pause 42.316 ms.
[memory ][Mon Aug 12 12:50:48 2013][16261] [YC#4] 996.195-996.232: YC 3876151KB->1518729KB (6291456KB), 0.037 s, sum of pauses 36.360 ms, longest pause 36.360 ms.
[memory ][Mon Aug 12 12:51:03 2013][16261] [YC#5] 1011.797-1011.833: YC 3950327KB->1592393KB (6291456KB), 0.036 s, sum of pauses 35.004 ms, longest pause 35.004 ms.
[memory ][Mon Aug 12 12:51:19 2013][16261] [YC#6] 1027.447-1027.489: YC 4022805KB->1665479KB (6291456KB), 0.041 s, sum of pauses 40.711 ms, longest pause 40.711 ms.
[memory ][Mon Aug 12 12:51:34 2013][16261] [YC#7] 1043.090-1043.127: YC 4097355KB->1739629KB (6291456KB), 0.037 s, sum of pauses 35.984 ms, longest pause 35.984 ms.
[memory ][Mon Aug 12 12:51:50 2013][16261] [YC#8] 1058.656-1058.704: YC 4171396KB->1814054KB (6291456KB), 0.047 s, sum of pauses 46.695 ms, longest pause 46.695 ms.
[memory ][Mon Aug 12 12:52:00 2013][16261] [YC#9] 1068.490-1068.533: YC 4245475KB->1887941KB (6291456KB), 0.043 s, sum of pauses 42.002 ms, longest pause 42.002 ms.
[memory ][Mon Aug 12 12:52:09 2013][16261] [YC#10] 1077.381-1077.421: YC 4318167KB->1961481KB (6291456KB), 0.041 s, sum of pauses 39.592 ms, longest pause 39.592 ms.
[memory ][Mon Aug 12 12:52:19 2013][16261] [YC#11] 1087.366-1087.406: YC 4394185KB->2036571KB (6291456KB), 0.039 s, sum of pauses 38.757 ms
87.597 ms, longest pause 50.632 ms.
[memory ][Tue Aug 13 18:21:28 2013][16261] [OC#9822] 107234.509-107237.018: OC 893216KB->845338KB (6291456KB), 2.509 s, sum of pauses 536.399 ms, longest pause 504.274 ms.
[memory ][Tue Aug 13 18:21:31 2013][16261] [OC#9823] 107237.419-107239.864: OC 1116022KB->860547KB (6291456KB), 2.445 s, sum of pauses 414.935 ms, longest pause 354.974 ms.
[memory ][Tue Aug 13 18:21:34 2013][16261] [OC#9824] 107239.864-107242.447: OC 949080KB->878533KB (6291456KB), 2.583 s, sum of pauses 541.277 ms, longest pause 504.113 ms.
[memory ][Tue Aug 13 18:21:37 2013][16261] [OC#9825] 107242.447-107245.494: OC 953535KB->860560KB (6291456KB), 3.047 s, sum of pauses 633.955 ms, longest pause 504.806 ms.
[memory ][Tue Aug 13 18:21:39 2013][16261] [OC#9826] 107245.494-107247.971: OC 1054631KB->869654KB (6291456KB), 2.478 s, sum of pauses 541.422 ms, longest pause 504.193 ms.
[memory ][Tue Aug 13 18:21:42 2013][16261] [OC#9827] 107247.972-107250.441: OC 921210KB->857407KB (6291456KB), 2.469 s, sum of pauses 483.940 ms, longest pause 440.031 ms.
[memory ][Tue Aug 13 18:21:45 2013][16261] [OC#9828] 107250.792-107253.213: OC 1132559KB->875285KB (6291456KB), 2.422 s, sum of pauses 524.526 ms, longest pause 487.132 ms.
[memory ][Tue Aug 13 18:21:47 2013][16261] [OC#9829] 107253.213-107255.610: OC 899114KB->855957KB (6291456KB), 2.397 s, sum of pauses 481.233 ms, longest pause 451.024 ms.
[memory ][Tue Aug 13 18:21:50 2013][16261] [OC#9830] 107256.011-107258.297: OC 1127479KB->868126KB (6291456KB), 2.286 s, sum of pauses 373.648 ms, longest pause 336.646 ms.
[memory ][Tue Aug 13 18:21:52 2013][16261] [OC#9831] 107258.298-107260.847: OC 912365KB->856462KB (6291456KB), 2.550 s, sum of pauses 526.103 ms, longest pause 492.768 ms.
[memory ][Tue Aug 13 18:21:55 2013][16261] [OC#9832] 107261.098-107263.611: OC 1044068KB->863005KB (6291456KB), 2.513 s, sum of pauses 541.427 ms, longest pause 504.196 ms.
[memory ][Tue Aug 13 18:21:57 2013][16261] [OC#9833] 107263.611-107265.846: OC 902510KB->847460KB (6291456KB), 2.235 s, sum of pauses 213.535 ms, longest pause 179.799 ms.
[memory ][Tue Aug 13 18:22:00 2013][16261] [OC#9834] 107265.946-107268.356: OC 974573KB->863254KB (6291456KB), 2.409 s, sum of pauses 441.951 ms, longest pause 405.552 ms.
[memory ][Tue Aug 13 18:22:02 2013][16261] [OC#9835] 107268.556-107271.134: OC 1013772KB->856892KB (6291456KB), 2.578 s, sum of pauses 542.932 ms, longest pause 503.782 ms.
[memory ][Tue Aug 13 18:22:05 2013][16261] [OC#9836] 107271.134-107273.302: OC 946088KB->860358KB (6291456KB), 2.168 s, sum of pauses 220.883 ms, longest pause 182.948 ms.
[memory ][Tue Aug 13 18:22:07 2013][16261] [OC#9837] 107273.552-107275.500: OC 1010670KB->854399KB (6291456KB), 1.948 s, sum of pauses 120.783 ms, longest pause 56.691 ms.
[memory ][Tue Aug 13 18:22:09 2013][16261] [OC#9838] 107275.501-107277.801: OC 906839KB->850508KB (6291456KB), 2.301 s, sum of pauses 399.919 ms, longest pause 367.834 ms.
[memory ][Tue Aug 13 18:22:11 2013][16261] [OC#9839] 107278.052-107280.071: OC 1045319KB->862319KB (6291456KB), 2.019 s, sum of pauses 144.317 ms, longest pause 75.239 ms.
[memory ][Tue Aug 13 18:22:14 2013][16261] [OC#9840] 107280.071-107282.578: OC 887997KB->849438KB (6291456KB), 2.507 s, sum of pauses 537.495 ms, longest pause 504.761 ms.
[memory ][Tue Aug 13 18:22:16 2013][16261] [OC#9841] 107282.879-107284.888: OC 1061809KB->860007KB (6291456KB), 2.009 s, sum of pauses 137.893 ms, longest pause 63.667 ms.
[memory ][Tue Aug 13 18:22:19 2013][16261] [OC#9842] 107284.888-107287.367: OC 908775KB->852632KB (6291456KB), 2.479 s, sum of pauses 541.465 ms, longest pause 504.889 ms.
[memory ][Tue Aug 13 18:22:21 2013][16261] [OC#9843] 107287.517-107289.881: OC 1005267KB->849986KB (6291456KB), 2.364 s, sum of pauses 160.999 ms, longest pause 86.633 ms.
[memory ][Tue Aug 13 18:22:24 2013][16261] [OC#9844] 107289.881-107292.353: OC 907985KB->848410KB (6291456KB), 2.472 s, sum of pauses 540.357 ms, longest pause 504.985 ms.
[memory ][Tue Aug 13 18:22:26 2013][16261] [OC#9845] 107292.353-107294.314: OC 916160KB->850798KB (6291456KB), 1.961 s, sum of pauses 104.840 ms, longest pause 66.068 ms.
[memory ][Tue Aug 13 18:22:28 2013][16261] [OC#9846] 107294.364-107296.780: OC 923551KB->849834KB (6291456KB), 2.416 s, sum of pauses 440.677 ms, longest pause 403.477 ms.
[memory ][Tue Aug 13 18:22:30 2013][16261] [OC#9847] 107296.931-107299.111: OC 997464KB->858904KB (6291456KB), 2.180 s, sum of pauses 246.058 ms, longest pause 206.937 ms.
[memory ][Tue Aug 13 18:22:33 2013][16261] [OC#9848] 107299.111-107301.563: OC 903415KB->851026KB (6291456KB), 2.452 s, sum of pauses 540.845 ms, longest pause 504.318 ms.
[memory ][Tue Aug 13 18:22:35 2013][16261] [OC#9849] 107301.814-107303.861: OC 1013878KB->857614KB (6291456KB), 2.048 s, sum of pauses 94.386 ms, longest pause 53.197 ms.
[memory ][Tue Aug 13 18:22:38 2013][16261] [OC#9850] 107303.861-107306.212: OC 887706KB->860005KB (6291456KB), 2.350 s, sum of pauses 346.029 ms, longest pause 311.092 ms.
[memory ][Tue Aug 13 18:22:40 2013][16261] [OC#9851] 107306.262-107308.853: OC 937699KB->860853KB (6291456KB), 2.591 s, sum of pauses 557.007 ms, longest pause 501.625 ms.
[memory ][Tue Aug 13 18:22:43 2013][16261] [OC#9852] 107308.853-107311.426: OC 951313KB->870294KB (6291456KB), 2.573 s, sum of pauses 541.352 ms, longest pause 504.381 ms.
[memory ][Tue Aug 13 18:22:45 2013][16261] [OC#9853] 107311.426-107314.144: OC 909609KB->852710KB (6291456KB), 2.718 s, sum of pauses 583.129 ms, longest pause 504.576 ms.
[memory ][Tue Aug 13 18:22:48 2013][16261] [OC#9854] 107314.144-107316.628: OC 969124KB->858298KB (6291456KB), 2.484 s, sum of pauses 542.151 ms, longest pause 504.257 ms.
[memory ][Tue Aug 13 18:22:50 2013][16261] [OC#9855] 107316.628-107319.114: OC 915682KB->849121KB (6291456KB), 2.486 s, sum of pauses 495.272 ms, longest pause 447.599 ms.
[memory ][Tue Aug 13 18:22:53 2013][16261] [OC#9856] 107319.314-107321.936: OC 1006620KB->861443KB (6291456KB), 2.621 s, sum of pauses 544.915 ms, longest pause 504.410 ms.
[memory ][Tue Aug 13 18:22:56 2013][16261] [OC#9857] 107321.936-107324.410: OC 922270KB->852766KB (6291456KB), 2.474 s, sum of pauses 541.767 ms, longest pause 504.142 ms.
[memory ][Tue Aug 13 18:22:58 2013][16261] [OC#9858] 107324.610-107327.023: OC 1039488KB->861496KB (6291456KB), 2.413 s, sum of pauses 542.856 ms, longest pause 504.187 ms.
[memory ][Tue Aug 13 18:23:01 2013][16261] [OC#9859] 107327.023-107329.315: OC 918829KB->843657KB (6291456KB), 2.292 s, sum of pauses 321.525 ms, longest pause 286.826 ms.
[memory ][Tue Aug 13 18:23:03 2013][16261] [OC#9860] 107329.616-107332.141: OC 1069773KB->863389KB (6291456KB), 2.525 s, sum of pauses 548.231 ms, longest pause 504.177 ms.
[memory ][Tue Aug 13 18:23:06 2013][16261] [OC#9861] 107332.141-107334.343: OC 915522KB->853889KB (6291456KB), 2.202 s, sum of pauses 189.135 ms, longest pause 153.663 ms.
[memory ][Tue Aug 13 18:23:08 2013][16261] [OC#9862] 107334.644-107337.056: OC 1032066KB->868736KB (6291456KB), 2.412 s, sum of pauses 545.438 ms, longest pause 504.254 ms.
[memory ][Tue Aug 13 18:23:11 2013][16261] [OC#9863] 107337.056-107339.296: OC 915783KB->864080KB (6291456KB), 2.240 s, sum of pauses 298.272 ms, longest pause 263.347 ms.
[memory ][Tue Aug 13 18:23:13 2013][16261] [OC#9864] 107339.597-107341.923: OC 1011429KB->878520KB (6291456KB), 2.326 s, sum of pauses 456.568 ms, longest pause 419.025 ms.
[memory ][Tue Aug 13 18:23:15 2013][16261] [OC#9865] 107341.923-107343.934: OC 919359KB->840367KB (6291456KB), 2.011 s, sum of pauses 125.250 ms, longest pause 57.223 ms.
[memory ][Tue Aug 13 18:23:18 2013][16261] [OC#9866] 107344.185-107346.733: OC 1012840KB->874965KB (6291456KB), 2.548 s, sum of pauses 540.636 ms, longest pause 504.970 ms.
[memory ][Tue Aug 13 18:23:20 2013][16261] [OC#9867] 107346.750-107348.793: OC 933751KB->854858KB (6291456KB), 2.043 s, sum of pauses 156.099 ms, longest pause 82.344 ms.
[memory ][Tue Aug 13 18:23:23 2013][16261] [OC#9868] 107348.793-107351.335: OC 887450KB->867195KB (6291456KB), 2.542 s, sum of pauses 537.543 ms, longest pause 504.801 ms.
[memory ][Tue Aug 13 18:23:25 2013][16261] [OC#9869] 107351.486-107353.546: OC 996281KB->860628KB (6291456KB), 2.060 s, sum of pauses 160.157 ms, longest pause 73.442 ms.
[memory ][Tue Aug 13 18:23:27 2013][16261] [OC#9870] 107353.546-107356.073: OC 906961KB->872330KB (6291456KB), 2.527 s, sum of pauses 539.374 ms, longest pause 504.913 ms.
[memory ][Tue Aug 13 18:23:30 2013][16261] [OC#9871] 107356.273-107358.702: OC 996457KB->851473KB (6291456KB), 2.429 s, sum of pauses 166.761 ms, longest pause 86.493 ms.
[memory ][Tue Aug 13 18:23:33 2013][16261] [OC#9872] 107358.703-107361.265: OC 907359KB->863117KB (6291456KB), 2.562 s, sum of pauses 541.203 ms, longest pause 504.927 ms.
[memory ][Tue Aug 13 18:23:35 2013][16261] [OC#9873] 107361.265-107363.378: OC 912545KB->853583KB (6291456KB), 2.113 s, sum of pauses 112.867 ms, longest pause 69.906 ms.
[memory ][Tue Aug 13 18:23:37 2013][16261] [OC#9874] 107363.379-107365.933: OC 919557KB->864998KB (6291456KB), 2.554 s, sum of pauses 543.605 ms, longest pause 504.637 ms.
[memory ][Tue Aug 13 18:23:39 2013][16261] [OC#9875] 107365.983-107368.091: OC 958748KB->857127KB (6291456KB), 2.108 s, sum of pauses 252.535 ms, longest pause 215.897 ms.
[memory ][Tue Aug 13 18:23:42 2013][16261] [OC#9876] 107368.342-107370.827: OC 999403KB->865783KB (6291456KB), 2.485 s, sum of pauses 540.028 ms, longest pause 504.197 ms.
[memory ][Tue Aug 13 18:23:44 2013][16261] [OC#9877] 107370.827-107372.683: OC 923670KB->857704KB (6291456KB), 1.856 s, sum of pauses 87.595 ms, longest pause 52.619 ms.
[memory ][Tue Aug 13 18:23:47 2013][16261] [OC#9878] 107372.883-107375.283: OC 985737KB->859804KB (6291456KB), 2.399 s, sum of pauses 487.291 ms, longest pause 451.118 ms.
[memory ][Tue Aug 13 18:23:49 2013][16261] [OC#9879] 107375.283-107377.932: OC 915211KB->853184KB (6291456KB), 2.649 s, sum of pauses 555.557 ms, longest pause 504.480 ms.
[memory ][Tue Aug 13 18:23:52 2013][16261] [OC#9880] 107377.932-107380.212: OC 1009969KB->874361KB (6291456KB), 2.279 s, sum of pauses 375.384 ms, longest pause 335.326 ms.
[memory ][Tue Aug 13 18:23:54 2013][16261] [OC#9881] 107380.212-107382.461: OC 914805KB->855458KB (6291456KB), 2.249 s, sum of pauses 288.521 ms, longest pause 250.881 ms.
[memory ][Tue Aug 13 18:23:56 2013][16261] [OC#9882] 107382.562-107384.892: OC 966755KB->867614KB (6291456KB), 2.330 s, sum of pauses 500.018 ms, longest pause 463.414 ms.
[memory ][Tue Aug 13 18:23:59 2013][16261] [OC#9883] 107384.942-107387.565: OC 932206KB->853768KB (6291456KB), 2.622 s, sum of pauses 565.151 ms, longest pause 504.160 ms.
[memory ][Tue Aug 13 18:24:01 2013][16261] [OC#9884] 107387.565-107389.985: OC 958792KB->862315KB (6291456KB), 2.421 s, sum of pauses 461.570 ms, longest pause 420.545 ms.

You need to find out the error code you get in fault due to response timeout. (run a test using test console and you would get that)
In error handler of stage from where you are calling this business service, check whether status code in $fault is equal to the error code due to response timeout. If it is equal then replace content of $body with required error xml and use reply with success.
See section "37.6 Fault Variable" to know more about $fault -
http://download.oracle.com/docs/cd/E14571_01/doc.1111/e15867/context.htm#i1051956
Regards,
Anuj

Response time in web services

I have a simple calculator web service running on tomcat server. On the client side, I have a loop in which I randomly select 2 operators and an operand and invoke the calculator web service.
I was conducting tests by invoking the web service within a loop. I observed that as the number of requests increased the response time reduced. I am unable to figure out why this happens.
Any help would be appreciated.

For monitoring BPEL orchestrated services (process status, activity, variables, suspend/resume/terminate instances), we have open source bpel monitor API and command line tool. We are working on a graphic version of BPEL monitor, but you can find a simple one contributed by a member in the community:
http://wiki.open-esb.java.net/Wiki.jsp?page=BPELMonitor
Regards,
Mei

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}

Will the problems I am having with slow Safari response times continue if I port the image of my 4 to an new iphone 5?

As in many families, I am ready to upgrade my iphone 4 to a 5 and pass on my 4 to my partner (who has my old 3), BUT I am resistant to do so because I have been having problems with Safari, (very slow response time) ever since I upgraded to the new OS a month or so back. I have completed all the cleaning tips (cookies, individual app shut downs) and hard boot steps with no change. I can sit my partners Iphone 3 next to my 4 and when using Safari it beats it hands down, almost doubling the time it takes on the 3. My 4 is quicker on all the other apps so I don't believe it is a hardware issue. My tests were done using our home wi fi set up the same on both phones after running all the cleaning tips on both.
I actually broke down and called the support line and the first level support told me if I upgraded to the 5 I would likely carry the problem to the new phone. She said she suspected malware or a virus and that for $300 she could forward me to second level support that could scan my phone and see what the problem is on my 4 and support any issues on a new iphone 5 OR for a one time lower fee $79, just help me fix my 4.
Thinking through her options, I chose none of the above. Seems like I should be able to either 1) isolate the issue myself with the help of this forum or 2) upgrade to the iphone 5 and if the problem follows to the new one, get the support via the new device warranty. If the support person is correct and the problem is in the software and would follow the device, then in theroy I could wipe and restore my old 4 with the back up/data of my partners 3 and the problem on the 4 should be resolved.
I really don't want to carry the problem to a new phone if I can fix the issue first. I have airwatch software to push my work email to my phone and that is usually a pain to do when I upgrade anyhow. I don't need to pay for a new phone that has the same problem as my old one. I will get grief from my partner for passing on an issue that will come up with the daily use of the old iphone 4 that I will be responsible to fix anyhow. I have invested too much time already to generate problems on both our phones. Thanks in advance for any tips or guideance about a streamlined way forward.

Basic troubleshooting from the User's Guide is reset, restart, restore (first from backup then as new). Has any of this been tried?
FYI, there are no viruses that affect iOS unless the device has been hacked or jailbroken, in which case they cannot be discussed here.

Response time for Error Messages - Please Help

Hi
I have a PRO C application talking to an Oracle database.
The Response time for successful query is within desirable limits.
But when there is a error condition (eg SQLError -3113,or connection refused) it takes more than 9 minutes for the database to respond with the error code.
This condition is observed with only one database while the others are working fine.
What is the reason for this? Can’t it be reduced?
Regards
David

ever been faced with the same problem ?
Why deleting ? It that only one way to fix this problem ?
What are the others doing in such cases. Or am I the only one person
where has this special problem on the world. Becides I dont believe
in solving the problem through removing mentioned directory and
reinstalling. Nevertheless I will try it. I let you know about the result.
bye
sas

Response Time BPEL Fault

Similar Messages

Maybe you are looking for