One thing to point out is that in SQL Server 2022 and above, when creating a new database from the SSMS GUI or by simply using the CREATE DATABASE MyNewDB syntax, the Query Store option will be on by default. For databases restored to SQL Server 2016 or later, the Query Store’s status from the original system will remain unchanged when the database is restored on the new instance.

Let’s go through the three ways to enable Query Store.

1. Manually in SQL Server Management Studio
2. Using T-SQL
3. Using PowerShell

1. Enabling Query Store using SQL Server Management Studio:

Since you’re likely already comfortable using SQL Server Management Studio for queries and database maintenance, SMSS does offer a convenient, familiar method for getting started with Query Store.

Steps to Enable Query Store using SSMS

1. Connect to a SQL Server instance running SQL Server 2016 or higher.
2. Click the ‘+’ sign next to the Databases folder to expand and see the list of databases.
3. Right-click on the database name and select “Properties.”
4. Left-click the “Query Store” option on the left-hand side of the GUI.
5. Change the Operation Mode(Requested) option from “Off” to “Read write.”
6. Click OK to apply the change and enable Query Store.

Further Details

Here is what you will see after step 3. The Query Store option mentioned in step 4 is at the bottom of the list of options, like the below.

Left-clicking that Query Store option will cause the below to show up on the right of the SSMS GUI.

What you see when you do that are the existing defaults on 2019 and above. If you are enabling Query Store on versions 2016 or 2017, you will want to adjust additional defaults. Prior to 2019, the default for “Query Store Capture Mode” was “All.” Change this option to “Auto” instead.

Furthermore, the default for Max_Storage_Size_MB was far too low in 2016 and 2017 and could be better in 2019 as well. This value represents the maximum amount of space that Query Store data will occupy in the database in which it was enabled. A good default value to start with is 2048 MB. It may be necessary to adjust that to 4096 MB at the high end in order to capture queries for the entire length of the “Stale Query Threshold (Days)” value.

The “Stale Query Threshold (Days)” option controls how many days of Query Store data will be kept. If the max storage size is set too low for a retention value of 30 days, then Query Store will start deleting collected data in the system tables to keep Query Store below the max storage size. This could result in having less data available than you intend for troubleshooting.

The rest of the defaults are acceptable and so could be left alone without concern.

2. Enabling Query Store using T-SQL

The T-SQL language is, of course, the language of SQL Server. It is often more flexible than the SSMS GUI. Notice in the screenshot up above that there is a “Script” button. If you click that instead of clicking “ok” in the UI, then SQL Server will script out the options in the GUI into a query window. This will allow you to see what the GUI does. Using T-SQL, it is easier to enable Query Store on multiple databases. You can use a construct like sp_msforeachdb to enable Query Store for multiple databases at once.

USE [master]
GO
ALTER DATABASE [MyDB] SET QUERY_STORE = ON
GO
ALTER DATABASE [MyDB] SET QUERY_STORE (OPERATION_MODE = READ_WRITE, MAX_STORAGE_SIZE_MB = 2048)
GO

3. Enabling Query Store using PowerShell

Many accidental DBAs, those folks who were “voluntold” to start managing SQL Server, are network engineers, sysadmins, or cloud admins. Automation is often music to their ears, and in the Windows universe, PowerShell is a go-to method for automating tasks. Consequently, using PowerShell to automate the enabling of Query Store may feel natural to accidental DBAs. For the below command, the DBATools module will be needed in your environment.

Below is how Query Store could be enabled on all user databases on an instance of SQL Server. If you only want to enable Query Store on a few select databases on an instance, then add the -Database parameter with a comma-separated list of databases.

Set-DbaDbQueryStoreOption -SqlInstance ServerA -State ReadWrite ​

-FlushInterval 900 -CollectionInterval 60 -MaxSize 4096 ​

-CaptureMode Auto -CleanupMode Auto -StaleQueryThreshold 30, -WaitStatsCaptureMode ON

Also, if your SQL Server environment has the Registered Server feature set up, then PowerShell can be used to read the servers registered there, loop over them, and enable Query Store on all user databases across your environment. This would be done using the Get-DbaRegServer command in the DBATools module.

Trace Flags for Query Store

If you aren’t familiar with Trace Flags, these are numbers that Microsoft uses to enable certain kinds of behavior in the database engine. They are occasionally meant to be short-term fixes, and later the functionality in a trace flag is built into how the SQL Server database engine works. This is the case for trace flags and Query Store. There are two trace flags to know about and enable. Notice that flag 7752 isn’t needed on SQL Server 2019 and above.

Trace Flag 7745—This prevents Query Store data from writing to disk prior to shutdown or failover process so it doesn’t delay a shutdown or failover.​

Trace Flag 7752 – Loads Query Store data to memory asynchronously from query execution. This default is built into the engine in SQL Server 2019.​

Want to Work With The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post How to Enable Query Store in SQL Server: A Step-by-Step Guide appeared first on The SERO Group.

The error message is telling us that the user owns a schema in this database. And as long as that’s the case, the user cannot be dropped. So, we need to determine which schema(s) are owned by the user.

Who owns a schema? Finding the reason for Msg 15138

There are a couple of easy ways to determine which schemas a user owns. You can view properties window for the user, or you can write a quick query. Let’s look at each method.

Viewing Owned Schemas in the Properties window

To see which schemas a user owns, drill down in the server, database, Security, Users in the connections pane of SQL Server Management Studio or Azure Data Studio. Right-click the user and select Properties. You’ll see the following Database User properties window open. Click on the Owned Schemas page.

In this example, Kim owns the db_ddladmin schema. That’s preventing you from dropping the user.

Using T-SQL to see the schemas owned by a user

Not really a point-and-click kind of person? The following query will show you a list of the schemas owned by a specific user. Of course, you can omit the WHERE clause to see a list of all schemas and who owns them. Replace Kim with the user you’re interested in.

--what schemas does this user own?
SELECT SCHEMA_NAME, 
    SCHEMA_OWNER
FROM INFORMATION_SCHEMA.schemata
WHERE SCHEMA_OWNER = 'Kim';

The results are below.

Fixing the Msg 15138 The Database Principal Owns a Schema error

Ok, we know the schema that’s preventing us from dropping the database. Now we need to fix the problem. To do that, we need to transfer the ownership of the schema to another user. As before there are a couple of ways to do this.

Changing the schema owner using the Properties window

To change the owner of a schema using SQL Server Management Studio or Azure Data Studio, use the connection list to drill down into the server, database, Security, Schemas. Right-click on the schema in question and select the Properties menu item.

On the General page, you’ll see the Schema Owner. Click Search to open a window that allows you to find another user. Enter the username you’d like to be the new owner, and click Check Names. Once, verified, click Ok, and then Ok again to close the Properties window.

Changing who owns a schema using T-SQL

Once again, we can use a quick T-SQL statement instead of the point-and-click method. Run the following statement to change the owner of the schema. Of course, change the schema and username to fit your needs.

--transfer schema ownership to dbo
ALTER AUTHORIZATION ON SCHEMA::db_ddladmin TO dbo;

Who should own a schema?

This begs a question: who should own a schema?

Generally, unless you have a compelling reason to do otherwise, having the schema owner be dbo is often preferred. This keeps things simple and straightforward. A good case for this would be when schemas are used to create a logical workspace or namespace for the database objects.

But a compelling reason may exist. For example, schemas are sometimes used as part of a broader security implementation. You can assign permissions to a schemas and all database objects in the schema will inherit those permissions. That can be convenient. If that’s the case in your environment, it’s worth discussing whether a specific user should own the schema.

So, as is frequently the case, the answer is: It depends.

Want to work with The SERO Group?

Here are some other posts posts that may be helpful, And be sure to check out our Script Library.

• Who’s the SQL Server Database Owner and How Can You Change It?
• What Takes Precedent db_datareader (GRANT) or db_denydatareader (DENY)?
• Who Has sysadmin Access to your SQL Servers?

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 Error Msg 15138 The Database Principal Owns a Schema in the Database, and Cannot be Dropped appeared first on The SERO Group.

What can a sysadmin do?

We often talk about a sysadmin as if it refers to an individual, but sysadmin is actually a role. Or more accurately, sysadmin is a Fixed Server Role. A role is a group or collection of individual logins. We assign permissions to the role and all members of the role inherit the permissions of the role. You know, role-based security. It’s much easier to manage than assigning permissions to the individual logins.

Members of the sysadmin role can do anything in SQL Server. Anything is a pretty bold statement. But in this case, it’s true. They have the proverbial keys to the kingdom.

Someone with sysadmin privileges can create and drop databases. They can grant or revoke permissions for other logins. They can change the configuration of the SQL Server; for example, the can enable xp_cmdshell or CLR integration. They can query or change data. They can do it all.

