数据库管理员（DBA）的一项基本的技能是对SQL数据库引擎的系统数据库的深刻理解。数据库开发人员了解SQL SERVER自带的系统数据库也是十分有用的。下面就列出了其中的一些系统数据库。（注：如果你决定研究一下这些系统数据库，那么你需要有一个开发数据库。）
Master
Master数据库保存有放在SQL SERVER实体上的所有数据库，它还是将引擎固定起来的粘合剂。由于如果不使用主数据库，SQL SERVER就不能启动，所以你必须要小心地管理好这个数据库。因此，对这个数据库进行常规备份是十分必要的。
这个数据库包括了诸如系统登录、配置设置、已连接的SERVER等信息，以及用于该实体的其他系统和用户数据库的一般信息。主数据库还存有扩展存储过程，它能够访问外部进程，从而让你能够与磁盘子系统和系统API调用等特性交互。这些过程一般都用像C 这样的现代编程语言。
如果不幸碰到系统崩溃而必须恢复主数据库的情况，你可以参看MCSE/MCDBA Steven Warren在TechRepublic上发表的文章。这篇文章讲得十分透彻，它解释了恢复这一重要数据库所需要的一些特殊步骤。
Model
Model是一个用来在实体上创建新用户数据库的模版数据库。你可以把任何存储过程、视图、用户等放在模型数据库里，这样在创建新数据库的时候，新数据库就会包含你放在模型数据库里的所有对象了。
Tempdb
正如其名字所提示的，tempdb存有临时对象，例如全局和本地临时表格和存储过程。
这个数据库在SQL SERVER每次重启的时候都会被重新创建，而其中包含的对象是依据模型数据库里定义的对象被创建的。除了这些对象，tempdb还存有其他对象，例如表格变量、来自表格值函数的结果集，以及临时表格变量。由于tempdb会保留SQL SERVER实体上所有数据库的这些对象类型，所以对数据库进行优化配置是非常重要的。
在SQL Server 2005里，tempdb数据库还有一项额外的任务；它还被用作一些特性的版本库，例如新的快照隔离层和在线索引操作等。关于新的隔离层的简要说明，请参考我关于SQL Server 2005高级特性的文章。
Distribution
当你的SQL SERVER实体被配置为复制分发SERVER时，这个数据库就会被添加到你的系统里。在默认情况下，数据库的名字就是distribution,但是你可以更改它的名字。这个数据库用来保存历史和快照、合并和事务复制等的元数据。
Msdb
Msdb数据库用来保存于数据库备份、SQL Agent信息、DTS程序包、SQL SERVER任务等信息，以及诸如日志转移这
样的复制信息。
结束语
在过去几年里，我发现理解SQL SERVER的最佳方法是研究系统数据库的工作原理。作为一条普遍的规律，我不建议你直接在SQL SERVER里查询系统表格；但是通过研究这些系统数据库里的表格，你可以学习到很多关于SQL SERVER工作原理的知识。
数据库工程师阐述死锁产生的原因
死锁产生的主要原因 是对共享资源的分配不当或者推进过程不当，从而引起无限期的等待。
死锁产生的四个必要条件：
互斥条件（Mutual exclusion）：资源不能被共享，只能由一个进程使用。
请求与保持条件（Hold and wait）：已经得到资源的进程可以再次申请新的资源。
非剥夺条件（No pre-emption）：已经分配的资源不能从相应的进程中被强制地剥夺。
循环等待条件（Circular wait）：系统中若干进程组成环路，改环路中每个进程都在等待相邻进程正占用的资源。
死锁解决策略：
分为发生前的预防和发生后的检测恢复，如下
1.忽略该问题。例如鸵鸟算法，该算法可以应用在极少发生死锁的的情况下。为什么叫鸵鸟算法呢，因为传说中鸵鸟看到危险就把头埋在地底下，可能鸵鸟觉得看不到危险也就没危险了吧。跟掩耳盗铃有点像。
2.检测死锁并且恢复。
3.仔细地对资源进行动态分配，以避免死锁。
4.通过破除死锁四个必要条件之一，来防止死锁产生。
oracle数据库具有检测并恢复死锁的功能
**************************************************************************
其实所有的死锁最深层的原因就是一个：资源竞争
表现一：
一个用户A 访问表A（锁住了表A），然后又访问表B,另一个用户B 访问表B（锁住了表B），然后企图访问表A,这时用户A由于用户B已经锁住表B,它必须等待用户B释放表B,才能继续，好了他老人家就只好老老实实在这等了，同样用户B要等用户A释放表A才能继续这就死锁了。
解决方法：
这种死锁是由于你的程序的BUG产生的，除了调整你的程序的逻辑别无他法。
仔细分析你程序的逻辑：
1:尽量避免同时锁定两个资源。
2: 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源。
表现二：
用户A读一条纪录，然后修改该条纪录。这是用户B修改该条纪录，这里用户A的事务里锁的性质由共享锁企图上升到独占锁（for update），而用户B里的独占锁由于A有共享锁存在所以必须等A释放掉共享锁，而A由于B的独占锁而无法上升
的独占锁也就不可能释放共享锁，于是出现了死锁。
这种死锁比较隐蔽，但其实在稍大点的项目中经常发生。
解决方法：
让用户A的事务（即先读后写类型的操作），在select 时就是用Update lock
语法如下：
select
*
from table1 with（updlock） where …
***********************************
数据库系统工程师浅析数据库镜像
自从SQL Server 2000以来，你已经能够通过使用复制来创建一个备用的服务器、传输日志，以及备份和重新存储了--但是现在微软又引入了一个内建的工具，它可以实现自动的错误恢复。数据库镜像是SQL Server 2005的一个新特性，它允许你将一个SQL Server中的数据库内容镜像到另一个SQL Server上。它还让你可以在发生错误的时候，通过镜像数据库来进行错误恢复。
Edgewood Solutions 的Greg Robidoux 回答了我们一些SQL Server 2005中有关数据库镜像的常见问题，同时还解释了为什么你现在就应该开始测试这个内建的功能来看看它最终是否会给你的环境带来好处。
什么是数据库镜像？
Robidoux:数据库镜像是将数据库事务处理从一个SQL Server数据库移动到不同SQL Server环境中的另一个SQL Server数据库中。镜像的拷贝是一个备用的拷贝，不能直接访问；它只用在错误恢复的情况下。
因为是在SQL Server 2005中新引入的特性，这个功能只能用在，这个版本的软件中。在某种程度上说，它是复制和日志传输的混合体：你所有的事物都在事物级别（复制）上移动（日志传输）到你的数据库的一个镜像拷贝上，同时减少了你在实现日志传输或者复制的时候可能会面临的问题。
复制包括大量的移动部分，并且如果你的数据库计划经常改变的话，要保证你的复制运行得流畅也是困难重重。对于日志传输，为了保证同步，同样需要实现很多的处理，例如创建备份、拷贝备份，以及备份重存。如果有一个进程崩溃了，整个处理过程就崩溃了。
数据库镜像的工作方式是什么？
Robidoux：要进行数据库镜像所需的最小需求包括了两个不同的SQL Server运行环境。主服务器被称为“基本的”，第二个服务器被称作“镜像的”.基本数据库就是你实际用着的数据库，镜像数据库就是你的数据库的备用拷贝。当事务写入你的基本服务器的时候，他们也同样被传送到并写入你的镜像数据库中。
除了基本和镜像之外，你还可以引入另一个可选的组件，名为“证人”。证人数据库是第三个SQL Server 2005运行实例，它是在判断什么时候进行错误恢复的时候，用于基本和镜像之间内部交
流。只有当你想实现自动错误恢复的时候用到这个选项。它实现了2比1投票的能力，当我的一个组件不可达，并因此需要进行错误恢复的时候。证人服务器只有在你想实现自动错误恢复的时候才需要用到。
实现的方式是什么？
Robidoux :数据库镜像提供了三种实现的方式。根据你想要用什么方式来进行错误恢复处理来进行选择。
高可用性：这个操作模式选项允许你在两台服务器上同步事务写入，并支持自动错误恢复。要使用这个选项，你必须还要使用一个证人服务器。
高保护：这个选项可以让你在两台服务器上同步事物写入，但是错误恢复是手工的。因为自动的错误恢复不是这个选项的一部分，所以也不会用到证人服务器。
高性能：这个选项不关心两台服务器上的写入是否是同步的，因此在性能上有所提高。当使用这个选项的时候，你只能假设镜像服务器上的所有事情都是成功完成。这个选项只允许手工的错误恢复，因此不会用到证人服务器。
时刻记住将你的数据自动恢复到第二个拷贝才是数据库镜像的真正好处。因此，大多数的实现可能都是使用的高可达性方式。其他的选项仍然提供了内建的错误恢复过程，但是前提是你在发生错误的时候对进行自动的错误恢复怀有极大的兴趣。
数据库镜像可以工作在哪几个版本上？
Robidoux :数据库镜像只能在标准版、开发版和企业版的SQL Server 2005中找到。基本服务器和镜像服务器的SQL Server运行实例都需要是这几个版本。证人服务器可以运行在任何版本的SQL Server上。此外，还有其他的一些特性是SQL Server的开发版和企业版上特有的，但是标准版具有最基本的功能。
总结
现如今，SQL Server 2005的数据库镜像已经关掉了，但是所有的功能仍然存在。数据库镜像可以通过使用检索标志来打开--但是微软现在并不支持这个功能了，所以不要在你的产品环境中运行它。数据库镜像将会在本年年末完全实现并被支持。
要打开这个特性并开始你的测试，你可以看看以前的专家知识解答。微软正在寻找额外的反馈，所以你可以看看它是否可以作为你的SQL Server环境的候选。