Worth a shot.

Getting the latest user activity from a DMV

If you have configured monitoring, auditing, or extended events to capture this information, then you’ve lucked out. Otherwise, your easiest option is to go looking in sys.dm_db_index_usage_stats. This is a DMV that retains information about index operations, such as the last time a user seek was performed. Just keep in mind that most DMVs reset after SQL Server is restarted.

sys.dm_db_index_usage_stats on its own has all the information we need to check for user activity, but will only contain records for databases that have had activity since the last SQL Server restart. Since the point is to find databases with no recent activity, you will want to bring in sys.databases as well.

Source code

SELECT d.name
 
,MAX(i.last_user_lookup) last_user_lookup
 
,MAX(i.last_user_scan) last_user_scan
 
,MAX(i.last_user_seek) last_user_seek
 
,MAX(i.last_user_update) last_user_update
 
FROM sys.databases d LEFT join sys.dm_db_index_usage_stats i ON d.database_id = i.database_id
 
WHERE d.database_id > 4
 
GROUP BY d.name

None of my user databases have had any user activity since the SQL Server service was last restarted, so let’s generate some activity.

Now let’s check the DMV again.

There is our proof that the StackOverflowDW database is at least being queried, so we will want to do some more investigation to find out who or what is accessing the database.

A More Resilient Method

If it has been weeks or months since the SQL Server service has been restarted, then this would be a good indication that the StackOverflowMini and DBA databases are stagnant, while StackOverflowDW is active. But what if your servers are regularly restarted, planned or otherwise? Then you should set up a more resilient method for tracking this info.

If you are content with this data, it is easy enough to set up a SQL Agent job to persist it to a table. It is an easy-to-read dataset that is scoped to the server level, so you don’t need to query each individual database.

First, create the table. I am just going to use the master database.

Source code

USE master
 
CREATE TABLE LastUserActivity
 
(
 
database_name NVARCHAR(100)
 
,last_user_lookup DATETIME null
 
,last_user_scan DATETIME null
 
,last_user_seek DATETIME null
 
,last_user_update DATETIME null
 
,insert_date DATETIME DEFAULT GETDATE()
 
)

Then create a SQL Agent job to execute the query and load the results to your new LastUserActivity table. Make sure to add a cleanup step so the table size doesn’t get out of control.

Source code

INSERT INTO LastUserActivity
 
(
 
database_name
 
,last_user_lookup
 
,last_user_scan
 
,last_user_seek
 
,last_user_update
 
)
 
SELECT d.name
 
,MAX(i.last_user_lookup) last_user_lookup
 
,MAX(i.last_user_scan) last_user_scan
 
,MAX(i.last_user_seek) last_user_seek
 
,MAX(i.last_user_update) last_user_update
 
FROM sys.databases d LEFT join sys.dm_db_index_usage_stats i ON d.database_id = i.database_id
 
WHERE d.database_id > 4
 
GROUP BY d.name

Schedule the job to run as frequently as you would like. Running daily should be more than sufficient.

Source code

SELECT database_name
 
,last_user_lookup
 
,last_user_scan
 
,last_user_seek
 
,last_user_update
 
,insert_date
 
FROM master.dbo.LastUserActivity

You’ve Done It

Now you will always have a small dataset with the latest activity for each database, making it much easier to find stagnant databases.

The post “Is anyone still using this database?” How to find stagnant databases appeared first on SQL Solutions Group.

I will go through a couple of common scenarios that we frequently encounter and give T-SQL and PowerShell solutions.

Is Max Memory Set Appropriately?

Let’s start small: Finding max memory values and evaluating if they are appropriate.

T-SQL Script:

Source code

SELECT mem.total_physical_memory_kb / 1024 'server memory (MB)'
 
,configs.value_in_use 'max server memory (MB)'
 
FROM sys.dm_os_sys_memory mem
 
cross apply (
 
SELECT value_in_use
 
FROM sys.configurations
 
WHERE name = 'max server memory (MB)'
 
) configs

T-SQL Results:

With that information, I can make a determination if Max Memory is set appropriately. If not, I can calculate an appropriate value and go implement the change.

PowerShell Script:

Source code

Test-DbaMaxMemory -SqlInstance SSG-LT-KBURWELL

PowerShell Results:

Again, this is a basic example, and the T-SQL isn’t exactly complex, but the PowerShell is much easier and even gives you a recommendation for Max Memory.

LastFullBackup

The T-SQL for this is also rather easy, but the tricky part is running it against multiple instances and returning a single result set.

T-SQL Script:

Source code

SELECT database_name
 
,MAX(backup_start_date) latest_full
 
FROM msdb.dbo.backupset s
 
WHERE s.type = 'D'
 
GROUP BY s.database_name

