Checking for the “Default” username

You can check for the presence of this login by running the query below. If found, a full network audit is recommended.

--Verify the default account doesn't exist.  No results is a good thing.
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
WHERE [name] = 'Default'

What if you already had a login named “Default”? Determine if the password was recently changed to “@fg125kjnhn987” and if there have been any recent login failures. Review for any recently created logins as well. Are all logins accounted for? Were any created that you were not aware of? If so, review each further to determine what permissions they have and identify what they’re being used for.

--Review recently created logins
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
ORDER BY create_date desc

Review recently modified logins.

--Review recently modified logins
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
ORDER BY modify_date desc

Avoid making your SQL Servers easy targets

By utilizing security best practices, most brute-force attacks can be stopped. Or, at the very least, set off alarm bells and whistles to alert you of suspicious activity. Below is a list of do’s and don’ts we typically recommend. This is not an exhaustive list.

Don’t

1. Don’t expose your SQL Servers to the internet (if at all possible). Use a VPN to access externally.
2. Don’t use weak passwords (for any account).
3. Don’t add your SQL Server service accounts to the local admin group.
4. Don’t grant your SQL Server service accounts more permissions than required.
5. Don’t grant logins more permissions than required.
6. Don’t install additional services which are not required. SQL Server licenses include not only the database engine, but integration services, analysis services, and reporting services as well (at the time of this post). It’s easy enough to go ahead and install these additional services but also increases the attack surface area. Only install what is required.
7. Don’t enable additional options, within SQL Server, if unneeded. For example, xp_cmdshell, Ole Automation Procedures, and ad hoc distributed queries.

Do

1. Patch often. Review latest cumulative update, service pack releases, and hotfixes. Start here.
2. Implement a policy in which an account will become locked out after X number of attempts.
3. Change passwords often.
4. Audit the creation of new logins (and review the audits often 😉).
5. Disable the SA account. This account is well known and has unfettered access.
6. If not required, don’t use SQL Server authentication.
7. Review failed login attempts. Especially those occurring numerous times within a short span of time. This could be an indication of a brute-force attempt.
8. Implement a process to audit using guidelines such as the US government Security Technical Implementation Guides (STIGs) or Center for Internet Security (more on these below).
9. Review the health and performance metrics of your SQL Servers regularly.
10. Proactively monitor your SQL Servers to look for unexpected deviations of resource consumption.

Audit your environment

These types of exploits can typically be avoided. Implementing good security practices can be a painful process (not only from a technical perspective but also from the staff and end user perspective). The following guides provide a large set of information and scripts to get you started with securing your environment.

CIS – Center for Internet Security

CIS Benchmarks are consensus-developed secure configuration guidelines for hardening. There are benchmarks for operating systems, server software, cloud providers, network devices etc. Take a look here for a list of what they have to offer. SQL Server specific benchmarks can be found at https://www.cisecurity.org/benchmark/microsoft_sql_server/. There are some aspects of the site which requires membership but includes additional tools. Well worth the consideration.

National Vulnerability Database

The NCP is the U.S. government repository of publicly available security checklists which provide guidance on setting the security configuration of operating systems and applications. The checklists (STIG) can be downloaded as a zip. To view, download and install the STIG Viewer from https://public.cyber.mil/stigs/srg-stig-tools/ and follow the instructions.

How we can help

Security is constantly evolving. Setting up good policies around platform hardening, password complexity and rotation, and using accounts with the least privilege required is a daunting task for any organization. Especially those without dedicated security or database administrators. I’m hopeful a few of the resources above can get you started on the right path. We’re here to help as well. If you’d like assistance in assessing your SQL Servers, schedule a call with us here.

Thanks for reading!

The post Am I affected by MrbMiner malware? appeared first on The SERO Group.

Guardicore has released a PowerShell script that examines servers to determine if they’ve been infected. We’ve safely run the scripts on SQL Servers in our lab environment and for many of our clients.

If you routinely apply regular updates to your servers, practice the Principle of Least Privilege, regularly change critical passwords, have stringent password complexity requirements, and don’t expose your SQL Servers directly to the internet, the likelihood of a brute force attack succeeding is greatly reduced.

Here are six scripts that can help determine your level of potential exposure.

Who Has sysadmin or serveradmin Privileges?

The Vollgar attack is a brute force attack that attempts to guess the password for SQL Logins with elevated privileges. To be successful it needs logins that can execute sp_configure to change server-level settings. This are implicitly held by the sysadmin and serveradmin fixed server roles.

So, the first step in determining your exposure to Vollgar is to discover the members of the sysadmin and serveradmin roles. The following script will show you the members of each role.

USE master; 
GO

EXEC sp_helpsrvrolemember
	'sysadmin';

EXEC sp_helpsrvrolemember
	'serveradmin';

In my sample database, the following is returned.

Another approach to retrieving the same information in one consolidated result set is to use the following script.

--list of logins that are members of the sysadmin or serveradmin roles
SELECT SP1.[name] AS 'Login',
	SP2.[name] AS 'ServerRole'
FROM sys.server_principals AS SP1
	JOIN sys.server_role_members AS SRM 
		ON SP1.principal_id = SRM.member_principal_id
	JOIN sys.server_principals AS SP2 
		ON SRM.role_principal_id = SP2.principal_id
WHERE SP2.[name] IN ('sysadmin', 'serveradmin')
ORDER BY SP2.[name],
	 SP1.[name];

As expected, this script produces the same results.

Of course, it’s best practice to only grant the minimum rights required by each login, a practice known as least privilege. If these queries return more logins than absolutely necessary, it’s time to review your security practices.

Who has Passwords that Do Not Expire and without Password Complexity Requirements?

Having a complex password and changing it regularly is part of the basic blocking and tackling of security. Passwords like “Password123”, “Qwerty”, and “Puddles!” can be cracked in very short order using tools freely available on the web. And if these passwords never expire, users have no reason to change them regularly, making them even more of a liability.

For Windows Integrated Authentication, password complexity and expiration is handled at the network domain level. For SQL logins, these are enforced inside of SQL Server.

To find active SQL logins (e.g. not disabled) that do not require a basic level of complexity and are set to not expired, run the following script.

--Active SQL Logins where passwords do not expire
--and do not have complexity requirements 
SELECT name, 
	type_desc, 
	create_date, 
	modify_date, 
	default_database_name
FROM sys.sql_logins
WHERE is_expiration_checked = 0
	 AND is_disabled = 0 
	 AND is_policy_checked = 0 ; 

In my sample system, the script produces the following list.

Regularly changing passwords creates a moving target for potential attackers. If you have SQL logins that do not expire and do not have minimum complexity requirements, consider turning these features on for all your logins.

Putting some of the above queries together will give us a list of all active SQL logins that are members of the sysadmin or serveradmin fixed server roles along with whether their logins adhere to password complexity and expiration policies.

--list of SQL logins that are members of the sysadmin or serveradmin roles
SELECT SP1.[name] AS 'Login',
	SP2.[name] AS 'ServerRole',
	CASE l.is_disabled WHEN 1 THEN 'No' ELSE 'Yes' END AS Is_Enabled,
	CASE l.is_expiration_checked WHEN 1 THEN 'Yes' ELSE 'No' End AS Pwd_Expires,
	CASE l.is_policy_checked WHEN 1 THEN 'Yes' ELSE 'No' END AS Pwd_Complexity_Reqs
FROM sys.server_principals AS SP1
	JOIN sys.server_role_members AS SRM
	ON SP1.principal_id = SRM.member_principal_id
	JOIN sys.server_principals AS SP2
	ON SRM.role_principal_id = SP2.principal_id
	JOIN sys.sql_logins AS l
	ON l.principal_id = SRM.member_principal_id
WHERE SP2.[name] IN ('sysadmin', 'serveradmin')
ORDER BY SP2.[name],
	 SP1.[name];

The following results are returned on my test system.

When was a SQL Login Password Changed?

From the prior two queries, we can see that Alice and Donnie are both active members of the sysadmin fixed server role. Donnie’s password doesn’t expire and doesn’t have to meet any password complexity requirements. Of course, this is a big red flag for security. Alice’s login, on the other hand, is set to adhere to complexity and expiration requirements. That’s good.

