Msg 4214, Level 16, State 1, Line 1
BACKUP LOG cannot be performed because there is no current database backup.
Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.

In a future blog post, I will go into why users resort to this bad practice and what they should be doing instead.

This solution is based on a great blog post from Kalen Delaney (blog, Twitter), that showed how the [sys].[database_recovery_status] catalog view can reveal databases suffering from this problem, using a query like so:

SELECT DB_Name([database_id]) AS [DatabaseName]
FROM [sys].[database_recovery_status]
WHERE (
    ([last_log_backup_lsn] IS NULL)
    AND
    (Cast(DatabasePropertyEx(DB_Name([database_id]), 'Recovery') AS NVarChar(16)) = N'FULL')
    AND
    (Cast(DatabasePropertyEx(DB_Name([database_id]), 'Status') AS NVarChar(16)) = N'ONLINE')
)
ORDER BY [DatabaseName] ASC;

The following PowerShell function uses the query to retrieve a list of problematic databases and then automatically backs up each one:

Function Repair-LogBackupChain (
    [String]$ServerName = $(Throw (New-Object -TypeName 'System.ArgumentNullException' -ArgumentList '$ServerName')),
    [String]$BackupDirectoryPath = $(Throw (New-Object -TypeName 'System.ArgumentNullException' -ArgumentList '$BackupDirectoryPath')),
    [String]$OutputDirectoryPath = $(Throw (New-Object -TypeName 'System.ArgumentNullException' -ArgumentList '$OutputDirectoryPath'))
) {
    [Int]$BackedUpDatabaseCount = 0;
    [String]$BackupFilePath = '';
    [String]$DatabaseName = '';
    [String]$ErrorMessage = '';
    [String]$OutputFilePath = '';
    [String]$Query = "SET NOCOUNT ON; SELECT DB_Name([database_id]) AS [DatabaseName] FROM [sys].[database_recovery_status] WHERE (([last_log_backup_lsn] IS NULL) AND (Cast(DatabasePropertyEx(DB_Name([database_id]), 'Recovery') AS NVarChar(16)) = N'FULL') AND (Cast(DatabasePropertyEx(DB_Name([database_id]), 'Status') AS NVarChar(16)) = N'ONLINE')) ORDER BY [DatabaseName] ASC;";
    [String]$TSQLCode = '';

    #   Create the necessary directories, if they don't already exist.
    $BackupDirectoryPath = Add-Directory -Path $BackupDirectoryPath;
    $OutputDirectoryPath = Add-Directory -Path $OutputDirectoryPath;

    #   Lookup the names of the databases, in the full recovery model, that 
    #   lack an intact transaction log backup chain.
    [String[]]$DatabaseNames = @(& 'SQLCmd.exe' -E -S $ServerName -d 'tempdb' -Q $Query -b -h-1 -W);
    $DatabaseNames | Write-Debug;

    #   Verify that the list of databases was successfully retrieved.
    If ((Get-Item -Path Variable:'LastExitCode').Value -eq 0) {
        #   Iterate through the databases that need backups.
        $DatabaseNames | ForEach-Object {
            $DatabaseName = $_;
            Write-Host "Backing up the [$($DatabaseName)] database..." -ForegroundColor 'Cyan';

            $OutputFilePath = "$($OutputDirectoryPath)$(Get-EscapedFileNameComponent -FileNameComponent $ServerName),Backup database,$(Get-EscapedFileNameComponent -FileNameComponent $DatabaseName),$([DateTime]::Now.ToString('yyyyMMddTHHmmssfff')).out";
            Write-Debug "`$OutputFilePath = `"$($OutputFilePath)`"";

            #   Construct the name of the backup file.
            $BackupFilePath = [String]::Format(
                '{0}{1}_{2}_{3}.bak',
                $BackupDirectoryPath,
                (Get-EscapedFileNameComponent -FileNameComponent $ServerName),
                (Get-EscapedFileNameComponent -FileNameComponent $DatabaseName),
                ([DateTime]::Now.ToString('yyyyMMddTHHmmssfff'))
            );

            #   Generate the T-SQL for backing up the database.
            $TSQLCode = [String]::Format(
                "BACKUP DATABASE [{0}] TO DISK = N'{1}';",
                $DatabaseName,
                $BackupFilePath
            );
            Write-Debug "`$TSQLCode = `"$($TSQLCode)`"";

            #   Backup the database.
            & 'SQLCmd.exe' -E -S $ServerName -d 'tempdb' -Q $TSQLCode -o $OutputFilePath -b;

            If (Test-Path -LiteralPath $BackupFilePath -PathType 'Leaf') {
                $BackedUpDatabaseCount++;
            }
            Else {
                $ErrorMessage = "There was a problem backing up the [$($DatabaseName)] database.";
                Throw (New-Object -TypeName 'System.InvalidOperationException' -ArgumentList $ErrorMessage);
            }
        }
    }
    Else {
        $ErrorMessage = [String]::Format(
            "There was a problem querying the [sys].[database_recovery_status] catalog view:`r`n{0}",
            (
                [String]::Join(
                    "`r`n",
                    $DatabaseNames
                )
            )
        );
        Throw (New-Object -TypeName 'System.InvalidOperationException' -ArgumentList $ErrorMessage);
    }

    Write-Host "A total of $($BackedUpDatabaseCount) database(s) was/were backed up." -ForegroundColor 'Green';

    Return;
}

Here’s an example of using the function:

Repair-LogBackupChain -ServerName 'DatabaseServer01\InstanceA' -BackupDirectoryPath 'C:\Temp\' -OutputDirectoryPath 'C:\Temp\';

Note: The code snippet is dependent on two functions that are included in the download for my PowerShell cookbook presentation, Add-Directory and Get-EscapedFileNameComponent.

Maybe by the time that I write the follow-up blog post, I will have received permission to break the customer of this nasty habit (using a tip from Paul Randal (blog, Twitter)).

Hopefully this PowerShell snippet will save you as much time as it has for me!

I’m a big proponent of using server-side traces for troubleshooting deadlocks. During my deadlocks presentation, I show how to manually extract XML deadlock graphs using SQL Server Profiler:

That works, but it’s a manual process, which is anathema to us automation adherents.

When processing XML deadlock graphs, I tend to:

1. query the trace data, via the [sys].[fn_trace_gettable] system function,
2. cast the [TextData] value to the XML data type, then
3. analyze the deadlocks with XQuery.

I can see the benefit of having a few loose *.XDL files, so I spent a little time writing a PowerShell script that will automatically extract the XML deadlock graphs and save them as files. This zip archive contains the script and sample trace files.

Here is an example of using the script (assuming that you extracted the files to the “C:\Temp\” directory):

[String]$ScriptUtilityPath = 'C:\Temp\Export-XDLFromTraceFile.ps1';
[String]$OutputDirectoryPath = 'C:\Temp\';
[String]$SourceServerName = 'T-SQL001';
[String]$TraceFilePath = 'C:\Temp\DeadlockTrace_20100522T113514.trc';
& $ScriptUtilityPath -TraceFilePath $TraceFilePath -OutputDirectoryPath $OutputDirectoryPath -SourceServerName $SourceServerName -FormatXML | Out-Null;

Here’s another example that leverages PowerShell’s composable nature:

[String]$ScriptUtilityPath = 'C:\Temp\Export-XDLFromTraceFile.ps1';
[String]$OutputDirectoryPath = 'C:\Temp\';
[System.IO.FileInfo[]]$OutputFiles = @();
[String]$SourceDirectoryPath = 'C:\Temp\';
[String]$SourceServerName = 'T-SQL001';
[String]$TraceFilePath = '';
Get-ChildItem -LiteralPath $SourceDirectoryPath -Filter '*.trc' | ForEach-Object {
    $TraceFilePath = $_.FullName;
    $OutputFiles += @(& $ScriptUtilityPath -TraceFilePath $TraceFilePath -OutputDirectoryPath $OutputDirectoryPath -SourceServerName $SourceServerName -FormatXML);
}
$OutputFiles | Select-Object -Property Name, @{Name='Size_bytes'; Expression={'{0:N0}' -f $_.Length}} | Format-Table -AutoSize;

