1.故障爆发：
2003－12－26 13:00
客户报告所有的POS死机和SERVER运行速度非常的慢。经过重新启动服务器（启动到检查RAID卡时开始报警）我们发现在WINDEOWS 2000 SERVER的“系统日志”中有这样的信息：
Error: 823, Severity: 24, State: 2
I/O error (torn page) detected during read at offset 0x0000001bf96000 in file D :\DATA\POS_DB.mdf'.
SQLSERVER的“错误日志”中有这样的信息：
2003-12-10 03:34:22.23 spid56 Error: 823, Severity: 24, State: 2
2003-12-10 03:34:22.23 spid56 I/O error (torn page) detected during read at offset 0x00000074964000 in file 'D:\DATA\POS_DB.mdf'..
来自msdn的解释：
　　I/O logical check failure: If a read Windows API call or a write Windows API call for a database file is successful, but specific logical checks on the data are not successful (a torn page, for example), an 823 error is raised. The following error message is an example of an 823 error for an I/O logical check failure:
2003-09-05 16:51:18.90 spid17 Error: 823, Severity: 24, State: 2
2003-09-05 16:51:18.90 spid17 I/O error (torn page) detected during read at offset 0x00000094004000 in file 'F:\SQLData\mydb.MDF'..
　　To resolve this problem, first run the DBCC CHECKDB statement on the database that is associated with the file in the error message. If the DBCC CHECKDB statement reports errors, correct those errors before you troubleshoot this problem. If the problem persists even after the DBCC CHECKDB errors have been corrected, or if the DBCC CHECKDB statement does not report any errors, review the Microsoft Windows NT system event log for any system errors or disk-related errors. You can also contact your hardware vendor to run any appropriate diagnostics.
　　 I/O逻辑检查失败：如果有一个WINDOWS程序在读取和写数据库文件时是成功的，但是在详细的数据逻辑检查时没有成功（比如：不完整的页），SQLSERVER会返回MSG 823的错误。下面就是一个I/O逻辑检查失败MSG 823的实例：
2003-09-05 16:51:18.90 spid17 Error: 823, Severity: 24, State: 2
2003-09-05 16:51:18.90 spid17 I/O error (torn page) detected during read at offset 0x00000094004000 in file 'F:\SQLData\mydb.MDF'..
　　要解决这样的问题，首先要在该数据库中执行DBCC CHECKDB（错误信息提示的数据库文件）。如果DBCC CHECKDB报错，在你修复错误之前纠正这些错误。如果这些错误信息一直保留到执行DBCC CHECKDB运行之后，或者DBCC CHECKDB没有报告任何错误，检查WINDOWS NT系统的的事件查看器的和系统错误或磁盘错误相关的信息。你也可以联系硬件厂商运行正确的诊断工具。

　　坏了:-(，数据库文件有问题，在检查OS的事件查看器，我们发现在一个星期之前就有错误信息（只是OFFSET的偏移地址不同）。

　　赶紧检查HDD,果然发现在RAID5的第一快HDD亮了红灯（灰尘太多，很难于看清）

执行 DBCC CHECKDB('POS_DB')检查发现：
Server: Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 26342838, index ID 35207, page ID (1:50978). The PageId in the page header =(32230:-2048732002).

大家可以到下面的地址找到相关的信息：
http://support.microsoft.com/default.aspx?scid=kb;en-us;826433
PRB: Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems
http://support.microsoft.com/default.aspx?scid=kb;en-us;828339
PRB: Error message 823 may indicate hardware problems or system problems
http://support.microsoft.com/default.aspx?scid=kb;en-us;308795
FIX: CheckDB May Not Fix Error 8909 or Error 8905

故障确诊：RAID有一块HDD坏，造成数据库文件破坏

2.更换HDD
2003－12－28 23:00
现在就体现了RAID5的好处，坏了一块HDD，系统可以照常运行，不过系统的日志和SQLSERVER的日志还是有MSG823的报错信息。
按照RAID 卡的REBUILD的步骤将新的HDD绑定到原始的RAID5中，顺利完成:-)
用DBCC检查数据库的完整性
DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS
发现还是有和更换HDD之前一样的ERROR信息，看来数据库文件还是有问题。

--有一个奇怪问题1，既然是5块HDD的RAID5，为何有一块HDD坏会影响数据库文件的损坏，不解？？？:-(

3.恢复数据库
2003－12－29 00:30
没有办法，用备份的数据集恢复数据库（看来备份是多么的重要）
USE MASTER
GO
RESTORE DATABASE POS_DB FROM DISK='D:\DATABASEBACKUP\POS_DB_BACKUP.DAT'
重新启动MSSQLSERCVER服务，
NET STOP MSSQLSERVER / NET START MSSQLSERVER
用DBCC检查数据库的完整性
DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS

和恢复之前的错误信息一致，没有改变。
--奇怪问题之2，SQLSERVER BACKUP 之前并不验证数据库的完整性，数据库的全备份竟然是有问题的。气愤！！

看来只能通过工具修复数据库了（--在修改之前记录错误表的记录数，以便修复数据库后进行比较）。
在查询分析器中运行：
ALTER DATABASE POS_DB SET SINGL_USER
GO
DBCC CHECKDB('POS_DB',repair_allow_data_loss) WITH TABLOCK
GO
ALTER DATABASE POS_DB SET MULTI_USER
GO

CHECKDB 有3个参数:
REPAIR_ALLOW_DATA_LOSS
执行由 REPAIR_REBUILD 完成的所有修复，包括对行和页进行分配和取消分配以改正分配错误、结构行或页的错误，以及删除已损坏的文本对象。这些修复可能会导致一些数据丢失。修复操作可以在用户事务下完成以允许用户回滚所做的更改。如果回滚修复，则数据库仍会含有错误，应该从备份进行恢复。如果由于所提供修复等级的缘故遗漏某个错误的修复，则将遗漏任何取决于该修复的修复。修复完成后，备份数据库。
REPAIR_FAST 进行小的、不耗时的修复操作，如修复非聚集索引中的附加键。这些修复可以很快完成，并且不会有丢失数据的危险。
REPAIR_REBUILD 执行由 REPAIR_FAST 完成的所有修复，包括需要较长时间的修复（如重建索引）。执行这些修复时不会有丢失数据的危险。

第一次运行，我们会发现：
DBCC results for 'TABLE_NAME'.
There are 1 rows in 1 pages for object 'TABLE_NAME'.
The error has been repaired.
CHECKDB found 0 allocation errors and 1 consistency errors in table '(Object ID 26342838)' (object ID 26342838).
CHECKDB fixed 0 allocation errors and 1 consistency errors in table '(Object ID 26342838)' (object ID 26342838).
这样的信息有很多，并且有“The error has been repaired”的提示。不过到最后还是有这样的信息：
CHECKDB found 0 allocation errors and 19 consistency errors in database 'POS_DB'.
CHECKDB fixed 0 allocation errors and 19 consistency errors in database 'POS_DB'.
再次运行，还是有同样的错误。糟糕:=)看来这种方式是无法修复这样测错误。

失败！！！

再仔细看看SQLSERVER BOL发现CHECKDB还有一个非常有用的参数PHYSICAL_ONLY

PHYSICAL_ONLY
仅限于检查页和记录标题物理结构的完整性，以及页对象 ID 和索引 ID 与分配结构之间的一致性。该检查旨在以较低的开销检查数据库的物理一致性，同时还检测会危及用户数据安全的残缺页和常见的硬件故障。PHYSICAL_ONLY 始终意味着 NO_INFOMSGS，并且不能与任何修复选项一起使用。

再次运行：
DBCC CHECKDB('POS_DB') with NO_INFOMSGS,PHYSICAL_ONLY
然后再运行：
DBCC CHECKDB('POS_DB',repair_allow_data_loss) WITH TABLOCK
这次会返回一些8952.8956的错误信息:
Server: Msg 8952, Level 16, State 1, Line 1
Table error: Database 'POS_DB', index 'POS_REFER.Idx2_POS_REFER' (ID 861246123) (index ID 2). Extra or invalid key for the keys:

Server: Msg 8956, Level 16, State 1, Line 1
Index row (1:26315:23) with values (PLU_ID = '6922825200240' and PRD_AGGR_ID = 10006 and EVNT_ID = NULL and RGST_MDE = 0 and SUBPRD_NBR = 0 and STR_ID = 12 and PRD_AGGR_ID = 10006 and SUBPRD_NBR = 0 and STR_ID = 12 and PLU_ID = '6922825200240' and EVNT_ID = NULL and RGST_MDE = 0) points to the data row identified by ().

根据MSDN上的说明：
This problem does not cause any data or index corruption. The problem is in the metadata which is corrected only by dropping and re-creating the indexes.
这些问题不会引起数据或索引的损坏，这些问题的元数据是正确的，只是删除再重新建立索引。
看来问题是修改了。

再次运行DBCC CHECKDB('POS_DB'),再次运行:DBCC CHECKDB('POS_DB'),message没有错误信息。

ok成功修复:-)

4.检查修复后的数据库并且备份数据库
检查DBCC CHECKDB报错的相关表，和没有执行DBCC之前的记录数进行比较，发现有一个表少了40条记录。郁闷:-

5.总结

1.RAID5并不能保证SQLSERVER 2000 数据库的数据文件的完整性；
2.SQLERVER 2000的备份程序不验证数据库文件的数据完整性；如果你的数据文件有问题，备份时也不图示；
3.DBCC CHECKDB的repair_allow_data_loss并不是非常安全的，不能修复所有的错误，即使是对不完整页（TORN PAGE）的修复也会着成数据丢失；
4.DBCC CHECKDB的REPAIR_ALLOW_DATA_LOSS参数无法修复所有的错误;

参考文章:
http://support.microsoft.com/default.aspx?scid=kb;en-us;298806
http://support.microsoft.com/default.aspx?scid=kb;en-us;284440
http://support.microsoft.com/default.aspx?kbid=320434
http://support.microsoft.com/default.aspx?scid=kb;en-us;828339
http://support.microsoft.com/default.aspx?scid=kb;en-us;308795
http://support.microsoft.com/default.aspx?scid=kb;en-us;826433

-----------------------------------------------------------------------------------------------------------------

EXECUTE master.dbo.xp_sqlmaint N'-PlanID 4F597334-7ABF-4140-8DF3-2CE11E9CE6C2 -Rpt "E:\DATABASE\数据库维护计划14.txt"  -BkUpMedia DISK -BkUpDB "E:\DATABASE" -BkExt "BAK"'

数据库全备份也成功了

Microsoft (R) SQLMaint 实用工具（Unicode），版本 登录到 SQL Server“P4”以“NT AUTHORITY\SYSTEM”（受信任）身份
开始维护计划“数据库维护计划1”（在 2005-7-6 15:56:31 上）
[1] 数据库 OTSP库 备份...
    目的: [E:\DATABASE\OtSpOnline_db_200507061556.BAK]

    ** 执行时间: 0 小时，2 分钟，30 秒 **

