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.