搜索
提纲：1、SQLServer锁的概念2、SQLServer事物概念3、解决数据库异常膨胀的技术思路4、操作系统崩溃后数据库重新安装的流程5、数据库性能优化6、常见的SQLServer连接失败错误及解决方法7、无法合理使用已建立的索引的错误写法8、常见系统函数9、编写可读性强的代码1.SQLServer锁的概念1.1锁定MicrosoftSQLServer使用锁定确保事务完整性和数据库一致性。锁定可以防止用户读取正在由其他用户更改的数据，并可以防止多个用户同时更改相同数据。如果不使用锁定，则数据库中的数据可能在逻辑上不正确，并且对数据的查询可能会产生意想不到的结果。虽然SQLServer自动强制锁定，但可以通过了解锁定并在应用程序中自定义锁定来设计更有效的应用程序1.2并发问题如果没有锁定且多个用户同时访问一个数据库，则当他们的事务同时使用相同的数据时可能会发生问题。并发问题包括：丢失或覆盖更新。未确认的相关性（脏读）。不一致的分析（非重复读）。幻像读。1.2.1丢失更新当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。例如，两个编辑人员制作了同一文档的电子复本。每个编辑人员独立地更改其复本，然后保存更改后的复本，这样就覆盖了原始文档。最后保存其更改复本的编辑人员覆盖了第一个编辑人员所做的更改。如果在第一个编辑人员完成之后第二个编辑人员才能进行更改，则可以避免该问题。1.2.2未确认的相关性（脏读）当第二个事务选择其它事务正在更新的行时，会发生未确认的相关性问题。第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。例如，一个编辑人员正在更改电子文档。在更改过程中，另一个编辑人员复制了该文档（该复本包含到目前为止所做的全部更改）并将其分发给预期的用户。此后，第一个编辑人员认为目前所做的更改是错误的，于是删除了所做的编辑并保存了文档。分发给用户的文档包含不再存在的编辑内容，并且这些编辑内容应认为从未存在过。如果在第一个编辑人员确定最终更改前任何人都不能读取更改的文档，则可以避免该问题。1.2.3不一致的分析（非重复读）当第二个事务多次访问同一行而且每次读取不同的数据时，会发生不一致的分析问题。不一致的分析与未确认的相关性类似，因为其它事务也是正在更改第二个事务正在读取的数据。然而，在不一致的分析中，第二个事务读取的数据是由已进行了更改的事务提交的。而且，不一致的分析涉及多次（两次或更多）读取同一行，而且每次信息都由其它事务更改；因而该行被非重复读取。例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题。1.2.4幻像读当对某行执行插入或删除操作，而该行属于某个事务正在读取的行的范围时，会发生幻像读问题。事务第一次读的行范围显示出其中一行已不复存在于第二次读或后续读中，因为该行已被其它事务删除。同样，由于其它事务的插入操作，事务的第二次或后续读显示有一行已不存在于原始读中。例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。1.3隔离级别当锁定用作并发控制机制时，它可以解决并发问题。这使所有事务得以在彼此完全隔离的环境中运行，但是任何时候都可以有多个正在运行的事务。可串行性是通过运行一组并发事务达到的数据库状态，等同于这组事务按某种顺序连续执行时所达到的数据库状态。SQL-92隔离级别尽管可串行性对于事务确保数据库中的数据在所有时间内的正确性相当重要，然而许多事务并不总是要求完全的隔离。例如，多个作者工作于同一本书的不同章节。新章节可以在任意时候提交到项目中。但是，对于已经编辑过的章节，没有编辑人员的批准，作者不能对此章节进行任何更改。这样，尽管有未编辑的新章节，但编辑人员仍可以确保在任意时间该书籍项目的正确性。编辑人员可以查看以前编辑的章节以及最近提交的章节。事务准备接受不一致数据的级别称为隔离级别。隔离级别是一个事务必须与其它事务进行隔离的程度。较低的隔离级别可以增加并发，但代价是降低数据的正确性。相反，较高的隔离级别可以确保数据的正确性，但可能对并发产生负面影响。应用程序要求的隔离级别确定了SQLServer使用的锁定行为。SQL-92定义了下列四种隔离级别，SQLServer支持所有这些隔离级别：未提交读（事务隔离的最低级别，仅可保证不读取物理损坏的数据）。提交读（SQLServer默认级别）。可重复读。可串行读（事务隔离的最高级别，事务之间完全隔离）。如果事务在可串行读隔离级别上运行，则可以保证任何并发重叠事务均是串行的。下面四种隔离级别允许不同类型的行为。隔离级别脏读不可重复读取幻像未提交读是是是提交读否是是可重复读否否是可串行读否否否事务必须运行于可重复读或更高的隔离级别以防止丢失更新。当两个事务检索相同的行，然后基于原检索的值对行进行更新时，会发生丢失更新。如果两个事务使用一个UPDATE语句更新行，并且不基于以前检索的值进行更新，则在默认的提交读隔离级别不会发生丢失更新。1.4SQLServer中的锁定介绍Microsoft®SQLServer™2000具有多粒度锁定，允许一个事务锁定不同类型的资源。为了使锁定的成本减至最少，SQLServer自动将资源锁定在适合任务的级别。锁定在较小的粒度（例如行）可以增加并发但需要较大的开销，因为如果锁定了许多行，则需要控制更多的锁。锁定在较大的粒度（例如表）就并发而言是相当昂贵的，因为锁定整个表限制了其它事务对表中任意部分进行访问，但要求的开销较低，因为需要维护的锁较少。SQLServer可以锁定以下资源（按粒度增加的顺序列出）。资源描述RID行标识符。用于单独锁定表中的一行。键索引中的行锁。用于保护可串行事务中的键范围。页8千字节(KB)的数据页或索引页。扩展盘区相邻的八个数据页或索引页构成的一组。表包括所有数据和索引在内的整个表。DB数据库。SQLServer使用不同的锁模式锁定资源，这些锁模式确定了并发事务访问资源的方式。SQLServer使用以下资源锁模式。锁模式描述共享(S)用于不更改或不更新数据的操作（只读操作），如SELECT语句。更新(U)用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。排它(X)用于数据修改操作，例如INSERT、UPDATE或DELETE。确保不会同时对同一资源进行多重更新。意向用于建立锁的层次结构。意向锁的类型为：意向共享(IS)、意向排它(IX)以及与意向排它共享(SIX)。架构在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改(Sch-M)和架构稳定性(Sch-S)。大容量更新(BU)向表中大容量复制数据并指定了TABLOCK提示时使用。共享锁共享(S)锁允许并发事务读取(SELECT)一个资源。资源上存在共享(S)锁时，任何其它事务都不能修改数据。一旦已经读取数据，便立即释放资源上的共享(S)锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务生存周期内用锁定提示保留共享(S)锁。更新锁更新(U)锁可以防止通常形式的死锁。一般更新模式由一个事务组成，此事务读取记录，获取资源（页或行）的共享(S)锁，然后修改行，此操作要求锁转换为排它(X)锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排它(X)锁。共享模式到排它锁的转换必须等待一段时间，因为一个事务的排它锁与其它事务的共享模式锁不兼容；发生锁等待。第二个事务试图获取排它(X)锁以进行更新。由于两个事务都要转换为排它(X)锁，并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。若要避免这种潜在的死锁问题，请使用更新(U)锁。一次只有一个事务可以获得资源的更新(U)锁。如果事务修改资源，则更新(U)锁转换为排它(X)锁。否则，锁转换为共享锁。排它锁排它(X)锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它(X)锁锁定的数据。意向锁意向锁表示SQLServer需要在层次结构中的某些底层资源上获取共享(S)锁或排它(X)锁。例如，放置在表级的共享意向锁表示事务打算在表中的页或行上放置共享(S)锁。在表级设置意向锁可防止另一个事务随后在包含那一页的表上获取排它(X)锁。意向锁可以提高性能，因为SQLServer仅在表级检查意向锁来确定事务是否可以安全地获取该表上的锁。而无须检查表中的每行或每页上的锁以确定事务是否可以锁定整个表。意向锁包括意向共享(IS)、意向排它(IX)以及与意向排它共享(SIX)。锁模式描述意向共享(IS)通过在各资源上放置S锁，表明事务的意向是读取层次结构中的部分（而不是全部）底层资源。意向排它(IX)通过在各资源上放置X锁，表明事务的意向是修改层次结构中的部分（而不是全部）底层资源。IX是IS的超集。与意向排它共享(SIX)通过在各资源上放置IX锁，表明事务的意向是读取层次结构中的全部底层资源并修改部分（而不是全部）底层资源。允许顶层资源上的并发IS锁。例如，表的SIX锁在表上放置一个SIX锁（允许并发IS锁），在当前所修改页上放置IX锁（在已修改行上放置X锁）。虽然每个资源在一段时间内只能有一个SIX锁，以防止其它事务对资源进行更新，但是其它事务可以通过获取表级的IS锁来读取层次结构中的底层资源。架构锁执行表的数据定义语言(DDL)操作（例如添加列或除去表）时使用架构修改(Sch-M)锁。当编译查询时，使用架构稳定性(Sch-S)锁。架构稳定性(Sch-S)锁不阻塞任何事务锁，包括排它(X)锁。因此在编译查询时，其它事务（包括在表上有排它(X)锁的事务）都能继续运行。但不能在表上执行DDL操作。大容量更新锁当将数据大容量复制到表，且指定了TABLOCK提示或者使用sp_tableoption设置了tablelockonbulk表选项时，将使用大容量更新(BU)锁。大容量更新(BU)锁允许进程将数据并发地大容量复制到同一表，同时防止其它不进行大容量复制数据的进程访问该表。1.5阻塞任何基于锁的并发系统都有可能在某种情况下发生阻塞。当一个连接控制了一个锁，而另一个连接需要冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，而在第一个连接上阻塞。不管是来自同一应用程序还是另外一台客户机上单独的应用程序，一个连接都可以阻塞另另一个连接。大多数阻塞问题的发生是因为一个进程控制锁的时间过长，导致阻塞的进程链都在其他进程上等待锁。常见的阻塞情形如下：(1)提交执行的时间长的查询长时间运行的查询会阻塞其它查询。例如，影响很多行的DELETE或UPDATE操作能获取很多锁，这些锁不论是否升级到表锁都堵塞其它查询。因此，一般不要将长时间运行的决策支持查询和联机事物处理（OLTP）查询混在一起。解决方案是想办法优化查询，如更改索引、将大的复杂查询分成简单的查询或在空闲时间或单独的计算机运行查询。（2）取消没有提交或回滚的查询如果应用程序取消查询（如采用ODBC的SQLCANCEL函数），但没有同时发出所需数目的ROLLBACK和commit语句，则会发生这种情况。取消查询并不自动回滚偶或提交事物。取消查询后，所有在事物内获取的锁都将保留。应用程序必须提交或回滚已取消的事物，从而正确地管理事物嵌套。（3）应用程序没处理完所有结果将查询发送到服务器后，所用应用程序必须理解完成提取所用结果行的过程。如果应用程序没有提取所用结果行，锁可能会留在表上而阻塞其它用户。如果使用的应用程序将Transact-SQL语句透明地提交给服务器，则该应用程序必须提取所用结果行。如果应用程序没这样做，则可能无法解决阻