na2009 enus sql_04

Chapter 4: Performance Audits

4-1

CHAPTER 4: PERFORMANCE AUDITS Objectives

The objectives are:

• Create and setup a test environment for troubleshooting purposes. • Run a performance audit using System Monitor. • Monitor performance using the Client Monitor tool. • Identify the clients that cause performance problems using Session

Monitor. • Create trace files using Microsoft® SQL Server® Profiler and analyze

the trace files. • Use the Database Engine Tuning Advisor to analyze indexes and

data partitioning. • Use Dynamic Management Views to analyze performance data. • Collect performance-related data using additional scripts, tools and

reports.

Introduction Monitoring server performance helps keep your servers functioning optimally and helps you identify bottlenecks in the system. You can use the performance monitoring data to identify problems and apply corrective action. You can also use the monitoring data to enhance the performance of your servers by identifying areas that need additional resources. For example, you may need to increase your storage capacity to handle the growing number of users in your organization.

If your organization is small, or if you rely on one server for most of the Microsoft SQL Server® operations, you may need to monitor only one server. If you have a larger organization, or if you want to monitor the performance of all servers and components in SQL Server, you can use System Monitor, which is a Windows Server 2003 component.

You can also use the Windows Performance Monitor, a Windows Server 2003 snap-in, to verify that your operating system is functioning correctly. The Windows Performance Monitor, which is made up of the System Monitor and Performance Logs and Alerts snap-ins, is the primary tool set used to analyze and maintain SQL Server and operating system performance levels. The Windows Performance Monitor is quite flexible and can be used to collect data interactively from a single server or automated to collect data from many servers. For more information about how to use the Performance console, see the Windows Server 2003 documentation Windows Server 2003 documentation (http://www.microsoft.com/windowsserver2003/proddoc/default.mspx).

Microsoft Official Training Materials for Microsoft Dynamics ® Your use of this content is subject to your current services agreement

SQL Server Installation and Optimization for Microsoft Dynamics® NAV 2009

4-2

You can also use Task Manager (Taskmgr.exe) to obtain information about the processes and programs that are running on your local computer.

There are important differences between Task Manager and the Windows Performance Monitor, such as the Windows Performance Monitor captures data to a file whereas the Task Manager can end a process. Task Manager is primarily a troubleshooting aid, and the Windows Performance Monitor is used for more detailed troubleshooting and analysis.

Set up a Test Environment Before troubleshooting and solving performance problems that exist in a working installation, you generally need to set up a separate test environment.

Setting up a test environment means the following:

1. Setting up a separate database server. The test server should be set up on a separate computer and not on the computer used by the production system. Using a separate test environment gives you complete control over the system and over who has access to it. It also means that the customer can continue to use the production system.

2. Copying the production system database to the test server. If you are running on SQL Server, use the backup/restore functions in SQL Server Management Studio to make a fast copy of the database to the test server. If you are running on Classic Database Server, you can use the server-based backup program HotCopy.

3. Warming up the server, to ensure that you get realistic measurements. You must warm up the test server regardless of which server option you are using.

Warming Up SQL Server

If you have just turned SQL Server on or if you have just created the database or company, you must warm up SQL Server by using the database and the company. This ensures that the system resembles the actual customer installation and means that you can generate realistic performance measurements.

You only need to run an initial test to warm up SQL Server. When SQL Server is warmed up, the execution plans for most queries have already been generated and are ready for use. Furthermore, the most frequently used data is now available in memory.

When SQL Server is not warmed up, you will, for example, see that inserting, modifying or deleting records in a table can take more time to finish. This would usually be done much faster in an active SQL Server installation.

To warm up a SQL Server, you can use an SQL script that contains a specific workload, or create a SQL Server Profiler trace file and replay the file afterward.



4-3

Performance Indicators

When you connect a client to Classic Database Server, you can see status information for server calls that take two or more seconds in the status bar.

Typical server calls that generate status information are as follows:

• Server calls that modify or delete sets of records. • Server calls that scan an index or an entire table to find some data. • Server calls that need to lock a record or a table can be forced to wait

until other transactions are committed and release the locks that they placed.

Therefore, you should monitor the indicator in the status bar when trying to identify problematic tasks because this information may be all you need to break down a performance problem.

However, if you are using the Microsoft SQL Server Option for Microsoft Dynamics NAV, the client's user interface has no indicators to tell you how much time is spent on long-running tasks. You therefore need some other procedures to break down a performance problem on SQL Server.

Performance Problems

Performance issues can occur at any time and can be caused by many things. Some of the most common causes are as follows:

• System resource contention • Application design problems • Queries or procedures that have long execution times • Blocking

Performance issues normally occur unexpectedly, but sometimes they can be predicted. A disk or memory failure, for example, is difficult to predict and is frequently detected after the problem arises. However, a performance issue that is caused by a missing index can be detected proactively, by monitoring the system resources and the database activity. Often, the monitoring information will show a specific trend. In the beginning, when there is little data in the system, the issue will not be visible in the counters. As more data is added to the database, one or more counters will start behaving differently.

Troubleshooting performance issues involves the use of a series of steps to isolate and determine the cause. Identifying these causes is typically very time-consuming, and you may spend several days evaluating the collected information. If there are performance issues, you can use the following troubleshooting scenario:

1. Check the hardware configuration.



4-4

2. Check the hardware performance. 3. Check the database design.

When you are trying to identify any bottlenecks that exist in an installation, we recommend that you start by checking the hardware that the installation is running on. The first thing to verify is whether the hardware meets the system and configuration requirements. Identify which RAID level is used. And are you using separate disks for database and transaction log files (or is everything placed on the same disk)?

If the configuration seems correct, you should start to look at the performance of the hardware. For example, does the server have sufficient memory to serve all requests, or is the server constantly paging because of a memory shortage, causing excessive disk I/O and CPU usage?

Finally, you can analyze the queries that are running on SQL Server. By monitoring the activity inside the database, you can see which queries cause the performance issue. Afterward, you can take the steps that are required to solve the problem.

Performance problems that are related to specific tasks should always be tested in the test environment, when no other users are logged on to the database server. This helps you determine whether the performance problem is related to the task itself, or if the problem only occurs when the task is executed in combination with other tasks on the same server.

Deadlocks occur when concurrent transactions try to lock the same resources but do not lock them in the same order. This can be either solved by always using the same locking order or by using a "locking semaphore" that will prevent these transactions from running concurrently.

To monitor the SQL Server installation, you can use several tools that will be described in the next sections.

System Monitor You can use System Monitor to obtain comprehensive information about your computer and about instances of SQL Server running on your computer. You can then use this information to diagnose performance issues and identify bottlenecks in the system. In this lesson, you learn how to use the System Monitor tool to collect and view real-time or logged data for memory, disk, processor and SQL Server activity.

With Performance Logs and Alerts, you can collect performance data automatically from local or remote computers. You can view logged counter data using System Monitor or import the data into spreadsheet programs or databases for analysis and report generation.



4-5

System Monitor

System Monitor is an MMC snap-in that can be used to view system performance metrics such as processor and memory utilization or disk activity statistics.

You can view System Monitor by starting the Performance application in the Administrative Tools program group. Alternatively, you can click Start, and then Run in the Windows Taskbar and enter perfmon.exe in the Run window.

System Monitor categorizes information into objects, counters and instances. Understanding how objects, counters and instances are related to one another is critical to using System Monitor effectively.

• Objects - in System Monitor, objects are major components or subsystems of the computer system. Objects can be hardware (for example, a hard disk), software (for example, a process), or applications (for example, an instance of SQL Server). There are a fixed number of objects in Windows Server 2003, and installing SQL Server adds more objects specific to SQL Server to the list.

• Counters - counters collect data about different aspects of objects. For example, for the Process object, counters collect data on the % processor time and the user time. Counters are built into the operating system and continually read performance data, whether it is visible in System Monitor or not. If an object has multiple instances, counters track statistics for each instance or for the total of all instances.

• Instances - instances are multiples of the same object type. For example, if a system has multiple processors, the Processor object type will have multiple instances. When you view performance information in System Monitor, you can choose to view the values for an individual instance of an object (for example, the utilization of a single processor) or the combined values for all instances (for example, the overall processor utilization across all processors in the system).

In System Monitor, you can specify which counters are to be displayed. You can display the counter values as a graph, a histogram (bar chart), or a report. Graphs, histograms and reports can be viewed in a browser and printed when performance data is saved as an HTML file. Reports can be exported into a spreadsheet, such as Microsoft® Office Excel® for further analysis.

Performance Logs and Alerts

In addition to the System Monitor MMC snap-in, the Performance tool includes a second snap-in named Performance Logs and Alerts. You can use this snap-in to capture performance information to a log file for later viewing in System Monitor. There are two types of log files: counter logs and trace logs. Counter logs record data about hardware resources and system resources based on performance over time. Counter logs are useful for tracking trends. Trace logs are used to record memory and resource events.



4-6

Log files provide useful information for troubleshooting and planning. While charts, alerts, and reports on current activity provide instant feedback, log files enable you to track counters over a long period of time. Thus, you can examine information more thoroughly and document system performance.

You can configure alerts that fire when a counter reaches a specific threshold value. Alerts are useful if you are not actively monitoring a particular counter but want to be notified when it exceeds or falls below a specified value so that you can investigate and determine the cause of the change. For example, you can set an alert to fire when the percentage of disk space used exceeds 80 percent or when the number of failed logon attempts exceeds a specific number.

NOTE: Alerts in System Monitor, though they perform a similar function, are not related to alerts in SQL Server.

For more information about how to create and configuring alerts in Windows Server 2003, see Microsoft Knowledge Base article 324752 How to Create and Configure Performance Monitor Alerts in Windows Server 2003 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324752).

NOTE: The alert functionality depends on the Windows Server 2003 Messenger Service, the Windows Server 2003 Alerter Service, and the existence of the recipient account registration in the Windows Internet Name Service (WINS). The Messenger and Alerter services are disabled by default and must be enabled and started to allow network messages to be transmitted.

SQL Server Performance Objects

SQL Server provides objects and counters that can be used by System Monitor to monitor activity in computers running an instance of SQL Server. An object is any SQL Server resource, such as the SQL Server Lock Manager. Each object contains one or more counters that determine various aspects of the objects to monitor. For example, the SQL Server Locks object contains the Number of Deadlocks/per second and Lock Timeouts/per second counters.

SQL Server Objects

The following table describes the most commonly used SQL Server Objects.

Performance object Description

SQLServer:Access Methods

Searches through and measures allocation of SQL Server database objects (for example the number of index searches or number of pages that are allocated to indexes and data).

SQLServer:Buffer Manager

Provides information about the memory buffers used by SQL Server, such as free memory and buffer cache hit ratio.



4-7

Performance object Description

SQLServer:Databases Provides information about a SQL Server database, such as how much log space is available or the number of active transactions in the database. There can be multiple instances of this object.

SQLServer:General Statistics

Provides information about general server-wide activity, such as the number of users who are connected to an instance of SQL Server.

SQLServer:Locks Provides information about the individual lock requests made by SQL Server, such as lock time-outs and deadlocks. There can be multiple instances of this object.

SQLServer:Memory Manager

Provides information about SQL Server memory usage, such as the total number of lock structures currently allocated.

SQLServer:Plan Cache Provides information about the SQL Server cache used to store objects such as stored procedures, triggers and query plans.

SQLServer:SQL Errors Provides information about SQL Server errors.

SQLServer:Transactions Provides information about the active transactions in SQL Server such as the overall number of transactions and the number of snapshot transactions.

There are many other SQL Server objects and some SQL Server Agent objects. When multiple instances of SQL Server are installed on the same computer, each instance has its own set of performance objects.

Considerations for Monitoring SQL Server

Monitoring an instance of SQL Server requires analysis of some key aspects of the system, such as disk system, memory, and CPU. Eliminating the physical bottlenecks can immediately affect performance and further isolate the design issues in the database, Transact-SQL queries, or client applications.

It is important to monitor SQL Server performance so that you can identify bottlenecks, determine their cause, and eliminate them. Bottlenecks can be eliminated by upgrading or optimizing hardware, by distributing server load among other SQL Servers, or by tuning SQL Server databases, indexes and queries.

While System Monitor and Performance Logs and Alerts show information about system resources, they do not show any information on the database activity that is going on at the same time.



4-8

System Monitor shows you the current activity. Performance Logs and Alerts allows you to create counter logs containing specific counters. The counter logs can run in the background and collect information over a longer period, so you can see when the performance issues occur and to analyze trends. Counter logs can be scheduled to run automatically in a specific time interval and can be used to document system performance. Measurements can be saved either to a file or to an SQL database.

Monitoring Disk Activity

SQL Server uses Windows operating system input/output (I/O) calls to perform read and write operations on your disk subsystems. SQL Server manages how and when disk I/O is performed, but the Windows operating system performs the underlying I/O operations. The I/O subsystem includes the system bus, disk controller cards, disks, tape drives, CD-ROM drive, and many other I/O devices. Disk I/O is a frequent cause of system bottlenecks.

Monitoring disk activity involves two areas of focus:

• Monitoring disk I/O and detecting excess paging • Isolating disk activity that SQL Server creates

You can monitor the following counters in the PhysicalDisk object to determine disk I/O and detect excess paging.

Counter Description Guidelines

% Disk Time

Monitors the percentage of time that the disk is busy with read/write activity.

If this counter is high (more than 90 percent), check the Current Disk Queue Length counter to see how many system requests are waiting for disk access.

Avg. Disk Queue Length

Monitors the average number of read/write requests that are queued.

This counter should be no more than twice the number of spindles that make up the physical disk.

Current Disk Queue Length

Monitors the current number of read/write requests that are queued.

This counter should be no more than twice the number of spindles that make up the physical disk.

The Disk Read Bytes/sec and Disk Write Bytes/sec counters indicate the maximum throughput of a disk. Use the values of the Current Disk Queue Length and % Disk Time to detect bottlenecks within a subsystem. If Current Disk Queue Length and % Disk Time counter values are consistently high, consider taking one of the following actions:

• Use a faster disk drive



4-9

• Move some files to an additional disk or server • Add disks to a RAID array (if one is used)

NOTE: If you have more than one logical partition on the same hard disk, use the LogicalDisk counters rather than the PhysicalDisk counters.

Monitor the Page Faults/sec counter in the Memory object to make sure that the disk activity is not caused by paging. A page fault occurs when the operating system cannot find the requested information in its physical memory, forcing the operating system to seek the information at the disk level. A soft page fault is when a page is found elsewhere in the physical memory, and a hard fault requires disk access. Most processors can handle large numbers of soft faults without any significant consequences. However, hard faults, which require disk access, can cause significant delays. In general, the value of this counter should stay below 20-25 pages per second (per processor).

You can monitor the following counters in the SQL Server:Buffer Manager object to isolate the disk activity generated by SQL Server components.


Page reads/sec

Number of physical database page reads that are issued per second. This statistic displays the total number of physical page reads across all databases.

Minimize the number of reads either by using a larger data cache, intelligent indexes and more efficient queries, or by changing the database design.

Page writes/sec

Number of physical database page writes issued per second.

Minimize the number of writes either by using a larger data cache, intelligent indexes and more efficient queries, or by changing the database design.

If the values for these counters approach the capacity limit of the hardware I/O subsystem, try to reduce the values by tuning your application or database to reduce I/O operations (such as index coverage, better indexes, or normalization), increasing the I/O capacity of the hardware or adding memory.

Monitoring CPU Usage

Monitor an instance of SQL Server periodically to determine whether CPU usage rates are within usual ranges. A continually high rate of CPU usage may indicate the need to upgrade the CPU or add multiple processors. Alternatively, a high CPU usage rate may indicate a poorly tuned or designed application. Optimizing the application can reduce CPU use.



4-10

Use the counters described in the following table to monitor CPU usage.


Processor - % Processor Time

Monitors how long the CPU spends executing a thread that is not idle.

A consistent state of 80 to 90 percent may indicate the need to upgrade your CPU or add more processors. For multiprocessor systems, monitor a separate instance of this counter for each processor.

Process - % Processor Time (sqlservr instance)

Monitors how long the CPU spends executing a thread in the SQL Server process.

Use this counter to assess the SQL Server contribution to overall processor utilization.

System - Processor Queue Length

Monitors the queue length per processor.

Recommended maximum value per processor is 2. Higher values usually indicate a CPU bottleneck.

Monitoring Memory Usage

You can monitor an instance of SQL Server periodically to confirm that memory usage is within typical ranges. You need to be sure that no processes, including SQL Server, consume too much memory or are constrained by insufficient memory.

To monitor for a low-memory condition, use the object counters described in the following table.

Counter Description Guidelines Memory - Available Bytes

Indicates how many bytes of memory are currently available for use by processes.

Low values of the Available Bytes counter can indicate an overall shortage of memory on the computer or that an application is not releasing memory.



4-11


Memory - Pages/sec

Indicates the number of pages that either were retrieved from disk because of hard page faults or written to disk to free up space in the working set because of page faults.

A high rate for the Pages/sec counter could indicate excessive paging. Monitor the Memory:Page Faults/sec counter to make sure that disk activity is not caused by paging. The counter will typically be high after SQL Server is restarted, but show a decreasing trend afterward.

Process - Page Faults/sec (sqlservr instance)

Windows Virtual Memory Manager takes pages from SQL Server and other processes as it trims the working-set sizes of those processes.

A high number of this counter indicates excessive paging and disk thrashing. Use this counter to check whether SQL Server or another process is causing the excessive paging.

Process - Working set (sqlservr instance)

Shows the amount of memory that is used by a process

If this number is consistently below the amount of memory that is set by the min server memory and max server memory server options, SQL Server is configured to use too much memory.

SQL Server Buffer Manager - Buffer Cache Hit Ratio

Monitors the percentage of required pages found in the buffer cache, without reading from the hard disk. Does not differentiate between physical memory and paging file memory that is used for buffer cache.

Add more memory until the value is consistently greater than 90 percent.

SQL Server Buffer Manager - Page Life Expectancy

Indicates the number of seconds a page remains in physical memory.

If this value is below 300 seconds, SQL Server is experiencing a memory shortage.

SQL Server Buffer Manager - Total Pages

Monitors the total number of pages in the buffer cache, including database, free and stolen pages from other processes.

A low number may indicate frequent disk I/O or thrashing. Consider adding more memory.



4-12


SQL Server Memory Manager - Total Server Memory (KB)

Monitors the total amount of dynamic memory that the server is using.

If this counter is consistently high in comparison to the amount of physical memory available, more memory may be required.

Miscellaneous Counters

Other than the hardware monitoring counters described in the previous sections, you can add various other counters that monitor the performance and that help identify bottlenecks in the system.


SQL Server:Locks - Lock Waits/Sec

Indicates the number of lock requests per second that require the caller to wait.

This number should be near 0. If the value is greater than 0 for a considerable period, the performance drop is most likely caused by locking and blocking issues within the database.

SQL Server:Locks - Lock Timeouts (Timeout > 0)/sec

Indicates the number of lock timeouts per second.

Recommended value is 0.

SQL Server:Locks - Number of Deadlocks/sec

Indicates the number of deadlocks per second.

Recommended value is 0.

SQL Server:Wait Statistics

Provides general information about the time SQL Server spends waiting due to several reasons. The different counters can help you identify bottlenecks in the performance of the log files, the data files, the network and so on.

In general, high values indicate that specific system components are not performing optimally. Further monitoring of the individual component is necessary.



4-13


SQLServer:Access Methods - Full Scans/sec

Monitors the number of full table scans that SQL Server performs to retrieve data.

A high number can indicate insufficient indexes. Recommended value is less than 2. Use the sys.dm_index_usage_stats dynamic management view to view the index statistics or run Database Engine Tuning Advisor to analyze current indexes.

SQLServer:Access Methods - Page Splits/sec

Monitors the number of times a page is full and split between the current page and a new allocated page.

Page splits occur when a data or index page is full. Excessive splitting can cause a high disk I/O. Consider adjusting the fill factor of your indexes.

SQLServer:Access Methods - Table Lock Escalations/sec

This reports the number of times a table lock was asked for in a second.

A high number can indicate insufficient indexes.

SQLServer:Access Methods - Worktables created/sec

Indicates the number of temporary work tables that SQL Server is creating.

A high number can indicate insufficient indexes.

SQLServer:SQL Statistics - Batch Requests/sec

Monitors the number of Transact-SQL command batches received per second.

High batch requests indicate good throughput. Recommended values frequently depend on hardware. In general, values around 1000 indicate a CPU bottleneck. If values grow higher, consider adding a faster network card.

SQLServer:SQL Statistics - SQL Re-Compilations/sec

Monitors the number of statement recompiles per second.

As recompiles consume CPU time, try to reduce the number of recompiles. A value of 100 indicates unnecessary compilation overhead. This counter should be compared with the Batch Requests/sec.



4-14

Demonstration: Setup Disk Activity Monitoring

Recently, Mort, the IT Systems developer, received several support requests about server performance. Users have been complaining about long execution times, sometimes resulting in deadlocks. Mort reports this to Tim, the IT Manager, who will setup some monitoring on the SQL Server.

Tim will monitor disk activity, memory and CPU usage. He will also monitor the number of deadlocks in SQL Server.

1. On the Windows taskbar, select Start and then Run. 2. In the Run window, enter perfmon and then click OK. The

Performance Microsoft Management Console including the System Monitor and Performance Logs and Alerts snap-ins will appear.

FIGURE 4.1 THE PERFMON TOOL

The bottom right pane shows the resources currently being monitored. In the upper right pane, you see the visualization of the counter values. By default, there are three counters, whose values are displayed in a graph object.

3. Right-click the graph object in the upper right pane and select Add Counters.

4. In the Add Counters window, select the computer that you want to monitor. You can either select the local computer or other computers in the network. In this case, Tim selects the local computer.



4-15

5. In the Performance object field, select PhysicalDisk. 6. Choose the Select counters from List option. 7. In the left list box, select % Disk Time. 8. Choose the Select Instances from List option. 9. In the right list box, select the C drive. 10. Click the Add button. 11. Repeat steps 7 to 10 for the Current Disk Queue Length and Avg.

Disk Queue Length counters.

To monitor the disk activity generated by SQL Server, Tim adds two more counters from the SQL Server:Buffer Manager object.

1. In the Performance object field, select SQL Server:Buffer Manager.

2. Choose the Select counters from List option. 3. In the left list box, select Page reads/sec. 4. Click the Add button. 5. In the left list box, select Page writes/sec. 6. Click the Add button.

Finally, to detect the I/O caused by paging, Tim will add the Page Faults/sec counter from the Memory object.

1. In the Performance object field, select Memory. 2. Choose the Select counters from List option. 3. In the left list box, select Page Faults/sec. 4. Click the Add button.

Demonstration: Setup CPU Monitoring

As a next step, Tim will add counters to monitor the CPU. The % Processor Time counter from the Processor object is displayed by default. To monitor the CPU time claimed by SQL Server, Tim adds the % Processor Time from the Process object.

1. In the Performance object field, select Process. 2. Choose the Select counters from List option. 3. In the left list box, select % Processor Time. 4. Choose the Select Instances from List option. 5. In the right list box, select the sqlservr process. 6. Click the Add button.



4-16

Demonstration: Setup Memory Monitoring

As a third step, Tim will add counters to monitor the server memory. The Pages/sec counter is added by default. The number of page faults per second has been added when monitoring disk activity. Tim wants to know whether SQL Server has sufficient memory, so he decides to add the Buffer Cache Hit Ratio counter.

1. In the Performance object field, select SQL Server:Buffer Manager.

2. Choose the Select counters from List option. 3. In the left list box, select Buffer Cache Hit Ratio. 4. Click the Add button.

Demonstration: Setup Lock Monitoring

As a final step, Tim will add counters to monitor the number of locks and deadlocks in SQL Server.

1. In the Performance object field, select SQL Server:Locks. 2. Choose the Select counters from List option. 3. In the left list box, select Number of Deadlocks/sec. 4. Choose the Select Instances from List option. 5. In the right list box, select the Database option. 6. Click the Add button.



4-17

The result should look as follows:

FIGURE 4.2 COUNTERS IN THE PERFMON TOOL WINDOW

Demonstration: Create a Counter Log

Tim has modified the default counters of System Monitor. However, he cannot watch System Monitor all the time. He wants to save the measurements in a counter log file so that he can analyze the data when he has time. Tim will also use counter logs to track trends. If necessary, he can go back months to confirm a change in resource usage. Moreover, by keeping logs, he can see exactly when a problem originated.

Perform the following steps to create a counter log.

1. On the Windows taskbar, select Start and then Run. 2. In the Run window, enter perfmon and then click OK. The

Performance Microsoft Management Console including the System Monitor and Performance Logs and Alerts snap-ins will appear.

3. In the left pane, under Performance Logs and Alerts, right-click Counter Logs and select New Log Settings.

4. In the New Log Settings window, enter a name for the log. For example, the name of the server or object to measure. In this case, Tim enters NAV-SRV-01.



4-18

5. Click OK to close the New Log Settings window. The NAV-SRV-01 window appears.

6. In the Current Log File Name field, enter a path and a name for the counter log files. The default folder for the log files is C:\PerfLogs. You can change the default folder and log name if you want.

7. Click the Add Counters button to add individual counters, as shown in the previous demonstrations. To select multiple counters in an object, press the Ctrl key at the same time you select the counters.

8. In the Interval and Units fields, leave the default values. Be aware that smaller intervals imply more accurate event information, but also require more disk space.

9. Click the Apply button to create and activate the counter log.

To modify the counter log, right-click the counter log and select Properties. To stop or start a counter log, right-click the log and select either Stop or Start.

Tim has defined and activated a counter log to monitor the system resources. While watching the System Monitor, he sees the % Processor Time counter peaking at almost 100%.

FIGURE 4.3 THE SYSTEM MONITOR WINDOW SHOWS INCREASED % PROCESSOR TIME

He needs to find out what is happening on the server. In the meantime, he leaves the counter log running.



4-19

Client Monitor The Client Monitor is an important tool for troubleshooting performance and locking problems. You can also use it to identify the worst server calls and to identify index and filter problems in the SQL Server Option. The Client Monitor and the Code Coverage tool now work closely together allowing you to easily identify, for example, the code that generated a particular server call.

Import Client Monitor

The Client Monitor displays all the details of the server calls made by the current client, including the time spent on each server call. All the trace information is stored in the Monitor table (a virtual table stored in the Microsoft Dynamics NAV database). This makes it an invaluable tool when analyzing a particular task and studying the server calls that the task makes as well as the code that initiates the server calls.

This tool can be used with both server options. When you use the Client Monitor with the SQL Server Option it contains some additional options and fields that provide more insight into how your application is performing.

