•  You have a complex query that involves lots of joined tables (for example, 8 or more tables are joined).
• The query may run slowly or slower than when you compare it to another SQL Server version or another system.
• The query plan of the query shows the following information in the XML query plan: StatementOptmEarlyAbortReason="TimeOut". Or, if you verify the properties of the left-most plan operator in Microsoft SQL Server Management Studio, you notice the value of "Reason For Early Termination of Statement Optimization" is “TimeOut.”

<?xml version="1.0" encoding="utf-16"?>
<ShowPlanXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Version="1.518" Build="13.0.5201.2" xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan">
 <BatchSequence>
  <Batch>
   <Statements>
    <StmtSimple StatementCompId="6" StatementEstRows="419.335" StatementId="1" StatementOptmLevel="FULL" StatementOptmEarlyAbortReason="TimeOut" ......>
    ...
   <Statements>
  <Batch>
<BatchSequence> 

There's no simple formula to determine what conditions would cause the optimizer threshold to be reached or exceeded. However, the following are some factors that determine how many plans are explored by QO in the process of looking for a "best plan":

• In what order to join tables:
  • join Table1 with Table2 and the result with Table3
  • join Table1 with Table3 and the result with Table2 Note The larger the number of tables, the larger the possibilities are.
• What heap or binary tree (HoBT) access structure to use to retrieve the rows from a table:
  • Nonclustered Index1
  • Nonclustered Index2
  • Clustered index, and so on
• What access method:
  • index seek
  • index scan
  • table scan
• What physical join operator to use :
  • Nested Loop
  • Hash Match
  • Merge Join (NL, HM, MJ)
• Should a parallel plan be used or a serial one?

To illustrate, take an example of a join between 3 tables (T1, T2 and T3) and each table has a clustered index only. There are two joins involved here and because there are 3 physical join possibilities (NL, HM, MJ), then each of the two joins can be performed in 6 (2 * 3) ways. Also consider the join order:

• T1 joined to T2 and then to T3
• T1 joined to T3 and then to T2
• T2 joined to T3 and then to T1

Now multiply 6 ways * 3 join orders and we have a minimum of 18 possible plans to choose from. If you include the possibility of parallelism and other factors like Seek or Scan of the HoBT, then the possible plans increase even more. If you are a math wizard you can figure out that when a query involves for example 10 tables, the possible permutations there are in the millions. Therefore, you can see that a query with lots of joins is more likely to reach the optimizer timeout threshold than one with fewer joins.

Note The query predicates (filters in the WHERE clause) and existence of constraints will reduce the number of access methods considered and thus the possibilities considered.

The result of reaching the optimizer timeout threshold is that SQL Server has not considered the entire set of possibilities for optimization and it may have missed a set of plans that could produce shorter execution times. QO will stop at the threshold and consider the least-costly query plan at that point, although there may be better unexplored options. This may result in a query execution that's suboptimal.

But I see an Optimizer Timeout with a simpler query?

Nothing with QO is simple (black and white). There are so many possible scenarios, its complexity so high that it is hard to grasp all of the possibilities. The Query Optimizer may dynamically adjust/set timeout threshold based on the cost of the plan found at a certain stage. For example, if a plan that appears relatively "cheap" is found, then the task limit to search for a better plan may be reduced. Therefore, grossly underestimated cardinality estimation may be one example for hitting an optimizer timeout early. In this case, the focus of investigation is cardinality estimation. This is a rarer case than the scenario that's discussed previously about running a complex query, but it is possible.

• Establish that the query under investigation is slower when you compare it to running on a different build of SQL Server or using a different CE configuration or different system. One of my mottos in performance tuning is "There is no performance problem without a baseline"
• Examine your query in detail when you determine its complexity. Upon initial examination, it may not be obvious that the query is complex and involves many joins. This is the common case when views or table-valued functions are involved. For example, on the surface the query may seem to be simple because it joins two views. But when you examine the views, you may find that each view joins 7 tables; When the two views are joined, you end up with a 14-table join.

