我正在将数据从ODBC移动到OLE目标,记录每天都被插入到ODBC上不同的表中。2程序包变得越来越慢--大约要花一天的时间来处理上百万条记录,有时甚至更多。3表中可以插入新的数据或新的更新数据,而加载和查找新数据会减慢处理速度。无论如何,我可以快速跟踪ETL过程,还是有任何开源平台,我可以用来加载数据更快
尝试计算OLE目标中要检查的行数,并仅插入大于ODBC源中行数的新记录,但令我惊讶的是,Openedge ODBC不支持ROW_NUMBER()函数
我正在将数据从ODBC移动到OLE目标,记录每天都被插入到ODBC上不同的表中。2程序包变得越来越慢--大约要花一天的时间来处理上百万条记录,有时甚至更多。3表中可以插入新的数据或新的更新数据,而加载和查找新数据会减慢处理速度。无论如何,我可以快速跟踪ETL过程,还是有任何开源平台,我可以用来加载数据更快
尝试计算OLE目标中要检查的行数,并仅插入大于ODBC源中行数的新记录,但令我惊讶的是,Openedge ODBC不支持ROW_NUMBER()函数
2条答案
按热度按时间a11xaf1n1#
根据您问题中的有限信息,我将按如下方式设计您的包
SEQC PG到SQL
这些操作的目的是将数据从源系统逐字传输到目标系统。目标表应该是全新的,并且从数据类型的Angular 来看应该是与PG表等效的SQL Server表。如果存在聚簇键,否则,请查看堆的执行情况。我将把它称为临时表。
数据流本身将非常简单
默认情况下,目标将执行快速加载并锁定表。
运行程序包并观察时间。
编辑OLE DB目标并将最大提交大小更改为小于2147483647的值。尝试100000 -是更好还是更差?向上/向下移动一个数量级,直到您了解包移动数据的最快速度。
在游戏的这个阶段有一大堆变量-源PG数据库有多忙碌,涉及的数据类型是什么,数据需要从源传输多远,到你的电脑,到目的地,但这至少可以帮助您理解“我可以拉 (在此插入较大的数字) 源系统中的行数在预期的容差范围内”如果您可以在预期的SLA内将数据从PG移动到SQL,并且还有剩余的处理时间,那么请继续下一节。
否则,你必须重新考虑你的策略,哪些数据被带来。(系统生成的)与行关联的插入/更新时间。可能是一个类似财务的系统,其中的行不更新,只插入行的新版本,净值才是最重要的。这里的可能性太多,但您可能需要找到系统的主题Maven-一个了解数据库模型的逻辑业务流程以及数据如何存储在数据库中的人。2给那个人买一些好吃的零食,因为它们价值不菲。
现在怎么办?
此时,我们已将数据从PG传输到SQL Server,我们需要确定如何处理它。
添加数据
insert
很容易,而且速度很快--这取决于表的设计。在SSIS中更改数据
update
s不太容易,而且比添加新行慢,慢是因为数据库将在后台删除该行并将其添加回去。非聚集索引也是潜在的瓶颈,但它们也可能是有益的。
选项1是只编写SQL语句来处理插入和更新。是的,您有一个可爱的GUI工具来创建数据流,但您需要速度,这就是您如何获得它(特别是因为我们已经将所有数据从外部系统移动到中央存储库)
选项2是使用数据流和可能的执行SQL任务来移动数据。其思想是,数据流将数据分段到New中,New将使用OLE DB目标写入插入。更新-从效率Angular 看,它取决于容量。如果要更新数十、数百、数千行,呃,承担性能损失,使用OLE DB命令更新行。也许它是几十万,包运行足够好,然后保留它。
否则,将更改的行路由到另一个临时表,然后从临时更新到目标表执行批量更新。但此时,您只编写了第一个选项所需查询的一半,因此只需编写Insert即可完成(并加快性能,因为现在所有内容都只是SQL Engine的“填充”)
piv4azn72#
您可能需要研究Progress的Change Data Capture功能。如果您有OpenEdge的最新版本(11.7或更高版本)和适当的许可证,您可以启用CDC策略来跟踪更改。然后您的ETL过程可以使用该信息来确定其工作目标。
警告:这很复杂。实际操作起来要比市场营销让你相信的要复杂得多。但是如果你的用例是直接的,它可能不会太可怕。
或者你可以实现Progress“Pro2”产品来为你做所有的脏活(这是一个额外的成本选项)。