So, if someone in your organization who’s a member of sysadmin falls for a phishing attack, it’s bad. The attacker very likely has sysadmin privileges on your SQL Server. Yikes! And if they know what they are doing, they very well may be able to go beyond the SQL Server.

Who are your sysadmins?

Knowing who has sysadmin privileges to your SQL Servers is an important first step in securing the servers. Here’s a query I use to get a list of syadmins in SQL Server.

--who are the sysadmins for this SQL Server? 
SELECT p.name AS [loginname],
    p.type,
    p.type_desc,
    CONVERT(VARCHAR(10), p.create_date, 101) AS [created],
    CONVERT(VARCHAR(10), p.modify_date, 101) AS [updated],
    p.is_disabled,
    CASE COALESCE(sl.is_expiration_checked, -1)
        WHEN 0 THEN 'No'
        WHEN 1 THEN 'Yes'
        ELSE '--'
        END AS [is_expiration_checked],
    CASE COALESCE(sl.is_policy_checked, -1)
        WHEN 0 THEN 'No'
        WHEN 1 THEN 'Yes'
        ELSE '--'
        END  AS [is_policy_checked],
    LOGINPROPERTY(sl.name, 'PasswordLastSetTime') AS PasswordLastSetTime
FROM sys.server_principals AS p
    JOIN sys.syslogins AS s ON p.sid = s.sid
    LEFT JOIN sys.sql_logins AS sl ON sl.sid = p.sid
WHERE p.type_desc IN('SQL_LOGIN', 'WINDOWS_LOGIN', 'WINDOWS_GROUP')
    -- Logins that are not process logins
    AND p.name NOT LIKE '##%'
    AND p.name NOT LIKE 'NT SERVICE%'
    -- Logins that are sysadmins
    AND s.sysadmin = 1 ;

Notice that the script looks for SQL logins as well as Windows logins. For the SQL logins, the script looks to see if the login must adhere to password expiration and complexity requirements. It also shows the last time that the SQL login’s password was changed.

The results from a test lab are shown below.

How many sysadmins should you have?

So, you’ve run the query and gotten the list of sysadmins. You’ve likely found some surprises. Maybe there’s a login for someone that left the company years ago. Or maybe a vender was temporarily granted sysadmin privileges during an installation but it was never removed. Some power users or developers may have been added to the role for a reason no one can remember? And your CFO needs sysadmin access? Really?

In any case, there are more members of sysadmin than there should be. Identify those logins and remove them. Grant them lower level permissions that will meet their needs while still protecting your SQL Server.

But this begs the question – how many sysadmins should you have?

That’s going to depend on your environment. The size of your company and the number of SQL Servers you have will certainly influence the number of sysadmins you need. I cannot answer that question for you, at least not with a specific number.

What I can say is: you should have as few as possible, but no less than that.

Here are a few other posts that you may find interesting.

• What Takes Precedent db_datareader (GRANT) or db_denydatareader (DENY)?
• Scary and Dangerous Things in SQL Server
• Who’s the SQL Server Database Owner and How Can You Change It?
• Securing Your SQL Servers, What Should You Audit?
• Protect Your SQL Server from MrbMiner and Other Malware Attacks

Also, check out our Script Library.

Want to work with The SERO Group?

Worried about your SQL Server’s security? Want a second set of eyes to review it? We can help.

Schedule a call with us to get started. It’s easy and there is no obligation. 

The post Who Has sysadmin Access to your SQL Servers? appeared first on The SERO Group.

If you want to skip the “why” and jump straight to the “how”, click here.

Does your SQL Server version really matter?

Microsoft releases a new version of SQL Server every 18 to 24 months. Each new version builds on the prior version, adding new features and improving existing capabilities. It’s a bit like Apple releasing a new iPhone. It’s new and shiny and can do things the prior versions couldn’t.

However, there’s a big difference. Upgrading your iPhone is really a luxury. If you don’t upgrade, you’ll miss out on a better camera and a maybe few O/S improvements. But otherwise, you’ll function just as well.

But not upgrading your database servers is another story. Not upgrading can create big problems. See Why Not Upgrading Could Be Risky for Your Data. Additionally, over time SQL Server will reach its end of mainstream support. That usually happens after five years. Extended support typically ends 10 years after the initial version release. What does the loss of mainstream and extended support mean? Check out End of Mainstream Support for SQL Server 2016 for a summary.

