How to: Find Currently Running Queries
You can use sys.dm_exec_requests DMV to list all requests. This view also contains a hash map of the SQL text – sql_handle, which can be passed to DMF sys.dm_exec_sql_text to get the query text:
SELECT REQUEST.session_id, REQUEST.start_time, QUERY.text
FROM sys.dm_exec_requests REQUEST
CROSS APPLY
sys.dm_exec_sql_text(REQUEST.sql_handle) QUERY
In case you are trying to find the query which is causing blocking, you can find the blocking session id by using sp_who or sp_who3.
Once you locate the blocking session id, it can be used to filter above results:
SELECT REQUEST.session_id, REQUEST.start_time, QUERY.text
FROM sys.dm_exec_requests REQUEST
CROSS APPLY
sys.dm_exec_sql_text(REQUEST.sql_handle) QUERY
WHERE REQUEST.session_id = 58
How to: Check SQL Agent Job History Using T-SQL
To check SQL Server Agent Job History you can use the Log File Viewer from SQL Server Management Studio.
Alternatively, you can also use the following T-SQL to check your job history.
SELECT [JobName] = JOB.name,
[Step] = HIST.step_id,
[StepName] = HIST.step_name,
[Message] = HIST.message,
[Status] = CASE WHEN HIST.run_status = 0 THEN 'Failed'
WHEN HIST.run_status = 1 THEN 'Succeeded'
WHEN HIST.run_status = 2 THEN 'Retry'
WHEN HIST.run_status = 3 THEN 'Canceled'
END,
[RunDate] = HIST.run_date,
[RunTime] = HIST.run_time,
[Duration] = HIST.run_duration
FROM sysjobs JOB
INNER JOIN sysjobhistory HIST ON HIST.job_id = JOB.job_id
/* WHERE JOB.name = 'Job1' */
ORDER BY HIST.run_date, HIST.run_time
Reference:
Refer to dbo.sysjobs and dbo.sysjobhistory on BOL for more information.
How to: Fix SQL Server Logins Using sp_change_login Procedure
The sp_change_users_login procedure has a specific purpose. It’s used to identify and correct users within a database which do not have a corresponding logins.
Execute the following query to see any users which do not have a corresponding login.
exec sp_change_users_login 'report'
Execute the following query which username that you need to fix.
sp_change_users_login ‘auto_fix’, ‘username‘
This only needs to be done when you are restoring a database from one server to another, and the logins on each server were created with seperated SIDs. An example of when this would happen is when you are restoring database from Production to QA.
Map an existing database user to a SQL Server login. If the login for a user has changed, use sp_change_users_login to link the user to the new login without losing user permission. The new login cannot be sa, and the user cannot be dbo, guest, or an INFORMATION_SCHEMA user.
This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify application that currently use this feature. Use ALTER USER instead.
How to: Change The Tempdb File Size
You could have been accidentally increased your tempdb data file to more than it actually needs and you have difficultly to reduce the size. Probably you have tried to resize it from the database properties or shrink the file, unfortunately it doesn’t make any changes to the file. The files size remain big.
For instance, your tempdb has 1GB, you accidentally increase it to 81GB which you actually plan to increase it to 8GB. Here is the solution.
First, you should reduce your tempdb file to the size smaller than your desire size.
DBCC SHRINKFILE (N'tempdev', '1024000KB'); --1GB
After that, you can change the tempdb file size to your desire file size.
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', SIZE = 8388608KB ); --8GB GO;
How to: Create Table From SQLPERF(LOGSPACE)
DBCC SQLPERF(LOGSPACE) provides transaction log space usage statistics for all databases. The script below allows you to extract the information and store it in a table.
--Turn off the message about the number of rows affected from being displayed.
SET NOCOUNT ON
--Create temp table
CREATE TABLE #temp (
[Database Name] varchar(100),
[Log Size (MB)] decimal (10,2),
[Log Space Used (%)] decimal (10,2),
[Status] varchar(1)
)
GO
--Insert SQLPERF(LOGSPACE) result into temp table
INSERT #temp EXEC ('DBCC SQLPERF (LOGSPACE)');
--List the result from temp table
SELECT * FROM #temp;
--Drop temp table
DROP TABLE #temp;
--Turn on the message about the number of rows affected from being displayed.
SET NOCOUNT OFF;
How to: Find Databases Without Full Backups
AS a production DBA, you need to make sure that your backup and restoration process is working perfectly fine. Everything else is secondary.
Below is the script which help you to determine missing full backup for all your databases.
SELECT d.name FROM sys.databases d LEFT OUTER JOIN msdb.dbo.backupset bs ON d.name = bs.database_name AND bs.backup_finish_date > d.create_date AND bs.type = 'D' WHERE bs.backup_set_id IS NULL AND d.recovery_model_desc <> 'SIMPLE'
How to: Find Last Restart of SQL Server
This DMV, sys.dm_os_sys_info, contains a column that holds the startup time for SQL Server. You can run the following command to find the start time.
SELECT sqlserver_start_time FROM sys.dm_os_sys_info
Activity Monitor Script to Find Head Blocker
I have been searching so long for this useful script. It produce similar result while you execute sp_who2 command. The best thing is you can filter the result. The following script is origin from SQLFRNDZ.com.
This is very handy useful script in production environment. Even the activity monitor does the same but when there is high server high activity then your activity monitor hangs and do not respond. Also it is not recommended to use activity monitor for long in production environments as it uses high resources.
SELECT [Session ID] = s.session_id, [User Process] = CONVERT(CHAR(1), s.is_user_process), [Login] = s.login_name, [Database] = ISNULL(db_name(p.dbid), N''), [Task State] = ISNULL(t.task_state, N''), [Command] = ISNULL(r.command, N''), [Application] = ISNULL(s.program_name, N''), [Wait Time (ms)] = ISNULL(w.wait_duration_ms, 0), [Wait Type] = ISNULL(w.wait_type, N''), [Wait Resource] = ISNULL(w.resource_description, N''), [Blocked By] = ISNULL(CONVERT (varchar, w.blocking_session_id), ''), [Head Blocker] = CASE -- session has an active request, is blocked, but is blocking others or session is idle but has an open tran and is blocking others WHEN r2.session_id IS NOT NULL AND (r.blocking_session_id = 0 OR r.session_id IS NULL) THEN '1' -- session is either not blocking someone, or is blocking someone but is blocked by another party ELSE '' END, [Total CPU (ms)] = s.cpu_time, [Total Physical I/O (MB)] = (s.reads + s.writes) * 8 / 1024, [Memory Use (KB)] = s.memory_usage * 8192 / 1024, [Open Transactions] = ISNULL(r.open_transaction_count,0), [Login Time] = s.login_time, [Last Request Start Time] = s.last_request_start_time, [Host Name] = ISNULL(s.host_name, N''), [Net Address] = ISNULL(c.client_net_address, N''), [Execution Context ID] = ISNULL(t.exec_context_id, 0), [Request ID] = ISNULL(r.request_id, 0), [Workload Group] = ISNULL(g.name, N'') FROM sys.dm_exec_sessions s LEFT OUTER JOIN sys.dm_exec_connections c ON (s.session_id = c.session_id) LEFT OUTER JOIN sys.dm_exec_requests r ON (s.session_id = r.session_id) LEFT OUTER JOIN sys.dm_os_tasks t ON (r.session_id = t.session_id AND r.request_id = t.request_id) LEFT OUTER JOIN ( -- In some cases (e.g. parallel queries, also waiting for a worker), one thread can be flagged as -- waiting for several different threads. This will cause that thread to show up in multiple rows -- in our grid, which we don't want. Use ROW_NUMBER to select the longest wait for each thread, -- and use it as representative of the other wait relationships this thread is involved in. SELECT *, ROW_NUMBER() OVER (PARTITION BY waiting_task_address ORDER BY wait_duration_ms DESC) AS row_num FROM sys.dm_os_waiting_tasks ) w ON (t.task_address = w.waiting_task_address) AND w.row_num = 1 LEFT OUTER JOIN sys.dm_exec_requests r2 ON (s.session_id = r2.blocking_session_id) LEFT OUTER JOIN sys.dm_resource_governor_workload_groups g ON (g.group_id = s.group_id)--TAKE THIS dmv OUT TO WORK IN 2005 LEFT OUTER JOIN sys.sysprocesses p ON (s.session_id = p.spid) ORDER BY s.session_id;
I have also attached the screenshot from SQLFRINDZ.com as below

How to: Check SQL Process % Complete
The following scripts origin from Mehernosh to help you to find out (SQL Server 2005 and onwards or with compatibility modes of 90 and higher) how long a particular Backup or restore on a database was taking or elapsed time.
USE MASTER GO SELECT SESSION_ID, '[' + CAST(DATABASE_ID AS VARCHAR(10)) + '] ' + DB_NAME(DATABASE_ID) AS [DATABASE], PERCENT_COMPLETE, START_TIME, STATUS, COMMAND, DATEADD(MS, ESTIMATED_COMPLETION_TIME, GETDATE()) AS ESTIMATED_COMPLETION_TIME, CPU_TIME FROM SYS.DM_EXEC_REQUESTS --Apply this Where Clause Filter if you need to check specific events --such as Backups, Restores, Index et al. WHERE COMMAND LIKE '%BACKUP%' OR COMMAND LIKE '%RESTORE%' OR COMMAND LIKE '%INDEX%' OR COMMAND LIKE '%DBCC%'
TEMPDB Should Always Have One Data File Per Processor Core
According to Microsoft’s Storage Top 10 Best Practices, it is recommended to have .25 to 1 data files (per filegroup) for each CPU on the host server (dual core counts as 2 CPUs). This is especially true for TEMPDB where the recommendation is 1 data file per CPU.
It’s also recommended to move TEMPDB to adequate storage and pre-size after installing SQL Server. Performance may benefit if TEMPDB is placed on RAID 1+0(dependent on TEMPDB usage). The data files should be of eaqual size as SQL Server uses a proportional fill algorithm that favors allocations in files with more space.
On the another hand, sometimes the recommendation might not always correct. Paul shared a very good example in his blog post,
I heard just last week of a customer who’s tempdb workload was so high that they had to use 64 tempdb data files on a system with 32 processor cores – and that was the only way for them to alleviate contention. Does this mean it’s a best practice? Absolutely not!
So, why is one-to-one not always a good idea? Too many tempdb data files can cause performance problems for another reason. If you have a workload that uses query plan operators that require lots of memory (e.g. sorts), the odds are that there won’t be enough memory on the server to accomodate the operation, and it will spill out to tempdb. If there are too many tempdb data files, then the writing out of the temporarily-spilled data can be really slowed down while the allocation system does round-robin allocation. The same thing can happen with very large temp tables in tempdb too.
In summary,
- It is recommended to have .25 to 1 data files (per filegroup) for each CPU on the host server (dual core counts as 2 CPUs).
- Sometime too many data files may also cause performance problems for another reason