To get the name of the table then we must use a combination of system metadata and the DBCC PAGE command:ĭBCC Page takes a database id, file id, page number and format type. If you just want to be able to see the type and size of I/O requests the you can import the data onto any instance (or even some other tool like excel). To display the name of the table, we need to import the data onto the same instance that had the data captured. This is fairly straightforward and involves taking the Operation, FileName, Offset and Length from the data we have already captured. Once you have the actual data you then need to analyse it. running a defrag or backup on the database) as this would skew the results unfairly. If this is a test system then you will need to carry out the same actions as your users would and try to avoid anything that is out of the ordinary (i.e. Ideally you should capture enough data to show a representation of the operations that normally occur on the system. If you save it as a csv file we can then import this into SQL. When you have captured enough data you can stop the trace. It should look something like this image, I have highlighted the areas we are particularly interested in: If the file is being used then you will already start to see entries. If you then apply the filter and press OK the application will start gathering data and when any file access occurs, you will see the operation displayed on the screen. If you wanted to, you could restrict procmon to work with a specific database or set of databases using a more selective filter. If you choose "Path" then "Ends With" and enter ".mdf" you can filter on all mdf data files. When you run procmon the first thing you are asked to do is to set up a filter (aside from the one time EULA!). What we will do is start procmon and create a filter for just the SQL Data files, because there are processes which constantly read and write to files we want to ignore the general "chatter". First you will need a copy of procmon (Process Monitor), which you can download from. CapturingĬapturing the data is very straight forward. To do this we can use the free "Process Monitor" tool and then load the output into SQL Server. In this article I will be show how to measure the quantity and size of I/O requests in each database as well as being able to work out where your I/O's are hitting and then matching those up with physical tables. Understanding SQL's I/O patterns can help you design your disk infrastructure and knowing your application's patterns can help you get the most out of your disks. While SSD drives have been hailed as the future and fault tolerant ram drives are prohibitively expensive, most of us still use the humble mechanical disk drive to store and retrieve data.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |