您是否搜索过SAP注释？

SAP注释0CO_OM_CCA_9有多个。

SAP注释2161776-BW- BCT：数据源0CO_OM_CCA_9提取了引起我注意的数据记录文本字段中的禁止字符。

1701213-提取器0CO_OM_CCA_9

1999420中的记录丢失-BI模式下以增量方式提取CO总计的内容

您是否正在使用BRConnect？

请参阅2202967-ORA-01555收集统计信息失败：快照太旧

其他ORA-01555错误记录在

1611954中-CORR：迁移期间的转储 帐户（ORA-01555）

2315880-在基于帐户的CO-PA的DELTA提取期间防止ORA-01555和打包读取

我将引用

185822-ORA-1555-原因和行动

症状

ORA-1555发生的可能性，如何找出哪个事件
触发了ORA-1555

其他条款

回滚段，快照太旧
ORA-01555

原因和先决条件

创建此注释的目的是为了便于分析 为什么发生ORA-01555。 即使最初创建它时要考虑到经典的回滚段配置，此处描述的所有三种情况也适用于oracle 9引入的自动撤消管理（AUM）设置。有关AUM的详细说明，请参见注释600141。

使用AUM可以大大减少此错误的发生。 因此，我们强烈建议您，如果仍在使用传统的回滚段布局，请切换到AUM，以帮助解决此问题。

尽管使用AUM，仍然可能出现ora-1555错误。 除非另有说明，关于回滚段的任何说明也适用于撤消段； 在讨论回滚表空间时，它也适用于撤消表空间。

解决方案

从数据库的角度来看，ora-1555可能发生的主要原因有三个。

1。 延迟块清除

数据库写入器将更改后的块从SGA写入数据文件，并在SGA的脏列表上工作。 这意味着并非所有块都必须在写入时提交。 如果提交稍后发生，则oracle不想执行完整的写操作，只是设置该块的提交标志。 因此，回滚信息被标记为可重用，但块本身保持不变。

下次访问该块时，将检测到该块未提交。 影子进程将查找回退信息以获取该块的最新更改。 它在最初创建回滚的回滚段中查找它。 如果选择的回滚插槽中的SCN比选择开始时的SCN更小，则选择将成功。 但是，如果另一个完全不相关的交易现在正在使用此特定的回滚段，因此SCN比交易的起始SCN大，则在某些情况下会报告ora-1555。 但是，该块将被提交，并且提交标志将被自动设置。

解决方案：从当前读取的所有表中进行选择*

• -> sqlplus sap /

• SQL>选择中的*;

，如果此处没有错误 消息返回，现在一切都应该没事了-在此选择过程中发生了清除操作。 也可能在此选择期间报告了ora-1555。 只要出现ora-1555错误，就可以连续重新执行选择操作，从而可以清除问题。 当访问特定的块时，将设置提交标志，但是由于返回错误，因此不会读取所有其他块。 因此，每次遇到问题时，仅更新一个块，并且仅通过连续访问该表的块，将清除所有块。 如果这是一个分区表，并且您正在读取的数据仅来自特定分区，那么从该特定分区读取数据就足够了。 如果您分别知道失败的选择语句（包括绑定变量的值），则可以执行该选择并执行清除操作-如果这样做，请检查代码是否相同的选择遵循多个 时间只是具有不同的值。 建议在重新执行报告之前，先读取因ora-1555失败的报告所涉及的完整数据集。 您还可以采取一些措施来最大程度地减少不执行提交就清除此类块的可能性（并避免在以后的阶段发生延迟的块清除）。

• 主触发器 对于要清除的块是检查点。 确保检查点频率不太小。 通常，应设置重做日志文件的大小，以便在高峰加载期间大约每4分钟发生一次日志切换。 如果日志切换更频繁地发生，请考虑增加重做日志文件的大小。

• 避免增量检查点。 增量检查点由以下参数强制执行

• log_checkpoint_timeout->将其设置为0以禁用它

• log_checkpoint_interval-- >将其设置为> = 3000000

• fast_start_io_target->将其设置为0或db_block_buffers的数量（db_cache_size/8192）

