Latch problem.

Hi All,
I've severe latching problem in my database, when I look in AWR but confused what is causing it.
Can someone guide me on this?
NoWait Waiter
Latch Name Where Misses Sleeps Sleeps
In memory undo latch ktiFlush: child 0 5 0
In memory undo latch kturbk 0 2 2
cache buffers chains kcbchg: kslbegin: bufs not 0 573 69
cache buffers chains kcbgtcr: fast path 0 380 554
cache buffers chains kcbgtcr: kslbegin excl 0 298 547
cache buffers chains kcbrls: kslbegin 0 183 153
cache buffers chains kcbzgb: scan from tail. no 0 83 0
cache buffers chains kcbibr 0 31 40
cache buffers chains kcbchg: kslbegin: call CR 0 10 70
cache buffers chains kcbgcur: kslbegin 0 4 13
cache buffers chains kcbget: pin buffer 0 3 72
cache buffers chains kcbnew: new latch again 0 3 18
cache buffers chains kcbzwb 0 2 3
cache buffers chains kcbbxsv 0 1 3
cache buffers chains kcbcge 0 1 5
cache buffers lru chain kcbzgws 0 45 0
cache buffers lru chain kcbibr 0 43 97
cache buffers lru chain kcbo_link_q 0 20 5
cache buffers lru chain kcbw_quiesce_granule 0 5 0
cache buffers lru chain kcbgtcr:CR Scan:KCBRSKIP 0 1 0
enqueues ksqdel 0 1 0
kks stats kks stats alloc/free 0 1 1
library cache kglobpn: child: 0 2,978 4,471
library cache kgldti: 2child 0 2,417 12
library cache kglLockCursor 0 1,604 3,398
library cache kglpin 0 1,426 538
library cache kglpndl: child: after proc 0 1,185 7
library cache kglhdgn: child: 0 766 1,485
library cache kglpnp: child 0 618 8,902
library cache kglhdgc: child: 0 331 0
library cache kgldte: child 0 0 95 809
library cache kglpndl: child: before pro 0 92 1,800
library cache kglic 0 50 0
library cache kglnti 0 30 0
library cache kglati 0 28 0
library cache kglobld 0 15 21
library cache kglScanDependency 0 7 2
library cache kglukp: child 0 6 5
library cache kglhdbrnl: child 0 1 0
library cache lock kgllkdl: child: no lock ha 0 10,017 217
library cache lock kgllkdl: child: cleanup 0 87 119
library cache lock kgllkal: child: multiinsta 0 80 48
library cache lock alloc kgllkget 0 1 1
library cache pin kglpndl 0 34 6
library cache pin kglpnp: child 0 17 23
library cache pin kglpnal: child: alloc spac 0 13 35
object queue header oper kcbo_switch_cq 0 12 5
object queue header oper kcbw_link_q 0 9 11
object queue header oper kcbo_link_q:reget 0 5 0
object queue header oper kcbw_unlink_q 0 2 10
redo allocation kcrfw_redo_gen: redo alloc 0 13 0
row cache objects kqreqd: reget 0 7 0
row cache objects kqreqd 0 1 0
session allocation ksuprc 0 44 7
session allocation ksudlc 0 24 25
session allocation ksuxds: not user session 0 16 1
session allocation ksucri 0 9 62
session allocation kspallmod 0 2 0
shared pool kghalo 0 2,269 126
shared pool kghupr1 0 690 3,122
Thanks for the help.
Thanks,
Rana.

DB Name         DB Id    Instance     Inst Num Release     RAC Host
orvprd        3135597156 orvprd              1 10.2.0.3.0  NO  ix205
              Snap Id      Snap Time      Sessions Curs/Sess
Begin Snap:      8273 22-Jun-09 03:00:39       132      22.4
  End Snap:      8275 22-Jun-09 05:00:42       135      19.3
   Elapsed:              120.05 (mins)
   DB Time:              565.08 (mins)
Cache Sizes
~~~~~~~~~~~                       Begin        End
               Buffer Cache:     7,392M     7,264M  Std Block Size:         8K
           Shared Pool Size:     2,768M     2,896M      Log Buffer:    14,340K
Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                  Redo size:             33,684.43              7,421.03
              Logical reads:            133,813.99             29,480.60
              Block changes:              4,946.72              1,089.81
             Physical reads:                  2.37                  0.52
            Physical writes:                 12.92                  2.85
                 User calls:                154.34                 34.00
                     Parses:                438.57                 96.62
                Hard parses:                  1.26                  0.28
                      Sorts:              5,130.10              1,130.21
                     Logons:                  0.07                  0.02
                   Executes:              5,604.35              1,234.70
               Transactions:                  4.54
  % Blocks changed per Read:    3.70    Recursive Call %:    98.52
Rollback per transaction %:    0.18       Rows per Sort:     2.85
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:  100.00       Redo NoWait %:  100.00
            Buffer  Hit   %:  100.00    In-memory Sort %:  100.00
            Library Hit   %:  100.01        Soft Parse %:   99.71
         Execute to Parse %:   92.17         Latch Hit %:   99.32
Parse CPU to Parse Elapsd %:    8.09     % Non-Parse CPU:   99.46
Shared Pool Statistics        Begin    End
             Memory Usage %:   84.14   84.89
    % SQL with executions>1:   97.57   97.11
  % Memory for SQL w/exec>1:   95.66   95.31
Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
CPU time                                         14,995          44.2
TCP Socket (KGAS)                   611,193       6,230     10   18.4    Network
latch: library cache                 21,661       4,756    220   14.0 Concurrenc
latch: shared pool                    3,333         320     96    0.9 Concurrenc
db file sequential read              17,316         193     11    0.6   User I/O
          -------------------------------------------------------------

Similar Messages

  • PowerBook 12" magnetic latch problem

    I have searched the discussion board for similar problems to mine and while some of them were close, none of them had any answers that I would find helpful. So here's my problem.
    I've had my PowerBook for little over two weeks now, and the magnetic latch that is used to keep the display closed is giving me a bit of trouble. As we all know the little hook comes out of the top of the display when it is close enough to the bottom of the computer in order to latch in properly. Now when I try to close my laptop it all goes according to plan, but only if I move the display down into place in one fast swing. If I do it fast, the display goes down all the way and then I hear the hook come out and it clicks and then that's it. The problem is if I'm doing it slowly, the latch jumps out all the way too soon and prohibits the display from going all the way down. It pretty much just sticks out vertically and won't allow me to close it down properly.
    Now I know that I am not in a bad situation here seeing as I can still close it fine unlike other people, but I paid a fair bit for this machine and I am a student and would like to take full advantage of my purchase. Is this typical for PowerBooks and should I just take it as a minor defect or make a stink about it? Any thoughts would be very welcome. Of course, it might very well be that when it does get stuck I just need to push down harder on it. I haven't done that because I wasn't sure if I'm supposed to and I didn't want to break it.
    Cheers!
    Powerbook G4 12"   Mac OS X (10.4.5)  

    Back with an update and a question.
    Before I go on, I will admit, yes, that I might love my computer a bit too much and maybe, just maybe I'm a bit too picky.
    Anyways, the update concerns the lower part of the locking mechanism. Back when it wouldn't close properly, due to the hook repeatedly hitting the lock at an awkward angle that would prevent it from closing, I managed to get the top of said lock slightly scratched. It's actually more like a little dent on it's top at the right extremity. Now that's minor and I'm fine and dandy with that. My problem is that a couple of days ago, I had the PowerBook at a funny angle on my lap for a second and I caught a glimpse of the side of the lock (by lock I'm referring to the part that the hook catches on to, the same one that moves inward when you press the release button) and I saw a major scratch there.
    On a closer look it turns out that it's not really scratch, but rahter a vertical line (shiny) that most likely resulted from the hook rubbing up against it. So I started freaking out, I mean is the hook going to dig a hole in the lock eventually? But what I don't know is whether the hook is doing this now or this was going down before I had the lock repositioned by the service guy. And further questions arise from the fact that I don't know if the rubbing and the scratching happen when it is being closed or when it's actually closed and there's a bit of play there. I checked the hook for any kind of wear signs and there aren't any. I would attribute that to the fact that the hook seems to be made of a denser alloy.
    Now I know none of you guys can answer the question whether the rubbing goes down now or not anymore, only time will tell there (hopefully before the warranty is over), but it would really put my mind at ease if you guys had a look at your PowerBooks and told me how you stand in terms of wear marks on the side of the lock. So I'm talking about the little slanted part that the hook grabs on to when you close it, that is the same part that the release button pushes away from the user when pressed. It's the side the hook catches on that I'm talking about, that is the right side as you are facing the computer. You might need to tilt the notebook a bit and have light shining down onto the right side to see. I would really appreciate any comments for my peace of mind.
    Sorry for being a geek!
    P.S. Does anyone know if I can email someone at Apple and ask them about this. The service guy didn't really seem to interested in my being so careful about this issue, I just want to get some kind of confirmation that this is not going to get worse in time.

  • Latch problem in the informix ! help Please!

    hi sir!
    when i have accessed informixin my .jsp file ,after that i want to use "dbexport" to restore my db ,when i use "onstat -u " there are several table showed being in latched status and "tty" colum is "-" , but when i close my web server tomcat , the latches are released.
    i have closed connection ,statement and resultset Object.
    help me ! Please !

    I'm facing the same problem and I wanna know if you already solved it.
    regards.
    Jorge Walendowsky
    [email protected]

  • Side panel latch problem

    Hey guys,
    Recently the latch that opens the side panel and releases the hard drives broke, fortunately the side panel came off but now randomly falls off because it does not lock back up. I still have AppleCare warrenty on the computer, is there anyway this can be fixed ?
    Thanks a bunch.

    You are not talking to Apple, Inc when you post here. We are all users like you.
    Applecare is very comprehensive coverage. If you have Applecare, and your computer is not working as it should, Apple will fix it, whatever it takes, including repairing or replacing the enclosure, if that is what it takes.
    If a store is nearby, you can make an appointment for a Genius to evaluate the situation, no charge. They can fix simple problems on the spot, but rarely have the time for a problems that may require substantial dis-assembly. If the repair is covered, it may take overnight or a few days to complete -- longer if they have to send it to a depot for major repair. It is prudent to make sure your backups are current before you turn over your Mac for repair, or include just a spare drive with Mac OS X and no personal files on it. You will be asked for an Admin password.

  • "latch: row cache objects" and high "VERSION_COUNT"

    Hello,
    we are being faced with a situation where the database spends most of it's time waiting for latches in the shared pool (as seen in the AWR report).
    All statements issued by the application are using bind variables, but what we can see in V$SQL is that even though the statements are using bind variables some of them have a relatively high version_count (> 300) and many invaliadations (100 - 200) even though the tables involved are very small (some not more than 3 or 4 rows).
    Here is some (hopefully enough) information about the environment
    Version: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production (on RedHat EL 5)
    Parameters:
    cursor_bind_capture_destination       memory+disk
    cursor_sharing                        EXACT
    cursor_space_for_time                 FALSE
    filesystemio_options                  none
    hi_shared_memory_address              0
    memory_max_target                     12288M
    memory_target                         12288M
    object_cache_optimal_size             102400
    open_cursors                          300
    optimizer_capture_sql_plan_baselines  FALSE
    optimizer_dynamic_sampling            2
    optimizer_features_enable             11.2.0.2
    optimizer_index_caching               0
    optimizer_index_cost_adj              100
    optimizer_mode                        ALL_ROWS
    optimizer_secure_view_merging         TRUE
    optimizer_use_invisible_indexes       FALSE
    optimizer_use_pending_statistics      FALSE
    optimizer_use_sql_plan_baselines      TRUE
    plsql_optimize_level                  2
    session_cached_cursors                50
    shared_memory_address                 0The shared pool size (according to AWR) is 4,832M     
    The buffer cache is 3,008M     
    Now, my question: is a version_count of > 300 a problem (we have about 10-15 of those with a total of ~7000 statements in v$sqlarea). Those are also the statements listed in the AWR report at the top in the section "SQL ordered by Version Count" and "SQL ordered by Sharable Memory"
    Is it possible that those statements are causing the the latch contention in the shared pool?
    I went through https://blogs.oracle.com/optimizer/entry/why_are_there_more_cursors_in_11g_for_my_query_containing_bind_variables_1
    The tables involved are fairly small and all the execution plans for each cursor are identical.
    I can understand some of the invalidations that happen, because we have 7 schemas that have identical tables, but from my understanding that shouldn't cause such a high invalidation number. Or am I mistaken?
    I'm not that experienced with Oracle tuning at that level, so I would appreciate any pointer on how I can find out where exactly the latch problem occurs
    After flushing the shared pool, the problem seems to go away for a while. But apparently that is only fighting symptoms, not fixing the root cause of the problem.
    Some of the statements in question:
    SELECT * FROM QRTZ_SIMPLE_TRIGGERS WHERE TRIGGER_NAME = :1 AND TRIGGER_GROUP = :2
    UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = :1 WHERE TRIGGER_NAME = :2 AND TRIGGER_GROUP = :3 AND TRIGGER_STATE = :4
    UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = :1 WHERE JOB_NAME = :2 AND JOB_GROUP = :3 AND TRIGGER_STATE = :4
    SELECT TRIGGER_STATE FROM QRTZ_TRIGGERS WHERE TRIGGER_NAME = :1 AND TRIGGER_GROUP = :2
    UPDATE QRTZ_SIMPLE_TRIGGERS SET REPEAT_COUNT = :1, REPEAT_INTERVAL = :2, TIMES_TRIGGERED = :3 WHERE TRIGGER_NAME = :4 AND TRIGGER_GROUP = :5
    DELETE FROM QRTZ_TRIGGER_LISTENERS WHERE TRIGGER_NAME = :1 AND TRIGGER_GROUP = :2So all of them are using bind variables.
    I have seen that the columns used in the where clause all have histograms available. Would removing them reduce the number of invalidations?
    Unfortunately I did not save the information from v$sql_shared_cursor before the shared pool was flushed, but most of the invalidations occurred in the ROLL_INVALID_MISMATCH column if that is of any help. There are some invalidations reported for AUTH_CHECK_MISMATCH and TRANSLATION_MISMATCH but to my understanding they caused by executing the statement for different schemas if I'm not mistaken.
    Looking at v$latch_missed, most of the waits for parent = 'row cache objects' are for "kqrpre: find obj" and "kqreqd: reget"

    >
    In the AWR report, what does the Dictionary Cache Stats section say?
    >
    Here they are:
    Dictionary Cache Stats                                                                                                     
    Cache                 Get Requests      Pct Miss     Scan Reqs    Mod Reqs      Final Usage                                
    dc_awr_control        65                0.00         0            2             1                                          
    dc_constraints        729               33.33        0            729           1                                          
    dc_global_oids        60                23.33        0            0             31                                         
    dc_histogram_data     7,397             10.53        0            0             2,514                                      
    dc_histogram_defs     21,797            9.83         0            0             5,239                                      
    dc_object_grants      4                 25.00        0            0             12                                         
    dc_objects            27,683            2.29         0            223           2,581                                      
    dc_profiles           1,842             0.00         0            0             1                                          
    dc_rollback_segments  1,634             0.00         0            0             39                                         
    dc_segments           7,335             6.94         0            360           1,679                                      
    dc_sequences          139               5.76         0            139           19                                         
    dc_table_scns         53                100.00       0            0             0                                          
    dc_tablespace_quotas  1,956             0.10         0            0             4                                          
    dc_tablespaces        17,488            0.00         0            0             11                                         
    dc_users              58,013            0.03         0            0             164                                        
    global database name  4,261             0.00         0            0             1                                          
    outstanding_alerts    54                0.00         0            0             9                                          
    sch_lj_oids           4                 0.00         0            0             2                                          
    Library Cache Activity                                                                                                     
    Namespace             Get Requests     Pct Miss     Pin Requests          Pct Miss      Reloads   Invalidations            
    ACCOUNT_STATUS        3,664            0.03         0                                   0         0                        
    BODY                  560              2.14         2,343                 0.60          0         0                        
    CLUSTER               52               0.00         52                    0.00          0         0                        
    DBLINK                3,668            0.00         0                                   0         0                        
    EDITION               1,857            0.00         3,697                 0.00          0         0                        
    INDEX                 99               19.19        99                    19.19         0         0                        
    OBJECT ID             68               100.00       0                                   0         0                        
    SCHEMA                2,646            0.00         0                                   0         0                        
    SQL AREA              32,996           2.26         1,142,497             0.21          189       226                      
    SQL AREA BUILD        848              62.15        0                                   0         0                        
    SQL AREA STATS        860              82.09        860                   82.09         0         0                        
    TABLE/PROCEDURE       17,713           2.62         26,112                4.88          61        0                        
    TRIGGER               1,704            2.00         6,737                 0.52          1         0                        

  • Powerbook cover won't latch properly

    Hi, I've searched thru the forum for PB Screen Cover Latch problem.
    Tried some suggestion like tap the Screen cover to close the lid but still it does not close and I have to force it down to close it.
    Previously, I have problem closing as the latch doesn't seems to be able to get locked by the bezel. URGGH!!! Frustration!!!
    So I have to always press the push button to close the screen cover. End up, now the screen cover would not close at all..
    Wat should I do?
    Instead of send for repair, (of cos, as per read from MUGS forum, such exterior does not cover under warranty).

    This is very common, and I wonder if every Powerbook has this issue, particularly the 12-inch.
    Mine usually works, if I'm latching it on a level surface, but otherwise, it likes to pop back up. However, on a level surface, it usually stays put. If yours never closes properly, you should contact Apple Care.

  • Latch staticsts

    Hi,
    when i were take dinamic view v$latch the following statistics got
    name get misses sleep
    cache buffers chain 1,239,949,155 3153 12
    Library Cache 396,007,245 28289 1
    Library Cache Pin 894,591,405 66089 1
    Library Cache Pin
    Allocation 394,870,329 961 6
    is it any contention problem in library cache, plz advice me
    best regards

    I hate reading numbers that do not line up but a quick eye-ball reading of your numbers do not show any problem. The misses all look to be a small percentage of the gets.
    Why do you think you have a latching problem? Have you noticed v$process entries marked as latch waited, or v$session_wait entries that are waiting on latch operations?
    HTH -- Mark D Powell --

  • Latch wait issue

    Hello gurus, i have a problem here with the latch, i already do some suggestion on google to set parameter cursor sharing to force and also make spin_count become 2000, but i still find this problem occurent so often, can u suggest me how to fix that problem?
    Regards,
    Freddie

    Here is the spec of my server :
    • O/S: HP-UX B.11.11
    • Server Type: HP RP8400
    • Server Name: DWHETL
    • IP : 10.128.1.24
    • CPU : 4
    • Memory: 16 GB
    • Oracle: Oracle 10 r2 patch 4
    • Oracle SID: tm1dev (existing)
    • Storage: 2 TB External Storage
    • Multipath:PVlink
    • Volume Management: LVM
    The parameter i set are :
    - alter system set sga_max_size=8G scope=spfile;
    - alter system set sga_target=8G scope=spfile;
    - alter system set pga_aggregate_target=4G scope=spfile;-
    - alter system set parallel_min_servers=4 scope=spfile;
    - alter system set parallel_max_servers=8 scope=spfile;
    - alter system set dbwr_io_slaves=8 scope=spfile;
    - alter system set open_cursors=500 scope=spfile;
    I see the latch problem from the spotlight, there is alarm that my latch wait is high. i have a printscreen about that, how to post a picture in here?

  • Querys not using indexes

    hi all.
    I want to know wich querys in not using indexes. this is posible??
    My db version is 10.2
    Thanks.

    gomcar wrote:
    hi all.
    I want to know wich querys in not using indexes. this is posible??
    My db version is 10.2
    Thanks.Here is something that I just put together as a possible solution. You probably do not want to execute this SQL statement frequently as it might cause a latching problem (note, not thoroughly tested):
    SELECT /*+ ORDERED */
      SP.SQL_ID,
      SP.HASH_VALUE,
      SP.CHILD_NUMBER,
      S.SQL_TEXT
    FROM
      (SELECT
        SP.SQL_ID,
        SP.HASH_VALUE,
        SP.CHILD_NUMBER,
        SUM(DECODE(INSTR(SP.OBJECT_TYPE,'INDEX'),0,0,1)) COUNTER
      FROM
        V$SQL_PLAN_STATISTICS_ALL SP
      WHERE
        SP.OBJECT_TYPE IS NOT NULL
      GROUP BY
        SP.SQL_ID,
        SP.HASH_VALUE,
        SP.CHILD_NUMBER
      HAVING
        SUM(DECODE(INSTR(SP.OBJECT_TYPE,'INDEX'),0,0,1))=0) SP,
      V$SQL S
    WHERE
      SP.SQL_ID=S.SQL_ID
      AND SP.HASH_VALUE=S.HASH_VALUE
      AND SP.CHILD_NUMBER=S.CHILD_NUMBER
    ORDER BY
      S.SQL_TEXT;Explanation of the above:
    The above looks at the stored execution plans for the queries currently in the shared pool, throwing out any line in the plan where no object is specified. If the OBJECT_TYPE column is found to not contain the word INDEX, a 0 is returned, otherwise a 1 is returned for that line in the plan. The sum of this generated column is calculated for each plan, and those plans having the sum of the generated column equal to 0 are returned. This inline view then drives into the V$SQL view to retrieve the matching SQL statements. An ordered hint is used to make certain that Oracle drives from the inline view into V$SQL.
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Compare Indicator

    Hi there ! I'm a pure beginner in LabView. My question are:
    1. Is it right if I make a text file by writing the data directly using Notepad program. In this case I just write down the number (0,1,2,.....n) and each number end by carriage return (enter key). Or I have to use the LabView procedure to write my file ?
    2. I already made two text files that contain number like I asked in no.1 (using Notepad). I've done the comparison of that two files. But I have problem to write it to a new text file, because I don't know to make a format in that new text file. I want to make it like table and contain header "no", "line" , etc. How to make a "formatted" text file like table and can be open using Notepad ?
    3. I used the boolean to be the fault indicator. T
    hat mean if the compare process found that the two files are not the same, this indicator will "on". But the indicator only "on" when it sees the fault. After that it turns off again. How to make a boolean has a latch function ?
    I need to solve this problem immediatly regarding to my project. So, please help me...Thanks

    Hi Dennis...
    After I saw your attachment file, I thought I have to change my problem.
    I have Test1.txt file contain "0,1,2....15". And second I have Test2.txt file too that contain the result of some process. This Test2.txt should contain the same "0,1,2...15" like Test1.txt, but in sometime it could be different. So, what I want is to compare the "0" on line 1 of Test1.txt with the data on line 1 of Test2.txt. And "1" on line 2 of Test1.txt with the second data on line 2 of Test2.txt, and so on. So, this what the process I called line-by-line comparison. I did it with "Read File" function of LabView.
    My problem now is since I didn't "translate" my file to be an array, how can I make it ? I want my data from Test1.txt file read and t
    ranslate it to an array. If I could translate it, I could use your method to solve my latch problem.
    Thanks

  • Higher parse and execute than I expected

    I am trying to diagnose a problem. But I'm a bit confused on how the following could happen. How could I get 25 parses on the same SQL statement? I'd expect 1 parse, 25 execute (which is what I get when I run that statement 25 times during a separate trace).
    SELECT PROJ_ID 
    FROM TIMEX.TD_PROJECTS 
    WHERE PROJ_TYPE = 'LVE'
    call     count       cpu    elapsed       disk      query    current        rows
    Parse       25      0.03       0.02          0          0          0           0
    Execute     25      0.00       0.00          0          0          0           0
    Fetch      265      0.16       0.19         31        935          0         250
    total      315      0.19       0.21         31        935          0         250
    Misses in library cache during parse: 1

    "only slightly more amusing than using DBMS_RANDOM"? Seriously Dan? I've got Cary's book & I've been to several of the Hotsos conferences. Method R doesn't necessarily apply here, or if it does, then please give me your targeted approach to implementing it. In my mind, I have to find out where the problem is before I can implement it. If the latch contention in the library cache is causing every session in the db to slow down, and I know that 4 new applications were introduced, then I need to figure out which of those 4 apps is the biggest contributor to the latching problem. Right?
    Initial Goal:
    Load the system with 1/3 of the upcoming user load, to see if it can handle cutover.
    Implementation:
    30 people entered application A, performing the work I captured which started my questions in this thread.
    12 people in application B, 18 in application C, 5 in application D.
    Result: Due to excessive latches in the library cache, the entire system became virtually unavailable.
    Next step: without involving 65 people for each test, capture an approximation of their work in their respective application, and use a testing harness find out which one is causing the majority of the latch contention. Then focus on fixing that app.
    The concern I have here, is that I want to capture that 1:1 parse-to-execution ratio for that one query, due specifically to the latch contention in the library cache - and it's excessive (and unnecessary) number of executions per user.
    If I can't replicate the problem, how can I find the problem areas and fix them?

  • Drive Access When Cover Shut

    I'm wondering if I have a latching problem. I rarely shut my PB down and transport it from the office to my home everyday. I have recently noticed that when I connect the AC cord, while the cover is closed, the PB accesses the hard drive from time to time. It does not happen everytime but did this evening. The other symptom is that when I open it up, I often have to log-in several times before I'm up and running. I get a log-in screen which often disappears to a blank screen then reappears. I enter my password, see my desktop then it cycles through again and I have to enter my password. This behavior too is intermittent.
    Any thoughts?

    I'm not sure about your hard drive issue but I get the login issue alot. I was bothered by it but then I realized why it occurred for me. I realized that when it occurred my computer wsa already sleeping when I closed the lid. Then it tends to "double sleep" (very technical term), you end up having to enter your password 2 or 3 times. Hope this helps you out.

  • Statspack interpretation

    I have been running statspack regularly and need help in interpretation. I believe the database in question is running ok from user's point of view. However, we will be doubling the users in a few weeks and I am trying to be proactive about preparing for this. I have looked at the statspack reports and have sent them through oraperf.com, but I still have questions. Can anyone help? I can share a couple of statspack reports with specific questions. Thanks in advance, Kim

    This is a good reference to interpret Statspack.
    Perspective EXPERT ADVICE
    Advanced Tuning with Statspack
    By Rich Niemiec
    But wait, there's more! What waits mean in Statspack reports and how to tune them out.
    If you could choose just two Oracle utilities to find and monitor performance problems in your Oracle9i Database system, those two utilities would be Oracle Enterprise Manager (now available in Release 4.0) and Statspack. As of Oracle8i Release 8.1.6, the Statspack utility replaced the UTLBSTAT/UTLESTAT scripts available for performance monitoring with earlier versions of Oracle Database; Statspack offers several significant enhancements to those scripts. This column focuses on solutions to advanced issues regarding wait events—those events for which your system had to wait during processing for a resource to become available, an action to complete, and so on.
    Top 5 Wait Events
    When you are trying to eliminate bottlenecks on your system, your Statspack report's Top 5 Wait Events section is the first place to look. This section of the report shows the top 5 wait events, the full list of wait events, and the background wait events. If your system's TIMED_STATISTICS initialization parameter is set to true, the events are ordered in time waited, which is preferable, since all events don't show the waits. If TIMED_STATISTICS is false, the events are ordered by the number of waits.
    Listing 1 shows a large number of waits related to reading a single block (db file sequential read) as well as waits for latches (latch free). You can see in this listing high waits for some of the writing to datafiles and log files. To identify which of these are major issues, you must narrow down the list by investigating the granular reports within other sections of Statspack.
    Resolving Your Wait Events
    The following are 10 of the most common causes for wait events, along with explanations and potential solutions:
    1. DB File Scattered Read. This generally indicates waits related to full table scans. As full table scans are pulled into memory, they rarely fall into contiguous buffers but instead are scattered throughout the buffer cache. A large number here indicates that your table may have missing or suppressed indexes. Although it may be more efficient in your situation to perform a full table scan than an index scan, check to ensure that full table scans are necessary when you see these waits. Try to cache small tables to avoid reading them in over and over again, since a full table scan is put at the cold end of the LRU (Least Recently Used) list.
    2. DB File Sequential Read. This event generally indicates a single block read (an index read, for example). A large number of waits here could indicate poor joining orders of tables, or unselective indexing. It is normal for this number to be large for a high-transaction, well-tuned system, but it can indicate problems in some circumstances. You should correlate this wait statistic with other known issues within the Statspack report, such as inefficient SQL. Check to ensure that index scans are necessary, and check join orders for multiple table joins. The DB_CACHE_SIZE will also be a determining factor in how often these waits show up. Problematic hash-area joins should show up in the PGA memory, but they're also memory hogs that could cause high wait numbers for sequential reads. They can also show up as direct path read/write waits.
    3. Free Buffer. This indicates your system is waiting for a buffer in memory, because none is currently available. Waits in this category may indicate that you need to increase the DB_BUFFER_CACHE, if all your SQL is tuned. Free buffer waits could also indicate that unselective SQL is causing data to flood the buffer cache with index blocks, leaving none for this particular statement that is waiting for the system to process. This normally indicates that there is a substantial amount of DML (insert/update/delete) being done and that the Database Writer (DBWR) is not writing quickly enough; the buffer cache could be full of multiple versions of the same buffer, causing great inefficiency. To address this, you may want to consider accelerating incremental checkpointing, using more DBWR processes, or increasing the number of physical disks.
    4. Buffer Busy. This is a wait for a buffer that is being used in an unshareable way or is being read into the buffer cache. Buffer busy waits should not be greater than 1 percent. Check the Buffer Wait Statistics section (or V$WAITSTAT) to find out if the wait is on a segment header. If this is the case, increase the freelist groups or increase the pctused to pctfree gap. If the wait is on an undo header, you can address this by adding rollback segments; if it's on an undo block, you need to reduce the data density on the table driving this consistent read or increase the DB_CACHE_SIZE. If the wait is on a data block, you can move data to another block to avoid this hot block, increase the freelists on the table, or use Locally Managed Tablespaces (LMTs). If it's on an index block, you should rebuild the index, partition the index, or use a reverse key index. To prevent buffer busy waits related to data blocks, you can also use a smaller block size: fewer records fall within a single block in this case, so it's not as "hot." When a DML (insert/update/ delete) occurs, Oracle Database writes information into the block, including all users who are "interested" in the state of the block (Interested Transaction List, ITL). To decrease waits in this area, you can increase the initrans, which will create the space in the block to allow multiple ITL slots. You can also increase the pctfree on the table where this block exists (this writes the ITL information up to the number specified by maxtrans, when there are not enough slots built with the initrans that is specified). Next Steps
    READ MORE about Statspack
    In "Performance Tuning with Statspack" on OTN
    /deploy/performance/pdf/
    statspack_tuning_otn_new.pdf
    In Rich Niemiec's "Oracle Performance Tuning Tips and Techniques," available from Amazon.com
    amazon.com/oracle
    GET SUPPORT from MetaLink
    oracle.com/support/metalink/index.html
    GET EDUCATED on Oracle9i
    /oramag/oracle/searchou.html
    5. Latch Free. Latches are low-level queuing mechanisms (they're accurately referred to as mutual exclusion mechanisms) used to protect shared memory structures in the system global area (SGA). Latches are like locks on memory that are very quickly obtained and released. Latches are used to prevent concurrent access to a shared memory structure. If the latch is not available, a latch free miss is recorded. Most latch problems are related to the failure to use bind variables (library cache latch), redo generation issues (redo allocation latch), buffer cache contention issues (cache buffers LRU chain), and hot blocks in the buffer cache (cache buffers chain). There are also latch waits related to bugs; check MetaLink for bug reports if you suspect this is the case (oracle.com/support). When latch miss ratios are greater than 0.5 percent, you should investigate the issue. I will cover latch waits in detail in my next Oracle Magazine column; the topic requires an article in itself.
    6. Enqueue. An enqueue is a lock that protects a shared resource. Locks protect shared resources, such as data in a record, to prevent two people from updating the same data at the same time. An enqueue includes a queuing mechanism, which is FIFO (first in, first out). Note that Oracle's latching mechanism is not FIFO. Enqueue waits usually point to the ST enqueue, the HW enqueue, the TX4 enqueue, and the TM enqueue. The ST enqueue is used for space management and allocation for dictionary-managed tablespaces. Use LMTs, or try to preallocate extents or at least make the next extent larger for problematic dictionary-managed tablespaces. HW enqueues are used with the high-water mark of a segment; manually allocating the extents can circumvent this wait. TX4s are the most common enqueue waits. TX4 enqueue waits are usually the result of one of three issues. The first issue is duplicates in a unique index; you need to commit/rollback to free the enqueue. The second is multiple updates to the same bitmap index fragment. Since a single bitmap fragment may contain multiple rowids, you need to issue a commit or rollback to free the enqueue when multiple users are trying to update the same fragment. The third and most likely issue is when multiple users are updating the same block. If there are no free ITL slots, a block-level lock could occur. You can easily avoid this scenario by increasing the initrans and/or maxtrans to allow multiple ITL slots and/or by increasing the pctfree on the table. Finally, TM enqueues occur during DML to prevent DDL to the affected object. If you have foreign keys, be sure to index them to avoid this general locking issue.
    7. Log Buffer Space. This wait occurs because you are writing the log buffer faster than LGWR can write it to the redo logs, or because log switches are too slow. To address this problem, increase the size of the log files, or increase the size of the log buffer, or get faster disks to write to. You might even consider using solid-state disks, for their high speed.
    8. Log File Switch. All commit requests are waiting for "logfile switch (archiving needed)" or "logfile switch (chkpt. Incomplete)." Ensure that the archive disk is not full or slow. DBWR may be too slow because of I/O. You may need to add more or larger redo logs, and you may potentially need to add database writers if the DBWR is the problem.
    9. Log File Sync. When a user commits or rolls back data, the LGWR flushes the session's redo from the log buffer to the redo logs. The log file sync process must wait for this to successfully complete. To reduce wait events here, try to commit more records (try to commit a batch of 50 instead of one at a time, for example). Put redo logs on a faster disk, or alternate redo logs on different physical disks, to reduce the archiving effect on LGWR. Don't use RAID 5, since it is very slow for applications that write a lot; potentially consider using file system direct I/O or raw devices, which are very fast at writing information.
    10. Idle Event. There are several idle wait events listed after the output; you can ignore them. Idle events are generally listed at the bottom of each section and include such things as SQL*Net message to/from client and other background-related timings. Idle events are listed in the stats$idle_event table.
    Stay Tuned
    In the next issue of Oracle Magazine, I'll investigate latches—another of the top waits you may encounter—looking at the usual latch waits you'll see and how to tune them for maximum performance.
    Rich Niemiec is the CEO of TUSC (www.tusc.com) and president of the International Oracle Users Group (www.ioug.org). Thanks to Steve Adams for editing help.
    Wait Events Quick Reference Guide
    Wait Problem Potential Fix
    DB File Scattered Read Indicates many full table scans: tune the code; cache small tables.
    DB File Sequential Read Indicates many index reads: tune the code (especially joins).
    Free Buffer Increase the DB_CACHE_SIZE; shorten the checkpoint; tune the code.
    Buffer Busy Segment header: add freelists or freelist groups.
    Buffer Busy Data block: separate "hot" data; use reverse key indexes and/or smaller blocks.
    Buffer Busy Data block: increase initrans and/or maxtrans.
    Buffer Busy Undo header: add rollback segments or areas.
    Buffer Busy Undo block: commit more often; use larger rollback segments or areas.
    Latch Free Investigate the latch detail.
    Enqueue—ST Use LMTs or preallocate large extents.
    Enqueue—HW Preallocate extents above high-water mark.
    Enqueue—TX4 Increase initrans and/or maxtrans on the table or index.
    Enqueue—TM Index foreign keys; check application locking of tables.
    Log Buffer Space Increase the log buffer; use faster disks for the redo logs.
    Log File Switch Archive destination slow or full; add more or larger redo logs.
    Log File Sync Commit more records at a time; use faster redo log disks or raw devices.
    Idle Event Ignore it.
    Common Idle Events
    Event Idle Event Type
    Dispatcher timer Shared server
    Lock manager wait for remote message Oracle9i Real Application Clusters
    Pipe get User process
    pmon timer Background process
    PX Idle wait Parallel query
    PX Deq Credit: need buffer Parallel query
    PX Deq Credit: send blkd Parallel query
    rdbms ipc message Background process
    smon timer Background process
    SQL*Net message from client User process
    virtual Circuit status Shared server
    http://otn.oracle.com/oramag/oracle/03-jan/o13expert.html
    Joel Pérez

  • Consider holding off on a MacBookPro

    It seems there are quite a few quality issues with the MacBookPro. Here's my story, your mileage may vary.
    My MacBookPro had a poorly functioning latch (so that it did not sleep), an annoying noise and sticky feel from the trackpad button, an even more annoying noise from the fan, and a high-pitched whine from the mother board. I sent it in, mostly for the latch problem, and mentioned the others. After OVER THREE WEEKS I have my MacBookPro back with ... a poorly functioning latch, an annoying noise and sticky feel from the trackpad button, and an even more annoying noise from the fan. The whine is gone, but that was the least of the problems.
    I've been buying macs since the mid 80's (i.e., since they've existed) and this is far and away the poorest quality mac I've ever had. Caveat emptor.
    MacBook Pro 15"   Mac OS X (10.4.7)  

    I think your story not only applies to Apple but to many other manufacturers. Nobody makes their products anymore. It is all outsourced and as soon as a problem crops up the fingers point to whomever made that part of the assembly. The automobile companies are the classic example. What is in your Mercedes Benz?
    We have to demand quality. Quality is determined by the consumer, not by the company. You should get back with Apple and state your case. You paid top dollar for the best notebook on the market.

  • Configuring a NI6509 in MAX

    I am configuring a NI6509 and not sure how to remove a latching problem on the input.  Power up state is set to Tristate which I thougt was correct.  However, in CVI when i monitor an input that is High I recieve a correct High response.  When i make that input Low  and monitor I recieve an incorrect High response.  If I then reset the card in MAX and run the function I recieve the correct Low response.
    Is there any way to stop this latching effect in MAX?

    Hi there,
    Are you still experiencing the problem?
    Are you using a PCI or PXI NI 6509?
    What version are your drivers? 
    The latest I can find are: 
    http://sine.ni.com/nips/cds/view/p/lang/en/nid/12919
    http://sine.ni.com/nips/cds/view/p/lang/en/nid/13261
    Is tristate what you want? This means the output will have High, Low and Float states. 
    I hope this helps.
    Tim, CLD, CTD
    National Instruments (UK & Ireland)
    "No problem is insoluble in all conceivable circumstances"

Maybe you are looking for