2020-09-08 17:07发布
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
朋友/专家
与以下问题相比,我在3周多的时间里一直在战斗,请帮助我。
数据源:0CO_OM_CCA_9
虽然我尝试选择数据001.2015至006.2015 ---->满载信息包成功。
当我尝试选择数据时007.2015 --------->满载信息包会引发错误。
我在BW中复制了数据源并全部激活,然后我也遇到了相同的错误。
请参考屏幕截图:
同一问题之后,直到35,400个数据被获取。
嗨,Rgi,
错误清楚地告诉您,在会计年度/期间,有一个数据提取器不喜欢该数据。
在源代码中使用ST22 系统查看堆栈转储,可能会为您提供线索。
请考虑选择007.2015并通过单个Cost Center或其他选择标准来识别"不良"数据。
请咨询ECC功能分析人员,以确定在此期间是否存在已知的不良数据。
SAP注释0CO_OM_CCA_9有多个。
SAP注释2161776-BW-BCT:数据源0CO_OM_CCA_9提取了数据记录文本字段中的禁止字符,引起了我的注意。
如果文本字段包含禁止使用的字符,提取将失败。
请不要忘记记录您的最终解决方案 并标记为已回答问题。
祝你好运
约翰·霍克
您是否得到了问题的答案?
我的一个自定义提取器中也遇到了同样的问题,如果发现任何问题,请共享解决方案。
可以在源系统中检查作业的日志吗?
嗨,约翰,
仍然无法解决我的问题,
我无法获得luanchpad的支持。
我找不到合适的文件。
人们肯定需要您的帮助。
您好
当我尝试选择数据时007.2015 --------->满载信息包引发错误。
我不认为这是一个内存问题,数据从001.2015到006.2015有6个周期,但是只有1个周期失败。
检查您的CMOD代码,有选择语句导致转储。 可能是它从表COVP中获取了所有数据。
如果要在Select语句中使用FOR FOR ALL ENTRIES IN Internal Table函数,请确保上面已选中" Internal table不应该是初始的"。
谢谢
Pratyaksh Jeet
您是否搜索过SAP注释?
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 p>
回滚段,快照太旧 ORA-01555
创建此注释的目的是为了便于分析 为什么发生ORA-01555。 即使最初创建它时要考虑到经典的回滚段配置,此处描述的所有三种情况也适用于oracle 9引入的自动撤消管理(AUM)设置。有关AUM的详细说明,请参见注释600141。
尽管使用AUM,仍然可能出现ora-1555错误。 除非另有说明,关于回滚段的任何说明也适用于撤消段; 在讨论回滚表空间时,它也适用于撤消表空间。
从数据库的角度来看,ora-1555可能发生的主要原因有三个。
数据库写入器将更改后的块从SGA写入数据文件,并在SGA的脏列表上工作。 这意味着并非所有块都必须在写入时提交。 如果提交稍后发生,则oracle不想执行完整的写操作,只是设置该块的提交标志。 因此,回滚信息被标记为可重用,但块本身保持不变。
下次访问该块时,将检测到该块未提交。 影子进程将查找回退信息以获取该块的最新更改。 它在最初创建回滚的回滚段中查找它。 如果选择的回滚插槽中的SCN比选择开始时的SCN更小,则选择将成功。 但是,如果另一个完全不相关的交易现在正在使用此特定的回滚段,因此SCN比交易的起始SCN大,则在某些情况下会报告ora-1555。 但是,该块将被提交,并且提交标志将被自动设置。
解决方案:从当前读取的所有表中进行选择*
解决方案:添加更多的回滚段,以使覆盖特定语句的可能性降低。 还可以根据大多数回滚段的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来解决问题。
请不要忘记记录您的最终解决方案并将问题标记为已回答。
祝您好运,
最多设置5个标签!
嗨,Rgi,
错误清楚地告诉您,在会计年度/期间,有一个数据提取器不喜欢该数据。
在源代码中使用ST22 系统查看堆栈转储,可能会为您提供线索。
请考虑选择007.2015并通过单个Cost Center或其他选择标准来识别"不良"数据。
请咨询ECC功能分析人员,以确定在此期间是否存在已知的不良数据。
SAP注释0CO_OM_CCA_9有多个。
SAP注释2161776-BW-BCT:数据源0CO_OM_CCA_9提取了数据记录文本字段中的禁止字符,引起了我的注意。
< p> https://launchpad.support.sap.com/#/solutions/r/?type=note&route=notes&p=%7B%22note%22%3A%222161776%22%2C% 22lang%22%3A%2…如果文本字段包含禁止使用的字符,提取将失败。
请不要忘记记录您的最终解决方案 并标记为已回答问题。
祝你好运
约翰·霍克
您是否得到了问题的答案?
我的一个自定义提取器中也遇到了同样的问题,如果发现任何问题,请共享解决方案。
可以在源系统中检查作业的日志吗?
p>嗨,约翰,
仍然无法解决我的问题,
我无法获得luanchpad的支持。
我找不到合适的文件。
人们肯定需要您的帮助。
您好
虽然我尝试选择数据001.2015至006.2015 ---->满载信息包成功。
当我尝试选择数据时007.2015 --------->满载信息包引发错误。
我不认为这是一个内存问题,数据从001.2015到006.2015有6个周期,但是只有1个周期失败。
检查您的CMOD代码,有选择语句导致转储。 可能是它从表COVP中获取了所有数据。
如果要在Select语句中使用FOR FOR ALL ENTRIES IN Internal Table函数,请确保上面已选中" Internal table不应该是初始的"。
谢谢
Pratyaksh Jeet
您是否搜索过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 p>
其他条款
回滚段,快照太旧
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。 但是,该块将被提交,并且提交标志将被自动设置。
解决方案:从当前读取的所有表中进行选择*
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)仍然可以在表空间内分配范围:
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来解决问题。
请不要忘记记录您的最终解决方案并将问题标记为已回答。
祝您好运,
约翰·霍克
一周热门 更多>