SQL Server Wait Type: PREEMPTIVE_OS_QUERYREGISTRY

Wait statistics, in the context of SQL Server, refer to the amount of time that a query spends waiting to access data in the database. When a client application requests data from the database, the request is placed in a queue and the client application must wait for its turn to access the data. The time that the query spends waiting is called a “wait” and is tracked by SQL Server. This information can be used to identify potential performance bottlenecks and optimize the performance of the database. Wait statistics are commonly used by database administrators to diagnose and troubleshoot performance issues in SQL Server.

The SQL Server PREEMPTIVE_OS_QUERYREGISTRY wait type is a type of wait that occurs when a session is waiting for the operating system to query the registry. This type of wait is typically associated with operations that require access to the registry, such as creating or modifying a database, or starting or stopping a SQL Server service.

When a session is waiting on the PREEMPTIVE_OS_QUERYREGISTRY wait type, it means that it is unable to proceed with its current operation until the operating system has queried the registry. This can cause delays and slow down the overall performance of the SQL Server instance.

To troubleshoot and resolve issues related to the PREEMPTIVE_OS_QUERYREGISTRY wait type, it is important to first determine what operation is causing the wait and then investigate why that operation is taking a long time to complete. This may involve looking at the queries or processes that are executing the registry operation, as well as any other operations that are running concurrently on the SQL Server instance.

In some cases, it may be necessary to optimize the queries or processes that are causing the PREEMPTIVE_OS_QUERYREGISTRY waits, or to adjust the workload on the SQL Server instance to reduce the occurrence of this wait type. It may also be necessary to adjust the settings of the registry operation to improve its performance and reduce the need for queries to the registry.

Overall, the PREEMPTIVE_OS_QUERYREGISTRY wait type can be a useful indicator of potential performance issues related to the registry in SQL Server, and can help DBAs and developers identify and resolve those issues to improve the performance of their databases.

More details avilable on this wait type here: http://DatabaseHealth.com/Waits/PREEMPTIVE_OS_QUERYREGISTRY.html

Do you have a favorite tool for monitoring your wait statistics on SQL Server over time? This is something that you can use Database Health monitor to do. More details at http://DatabaseHealth.com.

If you are having performance issues assocaited with this wait type and need soem help, please contact us with our 30 minute consulation link.

2 Comments on “SQL Server Wait Type: PREEMPTIVE_OS_QUERYREGISTRY”

Carlin Grose says:

December 6, 2023 at 18:33

Thanks for the article, Steve. This helped lead us towards figuring out a performance issue we had in SQL Server 2022 CU9 on-prem where if a non-admin account ran a query that used “has_access” (like some system views do) it would take around 1 minute in our production environment, whereas in 2016 it would take under 10 seconds.

As a test we ran “SELECT * FROM sys.database_permissions” and SQL Server would try to access the registry entry “HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL16.DEV\MSSQLServer\PurviewConfig” which doesn’t exist (we don’t use Purview), but it tries that around 418,000 times before delivering the results around 1 minute later. This also added a 20% CPU load during the entire test duration.
Enabling trace flag 12502 stopped all that from happening and now our test completes in 9 seconds during production workloads.
PREEMPTIVE_OS_QUERYREGISTRY previously popped up frequently under activity monitor but we’re not seeing it at all anymore.

We’re reaching out to Microsoft for more information on this as it sounds like a bug. Hopefully this information helps others.

- Lenny Vaynerman says:
  
  March 11, 2024 at 07:58
  
  Hi Carlin,
  
  We ran into similar performance issue and enabling trace flag resolved it. Were you able to get any more information from Microsoft?