使用Java将AS400 .MBR文件读取为平面文件

Question

这就是我一直在努力实现的目标。

我们正在释放一个名为go的供应商工具，该工具在触发select查询后从DB2数据库读取数据，创建一个文件，向它写入数据，并将其压缩到我们的ETL工具可以读取它的机器上。

我已经能够实现几乎同时GA所做的事情，事实上，在6.5GB的文件上，通过使用JSCH和动态地击败了上述工具5分钟。这使得读取和写入文件的时间从之前的32分钟缩短到现在的27分钟。

但是为了满足新的SLA需求，我们需要将时间进一步减少到我所拥有的时间的近一半，大约13分钟左右。

为了实现上述目标，我已经能够直接读取.MBR文件，并在13分钟或更短的时间内将其推送到Linux机器上，但该文件的格式并不是明文。我想知道如何使用Java或使用.MBR命令将.MBR文件转换为纯文本格式而不触发SQL。

任何帮助都很感激。

Answer 1

您的错误印象是，IBM上的“文件”就像Windows/Unix/Linux上的文件。

事实并非如此。

与IBM中的所有其他对象类型一样，它是一个具有定义良好的接口的对象。

在*FILE对象的特定情况下，它是一个数据库表。DB2 for I不是安装在操作系统之上的附加DBMS；DB2是他们给集成到操作系统中的DBMS取的名称。用户程序不能像Windows/Unix/Linux上的文件那样直接打开存储空间。您必须通过操作系统提供的接口。

有两个可用的接口，记录级访问( Record Level，RLA)或SQL。两者都可以从Java应用程序中使用。RLA由com.ibm.as400.access.AS400File类提供。SQL访问由JDBC类提供。

SQL很可能提供最好的性能，因为您处理一组记录，而不是每次使用RLA处理一个记录。

看看各种性能相关的JDBC属性可用。

从性能的角度来看，您的单个进程不太可能充分利用系统，即。CPU使用率不会达到100%，磁盘活动也不会超过60-80%。

既然如此，你最好的选择就是把这个过程分解成多个。您需要一些方法来将每个进程限制为一组选定的记录。可能是按主键隔离的。这将增加一些开销，除非记录是按主键顺序排列的。如果表没有删除记录，则使用RRN()按物理顺序进行隔离可能有效。但是请注意，在旧版本的操作系统上，使用RRN()需要进行全表扫描。

Answer 2

猜测正在发生的情况是，源表中有填充的十进制字段，这些字段不会被您自己开发的读取表的方法解压。

有几种可能性。

1. 让IBM团队在源表上创建一个视图，该表中的所有数字列都是十进制。此外，省略ETL不需要的列-它将通过不必移动这些字节来减少I/O。对此执行摘录。注:系统上可能已经有这样的视图了。
2. 让IBM团队构建适当的索引。通常，可以通过适当的索引来缓解SQL瓶颈。
3. 不要ZIP和解压缩；将原始文件发送到另一个系统。即使在6GB时，千兆以太网也能很容易地处理这个问题。
4. 在ETL系统上加载ODBC驱动程序，并让它直接读取源表(或适当的视图)，而不是将副本发送到ETL系统。
5. 二语习得的时限从何而来？如果SLA说“亚秒响应时间”，你会怎么做？在某种程度上，SLA需要反映物理定律所定义的现实的某些版本。我并不是说你已经达到了这个极限:我是说你需要找到它的基本原理。
6. 让IBM团队确保它们是当前的修补程序(PTF)。IBM经常通过PTF解决性能问题。
7. 让IBM团队确保正在运行作业的子系统具有足够的内存。