并行处理的性能调整

此附录描述了使用并行处理运行“CI 处理 (tccri7203m000)”进程时可能需要的性能调整。

“CI 处理 (tccri7203m000)”的实际性能取决于几个因素，包括可用的 CPU 数以及应用程序和数据库服务器的设置。表中包含的数据量是另一个主要因素。通常，下列各表包含大量数据：

集成事务处理 (tfgld482)
调节数据 (tfgld495)
已定案事务处理 (tfgld106)
在制品和库存事务处理 (JSC) (ticst300)
PCS 在制品和库存事务处理 (tipcs300)
销售订单历史记录（tdsls450、tdsls451 和 tdsls456）

在 LN FP5 及更高版本中可用于通过 RDBMS 直接更新表格的一种功能。此功能在 porting set 8.7a.03 及更高版本中实施。

直接通过 RDBMS 进行更新相比通过 bshell 更加有效。区别在于整个事务处理都移交给 RDBMS。此类更新限制于不需要重新计算本币金额和/或汇率的表格或数据。例如，报表货币的本币金额变为当地货币金额，就是这种情况。删除本币金额也属于这种情况。如果删除报表货币，或者在物流表中货币系统更改为标准货币系统，可能出现这种情况。

“CI 处理 (tccri7203m000)”进程将检查是否可以直接通过 RDBMS 应用更新。如果不允许通过 RDBMS 直接更新，进程将使用常见的（较慢的）更新。

是否可以使用 RDBMS 更新取决于以下条件：

在“CI 汇率 (tccri7100m000)”进程中，“以基本货币表示 ”字段的值必须与“汇率 (tcmcs0108m000)”进程中相应字段的值匹配。例如，对于欧元区公司，如果“以基本货币表示 ”设置在换算过程中不更改，则从欧盟成员国（当地）货币到事务处理货币之间的汇率可以保持不变。

“”注意：这适用于“汇率 (tcmcs0108m000)”进程中的每种基本货币的所有汇率类型。
技术限制
下列限制适用：
- 数据库驱动程序必须是二级驱动程序。
- 审核或对照下列表：
  
  tfgld495、tfgld482、tdsls451 和 tdsls456
必须使用 8.7a.03 版或更高版本的 Porting set。Porting set 的 TIV 等级必须是 1744 或更高。您可以通过在命令行运行 $BSE/bin/bshell6.2 –V（对于 Windows 系统，使用 %BSE\bin\ntbshell –V）来检查此版本号。

如果在“CI 处理 (tccri7203m000)”进程中开始货币初始化处理，则此进程将访问换算群和相关公司，然后会确定需要哪种类型的换算。如果可以应用通过 RDBMS 直接更新，则会在“按公司群列出的 CI 换算表 (tccri725)”和“CI 群换算表更新组 (tccri726)”中生成一些数据。

注意

只会针对“按公司群列出的 CI 转换表 (tccri7125m000)”进程中的集成事务处理 (tfgld482) 实体生成“CI 群换算表更新组 (tccri726)”。

如果“CI 处理 (tccri7203m000)”将通过 RDBMS 更新直接更新表，则在“按公司群列出的 CI 转换表 (tccri7125m000)”进程中将选择“大批更新”字段。

集成事务处理 (tfgld482) 表可以包含属于多个财务公司的事务处理。可以使用通过 RDBMS 直接更新进行处理的集成事务处理将会分组到更新组中。一个更新组中的事务处理可以在一次 RDBMS 更新中进行换算。而如果集成事务处理 (tfgld482) 必须在不使用通过 RDBMS 直接更新的情况下进行换算，则仍可以分割表换算。这样，将会使用并行处理来应用常见更新方法处理表更新。

只有在无法应用通过 RDBMS 直接更新的情况下才必须进行调节数据 (tfgld495) 分割。例如，需要重新计算本币金额或汇率，就是这种情况。

注意

如果调节数据 (tfgld495) 的换算已分割，则表将不会使用通过 RDBMS 直接更新进行更新。
已定案事务处理 (tfgld106) 表可以使用并行处理进行转换。不支持通过 RDBMS 直接更新。

调整示例

此示例适用于不使用通过 RDBMS 直接更新处理的、并且可以在“按公司群列出的 CI 转换表 (tccri7125m000)”中分割的转换任务。

根据每个公司的货币设置，使用并行处理的内部转换可能涉及多次使用和不使用通过 RDBMS 直接更新的转换。

