急，数据表无故丢失！！

[jomph]

我们公司有一台服务器用于接收企业发过来的数据，有100多个企业，每30秒会发一次数据过来（实际上只有80多个企业有发数据过来），我们就是要接收并储存数据的，接收到数据还会拆分成多条数据存放，由于数据量比较大，所以一个企业分配一个表，此为背景。

数据库是用2008 r2 的，有40多张表是手动建上的，用于存放基础资料及相关信息的，然后上面提到的企业数据表是通过存储过程创建上的，问题就是服务器在正常运行当中，那些企业数据表突然间全部丢失了（有数据的和没数据的都不见了），丢失都是通过存储过程所创建的表，而手动创建的一个不少！

接收软件及存储过程中均不会有drop table的语句，所以不可能是误操作导致调用了删表的语句。人为删除的可能也排除，这个就不多解释了。

本人对数据库的了解并不深入，所以想跟各位高手请教一下，什么情况下会导致数据表丢失？由于丢失的都是自动创建的表，那是否跟create table语句有关？如果是因为写进数据库的时候出现了意外，为什么那20几个企业没发过数据过来，但它们的表也会丢失了？

[發糞塗牆]

我没用过，但是别人说可以用的

[jomph]

我设置了时间段读取，但它一直在reading

[發糞塗牆]

你太久没备份日志了吧

[我纯洁全身都纯洁]

大牛们的回答看得我欲仙欲死！

[俺是大菠萝]

1、恢复一个最近的备份，尽量找回数据 2、应用连接数据库账号权限仅授予读写、执行存储过程的权限 3、禁用sa，单独创建有sysadmin权限的账号，并专人保管 4、检查存储过程，确认没有drop这样的DDL操作 5、创建数据表监控，只每天监控一下数据表的大小即可； 已经错过的场景无法重现了，只能亡羊补牢，做好后面的；

[發糞塗牆]

下个apexsql 分析一下日志文件

[發糞塗牆]

log exploer不支持2008及以上版本

[yoan2014]

可以尝试用DDL触发器看看

CREATE TRIGGER safety 
ON DATABASE 
FOR DROP_TABLE, ALTER_TABLE 
AS 
   PRINT 'You must disable Trigger "safety" to drop or alter tables!' 
   ROLLBACK ;

[霜寒月冷]

排除人为原因的话，真想不到会有其他的可能，会不会语句里面有问题，要么你的存储过程语句贴上来看看，隐私的部分你注释掉...

[Tiger_Zhao]

“储过程创建的表”和“手动创建的表”用的是不是同一个文件组？
会不会是文件损坏——硬盘故障？

[--小F--]

2008以上已经无法读日志文件了 祝你好运。

[jomph]

引用 4 楼 chz415767975 的回复:

排除人为原因的话，真想不到会有其他的可能，会不会语句里面有问题，要么你的存储过程语句贴上来看看，隐私的部分你注释掉...

主要创建表的语句就是这里， 其中@fieldvalue是企业编号，表是根据企业编号命名的，企业编号只会包含字母、数字及下划线

if not exists(select * from SYSOBJECTS where name=@fieldvalue)
			begin
					set @TempSql='create table '+@fieldvalue+'(DataTime datetime not null,PointCode varchar(20) not null,FactorID int not null,DataType int not null,dataValue decimal(18,8) null,ConvertValue decimal(18,8)  null,StateValue varchar(1) null,WriteTime datetime null,DevCode varchar(10) null,constraint PK_'+@fieldvalue+' primary key (DataTime,FactorID))'
					exec(@TempSql)
			end

[jomph]

企业编号都是这样的格式： D_5N_XXXX_XXXX (X是数据)

[jomph]

引用 5 楼 Tiger_Zhao 的回复:

“储过程创建的表”和“手动创建的表”用的是不是同一个文件组？ 会不会是文件损坏——硬盘故障？

是同一个文件组，不排除文件损坏的可能，但为什么丢的都是用语句创建的表（不管表里是否有数据），而手动创建的表却一点数据都没丢，而且有一些表还比自动创建的表要晚创建的，也没问题。

[道玄希言]

有没有可能是你们服务器中招了，被人SQL注入，而干掉了你的资料？

[jomph]

企业编号都是这样的格式： D_5N_XXXX_XXXX (X是数字) 上面写错了

[jomph]

引用 10 楼 yangb0803 的回复:

有没有可能是你们服务器中招了，被人SQL注入，而干掉了你的资料？

这种情况不可能，我们的服务器是内部网络，而且路由上只开放了一个端口映射到服务器，这个端口只是数据传输用的，只有接收软件用到，数据库是不公开的

[道玄希言]

有米有每天甚至是实时备份額～ 一是要考虑被删除原因，还有就是要数据恢复了～

[专注or全面]

你先尝试一下3楼提供的触发器，记录一下drop table的登录信息和日志 另外建议不好轻易排除某种可能，问题的原因往往就是“不可能是**原因”的原因

[小灰狼]

可以考虑设置一下数据库用户权限，不要把 sa 给这个进程，另外创建一个没有删除表的权限的用户给这个进程使用，在程序里捕捉异常，写好日志，看能否定位到哪个地方