Cache loader images prior to loading?

hi,
is there a way to cache external jpg images prior to them
being called with the loader component? download them in the
background and not when the parent movieclip is loaded? i am trying
to keep the user from having to wait either at the beginning to
load the flash mc, or during it as well.
would it work if i had the parent html document preloadimages
or would flash be looking somewhere else for them?
also, can i use a fade effect on externally loaded images?
thanks for any help

For the caching question, here's an approach (read all the
comments its not perfect) using flash loadVars.
http://www.actionscript.com/Article/tabid/54/ArticleID/Preloading-Files-into-the-Browser-s -Cache/Default.aspx

Similar Messages

  • High library cache load lock waits in AWR

    Hi All,
    Today i faced a significant performance problem related to shared pool. I made some observations, thought it would be a nice idea to share them with Oracle experts. Please feel free to add your observations/recommendations and correct me where i am wrong.
    Here are the excerpts from AWR report created for the problem timing. Database server is on 10.2.0.3 and running with 2*16 configuration. DB cache size is 4,000M and shared pool size is of 3008M.
    Snap Id Snap Time Sessions Cursors/Session
    Begin Snap: 9994 29-Jun-09 10:00:07 672 66.3
    End Snap: 10001 29-Jun-09 17:00:49 651 64.4
    Elapsed:   420.70 (mins)    
    DB Time:   4,045.34 (mins)   -- Very poor response time visible from difference between DB time and elapsed time.
    Load Profile
    Per Second Per Transaction
    Redo size: 248,954.70 23,511.82
    Logical reads: 116,107.04 10,965.40
    Block changes: 1,357.13 128.17
    Physical reads: 125.49 11.85
    Physical writes: 51.49 4.86
    User calls: 224.69 21.22
    Parses: 235.22 22.21
    Hard parses: 4.83 0.46
    Sorts: 102.94 9.72
    Logons: 1.12 0.11
    Executes: 821.11 77.55
    Transactions: 10.59   -- User calls and Parse count are almost same, means most of the calls are for parse. Most of the parses are soft. Per transaction 22 parses are very high figure.
    -- Not much disk I/O activity. Most of the reads are being satisfy from memory.
    Instance Efficiency
    Buffer Nowait %: 100.00 Redo NoWait %: 100.00
    Buffer Hit %: 99.92 In-memory Sort %: 100.00
    Library Hit %: 98.92 Soft Parse %: 97.95
    Execute to Parse %: 71.35 Latch Hit %: 99.98
    Parse CPU to Parse Elapsd %: 16.82 % Non-Parse CPU: 91.41 -- Low execute to parse ratio denotes CPU is significantly busy in parsing. Soft Parse% showing, most of the parse are soft parses. It means we should concentrate on soft parsing activity.
    -- Parse CPU to Parse Elapsed % is quite low, means some bottleneck is there related to parsing. It could be a side-effect of huge parsing pressure. Like CPU cycles are not available.
    Shared Pool Statistics
    Begin End
    Memory Usage %: 81.01 81.92
    % SQL with executions>1: 88.51 86.93
    % Memory for SQL w/exec>1: 86.16 86.76 -- Shared Pool memory seems ok (in 80% range)
    -- 88% of the SQLs are repeating ones. It's a good sign.
    Top 5 Timed Events
    Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
    library cache load lock 24,243 64,286 2,652 26.5 Concurrency
    db file sequential read 1,580,769 42,267 27 17.4 User I/O
    CPU time   33,039   13.6  
    latch: library cache 53,013 29,194 551 12.0 Concurrency
    db file scattered read 151,669 13,550 89 5.6 User I/O Problem-1: Contention on Library cache: May be due to under-sized shared pool, incorrect parameters, poor application design, But since we already observed that most of the parses are soft parses and shared pool usgae in 80%, seems problem related to holding cursors. open_cursors/session_cached_cursors are red flags.
    Problem-2: User I/O, may be due to poor SQLs, I/O sub-system, or poor physical design (wrong indexes are being used as DB file seq reads)
    Wait Class
    Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
    Concurrency 170,577 44.58 109,020 639 0.64
    User I/O 2,001,978 0.00 59,662 30 7.49
    System I/O 564,771 0.00 8,069 14 2.11
    Application 145,106 1.25 6,352 44 0.54
    Commit 176,671 0.37 4,528 26 0.66
    Other 27,557 6.31 2,532 92 0.10
    Network 6,862,704 0.00 696 0 25.68
    Configuration 3,858 3.71 141 37 0.01
    Wait Events
    Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
    library cache load lock 24,243 83.95 64,286 2652 0.09
    db file sequential read 1,580,769 0.00 42,267 27 5.91
    latch: library cache 53,013 0.00 29,194 551 0.20
    db file scattered read 151,669 0.00 13,550 89 0.57
    latch: shared pool 25,403 0.00 12,969 511 0.10
    log file sync 176,671 0.37 4,528 26 0.66
    enq: TM - contention 1,455 90.93 3,975 2732 0.01 Instance Activity Stats
    opened cursors cumulative 5,290,760 209.60 19.80
    parse count (failures) 6,181 0.24 0.02
    parse count (hard) 121,841 4.83 0.46
    parse count (total) 5,937,336 235.22 22.21
    parse time cpu 283,787 11.24 1.06
    parse time elapsed 1,687,096 66.84 6.31 Latch Activity
    library cache 85,042,375 0.15 0.43 29194 304,831 7.16
    library cache load lock 257,089 0.00 1.20 0 69,065 0.00
    library cache lock 41,467,300 0.02 0.07 6 2,714 0.07
    library cache lock allocation 730,422 0.00 0.44 0 0  
    library cache pin 28,453,986 0.01 0.16 8 167 0.00
    library cache pin allocation 509,000 0.00 0.38 0 0 Init.ora parameters
    cursor_sharing= EXACT
    open_cursors= 3000
    session_cached_cursors= 0
    -- open_cursors value is too high. I have checked that maximum usage by a single session is 12%.
    -- session_cached_cursors are 0 causing soft parsing. 500/600 is good number to start with.
    cursor_sharing exact may cause hard parses. But here, hard parsing is comparatively small, we can ignore this.
    From v$librarycache
    NAMESPACE             GETS    GETHITS GETHITRATIO       PINS PINHITRATIO    RELOADS INVALIDATIONS
    SQL AREA            162827      25127  .154317159  748901435  .999153087     107941         81886-- high invalidation count due to DDL like activities.
    -- high reloads due to small library cache.
    -- hit ratio too small.
    -- Need to pin frequently executed objects into library cache.
    P.S. Same question asked on Oracle_L, but due to formatting reasons, pasing duplicate contents here.
    Regards,
    Neeraj Bhatia
    Edited by: Neeraj.Bhatia2 on Jul 13, 2009 6:51 AM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    Thanks Charles. I really appreciate your efforts to diagnose the issue.
    I agree with you performance issue is caused by soft parsing, which can be solved by holding cursors (session_cached_cursors). It may be due to oversized shared pool, which is causing delay in searching child cursors.
    My second thought is, there is large number of reloads, which can be due to under-sized shared pool, if invalidation activities are not going (CBO statistics collection, DDL etc), cursors are being flushed frequently.
    CPU utilization is continuously high (above 90%). Pasting additional information from same AWR report.
    Namespace                Get Requests       Pct Miss        Pin Requests         Pct Miss      Reloads        Invalidations
    BODY                       225,345               0.76            4,965,541            0.15           5,533           0
    CLUSTER                   1,278                  1.41            2,542                  1.73           26                0
    INDEX                       5,982                  9.31            13,922                7.35           258               0
    SQL AREA                  141,465              54.10           27,831,235         1.21           69,863          19,085 Latch Miss Sources
    Latch Name             Where                                         NoWait Misses                 Sleeps             Waiter Sleeps
    library cache lock       kgllkdl: child: no lock handle             0                                   8,250                   5,792 Time Model Statistics
    Statistic Name                                                                           Time (s)                               % of DB Time
    sql execute elapsed time                                                           206,979.31                                      85.27
    PL/SQL execution elapsed time                                                    94,651.78                                      39.00
    DB CPU                                                                                     33,039.29                                      13.61
    parse time elapsed                                                                      22,635.47                                       9.33
    inbound PL/SQL rpc elapsed time                                                  14,763.48                                       6.08
    hard parse elapsed time                                                               14,136.77                                       5.82
    connection management call elapsed time                                        1,625.07                                       0.67
    PL/SQL compilation elapsed time                                                        760.76                                       0.31
    repeated bind elapsed time                                                               664.81                                       0.27
    hard parse (sharing criteria) elapsed time                                             500.11                                       0.21
    Java execution elapsed time                                                              252.95                                       0.10
    failed parse elapsed time                                                                   167.23                                       0.07
    hard parse (bind mismatch) elapsed time                                             124.11                                       0.05
    sequence load elapsed time                                                                23.34                                        0.01
    DB time                                                                                   242,720.12  
    background elapsed time                                                             11,645.52  
    background cpu time                                                                      247.25 According to this DB CPU is 65% utilization (DB CPU + Background CPU / Total Available CPU seconds). While at the same time DB host was 95% utilized (confirmed from DBA_HIST_SYSMETRIC_SUMMARY).
    Operating System Statistics
    Statistic                                         Total
    BUSY_TIME                             3,586,030
    IDLE_TIME                              1,545,064
    IOWAIT_TIME                              22,237
    NICE_TIME                                           0
    SYS_TIME                                  197,661
    USER_TIME                              3,319,452
    LOAD                                                 11
    RSRC_MGR_CPU_WAIT_TIME                  0
    PHYSICAL_MEMORY_BYTES          867,180
    NUM_CPUS                                           2

  • ROW CACHE ENQUEUE LOCK/ibrary cache load lock leads to database hung

    (lowercase, curly brackets, no spaces)
    We faced database hung on 3 node 11i erp 9i rac database.
    We saw the library cache load lock timed out events reported in alert log.
    Then few ora-600 and later ROW CACHE ENQUEUE LOCK timed out event. Eventually database was hung and we had to bounce the services .
    we created support sr 7845542.992 for RCA.
    The support says to increase shared pool size to avoid shared pool fragmentation and avoid reload ,additionaly to upgrade to 10g database.
    I am not covinced adding additional pool size would solve this or upgrade to 10 .furthermore even 10g has such issues reported.
    I saw couple of bugs mentioned such issue can happen due deadlock of session holding latches .
    kindly let me know your view on issue
    If required i can attach statspack for more information. (lowercase, curly brackets, no spaces)

    Many Thanks, i was keen to have your update .
    There are 8 cpus on each node . Reloads very high during time period ,but normally there are not high reloads.
    Statspack details for 3 nodes
    STATSPACK report for
    DB Name         DB Id    Instance     Inst Num Release     Cluster Host
    PROD            21184234 PROD1               1 9.2.0.8.0   YES     npi-or-db-p-
                                                                       11.npi.corp
                  Snap Id     Snap Time      Sessions Curs/Sess Comment
    Begin Snap:    149817 30-Oct-09 13:00:09      574 #########
      End Snap:    149837 30-Oct-09 14:00:17      602 #########
       Elapsed:               60.13 (mins)
    Cache Sizes (end)
    ~~~~~~~~~~~~~~~~~
                   Buffer Cache:     8,192M      Std Block Size:          8K
               Shared Pool Size:     1,024M          Log Buffer:     10,240K
    Load Profile
    ~~~~~~~~~~~~                            Per Second       Per Transaction
                      Redo size:            122,414.93             11,449.13
                  Logical reads:             69,550.76              6,504.89
                  Block changes:                928.41                 86.83
                 Physical reads:                196.24                 18.35
                Physical writes:                 28.65                  2.68
                     User calls:                343.97                 32.17
                         Parses:                558.61                 52.25
                    Hard parses:                 43.48                  4.07
                          Sorts:                467.24                 43.70
                         Logons:                  0.63                  0.06
                       Executes:              2,046.99                191.45
                   Transactions:                 10.69
      % Blocks changed per Read:    1.33    Recursive Call %:     97.59
    Rollback per transaction %:    5.07       Rows per Sort:     15.85
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Buffer Nowait %:  100.00       Redo NoWait %:    100.00
                Buffer  Hit   %:   99.72    In-memory Sort %:    100.00
                Library Hit   %:   96.79        Soft Parse %:     92.22
             Execute to Parse %:   72.71         Latch Hit %:     99.77
    Parse CPU to Parse Elapsd %:   60.10     % Non-Parse CPU:     78.07
    -> 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
                                                         Total Wait   wait    Waits
    Event                               Waits   Timeouts   Time (s)   (ms)     /txn
    db file sequential read           249,234          0      1,537      6      6.5
    db file scattered read             61,776          0        769     12      1.6
    row cache lock                    780,098         10        566      1     20.2
    library cache lock                697,849        157        432      1     18.1
    latch free                        127,926      4,715        387      3      3.3
    global cache cr request           370,770      3,091        309      1      9.6
    PL/SQL lock timer                      59         58        112   1903      0.0
    wait for scn from all nodes       303,572         18        103      0      7.9
    library cache pin                  26,231          2        100      4      0.7
    global cache null to x             17,717        716         92      5      0.5
    buffer busy waits                   5,388         18         74     14      0.1
    db file parallel read               5,245          0         69     13      0.1
    log file sync                      20,407         29         66      3      0.5
    enqueue                            52,200         70         60      1      1.4
    buffer busy global CR               4,845         33         55     11      0.1
    CGS wait for IPC msg              412,512    407,106         50      0     10.7
    ksxr poll remote instances      1,279,565    483,046         48      0     33.2
    log file parallel write           160,040          0         42      0      4.1
    library cache load lock             1,491          2         29     20      0.0
    global cache open x                19,507        344         28      1      0.5
    buffer busy global cache              957          0         22     23      0.0
    global cache s to x                16,516        180         20      1      0.4
    db file parallel write             11,120          0         12      1      0.3
    log file sequential read              618          0         11     18      0.0
    DFS lock handle                    23,768          0         10      0      0.6
    control file sequential read        8,563          0          4      0      0.2
    KJC: Wait for msg sends to c        1,549         57          4      3      0.0
    lock escalate retry                    76         76          4     52      0.0
    SQL*Net break/reset to clien       12,546          0          3      0      0.3
    SQL*Net more data to client        85,773          0          3      0      2.2
    control file parallel write         1,265          0          2      1      0.0
    global cache null to s                648         23          1      2      0.0
    global cache busy                     200          0          1      5      0.0
    global cache open s                 1,493         28          1      1      0.0
    log file switch completion             12          0          1     61      0.0
    PX Deq Credit: send blkd              161         70          1      4      0.0
    kksfbc child completion               119        118          1      5      0.0
    PX Deq: reap credit                 5,948      5,456          0      0      0.2
    PX Deq: Execute Reply                  83         29          0      3      0.0
    process startup                         8          0          0     25      0.0
    LGWR wait for redo copy               992         12          0      0      0.0
    IPC send completion sync              450        450          0      0      0.0
    PX Deq: Parse Reply                   100         28          0      1      0.0
    undo segment extension             10,380     10,372          0      0      0.3
    PX Deq: Join ACK                      146         65          0      1      0.0
    buffer deadlock                       222        221          0      0      0.0
    async disk IO                       1,179          0          0      0      0.0
    wait list latch free                    2          0          0     16      0.0
    PX Deq: Msg Fragment                  112         28          0      0      0.0
    Library Cache Activity for DB: PROD  Instance: PROD1  Snaps: 149817 -149837
    ->"Pct Misses"  should be very low
                             Get  Pct        Pin        Pct               Invali-
    Namespace           Requests  Miss     Requests     Miss     Reloads  dations
    BODY                 116,007    1.1        133,347   19.9     24,338        0
    CLUSTER                4,224    0.6          5,131    1.0          0        0
    INDEX                 15,048   24.1         13,798   26.4          2        0
    JAVA DATA                 82    0.0            692   39.6        136        0
    JAVA RESOURCE             66   39.4            206   25.2         12        0
    PIPE                   1,140    0.5          1,160    0.5          0        0
    SQL AREA           1,197,908   12.6     13,517,660    1.5    111,833       73
    TABLE/PROCEDURE    3,847,439    0.8      4,230,265    7.9    142,200        0
    TRIGGER                8,444    2.4          8,657   18.5      1,274        0
                        GES Lock      GES Pin      GES Pin   GES Inval GES Invali-
    Namespace           Requests     Requests     Releases    Requests     dations
    BODY                       1        1,234        1,258         985           0
    CLUSTER                3,222           25           25          25           0
    INDEX                 13,792        3,641        3,631       3,629           0
    JAVA DATA                  0            0            0           0           0
    JAVA RESOURCE              0           26           25           0           0
    PIPE                       0            0            0           0           0
    SQL AREA                   0            0            0           0           0
    TABLE/PROCEDURE      857,137       13,130       13,264      10,762           0
    TRIGGER                    0          200          202         200           0
    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    STATSPACK report for
    DB Name         DB Id    Instance     Inst Num Release     Cluster Host
    PROD            21184234 PROD2               2 9.2.0.8.0   YES     npi-or-db-p-
                                                                       12.npi.corp
                  Snap Id     Snap Time      Sessions Curs/Sess Comment
    Begin Snap:    149847 30-Oct-09 14:00:05      493 #########
      End Snap:    149857 30-Oct-09 15:00:02      432 #########
       Elapsed:               59.95 (mins)
    Cache Sizes (end)
    ~~~~~~~~~~~~~~~~~
                   Buffer Cache:     8,192M      Std Block Size:          8K
               Shared Pool Size:     1,024M          Log Buffer:     10,240K
    Load Profile
    ~~~~~~~~~~~~                            Per Second       Per Transaction
                      Redo size:             71,853.44             32,058.65
                  Logical reads:            273,904.84            122,207.36
                  Block changes:                889.13                396.70
                 Physical reads:                 40.40                 18.03
                Physical writes:                 20.97                  9.35
                     User calls:                153.74                 68.60
                         Parses:                 66.19                 29.53
                    Hard parses:                  2.66                  1.19
                          Sorts:                 25.70                 11.47
                         Logons:                  0.16                  0.07
                       Executes:                726.41                324.10
                   Transactions:                  2.24
      % Blocks changed per Read:    0.32    Recursive Call %:     92.41
    Rollback per transaction %:    4.84       Rows per Sort:    193.55
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Buffer Nowait %:  100.00       Redo NoWait %:     99.99
                Buffer  Hit   %:   99.99    In-memory Sort %:    100.00
                Library Hit   %:   99.35        Soft Parse %:     95.97
             Execute to Parse %:   90.89         Latch Hit %:     99.99
    Parse CPU to Parse Elapsd %:   36.55     % Non-Parse CPU:     98.28
    Wait Events for DB: PROD  Instance: PROD2  Snaps: 149847 -149857
    -> 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
                                                         Total Wait   wait    Waits
    Event                               Waits   Timeouts   Time (s)   (ms)     /txn
    enqueue                            65,823     33,667     90,459   1374      8.2
    row cache lock                     38,996        560      1,795     46      4.8
    PX Deq Credit: send blkd              522        499      1,223   2344      0.1
    PX Deq: Parse Reply                   466        416        987   2117      0.1
    db file sequential read            50,130          0        421      8      6.2
    library cache lock                 78,842        172        210      3      9.8
    db file scattered read              6,904          0        152     22      0.9
    global cache cr request            84,801        575        113      1     10.5
    latch free                          8,096        736         65      8      1.0
    log file sync                       5,676         27         41      7      0.7
    wait for scn from all nodes        18,891         10         24      1      2.3
    CGS wait for IPC msg              394,678    392,142         21      0     49.0
    library cache pin                   1,339          0         17     13      0.2
    global cache null to x              2,145         48         16      8      0.3
    global cache s to x                 3,242         32         16      5      0.4
    buffer busy waits                     366         10         15     40      0.0
    ksxr poll remote instances         70,990     31,295         14      0      8.8
    db file parallel read                 359          0         11     31      0.0
    global cache open x                 2,708         55         10      4      0.3
    async disk IO                       3,474          0          8      2      0.4
    global cache open s                 3,470         10          6      2      0.4
    log file parallel write            13,076          0          5      0      1.6
    global cache busy                      58         40          5     90      0.0
    PL/SQL lock timer                       1          1          5   4877      0.0
    DFS lock handle                     3,362          0          5      1      0.4
    log file sequential read              412          0          4     10      0.1
    db file parallel write              2,774          0          3      1      0.3
    library cache load lock                59          0          3     58      0.0
    buffer busy global CR                 722          0          3      4      0.1
    control file sequential read        6,398          0          3      0      0.8
    SQL*Net break/reset to clien       16,078          0          2      0      2.0
    name-service call wait                 26          0          2     67      0.0
    control file parallel write         1,248          0          2      1      0.2
    process startup                        24          0          1     49      0.0
    KJC: Wait for msg sends to c        3,491          4          1      0      0.4
    SQL*Net more data to client        23,724          0          1      0      2.9
    buffer busy global cache               23          0          0     19      0.0
    global cache null to s                114          0          0      4      0.0
    PX Deq: reap credit                 5,646      5,509          0      0      0.7
    log file switch completion              4          0          0     58      0.0
    lock escalate retry                    54         54          0      1      0.0
    IPC send completion sync              119        118          0      0      0.0
    direct path read                    2,820          0          0      0      0.3
    direct path read (lob)              3,632          0          0      0      0.5
    PX Deq: Join ACK                       88         37          0      0      0.0
    direct path write                   2,470          0          0      0      0.3
    kksfbc child completion                 6          6          0      6      0.0
    buffer deadlock                         3          3          0     11      0.0
    global cache quiesce wait               4          4          0      8      0.0
    Library Cache Activity for DB: PROD  Instance: PROD2  Snaps: 149847 -149857
    ->"Pct Misses"  should be very low
                             Get  Pct        Pin        Pct               Invali-
    Namespace           Requests  Miss     Requests     Miss     Reloads  dations
    BODY                  27,353    0.5         28,091    6.5      1,643        0
    CLUSTER                  203    1.0            269    1.5          0        0
    INDEX                    526    9.9            271   19.9          0        0
    JAVA DATA                 18    0.0            120    6.7          4        0
    JAVA RESOURCE             20   45.0             56   26.8          3        0
    JAVA SOURCE                1  100.0              1  100.0          0        0
    PIPE                     999    0.4          1,043    0.4          0        0
    SQL AREA             131,793    7.6      3,406,577    0.4      7,012        0
    TABLE/PROCEDURE      926,987    0.2      1,907,993    1.0      8,845        0
    TRIGGER                1,519    0.1          1,532    4.9         69        0
                        GES Lock      GES Pin      GES Pin   GES Inval GES Invali-
    Namespace           Requests     Requests     Releases    Requests     dations
    BODY                       1          129          277         117           0
    CLUSTER                  168            2            2           2           0
    INDEX                    271           52           56          52           0
    JAVA DATA                  0            0            0           0           0
    JAVA RESOURCE              0            9            6           0           0
    JAVA SOURCE                0            1            1           1           0
    PIPE                       0            0            0           0           0
    SQL AREA                   0            0            0           0           0
    TABLE/PROCEDURE       89,523          764          868         460           0
    TRIGGER                    0            2           14           2           0
    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    DB Name         DB Id    Instance     Inst Num Release     Cluster Host
    PROD            21184234 PROD3               3 9.2.0.8.0   YES     npi-or-db-p-
                                                                       13.npi.corp
                  Snap Id     Snap Time      Sessions Curs/Sess Comment
    Begin Snap:    149808 30-Oct-09 14:00:00       31 #########
      End Snap:    149809 30-Oct-09 15:00:02       34  11,831.4
       Elapsed:               60.03 (mins)
    Cache Sizes (end)
    ~~~~~~~~~~~~~~~~~
                   Buffer Cache:     8,192M      Std Block Size:          8K
               Shared Pool Size:     1,024M          Log Buffer:     10,240K
    Load Profile
    ~~~~~~~~~~~~                            Per Second       Per Transaction
                      Redo size:              1,518.14             36,700.35
                  Logical reads:              1,333.43             32,235.02
                  Block changes:                  5.09                123.01
                 Physical reads:                 54.31              1,312.88
                Physical writes:                  3.91                 94.44
                     User calls:                  1.46                 35.40
                         Parses:                  2.24                 54.21
                    Hard parses:                  0.04                  0.93
                          Sorts:                  0.84                 20.28
                         Logons:                  0.06                  1.45
                       Executes:                  3.11                 75.23
                   Transactions:                  0.04
      % Blocks changed per Read:    0.38    Recursive Call %:     94.31
    Rollback per transaction %:   45.64       Rows per Sort:    215.97
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Buffer Nowait %:   99.99       Redo NoWait %:    100.00
                Buffer  Hit   %:   96.21    In-memory Sort %:    100.00
                Library Hit   %:   99.07        Soft Parse %:     98.29
             Execute to Parse %:   27.94         Latch Hit %:     99.98
    Parse CPU to Parse Elapsd %:   69.88     % Non-Parse CPU:     97.92
    Wait Events for DB: PROD  Instance: PROD3  Snaps: 149808 -149809
    -> 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
                                                         Total Wait   wait    Waits
    Event                               Waits   Timeouts   Time (s)   (ms)     /txn
    enqueue                            19,510      7,472     15,509    795    130.9
    PX Deq: Parse Reply                 1,152      1,071      2,577   2237      7.7
    row cache lock                      2,202        518      1,579    717     14.8
    db file scattered read             31,556          0        354     11    211.8
    db file sequential read            17,272          0         67      4    115.9
    db file parallel read               1,722          0         34     20     11.6
    global cache cr request            53,754         91         32      1    360.8
    wait for scn from all nodes         1,897         13         10      5     12.7
    CGS wait for IPC msg              403,358    401,478         10      0  2,707.1
    DFS lock handle                     4,753          0          8      2     31.9
    direct path read                    1,248          0          6      5      8.4
    PX Deq: Execute Reply                 110         38          6     51      0.7
    global cache open s                   160         10          5     31      1.1
    control file sequential read        6,442          0          3      0     43.2
    name-service call wait                 26          0          2     78      0.2
    latch free                            129        109          2     13      0.9
    KJC: Wait for msg sends to c          153         24          1      9      1.0
    control file parallel write         1,245          0          1      1      8.4
    buffer busy waits                     199          0          1      6      1.3
    process startup                        20          0          1     44      0.1
    global cache null to x                 74          2          1      9      0.5
    global cache null to s                 19          0          1     29      0.1
    global cache open x                   268          1          1      2      1.8
    library cache lock                  1,150          0          0      0      7.7
    PX Deq: Join ACK                      129         48          0      3      0.9
    log file parallel write             1,157          0          0      0      7.8
    async disk IO                         219          0          0      1      1.5
    direct path write                   1,024          0          0      0      6.9
    ksxr poll remote instances          6,740      4,595          0      0     45.2
    PX Deq: reap credit                 6,580      6,511          0      0     44.2
    buffer busy global CR                  73          0          0      2      0.5
    log file sequential read               11          0          0     10      0.1
    log file sync                         100          0          0      1      0.7
    global cache s to x                   282          2          0      0      1.9
    db file parallel write                 95          0          0      1      0.6
    library cache pin                     142          0          0      0      1.0
    SQL*Net break/reset to clien           28          0          0      1      0.2
    IPC send completion sync               81         81          0      0      0.5
    PX Deq: Signal ACK                     32         14          0      1      0.2
    PX Deq Credit: send blkd                3          1          0      7      0.0
    SQL*Net more data to client           841          0          0      0      5.6
    PX Deq: Msg Fragment                   37         17          0      0      0.2
    log file single write                   4          0          0      1      0.0
    db file single write                    1          0          0      1      0.0
    SQL*Net message from client         4,213          0     13,673   3246     28.3
    gcs remote message                214,784     75,745      7,016     33  1,441.5
    wakeup time manager                   233        233      6,812  29237      1.6
    PX Idle Wait                        2,338      2,294      5,686   2432     15.7
    PX Deq: Execution Msg               2,151      1,979      4,796   2229     14.4
    Library Cache Activity for DB: PROD  Instance: PROD3  Snaps: 149808 -149809
    ->"Pct Misses"  should be very low
                             Get  Pct        Pin        Pct               Invali-
    Namespace           Requests  Miss     Requests     Miss     Reloads  dations
    BODY                   1,290    0.0          1,290    0.0          0        0
    CLUSTER                   18    0.0              8    0.0          0        0
    SQL AREA               4,893    2.0         36,371    0.5          2        0
    TABLE/PROCEDURE        1,555    3.9          3,834    4.9         71        0
    TRIGGER                  286    0.0            286    0.0          0        0
                        GES Lock      GES Pin      GES Pin   GES Inval GES Invali-
    Namespace           Requests     Requests     Releases    Requests     dations
    BODY                       1            0            0           0           0
    CLUSTER                    4            0            0           0           0
    SQL AREA                   0            0            0           0           0
    TABLE/PROCEDURE          863          224           42          42           0
    TRIGGER                    0            0            0           0           0
              -------------------------------------------------------------

  • How can I automatically mount a sparsebundle image prior to TimeMachine backup?

    I've been searching for a couple of days now a way to have Time Machine backup to a drive attached via USB.  The drive is a Western Digital 1TB hard drive formatted as NTFS and I'm using Tuxera to read/write from it.  I created a 300GB sparsebundle image with 256bit encryption via Disk Utility and was successfully able to mount the image and perform an initial backup via Time Machine.  All was well until I got an error stating that the backup image couldn't be loaded due to Error -1.  My guess it's because the image is dismounting and when Time Machine states it's looking for the backup image, it's unable to mount it.  I've added my password to the KeyChain Access section but am forced to manually mount the image prior to backing up or the backup fails.
    Most of the articles I've read deal with network backups but I only have one MacBook Pro Retina Display (Mid-2012) running Mountain Lion 10.8.2 x64 and would like to keep my Windows backups separate.  I'm not using a NAS and my setup is a BlackX enclosure holding the 1TB hard drive.  Is there something I can do to have Time Machine automatically mount the image prior to backing up?
    I wrote a small AppleScript to automate the mounting but I want the whole process automated.  I read iCal can help me but apparently it'll pop-up a window that I don't have to want to deal with.
    Also, backing up about 36MB takes around five minutes so I'm not thrilled about the speeds.  Hopefully there's also a solution for it.  I also tried Carbon Copy Cloner and (forgot the name of the other utility) but reading through the features, I just want to keep it simple with Time Machine.  I'm mostly concerned about corruption and loss of my data though I'm not sure how much better Time Machine is but am receptive to any suggestions.
    Thank you for your help.

    drag the dmg to the dock, right click, and "open at login?", that should achieve what you want

  • Caching Query Image Stream

    Currently I am working on a CMS of sorts and the higher-ups
    wanted to have some digital asset management capibilities. All
    images are now being stored in SQL2k5 in binary form. On a page
    that contains the image, I have a the image
    src="myImageLoader.cfm?imageId=x" where x is the id of the image to
    load.
    This all works fine, however if the user returns to a page
    that they have previously visited, the image is not cached and must
    restream out. Any ideas on how to cache the image after it has been
    streamed?

    The only smart way to do this is to write the image out as a
    regular file and link to that.
    Caching, handshaking, and compression are then handled
    beautifully by the web server and client browser.
    The only thing you would (possibly) need to do is to run a
    job every few days to clean out stale (or access limited) files.
    Otherwise, you will need to set the "last modified" and
    "expires" headers and to monitor for and process the
    "If-Modified-Since" header.

  • Sharing/Caching (Dynamic) Images

    I find that the Flash Player does not cache dynamic images
    (even in the same session), so my question is, how would I share
    images across multiple image components such that I can build an
    asset provider of sorts to assit with caching images and other
    assets?
    I've tried a simplistic approach where in I assign the source
    of one image component to another but then the first image
    component goes blank and the image "transfers" to the second.
    Not sure if BitmapData will help with this either.
    Any help/direction is much appreciated.
    Thanks.
    Shiv.

    URL? Code?
    Nancy Gill
    Adobe Community Expert
    Author: Dreamweaver 8 e-book for the DMX Zone
    Co-Author: Dreamweaver MX: Instant Troubleshooter (August,
    2003)
    Technical Editor: Dreamweaver CS3: The Missing Manual,
    DMX 2004: The Complete Reference, DMX 2004: A Beginner's
    Guide
    Mastering Macromedia Contribute
    Technical Reviewer: Dynamic Dreamweaver MX/DMX: Advanced PHP
    Web Development
    "kidcobra" <[email protected]> wrote in
    message
    news:g2oqb0$bgq$[email protected]..
    > PHP, dynamic images from mysql dbase....diplay on local
    server, but will
    > only
    > display on web server if in the same level or folder as
    the php page.
    > Locally,
    > I have put the path to the images in the dbase in front
    of the URL of the
    > image, and all works fine.... but with that path in
    there and images not
    > in
    > same folder as page, no web server display. I know I'm
    missing the
    > obvious, but
    > need help if anyone has the simple answer . Thanks
    >

  • Mail Not Caching Loaded Images

    Running Leopard and Mail 3.1 with multiple IMAP accounts:
    So I like Mail's ability to NOT load images when I first view an email... it's a great way to avoid massive amounts of junk mail. My problem exists when I've told Mail that I DO want to load the images... they aren't being cached. So if I quickly view an email... load the images... jump to another email... then try to come back to the first one... none of the images are still there. Requiring me to reload them.
    Is anyone else experiencing this? Am I missing a setting somewhere? It seems to me that these images should be cached by Mail somewhere on my machine so that I don't have to load them every time I view an email.

    Bump again. I can't seem to get Mail to load inline images no matter what I do. Mayday.
    -K

  • Where does Air cache loaded images?

    MSIE caches all loaded files in Temporary Internet Files
    folder.
    Firefox - in something like C:\Documents and
    Settings\user\Local Settings\Application
    Data\Mozilla\Firefox\Profiles\blablabla.default\Cache
    But where is the Air cache location?

    These things are using the browser's cache. If you were using RSL's that would be going to a location managed by Flash.

  • How to check if table or index bound to data cache loaded in memory?

    In my system, thare are many named data caches created and certain objects bind to those data cache.
    For example, I have a large table mytab which is bound to data cache mycache.
    When I issue a sql like select * from mytab where x=y, run it at first time is is very slow.  run it again and again. then it very fast. it means data loaded in cahce and ready for same query.
    Question:
    1. How can I know if the table mytab has been loaded in data cache mycache?
    2. How to load mytab into data cahce mycache one time for all query in the feature?

    one way to monitor is:
    select CacheName,DBName,OwnerName,ObjectName,IndexID,sum(CachedKB) as "CachedKb"
    from master..monCachedObject
    group by CacheName,DBName,OwnerName,ObjectName,IndexID
    order by CacheName,DBName,OwnerName,ObjectName,IndexID
    But, you should understand that caches have a finite size, and caches contain "pages" of objects including data pages, index pages, and LOB pages.  Also, caches may have different pool sizes, so a page can be in only one cache pool.  So, if you want  a table and all of it's indexes, text/image pages  to be loaded into a dedicated cache, you need a large enough cache to fit all of those pages, and decide which buffer pool you want them in (typically either the 1 page pool, or the 8 page pool).
    Then, simply execute SQL (or dbcc) commands that access all of those pages in the manner you wish to find them in the cache.  For example, two statements, one that scans the table using 2k reads, and another that scans the index (mytab_ind1) using 2k reads.
    select count(*) from mytab plan '( i_scan mytab_cl mytab) ( prop mytab ( prefetch 2 ) ( lru ) )'
    select count(*) from mytab plan '( i_scan mytab_ind1 mytab) ( prop mytab ( prefetch 2 ) ( lru ) )'
    etc etc.
    used count(*) to limit result sets of examples

  • Oracle Web Cache - Load Balancer Mode

    Hello,
    I am facing a problem related to fault tolerance in Oracle Web Cache
    My environment:
    2 Nodes of Oracle Application Server 10.1.3 configured in cluster.
    have configured Oracle Web Cache (in LoadBalancer mode only) to simulate a BigIP load balancing above these two oc4j node. This to be used as fault tolerance so if one http request will fail the LoadBalancer will direct it to the second oc4j (its http server).
    I have used the defaults recommended by Oracle documentation for configuration clustering load balancer using Oracle Web Cache and using JSESSIONID for Session binding with oc4j-type. I left all other cluster/server setting to default
    Problem:
    The problem is when I am shutting down one oc4j instance the Oracle Web Cache tries to keep the session with the un-available oc4j node and not direct the session to the other oc4j node.
    If I choose to start a new session (loose current work) than it does work with the second (alive) oc4j node, but than where is its fault tolerance??
    What do i need to do to keep working with the same session over the second oc4j node. My deployed Web App is enabled to work in cluster, using Oracle Application Server console. Here is its orion-application.xml
    +<?xml version="1.0"?>+
    +<orion-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/orion-application-10_0.xsd" deployment-version="10.1.3.1.0" default-data-source="jdbc/OracleDS" component-classification="external"+
    schema-major-version="10" schema-minor-version="0" >
    +     <web-module id="session_rep" path="session_rep.war" />+
    +     <persistence path="persistence" />+
    +     <principals path="principals.xml" />+
    +     <jazn provider="XML" />+
    +     <log>+
    +          <file path="application.log" />+
    +     </log>+
    +     <cluster allow-colocation="false">+
    +     <replication-policy trigger="onRequestEnd" scope="modifiedAttributes"/>+
    +     <flow-control-policy enabled="false" />+
    +          <protocol>+
    +               <peer>+
    +                              <opmn-discovery/>+
    +               </peer>+
    +          </protocol>+
    +     </cluster>+
    +</orion-application>+
    Will appreciate any help !

    is OHS/apache deployed between web cache and your OC4J? if so, i think since OHS/apache is alive to web cache, web cache keeps routing to it.
    maybe in your script, you can shutdown both OHS/apache and OC4J totgether so web cache can correctly route.

  • Web cache load balancing web forms - Urgent

    Hi,
    I have two servers(server 1 and server 2) with BI(forms and reports) installation. Infrastructure is running on another unix server( server 3).
    I can access forms application on server A and server B using URL :
    http://server1.gnb.ca:7778/forms90/f90servlet?config=test
    http://server2.gnb.ca:7778/forms90/f90servlet?config=test
    Web cache is installed on both server 1 and server 2.
    I want to load balance forms applications using web cache.I looked in metalink and i din't find a detailed document to do this.
    specially i am not clear on What parameters / how to setup
    1) site information for application
    2) origin server
    3) site to server mapping
    I am following doc # 229900.1 from metalink. If someone can give steps to do this is appreciated.
    Thanks

    Hi, I can't exactly answer this as am not aware of Forms. But, as such, Web Cache does a good load balancing work provided you configure it well. Probably, you should try posting this in Forms forum too.
    Regards,
    Priyanka GES

  • Navigation Cache - Loading Web Dynpro iview

    Hello Experts,
    I developed a simple WebDynpro that count the access number to a single portal page.
    And I put it in a Role.
    In a cluster environment I had different results depending on the cluster instance I use.
    If I do a Logon in the central instance and navigate the role I get a value of access number.
    If I do a Logon in the dialog instance and navigate the role I get a different value of access number.
    The value in the database is always the same..
    Could it be a cache problem??
    What can I do??
    Best Regards

    Hi,
    Did you try clearing the navigational cache on dialog server and also in Central Instance?
    In Portal Navigate to System Administration - Navigation - Clear Navigation Cache.
    And test the application again and see if it got resolved...
    Or
    Go to Index.html side and go to Web Dynpro Tools, and go to Invalidation of ARFC Metadata Cache - In section Dictionaries Cache Invalidation - click on the button to get teh application using the JCO connection and invalidate the cache...
    Hope this helps.
    Cheers-
    Pramod

  • Cache browser images

    Hello.
    The problem is wit with images (OAImageBean), I have a page where the user can assign an image to an articule, or changing the image if the articule already have an image, In both cases the name of the image wil be saved as the name of the articule (example, A001 with extension .jpg)
    the problem comes when the articule already have an image, bacause the browser saves in cache the first image that the articule already have, and when the user change the image and refresh the page (submitButon form, refresh,etc..) the same first image is till appearing,
    I have to go to internet options and clear de chache so the image can be loaded again, and the new image appear on the articule
    So I wanna know how I can load the new image each time the user change it?
    is there a method for OAImageBean that can do that, or how this can be done?
    regards

    Hi.
    well Im not saving photos in database, im saving them on inside directories like OA_MEDIA, and using the components of OAImageBean to get that image, like
    OAImageBean image = (OAImageBean)webBean.findchildrecursive(<id of region imgae>);
    image.setSource(<the directory were i stored the image>);
    everything works fine, its just that the image showing its the one that it's save in the cache of the browser
    Example
    Articule A001 have an image called A001.jpg (a pen)
    --the browser show the pen
    then the user change the image for a pencil
    Articule A001 now have the image called A001.jpg (a pencil) (I overwrite the file so the new file is the pencil with the same name)
    --but the browser still shows the pen because the browser save it on the cache
    I have to go to internet options -> view file -> and then delete the file with the name A001.jpg
    I refresh the page and now the browser shows the pencil (indicating that my code avobe its running correctly)
    so I wanna know how I can get the image always directly from the server where the image is and not from the cache of the browser
    or
    another way to acomplish the correct visualization of the new image (not usign database, becuase thats not our requirement)
    regards

  • Reducing size of .pdf image prior to displaying by Acrobat Reader

    I scanned a newspaper article to a .pdf file and when Iit was displayed by Acrobat Reader the image was at 290%.  I would prefer a 100% readable image.  Is there an option to reduce the image size to say 100 or 75% prior to displaying it in Acrobat?  Could this be a function best achieved during the scanning process?  If so, how?   I am new at this and would appreciate any advise available.
    bnlkasper

    Try playing with the default layout and zoom settings.
    Edit > Preferences > select the category Page Display
    In the Default Layout and Zoom pane, you can use the drop-down menus for
    Page Layout and Zoom to make selections.
    Be well...

  • 2 HD laptop setup - Best place to put Catalog, Cache, and Images??

    If I have two 500GB 7200rpm hard drives in my MBP, what is the best place for LR3, the catalog/previews, ACRcache, and the image files themselves?
    SATA3 connection for both HDs
    Should the boot drive hold the app and cache, while the second drive hold the files and catalog?
    Should the catalog and cache always stay on the same drive?
    Does it matter at all where the image (raw) files sit?
    Thanks!!

    I'd just keep the images on a different drive with a 2 internal drive setup.

Maybe you are looking for