使用 SetBigStringTryClob 通过 Oracle JDBC 处理 CLOB 的性能影响
我正在审查一些用于 Oracle 数据库上的 CLOB 处理的旧 Java/JDBC 代码。现有代码使用的方法类似于此问题中提到的方法。
我发现一篇文章其中规定：
在 Oracle JDBC 10g 之前，为了在 JDBC 中操作 CLOB 数据，使用了 Oracle 扩展类 oracle.sql.CLOB。但现在，Oracle JDBC 10g 进行了一些增强，简化了 JDBC 应用程序中的 CLOB 操作。这使得可以使用一些可用的标准 API 来处理大数据，而不是使用 Oracle 扩展类。
本文提供了有关此增强功能的详细信息：
默认情况下，preparedStatement.setString() 方法将允许处理最多 32765 字节的字符串。为了插入大于 32765 字节的数据，可以设置新引入的 Connection 属性 - SetBigStringTryClob。这会强制 preparedStatement.setString() 使用另一个新引入的方法 OraclePreparedStatement.setStringForClob() 来代替。
但它警告说：
...以这种方式处理大量数据可能并不明智；流式传输数据是更好的选择。
但以上是该文章中唯一与性能相关的警告。 我的问题是，如果我的代码中的所有 CLOB 访问已经都是通过 String 对象完成的，我是否应该担心这种方法更改可能导致的任何其他潜在性能问题？换句话说，我的应用程序没有利用流式传输提供的好处，因为它已经总是加载 String 对象中的 CLOB，因此上面的警告可能会被忽略，因为我们目前的目标不是提高性能。由于切换到此技术是否可能出现任何其他与性能相关的问题？
I am in process of reviewing some old Java/JDBC code for CLOB-handling on oracle database. Existing code uses approach similar to the approach mentioned in this question.
I found an article that states:
Prior to Oracle JDBC 10g, to manipulate the CLOB data in JDBC, Oracle extension class oracle.sql.CLOB was used. But now, Oracle JDBC 10g has a few enhancements that simplifies the CLOB manipulation in JDBC applications. This enables handling of large data using some of the available standard APIs, instead of using the Oracle extension classes.
The article gives following information about the details of this enhancement:
By default, the method preparedStatement.setString() will allow processing of the strings up to 32765 bytes. In order to insert data greater than 32765 bytes, a newly introduced Connection property - SetBigStringTryClob can be set. This forces the preparedStatement.setString() to use another newly introduced method, OraclePreparedStatement.setStringForClob() instead.
However it warns:
... handling very large amounts of data this way may not be a wise; streaming the data is a better alternative.
But above is the only performance-related warning in that article.
My question is that if all of the CLOB access in my code is already being done through String objects, should I worry about any other potential performance problems that this change of approach might cause? In other words, my app is not using the benefit offered by streaming as it already always load the CLOBs in String objects so above warning can probably be ignored because we are not aiming at performance improvement at the moment. Are there any other performance-related issues that might arise because of switching to this technique?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你说的是多大？我经常在内存中处理短音频文件和网页图像，没有任何性能问题。这些都是千字节级文件。我认为如果您运行兆字节大小，那么流式传输会更好。现在，通过标准化的东西，使用 LOB 流实际上非常容易。
How big are you talking about? I regularly handle short audio files and web images in memory without any performance issues. These are all kilobyte scale files. I think if you run megabyte sizes then streaming would be better. Using the streaming to a LOB is actually pretty easy now with the standardized stuff.