sqlserver机制,sqlserver作用

关于Sqlserver数据库 锁机制的小疑问，下种情况是否需要加入锁机制

不需要，就算确实用户同时执行，数据库的操作机制是有队列的，所以不存在并发情况。

锁基本用不到，我反正开发了5年了没用到过。

你要了解死锁发生的情况，一般是用事务的时候可能会碰到死锁，你申请了A资源，锁住了A然后申请B资源，其他人申请了B资源，然后申请A，这样就互不相让，导致A,B资源都不可访问了，不过其他数据我不知道，SQLSERVER发生这种死锁不是一直锁死的，过几分钟就会发现这个死锁，把锁释放掉，2个事务都失败。

相关问答

Q1: sqlserver有哪些安全策略

Microsoft建立了一种既灵活又强大的安全管理机制，它能够对用户访问SQL Server服务器系统和数据库的安全进行全面地管理。按照本文介绍的步骤，你可以为SQL Server 7.0(或2000)构造出一个灵活的、可管理的安全策略，而且它的安全性经得起考验。

一、验证方法选择

本文对验证(authentication)和授权(authorization)这两个概念作不同的解释。验证是指检验用户的身份标识;授权是指 允许用户做些什么。在本文的讨论中，验证过程在用户登录SQL Server的时候出现，授权过程在用户试图访问数据或执行命令的时候出现。

构造安全策略的第一个步骤是确定SQL Server用哪种方式验证用户。SQL Server的验证是把一组帐户、密码与Master数据库Sysxlogins表中的一个清单进行匹配。Windows NT/2000的验证是请求域控制器检查用户身份的合法性。一般地，如果服务器可以访问域控制器，我们应该使用Windows NT/2000验证。域控制器可以是Win2K服务器，也可以是NT服务器。无论在哪种情况下，SQL Server都接收到一个访问标记(Access Token)。访问标记是在验证过程中构造出来的一个特殊列表，其中包含了用户的SID(安全标识号)以及一系列用户所在组的SID。正如本文后面所介绍 的，SQL Server以这些SID为基础授予访问权限。注意，操作系统如何构造访问标记并不重要，SQL Server只使用访问标记中的SID。也就是说，不论你使用SQL Server 2000、SQL Server 7.0、Win2K还是NT进行验证都无关紧要，结果都一样。

如果使用SQL Server验证的登录，它最大的好处是很容易通过Enterprise Manager实现，最大的缺点在于SQL Server验证的登录只对特定的服务器有效，也就是说，在一个多服务器的环境中管理比较困难。使用SQL Server进行验证的第二个重要的缺点是，对于每一个数据库，我们必须分别地为它管理权限。如果某个用户对两个数据库有相同的权限要求，我们必须手工设 置两个数据库的权限，或者编写脚本设置权限。如果用户数量较少，比如25个以下，而且这些用户的权限变化不是很频繁，SQL Server验证的登录或许适用。但是，在几乎所有的其他情况下(有一些例外情况，例如直接管理安全问题的应用)，这种登录方式的管理负担将超过它的优 点。

二、Web环境中的验证

即使最好的安全策略也常常在一种情形前屈服，这种情形就是在Web应用中使用SQL Server的数据。在这种情形下，进行验证的典型方法是把一组SQL Server登录名称和密码嵌入到Web服务器上运行的程序，比如ASP页面或者CGI脚本;然后，由Web服务器负责验证用户，应用程序则使用它自己的 登录帐户(或者是系统管理员sa帐户，或者为了方便起见，使用Sysadmin服务器角色中的登录帐户)为用户访问数据。

这种安排有几个缺点，其中最重要的包括：它不具备对用户在服务器上的活动进行审核的能力，完全依赖于Web应用程序实现用户验证，当SQL Server需要限定用户权限时不同的用户之间不易区别。如果你使用的是IIS 5.0或者IIS 4.0，你可以用四种方法验证用户。第一种方法是为每一个网站和每一个虚拟目录创建一个匿名用户的NT帐户。此后，所有应用程序登录SQL Server时都使用该安全环境。我们可以通过授予NT匿名帐户合适的权限，改进审核和验证功能。

第二种方法是让所有网站使用Basic验证。此时，只有当用户在对话框中输入了合法的帐户和密码，IIS才会允许他们访问页面。IIS依靠一个NT 安全数据库实现登录身份验证，NT安全数据库既可以在本地服务器上，也可以在域控制器上。当用户运行一个访问SQL Server数据库的程序或者脚本时，IIS把用户为了浏览页面而提供的身份信息发送给服务器。如果你使用这种方法，应该记住：在通常情况下，浏览器与服 务器之间的密码传送一般是不加密的，对于那些使用Basic验证而安全又很重要的网站，你必须实现SSL(Secure Sockets Layer，安全套接字层)。

在客户端只使用IE 5.0、IE 4.0、IE 3.0浏览器的情况下，你可以使用第三种验证方法。你可以在Web网站上和虚拟目录上都启用NT验证。IE会把用户登录计算机的身份信息发送给IIS，当 该用户试图登录SQL Server时IIS就使用这些登录信息。使用这种简化的方法时，我们可以在一个远程网站的域上对用户身份进行验证(该远程网站登录到一个与运行着Web 服务器的域有着信任关系的域)。

最后，如果用户都有个人数字证书，你可以把那些证书映射到本地域的NT帐户上。个人数字证书与服务器数字证书以同样的技术为基础，它证明用户身份标 识的合法性，所以可以取代NT的Challenge/Response(质询/回应)验证算法。Netscape和IE都自动在每一个页面请求中把证书信 息发送给IIS。IIS提供了一个让管理员把证书映射到NT帐户的工具。因此，我们可以用数字证书取代通常的提供帐户名字和密码的登录过程。

由此可见，通过NT帐户验证用户时我们可以使用多种实现方法。即使当用户通过IIS跨越Internet连接SQL Server时，选择仍旧存在。因此，你应该把NT验证作为首选的用户身份验证办法。

三、设置全局组

构造安全策略的下一个步骤是确定用户应该属于什么组。通常，每一个组织或应用程序的用户都可以按照他们对数据的特定访问要求分成许多类别。例如，会 计应用软件的用户一般包括：数据输入操作员，数据输入管理员，报表编写员，会计师，审计员，财务经理等。每一组用户都有不同的数据库访问要求。

Q2: sqlserver锁表机制

这个问题要具体分析：

第一，事务隔离级别基本两种模式，一种是阻塞式（read committed，repeatable read，serializable）

，一种是非阻塞式(read uncommitted,snapshot)。

默认是read committed，这种情况一般在更新表的时候，如果不使用hint 提示，基本是先对表添加IX锁，级别不算高，基本和其他锁兼容，但是repeatable read，serializable 事务隔离级别就会先对表添加IX锁，然后向X锁转化，而X锁和大多数锁都不兼容，容易发生表阻塞。

第二种隔离级别不会有以上问题，但是又引入了其它的问题。

以上是一种情况。

另外一种就是 锁升级，一个锁是96B内存，如果太多，sqlserver就会升级为表锁，一般是5000以上行级锁就升级为一个表X锁。

所以适当的文件分组和表分区 是有必要的。

其次就是资源互相引用导致事务长时间不能释放，导致真正的死锁，不过SQL2005以后，这种情况发生的概率很低。

留个问题你自己去想。

两个SQL，两个连接，同时执行。

update A set A.NAME=xxx where A.id=55

update A set A.NAME=xxx where A.id=56, 如果 56 不存在你说会发生什么情况呢？