游戏公司在招聘哪些 DBA ？

wghao

不错，好长，得慢慢看。

liyihongcug

JOIN方法说明 性能优化的天堂和地狱
作者: RicCC, 　出处:cnblogs,　责任编辑: 叶江,　2007-07-03 14:50
　　在各个论坛看到很多朋友对数据库的理解、认识还是没有突破一个瓶颈，而这个瓶颈往往只是一层窗纸，越过了你将看到一个新世界
　　04、05年做项目的时候，用SQL Server 2000，核心表(大部分使用频繁的关键功能每次都要用到)达到了800万数据量，很早以前查过一些相关表，有的达到了3000多万，磁盘使用的光纤盘，100G空间，每周必须备份转移数据，否则100G空间一周会满掉，这个系统几年来，目前仍然保持非常良好的性能。还听说过朋友的SQL Server 2000数据库工作在几十TB的环境下，高并发量，对这种级别的驾驭能力我还是差的很遥远。

　　想当年，也是一提SQL Server，就觉得它的性能没法跟Oracle相比，一提到大数据处理就想到Oracle。自己一路走来，在本地blog上记录了很多优化方面的post，对的错的都有，没有时间系列的整理出来，这篇文章将join方法的概念稍微整理在一起，给大家个参考。通过查资料了解里面提到的各种概念，在实际中不断验证总结，完全可以对数据库一步步深入理解下去的。

　　我只对SQL Server 2000比较了解，但这并不阻碍我在Oracle、MySql进行SQL调优、产品架构，因为在数据库理论原理上，各大数据库基本出入不大，对数据库的深入理解，也不会影响你架构设计思想变坏，相反给你带来的是更深层次的思考。

　　关于执行计划的说明

　　在SQL Server查询分析器的Query菜单中选择Show Execution Plan，运行SQL查询语句，在结果窗口中有Grid、Execution Plan、Messages三个Tab。看图形形式的执行计划，顺序是从右到左，这也是执行的顺序。执行计划中的每一个图标表示一个操作，每一个操作都会有一个或多个输入，也会有一个或多个输出。输入和输出，有可能是一个物理数据表、索引数据结构，或者是执行过程中的一些中间结果集/数据结构。鼠标移动到图标上，会显示这个操作的具体信息，例如逻辑和物理操作名称、记录的数量和大小、I/O成本、CPU成本、操作的具体表达式(参数Argument)。鼠标移动到连接箭头上，会显示箭头起始端的操作输出结果集的记录数、记录的大小，一般情况下可以将这个输出结果集理解为箭头结束端的输入。

　　另外关于执行计划的一些补充说明：1. 执行计划中显示的信息，都是一个“评估”的结果，不是100%准确的信息，例如记录数量是取自统计信息，I/O成本、CPU成本来自执行计划生成过程中基于统计信息等得出的评估结果。2. 执行计划不一定准确，一方面受SQL Server维护的统计信息准确性的影响，另一方面SQL语句编译时刻与执行时刻的环境(内存使用状况、CPU状况等)可能会不一样。

　　关于统计信息、I/O成本和CPU成本的评估、SQL语句的编译和执行过程，这里不再深入。另外尽管执行计划不一定准确，但它仍是SQL语句分析最重要的依据，因为你可以理解为，绝大部分情况下，SQL Server是以这种方式来执行的。

　　JOIN方法说明

　　数据库中，象tableA inner join tableB、tableA left out join tableB这样的SQL语句是如何执行join操作的?就是说SQL Server使用什么算法实现两个表数据的join操作?

　　SQL Server 2000有三种方式：nested loop、merge、hash。Oracle也是使用这三种方式，不过Oracle选择使用nested loop的条件跟SQL Server有点差别，内存管理机制跟SQL Server不一样，因此查看执行计划，Oracle中nested loop运用非常多，而merge和hash方式相对较少，SQL Server中，merge跟hash方式则是非常普遍。

　　以SQL Server 2000为例对这三种方式进行说明，穿插在里面讲解执行计划的一些初级使用。

　　1. nested loop join

　　1.1 示例SQL

　　select ... from tableA inner join tableB on tableA.col1=tableB.col1 where tableA.col2=? and tableB.col2=?

　　tableA中没有建立任何索引，tableB中在col1上有建立一个主键(聚集索引)。
　在各个论坛看到很多朋友对数据库的理解、认识还是没有突破一个瓶颈，而这个瓶颈往往只是一层窗纸，越过了你将看到一个新世界

　　1.2 算法伪代码描述

    foreach rowA in tableA where tableA.col2=?
    {
    search rowsB from tableB where tableB.col1=rowA.col1 and tableB.col2=? ;
    if(rowsB.Count<=0)
        discard rowA ;
    else
        output rowA and rowsB ;
    }


　　join操作有两个输入，上面例子中tableA是outer input，用于外层循环;tableB是inner input，用于循环内部。下面针对执行计划描述一下SQL Server完成这个操作的具体步骤。

　　1.3 查看执行计划方法 移到文章最前面。

　　1.4 执行步骤

　　下面是示例SQL的执行计划图。nested loop操作的右边，位于上面的是outer input，位于下面的是inner input。你不能够根据join中哪个表出现在前面来确定outer input和inner input关系，而必须从执行计划中来确定，因为SQL Server会自动选择哪个作为inner input。



　　a) 对tableA执行Table Scan操作。这个操作的输入是tableA表中的数据，这些数据位于磁盘上，操作过程中被加载到内存;输出是符合条件的记录集，将作为b)的outer input。在这个操作中，tableA.col1=?的条件会被使用。

　　b) 执行上面伪代码描述的nested loop操作。对a)中的每个输出记录，执行步骤c)。

　　c) 对tableB执行Clustered Index Seek操作。这个操作是在nested loop循环里面执行的，输入是tableB表的聚集索引数据。它使用tableB.col1=rowA.col1和tableB.col2=?这两个条件，从tableB的聚集索引中选择符合条件的结果。

　　d) 构造返回结果集。从nested loop的输出中，整理出select中指定的字段，构造最终输出结果集。
1.5 进阶说明

　　上面例子对inner input使用的是聚集索引，下面看一下非聚集索引的情况，加强对执行计划的理解、分析能力。

　　把tableB col1上的主键修改为非聚集方式，示例的SQL语句执行计划如下：



　　前面三个执行步骤a)、b)、c)跟1.4中一样，有一点需要注意的是，步骤c)是执行Index Seek操作，它跟Clustered Index Seek有区别。聚集索引的根节点是每一条实际数据记录，而非聚集索引的根节点是对聚集索引根结点键值的引用(如果表存在聚集索引)，或者是对实际数据记录rowid的引用(指没有聚集索引的表，这种表称为heap表)。Clustered Index Seek执行之后，实际的物理数据记录已经被加载到内存中，而Index Seek操作之后，并没有加载实际的物理数据记录，而只是非聚集索引的根结点数据，其中只包含了索引字段数据以及引用的聚集索引键值或者rowid。SQL Server在这个步骤中使用非聚集索引根结点数据中的索引字段值，与outer input中的记录(rowA)关联字段进行匹配，判断是否是符合条件的结果，如果是，则将非聚集索引根结点数据结构保存到nested loop操作的输出数据结构中，并且会创建一个书签(Bookmark)，指示在必要的时候需要根据这个书签去获取引用的数据。

　　d) 执行Bookmark Lookup操作。nested loop操作的输出是一个内存数据结构，在从这个内存数据结构中整理出整个查询语句的输出结果集之前，需要处理前面的书签引用问题，Bookmark Lookup操作就是根据书签中引用的聚集索引键值或者rowid获取具体记录数据。

　　e) Filter过滤操作。回顾前面几个操作，在执行nested loop时只是使用非聚集索引的索引字段(tableB.col1)跟outer input的关联字段进行匹配，到目前为止还没有使用tableB.col2=?这个条件，这个操作就是使用tableB.col2=?对Bookmark Lookup的输出进行过滤。

　　看的仔细的人到这里后可能会有几个疑问，1. tableA.col2=?怎么没有一个Filter操作?2. 在1.4中为什么没有出现Filter操作?解释如下：1. 在tableA上面执行的是Table Scan操作，是直接对每条实际数据进行扫描，在这个扫描过程中可以使用tableA.col2=?这个条件进行过滤，避免一个额外的Filter操作。鼠标移动到Table Scan操作上，从提示信息的参数(Argument)里面可以看到tableA.col2=?的条件已经被运用上了。2. 前面说过，聚集索引的根节点是实际数据记录，执行Clustered Index Seek的时候，最终也是扫描到了实际数据记录，在这个过程中运用tableB.col2=?这个条件，同样避免一个额外的Filter操作。这就是1.4中没有Filter操作的原因。

　　f) 构造返回结果集。跟1.4步骤d)一样。
1.6 nested loop使用条件

　　任何一个join操作，如果满足nested loop使用条件，查询优化过程中SQL Server就会对nested loop的成本(I/O成本、CPU成本等)进行评估，基于评估结果确定是否使用这种join方式。

　　使用nested loop方式的条件是：a) outer input的记录数不大，最好是在1000-2000以下，一般超过3000就很难说了，基本不大会选择nested loop。b) 作为inner input的表中，有可用于这个查询的索引。

　　这是因为outer input记录数不大，意味着外层循环次数比较小;inner input上有可用的索引，意味着在循环里面搜索inner input表中是否存在匹配的记录时，效率会很高，哪怕inner input表实际记录数有几百万。基于这两个条件，nested loop的执行效率非常高，在三种join方式里面，是内存和CPU消耗最少的一种(不合理的强制指定nested loop方式除外)。

　　关于使用条件另外的说明：outer input的记录数，并不是指outer input表中实际记录数，例如示例SQL中，如果tableA在col2上有维护统计信息(存在col2的索引或者是单独维护的统计信息)，并且tableA.col2=?的条件值符合SARG(可搜索参数)形式，那么查询编译时刻SQL Server就能够利用统计信息和条件值评估出符合条件的记录数，查询执行时刻符合条件tableA.col2=?的记录才被用于外层循环。inner input表中有可用的索引，是指inner input表中用于和outer input表关联的字段(一个或多个字段)能够命中某个索引(这些字段的部分或者全部出现在某个索引字段的前面)。

　　符合上面的条件，也不是说SQL Server 100%就会选择nested loop。因为SQL Server的查询优化器是基于成本评估的，如果其它方案评估出的成本胜过这个，SQL Server会选择其它的join方式。举个例子，如果inner input上符合条件的索引是非聚集索引，这样SQL Server可能需要一个额外的Bookmark Lookup操作获取实际记录数据，如果inner input表数据量非常大，索引碎片程度很高等情况，可能导致Bookmark Lookup成本非常高，SQL Server会尝试其它join方案的评估选择。

　　1.7 强制指定nested loop方式

　　使用loop关键字实现，例如tableA inner loop join tableB，将强制SQL Server使用nested loop方式执行这个join操作。或者使用option选项，例如tableA inner join tableB option(loop join)

　　nested loop算法有它适用的范围，在这个范围之内效率是最高的，超出这个范围效率反而很差，除非你有十分的把握，不要随意强制指定join方式。

　　接下来就不再象上面这样详细的讲述了。

　　2. merge join

　　merge join第一个步骤是确保两个关联表都是按照关联的字段进行排序。如果关联字段有可用的索引，并且排序一致，则可以直接进行merge join操作;否则，SQL Server需要先对关联的表按照关联字段进行一次排序(就是说在merge join前的两个输入上，可能都需要执行一个Sort操作，再进行merge join)。

