In the first edition of this book, we focused on what we called the "High Availability Database Administrator." However, that term led G to the question of just what is meant by High Availability? As a term bandied about among database administrators, this can have different meanings depending on who is interpreting it, who has to implement it, and who is requesting it. After all, how high is high? To many end users and management types, "High Availability" really means the same thing as "always available," period—no ifs, ands, or buts. But then reality hits, and we realize that there is a cost associated with "always available." Nothing comes for free. The more mission-critical your system, the more you are willing to invest in maintaining the uptime to achieve that goal of "always available." But even when budgets are tight (as all budgets are), you want to get the "Maximum" possible availability for your investment. So perhaps the best way to think of "High Availability" is that it is synonymous with Maximum Availability, where Maximum Availability means getting the "maximum possible" return on investment out of the resources at your disposal.

The parameters surrounding this principle are wide and complex, but the reality is simple: availability is defined, ultimately, by end users of your systems who have no notion of what HA requires, but simply expect the system to be up and available at all times. This goes well beyond the users who just want to buy books at midnight or check their 401 (k) over the weekend, and it includes all manner of mission- critical systems that are needed to support an ever-shrinking world that never sleeps and requires 24/7/365 access. That means that any true availability solution must encompass the entire technology stack, from the database, to the application server, to the network. It goes without saying that this requires the cooperation of every aspect of a company's technology staff, working together in harmony.