The Client Monitor tool is available on the Tools menu. However, to profile and analyze a given task in Microsoft Dynamics NAV using the Client Monitor, you must have some Client Monitor helper objects, which allow better analysis. The helper objects are part of the Microsoft Dynamics NAV Database Resource Kit, which is available on PartnerSource(https://mbs.microsoft.com/partnersource/downloads/supplements/databaseresourcekit.htm).

Client Monitor requires a Microsoft Dynamics NAV Classic client and only captures information about the server requests (SQL statements) from the current client. It does not contain information about the system resources. You can either analyze the Client Monitor information in Client Monitor or you can export the output to a file and analyze the data in Microsoft Office Excel. Be aware that in the standard version of the Client Monitor, the virtual table Monitor is cleared when you exit the Microsoft Dynamics NAV Classic client. If you use the extended version, remember to open form 150020, Client Monitor before exiting the Classic client. (Opening the form copies the data from the virtual table to a regular database table, so the information will be available for later analysis.) If you run the Code Coverage and Client Monitor tools, you can link the output of both tools and see which line of C/AL code a specific measurement is linked to. Analyzing locking problems requires multiple clients running the Client Monitor. To find deadlocks, you must enter the locking rules.



4-20

Profile a Task

After you have imported and compiled the Client Monitor helper objects, you can start profiling a task.

1. On the Tools menu, click Debugger and then Code Coverage to open the Code Coverage window.

2. Start the Code Coverage tool and then start the Client Monitor just before you are ready to perform the task that you want to investigate.

3. Perform the task that you want to test. 4. When you have finished the task, stop the Client Monitor and then

stop the Code Coverage tool. The Client Monitor uses many lines to describe a single server call, and this makes it difficult to use for data analysis.

5. Run form 150020, Client Monitor. This processes the data from the Client Monitor and displays it in a new window.

The Client Monitor window displays and formats the data that has been collected by the Client Monitor so that it can be more easily analyzed. It performs a type of cross tabulation of the operations and parameters and uses one line per server call.

After you have profiled a specific task, you can start analyzing the information in the Client Monitor window. You can use the information to find the worst server calls and to detect locking problems.

Best Practices when Profiling a Task

When using these tools, make sure that your test tasks are focused on the area that you are interested in testing. If you spend time doing other tasks, both the Client Monitor and the Code Coverage tool will fill up with irrelevant information.

If you are analyzing a lengthy task that takes an hour or more to run, consider restricting the scope of the task. You can limit the task by applying filters that will make the task handle less data, or by stopping the task after several minutes. You can then use the Client Monitor data from the part of the task that was performed as the basis for your analysis.

You can analyze the Client Monitor data within Microsoft Dynamics NAV, or you can perform a more detailed analysis by importing the data into pivot tables in Excel.

Problematic Server Calls

Perform the following steps to identify the most problematic server calls:

1. Profile your task as described in the previous section.



4-21

2. Run form 150020, Client Monitor. 3. Click View and then Sort to sort the data in the Client Monitor

window. Sorting by Elapsed Time (ms) in descending order is a useful way to view the data.

The server calls that took the longest time will then be listed at the top. This helps you identify the worst server calls.

After you have identified the problematic server calls, you can optimize the slow queries that are caused by filters and keys that do not match (especially on SQL Server) by using the appropriate keys in the queries or possibly by changing the existing keys.

NOTE: Rearranging the fields in a key, for example, by moving the first field in a key to the end and by changing the references to the key (both in the code and in the properties), can solve a performance problem. Furthermore, any FlowFields in the key that are calculating sums are guaranteed to work as long as all the original fields are left in the key. If you remove some of the fields from a key, you can cause some FlowFields that are calculating sums to produce run time errors.

When you are developing an application, you will not encounter problems such as the one described here, unless you enter some pseudo-realistic amounts of data into the database.

Locking Problems

You can also use the Client Monitor to see whether locking prevents concurrent tasks from being executed at the same time and to identify where deadlocks occur in a specific multi-user scenario. Before you use the Client Monitor to identify potential locking problems, you must import the Client Monitor helper objects as described earlier in this lesson.

Before you try to identify locking problems, you must make sure the clocks are synchronized on all the client machines. You can set up computers running most Windows operating systems so that their clocks are automatically synchronized with the time on a server when they log on by using the following command: net time \\computername /SET .

1. Start the Client Monitor on all the computers involved in the multi-user test.

2. Perform the tasks that you want to test. 3. Stop the Client Monitor on all the computers. 4. On each client computer, process the common client monitor data by

running form 150020, Client Monitor. 5. Run form 150024, Client Monitor (Multi-User) on one of the client

computers.



4-22

The Client Monitor (Multi-User) window contains information about the transactions that might have blocked other clients. The COMMIT in the transactions that might have blocked other clients is shown with the server calls made by the clients that are potentially waiting for the COMMIT to be completed. The other server calls are listed before the COMMIT.

1. Check the values in the Elapsed Time (ms) field to see whether there are any server calls that are taking longer than usual. A high value in the Elapsed Time (ms) field indicates that a server call is waiting for locks to be released. Use the filtering features in Microsoft Dynamics NAV to see all the details of the locking scenarios. The value in the Locking field is Yes when a server call locks data. You should put a filter on this field to limit the data.

2. If a deadlock has occurred on SQL Server, the SQL Error field in the Client Monitor (Multi-User) window will show the error message that is generated by SQL Server. To see all of these lines, set the filter "SQL Error<>''. These lines are marked red and bold.

Deadlocks

Two transactions can only cause a deadlock if they both lock some of the same tables. However, if both of the transactions are defined so that the first lock they place is on the same table, no deadlock will occur. In other words, a deadlock occurs when two or more transactions have a conflicting locking order.

To identify potential locking problems, you only need to use one client. You run the tasks on the client that you think might cause locking problems and collect all of the relevant data in the Client Monitor and then open a special form to see whether there are any potential deadlocks.

To find potential deadlocks:

1. Import the Client Monitor.fob file, if you have not already imported it.

2. Compile all the objects that are imported. This must be done because some of the field definitions are different on the two database server options.

3. Prepare the tasks that you want to run concurrently without any deadlocks occurring.

4. Open and start the Code Coverage tool and then open and start the Client Monitor.

5. Perform the tasks. 6. Stop the Client Monitor and then stop the Code Coverage tool. 7. Run form 150030, Potential Deadlocks (Navision).



4-23

The Potential Deadlocks (Navision) window lists all the potential deadlocks or locking order conflicts that occurred during the tasks you performed. It is based on an analysis of the locking order used in each write transaction that was carried out. Each line in the window contains information about two transactions that represent a potential deadlock. These transactions represent a potential deadlock because they both lock some of the same tables but lock them in a different order. Sets of transactions that do not contain a potential deadlock are not displayed. Each line in the window contains the following information.

From this form, you can access more detailed information about the locks that were placed by each transaction, as well as the code that was used.

From this form, you can access more detailed information about the locks that were placed by each transaction, as well as the code that was used.

Locking Order Rules

As stated in the previous section, a deadlock occurs when two or more transactions have a conflicting locking order and no deadlock can occur if the first lock the transactions place is on the same table.

So if you have an agreed set of rules that determine the locking order that must be used in your application then no deadlocks will occur. The problem is that agreeing to a set of rules is one thing, adhering to the rules is another thing completely. Remembering the rules is not as easy as it sounds - there could be lots of them.

There is also a tool that can help you see whether your application follows the locking rules specified.

This involves determining which rules must apply in your application, entering them into the system and then checking your application to see whether it violates the rules or not.

Entering Locking Rules

The most practical way to identify the locking order rules is to focus on the key procedures and document the order in which they lock the various tables. After you determine the rules that govern the locking order in your application, you can enter them into the system.

1. Run form 150029, Locking Order Rules. 2. Enter the rules that you want your application to follow. Each entry

represents a rule and you can enter as many rules as are needed.

Each rule specifies that one table must be locked before another table. Needless to say your rules must not contain any conflicts.



4-24

Verifying Locking Rules

The consistency of the rules is checked when you test your application to see whether it follows the rules. If the rules contain a conflict you will receive an error message. After you have entered the rules, you can test whether your application follows the rules.


2. Perform the tasks that you want to test. 3. Stop the Client Monitor and then stop the Code Coverage tool. 4. Run form 150027, Transactions (Locking Rules). The

Transactions (Locking Rules) window appears listing the transactions that you performed.

5. In the Transactions (Locking Rules) window, check the Locking Rule Violations field. If any of the transactions violated the rules that you specified earlier a check mark is displayed in the Locking Rule Violations field.

6. Click Transaction, Locking Rules Violations to check the violation.

7. In Locking Rules Violations window, you can see whether and how your transaction violated the locking order rules. You can fix the code, amend the locking order rules or decide that the probability of the two processes running concurrently is minimal and ignore the violation.

Furthermore, the Transactions (Locking Rules) window offers the following functions:

• To see the C/AL code that broke the locking rule, select the transaction in question and then click C/AL Code. The Code Coverage window appears displaying the relevant code.

• To see all of the operations and tables involved in a particular transaction, select the transaction and then click Transaction and then Client Monitor.

• To see only the locking operations and the tables that were locked in a particular transaction, select the transaction and click Transaction and then Client Monitor (Locking Operations Only).

• To see the order in which tables were locked by a particular transaction, select the transaction and click Transaction and then Locking Order.

• To see the locking rules that were violated by a particular transaction and then select the transaction and click Transaction, Locking Rules Violated.



4-25

When testing the locking order rules, you can run the Code Coverage tool to help you identify the code that is causing the conflicts. However, the Code Coverage tool is quite a time intensive tool and should not be used for multiple transactions, or run for more than 10 minutes. It takes a long time to perform complex procedures when the Code Coverage tool is running and it also takes time to process the information in the tool afterward. If you only use the Client Monitor without the Code Coverage tool, you will most likely get enough information to identify the code that is causing the conflict.

Be aware that the only way to lock a record on SQL Server is to actually read it, whereas on Classic database server, you can use the LOCKTABLE command to dictate and define the locking order. The LOCKTABLE command on SQL Server Option does not do anything except flag internally that locks will be placed later when records are read.

In summary, you can run the Client Monitor on its own in a real-life environment without experiencing any major decrease in performance and still get the information needed to resolve incorrect locking order problems.

Keys

When you are using the SQL Server Option, it is important that any customizations that you develop contain keys and filters that are designed to run optimally on SQL Server. Microsoft has therefore developed a tool that helps you test your keys and filters in a development environment and ensure that they comply with the demands made by SQL Server.

To see whether an application contains any keys that might cause problems, you need a demonstration database and not a copy of the customer's database.

Inserting, modifying, and deleting records take a similar amount of time in both large and small databases. However, the time that it takes to read will be very different, especially for tables that become very large in the customer's database.

This means that an analysis based on the Elapsed Time (ms) field in the Client Monitor is not enough when you are troubleshooting performance problems in a small database.

To check whether the keys and filters are designed correctly:


2. Perform the task that you want to test. 3. Stop the Client Monitor and then stop the Code Coverage tool. 4. Open form 150022, Client Monitor (Key Usage).

Queries with filters that do not use the keys appropriately are shown in this window.



4-26

The key that is being used is split into two fields: Good Filtered Start of Key and Key Remainder. Fields that are filtered to a single value, but are not used efficiently on SQL Server because of the selection and ordering of fields in the key that is used, are shown in the Key Candidate Fields field.

Remember that SQL Server always wants a single-value field as the filter or as the first field in the filter.

The information in the Client Monitor (Key Usage) window is sorted by table name and only displays the queries with filters that can potentially cause problems. You will need to use your knowledge of the application being developed and the theory behind the design of keys for SQL Server to decide which of the queries can be ignored and which will have to be modified.

In general, consider the following:

• Ignore queries that use small tables that will not grow very large in the customer's database. An example of a small table that you can readily ignore is table 95, G/L Budget Name.

• Focus on the large tables and the tables that will grow quickly in the customer's database.

• Focus on the Key Candidate Fields and the Good Filtered Start of Key fields.

• As mentioned earlier, you should look at the Good Filtered Start of Key field. If this field is empty, check the Key Candidate Fields field and decide whether the fields shown here would have made a difference if they had been used efficiently. This is where your understanding of the application helps you.

You need to decide whether the suggested key will make the query run more efficiently or not. If the suggested filter is a field that contains many different values, it will probably help.

If you understand the theory behind the design of efficient queries, you will know whether it makes sense to change the application.

However, if you are uncertain about the theory you will have to test the suggested query. This means that you must use a database that contains a realistic amount of data and then test the existing filter and the suggested new filter to see which one works more efficiently.

NEXT Statements

When running SQL Server and reading data, some NEXT function calls can generate separate SQL statements instead of using the data that is stored in cache. This can cause performance problems. The Client Monitor also contains a tool that can help you locate the C/AL code that generated these problematic SQL NEXT statements.



4-27

To locate this C/AL code, you must perform the tasks in question, identify the problematic NEXT statements, and then locate the C/AL code that generated these statements.

1. Prepare the tasks that you want to perform. 2. Open and start the Code Coverage tool and then open and start the

Client Monitor. 3. Perform the tasks that you want to test. 4. Stop the Client Monitor and then stop the Code Coverage tool. 5. Run form 150023, Client Monitor (Cache Usage).

The Client Monitor (Cache Usage) window lists the problematic NEXT statements generated by the tasks that you performed. All of the normal NEXT statements are ignored.

These NEXT statements are problematic because they generate their own SQL statement and database call to retrieve data from the server and do not use the data that is already cached on the client. It is difficult to know with certainty why these NEXT statements behave in this manner. It might be due to the following:

• Because C/SIDE is unable to optimize this function. • A result of the way that the code is written.

However these NEXT statements only cause problems if they are run repeatedly as part of a long-running batch job and generate a large number of additional server calls.

To see the C/AL code that generated the SQL NEXT statements, select the line you are interested in and then click C/AL Code. The code that generated the statement is displayed in the Code Overview window.

Analysis in Microsoft Office Excel

You can use the Client Monitor together with Microsoft Excel to analyze the time that is spent by tasks that make many server calls (100+). You must begin by profiling the task as described earlier in this lesson. The data must then be transferred into Microsoft Office Excel.

Perform the following steps to transfer the data into Excel:

1. Run form 150020, Client Monitor. 2. Click Export and save as a .txt file. 3. In Excel, import the .txt file that you have just saved.

You now have a spreadsheet that contains the basic Client Monitor data.



4-28

Use the pivot tables in Microsoft Office Excel to generate a sorted list of the tables that take the most time. The pivot table must also list the functions that are used, the search method, and the search result for each table. You must check the server calls that generated the sums to see the average amount of elapsed time for each server call.

You can also create new spreadsheets that summarize different operations on various tables by using the Pivot Table feature.

To create a pivot table:

1. Click Data, PivotTable, PivotChart Report and then click Finish in the wizard that appears. You can now choose which breakdown of the Client Monitor elements you want to analyze. This example uses the typical elements.

2. In the PivotTable window, select the Table Name button and drag it over to the range that says "Drop Row Fields Here".

3. Repeat this procedure for Function Name, Search Method and Search Result placing each field to the right of the previous field.

4. Drag Elapsed Time (ms) over to the range that says "Drop Data Items Here".

A sum of the breakdown of timings per table/function, etc. is shown. Perform the following steps to list the most important tables first:

1. Double-click the Table Name field heading. 2. Select Advanced. 3. In the AutoSort options, select Descending. In the Using drop-down

list select Sum of Elapsed Time (ms).

To list the most important functions per table first, repeat this procedure for the Function Name field. If there are any totals that you do not want to see, right-click the field that contains the word Total and then click Hide. For more information about pivot tables, see the online help in Microsoft Office Excel.

If time is spent on modifications (INSERT, MODIFY, DELETE, MODIFYALL, DELETEALL) and the average time that is spent on modification server calls is high, you should check the keys in the table. The number and length of the keys influence the time it takes to make modifications on both database servers. On SQL Server, if the average time that is spent on modification server calls is very long, check whether there are SumIndexFields in the keys and whether the MaintainSIFTIndex property is set to Yes for these keys. Setting the MaintainSIFTIndex property to No for these keys can greatly improve the speed of modification server calls, but there will be some loss of performance for those tasks that generate sums using these keys.



4-29

Demonstration: Monitoring Code with Client Monitor

Mort needs to initialize a new field "Entry No. 2" in the Ledger Entry Dimension table. To do this, he writes a codeunit to copy the value from the Entry No. field to the Entry No. 2 field.

The C/AL code is as follows:

LEDim.SETRANGE("Entry No. 2", 0); WHILE LEDim.FIND('-') DO BEGIN LEDim."Entry No. 2" := LEDim."Entry No."; LEDim.MODIFY; END;

When he runs the code on the Test Database NAV (6-0) database, he notices that the code runs rather slowly. Before he runs the code in the live environment, he checks the performance of his code in the extended version of the Client Monitor as follows.

1. Open Microsoft Dynamics NAV 2009 Classic client. 2. In the Tools menu, select Object Designer to open the Object

Designer window.

Mort selects his codeunit. Before running his codeunit, he starts the Code Coverage tool and the Client Monitor tool, so he can link the performance data from the Client Monitor to the code information from the Code Coverage tool.

1. In the Tools menu, select Debugger > Code Coverage. 2. In the Code Coverage window, click the Start button. 3. In the Tools menu, select Client Monitor. 4. In the Client Monitor window, on the Options tab, and select all

options. 5. Click the Start button.

Now that both monitoring tools have been started, Mort starts his codeunit. As soon as the codeunit finishes, Mort stops both monitoring tools.

1. In the Code Coverage window, click the Stop button. 2. In the Client Monitor window, click the Stop button.

Mort now opens the extended version of the Client Monitor tool. As he is focused on the duration of the transaction, he sorts the Client Monitor information based on the Elapsed Time (ms) field.

1. In the Object Designer window, select Form 150020, Client Monitor.

2. Click Run to open the Client Monitor window. 3. On the View menu, select Sort.



4-30

4. In the Client Monitor - Sort window, in the Key field, select Login Date, Login Time, Connection ID, and Elapsed Time (ms).

5. In the Order field, select the Descending option. 6. Click OK to close the window.

The information will be sorted on Elapsed Time. The statements with the highest value will be displayed at the top.

FIGURE 4.4 THE CLIENT MONITOR WINDOW

When looking at the top lines, Mort notices that a lot of time is spent on MODIFY and FIND/NEXT statements.

Mort checks the SourceText column and sees that the Client Monitor line is linked to the LEDim.MODIFY statement.

FIGURE 4.5 THE SOURCETEXT COLUMN

Mort cannot do much about the MODIFY statement. Leaving it out is not an option, and he cannot use a MODIFYALL statement.



4-31

Mort decides to examine the FIND/NEXT function lines. He selects the second line in the Client Monitor window and clicks the C/AL Code button.

FIGURE 4.6 THE CODE COVERAGE WINDOW

The FIND/NEXT function is linked to the WHILE DO statement. Mort needs to find a faster way to go through the records.

Session Monitor You use the Session Monitor (SQL Server) to identify the clients that cause performance problems. As with the Client Monitor, you must import some helper objects before identifying the clients causing performance problems.

Before you can use the tool, you must read the following KB Article; KB 933042 - Error message when you use the Session Monitor feature in Microsoft Dynamics NAV: "Invalid length parameter passed to the substring function" (https://mbs.microsoft.com/knowledgebase/KBDisplay.aspx?WTNTZSMNWUKNTMMYLSVQUSPTNTNSMQPYLWVKVPNNSOMLNKYXSOONZRWVUTPWQPVL).

Import the Session Monitor

The Session Monitor (SQL Server)window displays updated information from the virtual Session table. Before identifying the clients that are causing performance problems, you must import some helper objects in the database. In addition, you need to run an SQL script to update the existing Session (SQL) view.

The helper objects and the SQL script are part of the Microsoft Dynamics NAV Database Resource Kit, which is available on PartnerSource(https://mbs.microsoft.com/partnersource/downloads/supplements/databaseresourcekit.htm).



4-32

Perform the following steps to import the Session Monitor:

1. Ensure that you have installed the client components for SQL Server from the Microsoft SQL Server CD.

2. Open the Microsoft SQL Server Management Studio and click New Query, File, and then Open.

3. Browse to the folder where you have stored the session monitor tools and open the Session Monitor (SQL Server).sql file.

4. In the toolbar, select the Microsoft Dynamics NAV database to monitor from the drop-down list of available databases.

5. Click Query and then Execute. The Session Monitor (SQL Server).sql script drops the current Session (SQL) view and creates a new view to replace it.

6. In Microsoft Dynamics NAV, open Object Designer and import the Session Monitor (SQL Server).fob file.

7. Compile all imported objects.

Start the Session Monitor

Perform the following steps to start the Session Monitor.

1. Run form 150014, Session Monitor (SQL Server), and click Monitor, and then Setup. The Session Monitor Setup (SQL) window opens.

2. Click the Log tab. 3. Select the Log Session Activity check box. Specify a time interval in

the Log Interval (sec) field. If you are only interested in identifying blocks that occur, select the Log only Blocks check box. You must enter a value in the Log Interval (sec) field, for example 15 seconds. Microsoft Dynamics NAV will now log the current level of activity once every 15 seconds. When Microsoft Dynamics NAV logs the activity, it runs through the active sessions and creates one entry per session. These entries are logged to the Session Information History table. If you select the Log only Blocks option, Microsoft Dynamics NAV only logs the sessions that are involved in blocking. This includes the sessions that are blocked and the sessions blocking others. Finding the correct setting for the Log Interval (sec) option is a matter of achieving the right balance between how accurately you want Microsoft Dynamics NAV to log activity, and how large a performance overhead you will accept. Fifteen seconds would seem to give a reasonable balance.



4-33

The Session Monitor creates a log entry every time the specified interval has elapsed and therefore any blocks that occur within the specified interval are not logged. If you want to make sure that the Session Monitor catches as many blocks as possible, decrease the interval to, for example, 5 seconds or less. To simultaneously decrease the performance overhead, select the Log only Blocks option so that only the sessions involved in a block are logged.

4. In the Session Monitor Setup (SQL) window, click Functions and then Start Logging. The Log Session Activity codeunit runs as a single instance codeunit. This means that the only way to stop the codeunit is to close and reopen the current company. However, you can suspend it by removing the check mark from the Log Session Activity option. The codeunit will continue to run in the background, but it will not log anything. To resume logging, you must restart the session and start logging again.

Viewing the Session Monitor Log

You can view the information collected by the Session Monitor in the Session Monitor (SQL Server) window.

The Session Monitor (SQL Server)window displays updated information from a SQL Server view. This view is similar to the one linked to the Session table. The Session Monitor (SQL Server) window tells you which clients are currently connected to the server and the current load on the server. The information is refreshed every second by default. This setting can be changed by clicking Monitor, Setup, and changing the number in the Refresh Rate (sec) field.

By default, the most active sessions in terms of the number of records scanned are shown at the top of the list. Follow the guidelines in the other sections to investigate these sessions.

By default, the most active sessions in terms of physical I/O (the number of records scanned), are listed at the top of the Session Monitor (SQL Server) window. The Records Scanned field shows how many records the database server has scanned to determine the records that this session wanted. The sessions with the largest number of scanned records are the sessions that should be investigated first. You can also list the sessions according to memory usage, as this is a good indicator of activity. SQL Server can also give you information about the CPU usage.

NOTE: In the Session Monitor (SQL Server) window, if the value in the Found/Scanned Ratio field is high, this indicates that the indexes and queries match. A value of 30-50% is normal, while 3% is low.

To investigate the most active sessions, follow the guidelines described in the following sections.



4-34

The Session Monitor (SQL Server) window also lists information about the clients that are waiting for locks held by other clients to be released, as well as the identity of the clients that placed the locks. If you want to concentrate on this area only, examine and/or filter the fields starting with Blocked (Blocked, Blocked by Connection ID, Blocked by User ID, Blocked by Host Name).

Analysis in Microsoft Office Excel

As mentioned earlier, the information collected by the Session Monitor is inserted into the Session Information History table. You can also use the Session Information History window to view this data.

The Session Information History window shows you all the entries that have been logged. You can analyze this information in Microsoft Dynamics NAV or export it to a .csv file and analyze it in Microsoft Office Excel.

Perform the following steps to export the log to and analyze it in Microsoft Office Excel:

1. Open Object Designer. 2. Run form 90015, Session Information History. 3. Click Functions and then Export, and in the Options tab specify a

file name and the location where you want to save the log file. Remember to use the extension .csv, for example, Log.csv.

4. Click OK to export the log file. 5. Locate the file and double-click it to open it in Microsoft Office

Excel.

Excel has a limitation of 1,048,576 rows. If the log contains more entries than this, you cannot open the file. This can be remedied by applying a filter and only exporting some of the entries. Alternatively, you can delete some of the entries and then export the rest. If you are close to the limit of 1,048,576 records, click Functions and then Count, to check how many entries are within the current filter.

SQL Server Profiler SQL Server Profiler provides the ability to trace server and database activity such as login, user and application activity. You can capture the data in a table, a file or a Transact-SQL script for later analysis.

What is SQL Server Profiler?

Microsoft SQL Server Profiler is a graphical user interface tool for monitoring an instance of the SQL Server Database Engine or Analysis Services. You can capture and save data about each event to a file or table to analyze later. For example, you can monitor a production environment to see which queries or stored procedures are affecting performance by executing too slowly.



4-35

Functions of SQL Server Profiler

SQL Server Profiler shows how SQL Server resolves queries internally, enabling administrators to view exactly which Transact-SQL statements are submitted to the server and how the server accesses the database to return result sets.

By using SQL Server Profiler, you can do the following:

• Create a trace based on a reusable template • Watch the trace results as the trace runs • Store the trace results in a table or file for further analysis • Start, stop, pause and modify the trace results as necessary • Replay the trace results

Use SQL Server Profiler to monitor only the events in which you are interested. If there is too much activity to examine easily, you can filter activity based on the information you want so that only a subset of the event data is collected. Monitoring too many events adds overhead to the server and the monitoring process, and can cause the trace file or trace table to grow very large, especially when the monitoring process occurs over a long period. To minimize the effect of monitoring on the SQL Server, you can start SQL Server Profiler on a second SQL Server.

Tracing SQL Server Activity by using SQL Server Profiler

To use SQL Server Profiler, first decide what to trace and then select the criteria. Activity that you might want to monitor includes the following:

• Poorly performing queries • Queries that cause table scans • Activities of individual users or applications • Performance of the tempdb database • Deadlock problems • Login attempts, failures, connections and disconnections • Logical disk reads and writes • CPU Use at statement level • Wait time for all post execution events



4-36

SQL Server Profiler Trace Options

When using SQL Server Profiler to create a trace, there are several options for defining the activity that it will record and where the logged trace activity will be stored.

Specifying a Trace Template

The events included in a trace are determined by specifying the event classes to monitor and the individual data values (columns) to record. Do this by selecting the template on which you want to base your trace, and then adding or removing individual event classes or columns and applying filters to limit the data collected based on specific criteria.

SQL Server Profiler offers several predefined templates that enable you to easily configure the events you are most likely to need for specific kinds of activity. The Standard template, for example, helps you create a generic trace for recording logins, logouts, batches completed, and connection information. Use this template to run traces without modification or as a starting point for additional templates with different event configuration. You can also create your own user-defined templates or modify the predefined templates.

Template Name

Template Purpose

SP_Counts Captures stored procedure execution behavior over time.

Standard Generic starting point for creating a trace. Captures all stored procedures and Transact-SQL batches that are run. Use to monitor general database server activity.

TSQL Captures all Transact-SQL statements submitted to SQL Server by clients and the time issued. Use to debug client applications.

TSQL_Duration Captures all Transact-SQL statements submitted to SQL Server by clients, their execution time (in milliseconds), and groups them by duration. Use to identify slow queries.

TSQL_Grouped Captures all Transact-SQL statements submitted to SQL Server and the time that they were issued. Groups information by user or client that submitted the statement. Use to investigate queries from a particular client or user.

TSQL_Locks Captures all of the Transact-SQL statements that are submitted to SQL Server by clients together with exceptional lock events. Use to troubleshoot deadlocks, lock time-out, and lock escalation events.

TSQL_Replay Captures detailed information about Transact-SQL statements that is required if the trace will be replayed. Use to perform iterative tuning, such as benchmark testing.



4-37

Template Name

Template Purpose

TSQL_SPs Captures detailed information about all executing stored procedures. Use to analyze the component steps of stored procedures. Add the SP:Recompile event if you suspect that procedures are being recompiled.

Tuning Captures information about stored procedures and Transact-SQL batch execution. Use to produce trace output that Database Engine Tuning Advisor can use as a workload to tune databases.

When tuning a Microsoft Dynamics NAV environment, we recommend that you start from the Tuning wizard and include the SP:StmtCompleted (in the Stored Procedures category) and SQL:BatchCompleted (in the TSQL category) events. To do benchmark testing, you can use the TSQL_Replay template.

For more information about trace templates, see SQL Server Profiler Trace Templates (SQL Server Profiler Trace Templates (http://msdn.microsoft.com/en-us/library/ms190176.aspx)).

Saving Trace Data

Save captured event data to a file or a SQL Server table when you need to analyze or replay the captured data at a later time. By saving a trace, you can do the following:

• Use a trace file or trace table to create a workload that is used as input for Database Engine Tuning Advisor.

• Use a trace file to capture events and send the trace file to the support provider for analysis.

• Use the query processing tools in SQL Server to access the data or to view the data in SQL Server Profiler. Only members of the sysadmin fixed server role or the table creator can access the trace table directly.

The following options are available when saving a trace to a table:

• The location and name of the table. • The maximum number of rows to store in the table.

The following options are available when saving a trace to a file:

• The location and name of the file. • The maximum file size.



4-38

• Trace behavior when the file is full (roll over to start at the beginning of the file again or create a new file).

• Trace processing by server or SQL Server Profiler. Configuring the server to process the trace can reduce the performance effect of tracing.

SQL Server Profiler traces can be combined with counter logs from the Performance Logs and Alerts snap-in. This way, you can link the performance information to specific database activities and analyze which query is being executed when performance drops. Furthermore, SQL Server Profiler traces can be analyzed by Database Engine Tuning Advisor.

Specifying a Trace Stop Time

Although SQL Server Profiler cannot be scheduled, you can set a trace stop time, which allows you to start a trace and have it run until a specific date and time. The ability to specify a stop time is useful when you want to record SQL Server activity for a predetermined period.

Trace Categories, Events and Columns

The information recorded in a trace is divided into categories. Categories contain events, each of which has attributes further defined by columns.

Trace Categories

In SQL Server Profiler, a category is a group of related event classes. Event classes consist of types of events that can be traced. The event class contains all the data columns that can be reported by an event.

Categories listed by default are as follows:

• Security Audit - includes event classes that are used to audit server activity.

• Sessions - includes event classes produced by clients connecting to and disconnecting from an instance of SQL Server.

• Stored procedures - includes event classes produced by the execution of stored procedures.

• TSQL - includes event classes produced by the execution of Transact-SQL statements passed to an instance of SQL Server from the client.

Each of the trace templates contains specific categories to monitor.



4-39

Events

An event is defined as the occurrence of an action within an instance of the SQL Server Database Engine. Events are further defined by their attributes, which are listed in data columns.

The default events available are described in the following table.

Category Event Description Security Audit

Audit Login Indicates that a user has successfully logged in to SQL Server.

Security Audit

Audit Logout Indicates that a user has successfully logged out of SQL Server.

Sessions ExistingConnection Indicates the properties of existing user connections when the trace was started. The server raises one ExistingConnection event per existing user connection.

Stored Procedures

RPC:Completed Indicates that a remote procedure call has been completed.

TSQL SQL:Batch:Completed Indicates that a Transact-SQL batch has been completed.

TSQL SQL:BatchStarting Indicates that a Transact-SQL batch is starting.

Columns

Data columns contain the attributes of events. SQL Server Profiler uses data columns in the trace output to describe events that are captured when the trace runs.

You can manage columns by using column filters to control what data is being collected. For example, use the Application Name filter to exclude any data generated by SQL Server Profiler itself. You can also organize columns into related groups by using the Organize Columns function.

Create a Trace

Perform the following steps to create a new trace in SQL Server Profiler.

1. On the File menu, click New Trace, and connect to an instance of SQL Server. The Trace Properties dialog box appears.

2. In the Trace name box, type a name for the trace. 3. In the Use the template list, select a trace template on which to base

the trace, or select Blank if you do not want to use a template.



4-40

4. To save the trace results, do one of the following: a. Click Save to file to capture the trace to a file. Specify a value

for Set maximum file size. The default value is 5 megabytes (MB).

b. Optionally, select Enable file rollover to automatically create new files when the maximum file size is reached. You can also select Server processes trace data, which causes the service that is running the trace to process trace data instead of the client application. When the server processes trace data, no events are skipped even under stress conditions, but server performance may be affected.

5. Optionally, select the Enable trace stop time check box, and specify a stop date and time.

6. To add or remove events, data columns or filters, click the Events Selection tab.

7. Click Run to start the trace.

Specify Events and Data Columns for a Trace

This topic describes how to specify event classes and data columns for traces by using SQL Server Profiler.

On the Trace Properties or Trace Template Properties dialog box, click the Events Selection tab.

The Events Selection tab contains a grid control. The grid control is a table that contains each of the traceable event classes. The table contains one row for each event class. The event classes can differ slightly, depending on the type and version of server to which you are connected. The event classes are identified in the Events column of the grid and are grouped by event category. The remaining columns list the data columns that can be returned for each event class.

• On the Events Selection tab, use the grid control to add or remove events and data columns from the trace file. The events checked by default depend on the trace template you select. To see a list of all events, check the Show all events field.

• To remove events from the trace, clear the check box in the Events column for each event class.

• To include events in a trace, select the box in the Events column for each event class, or check a data column that corresponds to an event.

The following are recommended columns to include in the trace: TextData, ApplicationName, Reads, Writes, CPU, DatabaseName, HostName, SPID, StartTime, EndTime and Duration. You can apply a filter to the Duration field, to only include events that take longer than 50 milliseconds.



4-41

NOTE: If the trace will be correlated with System Monitor or Performance Monitor data, both Start Time and End Time data columns must be included in the trace.

Filter Events in a Trace

Filters limit the events collected in a trace. If a filter is not set, all events of the selected event classes are returned in the trace output. It is not mandatory to set a filter for a trace. However, a filter minimizes the overhead that is incurred during tracing. For example, you can filter the DatabaseName column to include data from a specific database only, or you can filter the Duration column to include only statements with a minimum duration.

You add filters to trace definitions by using the Events Selection tab of the Trace Properties or Trace Template Properties dialog box.

1. In the Trace Properties or Trace Template Properties dialog box, click the Events Selection tab. The Events Selection tab contains a grid control. The grid control is a table that contains each of the traceable event classes. The table contains one row for each event class. The event classes may differ slightly, depending on the type and version of server to which you are connected. The event classes are identified in the Events column of the grid and are grouped by event category. The remaining columns list the data columns that can be returned for each event class.

2. Click Column Filters. The Edit Filter dialog box appears. The Edit Filter dialog box contains a list of comparison operators you can use to filter events in a trace.

3. To apply a filter, click the comparison operator, and type a value to use for the filter.

4. Click OK.

Considerations

If you set filter conditions on the StartTime and EndTime data columns of the Events Selection tab, then be sure to do the following:

• The date you enter matches this format: YYYY/MM/DD HH:mm:sec. -OR-

• Use regional settings to display date and time values is checked in the General Options dialog box. To view the General Options dialog box, on the SQL Server Profiler Tools menu, click Option. -AND-

• The date you enter is between January 1, 1753 and December 31, 9999.



4-42

When filtering the Duration field, check whether the duration is mentioned in milliseconds or in microseconds in the General Options dialog box. To view the General Options dialog box, on the SQL Server Profiler Tools menu, click Options.

Demonstration: Create a SQL Server Profiler Trace

Tim has noticed peaks in the % Processor Time counter. To identify the cause, he will create a new trace in SQL Server Profiler to monitor the queries.

1. Open SQL Server Management Studio. 2. On the Tools menu, click SQL Server Profiler. 3. Connect to the SQL Server that you want to run the trace on. SQL

Server Profiler will open. By default, the Trace Properties window displays. If it does not open, you can start a new trace by selecting New trace in the File menu.

FIGURE 4.7 THE TRACE PROPERTIES WINDOW

4. In the Trace Properties window, in the Trace Name field, enter a name for your trace. You can specify any name you want. We recommend that you use a meaningful name, such as the name of the server to trace, the starting date of the trace, or a combination of both.

5. In the Use the template field, you can choose to start from a blank trace, or you can select a template to base the trace on. In this case, Tim starts from a blank trace.



4-43

6. Click the Save to File option to save the trace information to a file. The Save As dialog box appears.

7. In the Save As dialog box, browse to the folder where you want to store the trace information and specify the name for the trace file. In this case, Tim decides to store the trace file as C:\PerfLogs\NAV-SRV-01_PctProcTime.trc.

8. Click the Save as button to close the dialog box. 9. Select the Server processes trace data option to make sure that all

data is logged. If selected, no events are skipped even under stress conditions. If this check box is cleared, processing is performed by SQL Server Profiler, and there is a possibility that some events are not traced under stress conditions.

10. Click the Events Selection tab. 11. In the Events column, select and expand the Stored Procedures

category. 12. Select the SP:StmtCompleted event. 13. In the Events column, select and expand the TSQL category. 14. Select the SQL:BatchCompleted event.

You can use the Show all event and Show all columns to show more or less events and columns.

15. For each of the selected events, select the following columns: ApplicationName, CPU, DatabaseName, Duration, EndTime, HostName, Reads, SPID, StartTime, TextData and Writes.

FIGURE 4.8 EVENTS AND COLUMNS SELECTION

16. Click the Column Filters button. 17. In the Edit Filter window, select the DatabaseName column in the

left pane.



4-44

18. In the right pane, double-click the Like operator and enter Demo Database NAV (6-0).

FIGURE 4.9 DEFINE A TRACE FILTER

As a consequence, the trace will only gather event information for the selected database.

19. Click OK to close the Edit Filters window. 20. Click Run to start the trace.

Correlate Perfmon and SQL Server Profiler Data

Although SQL Server Profiler trace files give you an overview of what is occurring inside a SQL Server database, they give no details about hardware resource consumption. However, the perfmon tool contains details about hardware resource consumption, but does not show which queries effectively cause the resource consumption.

As of SQL Server 2005, it is possible to correlate trace information from SQL Server Profiler with trace data collected by the Perfmon tool. You cannot correlate a running trace that is still collecting data. You can only correlate saved trace files.

NOTE: To correlate the SQL Trace file and the PerfMon log file, SQL Server Profiler trace files must include Start Time and End Time information.

For a correct matching, both files must be time synchronized. If both trace files are captured on different computers, make sure to synchronize the system time on both computers.

1. In SQL Server Profiler, open a saved trace file or trace table. You cannot correlate a running trace that is still collecting event data. For accurate correlation with System Monitor data, the trace must contain both StartTime and EndTime data columns.



4-45

2. On the SQL Server Profiler File menu, click Import Performance Data.

3. In the Open dialog box, select a file that contains a performance log. The performance log data must have been captured during the same time period in which the trace data is captured.

4. In the Performance Counters Limit dialog box, select the check boxes that correspond to the System Monitor objects and counters that you want to display along with the trace.

5. Click OK. 6. Select an event in the trace events window, or move through several

adjacent rows in the trace events window by using the arrow keys. The vertical red bar in the System Monitor data window indicates the performance log data that is correlated with the selected trace event.

7. Click a point of interest in the System Monitor graph. The corresponding trace row that is nearest in time is selected. To zoom in on a time range, press and drag the mouse pointer in the System Monitor graph.

Database Engine Tuning Advisor The Database Engine Tuning Advisor enables you to tune databases for improved query processing. Database Engine Tuning Advisor examines how queries are processed in the databases you specify and then it recommends how you can improve query processing performance by modifying physical design structures such as indexes, indexed views, and partitioning.

Database Engine Tuning Advisor provides a graphical user interface (GUI) and the dta command prompt utility. The GUI makes it easy to quickly view the results of tuning sessions. The dta utility makes it easy to incorporate Database Engine Tuning Advisor functionality into scripts for automated tuning.

In this lesson, you will use the GUI interface.

Launch DTA

To begin, open the Database Engine Tuning Advisor graphical user interface (GUI). On first use, a member of the sysadmin fixed server role must launch Database Engine Tuning Advisor to initialize the application. After initialization, members of the db_owner fixed database role can use Database Engine Tuning Advisor to tune databases that they own.

Perform the following steps to launch the DTA:

1. On the Windows Start menu, point to All Programs, point to Microsoft SQL Server, point to Performance Tools, and then click Database Engine Tuning Advisor.

2. In the Connect to Server dialog box, verify the default settings, and then click Connect.



4-46

By default, Database Engine Tuning Advisor opens to the configuration in the following illustration:

FIGURE 4.10 THE DATABASE ENGINE TUNING ADVISOR WINDOW

Two main panes are displayed in the Database Engine Tuning Advisor GUI when it is first opened.

Database Engine Tuning Advisor Left pane

The left pane contains the Session Monitor. This lists all tuning sessions that have been performed on this Microsoft SQL Server instance. When you open Database Engine Tuning Advisor, it displays a new session at the top of the pane. You can name this session in the adjacent pane. Initially, only a default session is listed. This is the default session that Database Engine Tuning Advisor automatically creates for you.

After you have tuned databases, all tuning sessions for the SQL Server instance to which you are connected are listed below the new session. You can right-click a tuning session to rename it, close it, delete it, or clone it. If you right-click in the list, you can sort the sessions by name, status, or creation time, or create a new session. In the bottom section of this pane, details of the selected tuning session are displayed.

You can choose to display the details organized into categories with the Categorized button, or you can display them in an alphabetized list by using the Alphabetical button. You can also hide Session Monitor by dragging the right pane border to the left side of the window. To view it again, drag the pane border back to the right. Session Monitor enables you to view previous tuning sessions, or to use them to create new sessions with similar definitions.



4-47

You can also use Session Monitor to evaluate tuning recommendations. For more information, see Using Session Monitor to Evaluate Tuning Recommendations (http://msdn.microsoft.com/en-us/library/ms175080.aspx).

Database Engine Tuning Advisor Right pane

The right pane contains the General and the Tuning Options tabs. Here you define your Database Engine Tuning session.

In the General tab, you type the name for your tuning session, specify the workload file or table to use, and select the databases and tables you want to tune in this session. A workload is a set of Transact-SQL statements that execute against a database or databases that you want to tune. Database Engine Tuning Advisor uses trace files, trace tables, Transact-SQL scripts, or XML files as workload input when tuning databases.

On the Tuning Options tab, you select the physical database design structures (indexes or indexed views) and the partitioning strategy that you want Database Engine Tuning Advisor to consider during its analysis. On this tab, you can also specify the maximum time the Database Engine Tuning Advisor takes to tune a workload. By default, Database Engine Tuning Advisor will tune a workload for one hour.

Setup DTA

You can set options that configure what the Database Engine Tuning Advisor graphical user interface (GUI) displays on startup, the font it uses, and other tool functionality to best support how you use it.

Perform the following steps to start the Database Engine Tuning Advisor:

1. On the Windows Start menu, point to All Programs, point to Microsoft SQL Server, point to Performance Tools, and then click Database Engine Tuning Advisor.

2. On the Tools menu, click Options. 3. In the Options dialog box, view the following options:

o Expand the On startup list to view what Database Engine Tuning Advisor can display when it is started. By default, Show a new session is selected.

o Click Change Font to see what fonts you can choose for the lists of databases and tables on the General tab. The fonts you choose for this option are also used in Database Engine Tuning Advisor recommendation grids and reports after you have performed tuning. By default, Database Engine Tuning Advisor uses system fonts.

o The Number of items in most recently used lists can be set between 1 and 10. This sets the maximum number of items in the lists displayed by clicking Recent Sessions or Recent Files on the File menu. By default, this option is set to 4.



4-48

o When Remember my last tuning options is selected, by default Database Engine Tuning Advisor uses the tuning options you specified for your last tuning session for the next tuning session. Clear this check box to use Database Engine Tuning Advisor tuning option defaults. By default, this option is selected.

o By default, Ask before permanently deleting sessions is selected to avoid accidentally deleting tuning sessions.

o By default, Ask before stopping session analysis is selected to avoid accidentally stopping a tuning session before Database Engine Tuning Advisor has finished analyzing a workload.

Demonstration: Monitor a Query Using DTA

When analyzing the counter log data and the SQL Server Profiler data, Tim notices that processor time peaks when the following query is executed:

SELECT [Entry No_] FROM [Demo Database NAV (6-0)].dbo. [CRONUS International Ltd_$Ledger Entry Dimension] WHERE [Entry No_ 2] > 0

In the SQL Server Profiler trace, in the HostName field, he can see that the query is issued from Mort's computer. Tim quickly checks whether this query can be optimized by adding indexes. To do this, he creates an SQL script with the query, which he analyzes with the Database Engine Tuning Advisor.

1. Open SQL Server Management Studio. 2. In the database drop-down list, select Demo Database NAV (6-0). 3. Click the New Query button to open a new query window. 4. In the Query window, enter the query listed above. 5. Right-click the Query window and select Analyze Query in

Database Engine Tuning Advisor. The Database Engine Tuning Advisor application opens.

6. In the Session Name field, enter a meaningful name for the tuning session. For example, enter MortsQuery.

7. In the Select databases to tune list, in the Name column, select the Demo Database NAV (6-0) database. In the Selected tables column, you see the number of tables that have been selected for tuning. By default all tables are selected.

8. Click the drop-down button to open a list of all tables.



4-49

9. In the list of tables, select the CRONUS International Ltd_$Ledger Entry Dimension table. Select the check box in the upper-left corner to (de)select all tables. To close the list of tables and return to the session window, click the dropdown button again. The Selected Tables column will contain the text : XXX of YYY, where XXX represents the number of selected tables and YYY represents the total number of tables.

FIGURE 4.11 DATABASE ENGINE TUNING ADVISOR SESSION

10. Click the Tuning Options tab. Here you can specify some settings that will influence the recommendations made by the Database Engine Tuning Advisor, as described earlier in this lesson.

11. Click the Start Analysis button in the toolbar. The query will now be analyzed.



4-50

While the Database Engine Tuning Advisor analyzes the query, a Progress tab appears, showing the overall progress of the analysis. When the analysis is finished, the recommendations and the estimated improvement are displayed on the Recommendations tab.

FIGURE 4.12 DATABASE ENGINE TUNING ADVISOR RECOMMENDATIONS

The Recommendations tab contains all indexing and partitioning recommendations from the Database Engine Tuning Advisor, depending on the selected tuning options. The overview contains information such as Database Name, Object Name, Recommendation and Definition. In this example, DTA suggests that you create an additional index on the Entry No. 2 field. The index fields are listed in the Definition column.

To implement the suggestions, first select all of the recommendations you want to apply. Next, on the Tools menu, select Apply recommendations. However, we recommend applying the recommendations from within Microsoft Dynamics NAV.

Dynamic Management Views You can use dynamic management views and dynamic management functions to query dynamic metadata in SQL Server. They provide information about the current state of SQL Server (such as locks currently held within a database); some views can depend on how long the server is running.

Dynamic Management Views are listed in the System Views folder in SQL Server Management Studio. Dynamic Management Views return the current status of activity in SQL Server. Their names generally contain the dm prefix to distinguish them from other views.



4-51

The information contained in the DMVs can also be obtained by using other monitoring tools. However, DMVs allow you to instantly check specific values, such as checking for missing indexes. You can join different dynamic management views to easily obtain even more detailed performance counter information.

This lesson provides an overview of the most important dynamic management views and functions. For more detailed information about each of the views, see Dynamic Management Views and Functions (http://msdn.microsoft.com/en-us/library/ms188754.aspx).

sys.dm_db_file_space_usage

This view returns space usage information for each file in the database. In SQL Server 2005, this view is only applicable to the tempdb database.

SELECT * FROM sys.dm_db_file_space_usage

Running out of disk space in tempdb can cause significant disruptions in the SQL Server production environment and can prohibit applications that are running from completing operations.

For more information, see Troubleshooting Insufficient Disk Space in tempdb (http://msdn.microsoft.com/en-us/library/ms176029(SQL.90).aspx).

sys.dm_db_index_usage_stats

This view gives statistics on how an index has been used to resolve queries. The view shows the number of times a query was used to find a single row (user_seeks), a range of values, or to resolve a non-unique query (user_scans). It also shows how many times the index has been updated (user_updates). Notice that sys.dm_db_index_operational_stats will give the details of how it has been modified.

The view is very useful for performance tuning, as it tells you when indexes are NOT being used. Using this dynamic management view, you can see which indexes are used, which ones are not used, and which indexes are updated many times and never being used.

sys.dm_db_index_physical_stats

This view returns size and fragmentation information for the data and indexes of the specified table or view.



4-52

Fragmentation occurs through the process of data modifications (INSERT, UPDATE, and DELETE statements) that are made against the table and therefore, to the indexes defined on the table. Because these modifications are not ordinarily distributed equally among the rows of the table and indexes, the fullness of each page can vary over time. For queries that scan part or all of the indexes of a table, this kind of fragmentation can cause additional page reads. This hinders parallel scanning of data.

Before optimizing the fragmentation of an index, it is useful to analyze the usage of an index.

The following example returns detailed index statistics for the index with ID 1 in the Customer table:

SELECT * FROM sys.dm_db_index_physical_stats( DB_ID(N'Demo Database NAV (6-0)'), OBJECT_ID(N'[CRONUS International Ltd_$Customer]'), 1, NULL, 'DETAILED');

sys.dm_db_index_operational_stats

This view returns current low-level I/O, locking, latching, and access method activity for each partition of a table or index in the database.

The following query shows the operational statistics for all indexes in the Customer table:

SELECT * FROM sys.dm_db_index_operational_stats( DB_ID(N'Demo Database NAV (6-0)'), OBJECT_ID(N'[CRONUS International Ltd_$Customer]'), NULL, NULL)

The last two parameters can be replaced by the index id or partition id.

sys.dm_db_missing_index_details

This view returns detailed information about missing indexes (excluding spatial indexes).

SELECT * FROM sys.dm_db_missing_index_details

After querying the sys.dm_db_missing_index_details dynamic management view, you can create the missing index by using information that is returned in the equality_columns, included_columns, and statement columns.



4-53

sys.dm_io_pending_io_requests

This view returns one row for each pending I/O request. On very active SQL Server computers, the view can return large result sets. Execute this query periodically to check the health of I/O subsystems and to isolate physical disk(s) that are involved in the I/O bottlenecks.

SELECT * FROM sys.dm_io_pending_io_requests

sys.dm_io_virtual_file_stats

This view returns I/O statistics for data and log files. The view has two parameters: a database ID (or NULL) and a file ID (or NULL).

If you do not specify a database, information for all databases will be displayed. If you do not specify a database file, information for all database files will be displayed.

SELECT * FROM sys.dm_io_virtual_file_stats(DB_ID('Demo Database NAV (6-0)'), NULL)

Important information is in the io_stall column which indicates the total time, in milliseconds, that users waited for I/O to be completed on the file. The view can help you identify I/O bottlenecks.

sys.dm_exec_cached_plans

This view returns a row for each query plan that is cached by SQL Server for faster query execution. You can use this dynamic management view to find cached query plans, cached query text, the amount of memory taken by cached plans, and the reuse count of the cached plans.

sys.dm_exec_query_optimizer_info

This view returns detailed statistics about the operation of the SQL Server query optimizer. You can use this view when tuning a workload to identify query optimization problems or improvements.

SELECT * FROM sys.dm_exec_query_optimizer_info

For example, you can use the total number of optimizations, the elapsed time value, and the final cost value to compare the query optimizations of the current workload and any changes observed during the tuning process. Some counters provide data that is relevant only for SQL Server internal diagnostic use. These counters are marked as "Internal only."



4-54

sys.dm_exec_query_plan

Use this view to collect information about the query plans that are used to execute a particular Transact-SQL query.

Query plans for various types of Transact-SQL batches, such as ad hoc batches, stored procedures, and user-defined functions, are cached in an area of memory called the plan cache. Each cached query plan is identified by a unique identifier called a plan handle. If a Transact-SQL query or batch runs a long time on a particular connection to SQL Server, you can retrieve the execution plan for that query or batch to discover what is causing the delay.

The following example shows how to retrieve the execution plan for a query that is identified as 0x06000100A27E7C1FA821B10600:

SELECT * FROM sys.dm_exec_query_plan(0x06000100A27E7C1FA821B10600)

sys.dm_exec_requests

This view returns one row per request that is executed on SQL Server. The view includes database information (database name), system resource information such as wait time, elapsed time and CPU time, but also some general information about open transactions and blocked sessions.

SELECT * FROM sys.dm_exec_sessions

sys.dm_exec_sessions

This view returns one row per authenticated session on SQL Server. sys.dm_exec_sessions is a server-scope view that shows information about all active user connections and internal tasks. This information includes client version, client program name, client login time, login user, current session setting, and more. Use sys.dm_exec_sessions to first view the current system load and to identify a session of interest, and then learn more information about that session by using other dynamic management views or dynamic management functions.

SELECT * FROM sys.dm_exec_sessions

sys.dm_os_performance_counters

This view makes it possible to query a view directly to capture the SQL Server counters related to the instance.

SELECT * FROM sys.dm_os_performance_counters



4-55

Depending on the services and applications installed the number of counters can vary. These counters range from memory usage to SQL Server application specific counters to include the following:

• MSSQL:Access Methods • MSSQL:Broker Activation • MSSQL:Broker/DBM Transport • MSSQL:Broker Statistics • MSSQL:Buffer Manager • MSSQL:Buffer Node • MSSQL:Buffer Partition • MSSQL:Catalog Metadata • MSSQL:CLR • MSSQL:Cursor Manager by Type • MSSQL:Cursor Manager Total • MSSQL:Databases • MSSQL:Exec Statistics • MSSQL:General Statistics • MSSQL:Latches • MSSQL:Locks • MSSQL:Memory Manager • MSSQL:Plan Cache • MSSQL:SQL Errors • MSSQL:SQL Statistics • MSSQL:Transactions • MSSQL:User Settable • MSSQL:Wait Statistics

The view is limited to SQL Server performance counters. You cannot use this view to monitor physical disks, network I/O, and so on.

sys.dm_os_wait_stats

This view returns information about all the waits encountered by threads that executed. You can use this aggregated view to diagnose performance issues with SQL Server and also with specific queries and batches.

sys.dm_os_wait_stats shows the time for waits that have completed. This dynamic management view does not show current waits.



4-56

Specific types of wait times during query execution can indicate bottlenecks or stall points within the query. Similarly, high wait times, or wait counts server wide can indicate bottlenecks or hot spots in interaction query interactions within the server instance. For example, lock waits indicate data contention by queries, page IO latch waits indicate slow IO response times, and page latch update waits indicate incorrect file layout.

For more information, see sys.dm_os_wait_stats (http://msdn.microsoft.com/en-us/library/ms179984.aspx).

You can query dynamic management views using a standard SELECT statement. For example, the following code returns details about the current locking status in the system:

SELECT * FROM sys.dm_tran_locks

For example, the following code returns all sessions that lock the Customer table:

SELECT DISTINCT request_session_id FROM sys.dm_tran_locks WHERE resource_associated_entity_id = object_id('CRONUS International Ltd_$Customer')

Useful Scripts, Tools, and Reports In addition to the monitoring tools described in the previous lessons, there are several other tools (scripts and reports) that can be used to analyze or troubleshoot performance issues.

The sp_who stored procedure provides the following information about current users, sessions, and processes in an instance of the Microsoft SQL Server Database Engine:

• Process ID • Process Status • User Login Name • User Name • Blocking Process SPID (for blocked processes) • Database used by the process • Command being executed

The information can be filtered to return only those processes that are not idle, that belong to a specific user, or that belong to a specific session. You can use sp_who to analyze the server load, by analyzing the number of database connections.



4-57

The sp_who2 stored procedure retrieves the same information as sp_who, but adds the following important columns:

• Total CPU time per process • Total amount of disk reads per process • Last time a client called a procedure or executed a query • Connected application

To run the stored procedures, enter the following Transact-SQL query in a new query window in SQL Server Management Studio:

-- To execute sp_who, enter: EXEC sp_who -- To execute sp_who2, enter: EXEC sp_who2

The following query, which is based on Dynamic Management Views, has proven to be very useful in general performance troubleshooting of SQL installations. The query is read-only. It does not cause any locks or any noticeable overhead to SQL Server.

SELECT TOP 30 st.text, SUBSTRING(st.text, (qs.statement_start_offset/2) + 1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) as statement_text, execution_count, CASE WHEN execution_count = 0 THEN null ELSE total_logical_reads/execution_count END as avg_logical_reads, last_logical_reads, min_logical_reads, max_logical_reads, CASE WHEN execution_count = 0 THEN null ELSE total_logical_writes/execution_count END as avg_logical_writes, last_logical_writes, min_logical_writes, max_logical_writes, max_elapsed_time FROM sys.dm_exec_query_stats as qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as st ORDER BY max_logical_reads DESC -- change ORDER BY to sort by max_logical_writes



4-58

The query gives you an immediate view of the top 30 plans that are currently in cache, ordered by number of reads (or writes with a small change). It gives you a view of the queries most likely to cause the most performance problems. In this way, it does what you would have otherwise had to use SQL Profiler for, but without the overhead of SQL Profiler or the need to spend hours browsing through thousands of lines of details in SQL Server Profiler traces.

Every time a query is sent to SQL Server, SQL Server makes a query-plan for that query. Then it caches this plan to re-use it for identical queries. This plan-cache also collects statistics about how efficiently each query-plan was run. This query looks into the plan-cache and retrieves the plans, with the one causing the most reads at the top. It returns (among other things) the following information:

• Text and Statement_text - this shows the query that this plan is being used for. Remember, the same plan can be used again for identical queries.

• Execution_count - shows how many times the plan was used. If this shows 1, the plan may have been for a one-off query, and it may not be relevant to investigate it further. If it shows a high count, then the plan is for a common query, and you may want to investigate further where this query came from.

SQL Server's plan cache changes all the time, depending on what queries SQL Server runs, so you may get different results, depending on what time of the day you run the query. The plan cache is also reset when SQL Server restarts.

What to look for

Being sorted by "max_logical_reads", you have the "worst" query at the top. But also look at execution_count. If a query ran just once, it might have been a batch job, or something else that is not really causing any problems. Queries that have an execution_count in the hundreds or thousands may be more relevant to look at. Also see whether the queries (statement_text) look similar, or if many of them are in the same area (same tables).

The column diff_quota shows max_logical_reads divided with min_logical_reads. If this number is high, it means that the query plan is inconsistent. This can be either because of inconsistent use of Microsoft Dynamics NAV (for example users applying different filters on the same table). Or, it may be because a query plan is good for some queries but bad for others. In this case, you can affect the way that SQL Server creates query plans, by adding RECOMPILE hints, plan guides, or index hints. Or by upgrading to a newer version of Microsoft Dynamics NAV client (for example see the post "SQL Pre-processing in Microsoft Dynamics NAV 5.0 SP1" for how NAV 5 SP1 will cause different query plans).



4-59

If diff_quota is low, it means that the query plan is just consistently bad, which means that it is more likely that the query itself is bad. You will then have to look for reasons why that query consistently causes the number of reads that it does. The "TOP 30"query cannot help determining why a query is causing many reads. But it can identify which queries to investigate first, which can otherwise be a very time-consuming task (collecting and analyzing profiler traces, and so on).

You can also look at max_elapsed_time, but be aware that when a query takes a long time to run because it is being blocked, then the real problem is elsewhere (in the blocking query). So, if a query has a high max_elapsed_time, then see whether the query contains a lock (WITH UPDLOCK). If it does, then you are most likely looking at a blocking problem which requires a wider look, and which frequently cannot be solved by the query you see.

Performance Data Collector

The data collector is a component of SQL Server 2008 that collects different sets of data. Data collection either runs constantly or on a user-defined schedule. The data collector stores the collected data in a relational database known as the management data warehouse.

The data collector is a core component of the data collection platform for SQL Server 2008 and the tools that are provided by SQL Server. The data collector provides one central point for data collection across your database servers and applications. This collection point can obtain data from a variety of sources and is not limited to performance data, unlike SQL Trace.

The data collector enables you to adjust the scope of data collection to suit your test and production environments. The data collector also uses a data warehouse, a relational database that enables you to manage the data that you collect by setting different retention periods for your data.

The Data Collector can be started and managed from SQL Server Management Studio > Management > Data Collection. To set up and configure storage for collected data, you can use the Configure Management Data Warehouse wizard. The wizard provides an easy way to do the following:

• Create the management data warehouse. You can install the management data warehouse on the same instance of SQL Server that runs the data collector. However, if server resources or performance are an issue on the server that is being monitored, you can install the management data warehouse on a different computer.

• Install the predefined System Data collection sets. • Map logins to management data warehouse roles. • Enable data collection. • Start the System Data collection sets.



4-60

When data collection is enabled, you can run reports on the management data warehouse database. To run the reports, right-click the database in SQL Server Management Studio, and select Reports and then Management Data Warehouse.

For more information, see Data Collection (http://msdn.microsoft.com/en-us/library/bb677179.aspx) and Data Collector Architecture and Processing (http://msdn.microsoft.com/en-us/library/bb677355.aspx).

Summary This chapter explains how to create a test environment that can be used to troubleshoot performance issues. It also explains different tools that can be used to monitor system performance and code execution.



4-61

Test Your Knowledge Test your knowledge with the following questions.

1. Performance troubleshooting involves several steps. Order the following steps correctly?

Step:

_____: Check database structure and indexes

_____: Check hardware performance

_____: Check hardware configuration

2. Which monitoring tools are part of the perfmon tool? (Select all that apply)

( ) System Information ( ) System Monitor ( ) Performance Logs and Alerts ( ) Task Manager

3. Information collected by the Client Monitor tool can be linked to information from another tool. Which tool can Client Monitor be linked to?

( ) Session Monitor ( ) SQL Server Profiler ( ) Code Coverage ( ) System Monitor

4. Which of the following statements about SQL Server Profiler are false? (Select all that apply)

( ) You can use customizable templates to trace performance. ( ) SQL Server Profiler can be scheduled to run automatically during a

specific period of time. ( ) You can save trace information to a file and a database ( ) You can use SQL Server Profiler to analyze current system

performance with current database activity.



4-62

5. Database Engine Tuning Advisor provides information about the performance of which of the following: (Select all that apply)

( ) memory ( ) CPU ( ) indexes ( ) partition structures

6. The sys.dm_os_performance_counters dynamic management views captures information related to __________.

7. The sys.dm_db_file_space_usage DMV returns information related to ______ database.



4-63

Lab 4.1 - Setup and Schedule System Monitor In this lab you set up several monitoring tools to monitor specific system resources.

Scenario

Recently users have reported that systems are occasionally performing poorly. Tim decides to start monitoring the hardware of the SQL Server to identify the cause of the problem. He starts monitoring CPU, disk activity, network activity and memory, with immediate effect and for the next 72 hours.

Challenge Yourself!

Use Perfmon to monitor the following system resources for 72 hours:

• % processor time (total) • % processor time (used by SQL Server) • % Disk Time, Disk Reads/sec, Disk Writes/sec, Average Disk Queue

Length, Current Disk Queue Length per drive • SQL Server Buffer cache hit ratio • Network packages sent and received per second • Available memory (in MB) • Page Faults / sec

Need a Little Help?

Perform the following steps to complete this lab:

1. Start Perfmon. 2. Create a New Counter Log. 3. Enter Log Settings. 4. Add Disk Activity Counters to the Counter Log. 5. Add Network Interface Counters to the Counter Log. 6. Add Processor Counters to the Counter Log. 7. Add Memory Counters to the Counter Log. 8. Add SQL Server Memory Counters to the Counter Log. 9. Schedule the Counter Log. 10. Activate the Counter Log.



4-64

Step by Step

Start Perfmon

1. In the Windows Taskbar, click Start. 2. On the Start menu, select Run. 3. In the Open field, enter perfmon. 4. Click OK to execute the command.

Create a New Counter Log

1. Click to expand Performance Logs and Alerts. 2. Right-click Counter Logs, then select New Log Settings. 3. In the New Log Settings dialog box, enter Lab 4-1. 4. Click OK to continue.

Enter Log Settings

In the Current Log file Name field, enter the path and location for the log files.

Add Disk Activity Counters to the Counter Log

1. Click the Add Counters button. 2. In the Add Counters window, select the Select counters from

Computer option. 3. In the computer name drop-down list, select NAV-SRV-01. 4. In the Performance object field, select PhysicalDisk. 5. Choose the Select counters from List option. 6. In the left list box, select % Disk Time. 7. Choose the Select Instances from List option. 8. In the right list box, select the C drive. 9. Keep the Ctrl key pressed. 10. In the left list box, click Avg. Disk Queue Length, Current Disk

Queue Length, Disk Reads/sec, and Disk Writes/sec. 11. Click the Add button.

Add Network Interface Counters to the Counter Log

1. In the Performance object field, select Network Interface. 2. Choose the Select counters from List option. 3. In the left list box, select Packets Received/sec. 4. Choose the Select Instances from List option. 5. In the right list box, select a network card.



4-65

6. Keep the Ctrl key pressed. 7. In the left list box, click Packets Sent/sec. 8. Click the Add button.

Add Processor Counters to the Counter Log

1. In the Performance object field, select Processor. 2. Choose the Select counters from List option. 3. In the left list box, select % Processor Time. 4. Choose the Select Instances from List option. 5. In the right list box, select Total. 6. Click the Add button. 7. In the Performance object field, select Process. 8. In the left list box, select % Processor Time. 9. Choose the Select Instances from List option. 10. In the right list box, select sqlservr. 11. Click the Add button.

Add Memory Counters to the Counter Log

1. In the Performance object field, select Memory. 2. Choose the Select counters from List option. 3. In the left list box, select Available MBytes. 4. Keep the Ctrl key pressed. 5. In the left list box, select Page Faults/sec. 6. Click the Add button.

Add SQL Server Memory Counters to the Counter Log

1. In the Performance object field, select SQLServer:Buffer Manager.

2. Choose the Select counters from List option. 3. In the left list box, select Buffer Cache Hit Ratio. 4. Keep the Ctrl key pressed. 5. In the left list box, click Pages reads/sec and Page writes/sec. 6. Click the Add button. 7. Click OK to close the Add Counters window. 8. Click the Apply button.



4-66

Schedule the Counter Log

1. On the Schedule tab, in the Start Log field, choose the first option. 2. In the Stop log field, select the second option (After ... units). 3. In the After field, enter 72. 4. In the Units field, select hours. 5. Click the OK button.

Activate the Counter Log

1. In the Microsoft Management Console, the new Lab 4.1 counter log appears.

2. Right-click the counter log. 3. Select Start.



4-67

Lab 4.2 - Create a SQL Server Profiler Trace In this lab you set up an SQL Server Profiler trace to identify database activity.

Scenario

To find the cause of the performance problems as soon as possible, Tim also starts monitoring the database activity using SQL Server Profiler. In case performance problems arise, he can see the database activity running on the server at the same time.

While Tim is monitoring, Susan runs the badly performing codeunit written by Mort (see the Client Monitor lesson in this chapter).

Challenge Yourself!

Trace the database activity for the Demo Database NAV (6-0) database for a period of 72 hours. Use the Tuning template, and make sure the trace data can be correlated to the counter log setup in Lab 4.1.

Need a Little Help?

Perform the following steps to complete the lab:

1. Open SQL Server Profiler. 2. Define the Trace. 3. Filter the Trace. 4. Run Codeunit in Microsoft Dynamics NAV. 5. Check the Trace.

Step by Step

Open SQL Server Profiler

1. Open SQL Server Management Studio. 2. In the Tools menu, select SQL Server Profiler. 3. Connect to the NAV-SRV-01 Database Engine.

Define the Trace

1. In the Trace Properties window, in the trace name, enter Lab 4.2. 2. In the Use the template list, select the Tuning template. 3. Check the Save to File option. 4. In the Save As dialog box, enter the path and file name for the SQL

Server Profiler trace. In this example, enter C:\PerfLogs\Lab 4.2.trc. 5. Clear the Enable file rollover option. 6. Select the Server processes trace data option.



4-68

7. Select the Enable trace stop time. 8. Set the date and time to current system time + 72 hours. 9. On the Events Selection tab, right-click the header for the

DatabaseID column and choose Deselect column. 10. Repeat step 7 for the ObjectType column. 11. Click the Show all columns option. 12. Right-click the header for the ApplicationName column and choose

Select column. 13. Repeat step 10 for the following columns: CPU, EndTime,

HostName, Reads, StartTime, and Writes.

Filter the Trace

1. On the Events Selection tab, click the Column Filters button. 2. In the Edit Filter window, in the left pane, select DatabaseName. 3. In the right pane, double-click the Like operator. 4. In the text box, enter Demo Database NAV (6-0). 5. Click OK to close the Edit Filter window. 6. Click Run to start the SQL Server Profiler trace.

Run Codeunit 123456710 in Microsoft Dynamics NAV

1. In the Windows Taskbar, go to Start > All Programs. 2. Right-click Microsoft Dynamics NAV 2009 Classic with

Microsoft SQL Server and select Run as. 3. In the Run as window, select The following user. 4. In the User name field, enter CONTOSO\Susan. 5. In the Password field, enter pass@word1. 6. Click OK to run the Microsoft Dynamics NAV 2009 Classic client. 7. On the Tools menu, select Object Designer. 8. Click Codeunit. 9. Select codeunit 123456710. 10. Click Run.



4-69

Check the Trace

Switch to the SQL Server Profiler window. While the codeunit is running, events are added to the SQL Server Profiler trace. The LoginName column shows that the database activity is caused by CONTOSO\SUSAN.

Stop the Trace

When defining the trace, you have entered a trace stop time. Under usual circumstances, the trace will continue to run until the stop time is reached. For this lab, you can stop the trace here. In the SQL Server Profiler, right-click the trace window and select Stop Trace.



4-70

Lab 4.3 - Correlate System Monitor and SQL Server Profiler Data

In this lab you use SQL Server Profiler to analyze the events in the trace file and to link this database activity information to the data in the performance counter logs.

Scenario

Counter Logs and SQL Server Profiler have been running for 72 hours. Both the log and the trace file now contain a lot of information about system resources performance and database activity.

Tim is curious to see the results of the monitoring processes.

Challenge Yourself!

In this lab you analyze the monitoring information from the counter log (Lab 4.1) and the trace file (Lab 4.2) in SQL Server Profiler.

Need a Little Help?


1. Stop the Counter Log. 2. Start SQL Server Profiler. 3. Open SQL Server Profiler Trace. 4. Import Performance Data. 5. Analyze Performance Events.

Step by Step

Stop the Counter Log

1. In the Windows Taskbar, Click Start > Run. 2. In the Run window, enter perfmon. 3. Click OK to start System Monitor. 4. Under Performance Logs and Alerts, select Counter Logs. 5. In the right pane, right-click the Lab 4.1 counter log and select Stop.



4-71

Start SQL Server Profiler

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 Database Engine. 3. In the Tools menu, select SQL Server Profiler. If the Trace

Properties window appears, click the Close button to close the window.

Open SQL Server Profiler Trace

1. In the File menu, select Open > Trace File. 2. In the Open File dialog box, browse to the SQL Server Profiler

Trace file that you created in Lab 4.2: C:\PerfLogs\Lab 4.2.trc 3. Click Open to load the trace file.

Import Performance Data

1. In the File menu, select Import Performance Data. 2. Browse to the Counter Log log file created in Lab 4.1:

C:\PerfLogs\Lab 4.1_000001.blg. 3. Click Open. 4. In the Performance Counters Limit Dialog window, select the

Processor and Process categories. 5. Click OK to import the performance data. The monitoring

information in both files is now correlated. The result should look as follows:

FIGURE 4.13 CORRELATING SYSTEM RESOURCE INFORMATION WITH DATABASE ACTIVITY



4-72

Analyze Performance Events

The SQL Server Profiler window is now divided into four panes:

• The top pane shows the database queries run on the database. • The second pane shows the system monitor graph. • The third pane shows the list of counters that are displayed in the

graph. • The bottom pane shows the SQL statement that is run.

To analyze the data, you can click any point in the graph or any event in the top pane. If you click an event in the top pane, the red line in the graph object will move to the corresponding point in time. Alternatively, you can click any point in the graph, after which the corresponding statement is selected in the top pane. In the top pane, in the LoginName column, you can see the login that caused the database activity.

FIGURE 4.14 ANALYZING PERFORMANCE IN THE SQL SERVER PROFILER WINDOW

1. In the graph object, click a point at the left side. 2. Verify the TextData, LoginName, Duration, CPU, Reads and Writes

columns in the events pane. 3. Use the right arrow key to move the red line farther to the right.

Watch the columns in the top pane. 4. Move the red line to the point where both graph lines show a sudden

increase. 5. Verify the Reads column in the top pane.



4-73

6. Click the ascending part of the graph lines. 7. Verify the Reads column in the top pane. 8. Repeat steps 6 and 7 several times. 9. Click the part of the graph where both lines reach the top limit. 10. Check the Reads column in the top pane. You notice that the number

of reads goes up.



4-74

Lab 4.4a - Analyze a SQL Server Profiler Trace using DTA In this lab, you analyze a SQL Server Profiler trace using Database Engine Tuning Advisor, in order to find missing indexes.

Scenario

When correlating system monitor and counter log information, Tim detects that performance degrades when Susan is executing her piece of code. He can see that many UPDATE and SELECT statements are run on the Ledger Entry Dimension table and that the number of reads is increasing toward the end of the batch. Tim checks the indexes of the table.

Challenge Yourself!

Analyze the SQL Server Profiler trace created in Lab 4.2 using Database Engine Tuning Advisor.

Need a Little Help?


1. Open Database Engine Tuning Advisor. 2. Configure Database Engine Tuning Advisor. 3. Start Database Engine Tuning Advisor.

Step by Step

Open Database Engine Tuning Advisor

1. Open SQL Server Management Studio. 2. On the Tools menu, select Database Engine Tuning Advisor. 3. Connect to the Demo Database NAV (6-0) Database Engine.

Configure Database Engine Tuning Advisor

1. In the Trace Properties window, in the Session Name field, enter a meaningful name for the tuning session. For example, enter Lab 4.4a.

2. In the Workload field, select the File option. 3. Click the Browse for a workload file button. 4. In the Open File dialog box, browse to the SQL Server Profiler trace

created in Lab 4.2: C:\PerfLogs\Lab 4.2.trc. 5. Click Open.



4-75

6. In the Select databases to tune list, in the Name column, select the Demo Database NAV (6-0) database. In the Selected tables column, you see the number of tables that have been selected for tuning. By default all tables are selected.

7. Click the drop-down button to open a list of all tables. 8. In the list of tables, click the check box in the upper-left corner to

deselect all tables. 9. In the list of tables, select the CRONUS International Ltd_$Ledger

Entry Dimension table. 10. Click the drop-down button again to close the list of tables and return

to the session window.

FIGURE 4.15 THE DATABASE ENGINE TUNING ADVISOR

11. On the Tuning Options tab, leave the default settings.

Start Database Engine Tuning Advisor

To start the Database Engine Tuning Advisor, click the Start Analysis button. Wait for the analysis to finish, and check the recommendations.



4-76

Lab 4.4b - Analyze an SQL query using DTA In this lab, you analyze an SQL query using Database Engine Tuning Advisor, in order to find missing indexes.

Scenario

When correlating system monitor and counter log information, Tim detects that performance is decreased when Susan is executing her piece of code. He can see that many UPDATE and SELECT statements are run on the Ledger Entry Dimension table and that the number of reads increases toward the end of the batch. Tim checks whether the necessary indexes exist for the SELECT query.

Challenge Yourself!

Analyze a query using Database Engine Tuning Advisor.

Need a Little Help?


1. Select the query to analyze. 2. Configure Database Engine Tuning Advisor. 3. Start Analysis.

Step by Step

Select the query to analyze

1. Open SQL Server Management Studio. 2. In the database drop-down list, select Demo Database NAV (6-0). 3. Click the New Query button to open a new query window. 4. In the Query window, enter the following query:

SELECT * FROM [Demo Database NAV (6-0)].dbo.[CRONUS International Ltd_$Ledger Entry Dimension]

Instead of entering the query manually, you can copy the query from SQL Server Profiler. Select the query you want to analyze, and select Edit > Copy cell. Paste the query in the new query window and remove all unknown variables and parameters. The resulting query should look like the query listed above.

5. Right-click the Query window and select Analyze Query in Database Engine Tuning Advisor.



4-77

Configure Database Engine Tuning Advisor

1. In the Session Name field, enter a meaningful name for the tuning session. For example, enter Lab 4.4b.

2. In the Select databases to tune list, in the Name column, select the Demo Database NAV (6-0) database. The Selected tables column shows the number of tables that have been selected for tuning. By default all tables are selected.

3. Click the drop-down button to open a list of all tables. 4. In the list of tables, select the check box in the upper-left corner to

deselect all tables. 5. In the list of tables, select the CRONUS International Ltd_$Ledger

Entry Dimension table. 6. Click the dropdown button again to close the list of tables and return

to the session window. 7. On the Tuning Options tab, leave the default settings.

Start Database Engine Tuning Advisor

To start the Database Engine Tuning Advisor, click the Start Analysis button. Wait for the analysis to finish, and check the recommendations.

FIGURE 4.16 DATABASE ENGINE TUNING ADVISOR RECOMMENDATIONS



4-78

Lab 4.4c - Find Missing Indexes using DMVs In this lab you find information about missing index information using dynamic management views.

Scenario

Tim checks for missing indexes using the dynamic management views.

Challenge Yourself!

Check for missing indexes using dynamic management views.

Need a Little Help?


1. Create a new query in SQL Server Management Studio. 2. Query Dynamic Management Views.

Step by Step

Create a new query in SQL Server Management Studio

1. Open SQL Server Management Studio. 2. Click the New Query button.

Query Dynamic Management Views

1. In the New Query window, enter the following statement:

SELECT * FROM sys.dm_db_missing_index_details

2. Click the Execute button.



4-79

Instead of waiting for the SQL Server Profiler or the Database Engine Tuning Advisor to process the load, Tim immediately sees the results of the query. The result should look as follows:

FIGURE 4.17 QUERYING THE SYS.DM_DB_MISSING_INDEX_DETAILS DMV



4-80

Quick Interaction: Lessons Learned Take a moment and write down three Key Points you have learned from this chapter

1.

2.

3.



4-81

Solutions Test Your Knowledge

1. Performance troubleshooting involves several steps. Order the following steps correctly?

Step:

3 : Check database structure and indexes

2 : Check hardware performance

1 : Check hardware configuration

2. Which monitoring tools are part of the perfmon tool? (Select all that apply)

( ) System Information (√) System Monitor (√) Performance Logs and Alerts ( ) Task Manager

3. Information collected by the Client Monitor tool can be linked to information from another tool. Which tool can Client Monitor be linked to?

( ) Session Monitor ( ) SQL Server Profiler (•) Code Coverage ( ) System Monitor

4. Which of the following statements about SQL Server Profiler are false? (Select all that apply)

( ) You can use customizable templates to trace performance. (√) SQL Server Profiler can be scheduled to run automatically during a

specific period of time. ( ) You can save trace information to a file and a database (√) You can use SQL Server Profiler to analyze current system

performance with current database activity.

5. Database Engine Tuning Advisor provides information about the performance of which of the following: (Select all that apply)

( ) memory ( ) CPU (√) indexes (√) partition structures



4-82

6. The sys.dm_os_performance_counters dynamic management views captures information related to SQL Server

7. The sys.dm_db_file_space_usage DMV returns information related to tempdb database.


na2009 enus sql_04

Technology

test server

thewindows server

awindows server

server calls

single server

server option

andmaintain sql server

monitor performance