foreword
If default trace information is turned on, it will automatically record SQL Server startup information when SQL Server starts. This function is like the black box of an airplane, and it will record all changes to the configuration information of a SQL Server instance. Looking at this information, you can see what changes were made to the database at the time of the failure. The default trace information and ERRORLOG are stored in the same log folder with a name such as "log_xxx.trc", where xxx is a set of sequence numbers. You can use Profiler to open these files to view event records, or use the function "fn_trace_gettable" to process these files.
"Tracking" is also ubiquitous in our SQL Server database. If we make good use of tracking techniques, we can conduct directional analysis for certain specific scenarios and find sufficient evidence to solve the case.
Just a few application scenarios:
Why did the online production library suddenly go down?
Why are hundreds of data sheets missing?
Why are systems that have just been patched repeatedly hacked?
Why is the newly added information table lost frequently?
Who made the sudden change of a table field?
Is there a person or a ghost behind these anonymous visits?
Is the sudden increase in incremental data right or wrong?
What is hidden behind the explosive growth of hundreds of megabytes of logs?
Behind all this, is it a bug in the application or a lack of user quality?
I believe that anyone who has used the SQL Server database will have used the SQL Profiler tool more or less. This thing is a graphical operation tool formed by using SQL Trace.
Trace