EXP备份数据库时出现错误提示 EXP-00056: 遇到 ORACLE 错误 29900 同一台机器同一个命令行不知道，求高手

解决办法： 

选择和远程服务器相同版本客户端里面的expexe。 

至于里面的参数buffer size的话，用默认值也行，假如想快点的话，就设置大一点。例如设置为512000kb，这样假如你本机内存不大的话，可以机器做别的会慢。不过导出的速度快。 

用plsql导出dmp格式数据库时，左侧“对象”里面默认选择的是“All object”,记得改为“My object”，然后在选择所有的表右键选择“导出数据”，之后当然是选择oracle导出，除非你不想导出dmp格式文件。因为默认为“All object”时有大量的系统表，这些表导出数据库的时候你是不需要的，而这些系统表数据量很大，导出的话很容易会报错。

原因： 

导出用的可执行文件expexe为本地装的oracle服务器端，本地版本高于远程服务器版本。 

log：EXP-00056: 遇到 ORACLE 错误 6550 ，

ORA-06550: line 1, column 41: 

PLS-00302: component 'SET_NO_OUTLINES' must be declared ，

ORA-06550: line 1, column 15: 

PL/SQL: Statement ignored ，

EXP-00000: 导出终止失败 。

备份数据文件,然后按下面的步骤处理: 1新建一个同名的数据库(数据文件与原来的要一致) 2再停掉sql server(注意不要分离数据库) 3用原数据库的数据文件覆盖掉这个新建的数据库 4再重启sql server 5此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名) 6完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用 数据库的脚本创建一个新的数据库,并将数据导进去就行了 USE MASTER GO SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE GO UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名' Go sp_dboption '置疑的数据库名', 'single user', 'true' Go DBCC CHECKDB('置疑的数据库名') Go update sysdatabases set status =28 where name='置疑的数据库名' Go sp_configure 'allow updates', 0 reconfigure with override Go sp_dboption '置疑的数据库名', 'single user', 'false 假设数据库为TEST： 按以下步骤执行 A．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。 use master go sp_configure 'allow updates',1 go reconfigure with override go B．设置test为紧急修复模式 update sysdatabases set status=-32768 where dbid=DB_ID('test') 此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表 C．下面执行真正的恢复操作，重建数据库日志文件 dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_logldf') 执行过程中，如果遇到下列提示信息： 服务器: 消息 5030，级别 16，状态 1，行 1 未能排它地锁定数据库以执行该操作。 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。 正确执行完成的提示应该类似于： 警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

这个应该是系统兼容性不好造成的问题，金蝶没有菜单可以修改这样的问题，所以建议你彻底卸载软件后重新装，这个前提是你的安装包要正规没有问题，否则重新安装也没有用，金蝶软件彻底卸载方法请参考http://wwwkingdeecncn/anzhuang/xie-zaihtml。

金蝶备份的文件为两个文件，一个是数据文件，另一个是备份说明文件，数据文件的后缀名为

：bak 说明文件的后缀名是 ： dbb

你看看你出现错误提示的备份文件是否缺少了后缀为dbb的文件

我们要告诉各位如何利用专业储存厂商所提供的备份解决方案来提升 ms exchange 服务器的数据备份。 通常这些备份软件都提供图型化的管理接口，透过点选的方式则可轻松完成 exchange 服务器数据库进行数据备份 ，更进一步来看，透过厂商的代理程序安装在 exchange 服务器上，能强化在备份和还原期间，备份主机和 exchange server 数据库之间的所有通讯效能。这包括准备、撷取、传输、解译和处理网络上来回传送的数据封包。 一般来说这些备份软件技术针对 ms exchange 平台可以区分为下列几种备份方式：

1 数据库层级备份和还原--使用此类型来备份和还原服务器的储存群组与数据库，并在灾难修复案例中还原系统。这种类型只能用来备份完整数据库，无法用来执行比较细微层级的备份和还原，例如备份个别数据夹。但这是很重要！每当备份 exchange server 时，都应该执行「数据库层级」备份。

2 堆栈层级备份和还原--使用此类型来执行数据夹层级的备份，以及备份使用讯息应用程序发展接口(mapi)的个别邮件。这种类型在还原信箱和数据夹到原始或其它位置时，非常有用。这种类型应该用于细微层级的备份和还原，例如备份个别数据夹，而不应该用来备份完整数据库。

当管理数据储存需求时，此两种模式能提供相当大的弹性和安全性。其优势及效益如下：

§ 从远程位置管理 exchange server 数据库、信箱和公用数据夹的备份。

§ 使用 exchange server 的备份和还原 api ，执行在线数据库备份。

§ 使用强大的「备份管理员」，排定 exchange server 备份。

§ 备份到储存装置的开放数组。

3 文件层级 ( 邮件层级 ) 备份和还原 -- 此类型可支持单一讯息储存 (single instance storage, sis) 、多重串流、进阶过滤和装置选项，提供最大效能和弹性。这种类型应该用于细微层级的备份和还原，例如备份个别数据夹，而不应该用来备份完整数据库。重点是！如果您使用文件层级备份和还原，就不需要使用堆栈层级备份和还原。此类型方式的效益，包括：

§ 完成单一讯息储存

§ 发送代理程序技术

§ 多执行多重串流

§ 文件层级还原

§ 版本升级支持

§ 加强丛集支持

§ 工作接续等

除了上述的 ms exchange 主机数据保护之外，我们还要针对两个相关的议题进一步的探讨 : 主机灾难复原及扇区阴影复制服务。

有多项因素会影响备份策略--备份动作多寡、还原动作多寡、服务器与储存硬件、可用媒体数量、媒体保留时间、网络频宽、服务器负载量、以及数据库的大小。因此，企业应该根据其实际硬件环境，决定使用何种备份策略。当决定备份策略时，首先必须先评估组织在每个礼拜可备份 exchange server 的时间数。在评估时，需注意执行还原时最耗时的项目，是重新执行日志档案。根据您多久执行一次完整备份，在还原时重新执行大型服务器的日志档案可能会花上几个小时，因为从上一次备份后所发生的每次异动都必须经过扫瞄。除此之外，根据必须重新执行的异动类型差异，又会造成不同的异动日志重新执行速度。执行日志档案的测试还原，取得更正确的执行时间估计值。在决定还原动作多寡之后，还须考虑企业环境与资源将对备份策略所造成的影响：

希望拥有最少还原动作的关键任务数据的环境中，应该在夜晚执行完整备份(或是在服务器最少作用状态时)而在中午(或是在完整备份腾出空间的那一天中较低的生产力期间时)执行递增备份。

如果媒体使用量是备份策略的主要因素，可以每天执行完整备份，或是每天交替执行完整与差异备份。

当还原动作多寡不是企业在意的事项，您应该每周至少执行一次完整备份，并在其它日子执行递增或差异备份。

下列附表包含几种备份策略的范例，以及其优点与缺点。尽管如此，为达最佳的保护效果，应该每天执行完整与递增备份，为达最佳的保护效果，管理者可以自订备份策略，以符合组织的需要。唯一的要求，就是最少要有每周一次完整备份的工作日，执行每日备份。

备份策略

优点

缺点

每日完整备份

良好的保护频率

较少还原动作

高媒体使用量

每日完整和递增备份

高保护频率

较少还原动作

高媒体使用量

每周至少一次完整备份的每日备份

良好的保护频率

低媒体使用量

较多还原动作

还原策略

所谓养兵千日用在一时，我们要告诉各位最初规划的备份策略及平日执行备份所花费的时间的磁带，要的就是能在最迫切的时间还原数据，因此数据的还原也是需要策略及演练计划，才可确保数据在重要时刻得以发挥作用。企业可以在在线系统执行备份测试；但是，建议在为在线系统执行备份、还原策略之前，应在与在线系统高度相似的测试系统中执行修复测试。

每月至少执行一次还原至备份服务器的测试，并确定还原的数据库可正常执行。这个步骤可以让您测试备份、还原策略，评估是否可正确地备份系统，并做好可能灾难的准备。虽然 exchange server 2003 包含修复储存群组，可用来测试还原特定的储存群组。但是，仍建议企业应该练习将整个 exchange server 还原至测试服务器。