Don't Place the Blame on SQL Server

I have never worked for Microsoft, but SQL Server has given me a lot in terms of learning, community and opportunities, all these together have helped me do a great job as a Database Administrator (DBA) for many years. Since I started working with SQL Server nearly 15 years ago, I have heard a lot of complaints about SQL Server being nowhere near as good as Oracle. Much as I would have liked to ignore these fruitless discussions, I couldn't see the point of comparing products in such a compulsive way. Is it not true that our skills are more crucial than the technology itself? — Or perhaps some people just try to find something to blame. Whatever the case, I am convinced that we, as database professionals, are compelled to make the most out of any specific database technology. 

No matter what technology we are working with, we are at the wheel — technology is just a tool — so it is not the best to blame technology on the ground of one's inefficiency.

I disagree with some database engineers who speak glowingly of SQL Server because I am cognisant that, after all, this is just one of the many hugely powerful tools available out there to manage databases. Indeed, every solution depends entirely on my expertise and experience; so technology is not in dispute, what I question is some people's attitude — and sometimes — the sneering tone of this.

So many issues arise just because of the misuse of technology — and sloppy SQL Server installations — for example, I have observed how some accidental DBAs strove to make Log Shipping function as a real HA/DR solution. Others asked me how to install SQL2000 on Windows Server 2016 — I just couldn't believe my ears! I still cannot see how it would work properly. For God's sake, If only people just made appropriate use of features, they would not come across so many unforeseen issues; at times it looks much as if they enjoyed making up issues on purpose; are you kidding me? No way!

People are to blame; technology is just a tool; use it wisely.

Talking from experience, I have to remark that Microsoft SQL Server is cleverly designed and has an easy-to-use interface that relieves you from having to know arcane syntax details to complete many jobs. So, if other database management products lack those features then it is not a Microsoft SQL Server's problem. The top priority of any software is to make our life easier and our work more productive — In this sense, SQL Server just makes that; is it not wonderful? Of course, it is!

Microsoft SQL Server provides scalable performance mostly when there is only one instance running per server, only then will it make efficient use of resources and eliminate the overhead of having various SQL instances struggling with shared memory and limited storage throughput, so the question is, Why do some people insist on having various instances per server? I can't understand it yet. Similarly, it is highly recommendable to carry out database maintenance tasks once a month at least to warrant strongly consistent data and to eke out every last ounce of performance; so why do people neglect it? And also bitterly complain when performance issues arise because of stale statistics or fragmented indexes?  Even though they request for the SQL Server minimum hardware requirements, they by far fall short of requirements resulting in unforeseen problems arising again and again, and — even worse — this part is often neglected too. 

Moreover, I have witnessed how SQL Server technology has improved dramatically since 2005. I have to admit that SQL Server 2000 was nowhere near as good; nobody can deny this fact; however, it didn't perform as poorly as previous versions such as SQL7.0 and SQL6.5. Although SQL2000, SQL7.0 and SQL6.5 were unscalable products, one as a DBA had to make wise use of them to handle poor performance issues with grace. If the DBA knows the database management system inside out then the DBA will not only harness the power of its strengths but also know how to deal with its limits; the DBA will use all the features appropriately — and not in the opposite way. Thus I'm convinced again it's all up to our expertise.

All in all, as you might have realised, the major problem is mostly about people — who poorly design and install database servers — many of them lack the knowledge and experience; so the root cause is people but the technology on its own. Again, it's unfair to place the blame on SQL Server on the grounds of one's inefficiency. But for people's misuse of technology, it would work perfectly.

The more you know SQL Server inside out, the better the performance will be. SQL Server just offers as good performance as you know it inside out. 

Thus, in the event that you are still unsatisfied with the product, remember what I mentioned before; you might be barking up the wrong tree. I hope this post helps clear some things up, and if you have some questions so please do let me know.