THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Linchi Shea

Checking out SQL Server via empirical data points

SQL Server “Always On” and Oracle HARD

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.


Published Tuesday, January 22, 2008 9:57 PM by Linchi Shea
Filed under:



joeyong said:

Good write up especially about pains with designing & monitoring SANs in a meaningful way for SQL Server or any database workload. If you haven't already, do check out HP's SANs. You can load the SAN counters into perfmon to get detailed information about what's going on down to each individual disk. I know the EVAs and XPs do this, not sure about MSA though. The good old disk queue length, sec per read/write, etc... can all be tracked to individual disks so you have some clue if your data pattern is causing hotspots - unusual for SANs but does happen.

Also, while we're on the subject of Oracle's work around storage, check out ASM and share your thoughts. I really like the concepts though the implementation is non-trivial. I know of at least a few very happy users especially with RAC deployments.

January 28, 2008 7:24 PM

Linchi Shea said:

I actually thought about writing something about ASM from a SQL Server person's perspective, but didn't want to tick off people with too many mentions of Oracle :-) ASM is pretty good if you just have a bunch of disks. If you already have a sophisticated SAN environment, it may not do anything bad, but I'm having difficult seeing a huge benefit. DB2 has something similar though to a less degree.

January 28, 2008 9:55 PM
New Comments to this post are disabled

About Linchi Shea

Checking out SQL Server via empirical data points

This Blog


Privacy Statement