• Force a particular plan: If you determine that a particular plan is better for your query through testing, ask QO to select that plan. To do this, check out the following reference articles:
  • How to force a plan by using Query Data Store (QDS)
  • Query hints OPTION (USE PLAN <XML PLAN HERE>)
  • Plan guides
• Try to reduce the permutations/possibilities that QO needs to consider. This involves testing the query with different options. Note: As is with most decisions with QO, the choices are not always deterministic because there is a large variety of factors considered. Therefore, there is no one guaranteed successful strategy. These may improve or worsen the performance of the selected query. For more information, see Query Hints:
  • Eliminate the order permutations: OPTION (FORCE ORDER)
  • Reduce the JOIN possibilities: OPTION (HASH JOIN, MERGE JOIN), OPTION (HASH JOIN, LOOP JOIN) or OPTION (MERGE JOIN)

• Change Cardinality Estimation (CE) configuration: You can attempt to change the Cardinality Estimation configuration by switching from Legacy CE to New CE or from New CE to Legacy CE. Changing the Cardinality Estimation configuration can cause the QO to pick a different path when SQL Server evaluates and creates query plans. So even if an optimizer timeout issue occurs, it is possible that you end up with a plan that performs more optimally than the one selected using the alternate CE configuration. For more information, see how you can assess and choose the best cardinality estimation configuration for your SQL Server system.

• Optimizer fixes: If you have not enabled QO fixes via T4199 or by using database compatibility levels for SQL Server 2016 and later or ALTER DATABASE SCOPED CONFIGURATION ..QUERY_OPTIMIZER_HOTFIXES = ON, you may consider applying these fixes. This may cause the optimizer to take a different path in plan exploration and therefore possibly end up with a more optimal query plan. For more information, see SQL Server query optimizer hotfix trace flag 4199 servicing model.

• Re-write the query: Consider breaking up the single multi-table query into multiple queries by using temporary tables. However, you shouldn't always do this, breaking up the query is just one of the ways to simplify the task for the optimizer. See the following sample:

select ...
from t1
join t2
on t1.id = t2.id
join t3
on t3.id = t2.id
join t4
on t4.id = t3.id

To optimize, try to break down into two queries:

select ...
into #temp1
from t1
join t2
on t1.id = t2.id

select ...
From t3
join #temp1
on t3.id = #temp1.id
join t4
on t4.id = t3.id

Important: Using Multiple Common Table Expressions (CTEs) is not an appropriate solution to simplify a query. Multiple CTEs will only increase the complexity of the query. Therefore, it’s counterproductive. CTEs appear to break a query logically, but they are combined into a single query and optimized as a single large join of tables in the end. 

Error: 26075, Severity: 16, State: 1. Failed to start a listener for virtual network name '<LISTENER NAME>'. Error: 10048.

The SQL Server (<INSTANCE NAME>) service entered the stopped state. The SQL Server (<INSTANCE NAME>) service terminated with the following service-specific error:  Only one usage of each socket address (protocol/network address/port) is normally permitted.

Cluster resource 'SQL Server (<INSTANCE NAME>)' of type 'SQL Server' in clustered role 'SQL Server (<INSTANCE NAME>)' failed. Based on the failure policies for the resource and role, the cluster service may try to bring the resource online on this node or move the group to another node of the cluster and then restart it.  Check the resource and group state using Failover Cluster Manager or the Get-ClusterResource Windows PowerShell cmdlet. The Cluster service failed to bring clustered role 'SQL Server (<INSTANCE NAME>)' completely online or offline. One or more resources may be in a failed state. This may impact the availability of the clustered role.

The configuration changes to the availability group listener were completed, but the TCP provider of the instance of SQL Server failed to listen on the specified port [<LISTENER NAME>:<PORT>]. This TCP port is already in use. Reconfigure the availability group listener, specifying an available TCP port. For information about altering an availability group listener, see the “ALTER AVAILABILITY GROUP (Transact-SQL)” topic in SQL Server Books Online. (Microsoft SQL Server, Error: 19486)

