Storage Area Networks (SANs) 101
by Brent Ozar
When I was a database administrator, I saw the SAN as a fancy, expensive black box. Well, it is, but in this podcast I give you some insights into that black box, tell you what kinds of things to ask about when moving your databases into that box, and how to refocus your SAN concerns from raid levels towards more basic things like response times.
Links from the presentation include:
- Linchi Shea’s blog on SQL Server and storage
- Scott Lowe’s blog on storage and virtualization
- Stephen Foskett’s blog on storage
You can subscribe to our podcast feeds here:
- MP4 (Apple) Video Feed
- WMV (Microsoft) Video Feed
- MP3 Audio-Only Feed
- Zune One-Click Subscribe for Video
- Zune One-Click Subscribe for MP3
Tags: san, storage area networks
Share this post with friends
October 27th, 2008 at 11:32 am
What a great introduction to SAN for non-storage people! Nice job. I used to teach a “storage 101″ class at the Storage Decisions conference, and I realized there that we in the enterprise storage industry are steeped in jargon of our own design. Translation is desperately needed!
November 5th, 2008 at 3:03 pm
Very nice. Really enjoyed it and it answered a lot of questions for me. Thanks!
December 9th, 2008 at 1:33 pm
I enjoyed your podcast on Storage Area Networks 101. http://sqlserverpedia.com/blog/podcasts/storage-area-networks-sans-101/
I particularly liked your focus on SAN performance as it pertains to SQL Server. It has helped me focus on response times rather than the back-end disk configuration. I believe information like this is invaluable, and there is a shortage of good information like this on the web: not everyone is correlating large storage technology with database performance.
I look forward to your next presentation on SANs with a database focus.
May I suggest a future topic? I work with 1TB+ databases which includes a lot of historical information. As part of my practice, I place my aging data in filegroups on slower storage since it is not consumed as often. However, once my large DB is spread across different speed disks, I find that I cannot: 1.) perform a FULL database restore or 2.) run DBCC CHECKDB. It appears I can only get around this by checking the integrity of individual objects or restoring by file groups which may not be as desirable at times. I do not have this problem on small databases. Large DBs are a different ball game…
Please keep up the good work. Thank you for all you do.