Sql Server Performance Tuning
•Télécharger en tant que PPT, PDF•
11 j'aime•7,487 vues
The document discusses SQL Server performance monitoring and tuning. It recommends taking a holistic view of the entire system landscape, including hardware, software, systems and networking components. It outlines various tools for performance monitoring, and provides guidance on identifying and addressing common performance issues like high CPU utilization, disk I/O issues and poorly performing queries.
![SQL Server performance monitoring and tuning Bala Subra [email_address]](https://image.slidesharecdn.com/sqlserverperformancetuning-12654248526207-phpapp01/85/Sql-Server-Performance-Tuning-1-320.jpg)
![Make SQL Server faster ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Sql Server Performance Tuning
Similaire à Sql Server Performance Tuning (20)
Plus de Bala Subra
Plus de Bala Subra (20)
Sql Server Performance Tuning
- 1. SQL Server performance monitoring and tuning Bala Subra [email_address]
- 19. SQL Server Query Processing basics Data Cache Proc Cache MTL 256Mb Select * from authors where au_lname = ‘White’ au_id au_lname au_fname phone address city state 172-32-1176 White Johnson 408-496-7223 10932 Bigge Rd. Oakland CA Pages read from disk - slow Pages read from cache –fast! Lookup Pages In Data Cache Lookup Exec Plan in Proc Cache Execution Plan Found? Yes? Execute.. No? Compile & Execute.. SQL Server stores table rows & columns (Authors Table in pubs db has ~26rows and is approx 6kb total size) Table rows are stored on Disk in 8kb units, named “ pages”. When loaded into memory pages are referred to as “ buffers” Data volume (HDD) Physical Memory (RAM) Buffer Manager
- 44. Inside SQL Server Query Optimization
- 64. SQL Server Performance Tuning Process Automation SQL Server Performance Tuning Process Automation Educated Guess Manual Automated Hunt and Peck Tool Set Entire company Reactive approach No tools Entire company Reactive approach Disjointed tools Entire company Proactive approach Integrated tools People: Process: Technology:
- 65. Performance Tuning Redefined with SQL 2008
Notes de l'éditeur
- Designed for SMP Buffer cache avoid physical IO (tens of thousands of times faster) Disk Design for throughput and fault tolerance (reliability) Many small drives, not few big ones Raid 0 striping faster but not fault tolerant Raid 1 mirroring fault tolerant but not faster for writes (is for reads since can read from either) Multiple Raid 1 faster but if have a hot spot (all writes to one table) then all writes to one disk so no speed increase. (File groups help across a database and Yukon partitioning will address table hot spots) Raid 1 good for transaction logs since writes are sequential. Raid 5 = striping and parity (any one drive fails can get data from remaining 4) has a write performance penalty and a read enhancement Raid 10 = raid 1&0 (e.g configure stripes and then mirror using W2K) (Raid 01 configure mirrors and then stripe
- Performance Monitor Counters Memory Page Reads/sec Page Writes/sec Page Input/sec Page Output/sec Network Interface Bytes Received/sec Bytes Sent/sec Bytes Total/sec Current Bandwidth Output Queue Length Objects All Paging File All Physical Disk – set ‘disk perf – y’ in DOS and reboot % Disk Read Time % Disk Write Time % Idle Time Avg Disk Bytes/Read Avg Disk Bytes/Transfer Avg Disk Bytes/Write Avg Disk Queue Length Current Disk Queue Length Process % Privileged Time % Processor Time % User Time Processor % Privileged Time % Processor Time % User Time Server Work Queues Active Threads Available Threads Queue Length Total Bytes/sec Total Operations/sec SQLServer:Access Methods Full Scans Page Splits/sec Table Lock Escalations/sec SQLServer:Cache Manager Cache Hit Ratio - _Total Cache Pages - _Total SQLServer:Databases Transactions/sec SQLServer:General Statistics Logins/sec Logouts/sec User Connections SQLServer:Locks Number of Deadlocks/sec
- sys.sysprocesses (sysprocesses in SQL2K) provides up to the second data on CPU, IO PRIOR to query completion can be joined to DMVs via sql_handle to obtain executing query data SQL2k options DBCC INPUTBUFFER() fn_getsql() sys.dm_os_workers DMV provides further info from thread perspective
- You can deal with capacity issues by tuning query workload, or increasing hardware, but tuning workload is most effective & cheaper Memory is the most significant infrastructure component to size correctly Unless utilization genuinely increases significantly or memory is actually reduced, memory problems are typically consequences of other problems. If query workload efficiency has degraded (increased reads), usually better to tune queries (source of problem) than simply add more memory. Requires problem query identification (Profiler, Trace, DMVs) Might not be “tunable” (eg vendor applications)
- Decreases represent either: Inefficient query workload (new changes / optimization issues) Increased utilization
- all cases listed above occur on a per-session basis, so many users can be causing each of the disk IO workloads concurrently all cases listed above are highly disk WRITE oriented in nature temp table & cursor population, resultset sorting & versioning all WRITE to disk often causes significantly higher random, concurrent disk activity than user databases hard drive disk heads can only be physically in one place at any point in time tempdb‘s random, concurrent, highly write intensive disk activity can generate enormous queued disk workloads
- Testing / Live results Customer testing & live deployment of SDD on tempdb alone confirms significant improvement in system performance large-scale financial services online system 19,000% reduction in IO stalls in batch processing
- It’s doing “include” fields for us. How many know what that is? What does this NOT show? The impact of inserts/updates/deletes by adding these indexes. If we went and added all of these indexes right now, would that help? How can we tell? Are there existing indexes we could tweak instead? We could test it by capturing a load test with Profiler, then making our changes on a dev box, replaying those traces with/without our changes. But that’s getting into an ACTIVE method of tuning. More on that later.
- Putting the clustered index on the primary key of OLTP tables reduces pages splits. Don’t do this on earlier versions of SQL Server where row-level locking is unavailable or on SQL2K servers where row-level locking is disabled.
- Any time you rebuild the clustered index, you also automatically rebuild all non-clustered indexes on the table.
- Can set FILL FACTOR at a server level or specify with each clustered index. A good rule of thumb setting is 75-80% Should not set at the server level since some tables perform worse with fill factor of less than 100%. Naturally, this option strongly affects the amount of space that a table and its indexes will consume. However, disk is cheap!
- Avoiding wildcards in the SELECT list (as in, SELECT * FROM foo ) offers several advantages: reduces on network activity since unneed columns are not to the client improves self-documentation of the code, since unacquainted coders can more easily discern the important data in the query alleviates the need for SQL Server to rebuild the query plan on procedures, views, triggers, functions or even frequently run queries any time the underlying table structure is changed 4. narrows the the query engine to the most pertinent index choices
- Execution Plan Is Strategy determined by SQL Query Optimizer Can be influenced by developers Key Decisions are made: Which indexes to use? How to perform JOIN operations? How to order and group data? In what order tables should be processed? If cached data and previously compiled plans can be reused? High-percentage bookmark lookups are bad if your query is already running slow… Consider covering indices Thick lines coming into the operation and thin lines coming out – Bad and Ugly because it means that SQL Server is reading a lot of data initially (high disk I/O) but it’s throwing most of it away at the end because of the query clauses. Similar to reading 1GB file in memory and using only 100k of data. Database Developer’s role in Query Optimization Process Is: Apply iterative process of changing queries and database objects so that SQL Query Optimizer can make better decisions and do it faster Identify plan deficiencies and make changes to force SQL Server to correct them Correct one problem at a time Capture performance statistics “before” and “after” – use Database Load Testing tool To test our applications with production-like data load before rolling it out As amount of data increases, to proactively monitor application performance in order to catch problems early and correct them before customer sees them – work with DBA team SQL Server performs sort, intersect, union, and difference operations using in-memory sorting and hash join technology. Using this type of query plan, SQL Server supports vertical table partitioning, sometimes called columnar storage. SQL Server employs three types of join operations: Nested loops joins Merge joins Hash joins If one join input is quite small (such as fewer than 10 rows) and the other join input is fairly large and indexed on its join columns, index nested loops are the fastest join operation because they require the least I/O and the fewest comparisons. For more information about nested loops, see Understanding Nested Loops Joins. If the two join inputs are not small but are sorted on their join column (for example, if they were obtained by scanning sorted indexes), merge join is the fastest join operation. If both join inputs are large and the two inputs are of similar sizes, merge join with prior sorting and hash join offer similar performance. However, hash join operations are often much faster if the two input sizes differ significantly from each other. For more information, see Understanding Merge Joins. Hash joins can process large, unsorted, nonindexed inputs efficiently. They are useful for intermediate results in complex queries because: Intermediate results are not indexed (unless explicitly saved to disk and then indexed) and often are not produced suitably sorted for the next operation in the query plan. Query optimizers estimate only intermediate result sizes. Because estimates can be an order of magnitude wrong in complex queries, algorithms to process intermediate results not only must be efficient but also must degrade gracefully if an intermediate result turns out to be much larger than anticipated. The hash join allows reductions in the use of denormalization to occur. Denormalization is typically used to achieve better performance by reducing join operations, in spite of the dangers of redundancy, such as inconsistent updates. Hash joins reduce the need to denormalize. Hash joins allow vertical partitioning (representing groups of columns from a single table in separate files or indexes) to become a viable option for physical database design. For more information, see Understanding Hash Joins.
- Not optimally written queries and flawed database schema Missing indexes Unnecessary joins Too much data returned (SELECT *) Unnecessary ORDER BY clauses Inadequate disk performance Disk I/O can’t keep up with needs of relational engine Disk fragmentation of db files (sometimes called external fragmentation) Index and data pages fragmentation within db files (sometimes called internal fragmentation) Memory pressure and low page life expectancy Data pages frequently accessed can not fit in SQL Server memory which causes more disk I/O Low cache/hit ratio and page life expectancy Long running queries (blocking and locking) Reports or massive batch inserts or updates Long running transactions Parsing is a step during which syntax of the statement is validated and clauses are converted into internal compiler structures. Execution tree is produced. Execution tree is a structure that describes the logical steps needed to transform the source data into the format required by the result set. Normalization is a step during which objects are verified and bound to, views are replaced with their definitions and implicit type conversions are performed (when column/variable types allow implicit conversions). Optimization is a most important step, during which execution plan (optimized, final version of execution tree) is formed. Execution plan is a detailed strategy of query execution – see next slides for details. Execution plans are reused and cached in memory. If SQL query engine finds a suitable execution plan that is already cached, it will use it. By the same token, “aged” execution plans are ejected from cache. After that, execution plan is cached is a specially allocated buffer called procedure cache. Please notice that percentage of memory allocated for procedure cache fluctuates depending on number of plans that need to be kept in memory. Therefore, having too many execution plans (common scenario when raw SQL statements are used) may cause SQL server to start ejecting data and index pages from cache, which is not good. After that, the relational engine begins executing the execution plan. As steps that need data from the base tables are processed, the relational engine uses OLE DB to request that the storage engine pass up data from the rowsets requested from the relational engine
- Source: Inside SQL Server Book Phase 1: Trivial Plan Optimization. Cost-based optimization is expensive to do when there really is only one viable plan for the SQL statement. Example 1: a query that consists of an INSERT statement with a VALUES clause. There is only one possible plan. Example 2: SELECT statement where all the columns are in a unique covering index and there is no other index that has that set of columns in it. The trivial plan optimizer finds the really obvious plans, which are typically very inexpensive. As a result, optimizer doesn't spend a lot of time searching for a good plan. Phase 2: Syntactical Transformations Looking for commutative properties Looking for operations that can be rearranged Constant folding Other operations that don't require looking at the cost or analyzing indexes Phase 3: Full Optimization SQL Server then loads up the statistics information on indexes and columns, and enters the final major part of optimization, which is the cost based optimizer
- How many indexes are there already? How many rows are in the table? Is it write-intensive? Do we have fast enough storage for our writes? Query to Identifying Missing Indexes SELECT statement AS [database.scheme.table], column_id , column_name, column_usage, migs.user_seeks, migs.user_scans, migs.last_user_seek, migs.avg_total_user_cost, migs.avg_user_impact FROM sys.dm_db_missing_index_details AS mid CROSS APPLY sys.dm_db_missing_index_columns (mid.index_handle) INNER JOIN sys.dm_db_missing_index_groups AS mig ON mig.index_handle = mid.index_handle INNER JOIN sys.dm_db_missing_index_group_stats AS migs ON mig.index_group_handle=migs.group_handle ORDER BY mig.index_group_handle, mig.index_handle, column_id GO
- The Index Tuning Wizard is invoked in SQL Enterprise Manager on the Tools menu >> Wizards >> Management >> Index Tuning Wizard. We feed it a load – could be a single query, could be a trace file It actively runs these queries against our server, and it changes schema objects while it works to figure out what indexes and statistics will be the fastest. The Index Tuning Wizard can consume significant CPU resources on the server where it is run so you might want to: A) avoid running it on production servers, B) run it on a separate computer, C) run it on small subsets of the tables in the database, and/or D) disable the Perform thorough analysis option. Rename Each Index If we follow its recommendations and just hit apply, this is what we get – a bunch of new indexes we can’t identify. CREATE NONCLUSTERED INDEX [_dta_index_Activity_11_1977058079__K1_K4_K7_K5_K3] ON [dbo].[Activity] ( [ServerName] ASC, [ActivityTypeID] ASC, [StatusTypeID] ASC, [StartTime] ASC, [DatabaseID] ASC )
- DMF & DMV New with SQL Server 2005 Gathers information continuously Data does disappear with restarts You can walk in and start tuning immediately with little preparation Now, when we get a list of index recommendations from the wizard, we can compare it against our schema to see what we’ve got, and what we need to add. -- Possible bad Indexes (writes > reads) DECLARE @dbid int SELECT @dbid = db_id() SELECT 'Table Name' = object_name(s.object_id), 'Index Name' =i.name, i.index_id, 'Total Writes' = user_updates, 'Total Reads' = user_seeks + user_scans + user_lookups, 'Difference' = user_updates - (user_seeks + user_scans + user_lookups) FROM sys.dm_db_index_usage_stats AS s INNER JOIN sys.indexes AS i ON s.object_id = i.object_id AND i.index_id = s.index_id WHERE objectproperty(s.object_id,'IsUserTable') = 1 AND s.database_id = @dbid AND user_updates > (user_seeks + user_scans + user_lookups) ORDER BY 'Difference' DESC, 'Total Writes' DESC, 'Total Reads' ASC
- You can pick which individual indexes you want to compress. The smaller they are, the faster they’re read off disk. How much faster? Well, SQL gives us a tool to find that out.
- Table fragmentation is similar to hard disk fragmentation caused by frequent file creation, deletion and modification. Database tables and indexes need occasional defragmentation to stay efficient. The most efficient allocation for read-heavy tables is when all pages occupy a contiguous area in the database, but after weeks of use, a table may become scattered across the disk drive. The more pieces it is broken into – the less efficient the table becomes. T-SQL Code As Microsoft SQL Server 2000 maintains indexes to reflect updates to their underlying tables, these indexes can become fragmented. Depending on workload characteristics, this fragmentation can adversely affect workload performance. This white paper provides information to help you determine whether you should defragment table indexes to benefit workload performance. To defragment indexes, SQL Server 2000 provides several statements. This white paper compares two of those statements: DBCC DBREINDEX and DBCC INDEXDEFRAG. /* Determine which indexes to defrag using our user-defined parameters */ INSERT INTO #indexDefragList SELECT database_id AS databaseID , QUOTENAME(DB_NAME(database_id)) AS 'databaseName' , [OBJECT_ID] AS objectID , index_id AS indexID , partition_number AS partitionNumber , avg_fragmentation_in_percent AS fragmentation , page_count , 0 AS 'defragStatus' /* 0 = unprocessed, 1 = processed */ , Null AS 'schemaName' , Null AS 'objectName' , Null AS 'indexName' FROM sys.dm_db_index_physical_stats (@databaseID, OBJECT_ID(@tableName), Null , Null, @scanMode) WHERE avg_fragmentation_in_percent >= @minFragmentation And index_id > 0 -- ignore heaps And page_count > 8 -- ignore objects with less than 1 extent OPTION (MaxDop 1); /* Grab the most fragmented index first to defrag */ SELECT TOP 1 @objectID = objectID , @indexID = indexID , @databaseID = databaseID , @databaseName = databaseName , @fragmentation = fragmentation , @partitionNumber = partitionNumber , @pageCount = page_count FROM #indexDefragList WHERE defragStatus = 0 ORDER BY fragmentation DESC; /* If the index is heavily fragmented and doesn't contain any partitions or LOB's, rebuild it */ IF @fragmentation >= @rebuildThreshold And IsNull(@containsLOB, 0) != 1 And @partitionCount <= 1 BEGIN /* Set online rebuild options; requires Enterprise Edition */ IF @onlineRebuild = 1 And @editionCheck = 1 SET @rebuildCommand = N' Rebuild With (Online = On'; ELSE SET @rebuildCommand = N' Rebuild With (Online = Off'; /* Set processor restriction options; requires Enterprise Edition */ IF @maxDopRestriction IS Not Null And @editionCheck = 1 SET @rebuildCommand = @rebuildCommand + N', MaxDop = ' + CAST(@maxDopRestriction AS VARCHAR(2)) + N')'; ELSE SET @rebuildCommand = @rebuildCommand + N')'; SET @sqlCommand = N'Alter Index ' + @indexName + N' On ' + @databaseName + N'.' + @schemaName + N'.' + @objectName + @rebuildCommand; END; EXECUTE SP_EXECUTESQL @sqlCommand; http://technet.microsoft.com/en-us/library/cc966523.aspx http://sqlserverpedia.com/wiki/Index_Maintenance
- Object names can include table name, table id, view name or view id (where an index exists on the view), and/or an optional index name or index ID. The WITH option allows you to control how much data comes back. - FAST skips a leaf (data) level read and returns minimal information. These columns: Pages Scanned, Extent Switches, Scan Density [Best Count:Actual Count], Logical Scan Fragmentation. - TABLERESULTS returns the data in table format. You could then store it in a temp table if you wanted. It also returns a few additional columns: ExtentSwitches, AverageFreeBytes, AveragePageDensity, ScanDensity, BestCount, ActualCount, LogicalFragmentation, ExtentFragmentation. - ALL_INDEXES returns data for all indexes on a table, even when an individual index is identified - ALL_LEVELS only usable with TABLERESULTS (and not with FAST), produces results for each level of the index processed. Otherwise, only the index leaf level or table data level are processed. There are several especially important points to check here. Pages Scanned : Number of database pages used by the table (when you specify indid of 1 or 0) or a non-clustered index (when you specify indid > 1). Extent Switches : All pages of a table or an index are linked into a chain. Access to the table or index is more efficient when all pages of each extent are linked together into a segment of this chain. DBCC command scans the chain of pages and counts the number of times it has to switch between extents. If the number of extent switches exceeds the number of pages divided by 8, then there is a room for optimization. Extents switched compared to extents scanned gives us the scan density value. Avg. Pages per Extent : Space for each table is reserved in extents of 8 pages. Some pages are unused, because the table has never grown to use them or because rows have been deleted from a page. The closer this number is to 8 – the better. A lower number indicates that there is a lot of unused pages that decrease performance of table access. Scan Density [Best Count: Actual Count] : Scan Density shows how contiguous the table is. The closer the number is to 100% – the better. Anything less than 100% indicate fragmentation. Best Count shows the ideal number of extent switches that could be achieved on this table. Actual Count shows the actual number of extent switches. Logical Scan Fragmentation : The Percentage of out-of-order pages returned from scanning the leaf pages of an index. This reading is not relevant for heaps (tables without indexes of any kind) and text indexes. A page is considered out of order when the next page in the Index Allocation Map (IAM) is different than the page indicated by the next page pointer in the leaf page. Extent Scan Fragmentation : Percentage of out-of-order extents in scanning the leaf pages of an index, excluding heaps. An extent is considered out-of-order when the extent containing the current index page is not physically next after the extent holding the previous index page. Logical and Extent scan fragmentation should be as low as possible. Extent scan will usually be higher. Logical scan of 0% to 10% is usually acceptible. Avg. Bytes free per page : The average number of free bytes per page used by the table or index. The lower the number – the better. High numbers indicate inefficient space usage . The highest possible number of free space is 2014 (on SQL 7.0) – the size of a database page minus overhead. This or a close number will be displayed for empty tables. For tables with large rows this number may be relatively high even after optimization. For example, if row size is 1005 bytes, then only one row will fit per page. DBCC will report average free space also as 1005 bytes, but don’t expect another row to fit into the same page. In order to fit a row of 1005 bytes you’d also need additional room for row system overhead. Avg. Page density (full) : How full is an average page. Numbers close to 100% are better. This number is tied to the previous one and depends on the row size as well as on clustered index fillfactor. Transactions performed on table rows change this number because they delete, insert or move rows around by updating keys. SQL BOL has a good way to defragment all indexes in a database that is fragmented above a declared threshold under the topic DBCC SHOWCONTIG.
- When defining which database, table, view, or index you would like to defragment, you may use either the name of the object or its object ID. (When using a zero instead of the database name or database ID, the current database is assumed.) For example: DBCC INDEXDEFRAG (Pubs, Authors, Aunmind) GO Results: Pages Scanned Pages Moved Pages Removed ------------- ----------- ------------- 359 346 8
- If either index_name or fillfactor is specified, all preceding parameters must also be specified.
- Create another pagefile.sys files on every separate physical drives (Except drive contains the Windows NT system directory). Spreading paging files across multiple disk drives and controllers improves performance on most disk systems because multiple disks can process input/output requests concurrently. If you have a lot of RAM, you can configure your Windows NT server to never page out drivers and system code to the pagefile that are in the pageable memory area. Run regedit and choose: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management Set DisablePagingExecutive to 1 and reboot the server box. Set the &quot;Maximize Throughput for Network Applications&quot; option. This can increase SQL Server performance, because Windows NT will allocate more RAM to SQL Server than to its file cache. To set this option, you can do the following: 1. Double-click the Network icon in Control Panel. 2. Click the Services tab. 3. Click Server to select it, and then click the Properties button. 4. Click Maximize Throughput for Network Applications, and then click OK. 5. Restart the computer. Allow the tempdb database to automatically expand as needed. This ensures that queries that generate larger than expected intermediate result sets stored in the tempdb database are not terminated before execution is complete. Set the original size of the tempdb database files to a reasonable size to avoid the files from automatically expanding as more space is needed. If the tempdb database expands too frequently, performance can be affected. Set the file growth increment percentage to a reasonable size to avoid the tempdb database files from growing by too small a value. If the file growth is too small compared to the amount of data being written to the tempdb database, then tempdb may need to constantly expand, thereby affecting performance. Place the tempdb database on a fast I/O subsystem to ensure good performance. Stripe the tempdb database across multiple disks for better performance. Place the tempdb database on disks different from those used by user databases. To optimize system memory use for SQL Server, you should limit the amount of memory that is used by the system for file caching. To limit the file system cache, make sure that Maximize data throughput for file sharing is not selected. You can specify the smallest file system cache by selecting Minimize memory used or Balance . To change the server optimization settings in Windows Server 2003 In Control Panel , choose Network Connections , and then click Local Area Connection . On the General tab of the Local Area Connection Status dialog box, click Properties . On the General tab of the Local Area Connection Properties dialog box, select File and Printer Sharing for Microsoft Networks , and click Properties . In the File and Printer Sharing for Microsoft Networks dialog box, choose one of the following options: Maximize data throughput for file sharing Maximize data throughput for network applications (the option that SQL Server automatically sets) While the default setting of 1.5 x RAM is sufficient for pagefile size for some server roles, if your machine is running disk- and memory-intensive applications like Exchange or SQL Server then you may want to increase the initial pagefile size to 2 x RAM or even larger. Microsoft doesn't recommend increasing the pagefile to more than 3 x RAM, however, and the maximum allowed size for any one instance of pagefile.sys on a machine is limited to 4GB. So, if you have a powerful machine with 4GB of RAM then you have to split the pagefile to overcome this limit. This splitting can be done in two ways: create separate pagefiles on different volumes (done in the usual way) or create multiple pagefiles on a single volume. (See KB 237740 for how to do this.) On a more modest machine with 1GB of RAM though, you would probably be best served to set the initial pagefile size to 2GB (2 x RAM) and the maximum pagefile size to 3GB (3 x RAM).
- This tasks are superior to the Database Maintenance wizard. But, at least, do the DBMaint wizard if nothing else. http://www.devarticles.com/c/a/SQL-Server/How-to-Perform-a-SQL-Server-Performance-Audit/
- 1 0 Most Frequent Top-Level SQL Queries 1 0 Most Frequent Stored Procedures Average Execution Time by Stored Procedure Average Execution Time by SQL Query Long Running SQL Queries CPU Utilization by Application CPU Utilization by Login SQL Agent Jobs CPU Utilization CPU Utilization Bottlenecks and Timing CPU Utilization Trends Hourly Average CPU Utilization Daily Average CPU Utilization I/O Utilization by Application I/O Utilization by Login I/O Utilization Trends Deadlocks Lock Timeouts Active Sessions Trends Applications Running in SQL Server Cumulative SQL Server Load Tables Experiencing Full-Table Scans Backup Duration Trends Latest Backup Timing and Overlap Overlapping SQL Agent Jobs Database Errors and Exceptions
- SQL Queries Whose Execution Time Has Changed Over 1 0% Stored Procedures Whose Execution Time Has Changed Over 1 0% Stored Procedures Execution Time Trends Stored Procedures Cache Hits and Misses (Details) Stored Procedures Cache Hits and Misses (Summary) Data Output Trends Free/Used Data Space Usage Trends Free/Used Log Space Usage Trends Data Space Allocation Trends - Comparison by Database Log Space Allocation Trends - Comparison by Database Row Count Trends by Database Top 1 0 Fastest Growing Tables by Space Top 1 0 Fastest Growing Tables by Row Count
- Educated Guess Users notify Help Desk of system issues Help desk scrambles IT to find the problem IT frantically searches for the problem Network, Windows, SQL Server, front end application, logs, etc Unable to find issue report to Help Desk User escalation to management IT monitor for symptoms and make changes to benefit the users, but cannot validate Problem = Lack of information Hunt and Peck Approach Ask users where problems exist Monitor SQL Server to capture data Review data to determine issues Change SQL Server based on data Re-design, code changes, indexing, etc. Monitor to determine improvement Problem = Information Overload 24x7 Performance Monitoring Install, configure and baseline Review data from integrated tools Current and historical view of system Proactively and intuitively review Focus IT Team on objects requiring the most resources Correct and validate improvement
- Performance Studio concepts (data collection, management data warehouse) How to monitor/troubleshoot performance issues using Performance Studio New performance monitoring features in SQL Server® 2008 A framework that ties together collection, analysis, troubleshooting, and persistence of SQL Server diagnostics information. It consists of a suite of tools for: Low overhead data collection Performance monitoring, troubleshooting, tuning Persistence of diagnostics data Reporting Short term goals: Provide enhanced data collection and reports out of the box In many cases, when a problem occurs, you get a call later that same day or even the next day, saying, “There is a problem, we don’t know what’s happening, but could you please look into it?” To correctly fix the issue, you need the ability to centrally store performance data to go back in time to see exactly what happened during that period of time and, hopefully, you’ll be able to figure out what the problem was. With Performance Studio, you could use the performance data to analyze and write policies to prevent future issues to your system. For example, a policy if the CPU utilization goes over 85 percent for more than 15 minutes, then take this action or enable a specific type of data collection. But, you want to be able to apply more general policies to your system. Server Side: Data Collector Extensible data collection infrastructure Includes out of the box data collections required to identify and troubleshoot the most common problems for the relational engine Support for SQL Server relational engine only, but other SQL Server services can be added in the future Server Side: Management Data Warehouse Data repository for baseline and historical comparisons Aggregated reporting for multiple SQL Server instances Client Side: Data collection configuration UI Management data warehouse properties General data collection properties Collection set configuration SQL Server dashboard based on system collection sets reports Performance monitoring and troubleshooting Historical data analysis based on warehouse information Data Collector Concepts data collection should be always on and have low overhead. Overhead is a very tricky question because for some people, anything above zero is overhead. For some other people, 5 percent is OK. The overhead level is up to you. Out of the box, a lot of testing has been done—running against TPC-C and all sorts of other benchmarks—to ensure that the basic overhead on our system collection sets is always below 5 percent. But it’s really up to the user. It’s disabled by default, so you have to enable it and run the collection sets if you want data collection on. Data Provider Source of information (for example, SQL Trace, Perform counters, DMVs, T-SQL queries, logs)
- http://www.devarticles.com/c/a/SQL-Server/How-to-Perform-a-SQL-Server-Performance-Audit/