In the good old days most DBA’s could walk into their computing center and point to their database server and its disks. Furthermore, many DBA’s could also point to specific disks and state which database objects they housed. In fact database object placement and separation was a key tuning consideration back in the day. Oh my how times have changed.


At first all database servers utilized direct attached storage devices (i.e. DASD). In many cases the database server had limits as to the number of DASD it could support. Thus a big database often required a big server. So there was a direct one-to-one correlation between database size and server size.


Then along came Storage Area Networks (i.e. SAN). Think of a SAN as a storage server designed to house many disks and connected back to the database server via expensive, high speed fiber channels. Smaller databases tended to remain on DASD, while larger ones often got a dedicated SAN. Then as SAN technology improved, small to medium databases started sharing a SAN.


Not too long after the SAN along came the Network Attached Storage (i.e. NAS). Think of a NAS as a storage server designed to house many disks and connected back to the database server via inexpensive and common Ethernet. At first Ethernet speeds of 100Mbit restricted NAS usage to primarily smaller and less critical databases. However as Ethernet speeds reached 1Gbit and now 10Gbit, NAS has become a viable choice for most databases storage needs.


Finally both SAN and NAS evolved, adding some new and interesting wrinkles such as Fiber Channel over Ethernet (i.e. FCoE) and Internet Small Computer System Interface (i.e. iSCSI). But essentially SAN and NAS device architectures have remained the same. Just the connection methods were modernized. So the basic architectural diagrams did not really change.


In either of these storage scenarios (i.e. SAN and NAS), the DBA generally lost all touch with database object to disk mappings. At first when the SAN or NAS device was generally for but one database, some DBA’s may have performed or assisted with the Logical Unit (i.e. LUN) design. But as these storage devices became shared, often the DBA was simply assigned a black box of space for the DBA specified size requirements.


So let’s assume that the DBA requested 80GB of disk space for the database and the storage administrator created four 20GB LUN’s for that request. There are many reasons why the storage administrator might have created for LUN’s rather than one. It might be that the LUN’s are on different SAN and/or NAs devices. It’s also quite possible that storage administrator simply wanted to provide more one LUN so that the DBA could perform some logical separation of database objects.



Figure 1: Database Storage Design


Thus the DBA might design the database storage as shown above in Figure 1. Basically the DBA thinks he has four disk drives (i.e. the four LUN’s) and lays things out accordingly. But he doesn’t know where the spindles are or how may he may be striped across due to this basic storage abstraction. And as Figure 1 shows, the DBA may introduce further abstractions by using a Logical Vole Manager (i.e. LVM) or Oracle’s Automated Storage manager (i.e. ASM). Furthermore the use of database logical containers and constructs such as table spaces and partitions adds yet additional level of abstractions. But it now gets even worse as shown below in Figure 2.



Figure 2: Virtualized Storage Architecture


With storage virtualization, the storage administrator can now manage space across storage devices in a manner much like a LVM. Thus the physical LUN’s are aggregated into a centralized and shared “Storage Pool”. Now he can create and assign logical LUN’s for the DBA’s need. Of course that means yet another level of abstraction and thus removal from knowing where your disks are.


Thus we need to realize and acknowledge two key points. First, we essentially virtualized (i.e. abstracted) storage a very long time ago with the concept of the LUN. And second, the virtualization craze is simply adding yet another layer of abstraction or removal from your disks. You now have logical LUN’s.


So forget about ever really knowing where your disks are and how your database objects are laid out across them. You’ll need a time machine if you really must know. I’d say just forget it – there are bigger fish to fry.