0

2016 年 6 月 18 日/19 日周末，我们在 PROD 上将数据库从 11.2.0.3.0 升级到 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 版本 12.1.3

我们还应用了CPU修补程序和其他修补程序（13942692，18813637，12404574，15969020，18835102，21612876，17889841，12598630，189991480

在测试期间，我们遇到了“日志导入”GLLEZL 作业性能缓慢的问题。

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

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

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

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

然后，当我们重新运行 Journal Import 时，它会快速运行。

奇怪的是，我们可以运行该命令，然后重新运行 Jnl Import，该实例的问题已得到解决。

下次我们运行一项大工作时，它又会卡住。

我们已经审查了此说明：

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

我们还从 Oracle 获得了另一个修复，即：

  1. 取消我们会计弹性域 Segment1 上不需要的索引

  2. 运行“程序 - 优化器”，将两个参数都设置为是

  3. 以 25 作为 Estimate Percent 值为 GL Schema 运行“Gather Schema Statistics”

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

我们现在还安排“程序 - 优化器”，每天将两个参数都设置为 Yes，并且每周 25 为所有模式运行完整的 Gather Schema Stats。

Oracle 仍在尝试解决这个问题，但我想我会在这里问一下，以防其他人遇到类似问题。

4

1 回答 1

0

最后我解决了这个问题。

而不是第 3 步是：

GL以 25 作为 Estimate Percent 值对 Schema 运行“Gather Schema Statistics”

它应该是：

ALL为25 作为估计百分比值的模式运行“收集模式统计信息”

这似乎奏效了。

于 2016-07-21T10:42:49.773 回答