Which factors impact the time for SQL Server Recovery to complete
Since you are not using SQL server 2019, ADR won't be applicable. There are few general guidelines, which should be considered in almost all the cases and they are as below:
- Keeping Transactions as tiny as possible.
- Control long running transactions liaising with application team or vendor as appropriate.
- Take transaction log backup as frequently as possible to reduce Analysis phase.
There is an option of changing target recovery time however that has some down-side also. You should consider them before enabling them.
From MS-site, if you avoid below scenarios, you don't need ADR:
Who should consider accelerated database recovery The following types of customers should consider enabling ADR:
- Customers that have workloads with long running transactions.
- Customers that have seen cases where active transactions are causing the transaction log to grow significantly.
- Customers that have experienced long periods of database unavailability due to SQL Server long running recovery (such as unexpected SQL Server restart or manual transaction rollback).
From the comment and new addition to your question about using blob type in your database, yes having these data types can significantly delay any checkpoint by database. In stead, you should use CAS storage type as explained well by Mr. Brent Ozar:
https://www.brentozar.com/archive/2015/03/no-more-blobs/
Hope this helps you in taking right decision.
Just to add a bit to the other answers:
Recovery is done in three steps. Analysis, REDO (rollforward) and UNDO (rollback).
A checkpoint happen with the frequency so that the REDO phase shouldn't exceed whatever you configured at the instance (sp_configure) or database (ALTER DATABASE) level. By default this is (as I can remember) one minute. I.e., you could see at most about one minute worth of REDO.
So either you've ran into something weird or you have a large rollback happening.
Having many VLF's for your ldf can increase recovery time, but I doubt it will cause this severe situation. My guess is a long-running transaction being rolled backup. Or a very old open transaction, causing reading lots and lots from the ldf even if that transaction in itself didn't modify much data.
There's some feedback from the recovery process in the errorlog file. That would be my starting point, and from there determine what phase took so long. And also check is you have a huge amounts of VLFs (which I doubt considering you are on 2016).
If you change to SQL Server 2019 you can enable accelerated database recovery, this will give you the biggest speed up by far. https://docs.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver15