有几种消息接收器的类型，一个调用拦截可以在服务器端进行也可以在客户端进行，服务器端接收器拦截所有对服务器上下文环境中对象的调用，同时作一些前处理和后处理。客户端的接收器拦截所有外出客户端上下文环境的调用，同时也做一些前处理和后处理。服务器负责服务器端接收器的安装，拦截对服务器端上下文环境访问的接收器称为服务器上下文环境接收器，那些拦截调用实际对象的接收器是对象接收器。通过客户安装的客户端接收器称为客户端上下文环境接受器，通过对象安装的客户端接收器则称为特使（Envoy）接收器，特使接收器仅拦截那些和它相关的对象。客户端的最后一个接收器和服务器端的第一个接收器是CrossContextChannel类型的实例。不同类型的接收器组成不同的段，每个段的端点都装上称为终结器的接收器，终结器起着把本段的消息传给下一个段的作用。在服务器上下文环境段的最后一个终结器是ServerContextTerminatorSink。如果你在终结器调用NextSink，它将返回一个null，它们的行为就像是死端头，但是在它们内部保存有下一个接收器对象的私有字段。

我们大致介绍了.NET Framework的对象调用拦截的实现机制，目的是让大家对这种机制有一个认识，现在是实现我们代码的时候了，通过代码的实现，你可以看到消息如何被处理的过程。首先是为我们的程序定义一个接收器CallTraceSink:

//TraceContext.cs

using System;
using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Remoting.Activation;

namespace NiwalkerDemo
{
    public class CallTraceSink : IMessageSink //实现IMessageSink
    {
       private IMessageSink nextSink;   //保存下一个接收器
       
       //在构造器中初始化下一个接收器
       public CallTraceSink(IMessageSink next)
       {
          nextSink=next;
       }
       
       //必须实现的IMessageSink接口属性
       public IMessageSink NextSink
       {
          get
          {
             return nextSink;
          }
       }
       
       //实现IMessageSink的接口方法，当消息传递的时候，该方法被调用
       public IMessage SyncProcessMessage(IMessage msg)
       {
          //拦截消息，做前处理
          Preprocess(msg);
          //传递消息给下一个接收器
          IMessage retMsg=nextSink.SyncProcessMessage(msg);
          //调用返回时进行拦截，并进行后处理
          Postprocess(msg,retMsg);
          return retMsg;
       }
       
       //IMessageSink接口方法，用于异步处理，我们不实现异步处理，所以简单返回null,
       //不管是同步还是异步，这个方法都需要定义
       public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink)
       {
          return null;
       }
       
       //我们的前处理方法，用于检查库存，出于简化的目的，我们把检查库存和发送邮件都写在一起了，
       //在实际的实现中，可能也需要把Inventory对象绑定到一个上下文环境，
       //另外，可以将发送邮件设计为另外一个接收器，然后通过NextSink进行安装
       private void Preprocess(IMessage msg)
       {
          //检查是否是方法调用，我们只拦截Order的Submit方法。
          IMethodCallMessage call=msg as IMethodCallMessage;
          
          if(call==null)
             return;
          
          if(call.MethodName=="Submit")
          {
             string product=call.GetArg(0).ToString(); //获取Submit方法的第一个参数
             int qty=(int)call.GetArg(1); //获取Submit方法的第二个参数
             
             //调用Inventory检查库存存量
             if(new Inventory().Checkout(product,qty))
                Console.WriteLine("Order availible");
             else
             {
                Console.WriteLine("Order unvailible");
                SendEmail();
             }
           }
        }
        
        //后处理方法，用于记录订单提交信息，同样可以将记录作为一个接收器
        //我们在这里处理，仅仅是为了演示
        private void Postprocess(IMessage msg,IMessage retMsg)
        {
           IMethodCallMessage call=msg as IMethodCallMessage;
           
           if(call==null)
              return;
           Console.WriteLine("Log order information");
        }
        
        private void SendEmail()
        {
           Console.WriteLine("Send email to manager");
        }
     }   
         ...   

       ...
public class CallTraceProperty : IContextProperty, IContributeObjectSink
{
    public CallTraceProperty()
    {
    }
    
    //IContributeObjectSink的接口方法，实例化消息接收器
    public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink next)
    {
       return new CallTraceSink(next);
    }
    
    //IContextProperty接口方法，如果该方法返回ture,在新的上下文环境中激活对象
    public bool IsNewContextOK(Context newCtx)
    {
       return true;
    }
    
    //IContextProperty接口方法，提供高级使用
    public void Freeze(Context newCtx)
    {
    }
    
    //IContextProperty接口属性
    public string Name
    {
       get { return "OrderTrace";}
    }
}
          ...

   ...
    [AttributeUsage(AttributeTargets.Class)]
    public class CallTraceAttribute : ContextAttribute
    {
       public CallTraceAttribute():base("CallTrace")
       {
       }
       
       //重载ContextAttribute方法，创建一个上下文环境属性
       public override void GetPropertiesForNewContext(IConstructionCallMessage ctorMsg)
       {
          ctorMsg.ContextProperties.Add(new CallTraceProperty());
       }
    }
}

//Inventory.cs

//Order.cs
using System;

namespace NiwalkerDemo
{
    [CallTrace]
    public class Order : ContextBoundObject
    {
       ...
       public void Submit(string product, int quantity)
       {
          this.product=product;
          this.quantity=quantity;
       }
     ...
    }
}

...
public class AppMain
{
    static void Main()
    {
       Order order1=new Order(100);
       order1.Submit("Item1",150);
       
       Order order2=new Order(101);
       order2.Submit("Item2",150);
    }
}
...

运行结果表明了我们对Order的Sbumit成功地进行了拦截。需要说明的是，这里的代码仅仅是作为对ContextAttribute应用的演示，它是粗线条的。在具体的实践中，大家可以设计的更精妙。

后记：本来想对Attribute进行更多的介绍，发现要讲的东西实在是太多了。请允许我在其他的专题中再来讨论它们。十分感谢大家有耐心读完这个系列。如果这里介绍的内容在你的编程生涯有所启迪的话，那么就是我的莫大荣幸了。再一次谢谢大家。

在.NET中有两种调用，一种是跨应用域（App Domain)，一种是跨上下文环境（Context)，两种调用均通过中间的代理（proxy)，代理被分为两个部分：透明代理和实际代理。透明代理暴露同对象一样的公共入口点，当客户调用透明代理的时候，透明代理把堆栈中的帧转换为消息（上一节提到的实现IMessage接口的对象），消息中包含了方法名称和参数等属性集，然后把消息传递给实际代理，接下去分两种情况：在跨应用域的情况下，实际代理使用一个格式化器对消息进行序列化，然后放入远程通道中；在跨上下文环境的情况下，实际代理不必知道格式化器、通道和Context拦截器，它只需要在向前传递消息之前对调用实行拦截，然后它把消息传递给一个消息接收器（实现IMessageSink的对象），每一个接收器都知道自己的下一个接收器，当它们对消息进行处理之后（前处理），都将消息传递给下一个接收器，一直到链表的最后一个接收器，最后一个接收器被称为堆栈创建器，它把消息还原为堆栈帧，然后调用对象，当调用方法结果返回的时候，堆栈创建器把结果转换为消息，传回给调用它的消息接收器，于是消息沿着原来的链表往回传，每个链表上的消息接收器在回传消息之前都对消息进行后处理。一直到链表的第一个接收器，第一个接收器把消息传回给实际代理，实际代理把消息传递给透明代理，后者把消息放回到客户端的堆栈中。从上面的描述我们看到穿越Context的消息不需要格式化，CLR使用一个内部的通道，叫做CrossContextChannel，这个对象也是一种消息接收器。

有几种消息接收器的类型，一个调用拦截可以在服务器端进行也可以在客户端进行，服务器端接收器拦截所有对服务器上下文环境中对象的调用，同时作一些前处理和后处理。客户端的接收器拦截所有外出客户端上下文环境的调用，同时也做一些前处理和后处理。服务器负责服务器端接收器的安装，拦截对服务器端上下文环境访问的接收器称为服务器上下文环境接收器，那些拦截调用实际对象的接收器是对象接收器。通过客户安装的客户端接收器称为客户端上下文环境接受器，通过对象安装的客户端接收器则称为特使（Envoy）接收器，特使接收器仅拦截那些和它相关的对象。客户端的最后一个接收器和服务器端的第一个接收器是CrossContextChannel类型的实例。不同类型的接收器组成不同的段，每个段的端点都装上称为终结器的接收器，终结器起着把本段的消息传给下一个段的作用。在服务器上下文环境段的最后一个终结器是ServerContextTerminatorSink。如果你在终结器调用NextSink，它将返回一个null，它们的行为就像是死端头，但是在它们内部保存有下一个接收器对象的私有字段。

我们大致介绍了.NET Framework的对象调用拦截的实现机制，目的是让大家对这种机制有一个认识，现在是实现我们代码的时候了，通过代码的实现，你可以看到消息如何被处理的过程。首先是为我们的程序定义一个接收器CallTraceSink:

//TraceContext.cs

using System;
using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Remoting.Activation;

namespace NiwalkerDemo
{
    public class CallTraceSink : IMessageSink //实现IMessageSink
    {
       private IMessageSink nextSink;   //保存下一个接收器
       
       //在构造器中初始化下一个接收器
       public CallTraceSink(IMessageSink next)
       {
          nextSink=next;
       }
       
       //必须实现的IMessageSink接口属性
       public IMessageSink NextSink
       {
          get
          {
             return nextSink;
          }
       }
       
       //实现IMessageSink的接口方法，当消息传递的时候，该方法被调用
       public IMessage SyncProcessMessage(IMessage msg)
       {
          //拦截消息，做前处理
          Preprocess(msg);
          //传递消息给下一个接收器
          IMessage retMsg=nextSink.SyncProcessMessage(msg);
          //调用返回时进行拦截，并进行后处理
          Postprocess(msg,retMsg);
          return retMsg;
       }
       
       //IMessageSink接口方法，用于异步处理，我们不实现异步处理，所以简单返回null,
       //不管是同步还是异步，这个方法都需要定义
       public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink)
       {
          return null;
       }
       
       //我们的前处理方法，用于检查库存，出于简化的目的，我们把检查库存和发送邮件都写在一起了，
       //在实际的实现中，可能也需要把Inventory对象绑定到一个上下文环境，
       //另外，可以将发送邮件设计为另外一个接收器，然后通过NextSink进行安装
       private void Preprocess(IMessage msg)
       {
          //检查是否是方法调用，我们只拦截Order的Submit方法。
          IMethodCallMessage call=msg as IMethodCallMessage;
          
          if(call==null)
             return;
          
          if(call.MethodName=="Submit")
          {
             string product=call.GetArg(0).ToString(); //获取Submit方法的第一个参数
             int qty=(int)call.GetArg(1); //获取Submit方法的第二个参数
             
             //调用Inventory检查库存存量
             if(new Inventory().Checkout(product,qty))
                Console.WriteLine("Order availible");
             else
             {
                Console.WriteLine("Order unvailible");
                SendEmail();
             }
           }
        }
        
        //后处理方法，用于记录订单提交信息，同样可以将记录作为一个接收器
        //我们在这里处理，仅仅是为了演示
        private void Postprocess(IMessage msg,IMessage retMsg)
        {
           IMethodCallMessage call=msg as IMethodCallMessage;
           
           if(call==null)
              return;
           Console.WriteLine("Log order information");
        }
        
        private void SendEmail()
        {
           Console.WriteLine("Send email to manager");
        }
     }   
         ...   

       ...
public class CallTraceProperty : IContextProperty, IContributeObjectSink
{
    public CallTraceProperty()
    {
    }
    
    //IContributeObjectSink的接口方法，实例化消息接收器
    public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink next)
    {
       return new CallTraceSink(next);
    }
    
    //IContextProperty接口方法，如果该方法返回ture,在新的上下文环境中激活对象
    public bool IsNewContextOK(Context newCtx)
    {
       return true;
    }
    
    //IContextProperty接口方法，提供高级使用
    public void Freeze(Context newCtx)
    {
    }
    
    //IContextProperty接口属性
    public string Name
    {
       get { return "OrderTrace";}
    }
}
          ...

   ...
    [AttributeUsage(AttributeTargets.Class)]
    public class CallTraceAttribute : ContextAttribute
    {
       public CallTraceAttribute():base("CallTrace")
       {
       }
       
       //重载ContextAttribute方法，创建一个上下文环境属性
       public override void GetPropertiesForNewContext(IConstructionCallMessage ctorMsg)
       {
          ctorMsg.ContextProperties.Add(new CallTraceProperty());
       }
    }
}

//Inventory.cs

//Order.cs
using System;

namespace NiwalkerDemo
{
    [CallTrace]
    public class Order : ContextBoundObject
    {
       ...
       public void Submit(string product, int quantity)
       {
          this.product=product;
          this.quantity=quantity;
       }
     ...
    }
}

...
public class AppMain
{
    static void Main()
    {
       Order order1=new Order(100);
       order1.Submit("Item1",150);
       
       Order order2=new Order(101);
       order2.Submit("Item2",150);
    }
}
...

运行结果表明了我们对Order的Sbumit成功地进行了拦截。需要说明的是，这里的代码仅仅是作为对ContextAttribute应用的演示，它是粗线条的。在具体的实践中，大家可以设计的更精妙。

后记：本来想对Attribute进行更多的介绍，发现要讲的东西实在是太多了。请允许我在其他的专题中再来讨论它们。十分感谢大家有耐心读完这个系列。如果这里介绍的内容在你的编程生涯有所启迪的话，那么就是我的莫大荣幸了。再一次谢谢大家。
（全文完）

经常有朋友问，Attribute是什么？它有什么用？好像没有这个东东程序也能运行。实际上在.Net中，Attribute是一个非常重要的组成部分，为了帮助大家理解和掌握Attribute，以及它的使用方法，特地收集了几个Attribute使用的例子，提供给大家参考。

在具体的演示之前，我想先大致介绍一下Attribute。我们知道在类的成员中有property成员，二者在中文中都做属性解释，那么它们到底是不是同一个东西呢？从代码上看，明显不同，首先就是它们的在代码中的位置不同，其次就是写法不同（Attribute必须写在一对方括符中）。

