Page History
...
- Heavy Statement
- Heavy Collapsed Statement
- Major Statement in Batch
- Heavy Operators
- Missing Indexes
- Missing Statistics
- Table Schema Change May Increase Its Accessing Time
- Statement Is Not Scalable
- Table Growth May Increase Its Accessing Time
- Increase in Resource Consumption
- Statement or Batch Was Locked
- Statement Activity Consistently High
Anchor | ||||
---|---|---|---|---|
|
...
Column | Description |
---|---|
What to do next | Perform one of the following options:
|
Advice | Perform the following options:
|
Anchor | ||||
---|---|---|---|---|
|
The average In MS-SQL time of the statement increased following a major change in table size.
Table 13-9 Table 9 Table Growth May Increase Its Accessing Time findings
Column |
---|
...
Description |
---|
What to do |
...
next | Examine the information displayed in the History tab in the SQL tab to identify volume changes and correlate these changes to performance degradation. |
Advice |
...
Volume changes may effect response time especially in: |
...
|
...
|
...
|
...
|
...
|
...
|
Anchor | ||
---|---|---|
|
...
|
The SQL Server resources consumed by the statement increased by n%.
n%.
Table 13-10 Increase 10 Increase in Resource Consumption findings
Column |
---|
...
Description |
---|
What to do |
...
next | Perform one of the following options: |
...
|
...
|
...
|
...
|
Advice |
...
The average In MS-SQL time of the statement or batch has increased but not as a result of major table growth, scalability change or schema changes. A major change can result from a change in the execution plan. Examine the history of the statement and try to identify whether a major change took place. Compare explain plans using the Compare tab. Check instance behavior. An increase in instance execution over time, may affect the performance of regular statements. |
Anchor |
---|
...
|
Much of the statement or batch time was spent waiting for a lock. Regular locks can be categorized as follows:■ During
- During the blocker session, a locked statement or batch ran for a short period of time. Afterwards the session was idle or continued running other statements or batches. In this case, it is possible to identify the blocker session, but not necessarily the blocker statement or batch.
...
- During the blocker session, a locked statement or batch ran for a long period of time. Identifying the blocker statement or batch is easier in this case.
...
Table 13-11 Statement 11 Statement or Batch Was Locked findings
Column |
---|
...
Description |
---|
What to do |
...
next | Perform one of the following options: |
...
|
...
|
...
|
Advice |
...
Identify the blocker session in the Activity tab and examine the application and application timing. Examine the lock chain to identify the statement or batch holding the lock: |
...
|
...
|
...
|
...
|
...
|
Anchor | ||
---|---|---|
|
...
|
Total In MS-SQL time of the statement was consistently high and reached the thresholds of the top statements.
Table 13-12 Statement 12 Statement Activity Consistently High findings
Column |
---|
...
Description |
---|
What to do |
...
next | Perform one of the following solutions: |
...
|
...
|
...
|
Advice |
...
The In MS-SQL time of the statement is consistently high for the select time frame, as compared with resource consumption of the previous week. This finding is issued when the statement shows up within the top resource consumers of your application, their resource consumption was always high, and no major change in resource consumption occurred during the last two weeks. Check which resource is most-consumed by the statement or batch and determine how you can make it available to the statement. For example: Consider scheduling different activities that uses the same resource at different times, thereby freeing the resources for the statement. |
Anchor | ||||
---|---|---|---|---|
|
...