我们公司有一台服务器用于接收企业发过来的数据，有100多个企业，每30秒会发一次数据过来（实际上只有80多个企业有发数据过来），我们就是要接收并储存数据的，接收到数据还会拆分成多条数据存放，由于数据量比较大，所以一个企业分配一个表，此为背景。
数据库是用2008 r2 的，有40多张表是手动建上的，用于存放基础资料及相关信息的，然后上面提到的企业数据表是通过存储过程创建上的，问题就是服务器在正常运行当中，那些企业数据表突然间全部丢失了（有数据的和没数据的都不见了），丢失都是通过存储过程所创建的表，而手动创建的一个不少！
接收软件及存储过程中均不会有drop table的语句，所以不可能是误操作导致调用了删表的语句。人为删除的可能也排除，这个就不多解释了。
本人对数据库的了解并不深入，所以想跟各位高手请教一下，什么情况下会导致数据表丢失？由于丢失的都是自动创建的表，那是否跟create table语句有关？如果是因为写进数据库的时候出现了意外，为什么那20几个企业没发过数据过来，但它们的表也会丢失了？
------解决方案--------------------
下个apexsql 分析一下日志文件
------解决方案--------------------
可以尝试用DDL触发器看看
CREATE TRIGGER safety
ON DATABASE
FOR DROP_TABLE, ALTER_TABLE
AS
PRINT 'You must disable Trigger "safety" to drop or alter tables!'
ROLLBACK ;
------解决方案--------------------
排除人为原因的话，真想不到会有其他的可能，会不会语句里面有问题，要么你的存储过程语句贴上来看看，隐私的部分你注释掉...
------解决方案--------------------
“储过程创建的表”和“手动创建的表”用的是不是同一个文件组？
会不会是文件损坏——硬盘故障？
------解决方案--------------------
2008以上已经无法读日志文件了 祝你好运。
------解决方案--------------------
有没有可能是你们服务器中招了，被人SQL注入，而干掉了你的资料？
------解决方案--------------------
你先尝试一下3楼提供的触发器，记录一下drop table的登录信息和日志
另外建议不好轻易排除某种可能，问题的原因往往就是“不可能是**原因”的原因
------解决方案--------------------
1、恢复一个最近的备份，尽量找回数据
2、应用连接数据库账号权限仅授予读写、执行存储过程的权限
3、禁用sa，单独创建有sysadmin权限的账号，并专人保管
4、检查存储过程，确认没有drop这样的DDL操作
5、创建数据表监控，只每天监控一下数据表的大小即可；
已经错过的场景无法重现了，只能亡羊补牢，做好后面的；
------解决方案--------------------
可以考虑设置一下数据库用户权限，不要把 sa 给这个进程，另外创建一个没有删除表的权限的用户给这个进程使用，在程序里捕捉异常，写好日志，看能否定位到哪个地方