什么是Atrribute

首先，我们肯定Attribute是一个类，下面是msdn文档对它的描述：
公共语言运行时允许你添加类似关键字的描述声明，叫做attributes, 它对程序中的元素进行标注，如类型、字段、方法和属性等。Attributes和Microsoft .NET Framework文件的元数据保存在一起，可以用来向运行时描述你的代码，或者在程序运行的时候影响应用程序的行为。

在.NET中,Attribute被用来处理多种问题，比如序列化、程序的安全特征、防止即时编译器对程序代码进行优化从而代码容易调试等等。下面，我们先来看几个在.NET中标准的属性的使用，稍后我们再回过头来讨论Attribute这个类本身。（文中的代码使用C#编写，但同样适用所有基于.NET的所有语言）

Attribute作为编译器的指令

在C#中存在着一定数量的编译器指令，如：#define DEBUG, #undefine DEBUG, #if等。这些指令专属于C#,而且在数量上是固定的。而Attribute用作编译器指令则不受数量限制。比如下面的三个Attribute:

• Conditional：起条件编译的作用，只有满足条件，才允许编译器对它的代码进行编译。一般在程序调试的时候使用。
• DllImport：用来标记非.NET的函数，表明该方法在一个外部的DLL中定义。
• Obsolete：这个属性用来标记当前的方法已经被废弃，不再使用了。

下面的代码演示了上述三个属性的使用：

 
#define DEBUG //这里定义条件
      
using System;
using System.Runtime.InteropServices;
using System.Diagnostics;
      
namespace AttributeDemo
{
     class MainProgramClass
     {
 
        [DllImport("User32.dll")]
        public static extern int MessageBox(int hParent, string Message, string Caption, int Type);
       
        static void Main(string[] args)
        {
           DisplayRunningMessage();
           DisplayDebugMessage();
       
           MessageBox(0,"Hello","Message",0);
       
           Console.ReadLine();
        }
       
        [Conditional("DEBUG")]
        private static void DisplayRunningMessage()
        {
           Console.WriteLine("开始运行Main子程序。当前时间是"+DateTime.Now);
        }
    
        [Conditional("DEBUG")]
        [Obsolete]
        private static void DisplayDebugMessage()
        {
           Console.WriteLine("开始Main子程序");
        }
     }
}    

如果在一个程序元素前面声明一个Attribute,那么就表示这个Attribute被施加到该元素上，前面的代码，[DllImport]施加到MessageBox函数上, [Conditional]施加到DisplayRuntimeMessage方法和DisplayDebugMessage方法，[Obsolete]施加到DisplayDebugMessage方法上。

根据上面涉及到的三个Attribute的说明，我们可以猜到程序运行的时候产生的输出：DllImport Attribute表明了MessageBox是User32.DLL中的函数，这样我们就可以像内部方法一样调用这个函数。

重要的一点就是Attribute就是一个类，所以DllImport也是一个类，Attribute类是在编译的时候被实例化的，而不是像通常的类那样在运行时候才实例化。Attribute实例化的时候根据该Attribute类的设计可以带参数，也可以不带参数，比如DllImport就带有"User32.dll"的参数。Conditional对满足参数的定义条件的代码进行编译，如果没有定义DEBUG,那么该方法将不被编译，读者可以把#define DEBUG一行注释掉看看输出的结果（release版本，在Debug版本中Conditional的debug总是成立的）。Obsolete表明了DispalyDebugMessage方法已经过时了，它有一个更好的方法来代替它，当我们的程序调用一个声明了Obsolete的方法时，那么编译器会给出信息，Obsolete还有其他两个重载的版本。大家可以参考msdn中关于的ObsoleteAttribute 类的描述。

Attribute类

除了.NET提供的那些Attribute派生类之外，我们可以自定义我们自己的Attribute，所有自定义的Attribute必须从Attribute类派生。现在我们来看一下Attribute 类的细节：

protected Attribute(): 保护的构造器，只能被Attribute的派生类调用。

三个静态方法：

static Attribute GetCustomAttribute():这个方法有8种重载的版本，它被用来取出施加在类成员上指定类型的Attribute。

static Attribute[] GetCustomAttributes(): 这个方法有16种重载版本，用来取出施加在类成员上指定类型的Attribute数组。

static bool IsDefined():由八种重载版本，看是否指定类型的定制attribute被施加到类的成员上面。

实例方法：

bool IsDefaultAttribute(): 如果Attribute的值是默认的值，那么返回true。

bool Match():表明这个Attribute实例是否等于一个指定的对象。

公共属性： TypeId: 得到一个唯一的标识，这个标识被用来区分同一个Attribute的不同实例。

我们简单地介绍了Attribute类的方法和属性，还有一些是从object继承来的。这里就不列出来了。

