• How to Backup a SQL Server Database

    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…

    SQL Server Backup SSMS

    2. In the General tab of the prompted window you’ll see it’s already set-up for a Full Backup.

    SQL Server Backup Wizard

    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.

    SQL Server Backup Media Options

    5. In Backup Options, enable compression if available.

    SQL Server Backup Options

    6. Click Script to generate the SQL script for the backup (optional).

    SQL Server Backup Generate Script

    7. Click OK to start the backup.

    SQL Server Backup Script

    8. You should see a success prompt if done via SSMS GUI.

    SQL Server Backup Successful

    You have a backup of your database. I hope this was useful!

  • Restoring a Full Database Backup in SQL Server

    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.

    Restore Database SQL Server Management Studio

    3. Select Backup Source: Choose Device, click the ellipsis (), and locate your backup file.

    Restore Database SSMS Add Device
    SQL Server Restore Database Locate Backup

    4. Verify Backup Options: Check the database name and modify it if necessary under the General tab.

    SQL Server Restore Database Choose Backup File

    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.

    SQL Server Restore Database Backup Files

    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.

    SQL Server Restore Database Options

    7. Generate T-SQL Scripts: Before execution, click Script to create a T-SQL restore script for version control and automation.

    SQL Server Restore Database Generate Script

    >

    SQL Server Restore Database TSQL

    8. Execute the Restore: Click OK or execute the generated script.

    Restore Database in SQL Server Successful

    9. Verify the Restore: Refresh the Object Explorer to confirm the restored database exists.

    Restored Database in SQL Server

  • How to Properly Copy SQL Dates into Excel

    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.

    Copy SQL Data Highlight

    >>

    Copy SQL Date tp Excel

    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.

    Copy Data to Excel Format

    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:

    Copy SQL Data to Excel Smalldatetime

    Once pasted into Excel, the dates will appear correctly using Excel’s default cell format.

    Copy SQL Smalldatetime to Excel

    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)?

    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.

    Stack Exchange Data Explorer (SEDE)

    The interesting content is way down at number 24 (Database Administrator site) 😉

    Stack Exchange Data Explorer (SEDE) for SQL Server

    A neat feature I discovered by accident: running a query creates a fork, allowing you to modify and build upon existing work.

    Stack Exchange Data Explorer (SEDE) Test Queries

    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
    Stack Exchange Data Explorer My Query

    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

    sp_who, sp_who2 & sp_whoisactive

    Ever wondered what’s happening inside your SQL Server instance? sp_who, sp_who2 and sp_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 to sp_who and sp_who2. It doesn’t show system processes and provides valuable data, such as running full text of SQL queries and Execution Plans. I would

    Let’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.

    SQL sp_who

    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 beyond sp_who, making it slightly more informative.

    SQL sp_who2

    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. Download sp_whoisactive and execute the script in a query window.
    2. Run EXEC 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 a SELECT on the same table—it will get blocked.
    Now execute sp_whoisactive to see the blocking details.

    SQL Server Blocking SPID

    As you can see in the screenshot above, session_id 55 is blocking the SELECT 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.