But how long has it been since Alice actually changed her password? We can use the LOGINPROPERTY() function to help us. Note: that for the function to return meaningful information, both CHECK_POLICY and CHECK_EXPIRATION must be enabled for the login.

--when was a login's password last changed?
SELECT 'Alice' AS username,
	LOGINPROPERTY('Alice', 'PasswordLastSetTime') AS PasswordLastSetTime;

In this case, we can see that Alice last set her password on March 26, 2020.

We can use other properties in the LOGINPROPERTY() function, such as BadPasswordCount and BadPasswordTime. I wouldn’t rely too heavily on the results, though. The BadPasswordCount is reset to 0 as soon as Alice successfully logs in. And, just as importantly, it’s only relevant for those SQL Logins who have CHECK_POLICY and CHECK_EXPIRATION enabled.

--bad password attempts
SELECT name, 
	LOGINPROPERTY(name, 'BadPasswordCount') AS BadPasswordCount,
	LOGINPROPERTY(name, 'BadPasswordTime') AS BadPasswordTime
FROM sys.sql_logins 
WHERE is_expiration_checked = 1
	AND is_disabled = 0 
	AND is_policy_checked = 1; 

The results from my test system are shown below.

How to See Failed Login Attempts

Assuming your SQL Server is configured to log failed login attempts, and of course it should be, you can query the error log files using the sp_readerrorlog procedure to see the failed attempts.

EXEC sp_readerrorlog 0, 1, 'Login failed' ;

The following is returned on my test system.

Better yet, use a monitoring tool to proactively monitor failed login attempts and alert when a minimum threshold is exceeded. For our DBA as a Service clients, we provide SentryOne‘s SQLSentry monitoring tool to help with this and other events that should be monitored.

Parting Thoughts

Many years ago, I set up a test system for a writing project I was involved with. As part of the test, I set the sa password to something like “Cat123Dog!” The password met most requirements of the day – upper and lower case, at least one number and one letter, and a special symbol. “Not bad,” I thought to myself.

Then I downloaded Ophcrack, a free Windows password cracker, and released it on my unsuspecting SQL Server. Expecting the utility to run for hours, if not days, I returned to work.

A few minutes later, I decided to check on it, wanting to make sure it wasn’t hung for some reason. I was stunned. Ophcrack had already found the password! That was at least 10 years ago. I’m sure the tools of the hacker trade have gotten much better since then.

Recently, I’ve read where most breaches are a result of social engineering – someone receives an e-Card from a secret admirer, finds a thumb drive in the parking lot, or clicks an email link. “The days of brute force attacks are over,” they say.

Vollgar has proven them wrong. Basic security measures are still best practice. You owe it to yourself to make sure you’re doing it well. Here are a few links that may help.

• Introduction to SQL Server Security
• Securing SQL Server
• SQL Server Security Checklist

The post Vollgar: 6 Scripts to Help Review Your SQL Servers appeared first on The SERO Group.

And the server performs well. For a while. Then it slows down and maybe even a database corrupts. You recover by restoring the prior night’s backup. You lost some data but not too much. At least, you’re running again. So, you add some memory and a couple of processors to the virtual machine in hopes that it’ll help. But you begin to wonder if your data is safe, really safe. And if it goes down, can you recover?

Unfortunately, this is a story that happens all too often.

SQL Configuration Matters

Microsoft SQL Server is a robust, well-designed database engine that performs remarkably well even when neglected. But knowing that critical information is not being actively cared for often leads to angst, especially in those who are responsible for the business.

If you have a SQL Server, you also probably have people who depend on it and the information it contains. They need SQL Server to be performant and reliable. Throwing hardware at problems can overcome a multitude of issues but at a cost – a real cost in terms of additional licenses and an emotional cost in terms of uncertainty.

The thing is: the way SQL Server is configured after it is installed can have a dramatic effect on how it performs. We’ve found that most SQL Servers are not configured with industry best practices. In fact, we find that 95% of the SQL Servers we’ve assessed depart from best practices in many areas. And that puts them at risk for poor performance or even data loss. You can download a free pdf of the most common issues we find.

So, we can you do?