下面介绍如何自定义一个Attribute: 自定义一个Attribute并不需要特别的知识，其实就和编写一个类差不多。自定义的Attribute必须直接或者间接地从Attribute这个类派生，如：

public MyCustomAttribute : Attribute { ... }

这里需要指出的是Attribute的命名规范，也就是你的Attribute的类名+"Attribute",当你的Attribute施加到一个程序的元素上的时候，编译器先查找你的Attribute的定义，如果没有找到，那么它就会查找“Attribute名称"+Attribute的定义。如果都没有找到，那么编译器就报错。

对于一个自定义的Attribute，你可以通过AttributeUsage的Attribute来限定你的Attribute 所施加的元素的类型。代码形式如下： [AttriubteUsage(参数设置)] public 自定义Attribute : Attribute { ... }

非常有意思的是，AttributeUsage本身也是一个Attribute，这是专门施加在Attribute类的Attribute. AttributeUsage自然也是从Attribute派生，它有一个带参数的构造器，这个参数是AttributeTargets的枚举类型。下面是AttributeTargets 的定义：

public enum AttributeTargets
{
     All=16383,
     Assembly=1,
     Module=2,
     Class=4,
     Struct=8,
     Enum=16,
     Constructor=32,
     Method=64,
     Property=128,
     Field=256,
     Event=512,
     Interface=1024,
     Parameter=2048,
     Delegate=4096,
     ReturnValue=8192
}       
           
     

作为参数的AttributeTarges的值允许通过“或”操作来进行多个值得组合，如果你没有指定参数，那么默认参数就是All 。 AttributeUsage除了继承Attribute 的方法和属性之外，还定义了以下三个属性：

AllowMultiple: 读取或者设置这个属性，表示是否可以对一个程序元素施加多个Attribute 。

Inherited:读取或者设置这个属性，表示是否施加的Attribute 可以被派生类继承或者重载。

ValidOn: 读取或者设置这个属性，指明Attribute 可以被施加的元素的类型。

AttributeUsage 的使用例子：

using System; 
namespace AttTargsCS 
{ 

     // 该Attribute只对类有效. 
     [AttributeUsage(AttributeTargets.Class)]
     public class ClassTargetAttribute : Attribute 
     { 
      } 

     // 该Attribute只对方法有效. 
     [AttributeUsage(AttributeTargets.Method)]
     public class MethodTargetAttribute : Attribute 
     { 
      } 

     // 该Attribute只对构造器有效。
     [AttributeUsage(AttributeTargets.Constructor)]
     public class ConstructorTargetAttribute : Attribute 
     { 
      } 

     // 该Attribute只对字段有效. 
     [AttributeUsage(AttributeTargets.Field)]
     public class FieldTargetAttribute : Attribute
     {
     } 

     
    // 该Attribute对类或者方法有效（组合）. 
    [AttributeUsage(AttributeTargets.Class|AttributeTargets.Method)]
     public class ClassMethodTargetAttribute : Attribute
     {
      } 

     // 该Attribute对所有的元素有效.
     [AttributeUsage(AttributeTargets.All)]
     public class AllTargetsAttribute : Attribute 
    { 
     } 

     //上面定义的Attribute施加到程序元素上的用法
     [ClassTarget]    //施加到类
     [ClassMethodTarget]//施加到类
     [AllTargets] //施加到类
     public class TestClassAttribute
     { 
        [ConstructorTarget] //施加到构造器
        [AllTargets] //施加到构造器
        TestClassAttribute()
        { 
         } 

        [MethodTarget] //施加到方法
        [ClassMethodTarget] //施加到方法
        [AllTargets] //施加到方法
        public void Method1()
        {
        }
       
        [FieldTarget] //施加到字段
        [AllTargets] //施加到字段
        public int myInt; 

        static void Main(string[] args)
        { 
        } 
     }
} 
       
       

至此，我们介绍了有关Attribute类和它们的代码格式。你一定想知道到底如何在你的应用程序中使用Attribute，如果仅仅是前面介绍的内容，还是不足以说明Attribute有什么实用价值的话，那么从后面的章节开始我们将介绍几个Attribute的不同用法，相信你一定会对Attribute有一个新的了解。（待续）

公共属性：
Name:只读属性。返回ContextAttribute的名称

公共方法：
GetPropertiesForNewContext：虚拟方法。向新的Context添加属性集合。
IsContextOK:虚拟方法。查询客户Context中是否存在指定的属性。
IsNewContextOK:虚拟方法。默认返回true。一个对象可能存在多个Context,使用这个方法来检查新的Context中属性是否存在冲突。
Freeze:虚拟方法。该方法用来定位被创建的Context的最后位置。

ContextBoundObject类

