Detecting slow inserts

We have an application that does hundreds of inserts per second to a specific table.
Naturally we are worried about performance there.
Is there a way to detect when insert into the table takes over X seconds? Ideally the time this occured, the insert command and how long it took will be written to another table, so we can later analyze the results.
Note that we don't want to do extra inserts just for testing how long they will take, we want to monitor the performance of the real application inserts.
Is it possible at all? Does Oracle "know" how long the insert took?

One simple approach is to monitor wait events on relevant segments - your table and its indexes. So using Statspack you can identify (in a 15 minute period, for example) whether there are any buffer busy waits, row lock waits etc, and if so, how long they took. If you have the level right (7, I think) you can also see the cumulative cost of specific SQL including inserts (counts, plus elapsed time and cpu if TIMED_STATISTICS are switched on).
Statspack generally reports the top 5 or 10; you can easily modify that if you like, but if this insert isn't in the top 10, you're probably not interested in tuning it....
HTH
Regards Nigel

Similar Messages

  • Slow inserts

    We suddently started seeing some slow inserts on some test boxes. All boxes are on RedHat 5 and 10.2.0.1.
    We have a multi-tier web application conencting to the DB using connection pool and inserting about a 100000 records in a table. They first do a select, if not found then its an insert. So to take the other pieces out of the puzzle. I wrote a small plssql, which does a select and then does an insert based on some random data generated.
    When I ran this on my test system(db1) it ran about 37 sec, cpu usage was very low. When I ran this on the system that was reported to be slow(db2), it ran for about 30 minutes and CPU was pegged.
    Then I think we let this system and when I tried today, on the system (db2), it completed in about 35 sec. This was wierd. So I re-created the schema (dropped the user) and then ran the test, it was slow again and the CPU was pegged.
    So I thought well may be since the system was not touched (no inserts or any activity) the stats jobs ran, etc that could have been the reason. So ran stats on the database and the schema but no use, it was still slow.
    So then I ran the PL/SQL block on another system (db3) where the schema was created but no iserts or and activty on this box for atleast a few days. But then it was extemely slow in this box as well and cpu was pegged.
    All these boxes have the same table, indexes, they are all identical. Any reason why this could be happening and what else should I be looking for?
    SET timing on;
    DECLARE
       uname    NVARCHAR2 (60);
       primid   NVARCHAR2 (60);
       num      NUMBER;
    BEGIN
       FOR i IN 1 .. 100000
       LOOP
          uname := DBMS_RANDOM.STRING ('x', 20);
          primid := DBMS_RANDOM.STRING ('x', 30);
          DBMS_OUTPUT.put_line (uname || ' ==> ' || primid);
          SELECT   COUNT (*)
              INTO num
              FROM test
             WHERE (deldate IS NULL)
               AND id = 0
               AND (   primid = primid
                    OR UPPER (username) = uname
                    OR uiname = uname
          ORDER BY time DESC;
          INSERT INTO test
               VALUES (0, uname, uname, 1,
                       uname, primid
          IF MOD (i, 200) = 0
          THEN
             COMMIT;
             DBMS_OUTPUT.put_line ('Commited');
          END IF;
       END LOOP;
    END;
    /

    So I used
    execute sys.dbms_support.start_trace_in_session(175, 9629, waits=>true, binds=>false);
    Othere than a couple of these I don't see any other wait events, should I be looking for something else or am I doing the trace wrong. I think this is equivalent to what you suggested.
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      log file sync                                   1        0.00          0.00
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     1        0.00          0.00
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      log file switch completion                      3        0.00          0.00

  • Slow inserts after log size increase

    I have an app that does 10k-50k consecutive SELECTs and INSERTs as part of a loading operation. Recently, I enlarged the redo logs from 10M to 100M, which appears about right, based on the frequency of log switches (half a dozen/day). Trouble is, now the load takes 5 times longer (20-25 min vs. 5). Any thoughts? I thought redo logs that were too small caused poor performance, b/c of increased checkpoint activity, but I can't imagine why larger redo logs would slow inserts down.
    Rob

    Logically the only difference a larger online redo log should make is that the number of checkpoints invoked due to log switches should decrease. But a larger online redo log will take longer to archive.
    Where did you place the larger online redo log and where does the archive redo log go to? Is this performance decrease consistent or does it appear when certain redo logs are in use?
    Even if your logical disk are different it could be the physical disk for some of your files are now the same where before this was not true.
    The suggested statspack is probably a good place to start but you might also want to take some OS IO stats during the run also.
    HTH -- Mark D Powell --

  • Slow insert

    hi,
    my below insert scripts takes lot of time , even dbcontrol displays high hash value for this insert
    insert into id_air_e (aire_key,aire_0) values (:b0,:b1)
    additional details:
    Name          ID_AIR_E
    Tablespace          USERS
    Organization          Standard, Heap Organized
    SQL> desc id_air_e
    Name Null? Type
    AIRE_KEY NOT NULL NUMBER
    AIRE_0 VARCHAR2(240)
    Constraints
    Name     Type     Table Columns     Disabled     Deferrable     Initially Deferred     Validate     RELY
    AIR_E_FKEY     FOREIGN     AIRE_KEY     NO     NO     NO     YES     NO
    SYS_C004747     CHECK     AIRE_KEY     NO     NO     NO     YES     NO
    Indexes
    Number of Indexes          0
    sql> select count(1) from id_air_e
    201456
    any suggestions to increase the insert time

    Hi,
    i created index on FK, dba_blockers view has no records, SGA is also well sized.
    still i face v slow insert in this table
    Name          ID_AIR_E
    Organization     Standard, Heap Organized
    Columns:
    AIRE_KEY     NUMBER     
    AIRE_0     VARCHAR2     240     
    Constraints:
    AIR_E_FKEY     FOREIGN     AIRE_KEY     NO     NO     NO     YES     NO
    SYS_C004747     CHECK     AIRE_KEY     NO     NO     NO     YES     NO
    Indexes:
    AE001T3.ID_AIR_E_INDX     on AIRE_KEY     
    SGA Allocation (MB)
    Shared Pool      304
    Buffer Cache      1664
    Large Pool      16
    Java Pool      16
    Other      48
    PGA : 1800 MB

  • Jdbc thin driver bulk binding slow insertion performance problem

    Hello All,
    We have a third party application reporting slow insertion performance, while I traced the session and found out most of elapsed time for one insert execution is sql*net more data from client, it appears bulk binding is being used here because one execution has 200 rows inserted. I am wondering whether this has something to do with their jdbc thin driver(10.1.0.2 version) and our database version 9205. Do you have any similar experience on this, what other possible directions should I explore?
    here is the trace report from 10046 event, I hide table name for privacy reason.
    Besides, I tested bulk binding in PL/SQL to insert 200 rows in one execution, no problem at all. Network folks confirm that network should not be an issue as well, ping time from app server to db server is sub milisecond and they are in the same data center.
    INSERT INTO ...
    values
    (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17,
    :18, :19, :20, :21, :22, :23, :24, :25, :26, :27, :28, :29, :30, :31, :32,
    :33, :34, :35, :36, :37, :38, :39, :40, :41, :42, :43, :44, :45)
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.02 14.29 1 94 2565 200
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 0.02 14.29 1 94 2565 200
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 25
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net more data from client 28 6.38 14.19
    db file sequential read 1 0.02 0.02
    SQL*Net message to client 1 0.00 0.00
    SQL*Net message from client 1 0.00 0.00
    ********************************************************************************

    I have exactly the same problem, I tried to find out what is going on, changed several JDBC Drivers on AIX, but no hope, I also have ran the process on my laptop which produced a better and faster performance.
    Therefore I made a special solution ( not practical) by creating flat files and defining the data as an external table, the oracle will read the data in those files as they were data inside a table, this gave me very fast insertion into the database, but still I am looking for an answer for your question here. Using Oracle on AIX machine is a normal business process followed by a lot of companies and there must be a solution for this.

  • Jdbc thin driver and bulk binding slow insertion performance

    Hello All,
    We have a third party application reporting slow insertion performance, while I traced the session and found out most of elapsed time for one insert execution is sql*net more data from client, it appears bulk binding is being used here because one execution has 200 rows inserted. I am wondering whether this has something to do with their jdbc thin driver(10.1.0.2 version) and our database version 9205. Do you have any similar experience on this, what other possible directions should I explore?
    here is the trace report from 10046 event, I hide table name for privacy reason.
    Besides, I tested bulk binding in PL/SQL to insert 200 rows in one execution, no problem at all. Network folks confirm that network should not be an issue as well, ping time from app server to db server is sub milisecond and they are in the same data center.
    INSERT INTO ...
    values
    (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17,
    :18, :19, :20, :21, :22, :23, :24, :25, :26, :27, :28, :29, :30, :31, :32,
    :33, :34, :35, :36, :37, :38, :39, :40, :41, :42, :43, :44, :45)
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.02 14.29 1 94 2565 200
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 0.02 14.29 1 94 2565 200
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 25
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net more data from client 28 6.38 14.19
    db file sequential read 1 0.02 0.02
    SQL*Net message to client 1 0.00 0.00
    SQL*Net message from client 1 0.00 0.00
    ********************************************************************************

    I have exactly the same problem, I tried to find out what is going on, changed several JDBC Drivers on AIX, but no hope, I also have ran the process on my laptop which produced a better and faster performance.
    Therefore I made a special solution ( not practical) by creating flat files and defining the data as an external table, the oracle will read the data in those files as they were data inside a table, this gave me very fast insertion into the database, but still I am looking for an answer for your question here. Using Oracle on AIX machine is a normal business process followed by a lot of companies and there must be a solution for this.

  • Extremely slow inserts/updates reported after HW upgrade...

    Hi gyus,
    I'll try to be as descriptive as I can. It's this project in which we have to move circa 6 mission critical (24x7) and mostly OLTP databases from MS Windows 2003 (DB on local disks) to HP-UX IA (CA metrocluster, HP XP 12000 disk array) - all ORA10gR2 10.2.0.4. And everything was perfect until we moved this XYZ database...
    Almost immediately users reported "considerable" performance degradation. According to 3rd party application log they get almost 40 secs. instead of previously recorded 10.
    We, I mean Oracle and HP specialists, haven't noticed/recorded any significant peeks/bottlenecks (RAM, CPU, Disk I/O).
    Feel free to check 3 AWR reports and the init.ora at [http://www.mediafire.com/?sharekey=0269c9bc606747b47f7ec40ada4772a6e04e75f6e8ebb871]
    1_awrrpt_standard.txt - standard workload during 8 hours (peek hours are from 8-12AM)
    2_awrrpt_2hrs_ca.txt - standard workload during 2 peek hours (8-10)
    3_awrrpt_2hrs_noca.txt - standard workload during 2 peek hours (10-12) with CA disk mirroring disabled
    Of course, I've checked the ADDM reports - and first, I'd like to ask why ADDM keeps on reporting the following (on all database instances on this
    cluster node):
    FINDING 1: 100% impact (310 seconds)
    Significant virtual memory paging was detected on the host operating system.
    RECOMMENDATION 1: Host Configuration, 100% benefit (310 seconds)
    Is it just some kind of false alarm (like we use to get on MS Windows)? Both nodes are running on 32gigs of RAM
    with roughly more than 10gigs constantly free.
    Second, as ADDM reported:
    FINDING 2: 44% impact (135 seconds)
    Waits on event "log file sync" while performing COMMIT and ROLLBACK operations
    were consuming significant database time.
    we've tried to split CA disk mirroring, using RAID 10 for redo log file disks etc. etc. No substantial performance gain was reported from users (though I've noticed some in AWR reports).
    Despite confusing app. users' feedback I'm nearly sure that our bottleneck are redo log file disks. Why? Previously (old HW) we had 1-3 ms avg wait on log file sync and log file parallel write and now (new HW, RAID5/RAID10 we've tested both) - it's 8 ms or even more. We were able to get 2ms only with CA switched off (HP etrocluster
    disk array mirroring).
    And that brings up two new questions:
    1. Does redo log group mirroring (2 on 2 separate disks vs. 1 on 1 disk) have any
    significant impact on abovementioned wait events? I mean what performance gain
    could I expect when I drop all "secondary" redo log members?
    2. Why do we get almost identical response times when we run bulk insert/update tests (say
    1000000 rows) against old and new DB/HW?
    Thanks in advance,
    tOPsEEK
    Edited by: smutny on 1.11.2009 17:39
    Edited by: smutny on 1.11.2009 17:46

    Hi again,
    so here's the actual AWR report (1 minute window while the most problematic operation took place). I think it's becoming clear we have to deal with slow redo log writes...
    WORKLOAD REPOSITORY report for
    DB Name         DB Id    Instance     Inst Num Release     RAC Host
    ...            294736156 ...                 1 10.2.0.4.0  NO  ...
                  Snap Id      Snap Time      Sessions Curs/Sess
    Begin Snap:      1254 02-Nov-09 10:07:45        91      46.4
      End Snap:      1255 02-Nov-09 10:08:47        91      46.4
       Elapsed:                1.04 (mins)
       DB Time:                0.51 (mins)
    Cache Sizes
    ~~~~~~~~~~~                       Begin        End
                   Buffer Cache:       576M       576M  Std Block Size:         8K
               Shared Pool Size:       912M       912M      Log Buffer:    14,372K
    Load Profile
    ~~~~~~~~~~~~                            Per Second       Per Transaction
                      Redo size:            163,781.94              4,575.45
                  Logical reads:              1,677.15                 46.85
                  Block changes:              1,276.32                 35.66
                 Physical reads:                  1.99                  0.06
                Physical writes:                  1.16                  0.03
                     User calls:                426.41                 11.91
                         Parses:                 20.74                  0.58
                    Hard parses:                  0.19                  0.01
                          Sorts:                  2.38                  0.07
                         Logons:                  0.00                  0.00
                       Executes:                386.76                 10.80
                   Transactions:                 35.80
      % Blocks changed per Read:   76.10    Recursive Call %:    31.51
    Rollback per transaction %:    0.00       Rows per Sort:   369.98
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Buffer Nowait %:  100.00       Redo NoWait %:  100.00
                Buffer  Hit   %:   99.88    In-memory Sort %:  100.00
                Library Hit   %:   99.90        Soft Parse %:   99.07
             Execute to Parse %:   94.64         Latch Hit %:  100.00
    Parse CPU to Parse Elapsd %:  112.50     % Non-Parse CPU:   99.11
    Shared Pool Statistics        Begin    End
                 Memory Usage %:   88.90   88.87
        % SQL with executions>1:   98.74   99.39
      % Memory for SQL w/exec>1:   95.35   97.75
    Top 5 Timed Events                                         Avg %Total
    ~~~~~~~~~~~~~~~~~~                                        wait   Call
    Event                                 Waits    Time (s)   (ms)   Time Wait Class
    log file parallel write               2,228          21     10   69.4 System I/O
    log file sync                         2,220          21     10   69.2     Commit
    CPU time                                             20          65.5
    SQL*Net break/reset to client         2,106           1      1    3.4 Applicatio
    db file sequential read                 131           0      4    1.5   User I/O
    Time Model Statistics                DB/Inst: ROVEPP/rovepp  Snaps: 1254-1255
    -> Total time in database user-calls (DB Time): 30.9s
    -> Statistics including the word "background" measure background process
       time, and so do not contribute to the DB time statistic
    -> Ordered by % or DB time desc, Statistic name
    Statistic Name                                       Time (s) % of DB Time
    DB CPU                                                   20.2         65.5
    sql execute elapsed time                                  9.1         29.4
    PL/SQL execution elapsed time                             0.3          1.0
    parse time elapsed                                        0.2           .5
    hard parse elapsed time                                   0.1           .5
    repeated bind elapsed time                                0.0           .0
    DB time                                                  30.9          N/A
    background elapsed time                                  22.2          N/A
    background cpu time                                       0.4          N/A
    Wait Class                            DB/Inst: ROVEPP/rovepp  Snaps: 1254-1255
    -> s  - second
    -> cs - centisecond -     100th of a second
    -> ms - millisecond -    1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc
                                                                      Avg
                                           %Time       Total Wait    wait     Waits
    Wait Class                      Waits  -outs         Time (s)    (ms)      /txn
    System I/O                      3,213     .0               22       7       1.4
    Commit                          2,220     .0               21      10       1.0
    Application                     2,106     .0                1       1       0.9
    User I/O                          134     .0                0       4       0.1
    Network                        29,919     .0                0       0      13.4
    Wait Events                          DB/Inst: ROVEPP/rovepp  Snaps: 1254-1255
    -> s  - second
    -> cs - centisecond -     100th of a second
    -> ms - millisecond -    1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc (idle events last)
                                                                       Avg
                                                 %Time  Total Wait    wait     Waits
    Event                                 Waits  -outs    Time (s)    (ms)      /txn
    log file parallel write               2,228     .0          21      10       1.0
    log file sync                         2,220     .0          21      10       1.0
    SQL*Net break/reset to clien          2,106     .0           1       1       0.9
    db file sequential read                 131     .0           0       4       0.1
    control file parallel write              44     .0           0       9       0.0
    db file parallel write                   44     .0           0       4       0.0
    SQL*Net more data to client           3,397     .0           0       0       1.5
    SQL*Net message to client            26,509     .0           0       0      11.9
    control file sequential read            897     .0           0       0       0.4
    SQL*Net more data from clien             13     .0           0       0       0.0
    direct path write                         3     .0           0       0       0.0
    SQL*Net message from client          26,510     .0       1,493      56      11.9
    Streams AQ: qmn slave idle w              2     .0          55   27412       0.0
    Streams AQ: qmn coordinator               4   50.0          55   13706       0.0
    PL/SQL lock timer                        10  100.0          49    4897       0.0
    Background Wait Events               DB/Inst: ROVEPP/rovepp  Snaps: 1254-1255
    -> ordered by wait time desc, waits desc (idle events last)
                                                                       Avg
                                                 %Time  Total Wait    wait     Waits
    Event                                 Waits  -outs    Time (s)    (ms)      /txn
    log file parallel write               2,228     .0          21      10       1.0
    control file parallel write              44     .0           0       9       0.0
    db file parallel write                   44     .0           0       4       0.0
    control file sequential read             71     .0           0       0       0.0
    rdbms ipc message                     2,412    7.7         525     218       1.1
    pmon timer                               20  100.0          59    2929       0.0
    Streams AQ: qmn slave idle w              2     .0          55   27412       0.0
    Streams AQ: qmn coordinator               4   50.0          55   13706       0.0
    Operating System Statistics           DB/Inst: ROVEPP/rovepp  Snaps: 1254-1255
    Statistic                                       Total
    AVG_BUSY_TIME                                     847
    AVG_IDLE_TIME                                   5,362
    AVG_IOWAIT_TIME                                 2,692
    AVG_SYS_TIME                                      295
    AVG_USER_TIME                                     549
    BUSY_TIME                                       3,396
    IDLE_TIME                                      21,457
    IOWAIT_TIME                                    10,776
    SYS_TIME                                        1,190
    USER_TIME                                       2,206
    LOAD                                                0
    OS_CPU_WAIT_TIME                          192,401,000
    RSRC_MGR_CPU_WAIT_TIME                              0
    VM_IN_BYTES                                    40,960
    VM_OUT_BYTES                                  335,872
    PHYSICAL_MEMORY_BYTES                  34,328,276,992
    NUM_CPUS                                            4
    NUM_CPU_SOCKETS                                     4
    Instance Activity Stats              DB/Inst: ROVEPP/rovepp  Snaps: 1254-1255
    Statistic                                     Total     per Second     per Trans
    CPU used by this session                        984           15.8           0.4
    CPU used when call started                      344            5.5           0.2
    CR blocks created                                 4            0.1           0.0
    Cached Commit SCN referenced                    208            3.3           0.1
    Commit SCN cached                                 0            0.0           0.0
    DB time                                       2,589           41.6           1.2
    DBWR checkpoint buffers written                  69            1.1           0.0
    DBWR checkpoints                                  0            0.0           0.0
    DBWR object drop buffers written                  0            0.0           0.0
    DBWR tablespace checkpoint buffe                  0            0.0           0.0
    DBWR thread checkpoint buffers w                  0            0.0           0.0
    DBWR transaction table writes                     8            0.1           0.0
    DBWR undo block writes                           15            0.2           0.0
    IMU CR rollbacks                                  0            0.0           0.0
    IMU Flushes                                   1,156           18.6           0.5
    IMU Redo allocation size                    996,048       16,017.2         447.5
    IMU commits                                   2,100           33.8           0.9
    IMU contention                                    0            0.0           0.0
    IMU ktichg flush                                  0            0.0           0.0
    IMU pool not allocated                            0            0.0           0.0
    IMU recursive-transaction flush                   0            0.0           0.0
    IMU undo allocation size                 22,402,560      360,250.9      10,064.0
    IMU- failed to get a private str                  0            0.0           0.0
    Misses for writing mapping                        0            0.0           0.0
    SQL*Net roundtrips to/from clien             26,480          425.8          11.9
    active txn count during cleanout                 34            0.6           0.0
    application wait time                           106            1.7           0.1
    background checkpoints completed                  0            0.0           0.0
    background checkpoints started                    0            0.0           0.0
    background timeouts                             199            3.2           0.1
    branch node splits                                0            0.0           0.0
    buffer is not pinned count                   13,919          223.8           6.3
    buffer is pinned count                       19,483          313.3           8.8
    bytes received via SQL*Net from             884,016       14,215.7         397.1
    bytes sent via SQL*Net to client          9,602,642      154,418.1       4,313.9
    calls to get snapshot scn: kcmgs             13,641          219.4           6.1
    calls to kcmgas                               3,029           48.7           1.4
    calls to kcmgcs                                  56            0.9           0.0
    change write time                                 8            0.1           0.0
    cleanout - number of ktugct call                 42            0.7           0.0
    cleanouts and rollbacks - consis                  0            0.0           0.0
    cleanouts only - consistent read                  0            0.0           0.0
    cluster key scan block gets                   1,100           17.7           0.5
    cluster key scans                             1,077           17.3           0.5
    commit batch/immediate performed                  1            0.0           0.0
    commit batch/immediate requested                  1            0.0           0.0
    commit cleanout failures: block                   0            0.0           0.0
    commit cleanout failures: buffer                  0            0.0           0.0
    commit cleanout failures: callba                  4            0.1           0.0
    commit cleanout failures: cannot                  0            0.0           0.0
    commit cleanouts                              9,539          153.4           4.3
    commit cleanouts successfully co              9,535          153.3           4.3
    commit immediate performed                        1            0.0           0.0
    commit immediate requested                        1            0.0           0.0
    commit txn count during cleanout                 26            0.4           0.0
    concurrency wait time                             0            0.0           0.0
    consistent changes                              264            4.3           0.1
    consistent gets                              48,659          782.5          21.9
    consistent gets - examination                26,952          433.4          12.1
    consistent gets direct                            2            0.0           0.0
    consistent gets from cache                   48,657          782.4          21.9
    cursor authentications                            2            0.0           0.0
    data blocks consistent reads - u                  4            0.1           0.0
    db block changes                             79,369        1,276.3          35.7
    db block gets                                55,636          894.7          25.0
    db block gets direct                              3            0.1           0.0
    db block gets from cache                     55,633          894.6          25.0
    deferred (CURRENT) block cleanou              4,768           76.7           2.1
    dirty buffers inspected                           0            0.0           0.0
    enqueue conversions                              15            0.2           0.0
    enqueue releases                              9,967          160.3           4.5
    enqueue requests                              9,967          160.3           4.5
    enqueue timeouts                                  0            0.0           0.0
    enqueue waits                                     0            0.0           0.0
    execute count                                24,051          386.8          10.8
    failed probes on index block rec                  0            0.0           0.0
    frame signature mismatch                          0            0.0           0.0
    free buffer inspected                           680           10.9           0.3
    free buffer requested                         1,297           20.9           0.6
    heap block compress                              11            0.2           0.0
    hot buffers moved to head of LRU              1,797           28.9           0.8
    immediate (CR) block cleanout ap                  0            0.0           0.0
    immediate (CURRENT) block cleano              2,274           36.6           1.0
    index crx upgrade (positioned)                   47            0.8           0.0
    index fast full scans (full)                      0            0.0           0.0
    index fetch by key                           10,326          166.1           4.6
    index scans kdiixs1                           6,071           97.6           2.7
    leaf node 90-10 splits                           14            0.2           0.0
    leaf node splits                                 18            0.3           0.0
    lob reads                                         0            0.0           0.0
    lob writes                                      198            3.2           0.1
    lob writes unaligned                            176            2.8           0.1
    logons cumulative                                 0            0.0           0.0
    messages received                             2,272           36.5           1.0
    messages sent                                 2,272           36.5           1.0
    no buffer to keep pinned count                    0            0.0           0.0
    no work - consistent read gets               21,083          339.0           9.5
    opened cursors cumulative                     1,290           20.7           0.6
    parse count (failures)                            0            0.0           0.0
    parse count (hard)                               12            0.2           0.0
    parse count (total)                           1,290           20.7           0.6
    parse time cpu                                   18            0.3           0.0
    parse time elapsed                               16            0.3           0.0
    physical read IO requests                       124            2.0           0.1
    physical read bytes                       1,015,808       16,335.0         456.3
    physical read total IO requests               1,030           16.6           0.5
    physical read total bytes                15,785,984      253,851.1       7,091.6
    physical read total multi block                   0            0.0           0.0
    physical reads                                  124            2.0           0.1
    physical reads cache                            122            2.0           0.1
    physical reads cache prefetch                     0            0.0           0.0
    physical reads direct                             2            0.0           0.0
    physical reads direct (lob)                       0            0.0           0.0
    physical reads direct temporary                   0            0.0           0.0
    physical reads prefetch warmup                    0            0.0           0.0
    physical write IO requests                       47            0.8           0.0
    physical write bytes                        589,824        9,484.8         265.0
    physical write total IO requests              4,591           73.8           2.1
    physical write total bytes               25,374,720      408,045.5      11,399.3
    physical write total multi block              4,461           71.7           2.0
    physical writes                                  72            1.2           0.0
    physical writes direct                            3            0.1           0.0
    physical writes direct (lob)                      3            0.1           0.0
    physical writes direct temporary                  0            0.0           0.0
    physical writes from cache                       69            1.1           0.0
    physical writes non checkpoint                   18            0.3           0.0
    pinned buffers inspected                          1            0.0           0.0
    prefetch warmup blocks aged out                   0            0.0           0.0
    prefetched blocks aged out befor                  0            0.0           0.0
    process last non-idle time                        0            0.0           0.0
    recursive calls                              12,197          196.1           5.5
    recursive cpu usage                             747           12.0           0.3
    redo blocks written                          11,398          183.3           5.1
    redo buffer allocation retries                    0            0.0           0.0
    redo entries                                  6,920          111.3           3.1
    redo log space requests                           0            0.0           0.0
    redo log space wait time                          0            0.0           0.0
    redo ordering marks                              96            1.5           0.0
    redo size                                10,184,944      163,781.9       4,575.5
    redo subscn max counts                          811           13.0           0.4
    redo synch time                               2,190           35.2           1.0
    redo synch writes                             2,220           35.7           1.0
    redo wastage                              1,377,920       22,158.0         619.0
    redo write time                               2,192           35.3           1.0
    redo writer latching time                         0            0.0           0.0
    redo writes                                   2,228           35.8           1.0
    rollback changes - undo records                  24            0.4           0.0
    rollbacks only - consistent read                  4            0.1           0.0
    rows fetched via callback                     1,648           26.5           0.7
    session connect time                              0            0.0           0.0
    session cursor cache hits                     1,242           20.0           0.6
    session logical reads                       104,295        1,677.2          46.9
    session pga memory                        2,555,904       41,101.0       1,148.2
    session pga memory max                            0            0.0           0.0
    session uga memory                          123,488        1,985.8          55.5
    session uga memory max                            0            0.0           0.0
    shared hash latch upgrades - no                  66            1.1           0.0
    sorts (disk)                                      0            0.0           0.0
    sorts (memory)                                  148            2.4           0.1
    sorts (rows)                                 54,757          880.5          24.6
    sql area evicted                                 86            1.4           0.0
    sql area purged                                   0            0.0           0.0
    summed dirty queue length                         0            0.0           0.0
    switch current to new buffer                    596            9.6           0.3
    table fetch by rowid                          9,173          147.5           4.1
    table fetch continued row                         0            0.0           0.0
    table scan blocks gotten                        982           15.8           0.4
    table scan rows gotten                      154,079        2,477.7          69.2
    table scans (cache partitions)                    0            0.0           0.0
    table scans (long tables)                         0            0.0           0.0
    table scans (short tables)                       59            1.0           0.0
    total number of times SMON poste                  0            0.0           0.0
    transaction rollbacks                             1            0.0           0.0
    undo change vector size                   3,990,136       64,164.5       1,792.5
    user I/O wait time                               49            0.8           0.0
    user calls                                   26,517          426.4          11.9
    user commits                                  2,226           35.8           1.0
    user rollbacks                                    0            0.0           0.0
    workarea executions - onepass                     0            0.0           0.0
    workarea executions - optimal                   204            3.3           0.1
    write clones created in backgrou                  0            0.0           0.0
    write clones created in foregrou                  0            0.0           0.0
              -------------------------------------------------------------... and what's even more interesting is the report that I've got using this great Tanel Poder's session snapper script. Take a look at these numbers (excerpt):
    SID      USERNAME        TYPE      STATISTIC                  DELTA         HDELTA/SEC       %TIME
    668      ROVE_EDA        WAIT      log file sync              2253426        450.69ms         45.1%
    668      ROVE_EDA        WAIT      log file sync              2140618        428.12ms         42.8%
    668      ROVE_EDA        WAIT      log file sync              2088327        417.67ms         41.8%
    668      ROVE_EDA        WAIT      log file sync              2184408        364.07ms         36.4%
    668      ROVE_EDA        WAIT      log file sync              2117470        352.91ms         35.3%
    668      ROVE_EDA        WAIT      log file sync              2051280        341.88ms         34.2%
    668      ROVE_EDA        WAIT      log file sync              1595019        265.84ms         26.6%
    668      ROVE_EDA        WAIT      log file sync              612034        122.41ms         12.2%
    668      ROVE_EDA        WAIT      log file sync              2162980         432.6ms         43.3%
    668      ROVE_EDA        WAIT      log file sync              2071811         345.3ms         34.5%
    668      ROVE_EDA        WAIT      log file sync              2004571         334.1ms         33.4%
    668      ROVE_EDA        WAIT      db file sequential read    28401          5.68ms           .6%
    668      ROVE_EDA        WAIT      db file sequential read    29028          4.84ms           .5%
    668      ROVE_EDA        WAIT      db file sequential read    24846          4.14ms           .4%
    668      ROVE_EDA        WAIT      db file sequential read    24323          4.05ms           .4%
    668      ROVE_EDA        WAIT      db file sequential read    17026          3.41ms           .3%
    668      ROVE_EDA        WAIT      db file sequential read    6736          1.35ms           .1%
    668      ROVE_EDA        WAIT      db file sequential read    33028           5.5ms           .6%
    764      (LGWR)          WAIT      log file parallel write    2236748        447.35ms         44.7%
    764      (LGWR)          WAIT      log file parallel write    2150825        430.17ms         43.0%
    764      (LGWR)          WAIT      log file parallel write    2139532        427.91ms         42.8%
    764      (LGWR)          WAIT      log file parallel write    2119086        423.82ms         42.4%
    764      (LGWR)          WAIT      log file parallel write    2134938        355.82ms         35.6%
    764      (LGWR)          WAIT      log file parallel write    2083649        347.27ms         34.7%
    764      (LGWR)          WAIT      log file parallel write    2034998        339.17ms         33.9%
    764      (LGWR)          WAIT      log file parallel write    1996050        332.68ms         33.3%
    764      (LGWR)          WAIT      log file parallel write    1797057        299.51ms         30.0%
    764      (LGWR)          WAIT      log file parallel write    555403        111.08ms         11.1%
    764      (LGWR)          WAIT      log file parallel write    277875         46.31ms          4.6%
    764      (LGWR)          WAIT      log file parallel write    2067591         344.6ms         34.5%Where SID=668 is the session we've been looking for... OK, we've got to get back to monitoring disk array and the corresponding network components.
    tOPsEEK

  • Using NI-VISA to detect USB insertion/​removal

    Is there a way to use NI-VISA to detect when a USB device has been inserted or removed?
    I am currently using Windows API in my LabWindows application to capture the WM_DEVICECHANGE event.  When this event is called, I check to see if the USB devices are still connected to my PC  by using viFindRsrc function.  On Windows XP 32-bit, this approached worked successfully.  On my Windows 7 64-bit system this is no longer working.  After I remove the USB device, the viFindRsrc function is still indicating that the device is connected even though it isn't. 
    Also, when a USB device is controlled by a NI-VISA driver, I cannot capture the Windows DBT_DEVICEARRIVAL and DBT_DEVICEREMOVECOMPLETE events.  I am able to see these events for other USB devices that are not controlled by a NI-VISA driver.
    Solved!
    Go to Solution.

    I solved the issue.
    The behavior of the NI-VISA driver requires that you register to receive Windows notifications. The other USB devices that weren't controlled by a NI-VISA driver didn't require me to register to receive the DBT_DEVICEARRIVAL and DBT_DEVICEREMOVECOMPLETE events.  I received them by default...
    Here is the code to register USB events
    Here is the code where I register the USB events:
    DEV_BROADCAST_DEVICEINTERFACE NotificationFilter;
    intptr_t postHandle = 0;
    /* Windows HWND */
    HWND hWnd = 0;
    long long unsigned int hWndVal = 0;
    /* Get HWND of LabWindows\CVI panel */
    GetPanelAttribute(panelHandle,ATTR_SYSTEM_WINDOW_H​ANDLE,&hWndVal);
    hWnd = (HWND)hWndVal;
    * USB Raw Device
    * Device Interface Class GUID = {a5dcbf10-6530-11d2-901f-00c04fb951ed}
    GUID_CLASS_USB_DEVICE.Data1 = 0xA5DCBF10L;
    GUID_CLASS_USB_DEVICE.Data2 = 0x6530;
    GUID_CLASS_USB_DEVICE.Data3 = 0x11D2;
    GUID_CLASS_USB_DEVICE.Data4[0] = 0x90;
    GUID_CLASS_USB_DEVICE.Data4[1] = 0x1F;
    GUID_CLASS_USB_DEVICE.Data4[2] = 0x00;
    GUID_CLASS_USB_DEVICE.Data4[3] = 0xC0;
    GUID_CLASS_USB_DEVICE.Data4[4] = 0x4F;
    GUID_CLASS_USB_DEVICE.Data4[5] = 0xB9;
    GUID_CLASS_USB_DEVICE.Data4[6] = 0x51;
    GUID_CLASS_USB_DEVICE.Data4[7] = 0xED;
    NotificationFilter.dbcc_size = sizeof(DEV_BROADCAST_DEVICEINTERFACE);
    NotificationFilter.dbcc_devicetype = DBT_DEVTYP_DEVICEINTERFACE;
    NotificationFilter.dbcc_classguid = GUID_CLASS_USB_DEVICE;
    * Installs a callback function for WM_DEVICECHANGE Windows message posted
    * or sent to a LabWindows/CVI panel.
    InstallWinMsgCallback (panelHandle, WM_DEVICECHANGE,
    WindowsDeviceDetection, VAL_MODE_INTERCEPT, NULL, &postHandle);
    * Register device notification for USB Raw Device interface class GUID
    RegisterDeviceNotification(hWnd, &NotificationFilter,
    DEVICE_NOTIFY_WINDOW_HANDLE);
    Here is the code that responds:
    static int CVICALLBACK WindowsDeviceDetection (int panelHandle, int message,
    unsigned int* wParam, unsigned int* lParam, void* callbackData)
    PDEV_BROADCAST_HDR lpdb = (PDEV_BROADCAST_HDR)lParam;
    switch (message)
    /* Received Windows WM_DEVICECHANGE message */
    case WM_DEVICECHANGE:
    switch (*wParam)
    * Received Windows device-change event "DBT_DEVNODES_CHANGED".
    * Device has been added or removed from the system.
    case DBT_DEVNODES_CHANGED:
    printf("[%s] DBT_DEVNODES_CHANGED\n",TimeStr());
    break;
    * Received Windows device-change event "DBT_DEVICEARRIVAL".
    case DBT_DEVICEARRIVAL:
    printf("[%s] DBT_DEVICEARRIVAL\n",TimeStr());
    break;
    * Received Windows device-change event "DBT_DEVICEREMOVECOMPLETE".
    case DBT_DEVICEREMOVECOMPLETE:
    printf("[%s] DBT_DEVICEREMOVECOMPLETE\n",TimeStr());
    break;
    default:
    break;
    return 0;

  • Very slow insert and query

    Dear Professionals:
    The insert and query become very slow and somtimes hang. It wasn't like this before .. Network people added 100 pc to the network .. most of them not using the databse only internet and we are all in the same network .. Can this slow down the database Oracle 9.2.0.1.0 OS w2k server ? And how to know that the slowness is from network and not from query or inserts ?
    Ahmed.

    Hi,
    >>Network people added 100 pc to the network .. most of them not using the databse only internet. Can this slow down the database Oracle 9.2.0.1.0 OS w2k server ?
    Maybe yes, maybe not, maybe a network performance problem ...
    If you try to execute these DML's (insert, ...) and querys directly on the Server, what's happen ?
    Cheers

  • Slow Inserts Using IKM SQL to SQL Append

    Hi all.
    I'm in a big, big trouble.
    I have a interface that gets that from the source and insert in the target (obvious)... but the unique way to insert into target is using SQL to SQL Append.
    Unfortunately, the inserts are about 10 rows/sec. Very, very, very slow.
    There are any ways to do the Agent faster than this?
    Regards.
    Luiz Araujo (a.k.a. Buchu_VP)

    My Staging Area is different from the target area, but unfortunately I'm not able to change this 'cause my sources are accessed via DBLink and there are restrictions to it, enabling only the IP and HostName of my ODI database. My target tables are located in a third server, in the same domain as my ODI database, but there are no DBLinks between them so I have to use SQL to SQL Append.
    Thanks in advance.
    Luiz Araujo (a.k.a. Buchu_VP)
    Edited by: Luiz Araujo (a.k.a. Buchu) on Jun 1, 2010 7:38 AM

  • Air for Android - Sqlite - Slow inserts

    Hello there,
    What is the best way to follow in order to make a lot of insert on a sqlite db?
    I ask because I noticed a great and unpredicatable slowdown on my Galaxy S when I make a lot of insert.
    I use an openAsync connection because I need to monitor what is happening.
    Everytime a row is created I increment a counter.
    It starts well, then after a 100 insert it slow down and nearly dies.
    Any suggestions?
    Thanks in advance

    I optimized the query:
    - I reuse the same statement and changing only the parameters
    - I use the transaction with begin and commit
    This speeded up the whole things in an incredible way, however I still notice a slow down that luckily, after the optimizations I made, never dies.
    Any other suggestion will be appreciated!

  • Slow inserts into partitioned table

    I am having trouble inserting into a simple partitioned table after an upgrade to 11.2.0.3. I'm seeing insert speeds of subsecond up to 10 and 12 seconds. We have pre created the partitions for this table (and all children via reference partitioning). We have gathered dictionary and static object stats as well as statistics on all partitions.
    Queries against the dictionary are incredibly slow as well and showing very high io.
    Any help would be greatly appreciated. Thank you for your time.
    Windows 2008 advanced server
    Oracle Enterprise edition 11.2.0.3
    Edited by: user593549 on Mar 26, 2012 11:16 AM

    user593549 wrote:
    I am having trouble inserting into a simple partitioned table after an upgrade to 11.2.0.3. I'm seeing insert speeds of subsecond up to 10 and 12 seconds. We have pre created the partitions for this table (and all children via reference partitioning). We have gathered dictionary and static object stats as well as statistics on all partitions.
    Queries against the dictionary are incredibly slow as well and showing very high io.
    Any help would be greatly appreciated. Thank you for your time.
    Windows 2008 advanced server
    Oracle Enterprise edition 11.2.0.3
    Edited by: user593549 on Mar 26, 2012 11:16 AMThread: HOW TO: Post a SQL statement tuning request - template posting
    HOW TO: Post a SQL statement tuning request - template posting

  • Slow Insert APPEND into Temporary Table

    Hello,
    We did the following test on Oracle11g 11.1.0.7 database:
    create global temporary table test_tab
    as select * from tab1 where rownum <= 1;
    insert into test_tab select * from tab1 where rownum <= 500000;
    commit;
    Elapsed time: 00:00:04.56
    Statistic
    80 recursive calls
    26360 db block gets
    10606 consistent gets
    4729 physical reads
    2543400 redo size
    399 bytes sent via SQL*Net to client
    340 bytes received via SQL*Net from client
    6 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    500000 rows processed
    truncate table test_tab;
    insert /*+ append */ into test_tab select * from tab1 where rownum <= 500000;
    commit;
    Elapsed time: 00:00:09.35
    Statistic
    84 recursive calls
    4900 db block gets
    4738 consistent gets
    4698 physical reads
    1128 redo size
    376 bytes sent via SQL*Net to client
    354 bytes received via SQL*Net from client
    6 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    500000 rows processed
    Note that insert APPEND generates much less redo size: 1128 vs 2543400 . Now the question: why insert APPEND into the temporary table is two times slower than the ordinary insert? Potentially, it should run faster because of lower redo size... Any ideas?

    If you run the truncate / insert / truncate / insert append again are the timings the same ?
    Wondering if the temp tablespace needed to extend for the first append.

  • Detecting if insert  or modify a footnote

    Hi
    I want to detect in my plugin if insert or modify a footnote on current document.
    If user insert or modify a footnote, I will do something in my plugin.
    How can I do?
    thanks

    You can use following code.
    FUNCTION zcmbalance.
    ""Local Interface:
    *" IMPORTING
    *" REFERENCE(DATE) TYPE ZFINTBCM017-GLDATE
    *" REFERENCE(COMPANY_CODE) TYPE ZFINTBCM017-GLCCODE
    *" REFERENCE(GL_ACCOUNT) TYPE ZFINTBCM017-GLACCOUNT
    *" REFERENCE(PROFIT_CENTER) TYPE ZFINTBCM017-GLPRFCENTER
    *" REFERENCE(SUBSIDIARY_BALANCE) TYPE ZFINTBCM017-SUBBALANCE
    TABLES:
    ZBALANCEINT.
    <b>DATA: ZBAL LIKE ZBALANCEINT.</b>
    ZBAL-ZDATE = DATE
    ZBAL-ZCODE = COMPANY_CODE
    ZBAL-ZACCOUNT = GL_ACCOUNT
    ZBAL-ZCENTER = PROFIT_CENTER.
    SELECT SINGLE *
    FROM ZBALANCEINT
    WHERE ZDATE = DATE
    AND ZCODE = COMPANY_CODE
    AND ZACCOUNT = GL_ACCOUNT
    AND ZCENTER = PROFIT_CENTER.
    IF sy-subrc <> 0.
    <b>ZBAL-ZBALANCE = SUBSIDIARY_BALANCE.</b>
    <b>INSERT ZBALANCEINT FROM ZBAL.</b>
    ELSE.
    <b>ZBAL-ZBALANCE = SUBSIDIARY_BALANCE.</b>
    <b>MODIFY ZBALANCEINT FROM ZBAL.</b>
    ENDIF.
    COMMIT WORK.
    ENDFUNCTION.

  • Fast select , slow insert

    hi ,
    i have a query that is fast in selection but somewhat very slow with the insertion with either create table as select OR the insert into table statment
    my table is an empty table and does not have any indexes created
    pls advise
    tks & rgds

    hi ,
    this is my SQLs
    INSERT INTO /*+ APPEND */ AfterSales_Tbl
    select a.txn_date , a.product_id , a.sales_date, a.sales_amountfrom MV_Txn a , MV_Sales bwhere a.txnid = b.salesidand b.sales_dates between trunc(sysdate) and trunc(sysdate) - 7
    [/pre
    rgds                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

Maybe you are looking for

  • How do i transfer photos from an old library to my current one ??????

      how do i transfer photos from an Iphone that has been sync to an old Itunes library and transfer the data to my new itunes library ???????

  • FCPx is repeatedly crashing when I try to create a new project.

    This started a few days ago, when FCPx crashed in the midst of my work, and I was unable to open the program without the spinning wheel. I deleted all events and projects, and re-installed the program, and now I can get it open successfully. But nwo

  • How do set multi ip address on solaris8

    I set multi ip address by following command: inconfig hme0:1 159.226.140.55 netmask 255.255.255.0 system error:not found interface hme0:1. I shoud how to set multi ip address on solaris8

  • FONTS on OSX 10.4 And Under Classic (System 9 )

    Okay - Ya' all be gentle. Remember - there are no STUPID questions. I'm running a new G5 but have lots of earlier stuff and a very large file of FONTS on my old - very old - G3 - system 9.2. Classic seems to be running fine but the fonts available in

  • Basic RAM upgrade question

    Hi, I've read a lot of threads on ram upgrades, but still have a very basic question. I want to buy the $599 Mac Mini, which comes with 1G RAM. Clearly, the Mac RAM is overpriced, but I've been told by a friend to upgrade to at least 2G for $50 extra