Question

我想要做的是说我在那个2中有一个包，在

下面有过程和2个功能

看起来像..

create or replace PACKAGE BODY xml_zip_pkg AS

PROCEDURE ZIP(src IN CLOB, dst IN OUT BLOB)
AS LANGUAGE JAVA
NAME 'com.oracle.ZipXml.zip(oracle.sql.CLOB, oracle.sql.BLOB[])';

PROCEDURE UNZIP(src IN BLOB, dst IN OUT CLOB)
AS LANGUAGE JAVA
NAME 'com.oracle.UnzipXml.unzipClob(oracle.sql.BLOB, oracle.sql.CLOB[])';

FUNCTION ZIP(src IN clob) RETURN blob
IS
 lvResult blob;
BEGIN
 IF src is not null THEN
  DBMS_LOB.createtemporary(lvResult, true, DBMS_LOB.CALL);
  xml_zip_pkg.ZIP(src, lvResult);
 END IF;
 RETURN lvResult;
END ZIP;

FUNCTION UNZIP(src IN blob) RETURN clob
IS
 lvResult clob;
BEGIN
 IF src is not null THEN
  DBMS_LOB.createtemporary(lvResult, true, DBMS_LOB.CALL);
  xml_zip_pkg.UNZIP(src, lvResult);
 END IF;
 RETURN lvResult;
END UNZIP;
END;

输出： -

select XML_ZIP_PKG.UNZIP(XML_ZIP_PKG.ZIP('abc xyz welcome to capa town') ) from dual;

abc xyz welcome to capa town

如果在函数中使用DBMS_LOB. FREETEMPORARY (lvResult);，则不是RETURN值

select XML_ZIP_PKG.UNZIP(XML_ZIP_PKG.ZIP('abc xyz welcome to capa town') ) from dual;

空值

请告诉我该软件包的内存问题有多接近。

Answer 1

目前尚不清楚您是否确实存在内存问题。 From the documentation：

临时LOB实例存在于您的应用程序中，直到它超出范围，您的会话终止或您明确释放该实例。建议释放临时LOB实例以释放系统资源。

您的函数正在返回临时LOB，因此它仍然在调用者的范围内。在这种情况下，调用者是您的SQL查询。查询完成后将释放临时LOB，因为它将超出范围。在退回之前，您不需要也不能释放它。如果您一次为多个值或多行调用函数，则只会出现内存问题;来自各种调用的临时LOB可能同时在范围内，并且可以共同使用比您想要的更多的内存。作为一个单一的电话，它确实不是一个问题。

您可以通过在函数调用之前和之后运行此查询来查看此内容：

select * from v$temporary_lobs where sid = sys_context('USERENV','SID');

在SQL * Plus中，之后显示cache_lobs为零。在SQL Developer中虽然它显示cache_lobs递增，这是我没想到的，这可能是一个JDBC问题。当会话结束时，它们仍然被释放，但它们一直持续到那时，显然。

在SQL * Plus和SQL Developer中调用匿名PL / SQL块中的函数仍然可以自动释放它（我认为这是有意义的，因为JDBC从未看到实际的CLOB）：

declare
  tmp clob;
begin
  tmp := XML_ZIP_PKG.UNZIP(XML_ZIP_PKG.ZIP('abc xyz welcome to capa town') );
end;
/

如果您愿意，还可以在块中添加DBMS_LOB.FREETEMPORARY(tmp);以明确释放它。

Answer 2

哪里有问题？虽然程序或函数blob分配器将在rollback / commit / disconnect之后释放。

为BLOB和CLOB分配的临时内存

2 个答案: