SQL Server on Google Cloud SQL - Database stuck in RECOVERING for 3+ days (Phase 3 Undo)

Google Cloud Database
1

SQL Server database stuck in RECOVERING (Phase 3) for over 72 hours on Google Cloud SQL

I’m trying to determine whether this is a normal long-running recovery, a very large rollback, or a recovery process that is effectively stuck.

Environment

  • Google Cloud SQL for SQL Server
  • Database: 0db
  • Recovery Model: SIMPLE

What happened

After an instance restart on 2026-07-20, database 0db entered recovery.

Another database on the same instance (0db_sub) recovered successfully within a few seconds.

Error log:

Starting up database '0db'.

Parallel redo is started for database '0db'
with worker pool size [1].

The companion database completed normally:
Recovery completed for database 0db_sub (same schema just altered logical name)
However, 0db never came online.

Current database state

SELECT
    name,
    state_desc,
    log_reuse_wait_desc,
    recovery_model_desc
FROM sys.databases
WHERE name = '0db';

Result:

name                  = 0db
state_desc            = RECOVERING
log_reuse_wait_desc   = ACTIVE_TRANSACTION
recovery_model_desc   = SIMPLE

Recovery progress

The error log shows:

Phase 1 completed
Phase 2 completed
Phase 3 (Undo) started

Recovery eventually reached:

Recovery of database '0db' is 1% complete.
2
Phase 3 of 3.

and has remained at 1% for more than 72 hours.

No
Recovery completed for database '0db'
message has appeared.

The estimated completion time in the log continuously fluctuates and sometimes reports extremely large values.

Active requests

SELECT
 command,
 percent_complete,
 estimated_completion_time,
 wait_type,
 blocking_session_id
FROM sys.dm_exec_requests;

Recovery-related session:

command = RECOVERY WRITER
percent_complete = 0
wait_type = DIRTY_PAGE_POLL
blocking_session_id = 0

I do not see any obvious recovery worker actively progressing.

Transaction information

SELECT
 database_id,
 database_transaction_begin_time,
 database_transaction_log_record_count,
 database_transaction_log_bytes_used
FROM sys.dm_tran_database_transactions;

Relevant row:

database_id = 6
database_transaction_begin_time = NULL
database_transaction_log_record_count = 17,428,339
database_transaction_log_bytes_used = 1,186,270,188

Approximately:

17.4 million log records
1.18 GB log bytes used

Additional observations

I tried:

SELECT
 *
FROM sys.dm_io_virtual_file_stats(6, NULL);

but it returned:
0 rows
This is Cloud SQL, so I cannot directly inspect MDF/LDF files.
I also could not find any obvious corruption-related errors in the SQL Server error log:

823
824
825
checksum
corruption

Questions

  1. Has anyone seen a database remain in Phase 3 (Undo) at 1% for more than 72 hours?

  2. Does the combination of:

    • RECOVERING
    • ACTIVE_TRANSACTION
    • RECOVERY WRITER
    • DIRTY_PAGE_POLL
    • 1% progress for days

    suggest a genuinely long rollback, or a recovery process that is effectively stuck?

  3. Is there any additional DMV or diagnostic query that can help determine whether recovery is still making progress?

  4. Has anyone encountered similar behavior on Google Cloud SQL for SQL Server specifically?

Any insight would be appreciated.

Thanks.

Unfortunately I do not currently have access to Google Cloud Support, so I’m trying to gather evidence before escalating internally. :cry:

2 Likes