Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Capacity Planner from OEM VS Statspack

Re: Capacity Planner from OEM VS Statspack

From: Mladen Gogala <mladen_at_wangtrading.com>
Date: Fri, 6 Feb 2004 15:12:20 -0500
Message-ID: <20040206201220.GA5779@mladen.wangtrading.com>


On 02/06/2004 01:28:08 PM, babette.turnerunderwood_at_hrdc-drhc.gc.ca wrote:

> I think the real issue is some form of swapping / paging going on.
> However, because of the way the mainframe handles the swapping /
> paging,
> It reports that it is not happening.=20
>
> I believe we have 2GB of REAL memory in this machine. We also have 10
> =
> instances with 300-600M of irtual memory each. Each Oracle process,
> =20
> runs in an Oracle service that can use up to 2GB of virtual memory=20
> for everything (eg SGA, PGA, sort..). The number is supposed to be
> 2GB,=20
> but in reality it is more like 1.8GB.
>
> This is TOTALLY different than UNIX. In UNIX the SGA sits in memory.
> In mainframe, only the active pages reside in memory. There is a=20
> "working set" that must be able to be loaded into real, expanded or =
> "disk swap area". The O/S decides which pages are active and they are
> in =
> memory.
> So when I startup an instance with 300M SGA, it might only load 80K
> of

Actually, it is not so different. I don't know whether you've ever worked on a VAX/VMS, but everything below so called "virtual=real memory line" on IBM mainframe is equivalent to the VAX/VMS "non-paged pool". You don't want to load many things there because this area is usually reserved for CICS control blocks DB/2 stuff and alike. So called "virtual memory" is the normal, paged RAM with page tables, TLB, L1,L2 and L3 caches. Then there is something called "channel memory", which is, essentially, attached to disk controllers and is analogous to the cache you can find on Symmetrix arrays. You see, the difference between a mainframe and a minicomputer is architectural. Minicomputer is interrupt-driven, which means that periferals communicate with CPU(s) using interrupts. Mainframe has "channels", which means that disks are atteched to the memory and do not have direct communication with the CPU. When you want to perform I/O on a maninframe, you fill in the form (called IORB) and put it to certain memory location. So called "channel processor" monitors that location, takes the "form" , performs the request and puts the result in memory. When that is done, a single interrupt, possibly piggybacking several I/O requests is sent to the CPU. When a minicomputer wants to perform I/O, it generates a slew of interrupts: CPU-> Controller: "are you ready?"

               Controller->CPU   "ready".
               CPU-> Controller   "setup DMA channel to buffer".
               Controller->CPU    "Set".
               CPU->Controller    "Read sector # into buffer".
               Controller->CPU    "Done."

Instead of all these messages, mainframe CPU gets only a single interrupt for I/O done. That saves time and context switching. Architecture like that is being explored on the minicomputers and it's called "I2O". Advatnages of the channel architecture are numerous, but the most obvious is much better CPU utilization. The obvious thing to do is not to perform many task switches as with time sharing option (TSO) but to have a single program run all the time and perform transactions on behalf of the users. Such programs are called "TP monitors" and on IBM, it's CICS. Here I will conclude the computer architecture lesson for today.



Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Fri Feb 06 2004 - 14:12:20 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US