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 suggest

user8850066 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

Similar Messages

Latch: cache buffers chains

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

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/

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

关于cache buffers chains的问题

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)等待即可。

High cache buffers chains

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

Bridge only shows "high quality thumbnails" even if i have "quick thumbs" selected under preferences

I have tried using the options "Convert To High Quality When Previewed" and "quick thumbnails" under preferences, and closed and restarted bridge after changing each option, but to no avail.
bridge only shows high quality thumbs even with other options selected.
any ideas?

After the thumbnails have been created using the option
i Convert To High Quality When Previewed
then reverting back to the option
i Quick Thumbnails
won't "downsize" the cached thumbnails; the high-quality thumbnails will still show. To see low-quality (quick) thumbnails, turn to another folder with images with no thumbnails yet created, or purge the thumbnail cache. Simply closing and restarting won't purge the cache.
-- Olaf

Local currency showing higher value in BW compared to ERP - Sales report

Hi,
My sales report is showing higher value in BW report compared to ERP e.g
the report is showing 567,01 and in ERP it is showing 566,94.
is there a way I can resolve this in the query.
thanks

Hi Bhat,
there may be lot many factors like
1)comparision between the Two i.e ERP and BIW.Are the Factors same.
2)Have u Deltas captured properly.
3)have u missed any deltas any day.
4)Any order that has been modified .
5)hope u have considered ONE days Lag between BIW and ERP.
6)To what is ur 0Recordmode mapped to.
7)Is it because of Rounding OFF Values.
Rgds
SVU

Slow/choppy playback - cache buffering issue

On playback, PP6 randomly slows down and plays back choppy on visually complex shots. It takes repeated stops and starts to clear it out. I have troubleshot the life out of this, read every relevant thread, and tried everything imaginable to fix it. Windows 7 pro is fully optimized. There are no software conflicts (installed a drive with only windows and CS6) I’ve got plenty of horsepower - 3930K in an asusp9x79pro, gtx 670 w/4mb, 32mb ram, OC to 4.5. Eric Bowen at ADK has personally tuned the system and done a manual overclock. Memtest confirms the ram is fine. There are no hardware issues. Dropped frame indicator stays green, no dropped frames. Switching from hardware to software mercury playback does nothing. Rendering has no effect, nor do any playback settings. It happens with AVCHD and h.264 mp4’s as well, on short clips, not just long ones. It does not happen outside of ppro. Since I have eliminated hardware and software issues, all this leaves is Premiere.
As Eric explains it, it is a cache buffering issue, related to how the nvidia card and ppro interact, and he sees it frequently enough. I can't do his explanation justice, but he has offered to jump in and provide more detail if need be.
Whatever it is, it’s ridiculous. It is totally unacceptable to play down a sequence and have it intermittently slow down on a system with this much power that has been properly set up by a pro. It’s a shame, because it’s the only thing from keeping ppro/cs6 from being the best platform I’ve edited on in my 12 years as an editor.
I’ve filed a bug report, but gotten no response. If others are seeing it, and can file a bug report, maybe it will be publicly acknowledged and resolved.
https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

Hi,
I think I have similair problem. First of all my current specs is:
Asus Sabertooth z77 mainboard with intel i7 2700K processor
32 gb (8*4) ram
120 gb ssd sata3 drive for OS and CS6
500 gb sata3 7200rpm hd for cache files
1 tb sata3 7200rpm hd for source video and audio
and finally Nvidia GeForce GTX 660 Ti with 2gb of memory
Blackmagic shuttle io card etc
This system were combined specially for my endless highend compositing needs and it works like a charm with all applications other than Premiere Pro.
Yesterday I barley finished editing a short (approx 2 minutes) 1080p project that shot with Canon 5D MKII. Without using mercury playback engine application
works fine but once I activate it all playback became really slow and laggy and sometime it freeze if I move playhead quickly.
I only use one video and one audio track in timeline so we can say this editing scenario is a fundamental for production grade NLE application.
My graphic processor has a lot of cuda power but Adobe doesn't support it natively so I have to edit the famous text file.
On CS5 and CS5.5 I done lots of 1080p project with my old gtx 480 card and I never encountered any similair problem.
I hope my favorite and trusted software company Adobe will find the problem and will fix it soon...
Thanks
M.Maya

Pageserver.exe showing high CPU processing on server

We have been running Crystal Enterprise 10 for awhile on the same server. Starting Thursday evening the pageserver.exe process showing high CPU utilitzation on the server. We have restarted all the Crystal services through the Central Configuration Manager but the problem still came back. The high CPU utilitization occurs during the day and at night when no one would be running any reports. Does any know what else we could look for?
Also does a separate pageserver.exe start for each user that runs a Crystal report, we show about 6-8 pageserver.exe processes at any given time. Is that normal? When do these pageserver.exe processes go away. I logged out of Infoview but a pageserver.exe process did not go away.
Thanks
Adam

Closed never answered.

My iphone shows high temperature last night and today is off and dont want to turn on what cani do?

MY phone shows high temperature and then went off what can i do? Is it damaged?

Here are some troubleshooting steps you can perform to try and get it started again: iOS: Not responding or does not turn on - Apple Support

CCX version 8.0 showing high Virtual memory.

Hi,
We have a CCX cluster 8.0 implemented in our scenario.
The cluster has been upgraded from 5.x to 8.x.
After the upgrade it is showing high Virtual Memory , the memory is shooting upto 90%.
Could you suggest any reason for?
Regards
Ankita Vig

Thanks a lot.
HASPJava.dll is used by verification License and is invoked less and can't use a lot of native memory.
Our business is communicating between java and COM component. In order to implement it, we used JavaCom to generate java class for COM component.
Memory of COM component is little, but Native Memory is high.
Who used JavaCom and did you meet this problem?
Please give me some suggestions. Thanks a lot.

Showing High-Speed motion in Flash

Hello All:
I am wondering if anyone has come up with a good method for
showing "high-speed" rotation of objects such as fans, wheels,
axles, shafts, etc. I create industrial training modules in Flash
and have employed several methods, most notably lines shifting
positions within a movie clip to give the impression of motion. But
my method leaves a lot to be desired and was wondering if someone
has a better mousetrap.
Thanks, Steve

i tried setting the frame rate faster (1000Hz), but it maxed out at the monitors frame rate (60Hz) - which kinda explains the resolution of Date.time
the high-speed timer only has to be consistent on my system. i'm using the timer for performance testing and won't need it in a "shipping" environment.
doug

Costing shows high value due to BOM alternative material

Hi,
In BOM we have maintained alternative material for few line items.(not maintained alternative BOM) When we do the standard cost run system is taking main material and alternative material value. so the cost of the product is showing high.
How system will behave this situation when doing standard cost estimate? how to avoid this excess value due to adding the alternative material?

Dear Govindaraj,
If there are alternative items maintained in the BOM,then as per the usage probability defined for each
item the cost will be taken.
say for one item if its 60% and for the another if its 40% means accordingly the cost gets captured.
So goto CS03,say Items X and Y are defined under alt.item group A1,now select the first item(row) X
and click on item details and check under Basic tab page you will be able to see the alt.item group
along with priority,strategy and usage probability.
So in CK11N or CK40N,it will be showing as 6 ea and 4 ea along with their prices for costing part.
So as per to the usage prob it picksup for the costing part.
Check and revert back.,
Regards
Mangalraj.S

Persistance Layer Anaysis shows high percentage

Hello Experts,
The PI System is showing high percentage (500 plus) of usage in persistance layer analysis. Recently I encountered queue blockages with TIME_OUT exception as the records were not able to insert in the table SXMSCLUP.
Can anyone tell me should I be worried about so much usage in the persistance layer? However, all the archiving and deletion jobs are running regularly.
Thanks in advance,
Anand Patil

Hello Anand,
What is current setting for Integration Engine's parameter DROP_MAX_TABLE_LOAD?
Please also advise approx. amount of processed messages per day and retention period (you can check SAP Note 872388 for general calculation logic of DROP_MAX_TABLE_LOAD based on these two input parameters).
What is approx. volume of processed messages?
Did you follow the logic described in the mentioned Note (872388) for scheduling archiving/deletion jobs or some other considerations?
In general, persistence layer should be cleaned on regular basis and since you observe exceptions when querying it, the attention for double-checking of current parameters for archiving/deletion jobs vs. persistence layer usage should surely be paid.
My regards,
Vadim

AWR showing high latch: cache buffers chains

Similar Messages

Maybe you are looking for