Re: Re: Memory operations on Sun/Oracle M class servers vs T class servers

some years ago I discovered an issue on Solaris where the CPU ws slowed down by MMON. We did a similar test observing the performance of select from dual in a loop. The work around was shutting down automatic memory management. Thus for me it looks clearly like you have an issue here and it looks familiar.

As for the CPU architecture I think your argument about the cores sharing a infrastructure makes sense. I could work with IBM P7 recently. The acrchicture of the P7 is compareable in the sense that ist is also trying to squeeze more out of the core by adding threads. Actually for demanding loads as highperforming databases the idea will not work out. IBM here suggests to switch off some core for more power on the database load (TurboCore: http://www.ibmsystemsmag.com/power/trends/ibmannouncements/power7_unveiled/TurboCore,-Active-Memory-Expansion-and-More/). Unforntunately it seems the trend is in favour of more threads, as the P8 shows.

Regards

Lothar

----Ursprüngliche Nachricht----
Von : contact_at_soocs.de
Datum : 17/12/2014 - 11:12 (GMT)
An : Finn.Jorgensen_at_constellation.com Cc : oracle-l_at_freelists.org
Betreff : 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: _at_OracleSK

> Tanel Poder <tanel_at_tanelpoder.com> 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
>

--
http://www.freelists.org/webpage/oracle-l



--
http://www.freelists.org/webpage/oracle-l