SQL环境中的状态62错误.docVIP

SQL 环境下的状态62 随着越来越多的用户将四班迁移到四班SQL环境，状态62的问题也有所增加。这样我们就有了3个疑问：是什么引发状态62的错误？如何处理状态62的错误？如何避免以后发生？ 是什么引发状态62的错误？ 四班应用程序会在3分钟之内向数据库提交业务。如果3分钟后业务没有成功的被提交到数据库，则此条记录会被回滚，与此同时终端用户用户会遇到状态62错误信息或数据正在使用的信息（通常数据正在使用会立刻显示出来）。数据正在使用的信息一般是指四班数据正在被另一四班应用程序所连接。在SQL环境下的状态62一般表明有一个外部程序在数据库内部产生了数据锁。 如何处理状态62的错误？ 第一步是确认产生锁的应用程序。您可以进入Enterprise Manager,打开SQL Server的Management, Current Activity。在Current Activity中你可以分析是那一个SPID产生了锁。一旦找到了产生锁的SIPD, 您可以用Process Info确定了是那个客户端用户帐号正在执行加锁的程序，而且有些时候Process Info可以判断出是那个应用程序（例如微软OFFICE程序）。此时你可以到有问题的客户端关闭产生锁的应用程序。你将为后面的问题答案保留应用程序产生锁的信息。注意Current Activity的数据不会自动刷新。 如果你不能确认锁的产生原因，你可以重新启动SQL Server服务来清除锁。有很多人会问“为什么不直接启动四班服务？”由于锁是来自通过SQL Server的外部程序产生的，重启四班的服务不能解决问题。 如何将来避免出现此问题？ 此问题的答案主要取决于哪个程序产生锁和此程序的作用。以下是您可以尝试的建议列表，但是此建议主要基于您的业务流程和数据使用情况而定，在这里没有所谓的“正确地答案”。以下的示例主要是针对两个应用程序，用户在使用外部程序总时产生四班数据库的锁。这两个程序为Microsoft Access (mdb格式) 和 Crystal Reports。请注意他们不是唯一使数据库产生锁的应用程序。 建议一：如果您所产生的报告只使用一次，例如在标准的四班模板中修改订单提料单或订单确认，则在打印预览中会遇到未知的锁。这种情况，用户可以采用“脏读”数据库的方式。您可以在SELECT语句中加入WITH(NOLOCK)或在查询语句中使用READ UNCOMMITTED。记住请永远不要修改四班已安装的VIEW。如果想在视图中加入READ UNCOMMITED，则需要在四班数据库中创建新的视图，在新视图中加入对锁的限制。更多关于如何使用NOLOCK或READ UNCOMMITTED请参考SQL的在线帮助文件。 建议二：如果您使用Microsoft Access数据库来恢复数据，您可以将Microsoft Access数据库升级为SQL数据库。您可以使用Microsoft Access（2000或更高的版本）做为数据库界面的工具，或者如果现在已经是SQL数据库，可以提供给终端用户SQL客户端工具。Microsoft Access Data Project的所见即所得的特点，使用户可以熟练的使用报告功能。当Access Data Project作为它连接的SQL数据库的界面时，对SQL的数据库设置权限（包括四班的数据库）是非常重要的。尽管此建议需要在初始安装时多花些时间，但是对于ACCESS/SQL的整合是长久的解决方案。 建议三：如果您不需要实时更新数据，用户可以使用DTS数据包在无人使用四班数据库的非工作时段还原数据。您也可以在有业务处理时做DTS，不过要注意上传数据的速度和类型，以免造成不必要的锁，所以在DTS执行语句中尽量使用READ UNCOMMITTED或 WITH (NOLOCK)的语句。 建议四：创建一个“临时性”的SQL数据库。这种方法在几年曾被四班的用户使用，而且迅速的变为最简单有效的绕过应用程序连接没有脏读方式的四班SQL数据库的问题。执行过程需要大约一小时，所以可以使您快速解决应用程序产生的问题，表级别的锁要优于行记录级别的锁。以下内容描述了如何创建此结构，但协助创建或排除由此引发的问题并不在支持服务部的支持范围之内。协助创建此结构为收费项目。 对于架构的操作应该遵循：当应用程序连接在SQL数据库产生了表级别的锁，这是一个在表上建立的“硬锁”，数据会重新恢复。当SQL从其它SQL 数据库通过默认方式恢复数据时，会使用行记录锁。假设我们设置一个“过滤锁的数据库”（范例中我们把它叫做“过程数据库”）我们就可以避免对四班的表产生加锁现象。 这个过程数据库可以当作FSDBMR和ENDUSER.MDB之间的过滤器。假设ENDUSER.MDB通过FSDBMRDSN连接到FSDBM