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:
*** KEUUXS - encountered error: (ORA-64203: Destination buffer too small to hold CLOB data after character set conversion. ORA-02063: preceding line from <DB_DESTINO> ) *** SQLSTR: ... SQLSTR={INSERT INTO sys.wrhs$_sqltext@<DB_LINK> ( 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_IDse guardan sin problema. - Pero el volcado de la tabla
SYS.WRHS$_SQLTEXTfalla 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).
About the author
Mi nombre es Carla y me defino como una apasionada de conocer, compartir ideas, divertirme y aprender todo lo relacionado con Oracle.
Alegre y creativa, con un alto grado de autoexigencia, que busca, incluso sin querer, una forma diferente de ver un mismo problema o solución. Defensora del trabajo en equipo en todas las facetas de la vida y de disfrutar todo lo que haces, siempre con humildad.
Actualmente cuento con más de 15 años de experiencia como administradora de Oracle, habiendo ocupado previamente posiciones como desarrolladora en la rama de Inteligencia de Negocios. Fue en ese momento que me di cuenta de que no quería centrarme en el desarrollo, sino participar en todas las capas que involucraban los datos, desde el despliegue de la base de datos hasta su explotación final.
Siempre estoy dispuesta a ayudar y compartir conocimientos. Creo firmemente que con la tecnología hay que divertirse y no verla como una competencia. La persona con la que tienes que ser el mejor es contigo mismo.
Comments
Join the discussionNo comments yet. Be the first to comment.
