Skip to main content

Slow SQL Server : What we should NOT do

 Try to list the best practices of SQL Server. It will require a heck of a time.

Try to list the Bad Practices and it will require more than the best practice list, of course, probably you’ll end up getting frustrated. (seeing all the oops configurations and its effect on SQL Server)

Figure: Bad practices can make your SQL Server go Slow.

Let me try and list some of the common bad practices before getting frustrated.

  1. Using SELECT *
    1. When you don't need al the columns and
    2. When there are fewer columns and you need all of them. You may be wondering What's wrong in selecting all columns if I have only 2/3 columns? See Why not use Select * in SQL Server for more details.
  2. Keeping the MaxDop Settings as default (0). See Maxdop and Cost theshold for parallelism SQL Server to get the optimum maxdop settings for your server.
    1. What if you use default maxdop? Your DB requests are going to use as many processors it needs or thinks it needs for better execution ending up eating up your resources for other requests.
    2. You are probably going to face Threadpool - A deadly poison wait for SQL Server (The What, When and How) . It's deadly because you’ll feel like your server is frozen solid but you cant see memory or CPU pressure in the server!
  3. MDF, LDF, tempdb initial size and autogrowth at default : By default SQL Server gives you a 8MB of autogrowth. Imagine What Can happen When you are facing heavy data flow in the server and the mdf, ldf and tempdb files need more space, so they request Server PC to call an autogrowth event and till then your requests are suspended until server allocates your SQL Server with more space. You’ll see more of preemptive wait types. See How to deal with SQL Server Autogrowth - The Smart Way
  4. SQL Server files are not excluded in Antivirus Scan: This is very scary.
    1. We were once preparing for Database Stress test heavy read-write operations. Just before we were going to start the test, we found that all our SQL Files (mdf,ldf) was going through read writes. (we were inspecting performance monitor of Windows server). The culprit process was sfc.exe and we understood it’s our Antivirus Program.

The list can grow very long, just one piece of advice, don't just go blindly with SQL Server default Configurations, understand your system and your needs properly before setting up your SQL Server. Think like the SQL Server engine and that will help you relieve its pain!

Labels:

Comments

Post a Comment

Most Loved Posts

How to configure your Availability Group listener to ASP.NET

SQL Server’s availability group Always On feature is great to have features for your Database. Anytime one of your database nodes goes down, your secondary replica will automatically take over. After a failover, your secondary cluster node becomes the primary cluster. Now the question arises, “Do I need to configure my APP server connectionstring each time I face a failover cluster?”. The answer is NO, you don’t have to configure your app server connectionstring every time. Default ConnectionString By default, your App server connectionstring looks something like this – <connectionStrings>    <add name="ConnStringDb1" connectionString="Data Source=localhost;Initial Catalog=YourDataBaseName;Integrated Security=True;" providerName="System.Data.SqlClient" />   </connectionStrings> ConnectionString for Failover Partner You can manually specify the failover partner in your connectionstring like this <connectionStrings>     <a...
Post a Comment
Read more

Threadpool - A deadly poison wait for SQL Server (The What, When and How)

Introduction  Threadpool is a  poison  wait. Yes, I mean it. Its poison for SQL Server, its poison for the Business and of course, the end-users! The most devastating thing about threadpool is you hardly recognize it because it comes in disguise, meaning you see no memory or cpu pressure in the system, yet you cannot run any query, it seems like your SQL Server is frozen solid. That scary, isn't it?
2 comments
Read more

SQL Insider 01 : An Anatomy of SELECT

Introduction When we write queries, we tend to think about the internals very little. In the new series of SQL Insider, I shall try to demonstrate what your SQL Server has to go through when you write a specific query, more specifically a specific operator. In the series, we shall try to cover all the important operators in SQL. Our today's SQL participant in SELECT. SELECT  With the SELECT query, we can select one, some, or all the columns of a SQL table. The typical syntax for SELECT is like this  SELECT * FROM Sales.SalesOrderDetail SELECT sod.OrderQty, sod.UnitPrice FROM Sales.SalesOrderDetail sod Please note that we will not be dealing with WHERE clause in today's episode.  Database We will be using AdventureWorks2019 Database for the demonstration Important Configuration We will be setting STATISTICS IO ON like this - SET STATISTICS IO ON; SET STATISTICS IO ON ; We will turn on Actual Execution Plan to examine the query SQL Insider Let's sta...
Post a Comment
Read more