SQL event probe, have you used it?

Because the development project is based on the project developed by a third-party company, the database is directly dependent, and the relationship between the project source code developed by the company and the database table is unknown, the installation process is also a "rogue" that I have never seen before (For details, refer to the software that you have seen monopoly? ). Therefore, the first problem we encounter is to analyze the database structure and what operations does the software perform on the database? According to a friend's introduction, I found that the SQL event probe is indeed a good tool for tracking SQL statement execution. Here I will share with you:

The SQL event probe is a graphical tool provided by SQL Server. It can be used to implement the following functions: (excerpt below)

1. monitor the performance of the SQL server instance.

2. debug Transact-SQL statements and stored procedures.

3. Identify slow queries.

4. In the project development stage, test the SQL statement and stored procedure by executing the statement in one step to confirmCodeRun as expected.

5. Solve SQL server problems by capturing events in the production system and replaying them in the test system. This is useful for testing and debugging, and allows users to continue using the production system without interference.

6. Review and review activities in the SQL server instance. This allows the security administrator to review any audit events, including logon attempts and failures, as well as access statements and object permissions.

Note that the system must have at least 10 MB of available space when running the SQL event probe. Otherwise, all functions of the SQL event probe will be stopped.

We can see that this SQL event probe is indeed very powerful, and every action executed in SQL Server can be clearly seen in the SQL event probe, which for performance tuning, later maintenance and so on are very helpful. However, the problem arises. After your software development is complete, as a software developer, you do not want to use the software user to track SQL statements through the SQL event probe. So what should we do in this situation? Is there any way to make the SQL event probe unable to track it?

Next we will explore this issue:

Assume that your database has a table "Organization" with a field "password". When you execute the following SQL statement:

Select   [ Password ]   From   [ Organization ] .

 

You will be surprised to find that the SQL event probe contains the following content:

-Find "password" in the event text ".

-For security reasons, replace the text with this annotation.

In this way, the content of the SQL statement you executed is invisible.

However, you can say that it is not displayed if there is no password field in my organization? Confirm this, but the official introduction said: as long as one of the keywords: Password, encryption, sp_setapprole appears in any part of the query process, the entire Query Process will be hidden, anywhere, of course, it also includes annotations. For example, execute the following statement:

-- Password
/* Protect SQL statements */
Select   1   From   [ Organization1 ]

 

Similarly, what we see in the SQL event probe is:

 

 

Summary:

This makes it clear that to avoid SQL statements being tracked in the SQL event probe, you only need to add a keyword comment to protect the SQL statement.

Fortunately, the third-party system software on which the system I developed is not protected against this SQL statement, so I can perform those operations on the database through the SQL event probe analysis software, further analyze the structure of the database table.

I can imagine how difficult it is to analyze the structure of database tables if all SQL statements in the software are protected?

Thank you for your advice!

 

Copyright description

This document is a learning note. You are welcome to repost it and note itArticleSource. Its copyright belongs to the author and the blog Park.

Author: Charles Chen

Article Source: http://charles2008.cnblogs.com/or http://www.cnblogs.com/