View a markdown version of this page

Memecahkan masalah kesalahan isolasi yang dapat diserialisasi - Amazon Redshift

Amazon Redshift tidak akan lagi mendukung penggunaan Python UDF setelah 30 Juni 2026. Kami akan mulai menegakkannya secara bertahap. Untuk informasi lebih lanjut tentang detail opsi akhir masa pakai dan migrasi Python, lihat posting blog yang diterbitkan pada 30 Juni 2025.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memecahkan masalah kesalahan isolasi yang dapat diserialisasi

ERROR:1023 DETAIL: Pelanggaran isolasi yang dapat diserialkan pada tabel di Redshift

Saat Amazon Redshift mendeteksi kesalahan isolasi yang dapat diserialisasi, Anda akan melihat pesan kesalahan seperti berikut ini.

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

Untuk mengatasi kesalahan isolasi yang dapat diserialisasi, Anda dapat mencoba metode berikut:

  • Coba lagi transaksi yang dibatalkan.

    Amazon Redshift mendeteksi bahwa beban kerja bersamaan tidak dapat diserialkan. Ini menunjukkan kesenjangan dalam logika aplikasi, yang biasanya dapat diatasi dengan mencoba kembali transaksi yang mengalami kesalahan. Jika masalah berlanjut, coba salah satu metode lainnya.

  • Pindahkan operasi apa pun yang tidak harus berada dalam transaksi atom yang sama di luar transaksi.

    Metode ini berlaku ketika operasi individu di dalam dua transaksi saling mereferensikan satu sama lain dengan cara yang dapat mempengaruhi hasil transaksi lainnya. Misalnya, dua sesi berikut masing-masing memulai transaksi.

    Session1_Redshift=# begin;
    Session2_Redshift=# begin;

    Hasil dari pernyataan SELECT di setiap transaksi mungkin dipengaruhi oleh pernyataan INSERT di yang lain. Dengan kata lain, misalkan Anda menjalankan pernyataan berikut secara serial, dalam urutan apa pun. Dalam setiap kasus, hasilnya adalah salah satu pernyataan SELECT yang mengembalikan satu baris lebih banyak daripada jika transaksi dijalankan secara bersamaan. Tidak ada urutan di mana operasi dapat berjalan secara serial yang menghasilkan hasil yang sama seperti ketika dijalankan secara bersamaan. Dengan demikian, operasi terakhir yang dijalankan menghasilkan kesalahan isolasi yang dapat diserialisasi.

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

    Dalam banyak kasus, hasil pernyataan SELECT tidak penting. Dengan kata lain, atomisitas operasi dalam transaksi tidak penting. Dalam kasus ini, pindahkan pernyataan SELECT di luar transaksi mereka, seperti yang ditunjukkan dalam contoh berikut.

    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;

    Dalam contoh-contoh ini, tidak ada referensi silang dalam transaksi. Kedua pernyataan INSERT tidak saling mempengaruhi. Dalam contoh ini, setidaknya ada satu urutan di mana transaksi dapat berjalan secara serial dan menghasilkan hasil yang sama seolah-olah dijalankan secara bersamaan. Ini berarti bahwa transaksi dapat diserialisasi.

  • Paksa serialisasi dengan mengunci semua tabel di setiap sesi.

    Per KUNCI intah memblokir operasi yang dapat mengakibatkan kesalahan isolasi yang dapat diserialisasi. Saat Anda menggunakan perintah LOCK, pastikan untuk melakukan hal berikut:

    • Kunci semua tabel yang terpengaruh oleh transaksi, termasuk yang terpengaruh oleh pernyataan SELECT read-only di dalam transaksi.

    • Kunci tabel dalam urutan yang sama, terlepas dari urutan operasi yang dilakukan.

    • Kunci semua tabel di awal transaksi, sebelum melakukan operasi apa pun.

  • Gunakan isolasi snapshot untuk transaksi bersamaan

    Gunakan perintah ALTER DATABASE dengan isolasi snapshot. Untuk informasi selengkapnya tentang parameter SNAPSHOT untuk ALTER DATABASE, lihatParameter.

ERROR:1018 DETAIL: Hubungan tidak ada

Saat menjalankan operasi Amazon Redshift bersamaan di sesi yang berbeda, Anda akan melihat pesan galat seperti berikut ini.

ERROR: 1018 DETAIL: Relation does not exist.

Transaksi di Amazon Redshift mengikuti isolasi snapshot. Setelah transaksi dimulai, Amazon Redshift mengambil snapshot dari database. Untuk seluruh siklus hidup transaksi, transaksi beroperasi pada status database seperti yang tercermin dalam snapshot. Jika transaksi dibaca dari tabel yang tidak ada di snapshot, itu akan menampilkan pesan kesalahan 1018 yang ditampilkan sebelumnya. Bahkan ketika transaksi bersamaan lainnya membuat tabel setelah transaksi mengambil snapshot, transaksi tidak dapat membaca dari tabel yang baru dibuat.

Untuk mengatasi kesalahan isolasi serialisasi ini, Anda dapat mencoba memindahkan awal transaksi ke titik di mana Anda tahu tabel ada.

Jika tabel dibuat oleh transaksi lain, titik ini setidaknya setelah transaksi itu dilakukan. Juga, pastikan bahwa tidak ada transaksi bersamaan yang dilakukan yang mungkin telah menjatuhkan tabel.

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

Operasi terakhir yang dijalankan sebagai operasi baca oleh session2 menghasilkan kesalahan isolasi yang dapat diserialisasi. Kesalahan ini terjadi ketika session2 mengambil snapshot dan tabel telah dihapus oleh sesi yang dikomitmen1. Dengan kata lain, meskipun sesi serentakan3 telah membuat tabel, session2 tidak melihat tabel karena tidak ada di snapshot.

Untuk mengatasi kesalahan ini, Anda dapat menyusun ulang sesi sebagai berikut.

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

Sekarang ketika session2 mengambil snapshot, session3 telah dilakukan, dan tabel ada di database. Session2 dapat membaca dari tabel tanpa kesalahan apa pun.