SQL Server - Stored Procedure Checklist

DBAs find it easier to manage large Database Server environments when checklists are
used. This Stored procedure checklist will stimulate some ideas you could use

For acceptance into the SQL Server environment , I’ve developed some scripts that
scan the T-SQL code for some items in this checklist

1) Same case for T-SQL Keywords. I prefer UPPER CASE , but I know other
DBA\Developers like lower case.

2) Inspect input parameters for valid values (numbers, strings etc)

3) Force developers to justify usage of dynamic SQL (SP_EXECUTESQL,

EXEC('SELECT col1…..')

4) Commenting. I prefer a comment block at the top with usage and revision history .
Snippets throughout the code to enhance the understanding

5) Limit xp_cmdshell usage - Read Xp_cmdshell – the most dangerous extended

stored procedure on the planet

6) Think in set theory. Avoid looping such as cursors.

7) Clean up . Close objects ,drop #temp tables, deallocate\close cursors, close

transactions

8) Use try...catch blocks. Trap errors and report into a log file

9) Performance is satisfactory

10) Investigate input parameters for SQL injection attacks. Better if it occurs at the
application level .

11) Manage security. Follow the SQL Server Security Policy.Access to stored
procedure and underlying objects

Xp_cmdshell – the most dangerous extended stored

procedure on the planet
Xp_cmdshell is possibly the most dangerous extended stored procedure on the planet.
I’ve seen some serious impact on a combination of xp_cmshell enabled and sysadmin
rights. The main reason for it’s dangerous image is xp_cmdshell allows shell scripts
to execute on OS.

My general rule is to not allow non DBAs xp_cmdshell direct access. If a user
requests xp_cmdshell with a valid and pragmatic reason, then I’ll set up a stored
procedure – allowing them to run only xp_cmdshell through this stored procedures.
Think about adding a check on input parameters to this managed store procedure

There are valid reasons for granting a user xp_cmdshell. A review is essential. Some
risk analysis should be implemented , weighing thesecurity risks and benefits
associated with granting xp_cmdshell privileges to a login

Different methods of granting xp_cmshell permissions

1. Grant sysadmin to the login account

2. It is also possible to grant a user xp_cmdshell usage by granting EXECUTE
permissions to the login on the stored procedure xp_cmdshell

How to check if xp_cmdshell is enabled

view source
print?
1.SELECT CONVERT(INT, ISNULL(value, value_in_use)) AS config_value
2.FROM sys.configurations WHERE name = 'xp_cmdshell' ;

Trace flag 610 and High performance data loading

06 June,2016 by Jack Vamvas
The Data Performance data loading guide is one of the most comprehensive
documents available when it comes to techniques for data loading performance. One
of the useful techniques is using trace flag 610.

Trace flag 610 sends an instruction to the server to minimally log INSERT and MERGE
on new page allocations. If rows are being added on existing page allocations fully
logged will persist.

This impacts minimally logged inserts into indexed tables.

view source
print?
1.-- enable trace flag 610
2.DBCC TRACEON (610);
3.-- disable trace flag 610
4.DBCC TRACEOFF(610);
5.-- minimally logged
6.MERGE INTO X1 USING Y1 ON

Keep in mind, the trace flag 610 turned on is SQL Server instance wide. All connections
to the SQL Server instance will be impacted.

Given the nature of the trace and the criteria required to be met :

1. New page allocations

2. Indexed tables

This is not a “catch-all” performance solution. But if proper analysis is completed and
solid testing , there are some potential gains. I’ve used it with good results in certain
large data loads.