Given that database applications are very IO intensive, it is advantageous to spread the data across multiple disk platters which allows data to be read or written faster (parallel vs. sequential processing). SAN infrastructures are ideal for doing this. Disk arrays are created on the SAN, and then the arrays are broken up into smaller segments called LUN’s (logical unit numbers) which are presented to the servers as virtual disks. If for example you have a RAID 5 array on a SAN that is divided into multiple LUNs, each LUN will be striped across all of the disks in the array, and will benefit from the parallelism of the array. Each SAN vendor has their own implementation of this which is designed to maximize the performance of the system. Generally, you can get much better performance out of the SAN than you can from a direct attached raid storage. This is because you are creating a much larger pool of resources, and then distributing the load across them. When optimizing for a database, it is advantageous to have the Log file to be on a separate volume from the database file. In a SAN environment, you would further segment the log file onto a separate data path, and preferably have the LUN on a different raid array. With some of the more modern SAN architectures, the architecture self optimizes for this and you don’t need to worry about it. With some of the more established vendors, quite a bit of planning needs to go into how to balance the workloads across the resources.