结束维护计划“数据库维护计划1”（在 2005-7-6 15:59:01 上）
SQLMAINT.EXE 进程退出代码: 0 (成功)


------------------------------------------------------------------------------------------------------------

执行下面的数据库维护计划

EXECUTE master.dbo.xp_sqlmaint N'-PlanID DB9949C7-4262-46EF-A16E-B5A16E9455CC -Rpt "E:\db_bak\数据库维护计划-Tonychen-200507022.txt" -DelTxtRpt 1WEEKS -WriteHistory  -CkDBRepair  '

错误日志如下：
Microsoft (R) SQLMaint 实用工具（Unicode），版本 登录到 SQL Server“SPSERVER”以“SPSERVER\Administrator”（受信任）身份
开始维护计划“数据库维护计划-Tonychen-20050702”（在 2005-7-6 11:32:32 上）
[1] 数据库 OtSp: 检查数据链接...
[Microsoft SQL-DMO （ODBC SQLState: 42000）] 错误 8906: [Microsoft][ODBC SQL Server Driver][SQL Server]扩展盘区 (3:10487)（属于数据库 ID 7）在 SGAM (3:3) 和 PFS (3:8088) 中进行了分配，但未在任何 IAM 中进行过分配。PFS 标志 'MIXED_EXT ALLOCATED   0_PCT_FULL'。
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB 发现了 1 个分配错误和 0 个一致性错误（在表 'WWCHAT_SUB_Around' 中，该表的对象 ID 为 1214627370）。
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB 发现了 1 个分配错误和 0 个一致性错误（在数据库 'OtSp' 中）。
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss 是最低的修复级别（对于由 DBCC CHECKDB (OtSp noindex) 发现的错误而言）。

    发现下列错误:

[Microsoft][ODBC SQL Server Driver][SQL Server]扩展盘区 (3:10487)（属于数据库 ID 7）在 SGAM (3:3) 和 PFS (3:8088) 中进行了分配，但未在任何 IAM 中进行过分配。PFS 标志 'MIXED_EXT ALLOCATED   0_PCT_FULL'。
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB 发现了 1 个分配错误和 0 个一致性错误（在表 'WWCHAT_SUB_Around' 中，该表的对象 ID 为 1214627370）。
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB 发现了 1 个分配错误和 0 个一致性错误（在数据库 'OtSp' 中）。
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss 是最低的修复级别（对于由 DBCC CHECKDB (OtSp noindex) 发现的错误而言）。
    ** 执行时间: 0 小时，0 分钟，41 秒 **

[2] 数据库 otspbak: 检查数据链接...

    ** 执行时间: 0 小时，0 分钟，4 秒 **

正在删除旧的文本报告...   已删除 0 个文件。

结束维护计划“数据库维护计划-Tonychen-20050702”（在 2005-7-6 11:33:17 上）
SQLMAINT.EXE 进程退出代码: 1 (失败)

解决方法：
alter database otsponline set single_user --切换到单用户模式下
dbcc checkdb('otsp',repair_allow_data_loss) WITH TABLOCK -- 进行数据库修复
alter database otsponline set multi_user --切换回到多用户模式下


重新执行数据库维护计划：
EXECUTE master.dbo.xp_sqlmaint N'-PlanID DB9949C7-4262-46EF-A16E-B5A16E9455CC -Rpt "E:\db_bak\数据库维护计划-Tonychen-200507022.txt" -DelTxtRpt 1WEEKS -WriteHistory  -CkDBRepair  '


事务日志正确：

Microsoft (R) SQLMaint 实用工具（Unicode），版本 登录到 SQL Server“P4”以“NT AUTHORITY\SYSTEM”（受信任）身份
开始维护计划“数据库维护计划1”（在 2005-7-6 15:53:49 上）
[1] 数据库 OTSP: 检查数据链接...

    ** 执行时间: 0 小时，1 分钟，34 秒 **

结束维护计划“数据库维护计划1”（在 2005-7-6 15:55:23 上）
SQLMAINT.EXE 进程退出代码: 0 (成功)

-----------------------------------------------------
-- Export file for user SA                         --
-- Created by Administrator on 2005-1-30, 18:05:12 --
-----------------------------------------------------

spool asdsd.log

prompt
prompt Creating table TEST
prompt ===================
prompt
create table TEST
(
  NAME   VARCHAR2(20),
  PASSWD VARCHAR2(20)
)
tablespace USERS
  pctfree 10
  initrans 1
  maxtrans 255
  storage
  (
    initial 64K
    minextents 1
    maxextents unlimited
  );

prompt
prompt Creating package DOTNET
prompt =======================
prompt
create or replace package DotNet as

  TYPE type_cur IS REF CURSOR;     --定义游标变量用于返回记录集

  PROCEDURE DotNetPagination(
  Pindex in varchar2,                --分页索引
  Psize in varchar2,                 --页面大小
  Psql in varchar2,                --产生dataset的sql语句
  Pcount out number,               --返回分页总数
  v_cur out type_cur               --返回当前页数据记录
  );
 
  PROCEDURE DotNetPageRecordsCount(
  Psqlcount in varchar2,
  Prcount   out number
  );
 
end DotNet;
/