Your SQL Server version matters. You want to be as close to current as your application venders will support.

What’s with all these SQL Server updates?

Before releasing a new SQL Server version into the wild, the SQL Server team spends a lot of time testing. However, SQL Server is complex and over time bugs are uncovered. Bugs that need to be fixed. So, the SQL Server team continues to improve the product even after the initial release date.

Microsoft pushes out updates using a couple of vehicles. Hotfixes are issued for high priority items. Items that affect security and system integrity are often released in hotfixes first.

Cumulative Updates

Periodically Microsoft will bundle the hotfixes along with other fixes into a Cumulative Update, or CU for short. Prior to SQL Server 2017, Microsoft had even larger updates called Service Packs, or SPs. Since then, they’ve opted for a more straightforward CU approach.

Applying CUs is important. Let’s look at SQL Server 2019 CU8 released in October of 2020 as an example. The CU contained the following fixes.

• Fixed an issue that reduced throughput and caused higher CPU when you run workloads that frequently allocate and release memory, such as XML related functions.
• Query Store scalability improvement for adhoc workloads. Query Store now imposes internal limits to the amount of memory it can use and automatically changes the operation mode to READ-ONLY until enough memory has been returned to the Database Engine, preventing performance issues.
• FIX: Restoring database fails due to backup command timeout in SQL Server 2019.
• FIX: SQL Server 2019 service fails to start in Linux operating system

This is just a sampling. There were at lot of other fixes included in CU8. For a full list, see the SQL Server CU8 Release Notes.

So, keeping your SQL Server patched with CUs can improve its reliability, its performance, and its security. That’s why checking the SQL Server version and patch level is the first thing we check in our SQL Assessments. And you can easily check this, too.

How can I tell what version of SQL Server I’m running.

Figuring out which version of SQL Server you’re running is straightforward. Let’s look at a graphical way, a couple of T-SQL scripts, and a PowerShell/dbatools script.

Using SQL Server Management Studio or Azure Data Studio

If you only have a server or two to check, using the point-and-click method in SQL Server Management Studio or Azure Data Studio is convenient. Right-click on the instance name in the list of connections and select Properties. In the window that opens, look for the version information on the General page.

You can see that this one is SQL Server Developer Edition running on Ubuntu Linux. It’s version is 15.0.4073.23. But what do those numbers mean? Is it up to date or not?

Go to https://sqlserverbuilds.blogspot.com/ and you’ll see that 15.0.4073.23 represents Cumulative update 8 (CU8) for SQL Server 2019. We can also see that this instance is behind on updates. See also Is There an Update for My SQL Server?

Using a T-SQL query

Often it’s faster and easier to run a quick script to gather the version information. This is especially true if you need to collect the information for dozens or even hundreds of SQL Servers.

You can use a couple of different queries to return the version and update information.

SERVERPROPERTY()

Let’s look at the SERVERPROPERTY() function first. Use the following query to return server version and patch level information.

SELECT 
     SERVERPROPERTY('ServerName') AS [Server Name] ,
     SERVERPROPERTY('Edition') AS [Edition], 
     SERVERPROPERTY('ProductLevel') AS [Product Level] ,
     SERVERPROPERTY('ProductUpdateLevel') AS [Update Level] ,
     SERVERPROPERTY('ProductVersion') AS [Version Number] ;

@@VERSION

You can also query the @@Version variable as shown below.

SELECT @@VERSION ; 

The results are shown below.

Microsoft SQL Server 2019 (RTM-CU8) (KB4577194) - 15.0.4073.23 (X64) 	Sep 23 2020 16:03:08 	Copyright (C) 2019 Microsoft Corporation	Developer Edition (64-bit) on Linux (Ubuntu 18.04.5 LTS) <X64>

Both queries work and are quick to run. You can even run the queries in Central Management Server to collect information from multiple instances at once.

Using PowerShell and dbatools

If you’ve looked through our Script Library, you’ve probably noticed we’re fans of using PowerShell and dbatools.io to perform common administrative tasks in SQL Server. And as you’d expect, you can get the version information using these tools.

In the PowerShell script below, I’m using the Get-DbaInstanceProperty commandlet on the localhost to gather the information.

Get-DbaInstanceProperty -SqlInstance localhost -SqlCredential sa -InstanceProperty NetName, Edition, VersionString, ProductLevel, HostPlatform | Format-Table 

There’s much more information available from the commandlet. Just omit the InstanceProperty parameter to get a complete list.

Get-DbaInstanceProperty -SqlInstance localhost -SqlCredential sa |Format-Table

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? Or learn more about our SQL Server Assessments? It’s easy and there is no obligation. Schedule a call and let’s talk.

The post What SQL Server Version Am I Running? appeared first on The SERO Group.

It’s like what Harvard Business School Professor Theodore Levitt said about marketing: “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” In the world of databases, stakeholders don’t care about SQL backups. They care about the ability to restore a SQL database.

Testing your SQL Server backups

How do you know if your SQL Server backups are good? We recommend three levels of testing.

1. Checking your SQL backup jobs
2. Verifying the backup file
3. Proving your backups with a test restore.

Checking your database backup job

The ability to restore a database starts with having a good backup. We prefer native backups and in our minds, there’s no better way to manage your native backups than using Ola Hallegren’s Award winning scripts. It’s our tool of choice when it comes to SQL backups. (Note: when/if you run a SQL Server backup manually, you can use this script to see how much longer the backup will take.)

Schedule full, differential, and transaction log backups to occur regularly. Then make sure that they actually run and complete successfully.

Job failure notifications are good, and you should set those up, but it’s reassuring to actually see for yourself that the jobs complete successfully. The absence of a failure notification doesn’t automatically mean success. It’s better to check. For our customers, we look at the SQL Server Agent job histories daily.

You can use SQL Server Management Studio or Azure Data Studio to look at job histories. Of course, scripting it out is faster and more detailed. You can use the following script as starting point for your own query to check job history. This query looks for all failed jobs within the past week.

USE msdb;
GO

SELECT j.name AS Job_Name,
    h.step_name AS Step_Name,
    CONVERT(CHAR(10), CAST(STR(h.run_date, 8, 0) AS DATETIME), 111) AS RunDate,
    STUFF(STUFF(RIGHT('000000'+CAST(h.run_time AS VARCHAR(6)), 6), 5, 0, ':'), 3, 0, ':') AS Run_Time,
    h.run_duration AS Step_Duration_In_Seconds,
    CASE h.run_status
		 WHEN 0 THEN 'Failed'
		 WHEN 1 THEN 'Succeeded'
		 WHEN 2 THEN 'Retrying'
		 WHEN 3 THEN 'Canceled'
		 WHEN 4 THEN 'In-progress'
	  END AS Execution_Status,
    h.message AS [Message]
FROM sysjobhistory AS h
    JOIN sysjobs AS j ON j.job_id = h.job_id
WHERE CAST(STR(h.run_date, 8, 0) AS DATETIME) > DATEADD(ww, -1, GETDATE())
    AND h.step_name = '(Job outcome)'
    AND h.run_status != 1
ORDER BY j.name ASC,
	    h.run_date DESC,
	    h.run_time DESC;

In this example, the database backup job failed recently.

Another script we frequently use to look for backup job failures is:

USE MSDB;

SELECT DISTINCT
    s.[Database_Name],
    f.logical_device_name AS LogicalDeviceName,
    f.physical_device_name AS PhysicalDeviceName,
    s.expiration_date AS ExpirationDate,
    s.name AS Name,
    s.[description] AS [Description],
    s.user_name AS UserName,
    s.backup_start_date AS StartDate,
    s.backup_finish_date AS EndDate,
    DATEDIFF(mi, s.backup_start_date, s.backup_finish_date) AS DurationInMinutes,
    CAST(CASE s.type 
        WHEN 'D' THEN 'Database' 
        WHEN 'L' THEN 'Log' 
        WHEN 'I' THEN 'Differential' 
        WHEN 'F' THEN 'File' 
        WHEN 'G' THEN 'Diff File' 
        WHEN 'P' THEN 'Partial' 
        WHEN 'Q' THEN 'Diff Partial' 
        END AS NVARCHAR(128)) AS BackupType,
    ISNULL(s.compressed_backup_size, s.backup_size) / 1048576 as SIZE,
    GetDate() AS DateChecked
FROM msdb.dbo.backupmediafamily AS f
    JOIN msdb.dbo.backupset AS s ON f.media_set_id = s.media_set_id
WHERE (CONVERT(datetime, s.backup_start_date, 102) >= GETDATE() - 1)
    AND s.server_name = @@servername --Filters out databases that were restored from other instances.
    --AND s.[Database_Name] = 'DBA'
    AND s.type = 'D'
ORDER BY StartDate DESC 

Verifying your database backup file

Your weekly, daily, and sub-daily backups are scheduled and running like clockwork. You’re checking to make sure that they are actually completing successfully. But, what if the SQL backup file is bad or incomplete? What if a file was corrupted while being written to disk? The job completed successfully, but you don’t have a valid backup file to restore from.

To help with this, you should verify your SQL backup files regularly. Use the RESTORE VERIFYONLY TSQL command to check the completeness of the backup file, as well as to make sure the entire file is readable by SQL Server.

In the following example, we’re verifying that the BaseballData.bak file is valid.

RESTORE VERIFYONLY FROM DISK='/var/opt/mssql/backup/BaseballData.bak'

If it verifies successfully, you’ll see a message similar to the following.

RESTORE VERIFYONLY helps provide confidence that the backup files are usable without having to actually restore the database. We recommend running a RESTORE VERIFYONLY regularly, at least monthly on select SQL backup files.

Testing your database backup

Once you’ve have confidence that SQL backups are occurring, and that the backup files are well-formed and complete. There is still one more check that should be done periodically. To have complete confidence you can restore when needed, it’s good to actually go through the restore process.

It’s like a grade school fire drill. You can talk to students about what to do during a fire, showing them exit plans and rallying points, but until you walk through the process, it’s all theoretical. And, in an emergency, you don’t want to work from theory; you want to have practiced.

Take a SQL backup file and restore it another SQL Server instance. Apply differential backup files and transaction log files. Document the steps if you haven’t already. Creating scripts that automate it the process is a good idea, as well. In the following script, I’m restoring a copy of the BaseballData database to another instance.

RESTORE DATABASE BaseballData_restored  
   FROM DISK = '/var/opt/mssql/backup/BaseballData.bak' 
   WITH RECOVERY,  
   MOVE 'Baseball' TO '/var/opt/mssql/data/Baseball_restored.mdf',   
   MOVE 'Baseball_log' TO '/var/opt/mssql/data/Baseball_restored.ldf';  

Once you’ve restored the SQL backup, test the integrity of the database by running DBCC CHECKDB, checking the output for errors. Also see: When Was the Last Known Good DBCC CHECKDB Integrity Check?

DBCC CHECKDB (BaseballData_restored);

For our DBA as a Service customers, we recommend going through this exercise quarterly.

How often should you test SQL Server backup files?

Each environment is different and has it’s own setup of unique requirements. So there isn’t a one-size-fits-all answer here. We generally recommend the following as a good starting point and then adjusting as needed.

1. Checking your SQL backup jobs. Do this daily. Without a backup file, you cannot restore. Don’t rely exclusively on job failure notifications. Make sure the backup jobs completed successfully.
2. Verifying the backup file. Spot check a few key backup files at least monthly to ensure that the files are well-formed and complete.
3. Proving your backups with a test restore. Depending on your systems and the storage requirements, performing a test restore and running an integrity check against the restored database every three or four months is worthwhile exercise.

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 Often Should I Test My SQL Server Backups? appeared first on The SERO Group.

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.

What version is my SQL Server currently running?

There are several ways to check the version of SQL Server you’re currently running – all of them documented in countless places on the the web. Checking the instance property page in Management Studio and executing SELECT @@VERSION are two of the more common.

My preference is to run the following script using SERVERPROPERTY. When used in combination with Central Management Server, you can check the current level for all the SQL Server instances in your environment with one click of the Execute button.

SELECT
	SERVERPROPERTY('servername') AS Server_Name,
	SERVERPROPERTY('edition') AS Edition,
	SERVERPROPERTY('productlevel') AS Product_Level, 
	SERVERPROPERTY('productversion') AS Product_Version,
	SERVERPROPERTY('productupdatelevel') AS Product_Update_Level,
	SERVERPROPERTY('productupdatereference') AS Product_Update_Reference,
	SERVERPROPERTY('resourceversion') AS Resource_Version, 
	@@VERSION AS Version_Information 

Running the query on my Docker container instance returns the following.

Keep in mind that SERVERPROPERTY can behave slightly differently for older versions of SQL Server. ProductUpdateLevel and ProductUpdateReference, for instance, were introduced as part of SQL Server 2012. When run against an older version, such as SQL Server 2005, these will return NULL.

Running against another older SQL Server produces the following. Still, it gives you the information you need.

