Five Useful SQL Server Management Practices

As organisations seek more cost efficient ways to manage their environments, the demand on IT to deliver and manage shops on a tighter budget is increasing. The typical IT person must think not just about what must be done but how it must be done not only with the least administrative effort but with the least financial cost.

Administrative effort indirectly contributes to financial cost when such factors such as time spent on performing tasks and resources employed in performing such administrative tasks are considered. In this article I have outlined a few areas where DBAs working in moderately sized environments can capitalise on to manage their environments more efficiently and more cost effectively.

1. Use Windows Authentication

SQL Server provides two main authentication modes: mixed mode and Windows Authenticaton.

In mixed mode authentication, logins can be created within SQL Server. SQL Server does the authentication and the user must provide both a username and a password when connecting to the instance. Windows logins can also be used.

Windows Authentication mode allows SQL Server to trust a credentials that have already been authenticated by Windows. This credential could be a local OS account or an Active Directory domain account. Typically when using Windows Authentication in a connection string you specify –T (for trust) or the option 'Integrated Security=true' (see https://www.connectionstrings.com/ for more details on this). Some developers are typically averse to taking the trouble to use Windows Authentication probably because it appears more straightforward to simply specify a username and password in the connection string.

Windows Authentication has the following advantages:

Much More Secure – Windows Authentication is more secure because a series of encrypted messages are used in the authentication process. When using Windows Authentication mode, SQL Server supports Kerberos through the Windows Security Support Provider Interface (SSPI). It is also worth noting that when you do use SQL Server Logins, passwords are transmitted across the network exposing them to sniffing.
Easier to Manage – In an environment where users every now and then request a password reset or lock their accounts, using Windows Authentication takes the load of trivial tasks such as unlocking account and resetting passwords off the DBA
Easier for Compliance – Many industry standards such as PCI-DSS demand basic practices such as password expiry, password complexity specifications and so on. Although this can be enabled on SQL Logins with the CHECK_POLICY=ON option, this is done per login. Using Windows Authentication ensures compliance requirements are handled by Windows not SQL Server which is much more efficient.
Easier for Access Management – When you need to manage a variety of departments who access SQL Server directly it will pay to handle access to the SQL Instance as follows:
- Create Windows Security Groups in Active Directory for each Department
- Grant the Windows Security Group Access to the SQL Instance
- Grant the Windows Groups the required privileges (through roles) on SQL Server
- When a new staff joins a particular depart, add him/her to the group on AD
- When a staff leaves the department remove him from the group on AD
- When a staff leave the organisation, remove him from ALL groups on AD

think the above approach or any variant is much easier than handling individual principals at SQL Server level. In addition, it can help pass Access Management to a non-DBA function entirely who will not need to access SQL Server frequently to do their job.

Fig 1. SQL Server Authentication Modes

2. Use Central Management Servers

Central Management Servers (available since SQL Server 2008) allow you to designate an instance as a management server and subsequently add the connection information for other instances as Registered Servers to that instance. You can group Registered servers as you like and run queries on them as groups.

One good example of the usefulness of this utility is documenting your instances (assuming you are not using more advanced methods). You can run one simple query on your Registered Server Group and get output across instances as shown in Fig 2.

Fig 2. Extracting Instance Information Across Instances

Fig 3 also shows how Central Management Servers can be used to perform adhoc maintenance tasks across instances. In Fig 4 we create an account across multiple instance and grant a role to this login within each database of each of the instances we loop through. You will find this useful if you, for example, want to create an account for monitoring or auditing purposes when using third party tools that must connect to the instance.

Fig 3. Updating Statistics Across Instances

Fig 4. Create a Moniitoring Login Across Instances

It is worth noting that when working in an environment where your database servers are behind firewalls, you should ensure that port 1433 (or any other port you have configured your instances to listen on) is open between the Central Management Server and the Registered Servers. The credentials you use to connect from the Central Management Server should have the required accesses on the Registered Servers.

3. Use a Quorum Share Server

In my experience building SQL Server failover clusters, I have always been more inclined to use Node and Disk Majority Quorum configuration simply because that is what I am used to. With the advent of AlwaysOn Availability Groups, we find that quorum configuration options are limited to Node Majority and Node and Fileshare majority.

When configuring AlwaysOn Availability Groups, It will be useful to designate a single low-spec server as your 'Quorum Share Server'. Create a number of shares on this server and grant permissions on the share to each clusters you install in your environment. You can manage and safeguard this single server from unintended reboots. You can take control of it as the DBA rather than for example depending on a share sitting on a Domain Controller.

4. Take Backups to a Share

For those who do not use or cannot afford enterprise backup solutions, one would often notice DBAs taking backups to a disk on the same server where the SQL instance is sitting. This is to say the least, RISKY. That means risky in UPPER case. It is even more risky if you are not using a SAN.

When in this situation, it would be a good idea to setup a share on a File Share server and grant permissions to the share to the SQL Server Service accounts across your enterprise. When configuring your backup jobs, simply use the share as your backup location. Below is a sample script.

-- Listing 1: Backup ALl Databases to a Share Excluding TempDB and Model
exec sp_MSforeachdb @command1='
DECLARE @backup sysname
SET @backup=N''\\10.1.119.45\Backup\?''+convert(nvarchar,getdate(),112)+N''.bak''
USE [?]
IF      ''?''     NOT IN ("tempdb","model")
  BACKUP DATABASE ? TO  DISK = @backup WITH  INIT ,  NOUNLOAD ,  
  NAME = N''?'',  NOSKIP , NOFORMAT'
-- Backup ALl Databases to a Share Excluding TempDB and Model if there has Been No Backup in the Last 24 Hours
exec sp_msforeachdb @command1='
USE ?
DECLARE @backup sysname
DECLARE @db sysname
SET @backup=N''\\10.1.119.45\POST_BKP\'' + DB_NAME() + ''_'' + convert(nvarchar,getdate(),112)+N''.bak''
SET @db = DB_NAME()
IF NOT EXISTS (
  select bus.database_name, bus.backup_start_date, bus.backup_finish_date,
  (((DATEPART(HH,bus.backup_finish_date))- (DATEPART(HH,bus.backup_start_date)))*3600) +
  (((DATEPART(MI,bus.backup_finish_date)) - (DATEPART(MI,bus.backup_start_date)))*60) +
  (((DATEPART(SS,bus.backup_finish_date)) - DATEPART(SS,bus.backup_start_date)))
  [backup_time (secs)], bus.backup_size,
  bmf.physical_device_name 
  from msdb..backupset bus
  join msdb..backupmediafamily bmf on bus.media_set_id=bmf.media_set_id
  where bus.backup_start_date >= (getdate() - 1)
  and bus.database_name=''?'')
  IF ''?'' NOT IN ("tempdb")
   BEGIN
   BACKUP DATABASE ? TO  DISK = @backup
   WITH  INIT ,  NOUNLOAD ,  
   NAME = N''?_Backup'',  NOSKIP ,  STATS = 10,  NOFORMAT
   END'

5. Use Operators and Alerts

Operators are aliases for a group of people who receive alerts from a SQL Server instance. Alerts can be triggered by server conditions as well as jobs. When an alert is raised and Database Mail has been configured correctly, the alert is fired as an email to the Operators defined and mapped to the specific alert. Using Operators and Alerts can replace the need for a third party monitoring tool assuming your shop is not too large and you wish to save some money on monitoring. With details planning, standardization Operators and Alerts can go a very long way in meeting monitoring requirements.

Conclusion

SQL Server ships with a wide variety of in-built features that can be harnessed creatively to cut down your financial and administrative costs significantly. This article simply points out a few key areas which will be useful especially to not-so-large organisations.