Let me know if this is useful to you, or if you have any suggestions to make it better.

NOTE: I haven’t had a chance to test the script with the SQL Server 2005 SQL Server Management Objects (SMO) assemblies. I suspect one or both of the following issues:

• Classes may reside in different assemblies—SMO has a less than stellar history of backward compatibility
• The sample trace files were created on a SQL Server 2008 R2 instance, so they probably cannot be opened by the 9.0 tools

As I mentioned previously, I’ve been adding to and improving the demonstrations for the SQLDiag presentation. I was satisfied with the code (in terms of functionality, it still needed polishing and testing) until last week, when I got an escalation call about end-user complaints of poor performance with a customer’s application. This type of case calls for the techniques covered in my presentation. I then realized that October has been a bit of a dry spell in terms of complex issues that merited these techniques.

I ended up seeing a number of opportunities to further automate the process, pleased with the dual benefit of 1.) helping to solve the issue for the customer and 2.) having more to share with my audiences. For example, I finally created a PowerShell script that automatically extracts a single SQLDiag data set from a 7-Zip archive and loads it into PAL and SQL Nexus. This saves an immense amount of time! The downside is that I added a significant set of new scripts that have to be refined and tested (but they are absolutely worth it!).

I have been putting the release of the presentation materials above many other tasks (including blogging, participating on forums, and many responsibilities in my personal life), which has really added to my stress level. It’s time to reprioritize… I need to enjoy some down-time with my wife, tie up a few loose ends at work, and prepare for the PASS conference. I’m sorry to postpone further, but on the other hand, the quality and quantity of deliverables will be much greater this way. I’m sure that you’ll find it worth the wait!

Expect the presentation materials the week of November 9th.

Sometimes it’s necessary to determine the version of Windows Installer present on a system. The installation package for new products may be designed to use a feature added to a specific version of Windows Installer. It can be helpful to know whether you need to upgrade Windows Installer before attempting deployment of the new product.

According to the Windows Installer Team, the best way to determine the version of Windows Installer is to examine the version of the “MSI.dll” file. The following PowerShell command lines do this.

NOTE: Sometimes I choose to issue individual PowerShell command lines rather than running a script. I’ll explain this later, but even for very long command lines, they can be pasted into the command window without any problems. It doesn’t matter if they wrap. Also, you can paste several lines at once.

The command lines are:

I want to thank two friends and mentors who helped me to secure this opportunity, Peter DeBetta (blog, Twitter) and Jason Massie (blog, Twitter). Both are SQL Server MVPs that I met through the North Texas SQL Server Users Group. Each has presented at previous PASS conferences and sat on committees to select conference speakers (Peter for DevTeach/SQLTeach and Jason for the PASS Summit). Their advice has helped me get into speaking at the local user groups, position my abstracts for selection, and simply grow as a SQL Server professional!

Here are the details on my session:

I’ll post information on this blog as I refine the presentation and its demonstrations over the next few months.

Since it was an introduction to PowerShell, the information was a bit below my skill level. However, I did glean a few gems of knowledge. Most of all, I found Buck’s presentation style very appealing. Now I’m really going to have to listen to episode 41 of SQL Down Under.

Anyway, at the end of the presentation, Buck announced that, courtesy of SQL Server MVP Rick Heiges, a Microsoft Thrive card would be awarded to the person that sent Buck the best PowerShell/SQL Server script.

I wrote a utility for myself back in January. Sometimes when I get an escalation call, the front-line support personnel simply jump in with “I received an alert with error ___.” Very few error codes are committed to my memory, so this doesn’t provide much information to me. My utility simply looks up the error message in the [master].[sys].[messages] table and then presents it in a web page.

I’ve been planning to publish the script utility on this blog for a little while, but just haven’t gotten around to it. It’s simple, but pretty useful.

I decided to submit it for Buck’s contest, and (amazingly) I won! Woohoo! Check out the announcement on Buck’s blog: And the Winner is – Get SQL Server Error Messages from PowerShell.

When I redeemed the Microsoft Thrive, I received a voucher for a free certification exam. I need to update my certifications, so this is very serendipitous. The bigger deal, though, is the recognition.