假设三个公司的数据必须使用 9 个并行 Bshell 进行转换。图中针对三个公司用不同颜色显示这种情况。

任务 1.1 中转换的表非常大。同时也转换了其他 3 个大表（2.1、2.2 和 3.1）。如果大的转换任务 1.1 可以被分割，则您可以决定用 6 个 Bshell 处理任务 1.1，而其它 3 个 Bshell 将处理任务 2.1、2,2 和 3.1。完成任务 1.1 分割后，处理此任务的 6 个较大任务会先进行处理，然后处理较小的（紫色）任务。

如果表 2.3 和 2.4 的转换可以被分割，也可以使用相同的方法。如果并行使用 2 个 Bshell 处理表 2.3，并行使用 3 个 Bshell 处理表 2.4，仍会有足够的容量用于剩余的并行 Bshell 同时处理较小的（绿色）任务。

分割任务后，并行处理的负载会看起来更平衡。

总经历时间从 28 个时间单位减少为 17 个。

“CI 处理 (tccri7203m000)”:试转换与实际转换

在模拟模式中，将测试通过 RDBMS 直接更新的数据库事务处理。在调节数据 (tfgld495)、集成事务处理 (tfgld482)、销售订单历史记录行 (tdsls451) 和销售订单历史记录交货行 (tdsls456) 的转换中可以使用此类型更新。事务处理将在试运行模式中回退。相比在实际转换中进行的实际事务处理，这可能要花费相当多的时间。

在常规转换逻辑中，试转换过程中是不执行表数据更新的。请注意，鉴于在试转换过程中会在较短的时间内处理这些表，所以在实际转换中处理这些表会花费更多时间。

注意

货币初始化过程中，换算群公司中一定不能存在处于活动状态的其他用户或处理，即使是使用“CI 处理 (tccri7203m000)”进程执行试转换也不可以。

要防止在表锁定或读取未确认的事务处理时出现问题，需注意以下几点：

通过 RDBMS 的直接更新会是非常大的事务处理，在试转换过程中对这些事务处理经过了测试但并未确认。在对调节数据 (tfgld495)、集成事务处理 (tfgld482)、销售订单历史记录行 (tdsls451) 和销售订单历史记录交货行 (tdsls456) 进行表锁定时可能会出现此问题。
SQL Server：默认情况下，数据库驱动程序使用“读取未确认”隔离等级来避免共享锁定以及排它锁定以进行更新和删除操作。所以，在（试）转换过程中，其他用户或处理可能会读取调节数据 (tfgld495)、集成事务处理 (tfgld482)、销售订单历史记录行 (tdsls451) 和销售订单历史记录交货行 (tdsls456) 中的未确认事务处理。如需更多信息，请参阅： Infor Enterprise Server Technical Reference Guide for SQL Server Database Driver (U8173US)。

Oracle 设置

通过 RDBMS 的直接更新将是非常大的事务处理。因此，需要大量的撤消表空间。测试 LN 需要使用 32 GB 的撤消表空间。我们建议您配置撤消表空间，例如每次配置 8 GB，以自动扩展数据文件。这将有助于避免出现 ORA-1555（快照太旧）错误。请记住最大数据文件大小。

预测撤消表空间大小是否足够并不容易。我们建议您在运行“CI 处理 (tccri7203m000)”时，在 LN 的事件查看器日志中查找 ORA-1555 错误。

通常，要很好地执行查询，Oracle 数据库需要进行适当的调整。

通过 $BSE/lib/default/db_resource 文件将以下设置应用于 LN 环境，已经对 LN 进行了测试：

ora_init:0101000
ora_max_array_fetch:100
ora_max_array_insert:100
ora_alter_session：设置“_optim_peek_user_binds”= false

应考虑使用基于批的数据库资源合并以上行来进行转换。

在某些实施中，隐藏的 Oracle 参数（也称为下划线参数）中会应用非默认的值。这些设置可能会影响查询的执行计划。考虑将其重新设置为默认值。通过将这些设置添加到 $BSE//lib/defaults/db_resource 文件中的 ora_alter_session 属性中，可以实现此操作。

SQL Server 设置

应考虑在货币初始化过程中将 LN 数据库上的记录更改为“简单”，并且在完成货币初始化创建完整备份。

设置 $BSE/lib/default/db_resource 文件启用数组抓取，然后将抓取大小设置为 100。

DB2 设置

设置 $BSE/lib/default/db_resource 文件启用数组抓取，然后将抓取大小设置为 100。