2GB limit of memory for Oracle on WIndows 32 bit
zigz...@yahoo.com
Oracle has limit of 2GB memory. I have 5 Oracle database instances, so
I see 5 oracle.exe in task manager. I am assuming each oracle.exe can
access up to 2GB memory, so up to 10GB memory can be used by Oracle on
the server.
Thanks a lot.
BD
No, not exactly. You have 2GB of memory for *all* of the Oracle
requirements. It's gross.
3 ways of dealing with that limitation:
1: the /3GB switch in boot.ini: allows for 3GB to be made available to
programs, with the kernel taking 1GB (could be repercussions there
too)
2: the /PAE switch in boot.ini: allows for use of upper memory
(anything above 4GB). Oracle needs to be configured to use this
memory, and this memory can only be used for the buffer cache. Shared
Pool, PGA, all the rest needs to sit in 'base' memory no matter what.
The /3GB and /PAE switches can be used together, but if they are, you
will never see more than 16GB on the box, even if there's 64GB of
physical memory installed. Just the way it works.
3: Use 64-Bit windows.
BD
fitzj...@cox.net
Is this a question?
Have you considered the memory limitations imposed by Windows 2000?
Yes, you can use the /PAE switch to enable a virtual 64-bit addressing
scheme but you are still left with a 2 GB limit for the kernel; adding
more page tables to 'trick' the application into thinking there is
more memory causes you to consume more of the limited 2 GB of memory
the kernel processes are using. This may not be the wisest of ideas.
I would research this further before you decide on an implementation
date; you could be setting yourself up for failure in a grand way with
this scheme.
David Fitzjarrell
zigz...@yahoo.com
When /3GB switch is turned on, will all oracle instances (5 in my
example) still have access only to 3GB memory combined or each
instance will have limit of 3GB memory. Various metalink articels say
this limit to be per instance so I am confused.
EdStevens
It's a hard OS limit. It is easily reached with one oversize SGA and
a small handful of oversize PGAs. I've seen it reached with as few as
4 connections on a server running a single database.
Your Windows is a 32-bit OS. As such it (the OS) can only address 4g
of memory without resorting to smoke and mirrors. By default, Windows
will reserve 50% of the physical memory (up to the 4g limit) for
itself, which means that with 4g or more installed, Windows will
reserve 2g for itself, leaving 2g for *ALL* other processes. the /3GB
switch will tell windows to reserve only 1gb for itself and release
3gb for *ALL* other processes. These are hard OS limits.
The PAE switch allows Windows to start using the smoke and mirrors to
reach memory beyond 4gb (up to 16gb), but to use this memory, the app
still has to cooperate in ways that it sees fit. Oracle sees fit to
use it for buffer cache only. Everything else still has to fit into
whatever memory the OS allocated to Oracle out of the base 2 or 3 gb.
Search MetaLink for ORA-4030 and "Windows memory". You'll get several
good articles which explain all this in excruciating detail.
sybr...@hccnet.nl
>When /3GB switch is turned on, will all oracle instances (5 in my
>example) still have access only to 3GB memory combined or each
>instance will have limit of 3GB memory. Various metalink articels say
>this limit to be per instance so I am confused.
They are discussing *virtual* memory, not *physical* memory. As soon
as a system runs out of *physical* memory, it will swap memory it no
longer needs to disk. When this memory is needed again it will be read
from disk. This is called a page fault.
A disk is a *slow* device.
So, please, pray tell me, how desirable do you think it is to
configure 3 Gb *per instance*?
--
Sybrand Bakker
Senior Oracle DBA
zigz...@yahoo.com
If my server has 8GB physical meory, it will be nice to make use of
8GB instead of restricted only to 3GB. I have seen
so many articles which talk about 3GB or 2GB per instance
restriction, but now I am told that is not correct, 3GB or 2GB
restriction is all instances combined, so it is confusing. Apparently
there is some restriction related to how much shared memory one can
allocate on Windows Server, otherwise each instance should be able to
address 2GB or 3GB (with /3GB switch).
sybr...@hccnet.nl
I don't know whether you are a developer or a DBA or a sysadmin. In
the latter 2 cases (but also in the first case) you really should try
to understand the virtual memory concept. Allocating virtual memory
*beyond* physical memory doesn't make sense, as it will force your
system to swap.
Even if you would have 8 Gb, it *doesn't make sense* to allocate 3 Gb
for every instance, as that will allocate 15 Gb, which is 7 Gb beyond
physical RAM. Is that going to work? OF COURSE NOT, as the SYSTEM is
GOING TO SWAP LIKE HELL.
If you still don't understand this, I would recommend you find a
different profession.
Why is it that nowadays IT personell doesn't have a clue about the
underlying technology?
BD
>
> - Show quoted text -
Windows 32-bit is a 32-bit os - which means you multiply 2 by itself
32 times, and you get the number of bytes of memory that it can
access. It calculates out to 4294967296, which is the same as 4GB.
By default, Windows 32-bit keeps half of this available memory for its
kernel processes - leaving only 2GB for other programs.
So that is *it*. That is all that Windows 32-bit can see (unless you
use PAE). It has to allocate that memory to all of its processes. They
all have to share that one chunk of memory.
The /3GB switch reduces the amount of memory used by the kernel from
2GB to 1GB, leaving 3GB for other programs.
NOT 3GB for each program. 3GB for ALL other programs together.
Now - if 32-bit Windows can see 4GB of memory directly, imagine how
much 64-bit Windows could see.
18,446,744,073,709,551,616 bytes. Or thereabouts. Lots.
So if you need memory, get off of Windows 32-bit.
Charles Hooper
Google search:
site:microsoft.com windows 2000 maximum memory
Finds this web page:
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
"Operating systems based on Microsoft Windows NT technologies have
always provided applications with a flat 32-bit virtual address space
that describes 4 gigabytes (GB) of virtual memory. The address space
is usually split so that 2 GB of address space is directly accessible
to the application and the other 2 GB is only accessible to the
Windows executive software.
The 32-bit versions of the Windows 2000 Advanced Server and Windows NT
Server 4.0, Enterprise Edition, operating systems were the first
versions of Windows to provide applications with a 3-GB flat virtual
address space, with the kernel and executive components using only 1
GB. In response to customer requests, Microsoft has expanded the
availability of this support to the 32-bit version of Windows XP
Professional and all 32-bit versions of Windows Server 2003."
http://msdn2.microsoft.com/en-US/library/aa196734(SQL.80).aspx
"Windows NT 4.0 and Windows 2000 provide a 4-gigabyte (GB) virtual
address space at any time, the lower 2 GB of which is private per
process and available for application use. The upper 2 GB is reserved
for system use. Windows NT Server, Enterprise Edition provides a 4-GB
virtual address space for each Microsoft Win32® application, the lower
3 GB of which is private per process and available for application
use. The upper 1 GB is reserved for system use.
The 4-GB address space is mapped to the available physical memory by
Windows NT Virtual Memory Manager (VMM). The available physical memory
can be up to 4 GB, depending on hardware platform support."
http://msdn2.microsoft.com/en-us/library/ms178067.aspx
"The 32-bit operating systems such as Windows 2000 and Windows Server
2003 provide access to 4-gigabyte (GB) of virtual address space. The
lower 2 GB of virtual memory is private per process and available for
application use. The upper 2 GB is reserved for operating system use.
All operating system editions, starting with Microsoft Windows XP
Professional and later, including Windows Server 2003, include a
boot.ini switch that can provide applications with access to 3 GB of
virtual memory, limiting the operating system to 1 GB. See your
Windows documentation for more information on using the /3GB switch
memory configuration."
>From "Microsoft Windows 95 Resource Kit" paperback version (c)1995
page 976-977:
"Windows 95 addresses this issue by using the 32-bit capabilities of
the 80386 (and above) processor architecture to support a flat, linear
memory model for 32-bit operating system functionality and Win32-based
applications. A linear addressing model simplifies the development
process for application vendors, and removes the performance penalties
imposed by the segmented memory architecture.
With this addressing model, Windows 95 allows full use of the 4 GB of
addressable memory space for all 32-bit operating system components
and applications. Each 32-bit application can access up to 2 GB of
addressable memory space, which is large enough to support even the
largest desktop application.
The Memory Pager maps virtual addresses from the process's address
space to physical pages in the computer's memory. In doing so, it
hides the physical organization of memory from the process's threads."
Hopefully, the above clarifies how memory is allocated on 32 bit
Windows, which seems to be consistent all the way back to 1995.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.
Brian Peasland
> underlying technology?
You can blame that on the colleges/universities/tech schools. It seems
like all of the above are trying to teach the latest and greatest
technologies without teaching the fundamental building blocks. And I
think this shows in many recent graduates (not all of them though).
Not too many years ago, I taught a Data Structures class at a local
college. The prerequisite was Programming I and Programming II. To a
person...each student informed me that they did not know how to write a
program from scratch. Their instructor had always provided them a
partial program and they just filled in the blanks. This floored me and
I knew it was time to get out of the teaching business (no offense
Daniel).
Just my 2 cents...
Brian
--
===================================================================
Brian Peasland
d...@nospam.peasland.net
http://www.peasland.net
Remove the "nospam." from the email address to email me.
"I can give it to you cheap, quick, and good.
Now pick two out of the three" - Unknown
--
Posted via a free Usenet account from http://www.teranews.com
Frank van Bortel
Hash: SHA1
> and applications. Each 32-bit application can access up to 2 GB of
> addressable memory space, which is large enough to support even the
> largest desktop application.
L'histoire se repete... Didn't I hear something similar on the
640kB address model?
Apart from this being utterly nonsense, of course. AutoCAD, anyone?
- --
Regards,
Frank van Bortel
Top-posting is one way to shut me up...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFGhWZzLw8L4IAs830RAlNZAKCcOFOy6DYaGOBxZsrc3w9CGsIoYACgiN17
lf8yyf51IOFB/IGb1DdVNpc=
=wLCA
-----END PGP SIGNATURE-----
zigz...@yahoo.com
Is there any thing wrong is using /PAE switch and setting some
parameters in init.ora to put buffer pools in this address space.I
want to have large buffer pool so I can "pin" some tables in memory
using
recycle pool. In addition, increase size of my default buffer pool. I
have 8GB memory on the server, some of it wll betaken kernel and other
oracle parameters - PGA etc, bur rest I can use for buffer pools.
sybr...@hccnet.nl
Recycle pool does not *pin* tables in memory. Tables can be kept
longer in memory by using the *keep* pool (funny name isn't it, if you
think of it).
Apart from that cranking up the memory won't resolve your fundamental
problem: apparently you never tuned your application and now you want
to resolve that by throwing memory at the problem.
This method has been demonstrated to be fundamentally wrong over and
over again, and is one of the safest methods to end up in hell or at
the unemployment office.
zigz...@yahoo.com
>
> - Show quoted text -
FYI, keep and recycle pools work exactly the same way. keep and
recycle are just the names given by Oracle. Vendor sells the
application, I cannot do any tuning of application.
sybr...@hccnet.nl
>FYI, keep and recycle pools work exactly the same way. keep and
>recycle are just the names given by Oracle. Vendor sells the
>application, I cannot do any tuning of application.
Actually they don't. But as you don't even understand the virtual
memory concept I won't waste my time in explaining this further.
Obviously it is not true you cannot due any tuning of application, at
least you can identify the problem areas, and address those with
vendor.
But as you prefer the DKB method of 'tuning' nothing is going to be
resolved and you will end up in hell, where you deserve to be.
zigz...@yahoo.com
You do not have any understanding of keep and recycle pools at all.
Read Tom Kyte's web site or post a question there. Problem with you
is you have no idea of reality, if vendor could fix the problem, it
won't be an issue at all. In many compaines people get stuck with
whatever vendor provides, yet same time management wants to improve
performance, so all one can do from DBA's perspective is to figure how
to add more memory, more CPU's etc. That is reality. Many years ago, I
used to work in an environment where company's developemnt group will
develop all the applications and you can ask them to tume the
application without much problem, but that is not true in all the
shops.
Also, using WIDNOWS'S AWE one can go beyound 4GB. That was my original
question which you have
no undesratnding.
zigz...@yahoo.com
>
> - Show quoted text -
sybr...@hccnet.nl
>Also, using WIDNOWS'S AWE one can go beyound 4GB. That was my original
>question which you have
>no undesratnding.
I'm not sure why you insist I don't understand the problem.
Actually it is *YOU* and *YOU ALONE*, who fails to understand it is
PURE MADNESS to run 5 databases on a single server and to crank up the
memory to 3 Gb for each of them, when there is ONLY 8 Gb physical
memory available.
You don't understand the virtual memory concept, and you really want
to apply the VOODOO concept of tuning to the server.
That shows you don't have ANY UNDERSTANDING OF VITAL IT CONCEPTS.
It also shows you DON'T DESERVE the name DBA, and you should be SHOWED
TO THE DOOR FIRST THING TOMORROW.
CRANK UP THAT MEMORY, AND NOTICE IT DOESN'T HELP, AT ALL.
I WILL GLADLY EXPLAIN TO YOUR BOSS WHY, AND RECOMMEND HE KICKS YOU
OuT.
YOU DON'T DESERVE ANY BETTER, YOU ARE BOTH INCOMPETENT AND ARROGANT
AND AN IDIOT.
--
zigz...@yahoo.com
You describe yourself very well:
"YOU DON'T DESERVE ANY BETTER, YOU ARE BOTH INCOMPETENT AND ARROGANT
AND AN IDIOT.:
Over and over again you show your arrogance and igonrarnce. It is
never too late to learn from others because you clearly have no
undersatdning of keep and recycle pools. What a shame.
Charles Hooper
> recycle are just the names given by Oracle. Vendor sells the
> application, I cannot do any tuning of application.
The above comment is interesting. I recall reading in several places
that the keep pool tries to keep blocks in memory, much like the
default pool, while the recycle pool tries to quickly age blocks out
of the pool. After a bit of a search, I found a bit of disagreement.
The results of the search follow:
"Expert Oracle Database 10g Administration" paraphrase:
The recycle buffer pool will cycle out the objects read out of the
cache as soon as the transaction ends.
"Oracle Database Concepts 10g Release 2 (10.2)":
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/memory.htm#sthref1291
The KEEP buffer pool retains the schema object's data blocks in
memory.
The RECYCLE buffer pool eliminates data blocks from memory as soon as
they are no longer needed.
The DEFAULT buffer pool contains data blocks from schema objects that
are not assigned to any buffer pool, as well as schema objects that
are explicitly assigned to the DEFAULT pool.
"Oracle8 Concepts Release 8.0":
http://download-east.oracle.com/docs/cd/A58617_01/server.804/a58227/ch_mem.htm
The KEEP buffer pool retains the schema object's data blocks in
memory.
The RECYCLE buffer pool eliminates data blocks from memory as soon as
they are no longer needed.
The DEFAULT buffer pool contains data blocks from schema objects that
are not assigned to any buffer pool, as well as schema objects that
are explicitly assigned to the DEFAULT pool.
"Expert Oracle One on One" Page 80:
"We also have the ability to carve out a space for segments in the
buffer pool. This space is called the RECYCLE pool. Here, the aging
of the blocks is done differently to the KEEP pool. In the KEEP pool,
the goal is to keep 'warm' and 'hot' blocks cached for as long as
possible. In the recycle pool, the goal is to age out a block as soon
as it is no longer needed."
http://www.jlcomp.demon.co.uk/faq/pin_table.html
"NOTE: there is no difference in the behavior of the three buffer
pools, the naming of the pools is merely for memo technically reasons
and intended use."
http://forums.oracle.com/forums/thread.jspa?threadID=524119 - look for
the posting by Jonathan Lewis for context:
"You will rarely be able to beat Oracle's caching algorithms by
playing with KEEP and RECYCLE pools - but there are a few special
cases..."
Niall Litchfield
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > and applications. Each 32-bit application can access up to 2 GB of
> > addressable memory space, which is large enough to support even the
> > largest desktop application.
>
> L'histoire se repete... Didn't I hear something similar on the
> 640kB address model?
No. Well you almost certainly did but inaccurately.
http://everything2.com/index.pl?node_id=91182 for example.
I do like the idea of Oracle as a desktop application though :)
Niall
zigz...@yahoo.com
> On Jul 1, 12:37 pm, zigzag...@yahoo.com wrote:
>
> > On Jul 1, 11:41 am, sybra...@hccnet.nl wrote:
> > > Apart from that cranking up the memory won't resolve your fundamental
> > > problem: apparently you never tuned your application and now you want
> > > to resolve that by throwing memory at the problem.
> > > This method has been demonstrated to be fundamentally wrong over and
> > > over again, and is one of the safest methods to end up in hell or at
> > > the unemployment office.
>
> > > --
> > > Sybrand Bakker
> > > Senior Oracle DBA-
>
> > FYI, keep and recycle pools work exactly the same way. keep and
> > recycle are just the names given by Oracle. Vendor sells the
> > application, I cannot do any tuning of application.
>
> The above comment is interesting. I recall reading in several places
> that the keep pool tries to keep blocks in memory, much like the
> default pool, while the recycle pool tries to quickly age blocks out
> of the pool. After a bit of a search, I found a bit of disagreement.
> The results of the search follow:
>
> "Expert Oracle Database 10g Administration" paraphrase:
> The recycle buffer pool will cycle out the objects read out of the
> cache as soon as the transaction ends.
>
> The KEEP buffer pool retains the schema object's data blocks in
> memory.
> The RECYCLE buffer pool eliminates data blocks from memory as soon as
> they are no longer needed.
> The DEFAULT buffer pool contains data blocks from schema objects that
> are not assigned to any buffer pool, as well as schema objects that
> are explicitly assigned to the DEFAULT pool.
>
> The KEEP buffer pool retains the schema object's data blocks in
> memory.
> The RECYCLE buffer pool eliminates data blocks from memory as soon as
> they are no longer needed.
> The DEFAULT buffer pool contains data blocks from schema objects that
> are not assigned to any buffer pool, as well as schema objects that
> are explicitly assigned to the DEFAULT pool.
>
> "Expert Oracle One on One" Page 80:
> "We also have the ability to carve out a space for segments in the
> buffer pool. This space is called the RECYCLE pool. Here, the aging
> of the blocks is done differently to the KEEP pool. In the KEEP pool,
> the goal is to keep 'warm' and 'hot' blocks cached for as long as
> possible. In the recycle pool, the goal is to age out a block as soon
> as it is no longer needed."
>
> http://www.jlcomp.demon.co.uk/faq/pin_table.html
> "NOTE: there is no difference in the behavior of the three buffer
> pools, the naming of the pools is merely for memo technically reasons
> and intended use."
>
> the posting by Jonathan Lewis for context:
> "You will rarely be able to beat Oracle's caching algorithms by
> playing with KEEP and RECYCLE pools - but there are a few special
> cases..."
>
> Charles Hooper
> IT Manager/Oracle DBA
> K&M Machine-Fabricating, Inc.
>> "NOTE: there is no difference in the behavior of the three buffer
pools, the naming of the pools is merely for memo technically reasons
and intended use."
This is exactly what I meant in my first post.
zigz...@yahoo.com
> > the posting by Jonathan Lewis for context:
> > "You will rarely be able to beat Oracle's caching algorithms by
> > playing with KEEP and RECYCLE pools - but there are a few special
> > cases..."
>
> > Charles Hooper
> > IT Manager/Oracle DBA
> > K&M Machine-Fabricating, Inc.
> >> "NOTE: there is no difference in the behavior of the three buffer
>
> pools, the naming of the pools is merely for memo technically reasons
> and intended use."
>
>
> - Show quoted text -
"NOTE: there is no difference in the behavior of the three buffer
pools, the naming of the pools is merely for memo technically reasons
and intended use."
This is exactly what I meant in my first post.-
Just because you put a table in recycle pool instead of keep. Oracle
is not going to treat it any differently.
Charles Hooper
> On Jul 2, 5:29 am, zigzag...@yahoo.com wrote:
> > On Jul 1, 10:47 pm, Charles Hooper <hooperc2...@yahoo.com> wrote:
>
> > > On Jul 1, 12:37 pm, zigzag...@yahoo.com wrote:
>
> > > > On Jul 1, 11:41 am, sybra...@hccnet.nl wrote:
> > > > > Apart from that cranking up the memory won't resolve your fundamental
> > > > > problem: apparently you never tuned your application and now you want
> > > > > to resolve that by throwing memory at the problem.
> > > > > This method has been demonstrated to be fundamentally wrong over and
> > > > > over again, and is one of the safest methods to end up in hell or at
> > > > > the unemployment office.
>
> > > > > --
> > > > > Sybrand Bakker
> > > > > Senior Oracle DBA-
>
> > > > FYI, keep and recycle pools work exactly the same way. keep and
> > > > recycle are just the names given by Oracle. Vendor sells the
> > > > application, I cannot do any tuning of application.
>
> > > The above comment is interesting. I recall reading in several places
> > > that the keep pool tries to keep blocks in memory, much like the
> > > default pool, while the recycle pool tries to quickly age blocks out
> > > of the pool. After a bit of a search, I found a bit of disagreement.
> > > The results of the search follow:
<snip>
> > > "Expert Oracle One on One" Page 80:
> > > "We also have the ability to carve out a space for segments in the
> > > buffer pool. This space is called the RECYCLE pool. Here, the aging
> > > of the blocks is done differently to the KEEP pool. In the KEEP pool,
> > > the goal is to keep 'warm' and 'hot' blocks cached for as long as
> > > possible. In the recycle pool, the goal is to age out a block as soon
> > > as it is no longer needed."
>
> > >http://www.jlcomp.demon.co.uk/faq/pin_table.html
> > > "NOTE: there is no difference in the behavior of the three buffer
> > > pools, the naming of the pools is merely for memo technically reasons
> > > and intended use."
>
> > >http://forums.oracle.com/forums/thread.jspa?threadID=524119-lookfor
> > > the posting by Jonathan Lewis for context:
> > > "You will rarely be able to beat Oracle's caching algorithms by
> > > playing with KEEP and RECYCLE pools - but there are a few special
> > > cases..."
>
> > > Charles Hooper
> > > IT Manager/Oracle DBA
> > > K&M Machine-Fabricating, Inc.
> > >> "NOTE: there is no difference in the behavior of the three buffer
>
> > pools, the naming of the pools is merely for memo technically reasons
> > and intended use."
>
> > This is exactly what I meant in my first post.>
>
> http://www.jlcomp.demon.co.uk/faq/pin_table.html
> "NOTE: there is no difference in the behavior of the three buffer
> pools, the naming of the pools is merely for memo technically reasons
> and intended use."
>
> This is exactly what I meant in my first post.-
> Just because you put a table in recycle pool instead of keep. Oracle
> is not going to treat it any differently.
>
A bit more searching in books finds two different opinions on how the
different buffer caches operate:
"Expert Oracle Database 10g Administration" page 123:
"Keep buffer pool: Keeps the data blocks in memory. You may have
small tables that are frequently accessed, so to prevent them from
being aged out of the database buffer cache, you can assign the tables
to the keep buffer cache when they are created.
Recycle buffer cache: Removes the data from the cache immediately
after use. You need to use this buffer cache carefully, if you decide
to use it at all. The recycle buffer cache will cycle out the object
from the cache as soon as the transaction is over."
"Expert Oracle Database Architecture" page 141:
"In fact, the three pools manage blocks in a mostly identical fashion;
they do not have radically different algorithms for aging or caching
blocks. The goal here was to give the DBA the ability to segregate
segments to hot, warm, and do not care to cache areas."
The first of the above quotes seems to be in agreement with Tom Kyte's
"Expert Oracle One on One" book and the Oracle 8 and Oracle 10g R2
Concepts manual. The second of the above quotes (from another book by
Tom Kyte) seems to be in agreement with the article written by Svend
Jensen on Jonathan Lewis's website.
It makes one wonder... is there a correct answer?
sybrandb
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
It makes one indeed wonder: Was the OP justified in stating I didn't
understand the concept of the keep and the recycle pool at all? I
don't think so. But then the OP is an idiot who mistakenly claims he
knows everything better, and won't retreat, even when it was been
demonstrated sufficiently I was not wrong at all.
zigz...@yahoo.com
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Yes, there is correct answer "the quote which I sent in my previous
mail". Apparenetly you have never used this feature. Once you use the
feature haze will disappear.
zigz...@yahoo.com
>
> - Show quoted text -
You are an idiot not OP.
Frank van Bortel
Hash: SHA1
Niall Litchfield wrote:
> On Jun 29, 9:07 pm, Frank van Bortel <frank.van.bor...@gmail.com>
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> and applications. Each 32-bit application can access up to 2 GB of
>>> addressable memory space, which is large enough to support even the
>>> largest desktop application.
>> L'histoire se repete... Didn't I hear something similar on the
>> 640kB address model?
>
> No. Well you almost certainly did but inaccurately.
>
> http://everything2.com/index.pl?node_id=91182 for example.
Well - I don't believe that, either, because only 256k was
allocated to "special" purposes (the I/O map, to be exact)
Some models, running MS/DOS, ran with 768kB of memory, and
could *use* it (to run Oracle V4, for example).
The TI Professional Computer was such a machine. That fact
does not comply with the quoted article.
MS has been twisting history before (not to use the word rewrite,
which is too strong), and has always bee excellent in marketing.
>
> I do like the idea of Oracle as a desktop application though :)
And I stated AutoCAD as an example, not Oracle.
>
> Niall
>
I guess this will soon also be one of those 'never said 2GB was enough'
things.
Bottom line is - you'll never have enough memory. There will always be
a product that uses more. Just like CPU power.
- --
Regards,
Frank van Bortel
Top-posting is one way to shut me up...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFGiUO9Lw8L4IAs830RAkqDAJ4sdx88NAslpgwubKy589ujhXHXhQCeM7J9
AU1acP5R4H0v5ikkdOjB9x8=
=9JPF
-----END PGP SIGNATURE-----
fitzj...@cox.net
>
> - Show quoted text -
No, it can't. Windows 32-bit can access 4 GB of physical memory and
no more, period. Installing 8 GB of memory on a 32-bit windows
machine is folly as only half of that allotment can be addressed.
The /PAE switch engages a 'smoke and mirrors' approach to SIMULATE
more memory, not provide actual physical addresses.
If you really want to access more than 4 GB of memory you need to
ditch the 32-bit version of Windows and install the 64-bit release.
David Fitzjarrell
joel garry
Yes, and it is actually quite simple. There doesn't have to be
separate _mechanisms_ for the pools. The _behavior_ of the pools is
influenced by the type of access of the objects in the pools. The
idea is to segregate the access types - if the pool is going to be
thrashed, put objects in recycle that thrash. This has the effect of
lowering thrashing in the other pools. Separating out hot and wam
areas is more subtle, but still, if you have too many different kinds
of objects for just depending on the default LRU mechanism, it
supposedly could help. Reread the references carefully with that in
mind.
jg
--
@home.com is bogus.
Nothin' new here: http://www.signonsandiego.com/uniontrib/20070703/news_1b3mortgage.html
Niall Litchfield
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Niall Litchfield wrote:
> > On Jun 29, 9:07 pm, Frank van Bortel <frank.van.bor...@gmail.com>
> > wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
>
> >>> and applications. Each 32-bit application can access up to 2 GB of
> >>> addressable memory space, which is large enough to support even the
> >>> largest desktop application.
> >> L'histoire se repete... Didn't I hear something similar on the
> >> 640kB address model?
>
> > No. Well you almost certainly did but inaccurately.
>
>
> Well - I don't believe that, either, because only 256k was
> allocated to "special" purposes (the I/O map, to be exact)
> Some models, running MS/DOS, ran with 768kB of memory, and
> could *use* it (to run Oracle V4, for example).
well doesn't it seem just a teensy bit unlikely that if msdos machines
ran with 768k memory then the quote may not have happened. Still since
it was a 1981 quote (in a newspaper according to some sources) I'm
sure it will be found if I'm wrong. This group has enough people who
don't like ms products and are sticklers for accuracy after all.
> The TI Professional Computer was such a machine. That fact
> does not comply with the quoted article.
>
> MS has been twisting history before (not to use the word rewrite,
> which is too strong), and has always bee excellent in marketing.
>
>
>
> > I do like the idea of Oracle as a desktop application though :)
>
> And I stated AutoCAD as an example, not Oracle.
It was charles I was quoting, and hopefully ironically.
>
> > Niall
>
> I guess this will soon also be one of those 'never said 2GB was enough'
> things.
>
> Bottom line is - you'll never have enough memory. There will always be
> a product that uses more. Just like CPU power.
Indeed. And often it will be windows :(
Charles Hooper
> On Jul 2, 5:49 am, Charles Hooper <hooperc2...@yahoo.com> wrote:
> > The first of the above quotes seems to be in agreement with Tom Kyte's
> > "Expert Oracle One on One" book and the Oracle 8 and Oracle 10g R2
> > Concepts manual. The second of the above quotes (from another book by
> > Tom Kyte) seems to be in agreement with the article written by Svend
> > Jensen on Jonathan Lewis's website.
>
> > It makes one wonder... is there a correct answer?
>
> Yes, and it is actually quite simple. There doesn't have to be
> separate _mechanisms_ for the pools. The _behavior_ of the pools is
> influenced by the type of access of the objects in the pools. The
> idea is to segregate the access types - if the pool is going to be
> thrashed, put objects in recycle that thrash. This has the effect of
> lowering thrashing in the other pools. Separating out hot and wam
> areas is more subtle, but still, if you have too many different kinds
> of objects for just depending on the default LRU mechanism, it
> supposedly could help. Reread the references carefully with that in
> mind.
>
> jg
Curiosity is a huge time sink. I wondered if there are actually
different mechanisms for the buffering of the KEEP and RECYCLE buffer
caches. The test below is rather long, but it seems to indicate, at
least on Oracle 10.2.0.3 with an 8KB block size, that there is a
difference in the caching mechanisms for the KEEP and RECYCLE buffer
caches:
STARTUP
Create 3 tables and indexes in the KEEP buffer pool and the RECYCLE
buffer pool:
CREATE TABLE T1 (
MY_DATE DATE NOT NULL,
MY_NUMBER NUMBER(12,10) NOT NULL,
MY_ROW NUMBER(12) NOT NULL)
STORAGE (BUFFER_POOL KEEP);
CREATE UNIQUE INDEX T1_IND1 ON T1(MY_DATE)
STORAGE (BUFFER_POOL KEEP);
CREATE TABLE T2 (
MY_DATE DATE NOT NULL,
MY_NUMBER NUMBER(12,10) NOT NULL,
MY_ROW NUMBER(12) NOT NULL)
STORAGE (BUFFER_POOL KEEP);
CREATE UNIQUE INDEX T2_IND1 ON T2(MY_DATE)
STORAGE (BUFFER_POOL KEEP);
CREATE TABLE T3 (
MY_DATE DATE NOT NULL,
MY_NUMBER NUMBER(12,10) NOT NULL,
MY_ROW NUMBER(12) NOT NULL)
STORAGE (BUFFER_POOL KEEP);
CREATE UNIQUE INDEX T3_IND1 ON T3(MY_DATE)
STORAGE (BUFFER_POOL KEEP);
CREATE TABLE T1_R (
MY_DATE DATE NOT NULL,
MY_NUMBER NUMBER(12,10) NOT NULL,
MY_ROW NUMBER(12) NOT NULL)
STORAGE (BUFFER_POOL RECYCLE);
CREATE UNIQUE INDEX T1_IND1_R ON T1_R(MY_DATE)
STORAGE (BUFFER_POOL RECYCLE);
CREATE TABLE T2_R (
MY_DATE DATE NOT NULL,
MY_NUMBER NUMBER(12,10) NOT NULL,
MY_ROW NUMBER(12) NOT NULL)
STORAGE (BUFFER_POOL RECYCLE);
CREATE UNIQUE INDEX T2_IND1_R ON T2_R(MY_DATE)
STORAGE (BUFFER_POOL RECYCLE);
CREATE TABLE T3_R (
MY_DATE DATE NOT NULL,
MY_NUMBER NUMBER(12,10) NOT NULL,
MY_ROW NUMBER(12) NOT NULL)
STORAGE (BUFFER_POOL RECYCLE);
CREATE UNIQUE INDEX T3_IND1_R ON T3_R(MY_DATE)
STORAGE (BUFFER_POOL RECYCLE);
Make certain that the two buffer pools are the same size:
ALTER SYSTEM SET DB_KEEP_CACHE_SIZE=16777216;
ALTER SYSTEM SET DB_RECYCLE_CACHE_SIZE=16777216;
Now, let's start loading data into the tables:
INSERT INTO
T1
SELECT
TRUNC(SYSDATE)+ROWNUM,
COS(ROWNUM/180*3.141592),
ROWNUM
FROM
DUAL
CONNECT BY
LEVEL<=100000;
COMMIT;
INSERT INTO
T2
SELECT
TRUNC(SYSDATE)+ROWNUM,
COS(ROWNUM/180*3.141592),
ROWNUM
FROM
DUAL
CONNECT BY
LEVEL<=100000;
COMMIT;
INSERT INTO
T3
SELECT
TRUNC(SYSDATE)+ROWNUM,
COS(ROWNUM/180*3.141592),
ROWNUM
FROM
DUAL
CONNECT BY
LEVEL<=100000;
COMMIT;
INSERT INTO
T1_R
SELECT
TRUNC(SYSDATE)+ROWNUM,
COS(ROWNUM/180*3.141592),
ROWNUM
FROM
DUAL
CONNECT BY
LEVEL<=100000;
COMMIT;
INSERT INTO
T2_R
SELECT
TRUNC(SYSDATE)+ROWNUM,
COS(ROWNUM/180*3.141592),
ROWNUM
FROM
DUAL
CONNECT BY
LEVEL<=100000;
COMMIT;
INSERT INTO
T3_R
SELECT
TRUNC(SYSDATE)+ROWNUM,
COS(ROWNUM/180*3.141592),
ROWNUM
FROM
DUAL
CONNECT BY
LEVEL<=100000;
COMMIT;
Create one more table in each of the buffer pools and load with data:
CREATE TABLE T4 (
MY_DATE DATE NOT NULL,
MY_NUMBER NUMBER(12,10) NOT NULL,
MY_ROW NUMBER(12) NOT NULL)
STORAGE (BUFFER_POOL KEEP);
CREATE UNIQUE INDEX T4_IND1 ON T4(MY_DATE)
STORAGE (BUFFER_POOL KEEP);
CREATE TABLE T4_R (
MY_DATE DATE NOT NULL,
MY_NUMBER NUMBER(12,10) NOT NULL,
MY_ROW NUMBER(12) NOT NULL)
STORAGE (BUFFER_POOL RECYCLE);
CREATE UNIQUE INDEX T4_IND1_R ON T4_R(MY_DATE)
STORAGE (BUFFER_POOL RECYCLE);
INSERT INTO
T4
SELECT
TRUNC(SYSDATE)+ROWNUM,
COS(ROWNUM/180*3.141592),
ROWNUM
FROM
DUAL
CONNECT BY
LEVEL<=400000;
COMMIT;
INSERT INTO
T4_R
SELECT
TRUNC(SYSDATE)+ROWNUM,
COS(ROWNUM/180*3.141592),
ROWNUM
FROM
DUAL
CONNECT BY
LEVEL<=400000;
COMMIT;
Now, let's see what is in the KEEP and RECYCLE pools:
SELECT
DS.BUFFER_POOL,
SUBSTR(DO.OBJECT_NAME,1,9) OBJECT_NAME,
DS.BLOCKS OBJECT_BLOCKS,
COUNT(*) CACHED_BLOCKS
FROM
DBA_OBJECTS DO,
DBA_SEGMENTS DS,
V$BH V
WHERE
DO.DATA_OBJECT_ID=V.OBJD
AND DO.OWNER=DS.OWNER(+)
AND DO.OBJECT_NAME=DS.SEGMENT_NAME(+)
AND DO.OBJECT_TYPE=DS.SEGMENT_TYPE(+)
AND DS.BUFFER_POOL IN ('KEEP','RECYCLE')
GROUP BY
DS.BUFFER_POOL,
DO.OBJECT_NAME,
DS.BLOCKS
ORDER BY
DO.OBJECT_NAME,
DS.BUFFER_POOL;
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
KEEP T2_IND1 256 2
RECYCLE T2_IND1_R 256 3
RECYCLE T2_R 384 2
KEEP T3 384 2
KEEP T3_IND1 256 3
RECYCLE T3_IND1_R 256 23
RECYCLE T3_R 384 64
KEEP T4 1536 1213
KEEP T4_IND1 1024 778
RECYCLE T4_IND1_R 1024 726
RECYCLE T4_R 1536 1175
On data load, the number cached blocks are different between the KEEP
and RECYCLE pools.
Now, let's shutdown and startup to clear the cache and collect
statistics on the tables and indexes:
SHUTDOWN IMMEDIATE;
STARTUP
EXEC
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T1',CASCADE=>TRUE);
EXEC
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2',CASCADE=>TRUE);
EXEC
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T3',CASCADE=>TRUE);
EXEC
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T4',CASCADE=>TRUE);
EXEC
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T1_R',CASCADE=>TRUE);
EXEC
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2_R',CASCADE=>TRUE);
EXEC
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T3_R',CASCADE=>TRUE);
EXEC
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T4_R',CASCADE=>TRUE);
Let's see what is in the buffer cache:
SELECT
DS.BUFFER_POOL,
SUBSTR(DO.OBJECT_NAME,1,9) OBJECT_NAME,
DS.BLOCKS OBJECT_BLOCKS,
COUNT(*) CACHED_BLOCKS
FROM
DBA_OBJECTS DO,
DBA_SEGMENTS DS,
V$BH V
WHERE
DO.DATA_OBJECT_ID=V.OBJD
AND DO.OWNER=DS.OWNER(+)
AND DO.OBJECT_NAME=DS.SEGMENT_NAME(+)
AND DO.OBJECT_TYPE=DS.SEGMENT_TYPE(+)
AND DS.BUFFER_POOL IN ('KEEP','RECYCLE')
GROUP BY
DS.BUFFER_POOL,
DO.OBJECT_NAME,
DS.BLOCKS
ORDER BY
DO.OBJECT_NAME,
DS.BUFFER_POOL;
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
RECYCLE T1_IND1_R 256 2
KEEP T4 1536 1233
KEEP T4_IND1 1024 765
RECYCLE T4_IND1_R 1024 866
RECYCLE T4_R 1536 1130
On statistics collection, the number cached blocks are different
between the KEEP and RECYCLE pools.
SHUTDOWN IMMEDIATE;
STARTUP
Let's try updating some rows:
UPDATE
T1
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+500);
COMMIT;
UPDATE
T2
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+500);
COMMIT;
UPDATE
T3
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+500);
COMMIT;
UPDATE
T4
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+500);
COMMIT;
UPDATE
T1_R
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+500);
COMMIT;
UPDATE
T2_R
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+500);
COMMIT;
UPDATE
T3_R
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+500);
COMMIT;
UPDATE
T4_R
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+500);
COMMIT;
Let's see what is in the buffer cache:
SELECT
DS.BUFFER_POOL,
SUBSTR(DO.OBJECT_NAME,1,9) OBJECT_NAME,
DS.BLOCKS OBJECT_BLOCKS,
COUNT(*) CACHED_BLOCKS
FROM
DBA_OBJECTS DO,
DBA_SEGMENTS DS,
V$BH V
WHERE
DO.DATA_OBJECT_ID=V.OBJD
AND DO.OWNER=DS.OWNER(+)
AND DO.OBJECT_NAME=DS.SEGMENT_NAME(+)
AND DO.OBJECT_TYPE=DS.SEGMENT_TYPE(+)
AND DS.BUFFER_POOL IN ('KEEP','RECYCLE')
GROUP BY
DS.BUFFER_POOL,
DO.OBJECT_NAME,
DS.BLOCKS
ORDER BY
DO.OBJECT_NAME,
DS.BUFFER_POOL;
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
KEEP T1 384 6
KEEP T1_IND1 256 5
RECYCLE T1_IND1_R 256 3
RECYCLE T1_R 384 3
KEEP T2 384 6
KEEP T2_IND1 256 5
RECYCLE T2_IND1_R 256 3
RECYCLE T2_R 384 3
KEEP T3 384 6
KEEP T3_IND1 256 5
RECYCLE T3_IND1_R 256 3
RECYCLE T3_R 384 3
KEEP T4 1536 8
KEEP T4_IND1 1024 13
RECYCLE T4_IND1_R 1024 4
RECYCLE T4_R 1536 3
On data update, the number cached blocks are different between the
KEEP and RECYCLE pools.
Let's try a larger update on a single table:
UPDATE
T3
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+50000);
COMMIT;
UPDATE
T3_R
SET
MY_ROW=MY_ROW+100
WHERE
MY_DATE BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE+50000);
COMMIT;
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
KEEP T1 384 6
KEEP T1_IND1 256 5
RECYCLE T1_IND1_R 256 3
RECYCLE T1_R 384 3
KEEP T2 384 6
KEEP T2_IND1 256 5
RECYCLE T2_IND1_R 256 3
RECYCLE T2_R 384 3
KEEP T3 384 548
KEEP T3_IND1 256 5
RECYCLE T3_IND1_R 256 3
RECYCLE T3_R 384 548
KEEP T4 1536 6
KEEP T4_IND1 1024 13
RECYCLE T4_IND1_R 1024 4
RECYCLE T4_R 1536 3
On data update of a single table, the number cached blocks for the
table affected by the update is roughly the same.
Let's try performing full tablescans on all of the test tables:
SELECT
COUNT(*)
FROM
T1
WHERE
MY_NUMBER<10;
SELECT
COUNT(*)
FROM
T2
WHERE
MY_NUMBER<10;
SELECT
COUNT(*)
FROM
T3
WHERE
MY_NUMBER<10;
SELECT
COUNT(*)
FROM
T4
WHERE
MY_NUMBER<10;
SELECT
COUNT(*)
FROM
T1_R
WHERE
MY_NUMBER<10;
SELECT
COUNT(*)
FROM
T2_R
WHERE
MY_NUMBER<10;
SELECT
COUNT(*)
FROM
T3_R
WHERE
MY_NUMBER<10;
SELECT
COUNT(*)
FROM
T4_R
WHERE
MY_NUMBER<10;
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
KEEP T1 384 2
RECYCLE T1_IND1_R 256 3
RECYCLE T1_R 384 372
KEEP T2 384 176
RECYCLE T2_IND1_R 256 3
RECYCLE T2_R 384 372
KEEP T3 384 373
RECYCLE T3_IND1_R 256 3
RECYCLE T3_R 384 548
KEEP T4 1536 1447
RECYCLE T4_IND1_R 1024 4
RECYCLE T4_R 1536 690
At least in this test case, there is a difference in the caching
mechanisms for the KEEP and RECYCLE buffer caches.
Please let me know if there is a mistake in this test case, other than
CACHED_BLOCKS exceeds OBJECT_BLOCKS in some cases.
Charles Hooper
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
KEEP T1 384 1
KEEP T1_IND1 256 1
RECYCLE T1_IND1_R 256 1
KEEP T2 384 3
KEEP T2_IND1 256 4
RECYCLE T2_IND1_R 256 1
RECYCLE T2_R 384 1
KEEP T3 384 139
KEEP T3_IND1 256 89
RECYCLE T3_IND1_R 256 60
RECYCLE T3_R 384 97
KEEP T4 1536 1055
KEEP T4_IND1 1024 708
RECYCLE T4_IND1_R 1024 738
RECYCLE T4_R 1536 1097
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
KEEP T4 1536 1164
KEEP T4_IND1 1024 836
RECYCLE T4_IND1_R 1024 813
RECYCLE T4_R 1536 1187
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
KEEP T1 384 6
KEEP T1_IND1 256 5
RECYCLE T1_IND1_R 256 3
RECYCLE T1_R 384 3
KEEP T2 384 6
KEEP T2_IND1 256 5
RECYCLE T2_IND1_R 256 3
RECYCLE T2_R 384 3
KEEP T3 384 6
KEEP T3_IND1 256 5
RECYCLE T3_IND1_R 256 3
RECYCLE T3_R 384 3
KEEP T4 1536 8
KEEP T4_IND1 1024 13
RECYCLE T4_IND1_R 1024 4
RECYCLE T4_R 1536 3
>
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
KEEP T1 384 6
KEEP T1_IND1 256 5
RECYCLE T1_IND1_R 256 3
RECYCLE T1_R 384 3
KEEP T2 384 6
KEEP T2_IND1 256 5
RECYCLE T2_IND1_R 256 3
RECYCLE T2_R 384 3
KEEP T3 384 597
KEEP T3_IND1 256 5
RECYCLE T3_IND1_R 256 3
RECYCLE T3_R 384 568
KEEP T4 1536 6
KEEP T4_IND1 1024 13
RECYCLE T4_IND1_R 1024 4
RECYCLE T4_R 1536 3
> Let's try performing full tablescans on all of the test tables:
BUFFER_ OBJECT_NA OBJECT_BLOCKS CACHED_BLOCKS
------- --------- ------------- -------------
KEEP T1 384 2
RECYCLE T1_R 384 1
KEEP T2 384 182
RECYCLE T2_R 384 184
KEEP T3 384 378
RECYCLE T3_R 384 376
KEEP T4 1536 1441
RECYCLE T4_R 1536 1441
joel garry
> On Jul 3, 1:37 pm, joel garry <joel-ga...@home.com> wrote:
>
> > On Jul 2, 5:49 am, Charles Hooper <hooperc2...@yahoo.com> wrote:
> <SNIP>
> > > The first of the above quotes seems to be in agreement with Tom Kyte's
> > > "Expert Oracle One on One" book and the Oracle 8 and Oracle 10g R2
> > > Concepts manual. The second of the above quotes (from another book by
> > > Tom Kyte) seems to be in agreement with the article written by Svend
> > > Jensen on Jonathan Lewis's website.
>
> > > It makes one wonder... is there a correct answer?
>
> > Yes, and it is actually quite simple. There doesn't have to be
> > separate _mechanisms_ for the pools. The _behavior_ of the pools is
> > influenced by the type of access of the objects in the pools. The
> > idea is to segregate the access types - if the pool is going to be
> > thrashed, put objects in recycle that thrash. This has the effect of
> > lowering thrashing in the other pools. Separating out hot and wam
> > areas is more subtle, but still, if you have too many different kinds
> > of objects for just depending on the default LRU mechanism, it
> > supposedly could help. Reread the references carefully with that in
> > mind.
>
> > jg
>
> Curiosity is a huge time sink. I wondered if there are actually
You can say that again! I barely have enough time to read this, much
less try it. I salute you! :-)
> different mechanisms for the buffering of the KEEP and RECYCLE buffer
> caches. The test below is rather long, but it seems to indicate, at
> least on Oracle 10.2.0.3 with an 8KB block size, that there is a
> difference in the caching mechanisms for the KEEP and RECYCLE buffer
> caches:
>
...
I'm not sure if I'm reading this correctly, but it looks like
sometimes the recycle is half the size of keep (like T4) and other
times it's the other way round (like T2,T3), and T1 is completely
different. I'm a bit sceptical as to whether that shows a different
mechanism, or just some other side effects, perhaps something cyclical
like every nth time either pool does something backwards, and I would
expect various interesting things to occur as the pools are filled and
concurrency effects are hit as Oracle tracks updated buffers. I do
appreciate the effort to come up with a simple reproducible test case,
I don't know if this is close but not quite there. There may be
enough variables involved to make this difficult to resolve as a
simple test. Or maybe I just missed something obvious in your demo?
To really waste some time, see the
Tuning Oracle at the Block Level; Beginners, Go Away!
download at http://www.tusc.com/oracle/download/author_niemiecr.html
(Usual disclaimers about stuff found on the internet apply, and I
don't mean to start any discussion about the author). In particular,
the part about hash bucket chains may give a clue how to follow what
is going on in those pools.
jg
--
@home.com is bogus.
"I came up to a stoplight next to a CHP, and my 4-year-old son stuck
his head out the window and said 'I smell bacon!'"
"Did he hear it?"
"Yeah, his windows were rolled down, he just smiled and waved. I was
totally embarrassed." - heard on radio call-in about things kids said
or did that they learned from their parents.
Frank van Bortel
Niall Litchfield wrote:
Unfortunately, Linux packs more and more into the kernel, making
it asking for more memory all the time - it's not 'just'
MicroSoft Windows.
- --
Regards,
Frank van Bortel
Top-posting is one way to shut me up...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFGjUCoLw8L4IAs830RAhM1AJwOB6lxyVhH/T1g0Zwa3ltEvwI83ACePDYH
HTr72SEDMJ0mrf7z8W5p+y4=
=qzRN
-----END PGP SIGNATURE-----