From oracle-l-bounce@freelists.org Thu Sep 15 16:46:58 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j8FLkwCk018834 for ; Thu, 15 Sep 2005 16:46:58 -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 j8FLks6H018821 for ; Thu, 15 Sep 2005 16:46:55 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 001881EC42D; Thu, 15 Sep 2005 16:46:48 -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 30983-05; Thu, 15 Sep 2005 16:46:48 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7A9711EC71B; Thu, 15 Sep 2005 16:46:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: I/O tuning... Allocating spindles to databases MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Ecartis Date: Thu, 15 Sep 2005 14:44:56 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I/O tuning... Allocating spindles to databases Thread-Index: AcW6OXtQrQcj2A3sQeCGVEr7pOXP9gABIjfA From: "Kevin Closson" To: X-archive-position: 25557 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: kevinc@polyserve.com Precedence: normal Reply-To: kevinc@polyserve.com 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=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 >>>Even if such access patterns are less than likely, it's >>>still important to know how storage responds in worst case >>>scenarios. Cache on the SAN/NAS is not a bad thing. I >>>can't think of a situation where it would *degrade* >>>performance merely by its presence. I've done a lot of benchmarking on systems configured with over 1000 disk drives and believe me, caching data that will never be revisted does not boost performance. Think FTS. I have used arrays that allow you to completely disable cache and doing so on the tables that sustain scans was often a performance boost. Mileage varies. >>>We've had a NetApp with rather fast disk and huge cache. >>>Burst performance indeed can be good. But, the thing has >>>effectively single gigabit fiber backbone and a single and >>>heavily burdened storage processor that renders it incapable >>>of sustaining more than maybe sixty (60) megabytes/sec That is because it is a single headed NAS. You need to see HP's story with the Enterprise File Server Clustered Gateway. Supports 16 active:active heads with no SPOF. ftp://ftp.compaq.com/pub/products/storageworks/efs/4AA0-0283ENW.pdf Besides, it's OEMed PolyServe :-) -- http://www.freelists.org/webpage/oracle-l