This has been an age old confusion ever since the Dynamic Management Views changed the way SQL Performance monitoring was done.
A SPID/Session ID will show up as Sleeping/Awaiting Command when it has no active work request that it needs to execute on the Database Engine. Consider the following scenario:
1. You connect to a SQL instance using Management Studio
2. You execute: SELECT @@SPID
3. You then open another SSMS query window and try and lookup the Session ID returned by the output of Step #2 using the DMV: sys.dm_exec_requests.
If you didn’t know of this behavior, then you will be in for a surprise! This is because the Session ID associated with the query in Step #2 has no active work to perform which is why the DMV didn’t report a row for that particular session. However, when you look up this session id using sys.dm_exec_connections or sys.sysprocesses. The reason sys.sysprocesses reports this SPID is because it doesn’t differentiate between a session with/without an active work request. It will report all SPIDs currently connected to the database engine.
The above behavior is expected and by-design.
Bob Dorr has mentioned about this in his post on the CSS SQL Escalation blog and also talks about how this can affect concurrency if such a session has open transactions:
How It Works: What is a Sleeping / Awaiting Command Session
I recently have developed an affinity for using Powershell. I saw a question on #sqlhelp hashtag for fetching database properties using Powershell. There are multiple posts out there on the web to do this using SMO. A crude way would be to use the Invoke-Sqlcmd cmdlet to do this.
Invoke-Sqlcmd -Query "SELECT filename,size,dbid FROM sys.sysaltfiles;"
If you wanted a cleaner output or some post processing done on the results fetched and wanted to use foreach, them this could also be done:
$dbprop = Invoke-Sqlcmd -Query "SELECT filename,size,dbid FROM sys.sysaltfiles;"
foreach ($db in $dbprop)
If you are using SQLPS, then the above command to give the information that you want by invoking SQLCMD using Powershell.
Other ways to do this are mentioned here:
Get SQL database size using Windows Powershell
Get database properties using PowerShell in SQL Server 2008 by Tim Chapman (Blog)
The ideal scenario for database mirroring would be to have the principal and secondary server instances be exact clones of each other from a hardware and disk space standpoint. This would ensure that the performance on the mirror instance is the same as the principal instance. But due to multiple constraints, this is not always possible. I recently had a question on how to move a secondary data file to a different physical location on the mirror instance. The catch here is that the physical data file locations on the principal and mirror instances are not the same. Now this can be tricky if not attempted or tested in your environment. The Microsoft SQLCAT(Twitter|Blog) team has a blog post on how to move the transaction log of a mirrored database to a secondary location. We shall use the same logic for the data file as well.
- If the server on which the data file relocation has to be done is not the mirror server currently, then failover the mirrored database so that the server on which the OS File has to be physically moved is the current Mirror.
- Change to High Performance mode if running under High Safety.
- Execute the ALTER DATABASE statement to move the data file to the new location on the mirror instance.
- Pause Mirroring to prevent any automatic failover while OS File Copy is happening.
- Stop the Mirror instance.
- Copy the file across to the new location (OS File Copy).
- Start the Mirror Instance.
- Resume mirroring and switch back to High Safety if the mirroring was running under High Safety. The mirroring should continue without any issues. Failback to original server if needed.
If the data file locations are the same on the principal and mirror and the data files need to be moved to different locations on both the server instances, then this is much easier. You would need to fire the ALTER DATABASE command on the principal server instance and then move the data files to the new location after failing over the database. The new data file location would take effect only after the server instance is restarted.