SQL Server high-availability common problem analysis _mssql

Every time you talk about the high availability of SQL Server, a lot of DBAs, especially SQL Server DBA, have a pain in their head: Because everyone thinks that SQL Server cannot or will be difficult to implement SQL Server. There are also a lot of DBA friends head a beat, give the answer "high availability is not Microsoft's those several technologies, such as replication, Failover clustering" ...

1. Does SQL Server seem so powerless on top of high availability?
Answer: No, actually SQL Server is very power.

2. Why do many people always complain that high availability in SQL Server is difficult to achieve?
Here, in a few ways.
First of all, there are many projects (mostly in Europe and America) that have been contacted, many of these projects are called massive data, there are a lot of high-performance applications, followed by SQL Server, and there is no Third-party database support software.

Secondly, we talk about the human problem. People have such a habit: every time there is a problem, the first reaction is to escape, and then find a good reason or scapegoat, and finally get it, began to blame technology itself. This is a bit similar, rookie with a knife when, kill not dead, not expensive own ability, but strange knives bad. Here, think of the previous csdn password leak problem, many people actually scold Microsoft technology not, this let those who already use Microsoft technology to achieve high security application of the company to see jokes.

Again, the concept of sweeping! Many people think that replication is highly available, so the hope of a brain replication can solve their problems, but: replication only to achieve high availability of an important component, but not all. Here, I think of a few similar misunderstandings, "think jquery is Ajax technology", but jquery is just a framework that can be used to achieve Ajax. Some people think that "architecture design is the use of design patterns and architectural patterns", in fact, architecture design is a kind of thinking, and those models are only a small means, the architectural design analogy to a building, those patterns are at best some bricks, not all.
Similarly, replication is only a "piece of bricks" for high availability.

Finally, the mastery of the technology is not enough, resulting in many people encounter problems can not be solved. And also do not know who to find solutions, where to find and so on.

3. Can high availability be done with a software or product?
A lot of people here think of Oracle's RAC, and some third-party products. Different products, the degree of encapsulation is not the same, and some products have a lot of things are encapsulated, just use the staff to learn how to use the tool OK, do not have to grasp the details. However, the use of these products, in the deployment and operation, is actually in accordance with the idea of the product designer to build high availability, but we think that the process is the "use of the manual."

SQL Server itself does not provide such a fully packaged product, but the important core technologies and components that are needed in the highly available design are already there, "nails, screws, materials", and see how you assemble them.
The same cooking materials and tools, a good cook is made of delicious food, and the average chef just cooked the dishes.

4. Is high availability just a database technology?
Implementation of high availability, not just the database level above the content, in fact, more need is the design and architectural capabilities. Need to know, software, hardware, operating system, network, database and other technologies.

and high availability is not a specific technology, but a concept, the realization of the method is thousands. Some people say "high availability is read and write separation", "high availability is load balancing", right? You can answer these questions with your toes.

5. No omnipotent products and omnipotent solutions, everything is "depends on the situation"
Many people are arguing that "no shared disk (database)" Is good, "split horizontally". These are straightforward: there is no point in a separate discussion. Technology is not used in the specific application, does not bring economic value, technical nothing.

Products, technology and so on themselves have a certain range of use and limitations, many community friends in the discussion, always like a universal product characteristics, for example, some people say "SQL Server 2012 AlwaysOn" can achieve high availability. Do not know: technology is a person in use, the product is only one of our people in the design of the use of a part, the final design or look at people. As early as more than 10 years ago, there were a lot of companies with large applications that were done with SQL 2000, and SQL Server didn't have so many features and components.