From oracle-l-bounce@freelists.org Thu Sep 22 10:46:54 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j8MFksCb028399 for ; Thu, 22 Sep 2005 10:46:54 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j8MFkl6H028375 for ; Thu, 22 Sep 2005 10:46:48 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id DE5FB1ED7C5; Thu, 22 Sep 2005 10:46:33 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13265-05; Thu, 22 Sep 2005 10:46:33 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 558381ED3E2; Thu, 22 Sep 2005 10:46:33 -0500 (EST) From: "Eric Buddelmeijer" To: , Cc: "'Oracle-L'" Subject: RE: Hard Disk selections Date: Thu, 22 Sep 2005 17:44:37 +0200 Organization: Elegant Application Services MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B4_01C5BF9D.4D1E4FD0" In-Reply-To: <910046b405092208203abc9b14@mail.gmail.com> Thread-Index: AcW/iLj9KLO44R/lQ8WTQ98b/dsKvgAAyniA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Message-Id: <20050922154438.F097C13FF8@coral.qinip.net> X-archive-position: 25801 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: Eric.Buddelmeijer@elegant.nl Precedence: normal Reply-To: Eric.Buddelmeijer@elegant.nl X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-mailscan-MailScanner-Information: Please contact the ISP for more information X-mailscan-MailScanner: Found to be clean X-MailScanner-From: oracle-l-bounce@freelists.org X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63 ------=_NextPart_000_00B4_01C5BF9D.4D1E4FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ Van: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] Namens Paul Drake Verzonden: donderdag 22 september 2005 17:20 Aan: bunjibry@gmail.com CC: Oracle-L Onderwerp: Re: Hard Disk selections Bryan, It depends. What you have going for you is: CPU bogomips (500 MHz to likely 3.4 GHz) Memory bandwidth (100 MHz FSB to 800 MHz effective) Newer disks tend to have faster interfaces, larger cache, higher RPMs and shorter seek times. The SAN will likely have some form of cache. >This triggered me. We had some issues with a SAN cache not being configured at all. Result was the throughput became >lousy although the disks were fast enough. What I learned from it is that you have to check if this is configured correctly >before looking at your database. If you're only loading up data into the buffer cache at instance startup and only writing to disk for redo, controlfile and archived redo logs, you may not notice the fewer disks. If you find that the CBO wants to do all table scans, you're in trouble. The only way to know for sure is to test. Get as much memory in the box as your budget allows and only use half of it. Use w2k advanced server instead of w2k server, as it has the /PAE and /3GB options. W2k3 server standard edition supports the /3GB option. hth. Paul ------=_NextPart_000_00B4_01C5BF9D.4D1E4FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Van: oracle-l-bounce@freelists.org = [mailto:oracle-l-bounce@freelists.org] Namens Paul=20 Drake
Verzonden: donderdag 22 september 2005 = 17:20
Aan:=20 bunjibry@gmail.com
CC: Oracle-L
Onderwerp: Re: = Hard Disk=20 selections

Bryan,

It depends.
What you have = going for=20 you is:

CPU bogomips (500 MHz to likely 3.4 GHz)
Memory = bandwidth=20 (100 MHz FSB to 800 MHz effective)
Newer disks tend to have faster=20 interfaces, larger cache, higher RPMs and shorter seek times.
The = SAN will=20 likely have some form of cache.

>This triggered me. We had some issues with a SAN cache = not being=20 configured at all. Result was the throughput became >lousy = although=20 the disks were fast enough. What I learned from it is that you = have to=20 check if this is configured correctly >before looking at your=20 database.

If you're only loading up data into the = buffer cache=20 at instance startup and only writing to disk for redo, controlfile and = archived redo logs, you may not notice the fewer disks.

If you = find=20 that the CBO wants to do all table scans, you're in = trouble.

The only=20 way to know for sure is to test.
Get as much memory in the box as = your=20 budget allows and only use half of it.
Use w2k advanced server = instead of=20 w2k server, as it has the /PAE and /3GB options.
W2k3 server = standard=20 edition supports the /3GB=20 option.

hth.

Paul

------=_NextPart_000_00B4_01C5BF9D.4D1E4FD0-- -- http://www.freelists.org/webpage/oracle-l