Whitepaper : Why Your AlwaysOn Solution is Not Always On
- Quorum Configuration
- Non-voting Nodes
- Dynamic Weighting
- Non-AG Member Cluster Nodes
- Multi-subnet Failover
Microsoft markets a variety of SQL Server availability technologies under the umbrella term Always On. Always On is a broad term that covers many features including things as simple as online index rebuilds and automatic page repair. The two main Always On features are Availability Groups (AGs) and Failover Cluster Instances (FCIs). The name Always On, however, is somewhat misleading. The term is a marketing term, and like many marketing terms, it is an overstatement of what to expect from the group of technologies. These features help to achieve a certain level of high availability, but 100% uptime is not a realistic expectation. Additionally, it is not merely up to the feature to remain online. It requires an effort to make it useful. Achieving high availability with Availability Groups or Failover Clustering requires proper planning, proper hardware, and an appropriate understanding of the technology.
This whitepaper describes how to avoid pitfalls that can cause unexpected failures with Always On technologies. The whitepaper delves into three issues that can cause Always On solutions to not be always on. These are three common scenarios that many database administrators do not even consider when planning to deploy an Always On solution. These issues are generally not recognized until problems arise from them. With careful planning and preparation, be proactive and prevent these issues from taking solutions offline.
Presenter: Robert L. Davis
Robert L. Davis was a senior database administrator and technical lead at Microsoft. He was a speaker and a trainer as well as a writer for SQL Server Magazine.
Register to read the full whitepaper.
Topics : Database Diagnostics,Database Monitoring,Database Performance,
Products : SQL Diagnostic Manager for SQL Server,