SQL Server 2016镜像启动失败：数据库处于还原中（错误927）

Hey there, I’ve run into this exact Error 927 issue multiple times when setting up SQL Server mirroring—even when sticking strictly to official docs and walkthroughs. Let’s break down what’s likely going wrong with your WSS_Content_1 database on SQL Server 2016 Enterprise, and how to fix it.

First, Understand the Root Cause #

Error 927 tells us the mirror database isn’t in the required RESTORING state for mirroring to start. Even though you ran RESTORE WITH NORECOVERY, common missteps can throw this off:

• You might have missed restoring one or more transaction log backups from the primary server
• An accidental restore operation could have flipped the database to a RECOVERED state instead of keeping it in RESTORING
• The backup chain between primary and mirror is broken (e.g., you took an extra log backup on SQL1 but didn’t apply it to SQL2 before starting mirroring)

Step-by-Step Troubleshooting & Fixes #

1. Verify the Mirror Database State

First, confirm the mirror database is actually stuck in RESTORING on SQL2. Run this query on the mirror server:

SELECT name, state_desc 
FROM sys.databases 
WHERE name = 'WSS_Content_1';

If the result is anything other than RESTORING, you’ll need to re-restore the full backup + all subsequent log backups with NORECOVERY to get it back to the correct state.

2. Validate the Backup Chain

On the primary server (SQL1), check all backups for WSS_Content_1 to ensure you’ve applied every log backup to the mirror:

SELECT 
    backup_set_id,
    type, -- 'D' = Full backup, 'L' = Transaction log backup
    backup_start_date,
    physical_device_name
FROM msdb.dbo.backupset
JOIN msdb.dbo.backupmediafamily ON backupset.media_set_id = backupmediafamily.media_set_id
WHERE database_name = 'WSS_Content_1'
ORDER BY backup_start_date DESC;

• Start with the full backup you took first, restore it on SQL2 with NORECOVERY
• Then restore every single transaction log backup taken after that full backup, each time using WITH NORECOVERY
• Don’t skip any log backups—even a small, overlooked one will break the chain

3. Bypass SSMS Wizard Quirks

Sometimes the SSMS Mirroring Wizard hides subtle issues. Try setting up mirroring with raw T-SQL instead—it’s more transparent and reliable:

1. On the mirror server (SQL2), confirm the database is in RESTORING state, then run:

   ALTER DATABASE WSS_Content_1 
   SET PARTNER = 'TCP://SQL1:5022'; -- Replace with your primary server's endpoint address
   

2. On the primary server (SQL1), run:

   ALTER DATABASE WSS_Content_1 
   SET PARTNER = 'TCP://SQL2:5022'; -- Replace with your mirror server's endpoint address
   

3. If you’re using the witness server (SQL2\wtn), run this on the primary server next:

   ALTER DATABASE WSS_Content_1 
   SET WITNESS = 'TCP://SQL2\wtn:5022'; -- Replace with your witness endpoint address
   

4. Double-Check Endpoint Configuration

Make sure all servers’ mirroring endpoints are running and accessible:
On each server (SQL1, SQL2, SQL2\wtn), run:

SELECT name, state_desc 
FROM sys.endpoints 
WHERE type_desc = 'DATABASE_MIRRORING';

The state should be STARTED. If not, start the endpoint with:

ALTER ENDPOINT [MirroringEndpointName] STATE = STARTED;

Also confirm the service accounts for each SQL Server instance have permission to connect to the other servers’ endpoints (whether using Windows auth or certificates as configured).

Final Notes #

The most common fix here is ensuring you’ve applied all transaction log backups from the primary to the mirror with NORECOVERY. Even if you think you did it, double-check the backup chain—one missed log backup is almost always the culprit.

Once you’ve got the mirror database in the correct RESTORING state and the backup chain is intact, the mirror setup should complete without Error 927.

内容的提问来源于stack exchange，提问作者Burre Ifort