RE: Memory operations on Sun/Oracle M class servers vs T class servers
- From: "Jorgensen, Finn:(BSC)" <Finn.Jorgensen@xxxxxxxxxxxxxxxxx>
- To: Oracle List List <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 17 Dec 2014 17:51:03 +0000
Thanks to Tanel, Stefan and Mark for their replies. The explanation of what the
EXEC call covers helps a lot in understanding this issue.
I was aware of the "original" design goal of the T series servers/CPU's as I've
worked with the sucky T5220/T5240's for far too long. However, my impression
from the server group at my company was that the T5's solved these issues. It
would appear that is not completely true. They may have gotten better at
masking and hiding the issues but they are not resolved.
What blows my mind is that a database company chooses to abandon one CPU
architecture (The SPARC processors produced by Fujitsu) in favor of something
that works worse for their core business, which is databases. You simply cannot
buy servers from Oracle anymore with SPARC CPU's in them. You can buy a Fujitsu
server with SPARC X/X+ CPU's called M10-4 which runs Solaris but nothing from
Oracle.
Thanks,
Finn
-----Original Message-----
From: Stefan Koehler [mailto:contact@xxxxxxxx]
Sent: Wednesday, December 17, 2014 5:13 AM
To: Jorgensen, Finn:(BSC)
Cc: Oracle List List
Subject: Re: Memory operations on Sun/Oracle M class servers vs T class servers
Hi Finn,
in addition to Tanel's awesome reply.
The current SCN is assigned to the cursor in the EXEC phase as well, which
results in (fixed) SGA memory access (variable kcsgscn_) for each EXEC call.
P.S.: I stumbled across this M- and T-series stuff round about one year ago as
well, while doing a database migration from Sun Solaris (SPARC) to Sun Solaris
(x86) as the production was running on T-series and the export was much much
slower. I was told (as i am not very familiar with the SUN CPU
architecture) that the T-series was not designed for single thread performance,
but for short parallel requests like a typical load with web sites.
This description is covered now by Tanel's great CPU explanation.
Best Regards
Stefan Koehler
Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: @OracleSK
> Tanel Poder <tanel@xxxxxxxxxxxxxx> hat am 17. Dezember 2014 um 03:55
> geschrieben:
>
> And reading your original email all the way to the end - depending on
> the exec plan the FETCH part may be the easy part - EXEC for example
> needs to pin the cursor, put binds in place in memory, walks through the
> execution plan "initializes" various row sources that may mean memory
> allocation (but for SELECTs, the actual plan execution and row production
> starts in FETCH)...
>
> So, can't assume that EXEC is less memory intensive than a 4 logical
> IO-doing fetch that follows it.
>
> Tanel
>
This e-mail and any attachments are confidential, may contain legal,
professional or other privileged information, and are intended solely for the
addressee. If you are not the intended recipient, do not use the information
in this e-mail in any way, delete this e-mail and notify the sender. -EXCIP
��i��0���zX���+�� n��{�+i�^
Other related posts:
