执行这条SQL语句的时候报错：ORA-01489: 字符串连接的结果过长，请怎么解决 是增加字符串链接么

Posted 2023-04-03

语句：
WITH DM_TBLS AS
(SELECT DECODE(T.DATA_TYPE,
'CHAR',
'''''''''||' || T.COLUMN_NAME || '||''''''''',
'VARCHAR2',
'''''''''||' || T.COLUMN_NAME || '||''''''''',
'DATE',
'''TO_DATE(''''''||to_char(' || T.COLUMN_NAME ||
',''YYYY-MM-DD HH24:MI:SS'')||'''''',''''YYYY-MM-DD HH24:MI:SS'''')''',
T.COLUMN_NAME) COLUMN_NAME,
T.COLUMN_ID,
T.TABLE_NAME,
T.OWNER,
T.COLUMN_NAME COL1,
LAG(COLUMN_ID) OVER(PARTITION BY T.TABLE_NAME ORDER BY T.COLUMN_ID) RN
FROM DBA_TAB_COLUMNS T
WHERE T.OWNER = UPPER('&V_OWNER'))
SELECT --T.TABLE_NAME,T.OWNER,
'SELECT ''INSERT INTO '||T.OWNER||'.'||T.TABLE_NAME||' (''||' ||
REPLACE(SUBSTRB(MAX(CHR(64 + LEVEL) || SYS_CONNECT_BY_PATH(T.COLUMN_NAME, '#')),
3),
'#',
'||'',''||') || '||'');'' TEXT FROM ' || T.OWNER || '.' || T.TABLE_NAME || ';' mysql
FROM DM_TBLS T
START WITH RN IS NULL
CONNECT BY RN = PRIOR COLUMN_ID
AND TABLE_NAME = PRIOR TABLE_NAME
GROUP BY T.OWNER,
T.TABLE_NAME;

参考技术A 应该是说，你拼接的查询结果，某些行已经超过了varchar2(4000)的最大长度。 参考技术B 这要看SQL的版本与支援厂商

遭遇ORA-04063

刚刚，客户的缴费系统突然报错，应用程序在后台提示执行某个存储过程时出错，手动在PLSQL DEVELOPER工具上执行那段报错的代码，错误显示如下：

可以看出，这段代码提示ORA-04063，在访问某个view时报错。

最开始，怀疑这个视图是否正常，让客户执行SQL语句检查这个视图的状态。

 

 

 可以看出，这个视图没有任何问题。我让客户把整个存储过程发过来，发现报错的地方是通过DBLINK访问远程数据库上的一个视图。

此时，客户也在积极地做着各种测试。发现只要在通过PL/SQL代码块就报ORA-04063错误，单独通过DBLINK访问都没有任何问题，测试过程如图：

 

 

 

         这些测试可以说明，这个问题与视图没有任何关系，因为在PL/SQL块里通过DBLINK访问原表都报错。

 

        通过关键字“ora-04063 dblink”进行搜索，发现MOS上有一篇文章：

Accessing TABLE From READ ONLY DATABASE Using DATABASE LINK Within PL/SQL Fails With ORA-06550 ORA-04063 or PLS-00905(Doc ID 358697.1)

        这篇文章提到，当在PL/SQL中通过DBLINK访问READ ONLY数据库时，有可能会出现ORA-04063错误。

错误原因：

CAUSE

This is expected behavior.

Compiling the PL/SQL block we require internal structures of the table, which is not yet generated in the read only database.

This has been identified in:
Bug 2798026 ORA-6550 / PLS-905 WHEN RUNNING PL/SQL OVER DBLINK TO READ ONLY STANDBY DATABASE

        询问客户当前数据库是个怎样的架构，客户反馈：源端是19C的RAC，生产库是11.2.0.2 RAC，在生产库上建立了DBLINK访问19C上的数据，并且源端的19C是一个Dataguard环境的备端。

 

        看起来，这个问题与这篇MOS文章的匹配度蛮高的，赶紧让客户看看这个文章。但客户觉得这个系统已经使用很久了，这个PL/SQL代码块也运行了很久，怎么突然就不行了？如果是这个问题，理论上应该系统刚上线就出错才对呀。我一时无以反驳。。。

        报着试试的想法，客户根据MOS文章中的workaread进行了修改。发现执行了workaread后，问题竟然解决了。那说明刚刚遭遇的故障真是这篇MOS提到的情况。

        对于这个问题，ORACLE官方就不认为是一BUG，所以也没有相应的补丁。