时间戳

首页 > 解决方案 > 使用 PutDatabaseRecord 处理器进行非常慢的更新

oracle - 使用 PutDatabaseRecord 处理器进行非常慢的更新

问题描述

我有 2 个PutDatabaseRecord正在写信给Oracle DB.

这是架构的一部分：

架构

那里的红色方块不是错误，而是信息消息，因此我将处理器置于 INFO 模式。所以它讲述了获取模式，以及使用 SQL 更新命令“提交因为批量大小”。

问题是，其中第一个：ml_task，在几分钟内处理数百万条记录，但另一个：ml_sales- 几个小时内有 1000 条记录的堆栈......这在晚上、当数据库负载很大时和在白天时都会堆栈。

在同一时刻，update goods.ml_[name] set load_date = sysdate语句通过 SQLDeveloper 接口花费相同的时间 - forml_task和ml_sales. 晚上大约需要10分钟，一天需要几分钟。

他们都使用相同的池服务。

这是服务底部的配置：

池化配置

两个处理器具有相同的配置，除了表名和更新键。

处理器配置

我尝试设置Max Batch Size为零，它没有影响。

配置的两个处理器都在一个线程中运行，但我尝试配置 10 个线程 - 没有影响。

此外，根本不缺少与数据库的连接，我有大约 10 个处理器，每个处理器都使用一个线程，所以 50 个连接，我认为就足够了。

他们正在处理大约 500 万条记录。

这是 JSON 的ml_task：

[{"DOC_ID": 1799041400,"LINE_D":694098344,"LOAD_DATE":"16-Jul-21"} ... ]

这类似于 Nifi 的更新ml_task：

update goods.ml_task
set load_date = sysdate
where doc_id = ? 
and line_id = ?;

这是表格：

Name          Null?    Type   
------------- -------- ------ 
DOC_ID        NOT NULL NUMBER 
LINE_ID       NOT NULL NUMBER 
ORG_ID        NOT NULL NUMBER 
NMCL_ID       NOT NULL NUMBER 
ASSORTMENT_ID NOT NULL NUMBER 
START_DATE    NOT NULL DATE   
END_DATE               DATE   
ITEMS_QNT              NUMBER 
MODIFY_DATE            DATE   
LOAD_DATE              DATE

这是一个 JSON ml_sales：

[{"REP_DATE":"06-Jul-21","NMCL_ID":336793,"ASSORT_ID":7,"RTT_ID":92,"LOAD_DATE":"16-Jul-21"} ... ]

请求ml_sales是这样的：

update goods.ml_sales set load_date = sysdate
where nmcl_id = ?
and assort_id = ?
and rtt_id = ?
and rep_date = ?;

和表：

Name        Null?    Type       
----------- -------- ---------- 
REP_DATE    NOT NULL DATE       
NMCL_ID     NOT NULL NUMBER(38) 
ASSORT_ID   NOT NULL NUMBER     
RTT_ID      NOT NULL NUMBER(38) 
OUT_ITEMS            NUMBER     
MODIFY_DATE          DATE       
LOAD_DATE            DATE

更新这么慢的原因是ml_sales什么？

更新

我把所有的电路都放到了STOP除了有问题的电路之外，我把所有的会话都放在了SQLDeveloper......结果是一样的......很长......

更新

正如我上面提到的，我实际上将ml_sales表复制到了其他方案，这并没有影响结果。

标签： oracleapache-nifi

解决方案

我猜Oracle中缺少索引存在问题。我让我们的 DBA 检查 DB 端的问题，他们修复了它，现在UPDATE工作速度和 table 一样快ml_task，但不幸的是我仍然不知道问题到底是什么，因此 DBA 离开了。因此，再次，很可能是索引问题。

推荐阅读