Muchos FETCH con pocas filas

El hallazgo FETCH_PEQUENO aparece cuando la aplicación hace muchos FETCH con pocas filas cada uno, en promedio. Un fetch size mayor reduce las idas y vueltas.

Se aplica a: Traces 10046, con o sin esperas

Cada FETCH es una llamada de la aplicación a la base de datos. Con pocas filas por FETCH, la aplicación paga una ida y vuelta por cada puñado de filas para leer lo que cabría en muchas menos llamadas.

Síntomas

En el Diagnóstico aparece el hallazgo Muchos FETCH con pocas filas (FETCH_PEQUENO). El texto dice cuántos FETCH hubo y cuántas filas trajo cada uno en promedio, por ejemplo 5.000 FETCH devolvieron 1,0 filas cada uno, en promedio, sugiere aumentar el array size (fetch size) del cliente y termina con Ver tipos de llamada.

El hallazgo cuenta solo los FETCH de nivel 0, los que pidió la aplicación: aparece cuando son muchos y traen, en promedio, pocas filas cada uno. Los FETCH de SQL recursivo, como los de PL/SQL, no entran en la cuenta. La gravedad es siempre media, y el porcentaje al lado es la duración de esos FETCH sobre el tiempo total.

Causa

El número de filas por FETCH es el array size (o fetch size) del cliente. Con array size 1, leer 10.000 filas cuesta 10.000 FETCH. En general, el mayor costo no está en el FETCH en sí, sino en la espera SQL*Net message from client entre un FETCH y el siguiente, que el porcentaje del hallazgo no incluye. Dos situaciones llevan al hallazgo:

Cursor leído en lotes pequeños: pocos EXEC y muchos FETCH. El array size del cliente está bajo.
Muchas consultas de una fila: el número de FETCH queda cerca del número de EXEC, y cada ejecución devuelve una sola fila. Aumentar el array size no ayuda: la aplicación hace una consulta por elemento.

Solución

Separe las dos situaciones. En Sentencias SQL, compare Exec, Fetch y Filas de las sentencias con Prof. 0.
Si hay pocos EXEC y muchos FETCH, aumente el array size en el cliente. En SQL*Plus:
```
set arraysize 500
```
En JDBC, por statement:
```
stmt.setFetchSize(500);
```
En python-oracledb:
```
cursor.arraysize = 500
```
Pruebe algunos valores: la ganancia es grande en los primeros aumentos y después se estabiliza, y los valores muy altos gastan memoria en el cliente.
Si FETCH y EXEC son parecidos, cambie las consultas de una fila por una consulta que traiga todo de una vez, con un join o con la lista de valores.
Para DML, el equivalente es enviar las filas en lotes: array DML, o addBatch y executeBatch en JDBC.

Cómo confirmar

Genere un trace nuevo de la misma operación después del cambio. En la sentencia, Fetch debe bajar y Filas quedar igual; en el perfil, las Ocurrencias de SQL*Net message from client bajan también, y el Tiempo total con ellas. El hallazgo desaparece cuando los FETCH de la aplicación pasan a traer muchas filas cada uno.

En el informe

El informe de ejemplo tiene solo 2 FETCH, sin este hallazgo. Los enlaces abren las secciones del ejemplo:

Diagnóstico: el hallazgo y el enlace Ver tipos de llamada.
Tipos de llamada: fila FETCH, Cantidad y Filas. Esa tabla suma todas las profundidades, incluido el SQL recursivo, y el hallazgo usa solo el nivel 0: en el ejemplo, uno de los 2 FETCH es de la sentencia recursiva #2.
Sentencias SQL por contribución: Prof., Exec, Fetch y Filas de cada sentencia.
Perfil, fila SQL*Net message from client: las idas y vueltas entre los FETCH.
Distribución de latencia del FETCH: la duración de cada llamada FETCH.

Este hallazgo suele aparecer junto con el de la sesión esperando a la aplicación.

Actualizado el 29/10/2026. Informar un error en esta página