T-SQL Results:

As I mentioned, this is a very simple script, but this is only for one instance. If you want to run this against multiple instances, you will need to do some additional setup, such as configuring linked servers or a Central Management Server, neither of which I will be detailing here. Instead, I will show how easy it is to query multiple instances in PowerShell.

PowerShell Script:

Source code

Get-DbaLastBackup -SqlInstance SSG-LT-KBURWELL

PowerShell Results:

One simple command and I get the same info, plus details for latest diff and log backups as well. Now let’s make a couple of changes so we can get results for multiple instances and make the output a little more friendly.

PowerShell Script:

Source code

Get-DbaLastBackup -SqlInstance SSG-LT-KBURWELL,SSG-LT-KBURWELL\MSSQLSERVER01 -ExcludeDatabase msdb,model,master | Format-Table

I made 3 minor changes to the script, but it is still a single line of code and now reads from multiple instances and formats the output as a table.

• Change 1: Added an additional SQL instance to the -SqlInstance parameter.
• Change 2: Added the -ExcludeDatabase parameter and passed in the system databases.
• Change 3: Piped the results to Format-Table

PowerShell Results:

Let’s take it one step further and generate a spreadsheet from the results.

PowerShell Script:

Source code

Get-DbaLastBackup -SqlInstance SSG-LT-KBURWELL,SSG-LT-KBURWELL\MSSQLSERVER01 -ExcludeDatabase msdb,model,master | Export-Excel -Path C:\Temp\LastBackups.xlsx

Instead of piping the results to Format-Table, I am piping the results to Export-Excel and providing a file path and name. Now I have a spreadsheet that I can share with whomever might want to see it.

Getting results from SSMS into Excel is obviously possible, it just requires extra manual steps. It’s much quicker to just have PowerShell do it for you.

“It’s easier”

When I say PowerShell is easier, I’m not just talking about the simplicity of commands. I’m also talking about how easy it is to add in functionality, such as querying multiple instances, combining the results, and exporting them to Excel.

If you are perfectly happy using T-SQL and SSMS, then by all means, continue to do so. But, I do encourage you to explore PowerShell, specifically the DBATools module. I will be following up this post with more complex Powershell examples such as copying databases between SQL instances and keeping AG objects synchronized between replicas. Stay tuned for more answers to the question “why use PowerShell?”

The post Why use PowerShell when you can use T-SQL? appeared first on SQL Solutions Group.

Getting Started

If you haven’t already, make sure you have DBATools installed. We are going to be using a command called Get-DbaDbFile to gather the information for us. This command only requires one parameter, -SqlInstance. Here is a snippet of what I get when I run it against my local dev instance:

This is a bit more information than we really need right now, so let’s trim it down and get some parameters added. For this script, we really only need SqlInstance, Database, TypeDescription, LogicalName, PhysicalName, Size, UsedSpace, and AvailableSpace. We can also exclude system databases from the result set. For readability, I am going to use Format-Table. I will also start to add in some parameters:

Source code

$SqlInstance = "SSG-LT-KBURWELL"
 
Get-DbaDbFile -SqlInstance $SqlInstance
 
Get-DbaDbFile -SqlInstance $SqlInstance -ExcludeDatabase master,model,msdb,tempdb |
 
    Select-Object SqlInstance, Database, TypeDescription, LogicalName, PhysicalName, Size, UsedSpace, AvailableSpace | Format-Table

Using Custom Objects

This will be much easier to work with, but it is important to be aware that the columns related to file size have GB, MB, and KB values, depending on what is most appropriate for that file size. This is great when just looking at the data like this, but can be a bit problematic for mathematical comparisons, which we will be doing later. To get around this, we can just use some custom objects:

Source code

$SqlInstance = "SSG-LT-KBURWELL"
 
Get-DbaDbFile -SqlInstance $SqlInstance -ExcludeDatabase master,model,msdb,tempdb |
 
    Select-Object SqlInstance, TypeDescription, LogicalName, PhysicalName,
 
     @{Name='DatabaseName'; Expression={$_.Database}},
 
     @{Name='SizeMB'; Expression={ [math]::Round($_.Size / 1MB, 2) }},
 
     @{Name='UsedSpaceMB'; Expression={ [math]::Round($_.UsedSpace / 1MB, 2) }},
 
     @{Name='AvailableSpaceMB'; Expression={ [math]::Round($_.AvailableSpace / 1MB, 2) }},
 
     @{Name='FreeSpacePercent'; Expression={
 
    if ($_.Size -gt 0) {
 
        $sizeMB = [math]::Round($_.Size / 1MB, 2)
 
        $availMB = [math]::Round($_.AvailableSpace / 1MB, 2)
 
        [math]::Round(($availMB / $sizeMB) * 100, 2)
 
        } else { 0 }
 
    }},
 
    @{Name='CaptureTimestamp'; Expression={ Get-Date -Format "yyyy-MM-dd HH:mm:ss" }}
 
    | Format-Table

