补充问题:
  1.重新安装数据库之前,系统中原来的数据库系统应该卸载掉对吧,卸载过程需要注意什么?
  2.在安装数据库的时候,操作系统(win2k advance server sp4)的设置有没有需要注意的地方?顺便顶一下...

解决方案 »

  1.   

    不知道楼主的崩溃到什么程度?
    大致如下
    1. 备份可用的数据, 包含所有系统数据库和用户数据库的数据文件和日志文件(*.mdf/ldf/ndf)
    2. 御载原来的安装
    3. 系统表查找和删除所有的mssqlserver项
    4. 磁盘上删除安装sql产生的所有文件5. 重新安装sql server和打相应的补丁6. 单用户模式下恢复master数据库
    7. 恢复其他系统数据库
    8. 恢复用户数据库
    如果楼主时间比较充分,而且想尽量恢复数据到最近的时间点, 可以在上述步骤中做下面的尝试
    1. 把6,7两步改为:
    a. 停止sql服务
    b. 用步骤1备份的系统数据库的数据文件和日志文件替换安装后生成的系统数据库的对应文件
    c. 建立与重新安装sql之前一样的用户数据库的存放目录, 并且把用户数据库文件按原文件存放
    d. 启动sql服务
    e. 如果sql服务成功, 在企业管理看看用户数据库有没有置疑, 如果没有置疑, 则其他操作都不用做了, 数据已经恢复
      

  2.   

    注意:
        在做上面的步骤b之前, 先备份准备覆盖的文件2. 如果步骤1的尝试不成功, 则再做下面的尝试, 把步骤8修改为下面的
       a. 停止sql服务
       b. 用备份的文件还原被覆盖的文件
       c. 尝试用附加的方式恢复用户数据库
       d. 如果成功, 则修复各用户数据库中的孤立用户
      

  3.   

    下面是恢复处理中会涉及到的一些具体的技术:
    如何恢复系统数据库? 
     
    关于系统数据库的恢复总结如下: 在SQL Server数据库中,系统信息存储在系统数据库中,主要的系统数据库包括: 
    master-从整体上控制用户数据库和SQL Server操作,在创建了任何用户定义的对象后,都要备份它
    model-为新数据库提供模版和原型 
    msdb-包含了有关作业、报警及操作员等信息如果包含系统数据库的介质变了,那么必须重建系统数据库,如果你仍然可以启动SQL Server服务,则可以通过RESTORE语句从系统数据库的备份中恢复数据库。 
      如果master坏了,不能启动系统,可以按照下面步骤进行恢复 
    1.重建系统数据库 运行c:\mssql7\binn\rebuildm.exe,按照提示进行即可,
    过程中需要系统数据库样本的路径,可在安装光盘中找到; 2 重建系统数据库后,启动SQL Server服务,用系统数据库的备份恢复数据库
    就行了通常恢复顺序为master->msdb->model 
    在恢复master的备份时要注意:必须在单用户(single user)模式下进行a.进入单用户模式的方法: 
    1.在命令行模式下输入sqlservr -c -f -m或者输入sqlservr -m 
    其中:-c 可以缩短启动时间,SQL Server 不作为Windows NT的服务启动 
    -f 用最小配置启动SQL Server 
    -m 单用户模式启动SQL Server  2.可以在控制面板-服务-MSSQLServer的启动参数中输入-c -f -m或者输入-m,点击开始 
      
    3.进行master数据库的恢复
    a.直接进入查询分析器,有个提示不要理会它
    输入恢复语句进行数据库恢复:
    RESTORE DATABASE master from disk='c:\具体的备份文件名'b.或者用这个,在命令提示符下输入,注意大小写
    使用"windows身份验证"的,输入:isql /E
    使用"sql server和windows身份验证"的,输入:isql /U"用户名" /P"密码"
    然后在出现的提示符下输入(注意1>,2>是提示符):
    1>RESTORE DATABASE master from disk='c:\具体的备份文件名'
    2>go
      

  4.   


    还原数据库的具体步骤
    企业管理器中的操作:1.恢复最近一次的完整备份
    企业管理器--右键"数据库"--所有任务--还原数据库
    --"还原为数据库库"中输入还原后的数据库名,设为:test
    --还原选择"从设备"--选择设备--添加--添加你的备份文件
    --确定,回到数据库还原的界面
    --"还原备份集",选择"数据库--完全"
    --选项--将"移至物理文件名"中的物理文件名修改为你的数据文件要存放的文件名
    --如果要还原的数据库已经存在,选择"在现有数据库上强制还原"
    --"恢复完成状态",选择"使数据库不再运行,但能还原其它事务日志"
    --确定--或用SQL语句:
    restore database 数据库 from disk='c:\你的完全备份文件名' with norecovery
    2.恢复完全备份后, 最近一次的差异备份(如果有的话)
    企业管理器--右键"数据库"--所有任务--还原数据库
    --"还原为数据库库"中选择数据库名:test
    --还原选择"从设备"--选择设备--添加--添加你的备份文件
    --确定,回到数据库还原的界面
    --"还原备份集",选择"数据库--差异"
    --"恢复完成状态",选择"使数据库不再运行,但能还原其它事务日志"
    --确定--或用SQL语句:
    restore database 数据库 from disk='c:\你的差异备份文件名' with norecovery
    3.按时间先后, 恢复差异备份后(如果没有差异备份,则是完全备份)的所有日志备份
    企业管理器--右键"数据库"--所有任务--还原数据库
    --"还原为数据库库"中选择数据库名:test
    --还原选择"从设备"--选择设备--添加--添加你的备份文件
    --确定,回到数据库还原的界面
    --"还原备份集",选择"事务日志"
    --"恢复完成状态"
       如果是恢复最后一个日志文件,选择"使数据库可以继续运行,但无法还原其它事务日志"
       否则选择"使数据库不再运行,但能还原其它事务日志"
    --确定--或用SQL语句:
    restore log 数据库 from disk='c:\你的日志备份文件名' with recoveryrestore log 数据库 from disk='c:\你的日志备份文件名' with recovery
      

  5.   

    解决孤立用户:1. 查看某个数据库的孤立用户:
    use 库名
    EXEC sp_change_users_login 'Report'2. 自动修复某个孤立用户:
    use 库名
    EXEC sp_change_users_login 'Auto_Fix', '孤立用户名', NULL, '密码'  --密码指用户对应的登录不存在时, 系统自动建立登录, 为登录分配的密码
      

  6.   

    邹大哥:-) 所谓的崩溃倒也不完全是数据库系统的"崩溃"....
    就是以前那个错误提示始终无法得到解决啊?
    SqlDumpExceptionHandler:进程61发生了严重的异常...[严重度: 19]详见:http://community.csdn.net/Expert/TopicView.asp?id=4828837这个错误随机出现,没有规律,也找不到原因。在这里找了很多办法,也没能解决啊。
    应用程序日志里只要一出这个故障,业务程序就崩溃了,业务一出问题,我就挨批了。
    所以啊....  不是数据库崩溃,是我快崩溃了啊 呵呵没辙,这不....只好寻求大家的帮助,重装并且恢复数据库了啊!
      

  7.   

    邹建大哥:
        我也是病急乱投医了,不知道我这样重装数据库系统并还原备份的数据库。能不能从根本上解决那个(SqlDumpExceptionHandler:进程61发生了严重的异常...[严重度: 19])错误。究竟这个错误是系统造成的? 还是业务程序调用了不规范的存储过程造成的?还是说数据库本事的问题(设置问题?还是数据库系统内部故障?)?关键是我无法确定故障产生的原因啊!!! 所以无法对症下药啊!!!所以.... 我也只好抱着重新安装,试一试的心态....但愿能彻底解决这个问题吧!
      

  8.   

    嗯 只好这样了
    我准备好了一台server,打算把数据库装的这台机器上,和应用服务器以内网的形式连接。等我回复完毕后,再来给邹建大哥和大伙们做汇报。 呵呵....
      

  9.   

    错误: 7987,严重度: 22,状态: 1
    在数据库 'CMPP' 中检测到一个可能的数据库一致性问题。应该对数据库 'CMPP' 运行 DBCC CHECKDB 和 DBCC CHECKCATALOG。 
    数据:
    0000: 33 1f 00 00 16 00 00 00   3.......
    0008: 08 00 00 00 5a 00 58 00   ....Z.X.
    0010: 30 00 36 00 31 00 30 00   0.6.1.0.
    0018: 38 00 00 00 05 00 00 00   9.......
    0020: 43 00 4d 00 50 00 50 00   G.M.P.P.
    -----------------------------------------
    这个错误,我用了如下操作:
    USE MASTER
    GO
    sp_dboption 'gmpp', 'single user', 'true'
    Go
    DBCC CHECKDB('gmpp',REPAIR_ALLOW_DATA_LOSS)
    dbcc checkcatalog('gmpp')
    go
    sp_dboption 'gmpp', 'single user', 'false'
    Go
    结果没有报告任何错误,之后错误日志依据会出现。
    gmpp是我的用户数据库。
    还请邹建大哥给与指导阿!
      

  10.   

    严重级别 22:SQL Server 严重错误表的完整性置疑这些消息表明消息中所指定的表或索引已因软件或硬件问题而损坏。严重级别 22 错误很少发生;但是,如果遇到该错误,请运行 DBCC CHECKDB 确定数据库中是否有其它对象也受损坏。问题有可能只存在于超速缓存中,而不是存在于磁盘本身。如果是这样,重新启动 SQL Server 将修正该问题。要继续工作,必须重新连接到 SQL Server。否则,用 DBCC 修复该问题。有些情况下,有必要还原数据库。如果重新启动帮助不大,则问题存在于磁盘上。有时,摧毁在错误信息中指定的对象可以解决该问题。例如,如果消息说 SQL Server 在非聚集索引中发现长度为 0 的行,删除该索引然后重建。
      

  11.   

    遇到这个问题后,我重新起动过sqlserver,虽然问题不是时刻都出现,
    但是故障在之后不久还是会出现的。您说的:
    “有时,摧毁在错误信息中指定的对象可以解决该问题。例如,如果消息说 SQL Server 在非聚集索引中发现长度为 0 的行,删除该索引然后重建。”
    我该如何理解呢?我又该如何去具体操作呢? 我除了用以下这个方式外(以下方式操作后,之后问题还是会出现):
    ----------------------
    USE MASTER
    GO
    sp_dboption 'gmpp', 'single user', 'true'
    Go
    DBCC CHECKDB('gmpp',REPAIR_ALLOW_DATA_LOSS)
    dbcc checkcatalog('gmpp')
    go
    sp_dboption 'gmpp', 'single user', 'false'
    Go
    ----------------------
    还有其他判断故障点并解决故障的办法么?
      

  12.   

    我指的"不久"并非是很短的时间,一天最多的时候也就发作5-6次了。
    日志中的这个提示让我很是奇怪。提示我使用dbcc checkdb和dbcc checkcatalog
    可是操作的时候又检查不出来任何的问题,这又该让我怎么做下一步呢?
    我真的很迷惑....我究竟下一步该怎么做呢???如果知道问题出在哪里,也好去找解决的办法。
    可是现在的问题是,我遇到这些问题的时候,根本找不到导致故障的原因。
    这才是我最困惑的。走投无路了.... 总不能出现问题就恢复数据库、重装数据库吧。我知道这是走极端。可是问题长时间解决不了,是很让人难受的一件事情。心情比较沮丧:-(
      

  13.   

    汇报工作:
    连续两天都没有出现那个错误提示了,不知道什么原因?
    也搞不明白如何解决的?
    不过我做了如下的一些操作...
      1.对经常读写的所有表进行了 DBCC DBREINDEX(表名,'',100).
      2.将数据库的动态内存最大值调整到512M(原来这个值是768M.机器的物理内存为1G).
      3.对后台管理登录脚本ASP做了防注入处理,增强了其安全性.
      4.在硬件管理中禁用了另外一块暂时没有用的网卡.
      5.通过IP安全策略关闭了UDP1434、TCP1433端口,仅仅开放给某个固定IP使用.
    ===================================
    能记住的就这些操作了,观察了两天,应用程序日志中没有发现这个错误。
    但愿能解决掉这个让人忧心的问题了继续观察 发现问题再来讨教... 
      

  14.   

    问题又开始了
    我不活了 tnnd