Error: 19476, Severity: 16, State: 4. The attempt to create the network name and IP address for the listener failed. If this is a WSFC availability group, the WSFC service may not be running or may be inaccessible in its current state, or the values provided for the network name and IP address may be incorrect. Check the state of the WSFC cluster and validate the network name and IP address with the network administrator. Otherwise, contact your primary support provider. The Service Broker endpoint is in disabled or stopped state. Error: 26023, Severity: 16, State: 1. Server TCP provider failed to listen on [ <IP ADDRESS> <PORT>]. Tcp port is already in use. Error: 26075, Severity: 16, State: 1. Failed to start a listener for virtual network name ‘<LISTENER NAME>:’. Error: 10048. Stopped listening on virtual network name ‘<LISTENER NAME>:’. No user action is required. Error: 10800, Severity: 16, State: 1. The listener for the WSFC resource ‘<RESOURCE GUID>’ failed to start, and returned error code 10048, ‘Only one usage of each socket address (protocol/network address/port) is normally permitted.‘. For more information about this error code, see “System Error Codes” in the Windows Development Documentation. Error: 19452, Severity: 16, State: 1. The availability group listener (network name) with Windows Server Failover Clustering resource ID ‘<RESOURCE GUID>’, DNS name ‘<LISTENER NAME>’, port <PORT> failed to start with a permanent error: 10048. Verify port numbers, DNS names and other related network configuration, then retry the operation.

Solution:

For Windows 7/Server 2008 R2

For Windows Server 2012

For Windows 8.1/Server 2012 R2

• SQL Server:Database Replica –> Transaction Delay
• SQL Server:Database Replica –> Mirrored Write Transactions/sec

1. When the task is running, it is in “Running” state and it is the active worker of the scheduler. 
2. When the task waits for nothing but CPU to run it is put into “Runnable” queue of a scheduler 
3. When the task is waiting for something (like lock,disk I/O, etc) it is in “Suspended” state. 
4. If the suspended task finishes the waits (wait for nothing) and is ready to run, it is put to the end of the Runnable queue. 
5. If the running thread voluntarily yields it is put back to end of Runnable queue. 
6.  If the running thread needs to wait for something it is switched out of the scheduler and is put into suspended status. 
7. If the running thread finishes its work then the top thread of the runnable queue becomes the “Running” thread. 

• SQL Server:Database Replica –> Transaction Delay
• SQL Server:Database Replica –> Mirrored Write Transactions/sec

 

 

1. Network latency between replicas. In above example, it is 3.907+0.587=4.494 seconds 

1. Log harden on Primary=0.663 seconds 

1. Log harden on Secondary=0.663 seconds 

"If the clustered index is not created with the UNIQUE property, the Database Engine automatically adds a 4-byte uniqueifier column to the table. When it is required, the Database Engine automatically adds a uniqueifier value to a row to make each key unique. This column and its values are used internally and cannot be seen or accessed by users."

Msg 666, Level 16, State 2, Line 1

The maximum system-generated unique value for a duplicate group was exceeded for index with partition ID <PARTITIONID>. Dropping and re-creating the index may resolve this; otherwise, use another clustering key.

Important: This is something that is not documented and can change in future versions, so our recommendation is that you should review table design to avoid relying on it.

1. Cached meta you scanned

2. Pre-processed the SQL meta files so loading time will be in seconds instead of minutes, and the size of the tool reduces from 40MB to 4MB.
3. Use multi-threading technology to load registry keys asynchronously and in parallel. This help reduce the time to scan the registry keys. With these technologies now the tool runs 2 times faster.
4. Put some scan task to background so you can get the UI sooner to browse the keys.
5. If you export the keys the result detailed text file will have remark about what the keys belongs to. For example, below entry tells you the key is for “SQL Server 2008 R2 Management Studio”: