Re: Memory operations on Sun/Oracle M class servers vs T class servers
- From: Stefan Koehler <contact@xxxxxxxx>
- To: Finn.Jorgensen@xxxxxxxxxxxxxxxxx
- Date: Wed, 17 Dec 2014 11:12:50 +0100 (CET)
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
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
