Recently,I have tried my best to find out a way to hide name of databases from Sql Server Management Studio, which I don’t want to show to a specific user. But unfortunately I can’t find any proper way to achieve my goal.
You can hide all databases from a specific user by using following statement
DENY VIEW ANY DATABASE TO [TargetUserNameHere];
And same way by using GRANT, you can allow your user to view ALL databases. Optimum solution I have found is to hide database objects (even name of TABLES, VIEW, SPs & FUNCTIONS) ONLY, by using following statement
In last post “Performance Counter to Count Stored Procedure Re-compilations” we have discussed about a useful counter of system performance counters i.e. SQL Re-Compilations/sec. In this post, we have discussed that if nonzero values are consistently occurring for this counter, we should seriously search for the culprit stored procedures and then statement with in that stored procedure.
Let me explain, how Sql Profiler can help us to find statement in a stored procedure which actually triggered the recompile event.
Open Sql Server Profiler and start a new trace but with following events
You can select these events by selecting check box “Show all events” (as mentioned in screen shot. Click “Run” button to start trace.
Meanwhile execute following query as an example
CREATETABLE #t( a INT)
Now shift your focus to Sql Profiler to examine trace, which must resembling following screen shot.
Watch closely the statement which appeared before and after the SP:Recompile. This is the statement in stored procedure which actually triggered recompilation. Once we have detected the culprit statement, we must find out the reason behind this happening. In our example statement triggered recompilation because of "Recompilations Due to Interleaving Data Definition Language (DDL) and Data Manipulation Language (DML) Operations". What are other reasons behind recompilation occurring read previous post.
Note: In our example you will only see the recompile event on the first execution of the procedure, or if you drop and re-create the procedure each time you execute the script.
In an ideal situation a stored procedure is compiled once and forth coming queries related to this stored procedure are satisfied with already created query plan. The following actions may cause recompilations of a stored procedure plan:
Use of a WITH RECOMPILE clause in the CREATE PROCEDURE or EXECUTE statement.
Schema changes to any of the referenced objects, including adding or dropping constraints, defaults, or rules.
Running sp_recompile for a table referenced by the procedure.
Restoring the database containing the procedure or any of the objects the procedure references (if you are performing cross-database operations).
Sufficient server activity causing the plan to be aged out of cache
A sufficient percentage of data changes in a table that is referenced by the stored procedure.
The procedure interleaves Data Definition Language (DDL) and Data Manipulation Language (DML) operations.
These recompilations of stored procedure add overhead on the processor. We should closely monitor the occurrence of recompilation of these stored procedures.Performance monitor counter Sql Re-Compilations/sec is very helpful counter for this recompilation monitoring task.
Recommended value for SQL Re-Compilations/sec is close to ZERO. If nonzero values are consistently occurring for this counter, we should seriously search for the culprit stored procedures. Sql Profiler is a nice tool for this task.
How to monitor Sql Re-Compilation/sec counter values.
On database server machine --> click on RUN -- > type Perfmon -- > delete existing counters by clicking on cross button on top.
Click on + button to add new counter. Add counter Form select “SQL Server: SQL Statistics”. Now select “SQL Re-Compilations/sec” from counters list. Click “Add “button . Click “Close” button to view graphical view of performance monitor.
On request of few blog readers following script will generate table data script based on your given conditions. This script is useful to generate script for only required records of a targeted table data and not the whole data for a table.
Following are four steps to achieve our goal.
1.Create function to get all columns name of targeted table
2.Create function to get values for all columns of targeted table
3.Create a store procedure, to group our queries for future use.
4.Execute store procedure with following parameters
Aasim Abdullah is working as SQL Server DBA with CureMD (www.curemd.com) based in NY, USA. He has been working with SQL Server since 2007 (Version 2005) and has used it in many projects as a developer, administrator, database designer. Aasim's primary interest is SQL Server performance tuning. If he finds the time, he like to sketch faces with graphite penciles.