Imagine you want to list all the files on C: on the SQL Server Windows host: you could write a T-SQL statement like this one:

EXECUTE master..xp_cmdshell 'dir c:'

This stored procedure, however, is a very dangerous one, as it would allow to execute harmful code. This is the reason why it’s disabled by default. Even when enabled, only users on the sysadmin role can use it.

If you ever need some users the ability to run only some specific commands with xp_cmdshell, you can use the method I’ll explain below, making use of the EXECUTE AS modifier of the stored procedure definitions in T-SQL.

The proposed solution involves five steps:

• Enabling the xp_cmdshell extended procedure.
• Adding a procedure on the database with the EXECUTE AS modifier as an administrator, controlling which commands are allowed to be executed.
• Modifying or creating the xp_cmdshell_proxy_account, associating it to a user with sysadmin privileges.
• Giving the user(s) you want the EXECUTE privileges to the procedure.
• Grant the proxy account user the privilege to log on as a batch in the Windows server.

The execution of xp_cmdshell must be enabled on the SQL Server. This can be done through the SQL Surface Area Configuration utility or by code. Refer to Figure below on how to activate xp_cmdshell through the SQL Surface Area Configuration.

SQL Surface Area

To enable xp_cmdshell using SQL code, use the sentences below:

EXEC master.dbo.sp_configure 'show advanced options', 1
RECONFIGURE
EXEC master.dbo.sp_configure 'xp_cmdshell', 1
RECONFIGURE

This will allow users of the sysadmin role, and no one else, to execute xp_cmdshell.

Now we have to create a special stored procedure that will control the actions used as parameters to xp_cmdshell. This will allow the administrators of the database to have control over which commands they allow to be executed on their servers. The most important part of this procedure is the EXECUTE AS OWNER modifier. By using this modifier, everyone that runs that procedure will be able to run it as if it was the owner of the database, thus having execute permissions to xp_cmdshell (we’re assuming the procedure will be created in the master schema. By granting execute permissions on that procedure, you will allow specific users an indirect way to call the xp_cmdshell.

Using this method, only the users of the sysadmin role will be able to execute xp_cmdshell, and only the users you grant EXECUTE permissions on the stored procedure will be able to execute the specific commands that you allow.

To insert the store procedure, log in as a sysadmin on the database and create it with the EXECUTE AS OWNER modifier on it.

For the above procedure to work on non sysadmin accounts there is another step that has to be done. By default, even if you have permissions on the store procedure, you won’t be able to execute it if you’re not on the sysadmin role. This is because those users need a proxy account that is used as the account in which the xp_cmdshell is executed.

So, for this procedure to work, you must create or modify the xp_cmdshell_proxy_account with a user within the sysadmin role. To setup this account, proceed with the code below:

EXEC sp_xp_cmdshell_proxy_account 'MyDomain\MyUserName', 'myDomainPassword'

If the above code does not work, try this one:

CREATE credential ##xp_cmdshell_proxy_account## WITH IDENTITY = 'Domain\DomainUser', secret =  password'

After the procedure and the proxy account have been set, the users we want to be able to execute the procedure must be granted EXECUTE permission on it. To do so, execute this statement for every user you want to grant permissions:

GRANT EXECUTE ON Tango_xp_cmdshell TO <username>;
GO

To grant this permission, use the Local Security Settings on the Administrative Tools interface of the Windows Control Panel. Once there locate the property shown on the screenshot and add the user you gave permissions to the user list.

Local Security Policy

Note that enabling the xp_cmdshell command may still have some security implications, so try to avoid it when possible.

One of the most interesting features of any good database engine is what we call concurrency. Concurrency means than the database engine should be able to perform a lot of data operations at the same time. This leads to some interesting problems that have a critical impact on another of the features that any database engine must ensure: data consistency.

Sometimes you need to perform more than one non atomic operation in a database that only make sense in a block. This is, all those operations should be executed from the start to the end without any other interference from other operations, because those other operations may have a non desired impact in your operations. The simulation of the atomic execution of more than one operation in databases is done by transactions. When you embrace a set of operations in a transaction, you are telling the database engine that you want those operations to be executed as if they were executed in an isolated mode, this is, with no interference from other operations.

While this might seem easy to accomplish, it can also have a big negative performance impact, because you can’t plan on executing all the transactions that arrive at the same time in a sequential way, at least not if you want your database engine to be slow, very slow.

This is where locks ans isolation levels intervene. Locks are protections made to some resources to allow or forbid further access to those resources by another processes. An exclusive lock, for example, done by a process, means that no other process should be able to access that resource until the first process has freed the lock. There are a lot of different locks in SQL Server, which you can review at http://msdn2.microsoft.com/en-us/library/ms175519.aspx.

One of the problems we can face when working with transactions is the well known repeatable read. Suppose a process A starts a transaction and reads a registry with a select clause in a table. After that, another transaction comes in and modifies that data. The first transaction reads the same data again and gets a different value, becuase it was modified by the second transaction. This is inconsistent, because as we are executing a set of operations inside a transaction, we expect them to be executed as if no one else was modifying the data we need to use.

Because of that, there’s a special isolation level called, precisely, Repeatable Read, which has a locking policy to avoid those problems. But be careful with this, since this can cause a nasty deadlock in your SQL Server if used the wrong way.

A deadlock is a special situation where two or more transactions are waiting each other. Imagine trasaction A starts some operations and locks some resources. Later, transaction B comes in, locks another set of resources, and then tries to access resources locked by A, so it waits for A to free those resources. After that, A tries to lock resources locked by B and wait for B to free them. A is waiting for B to free its resources, and B is waiting for A to do the very same thing. We have a deadlock. One of the transactions must be killed by the database engine and rolled back so the other one can continue. Altough this is something you might be able to control by code and issue a relaunch of the killed transaction, this is something usually not desired.

I’m going to talk now about a deadlock you may face when using the Repeatable Read transaction isolation level with SQL Server 2005. Imagine you have two transactions that do the same thing: read a value, modify it, and read it again. Note that you will be modifying the value, but you set the isolation mode to Repeatable Read (this is, setting the wrong isolation mode by mistake or by ignorance). Transaction A starts and reads the value. SQL Server puts a shared lock on that resource. Transaction B starts and reads the value. Because the lock in A was shared, B can also read that value, gaining a shared lock too. Now transaction B tries to write that value. Because the shared lock put by A was read only, B has to wait for A to release its shared lock to be able to gain write acces to it, so it blocks. After that, A tries to write the value, and because now it’s transaction B that has a shared lock on the resource, it has to wait too. And there it is, the deadlock.

The key in avoiding this is that, although we perform a read-write-read operation, we don’t need the second read to be the same as the first, because we are modifying that resource. In this case, the lock our transactions should get is an update lock, which knows that we’ll be modifying that data after having read it. This way, when transaction A locks the resource, the lock will not be shared, so transaction B will have to wait for A to write the new value before B gets the lock, thus avoiding the deadlock. Another option is use an isolation level that frees the locks just after having read the value, and not maintaining it until the next update.

The conclusion to this is: be careful when working with transactions on which isolation level you use on them, and be sure you’re using the right one if you don’t want to have bug reports when a lof of concurrency starts to stress the database engine!