Assessing Your SQL Configuration

A review of your SQL Server configuration settings is a great first step toward ensuring your SQL Server can perform well. Confirming that your SQL Servers are up to date and that the settings are consistent with industry-established best practices will give you confidence in knowing that your SQL Server has the foundation for solid execution.

There are several ways to do this.

1. Do You Own Configuration Review

Whether you have 5 or 500 SQL Servers, identify each instance in your SQL Server environment and prioritize the list based on key factors: impact on the business, frequency of issues, and complexity of setup. Review the list and begin assessing the configuration of the highest priority instances. Compare their settings to what they should be.

For example, what are their maximum and minimum memory settings? What values are configured for Maximum Degree of Parallelism and Cost Threshold for Parallelism? How many tempdb files are defined? Is the instance on the latest supported Cumulative Update? Do you have the appropriate maintenance plans defined? What about file growth settings? Etc.

Here are a few links that may help.

• Operating System Best Practice Configurations for SQL Server
• Performance guidelines for SQL Server in Azure Virtual Machines
• Recommended updates and configuration options for SQL Server 2017 and 2016 with high-performance workloads

Doing this by hand can be quite time-consuming, especially when your SQL Server landscape is broad, so automating the approach would be helpful. You can create scripts to check each value of interest. A quick internet search will provide some scripts you can use as a starting point. Brent Ozar has some free scripts; so does Glenn Berry. And there are others. Of course, be cautious with everything you get from the internet.

2. Microsoft SQL Assessment API

Microsoft has recently made assessing your SQL Server instances a bit easier with it’s free SQL Assessment API.  The API employees SQL Server Management Objects (SMO) and PowerShell to compare your SQL Server with a ruleset published in the samples repository. You and even add your own SQL Server configuration parameters to the ruleset to customize the settings as appropriate for your environment.

This API is new enough that I haven’t had a chance to explore it as much as I’d like. However, it looks promising. If you have more than a few SQL Servers to examine, I’d encourage you to see if the API is a good alternative for you.

3. Get Some Outside Help

The first two options are great for organizations that have the time and the internal skill set to evaluate what is a good configuration for their environment and what should be changed. Not all companies have this luxury.

If you don’t have both the time and the knowledge, you can look outside your organization for an external expert to review your settings and provide an unbiased assessment of your SQL Server configurations.

For example, we frequently provide SQL Assessments for our clients. For a fixed price, we examine up to three of SQL Servers and deliver a 40 to 60-page document that describes our findings. It details and prioritizes each setting and provides links to additional information. During a one-hour follow-up call, we provide specific and actionable recommendations to bring these servers into alignment with industry-established best practices.

In the end, our clients are equipped to make the changes themselves, or we assist in the remediation as needed. In either case, they can rest assured that they’ve provided the best configuration possible for their database servers.

Next Steps

Don’t wait until the next “Oh No!” moment to think about your database servers. Get the peace of mind that comes from understanding exactly how your servers are configured. Begin assessing your SQL Server soon.

Not sure where to start? We’ll be glad to help. Let’s talk.

The post Is My SQL Server Configured Properly? appeared first on The SERO Group.

What does that mean?

It means that Microsoft will no longer release any updates for any version of SQL Server 2008. That includes security patches and data integrity fixes. If a hacker finds a zero-day vulnerability and publishes it to the web for all ne’er-do-wells to use, it won’t be fixed. If a new issue is discovered that could lead to data corruption or loss, no fix will be forthcoming. Discover a performance problem? Forget about it. It’s yours alone.

It’s not that Microsoft is heartless or doesn’t care. They do. But they understandably can’t support a version indefinitely. And we’ve known for a long time that this train would leave the station.

Yet many companies are still using SQL Server 2008 and SQL Server 2008 R2 for a lot of different reasons. Too many other projects, fear of a complicated upgrade path, wanting to bundle it with a larger initiative, and simply not knowing where to start are commonly cited reasons for not upgrading. Yet.

What are your options?

Now, the day has come and SQL Server 2008 has officially been mothballed. So, what can you do?

1. The “Do Nothing” Option

