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

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

我们正在开发一个名为GoAnywhere的供应商工具，该工具在触发一个select查询后从DB2数据库读取数据，创建一个文件，将数据写入其中，然后将其压缩并发送到一台机器上，我们的ETL工具可以在该机器上读取数据

我已经能够在几乎相同的时间内实现GA的功能，事实上，通过动态使用JSCH和jaring-un-jaring，在6.5GB文件上比上述工具快5分钟。这将读取和写入文件的时间从以前的32分钟缩短到现在的27分钟

但为了满足新的SLA要求，我们需要进一步将时间缩短到我现有时间的一半，大约13分钟左右

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

---

感谢您的帮助。

您错误地认为IBM i上的“文件”就像Windows/Unix/Linux上的文件

不是

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

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

有两个可用接口，记录级访问（RLA）或SQL。两者都可以从Java应用程序中使用。RLA由

com.ibm.as400.access.AS400File

类提供。SQL访问由JDBC类提供

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

查看各种可用的与性能相关的

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

---

在这种情况下，最好的办法是将流程分解为多个流程。您需要某种方法将每个进程限制为一组选定的记录。可能是主键隔离。这将增加一些开销，除非记录按主键顺序排列。如果表中没有已删除的记录，则使用RRN（）按物理顺序隔离可能会起作用。但请注意，在较旧版本的操作系统上，使用RRN（）需要进行完整的表扫描

您错误地认为ibmi上的“文件”就像Windows/Unix/Linux上的文件

不是

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

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

有两个可用接口，记录级访问（RLA）或SQL。两者都可以从Java应用程序中使用。RLA由

com.ibm.as400.access.AS400File

类提供。SQL访问由JDBC类提供

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

查看各种可用的与性能相关的

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

---

在这种情况下，最好的办法是将流程分解为多个流程。您需要某种方法将每个进程限制为一组选定的记录。可能是主键隔离。这将增加一些开销，除非记录按主键顺序排列。如果表中没有已删除的记录，则使用RRN（）按物理顺序隔离可能会起作用。但请注意，在较旧版本的操作系统上，使用RRN（）需要进行完整的表扫描

猜测发生的情况是，源表中存在压缩的十进制字段，这些字段没有通过您自己开发的读取表的方法进行解压缩

有几种可能性

让IBMi团队在源表上创建一个视图，该表的所有数字列都被分区为decimal。此外，省略ETL不需要的列—它将通过不必移动这些字节来减少I/O。在上面执行摘录。注意：系统上可能已经存在这样的视图

让IBMi团队构建适当的索引。通常，通过适当的索引可以缓解SQL瓶颈

不要压缩和解压；将原始文件发送到其他系统。即使在6GB的情况下，千兆以太网也可以很容易地解决这个问题

在ETL系统上加载ODBC驱动程序，让它直接读取源表（或适当的视图），而不是将副本发送到ETL系统

SLA时间限制从何而来？如果SLA说“亚秒响应时间”，您会怎么做？在某种程度上，SLA需要反映物理定律定义的某种现实版本。我不是说你已经达到了极限：我是说你需要找到它的理由

让IBMi团队确保他们在补丁（PTF）上是最新的。IBM通常通过PTF解决性能问题

让IBMi团队确保运行作业的子系统具有足够的内存

---

猜测正在发生的事情是有大量的数据