Pertimbangan dan batasan tabel temporal

Berlaku untuk: SQL Server 2016 (13.x) dan Azure SQL DatabaseAzure SQL Managed Instance yang lebih baru

Ada beberapa pertimbangan dan batasan yang perlu diperhatikan saat bekerja dengan tabel temporal, karena sifat penerapan versi sistem:

  • Tabel temporal harus memiliki kunci utama yang ditentukan, untuk menghubungkan rekaman antara tabel saat ini dan tabel riwayat, dan tabel riwayat tidak dapat memiliki kunci utama yang ditentukan.

  • Kolom SYSTEM_TIME periode yang digunakan untuk merekam ValidFrom nilai dan ValidTo harus ditentukan dengan jenis data datetime2.

  • Sintaksis temporal berfungsi pada tabel atau tampilan yang disimpan secara lokal dalam database. Dengan objek jarak jauh seperti tabel di server tertaut, atau tabel eksternal, Anda tidak dapat menggunakan FOR klausa atau predikat periode secara langsung dalam kueri.

  • Jika nama tabel riwayat ditentukan selama pembuatan tabel riwayat, Anda harus menentukan skema dan nama tabel.

  • Secara default, tabel riwayat dikompresi PAGE .

  • Jika tabel saat ini dipartisi, tabel riwayat dibuat pada grup file default karena konfigurasi partisi tidak direplikasi secara otomatis dari tabel saat ini ke tabel riwayat.

  • Tabel temporal dan riwayat tidak dapat menggunakan FileTable atau FILESTREAM, karena FileTable dan FILESTREAM memungkinkan manipulasi data di luar SQL Server dan dengan demikian penerapan versi sistem tidak dapat dijamin.

  • Simpul atau tabel tepi tidak dapat dibuat sebagai atau diubah ke tabel temporal.

  • Sementara tabel temporal mendukung jenis data blob, seperti (n)varchar(max), varbinary(max), (n)teks, dan gambar, mereka dikenakan biaya penyimpanan yang signifikan dan memiliki implikasi performa karena ukurannya. Dengan demikian, saat merancang sistem Anda, perawatan harus dilakukan saat menggunakan jenis data ini.

  • Tabel riwayat harus dibuat dalam database yang sama dengan tabel saat ini. Kueri temporal melalui server tertaut tidak didukung.

  • Tabel riwayat tidak boleh memiliki batasan (kunci primer, kunci asing, batasan tabel atau kolom).

  • Tampilan terindeks tidak didukung di atas kueri temporal (kueri yang menggunakan FOR SYSTEM_TIME klausa).

  • Opsi online (WITH (ONLINE = ON) tidak berpengaruh dalam ALTER TABLE ALTER COLUMN tabel temporal versi sistem. ALTER kolom tidak dilakukan sebagai operasi online, terlepas dari nilai mana yang ditentukan untuk opsi ONLINE.

  • INSERT pernyataan dan UPDATE tidak dapat mereferensikan SYSTEM_TIME kolom periode. Upaya untuk menyisipkan nilai langsung ke dalam kolom ini diblokir.

  • TRUNCATE TABLE tidak didukung saat SYSTEM_VERSIONING adalah ON.

  • Modifikasi langsung data dalam tabel riwayat tidak diizinkan.

  • ON DELETE CASCADE dan ON UPDATE CASCADE tidak diizinkan pada tabel saat ini. Dengan kata lain, ketika tabel temporal mereferensikan tabel dalam hubungan kunci asing parent_object_id (sesuai dengan di sys.foreign_key) CASCADE opsi tidak diizinkan. Untuk mengatasi batasan ini, gunakan logika aplikasi atau setelah pemicu untuk mempertahankan konsistensi pada penghapusan dalam tabel kunci primer (sesuai dengan referenced_object_id di sys.foreign_key). Jika tabel kunci utama bersifat temporal dan tabel referensi non-temporal, tidak ada batasan seperti itu.
  • INSTEAD OF pemicu tidak diizinkan pada tabel saat ini atau riwayat untuk menghindari pembatalan logika DML. AFTER pemicu hanya diizinkan pada tabel saat ini. Mereka diblokir pada tabel riwayat untuk menghindari pembatalan logika DML.

  • Penggunaan teknologi replikasi terbatas:

    • Grup ketersediaan: Didukung penuh

    • Mengubah penangkapan data dan pelacakan perubahan: Hanya didukung pada tabel saat ini

    • Rekam jepret dan replikasi transaksional: Hanya didukung untuk satu penerbit tanpa temporal diaktifkan, dan satu pelanggan dengan temporal diaktifkan. Penggunaan beberapa pelanggan tidak didukung karena ini dapat menyebabkan data temporal yang tidak konsisten karena dependensi pada jam sistem lokal. Dalam hal ini, penerbit digunakan untuk beban kerja OLTP sementara pelanggan berfungsi untuk pelaporan offloading (termasuk AS OF kueri). Ketika agen distribusi dimulai, agen distribusi membuka transaksi yang ditahan terbuka sampai agen distribusi berhenti. ValidFrom dan ValidTo diisi ke waktu mulai transaksi pertama yang dimulai oleh agen distribusi. Mungkin lebih baik menjalankan agen distribusi pada jadwal daripada perilaku default menjalankannya terus menerus, jika memiliki ValidFrom dan ValidTo diisi dengan waktu yang dekat dengan waktu sistem saat ini penting untuk aplikasi atau organisasi Anda. Untuk informasi selengkapnya, lihat Skenario penggunaan tabel Temporal.

    • Gabungkan replikasi: Tidak didukung untuk tabel temporal

  • Kueri reguler hanya memengaruhi data dalam tabel saat ini. Untuk mengkueri data dalam tabel riwayat, Anda harus menggunakan kueri temporal. Untuk informasi selengkapnya, lihat Mengkueri data dalam tabel temporal versi sistem.

  • Strategi pengindeksan optimal mencakup indeks penyimpanan kolom berkluster dan/atau indeks rowstore pohon B pada tabel saat ini dan indeks penyimpan kolom berkluster pada tabel riwayat untuk ukuran dan performa penyimpanan yang optimal. Jika Anda membuat/menggunakan tabel riwayat Anda sendiri, kami sangat menyarankan Anda membuat jenis indeks ini yang terdiri dari kolom periode yang dimulai dengan akhir kolom periode, untuk mempercepat kueri temporal dan mempercepat kueri yang merupakan bagian dari pemeriksaan konsistensi data. Tabel riwayat default memiliki indeks rowstore berkluster yang dibuat untuk Anda berdasarkan kolom titik (akhir, mulai). Minimal, indeks rowstore non-kluster direkomendasikan.

  • Objek/properti berikut ini tidak direplikasi dari tabel saat ini ke riwayat saat tabel riwayat dibuat:

    • Definisi periode
    • Definisi identitas
    • Indeks
    • Statistik
    • Periksa batasan
    • Pemicu
    • Konfigurasi partisi
    • Izin
    • Predikat keamanan tingkat baris
  • Tabel riwayat tidak dapat dikonfigurasi sebagai tabel saat ini dalam rantai tabel riwayat.

Catatan

Dokumentasi SQL Server menggunakan istilah pohon B umumnya dalam referensi ke indeks. Dalam indeks rowstore, SQL Server mengimplementasikan pohon B+. Ini tidak berlaku untuk indeks penyimpan kolom atau penyimpanan data dalam memori. Untuk informasi selengkapnya, lihat panduan arsitektur dan desain indeks SQL Server dan Azure SQL.

Langkah berikutnya