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

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