实现被拦截的类，需要从ContextBoundObject类派生，这个类的对象通过Attribute来指定它所在Context,凡是进入该Context的调用都可以被拦截。该类从MarshalByRefObject派生。

以下是涉及到的接口：

IMessage:定义了被传送的消息的实现。一个消息必须实现这个接口。

IMessageSink:定义了消息接收器的接口，一个消息接收器必须实现这个接口。

还有几个接口，我们将在下一节结合拦截构架的实现原理中进行介绍。

• Decide upon a database naming convention, standardize it across your organization, and be consistent in following it. It helps make your code more readable and understandable. Click here to see the database object naming convention that I follow.
  
  
• Make sure you normalize your data at least to the 3rd normal form. At the same time, do not compromise on query performance. A little bit of denormalization helps queries perform faster.
  
  
• Write comments in your stored procedures, triggers and SQL batches generously, whenever something is not very obvious. This helps other programmers understand your code clearly. Don't worry about the length of the comments, as it won't impact the performance, unlike interpreted languages like ASP 2.0.
  
  
• Do not use SELECT * in your queries. Always write the required column names after the SELECT statement, like:

SELECT CustomerID, CustomerFirstName, City

This technique results in reduced disk I/O and better performance.

• Try to avoid server side cursors as much as possible. Always stick to a 'set-based approach' instead of a 'procedural approach' for accessing and manipulating data. Cursors can often be avoided by using SELECT statements instead.

If a cursor is unavoidable, use a WHILE loop instead. I have personally tested and concluded that a WHILE loop is always faster than a cursor. But for a WHILE loop to replace a cursor you need a column (primary key or unique key) to identify each row uniquely. I personally believe every table must have a primary or unique key. Click here to see some examples of using a WHILE loop.

• Avoid the creation of temporary tables while processing data as much as possible, as creating a temporary table means more disk I/O. Consider using advanced SQL, views, SQL Server 2000 table variable, or derived tables, instead of temporary tables.
  
  
• Try to avoid wildcard characters at the beginning of a word while searching using the LIKE keyword, as that results in an index scan, which defeats the purpose of an index. The following statement results in an index scan, while the second statement results in an index seek:
  
  SELECT LocationID FROM Locations WHERE Specialities LIKE '%pples'
  SELECT LocationID FROM Locations WHERE Specialities LIKE 'A%s'
  
  Also avoid searching using not equals operators (<> and NOT) as they result in table and index scans.
  
  
• Use 'Derived tables' wherever possible, as they perform better. Consider the following query to find the second highest salary from the Employees table:
  
  SELECT MIN(Salary)
  FROM Employees
  WHERE EmpID IN
  (
  SELECT TOP 2 EmpID
  FROM Employees
  ORDER BY Salary Desc
  )
  
  The same query can be re-written using a derived table, as shown below, and it performs twice as fast as the above query:
  
  SELECT MIN(Salary)
  FROM
  (
  SELECT TOP 2 Salary
  FROM Employees
  ORDER BY Salary DESC
  ) AS A
  
  This is just an example, and your results might differ in different scenarios depending on the database design, indexes, volume of data, etc. So, test all the possible ways a query could be written and go with the most efficient one.
  
  
• While designing your database, design it keeping "performance" in mind. You can't really tune performance later, when your database is in production, as it involves rebuilding tables andindexes, re-writing queries, etc. Use the graphical execution plan in Query Analyzer or SHOWPLAN_TEXT or SHOWPLAN_ALL commands to analyze your queries. Make sure your queries do an "Index seek" instead of an "Index scan" or a "Table scan." A table scan or an index scan is a very bad thing and should be avoided where possible. Choose the right indexes on the right columns.
  
  
• Prefix the table names with the owner's name, as this improves readability and avoids any unnecessary confusion. Microsoft SQL Server Books Online even states that qualifying table names with owner names helps in execution plan reuse, further boosting performance.
  
  
• Use SET NOCOUNT ON at the beginning of your SQL batches, stored procedures and triggers in production environments, as this suppresses messages like '(1 row(s) affected)' after executing INSERT, UPDATE, DELETE and SELECT statements. This improves the performance of stored procedures by reducing network traffic.
  
  
• Use the more readable ANSI-Standard Join clauses instead of the old style joins. With ANSI joins, the WHERE clause is used only for filtering data. Where as with older style joins, the WHERE clause handles both the join condition and filtering data. The first of the following two queries shows the old style join, while the second one shows the new ANSI join syntax:
  
  SELECT a.au_id, t.title
  FROM titles t, authors a, titleauthor ta
  WHERE
  a.au_id = ta.au_id AND
  ta.title_id = t.title_id AND
  t.title LIKE '%Computer%'
  
  SELECT a.au_id, t.title
  FROM authors a
  INNER JOIN
  titleauthor ta
  ON
  a.au_id = ta.au_id
  INNER JOIN
  titles t
  ON
  ta.title_id = t.title_id
  WHERE t.title LIKE '%Computer%'
  
  
