If you’re reading this, you probably think, like me, that SQL Server is an awesome product. One of the great things about SQL Server is the fact that it’s super easy to start working with it: You download the installation (or connect to the Azure portal and get a VM), and after a few clicks you can create tables, load data and write Select statements.

But this is also a drawback.

Here’s a scenario:

• A company needs a database system for a new product
• A decision is made to go with SQL Server
• The product is developed quickly and easily on top of SQL Server
• It’s a big success, more features are added and lots of data is loaded
• Things start to be slow
• A consultant is brought in and fixes some of the problems
• It’s good enough, more features are added and more data is loaded
• Things are slow again
• A DBA is recruited
• He starts working in order to fix the problems, but things are really messed up and it takes a lot of time and effort
• A manager starts talking about the fact that “SQL Server doesn’t scale”
• A few discussions are made, and a decision is taken to start working with another database platform

I saw this scenario happening a few times in the past few years, and the main reason for that is frustration. People are frustrated when their processes are slow, when it’s hard to develop new features, when they don’t get help and when they don’t see an improvement in the horizon. So they start looking for other options, and there are many of them today.

Once this decision is made, it’s pretty much impossible to change it. One of the reasons for that, except for ego, is that the migration is a considerable investment, and the managers won’t want to throw this investment to the trash. In addition, a lot of times (but not always), the migration will be done after carefully learning the new platform and applying best practices, which will make the new platform work well, at least at the beginning. This is because the company is more stable now, and budgets can be invested in the migration.

The possibility to change this sometimes comes after the managers realize the weaknesses of the new chosen platform, but that can take a while.

And that’s why you should be a proactive DBA!

It’s your job to make sure your company leverages SQL Server’s full potential before it starts looking at adventures with other database platforms. By being proactive and spotting problems when they are small and before frustration starts to spread across the organization, you can save your organization a lot of time and money, keep SQL Server as the main database platform of the organization, and save you the hassle of learning how to work with a new database platform, or worse, finding a new job.

* To be balanced, SQL Server doesn’t fit every scenario. There are shops that use more than one database technology side-by-side, for example – crunching things in Hadoop and then spilling the output to SQL Server. Your job here is to know what data and processes fit SQL Server and what should be put in the other platform.

So What Does Proactive Mean?

Here’s 10 things you can do for a start:

• Get to know your system and your workload. Over time, you’ll get a feeling of the normal state and when things are not normal
• Collect performance data, identify problematic areas and solve the issues, even if no one complains about the problem
• Setup an alerting system that will tell you when something’s wrong with your production system
• Be updated about the latest SQL Server features and releases so you can offer them to people who talk about problems they face
• Educate your users and developers about T-SQL best practices
• Don’t overlook problems just because they’re hard to solve or because the code is horrible
• Talk to your users, developers and managers – ask them what bothers them
• Work with your developers and help them instead of just saying “No”
• If you identify a general degradation in your system, don’t wait for it to be a big problem. Raise a flag and ask for help. That help can be more hardware, consulting time, your time in order to address the issue, another DBA that will help you, and so on..
• From time to time, share what you do with your manager and peers. Let them know you’re on top of things and not just playing Solitaire all day

If you show your managers that things are under control, it will be harder for them to declare that “SQL Server doesn’t scale” and go on a hunt for a new platform.

The post The Real Reason You Should Be a Proactive DBA appeared first on .