A while back, I was drafted to work on some database corruption issues, and spent a good amount of time toying with the notion of database resilience. In the process, I looked at various vendor initiatives in helping to alleviate data corruption, and bumped into a SQL Server program called Always On that specifies the storage I/O requirements for its storage solution partners and an Oracle program called Hardware Assisted Resilient Data (HARD) initiative.
I’m not here to compare the two programs. So I won’t get into their details. If you are interested, you can read more at the above two links, or simply do a Google search on “SQL Server Always On” and “Oracle HARD”.
What intrigued me was the level of integration between DBMS and storage solutions that the Oracle HARD initiative would require.
If you work with modern complex storage solutions such as Storage Area Networks (SAN), no matter what your experience may be, you most likely have been frustrated by the lack of integration between SQL Server and the underlying storage solutions, especially high-end storage solutions. Yes, you can talk about architecting storage to meet the SQL Server workload requirements, and there are tons of whitepapers and best practice guidelines—written by Microsoft and storage solution vendors—on how to best utilize storage for SQL Server performance.
But when you suspect something is going on soewhere along the storage I/O path and want to find out exactly what’s going on, your visibility beyond the server is either very limited or none at all. The storage solution for your database is supposed to be a team effort among the database folks, the server folks, and the storage folks. But when things happen, you may find that you are not getting much from your server or storage counterparts, or not much in a timely fashion. This is not an indictment of your server teams or storage teams. It's just the nature of having too many people or too many groups involved.
It's not that there is a lack of information. Information is there. Take SAN performance as an example. Storage vendors have tools to expose the performance data of their storage arrays. For instance, EMC has a ControlCenter Performance Manager that collects, correlates, and presents a comprehensive set of performance information regarding host, storage area network, and disk arrays. But that invaluable information is not often readily available to the database folks.
What is needed is tighter integration between databases and storage solutions so that the database folks can get to the storage management information directly in the context of managing databases.
Now, I’m not suggesting that the Oracle HARD initiative offers such integration. Its focus is on addressing data corruption, not storage management ro ease of use for the database professionals. But I applaud Oracle’s effort to engage storage solution vendors in addressing that data corruption issue.
I hope Microsoft can take advantage of the huge opportunity in this area to provide much better integration between SQL Server and major storage solutions than that between Oracle and the storage vendors, the kind of integration that not only addresses the data corruption issue but also significantly improves the ease of use in managing SQL Server storage. This, I believe, is a truly value-added proposition.