What risks are there if we enable read committed snapshot in sql-server?

Summary

1. If you have locking problems then you have a problem with your code: it isn't the database engine
2. It isn't a magic bullet
3. You may add more problems

Load

It will also increase load on your tempdb and CPU. Also see:

• "Performance Impact: The Potential Cost of Read_Committed_Snapshot" (Linchi Shea)

Safety

Most important, snapshot isolations are not safe in many cases by default. Read "Snapshot isolation" (Wikipedia) for more on write-skew anomalies. The next section is "Making Snapshot Isolation Serializable" to get around this.

In general, therefore, snapshot isolation puts some of the problem of maintaining non-trivial constraints onto the user, who may not appreciate either the potential pitfalls or the possible solutions. The upside to this transfer is better performance.

Also see:

• "The Potential Dangers of the Read Committed Snapshot Isolation Level" (JimMcLeod, disputed in comments by Alex Kuznetsov)
• Deadlocked!: "read committed snapshot" Explained (Nick Berardi)
• Serializable vs. Snapshot Isolation Level, the Marble problem (Craig Freedman)
• Reads involving UDFs under READ_COMMITTED_SNAPSHOT may seem inconsistent (Alex Kuznetsov)

I know this is an old thread but I would say to a large degree snapshot isolation is a magic bullet. It will eliminate all of your blocking between readers and writers. It will however not prevent writers from blocking other writers. There is no way around that.

In my experience, the additional load on the TEMPDB is negligible and the benefits of row versioning in reducing blocked readers is huge.

For reference, row versioning (snapshot isolation) is the method Oracle has used for decades to achieve isolation without blocking readers and the Oracle DBs I've worked on for nearly 20 years experience far less blocking issues than SQL Server does. Most SQL developers are hesitant to use snapshot isolation though because they've only tested their code against databases that use the default setting.

Couple of additional points to add to the other answers:

SET ALLOW_SNAPSHOT_ISOLATION ON only enables snapshot isolation in a database. To take advantage of it you have to recode and SET TRANSACTION ISOLATION LEVEL SNAPSHOT for the transactions you want it to apply to. The calling code will need to be changed to handle update conflict errors.

After SET READ_COMMITTED_SNAPSHOT ON, statements at read committed use row-versioning. Note, this is statement level row-versioning for reads only. For updates, the "real" row is retrieved and update locks applied. See the Summary of Behaviour section in Understanding Row-Versioning based Isolation Levels

Either route, without exhaustive testing you're likely to introduce a completely new set of problems to the system.