prompt
prompt Creating package PKG_TEST
prompt =========================
prompt
CREATE OR REPLACE PACKAGE pkg_test
AS
   TYPE myrctype IS REF CURSOR;

   PROCEDURE get (p_id in NUMBER, p_rc OUT myrctype);
END pkg_test;
/

prompt
prompt Creating package PKG_TEST_FUNCTION
prompt ==================================
prompt
create or replace package pkg_test_function as
/* 定义ref cursor类型
    不加return类型，为弱类型，允许动态sql查询，
    否则为强类型，无法使用动态sql查询;
*/
   type myrctype is ref cursor; 
  
--函数申明
   function get(intID number) return myrctype;
end pkg_test_function;
/

prompt
prompt Creating procedure DOTNETPAGINATION
prompt ===================================
prompt
CREATE OR REPLACE PROCEDURE dotnetpagination (
      pindex   IN       number,
      psize    IN       number,
      psql     IN       VARCHAR2,
      pcount   OUT      NUMBER
   )
   IS
      v_sql     VARCHAR2 (1000);
      v_count   NUMBER;
      v_plow    NUMBER;
      v_phei    NUMBER;
   BEGIN
------------------------------------------------------------取分页总数
      v_sql := 'select count(*) from (' || psql || ')';

      EXECUTE IMMEDIATE v_sql
                   INTO v_count;
      pcount := CEIL (v_count / psize);
------------------------------------------------------------显示任意页内容
      v_phei := pindex * psize + psize;
      v_plow := v_phei - psize + 1;

   END dotnetpagination;
/

prompt
prompt Creating package body DOTNET
prompt ============================
prompt
CREATE OR REPLACE PACKAGE BODY dotnet
AS
--***************************************************************************************
   PROCEDURE dotnetpagination (
      pindex   IN       VARCHAR2,
      psize    IN       VARCHAR2,
      psql     IN       VARCHAR2,
      pcount   OUT      NUMBER,
      v_cur    OUT      type_cur
   )
   IS
      v_sql     VARCHAR2 (1000);
      v_count   NUMBER;
      v_plow    NUMBER;
      v_phei    NUMBER;
   BEGIN
------------------------------------------------------------取分页总数
      v_sql := 'select count(*) from (' || psql || ')';

      EXECUTE IMMEDIATE v_sql
                   INTO v_count;
      pcount := CEIL (v_count / psize);
------------------------------------------------------------显示任意页内容
      v_phei := pindex * psize + psize;
      v_plow := v_phei - psize + 1;
      --Psql := 'select rownum rn,t.* from cd_ssxl t' ;            --要求必须包含rownum字段
      v_sql :='select * from ('|| psql || ') where rownum between '|| v_plow || ' and ' || v_phei;

      OPEN v_cur FOR v_sql;
   END dotnetpagination;

--**************************************************************************************

 procedure DotNetPageRecordsCount(
  Psqlcount in varchar2,
  Prcount   out number
  )
  as

   v_sql varchar2(1000);
   v_prcount number;

  begin

   v_sql := 'select count(*) from (' || Psqlcount || ')';
   execute immediate v_sql into v_prcount;
   Prcount := v_prcount;                  --返回记录总数

  end DotNetPageRecordsCount;

 --**************************************************************************************
END dotnet;
/

prompt
prompt Creating package body PKG_TEST
prompt ==============================
prompt
CREATE OR REPLACE PACKAGE BODY pkg_test
AS
   PROCEDURE get (p_id in NUMBER, p_rc OUT myrctype)
   IS
      sqlstr   VARCHAR2 (500);
   BEGIN
      IF p_id = 0
      THEN
         OPEN p_rc FOR
            SELECT phone, msg_content, gateid
              FROM wwchat_del_log
             WHERE ROWNUM < 100;
      ELSE
         sqlstr :=
            'SELECT phone,msg_content,gateid FROM wwchat_del_log where rownum<100';

         OPEN p_rc FOR sqlstr USING p_id;
      END IF;
   END get;
END pkg_test;
/

prompt
prompt Creating package body PKG_TEST_FUNCTION
prompt =======================================
prompt
CREATE OR REPLACE PACKAGE BODY pkg_test_function
AS
--函数体
   FUNCTION get (intid NUMBER)
      RETURN myrctype
   IS
      rc       myrctype;                                 --定义ref cursor变量
      sqlstr   VARCHAR2 (500);
   BEGIN
      IF intid = 0
      THEN
         --静态测试，直接用select语句直接返回结果
         OPEN rc FOR
            SELECT phone, msg_content, gateid
              FROM wwchat_del_log
             WHERE ROWNUM < 100;
      ELSE
         --动态sql赋值，用:w_id来申明该变量从外部获得
         sqlstr :=
            'select id,name,sex,address,postcode,birthday from student where id=:w_id';

         --动态测试，用sqlstr字符串返回结果，用using关键词传递参数
         OPEN rc FOR sqlstr USING intid;
      END IF;

      RETURN rc;
   END get;
END pkg_test_function;
/

作为网管员，无论其管理的网络的规模是大还是小，在日常的管理中除了维护网络平稳运行、及时排除网络故障、保护网络安全等工作以外，备份网络中关键数据也是其中的一个非常非常重要的工作环节。 网络中的各种故障无非就分两种：软件故障和硬件故障。对于“硬件故障”可以通过维修或更换硬件设备得到及时解决；对于“软件故障”则可以通过重新安装或升级软件、重做网络或应用软件系统等方法及时解决，而且用此方法来解决网络故障大多需要一些基础的、关键的数据支持才能得以恢复正常。但是，网络中诸如此类的关键数据(特别是“应用软件系统”中的关键数据)的损坏或丢失，绝大部分是无法恢复和弥补的。即使可以恢复部分数据，弥补它们所花费的代价(诸如时间、人力、财力、物力等)都可能远远超出了公司的承受能力。

所以说，注重数据的备份工作是网管员日常管理工作中的必须时刻关注的一项任务，也是必须周期性重复操作的一项工作。

目录

现行备份策略
具体实现步骤
结束语

现行备份策略

我公司在组建局域网时，考虑到商业企业的特点，仔细考量了购、销、存三大环节中发生的各种数据及其存储问题后，选定了以Windows 2000 Server为操作系统，SQL Server 2000为数据库平台来搭建局域网的应用系统的软件平台，以网线为载体将购、销、存等核心部门的计算机通过局域网平台紧密地连接起来。这样，各个核心部门每天的任何一笔业务都及时地、动态地存储到公司局域网的核心Dell服务器上的SQL Server 2000数据库中，并以此为基础平台向各方提供所需的各种数据服务。

因此，自公司局域网开始正式运作之日起，作为网管员的我就非常注重对局域网中的关键数据——特别是这些业务数据的备份工作。同时，我也希望备份数据的软件能够实现以下自动功能。

功能1：能够在每天的某个固定的时刻(如夜晚0:00:00，当然这个时间是可以自主设定的)对包含所有业务数据库在内的所有关键数据库进行一次“完全备份”。

功能2：能够在每天的0:00:00至23:59:59这段时间内，每间隔1个小时对功能1中所涉及到的各个数据库的事务日志进行“差异备份”。

功能3：每天都能够保留功能1和功能2中所生成的数据库和事务日志的最近两天的备份(即：前一天的和前两天的)，而且能够自动地删除久于两天前的所有数据库和事务日志的备份。

功能4：定期(如每个星期一次)将所有关键数据库的完全备份的副本备份到磁带或其它存储介质上(这部分工作可能需要手工完成)。

于是，围绕这些功能的实现，在日常管理工作中，我尽可能地尝试了各种备份数据的软件和方法，如Windows 2000自带的“备份”工具、SQL Server 2000自带的“备份”功能等。这些备份软件和方法的功能各有千秋，但是都存在以下缺点：

一种就是需要人工干预，无法实现自动备份(如Windows 2000自带的“备份”工具)。如果采用这种方法，就必须时刻人工手动备份，万一哪天因为出差或其它原因没有进行备份，而这时又出现服务器或数据故障的话，那麻烦就大了。

另一种就是能够实现自动备份，但是旧的备份不能被自动地删除(如SQL Server 2000自带的“备份”功能)。如果采取这种方法，就必须及时地手工删除旧的备份，否则再大的硬盘也会迅速地被用完。

在相互比较后，我还是决定采用第二种——SQL Server 2000自带的“备份”功能对关键数据库进行备份，因为它能够实现“自动备份”功能，比第一种略强。所以，在一段时期内，我每天上班后的第一件事就是先检查一下备份目录下各种数据的新的备份，然后手工删除旧的备份数据。这种做法一度让我很是苦恼。

一天，我在利用SQL Server 2000的“帮助”查询某个Transact-SQL语句的语义解释时无意中阅读到“自动化管理任务”的内容。从头到尾地仔细阅读后，我不由得眼睛一亮，原来SQL Server 2000本身自带了一个能够实现我的备份要求的、强大的功能——“数据库维护计划”。于是我立刻按照这部分内容的提示，以一个数据库为试验样本一步一步地操作，成功地创建了一个数据库维护计划。经过一个星期的试运行，这个计划果然能够实现自动备份调度，以及自动删除旧的数据备份，完全能够满足我的备份要求。

从那时起，我就利用SQL Server 2000的“数据库维护计划”备份所有关键数据库，而且严格地、定期地执行功能4，每个星期五将完全备份的数据库备份到磁带和局域网中其它客户机(主要是用于网络管理的网管PC)的硬盘上。这样做的目的是，能同时异地保存三份相同的备份，减少故障带来的损失。

而且，通过SQL Server 2000的“数据库维护计划”，我现在能够较轻松地备份所需各种数据，方便地管理其备份，相应地减少了日常工作量，也减轻了部分工作压力。

具体实现步骤

目录

第一步：打开SQL Server“企业管理器”窗体
第二步：找到“数据库维护计划”功能
第三步：创建“数据库维护计划”
第四步：维护和管理“数据库维护计划”
第五步：启动SQL Server 2000代理以便执行“作业”
第六步：检查结果

“数据库维护计划”功能在SQL Server 2000的“企业管理器”中可以找到。

说明：

1.以下操作是在服务器的Windows 2000 Server上进行操作的。在Window 9X系统上操作相同。

2.由于SQL Server 2000执行备份时将产生许多文件(特别是在进行事务日志备份时)，所以建议按数据库名称分别建立独立的备份目录进行存储。

3.以下所有操作过程当中一般不会对数据库的使用产生影响。

第一步：打开SQL Server“企业管理器”窗体

用鼠标单击任务栏上的“开始”按钮中的“程序(P)”菜单下的“Microsoft SQL Server”子菜单中的“企业管理器”菜单项，即可打开SQL Server 2000的“企业管理器”窗体。

第二步：找到“数据库维护计划”功能

