¿Por qué se canceló mi consulta en Amazon Redshift?

Descripción breve

Se puede cancelar una consulta en Amazon Redshift por los siguientes motivos:

• Configuración de reglas de supervisión de consultas de administración de cargas de trabajo (WLM) de Amazon Redshift
• Valor de tiempo de espera de instrucción
• Solicitudes ABORT, CANCEL o TERMINATE
• Problemas de red
• Actualizaciones de mantenimiento de clúster
• Errores de procesamiento interno
• Errores ASSERT

Para evitar que la consulta se interrumpa, siga estos pasos:

• Incremente el parámetro de tiempo de espera.
• Actualice las reglas QMR de WLM.
• Programe operaciones de larga duración fuera de los períodos de mantenimiento.

Resolución

Configurar reglas de supervisión de consultas de WLM de Amazon Redshift

Cree reglas de supervisión de consultas (QMR) de WLM para definir límites de rendimiento basados en métricas para las colas. Como alternativa, especifique las acciones que lleva a cabo Amazon Redshift cuando una consulta supera los límites de tiempo de WLM. Por ejemplo, cree una regla que cancele las consultas que se ejecuten durante más de 60 segundos.

Ejemplo 1: anular la acción especificada en la regla de supervisión de consultas

Si se cancela una consulta debido a la acción anular que se especifica en una regla de supervisión de consultas, la consulta devuelve el siguiente error:

"ERROR: Query (500029) cancelled by WLM abort action of Query Monitoring Rule "testrule"."

Para identificar si una consulta se ha cancelado debido a una acción «anular», ejecute la siguiente consulta:

select * from STL_WLM_RULE_ACTION where action = 'abort';

El resultado de la consulta muestra todas las consultas que se cancelan mediante la acción «anular». Si el ID de su consulta aparece en la salida, aumente el límite de tiempo en el parámetro QMR de WLM.

Ejemplo 2: no hay colas disponibles para saltar la consulta

Se puede saltar una consulta si la acción «saltar» se especifica en la regla de supervisión de consultas. Cuando se salta una consulta, WLM trata de dirigir la consulta a la siguiente cola coincidente en función de las reglas de asignación de colas de WLM. Si la consulta no coincide con una definición de cola, se cancela. Una consulta cancelada no se reasigna a la cola predeterminada. Para obtener más información, consulte Propiedades del parámetro wlm_json_configuration.

Nota: Solo se pueden saltar consultas en una configuración manual de WLM.

Si se salta una consulta, pero no hay colas coincidentes disponibles, la consulta cancelada devolverá el siguiente mensaje de error:

"ERROR: Query (500104) canceled on user's request and ran out of wlm queues for restart."

Si la consulta se cancela con este mensaje de error, ejecute la siguiente consulta para comprobar las colas definidas por el usuario:

select * from stl_wlm_query where query=<query-id>;

En la salida, las entradas 6 a 13 de service_class incluyen las colas definidas por el usuario. Por ejemplo, la entrada 6 de service_class podría incluir Queue1 en la configuración de WLM, y la entrada 7 de service_class podría incluir Queue2.

Ejecute la siguiente consulta para obtener más información sobre la asignación de service_class a las colas:

select * from stv_wlm_service_class_config where service_class>5;

Tras obtener la información de asignación a colas, compruebe la configuración de WLM en la consola de Amazon Redshift. Compruebe que las colas coincidan con la configuración de WLM. Solo puede saltar una consulta si hay una cola coincidente disponible para la configuración de grupo de usuarios o de grupo de consultas. Para obtener más información, consulte Salto de cola de consultas de WLM.

Valor de tiempo de espera de instrucción

El valor de statement_timeout es la cantidad máxima de tiempo en que se ejecuta una consulta antes de que Amazon Redshift la termine. Cuando se supera el tiempo de espera de una instrucción, las consultas enviadas durante la sesión se cancelan con el siguiente mensaje de error:

