As we go through each of the reports available in SQL Server Management Studio, I have an anecdote to share almost for most of them actually. I have used them extensively at different times and I am glad to share some of them via this blog series.
Once a friend of mine Joe pinged me over a chat. He was going to join a new organization and it was interesting to see the excitement and energy in his conversation. He was brimming with confidence about his new found job. After joining, he was back to ping me again. I was curious to know how his new job responsibilities were. After our initial greetings, Joe was quick to ask me a SQL Server related query.
Joe: Dave, in my new job we are supposed to have some standards to our servers.
Pinal: Ok, so what is the problem?
Joe: As I get access to some of the servers, I want to quickly know what changes were made to the server.
Pinal: Ok, so what is the problem? I still don’t get it.
Joe: Do you have any query that will give me this information?
Pinal: Now you are talking business.
Joe: I know you can help me, as you have done a number of times in the past.
Pinal: Thanks for your compliments, no need to search anywhere. It is already available with you.
Joe: You must be kidding me
Pinal: No Joe, Have you ever checked the Configuration Change history SQL Server Management Studio Report?
Joe: Ahhh … that was a good catch.
Pinal: See, it was all along with you. Just that I helped you find it existed. Now enjoy!!!
To find this SSMS report, it is second in the list from Server node -> Standard reports.
The purpose of this report is to show two key information:
- Changes made to Server Configuration using sp_configure
- Changes to trace flags (Enable or Disable) done via T-SQL.
The information from this report is fetched from “default trace” which runs by default in every SQL installation. If the default setting is disabled by administrator by any chance, then we will not get any reports. We will get the below message in report when the default trace is disabled.
“Currently, this table does not have any data to show, because default trace is not enabled.”
To enable the default trace, below command can be used
sp_configure 'default trace enabled', 1
RECONFIGURE WITH override
For most installations you don’t need to enable because it is running by default. Normally, a user is likely to see the below report with data like:
I am always intrigued when such reports every time. To look at the query fired for this report, we can fire up profiler to capture the same. Report uses fn_trace_gettable to read default trace and get event class 22 and 116.
WHERE trace_event_id IN (22, 116)
From the trace events, it means whenever a change is made using DBCC TraceStatus or sp_configure, they are recorded in default trace under “ErrorLog” and “Audit DBCC Event”. To display the SSMS reports additional filters have been applied to show only relevant information.
Do check these reports in your environment and let me know if you found any interesting information that you learnt today?
Reference: Pinal Dave (https://blog.sqlauthority.com)
Nice Example @Pinal…Keep posting
Nice Example …@Pinal Keep Posting
Little stuff but super important nonetheless. Thank you.
How much is the overhead for SQL server to have the default trace enabled and to manage the storage for the trace table to continually monitor for any configuration changes for each SQL server box?
How much overhead for SQL server to enable default trace on and to maintain the trace table to have this trace run continuously to capture any SQL server configuration changes? Trace in itself can have high overhead.