Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Apple RAID marketing?

Re: Apple RAID marketing?

From: Paul Drake <>
Date: Wed, 07 Jan 2004 12:09:46 -0800
Message-ID: <>

210 Mbps? a single 4 year old SCSI-3 (U2W) drive can beat that.

Caution: TLAs abound.

GigE - Gigabit Ethernet
FC - Fibrechannel
FC HBA - FibreChannel Host Bus Adapter

SAN - Storage Area Network
DAS - Direct Attached Storage
NAS - Network Attached Storage

GigE = 1 Gigabit per second
FC = 1 Gigabit per second (also available in 2 Gbps)

Trunking across multiple ports is used to increase throughput and/or increase availability.

when it comes to moving bits across a network, its Mbps or Gbps, whether that data is moving over GigE or FC.

when it comes to moving blocks of data around a SAN or over DAS (direct attached storage) the unit of measurement is MBps.

Big 'B' little 'b', b B bee.

The order of magnitude difference between bits 'b' and bytes 'B' is non-trivial. Oracle measures all storage amounts, e.g. db_block_size, in Bytes. Bytes are what matters to a DBA. Bits are for Network Admins.

Typical SCSI Drives purchased 2-3 years ago were capable of 40 MB/sec sustained throughput per drive (as JBOD) (I can make a copy of a benchmark of mine available from a reference Dell PE 2650 system).

Typical SCSI drives these days are rated for Ultra 320, meaning 320 MB/sec *interface* speed (read theoretical throughput for the channel). Typical SCSI drives these are days are capable of 50-60 MB/sec sustained max throughput per physical drive.
The 160 MB/sec interface was a bottleneck when using more than 4 drives in a RAID configuration connected by a single RAID controller channel, hence manufacturers moved quickly to Ultra 320.

SCSI interfaces

SCSI-2   40 MB/sec aka UW
SCSI-3   80 MB/sec aka U2W
SCSI-3  160 MB/sec aka Ultra 160/m
SCSI-3  320 MB/sec aka Ultra 320/m

SCSI-2 was a 50 pin interface.
SCSI-3 is available in either 68 pin LVD or 80 pin hot swap interface.

Similarly, FC HBA manufacturers (SAN) are quickly moving from 1 Gbps FC HBA to 2 Gbps FC HBA to try to stay competitive with good old direct attached storage (DAS) over SCSI RAID and network attached storage (NAS) over GigE. I don't think that we'll be seeing anyone mounting oracle datafiles over iSCSI anytime soon, but it will be nice to store near-line backup sets on another server via iSCSI soon.

Ask anyone that has done battle with mounting oracle datafiles on a NetApp filer if they would consider mounting live oracle datafiles on a third-party system that has no working relationship with Oracle (meaning apple). no way.

To me, direct attached storage is still king. SANs are great for high availability and clustering, but if you can get away with direct attached storage for use with Oracle database files, go for it. You don't need visualization tools, you don't introduce the complexity of the SAN fabric. If you're lucky, you can even tell the SysAdmin how you want the RAID volumes and filesystems laid out.

In my non-representatively large enough sample size of system quotes, A small SAN is still 3 times more expensive than DAS in the 1 terabyte (gross) range.

As far as apple, no production grade code release of 9i Release 2 Database Server was ever made public. The oracle server product was simply for developers to load on their shiny iBooks (no offense intended to those on the list).

The RAIDserve looks like a great solution for storing files for your iPod.


Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
Please see the official ORACLE-L FAQ:
Author: Paul Drake

Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message
to: (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Wed Jan 07 2004 - 14:09:46 CST

Original text of this message