«ERROR: Consulta (150) cancelada a petición del usuario»

Para comprobar si se canceló una consulta debido al tiempo de espera de una instrucción, ejecute la siguiente consulta:

select * from SVL_STATEMENTTEXT where text ilike '%set%statement_timeout%to%' and pid in (select pid from STL_QUERY where query = <queryid>);

Los tiempos de espera de instrucciones también se pueden establecer en el grupo de parámetros del clúster. Compruebe el grupo de parámetros del clúster y cualquier configuración de statement_timeout para obtener una confirmación adicional. Para obtener más información, consulte Modificación de un grupo de parámetros.

Solicitudes ABORT, CANCEL o TERMINATE

Para comprobar si un usuario (por ejemplo, un superusuario) ha interrumpido o cancelado una consulta concreta, ejecute la siguiente consulta con el ID de su consulta:

select * from SVL_STATEMENTTEXT where text ilike '%cancel%' and xid
    in (select xid from STL_QUERY where query = <queryid>);
select * from SVL_STATEMENTTEXT where text ilike '%abort%' and xid in (select xid from STL_QUERY where query = <queryid>);

Si la consulta aparece en la salida, la consulta se interrumpió o canceló a petición del usuario.

Nota: Los usuarios solo pueden terminar su propia sesión. Un superusuario puede terminar todas las sesiones.

Las consultas también se pueden interrumpir cuando un usuario cancela o termina un proceso correspondiente (en el que se está ejecutando la consulta). A continuación, se muestran ejemplos de procesos que pueden cancelar o terminar una consulta:

• PG_TERMINATE_BACKEND
• PG_CANCEL_BACKEND
• CANCEL

Cuando estos comandos cancelan o terminan un proceso, se registra una entrada en SVL_TERMINATE. Para confirmar si una consulta se interrumpió porque terminó una sesión, compruebe los registros SVL_TERMINATE. Ejecute la siguiente consulta para comprobar los registros SVL_TERMINATE:

select * from SVL_TERMINATE where pid=(select pid from STL_QUERY where query=500534);

Problemas de red

A veces, las consultas se cancelan debido a problemas de red subyacentes. Para comprobar si los problemas de red están provocando la cancelación de su consulta, ejecute la siguiente consulta para comprobar las entradas STL_CONNECTION_LOG:

select * from STL_CONNECTION_LOG where pid in (select pid from STL_QUERY where query = <query_id>);

La entrada STL_CONNECTION_LOG registra los intentos de autenticación y las conexiones o desconexiones de red. Si la consulta aparece en la salida, es posible que un problema de conexión de red esté provocando la cancelación de su consulta.

Actualizaciones de mantenimiento de clúster

Si se lleva a cabo un mantenimiento programado mientras se ejecuta una consulta, finaliza y se restaura, por lo que es necesario reiniciar el clúster. Programe operaciones de larga duración (como grandes cargas de datos o la operación VACUUM) para evitar periodos de mantenimiento. Para obtener más información, consulte Programación de periodos de mantenimiento.

Para comprobar si se llevó a cabo el mantenimiento en su clúster de Amazon Redshift, seleccione la pestaña Eventos de la consola de Amazon Redshift.

Errores de procesamiento interno

La tabla STL_ERROR registra los errores de procesamiento internos generados por Amazon Redshift. La tabla STL_ERROR no registra errores ni mensajes de SQL.

Para comprobar si su consulta se canceló por un error interno, ejecute la siguiente consulta para comprobar las entradas STL_ERROR:

select * from STL_ERROR where userid=<user id>;

Errores ASSERT

A veces, las consultas se interrumpen debido a un error ASSERT. El error ASSERT puede producirse cuando hay un problema con la propia consulta. Si aparece un error ASSERT después de una actualización de parche, actualice Amazon Redshift a la versión de clúster más reciente. A continuación, compruebe el historial de versiones del clúster. Como alternativa, puede restaurar la versión del clúster.