Oracle FAQ Your Portal to the Oracle Knowledge Grid

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

RE: Capacity Planner from OEM VS Statspack

From: <>
Date: Mon, 9 Feb 2004 09:48:43 -0800
Message-ID: <>

Consider writing an update that assures that their cache gets saturated, then ask them why it is so slow. ;)

In development of course.


<> Sent by:
 02/09/2004 08:14 AM
 Please respond to oracle-l  

        To:     <>
        Subject:        RE: Capacity Planner from OEM VS Statspack

Thanks Mladen,

This mainframe world is a very strange world to me. Any and all explanations are very helpful. I have been=20 using Oracle on the mainframe for over a year now and=20 I still confused about the architecture.

It doesn't help having the SysAdmin guys telling me=20 white lies.=20

ME: How are the datafiles arranged on disks? How are they mapped to real = disks.
SYSADMIN: It doesn't matter, it is all RAM access. There are no disks = involved
(then later we get a presentation on the DASD system and they explain = the number of physical disks and logical volumes and the difference = between FiCon and FibreChannel)
ME: So we have real disks under it all
SYSADMIN: Well not really. Everything is so fast and in cache, you can = consider it all in RAM
ME: (screaming in my head) AAAAaaaaarrgggh!

Babette Turner-Underwood

-----Original Message-----
From: =
[] On Behalf Of Mladen Gogala Sent: 2004-02-06 3:12 PM
Subject: Re: Capacity Planner from OEM VS Statspack

On 02/06/2004 01:28:08 PM, =20 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.=3D20


> I believe we have 2GB of REAL memory in this machine. We also have 10
> =3D
> instances with 300-600M of irtual memory each. Each Oracle process,=20
> =3D20
> runs in an Oracle service that can use up to 2GB of virtual =
> for everything (eg SGA, PGA, sort..). The number is supposed to be
> 2GB,=3D20
> 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=3D20
> "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 =3D
> memory.
> So when I startup an instance with 300M SGA, it might only load 80K =20
> of

Actually, it is not so different. I don't know whether you've ever =20 worked on a VAX/VMS, but everything below so called "virtual=3Dreal =20 memory line" on IBM mainframe is equivalent to the VAX/VMS "non-paged =20 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 =20 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, =20 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 =20 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:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Please see the official ORACLE-L FAQ:
To unsubscribe send email to:
put 'unsubscribe' in the subject line.
Archives are at
FAQ is at

Please see the official ORACLE-L FAQ:
To unsubscribe send email to:
put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Mon Feb 09 2004 - 11:48:43 CST

Original text of this message