在“企业管理器”窗体中左侧的树型选项卡中，用鼠标单击“+”图标扩展开“控制台根目录”下的“Microsoft SQL Servers”，可以看到其下有一个“SQL Server组”；接着继续扩展开“SQL Server组”，此时可以看到其下出现了服务器的名称(图1中的“JXNC-SERVER”就是我的服务器的名称)；再继续扩展开此服务器，可以看到其下列出了诸如“数据库”、“数据转换服务”等项目；最后单击“管理”项目，可以看到其下存在一个“数据库维护计划”(如图1)。

图1

单击“数据库维护计划”项目，在“企业管理器”窗口右侧将会显示出已经存在的维护计划项目。每个维护计划均包括以下项目：

1.名称：就是维护计划的名称。此名称可以自定义，中英文皆可。

2.数据库：就是维护计划所进行维护的数据库的名称。

因为一个维护计划允许同时维护多个数据库，所以此处可以显示出多个数据库的名称(在图1中可以看到名为“系统数据库备份”的数据库维护计划中的“数据库”就包括三个数据库：master、model和msdb)。

3.服务器：也就是维护计划所维护的数据库所处的服务器的名称。“(local)”表示是本地服务器。

4.对策：是指维护计划所需要进行的具体维护工作的内容。

图1中有3个“数据库维护计划”均为“数据库备份，事务日志备份”，它的含义就是这些维护计划中同时对所指定的数据库进行“数据库”和“事务日志”的备份。

第三步：创建“数据库维护计划”

鼠标右击“数据库维护计划”项目，选择“新建维护计划(P)”功能，将打开“数据库维护计划向导”窗体，依照此向导能够创建一个新的“数据库维护计划”。

步骤1：单击 “下一步(N)”按钮，打开“选择数据库”窗体(如图2)。在此窗体中可以选定一个或多个的数据库作为操作对象。为了叙述方便，我在此只选择了一个数据库“regie”。

图2

步骤2：单击图2中的“下一步(N)”按钮，打开“更新数据优化信息”窗体(如图3)。

图3

在此窗体中可以对数据库中的数据和索引重新进行组织，以及能够设定在满足一定条件的情况下，维护计划自动删除数据库中的未使用的空间，以便提高性能。

但要注意的是，在此窗体中，只要选定了“重新组织数据和索引页[R]”复选框，“更新查询优化器所使用的统计。示例[D]”复选框将失效(变成灰色，不能选择)。而且“重新组织数据和索引页[R]”复选框和“从数据库文件中删除未使用的空间[M]”复选框二者只要有一个被选中，其下的“调度[S]”功能才有效。单击“更改[C]”按钮可以对“调度”进行自定义。

各位读者可以根据自身情况决定是否选用其中的功能。当然也可以通过单击“帮助”按钮来查看各功能的具体含义。

在此窗体中能够便捷地设定每项作业的持续运行时间和运行的频率。完成自己的设置后，一定要选定右上角的“启用调度[B]”复选框，这样一个作业调度才算真正完成了。

步骤3：单击图3中的“下一步(N)”按钮，打开“检查数据库完整性”窗体。

在此窗体中可以设定维护计划在备份数据库前自动检查数据库的完整性，以便检测由于硬件或软件错误而导致数据的不一致。在此窗体中只有先选定了“检查数据库完整性[H]”复选框，其下的“备份之前执行这些检查[R]”和“调度[S]”功能才有效。单击“更改[C]”按钮可以对“调度”进行自定义。

各位读者可以自主决定，较好的一种做法就是选中“检查数据库完整性[H]”复选框(推荐，因为有可能会修正一些错误)。

步骤4：在“检查数据库完整性”窗体中的“下一步(N)”按钮，打开“指定数据库备份计划”窗体。

如需对数据库进行备份，则必须选定“作为维护计划的一部分来备份数据库[A]”复选框，而且必须指定存储备份文件的位置：磁带[P]或磁盘[K]。

如果选择“磁盘[K]”作为数据库备份的位置，设定“调度”后单击“下一步(N)”按钮则显示“指定备份磁盘目录”窗体(如图4)。

图4

在图4中，可以具体指定存储备份文件的目录(可以使用默认的目录，也可自定义)、备份文件扩展名，而且能够指示备份计划自动地删除早于某个时间(图4中设定的是“2天”，也就是说两天前的所有备份文件将被自动地删除，只留下最近两天的备份)的备份文件。而图4中的“为每个数据库创建子目录[C]”功能只是在步骤1中选择了多个数据库时才有用，对于一个数据库作用不大。设定后，单击“下一步(N)”按钮则显示“指定事务日志备份计划”窗体。

如果选择“磁带[P]”作为数据库备份的位置，设定“调度”后单击“下一步(N)”按钮则直接显示“指定事务日志备份计划”窗体。

步骤5：指定“事务日志备份计划”的过程与步骤4的过程完全相同，只是在设定“调度”上稍有差别(因为我的要求是数据库每天备份一次，事务日志每1小时备份一次)。

步骤6：对事务日志的备份计划全部设定后，单击“下一步(N)”按钮则显示“要生成的报表”窗体。

在此窗体中可以指定用于存放整个备份计划执行过程中的日志的目录。设定过程与图4的操作及其相似。

图5

步骤7：完成步骤6后，单击“下一步(N)”按钮则显示“维护计划历史纪录”窗体。

在此窗体中可以指定如何存储此维护计划的历史纪录(是存放在“本地服务器”上，还是在“远程服务器”上)，而且通过指定表中的行数可以限定历史纪录的存储大小。

步骤8：完成步骤7后，单击“下一步(N)”按钮则显示“正在完成数据库维护计划向导”窗体(如图5)。

在此窗体中可以自定义一个“计划名[P]”(推荐，这样便于管理和识别)，当然也可使用默认的“计划名[P]”。而且还可以通过对“计划名[P]”下的文本框中的内容进行确认，如有误，则可通过单击窗体中的“上一步[B]”按钮退回到相应的窗体进行修改。

步骤9：完成步骤8后，单击“完成”按钮，则显示“维护计划已创建成功。”的提示框，再单击 “确定”按钮即成功地设定了一个新的数据库维护计划。

从图6中可以看到，已经成功的创建了一个新的数据库维护计划——“regie备份”。

第四步：维护和管理“数据库维护计划”

第三步完成后，对各个“数据库维护计划”的日常维护和管理都非常方便，只需要双击“数据库维护计划”即可对第三步中所涉及的内容进行变更、修正。

图6

如图6所示，鼠标右击“regie备份”，单击“属性[R]”，或者直接双击“regie备份”，打开“数据库维护计划”窗体。在此窗体中集成了第三步中涉及到的所有功能，每项功能都能任意修改，修改过程与第三步中的相应步骤一样。

但需要说明的是，在设定图7中的“报表”选项卡下的“文本报表”中的“删除早于此时间的文本报表文件[F]”选项时，也就是第三步中的步骤6中的内容，无论您将其设定成“分钟”、“小时”、“天”，还是“月”，创建成功后都将被自动地更正为“周”，而且以后无论如何修改，保存后再去查看时它仍将显示为“周”，但不意味着其它选项无效，其它选项仍然有效。

图7

第五步：启动SQL Server 2000代理以便执行“作业”

完成第三步后，还需启动SQL Server 2000 Agent(代理)，以便执行“数据库维护计划”作业。

与展开SQL Server 2000“数据库维护计划”的步骤一样，在“管理”项目中，可以发现存在一个“SQL Server 代理”(如图8)。

图8

单击“SQL Server 代理”下的“作业”子菜单，在“企业管理器”窗口右侧将会显示出已经存在的作业项目(在图8中可以看到已经存在17个作业项目)。每个作业项目均包括以下数据列：

1.名称：当然是指作业的名称，可以自定义，中英文皆可。为了理解方便，建议用中英文结合。

每当新建立一个“数据库维护计划”，将自动生成以下默认名称的作业：

(1)当新建的“数据库维护计划”中设定了“备份数据库”功能时，将生成默认名为“DB 维护计划‘******’的 DB 备份作业”的作业。

(2)当新建的“数据库维护计划”中设定了“备份事务日志”功能时将生成默认名为“DB 维护计划‘******’的 事务日志备份作业(多服务器)”的作业。

以上(1)和(2)中的“******”处将显示“数据库维护计划”中的“计划名”(也就是第三步步骤8中设定的“计划名”)。

2.分类：指明该作业当前所属的类别。缺省值为“[未分类(本地)]”。

3.启用：指明该作业是否处于“启用”状态。

4.可运行：指明该作业是否处于“可运行”状态。

5.已调度：指明该作业是否处于“已调度”状态。

6.状态：指明该作业当前的运行状态—不在运行、正在运行。

7.上次运行状态(开始日期)：显示最近一次运行该作业后的状态(“已成功”、“失败”，还是“未知”)，和运行时的日期和时间。

8.下次运行日期：指明下一次运行该作业的日期和时间。

如图8所示，鼠标右击“regie完全备份”作业，单击“属性[R]”，或者直接双击“regie完全备份”作业，打开作业的“属性”窗体。在此窗体中集成了该作业的详细的配置项。每个配置项都能任意修改。“属性”窗体中有四个选项卡：

◆ 常规：在此选项卡中可以重新设定作业名称(“名称[N]”文本框)、修改作业的分类(“分类[Y]”下拉框)、指定作业的所有者(“所有者[W]”下拉框)、简单地对作业进行描述(“描述[R]”文本框)，以及决定是否启用此作业(“启用[E]”复选框)。

◆ 步骤：在此选项卡中可以新建、插入新的步骤，删除、编辑已有的步骤。

单击“编辑[E]”按钮，在“编辑作业步骤”窗体中的“常规”选项卡中的“命令[M]”文本框中可以查阅到该作业的执行语句。

◆ 调度：在此选项卡中可以新建调度、新建警报，删除、编辑已有的调度。

◆ 通知：在此选项卡中可以设定作业完成时(即当作业成功时、作业失败时)执行的操作，即发送电子邮件、传呼操作员、发出网络警报信息、写入Windows应用程序事件日志、自动删除等操作。

第六步：检查结果

经过上述五个步骤后，一个完整的备份数据库的计划就建立起来了。可以通过“资源管理器”来检查备份目录下是否存在相应地备份文件。

经过长时间的使用，如果以“保留2天的数据库完全备份和2天的每个一小时的事务日志备份”的备份策略来正确地建立了一个完整的数据库维护计划的话，无论何时查看相应备份目录下的文件，都应该存在102个文件：

◆2个数据库的完整备份，即2个以“数据库名_db_yyyy mmddhhss.bak”格式为文件名的文件；

◆ 3个与数据库完整备份相对应的操作过程的记录报告文件，即以“数据库名”+“备份4_yyyymmddhhss.txt” 格式为文件名的文件；

◆ 48个事务日志的差异备份，即2天各24个以“数据库名_tlog_yyyymmddhhss.trn”格式为文件名的文件；

◆ 49个与事务日志的差异备份对应的操作过程的记录报告文件，即以“数据库名”+“备份6_yyyymmddhhss.txt” 格式为文件名的文件。

以上文件名中，“数据库名”为第三步的步骤一中选定的数据库的名称；“yyyymmddhhss”是时间戳，其格式为：“yyyy”指“年”(4位数值)，“mm”指“月”(2位数值，不足2位的补“0”)，“dd”指“日”(2位数值，不足2位的补“0”),“hh”指“时”(2位数值，不足2位的补“0”)，“ss”指“分”(2位数值，不足2位的补“0”)。

结束语

对于一个企业而言，日常运作中发生的各种业务所产生的所有数据，经过计算机不断地日积月累，逐渐成为公司的一种财富和资本。利用计算机，可以便捷地统计分析部分或全部的数据，通过各种形式的反馈(如图表、表格等)，给公司的决策层用于参考，便于为公司的今后决策提供指导和帮助。正基于此，这些数据的价值随着时间的延续正呈现出几何速度的增长。因此我认为，对于数据的备份工作是网管员日常工作中最重要的工作之一。

通过这次“数据库维护计划”的创建，我略有感受：

1.经过这么长时间的运用，我认为“数据库维护计划”仍然存在不足之处，虽说“数据库维护计划”功能很强大，但是它最终的结果是生成一项作业，由“SQL Server 2000 Agent”服务定期执行它来完成对数据库的备份工作。这就要求“SQL Server 2000 Agent”服务能够正常地“运行”。从多次安装来看，在Windows 2000系统中“SQL Server 2000 Agent”服务能够正常运行，而且能随Windows 2000的启动自动运行。但是在Window 98系统(包括第二版)中，却不能正常运行。所以说，在Windows 98系统中即使依照上述步骤成功地创建了“数据库维护计划”，也会因为“SQL Server 2000 Agent”服务无法启动而变得没有任何作用。

2.之所以选择“完全备份”，主要在于，在进行完全备份时，SQL Server将.mdf与其对应的.ldf文件进行对比，删除一些旧的、不必要的日志，然后将.mdf和.ldf文件进行合并、压缩后一起存储。

◆ 优点是：能最大可能地、完整地保存数据库。

◆ 缺点是：存储量随着数据库的增大而增大，存储时间也将随着数据库的增大而延长。

3.在建立“数据库维护计划”过程，各位读者应该尽可能地去使用各种选项、功能，以便加深对“数据库维护计划”的理解和掌握。

4.虽然Internet上有许多第三方备份软件和工具，但是大多数是共享版。由于担心知识产权问题、病毒问题和其它问题，所以我没有试用这些第三方软件。这样的话，它们的性能我就不清楚了。也许这些软件的功能非常强大，能够满足更多的、更高的要求。在这里我只是就Windows 2000和SQL Server 2000自带的“备份”工具和软件进行一个比较。

				--压缩日志

1:截断事务日志：
BACKUP LOG 数据库名 WITH NO_LOG

2:清空日志
DUMP  TRANSACTION  库名  WITH  NO_LOG    

再：
企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了


3: 删除LOG
	1：分离数据库   企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
	2：删除LOG文件
	3：附加数据库  企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库
	此法生成新的LOG，大小只有500多K
   再将此数据库设置自动收缩
 或用代码： 
下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。

EXEC sp_detach_db @dbname = 'pubs'
EXEC sp_attach_single_file_db @dbname = 'pubs', 
   @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'




		

				对于有两个库文件的数据库请用下面的语句：

exec sp_attach_db @dbname = 'pubs',
 @filename1 = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf',
 @filename2 = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs1_Data.NDF'


		

				如果数据库有两个日志文件，则以上方法就不行了。
需要删掉其中一个日志文件，方法如下：
截断事务日志：
BACKUP LOG otsp WITH NO_LOG

清空日志
DUMP  TRANSACTION  otsp WITH  NO_LOG    
   
删除LOG文件
	企业管理器－＞服务器－＞数据库－＞右键－＞属性－＞日志文件－＞选择第二个日志文件删除－＞确定

再按上面说的删除日志的方法去附加数据库，就成功了
		

--还不行,就关闭用户打开的进程处理,在查询分析器中执行下面的语句

use master
go

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[p_killspid]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [dbo].[p_killspid]
GO

create proc p_killspid
@dbname varchar(200)	--要关闭进程的数据库名
as  
	declare @sql  nvarchar(500)  
	declare @spid nvarchar(20)

	declare #tb cursor for
		select spid=cast(spid as varchar(20)) from master..sysprocesses where dbid=db_id(@dbname)
	open #tb
	fetch next from #tb into @spid
	while @@fetch_status=0
	begin  
		exec('kill '+@spid)
		fetch next from #tb into @spid
	end  
	close #tb
	deallocate #tb
go

--用法  
exec p_killspid  'statmemberdata'
go
DBCC SHRINKDATABASE (statmemberdata)
go

drop proc p_killspid










删除数据文件
dbcc shrinkfile (db_data2 , emptyfile)
alter database db
remove file db_data2
go

参考链接：
http://support.microsoft.com/?kbid=814579
http://www.experts-exchange.com/Databases/Microsoft_SQL_Server/Q_21090815.html
http://support.microsoft.com/default.aspx?scid=kb;zh-cn;317375
http://www.weste.net/html/200409/20040904QBI110037.html
http://www.knowsky.com/18746.html