Amazon Redshift tidak akan lagi mendukung pembuatan Python UDFs baru mulai Patch 198. Python yang ada UDFs akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat [posting blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Mengelola operasi tulis bersamaan Beberapa aplikasi tidak hanya memerlukan kueri dan pemuatan bersamaan, tetapi juga kemampuan untuk menulis ke beberapa tabel atau tabel yang sama secara bersamaan. Dalam konteks ini, *secara bersamaan* berarti tumpang tindih, tidak dijadwalkan untuk berjalan pada waktu yang bersamaan. Dua transaksi dianggap bersamaan jika yang kedua dimulai sebelum komitmen pertama. Operasi bersamaan dapat berasal dari sesi berbeda yang dikendalikan baik oleh pengguna yang sama atau oleh pengguna yang berbeda. Amazon Redshift mendukung jenis aplikasi ini dengan memungkinkan tabel dibaca saat sedang dimuat atau dimodifikasi secara bertahap. Kueri hanya melihat versi komit terbaru, atau *snapshot*, dari data, daripada menunggu versi berikutnya untuk dilakukan. Jika Anda ingin kueri tertentu menunggu komit dari operasi penulisan lain, Anda harus menjadwalkannya sesuai. **catatan** Amazon Redshift mendukung perilaku *komit otomatis default di mana masing-masing menjalankan komit* perintah SQL secara terpisah satu per satu. Jika Anda melampirkan satu set perintah dalam blok transaksi (didefinisikan oleh [MULAI](r_BEGIN.md) dan [AKHIR](r_END.md) pernyataan), blok tersebut melakukan sebagai satu transaksi, sehingga Anda dapat memutar kembali jika perlu. Pengecualian untuk perilaku ini adalah perintah TRUNCATE dan VACUUM, yang secara otomatis melakukan semua perubahan yang belum selesai yang dibuat dalam transaksi saat ini. Beberapa klien SQL mengeluarkan perintah BEGIN dan COMMIT secara otomatis, sehingga klien mengontrol apakah sekelompok pernyataan dijalankan sebagai transaksi atau setiap pernyataan individu dijalankan sebagai transaksinya sendiri. Periksa dokumentasi untuk antarmuka yang Anda gunakan. Misalnya, saat menggunakan driver Amazon Redshift JDBC, JDBC `PreparedStatement` dengan string kueri yang berisi beberapa perintah SQL (dipisahkan titik koma) menjalankan semua pernyataan sebagai satu transaksi. Sebaliknya, jika Anda menggunakan SQL Workbench/J dan mengatur AUTO COMMIT ON, maka jika Anda menjalankan beberapa pernyataan, setiap pernyataan berjalan sebagai transaksinya sendiri. Topik berikut menjelaskan beberapa konsep kunci dan kasus penggunaan yang melibatkan transaksi, snapshot database, pembaruan, dan perilaku bersamaan. **Topics** + [Tingkat isolasi di Amazon Redshift](c_serial_isolation.md) + [Menulis dan read/write operasi](c_write_readwrite.md) + [Contoh tulis bersamaan](r_Serializable_isolation_example.md) + [Memecahkan masalah kesalahan isolasi serial](c_serial_isolation-serializable-isolation-troubleshooting.md) # Tingkat isolasi di Amazon Redshift Operasi penulisan bersamaan didukung di Amazon Redshift dengan cara protektif, menggunakan kunci tulis pada tabel dan *prinsip isolasi serial.* Isolasi serializable mempertahankan ilusi bahwa transaksi yang berjalan melawan tabel adalah satu-satunya transaksi yang berjalan melawan tabel itu. Basis data Amazon Redshift mendukung operasi penulisan bersamaan dengan meminta setiap operasi menggunakan versi komit terbaru, atau snapshot, dari data mereka pada awal transaksi. Sebuah snapshot database dibuat dalam transaksi pada kemunculan pertama dari sebagian besar pernyataan SELECT, perintah DMLseperti COPY, DELETE, INSERT, UPDATE, dan TRUNCATE, dan perintah DDL berikut: + ALTER TABLE (untuk menambah atau menjatuhkan kolom) + CREATE TABLE + MEJA DROP + MEMOTONG TABEL Tidak ada transaksi lain yang dapat mengubah snapshot ini, artinya transaksi terisolasi satu sama lain. Artinya, transaksi bersamaan tidak terlihat satu sama lain dan tidak dapat mendeteksi perubahan satu sama lain. Eksekusi transaksi bersamaan harus menghasilkan hasil yang sama dengan eksekusi serial dari transaksi tersebut. Jika tidak ada eksekusi serial dari transaksi tersebut yang dapat menghasilkan hasil yang sama, transaksi yang menjalankan pernyataan yang mungkin merusak kemampuan untuk membuat serial dihentikan dan digulung kembali. Misalnya, pengguna mencoba menjalankan dua transaksi bersamaan, T1 dan T2. Menjalankan T1 dan T2 harus menghasilkan hasil yang sama dengan setidaknya salah satu skenario berikut: + T1 dan T2 berjalan secara serial dalam urutan itu. + T2 dan T1 berjalan secara serial dalam urutan itu. Tingkat isolasi di Amazon Redshift mencegah masalah berikut: + Pembacaan kotor - Pembacaan kotor terjadi ketika transaksi membaca data yang belum dilakukan. Misalnya, transaksi 1 memperbarui baris. Transaksi 2 membaca baris yang diperbarui sebelum T1 melakukan pembaruan. Jika T1 mengembalikan perubahan, T2 akan membaca data dalam baris yang tidak terikat yang sekarang dianggap Amazon Redshift tidak pernah ada. + Pembacaan yang tidak dapat diulang - Pembacaan yang tidak dapat diulang terjadi ketika satu transaksi membaca baris yang sama dua kali tetapi mendapatkan data yang berbeda setiap kali. Misalnya, transaksi 1 membaca satu baris. Transaksi 2 memperbarui atau menghapus baris itu dan melakukan pembaruan atau penghapusan. Jika T1 membaca ulang baris, ia mengambil nilai baris yang berbeda atau menemukan bahwa baris telah dihapus. + Phantom adalah baris yang cocok dengan kriteria pencarian tetapi awalnya tidak terlihat. Misalnya, transaksi 1 membaca satu set baris yang memenuhi kriteria pencariannya. Transaksi 2 menghasilkan baris baru dalam pernyataan UPDATE atau INSERT yang cocok dengan kriteria pencarian untuk T1. Jika T1 menjalankan kembali pernyataan pencariannya, ia mendapat serangkaian baris yang berbeda. ## Isolasi SNAPSHOT dan SERIALIZABLE Isolasi SNAPSHOT dan SERIALIZABLE adalah dua tingkat isolasi serial yang tersedia di Amazon Redshift. Isolasi SNAPSHOT adalah tingkat isolasi default saat membuat cluster yang disediakan dan grup kerja tanpa server, memungkinkan Anda memproses volume data yang lebih besar daripada isolasi SERIALIZABLE dalam waktu yang lebih singkat. Isolasi SERIALIZABLE membutuhkan lebih banyak waktu, tetapi menerapkan batasan yang lebih ketat pada transaksi bersamaan. Tingkat isolasi ini mencegah masalah seperti anomali write-skew dengan hanya mengizinkan satu transaksi untuk dilakukan, sementara membatalkan semua transaksi bersamaan lainnya dengan kesalahan pelanggaran isolasi serializable. Berikut ini adalah contoh timeline tentang bagaimana dua operasi penulisan bersamaan akan ditangani saat menggunakan isolasi SNAPSHOT. Setiap pernyataan UPDATE pengguna diizinkan untuk melakukan komit karena mereka tidak bertentangan dengan mencoba memperbarui baris yang sama. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/c_serial_isolation.html) Jika skenario yang sama dijalankan menggunakan isolasi serial, Amazon Redshift menghentikan pengguna 2 karena pelanggaran serial dan mengembalikan kesalahan. `1023` Untuk informasi selengkapnya, lihat [Memecahkan masalah kesalahan isolasi serial](c_serial_isolation-serializable-isolation-troubleshooting.md). Dalam hal ini, hanya pengguna 1 yang dapat melakukan komit dengan sukses. ## Pertimbangan-pertimbangan Saat menggunakan tingkat isolasi di Amazon Redshift, pertimbangkan hal berikut: + Kueri tampilan katalog STV\$1DB\$1ISOLATION\$1LEVEL untuk melihat tingkat isolasi yang digunakan database Anda. Untuk informasi selengkapnya, lihat [STV\$1DB\$1ISOLASI\$1TINGKAT](r_STV_DB_ISOLATION_LEVEL.md). + Kueri tampilan PG\$1DATABASE\$1INFO untuk melihat berapa banyak transaksi bersamaan yang didukung untuk database Anda. Untuk informasi selengkapnya, lihat [PG\$1DATABASE\$1INFO](r_PG_DATABASE_INFO.md). + Tabel katalog sistem (PG) dan tabel sistem Amazon Redshift lainnya tidak terkunci dalam transaksi. Oleh karena itu, perubahan pada objek database yang muncul dari operasi DDL dan TRUNCATE terlihat pada komit untuk setiap transaksi bersamaan. Misalnya, anggaplah tabel A ada dalam database ketika dua transaksi bersamaan, T1 dan T2, dimulai. Misalkan T2 mengembalikan daftar tabel dengan memilih dari tabel katalog PG\$1TABLES. Kemudian T1 menjatuhkan tabel A dan komit, lalu T2 mencantumkan tabel lagi. Tabel A sekarang tidak lagi terdaftar. Jika T2 mencoba menanyakan tabel yang dijatuhkan, Amazon Redshift mengembalikan kesalahan “relasi tidak ada”. Kueri katalog yang mengembalikan daftar tabel ke T2 atau memeriksa bahwa tabel A ada tidak tunduk pada aturan isolasi yang sama seperti operasi yang dilakukan pada tabel pengguna. Transaksi untuk pembaruan tabel ini berjalan dalam mode isolasi komited baca. + Tabel katalog awalan PG tidak mendukung isolasi SNAPSHOT. # Menulis dan read/write operasi Anda dapat mengelola perilaku spesifik operasi penulisan bersamaan dengan memutuskan kapan dan bagaimana menjalankan berbagai jenis perintah. Perintah berikut relevan dengan diskusi ini: + perintah COPY, yang melakukan beban (awal atau inkremental) + INSERT perintah yang menambahkan satu atau beberapa baris pada satu waktu + Perintah UPDATE, yang memodifikasi baris yang ada + DELETE perintah, yang menghapus baris Operasi COPY dan INSERT adalah operasi penulisan murni. Operasi DELETE dan UPDATE adalah read/write operasi (untuk baris yang akan dihapus atau diperbarui, mereka harus dibaca terlebih dahulu). Hasil operasi penulisan bersamaan bergantung pada perintah spesifik yang sedang dijalankan secara bersamaan. Operasi UPDATE dan DELETE berperilaku berbeda karena mereka mengandalkan pembacaan tabel awal sebelum mereka melakukan penulisan apa pun. Mengingat bahwa transaksi bersamaan tidak terlihat satu sama lain, keduanya UPDATEs dan DELETEs harus membaca snapshot data dari komit terakhir. Ketika UPDATE atau DELETE pertama melepaskan kuncinya, UPDATE atau DELETE kedua perlu menentukan apakah data yang akan digunakan berpotensi basi. Itu tidak akan basi, karena transaksi kedua tidak mendapatkan snapshot datanya sampai setelah transaksi pertama merilis kuncinya. ## Potensi situasi kebuntuan untuk transaksi tulis bersamaan yang melibatkan beberapa tabel Ketika transaksi melibatkan pembaruan lebih dari satu tabel, selalu ada kemungkinan transaksi yang berjalan secara bersamaan menjadi menemui jalan buntu ketika keduanya mencoba menulis ke set tabel yang sama. Sebuah transaksi melepaskan semua kunci tabelnya sekaligus ketika melakukan atau memutar kembali; itu tidak melepaskan kunci satu per satu. Misalnya, transaksi T1 dan T2 dimulai pada waktu yang hampir bersamaan. Jika T1 mulai menulis ke tabel A dan T2 mulai menulis ke tabel B, kedua transaksi dapat dilanjutkan tanpa konflik. Namun, jika T1 selesai menulis ke tabel A dan perlu mulai menulis ke tabel B, itu tidak akan dapat melanjutkan karena T2 masih memegang kunci pada B. Demikian pula, jika T2 selesai menulis ke tabel B dan perlu mulai menulis ke tabel A, itu tidak akan dapat melanjutkan baik karena T1 masih memegang kunci pada A. Karena tidak ada transaksi yang dapat melepaskan kunci sampai semua operasi penulisannya dilakukan, tidak ada transaksi yang dapat dilanjutkan. Untuk menghindari kebuntuan semacam ini, Anda perlu menjadwalkan operasi penulisan bersamaan dengan hati-hati. Misalnya, Anda harus selalu memperbarui tabel dalam urutan yang sama dalam transaksi dan, jika menentukan kunci, mengunci tabel dalam urutan yang sama sebelum Anda melakukan operasi DML apa pun. ## Potensi situasi kebuntuan untuk transaksi tulis bersamaan yang melibatkan satu tabel Dalam lingkungan isolasi snapshot, kebuntuan dapat terjadi saat menjalankan transaksi tulis bersamaan pada tabel yang sama. Kebuntuan isolasi snapshot terjadi ketika pernyataan INSERT atau COPY bersamaan berbagi kunci dan membuat kemajuan, dan pernyataan lain perlu melakukan operasi (UPDATE, DELETE, MERGE, atau operasi DDL) yang memerlukan kunci eksklusif pada tabel yang sama. Pertimbangkan skenario berikut: Transaksi 1 (T1): ``` INSERT/COPY INTO table_A; ``` Transaksi 2 (T2): ``` INSERT/COPY INTO table_A; table_A ``` Kebuntuan dapat terjadi ketika beberapa transaksi dengan operasi INSERT atau COPY berjalan bersamaan pada tabel yang sama dengan kunci bersama, dan salah satu transaksi tersebut mengikuti operasi tulis murni dengan operasi yang memerlukan kunci eksklusif, seperti pernyataan UPDATE, MERGE, DELETE, atau DDL. Untuk menghindari kebuntuan dalam situasi ini, Anda dapat memisahkan pernyataan yang membutuhkan kunci eksklusif (UPDATE/MERGE/DELETE/DDL statements) to a different transaction so that any INSERT/COPY statements can progress simultaneously, and the statements requiring exclusive locks can execute after them. Alternatively, for transactions with INSERT/COPY statements and MERGE/UPDATE/MERGEpernyataan pada tabel yang sama, Anda dapat menyertakan logika coba lagi dalam aplikasi Anda untuk mengatasi potensi kebuntuan. # Contoh tulis bersamaan Contoh pseudo-code berikut menunjukkan bagaimana transaksi berjalan atau menunggu saat dijalankan secara bersamaan. ## Contoh tulis bersamaan dengan isolasi serial ### Operasi COPY bersamaan ke dalam tabel yang sama dengan isolasi serial Transaksi 1 salinan baris ke dalam tabel LISTING: ``` begin; copy listing from ...; end; ``` Transaksi 2 dimulai secara bersamaan dalam sesi terpisah dan mencoba menyalin lebih banyak baris ke dalam tabel LISTING. Transaksi 2 harus menunggu hingga transaksi 1 melepaskan kunci tulis pada tabel LISTING, kemudian dapat dilanjutkan. ``` begin; [waits] copy listing from ; end; ``` Perilaku yang sama akan terjadi jika salah satu atau kedua transaksi berisi perintah INSERT alih-alih perintah COPY. ### Operasi DELETE bersamaan dari tabel yang sama dengan isolasi serial Transaksi 1 menghapus baris dari tabel: ``` begin; delete from listing where ...; end; ``` Transaksi 2 dimulai secara bersamaan dan mencoba menghapus baris dari tabel yang sama. Ini akan berhasil karena menunggu transaksi 1 selesai sebelum mencoba menghapus baris. ``` begin [waits] delete from listing where ; end; ``` Perilaku yang sama akan terjadi jika salah satu atau kedua transaksi berisi perintah UPDATE ke tabel yang sama, bukan perintah DELETE. ### Transaksi bersamaan dengan campuran operasi baca dan tulis dengan isolasi serial Dalam contoh ini, transaksi 1 menghapus baris dari tabel USERS, memuat ulang tabel, menjalankan kueri COUNT (\$1), dan kemudian ANALISIS, sebelum melakukan: ``` begin; delete one row from USERS table; copy ; select count(*) from users; analyze ; end; ``` Sementara itu, transaksi 2 dimulai. Transaksi ini mencoba menyalin baris tambahan ke dalam tabel USERS, menganalisis tabel, dan kemudian menjalankan kueri COUNT (\$1) yang sama dengan transaksi pertama: ``` begin; [waits] copy users from ...; select count(*) from users; analyze; end; ``` Transaksi kedua akan berhasil karena harus menunggu yang pertama selesai. Kueri COUNT-nya akan mengembalikan hitungan berdasarkan beban yang telah diselesaikan. ## Contoh tulis bersamaan dengan isolasi snapshot ### Operasi COPY bersamaan ke dalam tabel yang sama dengan isolasi snapshot Transaksi 1 salinan baris ke dalam tabel LISTING: ``` begin; copy listing from ...; end; ``` Transaksi 2 dimulai secara bersamaan dalam sesi terpisah dan mencoba menyalin lebih banyak baris ke dalam tabel LISTING. Transaksi 2 dapat berkembang secara bersamaan hingga salah satu transaksi perlu menulis data ke tabel target`listing`, di mana mereka akan berjalan secara berurutan. ``` begin; //When the COPY statement from T1 needs to write data to the table, the COPY statement from T2 waits. copy listing from ...; end; ``` Perilaku yang sama akan terjadi jika salah satu atau kedua transaksi berisi perintah INSERT alih-alih perintah COPY. ### Operasi DELETE bersamaan dari tabel yang sama dengan isolasi snapshot Operasi DELETE atau UPDATE bersamaan dari tabel yang sama dengan isolasi snapshot berjalan sama seperti operasi yang dijalankan dengan isolasi serializable. ### Transaksi bersamaan dengan campuran operasi baca dan tulis dengan isolasi snapshot Transaksi bersamaan yang dijalankan dengan campuran operasi dengan isolasi snapshot berjalan sama seperti transaksi dengan campuran operasi yang dijalankan dengan isolasi serializable. # Memecahkan masalah kesalahan isolasi serial ## ERROR:1023 DETAIL: Pelanggaran isolasi serial di atas meja 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 serializable, Anda dapat mencoba metode berikut: + Coba lagi transaksi yang dibatalkan. Amazon Redshift mendeteksi bahwa beban kerja bersamaan tidak dapat diserialkan. Ini menunjukkan celah dalam logika aplikasi, yang biasanya dapat diatasi dengan mencoba kembali transaksi yang mengalami kesalahan. Jika masalah berlanjut, coba salah satu metode lain. + Pindahkan operasi apa pun yang tidak harus berada dalam transaksi atom yang sama di luar transaksi. Metode ini berlaku ketika operasi individu dalam dua transaksi saling merujuk 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 dalam setiap transaksi mungkin dipengaruhi oleh pernyataan INSERT di yang lain. Dengan kata lain, anggaplah Anda menjalankan pernyataan berikut secara serial, dalam urutan apa pun. Dalam setiap kasus, hasilnya adalah salah satu pernyataan SELECT 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 serial. ``` 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 dari 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 pada 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 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 diserialkan. + Paksa serialisasi dengan mengunci semua tabel di setiap sesi. [GEMBOK](r_LOCK.md)Perintah memblokir operasi yang dapat mengakibatkan kesalahan isolasi serializable. Saat Anda menggunakan perintah LOCK, pastikan untuk melakukan hal berikut: + Kunci semua tabel yang terpengaruh oleh transaksi, termasuk yang terpengaruh oleh pernyataan SELECT hanya-baca 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, lihat. [Parameter](r_ALTER_DATABASE.md#r_ALTER_DATABASE-parameters) ## ERROR:1018 DETAIL: Relasi 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 sebagaimana tercermin dalam snapshot. Jika transaksi membaca dari tabel yang tidak ada dalam snapshot, itu akan menampilkan pesan kesalahan 1018 yang ditunjukkan 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 itu ada. Jika tabel dibuat oleh transaksi lain, poin ini setidaknya setelah transaksi 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 serial. Kesalahan ini terjadi ketika session2 mengambil snapshot dan tabel telah dijatuhkan oleh sesi komitmen1. Dengan kata lain, meskipun session3 bersamaan telah membuat tabel, session2 tidak melihat tabel karena tidak ada dalam 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-nya, session3 telah dilakukan, dan tabelnya ada di database. Session2 dapat membaca dari tabel tanpa kesalahan.