{"id":12773,"date":"2019-09-10T11:01:08","date_gmt":"2019-09-10T09:01:08","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/"},"modified":"2023-07-17T15:10:31","modified_gmt":"2023-07-17T13:10:31","slug":"introducing-accelerated-database-recovery-with-sql-server-2019","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/","title":{"rendered":"Introducing Accelerated Database Recovery with SQL Server 2019"},"content":{"rendered":"

SQL Server 2019 RC1 was released out a few weeks ago and it is time to start blogging about my favorite core engine features that will be shipped with the next version of SQL Server. Things should not be completely different with the RTM, so let\u2019s introduce the accelerated database recovery<\/a> (aka ADR) which is mainly designed to solve an annoying issue that probably most of SQL Server DBAs already faced at least one time: long running transactions that impact the overall recovery time. As a reminder with current versions of SQL Server, database recovery time is tied to the largest transaction at the moment of the crash. This is even more true in high-critical environments where it may have a huge impact on the service or application availability and ADR is another feature that may help for sure.<\/p>\n

\"\"<\/p>\n

Image from Microsoft documentation<\/em><\/a><\/p>\n

In order to allow very fast rollback and recovery process the SQL Server team redesigned completely the SQL database engine recovery process and the interesting point is they have introduced row-versioning to achieve it. Row-versioning, however, exist since the SQL Server 2005 version through RCSI and SI isolation levels and from my opinion this is finally good news to extend (finally) such capabilities to address long recovery time.<\/p>\n

Anyway, I performed some testing to get an idea of what could be the benefit of ADR and the impact of the workload as well. Firstly, I performed a recovery test without ADR and after initiating a long running transaction, I simply crashed my SQL Server instance. I used an AdventureWorks<\/em> database with the dbo.bigTransactionHistory<\/a> <\/em>table which is big enough (I think) to get a relevant result.<\/p>\n

The activation of ADR is per database meaning that row-versioning is also managed locally per database. It allows a better workload isolation compared to using the global tempdb version store with previous SQL Server versions.<\/p>\n

USE AdventureWorks_dbi;\n\nALTER DATABASE AdventureWorks_dbi SET\n    ACCELERATED_DATABASE_RECOVERY = OFF; \n\nALTER DATABASE AdventureWorks_dbi SET\n\tCOMPATIBILITY_LEVEL = 150;\nGO<\/pre>\n
The dbo.bigtransactionHistory<\/em> table has only one clustered primary key \u2026<\/p>\n
EXEC sp_helpindex 'dbo.bigTransactionHistory';\nGO<\/pre>\n
\"\"<\/p>\n
\u2026 with 158\u2019272\u2019243 rows and about 2GB of data<\/p>\n
EXEC sp_helpindex 'dbo.bigTransactionHistory';\nGO<\/pre>\n
\"\"<\/p>\n
I simulated a long running transaction with the following update query that touches every row of the dbo.bigTransactionHistory<\/em> table to get a relevant impact on the recovery process duration time.<\/p>\n
BEGIN TRAN;\n\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO<\/pre>\n
The related transactions wrote a log of records into the transaction log size as show below:<\/p>\n
SELECT \n\tDB_NAME(database_id) AS [db_name],\n\ttotal_log_size_in_bytes \/ 1024 \/ 1024 AS size_MB,\n\tused_log_space_in_percent AS [used_%]\nFROM sys.dm_db_log_space_usage;\nGO<\/pre>\n
\"\"<\/p>\n
The sys.dm_tran_* and sys.dm_exec_* DMVs may be helpful to dig into the transaction detail including the transaction start time and log used in the transaction log:<\/p>\n
SELECT \n   GETDATE() AS [Current Time],\n   [des].[login_name] AS [Login Name],\n   DB_NAME ([dtdt].database_id) AS [Database Name],\n   [dtdt].[database_transaction_begin_time] AS [Transaction Begin Time],\n   [dtdt].[database_transaction_log_bytes_used] \/ 1024 \/ 1024 AS [Log Used MB],\n   [dtdt].[database_transaction_log_bytes_reserved] \/ 1024 \/ 1024 AS [Log Reserved MB],\n   SUBSTRING([dest].text, [der].statement_start_offset\/2 + 1,(CASE WHEN [der].statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max),[dest].text)) * 2 ELSE [der].statement_end_offset END - [der].statement_start_offset)\/2) as [Query Text]\nFROM \n   sys.dm_tran_database_transactions [dtdt]\n   INNER JOIN sys.dm_tran_session_transactions [dtst] ON  [dtst].[transaction_id] = [dtdt].[transaction_id]\n   INNER JOIN sys.dm_exec_sessions [des] ON  [des].[session_id] = [dtst].[session_id]\n   INNER JOIN sys.dm_exec_connections [dec] ON   [dec].[session_id] = [dtst].[session_id]\n   LEFT OUTER JOIN sys.dm_exec_requests [der] ON [der].[session_id] = [dtst].[session_id]\n   OUTER APPLY sys.dm_exec_sql_text ([der].[sql_handle]) AS [dest]\nGO<\/pre>\n
\"\"<\/p>\n
The restart of my SQL Server instance kicked-in the AdventureWorks_dbi<\/em> database recovery process. It took about 6min in my case:<\/p>\n
EXEC sp_readerrorlog 0, 1, N'AdventureWorks_dbi'<\/pre>\n
\"\"<\/p>\n
Digging further in the SQL Server error log, I noticed the phase2 (redo) and phase3 (undo) of the recovery process that took the most of time (as expected).<\/p>\n
However, if I performed the same test with ADR enabled for the AdventureWorks_dbi<\/em> database \u2026<\/p>\n
USE AdventureWorks_dbi;\n\nALTER DATABASE AdventureWorks_dbi SET\n    ACCELERATED_DATABASE_RECOVERY = ON;<\/pre>\n
\u2026 and I dig again into the SQL Server error log:<\/p>\n
\"\"<\/p>\n
Well, the output above is pretty different but clear and irrevocable: there is a tremendous improvement of the recovery time process here. The SQL Server error log indicates the redo phase took 0ms and the undo phase 119ms. I also tested different variations in terms of long transactions and logs generated in the transaction log (4.5GB, 9.1GB and 21GB) without and with ADR. With the latter database recovery remained fast irrespective to the transaction log size as shown below:<\/p>\n
\"\"<\/p>\n
But there is no free lunch when enabling ADR because it is a row-versioning based process which may have an impact on the workload. I was curious to compare the performance of my update queries between scenarios including no row-versioning (default), row-versioning with RCSI only, ADR only and finally both RCSI and ADR enabled. I performed all my tests on a virtual machine quad core Intel\u00ae Core \u2122 i7-6600U CPU @ 2.6Ghz and 8GB of RAM. SQL Server memory is capped to 6GB. The underlying storage for SQL Server data files is hosted on SSD disk Samsung 850 EVO 1TB.<\/p>\n
Here the first test I performed. This is the same update I performed previously which touches every row on the dbo.bigTransactionHistory<\/em> table:<\/p>\n
BEGIN TRAN;\n\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO<\/pre>\n
And here the result with the different scenarios:<\/p>\n
\"\"<\/p>\n
Please don\u2019t focus strongly on values here because it will depend on your context but the result answers to the following questions: Does the activation of ADR will have an impact on the workload and if yes is it in the same order of magnitude than RCSI \/ SI? The results are self-explanatory.<\/p>\n
Then I decided to continue my tests by increasing the impact of the long running transaction with additional updates on the same data in order to stress a little bit the version store.<\/p>\n
BEGIN TRAN;\n\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO<\/pre>\n
Here the new results:<\/p>\n
\"\"<\/p>\n
This time ADR seems to have a bigger impact than RCSI in my case. Regardless the strict values of this test, the key point here is we have to be aware that enabling ADR will have an impact to the workload.<\/p>\n
After performing these bunch of tests, it\u2019s time to get a big picture of ADR design with several components per database including a persisted version store (PVS), a Logical Revert, a sLog and a cleaner process. In this blog post I would like to focus on the PVS component that acts as persistent version store for the concerned database. In other words, with ADR, tempdb will not be used to store row versions anymore. The interesting point is that RCSI \/ SI row-versioning will continue to be handle through the PVS if ADR is enabled according to my tests.<\/p>\n
There is the new added column named is_accelerated_database_recovery_on<\/em> to the sys.databases<\/em> system view. In my case both RCSI and ADR are enabled in AdventureWorks_dbi database.<\/p>\n
SELECT \n\tname AS [database_name],\n\tis_read_committed_snapshot_on,\n\tis_accelerated_database_recovery_on\nFROM sys.databases\nWHERE database_id = DB_ID()<\/pre>\n
\"\"<\/p>\n
The sys.dm_tran_version_store_space_usage<\/em> DMV displays the total space in tempdb used by the version store for each database whereas the new sys.dm_tran_persistent_version_store_stats<\/em> DMV provides information related to the new PVS created with the ADR activation.<\/p>\n
BEGIN TRAN;\n\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO\n\nSELECT \n\tDB_NAME(database_id) AS [db_name],\n\toldest_active_transaction_id,\n\tpersistent_version_store_size_kb \/ 1024 AS pvs_MB\nFROM sys.dm_tran_persistent_version_store_stats;\nGO\n\nSELECT \n\tdatabase_id,\n\treserved_page_count \/ 128 AS reserved_MB\nFROM sys.dm_tran_version_store_space_usage;\nGO<\/pre>\n
After running my update query, I noticed the PVS in AdventureWorks_dbi<\/em> database was used rather the version store in tempdb.<\/p>\n
\"\"<\/p>\n
So, getting rid of the version store in tempdb seems to be a good idea and probably more scalable per database but according to my tests and without drawing any conclusion now it may lead to performance considerations \u2026 let\u2019s see in the future what happens \u2026<\/p>\n
In addition, from a storage perspective, because SQL Server doesn\u2019t use tempdb anymore as version store, my curiosity led\u00a0\u00a0to see what happens behind the scene and how PVS interacts with the data pages where row-versioning comes into play. Let\u2019s do some experiments:<\/p>\n
Let\u2019s create the dbo.bigTransationHistory_row_version<\/em> table from the dbo.bigTransationHistory<\/em> table with fewer data:<\/p>\n
USE AdventureWorks_dbi;\nGO\n\nDROP TABLE IF EXISTS [dbo].[bigTransactionHistory_row_version];\n\nSELECT TOP 1 *\nINTO [dbo].[bigTransactionHistory_row_version]\nFROM [dbo].[bigTransactionHistory]<\/pre>\n
Now, let\u2019s have a look at the data page that belongs to my dbo.bigTransacitonHistory_row_version table with the page ID 499960 in my case:<\/p>\n
DBCC TRACEON (3604, -1);\nDBCC PAGE (AdventureWorks_dbi, 1, 499960, 3);<\/pre>\n
\"\"<\/p>\n
Versioning info exists in the header but obviously version pointer is set to Null because there is no additional version of row to maintain in this case. I just inserted one.<\/p>\n
Let\u2019s update the only row that exists in the table as follows:<\/p>\n
BEGIN TRAN;\nUPDATE [dbo].[bigTransactionHistory_row_version]\nSET Quantity = Quantity + 1<\/pre>\n
\"\"<\/p>\n
The version pointer has been updated (but not sure the information is consistent here or at least the values displayed are weird). One another interesting point is there exists more information than the initial 14 bytes of information we may expect to keep track of the pointers. There is also extra 21 bytes at the end of row as show above. On the other hand, the sys.dm_db_index_physical_stats()<\/em> DMF has been updated to reflect the PVS information with new columns inrow_*, total_inrow_* and offrow_* and may help to understand some of the PVS internals.<\/p>\n
SELECT \n\tindex_id,\n\tindex_level,\n\tpage_count,\n\trecord_count,\n\tversion_record_count,\n\tinrow_version_record_count,\n\tinrow_diff_version_record_count,\n\ttotal_inrow_version_payload_size_in_bytes,\n\toffrow_regular_version_record_count,\n\toffrow_long_term_version_record_count\nFROM sys.dm_db_index_physical_stats(\n\tDB_ID(), OBJECT_ID('dbo.bigTransactionHistory_row_version'), \n\tNULL, \n\tNULL, \n\t'DETAILED'\n)<\/pre>\n
\u00a0<\/a><\/p>\n
\"\"<\/p>\n
Indeed, referring to the above output and correlating them to results I found inside the data page, I would assume the extra 21 bytes stored in the row seems to reflect a (diff ?? .. something I need to get info) value of the previous row (focus on in_row_diff_version_record_count and in_row_version_payload_size_in_bytes columns).<\/p>\n
Furthermore, if I perform the update operation on the same data the storage strategy seems to switch to a off-row mode if I refer again to the sys.dm_db_index_physical_stats() DMF output:<\/p>\n
\"\"<\/p>\n
Let\u2019s go back to the DBCC PAGE output to confirm this assumption:<\/p>\n
\"\"<\/p>\n
Indeed, the extra payload has disappeared, and it remains only the 14 bytes pointer which has been updated accordingly.<\/p>\n
Finally, if I perform multiple updates of the same row, SQL Server should keep the off-row storage and should create inside it a chain of version pointers and their corresponding values.<\/p>\n
BEGIN TRAN;\n\nUPDATE [dbo].[bigTransactionHistory_row_version]\nSET Quantity = Quantity + 1\nGO 100000<\/pre>\n
My assumption is verified by taking a look at the previous DMVs. The persistent version store size has increased from ~16MB to ~32MB and we still have 1 version record in off-row mode meaning there is still one version pointer that references the off-row mode structure for my record.<\/p>\n
\"\"<\/p>\n
Finally, let\u2019s introduce the cleaner component. Like the tempdb version store, cleanup of old row versions is achieved by an asynchronous process that cleans page versions that are not needed. It wakes up periodically, but we can force it by executing the sp_persistent_version_cleanup<\/em> stored procedure.<\/p>\n
Referring to one of my first tests, the PVS size is about 8GB.<\/p>\n
BEGIN TRAN;\n\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO\n\n\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO\nUPDATE dbo.bigTransactionHistory\nSET Quantity = Quantity + 1;\nGO\nSELECT \n\tDB_NAME(database_id) AS [db_name],\n\toldest_active_transaction_id,\n\tpersistent_version_store_size_kb \/ 1024 AS pvs_MB\nFROM sys.dm_tran_persistent_version_store_stats;\nGO\n-- Running PVS cleanu process\nEXEC sp_persistent_version_cleanup<\/pre>\n
According to my tests, the cleanup task took around 6min for the entire PVS, but it was not a blocking process at all as you may see below. As ultimate test, I executed in parallel an update query that touched every row of the same table, but it was not blocked by the cleaner as show below:<\/p>\n
\"\"<\/p>\n
This is a process I need to investigate further. Other posts are coming as well .. with other ADR components.<\/p>\n
See you!<\/p>\n
By David Barbarin<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
SQL Server 2019 RC1 was released out a few weeks ago and it is time to start blogging about my favorite core engine features that will be shipped with the next version of SQL Server. Things should not be completely different with the RTM, so let\u2019s introduce the accelerated database recovery (aka ADR) which is […]<\/p>\n","protected":false},"author":26,"featured_media":12775,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229,99],"tags":[1690,1174,67,1691,1457],"type_dbi":[],"class_list":["post-12773","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-database-administration-monitoring","category-sql-server","tag-accelerated-database-recovery","tag-adr","tag-performance","tag-recovery-process","tag-sql-server-2019"],"acf":[],"yoast_head":"\nIntroducing Accelerated Database Recovery with SQL Server 2019 - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Introducing Accelerated Database Recovery with SQL Server 2019\" \/>\n<meta property=\"og:description\" content=\"SQL Server 2019 RC1 was released out a few weeks ago and it is time to start blogging about my favorite core engine features that will be shipped with the next version of SQL Server. Things should not be completely different with the RTM, so let\u2019s introduce the accelerated database recovery (aka ADR) which is […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2019-09-10T09:01:08+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-07-17T13:10:31+00:00\" \/>\n<meta property=\"og:image\" content=\"http:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"643\" \/>\n\t<meta property=\"og:image:height\" content=\"45\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Microsoft Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Microsoft Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/\"},\"author\":{\"name\":\"Microsoft Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\"},\"headline\":\"Introducing Accelerated Database Recovery with SQL Server 2019\",\"datePublished\":\"2019-09-10T09:01:08+00:00\",\"dateModified\":\"2023-07-17T13:10:31+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/\"},\"wordCount\":1648,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg\",\"keywords\":[\"Accelerated Database Recovery\",\"ADR\",\"Performance\",\"Recovery process\",\"SQL Server 2019\"],\"articleSection\":[\"Database Administration & Monitoring\",\"SQL Server\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/\",\"name\":\"Introducing Accelerated Database Recovery with SQL Server 2019 - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg\",\"datePublished\":\"2019-09-10T09:01:08+00:00\",\"dateModified\":\"2023-07-17T13:10:31+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#primaryimage\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg\",\"contentUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg\",\"width\":643,\"height\":45},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Introducing Accelerated Database Recovery with SQL Server 2019\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\",\"name\":\"Microsoft Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"caption\":\"Microsoft Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/microsoft-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Introducing Accelerated Database Recovery with SQL Server 2019 - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/","og_locale":"en_US","og_type":"article","og_title":"Introducing Accelerated Database Recovery with SQL Server 2019","og_description":"SQL Server 2019 RC1 was released out a few weeks ago and it is time to start blogging about my favorite core engine features that will be shipped with the next version of SQL Server. Things should not be completely different with the RTM, so let\u2019s introduce the accelerated database recovery (aka ADR) which is […]","og_url":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/","og_site_name":"dbi Blog","article_published_time":"2019-09-10T09:01:08+00:00","article_modified_time":"2023-07-17T13:10:31+00:00","og_image":[{"width":643,"height":45,"url":"http:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg","type":"image\/jpeg"}],"author":"Microsoft Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Microsoft Team","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/"},"author":{"name":"Microsoft Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4"},"headline":"Introducing Accelerated Database Recovery with SQL Server 2019","datePublished":"2019-09-10T09:01:08+00:00","dateModified":"2023-07-17T13:10:31+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/"},"wordCount":1648,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg","keywords":["Accelerated Database Recovery","ADR","Performance","Recovery process","SQL Server 2019"],"articleSection":["Database Administration & Monitoring","SQL Server"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/","url":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/","name":"Introducing Accelerated Database Recovery with SQL Server 2019 - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg","datePublished":"2019-09-10T09:01:08+00:00","dateModified":"2023-07-17T13:10:31+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/161-1-bigTransactionHistory-index.jpg","width":643,"height":45},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/introducing-accelerated-database-recovery-with-sql-server-2019\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Introducing Accelerated Database Recovery with SQL Server 2019"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4","name":"Microsoft Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","caption":"Microsoft Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/microsoft-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/26"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=12773"}],"version-history":[{"count":1,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12773\/revisions"}],"predecessor-version":[{"id":26747,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12773\/revisions\/26747"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media\/12775"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=12773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=12773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=12773"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=12773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}