SQL Server Snippets | Paul Hewson

The  SQL_Latin1_General_CP1_CI_AS collation is a legacy collation and we are recommended by Microsoft to use the supported  Latin1_General_CI_AS .  So when I was installing a cluster recently to host the databases for SCOM 2012 I chose the latter. This was a mistake as unfortunately it still requires the old collation .  How to change a SQL Server's collation after you've installed it is well documented  and so is the command, but there are a couple of gotchas that might be worth remembering. The command executed from a cmd.exe window is: z:\Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=domain\AUser /SAPWD=MyPassword /SQLCOLLATION=SQL_Latin1_General_CP1_CI_AS Probably due to the /QUIET option virtually no progress or errors are returned - you just need to wait for five minutes looking at an empty DOS box while it does its thing. The user account name and SA password should not be in quotes or square brackets The SQL se

I use the dbWarden alerts to inform me if a SQL job is taking longer to complete than normal and I got one this morning:   Click to enlarge I noticed by looking at the history this purge job was gradually taking longer and longer to complete each day since I installed it again ( see mylast post on this ): RunDate RunTime Duration ExecutionStatus JobName 04/10/2013 02:00:01 00:00:45 Succeded mdw_purge_data_[MDW] 05/10/2013 02:00:00 00:13:27 Succeded mdw_purge_data_[MDW] 06/10/2013 02:00:00 00:17:03 Succeded mdw_purge_data_[MDW] 07/10/2013 02:00:01 00:30:58 Succeded mdw_purge_data_[MDW] 08/10/2013 02:00:01 01:04:25 Succeded mdw_purge_data_[MDW] 09/10/2013 02:00:01 01:41:39 Succeded mdw_purge_data_[MDW] 10/10/2013 02:00:01 02:35:17 Succeded mdw_pu

The SQL Server Management Data Warehouse (when you first come across it) seems to promise so much if the verbiage from Microsoft and some other websites is to to believed. But when you install it you may find that it is not as useful as it could be. This is a shame but we are currently only on v2 of the product with SQL 2012 so one hopes it will improve in subsequent versions. However, it probably is worth playing with if you have never used it before - at least you can show your boss some reports on general server health when he asks for it and you have nothing else in place. There is one big problem with it though if you decide that you don't want to use it any more, uninstalling it is not supported! Mad, I know. But as usual some very helpful people in the community have worked out, what seems to me, a pretty safe way of doing it. I had a problem with my MDW. The data collector jobs were causing a lot of deadlocking on some production servers and impacting performance. I

There is a handy little "by product", if you like, when running queries which means you can quickly generate scripts to do different things. Below is an example of generating multiple "attach" commands that you can copy from the results pane into the main SSMS window for execution. I have found this very handy in the past: SELECT 'CREATE DATABASE [' + name + '] ON ( FILENAME = N''F:\MSSQL\Data\' + name + '.mdf'' ), ( FILENAME = N''E:\MSSQL\Log\' + name + '_log.ldf'' )  FOR ATTACH GO ' FROM master . dbo . sysdatabases WHERE name not in ( 'master' , 'msdb' , 'model' , 'tempdb' ) ORDER BY name

There are a large number of DBCC commands and it's easy to forget their names and syntax/order of parameters. To help you can run the commands below: -- Show list of all DBCC commands DBCC TRACEON ( 2520 ) DBCC HELP ( '?' ) GO -- Show help for specific command DBCC HELP ( show_statistics ) This piece of code is ideal for a  Snippet .

When checking out who has what permissions to a SQL Server or database you often see that BUILTIN\Administrators has sysadmins. To quickly find out the membership of the group run this bit of code: EXEC xp_logininfo 'BUILTIN\Administrators'   , 'members' This piece of code is ideal for a  Snippet .

This is is a handy piece of TSQL code which generates a list of TSQL commands that can be used to alter the location of all user databases to the path specified. It assumes that the filenames for the data file and log file will match the database name plus ".mdf" for the former and "_log.ldf" for the latter. This can be executed while the SQL service is running and will only take effect after it has been restarted. You will of course have to physically copy the files to the new location when the service is down. USE master ; GO SELECT 'ALTER DATABASE [' + name + '] MODIFY FILE ( NAME = [' +  name + '], FILENAME = ''F:\MSSQL\Data\' + name + '.mdf'' ); ALTER DATABASE [' + name + '] MODIFY FILE ( NAME = [' + name + '_Log], FILENAME = ''E:\MSSQL\Log\' + name + '_Log.ldf'' ); GO ' FROM sysdatabases WHERE [sid] <> 0x01

If you need to know which users exist in every database on your server (as apposed to server logins) you can use the undocumented stored procedure  sp_msforeachdb    as in the example below: EXEC sp_msforeachdb 'USE [?];                      SELECT DB_NAME() As DBName                            ,name                      FROM sysusers                      ORDER BY name' This piece of code is ideal for a  Snippet .

This is a very handy piece of code that I have readily available. It is useful to use on servers that have dozens of SQL Agent jobs to find out who owns a job and whether it is enabled. By default when someone creates a job it sets their name as the owner which means if their account becomes disabled, they have left the company for instance, the job will no longer work. I've seen exactly this issue many times over the years. So every now and again I will run this piece of code to find who the owner is and then ask them to assign it to a more suitable account. USE MSDB ; GO SELECT j . NAME AS JobName        , u . NAME AS JobOwner        , j . enabled FROM sysjobs j LEFT JOIN master . sys . syslogins u        ON j . owner_sid = u . sid ORDER BY j . NAME This piece of code is ideal for a  Snippet .

On a server with a large number number of SQL Agent jobs the error log can become quite large. This can cause problems if it is located on the C: drive. The solution is to move it to a drive that is less critical or has more space by using this script. Replace the string within the angle brackets to an existing drive and folder. USE msdb;  GO EXEC msdb . dbo . sp_set_sqlagent_properties @errorlog_file = N'<New_Errorlog_Location>\SQLAGENT.OUT' GO   You will need to restart SQL Agent service for this change to take place. [This piece of code is ideal for a Snippet ]

To disable a SQL Agent job you can right click on it and choose Disable. The trouble is if you want to disable a large number of them at once this can be time consuming and a nuisance. You can also  disable a job by running the following command: EXEC msdb . dbo . sp_update_job @job_name = 'Your job name'        , @enabled = 0 You can get 'Your job name' from msdb.dbo.sysjobs so all we need to do is query that table and plug the result into the script below which will generate a list of scripts we can use: USE [msdb] GO SELECT    'EXEC msdb.dbo.sp_update_job @job_id=N''' + CONVERT ( NVARCHAR ( 36 ), job_id ) + ''',               @enabled=0 GO' , name FROM msdb . dbo . sysjobs WHERE name LIKE 'LSRestore_%' In this case I wanted to return all the jobs that are involved with a log ship restore. The results returned look like this: Click to enlarge To generate the script