If SQL Server 2008 has been working well for you and you don’t see a need to upgrade, it may be that you don’t have to do anything. You could simply continue working as you currently are for a while longer and then sunset the aging applications in due course.

But before you get too excited about this, remember what you’ll forfeit, both now and in the future. Microsoft will not release any hot patches, service patches, cumulative updates, or anything else for the database platform. That’s bad, but that’s not all.

You will also be limited on your operating system upgrades. (Keep in mind that Windows Server 2008 will not be supported after January 14, 2020.)

And if you do decide to upgrade, there will be a substantial amount of technical debt to pay down. The longer you wait, the further entrenched the dated software will become and the more difficult it will be to upgrade or remove.

Although this option may be right for some organizations or instances of SQL Server, it should not be considered for any system that is connected to the internet in any way, even through a VPN. It is risky enough without the possibility of accidentally introducing malicious code.

2. The “One-for-One Upgrade” Option

Sometimes the most straightforward approach is the best approach. If you only have a handful of SQL Servers, you may be able to spin up a new virtual server for each existing database server and migrate to the new servers. This one-for-one approach makes planning and even execution relatively easy. Relatively.

To do it right, however, will take a bit of thought. Before doing anything, you’ll want to run the Data Migration Assistant to check for any potential issues with the upgrade. The DMA will help identify discontinued or deprecated features that your older systems may be using. It’ll also help you discover any potential breaking or behavioral changes that you should be aware before you upgrade.

You’ll also want to make sure you right-size the new environment and configure the new SQL Servers appropriately. Then you can migrate the databases, logins, users, jobs, linked servers, etc. to the new servers. You’ll also want to consider the service accounts used and how they access network resources such as shares used for backups.

Check out our free 5 Common Issues That May Be Putting Your SQL Server At Risk PDF for some common configuration issues we find during our SQL Assessments.

Of course, this option doesn’t consider potential gains that may be realized through server consolidation.

3. The “Consolidation Upgrade” Option

For environments with say ten to forty SQL Servers, it’s worth considering a new SQL Server landscape. The existing SQL Server environment probably grew organically over time without a lot of planning or forethought. New applications were purchased and the easiest thing to do was to spin up a new SQL Server instance for it. Over time, the number of database servers sprawled and now you may have more licenses than you actually need.

The upgrade project is a perfect time to (re)evaluate your landscape.

For this option, you’ll want to:

• Identify the scope and breadth of the project
• Run the Data Migration Assistant to look for possible upgrade issues
• Determine vendor and licensing requirements
• Collect and analyze performance data for each server to determine potential consolidation candidates
• Determine a preliminary consolidation design
• Plan and execute the project

Depending on the scope, you may also want to include a High Availability / Disaster Recovery component to the project.

4. The “Combination” Upgrade

For many environments, especially larger or more complex ones, a combination approach will likely be required, one that incorporates elements from each of the first three options.

Some applications and their associated SQL Servers will be identified as “on their way out” and the first “Do Nothing” approach will be adopted. Use them as-is until you can get rid of them.

Other servers will likely need to be upgraded using the “one-for-one” approach. This will likely apply for larger database servers where resources are a concern. It may also be the case for specific application servers whose vendors insist on sysadmin privileges to the SQL Server. You’ll likely want to separate those application databases to restrict what the vendor has access to.

The majority of the SQL Servers will hopefully be considered candidates for potential consolidation, thus saving some licensing costs and simplifying your environment.

Which option is right for you?

As with most technical questions, the answer is: it depends. There is no clear one-size-fits-all approach for an upgrade project. Consider your timeline and budget, the business requirements and the other projects you have on your plate. Then make the best decision you can.

Not sure where to start? Or don’t have the bandwidth to tackle the upgrade project? We can help. We’ve walked this path before and can help guide you as you take the journey. Give us a call and let’s talk.

The post 4 Options Now That Your SQL Server 2008 Is Out of Support appeared first on The SERO Group.

What Is tempdb?

Let’s start with a very brief description of tempdb. When SQL Server needs some additional workspace to resolve a query, it uses a built-in system database called tempdb. A query may use tempdb for sorting operations, cursors, temporary tables, or even aggregation operations among other things. Since there is only one tempdb database for each SQL Server instance, it can be quite heavily used. 

