Reliability -

When it comes to healthcare, the primary focus of any patient data is that the information is both available and accurate at all times. Some businesses can afford downtime, even for long periods, but when the data is patient related, the data involved could become critical or even vital. For this reason, in my experience, reliability is often the most important consideration when it comes to choosing a database solution for many healthcare applications.

There are a several ways that databases have made themselves more reliable. The first solution we will discuss will be Clustering/Mirroring.

Database Clustering involves using more than one physical, or virtual, computer systems that have access to the exact same data files. That is both machines are pointing to the same physical storage device when saving or retrieving information from the database. Database clusters rely on the operating system to synchronize reading and writing to the database. Database clusters can be either “Failover” or “Load Balanced”. Failover clusters use two servers, but they never process data at the same time, an inactive cluster server only springs to action if the primary server fails, this kind of database server is much cheaper to build and maintain than a Load Balanced cluster. In a Load Balanced cluster all the servers in the cluster are working with the data at all times. For these servers the traffic is constantly being split up so that no single server is being worked harder than the others. The advantage here is a database can “scale” from a small system to a very large system without a lot of rework. The disadvantage comes in cost, Load Balanced database clusters are often expensive and difficult to maintain. Clustering is not supported by all databases support for clustering usually represents a significant increase in cost over the less complex and less reliable database solutions. In Microsoft SQL 2005 Database Mirroring was introduced. It is similar to a failover cluster, but does not rely on the operating system of either machine to synchronize data operations. On a database mirror it is the Database Server itself that handles synchronization and a 3rd machine, the witness, to watch the primary server. It is the witnesses job to inform the failover server to activate and step in for the primary server.

For the scope of this discussion let us restrict the definition of reliability to simply mean that the database server can create a new connection, execute commands, respond to queries, and close the connection after completion. Within this scope a server is functional as long as they can perform all the aforementioned actions without error. We will refer to this as a server’s Availability. In this scope a server that allows only a single connection path to the client suffers from a Single Point of Failure (SPoF). That is, if that single connection goes down, for whatever reason, the database is no longer Available. The more SPoF’s a database connection has, the lower its reliability then becomes. A clustered database can have a server fail and yet keep the database connection in tact either by directing the request/command to another active server, or by activating the failover server and relaying the request.

For most databases reliability is measured as a ratio or the databases uptime divided by its lifetime. That is the amount of time the database has been functional divided by the amount of time that has transpired between its initial setup and the present time. For some industries an availability rating of 95% uptime is considered to be satisfactory, while in the world of healthcare we tend to have higher expectations of our application’s availability, often shooting for 99.95% or higher. It is for this reason that I often recommend that any database application being purchased by my employer be installed on a Database Cluster or Mirror.