code 39 barcode font for crystal reports download MEMORY STRUCTURES in Objective-C

Create Data Matrix ECC200 in Objective-C MEMORY STRUCTURES

1031 0 0 4078637 53154 4796 1 0 71917

consistent gets physical reads redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

ops$tkyte%ORA11GR2> set autotrace off As you can see, the sort was done entirely in memory, and in fact if we peek at our session's PGA/UGA usage, we can see how much we used: ops$tkyte%ORA11GR2> select a.name, to_char(b.value, '999,999,999') bytes, 2 to_char(round(b.value/1024/1024,1), '99,999.9' ) mbytes 3 from v$statname a, v$mystat b 4 where a.statistic# = b.statistic# 5 and a.name like '%ga memory%'; NAME BYTES MBYTES ------------------------------ ------------ --------session uga memory 1,367,116 1.3 session uga memory max 9,674,632 9.2 session pga memory 1,802,856 1.7 session pga memory max 10,257,000 9.8 We see the same 9-10MB of RAM we observed earlier in the prior test for sorting. Now we ll fill up that CHAR array we have in the package (a CHAR datatype is blank-padded so each of these array elements is exactly 2,000 characters in length): ops$tkyte%ORA11GR2> begin 2 for i in 1 .. 200000 3 loop 4 demo_pkg.g_data(i) := 'x'; 5 end loop; 6 end; 7 / PL/SQL procedure successfully completed. If we then measure our session's current PGA utilization, we find something similar to the following: ops$tkyte%ORA11GR2> select a.name, to_char(b.value, '999,999,999') bytes, 2 to_char(round(b.value/1024/1024,1), '99,999.9' ) mbytes 3 from v$statname a, v$mystat b 4 where a.statistic# = b.statistic# 5 and a.name like '%ga memory%'; NAME BYTES MBYTES ------------------------------ ------------ --------session uga memory 469,319,332 447.6

469,319,332 470,188,648 470,188,648

447.6 448.4 448.4

Now, that is memory allocated in the PGA that the database itself can t control. We already exceeded the PGA_AGGREGATE_TARGET set for the entire system in this single session and there is quite simply nothing the database can do about it. It would have to fail our request if it did anything, and it will do that only when the OS reports back that there is no more memory to give. If we wanted, we could allocate more space in that array and place more data in it, and the database would just have to do it for us. However, the database is aware of what we have done. It does not ignore the memory it can t control; it simply recognizes that the memory is being used and backs off the size of memory allocated for work areas accordingly. So if we rerun the same sort query, we see that this time we sorted to disk the database did not give us the 9MB or so of RAM needed to do this in memory since we had already exceeded the PGA_AGGREGATE_TARGET: ops$tkyte%ORA11GR2> set autotrace traceonly statistics; ops$tkyte%ORA11GR2> select * from t order by 1,2,3,4; 71917 rows selected. Statistics ---------------------------------------------------------9 recursive calls 7 db block gets 1031 consistent gets 1055 physical reads 0 redo size 4078637 bytes sent via SQL*Net to client 53154 bytes received via SQL*Net from client 4796 SQL*Net roundtrips to/from client 0 sorts (memory) 1 sorts (disk) 71917 rows processed ops$tkyte%ORA11GR2> set autotrace off So, because some PGA memory is outside of Oracle's control, it is easy to exceed the PGA_AGGREGATE_TARGET simply by allocating lots of really large data structures in our PL/SQL code. I am not recommending you do this by any means. I'm just pointing out that the PGA_AGGREGATE_TARGET is more of a request than a hard limit.

So, which method should you use, manual or automatic My preference is to use the automatic PGA memory management by default.

Caution I'll repeat this from time to time in this book: please do not make any changes to a production

system a live system without first testing for any side effects. For example, please do not read this chapter, check your system and find you are using manual memory management and then just turn on automatic memory management. Query plans may change, and performance may be impacted. One of three things could happen: Things run exactly the same. Things run better than they did before. Things run much worse than they did before.