-
-
Notifications
You must be signed in to change notification settings - Fork 184
Description
Did you check DOCS to make sure there is no workaround?
https://sqlwatch.io/docs/
Describe the bug
This was something we noticed when creating a new SharePoint database on our SP2019 environment which runs many queries to create the database. I also so this on one of our monitoring servers during an upgrade. When the SQLWATCH_query_problems Extended Event session is running, it can take about an hour to create a new content database for SharePoint. When I stop the XES, and go back and create another database, it takes 2 minutes.
To Reproduce
Steps to reproduce the behavior:
- Go to SSMS --> Management --> Extended Events --> Session
- Turn off SQLWATCH_query_problems
- In SharePoint, create a new content database through the PowerShell command "New-SPContentDatabase" - time is about 2 minutes
- Turn on SQLWATCH_query_problems
- In SharePoint, create a new content database through the PowerShell command "New-SPContentDatabase" - time to complete is about 55 minutes.
Expected behavior
The process should only take a couple of minutes to complete.
Windows Server (please complete the following information):
- Win2019 Server, latest OS Patches through 11/2022
SQL Server (please complete the following information):
- SQL Version: 2019 (15.0.4261.1)
- SQL Edition: Standard Edition
SQL Server Management Studio (SSMS -> about -> copy info):
SQL Server Management Studio 15.0.18424.0
SQL Server Management Objects (SMO) 16.100.47021.0+7eef34a564af48c5b0cf0d617a65fd77f06c3eb1
Microsoft Analysis Services Client Tools 15.0.19750.0
Microsoft Data Access Components (MDAC) 10.0.17763.3650
Microsoft MSXML 3.0 6.0
Microsoft .NET Framework 4.0.30319.42000
Operating System 10.0.17763
SQLWATCH version (from DACPAC or from sysinstances)
- 4.5.0.534
Additional context
I had opened a case with Microsoft to help with trying to determine if it was a SQL issue or a SharePoint issue, but they were able to prove it wasn't SharePoint and they could not determine why SQL was causing the problem. They ran PSS Diag's on SQL and tried to find something in the log files, but were unable to. We were able to come up with the same slowness results in both our dev environment and prod environment. In both instances, when I shut off this XES, the issue disappears.