Question

我们在2016年6月18日至19日的周末将数据库从11.2.0.3.0升级到PROD的12.1.0.2.0。

SELECT * FROM v$version;

版本信息：

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
PL/SQL Release 12.1.0.2.0 - Production
CORE    12.1.0.2.0    Production
TNS for Solaris: Version 12.1.0.2.0 - Production
NLSRTL Version 12.1.0.2.0 - Production

我们正在运行Oracle Release 12.1.3

我们还应用了CPU补丁和其他（13942692,18813637,12404574,15969020,18835102,21612876,17889841,12598630,18841480,22465286,22614470,16289505,18039691,9833058,16958896,22378313）。

在测试期间，我们遇到了“日记帐导入”GLLEZL作业效果不佳的问题。

我们发现，当日记帐导入运行缓慢时（例如，对于19,000行Web ADI日志，“Web ADI - 日记帐导入”作业需要2.5小时，而数据库11版本则需要几分钟）。

对于其他工作，例如当我们将数据加载到GL_INTERFACE并运行标准的“程序 - 日记帐导入”时，例如一份120,000行的期刊，这项工作永远不会完成。

我提出了一个服务请求，我们得到了一个快速修复，即取消长时间运行的作业，然后运行此命令：

exec fnd_stats.gather_table_stats('GL','GL_INTERFACE',100)

然后，当我们重新运行日记帐导入时，它会快速运行。

奇怪的是我们可以运行该命令，并重新运行Jnl Import，并且针对该实例修复了该问题。

下次我们做大工作时，它会再次陷入困境。

我们已经审核了这个注意事项：

R12：提高总帐和日记帐导入的性能（文档ID 858725.1）

我们还有另一个来自Oracle的修复程序，即：

在会计弹性域的Segment1上取消不需要的索引
运行“程序 - 优化程序”，并将两个参数设置为是
为GL架构运行“收集架构统计信息”，其中25为估算百分比值

但这并没有解决问题 - 我们仍然需要每次都进行手动修复。

我们现在还安排“程序 - 优化程序”，每天将两个参数设置为“是”，并且每周运行一次完整的“收集模式统计”，每次运行25次。

甲骨文仍然试图解决这个问题，但我想我会问这里以防其他人遇到过类似的问题。

Answer 1

最后我解决了这个问题。

而不是第3步：

运行＆＃34;收集架构统计信息＆＃34;对于GL架构，其中25为估算百分比值

应该是：

运行＆＃34;收集架构统计信息＆＃34;对于ALL模式，其中25为估计百分比值

这似乎可以解决问题。

升级后的数据库从11.2.0.3.0升级到12.1.0.2.0。慢速日记导入

1 个答案: