Re: [OT] HOWTO's of messing up Linux cluster?

Like some other people said, I'd highly recommend looking at the optimizer plans for those reports. The interconnect is another place where we see our customers that have tried to deploy RAC on their own have problems -- they use 100mbit or Gigabit through a slow switch, etc.

The other question - could the methodology be flawed? As an example, I was once handling a datacenter migration for my employer and we had just built a brand-new database cluster at the new site. I turned it over to the DBAs to do their production testing on, and an hour later they came running back claiming the new cluster was 3x SLOWER than the old one, despite being twice as large and twice the cpu speed. After some troubleshooting that showed nothing, I asked them to show me what they were running. They were running a report on both database clusters that spooled all of the output to the screen - except the current "faster" database cluster was located in the office on the LAN and the new "slower" database cluster was connected to the office over a high-latency VPN link. When they spooled the report output to disk instead of screen, the new cluster was 4x faster. Make sure the testing scenarios are apples/apples.

Also, if you could let us know if you find the problem, I'd be interested to know.

Thanks,
Matt

--
Matthew Zito
GridApp Systems
Email: mzito_at_gridapp.com
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com


On Nov 20, 2004, at 6:30 PM, Branimir Petrovic wrote:



> Situation:

>    Early stages of development project; same small database runs on

>    development PCs, early build is given to customer for "look and

>    feel" and training purposes.

>

> Sad facts:

>    "PC Vulgaris" (P4 @ 2.8 GHz with _one_ IDE drive running WinXP)

>    /w Oracle 9.2 db outperforms by factor of FIVE (meaning exact same

>    batch jobs run at least 5 TIMES FASTER!!!???) two node Oracle 9.2

>    cluster on Linux (RH AS3). Beats it by huge margin it every single

>    time.

>

>    Hardware at customer's site is 6 month old (implying relatively

>    new hardware) 2 P4-Xeon CPUs server forming two node Oracle 9.2

>    cluster connected to dedicated (this cluster only, dedicated

>    to this project only) SAN (with unknown number of drives).

>

> Question:

>    If you were really incompetent SA/DBA what would be easy ways

>    to duplicate the above requirement? (achieve five times

>    worse performance using much "stronger" hardware)

>

> From whatever little I know of ways problematic database is set

> up and configured, I'd say it is not the Oracle that is messed up,

> but the underlying OS.

>

> Being at arms length from the problem (due to mountains of political

> bs. - "us" vs. "them"), and quite frankly due to my own shortcomings

> with Unix/Linux, I am in no position to help in any meaningful way.

> Still curiosity factor is strong - what could possibly be so wrong

> with this RAC?

>

> Wild guesses - welcomed :-)

>

> Branimir

> --

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


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