V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
rockpine
V2EX  ›  程序员

请教棘手的 SQLSERVER 数据丢失的问题

  •  
  •   rockpine · 2019-08-26 13:19:27 +08:00 · 3351 次点击
    这是一个创建于 1916 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我们一个使用 MS SQLSERVER 数据库的重要应用系统,丢失了大约 4 天的数据,也是很诡异的事情,现在找不到原因。
    系统的硬件使用的是 1 台 WEB 服务器+1 台 SQL 服务器+1 台光纤存储的方式,操作系统是 Windows Server 2016 标准版,数据库是 MSSQLSERVER 2008 R2,操作系统和数据库都是采购的正版。

    事情经过:
    1、23 日接到运维人员电话远程不上 SQL 服务器( DELL R930,该服务器之前也出现过这个问题,远程是黑屏界面,机房内插上鼠标键盘电源灯不亮,接显示器也是黑灰色屏),没办法,只能通过 iDrac 口远程重启。
    2、重启后,通过反查操作系统日志,发现 8 月 20 日早 8 点后一直到重启的时间点( 23 日下午 6 点),操作系统就没有任何的日志记录了(与之前出现这个问题是一样的表现)。出现异常的时间应该是 20、21、22、23 日共 4 天时间。
    3、查看应用程序日志,看到重启后 MSSQLSERVER 很多报错,但大多是报表报错,好在各个数据库启动正常。不过凭经验感觉数据库运行应该有问题,就联系技术想确认一下数据完整性。
    4、通过查看应用系统数据库中的过程表、日志表这些数据,发现最新的记录停留在了 20 日早上 8 点,也就是说 4 天操作系统异常期间的数据一条都没写进去,看到这我人都崩溃了。去查 SQLSERVER 的日志,发现这 4 天数据库也没有任何的日志记录,进一步崩溃。
    5、诡异的是,这些天应用系统是正常运行的,不管是我们内部的管理使用人员,还是对外提供服务的注册用户,都在正常使用,也从没有人提出系统使用有问题。从 WEB 服务器上看 IIS 日志,这 4 天一直是正常的。

    DELL 这台服务器从去年采购后,就经常爆出这样的问题,所以一直没敢用它跑数据,DELL、微软、供货商和我们排查了一年了,都找不出原因。今年突然有一两个月没问题了,我们就部署上应用了,然后就发生了这次导致数据丢失的严重事故。

    微软的 SQLSERVER 不应该会丢掉这么多天的数据啊,如果数据库服务停止了,那我们 WEB 与数据库的交互应该报错才对,这 4 天的数据去哪里了,还能不能找回呢。
    问题到底出在哪里,还望大神给予指点,感激不尽!
    11 条回复    2019-08-26 16:26:45 +08:00
    arrow8899
        1
    arrow8899  
       2019-08-26 13:32:00 +08:00
    是不是硬盘坏了导致数据只能读取无法写入啊,如果没重启的话还可以把内存 DUMP 出来看看,重启就没法了;
    先查下是不是硬件问题,其他也不太懂,帮顶。
    zjsxwc
        2
    zjsxwc  
       2019-08-26 13:55:43 +08:00
    换硬盘试试呗
    Fule
        3
    Fule  
       2019-08-26 14:02:02 +08:00
    4 天数据没了,但是系统不出错,确实很奇怪。。。

    1. 有没有设置每天的定时备份?备份可能选了截断日志选项?
    2. 有没有可能系统会连接到其它服务器的数据库,那 4 天的数据写到别的数据库服务器上的数据库了?

    最后你们没有每日备份么?生产数据库至少有个每日备份,备份到另一个磁盘或者服务器吧?
    saulshao
        4
    saulshao  
       2019-08-26 14:21:40 +08:00
    你描述的问题基本上没有出现的可能性。
    强烈建议你仔细审视自己的检查过程。
    sun1991
        5
    sun1991  
       2019-08-26 14:45:29 +08:00
    同样怀疑是否写到别的数据库去了, 比如测试环境数据库.
    LeeSeoung
        6
    LeeSeoung  
       2019-08-26 15:01:49 +08:00
    看下应用代码连的数据库。。还有 重要数据每天冷备,业务使用上搞主备,把风险降到最低。。

    ====================
    以上是原来想说的。。敲了一半想删,算了还是发出来,可能成本上不允许这么搞
    rockpine
        7
    rockpine  
    OP
       2019-08-26 16:12:56 +08:00
    @arrow8899 这台服务器之前出问题的时候,已经生成好几次 DUMP 了,微软的工程师看了说没有问题。这次出问题,我后悔没有生成 DUMP 文件,如果有 DUMP 文件,内存里有哪些数据说不定还能搞一些出来
    rockpine
        8
    rockpine  
    OP
       2019-08-26 16:15:09 +08:00
    @zjsxwc 我们的数据是存在存储上的,做的 RAID6,而且业务数据库中的数据记录就终止在操作系统异常的那个时刻,应该跟硬盘关系不大
    rockpine
        9
    rockpine  
    OP
       2019-08-26 16:22:37 +08:00
    @Fule
    1、没有每日备份,技术记的做了但是实际没做,这次就是看看备份的情况时发现异常的,我也是够够的;
    2、连接到其它数据库的可能性不大,因为日志、过程表是中断在早上 8 点还没有上班的时候,没人去更改代码或配置。而且中断的时间跟操作系统日志异常的时间非常吻合。
    rockpine
        10
    rockpine  
    OP
       2019-08-26 16:24:23 +08:00
    @saulshao 问题就是出现了,我也觉得不可能出现这样的状况,现在我也给领导解释不清,毕竟我自己都搞不清为啥出这样的状况。很无奈
    rockpine
        11
    rockpine  
    OP
       2019-08-26 16:26:45 +08:00
    @LeeSeoung 其实我们不是很在乎成本,毕竟数据无价。
    之前我们就是你所说的这样,数据库服务器双机热备,数据存储使用 DELL 的远程复制软件双机实时备份。
    不过由于年初业务系统调整,把这套机制给拆了,悔死了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   953 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 20:28 · PVG 04:28 · LAX 12:28 · JFK 15:28
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.