-
How to Backup a SQL Server Database
Ensuring regular backups of your SQL Server database is essential for data protection and disaster recovery. Whether you prefer using SQL commands or SQL Server Management Studio (SSMS), this guide will walk you through both methods.
Backing Up a SQL Server Database Using T-SQL
If you want a quick and efficient way to back up your database, use the following SQL command:
-- Perform full backup of database BACKUP DATABASE [YourDatabaseName] TO DISK = N'C:\Backups\YourDatabaseName.bak' WITH FORMAT, COMPRESSION, STATS = 10;
That’s what I’m used to writing. I’ve no need to worry about the copy_only option these days, or check SQL Server Editions to see if I can use compression. Good times that was. Measuring available disk space against estimated backup sizes, and sometimes even adding temporary virtual disks to the server to accommodate the backup file size. The SQL statement for backups is simple… but there’s a lot to consider when performing a one. It just depends on the restrictions of the servers you are working with really.
Below is a simple run-through for backing up a database using the Back Up Database Wizard. As always, have a look at the manual first.
Backing Up a SQL Server Database Using SSMS
If you prefer a graphical approach, follow these steps.
1. Right click your database, select Tasks and click Back Up…
2. In the General tab of the prompted window you’ll see it’s already set-up for a Full Backup.
3. Choose a destination and specify a file name ending in
.bak
.4. In Media Options, choose whether to verify the backup or perform checksum validation. Review all other available options too before you proceed to the next tab.
5. In Backup Options, enable compression if available.
6. Click Script to generate the SQL script for the backup (optional).
7. Click OK to start the backup.
8. You should see a success prompt if done via SSMS GUI.
You have a backup of your database. I hope this was useful!
-
Restoring a Full Database Backup in SQL Server
In this post I’m sharing a demo of restoring a Full database backup using the SQL Server Management Studio (SSMS) Restore Database Wizard.
I often find myself running through the SSMS Restore Database Wizard and scripting out the SQL to a new query window when running an ad-hoc database restore. This makes it easier particularly for when databases are split into multiple data files across many different drives.
Full Backups in SQL Server capture the entire database, including all data and the transaction log necessary for restoring the database to its exact state at the time of backup. They form the foundation of any good backup strategy, and are needed for reliable disaster recovery of your SQL Server data.
Restore using SSMS Restore Database Wizard
1. Open SQL Server Management Studio (SSMS) and connect to the SQL Server instance.
2. Start the Restore: Right-click on Databases and select Restore Database.
3. Select Backup Source: Choose Device, click the ellipsis (…), and locate your backup file.
4. Verify Backup Options: Check the database name and modify it if necessary under the General tab.
5. Define File Locations: Use the Files tab to specify paths for your data (.mdf) and log (.ldf) files. I’m often checking the relocate all files to folder option for restores.
6. Set Recovery Options: On the Options tab, choose the appropriate recovery state:
– STANDBY: Keep the database in read-only mode.
– WITH RECOVERY: Make the database ready for immediate use.
– NORECOVERY: Allow additional restores.7. Generate T-SQL Scripts: Before execution, click Script to create a T-SQL restore script for version control and automation.
>
8. Execute the Restore: Click OK or execute the generated script.
9. Verify the Restore: Refresh the Object Explorer to confirm the restored database exists.
-
How to Properly Copy SQL Dates into Excel
When copying a SQL query result directly into Excel, DATETIME columns often don’t display as expected. Excel doesn’t seem to handle milliseconds well, making the dates appear messy.
The Issue: Excel Precision Struggles
Here’s an example of data I copied over from SQL Server into an Excel sheet.
>>
The DATETIME values don’t format properly, causing readability issues. It’s shows 00:00:0 instead of the dates.
Excel doesn’t recognize the format type and doesn’t know how to display the data.
The Fix: Convert to SMALLDATETIME
To ensure proper formatting, convert the DATETIME columns to SMALLDATETIME before copying the data into Excel. SMALLDATETIME removes milliseconds, making the values more Excel-friendly.
Example SQL query:
Once pasted into Excel, the dates will appear correctly using Excel’s default cell format.
I’d be interested to know if there’s an easier way to sort this on the Excel side. For now, the above does the trick for me.
-
What is Stack Exchange Data Explorer (SEDE)?
As a DBA, I’ve found Stack Exchange Data Explorer (SEDE) to be an invaluable tool for analyzing data from the Stack Exchange network. It’s essentially a web-based SQL playground, allowing you to run queries and uncover hidden insights without downloading any data. Just open the tool, write a query, and explore the results.
Why I Like SEDE
No setup required – It’s entirely web-based.
Pre-built queries – Use existing queries on topics like user activity, Q&A stats, and tag trends.
Easy sharing – Share your queries and visualizations with the Stack Exchange community.The interface is smooth and intuitive. Each Stack Exchange site has its own database, and you can browse queries others have created or write your own.
The interesting content is way down at number 24 (Database Administrator site) 😉
A neat feature I discovered by accident: running a query creates a fork, allowing you to modify and build upon existing work.
The top query above is my one. Here’s my example query that finds the top 10 most-viewed posts from the past year:
-- stack exchange data explorer, show top posts since last year SELECT TOP 10 Title, ViewCount, Score, Tags, CommentCount FROM Posts WHERE CreationDate > DATEADD(year, -1, GETDATE()) ORDER BY ViewCount DESC
This is a great way to see trending topics and refine your SQL skills.
If you’re a DBA, data analyst, or just someone who enjoys working with data, SEDE is worth checking out. It’s a fun, powerful tool that makes exploring Stack Exchange data easy and engaging. I hope this was useful for you and you have already navigated away to check it out!
-
sp_who, sp_who2 & sp_whoisactive
Ever wondered what’s happening inside your SQL Server instance?
sp_who
,sp_who2
andsp_whoisactive
are stored procedures that allow you to view current users, sessions, and processes within a SQL Server instance. This kind of information helps you diagnose blocking issues and monitor general activity.Among them,
sp_whoisactive
is a go-to tool for many SQL DBAs & Software Engineers. Created by Adam Machanic, it offers a much richer set of details compared tosp_who
andsp_who2
. It doesn’t show system processes and provides valuable data, such as running full text of SQL queries and Execution Plans. I wouldLet’s take a closer look at these three procedures and how they can help with SQL Server monitoring and troubleshooting.
sp_who
sp_who
retrieves information on all active processes in SQL Server at the time of execution. It includes login names, hostnames, current commands being run (not full SQL text), and target databases.The first 50 results are system SPIDS which you’d never try kill. If you’re looking terminating SQL SPIDs, check out my other post: Killing SQL Server Processes.
sp_who2
sp_who2
is an undocumented stored procedure by Microsoft, meaning it could be modified or deprecated without notice. It offers additional columns beyondsp_who
, making it slightly more informative.In my other post I share a simple SQL script that logs
sp_who2
results into a temporary table, allowing you to filter and sort sessions in SQL for review. This can be especially useful when investigating blocking issues, long-running queries, or hidden inactive SPIDs that standard scripts might miss.sp_whoisactive
Now, this is where things improve.
sp_whoisactive
provides a comprehensive snapshot of SQL Server’s current activity. Info includes full SQL queries, query plans, hardware usage, temp DB allocations, blocks and more. This 4 minute video by Brent Ozar gives the perfect run-through of it:To try it yourself, follow these steps:
1. Downloadsp_whoisactive
and execute the script in a query window.
2. RunEXEC sp_whoisactive;
to see active sessions.
3. If your test environment is empty, simulate a blocking scenario:
— Open a session and start an explicit transaction without committing.
— In another session, run aSELECT
on the same table—it will get blocked.
— Now executesp_whoisactive
to see the blocking details.As you can see in the screenshot above,
session_id 55
is blocking theSELECT
statement from being run. As mentioned above in this post, you might want to kill the lead blocker in SQL if it’s causing a bottleneck.Most of the time, I run
sp_whoisactive
without parameters or use@get_plans = 1
to capture execution plans. Depending on the situation, additional parameters can provide more useful info.A great way to leverage this stored proc is by running it as a SQL Agent job every 30–60 seconds, storing results into a table for historical analysis.
I hope all this was useful for you! Cheers.