From: Severin on
Hi,

Context: OS Windows 2003, 8GB RAM, 4CPU
Ref: Metalink note 225349.1

I'm trying to adjust the AWE_WINDOW_MEMORY value (set as key into the
registry).
I have set the AWE_WINDOW_MEMORY to 1GB (=1,048,576 Bytes)
As describ into the Metalink note 225349.1:
"If the # of Map misses is relatively high, or particularly of the # of
map misses increases consistently over time, this may be an indication
that the value for AWE_WINDOW_MEMORY is set too low."

I would ask you what it means "relatively high" and "increase
consistently". My number of map misses was 1200 after one day, is it high?

Is it possible to ive a value for AWE as great as that value is staing on
0?

Thanks for your answers and tips!
Best Regards!

--
Severin
From: Sybrand Bakker on
On Fri, 28 Oct 2005 16:35:29 +0200, Severin
<left-side(a)right-side.fr.invalid> wrote:

>Hi,
>
>Context: OS Windows 2003, 8GB RAM, 4CPU
>Ref: Metalink note 225349.1
>
>I'm trying to adjust the AWE_WINDOW_MEMORY value (set as key into the
>registry).
>I have set the AWE_WINDOW_MEMORY to 1GB (=1,048,576 Bytes)
>As describ into the Metalink note 225349.1:
> "If the # of Map misses is relatively high, or particularly of the # of
>map misses increases consistently over time, this may be an indication
>that the value for AWE_WINDOW_MEMORY is set too low."
>
>I would ask you what it means "relatively high" and "increase
>consistently". My number of map misses was 1200 after one day, is it high?
>
>Is it possible to ive a value for AWE as great as that value is staing on
>0?
>
>Thanks for your answers and tips!
>Best Regards!

increase consistently: does not stays the same, but keeps increasing.
Expressions like this are best looked up in a dictionary.
It seems you are adhering the 'More is better' approach: you tune the
O/S by throwing resources at the problem.
I can guarantee you it is not going to work, EVER.

--
Sybrand Bakker, Senior Oracle DBA
From: Severin on
On Fri, 28 Oct 2005, Sybrand Bakker wrote:

> increase consistently: does not stays the same, but keeps increasing.
> Expressions like this are best looked up in a dictionary.

Yes of course... but there is perhaps a gap between the dictionary and the
reality in computer science!

> It seems you are adhering the 'More is better' approach: you tune the
> O/S by throwing resources at the problem.
> I can guarantee you it is not going to work, EVER.

My job is very simple:
1. someone did buy any computer with 8GB, did choose
windows 2003 and Oracle to runnig SAP R/3.
2. I must do the best to use correctly those gigabytes of RAM. Then I
will see if this 'More GB RAM' is better for Oracle and SAP R/3.

I don't understand the decision of 1. because so much RAM could not be
correctly managed with any 32-bytes hardware.

What do you mean about that?
Anyone have some experience about that?

Thanks for your response!
Best Regards.

--
Severin
From: mccmx on
> My job is very simple:
> 1. someone did buy any computer with 8GB, did choose
> windows 2003 and Oracle to runnig SAP R/3.
> 2. I must do the best to use correctly those gigabytes of RAM. Then I
> will see if this 'More GB RAM' is better for Oracle and SAP R/3.
>

Just because you have 8Gb of RAM in the server, it doesn't mean you
need to use it all....

Bear in mind that the memory above 4Gb can only be used for the Buffer
Cache.

Having an SGA which is too big can actually hurt performance.

Access to memory above the 4Gb mark will effectively be accessed via a
'soft' page fault. While this is quicker than disk I/O it is still an
overhead (cpu etc).

I would seriously investigate whether you need such a huge SGA...

Matt

From: DA Morgan on
Severin wrote:

> My job is very simple:
> 1. someone did buy any computer with 8GB, did choose windows 2003 and
> Oracle to runnig SAP R/3.

You have my sympathy but it is what it is.

> 2. I must do the best to use correctly those gigabytes of RAM. Then I
> will see if this 'More GB RAM' is better for Oracle and SAP R/3.

Why does having 8GB of RAM require that you use it? You might be far
better off using less of it.

> I don't understand the decision of 1. because so much RAM could not be
> correctly managed with any 32-bytes hardware.

Your inability to understand someone else's decision making process, if
there was one, should not affect what you do with it now.

> What do you mean about that?
> Anyone have some experience about that?
>
> Thanks for your response!
> Best Regards.

What you should be doing is using Oracle's internal instrumentation
to identify the best settings ... not as Sybrand suggests ... throwing
resources at a problem that so far you have not indicated even exists.

So lets go back to basics: What is the business problem you are
addressing with this exercise? What specific issue is causing end-user
problems? And how was it measured?
--
Daniel A. Morgan
http://www.psoug.org
damorgan(a)x.washington.edu
(replace x with u to respond)