　　两个表都按照关联字段排序好之后，merge join操作从每个表取一条记录开始匹配，如果符合关联条件，则放入结果集中;否则，将关联字段值较小的记录抛弃，从这条记录对应的表中取下一条记录继续进行匹配，直到整个循环结束。

在多对多的关联表上执行merge join时，通常需要使用临时表进行操作。例如A join B使用merge join时，如果对于关联字段的某一组值，在A和B中都存在多条记录A1、A2...An、B1、B2...Bn，则为A中每一条记录A1、A2...An，都必须在B中对所有相等的记录B1、B2...Bn进行一次匹配。这样，指针需要多次从B1移动到 Bn，每一次都需要读取相应的B1...Bn记录。将B1...Bn的记录预先读出来放入内存临时表中，比从原数据页或磁盘读取要快。

　　merge join操作本身是非常快的，但是merge join前进行的排序可能会相当耗时(SQL Server最消耗内存和CPU的操作，一个是大数据排序，一个是大数据的hash运算，这都是指查询计划里面的Sort以及Hash相关的操作，例如hash join、使用hash算法实现的Distinct操作等，而不是指你的SQL中order by关键字)，尤其是对数据量非常大的记录集，因此导致使用merge join的查询成本变得非常高。对于数据量非常大的表，如果merge join的关联字段可以使用聚集索引，merge join是最快的Join方法之一。因此优化方案是在表结构设计层面良好的设计关联关系和表的索引结构，SQL语句充分利用索引，尽可能减少merge join前的排序操作，减少Bookmark Lookup操作。

　　一般情况下，如果无法满足nested loop条件，会考虑对merge join方法的评估。merge join的选择，主要是考虑两个输入的数据量，以及分别对应于关联字段是否能够命中索引。例如tableA join tableB，关联字段在两个表中都能命中索引，数据量超过了nested loop的选择范围，则会考虑使用merge join方法。当然，如果tableA和tableB的数据量过大导致评估出来的成本过高，则会放弃merge join而评估hash join了。

　　使用inner merge join或者option(merge join)强制使用merge join方法。

　　3. hash join

　　hash join有两个输入：build input(也叫做outer input)和probe input(也叫做inner input)，不仅用于inner/left/right join等，象union/group by等也会使用hash join进行操作，在group by中build input和probe input都是同一个记录集。

　　同nested loop，在执行计划中build input位于上方，probe input位于下方。

　　hash join操作分两个阶段完成：build(构造)阶段和probe(探测)阶段。

　　Build阶段

　　这个阶段主要构造hash table。在inner/left/right join等操作中，表的关联字段作为hash key;在group by操作中，group by的字段作为hash key;在union或其它一些去除重复记录的操作中，hash key包括所有的select字段。

　　Build操作从build input输入中取出每一行记录，将该行记录关联字段的值使用hash函数生成hash值，这个hash值对应到hash table中的hash buckets(哈希表目)。如果一个hash值对应到多个hash buckts，则这些hash buckets使用链表数据结构连接起来。当整个build input的table处理完毕后，build input中的所有记录都被hash table中的hash buckets引用/关联了。

　　Probe阶段

　　在这个阶段，SQL Server从probe input输入中取出每一行记录，同样将该行记录关联字段的值，使用build阶段中相同的hash函数生成hash值，根据这个hash值，从build阶段构造的hash table中搜索对应的hash bucket。hash算法中为了解决冲突，hash bucket可能会链接到其它的hash bucket，probe动作会搜索整个冲突链上的hash bucket，以查找匹配的记录。

　　关于hash算法的细节，可以查看数据结构的一些资料。hash算法主要是用于大数据量的搜索，为了避免每次都象merge join一样在全部的数据中进行搜索匹配，通过合适的 hash函数，先给要搜索的数据根据hash key建立hash值作为索引，在搜索时，先通过hash值定位到一个较小的搜索范围，然后在这个范围中搜索匹配符合条件的结果，以提高效率。

SQL Server将数据量较小的表作为build input，尽量使根据build input构造的hash table能够完全放在内存中，这样probe阶段的匹配操作就完全是在内存中进行，这样的hash join叫做In-Memory Hash Join。

　　如果build input记录数非常大，构建的hash table无法在内存中容纳时，SQL Server分别将build input和probe input切分成多个分区部分(partition)，每个partition都包括一个独立的、成对匹配的build input和probe input，这样就将一个大的hash join切分成多个独立、互相不影响的hash join，每一个分区的hash join都能够在内存中完成。SQL Server将切分后的partition文件保存在磁盘上，每次装载一个分区的build input和probe input到内存中，进行一次hash join。这种hash join叫做Grace Hash Join，使用的Grace Hash Join算法。

　　伴随着大数据的hash join运算，还会有standard external merge sorts、multiple merge levels、multiple partitioning steps、multiple partitioning levels，SQL Server还可能会使用Recursive Hash Join等算法或其它的优化手段。

　　hash join一般都用于大数据量的操作，例如join中某个表的数据达到一定程度或者无法一次加载到内存，另外如果你的关联字段在两个join表中都不能够命中索引，也是使用hash join来处理。因此一般情况下，hahs join处理代价非常高，是数据库服务器内存和CPU的头号杀手之一，尤其是涉及到分区(数据量太大导致内存不够的情况，或者并发访问很高导致当前处理线程无法获得足够的内存，那么数据量不是特大的情况下也可能需要进行分区)，为了尽快的完成所有的分区步骤，将使用大量异步的I/O操作，因此期间单一一个线程就可能导致多个磁盘驱动器出于忙碌状态，这很有可能阻塞其它线程的执行。

　　使用inner hash join或者option (hash join)强制使用hash join方法。

　　建议

　　三种join方法，都是拥有两个输入。优化的基本原则：1. 避免大数据的hash join，尽量将其转化为高效的merge join、nested loop join。可能使用的手段有表结构设计、索引调整设计、SQL优化，以及业务设计优化。例如冗余字段的运用，将统计分析结果用service定期跑到静态表中，适当的冗余表，使用AOP或类似机制同步更新等。2. 尽量减少join两个输入端的数据量。这一点比较常犯的毛病是，条件不符合SARG(光这一点就有很多高超的技巧可以发挥)，在子查询内部条件给的不充分(SQL过于复杂情况下SQL Server查询优化器经常犯傻，写在子查询外部的条件不会被用在子查询内部，影响子查询内部的效率或者是跟子查询再join时候的效率)。另外也是设计、业务端尽量限制这两个输入的数据量了。

　　关于业务设计方面的优化，参考以前写的一篇post：系统分析设计 一个JOIN问题解决方案的感想 重视业务分析设计。

　　补充(2007.06.27)：关于SQL Server 2005

　　大致看了下SQL Server 2005，执行计划的显示确实有一些不一样，但主要部分或者说原理上是差不多的，不会有多少偏差。上面的示例SQL，在tableB上面使用非聚集索引时，SQL Server 2005的执行计划图如下：



　　一个主要的不同点是SQL Server 2000下面Bookmark Lookup操作，在2005下面显示成一个RID Lookup操作 + 一个Nested Loops操作实现，其实这也是很好理解的，可以说这样显示执行计划更合理一点，让你一看到这个操作，就知道它是通过一个循环机制到tableB中获取实际数据。

　　另外一点是，将鼠标移动到执行计划的图标上面后，弹出的提示信息的一些改变，例如2005里面会显示每个操作的输出列表(output list)，而我上面的文章中基本都使用“输出数据结构”这样一个词汇在表达。通过查看output list，你更能明白RID Lookup(Bookmark Lookup)这样的操作存在的理由了。

　　最后，2005里面可以将图形显示的执行计划保存下来，以后可以打开再以图形方式进行查看分析，这个在2000下面是不行的，2000只能保存执行计划的文本。这样一些小功能对于分析SQL性能非常有用，在图形界面上的分析更直观。

liyihongcug

分析SQL Server中数据库快照工作原理
作者: , 　出处:IT专家网社区,　责任编辑: 叶江,　2007-06-19 10:36
　　在SQL Server 2005中，它的另外一个强大的新特点是数据库快照。数据库快照是一个数据库的只读副本，它是数据库所有数据的映射，由快照被执行的时间点来决定它的内容
　　这些数据库快照在报表方面是非常有价值，因为在快照数据库中或者在原数据库中，对于任何查询而言没有锁就将被执行。快照也可以使用在灾难恢复中，因为你可以将现有的数据恢复到现有的快照中，或者还可以在有害数据操作声明的事件中存储个别必要的表和数据。

　　数据库快照如何工作

　　可以使用典型的数据库命令CREATE DATABASE语句来生成一个数据库快照，在声明中有一个源数据库快照的附加说明。当快照被建立时，同时生成一个稀疏文件。这个文件(只能使用在NTFS卷中)在初始化的时候并没有磁盘空间分配给它——尽管你可能在WINDOWS资源管理器中看到了文件的大小，它会看上去与原始的源数据库文件的大小相同。对磁盘来说其实这个文件的大小接近于零。

　　数据库快照在初始化时读的数据文件是来自于源数据库的。当源数据库的数据发生变化时，数据引擎就会将原始数据从源数据库拷贝到快照数据库中。这个技术确保快照数据库只反映快照被执行时数据的状态。当SELECT命令被用来发布反对数据库快照时，不管数据页的读取是否被定位在源数据库数据文件中还是在快照数据库数据文件中都是没有锁被发布的。因为在只读数据库快照中是没有锁被发布，数据库快照对于报表解决方案是一个重要的解决方案。

　　一个快照的实例

　　现在，让我们来看看数据库快照在SQL Server 2005中是如何工作的。为此，首先我需要一个源数据库作为快照的来源。下面的脚本将创建一个源数据库：

　　USE master
　　GO
　　IF EXISTS(SELECT name from
　　sysdatabases where [name] = \'SourceDatabase\')
　　DROP DATABASE SourceDatabase
　　GO
　　CREATE DATABASE SourceDatabaseON PRIMARY
　　(
　　NAME = SourceDatabase_Data,
　　FILENAME = \'C:SQLServerSourceDatabase_Data.mdf\'
　　) LOG ON
　　(
　　NAME = SourceDatabase_Log,
　　FILENAME = \'C:SQLServerSourceDatabase_Log.ldf\'
　　)
　　GO


　　注意这里产品区域的大小。我定义它的大小为CHAR(150)来强调数据文件的增长级数，这样在我接下来的实例中将更容易解释清楚快照是如何工作的。

　　现在既然我已经有了一个源数据库，现在我装载一些数据来扩展数据文件的大小位。如此，使用上面的脚本来创建销售历史表。

　　USE SourceDatabase
　　GO
　　IF OBJECT_ID(\'SalesHistory\')>0 DROP TABLE SalesHistory
　　GO
　　CREATE TABLE SalesHistory
　　(SaleID INT IDENTITY(1,1),
　　Product CHAR(150), SaleDate DATETIME,
　　SalePrice MONEY)
　　DECLARE @i INT
　　SET @i = 1
　　WHILE (@i <=10000)
　　BEGIN INSERT INTO SalesHistory
　　(Product, SaleDate, SalePrice)
　　VALUES (\'Computer\', DATEADD(mm, @i, \'3/11/1919\'),
　　DATEPART(ms, GETDATE()) + (@i + 57) )
　　INSERT INTO SalesHistory
　　(Product, SaleDate, SalePrice)
　　VALUES (\'BigScreen\', DATEADD(mm, @i, \'3/11/1927\'),
　　DATEPART(ms, GETDATE()) + (@i + 13) )
　　INSERT INTO SalesHistory
　　(Product, SaleDate, SalePrice)
　　VALUES (\'PoolTable\', DATEADD(mm, @i, \'3/11/1908\'),
　　DATEPART(ms, GETDATE()) + (@i + 29) )
　　SET @i = @i + 1
　　END
　　GO
一旦你运行以下的脚本，就可以来操纵数据库文件储存的地方了。在这个实例上面，我将这些文件放在C:SQL Server文件夹下。在我的计算机上，当数据库被初始化创建时数据文件的大小是1,216KB，数据装载后的大小是7,360KB。既然源数据库有一些数据已经在里面了，所以我们现在就能建立一个快照了。使用以下的脚本来建立数据库快照。

　　CREATE DATABASE SnapshotDatabase
　　ON
　　(
　　NAME = \'SourceDatabase_Data\',
　　FILENAME = \'C:SQLServerSnapshotDatabase.mdf\'
　　) AS SNAPSHOT OF SourceDatabase


　　这个创建快照的语法与创建数据库的语法非常相似。两个主要的区别：第一个区别是AS SNAPSHOT OF SourceDatabase语句，在服务器实例上指明哪个数据库将作为快照的源数据库;第二个区别是，在事实上数据库快照是不会生成日志文件的。因为没有数据操作事物只会发生在只读数据库上，所以没有也不需要日志。

　　这个数据库脚本创建一个名为SnapshotDatabase.mdf(数据文件的扩展名不需要mdf)的稀疏文件。如果你在WINDOWS资源管理器中操作这个文件，并同时查看它的属性，你将看到这个文件的大小与源数据库文件的大小相同;然而，实际上磁盘上的大小却接近于零。这时，数据库快照是没有它自己的数据。

　　你能运行上面我使用的脚本重新在SourceDatabase数据库里面插入10,000行数据到SalesHistory表中。这时，我的SourceDatabase数据库大小是12,480KB，同时，磁盘上我的SourceDatabase数据库大小现在为448KB。这时在SourceDatabase数据库中所改变的数据页都已经被拷贝到SnapshotDatabase数据库中了，这样就能解释为什么在磁盘上它的大小被增加了。

　　进一步思考

　　数据库快照允许你为报表创建只读数据库，并且如果有必要的话你可以恢复你的源数据库到你的数据库快照上。同样的，你也可以根据你的报表目的创建任意多个数据库快照。

　　特别值得注意的是，这些数据库快照会占用磁盘空间，如果有太多的数据库快照的话，它将很快的将你的磁盘阵列填满，尤其在一个产品环境下，如果数据经常要被更新，就更容易将磁盘阵列填满。

　　另外，使用数据库快照会降低数据库的性能，因为在数据库中将数据页作为执行写操作拷贝是增加了数据库输入/输出。

　　虽然有这些小缺点，如果你能为报表提出一个好的数据库快照创建方案，SQL Server 2005的这个新的特性将有更多的人使用。

liyihongcug

精讲SQL Server数据库备份多种方法
作者: , 　出处:IT专家网社区,　责任编辑: 叶江,　2007-06-29 13:48
　　SQL Server数据库备份有两种方式，一种是使用BACKUP DATABASE将数据库文件备份出去，另外一种就是直接拷贝数据库文件mdf和日志文件ldf的方式……
　　SQL Server数据库备份有两种方式，一种是使用BACKUP DATABASE将数据库文件备份出去，另外一种就是直接拷贝数据库文件mdf和日志文件ldf的方式。下面将主要讨论一下后者的备份与恢复。本文假定您能熟练使用SQL Server Enterprise Manager(SQL Server企业管理器)和SQL Server Quwey Analyser(SQL Server查询分析器)

　　1、正常的备份、SQL数据库恢复方式

　　正常方式下，我们要备份一个数据库，首先要先将该数据库从运行的数据服务器中断开，或者停掉整个数据库服务器，然后复制文件。

　　卸下数据库的命令：Sp_detach_db 数据库名

　　连接数据库的命令：

　　Sp_attach_db或者sp_attach_single_file_db
　　s_attach_db [@dbname =] ′dbname′, [@filename1 =] ′filename_n′ [,...16]
　　sp_attach_single_file_db [@dbname =] ′dbname′, [@physname =] ′physical_name′


　　使用此方法可以正确恢复SQL Sever7.0和SQL Server 2000的数据库文件，要点是备份的时候一定要将mdf和ldf两个文件都备份下来，mdf文件是数据库数据文件，ldf是数据库日志文件。

　　例子：

　　假设数据库为test，其数据文件为test_data.mdf，日志文件为test_log.ldf。下面我们讨论一下如何备份、恢复该数据库。

　　卸下数据库：sp_detach_db \'test\'

　　连接数据库：

　　sp_attach_db \'test\',
　　\'C:\\Program Files\\Microsoft SQL Server\\MSSQL\\Data\\test_data.mdf\',
　　\'C:\\Program Files\\Microsoft SQL Server\\MSSQL\\Data\\test_log.ldf\'
　　sp_attach_single_file_db \'test\',\'C:\\Program Files\\Microsoft SQL Server\\MSSQL\\Data\\test_data.mdf\'


　　2、只有mdf文件的恢复技术

　　由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。

　　如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息

　　设备激活错误。

　　物理文件名 \'C:\\Program Files\\Microsoft SQL Server\\MSSQL\\data\\test_Log.LDF\' 可能有误。

　　已创建名为 \'C:\\Program Files\\Microsoft SQL Server\\MSSQL\\Data\\test_log.LDF\' 的新日志文件。
直接拷贝数据库文件mdf和日志文件ldf的方式……

　　但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息

　　服务器: 消息 1813，级别 16，状态 2，行 1

　　未能打开新数据库 \'test\'。CREATE DATABASE 将终止。

　　设备激活错误。物理文件名 \'d:\\test_log.LDF\' 可能有误。

　　怎么办呢?别着急，下面我们举例说明恢复办法。

　　A.我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。

　　B.停掉数据库服务器。

　　C.将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。

　　D.启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。

　　E.设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

　　use master
　　go
　　sp_configure \'allow updates\',1
　　go
　　reconfigure with override
　　go


　　F.设置test为紧急修复模式:

　　update sysdatabases set status=-32768 where dbid=DB_ID(\'test\')


　　此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\\置疑\\脱机\\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

　　G.下面执行真正的恢复操作，重建数据库日志文件:

　　dbcc rebuild_log(\'test\',\'C:\\Program Files\\Microsoft SQL Server\\MSSQL\\Data\\test_log.ldf\')


　　执行过程中，如果遇到下列提示信息：

　　服务器: 消息 5030，级别 16，状态 1，行 1 未能排它地锁定数据库以执行该操作。
SQL Server数据库备份有两种方式，一种是使用BACKUP DATABASE将数据库文件备份出去，另外一种就是直接拷贝数据库文件mdf和日志文件ldf的方式……

　　DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。

　　正确执行完成的提示应该类似于：(此文章由飞客数据恢复中心搜集http://www.cellma.com.cn)

　　警告: 数据库 \'test\' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

　　DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

　　H.验证数据库一致性: dbcc checkdb(\'test\')

　　一般执行结果如下：

　　CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 \'test\' 中)。

　　DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　I.设置数据库为正常状态

　　sp_dboption \'test\',\'dbo use only\',\'false\'


　　如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

　　J.最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成:

　　sp_configure \'allow updates\',0
　　go
　　reconfigure with override
　　go

liyihongcug

http://database.ctocio.com.cn/tips/125/7413625_1.shtmlSQL Server集群设计:大集群还是小集群
作者: Michelle Gutzait, 　出处:TechTarget,　责任编辑: 叶江,　2007-07-05 21:20
　　当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。那么，是大的集群还是小的集群更值的选择呢……
　　【IT专家网独家】很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。

　　将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

　　当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

　　什么是Microsoft集群服务器( Microsoft Cluster Server，缩写是MSCS)

　　MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率，以及无需停机时间来调度计划中的维护任务。

　　这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

　　MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

　　在集群服务器上的SQL Server

　　SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

　　SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

　　注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。

　　单个的大的SQL Server集群还是小的集群

　　下面是大的、由更多的节点组成的集群的优点：

　　更高的可用新(更多的节点来灾难恢复)
　　更多的负载均衡选择(更多的节点)
　　更低廉的维护成本
　　增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。
　　增强的管理性和简化环境(需要管理的少了)
　　更少的停机时间(灾难恢复更多的选择)
　　灾难恢复性能不受集群中的节点数目影响下面是单个大的集群的缺点：

　　集群节点数目有限(如果需要第9个节点怎么办)
　　在集群中SQL实例数目有限
　　没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。
　　使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。
　　虚拟化和集群

　　虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

　　在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

　　描述Windows和SQL Server集群的重要链接

　　SQL Server集群基础(An introduction to SQL Server clustering basics)
　　SQL Server集群简介(An introduction to SQL Server clustering)
　　SQL Server集群资源(SQL Server clustering resources ，这篇文章包含了关于集群的重要链接和信息)。
　　集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。

[ 本帖最后由 liyihongcug 于 2007-12-7 11:18 编辑 ]

liyihongcug

您现在的位置： IT专家网 > 数据库子站 > 数据库技巧
如何解决SQL Server虚拟内存不足情况
作者: , 　出处:IT专家网社区,　责任编辑: 叶江,　2007-07-16 13:56
　　
　　症状

　　在具有2GB 或更多 RAM 的计算机上，除了 256 MB (SQL Server 7.0) 或 384 MB (SQL Server 2000) 虚拟地址空间之外，SQL Server 在启动过程中保留剩下的所有虚拟地址空间以供缓冲池使用。另外，为了存储数据和过程缓存，SQL Server 使用缓冲池内存为来自 SQL Server 进程的大多数小于 8 KB 的其他内存请求提供服务。剩下的未保留内存准备用于不能从缓冲池得到服务的其他分配。这些分配包括、但不限于以下各项：SQL Server 创建的所有线程的堆栈和关联的线程环境块。在 SQL Server 创建了所有 255 个工作线程之后，这大约为 140 MB。

　　由在 SQL Server 地址空间(根据具体系统而有所不同)中运行的其他 DLL 或进程进行的分配，如： •任何链接的服务器中的 OLE DB 提供程序。
　　通过使用 sp_OA 系统存储过程或扩展存储过程加载的 COM 对象。
　　加载到地址空间中的任何映像(.exe 或 .dll)，这些映像通常使用 20 到 25 MB，但是如果您使用链接的服务器、sp_OA 或扩展存储过程，则这些映像可能使用更多的空间。
　　进程堆和 SQL Server 可能创建的任何其他堆。在启动过程中，此空间通常为 10 MB，但是如果您使用链接的服务器、sp_OA 或扩展存储过程，则此空间可能更多。
　　来自 SQL Server 进程的大于 8 KB 的分配，例如较大查询计划、网络数据包大小配置选项接近于 8 KB 时发送和接收缓冲区等情况所需要的分配。要查看此数字，请查找在 DBCC MEMORYSTATUS 中报告的 OS Reserved 值，该值是作为 8 KB 页的数目报告的。通常，该值为 5 MB。
　　跟踪缓冲池中每个缓冲区状态信息的数组。该值通常约为 20 MB，除非 SQL Server 运行时启用了地址窗口化扩展插件 (AWE)，在这种情况下，该值将会显著提高。
　　在拥有大量数据库的系统上，日志格式化所需的 64 KB 分配可能会占用所有剩余的虚拟内存。这之后的分配将失败，导致本文的“症状”一节中列出的一个或多个错误。

　　通过使用 -g 启动参数，您可以指示 SQL Server 保留附加的虚拟内存可用，以便这些与日志相关的分配和其他正常分配加在一起也不会用完虚拟地址空间。

　　下表根据数据库的数目和服务器版本列出-g值的一些建议初始值： DatabasesSQL Server 7.0 SQL Server 2000:

　　250-g134N/A
　　500-g185N/A
　　750-g237N/A
　　1000-g288-g288
　　1250-g340-g340
　　1500-g392-g392


　　此表是使用列出的典型值进行计算的，并且此计算是基于没有使用链接的服务器活动、sp_OA 或扩展存储过程这一假设的。它还假设您没有使用 AWE 和 SQL 事件探查器。出现以上任意一种情况都需要您增加 -g 的值。

　　如果服务器上数据库的数目超过此数目，Microsoft 建议您在运行该服务器之前进行慎重的考虑，因为系统上具有如此数目的数据库所需的系统开销将占用缓冲池中的大量虚拟内存，从而可能导致系统整体性能下降。

liyihongcug

SQL Server数据库同步问题
作者: , 　出处:IT专家网社区,　责任编辑: 叶江,　2007-07-09 13:00
　　数据库的复制和同步是数据存储中非常重要的一个的方面……
　　我们可以通过数据复制跨局域网，Internet在不同的数据库服务器上面维护多个数据的多个拷贝，同时以同步或异步的方式保证各个拷贝之间的数据一致性。

　　SQL Server提供完善的内置数据复制能力，它是SQL Server核心引擎非常重要的一部分。

　　SQL Server的复制分为三种方式：

　　快照复制：在某个时间点对于出版数据库中的数据照相，然后将其复制到定购服务器上。一般用于复制静态表。
　　事务复制：事务复制复制的内容是多条语句和存储过程，这样定购数据库只是读取数据库的数据修改方式，并且反映这种修改。一般用户更新频率较高的数据库。
　　合幷复制：允许定购者和出版者的双向修改，幷将修改反映到双方数据库上。如果数据有冲突，将会按照一定规则处理该冲突。
　　目前单位有用到一个web网站，数据库分别位于美国，荷兰和深圳。在网站基础架构上我们使用的是3DNS和BigIP实现智能域名解析和负载均衡。但由于三地具备各自的数据库(SQL Server)，需要保证各个数据库的数据一致。我们就需要做数据复制。根据用户的要求我们做的是事务复制，在网站的前两个版本都很正常，但在上两周更新了web页面版本后，发现事务复制经常出现错误。重新做事务复制在间隔不长的时间后仍然出现。后检查错误日志发现提示：

　　The query processor could not produce a query plan from the optimizer because a query cannot update a text, ntext, or image column and a clustering key at the same

　　检查数据库表格经过排查，确定存在问题的一个表格(XXX_article)。和程序员确认后发现此表格属性变更为ntext类型，而且会同时更新此字段和此表的聚集索引欗位。

　　因此怀疑是由于在做事务复制时会同时修改这两处位置造成，查阅相关的数据未能找到明确的官方说明，但是有其他程序的人员在程序编码中发现类似问题，其解决方法是分成两次update这个两个欗位。具体的技术细节，未能得到明确的说明。在事务复制上我们无法干扰其过程，因此我们将不对xxx_article做事务复制.然后对于xxx_article做快照复制，这样可以避免此问题的产生。经过测试和应用，此问题已经得到解决

liyihongcug

SQL Server数据库同步问题
作者: , 　出处:IT专家网社区,　责任编辑: 叶江,　2007-07-09 13:00
　　数据库的复制和同步是数据存储中非常重要的一个的方面……
　　我们可以通过数据复制跨局域网，Internet在不同的数据库服务器上面维护多个数据的多个拷贝，同时以同步或异步的方式保证各个拷贝之间的数据一致性。

　　SQL Server提供完善的内置数据复制能力，它是SQL Server核心引擎非常重要的一部分。

　　SQL Server的复制分为三种方式：

　　快照复制：在某个时间点对于出版数据库中的数据照相，然后将其复制到定购服务器上。一般用于复制静态表。
　　事务复制：事务复制复制的内容是多条语句和存储过程，这样定购数据库只是读取数据库的数据修改方式，并且反映这种修改。一般用户更新频率较高的数据库。
　　合幷复制：允许定购者和出版者的双向修改，幷将修改反映到双方数据库上。如果数据有冲突，将会按照一定规则处理该冲突。
　　目前单位有用到一个web网站，数据库分别位于美国，荷兰和深圳。在网站基础架构上我们使用的是3DNS和BigIP实现智能域名解析和负载均衡。但由于三地具备各自的数据库(SQL Server)，需要保证各个数据库的数据一致。我们就需要做数据复制。根据用户的要求我们做的是事务复制，在网站的前两个版本都很正常，但在上两周更新了web页面版本后，发现事务复制经常出现错误。重新做事务复制在间隔不长的时间后仍然出现。后检查错误日志发现提示：

　　The query processor could not produce a query plan from the optimizer because a query cannot update a text, ntext, or image column and a clustering key at the same

　　检查数据库表格经过排查，确定存在问题的一个表格(XXX_article)。和程序员确认后发现此表格属性变更为ntext类型，而且会同时更新此字段和此表的聚集索引欗位。

　　因此怀疑是由于在做事务复制时会同时修改这两处位置造成，查阅相关的数据未能找到明确的官方说明，但是有其他程序的人员在程序编码中发现类似问题，其解决方法是分成两次update这个两个欗位。具体的技术细节，未能得到明确的说明。在事务复制上我们无法干扰其过程，因此我们将不对xxx_article做事务复制.然后对于xxx_article做快照复制，这样可以避免此问题的产生。经过测试和应用，此问题已经得到解决

liyihongcug

005分析服务 统一整合视图
作者: , 　出处:IT专家网社区,　责任编辑: 叶江,　2007-05-25 08:11
　　本文讲解SQL Server 2005分析服务……
　　统一的空间模型

　　分析服务提供了一个商务语义模型，被称为统一的空间模型 (UDM)。该模型定义了商务实体、商务逻辑、计算和度量。UDM 是一个中心位置，充当所有报告、电子表格、OLAP浏览器、KIPS 和分析应用程序的真实情况的唯一版本。

　　使用强大的新的数据源视图功能，可以将UDM映射为后端不同类型数据源的主机，提供完全整合了的商务图像，而与数据的位置无关。通过使用友好的商务实体描述、层次导航、多视图以及自动翻译为当地语言的功能，用户将会发现可以轻松浏览企业的商务数据。

　　主动的缓冲

　　主动的缓冲使得能够通过多维在线分析处理(MOLAP)分类的工作情况来合并实时的更新。分析服务维护着高度压缩和优化的数据缓冲，可以将其作为潜在数据源变化中的数据进行自动维护。该缓冲提供了极好的查询性能，并将后端源系统与分析查询分离开。

　　高级的商务智能

　　KPI 框架提供了丰富的定义了主要度量和积分卡的中心仓库。分析服务中的 KPI 框架可以让您轻松构建平衡的积分卡和其它类型的商务性能管理应用。

　　翻译。翻译提供了简单的集中化管理的机制，以用户偏好的语言保存和将分析数据提供给用户。
　　MDX 脚本。对于定义被计算成员、命名集合和单元计算来说，多维表达式(MDX)脚本是新的机制。
　　商业智能向导。一组易于使用的向导可以帮助初学者为更为复杂的商务智能问题中的一些建立模型。
　　半附加性的方法。这种新的方法聚合类型适合于最新非空、最后孩子、最先孩子、孩子平均以及统计类型等高级数据建模。
　　Web服务

　　分析的 XML(XML/A)对于与分析服务器进行通讯是必须的、基础标准协议。激活新类型的应用，并易于开发整合实时操作分析的并可以通过任何平台和语言都可以访问的应用。

　　企业功能

　　SQL Server 2005 分析服务为商务智能服务器在企业的可伸缩性、可管理性和生产力方面设定了新的标准。

　　可伸缩性。分析服务适合于要求高度分析和报表的应用中。通过新的空间结构，使用UDM的应用使得用户能够使用多维和多等级来快速进行丰富的、直观的特别 hoc 分析。等级使得用户更容易的通过成百上千的成员来导航和查询 UDM。

　　此外，新的架构还去除了内存驻留维数和每个父亲拥有孩子个数的限制。XML/A 协议与极大优化以角色为基础的安全是成对配合的。通过以 XML/A 为基础的通讯协议，分析服务帮助 UDM 处理成千上万的用户，激活使用 Web/中间层或客户/服务器结构的企业扩展商务智能应用。

　　可管理性。通过整合关系引擎和分析服务的管理工具，商务智能管理员会从单独、统一的管理SQL Server分析服务的环境中获得好处。通过 SQL Server Management Studio，管理员 可以轻松编制分析服务对象和操作或人物的脚本。管理员可以使用富文本编辑器编写 MDX 和数据挖掘扩展 (DMX) 查询。 SQL Profiler 可以用来跟踪、捕获和重现分析服务查询和其它命令。多实例、提高的备份和恢复、跨服务器的同步和改善了的优秀的管理许可是新的可用的管理性工具中一些特色。

　　生产力。分析服务向导和编辑器与 Visual Studio集成，提供真正的应用开发环境，可以支持项目的全生命周期。源控制、形成版本、工作站分离、嵌入调试和配置管理是新的Business Intelligence Development Studio中的一些特色。(

liyihongcug

SQL Server 灾难恢复
作者: , 　出处:IT专家网社区,　责任编辑: 叶江,　2007-07-04 10:00
　　由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了
　　如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息：

　　设备激活错误。物理文件名 \'C:\\Program Files\\Microsoft SQL Server\\MSSQL\\data\\test_Log.LDF\' 可能有误。
　　已创建名为 \'C:\\Program Files\\Microsoft SQL Server\\MSSQL\\Data\\test_log.LDF\' 的新日志文件。


　　但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息

　　服务器: 消息 1813，级别 16，状态 2，行 1
　　未能打开新数据库 \'test\'。CREATE DATABASE 将终止。
　　设备激活错误。物理文件名 \'d:\\test_log.LDF\' 可能有误。


　　怎么办呢?别着急，下面我们举例说明恢复办法。

　　A.我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。

　　B.停掉数据库服务器。

　　C.将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。

　　D.启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。

　　E.设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

　　use master
　　go
　　sp_configure \'allow updates\',1
　　go
　　reconfigure with override
　　go


　　F.设置test为紧急修复模式

　　update sysdatabases set status=-32768 where dbid=DB_ID(\'test\')


　　此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\\置疑\\脱机\\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

　　G.下面执行真正的恢复操作，重建数据库日志文件

　　dbcc rebuild_log(\'test\',\'C:\\Program Files\\Microsoft SQL Server\\MSSQL\\Data\\test_log.ldf\')


　　执行过程中，如果遇到下列提示信息：

　　服务器: 消息 5030，级别 16，状态 1，行 1

　　未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。

　　正确执行完成的提示应该类似于：

　　警告: 数据库 \'test\' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

　　DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

　　H.验证数据库一致性(可省略)

　　dbcc checkdb(\'test\')

　　一般执行结果如下：

　　CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 \'test\' 中)。

　　DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　I.设置数据库为正常状态

　　sp_dboption \'test\',\'dbo use only\',\'false\'


　　如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

　　J.最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成

　　sp_configure \'allow updates\',0
　　go
　　reconfigure with override
　　go