Performance problem on wait event PX Deq: Execute Reply
Hi everybody
I encounter some performance problem, I've made a tkprof on a select statement and I saw that more than 95% of the elapsed time is due to event PX Deq: Execute Reply.
This request is not CPU or paging consuming. What is this event and how could I reduce it ? Could it be a disk problem ?
Thanks a lot, best regards
Greg
Here is a sample of my tkprof:
call count cpu elapsed disk query current rows
Parse 1 0.03 0.03 0 0 0 0
Execute 1 0.22 2.16 68 177 12 0
Fetch 2 0.17 511.97 38 40 0 1
total 4 0.42 514.16 106 217 12 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 38
Rows Row Source Operation
1 PX COORDINATOR (cr=202 pr=103 pw=0 time=513984636 us)
0 PX SEND QC (RANDOM) :TQ10003 (cr=0 pr=0 pw=0 time=0 us)
0 HASH GROUP BY (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
0 PX SEND HASH :TQ10002 (cr=0 pr=0 pw=0 time=0 us)
0 HASH GROUP BY (cr=0 pr=0 pw=0 time=0 us)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
0 PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us)
473 TABLE ACCESS FULL DIM_CALL_DISTANCE (cr=8 pr=7 pw=0 time=27259 us)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
0 PX SEND BROADCAST :TQ10001 (cr=0 pr=0 pw=0 time=0 us)
4 TABLE ACCESS FULL DIM_AUDIT_CALL (cr=32 pr=31 pw=0 time=35037 us)
0 PX BLOCK ITERATOR PARTITION: 1 16 (cr=0 pr=0 pw=0 time=0 us)
0 TABLE ACCESS FULL FACT_CALL PARTITION: 1 48 (cr=0 pr=0 pw=0 time=0 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 67 0.05 0.95
os thread startup 4 0.21 0.80
PX Deq: Join ACK 4 0.00 0.00
PX Deq: Parse Reply 3 0.13 0.17
SQL*Net message to client 2 0.00 0.00
PX Deq: Execute Reply 304 1.96 511.68
db file scattered read 6 0.01 0.03
PX qref latch 12 0.00 0.00
SQL*Net message from client 2 94.93 94.94
PX Deq: Signal ACK 6 0.10 0.11
enq: PS - contention 1 0.00 0.00
********************************************************************************
PX Deq: Execute Reply is an idle event associated with Parallel Query. Are your tables partitioned or have a degree greater then 1?
The tables appear to be small in size. The overhead associated with parallel query generally hinders response time on queries involving small tables.
Similar Messages
-
PX Deq: Execute Reply - Wait event
I am seeing PX Deq: Execute Reply wait event for a query which returns no data. From metalink I see this can be ignored.
Any suggestion is appreciated.I am attaching explain plan. Not sure if this helps. Another prod database which has similiar plan works fine.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=205424 Card=1 Bytes=
142)
1 0 TABLE ACCESS* (BY INDEX ROWID) OF 'STG_TRD_SWAP_CF' (Cost= :Q804383
4 Card=1 Bytes=82) 001
2 1 NESTED LOOPS* (Cost=205424 Card=1 Bytes=142) :Q804383
001
3 2 HASH JOIN* (Cost=59005 Card=146419 Bytes=8785140) :Q804383
001
4 3 NESTED LOOPS* (Cost=3 Card=1 Bytes=25) :Q804383
000
5 4 VIEW (Cost=2 Card=1 Bytes=13)
6 5 SORT (AGGREGATE)
7 6 INDEX (FULL SCAN (MIN/MAX)) OF 'T_HUB_CONTROL_
TRADE_HDR_PK' (UNIQUE) (Cost=2 Card=579 Bytes=2316)
8 4 TABLE ACCESS (BY INDEX ROWID) OF 'T_HUB_CONTROL_TR
ADE_HDR' (Cost=1 Card=1 Bytes=12)
9 8 INDEX (UNIQUE SCAN) OF 'T_HUB_CONTROL_TRADE_HDR_
PK' (UNIQUE)
10 3 PARTITION RANGE* (ALL) :Q804383
001
11 10 PARTITION LIST* (ALL) :Q804383
001
12 11 TABLE ACCESS* (FULL) OF 'T_HUB_TRD_MAIN' (Cost=5 :Q804383
9002 Card=84630120 Bytes=2962054200) 001
13 2 INDEX* (RANGE SCAN) OF 'STG_TRD_SWAP_CF_PK' (UNIQUE) ( :Q804383
Cost=3 Card=1) 001
1 PARALLEL_COMBINED_WITH_CHILD
2 PARALLEL_TO_SERIAL SELECT /*+ ORDERED NO_EXPAND USE_NL(A2) INDE
X(A2 "STG_TRD_SWAP_CF_PK") */ A1.C0,
3 PARALLEL_COMBINED_WITH_PARENT
4 PARALLEL_FROM_SERIAL
10 PARALLEL_COMBINED_WITH_PARENT
11 PARALLEL_COMBINED_WITH_PARENT
12 PARALLEL_COMBINED_WITH_PARENT
13 PARALLEL_COMBINED_WITH_PARENT -
Wait event PX Deq: reap credit in Oracle 9.2.0.8
Hi,
Can you please explain me what does mean by "PX Deq: reap credit" wait event. My session is waiting on this event. Can you please suggest how to reduce this wait.
ThanksHi
oratst@ebsdevdb on /ebdbh/11g/data/cfgtoollogs/dbua/ebstest/upgrade1 # more Upgrade_Directive.log
Connected.
ODMA_DIRECTIVE:VERSION:9.2.0.8
ODMA_DIRECTIVE:MIGRATE_SID:
ODMA_DIRECTIVE:ORA:IGNORE:06512:
ODMA_DIRECTIVE:ORA:FATAL:00600:
ODMA_DIRECTIVE:ORA:FATAL:01012:
ODMA_DIRECTIVE:ORA:FATAL:01031:
ODMA_DIRECTIVE:ORA:FATAL:01034:
ODMA_DIRECTIVE:ORA:FATAL:01078:
ODMA_DIRECTIVE:ORA:FATAL:01092:
ODMA_DIRECTIVE:ORA:FATAL:01109:
ODMA_DIRECTIVE:ORA:FATAL:01119:
ODMA_DIRECTIVE:ORA:FATAL:01507:
ODMA_DIRECTIVE:ORA:FATAL:01722:
ODMA_DIRECTIVE:ORA:FATAL:03113:
ODMA_DIRECTIVE:ORA:FATAL:03114:
ODMA_DIRECTIVE:ORA:FATAL:07445:
ODMA_DIRECTIVE:ORA:FATAL:12560:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01650:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01651:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01652:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01653:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01654:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01655:
ODMA_DIRECTIVE:ORA:RECOVER_ROLL:01562:
ODMA_DIRECTIVE:ORA:RECOVER_INIT:04031:
ODMA_DIRECTIVE:SCRIPT:UPGRADE:rdbms/admin/catupgrd.sql:
ODMA_DIRECTIVE:BOUNCE_DATABASE:UPGRADE:
ODMA_DIRECTIVE:SCRIPT:UPGRADE:rdbms/admin/catuppst.sql:
ODMA_DIRECTIVE:SCRIPT:UPGRADE:sqlplus/admin/help/hlpbld.sql helpus.sql:
Thanks
With Regards
A-Z -
Hi,
Statspack report me that on our database, there is wait event about this PX Deq :
PX Deq: Table Q Normal
PX Deq: Execute Reply
PX Deq Credit: send blkd
What is this exactly ?
Nicolas.Here is some additional info from metalink.
PX Deq: Table Q Normal
Indicates that the slave wait for data to arrive on its input table queue.
In a parallel execution environment we have a producer consumer model.
One slave set works on the data ( e.g. read data from disk , do a join )
called the produces slave set and the other slave set waits to get the data
that the can start the work. The slaves in this slave set are called consumer.
The wait event "PX Deq: Table Q Normal" means that the slaves in the consumer
slave have to wait for rows( data ) from the other slave set that they can
start there work.
PX Deq: Execute Reply
The QC is expecting a response (acknowledgement) to a control message
from the slaves or is expecting to dequeue data from the producer slave set.
This means he waits that the slaves finished to execute the SQL statement
and that they send the result of the query back to the QC. -
Hello SAP Community,
I start by mentioning a few details about the system I'll be talking about in this subject:
- SAP NetWeaver 7.0
- Oracle Database 10.2g
I was reading the following Note: "Note 618868 - FAQ: Oracle performance", in order to try to understand what's causing the oracle database to have slow performance.
While reading section 3 "How can I determine whether the general database performance can be optimized?" I found out that the ratio of "Busy wait time to CPU time" is away above the recommended 60:40 value. I'm getting a 94:6 ratio. This value was calculated using the query:
SELECT
ROUND((STM1.VALUE - STM2.VALUE) / 1000000) "BUSY WAIT TIME (S)",
ROUND(STM2.VALUE / 1000000) "CPU TIME (S)",
ROUND((STM1.VALUE - STM2.VALUE) / STM1.VALUE * 100) || ' : ' ||
ROUND(STM2.VALUE / STM1.VALUE * 100) RATIO
FROM V$SYS_TIME_MODEL STM1, V$SYS_TIME_MODEL STM2
WHERE STM1.STAT_NAME = 'DB time' AND STM2.STAT_NAME = 'DB CPU';
With such high values, SAP recommends to improve system performance doing some "wait event tuning".
Can someone give me some directions about this subject? Some guides specific to this subject would be nice. Any further information about my system you may require, please ask me.
Thanks in advance.
Best regards,
Daniel GarridoHello again,
Before I did any changes to the Oracle's parameters I checked the Note 619188 - FAQ: Oracle wait events, to understand what could be causing such high event wait time.
With the query:
SELECT EVENT, TOTAL_WAITS, TIME_WAITED, AVG_MS,
ROUND(RATIO_TO_REPORT(TIME_WAITED) OVER () * 100) PERCENT
FROM (SELECT SUBSTR(EVENT, 1, 30) EVENT, TOTAL_WAITS, TIME_WAITED,
ROUND(TIME_WAITED_MICRO / TOTAL_WAITS / 1000, 2) AVG_MS
FROM V$SYSTEM_EVENT
WHERE WAIT_CLASS NOT IN ('Idle', 'System I/O')
UNION
SELECT 'CPU' EVENT, NULL, VALUE, NULL
FROM V$SYSSTAT
WHERE STATISTIC# = 12
ORDER BY 3 DESC)
WHERE ROWNUM <=10;
I got the non-idle events that took more time in my system and the result was:
Result of the SELECT statement
EVENT
TOTAL_WAITS
TIME_WAITED
AVG_MS
PERCENT
log file switch (archiving nee
578.686
57.850.863
999.69
80
buffer busy waits
712.163
6.420.932
90.16
9
CPU
0
2.791.238
4
db file sequential read
4.005.546
1.746.442
4.36
2
log file sync
10.176.490
1.577.177
1.55
2
enq: TX - row lock contention
854.451
642.955
7.52
1
db file scattered read
1.055.533
621.332
5.89
1
enq: CF - contention
210.085
246.910
11.75
0
read by other session
561.558
119.910
2.14
0
log file switch completion
10.777
85.843
79.65
0
So most of the TIME_WAITED for wait events was because of the "log file switch (archiving needed)", after reading what could cause such wait event, I understood this was related with a problem I previously had in the server, where the archiving folder was with no space left. (Meanwhile the backup of the archives is being done and so the folder is being cleaned on a daily basis).
Thank you all for your help! -
Hi,
in my top evens i've:
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
CPU time 1,894 36.1
log file sync 36,862 1,008 27 19.2 Commit
db file scattered read 165,508 970 6 18.5 User I/O
db file sequential read 196,596 857 4 16.3 User I/O
log file parallel write 35,847 565 16 10.8 System I/O
Log file are on a separate disks, with no activity, only 1 redo per group, and 4 groups.
I think that 27ms for log file synch is high.
I raised commits in sqlloader putting rows=100000 instead 30000 but it's always high.
Which check i can perform?
I'm on AIX 5.3 and database in 10.2.0.4.4Log File Sync
The “log file sync” wait event is triggered when a user session issues a commit (or a rollback). The user session will signal or post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session. The wait is entirely dependent on LGWR to write out the necessary redo blocks and send confirmation of its completion back to the user session. The wait time includes the writing of the log buffer and the post, and is sometimes called “commit latency”.
The P1 parameter in <View:V$SESSION_WAIT> is defined as follows for this wait event:
P1 = buffer#
All changes up to this buffer number (in the log buffer) must be flushed to disk and the writes confirmed to ensure that the transaction is committed and will be kept on an instance crash. The wait is for LGWR to flush up to this buffer#.
Reducing Waits / Wait times:
If a SQL statement is encountering a significant amount of total time for this event, the average wait time should be examined. If the average wait time is low, but the number of waits is high, then the application might be committing after every row, rather than batching COMMITs. Applications can reduce this wait by committing after “n” rows so there are fewer distinct COMMIT operations. Each commit has to be confirmed to make sure the relevant REDO is on disk. Although commits can be "piggybacked" by Oracle, reducing the overall number of commits by batching transactions can be very beneficial.
If the SQL statement is a SELECT statement, review the Oracle Auditing settings. If Auditing is enabled for SELECT statements, Oracle could be spending time writing and commit data to the AUDIT$ table.
If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same
If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same buffer# then the SEQ# column of V$SESSION_WAIT should increment every second. If not then the local session has a problem with wait event timeouts. If the SEQ# column is incrementing then the blocking process is the LGWR process. Check to see what LGWR is waiting on as it may be stuck. If the waits are because of slow I/O, then try the following:
Reduce other I/O activity on the disks containing the redo logs, or use dedicated disks.
Try to reduce resource contention. Check the number of transactions (commits + rollbacks) each second, from V$SYSSTAT.
Alternate redo logs on different disks to minimize the effect of the archiver on the log writer.
Move the redo logs to faster disks or a faster I/O subsystem (for example, switch from RAID 5 to RAID 1).
Consider using raw devices (or simulated raw devices provided by disk vendors) to speed up the writes.
See if any activity can safely be done with NOLOGGING / UNRECOVERABLE options in order to reduce the amount of redo being written.
See if any of the processing can use the COMMIT NOWAIT option (be sure to understand the semantics of this before using it).
Check the size of the log buffer as it may be so large that LGWR is writing too many blocks at one time. -
How to see the wait events info. after excute a select query
Hi
How to see the wait events info. after execute a select query. Are there any parameter to set for this option?
And also wanna see the follwing info. in trace file. For this what are the parameters I have to set right?
SELECT * FROM emp, dept
WHERE emp.deptno = dept.deptno;
call count cpu elapsed disk query current rows
Parse 1 0.16 0.29 3 13 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.03 0.26 2 2 4 14
Misses in library cache during parse: 1
Parsing user id: (8) SCOTT Regards
Arpitha$ sqlplus scott/tiger
SQL*Plus: Release 10.2.0.2.0 - Production on Wed Apr 20 15:29:33 2011
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> SHOW PARAMETER dump
NAME TYPE VALUE
background_core_dump string partial
background_dump_dest string /user/oracle/app/oracle/admin/
orclsb/bdump
core_dump_dest string /user/oracle/app/oracle/admin/
orclsb/cdump
max_dump_file_size string UNLIMITED
shadow_core_dump string partial
user_dump_dest string /user/oracle/app/oracle/admin/
orclsb/udump
SQL> ALTER SESSION SET EVENTS='10046 trace name context forever, level 12';
Session altered.
SQL> SELECT * FROM emp WHERE deptno=20;
EMPNO ENAME JOB MGR HIREDATE SAL COMM
DEPTNO
7369 SMITH CLERK 7902 17-DEC-80 800
20
7566 JONES MANAGER 7839 02-APR-81 2975
20
7788 SCOTT ANALYST 7566 19-APR-87 3000
20
EMPNO ENAME JOB MGR HIREDATE SAL COMM
DEPTNO
7876 ADAMS CLERK 7788 23-MAY-87 1100
20
7902 FORD ANALYST 7566 03-DEC-81 3000
20Now
$ pwd
/user/oracle/app/oracle/admin/orclsb/udump
$ ls -ltr|tail -5
-rw-r----- 1 oracle oinstall 622 Apr 20 11:35 orclsb_ora_949.trc
-rw-r----- 1 oracle oinstall 651 Apr 20 11:35 orclsb_ora_976.trc
-rw-r----- 1 oracle oinstall 1982 Apr 20 11:35 orclsb_ora_977.trc
-rw-r----- 1 oracle oinstall 1443 Apr 20 15:29 orclsb_ora_1251.trc
-rw-r----- 1 oracle oinstall 279719 Apr 20 15:30 orclsb_ora_1255.trc
$ tkprof orclsb_ora_1255.trc orclsb_ora_1255.txt
TKPROF: Release 10.2.0.2.0 - Production on Wed Apr 20 15:32:17 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
$ ls -ltr|tail -5
-rw-r----- 1 oracle oinstall 651 Apr 20 11:35 orclsb_ora_976.trc
-rw-r----- 1 oracle oinstall 1982 Apr 20 11:35 orclsb_ora_977.trc
-rw-r----- 1 oracle oinstall 1443 Apr 20 15:29 orclsb_ora_1251.trc
-rw-r----- 1 oracle oinstall 279719 Apr 20 15:30 orclsb_ora_1255.trc
-rw-r--r-- 1 oracle oinstall 26872 Apr 20 15:32 orclsb_ora_1255.txtThis orclsb_ora_1255.txt contains the required information. -
Performance problem - event : cursor: pin S wait on X
Hi,
Bellow is 17 min awr report , of oracle PeopleSoft DB on 10204 instance on HPUX machine.
During this time the customers complained on poor performance.
There were 4,104.23 execution per second and 3,784.95 parses
which mean that almost any statment was parsed. since the Soft Parse %= 99.77
its seems that most of the parses are soft parse.
During those 17 min , the DB Time = 721.74 min and the "Top 5 Timed Events"
shows : "cursor: pin S wait on X" at the top of the Timed Events
Attached some details for the awr report
Could you please suggest where to focus ?
Thanks
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst Num Release RAC Host
xxxx 2993006132 xxxx 1 10.2.0.4.0 NO xxxx
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 18085 25-Mar-10 10:30:41 286 14.9
End Snap: 18086 25-Mar-10 10:48:39 301 15.1
Elapsed: 17.96 (mins)
DB Time: 721.74 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 4,448M 4,368M Std Block Size: 8K
Shared Pool Size: 2,736M 2,816M Log Buffer: 2,080K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 3,831,000.13 271,096.84
Logical reads: 164,733.47 11,657.20
Block changes: 17,757.42 1,256.59
Physical reads: 885.19 62.64
Physical writes: 504.92 35.73
User calls: 5,775.09 408.67
Parses: 3,784.95 267.84
Hard parses: 8.55 0.60
Sorts: 212.37 15.03
Logons: 0.77 0.05
Executes: 4,104.23 290.43
Transactions: 14.13
% Blocks changed per Read: 10.78 Recursive Call %: 24.14
Rollback per transaction %: 0.18 Rows per Sort: 57.86
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.98 Redo NoWait %: 99.97
Buffer Hit %: 99.47 In-memory Sort %: 100.00
Library Hit %: 99.73 Soft Parse %: 99.77
Execute to Parse %: 7.78 Latch Hit %: 99.77
Parse CPU to Parse Elapsd %: 3.06 % Non-Parse CPU: 89.23
Shared Pool Statistics Begin End
Memory Usage %: 34.44 34.78
% SQL with executions>1: 76.52 60.40
% Memory for SQL w/exec>1: 73.75 99.18
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
cursor: pin S wait on X 1,378,354 13,462 10 31.1 Concurrenc
db file sequential read 878,684 8,779 10 20.3 User I/O
CPU time 4,998 11.5
local write wait 2,692 2,442 907 5.6 User I/O
cursor: pin S 1,932,830 2,270 1 5.2 Other
Time Model Statistics DB/Inst: xxxx/xxxx Snaps: 18085-18086
Statistic Name Time (s) % of DB Time
sql execute elapsed time 21,690.6 50.1
parse time elapsed 17,504.9 40.4
DB CPU 4,998.0 11.5
hard parse elapsed time 372.1 .9
connection management call elapsed time 183.9 .4
sequence load elapsed time 125.8 .3
PL/SQL execution elapsed time 89.2 .2
PL/SQL compilation elapsed time 9.2 .0
inbound PL/SQL rpc elapsed time 5.5 .0
hard parse (sharing criteria) elapsed time 5.5 .0
hard parse (bind mismatch) elapsed time 0.5 .0
failed parse elapsed time 0.1 .0
repeated bind elapsed time 0.0 .0
DB time 43,304.1 N/A
background elapsed time 3,742.3 N/A
background cpu time 114.8 N/A
Avg
%Time Total Wait wait Waits
Wait Class Waits -outs Time (s) (ms) /txn
Concurrency 1,413,633 97.5 14,283 10 92.8
User I/O 925,010 .3 11,485 12 60.7
Other 1,984,969 .2 2,858 1 130.3
Application 1,342 46.4 1,873 1396 0.1
Configuration 12,116 63.6 1,857 153 0.8
System I/O 582,094 .0 1,444 2 38.2
Commit 17,253 .6 1,057 61 1.1
Network 6,180,701 .0 68 0 405.9
Wait Events DB/Inst: xxxx/xxxx Snaps: 18085-18086
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
cursor: pin S wait on X 1,378,354 100.0 13,462 10 90.5
db file sequential read 878,684 .0 8,779 10 57.7
local write wait 2,692 91.2 2,442 907 0.2
cursor: pin S 1,932,830 .0 2,270 1 126.9
log file switch (checkpoint 2,669 49.1 1,510 566 0.2
enq: RO - fast object reuse 542 86.5 1,398 2580 0.0
log file sync 17,253 .6 1,057 61 1.1
control file sequential read 450,043 .0 579 1 29.6
log file parallel write 17,903 .0 558 31 1.2
enq: TX - row lock contentio 295 52.2 475 1610 0.0
buffer busy waits 7,338 4.4 348 47 0.5
buffer exterminate 322 92.5 302 938 0.0
read by other session 24,694 .0 183 7 1.6
library cache lock 59 94.9 167 2825 0.0
log file sequential read 109,494 .0 161 1 7.2
latch: cache buffers chains 18,662 .0 149 8 1.2
log buffer space 2,493 .0 139 56 0.2
Log archive I/O 3,592 .0 131 37 0.2
free buffer waits 6,420 99.1 130 20 0.4
latch free 42,812 .0 121 3 2.8
Streams capture: waiting for 845 6.0 106 125 0.1
latch: library cache 2,074 .0 96 46 0.1
db file scattered read 12,437 .0 80 6 0.8
enq: SQ - contention 150 14.0 71 471 0.0
SQL*Net more data from clien 331,961 .0 41 0 21.8
latch: shared pool 320 .0 32 100 0.0
LGWR wait for redo copy 5,307 49.1 29 5 0.3
SQL*Net more data to client 254,217 .0 17 0 16.7
control file parallel write 1,038 .0 15 14 0.1
latch: library cache lock 477 .4 14 29 0.0
latch: row cache objects 6,013 .0 10 2 0.4
SQL*Net message to client 5,587,878 .0 10 0 366.9
latch: redo allocation 1,274 .0 9 7 0.1
log file switch completion 62 .0 6 92 0.0
Streams AQ: qmn coordinator 1 100.0 5 4882 0.0
latch: cache buffers lru cha 434 .0 4 9 0.0
block change tracking buffer 111 .0 4 35 0.0
wait list latch free 135 .0 3 21 0.0
enq: TX - index contention 132 .0 2 17 0.0
latch: session allocation 139 .0 2 14 0.0
latch: object queue header o 379 .0 2 4 0.0
row cache lock 15 .0 2 107 0.0
latch: redo copy 56 .0 1 17 0.0
latch: library cache pin 184 .0 1 5 0.0
write complete waits 14 28.6 1 51 0.0
latch: redo writing 251 .0 1 3 0.0
enq: MN - contention 3 .0 1 206 0.0
enq: CF - contention 16 .0 0 23 0.0
log file single write 24 .0 0 13 0.0
os thread startup 3 .0 0 102 0.0
reliable message 66 .0 0 4 0.0
enq: JS - queue lock 2 .0 0 136 0.0
latch: cache buffer handles 46 .0 0 5 0.0
buffer deadlock 65 100.0 0 4 0.0
latch: undo global data 73 .0 0 3 0.0
change tracking file synchro 24 .0 0 6 0.0
change tracking file synchro 30 .0 0 3 0.0
kksfbc child completion 2 100.0 0 52 0.0
SQL*Net break/reset to clien 505 .0 0 0 0.0
db file parallel read 3 .0 0 30 0.0
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
SQL*Net more data from dblin 127 .0 0 0 0.0
SQL*Net more data to dblink 319 .0 0 0 0.0
latch: enqueue hash chains 20 .0 0 2 0.0
latch: checkpoint queue latc 5 .0 0 5 0.0
SQL*Net message to dblink 6,199 .0 0 0 0.4
enq: TX - allocate ITL entry 1 .0 0 22 0.0
direct path read 5,316 .0 0 0 0.3
latch: messages 24 .0 0 1 0.0
enq: US - contention 3 .0 0 4 0.0
direct path write 1,178 .0 0 0 0.1
rdbms ipc reply 1 .0 0 1 0.0
library cache load lock 2 .0 0 0 0.0
direct path write temp 3 .0 0 0 0.0
direct path read temp 3 .0 0 0 0.0
SQL*Net message from client 5,587,890 .0 135,002 24 366.9
wait for unread message on b 7,809 21.8 3,139 402 0.5
LogMiner: client waiting for 262,604 .1 3,021 12 17.2
LogMiner: wakeup event for b 1,405,104 2.4 2,917 2 92.3
Streams AQ: qmn slave idle w 489 .0 2,650 5420 0.0
LogMiner: wakeup event for p 123,723 32.1 2,453 20 8.1
Streams AQ: waiting for time 9 55.6 1,790 198928 0.0
LogMiner: reader waiting for 45,193 51.3 1,526 34 3.0
Streams AQ: waiting for mess 297 99.3 1,052 3542 0.0
Streams AQ: qmn coordinator 470 33.8 1,050 2233 0.0
Streams AQ: delete acknowled 405 32.3 1,049 2591 0.0
jobq slave wait 379 77.8 958 2529 0.0
LogMiner: wakeup event for r 16,591 10.6 125 8 1.1
SGA: MMAN sleep for componen 3,928 99.3 35 9 0.3
SQL*Net message from dblink 6,199 .0 31 5 0.4
single-task message 108 .0 8 74 0.0
class slave wait 3 .0 0 0 0.0
Background Wait Events DB/Inst: xxxx/xxxx Snaps: 18085-18086
-> ordered by wait time desc, waits desc (idle events last)
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
log file parallel write 17,916 .0 558 31 1.2
Log archive I/O 3,592 .0 131 37 0.2
log file sequential read 3,636 .0 47 13 0.2
events in waitclass Other 6,149 42.4 40 7 0.4
log file switch (checkpoint 30 53.3 19 619 0.0
control file parallel write 1,038 .0 15 14 0.1
db file sequential read 1,166 .0 6 5 0.1
control file sequential read 2,986 .0 6 2 0.2
latch: shared pool 4 .0 4 917 0.0
latch: library cache 5 .0 3 646 0.0
free buffer waits 160 98.8 2 10 0.0
buffer busy waits 2 .0 1 404 0.0
latch: redo writing 19 .0 0 23 0.0
log file single write 24 .0 0 13 0.0
os thread startup 3 .0 0 102 0.0
log buffer space 7 .0 0 35 0.0
latch: cache buffers chains 16 .0 0 8 0.0
log file switch completion 1 .0 0 71 0.0
latch: library cache lock 3 66.7 0 11 0.0
latch: redo copy 1 .0 0 20 0.0
direct path read 5,316 .0 0 0 0.3
latch: row cache objects 3 .0 0 1 0.0
direct path write 1,174 .0 0 0 0.1
latch: library cache pin 3 .0 0 0 0.0
rdbms ipc message 20,401 24.2 11,112 545 1.3
Streams AQ: qmn slave idle w 489 .0 2,650 5420 0.0
Streams AQ: waiting for time 9 55.6 1,790 198928 0.0
pmon timer 379 94.5 1,050 2771 0.0
Streams AQ: delete acknowled 406 32.3 1,050 2586 0.0
Streams AQ: qmn coordinator 470 33.8 1,050 2233 0.0
smon timer 146 .0 1,039 7118 0.0
SGA: MMAN sleep for componen 3,928 99.3 35 9 0.3
Operating System Statistics DB/Inst: xxxx/xxxx Snaps: 18085-18086
Statistic Total
AVG_BUSY_TIME 68,992
AVG_IDLE_TIME 37,988
AVG_IOWAIT_TIME 28,529
AVG_SYS_TIME 11,748
AVG_USER_TIME 57,214
BUSY_TIME 552,209
IDLE_TIME 304,181
IOWAIT_TIME 228,489
SYS_TIME 94,253
USER_TIME 457,956
LOAD 2
OS_CPU_WAIT_TIME 147,872,604,500
RSRC_MGR_CPU_WAIT_TIME 0
VM_IN_BYTES 49,152
VM_OUT_BYTES 0
PHYSICAL_MEMORY_BYTES 25,630,269,440
NUM_CPUS 8
NUM_CPU_SOCKETS 8mbobak wrote:
So, this is a parsing related wait. You already mentioned that you're doing lots of parsing, mostly soft. Do you have session_cursor_cache parameter set to a reasonable value? 10g, I believe the default is 50, which is probably not a bad starting point. You may get additional benefits with moderate increases, perhaps to 100-200 range. It can be costly to do so, but can the extra parsing be addressed in the application? Is there anything you can do to reduce parsing in the application? When the problem occurs, how is the CPU consumption on the box? Are the CPUs pegged? Are you bottlenecked on CPU resources? Finally, there are bugs around 10.2.0.x and mutexes, so, you may want to open an SR w/ Oracle support, and determine if the root cause is actually a bug.
Mark,
I think you might read a little more into the stats than you have done - averaging etc. notwithstanding.
There are 8.55 "hard" parses per second - which in 17.96 minutes is about 9,500 hard parses - and there are 1.3M pin S wait on X: which is about 130 per hard parse (and 1.9M pin S). So the average statistics might be showing an interesting impact on individual actions.
The waits on "local write wait" are worth nothing. There are various reasons for this, one of which is the segment header block writes and index root block writes when you truncate a table - which could also be a cause of the "enq: RO - fast object reuse" waits in the body of the report.
Truncating tables tends to invalidate cursors and cause hard parsing.
So I would look for code that is popular, executed from a number of sessions, and truncates tables.
There were some bugs in this area relating to global temporay tables - but they should have been fixed in 10.2.0.4.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"Science is more than a body of knowledge; it is a way of thinking"+
+Carl Sagan+ -
Performance Issue: Wait event "log file sync" and "Execute to Parse %"
In one of our test environments users are complaining about slow response.
In statspack report folowing are the top-5 wait events
Event Waits Time (cs) Wt Time
log file parallel write 1,046 988 37.71
log file sync 775 774 29.54
db file scattered read 4,946 248 9.47
db file parallel write 66 248 9.47
control file parallel write 188 152 5.80
And after runing the same application 4 times, we are geting Execute to Parse % = 0.10. Cursor sharing is forced and query rewrite is enabled
When I view v$sql, following command is parsed frequently
EXECUTIONS PARSE_CALLS
SQL_TEXT
93380 93380
select SEQ_ORDO_PRC.nextval from DUAL
Please suggest what should be the method to troubleshoot this and if I need to check some more information
Regards,
Sudhanshu BhandariWell, of course, you probably can't eliminate this sort of thing entirely: a setup such as yours is inevitably a compromise. What you can do is make sure your log buffer is a good size (say 10MB or so); that your redo logs are large (at least 100MB each, and preferably large enough to hold one hour or so of redo produced at the busiest time for your database without filling up); and finally set ARCHIVE_LAG_TARGET to something like 1800 seconds or more to ensure a regular, routine, predictable log switch.
It won't cure every ill, but that sort of setup often means the redo subsystem ceases to be a regular driver of foreground waits. -
My wait events - can anyone see a problem?
hi,
this is what i have, can anyone see a problem?
thanks
EVENT TOTAL_WAITS PCT_WAITS TIME_WAIT_SEC PCT_TIME_WAITED TOTAL_TIMEOUTS PCT_TIMEOUTS AVERAGE_WAIT_SEC
Streams AQ: qmn slave idle wait 148147 .3 4051461.88 38.04 3478 .07 27.35
Streams AQ: qmn coordinator idle wa 291006 .59 3962890.53 37.21 148370 3.13 13.62
it
Streams AQ: waiting for time manage 948 0 2021434.2 18.98 948 .02 2132.31
ment or cleanup tasks
control file parallel write 1292057 2.64 266839.64 2.51 0 0 .21
log file parallel write 28433394 58.02 134658.55 1.26 0 0 0
db file sequential read 8307195 16.95 69830.07 .66 0 0 .01
free buffer waits 3117839 6.36 43374.04 .41 3106093 65.55 .01
log buffer space 55520 .11 20810.2 .2 20235 .43 .37
db file scattered read 583604 1.19 18169.58 .17 0 0 .03
write complete waits 17946 .04 17536.66 .16 17941 .38 .98
log file sync 282268 .58 10005.35 .09 9369 .2 .04
enq: RO - fast object reuse 26602 .05 6623.44 .06 2171 .05 .25
enq: CF - contention 1839 0 5178.14 .05 1723 .04 2.82
Streams AQ: qmn coordinator waiting 999 0 4311.01 .04 883 .02 4.32
for slave to start
buffer busy waits 32464 .07 3898.51 .04 3950 .08 .12
control file sequential read 2199199 4.49 3558.34 .03 0 0 0
SGA: MMAN sleep for component shrin 234330 .48 2523.65 .02 234216 4.94 .01
k
buffer exterminate 1583 0 1539.72 .01 1573 .03 .97
library cache pin 317 0 927.71 .01 316 .01 2.93
enq: CI - contention 1829 0 570.84 .01 159 0 .31
log file switch completion 1658 0 517.18 0 425 .01 .31
enq: TX - row lock contention 257 0 438.8 0 149 0 1.71
read by other session 27269 .06 355.17 0 52 0 .01
os thread startup 3869 .01 338.67 0 98 0 .09
latch: shared pool 760 0 285.87 0 0 0 .38
latch: row cache objects 664 0 250 0 0 0 .38
Data file init write 16324 .03 231.59 0 0 0 .01
reliable message 19189 .04 218.16 0 170 0 .01
latch: library cache 483 0 172.51 0 0 0 .36
SQL*Net message from dblink 1143086 2.33 128.69 0 0 0 0
latch free 6091 .01 121.1 0 0 0 .02
library cache load lock 90 0 89.48 0 18 0 .99
log file single write 1894 0 69.76 0 0 0 .04
cursor: pin S wait on X 5183 .01 55.87 0 5165 .11 .01
local write wait 6732 .01 42.58 0 2 0 .01
log file switch (checkpoint incompl 95 0 42.11 0 30 0 .44
ete)
row cache lock 119 0 30.96 0 10 0 .26
SQL*Net more data from dblink 17198 .04 25.92 0 0 0 0
log file switch (private strand flu 69 0 17.54 0 5 0 .25
sh incomplete)
enq: HW - contention 180 0 16.53 0 5 0 .09
enq: PR - contention 9 0 14.5 0 2 0 1.61
enq: JS - queue lock 51 0 12.36 0 0 0 .24
SQL*Net more data to client 48311 .1 11.66 0 0 0 0
enq: TM - contention 12 0 10.66 0 3 0 .89
class slave wait 3128 .01 7.03 0 1 0 0
JS coord start wait 68 0 6.42 0 68 0 .09
direct path write 92712 .19 6.06 0 0 0 0
control file heartbeat 1 0 3.91 0 1 0 3.91
PX Deq: Par Recov Execute 100 0 3.8 0 0 0 .04
log file sequential read 1900 0 2.88 0 0 0 0
single-task message 50 0 2.61 0 0 0 .05
enq: TX - contention 11 0 2.38 0 0 0 .22
undo segment extension 1181001 2.41 1.95 0 1180981 24.92 0
db file single write 165 0 1.3 0 0 0 .01
enq: TX - index contention 97 0 1.27 0 0 0 .01
LGWR wait for redo copy 20840 .04 .66 0 0 0 0
JS kgl get object wait 8 0 .63 0 8 0 .08
SQL*Net message to dblink 1143086 2.33 .55 0 0 0 0
kksfbc child completion 14 0 .55 0 11 0 .04
direct path read temp 217237 .44 .41 0 0 0 0
latch: cache buffers chains 2138 0 .37 0 0 0 0
latch: messages 1245 0 .27 0 0 0 0
latch: redo writing 786 0 .15 0 0 0 0
PX Deq: Par Recov Reply 65 0 .09 0 0 0 0
latch: checkpoint queue latch 171 0 .09 0 0 0 0
latch: redo allocation 1029 0 .08 0 0 0 0
latch: cache buffers lru chain 268 0 .07 0 0 0 0
SGA: allocation forcing component g 5 0 .05 0 2 0 .01
rowth
db file parallel read 83 0 .04 0 0 0 0
latch: In memory undo latch 558 0 .04 0 0 0 0
latch: object queue header operatio 338 0 .04 0 0 0 0
n
direct path read 5042 .01 .03 0 0 0 0
PX Deque wait 7 0 .02 0 0 0 0
direct path write temp 4691 .01 .02 0 0 0 0
enq: SQ - contention 1 0 .02 0 0 0 .02
latch: session allocation 190 0 .02 0 0 0 0
PX Deq: Join ACK 15 0 .01 0 0 0 0
cursor: pin S 894 0 .01 0 0 0 0
enq: TX - allocate ITL entry 37 0 .01 0 0 0 0
kkdlgon 15 0 .01 0 0 0 0
latch: enqueue hash chains 37 0 .01 0 0 0 0
library cache lock 1 0 .01 0 0 0 .01
Log archive I/O 1 0 0 0 0 0 0
PX Deq: Par Recov Change Vector 2 0 0 0 0 0 0
PX Deq: Signal ACK 3 0 0 0 0 0 0
PX Deq: Test for msg 1 0 0 0 0 0 0
PX qref latch 1 0 0 0 1 0 0
SQL*Net break/reset to dblink 5 0 0 0 0 0 0
SQL*Net more data to dblink 1 0 0 0 0 0 0
buffer deadlock 27 0 0 0 27 0 0
checkpoint completed 4 0 0 0 0 0 0
cursor: mutex S 3 0 0 0 0 0 0
cursor: mutex X 1 0 0 0 0 0 0
enq: JS - q mem clnup lck 1 0 0 0 0 0 0
enq: PS - contention 2 0 0 0 0 0 0
enq: US - contention 1 0 0 0 0 0 0
instance state change 2 0 0 0 0 0 0
latch: library cache lock 4 0 0 0 0 0 0
latch: library cache pin 1 0 0 0 0 0 0
latch: object queue header heap 8 0 0 0 0 0 0
latch: undo global data 3 0 0 0 0 0 0
recovery read 39 0 0 0 0 0 0Hi,
If its for a week than I won't bother. Probably you should try to get teh same report for these wait events in a much smaller period , like 20-30minutes of time period when your db is fully operational. If still at that time the wait events,these or any other, shoot up to high wait times, things can be investigated more deeply.
HTH
Aman.... -
Waiting event when execute my jdbc queries
I write a simple multithread jdbc programme to connect to oracle, execute 10 time "select * from mytable" , when I start 2 threads, the time each thread use to complete queries is 9 second. when i start 3 threads, it become extremly slow.
I notice there are serveral waiting event: resmgr:waiting in end wait, resmgr:waiting in actses run, and single-task message , they are waiting for as long as 4 seconds. they after my programm finished,
could anyone tell me what are these event? do they affect the performance of my oracle?I write a simple multithread jdbc programme to connect to oracle, execute 10 time "select * from mytable" , when I start 2 threads, the time each thread use to complete queries is 9 second. when i start 3 threads, it become extremly slow.
I notice there are serveral waiting event: resmgr:waiting in end wait, resmgr:waiting in actses run, and single-task message , they are waiting for as long as 4 seconds. they after my programm finished,
could anyone tell me what are these event? do they affect the performance of my oracle? These wait events are associated with the Resource Manager which handles the Consumer Groups. Try changing your consumer group are shutting the Resource Manager off with
alter system set resource_manager_plan='';
then test your queries again. -
Query performance problem - events 2505-read cache and 2510-write cache
Hi,
I am experiencing severe performance problems with a query, specifically with events 2505 (Read Cache) and 2510 (Write Cache) which went up to 11000 seconds on some executions. Data Manager (400 s), OLAP data selection (90 s) and OLAP user exit (250 s) are other the other event with noticeable times. All other events are very quick.
The query settings (RSRT) are
persistent cache across each app server -> cluster table,
update cache in delta process is checked ->group on infoprovider type
use cache despite virtual characteristics/key figs checked (one info-cube has1 virtual key figure which should have a static result for a day)
=>Do you know how I can get more details than what's in 0TCT_C02 to break down the read and write cache events time or do you have any recommandation?
I have checked and no dataloads were in progres on the info-providers and no master data loads (change run). Overall system performance was acceptable for other queries.
ThanksHi,
Looks like you're using BDB, not BDB JE, and this is the BDB JE forum. Could you please repost here?:
Berkeley DB
Thanks,
mark -
Event ID 218 Copy of database 'Mailbox Database'- experienced a performance problem
Hi,
We have 16 GB of RAM for EXchange 2010 and 4 Processor and using iSCSI Starwind LUN.
Event ID : 218
Event Source : ExchangeStoreDB
Event Category :Database Recovery
the copy of database 'Mailbox Database - NYM' on this server experienced a performance problem. Failover returned the following
error: here is only one copy of this mailbox database (Mailbox Database - NYM). Automatic recovery is not available.
It occurs specially when the exchange backup start ; we are using window backup for taking exchange backup
I can see warnning of ESE below the event 218 - Information Store (3912) Mailbox Database - NYM: A request to write to the file "D:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0959355037\Mailbox Database 0959355037.edb" at
offset 150801350656 (0x000000231c760000) for 32768 (0x00008000) bytes has not completed for 68 second(s). This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.
Also,
1. How can I enable verbose logging to expert level for exchange MailboxDatabase.
2. What type performace counter need to be set for exchange database in Performance Monitor
Any Help ?
Thanks
PrakashWe had the same issue on our mbx server with Exchange 2010 Ent SP3, Win Svr 2008 R2 SP1 running on VMware v5.1 with Exchange dbs mounted to the VM via iSCSI LUNs on our NetApp SAN.
We escalated the ticket, and the Microsoft Exchange escalation team stated that the EIDs of the database corruption and automatic recovery seem to point to a hardware issue. And, they told us not to panic and that there was no need to rebuild the environment
and migrate the databases immediately. They instead asked us to focus all our efforts on solving the iSCSI environment issues, since each Exchange EID db corruption/ autorecovery would be preceded by some type of corresponding iSCI System EID.
We hence opened tickets with MS Storage Team and with NetApp support and worked on this ticket with input from all 3 groups.
After about a month an a half of troubleshooting & trial error- with tickets open with NetApp, MS Storage Team, and MS Exchange team, we finally seem to have applied a configuration change that worked.
NetApp support referred us to the following article relating to VMware:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2039495
So, per NetApp support and MS Storage team, do the following:
1. Manually dismount Exchange Databases on the mailbox server.
2. Open Device Manager, Network Adapters, VMXNET3 Ethernet Adapter #3, Properties
3. Change Small RX Buffers from the default 512 to the maximum 8192 using the drop down selector.
4. Change the RX Ring #1 from the default 1024 to the maximum of 4096 using the drop down selector.
5. Click OK and save the change.
6. Re-mount the Exchange Databases
And, to our surprise, this seems to have done the trick. It seems like the issue is an iSCSI-related NIC setting all along.
Thanks,
Detrich -
Database performing Very slow - Lots of wait events
My database is on Oracle10g on Sun 5.10
The users are complaining about database is very slow.
I analyzed the indexes & later on rebuild them, hardly it has only 5% performance improvement.
http://i812.photobucket.com/albums/zz43/sadeel00/untitled1.jpg
http://i812.photobucket.com/albums/zz43/sadeel00/untitled2.jpg
ADDM has no recommendations.Duplicate post - Database performing Very slow - Lots of wait events
Srini -
I have problem with enq: TM – contention wait events.
From ASH report in Top Event P1/P2/P3 I find problematic object – table T1. It has two columns C1 and C2. There are PK and FK constraints on these two columns.Table T1 has one UNIQUE INDEX - index_name(C1, C2).
With this:
SELECT * FROM (
SELECT c.table_name, cc.column_name, cc.position column_position
FROM user_constraints c, user_cons_columns cc
WHERE c.constraint_name = cc.constraint_name
AND c.constraint_type = 'R'
MINUS
SELECT i.table_name, ic.column_name, ic.column_position
FROM user_indexes i, user_ind_columns ic
WHERE i.index_name = ic.index_name
+)+
ORDER BY table_name, column_position;
I find unindexed Foreign Key constraints, and show me that no index on C2 column.
Can I create new index on this C2 column: CREATE INDEX index_name_c2 ON T1(C2) because I have index on C1 and C2 columns ?
In ASH report in Top DB Objects I see another indexes and table with enq: TM – contention event. Whey Oracle show me this objects?Based on what you've written I see nothing that should stop you from creating an index but I would recommend you do so in dev or test before production.
As to why Oracle is showing it to you? Likely because it thinks there is a potential issue there.
Remember always that the best designed database in the world is going to have a top 5 or top 10 list too. The only way to not have events reported is with shutdown abort.
Maybe you are looking for
-
How to create a shared review without an internal server
I have Adobe Acrobat XI Pro, and I'm trying to create a shared review where myself and 2 colleagues can make edits and add comments to the same PDF simultaneously. Basically, we're all tasked with editing the document and have to work on it at the sa
-
YouTube Videos are not showing on my site
Recently I tried to add some YouTube videoson my site Dhow Cruise, but unfortunately the video is not displaying, I'm unable to solve it, can anyone help me out? Regards
-
Vertical navigation in iWeb 08 possible?
I have a website with around 80 entries in the navigation menu, sorted in around 10 upper level groups. iWeb seems to be rather static in terms of placing the navigation. Is there any plugin, addon or workaround someone has found? Thanks, Ralf
-
Problem updating cs6 "application manager is already running..." ?
Hi everybody When im trying to update CS6 the application manager app don doit and give this message: "adobe application manager is already running, please close other instances before applying updates." There is not other instances of the applicatio
-
So that we may better diagnose DOWNLOAD problems, please provide the following information. - Server name - Filename Linux9i_Disk1.cpio.gz & Linux9i_Disk2.cpio.gz - Date/Time a week ago - Browser + Version Netscape 4.76 - O/S + Version Mandrake Linux