{"id":798,"date":"2024-10-08T08:00:00","date_gmt":"2024-10-08T13:00:00","guid":{"rendered":"https:\/\/www.sqltabletalk.com\/?p=798"},"modified":"2024-10-04T21:11:41","modified_gmt":"2024-10-05T02:11:41","slug":"manually-catch-up-secondary-replica-sql-server","status":"publish","type":"post","link":"https:\/\/www.sqltabletalk.com\/?p=798","title":{"rendered":"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups"},"content":{"rendered":"

Introduction<\/h2>\n

In high-availability environments, SQL Server Always On Availability Groups (AG) are essential for minimizing downtime and preventing data loss. However, situations can arise where a secondary replica lags behind the primary, disrupting synchronization and risking potential data inconsistencies. This blog provides instructions on how to manually catch up a lagging secondary replica using transaction log backups.<\/p>\n

Common Scenarios Leading to a Lagging Secondary Replica<\/h2>\n

Understanding the reasons behind a lagging secondary replica can help in effectively addressing the issue. Here are some common scenarios:<\/p>\n

1. Extended Network Outages<\/h3>\n

A prolonged network outage between the primary and secondary replicas can prevent the secondary from receiving and applying transaction logs. When the connection is restored, the accumulated backlog may cause the secondary to be significantly behind the primary.<\/p>\n

2. Insufficient Bandwidth During Heavy Load<\/h3>\n

High transaction volumes on the primary database can overwhelm the available network bandwidth. If the bandwidth between replicas isn’t sufficient to handle the load, the secondary may fall behind, leading the availability group to enter a “not synchronized” state.<\/p>\n

3. Resource Constraints on the Secondary Replica<\/h3>\n

Limitations in CPU, memory, or disk I\/O on the secondary server can delay the application of transaction logs. These resource bottlenecks can cause the secondary replica to become increasingly out of sync with the primary.<\/p>\n

4. Unexpected Failover Events<\/h3>\n

In the event of an unplanned failover, an unsynchronized secondary replica can result in significant lag. Post-failover, manual intervention is required to catch up the secondary to ensure it’s prepared for future failover scenarios.<\/p>\n

Steps to Manually Catch Up the Secondary Replica<\/h2>\n

To restore full synchronization and prevent potential data loss, follow these steps to manually catch up the secondary replica using transaction log backups.<\/p>\n

1. Query the Last Hardened LSN on the Secondary Replica<\/h3>\n

Begin by identifying the last hardened log sequence number (LSN) on the secondary replica. This LSN represents the point up to which the secondary has applied transaction logs.<\/p>\n

SELECT DISTINCT\n    dcs.database_name,\n    ds.last_hardened_lsn\nFROM\n    sys.dm_hadr_database_replica_states ds\nJOIN\n    sys.dm_hadr_database_replica_cluster_states dcs ON ds.group_database_id = dcs.group_database_id\nWHERE\n    dcs.database_name = 'YourDatabaseName';<\/code><\/pre>\n
This query retrieves the last hardened LSN for the specified database, which you’ll use to identify the required transaction log backups.<\/p>\n
2. Identify the Relevant Transaction Log Backups in MSDB<\/h3>\n
With the last hardened LSN, query the backup history in the msdb<\/code> database to find the transaction log backups that need to be applied to the secondary replica.<\/p>\n
SELECT\n    name,\n    backup_set_id,\n    backup_start_date,\n    backup_finish_date,\n    first_lsn,\n    last_lsn\nFROM\n    msdb..backupset\nWHERE\n    database_name = 'YourDatabaseName' AND\n    type = 'L' AND -- 'L' indicates transaction log backups\n    first_lsn <= 'YourLSN' AND\n    last_lsn >= 'YourLSN'\nORDER BY\n    backup_start_date;<\/code><\/pre>\n
This query lists all transaction log backups where the hardened LSN falls between first_lsn<\/code> and last_lsn<\/code>.<\/p>\n
3. Take the Database Out of the Availability Group on the Secondary Replica<\/h3>\n
Before applying the transaction logs, remove the database from the availability group on the secondary replica. This action puts the database into the RESTORING state, allowing you to apply transaction log backups manually.<\/p>\n
ALTER DATABASE [YourDatabaseName] SET HADR OFF;<\/code><\/pre>\n
4. Apply the Transaction Log Backups Manually<\/h3>\n
Restore the necessary transaction log backups to the secondary replica using the RESTORE LOG<\/code> command with the NORECOVERY<\/code> option. This option keeps the database in a restoring state, enabling the application of subsequent logs.<\/p>\n
RESTORE LOG [YourDatabaseName]\nFROM DISK = 'Path\\To\\YourFirstTransactionLogBackup.trn'\nWITH NORECOVERY;\n\nRESTORE LOG [YourDatabaseName]\nFROM DISK = 'Path\\To\\YourSecondTransactionLogBackup.trn'\nWITH NORECOVERY;\n\n-- Continue this process for all relevant transaction log backups<\/code><\/pre>\n
Ensure that you apply all transaction log backups sequentially up to the most recent one needed to catch up the secondary replica.<\/p>\n
5. Add the Database Back into the Availability Group<\/h3>\n
After applying all the required transaction log backups, add the database back to the availability group and resume synchronization:<\/p>\n
ALTER DATABASE [YourDatabaseName] SET HADR AVAILABILITY GROUP = [YourAvailabilityGroupName];\nGO\n\nALTER DATABASE [YourDatabaseName] SET HADR RESUME;\nGO<\/code><\/pre>\n
6. Verify Synchronization<\/h3>\n
Confirm that the database is synchronizing properly by querying the status of the availability group database:<\/p>\n
SELECT\n    dcs.database_name,\n    drs.synchronization_state_desc,\n    drs.is_suspended,\n    drs.last_hardened_lsn\nFROM\n    sys.dm_hadr_database_replica_states drs\nJOIN\n    sys.dm_hadr_database_replica_cluster_states dcs ON drs.group_database_id = dcs.group_database_id\nWHERE\n    dcs.database_name = 'YourDatabaseName';<\/code><\/pre>\n
The synchronization_state_desc<\/code> should display SYNCHRONIZED, and is_suspended<\/code> should be 0, indicating that synchronization is active and not suspended.<\/p>\n
Conclusion<\/h2>\n
Catching up a lagging secondary replica in a SQL Server Always On Availability Group is important for maintaining high availability and ensuring data consistency across replicas. By following the steps outlined\u2014identifying the last hardened LSN, applying the necessary transaction log backups, and re-adding the database to the availability group\u2014you can restore full synchronization without significant data loss or downtime. Regular monitoring and proactive management of network and server resources can help prevent such lag issues from occurring in the future.<\/p>\n","protected":false},"excerpt":{"rendered":"
In high-availability environments, SQL Server Always On Availability Groups (AG) are essential for minimizing downtime and preventing data loss. However, situations can arise where a secondary replica lags behind the primary, disrupting synchronization and risking potential data inconsistencies. This blog provides instructions on how to manually catch up a lagging secondary replica using transaction log backups.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[36,35,54,13,18,73],"tags":[38,307,308,42,306,304,131,305],"class_list":["post-798","post","type-post","status-publish","format-standard","hentry","category-availability-groups","category-data-integrity","category-maintenance","category-storage-engine","category-transaction-logs","category-troubleshooting","tag-availability-groups","tag-database-recovery","tag-database-synchronization","tag-high-availability","tag-restore-transaction-logs","tag-secondary-replica","tag-sql-server","tag-transaction-log-backups"],"yoast_head":"\nManually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups - SQL Table Talk<\/title>\n<meta name=\"description\" content=\"In high-availability environments, SQL Server Always On Availability Groups (AG) are essential for minimizing downtime and preventing data loss. However, situations can arise where a secondary replica lags behind the primary, disrupting synchronization and risking potential data inconsistencies. This blog provides instructions on how to manually catch up a lagging secondary replica using transaction log backups.\" \/>\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.sqltabletalk.com\/?p=798\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups - SQL Table Talk\" \/>\n<meta property=\"og:description\" content=\"In high-availability environments, SQL Server Always On Availability Groups (AG) are essential for minimizing downtime and preventing data loss. However, situations can arise where a secondary replica lags behind the primary, disrupting synchronization and risking potential data inconsistencies. This blog provides instructions on how to manually catch up a lagging secondary replica using transaction log backups.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.sqltabletalk.com\/?p=798\" \/>\n<meta property=\"og:site_name\" content=\"SQL Table Talk\" \/>\n<meta property=\"article:published_time\" content=\"2024-10-08T13:00:00+00:00\" \/>\n<meta name=\"author\" content=\"Yvonne Vanslageren\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Yvonne Vanslageren\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"3 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=798#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=798\"},\"author\":{\"name\":\"Yvonne Vanslageren\",\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/68bb31b454bafe9e139183ed4f3e9082\"},\"headline\":\"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups\",\"datePublished\":\"2024-10-08T13:00:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=798\"},\"wordCount\":647,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0\"},\"keywords\":[\"availability groups\",\"Database Recovery\",\"Database Synchronization\",\"High Availability\",\"Restore Transaction Logs\",\"Secondary Replica\",\"SQL Server\",\"Transaction Log Backups\"],\"articleSection\":[\"Availability Groups\",\"Data Integrity\",\"Maintenance\",\"Storage Engine\",\"Transaction Logs\",\"Troubleshooting\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.sqltabletalk.com\/?p=798#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=798\",\"url\":\"https:\/\/www.sqltabletalk.com\/?p=798\",\"name\":\"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups - SQL Table Talk\",\"isPartOf\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/#website\"},\"datePublished\":\"2024-10-08T13:00:00+00:00\",\"description\":\"In high-availability environments, SQL Server Always On Availability Groups (AG) are essential for minimizing downtime and preventing data loss. However, situations can arise where a secondary replica lags behind the primary, disrupting synchronization and risking potential data inconsistencies. This blog provides instructions on how to manually catch up a lagging secondary replica using transaction log backups.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=798#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.sqltabletalk.com\/?p=798\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=798#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.sqltabletalk.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.sqltabletalk.com\/#website\",\"url\":\"https:\/\/www.sqltabletalk.com\/\",\"name\":\"SQL Table Talk\",\"description\":\"Breaking Down SQL Server, One Post at a Time.\",\"publisher\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.sqltabletalk.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0\",\"name\":\"Stephen Planck\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/64181114edc3de3d99072c049bcec024f025c9536dc89fc8ff1bac58976ca81e?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/64181114edc3de3d99072c049bcec024f025c9536dc89fc8ff1bac58976ca81e?s=96&d=mm&r=g\",\"caption\":\"Stephen Planck\"},\"logo\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/\"},\"sameAs\":[\"https:\/\/dexterwiki.com\",\"https:\/\/www.linkedin.com\/in\/stephen-planck-4611b692?trk=people-guest_people_search-card&challengeId=AQErf8gbBmcVMwAAAYsyIsxO-0UvU8z7cHrBpZoo_n3xt9qEKpRN5B_jd_LmAMu-OfeArkQ7GDjobJ2uRoQQV35EQdh_rR6kxA&submissionId=09de7067-c335-8e17-40b8-8dc32b60ed6c&challengeSource=AgEcUCw35zpPmAAAAYsyI4vAWhJTV7Nt4vZYKc3V1qiDBpCkKgUvtlOBgYXcE84&challegeType=AgE_wZiTT09IAQAAAYsyI4vDmNvbZIYe6XHju5V2bXVvM3IVxnJslgY&memberId=AgESFTkUShzs_gAAAYsyI4vGYk0Gic1uc5kB6cKOABA26Gw&recognizeDevice=AgHdSZyUSI5CEwAAAYsyI4vKd_koF9JgpsCJShT8QfbK1QMiv8SI\",\"https:\/\/www.youtube.com\/linuxmate\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/68bb31b454bafe9e139183ed4f3e9082\",\"name\":\"Yvonne Vanslageren\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/22c274a7a354b81a0a8dc5b23e8e0be9bdd81a6bc0541474cfb6b954d6bb2089?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/22c274a7a354b81a0a8dc5b23e8e0be9bdd81a6bc0541474cfb6b954d6bb2089?s=96&d=mm&r=g\",\"caption\":\"Yvonne Vanslageren\"},\"url\":\"https:\/\/www.sqltabletalk.com\/?author=2\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups - SQL Table Talk","description":"In high-availability environments, SQL Server Always On Availability Groups (AG) are essential for minimizing downtime and preventing data loss. However, situations can arise where a secondary replica lags behind the primary, disrupting synchronization and risking potential data inconsistencies. This blog provides instructions on how to manually catch up a lagging secondary replica using transaction log backups.","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.sqltabletalk.com\/?p=798","og_locale":"en_US","og_type":"article","og_title":"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups - SQL Table Talk","og_description":"In high-availability environments, SQL Server Always On Availability Groups (AG) are essential for minimizing downtime and preventing data loss. However, situations can arise where a secondary replica lags behind the primary, disrupting synchronization and risking potential data inconsistencies. This blog provides instructions on how to manually catch up a lagging secondary replica using transaction log backups.","og_url":"https:\/\/www.sqltabletalk.com\/?p=798","og_site_name":"SQL Table Talk","article_published_time":"2024-10-08T13:00:00+00:00","author":"Yvonne Vanslageren","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Yvonne Vanslageren","Est. reading time":"3 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.sqltabletalk.com\/?p=798#article","isPartOf":{"@id":"https:\/\/www.sqltabletalk.com\/?p=798"},"author":{"name":"Yvonne Vanslageren","@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/68bb31b454bafe9e139183ed4f3e9082"},"headline":"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups","datePublished":"2024-10-08T13:00:00+00:00","mainEntityOfPage":{"@id":"https:\/\/www.sqltabletalk.com\/?p=798"},"wordCount":647,"commentCount":0,"publisher":{"@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0"},"keywords":["availability groups","Database Recovery","Database Synchronization","High Availability","Restore Transaction Logs","Secondary Replica","SQL Server","Transaction Log Backups"],"articleSection":["Availability Groups","Data Integrity","Maintenance","Storage Engine","Transaction Logs","Troubleshooting"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.sqltabletalk.com\/?p=798#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.sqltabletalk.com\/?p=798","url":"https:\/\/www.sqltabletalk.com\/?p=798","name":"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups - SQL Table Talk","isPartOf":{"@id":"https:\/\/www.sqltabletalk.com\/#website"},"datePublished":"2024-10-08T13:00:00+00:00","description":"In high-availability environments, SQL Server Always On Availability Groups (AG) are essential for minimizing downtime and preventing data loss. However, situations can arise where a secondary replica lags behind the primary, disrupting synchronization and risking potential data inconsistencies. This blog provides instructions on how to manually catch up a lagging secondary replica using transaction log backups.","breadcrumb":{"@id":"https:\/\/www.sqltabletalk.com\/?p=798#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.sqltabletalk.com\/?p=798"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.sqltabletalk.com\/?p=798#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.sqltabletalk.com\/"},{"@type":"ListItem","position":2,"name":"Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups"}]},{"@type":"WebSite","@id":"https:\/\/www.sqltabletalk.com\/#website","url":"https:\/\/www.sqltabletalk.com\/","name":"SQL Table Talk","description":"Breaking Down SQL Server, One Post at a Time.","publisher":{"@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.sqltabletalk.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":["Person","Organization"],"@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0","name":"Stephen Planck","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/64181114edc3de3d99072c049bcec024f025c9536dc89fc8ff1bac58976ca81e?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/64181114edc3de3d99072c049bcec024f025c9536dc89fc8ff1bac58976ca81e?s=96&d=mm&r=g","caption":"Stephen Planck"},"logo":{"@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/"},"sameAs":["https:\/\/dexterwiki.com","https:\/\/www.linkedin.com\/in\/stephen-planck-4611b692?trk=people-guest_people_search-card&challengeId=AQErf8gbBmcVMwAAAYsyIsxO-0UvU8z7cHrBpZoo_n3xt9qEKpRN5B_jd_LmAMu-OfeArkQ7GDjobJ2uRoQQV35EQdh_rR6kxA&submissionId=09de7067-c335-8e17-40b8-8dc32b60ed6c&challengeSource=AgEcUCw35zpPmAAAAYsyI4vAWhJTV7Nt4vZYKc3V1qiDBpCkKgUvtlOBgYXcE84&challegeType=AgE_wZiTT09IAQAAAYsyI4vDmNvbZIYe6XHju5V2bXVvM3IVxnJslgY&memberId=AgESFTkUShzs_gAAAYsyI4vGYk0Gic1uc5kB6cKOABA26Gw&recognizeDevice=AgHdSZyUSI5CEwAAAYsyI4vKd_koF9JgpsCJShT8QfbK1QMiv8SI","https:\/\/www.youtube.com\/linuxmate"]},{"@type":"Person","@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/68bb31b454bafe9e139183ed4f3e9082","name":"Yvonne Vanslageren","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/22c274a7a354b81a0a8dc5b23e8e0be9bdd81a6bc0541474cfb6b954d6bb2089?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/22c274a7a354b81a0a8dc5b23e8e0be9bdd81a6bc0541474cfb6b954d6bb2089?s=96&d=mm&r=g","caption":"Yvonne Vanslageren"},"url":"https:\/\/www.sqltabletalk.com\/?author=2"}]}},"jetpack_featured_media_url":"","jetpack-related-posts":[],"jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/posts\/798","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=798"}],"version-history":[{"count":2,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/posts\/798\/revisions"}],"predecessor-version":[{"id":801,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/posts\/798\/revisions\/801"}],"wp:attachment":[{"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=798"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=798"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=798"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}