使用 PutDatabaseRecord 处理器更新非常慢
Very slow UPDATE with PutDatabaseRecord processor
我有 2 个 PutDatabaseRecord
正在写入 Oracle DB
。
这是架构的一部分:
红色方块不是错误,而是信息消息,因此我将处理器设置为信息模式。所以它讲述了获取模式,以及使用 SQL 更新命令“由于批量大小而提交”。
问题是,其中第一个:ml_task
,在几分钟内处理了数百万条记录,但另一个:ml_sales
- 与 1000 条记录堆叠了几个小时......这堆叠无论是在晚上,当数据库负载很大时还是在白天。
在同一时刻,update goods.ml_[name] set load_date = sysdate
语句通过 SQL 开发人员界面花费的时间相同 - 对于 ml_task
和 ml_sales
。晚上大约需要 10 分钟,一天需要几分钟。
他们都使用相同的池服务。
这是服务底部的配置:
除了 table 名称和更新密钥外,这两个处理器具有相同的配置。
我试过将Max Batch Size
设置为零,没有影响。
两个处理器都配置运行一个线程,但我尝试配置10个线程-没有影响。
此外,与数据库的连接并不缺乏,我有大约 10 个处理器,每个处理器都使用一个线程,所以 50 个连接,我认为足够了。
他们正在处理大约 500 万条记录。
这是 ml_task
的 JSON:
[{"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 = ?;
这是table:
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
这是 ml_sales
的 JSON:
[{"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 = ?;
和 table:
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
table 复制到其他方案,这并没有影响结果。
我猜是 Oracle 中缺少索引的问题。我要求我们的 DBA 检查数据库端的问题,他们修复了它,现在 UPDATE
的工作速度与 ml_task
table 一样快,但不幸的是我仍然不知道到底是什么问题,DBA 就此离职。所以,很可能是索引问题。
我有 2 个 PutDatabaseRecord
正在写入 Oracle DB
。
这是架构的一部分:
红色方块不是错误,而是信息消息,因此我将处理器设置为信息模式。所以它讲述了获取模式,以及使用 SQL 更新命令“由于批量大小而提交”。
问题是,其中第一个:ml_task
,在几分钟内处理了数百万条记录,但另一个:ml_sales
- 与 1000 条记录堆叠了几个小时......这堆叠无论是在晚上,当数据库负载很大时还是在白天。
在同一时刻,update goods.ml_[name] set load_date = sysdate
语句通过 SQL 开发人员界面花费的时间相同 - 对于 ml_task
和 ml_sales
。晚上大约需要 10 分钟,一天需要几分钟。
他们都使用相同的池服务。
这是服务底部的配置:
除了 table 名称和更新密钥外,这两个处理器具有相同的配置。
我试过将Max Batch Size
设置为零,没有影响。
两个处理器都配置运行一个线程,但我尝试配置10个线程-没有影响。
此外,与数据库的连接并不缺乏,我有大约 10 个处理器,每个处理器都使用一个线程,所以 50 个连接,我认为足够了。
他们正在处理大约 500 万条记录。
这是 ml_task
的 JSON:
[{"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 = ?;
这是table:
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
这是 ml_sales
的 JSON:
[{"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 = ?;
和 table:
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
table 复制到其他方案,这并没有影响结果。
我猜是 Oracle 中缺少索引的问题。我要求我们的 DBA 检查数据库端的问题,他们修复了它,现在 UPDATE
的工作速度与 ml_task
table 一样快,但不幸的是我仍然不知道到底是什么问题,DBA 就此离职。所以,很可能是索引问题。