Ever hear people say they miss the good ole days – when times and things were much simpler than now? Well the same is true for Oracle DBAs, the early 90’s (circa 1993) were much simpler in terms of hardware selection for an Oracle server as summarized below.
|
CPU
Architecture
|
CPU
Family
|
Operating
System
|
Storage
Architecture
|
Disk
Architecture
|
|
RISC
|
SPARC
|
SOLARIS
|
DAS
|
ATA-2
E-IDE
16 MB/sec
|
|
PA-RISC
|
HP-UX
|
|
ALPHA
|
TRU-64
|
|
POWER-PC
|
IBM-AIX
|
SCSI-3
Wide Ultra
40 MB/sec
|
|
MIPS R4000
|
UNIX
|
|
CISC
|
System 390
|
MVS
|
|
DEC-VAX
|
VMS
|
NAS
(Fast Ethernet)
|
|
MC 68040
|
UNIX
|
|
PENTIUM-I
|
WINDOWS
|
SAN
(Fibre Channel)
|
|
AMD-486
|
WINDOWS
|
Since few people could afford an IBM mainframe (i.e. System 390), and Digital’s proprietary VAX hardware and VMS software were quickly losing favor, and PC server based technology could not yet scale for mid-to-large databases, the primary and logical choice was mid-range RISC servers running some variant of UNIX. Also, NAS was pretty much limited to NFS (which still does not scale well), and SAN was still both relatively new and expensive – direct attached storage (DAS) was pretty much the mainstay. We even still backed up to tape back then J. And although SNMP CPU’s were available, it was not uncommon to still order single processor servers for many database needs.
What this meant was the DBA’s hardware sizing job was simple – find a vendor’s server whose IO backplane accommodated the number of drives required for your database size. That was it!
Therefore Sun’s server platform (i.e. Solaris on SPARC) and Hewlett Packard’s server platform (HP-UX on PA-RISC) were pretty much “no-brainers”. In fact, I’d say I did 90+% of my Oracle DBA work back then on just these two platforms (with a few Intel based servers running IBM-OS/2, Interactive UNIX and Novel Netware – but very few successful Windows NT 3.1 setups).
But my how times have changed …
Look at the hardware options available to the DBA’s of today.
|
CPU
Architecture
|
CPU
Family
|
Operating
System
|
Storage
Architecture
|
Disk
Architecture
|
|
|
RISC
|
SPARC
|
SOLARIS
|
DAS
|
SATA-I
150 MB/sec
|
|
SATA-II
300 MB/sec
|
|
PA-RISC
|
HP-UX
|
NAS
(GB Ethernet)
|
|
POWER-6
|
IBM-AIX
|
SCSI-320
320 MB/sec
|
|
SAN
(Fibre Channel)
|
|
CISC
|
Intel
Xeon
|
LINUX
|
|
SCSI-640
640 MB/sec
|
|
SAN
(Infini-Band)
|
|
WINDOWS
|
|
AMD
Opteron
|
Tiered
Storage
|
SAS-I
375 MB/sec
|
|
SOLARIS
|
|
iSCSI
|
SAS-II
750 MB/sec
|
While the CPU and operating system choices have simplified, the entire IO subsystem alternatives are now quite overwhelming. The only obvious choice today is that DAS is now almost universally used for just operating system and swap files. In the good old days, IDE was generally restricted to DAS. But today, it’s not uncommon to mix and match among the last two columns above. We even have newer technologies which I left off on purpose (to keep it simple) – namely solid state disks and the next generation of disk drives that will incorporate small amounts of flash space.
Now add to that the many disk storage array vendors, the disk vendors, the various RAID levels, stripe size considerations, LUN configuration, plus the complexities of the mixed disk architectures and the various combinations of these choices – and you’ll see that a DBA today needs to be a freaking storage guru.
And since we all know from DBA 101 that IO is the most expensive operation, we cannot afford to make bad choices on the now overly complex IO subsystem alternatives. I think it’s time to find a new and much simpler career – like medical doctor J