# ORA-64203 en AWR sobre Active Data Guard (19.26): análisis de un bug Si te mueves entre entornos Oracle 19c Enterprise Edition con Active Data Guard y tiras de Remote AWR, es muy probable que en algún momento te hayas cruzado con este regalito en los logs: ORA-64203 (Destination buffer too small to hold CLOB data after character set conversion). No es cosa de que hayas afinado mal una query o de que tengas un problema de rendimiento en tu base de datos. Es un bug de Oracle que te explota en la cara en cuanto usas juegos de caracteres multibyte como AL32UTF8. ## ¿Qué pinta tiene el error? El fallo salta sin avisar durante los volcados automáticos de AWR entre la standby y el destino a través del DB Link. Si te da por mirar la traza del proceso de fondo en la standby, te encuentras con esto: ```plaintext *** KEUUXS - encountered error: (ORA-64203: Destination buffer too small to hold CLOB data after character set conversion. ORA-02063: preceding line from ) *** SQLSTR: ... SQLSTR={INSERT INTO sys.wrhs$_sqltext@ ( stage_inst_id, stage_id, dbid, per_pdb, con_dbid, snap_id, sql_id, sql_text_l2c, command_type ) SELECT :instance_number, :snap_id, :dbid, ST.con_id, con_id_to_dbid(ST.con_id) con_dbid, :lah_snap_id, sqlid_kewrstx, to_char(substr(sqlfulltext_kewrstx, 1, 4000)), cmdtype_kewrstx FROM x$kewrtsqltext ST } kewrftecpc: Error=64203 encountered flushing table=13 ``` Lo que vemos es que kewrftecpc / KEUUXS intentar meter con calzador los datos. ## ¿Cuál es el impacto real? ¿Te deja sin AWR? Que no cunda el pánico: **el snapshot de AWR en la standby no se cae entero**. Como puedes comprobar en los logs, el proceso general sigue tirando y los snapshots se completan. El problema real y la faena de esto es que **te deja a ciegas con el texto de las queries**. Cuando salta el error: - Las métricas generales, los tiempos de espera y los `SQL_ID` se guardan sin problema. - Pero el volcado de la tabla `SYS.WRHS$_SQLTEXT` falla contra el DB Link por culpa del límite de bytes. ¿En qué se traduce esto para ti? Pues que cuando vayas a tirar de histórico o a sacar un informe AWR para cazar una query problemática en la standby, te vas a encontrar con el `SQL_ID` en el top de consumo, pero **el texto completo de la consulta no se habrá guardado** en el repositorio. Te quedarás con la mitad de la foto justo en las queries más largas o que tiran de caracteres multibyte. ## Dónde está el truco (y el fallo de diseño) Lo curioso es cómo trata Oracle el tema según dónde esté ejecutando: En la primaria: El AWR guarda el texto de la query (sqlfulltext_kewrstx) directamente en un CLOB en wrh$\_sqltext. En el volcado remoto desde la ADG Standby: monta una SQL dinámica que fuerza un to_char(substr(sqlfulltext_kewrstx, 1, 4000)). Aquí es donde se tropieza. Si tu entorno tira de AL32UTF8, una sentencia SQL puede medir 4000 caracteres o menos, pero superar holgadamente los 4000 bytes en cuanto metes caracteres multibyte. Cuando la función interna intenta empaquetar esa porción truncada en un tipo CHAR/VARCHAR2 clásico (que mide estrictamente sus límites en bytes, no en caracteres) para mandarlo al otro lado del DB Link, salta el ORA-64203. ¿Y lo peor? Que al ser una query generada automáticamente por el propio kernel sobre tablas fijas del sistema (x$kewrtsqltext), tú como DBA no puedes tocar ni una coma para arreglarlo. Estás totalmente atado de pies y manos. ## Estado actual El caso ya lo hemos escalado a soporte y lo tienen fichado bajo el Bug 40200481 (REMOTE AWR SQL-TEXT FLUSH FAILS WITH ORA-64203 ON 19.26), catalogado actualmente en pleno desarrollo (Development Working).