Hi Wim,

my SGA_TARGET is 256MB.

show sga:

Total System Global Area 268435456 bytes
Fixed Size            1260320 bytes
Variable Size         109053152 bytes
Database Buffers       155189248 bytes
Redo Buffers           2932736 bytes

my ASM-Instance:

Total System Global Area 104857600 bytes
Fixed Size            1259384 bytes
Variable Size         78432392 bytes
ASM Cache            25165824 bytes


% ipcs -a

------ Shared Memory Segments --------
key     shmid    owner    perms    bytes    nattch   status
0x00000000 589824   oracle   600     262144   1       dest
0x15e0e074 655361   oracle   640     109051904 16
0xfa6720a8 688130   oracle   660     272629760 34

------ Semaphore Arrays --------
key     semid    owner    perms    nsems
0xe6f34240 98304    oracle   640     44
0x53a09d3c 229377   oracle   660     154

------ Message Queues --------
key     msqid    owner    perms    used-bytes  messages


% free
        total     used     free   shared   buffers   cached
Mem:     1035672   1013844    21828       0   120448   459636
-/+ buffers/cache:   433760   601912
Swap:    1052216    24540   1027676


Ciao

Clemens

--- Originalnachricht ---
> how big is the SGA in oracle (well more specifically the
> buffercache ) ?
>
> when you start up oracle, the pages are not all touched. so
> if you start
> do a scan then all those pages are touched in the SGA (shmem
> segment)
> and will show up as memory in use. otherwise they wouldnt. yet
> if not
> used. that could explain why. so cached in that case is shmem
> - not os
> disk or filesystem buffers
>
>
> CLEMENS.BLEILE@(protected):
> > Hi Mihail,
> >
> > asking this question an ASMLIB-developer I got this reply:
> >
> > "ASMLib uses the block devices directly, and does no caching.
> > It's direct I/O only. There can be many other things caching, of
> > course."
> >
> > I actually made a quick test:
> >
> > 1. created a table with 350MB size.
> > 2. My machine has 1GB RAM
> > 3. After the first full table scan my cache went up to 540MB
> > 4. alter system flush buffer_cache;
> > 5. Repeating the full table scan showed that the same amount of physical IO happened (iostat -x) as the first time
> > 6. I verified this on the storage (I have an iSCSI-target on Linux), because I see IO there as well.
> >
> > I.e. subsequent full-table-scans do not take data out of the cache, i.e. direct IO happens. The mysterious thing is: What's in the cache?
> >
> > Ciao
> >
> > Clemens
> >
> > --- Originalnachricht ---
> >  
> >> Hi all,
> >> I observed a strange (to my eyes) behaviour in my SLES9 + ASM
> >> + ASMLib +
> >> Oracle10.2 RAC setup.
> >> After upgrading my 2 nodes to 7GB RAM each I started the RAC
> >> instances
> >> and used top to observer the memory and CPU usage.
> >>
> >> Then I launched a SELECT statement which accesses lots of data
> >> and
> >> performs group by and order by operations. What seems strange
> >> to me is
> >> that
> >> 'cached' grew from 2GB to about 5GB while the statements
> >> finishes.
> >>
> >> So the question is does Oracle ASM use my devices as block
> >> devices and
> >> does it hold the blocks in some cache?
> >>
> >> I am using partitions from shared scsi disk array which are
> >> marked as
> >> ASMLib DISKS. The OS is 32bit SLES9 SP3 + updates (kernel
> >> bigsmp-276).
> >>
> >> Here is the output of cat /proc/meminfo :
> >> MemTotal:    7267640 kB
> >> MemFree:     250172 kB
> >> Buffers:     117076 kB
> >> Cached:     5180112 kB
> >> SwapCached:    28880 kB
> >> Active:     6236304 kB
> >> Inactive:     375548 kB
> >> HighTotal:   6422320 kB
> >> HighFree:      2108 kB
> >> LowTotal:     845320 kB
> >> LowFree:     248064 kB
> >> SwapTotal:   8401976 kB
> >> SwapFree:    8292396 kB
> >> Dirty:        1616 kB
> >> Writeback:       0 kB
> >> Mapped:     4014284 kB
> >> Slab:       133152 kB
> >> Committed_AS: 6998544 kB
> >> PageTables:   240464 kB
> >> VmallocTotal:  112632 kB
> >> VmallocUsed:   12060 kB
> >> VmallocChunk:  100284 kB
> >> HugePages_Total:   0
> >> HugePages_Free:    0
> >> Hugepagesize:   2048 kB
> >>
> >> 10x in advance,
> >>
> >> Mihail Daskalov,
> >> Oracle DBA    
> >> www.technologica.com
> >>
> >>
> >>
> >> --
> >> To unsubscribe, email: suse-oracle-unsubscribe@(protected)
> >> For additional commands, email: suse-oracle-help@(protected)
> >> Please see http://www.suse.com/oracle/ before posting
> >>
> >>  
> >
> >
> >  
>


--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting