High roll wait time
For my below crm transaction for a perticular user the response time is ~18000 ms out of which 15130 is roll time. Memory used is 16 MB.
"BSPWDWCC_SLS_HOME SAPMHTTP /sap/bc/bsp/sap/CRM_UI_PORTAL/B"
Roll time
Out 5 ms
In 5 ms
Wait 15,130 ms
Where is causing this roll wait ? What memory is not sufficient ? What to look at ?
In st02
roll buffer max used is 25% ,
page buffer max used is 10%.
EM max used 50%.
No swaps for above.
My user memory settings are as below:
ztta/roll_area 9000000
ztta/roll_first 1
ztta/roll_extension 4000000000
thank you
Laxmi
Thank you Shyam,Krishna.
I checked another similar instance again today with high wait time. Most of the time was wait time. There were NO RFC RECORD. just http record with most of it being on the server (Remote exec. time ~ 16 534 ms).
Now i assume calling time = gate way time + remote exec time. So as most of it was on the server I can rule out network.
I checked st03 and rfc times were really small. Also we have plenty of wps .. ~ 90. So not sure why still the high wait time. Also stad does not give any RFC record. If this was rfc will it now show up ?
I have given below the details. Am I missing some thing ?
Response time 16,546 ms
Wait for work process 5 ms
Processing time 1,155 ms
Load time 28 ms
Generating time 0 ms
Roll (in+wait) time 15,016 ms
Database request time 341 ms
Enqueue time 0 ms
Roll time Out 5 ms
In 3 ms
Wait 15,013 ms
NO RFC SUB RECORD
HTTP Records
as Server
Number Connections 1
Destinations 1
Calls 1
Time Calling 16,540 ms
Remote execution 16,534 ms
Idle 219 ms
HTTP Server connection record
Connection-Id 4B7CAADEF5DA00A7E10080000A68F456
Communication step Send/Receive
Timestamp 20100218 155216 EST
Host sappc003
Port 8031
Path /sap/bc/bsp/sap/crm_ui_frame/BSPWDApplication.do
Status phrase OK
Status code 200
Protocol HTTP
Method GET
Similar Messages
-
High roll wait time, gui time and processing time
Hi all,
We are having a performance issue with the system at the moment. After running ST03N and STAD, we have determined that we are having abnormally high roll-wait, GUI and processing times.
Here are some results from STAD:
CPU time: 2956ms
Processing time: 4417ms
Roll wait time: 1319ms
GUI Time: 2859ms
Can someone direct me towards finding the problem?
If you need more information please let me know. I would post a screenshot if I was able to.
Thanks,
HLHi,
Regarding Performance Of SAP system it will not be possible to Come to conclusion with the one Single data.
GUI time is basically the time spent in front end i.e Your Network load or such time
Coming to CPU time Can you see ST06 what is the CPU Utilization of your system?
Roll Wait time is the time Spent in buffer if you can share us the OS and Memory configuration.
We can Try to tune the Roll memory ( extended memory tuning) so that we can try to reduce the Roll time.
If possible try to find the Top Dialog Response Time Transaction Is it Standard or for Z Programs.
https://cw.sdn.sap.com/cw/docs/DOC-14387
Go through this link you might get clear idea of performance.
Thanks & Regards,
Balaji.S -
Exremely high (98%) roll wait time
I am running a ECC 6.0 EHP4 server in solaris 5.10 OS, Oracle 10.2.0.4.
My users experience extremely high roll wait time when they execute transactions like PA20/PA30. It took about 20 minutes for it to load.
I ran stad and found out the majority of the portion is wasted at roll wait time. How do we know what caused the wait time?
e.g. user execute TCODE PA20 and wait for the hourglass for about 20 minutes before the record is shown
Other transactions ran smoothly.
Your help is appreciated.After a RFC trace, it showed this RFC statement having very high duration:
RFC Statement
Function module name HTTP_GET
Source IP Address a.b.c.d
Source Server ourSECCServer
Destination IP Address a.b.c.d (same ip as source)
Destination Server ourSECCServer
Client/Server Client
Conversation ID
RFC Trace Rec. Status 4
Sent Bytes 9.476
Received Bytes 3.353
Total Sent Bytes
Total Received Bytes
ABAP program name SAPLSFTP
RFC Time 224881.681
Any ideas? -
Roll wait time very high.
Hi All,
We are facing a strange problem.
Our system is performing low just because of the share of high Roll Wait Time.
Can anyone tell why it is so high ? and how to reduce it's time.
Now it's taking more than 60% of Total Resp. Time.
Thanks & Regards,
Santosh RajputHi Santosh,
sometimes we have the same problem when inserting records with MM41. In ST03 Top Response Times the roll wait time takes nearly minutes, the whole response time 5 minutes.
The SAP HELP defines roll wait time as follows:
Wait time in the roll area.
If synchronous RFCs are called, the work process performs a roll out and waits for the end of the RFC in the roll area. The RFC server programs can wait for other RFCs to be sent to them in the roll area.
I'm not quite sure whether this explanation meets your or my problem because the problem occurs just two or three times a day. So - what is the process waiting for?
Can anybody help?
Thanks and best regards,
Frank Ihnen -
Relation between RFC time and Roll wait time
Hello
What is the relation between RFC time and Roll wait time?
In a diagram from E2E100 training I took recently the relationship is made out to be:
RFC+CPIC = some processing time + Roll wait time
Something like this
Processing----
Roll wait-------
Roll in
RFC+CPIC----
In the diagram I saw it shows that roll out occurs during processing.
Assumming that the user context rolls out and then rolls in again, wouldn't "Wait" time occur when the request comes back and the dispatcher has to assign the request to a work process?
Is this wait time calculated as "Wait" time or is it calculated as "Roll wait" time?
I was forced to think about this because of a STAD record I have with high Roll wait time, but with low RFC time as well as zero GUI time. If "Wait" time when the request comes back from RFC is included in "Roll wait" then it might explain what i'm seeing.
Kind regards,
PeterHello Santosh,
Thank you for your reply.
I would like to know how time spend in the dispatcher by a request coming back from an RFC is calculated.
When the RFC is made the user context is rolled out of the work process so the work process becomes free. When the RFC comes back it has to be assigned to a new work process. This means that a bit of time would need to be spent in the dispatcher. Would this time be measured as "wait" time or is it part of "Roll wait time?
From the definition you gave of "Roll wait time", "it is the time dedicated by the R/3 system to waiting for the return value of an RFC call plus the CPIC time required to create the connection for that RFC to an outside system", one would think that the time spent in the dispatcher by a returning RFC would be measured as "wait time" the same as when the dialog request first comes in from the front end. I've never seen a diagram that explained this satisfactorily.
Kind regards,
Peter -
Network/roll wait time is high
Hi,
One of my dialog instance is showing high response time at SMLG.
When i am checking Dialog Overview at RZ20, network response time of this server is very high.
When i am checking the parts of response time at ST03, roll wait time is always around 70% for this instance.
(4.7,2003 server, SQL 2000)
Kindly suggest me to resolve this.
Regards,
Gayathry.Hai,
Roll wait time means: During processing of some dialog steps, the user context may be rolled out; for example, during RFCs when the client is waiting for a response from the server. This wait time until the dialog step can continue is called the roll wait time.
try to check what RFC causes this, somtimes this may lead to rollfile overflow and in turn some background jobs might fail due to rollfile overflow.
Check SAP Notes:1100926 and 578118.
Regards,
Yoganand.V
Edited by: Yoganand Vedagiri on Mar 12, 2009 1:47 PM -
Long Roll-Wait time in SAP (ST03N)
Hello !
On my SAP-PRD, just registering long roll-wait times since almost 6 weeks !! Network diagnostics are normal ! Can somebody give me any hints to the issue !
Thanks in adv.
Kumar Mitra from Germany
====================Hai,
Check the below link.....
http://sap.ittoolbox.com/groups/technical-functional/sap-basis/high-rollwait-time-1514656?cv=expanded
http://www.saptechies.com/rfc-statistics-in-transactions-st03st03n-and-stad/
Roll wait time = time spent in roll context waiting for RFCs.
Also you can check tcode ST05 for RFC trace.
Regards,
Yoganand.V
Edited by: Yoganand Vedagiri on Feb 4, 2009 12:05 PM
Edited by: Yoganand Vedagiri on Feb 4, 2009 12:10 PM -
In t-code ST03N, there are following info:
1. Average Wait Time per Dialog Step (ms)
2. Average Roll In Time (ms)
3. Average Roll Wait Time (ms)
Question:
1. When will Roll Wait happen?
2. What is relationship between Wait Time and Roll Wait Time?
3. When dispatcher looking for free dialog wp, the dispatcher wait time occurs. From above two type of wait time, which one is dispatcher wait time?
Thanks.
JamesHi,
Read the OSS note which explains the decomposition of response time in detail...
Regards,
Olivier -
High PREEMPTIVE_SP_SERVER_DIAGNOSTICS wait time in sql server 2014 server
I am seeing high waittimes for PREEMPTIVE_SP_SERVER_DIAGNOSTICS and the server is runninf with high cpu.
What could have triggered this high waittime, how can this be fixed,
WaitType Wait_S
Resource_S Signal_S
WaitCount Percentage
AvgWait_S AvgRes_S
AvgSig_S
PREEMPTIVE_SP_SERVER_DIAGNOSTICS 1655043.72
1655043.72 0.00
4 39.75
413760.9305 413760.9305
0.0000
PREEMPTIVE_OS_PIPEOPS 935157.21
935157.21 0.00
343445 22.46
2.7229 2.7229
0.0000
CXPACKET 259912.58
250608.73 9303.85
25115286 6.24
0.0103 0.0100
0.0004
PAGEIOLATCH_SH 206350.14
205563.18 786.96
37649420 4.96
0.0055 0.0055
0.0000
SOS_SCHEDULER_YIELD 139263.91
2430.27 136833.63
293382681 3.35
0.0005 0.0000
0.0005Hello,
I remember I read a user complaining about high waits on PREEMPTIVE_SP_SERVER_DIAGNOSTICS when he installed CU5 for SQL
Server 2012 SP1, but in your scenario you have a SQL Server 2014 with CU1 (build 2342). I am treating this as a bug and that is the reason I would like you to consider applying CU5, the latest cumulative update, to see if that solves the issue.
http://support.microsoft.com/kb/3011055/en-us
This is the first time I read about this happening on SQL Server 2014 though.
I would like to suggest you to create a Connect item too, to see if the SQL Server team can suggest you another way to
treat this issue.
https://connect.microsoft.com/sqlServer/
Hope this helps.
Regards,
Alberto Morillo
SQLCoffee.com -
I have a SCCM 2012 SP1 CU4 environment with SCOM monitoring installed.
I also do have 4 secondary sites installed below my primary. The secondaries are using SQL 2012 Express version default deployed using the secondary site installation.
My SCOM monitoring is generating tickets with the following message:
The Average Wait Time of SQL instance "CONFIGMGRSEC" on computer "<SEC_SITE_SERVER>" is too high
How can i solve this ? Or do I need to ignore this ?Never ignore messages, but tune them.
In this specific case you might want to take a look at this:
http://social.technet.microsoft.com/Forums/en-US/ffeefe0d-0ef7-49a3-862e-9be27989dc5d/scom2012-alert-sql-2008-db-average-wait-time-recompilationis-too-high?forum=operationsmanagergeneral
My Blog: http://www.petervanderwoude.nl/
Follow me on twitter: pvanderwoude -
SCOM2012 Alert: SQL 2008 DB Average Wait Time & Recompilationis too high
WE have SCOM 2012sp1 CU3 updated.
I receive the below critical alerts from SQL servers continuously, please help me to resolve this issue.
SQL 2008 DB Average Wait Time is too high
SQL DB 2008 SQL Recompilation is too highI don't know about anyone else but overriding those monitors and rules didn’t work for me, I had to override<o:p></o:p>
SQL Re-Compilation monitor for SQL 2012 DB Engine<o:p></o:p>
SQL Re-Compilation monitor for SQL 2008 DB Engine<o:p></o:p>
Average Wait Time monitor for SQL 2012 DB<o:p></o:p>
Average Wait Time monitor for SQL 2008 DB<o:p></o:p>
Now I am wondering if other monitors are valid as well in particular I have multiple alerts for<o:p></o:p>
Buffer Cache Hit Ratio monitor for SQL 2008 DB Engine is too low<o:p></o:p>
Page Life Expectancy (s) for 2008 DB Engine is too low<o:p></o:p>
is anyone else seeing these issues as well? -
Deadlocks and very high wait times
We are seeing a very high number of deadlocks in the system. The deadlocks trace all show a 'enq: TX - row lock contention' with wait times of around 2929700+ seconds ex:
last wait for 'enq: TX - row lock contention' blocking sess=0x70000006d85e1b8 seq=55793 wait_time=2929704 seconds since wait started=4
name|mode=54580006, usn<<16 | slot=1d0010, sequence=705f
Dumping Session Wait History
for 'enq: TX - row lock contention' count=1 wait_time=2929704
name|mode=54580006, usn<<16 | slot=1d0010, sequence=705f
for 'latch: enqueue hash chains' count=1 wait_time=1649
address=70000006dbb4a20, number=13, tries=0
for 'enq: TX - row lock contention' count=1 wait_time=2929708
name|mode=54580006, usn<<16 | slot=1d0010, sequence=705f
for 'SQL*Net message from client' count=1 wait_time=101740
driver id=54435000, #bytes=1, =0
for 'SQL*Net message to client' count=1 wait_time=1
driver id=54435000, #bytes=1, =0
for 'direct path write temp' count=1 wait_time=921
file number=fb, first dba=6521b, block cnt=2
for 'SQL*Net more data from client' count=1 wait_time=3
driver id=54435000, #bytes=10, =0
for 'SQL*Net more data from client' count=1 wait_time=5
driver id=54435000, #bytes=1e, =0
for 'SQL*Net more data from client' count=1 wait_time=10
driver id=54435000, #bytes=2c, =0
for 'SQL*Net more data from client' count=1 wait_time=5
driver id=54435000, #bytes=3a, =0
Any ideas on how to resolve this ?
Thanks
SuryaSorry for the typo, that Ora-0060 error we are seeing. Here is the deadlock graph:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining Scoring Engine
and Real Application Testing options
ORACLE_HOME = /orasw/product/10.2.0.4.0
System name: AIX
Node name: spda5001
Release: 3
Version: 5
Machine: 00074D5AD400
Instance name: IAMS01P1
Redo thread mounted by this instance: 1
Oracle process number: 21
Unix process pid: 2306444, image: oracle@spda5001
*** 2011-12-24 05:05:39.885
*** SERVICE NAME:(IAMS01P) 2011-12-24 05:05:39.884
*** SESSION ID:(443.2130) 2011-12-24 05:05:39.884
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-00080020-000c3957 21 443 X 58 391 X
TX-001d0010-0000705f 58 391 X 21 443 X
session 443: DID 0001-0015-0000002E session 391: DID 0001-003A-00000081
session 391: DID 0001-003A-00000081 session 443: DID 0001-0015-0000002E
Rows waited on:
Session 391: obj - rowid = 0001098B - AAATtpAAGAAADROAAD
(dictionary objn - 67979, file - 6, block - 13390, slot - 3)
Session 443: obj - rowid = 00010B25 - AAARRwAAGAAAAdgAAN
(dictionary objn - 68389, file - 6, block - 1888, slot - 13)
Information on the OTHER waiting sessions:
Session 391:
pid=58 serial=16572 audsid=52790041 user: 93/IAMS_USR
O/S info: user: , term: , ospid: 1234, machine: mac3023
program:
Current SQL Statement:
update spt_identity set created=:1, modified=:2, owner=:3, assigned_scope=:4, assigned_scope_path=:5, extended1=:6, extended2=:7, extended3=:8, extended4=:9, extended5=:10, extended6=:11, extended7=:12, extended8=:13, extended9=:14, extended10=:15, extended11=:16, extended12=:17, extended13=:18, extended14=:19, extended15=:20, extended16=:21, extended17=:22, extended18=:23, extended19=:24, extended20=:25, name=:26, description=:27, protected=:28, iiqlock=:29, attributes=:30, manager=:31, display_name=:32, firstname=:33, lastname=:34, email=:35, manager_status=:36, inactive=:37, last_login=:38, last_refresh=:39, password=:40, password_expiration=:41, password_history=:42, bundle_summary=:43, assigned_role_summary=:44, correlated=:45, auth_question_lock_start=:46, failed_auth_question_attempts=:47, controls_assigned_scope=:48, certifications=:49, activity_config=:50, preferences=:51, history=:52, scorecard=:53, uipreferences=:54, attribute_meta_data=:55, workgroup=:56 where id=:57
End of information on OTHER waiting sessions.
Current SQL statement for this session:
update spt_workflow_case set created=:1, modified=:2, owner=:3, assigned_scope=:4, assigned_scope_path=:5, stack=:6, attributes=:7, launcher=:8, host=:9, launched=:10, completed=:11, progress=:12, percent_complete=:13, type=:14, messages=:15, name=:16, description=:17, complete=:18, target_class=:19, target_id=:20, target_name=:21, workflow=:22 where id=:23 -
Hello,
Our DB is having very high redo log space wait time :
redo log space requests 867527
redo log space wait time 67752674
LOG_BUFFER is 14 MB and having 6 redo logs groups and the size of redo log file is 500MB for each log file.
Also, the amount of redo generated per hour :
START_DATE START NUM_LOGS MBYTES DBNAME
2008-07-03 10:00 2 1000 TKL
2008-07-03 11:00 4 2000 TKL
2008-07-03 12:00 3 1500 TKL
Does increasing the size of LOG_BUFFER will help to reduce the redo log space wait ?
Thanks in advance ,
Regards,
AmanLooking quickly over the AWR report provided the following information could be helpful:
1. You are currently targeting approx. 6GB of memory with this single instance and the report tells that physical memory is 8GB. According to the advisories it looks like you could decrease your memory allocation without tampering your performance.
In particular the large_pool_size setting seems to be quite high although you're using shared servers.
Since you're using 10.2.0.4 it might be worth to think about using the single SGA_TARGET parameter instead of the specifying all the single parameters. This allows Oracle to size the shared pool components within the given target dynamically.
2. You are currently using a couple of underscore parameters. In particular the "_optimizer_max_permutations" parameter is set to 200 which might reduce significantly the number of execution plans permutations Oracle is investigating while optimizing the statement and could lead to suboptimal plans. It could be worth to check why this has been set.
In addition you are using a non-default setting of "_shared_pool_reserved_pct" which might no longer be necessary if you are using the SGA_TARGET parameter as mentioned above.
3. You are using non-default settings for the "optimizer_index_caching" and "optimizer_index_cost_adj" parameters which favor index-access paths / nested loops. Since the "db file sequntial read" is the top wait event it might be worth to check if the database is doing too excessive index access. Also most of the rows have been fetched by rowid (table fetch by rowid) which could also be an indicator for excessive index access/nested loop usage.
4. You database has been working quite a lot during the 30min. snapshot interval: It processed 123.000.000 logical blocks, which means almost 0.5GB per second. Check the top SQLs, there are a few that are responsible for most of the blocks processed. E.g. there is a anonymous PL/SQL block that has been executed almost 17.000 times during the interval representing 75% of the blocks processed. The statements executed as part of these procedures might be worth to check if they could be tuned to require less logical I/Os. This could be related to the non-default optimizer parameters mentioned above.
5. You are still using the compatible = 9.2.0 setting which means this database could still be opened by a 9i instance. If this is no longer required, you might lift this to the default value of 10g. This will also convert the REDO format to 10g I think which could lead to less amount of redo generated. But be aware of the fact that this is a one-way operation, you can only go back to 9i then via a restore once the compatible has been set to 10.x.
6. Your undo retention is set quite high (> 6000 secs), although your longest query in the AWR period was 151 seconds. It might be worth to check if this setting is reasonable, as you might have quite a large undo tablespace at present. Oracle 10g ignores the setting if it isn't able to honor the setting given the current Undo tablespace size.
7. "parallel_max_servers" has been set to 0, so no parallel operations can take place. This might be intentional but it's something to keep in mind.
Regards,
Randolf
Oracle related stuff:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
High Enqueue Waits in Statspack Report
Hi Everybody,
Oracle Version:Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
OS:Solaris 64 bit
Statspack Report is showing High Enqueue Waits
Here is a Snapshot.....
STATSPACK report for
DB Name DB Id Instance Inst Num Release Cluster Host
XXXXX 434917312 XXXXX 1 9.2.0.7.0 NO INgenius1
Snap Id Snap Time Sessions Curs/Sess Comment
Begin Snap: 1064 24-Sep-08 06:00:01 1,333 19.6
End Snap: 1065 24-Sep-08 07:00:01 1,344 19.7
Elapsed: 60.00 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 1,152M Std Block Size: 8K
Shared Pool Size: 752M Log Buffer: 1,536K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 27,771.53 1,196.23
Logical reads: 777.20 33.48
Block changes: 180.58 7.78
Physical reads: 33.25 1.43
Physical writes: 7.51 0.32
User calls: 76.89 3.31
Parses: 23.29 1.00
Hard parses: 0.27 0.01
Sorts: 0.42 0.02
Logons: 0.05 0.00
Executes: 88.69 3.82
Transactions: 23.22
% Blocks changed per Read: 23.23 Recursive Call %: 61.50
Rollback per transaction %: 0.00 Rows per Sort: 738.76
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 96.90 In-memory Sort %: 99.67
Library Hit %: 99.76 Soft Parse %: 98.84
Execute to Parse %: 73.74 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 94.38 % Non-Parse CPU: 94.45
Shared Pool Statistics Begin End
Memory Usage %: 86.56 87.54
% SQL with executions>1: 50.57 63.10
% Memory for SQL w/exec>1: 10.02 14.63
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
enqueue 19,553 57,405 98.39
db file sequential read 44,161 384 .66
CPU time 333 .57
log file parallel write 166,602 82 .14
log file sync 67,683 71 .12
Wait Events for DB: XXXXX Instance: XXXXX Snaps: 1064 - 1065
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
enqueue 19,553 19,540 57,405 2936 0.2
db file sequential read 44,161 0 384 9 0.5
log file parallel write 166,602 0 82 0 2.0
log file sync 67,683 0 71 1 0.8
db file scattered read 6,676 0 54 8 0.1
db file parallel write 1,135 0 7 6 0.0
direct path read 1,117 0 3 3 0.0
SQL*Net more data to client 3,932 0 2 0 0.0
control file parallel write 1,200 0 2 1 0.0
control file sequential read 1,389 0 1 1 0.0
PX Deq: Execute Reply 112 0 0 4 0.0
direct path write 752 0 0 1 0.0
db file parallel read 9 0 0 42 0.0
Background Wait Events for DB: XXXXX Instance: XXXXX Snaps: 1064 - 10
-> ordered by wait time desc, waits desc (idle events last)
Avg Wt Wait
Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
TC 25 24 0 4 32.00 0
TX 84,615 84,605 0 3 8.33 0
HW 118 118 0 2 2.00 0
PS 29 25 4 2 1.00 0
Here frm Statspack Report we can see that enqueue type- TX is taking up most of the resources.......
I want to find out which sql statements are causing this high enqueue waits......
Any Help Appreciated....
Regards,
Prosenjit MukherjeeHi All,
Here is the Statspack Report..........
STATSPACK report for
DB Name DB Id Instance Inst Num Release Cluster Host
XXXXX 434917312 XXXXX 1 9.2.0.7.0 NO XXXXXxxx1
Snap Id Snap Time Sessions Curs/Sess Comment
Begin Snap: 1064 24-Sep-08 06:00:01 1,333 19.6
End Snap: 1065 24-Sep-08 07:00:01 1,344 19.7
Elapsed: 60.00 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 1,152M Std Block Size: 8K
Shared Pool Size: 752M Log Buffer: 1,536K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 27,771.53 1,196.23
Logical reads: 777.20 33.48
Block changes: 180.58 7.78
Physical reads: 33.25 1.43
Physical writes: 7.51 0.32
User calls: 76.89 3.31
Parses: 23.29 1.00
Hard parses: 0.27 0.01
Sorts: 0.42 0.02
Logons: 0.05 0.00
Executes: 88.69 3.82
Transactions: 23.22
% Blocks changed per Read: 23.23 Recursive Call %: 61.50
Rollback per transaction %: 0.00 Rows per Sort: 738.76
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 96.90 In-memory Sort %: 99.67
Library Hit %: 99.76 Soft Parse %: 98.84
Execute to Parse %: 73.74 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 94.38 % Non-Parse CPU: 94.45
Shared Pool Statistics Begin End
Memory Usage %: 86.56 87.54
% SQL with executions>1: 50.57 63.10
% Memory for SQL w/exec>1: 10.02 14.63
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
enqueue 19,553 57,405 98.39
db file sequential read 44,161 384 .66
CPU time 333 .57
log file parallel write 166,602 82 .14
log file sync 67,683 71 .12
Wait Events for DB: XXXXX Instance: XXXXX Snaps: 1064 - 1065
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
enqueue 19,553 19,540 57,405 2936 0.2
db file sequential read 44,161 0 384 9 0.5
log file parallel write 166,602 0 82 0 2.0
log file sync 67,683 0 71 1 0.8
db file scattered read 6,676 0 54 8 0.1
db file parallel write 1,135 0 7 6 0.0
direct path read 1,117 0 3 3 0.0
SQL*Net more data to client 3,932 0 2 0 0.0
control file parallel write 1,200 0 2 1 0.0
control file sequential read 1,389 0 1 1 0.0
PX Deq: Execute Reply 112 0 0 4 0.0
direct path write 752 0 0 1 0.0
db file parallel read 9 0 0 42 0.0
process startup 6 0 0 44 0.0
SQL*Net break/reset to clien 296 0 0 1 0.0
PX Deq: Signal ACK 3 1 0 33 0.0
latch free 17 4 0 3 0.0
LGWR wait for redo copy 286 0 0 0 0.0
PX Deq: Join ACK 3 0 0 2 0.0
PX Deq: Parse Reply 4 0 0 1 0.0
buffer busy waits 12 0 0 0 0.0
PX Deq Credit: need buffer 4 0 0 0 0.0
PX Deq: Table Q Sample 1 0 0 0 0.0
SQL*Net message from client 204,628 0 4,620,111 22578 2.4
virtual circuit status 120 120 3,516 29297 0.0
PX Idle Wait 753 749 1,470 1953 0.0
SQL*Net more data from clien 20,540 0 3 0 0.2
PX Deq: Execution Msg 128 0 2 13 0.0
SQL*Net message to client 204,628 0 0 0 2.4
Background Wait Events for DB: XXXXX Instance: XXXXX Snaps: 1064 - 10
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
log file parallel write 166,634 0 82 0 2.0
db file parallel write 1,134 0 8 7 0.0
control file parallel write 1,200 0 2 1 0.0
control file sequential read 1,327 0 1 1 0.0
db file scattered read 44 0 0 10 0.0
db file sequential read 25 0 0 3 0.0
direct path read 23 0 0 3 0.0
rdbms ipc reply 67 0 0 0 0.0
LGWR wait for redo copy 286 0 0 0 0.0
direct path write 23 0 0 0 0.0
buffer busy waits 2 0 0 0 0.0
rdbms ipc message 86,933 3,437 20,199 232 1.0
pmon timer 1,194 1,194 3,504 2935 0.0
smon timer 17 8 3,239 ###### 0.0
Enqueue activity for DB: XXXXX Instance: XXXXX Snaps: 1064 - 1065
-> Enqueue stats gathered prior to 9i should not be compared with 9i data
-> ordered by Wait Time desc, Waits desc
Avg Wt Wait
Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
TC 25 24 0 4 32.00 0
TX 84,615 84,605 0 3 8.33 0
HW 118 118 0 2 2.00 0
PS 29 25 4 2 1.00 0
End of Report (this is not the entire report,only posted part of it,getting error page when trying to post the entire report)
Regards,
Prosenjit Mukherjee -
I was always under the impression that Wait Timers (e.g. Wait and Wait Ms Multiple) always executed last within a while loop. As I'm reading up on timing of real-time loops I'm finding that NI suggested using a stacked sequence structure to force timing to run last. Has my assumption of wait timer execution been wrong all this time or do PC and RT systems differ in how loops handle timing?
Thanks,
CraigSo, ok, coming back on this.
Attached you find a small example to show my remarks in the previous post.
How to use it:
The main focus is in the first iterations once "Wait now!" is pressed. So it is usually not of interest to run the "waiting" for more than 5-10 iterations.
In order to see an "understandable" behavior, i suggest to wait at least 100ms. I configured "Time To Wait" to be at least 10 (coercing).
The second focus is "Time Value".
For "Wait (ms)", the "Time Value" will have any number, but increase each iteration by the amount of "Time To Wait".
For "Wait Until Next Multiple (ms)", "Time Value" will be initialized to a value, which is a integer multiple of the "Time To Wait" and will increase each iteration to the next multiple.
My example does not contain parallel code, so it does not show the parallelism of the waiting functions!
Nevertheless, understanding the shown behavior is the key. Because if the code running in parallel to the waiting requires less execution time than the wait function will wait, the behavior will be exactly as shown.
If the parallel code requires more execution time than the waiting, "Wait (ms)" is already finished and therefore the loop will immediatly continue with the next iteration (high CPU load!).
If the parallel code requires more execution time than the waiting, "Wait Until Nexty Multiple (ms)" will wait that long that the "Time Value" is again in line to an integer multiple of the "Time To Wait" (so this one keeps on running in parallel until waiting time is calculated and over). Hence, "Wait Until Next Multiple" will still introduce a waiting time (reduced CPU load), but you will "miss complete iteration slots".
As you can see, using a single "Wait Until Next Multiple" outside the loop for initialization can make sense if the first iteration should also have a "close to normal" execution time.
Please note that the Timed Loop does something similar once started. As it does it during the iterations, the first 1-3 iteration(s) are called "warmup iterations". Most often, the first single iteration is sufficient for this though....
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Attachments:
TimingVI_Behavior_2011.vi 29 KB
Maybe you are looking for
-
What is the best way to connect macbook to hd tv?
right now i'm using kanex minidisplay port to hdmi adapter. Just wondering if there is a better way to connect to a hdtv. mostly for watching movies.
-
SAP ECC 6.0 file system Restore
Dear Friends, Happy Holi. I have restore file system backup of our development server to another host having oracle 10g and ECC 6.0. After restore database has been up successfully. But listner is not running when I trid to run listner it is giving t
-
How to make Finder use a copied .DS_Store file?
Hi, since the Finder still does not allow applying view options to multiple folders I tried, yet again, to do this manually: Create folder A and populate with stuff Create folder B and populate with stuff Verify that both folders use the system defau
-
Hi, When i am enterying vendor invoice and customer invoice then i am getting following error. Item category 04000 not allowed in accounting transaction 0200/0001 Message no. GLT2001 Diagnosis The online document splitting is active in your system. H
-
Need cvuqdisk rpm package for oracle 10.2.0.1 on IBM PPC..
I need the cvuqdisk rpm package for IBM PPC running Redhat. It is not in the Oracle distro that was downloaded from Oracles site.