By default, when you install SQL Server, one data file is created for the tempdb database. Having only one data file, however, can hinder SQL Server’s performance. The solitary file can become a bottleneck for queries that require tempdb. This is a pretty common issue, in fact, it made our Top 5 List. 

How Many tempdb Files Do You Need?

So, if the default value is likely not right for you, how many tempdb data files should you have? The answer is: it depends. According to Microsoft Support, the best approach is to create one tempdb data file per logical processor up to 8 data files.

If your system has more than 8 logical processors, start with 8 data files and monitor your server’s workload to determine if more data files would be beneficial. If you do find that an increase is warranted, add 4 data files at a time, but do not add more than the number of logical processors.

How Many tempdb Files Do You Have?

How many tempdb data files does your SQL Server have? A fairly straightforward query can answer the question. Open Management Studio and run the following query.

--tell me about my tempdb
SELECT
  f.name AS [file_name],
  CAST((f.size / 128.0) AS DECIMAL(15, 2)) AS [size_in_MB],
  CAST(f.size / 128.0 - CAST(FILEPROPERTY(f.name, 'SpaceUsed') AS INT) / 128.0 AS DECIMAL(15, 2)) AS [space_available_in_MB],
  [file_id] AS [file_id],
  ISNULL(fg.name, 'LOG') AS [filegroup_name],
  f.physical_name AS [physical_name]
FROM sys.master_files AS f
LEFT OUTER JOIN sys.data_spaces AS fg
  ON f.data_space_id = fg.data_space_id
WHERE f.database_id = 2;

You’ll notice that the results from the query above include the folder location for each tempdb file. That’s because file placement can also have a dramatic impact on performance and even reliability. But that’s another story.

For more information about tempdb, check out Microsoft’s SQL Docs. 

Want to know more about other configuration options that could affect performance and reliability? Check out Is My SQL Server Configured Properly?

[EDIT Oct 5, 2021] – Also see How to Configure SQL Server tempdb? for other tempdb configuration settings that can affect performance.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation.

Schedule a call with us to get started.

The post How Many tempdb Data Files Should My SQL Server Have? appeared first on The SERO Group.

The scary part is that behind many IIS web sites sits the honeypot that the hackers are after: customer and other proprietary data in a Microsoft SQL Server database. Many websites, such as customer portals, online stores, software-as-a-service sites, and others, contain specific information about individuals that, if exposed, will cost the company dearly.

As my friend and SQL Server expert Steve Jones (@way0utwest) recently tweeted:

“The amount of shareholder value that can be lost due to a data breach is the amount of shareholder value you have.” 

Agreed. A well-targeted attack can bring down a company.

Fortunately, Microsoft SQL Server can be made extremely secure if configured properly. Encryption, Role-based security, Auditing, and other mechanisms allow administrators to define, limit, and monitor access at a very granular level.

The problem is that not all SQL Servers are configured properly. Over 96% of the SQL Server instances we’ve assessed deviate from industry best practices in security, performance, or other configurations. This is troubling.

What can you do? Spend some time with your application developers, with your system and network administrator, and with your DBA team to review the layers of security designed into your systems. Are the Windows Servers patched and up to date? Have the appropriate rules been defined in your firewalls? And, of course, are your SQL Servers configured properly?

Not sure where to start with security for your SQL Servers? Review the following:

• Overview of SQL Server Security
• Securing SQL Server
• MSDN SQL Server Security Blog
• MSSQLTips SQL Server Security Tips

Have questions? Give us a call. Our SQL Server Configuration Assessments maybe a good place for you to start.

The post Are Your SQL Servers Safe? IIS Attacks Increased 782x in One Quarter appeared first on The SERO Group.

In the SQL Server world, we have industry best practices. These are guidelines that most every knowledgeable database professional will agree is a good idea or a good baseline. Sure there are exceptions, specific tweaks to accommodate certain workloads, but the best practices are a generally a good starting point. Then you can customize for your needs.

As part of our practice, we regularly examine SQL Server instances to ensure they are configured with industry best practices in mind. We check configuration settings, maintenance jobs, and alerts, among other things, to help ensure the systems are protected and highly available.

