100 %CPU utilizationis , cache buffers chains and cursor: pin S
Hi every one ,
we have incident causing system response very slow with very bad response time, below top 5 wait events from AWR (RAC database)
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
latch: cache buffers chains 122,492 198,139 1,618 16.8 Concurrency
gc buffer busy 119,903 83,248 694 7.1 Cluster
cursor: pin S 18,674,280 72,651 4 6.2 Other
log file sync 639,867 66,673 104 5.7
Commit latch free 143,519 54,239 378 4.6 Other
Oracle support clearly identified the issue with latch cache buffer chains as SQL statement executed around 35000 times which is too high based on execution plan . and they suggest to tune SQL statements .
my question is cursor: pin S wait on X and library cache lock related ot it is just a symptoms , and is document 742599.1 applicable to us or not as we have 10.2.0.5 (suggest disable automatic memory management)
As I know high CPU utilization as result of latch: cache buffers chains , the cursor Pin S Wait should not .
Thank you in advance
Hi,
All these 4 top events (excluding log file sync) are quite unusual and in your case, if all these are comming atop, these quite well be related. So, you can't say that cursor pin s wait on x should not be dealt saperatly, but, still you can try out suggestion in the note. First find out from v$sgasta about current allocation of shared pool, then after disabling automatic memory management, increase shared_pool significantly as compared to current value, and then monito the system
Definitely you should tune your SQL also, as suggested by support.
Salman
Similar Messages
-
question from oracler:
由于没有代码，所以sql语句没法改。
1、4_28_awr.html是最初的状态cache buffers chains 征用严重，后来我把热点的2个索引INFO_KEYWORD、PKKEY_ARTICLE单独挪到了16k和4k的非标准表空间，这样多增加了几个池子希望可以降低征用。
2、4_28_2awr.html虽然cache buffers chains 还是比较多，但是waitstime比较低，没有影响前台使用。
3、428_3_awr.html 是刚才cpu的使用率又上去了，做的awr报告，发现cache buffers chains仍然较多，waitstime明显上去了。
请教：因为没办法修改sql语句的程序代码，只能从数据库层面入手。尽量降低热点块。是不是可以尝试将2个索引表空间的pctfree再增加到30%或者更高。或者2个索引采用4k的非标准块，这样分布在每个块中的行会比较少一点。我觉得我设置的16k块大小可能有点问题，盼赐教。
http://t.askmaclean.com/viewthread.php?tid=866&extra=page%3D1%26amp%3Bfilter%3Ddigest就症结来看 是SQL语句存在优化空间，大多都Buffer Gets过高 这意味着大量的逻辑读
Logical reads: 952,053.46 511,723.68
在其中一个AWR中 每秒逻辑读 达到 7G
buffer gets 较高 存在优化的SQL包括：
SQL ordered by Gets
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
Total Buffer Gets: 1,733,719,818
Captured SQL account for 42.9% of Total
Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text
150,857,840 6 25,142,973.33 8.70 1296.33 1769.90 gmm6ktqrft6n1 select rowid, title, filep...
57,452,737 234 245,524.52 3.31 676.45 678.49 06r32459s5kzc select rowid, ArticleID, S...
50,264,264 2 25,132,132.00 2.90 311.70 329.90 731rq4a5rd9by select rowid, title, filep...
28,441,522 2 14,220,761.00 1.64 310.11 570.12 bxa7c0y5p6smg select rowid, title, filep...
28,440,949 2 14,220,474.50 1.64 279.11 464.68 68pwkvkgs7taj select rowid, title, filep...
28,433,242 2 14,216,621.00 1.64 234.45 391.91 f442cdh9hp6sk select rowid, title, filep...
粗略看 可能是因为 希望执行计划准确 而没有去绑定变量
这里考虑到 无法修改SQL 语句， 但是 有没有想过 通过其他手段(不修改语句 添加hint)而 改善其执行计划？
Segments by Logical Reads
Total Logical Reads: 1,733,719,818
Captured Segments account for 98.8% of Total
Owner Tablespace Name Object Name Subobject Name Obj. Type Logical Reads %Total
JSCMS JSCMS INFO_KEYWORD INDEX 1,159,873,824 66.90
JSCMS JSCMS PKKEY_ARTICLE INDEX 215,263,104 12.42
JSCMS JSCMS ARTICLE SYS_P76 TABLE PARTITION 198,657,088 11.46
逻辑较高的 segment 包括 INFO_KEYWORD 和 PKKEY_ARTICLE 把他们 移动到 block size的 非标准表空间上确实可以一定程度缓解 对这个segment 上buffer的交叉访问争用 ， 但是 使用 16KB的block size意味着 数据行的分布更为集中 ， 这可能导致段内buffer的争用加剧 。
建议：
1. 考虑在 不修改SQL文本 的情况下 调优SQL ，包括使用SQL Profile等技术
2. 考试使用 global hash index ，当然hash index不是一定能缓解cbc
3. 内存允许的话 可以吧 一个索引 keep到 db cache keep pool中(而非16k pool)，另一个使用 4k pool
一些Cache buffer chains相关的master Notes:
ODM FINDING:
Cache Buffers Chains Latch waits are caused by contention where multiple sessions waiting to read the same block.
Typical solutions are:-
o Look for SQL that accesses the blocks in question and determine if the repeated reads are necessary.
o Check for suboptimal SQL (this is the most common cause of the events) - look at the execution plan for the
SQL being run and try to reduce the gets per executions which will minimise the number of blocks being accessed
and therefore reduce the chances of multiple sessions contending for the same block
Note 34405.1 WAITEVENT: "buffer busy waits" Reference Note
@Note 42152.1 LATCH: CACHE BUFFERS CHAINS
Note 155971.1 Ext/Pub Resolving Intense and "Random" Buffer Busy Wait Performance Problems:
Note 163424.1 Ext/Pub How To Identify a Hot Block Within The Database Buffer Cache.:
These queries would benefit from tuning. They either do too much buffer gets (logical reads) per execution or just do a lot of buffer gets. Tuning these queries would lower the load on the CPU and reduce the CPU wait time. Check if all objects in these queries have representative and up to date stats present. Also check if all the indexes are present.
If a query does not do an excessive amount of gets for 1 run but when the query runs often, then lowering the amount of buffer gets per run with for example 10% will have a big impact overall.
To see the full SQL open the html AWR report and select SQL Statistics in the Main Report section, then select SQL ordered by Gets clicking on the SQL id then gives the complete statement.
"Cache Buffers Chains Latch waits are caused by contention where multiple sessions waiting to read the same block.
那么与
read by others session 这个等待事件有什么区别？"
通俗的说 (不深究技术细节)
CBC latch 是 大家都要逻辑读取同一个块，对于Consistent Read会使用kcbgtcr函数， kcbgtcr 函数可能使用2中模式去get cache buffer chains， 分别是 kcbgtcr: kslbegin excl 和 kcbgtcr: kslbegin shared， 在上述AWR中 主要是 kslbegin excl
“我们一般认为Latch结构是Mostly exclusive access的，也就是极少会有共享访问闩的机会。但Oracle一般对外宣称读取数据时服务进程是以共享模式使用cache buffers chains闩，这就造成了许多人误以为读读是不会出现latch: cache buffers chains争用的。
但是实际上查询语句大部分情况下仍需要以exclusive模式持有该类子闩(有时会以SHARED模式持有，这取决于读取时是使用kcbgtcr: kslbegin shared还是kcbgtcr: kslbegin excl；kcbgtcr是Oracle rdbms中重要的获取一致性读的函数，其含义为Kernal Cache Buffer GeT Cosistents Read，显然该函数存在两种获取cache buffers chains的方式即kslbegin shared和excl。与之相对应的是kcbgcur: kslbegin，kcbgcur的含义为Kernel Cache Buffer Get Current，该函数用以获取当前块以便修改，也就是”写”；很显然kcbgcur: kslbegin函数只有以excl排他方式持有child cache buffers chains latch的必要)，原因在于虽然是查询语句但同样需要修改buffer header结构，譬如修改tch抢手度、holder list的hash变量us_nxt、us_prv以及waiter list的hash变量wa_prv、wa_nxt等。换而言之读读是会引起Latch free:cache buffers chains等待的，而非许多人认为的仅有读写、写写会导致缓存链闩争用。”
FROM http://www.oracledatabase12g.com/archives/oracle%E9%97%A9latch-cache-buffers-chains.html
cache buffers chains kcbgtcr: kslbegin excl 0 28,633,140 27,628,172
cache buffers chains kcbrls: kslbegin 0 27,162,431 28,455,820
cache buffers chains kcbgtcr: fast path 0 1,969 2,664
read by others session 是这个block不在缓存(buffer cache)中，大家都想要访问这个block，但是只需要一个人去做物理读取到Buffer cache， 其他人在 有一个人去做physical read 的情况下非空闲(non-idle wait)等待即可。 -
Why the event latch: cache buffers chains wait event arises and resolution
Can any one please give full information about:
latch: cache buffers chains wait event
Why this event arises and resolution?Google gave me
http://www.pythian.com/news/1135/tuning-latch-contention-cache-buffers-chain-latches/ -
Hi,
I am facing the following in my DB.Oracle version is 11.1.0.7.0
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
latch: cache buffers chains 37,910,465 17,344 0 42.64 Concurrency
I checked the SQL causing the wait using following query.
select count(*), SQL_ID from gv$active_session_history where event like '%cache buffers%' group by SQL_ID;
COUNT(*) SQL_ID
1
3 3wunvbmu64d8j
2 9q2ux8f92za7m
36000 47g8dw48ghk5s
2 5arqxftxr7tjr
Also i tried the following.
select count(*) child_count, sum(gets) sum_gets, sum(misses) sum_misses, sum(sleeps) sum_sleeps from v$latch_children where name = 'cache buffers chains';
CHILD_COUNT SUM_GETS SUM_MISSES SUM_SLEEPS
65536 1.5723E+10 3163139088 56744600
SQL> select P1 from v$session_wait where event = 'cache buffer chains';
no rows selected
How do i proceed with this?
SQL ID - 47g8dw48ghk5s is an update query.Can increasing freelists of this table help ??Kindly assist me.
Thanks.user10698496 wrote:
Elapsed Time (s) CPU Time (s) Executions Elap per Exec (s) % Total DB Time SQL Id SQL Module SQL Text
29,725 6,747 82,289 0.36 73.08 47g8dw48ghk5s app2 (TNS V1-V3) UPDATE ZH_TBL SE
CPU Time (s) Elapsed Time (s) Executions CPU per Exec (s) % Total % Total DB Time SQL Id SQL Module SQL Text
6,747 29,725 82,289 0.08 62.52 73.08 47g8dw48ghk5s app2 (TNS V1-V3) UPDATE ZH_TBL SE...
Assuming that this is the standard one-hour snapshot that seems to be a rather small number of executions to waste so much latch time.
Moreover, since it's an update by rowid it's surprising that it should take so much CPU per executions unless you have a very large number of indexes on the table which have to be maintained.
Can you show us the "Load profile" and "Top 5 timed events" from the same period, plus the system summary bit (memory, cache size, CPU count) that's near the top of the report.
In your position I'd run up a little query to look at the stats in v$sql for that sql_id, and watch the executions, buffer_gets, cpu_time etc. changing over a few minutes in case there's something funny with the snapshot and youre losing large numbers in the execution counts. (I'd be particularly interested in the number of CPUs you have, and the CPU load on the system - sometimes you can get really wierd latching issue which are basically caused by CPU loading, especially on NUMA systems).
Since you've got the ASH data, there's also more information you can get from there - is it
a) the same latch all the time
b) a small number of different latches
c) a small number of different latches, but the same latch for any specific sid/serial
d) does the latch seem to change over time
If it's a small number of fixed latches you may be able to query the buffer cache with the latch address to see if there are any "obvious" blocks with a high touch count covered by those latches - they may be things like the root blocks of indexes used for referential integrity.
If the latch seems to keep moving it could be an indication that the update is slowly travelling along a table and every block is subject to competition from a number of concurrent processes.
Kyle Hailey has some sample queries against ASH that may point you in the right direction: http://sites.google.com/site/embtdbo/wait-event-documentation/oracle-latch-cache-buffers-chains
If you can spot a session hitting the problem you could also start tracing it to see if that level of detail gives you more clues, and I'd also start thinking about read up Tanel's notes.
Regards
Jonathan Lewis
To post code, statspack/AWR report, execution plans or trace files, START and END the text with the tag {noformat}{noformat} (the word "code" in 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.) -
AWR showing high latch: cache buffers chains
OS:Solaris 5.8
DB:10.2.0.2
AWR report show high latch: cache buffers chains . Please suggestuser8850066 wrote:
OS:Solaris 5.8
DB:10.2.0.2
AWR report show high latch: cache buffers chains . Please suggestYour question is not sensible - so the first answer you got may be a complete waste of your time, or it may be a lucky shot in the dark that helps.
How did you decide that your "latch: cache buffers chains" was high ?
The evidence that led you to this conclusion may help us understand what your problem is and how to help you.
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.)
+"I believe in evidence. I believe in observation, measurement, and reasoning, confirmed by independent observers. I'll believe anything, no matter how wild and ridiculous, if there is evidence for it. The wilder and more ridiculous something is, however, the firmer and more solid the evidence will have to be."+
Isaac Asimov -
After a data load the data increased by around 30%. After the load, one statement now takes 5h compared to 40min before the load. The statement runs during the nighty batch so there are no other connections. Statistics for tables and indexes are gathered and current.
I have compared the AWRs before the data load and the current AWR:
- latch: cache buffers increased from 12Mio waits to 95Mio waits. As a consequence CPU usage is very high during the load period.
- consistent gets increased 3 times
- select count(distinct(hladdr)) from x$bh; result is 8192
- I checked for hot blocks - there are none as there is no other process during that time
The slow statement is an CTAS like (The same statement runs in an environment with much more data in less time.)
CREATE TABLE XXX NOLOGGING PARALLEL TABLESPACE YYY COMPRESS PARTITION BY RANGE(...) select with some outer joins.
What else should I examine/consider?The object statistics including indexes are current & complete. I have rerun the whole queries on both environments - the plans are different.
Difference between the databases:
- the slow one uses AL32UTF8 as DB character set, the fast one WE8ISO8859P1.
- the fast DB has temporary tablespace on raw devices
SELECT
count(*)
FROM
SELECT
mand,
c2v_thk1, c2v_thk1origin,
c2v_thk1 AS thk1,
sustainid,
_from, _to,
FROM
SELECT
mand,
CASE WHEN c2v_thk1skr IS NOT NULL THEN c2v_thk1skr ELSE thk1 END AS c2v_thk1,
CASE WHEN c2v_thk1skr IS NOT NULL THEN thk1 ELSE NULL END AS c2v_thk1origin,
sustainid,
_from, _to,
FROM chem.exper LEFT OUTER JOIN
SELECT
olr.mand,
olr.sustainid,
o.handoverdate
FROM
chem.order olr, chem.ch_order o
WHERE
(olr.mand = o.mand AND olr.sustainorderno = o.sustainorderno) AND
olr.finishDate IS NULL AND
o.finishDate IS NULL
) v2o USING (mand, sustainid) LEFT OUTER JOIN
SELECT
mand, thk1, sustainid,
selling_retuid,
CASE WHEN liqudateStep = 0 THEN liqu_retuid ELSE NULL END AS liqu_retuid,
CASE WHEN liqudateStep = 0 THEN trj55_lastliqudate ELSE NULL END AS trj55_lastliqudate
FROM
SELECT
mand,
thk1,
sustainid,
DECODE(roleselling, 0, retuid, NULL) AS selling_retuid, DECODE(roleliqu, 1, retuid, NULL) AS liqu_retuid,
DECODE(roleliqu, 2, lastliqudate, NULL) AS trj55_lastliqudate,
ROW_NUMBER () OVER (PARTITION BY mand, thk1, sustainid ORDER BY roleliqu DESC NULLS LAST, lastliqudate DESC NULLS LAST,retuid) AS liqudateStep
FROM chem.sat_trj55etu trj55
WHERE finishDate IS NULL
WHERE
(liqudateStep = 1 OR liqu_retuid IS NULL OR selling_retuid IS NOT NULL)
) trj55 USING (mand, thk1, sustainid) LEFT OUTER JOIN
SELECT
mand,
thk1origin AS thk1,
thk1skr AS c2v_thk1skr
FROM chem.x_ref
WHERE finishDate IS NULL
) USING (mand, thk1) )
) bs LEFT OUTER JOIN (
SELECT
tk_pla.mand,
tk_pla.thk1company AS thk1,
CASE WHEN ss.thk1skr IS NOT NULL THEN ss.thk1skr ELSE tk_pla.thk1individual END AS tk_pla_thk1individual,
CASE WHEN ss.thk1skr IS NOT NULL THEN tk_pla.thk1individual ELSE NULL END AS tk_pla_thk1individualorigin,
FROM chem.sat_indy tk_pla, (SELECT * FROM chem.x_ref WHERE finishDate IS NULL) ss
WHERE tk_pla.finishDate IS NULL
AND (tk_pla.mand = ss.mand(+) AND tk_pla.thk1individual = ss.thk1origin(+))
AND tk_pla._to IS NULL
) tk_pla USING (mand, thk1);Slow environment with much less data (execution time much more since last data load; object statistics are current)
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 62 | | 116 (6)| 00:00:02 | | | | |
| 1 | SORT AGGREGATE | | 1 | 62 | | | | | | | |
| 2 | NESTED LOOPS OUTER | | 90571 | 5483K| | 116 (6)| 00:00:02 | | | | |
| 3 | VIEW | | 73410 | 2437K| | 116 (6)| 00:00:02 | | | | |
| 4 | PX COORDINATOR | | | | | | | | | | |
| 5 | PX SEND QC (RANDOM) | :TQ10003 | 73410 | 10M| | 116 (6)| 00:00:02 | | | Q1,03 | P->S | QC (RAND)
| 6 | NESTED LOOPS OUTER | | 73410 | 10M| | 116 (6)| 00:00:02 | | | Q1,03 | PCWP |
| 7 | NESTED LOOPS OUTER | | 73410 | 8674K| | 115 (5)| 00:00:02 | | | Q1,03 | PCWP |
|* 8 | HASH JOIN RIGHT OUTER | | 73410 | 4588K| | 115 (5)| 00:00:02 | | | Q1,03 | PCWP |
| 9 | PX RECEIVE | | 49290 | 1540K| | 9 (12)| 00:00:01 | | | Q1,03 | PCWP |
| 10 | PX SEND HASH | :TQ10002 | 49290 | 1540K| | 9 (12)| 00:00:01 | | | Q1,02 | P->P | HASH
| 11 | VIEW | | 49290 | 1540K| | 9 (12)| 00:00:01 | | | Q1,02 | PCWP |
|* 12 | VIEW | | 49290 | 6979K| | 9 (12)| 00:00:01 | | | Q1,02 | PCWP |
| 13 | WINDOW SORT | | 49290 | 2406K| 7000K| 9 (12)| 00:00:01 | | | Q1,02 | PCWP |
| 14 | PX RECEIVE | | 49290 | 2406K| | 8 (0)| 00:00:01 | | | Q1,02 | PCWP |
| 15 | PX SEND HASH | :TQ10001 | 49290 | 2406K| | 8 (0)| 00:00:01 | | | Q1,01 | P->P | HASH
| 16 | PX BLOCK ITERATOR | | 49290 | 2406K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,01 | PCWC |
|* 17 | TABLE ACCESS FULL | SAT_trj55etu | 49290 | 2406K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,01 | PCWP |
| 18 | BUFFER SORT | | | | | | | | | Q1,03 | PCWC |
| 19 | PX RECEIVE | | 73410 | 2294K| | 106 (4)| 00:00:02 | | | Q1,03 | PCWP |
| 20 | PX SEND HASH | :TQ10000 | 73410 | 2294K| | 106 (4)| 00:00:02 | | | | S->P | HASH
| 21 | PARTITION RANGE ALL | | 73410 | 2294K| | 106 (4)| 00:00:02 | 1 | 6 | | |
| 22 | TABLE ACCESS FULL | exper | 73410 | 2294K| | 106 (4)| 00:00:02 | 1 | 6 | | |
| 23 | PARTITION RANGE ITERATOR | | 1 | 57 | | 0 (0)| 00:00:01 | KEY | KEY | Q1,03 | PCWP |
|* 24 | INDEX FAST FULL SCAN | X_x_ref | 1 | 57 | | 0 (0)| 00:00:01 | KEY | KEY | Q1,03 | PCWP |
|* 25 | VIEW PUSHED PREDICATE | | 1 | 35 | | 0 (0)| 00:00:01 | | | Q1,03 | PCWP |
|* 26 | TABLE ACCESS BY LOCAL INDEX ROWID| order | 1 | 106 | | 0 (0)| 00:00:01 | 1 | 1 | Q1,03 | PCWP |
| 27 | NESTED LOOPS | | 1 | 199 | | 0 (0)| 00:00:01 | | | Q1,03 | PCWP |
| 28 | PARTITION RANGE ALL | | 1 | 93 | | 0 (0)| 00:00:01 | 1 | 6 | Q1,03 | PCWP |
|* 29 | INDEX SKIP SCAN | X_ch_order | 1 | 93 | | 0 (0)| 00:00:01 | 1 | 6 | Q1,03 | PCWP |
| 30 | PARTITION RANGE SINGLE | | 1 | | | 0 (0)| 00:00:01 | KEY | KEY | Q1,03 | PCWP |
|* 31 | INDEX RANGE SCAN | XPKorder | 1 | | | 0 (0)| 00:00:01 | KEY | KEY | Q1,03 | PCWP |
| 32 | PX COORDINATOR | | | | | | | | | | |
| 33 | PX SEND QC (RANDOM) | :TQ20000 | 1 | 28 | | 0 (0)| 00:00:01 | | | Q2,00 | P->S | QC (RAND)
|* 34 | VIEW PUSHED PREDICATE | | 1 | 28 | | 0 (0)| 00:00:01 | | | Q2,00 | PCWP |
| 35 | NESTED LOOPS OUTER | | 40517 | 3204K| | 2 (0)| 00:00:01 | | | Q2,00 | PCWP |
| 36 | PX BLOCK ITERATOR | | 40517 | 1463K| | 2 (0)| 00:00:01 | KEY | KEY | Q2,00 | PCWC |
|* 37 | TABLE ACCESS FULL | SAT_INDI | 40517 | 1463K| | 2 (0)| 00:00:01 | KEY | KEY | Q2,00 | PCWP |
| 38 | PARTITION RANGE ITERATOR | | 1 | 44 | | 0 (0)| 00:00:01 | KEY | KEY | Q2,00 | PCWP |
|* 39 | INDEX FAST FULL SCAN | X_x_ref | 1 | 44 | | 0 (0)| 00:00:01 | KEY | KEY | Q2,00 | PCWP |
Predicate Information (identified by operation id):
8 - access("exper"."mand"="trj55"."mand"(+) AND "exper"."thk1"="trj55"."thk1"(+) AND
"exper"."sustainID"="trj55"."sustainID"(+))
12 - filter("liqudateStep"=1 OR "liqu_retuID" IS NULL OR "SELLIN
17 - filter("finishDate" IS NULL)
24 - filter("finishDate"(+) IS NULL AND "exper"."mand"="mand"(+) AND "exper"."thk1"="thk1ORIGIN"(+))
25 - filter("exper"."sustainID"="V2O"."sustainID"(+))
26 - filter("olr"."finishDate" IS NULL)
29 - access("O"."finishDate" IS NULL)
filter("O"."finishDate" IS NULL)
31 - access("olr"."mand"="O"."mand" AND "olr"."sustainORDERNO"="O"."sustainORDERNO")
filter("olr"."mand"="exper"."mand")
34 - filter("BS"."thk1"="tk_pla"."thk1"(+))
37 - filter("tk_pla"."finishDate" IS NULL AND "tk_pla"."_to" IS NULL AND "tk_pla"."mand"="BS"."mand")
39 - filter("finishDate"(+) IS NULL AND "tk_pla"."mand"="x_ref"."mand"(+) AND "tk_pla"."thk1INDIVIDUAL"="x_ref"."thk1ORIGIN"(+))
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
db_file_multiblock_read_count integer 32
db_block_size integer 8192
parallel_max_servers integer 17
parallel_min_percent integer 0
parallel_min_servers integer 0
parallel_server boolean FALSE
parallel_server_instances integer 1
parallel_threads_per_cpu integer 2
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1653.70019
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM 3.684
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED 1471
{code}
Fast environment with more data
{code}
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 33 | | 52357 (6)| 00:04:29 | | | | | |
| 1 | SORT AGGREGATE | | 1 | 33 | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10010 | 1 | 33 | | | | | | Q1,10 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | | 1 | 33 | | | | | | Q1,10 | PCWP | |
|* 5 | HASH JOIN RIGHT OUTER | | 22M| 698M| | 52357 (6)| 00:04:29 | | | Q1,10 | PCWP | |
| 6 | PX RECEIVE | | 294K| 4020K| | 86 (3)| 00:00:01 | | | Q1,10 | PCWP | |
| 7 | PX SEND BROADCAST | :TQ10007 | 294K| 4020K| | 86 (3)| 00:00:01 | | | Q1,07 | P->P | BROADCAST |
| 8 | VIEW | | 294K| 4020K| | 86 (3)| 00:00:01 | | | Q1,07 | PCWP | |
|* 9 | HASH JOIN OUTER BUFFERED | | 294K| 10M| | 86 (3)| 00:00:01 | | | Q1,07 | PCWP | |
| 10 | PX RECEIVE | | 294K| 6892K| | 77 (2)| 00:00:01 | | | Q1,07 | PCWP | |
| 11 | PX SEND HASH | :TQ10002 | 294K| 6892K| | 77 (2)| 00:00:01 | | | Q1,02 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 294K| 6892K| | 77 (2)| 00:00:01 | 1 | 6 | Q1,02 | PCWC | |
|* 13 | TABLE ACCESS FULL | SAT_INDI | 294K| 6892K| | 77 (2)| 00:00:01 | 1 | 6 | Q1,02 | PCWP | |
| 14 | PX RECEIVE | | 71698 | 980K| | 8 (0)| 00:00:01 | | | Q1,07 | PCWP | |
| 15 | PX SEND HASH | :TQ10003 | 71698 | 980K| | 8 (0)| 00:00:01 | | | Q1,03 | P->P | HASH |
| 16 | PX BLOCK ITERATOR | | 71698 | 980K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,03 | PCWC | |
|* 17 | INDEX FAST FULL SCAN | X_x_ref | 71698 | 980K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,03 | PCWP | |
| 18 | VIEW | | 22M| 402M| | 52253 (6)| 00:04:28 | | | Q1,10 | PCWP | |
|* 19 | HASH JOIN RIGHT OUTER | | 22M| 1524M| | 52253 (6)| 00:04:28 | | | Q1,10 | PCWP | |
| 20 | PX RECEIVE | | 1673K| 28M| | 706 (3)| 00:00:04 | | | Q1,10 | PCWP | |
| 21 | PX SEND HASH | :TQ10008 | 1673K| 28M| | 706 (3)| 00:00:04 | | | Q1,08 | P->P | HASH |
| 22 | VIEW | | 1673K| 28M| | 706 (3)| 00:00:04 | | | Q1,08 | PCWP | |
|* 23 | VIEW | | 1673K| 111M| | 706 (3)| 00:00:04 | | | Q1,08 | PCWP | |
| 24 | WINDOW SORT | | 1673K| 63M| 192M| 706 (3)| 00:00:04 | | | Q1,08 | PCWP | |
| 25 | PX RECEIVE | | 1673K| 63M| | 695 (2)| 00:00:04 | | | Q1,08 | PCWP | |
| 26 | PX SEND HASH | :TQ10004 | 1673K| 63M| | 695 (2)| 00:00:04 | | | Q1,04 | P->P | HASH
| 27 | PX BLOCK ITERATOR | | 1673K| 63M| | 695 (2)| 00:00:04 | 1 | 6 | Q1,04 | PCWC |
|* 28 | TABLE ACCESS FULL | SAT_trj55etu | 1673K| 63M| | 695 (2)| 00:00:04 | 1 | 6 | Q1,04 | PCWP |
| 29 | PX RECEIVE | | 22M| 1143M| | 51528 (6)| 00:04:25 | | | Q1,10 | PCWP |
| 30 | PX SEND HASH | :TQ10009 | 22M| 1143M| | 51528 (6)| 00:04:25 | | | Q1,09 | P->P | HASH
|* 31 | HASH JOIN RIGHT OUTER | | 22M| 1143M| | 51528 (6)| 00:04:25 | | | Q1,09 | PCWP |
| 32 | PX RECEIVE | | 504K| 6893K| | 167 (3)| 00:00:01 | | | Q1,09 | PCWP |
| 33 | PX SEND BROADCAST | :TQ10005 | 504K| 6893K| | 167 (3)| 00:00:01 | | | Q1,05 | P->P | BROADCAST
| 34 | VIEW | | 504K| 6893K| | 167 (3)| 00:00:01 | | | Q1,05 | PCWP |
|* 35 | HASH JOIN | | 504K| 21M| | 167 (3)| 00:00:01 | | | Q1,05 | PCWP |
| 36 | PX BLOCK ITERATOR | | 692K| 16M| | 67 (2)| 00:00:01 | 1 | 6 | Q1,05 | PCWC |
|* 37 | INDEX FAST FULL SCAN | X_order | 692K| 16M| | 67 (2)| 00:00:01 | 1 | 6 | Q1,05 | PCWP |
| 38 | BUFFER SORT | | | | | | | | | Q1,05 | PCWC |
| 39 | PX RECEIVE | | 698K| 12M| | 98 (3)| 00:00:01 | | | Q1,05 | PCWP |
| 40 | PX SEND BROADCAST LOCAL| :TQ10001 | 698K| 12M| | 98 (3)| 00:00:01 | | | Q1,01 | P->P | BCSTLOCAL
| 41 | PX BLOCK ITERATOR | | 698K| 12M| | 98 (3)| 00:00:01 | 1 | 6 | Q1,01 | PCWC |
|* 42 | INDEX FAST FULL SCAN | X_ch_order | 698K| 12M| | 98 (3)| 00:00:01 | 1 | 6 | Q1,01 | PCWP |
|* 43 | HASH JOIN RIGHT OUTER | | 22M| 846M| | 51344 (6)| 00:04:24 | | | Q1,09 | PCWP |
| 44 | PX RECEIVE | | 71698 | 1400K| | 8 (0)| 00:00:01 | | | Q1,09 | PCWP |
| 45 | PX SEND HASH | :TQ10006 | 71698 | 1400K| | 8 (0)| 00:00:01 | | | Q1,06 | P->P | HASH
| 46 | PX BLOCK ITERATOR | | 71698 | 1400K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,06 | PCWC |
|* 47 | INDEX FAST FULL SCAN | X_x_ref | 71698 | 1400K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,06 | PCWP |
| 48 | BUFFER SORT | | | | | | | | | Q1,09 | PCWC |
| 49 | PX RECEIVE | | 22M| 423M| | 51319 (6)| 00:04:24 | | | Q1,09 | PCWP |
| 50 | PX SEND HASH | :TQ10000 | 22M| 423M| | 51319 (6)| 00:04:24 | | | | S->P | HASH
| 51 | PARTITION RANGE ALL | | 22M| 423M| | 51319 (6)| 00:04:24 | 1 | 6 | | |
| 52 | TABLE ACCESS FULL | exper | 22M| 423M| | 51319 (6)| 00:04:24 | 1 | 6 | | |
Predicate Information (identified by operation id):
5 - access("BS"."mand"="tk_pla"."mand"(+) AND "BS"."thk1"="tk_pla"."thk1"(+))
9 - access("tk_pla"."mand"="x_ref"."mand"(+) AND "tk_pla"."thk1INDIVIDUAL"="x_ref"."thk1ORIGIN"(+))
13 - filter("tk_pla"."finishDate" IS NULL AND "tk_pla"."_to" IS NULL)
17 - filter("finishDate"(+) IS NULL)
19 - access("exper"."mand"="trj55"."mand"(+) AND "exper"."thk1"="trj55"."thk1"(+) AND
"exper"."sustainID"="trj55"."sustainID"(+))
23 - filter("liqudateStep"=1 OR "liqu_retuID" IS NULL OR "SELLING_retuID" IS NOT NULL)
28 - filter("finishDate" IS NULL)
31 - access("exper"."mand"="V2O"."mand"(+) AND "exper"."sustainID"="V2O"."sustainID"(+))
35 - access("olr"."mand"="O"."mand" AND "olr"."sustainORDERNO"="O"."sustainORDERNO")
37 - filter("olr"."finishDate" IS NULL)
42 - filter("O"."finishDate" IS NULL)
43 - access("exper"."mand"="mand"(+) AND "exper"."thk1"="thk1ORIGIN"(+))
47 - filter("finishDate"(+) IS NULL)
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
db_file_multiblock_read_count integer 32
db_block_size integer 8192
parallel_max_servers integer 17
parallel_min_percent integer 0
parallel_min_servers integer 0
parallel_server boolean FALSE
parallel_server_instances integer 1
parallel_threads_per_cpu integer 2
(actually workload stats are missing)
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1644.207
SYSSTATS_MAIN IOSEEKTIM 3.775
SYSSTATS_MAIN IOTFRSPEED 6059.372
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED 1663
{code}
Edited by: TanteKaethe on May 26, 2009 1:38 PM -
100% CPU using LabView 7.1 and DSC module
Seven years ago I used BridgeView and PXI to execute a project, and the results were so good that after that initial system, I installed one more using BridgeView, and three more using LabView 7.1.
BridgeView is working very well, but lately, LabView 7.1 is giving me more and more problems. It all started in a system running LabView 7.1 and DSC on Windows XP, using a PXI-8187 controller with a PXI-1042 chassis. I have two PXI-6533 digital I/O boards, one PXI-6030E multifunction, one PXI-6713 analog output board, one PXI-6602 counter board and one PXI-8422 serial com. board. In may/06, all of the sudden, the CPU went to a 100% use. Since I am running PID's to control a flash-butt welding machine in a steel factory, this was extremely dangerous. I changed the controller and everything went back to normal. It was running fine until december/06, when the same behavior appeared again. This time changing the controller did not help. We increased the system memory, from 256 MB to 512 MB and everything worked fine. But one month later (january/07) the fault reappeared. This time we changed the chassis and from that moment to this time, we are running smoothly.
Application problems were suspect from the very first time this problem appeared, but I was unable to identify the source, if any. I used PROFILE VI's and apparently the write/read tags were taking all the processor resources. However, changing the routines and disabling communications, and optimizing CPU intensive programs never solved the CPU overload.
Until now, I was aware of only one system showing this erratic behavior. But today I went to check another system, with a totally different application. This one is used to measure the thickness of the steel sheet on a rolling mill. Is not so resource-intensive, but the maintenance folks told me that every time they turned off this particular system, they always had problems trying to turn it on.
I was suspecting of a PLC-communication related issue, but what I found turned my alarms on. I turned off the system, which was fully functional, and turned it back on, and there it was, CPU load at 100%!. Is exactly the same problem that I have on the welder. This system has a PXI-8184, a PXI-1042 chassis, Windows XP, one PXI-6030E, one PXI-6713 and one PXI-6533. I battled for 20 minutes to put the system back in normal conditions.
I specified every single board, installed everything and programmed all the applications. The BridgeView applications have never showed anything like this. I am using the DSC (Datalogging and Supervisory Control Module) on both applications, and the Lookout Protocol Drivers are communicating to Modicon PLC's.
Please, I need help to solve this issue. I believe none of your actual Knowledge Base "100% CPU" articles apply to my case...
Thanks in advance...
Antonio Jimenez
[email protected]Thanks for your reply...
Yes, sometimes I have the feeling that the systems works again because some file or database gets initialized after so many reboots.
Intentionally I turned off all the events and alarm logging to disk. Also the historical data logging is disabled. This is done by code, every time the main VI is started. This was included precisely to save CPU processing power. However, I am communicating to PLC's, and of course I have to declare variables inside the citadel database to make the communication possible.
Right now I can't have access to the application, because the mill is rolling, but during the next maintenance stop I will check the database location and size, and I could change the directory location the next time the fault comes up. -
All programs using 100% CPU, freezing, crashing, -10810, -600, and -1712 errors
Okay, so. I have a Macbook Pro from December 2012, a little over a year old.
Version 10.9.1, running Mavericks
Processor 2.4 GHz Intel Core i7
Memory 8 GB
Startup Disk - Macintosh HD
I can send more info if I need to. I'm a graphic designer using Photoshop, Illustrator, and InDesign usually simultaneously, as well as Spotify, Messages, Sparrow (mail), Stickies, Tweetdeck, and Evernote. I also use a wireless mouse, drawing tablet, and second screen. This has never been a problem (I mean, my old computer had 4 GB memory and handled these programs just fine, except for Final Cut Pro 7) up until recently.
For the last two months, my computer has been seriously out of whack.
I'm constantly having to refresh finder
Every time I open Google Chrome, all of my extentions crash immediately and any website I try to go to is extremely sluggish (but Safari works)
The dock freezes
Constant error messages: 1712, 10810, 600
Audio fails randomly
Overall, the problem seems to be that I can't do more than one thing at a time -- I can't take a screenshot if more than two programs are open, I can't open DMG files, I can't open Spotify if any Creative Suite program is open. I've been watching the activity monitor, and it seems like each program is trying to use 100% CPU, which doesn't seem right. I have to close every program to work in Photoshop, which makes me miss calls and emails.
I've tried restarting in safe mode, verifiyng the disk and repairing permissions, I used time capsule to restore to a time before it was happening, and restored my user profile in Chrome. I'm at my complete wit's end trying to figure this out! I feel like my next step is to just reinstall my OS completely, but that would be a major setback for getting my work done, and I'm not even sure that would work.
I've looked on other forums and it seems like the Mail app typically causes problems, but I don't even use it, I use Sparrow.
PLEASE PLEASE PLEASE HELPLaunch error -10810 in Mavericks
I have the same issue since a couple of days. Nothing that I found in the community (rebuilding launch info using Onyx or manually deleting the apple.com-launch prefs) has helped me so far. Only some apps are affected (PasswordWallet 4.7.4 among them).
I can launch it once and it will run fine as long as it’s open. Next time it refuses to open displaying the error -10810 message instead. I trash the app and use a fresh one off the vendor’s dmg file I downloaded and the sequence repeats.
MacPro 2.8 QuadCore Intel Xeon, 16 Gig RAM, Samsung SSD 840 PRO Series HD plus 3 more regular 3,5“ HDs, Mavericks 10.9.3 -
100% CPU Usage, Sound configuration Error and Unknown Error (0xE8000001)
Hi, I just bought a iPod Touch - amazing iPod I must say.
Pluged it in to my Windows Xp to sync some music. (I've been using iTunes for several years now and just upgraded from a 1st generation iPod nano to a 16 Gb touch).
It connected very well and I was ready to sync but then I made a stupid mistake - I updated iTunes to be sure that every thing was up to date.
After the update I get an error about my sound configuration (I've tried uninstalling QuickTime and installing again - didn't work). iTunes open up and starts to sync and now a second issue apears. It uses all of my CPU - flatlinig at 100%, so I cannot use my computer at all. It is now syncing but extremely slow - one song takes about a minute. Now the iPod touch starts to say these weird sounds and rebooting every 20 seconds or so. Finally I get an eroor in iTunes saying that there has been an unknown error (0xE8000001).
So I'm stuck with iTunes not working and no songs on my iPod.. :o(
What to do..?Hi, I just bought a iPod Touch - amazing iPod I must say.
Pluged it in to my Windows Xp to sync some music. (I've been using iTunes for several years now and just upgraded from a 1st generation iPod nano to a 16 Gb touch).
It connected very well and I was ready to sync but then I made a stupid mistake - I updated iTunes to be sure that every thing was up to date.
After the update I get an error about my sound configuration (I've tried uninstalling QuickTime and installing again - didn't work). iTunes open up and starts to sync and now a second issue apears. It uses all of my CPU - flatlinig at 100%, so I cannot use my computer at all. It is now syncing but extremely slow - one song takes about a minute. Now the iPod touch starts to say these weird sounds and rebooting every 20 seconds or so. Finally I get an eroor in iTunes saying that there has been an unknown error (0xE8000001).
So I'm stuck with iTunes not working and no songs on my iPod.. :o(
What to do..? -
100% CPU usage when importing cd and downloading from store, please help!
I am using itunes 8.2.1.6. The problem is that whenever I import a cd or download any music from the store my cpu runs at 100%. I have a pentium 4 (which manages nicely with any other task, even importing cd's with another programe) with 3gb RAM.
Is anybody else having this problem? Does anybody know how to fix it?Mr. Bump
-
Some web pages causing 100% CPU use of iexplore.exe since Flash update
I'm having a problem with certain Amazon.com pages hanging my
Internet Explorer 6 using Flash Player 10,0,12,36, causing 100% CPU
use for iexplore.exe and requiring me to End Task to quit. All the
pages effected have an interactive mouseover Size and Color chart
that intially says "Loading" but then says "Select Size and Color"
once loaded. One mouseovers the various color patches and size
options, each time giving item availability in that option. When
the pages hang the IE browser with 100% CPU use that chart never
gets to the "Select Size and Color" point, instead stuck at the
"Loading" status. This happens most times, but not every time.
Sometimes the pages load correctly, after a brief lag as it loads
the chart.
Amazon pages without this chart load fine.
The start of this problem coincides with updating Flash.
I can prevent the problem from happening almost every time if
I can quickly get my cursor into that chart area while the page
begins loading. If I allow the pages to load fully with no
interaction they will hang almost every time.
I have not noticed any problems on those same web pages using
Firefox using Flash Player 9,0,124,0
I also have not noticed any issues with other sites using
Internet Explorer either. (YouTube, QVC, CNN...etc, all OK.)
I had posted for assistance on the Experts Exchange site and
there was some debate on whether the chart was a Java or
Flash-based chart, so initially it was being approached as a
possible Java issue, so I removed all Java versions on the system
and installed various versions, but the same problem persists.
I've downloaded but not run the Flash Uninstaller, as I'm
reluctant to uninstall the Firefox Flash version without knowing
for sure I could install 9,0,124,0 again.
I've downloaded an archived fp9_archive.zip, which seems to
indicate the contained files flashplayer9r124_winax.exe (Internet
Explorer) and flashplayer9r124_win.exe (Netscape) would be versions
9,0,124,0 to install after running the uninstaller.
Can anyone check a few of the links below and see if the
"Select Size and Color" chart is Flash based? If so, would
executing the files listed above install 9,0,124,0 into my
respective browsers again?
http://www.amazon.com/FCS-Regular-7mm-Surf-Leash/dp/B00149XJ68
http://www.amazon.com/Womens-Classic-Short-UGG-Boots/dp/B00064NH8W/ref=pd_ecc_rvi_cart_3
http://www.amazon.com/Columbia-Sportswear-Womens-Benton-Springs/dp/B0006M6IQ2/ref=pd_ecc_r vi_cart_2
http://www.amazon.com/Ladies-Chenille-Zip-Cardigan-Sweater/dp/B001E0YJ0C/ref=pd_ecc_rvi_ca rt_4
XP IE 6 (error module : MSHTML.DLL)
Flash Player version 10,0,12,36
Firefox
Flash Player version 9,0,124,0
Thank you-
VickieI'm attempting to troubleshoot an issue with Amazon web pages
since I've updated my Flash player. I would appreciate if someone
could take a look at my initial post and advise if the issue seems
to be Flash related.
Thank you.
I'm having a problem with certain Amazon.com pages hanging my
Internet Explorer 6 using Flash Player 10,0,12,36, causing 100% CPU
use for iexplore.exe and requiring me to End Task to quit. All the
pages effected have an interactive mouseover Size and Color chart
that intially says "Loading" but then says "Select Size and Color"
once loaded. One mouseovers the various color patches and size
options, each time giving item availability in that option. When
the pages hang the IE browser with 100% CPU use that chart never
gets to the "Select Size and Color" point, instead stuck at the
"Loading" status. This happens most times, but not every time.
Sometimes the pages load correctly, after a brief lag as it loads
the chart.
Amazon pages without this chart load fine.
The start of this problem coincides with updating Flash.
I can prevent the problem from happening almost every time if
I can quickly get my cursor into that chart area while the page
begins loading. If I allow the pages to load fully with no
interaction they will hang almost every time.
I have not noticed any problems on those same web pages using
Firefox using Flash Player 9,0,124,0
I also have not noticed any issues with other sites using
Internet Explorer either. (YouTube, QVC, CNN...etc, all OK.)
I had posted for assistance on the Experts Exchange site and
there was some debate on whether the chart was a Java or
Flash-based chart, so initially it was being approached as a
possible Java issue, so I removed all Java versions on the system
and installed various versions, but the same problem persists.
I've downloaded but not run the Flash Uninstaller, as I'm
reluctant to uninstall the Firefox Flash version without knowing
for sure I could install 9,0,124,0 again.
I've downloaded an archived fp9_archive.zip, which seems to
indicate the contained files flashplayer9r124_winax.exe (Internet
Explorer) and flashplayer9r124_win.exe (Netscape) would be versions
9,0,124,0 to install after running the uninstaller.
Can anyone check a few of the links below and see if the
"Select Size and Color" chart is Flash based? If so, would
executing the files listed above install 9,0,124,0 into my
respective browsers again?
http://www.amazon.com/FCS-Regular-7mm-Surf-Leash/dp/B00149XJ68
http://www.amazon.com/Womens-Classic-Short-UGG-Boots/dp/B00064NH8W/ref=pd_ecc_rvi_cart_3
http://www.amazon.com/Columbia-Sportswear-Womens-Benton-Springs/dp/B0006M6IQ2/ref=pd_ecc_r vi_cart_2
http://www.amazon.com/Ladies-Chenille-Zip-Cardigan-Sweater/dp/B001E0YJ0C/ref=pd_ecc_rvi_ca rt_4
XP IE 6 (error module : MSHTML.DLL)
Flash Player version 10,0,12,36
Firefox
Flash Player version 9,0,124,0 -
I have been experiencing a strange problem with itunes (7.2) for the last week which I have never encountered before.
It all started when I doubled clicked on a mpg hd mpg file (1920 x 1080) by accident rather than right clicking and hitting play with windows media player. Ituens opened up but did not add this file to the library because it's incompatible. However, I tunes at that time stared using 100% cpu usage on my system and lagging to death.
Now every time I open Itunes it takes 2 minutes to appear after opening it, then another minute to respond before it actually does anything if you click on anything such as library, store or the file menues. Once you click on any of those, or any link in the store once again you have to wait 2 minutes for itunes to actually go there and start responding again. Playing of songs or videos is extreamly choppy.
To fix this problem I have tried rebooting, reinstalling itunes, and trying ot see if there is anything visible in my library that could cause the problem when loading (which there is not)
This problem has been going on for a week now, and itunes uses 100% cpu usage at all times while open, it never slips to 99%.
This is happening on my laptop with Windows Vista x64 Ultimate, AMD Athlon x2 4800+ and 2GB of ram.
Does anyone know what might be going on here or how I could fix this rather annoying problem so I can use ituens normaly again.
I'm just glade my processor has more than one core, so my system doesn't bog down and stop. (Itunes shows 50% total system cpu ussage at all times or 100% single core)So, are you on XP Pro or Vista Ultimate? Kinda confused.
I'm hedging my bets on the file being corrupted. You say you don't get these problems when running the file from WMP?
BTW, have you restarted your PC since the aforementioned 100% CPU usage?
If you haven't, you could try opening up task manager (ctrlshiftesc) and killing the iTuneshelper process along with iTunes. I'd do the kill process tree thing. Do check if there's anything else using up memory.
If all else fails, restart. If you've done that already, then we can start looking at other options. -
HELP PLEASE - syslogd gone mad taking 100% CPU!!!!!!!!!!!!!!!!!
Hi PLEASE HELP
I have no idea what is going on but syslogd has suddenly started taking 100% CPU.
This started around 6pm this evening and despite 5 restarts 2 hours later it is STILL consuming 100% CPU.
Kicks in as soon as the machine has finished booting.
Did stop for no reason for about 10 minutes then started again!!!!!!!!!!!!!!!
RobinThis topic should be a Sticky untill Apple releases a fix for the issue!
Also these 2 Links are very useful!
http://smartic.us/2007/11/8/leopard-100-cpu-usage-caused-by-syslogd-and-possibly -time-machine
http://julianschrader.de/20080131-100-cpu-usage-caused-by-syslogd-leopard/ -
环境：db：10.2.0.4.0 system：hp-ux 11.31
近期系统在访问高峰时，性能严重下降，分析awr得到信息为
Elapsed: 60.20 (mins)
DB Time: 1,916.95 (mins) 系统负担非常严重
Library Hit %: 99.60 Soft Parse %: 99.44
Execute to Parse %: -22.89 重解析现象很严重
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
CPU time 26,661 23.2
cursor: pin S 5,346,339 11,727 2 10.2 Other
latch: cache buffers chains 25,963 5,205 200 4.5 Concurrency
db file scattered read 710,601 2,698 4 2.3 User I/O
latch: library cache 6,743 2,087 309 1.8 Concurrenc
cursor: pin S事件为等待时间第一， 一般判读为系统并发sql语句过多，由于没有之前正常状态的awr报告作为对比，所以对于这个系统问题的根源和解决办法不是很清楚，对于应用方面，减少并发sql语句，绑定变量等，在数据库方面调整ession_cached_cursors参数，增加sharepool空间，由于水平有限只能知道这么多，希望得到更加深入的分析。谢谢
附部分awr（如何上传完整报告？）WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst num Release RAC Host
ORCL 1183953527 orcl 1 10.2.0.4.0 NO HP-UX-1
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 36825 14-8ÔÂ -12 09:00:16 1426 1.5
End Snap: 36826 14-8ÔÂ -12 10:00:29 1630 1.4
Elapsed: 60.20 (mins)
DB Time: 1,916.95 (mins)
Report Summary
Cache Sizes
Begin End
Buffer Cache: 9,216M 9,216M Std Block Size: 8K
Shared Pool Size: 6,144M 6,144M Log Buffer: 14,348K
Load Profile
Per Second Per Transaction
Redo size: 85,077.91 5,632.74
Logical reads: 323,798.90 21,437.69
Block changes: 489.98 32.44
Physical reads: 4,190.38 277.43
Physical writes: 36.21 2.40
User calls: 7,273.13 481.53
Parses: 1,499.45 99.27
Hard parses: 8.39 0.56
Sorts: 150.73 9.98
Logons: 1.72 0.11
Executes: 1,220.19 80.78
Transactions: 15.10
% Blocks changed per Read: 0.15 Recursive Call %: 9.01
Rollback per transaction %: 12.68 Rows per Sort: 118.78
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 99.99 Redo NoWait %: 99.99
Buffer Hit %: 98.71 In-memory Sort %: 100.00
Library Hit %: 99.60 Soft Parse %: 99.44
Execute to Parse %: -22.89 Latch Hit %: 99.95
Parse CPU to Parse Elapsd %: 6.61 % Non-Parse CPU: 94.79
Shared Pool Statistics
Begin End
Memory Usage %: 92.12 92.19
% SQL with executions>1: 90.33 87.07
% Memory for SQL w/exec>1: 90.37 88.32
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
CPU time 26,661 23.2
cursor: pin S 5,346,339 11,727 2 10.2 Other
latch: cache buffers chains 25,963 5,205 200 4.5 Concurrency
db file scattered read 710,601 2,698 4 2.3 User I/O
latch: library cache 6,743 2,087 309 1.8 Concurrency
Time Model Statistics
Total time in database user-calls (DB Time): 115017.1s
Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic
Ordered by % or DB time desc, Statistic name
Statistic Name Time (s) % of DB Time
sql execute elapsed time 89,472.10 77.79
DB CPU 26,660.94 23.18
parse time elapsed 20,759.09 18.05
PL/SQL execution elapsed time 322.11 0.28
hard parse elapsed time 256.97 0.22
connection management call elapsed time 90.04 0.08
failed parse elapsed time 44.23 0.04
hard parse (sharing criteria) elapsed time 27.70 0.02
sequence load elapsed time 13.43 0.01
PL/SQL compilation elapsed time 10.03 0.01
hard parse (bind mismatch) elapsed time 2.82 0.00
repeated bind elapsed time 0.10 0.00
inbound PL/SQL rpc elapsed time 0.05 0.00
DB time 115,017.09
background elapsed time 451.46
background cpu time 47.64
Back to Wait Events Statistics
Back to Top
Wait Class
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
Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
Other 5,359,517 0.06 12,985 2 98.23
Concurrency 41,787 7.97 7,899 189 0.77
User I/O 1,541,553 0.00 4,385 3 28.25
Network 28,263,892 0.00 515 0 518.03
Commit 31,974 1.02 489 15 0.59
Application 7,028 1.04 232 33 0.13
System I/O 41,367 0.00 118 3 0.76
Configuration 48 0.00 8 177 0.00
Back to Wait Events Statistics
Back to Top
Wait Events
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)
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
cursor: pin S 5,346,339 0.00 11,727 2 97.99
latch: cache buffers chains 25,963 0.00 5,205 200 0.48
db file scattered read 710,601 0.00 2,698 4 13.02
latch: library cache 6,743 0.00 2,087 309 0.12
db file sequential read 657,512 0.00 1,191 2 12.05
latch free 7,839 0.10 973 124 0.14
read by other session 153,818 0.04 489 3 2.82
log file sync 31,974 1.02 489 15 0.59
SQL*Net more data to client 2,454,333 0.00 308 0 44.98
enq: TX - row lock contention 82 89.02 227 2762 0.00
latch: library cache lock 968 0.00 211 218 0.02
latch: session allocation 1,369 0.00 196 143 0.03
latch: shared pool 1,801 0.00 177 98 0.03
SQL*Net message to client 25,709,776 0.00 130 0 471.22
latch: row cache objects 2,772 0.00 113 41 0.05
log file parallel write 33,654 0.00 105 3 0.62
SQL*Net more data from client 99,783 0.00 77 1 1.83
buffer busy waits 198 24.24 64 325 0.00
latch: cache buffers lru chain 204 0.00 35 173 0.00
cursor: pin S wait on X 3,284 99.97 32 10 0.06
LGWR wait for redo copy 3,493 91.24 32 9 0.06
latch: object queue header operation 91 0.00 8 91 0.00
latch: In memory undo latch 43 0.00 8 191 0.00
db file parallel read 530 0.00 7 14 0.01
enq: SQ - contention 8 0.00 5 670 0.00
log file sequential read 400 0.00 5 13 0.01
SQL*Net break/reset to client 6,942 0.00 5 1 0.13
Streams AQ: qmn coordinator waiting for slave to start 1 100.00 5 4889 0.00
control file parallel write 1,844 0.00 5 2 0.03
latch: enqueue hash chains 55 0.00 4 76 0.00
Log archive I/O 344 0.00 3 9 0.01
wait list latch free 104 0.00 2 20 0.00
latch: undo global data 9 0.00 2 191 0.00
log file switch (checkpoint incomplete) 11 0.00 2 150 0.00
log file switch completion 28 0.00 1 53 0.00
os thread startup 11 0.00 1 132 0.00
control file sequential read 5,093 0.00 0 0 0.09
latch: redo allocation 4 0.00 0 68 0.00
enq: RO - fast object reuse 4 0.00 0 59 0.00
local write wait 50 0.00 0 2 0.00
latch: library cache pin 1 0.00 0 95 0.00
latch: cache buffer handles 1 0.00 0 80 0.00
enq: CF - contention 2 0.00 0 19 0.00
direct path read temp 18,314 0.00 0 0 0.34
log file single write 32 0.00 0 1 0.00
enq: TX - index contention 3 0.00 0 5 0.00
direct path write temp 25 0.00 0 0 0.00
reliable message 4 0.00 0 0 0.00
direct path read 350 0.00 0 0 0.01
Background Wait Events
ordered by wait time desc, waits desc (idle events last)
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
events in waitclass Other 2,441 130.93 140 57 0.04
log file parallel write 33,654 0.00 105 3 0.62
log file sequential read 400 0.00 5 13 0.01
control file parallel write 1,844 0.00 5 2 0.03
buffer busy waits 4 75.00 3 832 0.00
Log archive I/O 344 0.00 3 9 0.01
os thread startup 11 0.00 1 132 0.00
latch: library cache 3 0.00 1 220 0.00
control file sequential read 4,390 0.00 0 0 0.08
latch: shared pool 1 0.00 0 309 0.00
db file sequential read 82 0.00 0 4 0.00
db file scattered read 56 0.00 0 4 0.00
log file single write 32 0.00 0 1 0.00
latch: library cache lock 1 0.00 0 26 0.00
direct path read 344 0.00 0 0 0.01
direct path write 343 0.00 0 0 0.01
latch: In memory undo latch 1 0.00 0 0 0.00
Back to Wait Events Statistics
Back to Top
Operating System Statistics
Statistic Total
AVG_BUSY_TIME 355,404
AVG_IDLE_TIME 5,624
AVG_IOWAIT_TIME 1,350
AVG_SYS_TIME 24,626
AVG_USER_TIME 330,677
BUSY_TIME 2,844,143
IDLE_TIME 45,639
IOWAIT_TIME 11,363
SYS_TIME 197,893
USER_TIME 2,646,250
LOAD 8
OS_CPU_WAIT_TIME ###############
RSRC_MGR_CPU_WAIT_TIME 0
VM_IN_BYTES 0
VM_OUT_BYTES 0
PHYSICAL_MEMORY_BYTES 51,504,857,088
NUM_CPUS 8
NUM_CPU_SOCKETS 8
Back to Wait Events Statistics
Back to Top
Service Statistics
ordered by DB Time
Service Name DB Time (s) DB CPU (s) Physical Reads Logical Reads
orcl 108,264.60 24,956.90 12,796,071 1,110,466,840
SYS$USERS 6,748.20 1,707.20 2,350,206 59,196,825
SYS$BACKGROUND 0.00 0.00 1,188 41,361
Back to Wait Events Statistics
Back to Top
Service Wait Class Stats
Wait Class info for services in the Service Statistics section.
Total Waits and Time Waited displayed for the following wait classes: User I/O, Concurrency, Administrative, Network
Time Waited (Wt Time) in centisecond (100th of a second)
Service Name User I/O Total Wts User I/O Wt Time Concurcy Total Wts Concurcy Wt Time Admin Total Wts Admin Wt Time Network Total Wts Network Wt Time
orcl 1354220 373545 40097 757402 0 0 26777629 50042
SYS$USERS 186115 64780 1563 27129 0 0 1456144 1238
SYS$BACKGROUND 1221 183 23 584 0 0 0 0
Back to Wait Events Statistics
Back to Top
SQL ordered by Elapsed Time
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
% Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
Elapsed Time (s) CPU Time (s) Executions Elap per Exec (s) % Total DB Time SQL Id SQL Module SQL Text
17,352 1,151 282,032 0.06 15.09 58nqcgq93qdpp w3wp.exe SELECT sysdate FROM dual
13,412 3,344 3,516 3.81 11.66 gpz6zsfjvvgx7 obilling.exe select sum ( costs ) , sum ( ...
9,176 2,771 393 23.35 7.98 ajp712h079d57 dosage.exe select DIAG_DESC from outp_mr ...
8,351 2,411 3,163 2.64 7.26 9skkhx9qfmzjy outpdoct.exe SELECT "OUTP_TREAT_REC"."VIS...
6,278 2,042 2,598 2.42 5.46 f9nfgywd1dzbc outpdoct.exe SELECT :"SYS_B_0" del_indica...
3,406 1,070 729 4.67 2.96 3fgaurmna0hx9 obilling.exe SELECT "OUTP_PRESC_T"."VISIT...
3,228 867 9,221 0.35 2.81 3vy04kpknkqgk w3wp.exe select T1.REMIND_DATETIME, T1....
2,802 514 214 13.09 2.44 f4q13jvt6n8r8 mzcx.exe SELECT DISTINCT "OUTPBILL"."...
2,406 533 725 3.32 2.09 87mazvgqfas1z obilling.exe SELECT "OUTP_TREAT_REC_T"."V...
2,340 535 724 3.23 2.03 f4xrxypn2cpkm obilling.exe SELECT "OUTP_PRESC_T"."VISIT...
2,303 781 15,143 0.15 2.00 89yw129xmhchc w3wp.exe select a.PATIENT_ID, a.VISIT_I...
1,572 449 4,748 0.33 1.37 0nwg8cxxzcb0m w3wp.exe select T1.REMIND_DATETIME, T1....
1,258 135 44 28.58 1.09 cnuj5dstf2559 outpdoct.exe SELECT "DOCT_DRUG_PRESC_DE...
Back to SQL Statistics
Back to Top
SQL ordered by CPU Time
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
% Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
CPU Time (s) Elapsed Time (s) Executions CPU per Exec (s) % Total DB Time SQL Id SQL Module SQL Text
3,344 13,412 3,516 0.95 11.66 gpz6zsfjvvgx7 obilling.exe select sum ( costs ) , sum ( ...
2,771 9,176 393 7.05 7.98 ajp712h079d57 dosage.exe select DIAG_DESC from outp_mr ...
2,411 8,351 3,163 0.76 7.26 9skkhx9qfmzjy outpdoct.exe SELECT "OUTP_TREAT_REC"."VIS...
2,042 6,278 2,598 0.79 5.46 f9nfgywd1dzbc outpdoct.exe SELECT :"SYS_B_0" del_indica...
1,151 17,352 282,032 0.00 15.09 58nqcgq93qdpp w3wp.exe SELECT sysdate FROM dual
1,070 3,406 729 1.47 2.96 3fgaurmna0hx9 obilling.exe SELECT "OUTP_PRESC_T"."VISIT...
867 3,228 9,221 0.09 2.81 3vy04kpknkqgk w3wp.exe select T1.REMIND_DATETIME, T1....
781 2,303 15,143 0.05 2.00 89yw129xmhchc w3wp.exe select a.PATIENT_ID, a.VISIT_I...
540 825 1,790 0.30 0.72 cw74b4gm99xd5 ORACLE.EXE SELECT "A4"."PATIENT_ID", TO_C...
535 2,340 724 0.74 2.03 f4xrxypn2cpkm obilling.exe SELECT "OUTP_PRESC_T"."VISIT...
533 2,406 725 0.73 2.09 87mazvgqfas1z obilling.exe SELECT "OUTP_TREAT_REC_T"."V...
514 2,802 214 2.40 2.44 f4q13jvt6n8r8 mzcx.exe SELECT DISTINCT "OUTPBILL"."...
449 1,572 4,748 0.09 1.37 0nwg8cxxzcb0m w3wp.exe select T1.REMIND_DATETIME, T1....
135 1,258 44 3.06 1.09 cnuj5dstf2559 outpdoct.exe SELECT "DOCT_DRUG_PRESC_DE...
Back to SQL Statistics
Back to Top
SQL ordered by Gets
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
Total Buffer Gets: 1,169,640,302
Captured SQL account for 71.4% of Total
Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text
158,325,351 3,516 45,029.96 13.54 3344.37 13412.17 gpz6zsfjvvgx7 obilling.exe select sum ( costs ) , sum ( ...
142,486,001 3,163 45,047.74 12.18 2410.79 8351.24 9skkhx9qfmzjy outpdoct.exe SELECT "OUTP_TREAT_REC"."VIS...
107,954,245 2,598 41,552.83 9.23 2041.61 6278.17 f9nfgywd1dzbc outpdoct.exe SELECT :"SYS_B_0" del_indica...
54,640,906 729 74,953.23 4.67 1069.81 3405.85 3fgaurmna0hx9 obilling.exe SELECT "OUTP_PRESC_T"."VISIT...
54,464,191 15,143 3,596.66 4.66 781.43 2302.60 89yw129xmhchc w3wp.exe select a.PATIENT_ID, a.VISIT_I...
52,300,799 9,221 5,671.92 4.47 866.73 3228.09 3vy04kpknkqgk w3wp.exe select T1.REMIND_DATETIME, T1....
36,350,381 1,790 20,307.48 3.11 539.85 825.10 cw74b4gm99xd5 ORACLE.EXE SELECT "A4"."PATIENT_ID", TO_C...
28,097,571 1,132 24,821.18 2.40 105.62 304.33 44cpsg5hgwtv3 outpdoct.exe SELECT "CLINIC_MASTER"."NAME...
27,329,179 724 37,747.48 2.34 534.54 2339.79 f4xrxypn2cpkm obilling.exe SELECT "OUTP_PRESC_T"."VISIT...
27,276,384 725 37,622.60 2.33 532.84 2405.61 87mazvgqfas1z obilling.exe SELECT "OUTP_TREAT_REC_T"."V...
26,913,555 4,748 5,668.40 2.30 449.02 1571.69 0nwg8cxxzcb0m w3wp.exe select T1.REMIND_DATETIME, T1....
25,335,084 214 118,388.24 2.17 514.25 2802.12 f4q13jvt6n8r8 mzcx.exe SELECT DISTINCT "OUTPBILL"."...
12,756,154 4 3,189,038.50 1.09 73.99 592.57 4v3jxnrj4duq0 ºǫ́ÅäÒ©ÐÂ2012.07.31.exe SELECT "DRUG_PRESC_MASTER"....
Back to SQL Statistics
Back to Top
SQL ordered by Reads
Total Disk Reads: 15,136,657
Captured SQL account for 81.4% of Total
Physical Reads Executions Reads per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text
6,716,909 214 31,387.43 44.38 514.25 2802.12 f4q13jvt6n8r8 mzcx.exe SELECT DISTINCT "OUTPBILL"."...
3,642,877 44 82,792.66 24.07 134.64 1257.56 cnuj5dstf2559 outpdoct.exe SELECT "DOCT_DRUG_PRESC_DE...
1,707,395 12 142,282.92 11.28 56.42 470.82 bkkm26gd9ydjp prescent.exe SELECT "DRUG_PRESC_MASTER"....
208,221 4 52,055.25 1.38 73.99 592.57 4v3jxnrj4duq0 ºǫ́ÅäÒ©ÐÂ2012.07.31.exe SELECT "DRUG_PRESC_MASTER"....
137,856 0 0.91 383.09 1041.12 b1y7hxw5s572b ORACLE.EXE SELECT /*+ OPAQUE_TRANSFORM */...
45,210 1 45,210.00 0.30 136.24 617.92 9k2mtm738ffbk ORACLE.EXE SELECT "A1"."PATIENT_ID", "A1"...
21,692 0 0.14 44.82 288.67 5w6u29xnk192r ORACLE.EXE SELECT "A1"."TEST_NO", "A1"."I...
2,078 17,010 0.12 0.01 6.78 13.35 3ts97u1my91n4 testprn.exe SELECT "LAB"."LAB_TEST_ITEM...
539 1,732 0.31 0.00 124.85 289.44 0a96nnbzvb78j sjcj.exe select diag_desc , doctor fro...
224 14,499 0.02 0.00 1.75 2.81 adr24vcznhjhz C:\Documents and Settings\yj.ÐÄÄÚʵÑéÊÒ1.000\×À? SELECT COSTS , BILLING_INDICA...
Back to SQL Statistics
Back to Top
SQL ordered by Executions
Total Executions: 4,407,615
Captured SQL account for 43.0% of Total
Executions Rows Processed Rows per Exec CPU per Exec (s) Elap per Exec (s) SQL Id SQL Module SQL Text
324,063 324,042 1.00 0.00 0.00 1jzhjx524wyfm presdisp.exe select TRADE_PRICE , retail_p...
282,032 281,745 1.00 0.00 0.06 58nqcgq93qdpp w3wp.exe SELECT sysdate FROM dual
197,067 197,006 1.00 0.00 0.00 f0wzs9nc663bn obilling.exe select sysdate from dual
162,033 112,966 0.70 0.00 0.00 ak8wcxnbv0mq7 presdisp.exe select location from drug_stoc...
162,032 162,023 1.00 0.00 0.00 g982zswg09n71 presdisp.exe SELECT sum ( DRUG_STOCK.QUANTI...
152,651 1,296 0.01 0.00 0.00 ctc7t080mcrpr PACSVR.exe Select exam_master.*, exam_ma...
89,187 89,186 1.00 0.00 0.00 054n8y7sfgsjc anesmgr.exe select 1 from dual
53,088 24,076 0.45 0.00 0.00 fhzdwv4sgvurz ORACLE.EXE SELECT "A1"."END_DATE_TIME", S...
43,074 991 0.02 0.00 0.00 8kj11spfu1w5k ORACLE.EXE SELECT DISTINCT "A1"."LOG_DATE...
40,962 4,803 0.12 0.00 0.00 664crkjw8n47y doctws.exe select dept_code , ward_code ...
Back to SQL Statistics
Back to Top
SQL ordered by Parse Calls
Total Parse Calls: 5,416,394
Captured SQL account for 41.3% of Total
Parse Calls Executions % Total Parses SQL Id SQL Module SQL Text
457,941 152,651 8.45 ctc7t080mcrpr PACSVR.exe Select exam_master.*, exam_ma...
324,064 324,063 5.98 1jzhjx524wyfm presdisp.exe select TRADE_PRICE , retail_p...
281,992 282,032 5.21 58nqcgq93qdpp w3wp.exe SELECT sysdate FROM dual
197,067 197,067 3.64 f0wzs9nc663bn obilling.exe select sysdate from dual
162,033 162,033 2.99 ak8wcxnbv0mq7 presdisp.exe select location from drug_stoc...
162,032 162,032 2.99 g982zswg09n71 presdisp.exe SELECT sum ( DRUG_STOCK.QUANTI...
113,451 0 2.09 gbztx1wqkp1zw ORACLE.EXE SELECT * FROM "OPERATION_MASTE...
109,344 0 2.02 1gk864rffswjx ORACLE.EXE SELECT * FROM "PAT_VISIT"
104,957 0 1.94 dw9ggd0h86cw4 ORACLE.EXE SELECT * FROM "ADT_LOG"
89,187 89,187 1.65 054n8y7sfgsjc anesmgr.exe select 1 from dual
Back to SQL Statistics
Back to Top
SQL ordered by Sharable Memory
Only Statements with Sharable Memory greater than 1048576 are displayed
Sharable Mem (b) Executions % Total SQL Id SQL Module SQL Text
14,285,976 0.22 998p6b7d1q9bz ** SQL Text Not Available **
14,265,528 0.22 dsxd21s5bw5h3 ** SQL Text Not Available **
4,621,517 45 0.07 18h8s79av5v45 w3wp.exe select T1.REMIND_DATETIME, T1....
3,949,845 20 0.06 bn69cjprha24w w3wp.exe select T1.REMIND_DATETIME, T1....
3,407,101 41 0.05 5syt1sugfkg7c w3wp.exe select T1.REMIND_DATETIME, T1....
2,623,013 65 0.04 gh6391dujc994 w3wp.exe select T1.REMIND_DATETIME, T1....
2,314,741 30 0.04 49husy8txxw6h w3wp.exe select T1.REMIND_DATETIME, T1....
2,184,421 87 0.03 5a77mhab8fmq4 w3wp.exe select T1.REMIND_DATETIME, T1....
2,029,197 24 0.03 57wp7yk0ajprt w3wp.exe select T1.REMIND_DATETIME, T1....
2,028,837 5 0.03 csd4pjvrfpxry w3wp.exe select T1.REMIND_DATETIME, T1....
2,024,581 44 0.03 890zsd9cju097 w3wp.exe select T1.REMIND_DATETIME, T1....
1,925,949 39 0.03 cw4y41z3vnz8y w3wp.exe select T1.REMIND_DATETIME, T1....
1,793,389 71 0.03 gwx893aphkzw8 w3wp.exe select T1.REMIND_DATETIME, T1....
1,747,565 19 0.03 4p0vbj8qba0sj w3wp.exe select T1.REMIND_DATETIME, T1....
1,747,253 75 0.03 6hhka0kpch5bq w3wp.exe select T1.REMIND_DATETIME, T1....
1,746,061 60 0.03 cqbyt6m5m9f6g w3wp.exe select T1.REMIND_DATETIME, T1....
1,745,909 47 0.03 aatwks74mtqkx w3wp.exe select T1.REMIND_DATETIME, T1....
1,718,005 20 0.03 cmws54r2xv332 w3wp.exe select T1.REMIND_DATETIME, T1....
1,709,493 24 0.03 71zxrhv747290 w3wp.exe select T1.REMIND_DATETIME, T1....
1,265,905 1,585 0.02 a7c5z25vb0kvz obilling.exe SELECT COLUMN_NAME, DATA_TYPE...
1,132,605 30 0.02 9s6btksh172dz w3wp.exe select T1.REMIND_DATETIME, T1....
1,115,157 30 0.02 9s6btksh172dz w3wp.exe select T1.REMIND_DATETIME, T1....
1,055,029 105 0.02 da0pcbq6qxxqx w3wp.exe select T1.REMIND_DATETIME, T1....
Back to SQL Statistics
Back to Top
SQL ordered by Version Count
Only Statements with Version Count greater than 20 are displayed
Version Count Executions SQL Id SQL Module SQL Text
698 998p6b7d1q9bz ** SQL Text Not Available **
697 dsxd21s5bw5h3 ** SQL Text Not Available **
57 192 9mrhw217pc809 DOCTWS.EXE select MR_CODE , mr_attr , m...
43 1,307 53mkjqn5tdptj examapt.exe SELECT to_char ( last_updt_dat...
32 125 399071urkdx7n admit.exe SELECT to_char ( last_updt_dat...
26 564 14fz7s749tx24 prescent.exe Select drug_spec , batch_no , ...
Back to SQL Statistics
Back to Top
Complete List of SQL Text
SQL Id SQL Text
054n8y7sfgsjc select 1 from dual
0a96nnbzvb78j select diag_desc , doctor from outp_mr where patient_id =:1 and visit_date like visit_date and visit_no =:2
0nwg8cxxzcb0m select T1.REMIND_DATETIME, T1.START_DATETIME, T1.VISIT_DATE, T1.REMIND_TYPE, T1.REMIND_ID, T1.DELETE_FLAG, T1.REPEAT_INTERVAL, T1.VISIT_ID, T1.VISIT_NO, T1.DELETE_USER_ID, T1.DELETE_USER_NAME, T1.PATIENT_ID, T1.REMIND_DEPICT, T1.REMIND_INDEX, T2.REMIND_TYPE_NAME, T1.REMIND_USER_ID, T1.REMIND_USER_NAME from REMIND T1, REMIND_TYPE_DICT T2 where T1.REMIND_TYPE=T2.REMIND_TYPE_CODE(+) and T1.Remind_Type in (:"SYS_B_0") and T1.Delete_Flag=:"SYS_B_1" and T1.Remind_User_Name=:"SYS_B_2" order by T1.Remind_Id
14fz7s749tx24 Select drug_spec , batch_no , quantity , supply_indicator from drug_stock where drug_code =:1 and firm_id =:2 and package_spec =:3 and package_units =:4 and storage =:5 order by batch_no DESC
18h8s79av5v45
sql--省略
Back to SQL Statistics
Back to Top
SGA breakdown difference
ordered by Pool, Name
N/A value for Begin MB or End MB indicates the size of that Pool/Name was insignificant, or zero in that snapshot
Pool Name Begin MB End MB % Diff
java free memory 26.47 26.47 0.00
java joxlod exec hp 5.34 5.34 0.00
large free memory 32.00 32.00 0.00
shared CCursor 870.37 871.80 0.16
shared Cursor Stats 65.30 65.30 0.00
shared PCursor 506.48 505.60 -0.17
shared db_block_hash_buckets 90.00 90.00 0.00
shared free memory 484.07 480.10 -0.82
shared kglsim object batch 90.30 90.30 0.00
shared library cache 352.64 351.46 -0.33
shared sql area 3,290.12 3,291.57 0.04
streams free memory 16.00 16.00 0.00
buffer_cache 9,216.00 9,216.00 0.00
fixed_sga 1.99 1.99 0.00
log_buffer 14.01 14.01 0.00
Back to Memory Statistics
Back to Top
Resource Limit Stats
only rows with Current or Maximum Utilization > 80% of Limit are shown
ordered by resource name
Resource Name Current Utilization Maximum Utilization Initial Allocation Limit
processes 1,631 1,824 2000 2000
sessions 1,639 1,884 2205 2205
Back to Top
init.ora Parameters
Parameter Name Begin value End value (if different)
audit_file_dest /oracle/product/10.2.0/admin/orcl/adump
background_dump_dest /oracle/product/10.2.0/admin/orcl/bdump
compatible 10.2.0.1.0
control_files /oradata/orcl/control01.ctl, /oradata/orcl/control02.ctl, /oradata/orcl/control03.ctl, /oralog/orcl/control04.ctl
core_dump_dest /oracle/product/10.2.0/admin/orcl/cdump
cursor_sharing FORCE
db_block_size 8192
db_cache_size 9663676416
db_domain
db_file_multiblock_read_count 32
db_name orcl
db_recovery_file_dest /oracle/product/10.2.0/flash_recovery_area
db_recovery_file_dest_size 2147483648
java_pool_size 33554432
job_queue_processes 10
large_pool_size 33554432
log_archive_dest_1 LOCATION=/oralog/arch
nls_language SIMPLIFIED CHINESE
nls_length_semantics CHAR
nls_territory CHINA
open_cursors 300
pga_aggregate_target 2147483648
processes 2000
remote_login_passwordfile EXCLUSIVE
sessions 2205
shared_pool_size 6442450944
streams_pool_size 16777216
undo_management AUTO
undo_tablespace UNDOTBS1
user_dump_dest /oracle/product/10.2.0/admin/orcl/udump
Back to Top
End of Report焦点在于解析：
Parses: 1,499.45 99.27
Hard parses: 8.39 0.56
Execute to Parse %: -22.89每秒软解析1500次 ，Execute to Parse 解析是负值 ， 这说明 执行解析比非常差。
以下SQL parse次数频繁：
SQL ordered by Parse Calls
Total Parse Calls: 5,416,394
Captured SQL account for 41.3% of Total
Parse Calls Executions % Total Parses SQL Id SQL Module SQL Text
457,941 152,651 8.45 ctc7t080mcrpr PACSVR.exe Select exam_master.*, exam_ma...
324,064 324,063 5.98 1jzhjx524wyfm presdisp.exe select TRADE_PRICE , retail_p...SQL ID ctc7t080mcrpr 1jzhjx524wyfm
ctc7t080mcrpr 实际执行只有 152,651 ，解析倒有457,941次
建议分析以上语句为何产生了大量软解析
Advice:
1. 分析SQL语句，减少软解析的数量
2. 利用open cursor、session cached cursors等技术减少软解析
3. 考虑设置_kks_use_mutex_pin=FALSE 禁用10g中的MUTEX PIN CURSOR特性
*<font color="red" size="2" face="courier">如果觉得本回复有意义，请点击本条回复右手边的Correct按钮，谢谢！</font>*
Maclean Liu
Oracle Database Administrator
Oracle Certified 10g/11g Master
www.askmaclean.com
Edited by: Liu Maclean on 2012-8-23 下午11:48 -
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+
Maybe you are looking for
-
Dynamic sql and bind variables
Hi, I have a stored procedure which filters a table on 5 five columns. The filters come from the input parameters, and these 5 parameters can come in any combination, I mean some of them may be null and some of them may not be null. So I constructed
-
I have a new IMac with OS Lion. When trying to open some websites they open with Safari by default. I am trying to change this by changing the "open with" default to Firefox but I can't move Firefox to the Apps location.
-
Hi , In the esf interface if_esf_provider_access we get an attribute called in_edit_mode for method retrieve and retrieve association . The problem is when we try to create an new entry in the root using the esf test tool and us
-
SUSE SLES9 64-bit and J2SDK 64-bit
Hello, We have a system, which is running on SUSE SLES9 64-bit OS. I would liek to install JAVA which is J2SDK 64-bit on X86 system (java version "1.4.2_08" 64-bit). Could you please direct me the link to download the software.. I looked around under
-
How to set query result to emai content?
Dears, Since user want to get the email with content like a grid format, just like a sql query result with some columns and rows. Is there any simply way to set the sql query result to the email content? Thanks!