Skip to content

SQLWATCH 4.5 XES "SQLWATCH_query_problems" slows performance of database creation #466

@monteroman

Description

@monteroman

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:

  1. Go to SSMS --> Management --> Extended Events --> Session
  2. Turn off SQLWATCH_query_problems
  3. In SharePoint, create a new content database through the PowerShell command "New-SPContentDatabase" - time is about 2 minutes
  4. Turn on SQLWATCH_query_problems
  5. 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.

Screenshots
image

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions