备份类型 事务日志_Replace函数中小小,引发的灾难，借助事务日志恢复数据

Replace函数中小小’’,引发的灾难，借助事务日志恢复数据

在基层医院信息科，处理日常维护繁杂琐碎的事情，也有时前一秒还在平凡中度过，下一秒就会血压飙升，惊险刺激中度过。在医院信息科我们会经常因为某些原因进行数据库操作，对数据进行处理。

前情回顾：

因为医院更换名称，9月份lis系统重新注册医院名称，更新注册文件。更新文件后其他仪器设备报告一切正常，只有尿常规仪器lis界面结果出现未注册。

 

Lis工程师多次查找原因，未找到明确原因，设备重新注册后结果还是有未注册。

与检验科主任沟通的解决方案为：

1、检验科医师做完结果后  审核时手工删除未注册，进行审核。

2、信息科通过数据库批量修改，替换未注册。检验科审核核对。

3、病人量大体检客户多时，检验科医师手工删除不现实。门诊和住院病人急需检验报告时，检验科医师手工删除，审核报告，体检病人信息科通过数据库批量操作，检验医师审核。

不知道其他医院信息科同仁在遇到这种情况时有什么更好的解决方案？

就这样信息科和检验科愉快的合作运行了几天。信息科一直督促lis工程师查找原因。

不同寻常的周末

就在周末在家休息时，9点左右看到医院微信群有人说停电，心中一阵不爽，机房空调肯定停了(基层医院条件有限，配备的ups电源只供服务器、存储设备、网络交换机、无线)，只能去医院来电后开启空调。到医院后和维修人员沟通后，预计要到晚上19:00才能修好，而且还不一定。心中快速估算ups供电时间，是否能坚持到晚上来电。

惊魂时刻：

周二下午一上班，准备修改更正体检尿常规结果，lis数据库使用sql server 2008r2,打开数据库，准备进行修改。前几天修改均正常，对这次修改也是信心满满。先查询下

 

编写sql语句，执行update。

执行完后，查询结果，血压迅速飙升，头顶一直冒汗。今天体检的尿常规检验结果怎么全都成’csjg’ 了。

 

仔细检查sql   语句， 发现replace函数

--update lab_result set csjg=replace('csjg','未注册','') where **************   ，发现replace函数第一个参数加了’’,导致csjg 这列内容成为csjg。原有结果更新错误，原有结果丢失。尿常规的标本尿杯检验科一般做完后直接丢弃，不同血液标本会保存一段时间。重新检测已经不存在可能性。

Sqlserver中Replace函数：实现字段中某个字符串批量替换。

注意：强烈建议替换前备份数据库以免发生灾难性后果。

如果字段类型为text，会报错：参数数据类型 text 对于 replace 函数的参数 1 无效。

对text或ntext类型的数据在查询中不能进行字符串操作。这时用得最多的是把text当作varchar(实际内容长度低于8000字节时)或把ntext当作nvarchar(实际内容长度低于4000字节时)来处理。

特别提醒：

在使用replace函数时，第一个参数一定不要加引号：

比如：update lab_result set csjg=replace('csjg','未注册','');

它会将csjg字段全部替换为csjg字符串，这就是灾难性后果，所以前面提醒要备份。

越是面对突发事件时，数据灾难发生越要冷静，想到解决问题的办法。如何恢复数据，获取当天的原有检验结果至关重要。这时，检验科主任也来了，lis系统的检验结果，同检验科主任协商尽量最短时间内恢复数据。突然想到，检验科检验结果仪器和lis系统间是通过接口传输结果的，找到接口小程序就能找到存放标本结果的txt文件。快速到检验科尿常规仪器，在电脑上快速找到存放结果的result文件夹中的今天的文本文件，检验科可依据今天的文本文件按照标本序号重新录入结果。文本文件中的结果不会丢失，确保有一道数据保障。

恢复数据至关重要，sqlserver  数据库可以通过事务日志恢复到今天更改数据之前的时间点。

(1)重点前期做过完整模式下完整备份。 

 切记，对于任何重要环境，不仅仅是客户正式环境(俗称生产环境)，都强烈建议使用【完整恢复模式】，虽然对于另外两种(大容量日志(BULK_LOGGED)、简单(SIMPLE))来说，完整恢复模式产生的日志会大，但是在出现问题的时候，就会觉得这些都不算什么了。并且我也想不到任何理由对于正式环境不使用完整恢复模式。只要管理得当，完整恢复模式的日志也不会太变态。

医院数据通常设置为每天自动备份一次或者两次，有的要求甚至多次。目的就是为了在数据灾难或者异常发生时最大限度的恢复数据。

通过

SELECT database_name,recovery_model,name FROM msdb.dbo.backupset

 

(2)发生数据更新失败数据错误或者deltet时，确保不再有用户连接数据库，不再有新数据产生。抓紧备份事务日志。通过事务日志进行数据恢复。抓住最后的救命稻草。

备份选择事务日志

 

然后在【选项】页选择：除【事务日志】除，其他红框包裹的地方为强烈建议勾选的地方。并且保证数据库不要有别人在连接，因为备份日志尾部会使数据库处于还原状态，拒绝其他会话的连接，如果不断开其他连接，是备份不了的。

 

 

事务日志备份完成，数据库的状态变成还原状态。

如果不能备份提示有其他连接，查看连接的spid，并kill 掉。

SELECT * FROM sys.sysprocesses WHERE dbid=DB_ID('lisnet')

(3)进行还原最近的一次完整备份。由于日志备份的特性，只认最后一次备份，所以要选择最新的那次，否则还原不了。

 

最重要的 【选项】

 

 

最后提示还原成功。如果数据量大，还原时间相对较长。

接着还原出现数据丢失后备份的事务日志文件

 

 

时间点选择数据丢失之前的时间点

 

还原成功后，再次查询数据，数据恢复成功。

 

数据恢复成功。

  在此提醒各位同仁任何有关数据的操作都要提前备份，慎重、慎重、再慎重，最好采用双人核查机制，并建立适合自己医院科室的数据更改流程。数据恢复成功了挽回不必要的损失。如果数据不能成功恢复，那真的就是事故了。

熟练掌握数据恢复的方法，在数据发生异常时，快速恢复数据，恢复生产。

为传递更多信息学习之用，版权归原作者所有，如有侵犯版权，请及时联系我们，及时删除。如果你喜欢本文，请分享到朋友圈，想要获得更多信息，请关注我。

戳

我就知道你“在看”