Python 使用cx_Oracle将长字符串数组（>；4000字节）传递给Oracle（11gR2）存储过程

我们需要大容量加载许多长字符串（>4000字节，但其中1亿个字符串）。逐个加载会很糟糕。以大容量方式进行加载，即使用cursor.arrayvar（）非常理想。但是，CLOB不支持数组。BLOB、LOB、LOG\u STRING LONG\u RAW也不支持。如果您有任何帮助，我们将不胜感激。

非正式建议，但既然您使用的是11gR2，请查看 从“加载”的角度来看，您只是在复制文件，而它们“显示”为LOB。您可以使用内置FTP服务器执行类似的操作，但文件处理要简单得多

然后编写一个过程，将它们从dbfs_内容视图中拉出来并推送到您的过程中

---

另一个是，如果它们都小于12000字节，则将它们分成三部分，并将它们作为三个独立的VARCHAR2（4000）进行处理字符串，并在PL/SQL端再次将它们连接起来。

为了完成足够好的工作，我们滥用了我在评论中提到的CLOB。编码、运行速度快且有效的时间不到30分钟。

数据当前在哪里（例如一个文件、多个文件、其他数据库、web服务…）.从文件中，我将查看SQLLDR（SQL*加载器）作为任何大容量加载操作的起点。远程存放在多个文件中。大容量加载不起作用，因为我们需要填充多个表、获取下一个表和各种其他形式的PL/SQL数据消息。我们目前正在试验一种丑陋的方法，即使用一些预定义的分隔符将所有字符串连接到一个C中LOB然后通过一个数字数组传递CLOB，该数组指定分隔符的位置，并在PL/SQL中从此处进行解析。是的，我们不需要传递分隔符的idx，但PL/SQL中的字符串操作相当于用断了的牙签挖出你的眼睛（与其他语言相比，在易用性/可读性/可维护性方面）我们有3个CLOB字段，每个字段包含大于4000字节的字符串，我们希望一次加载1000行。DBFS方法确实有效，但我不喜欢PL/SQL中的字符串操作，因为它很脆弱，开发和测试所需的时间比用高级语言所做的要长正如我们所看到的，在这些情况下，使用PL/SQL也不会带来任何性能上的好处，它没有针对字符串操作进行优化。