SQL Server Down? Your Emergency Checklist for Rapid Recovery in Australia

Your SQL Server is down. Users are calling. Your phone won't stop. Every minute of downtime is costing your business money, and you're not sure where to start.

When SQL Server goes down, the fastest path to recovery is a structured diagnostic process: check SQL Server error logs first, confirm service status, identify whether you're dealing with a crash, corruption, or connectivity failure, then act on what you find. Most outages can be diagnosed within 15 minutes if you know where to look.

This checklist is built from over 20 years of responding to SQL Server emergencies across Australia. Use it right now.

Step 1: What to Check in the First 5 Minutes

Don't panic. Don't restart anything yet. A premature restart can destroy the diagnostic evidence you need to prevent this from happening again.

Work through these checks in order:

1. Confirm the SQL Server service is actually running. Open Services.msc or run SELECT @@VERSION from SSMS. If the service is stopped, check the Windows Event Log before you restart it.
2. Check the SQL Server Error Log. This is your most important diagnostic tool. Location: C:\Program Files\Microsoft SQL Server\MSSQL<version>.MSSQLSERVER\MSSQL\Log\ERRORLOG. Look for the most recent entries at the bottom.
3. Check Windows Application and System Event Logs. SQL Server errors almost always produce corresponding Windows events. Look for errors in the last 30 minutes.
4. Confirm disk space. A full data or log drive will bring SQL Server to its knees instantly. Run this quickly:

EXEC xp_fixeddrives;

This returns free space in MB for each drive. If any drive shows near zero, you've likely found your problem.

5. Check for blocking. If the service is running but users can't connect or queries are hanging, blocking is a common culprit.

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    status,
    command,
    sql_handle
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

6. Check active connections. Confirm whether the instance is accepting connections at all.

SELECT COUNT(*) AS active_connections 
FROM sys.dm_exec_sessions 
WHERE is_user_process = 1;

How to Fix a SQL Server Database in Emergency Mode

If your database has entered EMERGENCY mode, that's a serious signal. It means SQL Server has detected corruption and has restricted access to protect the data. The database will show as (Emergency) in SSMS.

Here's what you need to know before touching anything.

First, set the database to single-user mode and attempt a consistency check:

ALTER DATABASE YourDatabase SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB ('YourDatabase') WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

Review the CHECKDB output carefully. It will tell you the nature and extent of the corruption.

If CHECKDB reports errors and you have a recent clean backup, restore from backup. That is almost always the right answer. Repair options like REPAIR_ALLOW_DATA_LOSS do exactly what the name says - they may resolve the corruption by deleting the affected data. As Paul Randal (former Microsoft SQL Server lead) documented, EMERGENCY mode repair is a one-way operation and cannot be rolled back.

Only consider repair operations when you have no viable backup and the data loss from repair is acceptable. In that scenario:

DBCC CHECKDB ('YourDatabase', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
GO

After any repair, run CHECKDB again to confirm the database is clean, then return it to multi-user mode:

ALTER DATABASE YourDatabase SET MULTI_USER;
GO

If you're facing database corruption and you're not certain what you're doing, stop and get urgent SQL Server help from a qualified DBA. The wrong repair command can make data unrecoverable.

What Are the Most Common Causes of SQL Server Outages?

Based on real-world emergency response calls across Australia, the most frequent causes of SQL Server downtime are:

• Full transaction log. The log drive runs out of space and the database stops accepting writes. This accounts for roughly 35% of emergency calls we receive.
• Disk failure or storage issues. Particularly on ageing on-premise hardware. SAN or NAS connectivity problems can trigger SQL Server to take databases offline automatically.
• Memory pressure. SQL Server consuming all available RAM, leading to severe performance degradation or crashes.
• Blocking and deadlocks. Long-running transactions blocking other sessions, causing timeouts that look like an outage from the application side.
• Corruption. Hardware failures, improper shutdowns, or storage-layer issues can cause page-level corruption.
• SQL Server service account issues. Password expiry on the service account is a surprisingly common cause of unexpected restarts and failures.
• Failed SQL Server Agent jobs. Critical maintenance jobs (log backups, index rebuilds) failing silently for days before the consequences become an outage.

Knowing the cause matters because the fix is different for each one. Restarting SQL Server when the real problem is a full log drive will just take the database offline again within minutes.

How to Repair Microsoft SQL Server After a Crash

If SQL Server itself has crashed rather than just a database going offline, the recovery process is different.

Start with the SQL Server Error Log. Look for entries containing Error: 823, Error: 824, or Error: 825 - these indicate I/O errors. Error: 17 or Error: 18 relate to login and connectivity failures. Stack dumps in the error log (look for BEGIN STACK DUMP) indicate SQL Server encountered an internal exception.

After a crash, SQL Server performs automatic recovery on restart. When it comes back online, check the status of all databases:

SELECT name, state_desc, recovery_model_desc
FROM sys.databases
ORDER BY name;

Any database showing RECOVERY_PENDING, SUSPECT, or RESTORING needs immediate attention. A database in SUSPECT state has failed recovery and needs investigation before you can bring it back online.

For most crash scenarios, the recovery path is:

1. Restart SQL Server and allow automatic recovery to complete
2. Identify any databases that did not recover cleanly
3. Restore from the most recent clean backup plus transaction log backups
4. Verify data integrity with DBCC CHECKDB on all user databases
5. Investigate root cause before returning to production

Does Microsoft Still Support SQL Server? What Version Should You Be Running?

Yes, Microsoft still actively supports SQL Server. As of 2025, the supported versions are:

• SQL Server 2019 - Mainstream support ends 28 January 2025, Extended Security Updates available until 2030
• SQL Server 2022 - Mainstream support runs until 2027, Extended Support until 2032
• SQL Server 2025 - Currently in preview as of mid-2025

SQL Server 2016 and earlier are out of extended support entirely, meaning no security patches. Running unsupported SQL Server versions in production is a significant security and compliance risk, particularly for Australian organisations subject to the Privacy Act and the Australian Signals Directorate's Essential Eight framework.

Regarding SQL Server 2019 compatibility with Windows Server 2025: yes, SQL Server 2019 is supported on Windows Server 2025 according to Microsoft's official compatibility matrix. However, if you're migrating to Windows Server 2025, this is also a good opportunity to evaluate upgrading to SQL Server 2022 for improved security features and performance enhancements.

When Do You Need Emergency SQL Server Support in Australia?

Some situations you can work through yourself with this checklist. Others require immediate expert intervention.

Call for emergency SQL Server support in Australia when:

• You have database corruption and no tested backup
• The SQL Server service won't start after multiple attempts
• You're seeing data loss or suspect data integrity issues
• Your recovery time objective is being breached and you're stuck
• You're dealing with a ransomware attack affecting your SQL Server instances
• You've attempted repairs and the situation has worsened

Remote SQL Server support is often the fastest option for Australian businesses outside major metro areas. A senior DBA can connect via secure remote access within minutes and work through diagnostics in real time alongside your team. DBA Services provides 30-minute response times for critical outages, 24 hours a day, 7 days a week, with senior DBAs who have handled hundreds of production emergencies.

Key Takeaways

• Don't restart first. Check error logs before taking any action. A premature restart destroys diagnostic evidence.
• Full transaction logs cause roughly 35% of SQL Server outages. Check disk space immediately with xp_fixeddrives.
• EMERGENCY mode means corruption. Restore from backup if you have one. Only use REPAIR_ALLOW_DATA_LOSS as a last resort and understand it may delete data.
• Unsupported SQL Server versions are a real risk. SQL Server 2016 and earlier have no security patches. SQL Server 2022 is the recommended production version for new deployments.
• Remote SQL Server support can have a senior DBA working on your system within 30 minutes. You don't need to be in Sydney or Melbourne to get expert help fast.

What to Do Next

If you're in the middle of an outage right now, call DBA Services on 1800 SQL DBA (1800 775 322). We respond to critical SQL Server emergencies within 30 minutes, around the clock.

If you've recovered from this incident and want to make sure it doesn't happen again, a SQL Server Health Check is your most practical next step. Our health checks examine over 150 configuration points across your SQL Server environment, covering backup integrity, security configuration, performance baselines, and disaster recovery readiness. In our experience, more than 97% of SQL Server environments we assess have at least one misconfiguration that creates meaningful outage risk.

An outage that's already happened is the best warning you'll ever get. Use it.

Book a SQL Server Health Check with DBA Services