Solución de problemas de errores de aislamiento serializable - Amazon Redshift
ERROR:1023 DETAIL: Serializable isolation violation on a table in RedshiftERROR:1018 DETAIL: Relation does not exist

Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del 1 de noviembre de 2025. Si desea utilizar las UDF de Python, créelas antes de esa fecha. Las UDF de Python existentes seguirán funcionando con normalidad. Para obtener más información, consulte la publicación del blog.

Solución de problemas de errores de aislamiento serializable

ERROR:1023 DETAIL: Serializable isolation violation on a table in Redshift

Cuando Amazon Redshift detecta un error de aislamiento serializable, se muestra un mensaje de error como el siguiente.

ERROR:1023 DETAIL: Serializable isolation violation on table in Redshift

Para solucionar el error de aislamiento serializable, puede probar los métodos siguientes:

  • Volver a intentar la transacción cancelada.

    Amazon Redshift detectó que una carga de trabajo simultánea no es serializable. Sugiere que hay deficiencias en la lógica de la aplicación, que por lo general se pueden solucionar si se intenta realizar la transacción en la que se encontró el error de nuevo. Si el problema persiste, pruebe uno de los métodos siguientes.

  • Mover cualquier operación que no tenga que estar en la misma transacción atómica fuera de la transacción.

    Este método se aplica cuando las operaciones individuales dentro de dos transacciones tienen referencias cruzadas entre sí de forma que pueden afectar al resultado de la otra transacción. Por ejemplo, las dos sesiones siguientes inician una transacción cada una. 

    Session1_Redshift=# begin;
    Session2_Redshift=# begin;

    El resultado de la instrucción SELETCT en cada transacción se podría ver afectado por una instrucción INSERT en la otra. Dicho de otro modo, suponga que ejecuta las siguientes instrucciones en serie, en cualquier orden. En cada caso, el resultado es que una de las instrucciones SELECT devuelve una fila más que si las transacciones se ejecutaran de forma simultánea. No hay ningún orden en que las operaciones se puedan ejecutar en serie que produzca el mismo resultado que cuando se ejecutan de forma simultánea. Así, la última operación que se ejecuta da lugar a un error de aislamiento serializable.

    Session1_Redshift=# select * from tab1;
Session1_Redshift=# insert into tab2 values (1);
    Session2_Redshift=# insert into tab1 values (1);
Session2_Redshift=# select * from tab2;

    En muchos casos, el resultado de las instrucciones SELECT no es importante. Dicho de otro modo, la atomicidad de las operaciones en las transacciones no es importante. En estos casos, saque las instrucciones SELECT de sus transacciones, como se muestra en los ejemplos siguientes.

    Session1_Redshift=# begin;
Session1_Redshift=# insert into tab1 values (1)
Session1_Redshift=# end;
Session1_Redshift=# select * from tab2;
    Session2_Redshift # select * from tab1;
Session2_Redshift=# begin;
Session2_Redshift=# insert into tab2 values (1)
Session2_Redshift=# end;

    En estos ejemplos, no hay ninguna referencia cruzada en las transacciones. Las dos instrucciones INSERT no se ven afectadas entre sí. En estos ejemplo, hay al menos un orden en el que las transacciones se pueden ejecutar en serie y producir el mismo resultado que si se ejecutan de manera simultánea. Estos significa que las transacciones son serializables.

  • Obligue a la serialización bloqueando todas las tablas en cada sesión.

    El comando LOCK bloquea operaciones que dan lugar a errores de aislamiento serializable. Cuando utilice el comando LOCK, asegúrese de hacer lo siguiente:

    • Bloquee todas las tablas que se ven afectadas por la transacción, incluidas aquellas afectadas por instrucciones SELECT de solo lectura dentro de la transacción.

    • Bloquee las tablas en el mismo orden, con independencia del orden en que se ejecutan las operaciones.

    • Bloquee todas las tablas al principio de la transacción, antes de llevar a cabo alguna operación.

  • Utilizar el aislamiento de instantáneas para transacciones simultáneas

    Utilice un comando ALTER DATABASE con aislamiento de instantáneas. Para obtener más información sobre el parámetro SNAPSHOT para ALTER DATABASE, consulte Parameters.

ERROR:1018 DETAIL: Relation does not exist

Cuando ejecuta operaciones simultáneas de Amazon Redshift en sesiones diferentes, se muestra un mensaje de error como el siguiente.

ERROR: 1018 DETAIL: Relation does not exist.

Las transacciones en Amazon Redshift utilizan el aislamiento de la instantánea. Una vez que se inicia una transacción, Amazon Redshift toma una instantánea de la base de datos. En todo el ciclo de vida de la transacción, la transacción realiza las operaciones en el estado de la base de datos como se refleja en la instantánea. Si la transacción realiza la lectura desde una tabla que no existe en la instantánea, arroja el mensaje de error 1018 mostrado anteriormente. Incluso cuando otra transacción simultánea crea una tabla después de que la transacción haya tomado la instantánea, la transacción no puede realizar la lectura desde la tabla recién creada.

Para solucionar este error de serialización del aislamiento, puede intentar cambiar el inicio de la transacción a un punto en el que sepa que existe la tabla.

Si otra transacción crea la tabla, este punto será después de que se haya confirmado la transacción. Además, asegúrese de que no se haya confirmado ninguna transacción simultánea que pueda haber eliminado la tabla.

session1 = # BEGIN;
session1 = # DROP TABLE A;
session1 = # COMMIT;
session2 = # BEGIN;
session3 = # BEGIN;
session3 = # CREATE TABLE A (id INT);
session3 = # COMMIT;
session2 = # SELECT * FROM A;

La última operación que ejecuta session2 como la operación de lectura da lugar a un error de aislamiento serializable. Este error ocurre cuando session2 toma una instantánea y la tabla ya ha sido eliminada por una session1 confirmada. En otras palabras, aunque una session3 simultánea haya creado la tabla, la session2 no ve la tabla porque no está en la instantánea.

Para resolver este error, puede reordenar las sesiones de la siguiente manera.

session1 = # BEGIN;
session1 = # DROP TABLE A;
session1 = # COMMIT;
session3 = # BEGIN;
session3 = # CREATE TABLE A (id INT);
session3 = # COMMIT;
session2 = # BEGIN;
session2 = # SELECT * FROM A;

Cuando session2 toma su instantánea, session3 ya se ha confirmado y la tabla está en la base de datos. La session2 puede leer desde la tabla sin ningún error.