我一直在从一个服务器恢复SQL 2005数据库到另一个（类似的规范，相同的版本和服务包等），并遇到以下情况。
问题从数据库的还原开始 – 还原过程正常工作我使用pipe理工作室并执行还原完成没有问题，所有的数据在那里，可以使用。 但是，当我尝试运行现有的维护计划备份时，出现以下错误：
执行失败。 有关详细信息，请参阅维护计划和SQL Server代理作业历史logging日志。 附加信息 – > Job'Full_Backup.Subplan_1失败。 （SQL ManagerUI）附加信息给我下面的程序位置：在Microsoft.SqlServer.Management.SqlManagerUI.MaintenancePlanMenu_Run.PerformActions（）
在这个时候，我尝试重新创build维护计划，当我select数据库作为完整备份的一部分时，我刚刚恢复的数据库从select窗格中丢失。
我已经在2台“新鲜”的服务器上复制了这个问题，同时安装了新的SQl服务器2005.对于我来说，恢复操作是罪魁祸首，所以如果有某种方式可以跟踪某个系统数据库，然后可以调查。
这是几个星期的烦恼，任何帮助将不胜感激。
我似乎偶然发现了答案。 看起来原来的SQL服务器是从7升级到2000到2005！ 疯狂，但显然已经使用了8年之久，在我的时间之前。
该问题似乎与数据库兼容性有关，请参阅以下msoft文章
链接文本
“不显示设置为兼容性级别70或更低的数据库”
我已经testing了这个通过改变水平到90，果然现在可以工作。
感谢所有回复的人，这个网站将会非常有用。
一个问题可能是这些数据库中存在的用户，并且可能不具有与另一个服务器上相同的SID。 Maby维护计划是使用孤立用户的凭据执行的。 MS SQL有一个存储过程可以修复那些孤儿用户：sp_change_users_login
只需从SQL Management Studio转到新服务器上的数据库，转到安全性并查看该数据库上的login信息。 然后为每个用户执行修复命令。
使用数据库
走
sp_change_users_login'auto_fix'，'用户名'
走
– 其中“数据库”是您恢复的数据库的名称。
由于这些数据库正在从一个服务器移动到另一个服务器，所以您可以检查Master中的sysdatabases表以查看是否存在不一致。 如果dbids不同步，则旧的维护计划可能会在查看还原的数据库时遇到问题。
您可能会发现，这与恢复数据库后刷新对象资源pipe理器一样简单。 SSMScaching了大量的信息，所以不需要一遍又一遍地重复使用相同的数据，更不用说已经拥有caching中的数据的性能改进了。 创build维护计划可能是读取caching信息的一个地方。