pbarryuk
pbarryuk
I would suggest you capture the backup_restore_progress_trace Extended Event (see https://techcommunity.microsoft.com/t5/sql-server-blog/new-extended-event-to-track-backup-and-restore-progress/ba-p/384447 for more details) as it captures the part where the back history is attempted to be written and potential...
Sorry if it wasn’t clear , I wasn’t suggesting changing the selects of the monitoring system. I was suggesting that you capture the xEvent for backups as there are entries...
> I believe Clifton's issue was with Azure Backups, as it's taking a Full snapshot backup of the database, but the backup isn't copy-only so it breaks the differential chain...
This issue should have been fixed by VSTS bug 14173307 in SQL Server 2019 CU13 [https://support.microsoft.com/en-us/topic/kb5005679-cumulative-update-13-for-sql-server-2019-5c1be850-460a-4be4-a569-fe11f0adc535] ________________________________ From: e11ameno ***@***.***> Sent: Monday, December 20, 2021 4:01:33 PM To: olahallengren/sql-server-maintenance-solution ***@***.***>...
It looks like I can repro in Microsoft SQL Server 2019 (RTM-CU14) (KB5007182) - 15.0.4188.2 server. The method of execution of the CHECKDB impacts the outcome. If you just run...
I’m very sure the TF does as described - it skips the stats check code that is getting incorrectly called for certain object types that it should not, such as...
The fix has been released for SQL Server 2017 in CU30 - [https://support.microsoft.com/en-us/topic/kb5013756-cumulative-update-30-for-sql-server-2017-274943fa-8dde-4844-90ed-d3b587fa0c7c#bkmk_14673411](url)
This has now also been fixed in SQL Server 2019 - https://support.microsoft.com/en-us/topic/kb5016394-cumulative-update-17-for-sql-server-2019-3033f654-b09d-41aa-8e49-e9d0c353c5f7#bkmk_14673410 I would suggest this bug can be closed @olahallengren
We are having the same issue in our environment - the secondary AG still has databases marked as essentially a primary replica, so the script assumes that it can access...