James Morle is blogging! His stuff is definitely (very much) worth reading, in fact I have learnt a lot from his book Scaling Oracle 8i, which I still recommend as first reading for people who want to understand Oracle, OS and hardware touchpoint. And his book is freely downloadable from his website too :)
Check out his blog: http://jamesmorle.wordpress.com/
Download his book: http://www.scaleabilities.co.uk/
Enjoy! :)
Note: I accidentially published this note while I was writing it, so you may have seen a partial version of it. It’s complete now.
If you have queried v$sgastat on recent Oracle versions (by which I mean 9i and above) you probably have seen allocations for some sort of simulators in Oracle instance. Here’s an example:
SQL> select * from v$sgastat where lower(name) like '%sim%' order by name; POOL NAME BYTES ------------ -------------------------- ---------- shared pool kglsim alloc latch area 1700 shared pool kglsim alloc latches 68 shared pool kglsim count of pinned he 9248 shared pool kglsim free heap list 204 shared pool kglsim free obj list 204 shared pool kglsim hash table 4104 shared pool kglsim hash table bkts 2097152 shared pool kglsim heap 635536 shared pool kglsim latch area 1700 shared pool kglsim latches 68 shared pool kglsim main lru count 87040 shared pool kglsim main lru size 174080 shared pool kglsim object batch 909440 shared pool kglsim pin list arr 816 shared pool kglsim recovery area 2112 shared pool kglsim sga 22092 shared pool kglsim size of pinned mem 18496 shared pool ksim client list 84 shared pool log_simultaneous_copies 480 shared pool sim cache nbufs 640 shared pool sim cache sizes 640 shared pool sim kghx free lists 4 shared pool sim lru segments 640 shared pool sim segment hits 1280 shared pool sim segment num bufs 640 shared pool sim state object 48 shared pool sim trace buf 5140 shared pool sim trace buf context 120 shared pool sim_knlasg 1200 shared pool simulator hash buckets 16512 shared pool simulator latch/bucket st 4608 31 rows selected.
See, a bunch of “kgl sim” and then just “sim” allocations.
… or sometimes you can see latch contention on following latches:
SQL> select name from v$latch where name like '%sim%'; NAME ------------------------------------------------------- ksim membership request latch simulator lru latch simulator hash latch sim partition latch shared pool simulator shared pool sim alloc 6 rows selected.
Again, there seems to be some “simulation” work going on in Oracle instance.
So what are these simulators about?
Since Oracle 10.2 it’s valid to say that buffer cache can be stored inside shared pool.
Now you may think I’m crazy, but read until the end of the post – no matter how crazy I may sound – I have proof!
Here it is:
Few years ago I started noticing a strange memory allocation in shared pool (in V$SGASTAT), called KGH: NO ACCESS.
SQL> select * from v$sgastat where name = 'KGH: NO ACCESS';
POOL NAME BYTES ------------ -------------------------- ---------- shared pool KGH: NO ACCESS 10513696 SQL>
You see, some 10 MB of memory in shared pool has been allocated for something called KGH: NO ACCESS.
Ok, lets see where this memory resides inside shared pool. We can use x$ksmsp view for that, this view has a line in it for each chunk of memory allocated from it (and also the free chunks), along the reasons (or comments) for what reason these chunks were allocated.
You may already have noticed that Oracle 11gR2 for Linux is available for download on Oracle.com website, with documentation.
And this document ends speculation about whether Oracle 11.2 will support column-oriented storage – yes it will:
However, this is apparently available on Exadata storage only as a new error message below indicates:
ORA-64307: hybrid columnar compression is only supported in tablespaces residing on Exadata storage
Cause: An attempt was made to use hybrid columnar compression on unsupported storage.
Action: Create this table in a tablespace residing on Exadata storage or use a different compression type.
Update: Kevin Closson mentioned that 11gR2 doesn’t really have column oriented storage as some other products like Vertica’s and Sybase IQ use, but its rather just column oriented compression option where storage is still organized by row but individual fields in these rows use compression dictionaries whichcan span multiple block boundaries (we’ll thats my interpretation at least).
The 11gR2 release overview doc seems to be wrong in this case, as it says:
Hybrid columnar compression is a new method for organizing how data is stored. Instead of
storing the data in traditional rows, the data is grouped, ordered and stored one column at a time.
Read Kevin’s note here:
Tweets
|
|
|
|
User Comments
User Comments