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

From: Jorgensen, Finn:(BSC) <"Jorgensen,>
Date: Wed, 17 Dec 2014 17:51:03 +0000
Message-ID: <6837D1E9EB637E41AF54220483D53D37754CA19C_at_exchm-omf-23.exelonds.com>



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_at_soocs.de] 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: _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
>

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 i0zX+n{+i^ Received on Wed Dec 17 2014 - 18:51:03 CET

Original text of this message