• Do not prefix your stored procedure names with "sp_". The prefix sp_ is reserved for system stored procedure that ship with SQL Server. Whenever SQL Server encounters a procedure name starting with sp_, it first tries to locate the procedure in the master database, then it looks for any qualifiers (database, owner) provided, then it tries dbo as the owner. So you can really save time in locating the stored procedure by avoiding the "sp_" prefix.
  
  
• Views are generally used to show specific data to specific users based on their interest. Views are also used to restrict access to the base tables by granting permission only on views. Yet another significant use of views is that they simplify your queries. Incorporate your frequently required, complicated joins and calculations into a view so that you don't have to repeat those joins/calculations in all your queries. Instead, just select from the view.
  
  
• Use User Defined Datatypes if a particular column repeats in a lot of your tables, so that the datatype of that column is consistent across all your tables.
  
  
• Do not let your front-end applications query/manipulate the data directly using SELECT or INSERT/UPDATE/DELETE statements. Instead, create stored procedures, and let your applications access these stored procedures. This keeps the data access clean and consistent across all the modules of your application, and at the same time centralizing the business logic within the database.
  
  
• Try not to use TEXT or NTEXT datatypes for storing large textual data. The TEXT datatype has some inherent problems associated with it. For example, you cannot directly write or update text data using the INSERT or UPDATE statements. Instead,   you have to use special statements like READTEXT, WRITETEXT and UPDATETEXT. There are also a lot of bugs associated with replicating tables containing text columns. So, if you don't have to store more than 8KB of text, use CHAR(8000) or VARCHAR(8000) datatypes instead.
  
  
• If you have a choice, do not store binary or image files (Binary Large Objects or BLOBs) inside the database. Instead, store the path to the binary or image file in the database and use that as a pointer to the actual binary file stored elsewhere on a server. Retrieving and manipulating these large binary files is better performed outside the database, and after all, a database is not meant for storing files.
  
  
• Use the CHAR data type for a column only when the column is non-nullable. If a CHAR column is nullable, it is treated as a fixed length column in SQL Server 7.0+. So, a CHAR(100), when NULL, will eat up 100 bytes, resulting in space wastage. So, use VARCHAR(100) in this situation. Of course, variable length columns do have a very little processing overhead over fixed length columns. Carefully choose between CHAR and VARCHAR depending up on the length of the data you are going to store.
  
  
• Avoid dynamic SQL statements as much as possible. Dynamic SQL tends to be slower than static SQL, as SQL Server must generate an execution plan every time at runtime. IF and CASE statements come in handy to avoid dynamic SQL. Another major disadvantage of using dynamic SQL is that it requires users to have direct access permissions on all accessed objects, like tables and views. Generally, users are given access to the stored procedures which reference the tables, but not directly on the tables. In this case, dynamic SQL will not work. Consider the following scenario where a user named 'dSQLuser' is added to the pubs database and is granted access to a procedure named 'dSQLproc', but not on any other tables in the pubs database. The procedure dSQLproc executes a direct SELECT on titles table and that works. The second statement runs the same SELECT on titles table, using dynamic SQL and it fails with the following error:
  
  Server: Msg 229, Level 14, State 5, Line 1
  SELECT permission denied on object 'titles', database 'pubs', owner 'dbo'.

Transaction Isolation Levels

nonrepeatable read
When a transaction reads the same row more than one time, and between the
two (or more) reads, a separate transaction modifies that row. Because the
row was modified between reads within the same transaction, each read
produces different values, which introduces inconsistency.

phantom
Phantom behavior occurs when a transaction attempts to select a row that
does not exist and a second transaction inserts the row before the first
transaction finishes. If the row is inserted, the row appears as a phantom
to the first transaction, inconsistently appearing and disappearing.

SET TRANSACTION ISOLATION LEVEL 
     {
         READ COMMITTED 
         | READ UNCOMMITTED 
         | REPEATABLE READ 
         | SERIALIZABLE
     }

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
DBCC USEROPTIONS
GO

spid    locktype                             table_id     page         dbname
------ ----------------------------------- ----------- ----------- ---------------
11      Sh_intent                            688005482    0            master
11      Ex_extent                            0            336          tempdb

As you might imagine, deadlocks can use up SQL Server's resources, especially CPU power, wasting it unnecessarily.

Most well-designed applications, after receiving a deadlock message, will resubmit the aborted transaction, which most likely can now run successfully. This process, if it happens often on your server, can drag down performance. If the application has not been written to trap deadlock errors and to automatically resubmit the aborted transaction, users may very well become confused as to what is happening when they receive deadlock error messages on their computer.

Here are some tips on how to avoid deadlocking on your SQL Server:

