First off use PSSDiag / SQLDiag Manager as you would normally for SQL 2008 R2. Here's a high level of what I configure when I am only looking to collect a Profiler Trace and PerfMon which will typically satisfy the needs of most SQL Engineers unless you are troubleshooting a lower level performance issue.
- Select "SQL 2008" as the SQL Version
- Enter the machine name
- Enter the instance name (if required)
- Ensure that Windows Auth is selected
- Deselect Event Logs, Shutdown from Machine Wide Diagnostics
- Deselect SQLDIAG, and Shutdown from Instance-Specific Diagnostics
- Ensure that Trace is checked
- Select either the _GeneralPerformance10.xml or DetailedPerformance10.xml template depending on the level of Statement detail you wish to collect.
- Within the Custom Diagnostics section deselect the SQL Base, MSInfo, SQL Best Practises, SQL 2008 Perf Stats, SQL Dump
- Click the Save button
- Enter the path where you wish to save the .cab file.
- When prompted select SQL 2008 R2
Now is where you must modify the generated XML so it will work with SQL 2012. Here is what to do:
- Locate the cab file you generated and extract it
- With in the extracted files, locate the PSSDiag.xml and open it in Notepad (or your favourite XML editor)
- Locate the
node and change the value of ssver to 11.
The original xml will look like:
The modified xml should now be: - Save the XML and move it back into the .cab if required.
- Copy the files/cab to your server and run it as usual.
I will usually also modify the PSSDiag.cmd file to set an end time so that if I schedule the data collection it will stop without user interaction. Also this helps in case some operational issues arise and distract enough to forgot to stop the collection.
To do this add the /E parameter to the end of the call to SQLDiag and supply the duration in the format of +HH:MM. So if I was to set SQLDiag to stop after 2 hours the line would look like:
%diagEXE% /O output /I pssdiag.xml /P %1 %2 %3 %4 %5 %6 %7 %8 %9 /E +02:00
NOTE: I haven't actually gone through and validated if there are any different events we need to start capturing for SQL 2012, but should I find any I will update this post. Also I should point out that SQL Profiler has been marked as a depreciated feature and may be removed from future releases, which makes Extended Events the recommended method of capturing/monitoring SQL activity moving forward.
Legal Stuff: The contents of this blog is provided “as-is”. The information, opinions and views expressed are those of the author and do not necessarily state or reflect those of any other company with affiliation to the products discussed. This includes any URLs or Tools. The author does not accept any responsibility from the use of the information or tools mentioned within this blog, and recommends adequate evaluation against your own requirements to measure suitability.
No comments:
Post a Comment