FIX: A MERGE statement may not enforce a foreign key constraint when the statement updates a unique key column that is not part of a clustering key and there is a single row as the update source in SQL Server 2008

In Microsoft SQL Server 2008, a foreign key constraint may not be enforced when the following conditions are true:
• A MERGE statement is issued.
• The target column of the update has a nonclustered unique index.

Microsoft has created the first Hotfix for SQL Server 2008 which will fix this issue.

You can read more about this bug including how you can obtain the fix here: http://support.microsoft.com/kb/956718

Adam Machanic created an item on connect explaining how LINQ to SQL queries involving strings cause SQL Server procedure cache bloat

If an application is using LINQ to SQL and the queries involve the use of strings that can be highly variable in length, the SQL Server procedure cache will become bloated with one version of the query for every possible string length. For example, consider the following very simple queries created against the Person.AddressTypes table in the AdventureWorks2008 database:

If both of these queries are run, we will see two entries in the SQL Server procedure cache: One bound with an NVARCHAR(7), and the other with an NVARCHAR(11). Now imagine if there were hundreds or thousands of different input strings, all with different lengths. The procedure cache would become unnecessarily filled with all sorts of different plans for the exact same query. Even worse, imagine if a query used two or three different string parameters. The procedure cache could end up with hundreds of thousands or even millions of entries, the only differences being the variable lengths

Wow that is bad indeed, please go to the connect site and vote for this so that Microsoft ‘fixes’ this. Here is the URL: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Got an email from a friend who is suffering from this problem

Here are the symptoms
When you host Web applications that use Microsoft ASP.NET on a computer that is running Microsoft Windows Server 2003, you may experience decreased performance. This issue may occur when you host the Web applications in multiple application pools on a multiprocessor computer. Additionally, you may experience one or more of the following issues when available memory is low:
• You may receive exceptions of type System.OutOfMemoryException.
• You may receive the following error message when you try to open an ASP.NET Web page:
Server Application Unavailable
• The computer may stop responding.

And here is why
These issues occur because the Microsoft .NET Framework common language runtime (CLR) uses the Server garbage collector (GC) on multiprocessor computers. This is the default behavior. The Server garbage collector is optimized for scalable throughput on multiprocessor computers. To reduce contention and to improve garbage collector performance on multiprocessor computers, the Server garbage collector creates one heap per processor for parallel collections. Therefore, the Server garbage collector consumes lots of memory when you host multiple ASP.NET worker processes. This behavior may cause the issues that are described in the “Symptoms” section.

Microsoft has published a knowledge base article, you can read the article here: http://support.microsoft.com/kb/911716

The article has the workaround for this problem