This converts all sizes to MB, which will make any mathematical operations much easier. I also included a custom object for DatabaseName, FileSpacePercent, and CaptureTimestamp. DatabaseName really just acts as a custom column name, which is necessary when loading the data into SQL.

On To The Comparisons

Now that we are getting only the data we need, we need to save it to a table so we can do point in time comparisons. As with everything else, DBATools makes this ridiculously easy. We just need to point it to an instance and a database, it will take care of the rest. Instead of piping our results to Format-Table, I am going to pipe them to a command that will build and load a SQL table:

Source code

$SqlInstance = "SSG-LT-KBURWELL"
 
$WriteInstance = "SSG-LT-KBURWELL"
 
$WriteDB = "DBA"
 
$WriteTable = "FileSizesAndUsage"
 
Get-DbaDbFile -SqlInstance $SqlInstance -ExcludeDatabase master,model,msdb,tempdb |
 
    Select-Object SqlInstance, TypeDescription, LogicalName, PhysicalName,
 
     @{Name='DatabaseName'; Expression={$_.Database}},
 
     @{Name='SizeMB'; Expression={ [math]::Round($_.Size / 1MB, 2) }},
 
     @{Name='UsedSpaceMB'; Expression={ [math]::Round($_.UsedSpace / 1MB, 2) }},
 
     @{Name='AvailableSpaceMB'; Expression={ [math]::Round($_.AvailableSpace / 1MB, 2) }},
 
     @{Name='FreeSpacePercent'; Expression={
 
    if ($_.Size -gt 0) {
 
        $sizeMB = [math]::Round($_.Size / 1MB, 2)
 
        $availMB = [math]::Round($_.AvailableSpace / 1MB, 2)
 
        [math]::Round(($availMB / $sizeMB) * 100, 2)
 
        } else { 0 }
 
    }},
 
    @{Name='CaptureTimestamp'; Expression={ Get-Date -Format "yyyy-MM-dd HH:mm:ss" }}
 
    | Write-DbaDbTableData -SqlInstance $WriteInstance -Database $WriteDB -Table $WriteTable -AutoCreateTable

Now I have the data in SQL Server:

With this information being collected regularly, via scheduled task or agent job, we can easily trend out how much our database files are growing. It will also make potential misconfigurations stand out, such as a 1TB mdf with 99% free space. Personally, I use it in client environments to find over-allocated files that can be shrunk to reclaim some space. I know, “shrink bad”, but sometimes you just need to do it. As you can see, it’s quite straightforward and rather easy to track database file sizes with Powershell!

The post Track Database File Sizes with PowerShell: A Quick Guide for DBAs appeared first on SQL Solutions Group.

Then I go and find the answer myself. There are a bunch of ways to get this info, but I find querying MSDB the easiest:

Source code

SELECT d.name database_name
 
,MAX(backup_finish_date) last_backup_date
 
,CURRENT_TIMESTAMP right_now
 
FROM sys.databases d LEFT join msdb.dbo.backupset b ON d.name = b.database_name and b.type = 'D' -–ONLY concerned about FULLs RIGHT now
 
GROUP BY d.name

Now I know that I need to dig deeper into the backup strategy in place. This typically starts with firing off a couple of questions to whomever is responsible for the database.

1. Did you know that we’re not backing up (insert database name here)?
2. Is this intentional?

During the conversation that follows, it sometimes comes to light that the database owner does have backups configured for the database in question, or at least they think they do. This is where the misconception about SQL Server backups comes in: that file-level backups of the database files are the same thing or as good as a native SQL Server backup of the database. This  simply isn’t true.

The Key Differences

While they both have their uses and can definitely be used in conjunction with one another, you need to have native SQL backups of your databases.

Why? There are dozens of reasons, but here are the two I bring up the most:

1. Transaction safety/consistency: Native backups maintain ACID compliance while file-level backups may capture transactions in-flight.
2. RTO/RPO: Native backups, when configured correctly, make Point-in-time recovery possible. You don’t get this with file-level backups.

This isn’t to say that you can’t or shouldn’t use a third party utility to perform these backups; some of those utilities integrate really well with SQL Server. You just need to know what is being backed up and how to verify. This is where MSDB comes in again. Even third party utilities will generate a record when they perform a native SQL Server backup:

So in sum, file-level backups are great. Just make sure you are also performing and testing native backups. And don’t forget your system databases!

The post A Common Misconception About SQL Server Backups appeared first on SQL Solutions Group.