• Ensure the database design is properly normalized.
• Have the application access server objects in the same order each time.
• During transactions, don't allow any user input. Collect it before the transaction begins.
• Avoid cursors.
• Keep transactions as short as possible. One way to help accomplish this is to reduce the number of round trips between your application and SQL Server by using stored procedures or keeping transactions with a single batch. Another way of reducing the time a transaction takes to complete is to make sure you are not performing the same reads over and over again. If you do need to read the same data more than once, cache it by storing it in a variable or an array, and then re-reading it from there.
• Reduce lock time. Try to develop your application so that it grabs locks at the latest possible time, and then releases them at the very earliest time.
• If appropriate, reduce lock escalation by using the ROWLOCK or PAGLOCK.
• Consider using the NOLOCK hint to prevent locking if the data being locked is not modified often.
• If appropriate, use as low of an isolation level as possible for the user connection running the transaction.   
• Consider using bound connections.

[6.5, 7.0, 2000, 2005] Updated 6-6-2005

*****

When a deadlock occurs, by default, SQL Server choose a deadlock "victim" by identifying which of the two processes will use the least amount of resources to rollback, and then returns error message 1205.

But what if you don't like default behavior? Can you change it? Yes, you can, by using the following command:

SET DEADLOCK_PRIORITY { LOW | NORMAL | @deadlock_var }

WHERE:

Low tells SQL Server that the current session should be the preferred deadlock victim, not the session that incurs the least amount of rollback resources. The standard deadlock error message 1205 is returned.

Normal tells SQL Server to use the default deadlock method.

@deadlock_var is a character variable specifying which deadlock method you want to use. Specify "3" for low, or "6" for normal.

This command is set a runtime for a specified user connection. [2000] Updated 9-1-2005

*****

To help identify deadlock problems, use the SQL Server Profiler's Create Trace Wizard to run the "Identify The Cause of a Deadlock" trace. This will provide you with the raw data you need to help isolate the causes of deadlocks in your databases.   [7.0]

*****

Consider turning on SQL Server deadlock tracing in order to track deadlocks, when you are having deadlock-related issues. The overhead for doing this is minimal.

DBCC TRACEON (3605,1204,-1)

Once this is run, then all deadlocking activity will be written to the SQL Server log file. [7.0, 2000] Updated 11-6-2006

*****

To help identify which tables or stored procedures are causing deadlock problems, turn on trace flag 1204 (outputs basic trace data) or trace flag 1205 (outputs more detailed trace data). Be sure to turn off this trace flag when you are done, as this trace can eat up SQL Server's resources unnecessarily, hurting performance. [6.5, 7.0, 2000] Updated 11-6-2006

*****

Ideally, deadlocks should be eliminated from your applications. But if you are unable to eliminate all deadlocks in your application, be sure to include program logic in your application to deal with killed transactions in a user-friendly way.

For example, let's say that two transactions are deadlocked and that SQL Server kills one of the transactions. In this case, SQL Server will raise an error message that your application needs to respond to. In most cases, you will want your application to wait a random amount of time after the deadlock in order to resubmit the killed transaction to SQL Server.

It is important that there is a random waiting period because it is possible that another contending transaction could also be waiting, and you don't want both contending transactions to wait the same amount of time and then both try to execute at the same time, causing another deadlock.

If your error-trapping code is good, the end user should never know that the deadlock even occurred. [6.5, 7.0, 2000] Updated 9-1-2005

*****

One way to help prevent deadlocks is to use the UPDLOCK optimizer hint. What this hint does is to force SQL Server to use an update lock instead of a shared lock.

A shared lock occurs when your query wants to read a row, but does not want to change it. Shared locks can co-exist with other shared locks, which means that multiple shared locks can exist on the same row, page, or table. A shared lock prevents the locked resource from receiving an exclusive lock, so if another user runs a query that need to UPDATE a row, they will not be able to until all of the shared locks on the row are gone. Once a shared lock is no longer needed by a query that is reading it, it is immediately released.

An update lock is a hybrid between an shared and an exclusive lock. Update locks are used when a query needs to update one or more records, but until the WHERE clause is complete, the query doesn't know which records it needs to UPDATE. So instead of putting an exclusive lock on every record (which reduces concurrency and your application's performance) it places a shared lock on the requisite records, and only when the WHERE clause is completed, are exclusive locks put on the records that need to be UPDATEDed. The shared locks created by an update lock are held until the WHERE clause is completed running, not immediately released after the row is read, as is normal with a shared lock.

So how does using the UPDLOCK hint help to reduce deadlocks? If you force the use of an update lock instead of a shared lock when reading tables, the UPDLOCK hint holds the locks until the end of your statement or transaction. This allows you to read data without blocking other users, and to update data later with the knowledge that the data has not changed since you last read it. This helps to prevent deadlocks because other users can't sneak in and lock a record that you will need before you need it. [6.5, 7.0, 2000] Updated 9-1-2005