amazon web services - pricing - redshift drop o truncar la tabla muy muy lento

redshift render

Question

Cuando elimino o trunque una tabla no demasiado grande (filas de 4M) en mi base de datos de redshift, me lleva mucho tiempo (horas) completarla. ¿Alguien tiene el mismo problema?

Gracias

Answer 1

En mi experiencia, como dice @Gerardo Grignoli, los bloqueos no aparecen en la tabla stv_locks , pero aparecen en pg_locks . Dependiendo de su entorno, puede que no sea aceptable matar una sesión arbitraria de larga duración incluida en stv_sessions . Encuentro que la tabla pg_locks es muy confiable para detectar este tipo de bloqueo:

select * from pg_locks where relation = (select oid from pg_class where relname = ''the_table'')
select pg_cancel_backend(pid)

Normalmente, el problema es un bloqueo ACCESS EXCLUSIVE que bloquea la tabla. Entonces, si se enumeran muchos bloqueos, encuentre y elimine ACCESS EXCLUSIVE .

Answer 2

He experimentado el mismo problema. Resultó ser una transacción abierta ejecutada desde otro lugar.

Por ejemplo, si tienes 2 shells abiertos con redshift shell, no podrás soltar una tabla desde el primer shell, que participa en una transacción abierta en el segundo shell.

Después de comprometer / revertir en la segunda ventana, truncar funcionó perfectamente.

Espero que haya ayudado.

Answer 3

IMO AccessShareLock en las tablas también hace que los comandos DDL se atasquen.

Ejecute esta consulta para descubrir los pids de AccessShareLock

select
  current_time,
  c.relname,
  l.database,
  l.transaction,
  l.pid,
  a.usename,
  l.mode,
  l.granted
from pg_locks l
join pg_catalog.pg_class c ON c.oid = l.relation
join pg_catalog.pg_stat_activity a ON a.procpid = l.pid
where l.pid <> pg_backend_pid();

select pg_terminate_backend(<pid>); los procesos usando select pg_terminate_backend(<pid>);

Asegúrese de que todas sus aplicaciones de solo lectura se cierren y libere todas las conexiones y, por lo tanto, estos bloqueos.

Answer 4

Redshift tiene E / S muy rápido, por lo que la operación debería tomar menos de 1 segundo para cualquier tipo o tamaño de clúster. Como dijo diemacht, el problema se debe a que tiene otra conexión con una transacción abierta.

Tuve un problema similar: un bloqueo en el cliente dejó una transacción ''abierta'' pero sin acceso. No aparecieron bloqueos db en la tabla STV_LOCKS: (utilizando select table_id, last_update, lock_owner, lock_owner_pid from stv_locks; )

Además, aún no se ejecutaba ninguna consulta: (marcado con: select pid, trim(user_name), starttime, query , substring(query,1,20), status from stv_recents where status=''Running''; )

Así que la solución fue listar las sesiones de los usuarios: SELECT * FROM STV_SESSIONS Y luego matarlo usando: SELECT pg_terminate_backend(pid)

O la versión KILL''EM ALL:

SELECT pg_terminate_backend(process) FROM STV_SESSIONS where user_name=''user_name'' and process != pg_backend_pid();

Tenga en cuenta que CANCEL {pid} no funcionó! (la consulta se canceló pero la transacción aún estaba abierta y bloqueada).