Our findings: 9 out of 10 SQL Server instances we assess do not adhere to these industry best practices. Now, this isn’t a scientific study conducted by Forrester Research. Rather it’s our direct experiences working with hundreds of SQL Servers and clients.

Why Aren’t Most SQL Servers Configured with Best Practices?

We’ve found five predominant reasons for this.

SQL Server is so easy to set up

Many years ago, I taught a bunch of Oracle DBAs how to install, configure, and administer SQL Server. The hands-on lab allocated an hour for the installation, They were incredulous. “It can’t be done that quickly.” But it was. Find the media, double-click Setup, click Next-Next-Next, and it’s installed. Unfortunately, that’s where many people stop. They accept all of the defaults and never go back to configure the instance properly. The defaults are not best practices.

SQL Server just works

Even with the defaults, SQL Server is pretty responsive and resilient. It’s a testament to the quality of the product. You can neglect it, take it for granted, and still it keeps on keeping on. We’ve assessed (and subsequently remediated) systems that haven’t been touched in years. No patches applied. No maintenance performed. Nothing but users hitting it every day. Yet, it still works. That doesn’t mean it’s good or safe. In fact, we are frequently called into a new client because something has gone terribly wrong and the company needs help getting SQL Server out of the ditch. The better care you take of your SQL Server, the better it will be to you.

Introducing the accidental DBA

Many IT organizations don’t have the need for a full-time, dedicated Database Administrator. They only have a few SQL Server instances with 10 or 20 databases. Hiring a DBA isn’t in the cards. But someone has to care for the databases, has to think about backups and restores, disaster recovery, and high availability. Someone has to throw hardware at the problem when performance suffers. That’s when the CIO, a network admin, or an application developer steps up to do it in their “spare” time. These are smart, capable people with no spare time to give to SQL Server. “If an ain’t broke, don’t fix it” becomes the defacto approach since the accidental DBA is super busy with her day job.

Duct-taping with hardware

When a performance problem creeps into a production server, often the first recourse is to simply throw hardware at the problem. Reports taking too long? Add some CPUs! Imports not processing fast enough? Get faster disks! Application not responsive enough? Increase the RAM! Hardware can cover a multitude of SQL sins. But adding hardware gets expensive. Although the cost of hardware continues to go down, licensing costs do not. Adding an additional 8 CPUs to an Enterprise Edition of SQL Server can be expensive. And even if you have the really deep pockets to do it, hardware doesn’t address the root cause or protect your system any better.

Everyone has their own standards

Many IT organizations hire capable DBAs and let them do their jobs. That’s good. However, without a common playbook and set of standardized scripts, each DBA will handle things slightly differently, or worse, manually, and the result will be widely varying configurations. No two instances are the same. One instance may have 1 tempdb file on the C:\ and another has 8 somewhere else. One instance may have a patchwork of scheduled jobs and another may not have any. It’s like a box of chocolates. That makes troubleshooting difficult and performance unpredictable.

So, What Should You Do?

Best practices are exactly that, best practices. They are settings and techniques that should be adopted and applied to your SQL Server instances. Then you can tune based on your specific needs.

So, what should you do?

The first step is to know what you’re dealing with. Just how big is this elephant you’re about to eat? Assess your SQL Servers to see just how far from the best practices they really are. Then you can make a plan for updating them. Check out Is My SQL Server Configured Properly? for more information on assessing your SQL Server.

When we do assessments for companies, we have a standard script we run on each instance that looks for departures from best practices. That allows us to effectively collect, analyze, and report on the state of each instance. Sometimes there are good reasons for the variances and we discuss the rationale behind those decisions. Often we find that some remediation is recommended and we help to prioritize the findings so you’ll know where the biggest bang for your buck is. Learn about our SQL Server Assessments.

Whether you use our services or not, I’d recommend that you adopt a similar approach: identify what needs to change, prioritize the items, create a plan to remediate, and then work the plan.

In a coming post, I’ll share some of the things we look for when we assess an instance.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Why 9 Out of 10 SQL Servers Aren’t Configured with Best Practices appeared first on The SERO Group.