So, is that up to date or not for this version of SQL Server?

What is the latest update level for my version of SQL Server?

To answer that question, let’s turn to the definitive source – Microsoft. Microsoft has gotten into a fairly predictable cadence of regularly releasing updates for SQL Server. To help us keep track of the releases they’ve provided a SQL Docs page that lists all versions of SQL Server for the past 20 years. Yes, all the way back to SQL Server 2000.

The list shows the Product Version, the Latest Service Pack (if applicable), the Latest GDR (General Distribution Release), the Latest cumulative update (CU), the CU Release Date, and a link to some General Guidance for the each version. Here’s what the site looks like today, March 31, 2020.

Not sure of the difference in a SP, GDR, and CU? Here’s a blog post I wrote 12 years ago when I blogged at SQLTeam that explains the vernacular.

Additional Information

Here are a few other links that may help.

• SQL Server Release Blog – A Micosoft Tech Community blog dedicated to SQL Server Releases.
• SQL Server Builds Blog – I particularly like this blog since it shows each version along with relevant build numbers.
• SQL Server Updates – Brent Ozar also maintains a great site for keeping track of version update information.

The post Is There an Update for My SQL Server? 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.

Someone has started a database restore (or backup) using a T-SQL command. Now he wants to know how long the process will take to complete. He’s gone to the bathroom and even gotten a coffee, yet it’s still running. 

If he had used the WITH STATS option for either the BACKUP DATABASE or RESTORE DATABASE command, the percentage processed would have been piped to the Messages tab of Management Studio a little at a time. 10 percent processed. 20 percent processed. And so on as shown below.

BACKUP DATABASE wideworldimporters TO DISK = 'c:\temp\wwi.bak' WITH STATS;

SQL Server backup/restore information using DMVs

Still, that doesn’t provide an estimate of how long the process is likely to run. Fortunately, the Dynamic Management Views in SQL Server allow us to gather and report backup and restore estimates.

Here’s a script that I’ve found useful. It’s an amalgamation of a script I found on StackOverflow and my own handiwork. As always, this is for your reference only and no guarantees are implied.

SELECT SERVERPROPERTY('ServerName') AS [Instance],
   reqs.session_id,
   sess.login_name,
   reqs.command,
   CAST(reqs.percent_complete AS NUMERIC(10, 2)) AS [Percent Complete],
   CONVERT(VARCHAR(20), DATEADD(ms, reqs.estimated_completion_time, GETDATE()), 20) AS [Estimated Completion Time],
   CAST(reqs.total_elapsed_time / 60000.0 AS NUMERIC(10, 2)) AS [Elapsed Minutes],
   CAST(reqs.estimated_completion_time / 60000.0 AS NUMERIC(10, 2)) AS [Estimated Remaining Time in Minutes],
   CAST(reqs.estimated_completion_time / 3600000.0 AS NUMERIC(10, 2)) AS [Estimated Remaining Time in Hours],
   CAST((
     SELECT SUBSTRING(text, reqs.statement_start_offset/2,
                CASE
                WHEN reqs.statement_end_offset = -1
                THEN 1000
                ELSE(reqs.statement_end_offset-reqs.statement_start_offset)/2
                END)
     FROM sys.dm_exec_sql_text(sql_handle)) AS VARCHAR(1000)) AS [SQL]
FROM sys.dm_exec_requests AS reqs
 JOIN sys.dm_exec_sessions AS sess ON sess.session_id = reqs.session_id
WHERE command IN('RESTORE DATABASE', 'BACKUP DATABASE');

The script returns the following information:

• Instance Name
• Session Id 
• Login Name
• Command 
• Percent Complete
• Estimated Completion Time
• Elapsed Time in Minutes
• Estimated Remaining Time in Minutes
• Estimated Remaining Time in Hours
• The Complete Command Used to Start Backup/Restore
  

Since this script uses Dynamic Management Views, it won’t work on ancient versions of SQL Server. I’ve tested it on SQL Server 2008 R2 and forward on the Windows version. I haven’t tried it on SQL Server 2017 running on Linux. 

Hopefully, you’ll find this script handy. Here are a few more that you may find helpful.

• High Availability and Disaster Recovery in SQL Server
• How to Create SQL Server 2019 Failover Clustered Instances in Azure
• Vollgar: 6 Scripts to Help Review Your SQL Servers

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 Script: How Long Until My SQL Server Backup/Restore Completes? appeared first on The SERO Group.