• fast_start_mttr_target->将其设置为0

• 尝试找出哪个程序正在对表进行更新（例如，数据加载，长时间运行的批处理作业）。 它很可能一次执行对大量记录的插入/更新。 检查是否可以提高提交频率。

• 查看是否可以在处理完成后立即重新读取批处理作业刚刚处理过的记录 。 这样一来，您就可以对刚刚更新的特定记录进行选择，并清除所有丢失的提交标志。

与以前的回滚段设置相比，此问题也很可能发生 新的AUM设置。

2。 回滚段或回滚/撤消表空间太小。

回滚段是否太小（仅回滚段设置，不适用于撤消段），也可能导致ora-01555错误。 您可以按以下方式检查每个回滚段的当前最大大小：sqlplus'/as sydba'
SQL>从v $ rollstat中选择hwmsize； 这将返回所有回滚段一直增长到的最大大小。 请确保该回滚段未达到

a）maxextents SQL>从dba_rollback_segs中选择initial_extent，next_extent
max_extents；
hwmsize应为 小于initial_extent +（next_extent * max_extents）。
b）仍然可以在表空间内分配范围：
• hwmsize，用于从段中进行最大的回滚+ optimum_size *回滚段的数量不应大于 小于回滚表空间大小的80％。
• 否则，将数据文件添加到表空间
3。 运行中的select语句需要更新的回滚信息，该信息已经发生在select语句的开始与数据的获取之间。 更新完成后，回滚段已释放并已被另一个事务覆盖。

解决方案：添加更多的回滚段，以使覆盖特定语句的可能性降低。 还可以根据大多数回滚段的hwmsize来确定回滚段的最佳大小。

要获得有关平均回滚信息在您的系统上平均保留多长时间的估计，可以使用以下公式： SQL> SELECT
trunc（24 *（sysdate-i.startup_time）/v.cycles）"在小时内"，
trunc（1440 *（sysdate-i.startup_time）/v.cycles）" IN MINUTES"
FROM sys.v_ $ instance i，
（SELECT
max（
（r.writes + 24 * r.gets）/-使用的字节数/
nvl（最低（r。 optsize，r.rssize），r.rssize）*-段大小
（r.extents-1）/r.extents-减去1 ext。
）个周期
FROM sys.v_ $ rollstat r
WHERE r.status ='ONLINE'）v;

由于结果仅为AVERAGE，因此并不意味着在此之前不能进行任何覆盖。 如果您的作业运行时间长于此查询的结果（最好是结果至少是作业运行时间的2倍），那么您肯定需要增加回滚段的数量以延长时间，直到覆盖回滚信息。

尽管oracle通常在各段之间均匀地分配事务，因此回滚信息之间发生覆盖回滚信息之前的时间应该是一致的，但是不幸的是不能保证这一点。

p>

从oracle 9.2开始，oracle引入了一种存储撤消信息的新概念-撤消空间不是使用回滚段，而是由oracle自动管理的。 切换到新概念可能有助于发生ora-1555错误的第三种可能性。 有关自动撤消管理及其设置方法的详细信息，请参见注释600141。由于可以设置回滚的保留时间，因此oracle为我们提供了更多的保证，即在该范围内不会覆盖回滚信息。 指定时间。 但是，如果撤消表空间的大小不足以容纳事务这么长时间，则事务仍将在少于指定的时间内被覆盖。 确保指定的保留时间超过要获取ora-1555的作业的运行时间，并且撤消表空间还能够存储在该时间内写入的撤消量。

请注意，这不会自动消除您的ora-1555错误。 仍然需要进行一些测试和调整，尤其是在设置这两个变量，保留时间的值和撤消表空间的大小时。

可能。 请执行检查1）+2），如果结果看起来像您没有遇到这些问题之一，请添加更多的回滚段以最大程度地降低可能性3发生的可能性。

如果您已查看所有 注释，尝试修复，但仍然没有成功-请考虑打开SAP事件。

此问题超出了您的技能范围。 您需要让您的基础团队和SAP来解决问题。

请不要忘记记录您的最终解决方案并将问题标记为已回答。

祝您好运，

约翰·霍克