数据库作业执行失败,计划10调用了该作业

数据库作业执行失败，前正常的通过维护计划进行的数据库备份作业执行失败，并生成以下错误提示：

已以用户 XXX-999/SYSTEM 的身份执行。 Microsoft (R) SQL Server 执行包实用工具 版本 9.00.3042.00 (32 位) 版权所有 (C) Microsoft Corp 1984-2005。保留所有权利。 开始时间: 14:14:19 警告: 2010-03-19 14:14:20.17 代码: 0x80012017 源: USER_DBPlan

说明: 包路径引用了找不到的对象:“/Package/Subplan_1.Disable”。在尝试解析找不到的对象的包路径时，会出现此情况。 警告结束 DTExec: 无法将 /Package/Subplan_1.Disable 值设置为 false。 开始时间: 14:14:19 完成时间: 14:14:20 已用时间: 0.844 秒. 包执行失败。. 该步骤失败。

一、备份系统数据SYBASE 系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性。SQL Server 提供了两种不同类型的恢复机制：一类是系统自动完成的恢复，这种措施在每次系统启动时都自动进行，保证了在系统瘫痪前完成的事务都写到数据库设备上，而未完成的事务都被回退；另一类是人工完成的恢复，这是通过 DUMP 和 LOAD 命令来执行人工备份和恢复工作。因此定期备份事务日志和数据库是一项十分重要的日常维护工作。1、备份数据库每一个数据库都应在创建之后卸出，从而提供一个装入基点。在此之后按排定的时间周期表卸出。比如每周五卸出数据库。对一般数据库系统卸出数据库周期建议为每周一次。除了按计划周期卸出数据库之外，还需在每次运行没有日志的 *** 作后卸出数据库。例如：·每次强制地运行了 DUMP TRAN WITH NO_LOG （因为数据库的磁盘空溢出）；·每次用 sp_dboption 允许 select into/bulkcopy 做快速拷贝，或用 SELECT INTO 命令创建一个永久性的表，或使用了 WRITETEXT 命令。卸出数据库的命令为：DUMP DATABASE database_nameTO dump_devicedatabase_name 是要卸出的数据库名称，dump_device 是卸出设备的名称。用系统过程 sp_helpdevice 可以获得设备的信息。下面一条命令用来卸出数据库 my_db ：DUMP DATABASE my_dbTO db_bk_dev2、备份事务日志如果事务日志与数据库放在同一个设备上，则事务日志不应与数据库分开备份。master 数据库和小于 4M 的用户数据库就是这种情况。一般数据库系统的数据库和日志分别放在不同的设备上，因此，可以用 DUMP TRAN 命令单独备份日志。备份事务日志的周期直接影响数据的恢复程度，因此建议每天备份。备份事务日志的命令格式为：DUMP TRANsaction database_name[TO dump_device][WITH TRUNCATE_ONLY|WITH NO_LOG|WITH NO_TRUNCATE]其中 database_name 是要备份事务的数据库名称，dump_device 是备份设备名称，仅当包含了 WITH TRUNCATE_ONLY 或 WITH NO_LOG 子句时，才可以备份到设备。注意：如果总是用 DUMP DATEBASE （备份数据库及其日志），而不用 DUMP TRAN ，事务日志将不会刷新，而变得非常庞大。对于 master 数据库和小型数据库每次运行 DUMP DATEBASE 之后应当运行 DUMP TRANsaction 命令刷新日志 。下面一条命令备份数据库 db160 的事务日志到备份设备上：DUMP TRANsaction db160TO db_log_bk_devWITH TRUNCATE_ONLY3、备份数据库及其日志间的相互作用在至少卸出一次数据库前，卸出事务日志是毫无意义的。下图显示了备份数据库及其日志间的关系如果在星期二下午5：01出现非硬件故障，需要做的所有工作是装入磁带5（参见下一节：数据恢复），由于磁带5是下午5：00刚备份的，因此只有备份和装入之间的一分钟内的数据损失。但是，如果在星期二下午4：49失效会怎么样呢？在这种情况下，要装入磁带1（在星期五下午5：00的卸出）。然后，依次装入磁带2，3以及4。这样，系统将恢复到星期二上午10：00点的状态，星期二的大部分工作丢失了。此例显示了经常卸出事务的重要性。二、万一系统失败时恢复数据库系统如果用户数据库存储的设备失效，从而数据库被破坏或不可存取，通过装入最新的数据库备份以及后来的事务日志备份可以恢复数据库。假设当前的事务日志存在于一个并没有毁坏的设备上，带着 WITH NO_TRUNCATE 选项的 DUMP TRANsaction 命令卸出它。要恢复数据库按如下步骤去做：1、如果日志存在于一个分离的设备上，用带着 NO_TRUNCATE 选项的 DUMP TRANsaction 命令卸出被毁坏的或者不可存取的用户数据库事务日志。2、用下面的查询检查设备分配已毁坏数据库的设备使用情况。必须为同一目的赋同样的空间块。下面的查询显示

如果帮助到您，请记得采纳为满意答案哈，谢谢！祝您生活愉快！ vae.la

我之前也遇到过，我的解决是我的Vista 将UAC关掉或者以管理员权限运行Management Sdudio 就行了。以后在Vista遇到奇怪的问题，可以试着用管理员权限运行（关闭UAC也行）。

或者打开sqlserver/tools/sqlserver query analyzer 执行下面 *** 作 USE MASTER GO sp_configure'allow update',1 RECONFIGURE WITH OVERRIDE GO UPDATE sysdatabasesset status = 32768 WHERE name = 'db_pos363' GO sp_configure 'allowupdate',0 RECONFIGURE WITH OVERRIDE GO说明：'db_pos363'是要修复的数据库名称。执行完毕再重启一下Servicemanager打开数据库看是否处于紧急状态！再从另一装有sql2000的机器上连接报错的数据库，然后再在sql2000的机器上新建一数据库，再使用sql2000自带的数据库导入导出功能（在新建的数据库上单击右键/所有任务/数据导入、数据导出）从报错数据库导入数据到新建的数据库中！在导入选项中注意以下几项：1， 导入方式选择分‘从源数据库复制表和视图’以及‘从sqlserver数据库间复制对象和数据’。当选择从源数据库复制表和视图时一定要选择全部表！2， 当选择‘从sqlserver数据库间复制对象和数据’时，在‘导入导出向导’对话框中去除‘使用默认选项’的选中标志；再在打开‘选项’对话框，去除以下三项的选中标志。A,复制数据用户和数据库角色；B，复制sqlserver 登陆；C，复制对象及权限。 3， 在使用‘从sqlserver数据库间复制对象和数据’时，有时会出现单张表导入失败，这时有时会在导入结束时提示那几张表导入失败有时不提示，如果提示，就再使用‘从源数据库复制表和视图’并选中导入失败的表重新导入一遍；如果不提示就只能在一张张表打开查看了，发现空表后再使用‘从源数据库复制表和视图’导入需要导入的表！导入成功后再删除sqlserver7.0机器上处于紧急状态的数据库，再新建一个同名数据库，建好后再使用sql2000的数据库导出功能导出到此数据库中，在导出过程中同样要注意导入时的注意事项！

---