Durabilitas untuk Tabel yang Dioptimalkan Memori

Berlaku untuk:SQL Server

OLTP Dalam Memori memberikan durabilitas penuh untuk tabel yang dioptimalkan memori. Ketika transaksi yang mengubah penerapan tabel yang dioptimalkan memori, SQL Server (seperti halnya untuk tabel berbasis disk), menjamin bahwa perubahan bersifat permanen (akan bertahan dari hidupkan ulang database), asalkan penyimpanan yang mendasar tersedia. Ada dua komponen utama durabilitas: pengelogan transaksi dan perubahan data yang bertahan pada penyimpanan di disk.

Untuk detail tentang batasan ukuran apa pun untuk tabel tahan lama, lihat Memperkirakan Persyaratan Memori untuk Tabel yang Dioptimalkan Memori.

Log Transaksi

Semua perubahan yang dilakukan pada tabel berbasis disk atau tabel yang dioptimalkan memori tahan lama diambil dalam satu atau beberapa rekaman log transaksi. Ketika transaksi dilakukan, SQL Server menulis catatan log yang terkait dengan transaksi ke disk sebelum berkomunikasi ke aplikasi atau sesi pengguna yang telah dilakukan transaksi. Ini menjamin bahwa perubahan yang dilakukan oleh transaksi tahan lama. Log transaksi untuk tabel yang dioptimalkan memori sepenuhnya terintegrasi dengan aliran log yang sama yang digunakan oleh tabel berbasis disk. Integrasi ini memungkinkan operasi pencadangan, pemulihan, dan pemulihan log transaksi yang ada untuk terus berfungsi tanpa memerlukan langkah tambahan. Namun, karena OLTP Dalam Memori dapat meningkatkan throughput transaksi beban kerja Anda secara signifikan, IO log mungkin menjadi hambatan performa. Untuk mempertahankan peningkatan throughput ini, pastikan subsistem IO log dapat menangani peningkatan beban.

File Data dan Delta

Data dalam tabel yang dioptimalkan memori disimpan sebagai baris data bentuk bebas dalam struktur data tumpukan dalam memori, dan ditautkan melalui satu atau beberapa indeks dalam memori. Tidak ada struktur halaman untuk baris data, seperti yang digunakan untuk tabel berbasis disk. Untuk persistensi jangka panjang dan untuk memungkinkan pemotongan log transaksi, operasi pada tabel yang dioptimalkan memori dipertahankan dalam sekumpulan data dan file delta. File-file ini dihasilkan berdasarkan log transaksi, menggunakan proses latar belakang asinkron. Data dan file delta terletak di satu atau beberapa kontainer (menggunakan mekanisme yang sama yang digunakan untuk data FILESTREAM). Kontainer ini adalah bagian dari grup file yang dioptimalkan memori.

Data ditulis ke file-file ini dengan cara yang sangat berurutan, yang meminimalkan latensi disk untuk memutar media. Anda dapat menggunakan beberapa kontainer pada disk yang berbeda untuk mendistribusikan aktivitas I/O. File data dan delta dalam beberapa kontainer pada disk yang berbeda akan meningkatkan performa pemulihan/pemulihan database saat data dibaca dari data dan file delta pada disk, ke dalam memori.

Transaksi pengguna tidak langsung mengakses data dan file delta. Semua baca dan tulisan data menggunakan struktur data dalam memori.

The Data File

File data berisi baris dari satu atau beberapa tabel yang dioptimalkan memori yang dimasukkan oleh beberapa transaksi sebagai bagian dari operasi INSERT atau UPDATE. Misalnya, satu baris dapat berasal dari tabel T1 yang dioptimalkan memori dan baris berikutnya dapat berasal dari tabel yang dioptimalkan memori T2. Baris ditambahkan ke file data dalam urutan transaksi dalam log transaksi, membuat akses data berurutan. Ini memungkinkan urutan throughput I/O yang lebih baik dibandingkan dengan I/O acak.

Setelah file data penuh, baris yang disisipkan oleh transaksi baru disimpan dalam file data lain. Seiring waktu, baris dari tabel yang dioptimalkan memori tahan lama disimpan dalam salah satu file data lainnya dan setiap file data yang berisi baris membentuk rentang transaksi yang berbeda tetapi berdampingan. Misalnya file data dengan tanda waktu penerapan transaksi dalam rentang (100, 200) memiliki semua baris yang disisipkan oleh transaksi yang memiliki tanda waktu penerapan lebih besar dari 100 dan kurang dari atau sama dengan 200. Tanda waktu penerapan adalah angka yang meningkat secara monoton yang ditetapkan ke transaksi ketika siap untuk berkomitmen. Setiap transaksi memiliki tanda waktu penerapan yang unik.

Saat baris dihapus atau diperbarui, baris tidak dihapus atau diubah di tempat dalam file data tetapi baris yang dihapus dilacak dalam jenis file lain: file delta. Operasi pembaruan diproses sebagai tuple operasi hapus dan sisipkan untuk setiap baris. Ini menghilangkan IO acak pada file data.

Ukuran: Setiap file data berukuran sekitar 128MB untuk komputer dengan memori lebih besar dari 16GB, dan 16MB untuk komputer dengan kurang dari atau sama dengan 16GB. Di SQL Server 2016 (13.x) SQL Server dapat menggunakan mode titik pemeriksaan besar jika dianggap subsistem penyimpanan cukup cepat. Dalam mode titik pemeriksaan besar, file data berukuran 1GB. Hal ini memungkinkan efisiensi yang lebih besar dalam subsistem penyimpanan untuk beban kerja throughput tinggi.

The Delta File

Setiap file data dipasangkan dengan file delta yang memiliki rentang transaksi yang sama dan melacak baris yang dihapus yang dimasukkan oleh transaksi dalam rentang transaksi. File data dan delta ini disebut sebagai Checkpoint File Pair (CFP) dan merupakan unit alokasi dan dealokasi serta unit untuk operasi Penggabungan. Misalnya, file delta yang sesuai dengan rentang transaksi (100, 200) akan menyimpan baris yang dihapus yang dimasukkan oleh transaksi dalam rentang (100, 200). Seperti file data, file delta diakses secara berurutan.

Saat baris dihapus, baris tidak dihapus dari file data tetapi referensi ke baris ditambahkan ke file delta yang terkait dengan rentang transaksi tempat baris data ini dimasukkan. Karena baris yang akan dihapus sudah ada dalam file data, file delta hanya menyimpan informasi {inserting_tx_id, row_id, deleting_tx_id } referensi dan mengikuti urutan log transaksional dari operasi penghapusan atau pembaruan asal.

Ukuran: Setiap file delta berukuran sekitar 16MB untuk komputer dengan memori lebih besar dari 16GB, dan 1MB untuk komputer dengan kurang dari atau sama dengan 16GB. Memulai SQL Server 2016 (13.x) SQL Server dapat menggunakan mode titik pemeriksaan besar jika dianggap subsistem penyimpanan cukup cepat. Dalam mode titik pemeriksaan besar, file delta berukuran 128MB.

Mengisi Data dan File Delta

Data dan file delta diisi berdasarkan catatan log transaksi yang dihasilkan oleh transaksi yang diterapkan pada tabel yang dioptimalkan memori dan menambahkan informasi tentang baris yang disisipkan dan dihapus ke dalam file data dan delta yang sesuai. Tidak seperti tabel berbasis disk di mana halaman data/indeks dibersihkan dengan I/O acak ketika titik pemeriksaan selesai, persistensi tabel yang dioptimalkan memori adalah operasi latar belakang berkelanjutan. Beberapa file delta diakses karena transaksi dapat menghapus atau memperbarui baris apa pun yang disisipkan oleh transaksi sebelumnya. Informasi penghapusan selalu ditambahkan di akhir file delta. Misalnya, transaksi dengan tanda waktu penerapan 600 menyisipkan satu baris baru dan menghapus baris yang disisipkan oleh transaksi dengan tanda waktu penerapan 150, 250, dan 450 seperti yang ditunjukkan pada gambar di bawah ini. Semua 4 operasi I/O file (tiga untuk baris yang dihapus dan 1 untuk baris yang baru disisipkan), adalah operasi khusus tambahan ke delta dan file data yang sesuai.

Mengakses Data dan File Delta

Pasangan file data dan delta diakses saat berikut ini terjadi.

Pekerja titik pemeriksaan offline
Utas ini menambahkan penyisipan dan penghapusan ke baris data yang dioptimalkan memori, ke pasangan data dan file delta yang sesuai. Di SQL Server 2014 (12.x) ada satu pekerja titik pemeriksaan offline; mulai SQL Server 2016 (13.x) ada beberapa pekerja titik pemeriksaan.

Operasi penggabungan
Operasi ini menggabungkan satu atau beberapa pasangan data dan file delta dan membuat pasangan file data dan delta baru.

Selama pemulihan crash
Ketika SQL Server dimulai ulang atau database kembali online, data yang dioptimalkan memori diisi menggunakan pasangan file data dan delta. File delta bertindak sebagai filter untuk baris yang dihapus saat membaca baris dari file data yang sesuai. Karena setiap data dan pasangan file delta independen, file-file ini dimuat secara paralel untuk mengurangi waktu yang diperlukan untuk mengisi data ke dalam memori. Setelah data dimuat ke dalam memori, mesin OLTP Dalam Memori menerapkan catatan log transaksi aktif yang belum dicakup oleh file titik pemeriksaan sehingga data yang dioptimalkan memori selesai.

Selama operasi pemulihan
File titik pemeriksaan OLTP Dalam Memori dibuat dari cadangan database, lalu satu atau beberapa cadangan log transaksi diterapkan. Seperti halnya pemulihan crash, mesin OLTP Dalam Memori memuat data ke dalam memori secara paralel, untuk meminimalkan dampak pada waktu pemulihan.

Menggabungkan Data dan File Delta

Data untuk tabel memori yang dioptimalkan disimpan dalam satu atau beberapa pasangan file data dan delta (juga disebut pasangan file titik pemeriksaan, atau CFP). File data menyimpan baris yang disisipkan dan file delta mereferensikan baris yang dihapus. Selama eksekusi beban kerja OLTP, karena operasi DML memperbarui, menyisipkan, dan menghapus baris, CFP baru dibuat untuk mempertahankan baris baru, dan referensi ke baris yang dihapus ditambahkan ke file delta.

Seiring waktu, dengan operasi DML, jumlah data dan file delta bertambah menyebabkan, menyebabkan peningkatan penggunaan ruang disk dan peningkatan waktu pemulihan..

Untuk membantu mencegah inefisiensi ini, data tertutup dan file delta yang lebih lama digabungkan, berdasarkan kebijakan penggabungan yang dijelaskan di bawah ini, sehingga array penyimpanan dikompresi untuk mewakili kumpulan data yang sama, dengan jumlah file yang dikurangi.

Operasi penggabungan mengambil sebagai input satu atau beberapa pasangan file titik pemeriksaan tertutup (CFP) yang berdekatan, yang merupakan pasangan file data dan delta, (disebut sumber penggabungan) berdasarkan kebijakan penggabungan yang ditentukan secara internal, dan menghasilkan satu CFP yang dihasilkan, yang disebut target penggabungan. Entri dalam setiap file delta CFP sumber digunakan untuk memfilter baris dari file data terkait untuk menghapus baris data yang tidak diperlukan. Baris yang tersisa dalam CFP sumber dikonsolidasikan ke dalam satu CFP target. Setelah penggabungan selesai, CFP target penggabungan yang dihasilkan menggantikan CFP sumber (sumber penggabungan). CFP sumber penggabungan melalui fase transisi sebelum dihapus dari penyimpanan.

Dalam contoh di bawah ini, grup file tabel yang dioptimalkan memori memiliki empat pasangan file data dan delta pada tanda waktu 500 yang berisi data dari transaksi sebelumnya. Misalnya, baris dalam file data pertama sesuai dengan transaksi dengan tanda waktu lebih besar dari 100 dan kurang dari atau sama dengan 200; atau dinyatakan sebagai (100, 200]. File data kedua dan ketiga ditampilkan kurang dari 50 persen penuh setelah memperhitungkan baris yang ditandai sebagai dihapus. Operasi penggabungan menggabungkan kedua CFP ini dan membuat CFP baru yang berisi transaksi dengan tanda waktu lebih besar dari 200 dan kurang dari atau sama dengan 400, yang merupakan rentang gabungan dari kedua CFP ini. Anda melihat CFP lain dengan rentang (500, 600] dan file delta tidak kosong untuk rentang transaksi (200, 400] menunjukkan bahwa operasi penggabungan dapat dilakukan bersamaan dengan aktivitas transaksional termasuk menghapus lebih banyak baris dari CFP sumber.

Utas latar belakang mengevaluasi semua CFP tertutup menggunakan kebijakan penggabungan lalu memulai satu atau beberapa permintaan penggabungan untuk CFP yang memenuhi syarat. Permintaan penggabungan ini diproses oleh utas titik pemeriksaan offline. Evaluasi kebijakan penggabungan dilakukan secara berkala dan juga ketika titik pemeriksaan ditutup.

Kebijakan Penggabungan SQL Server

SQL Server menerapkan kebijakan penggabungan berikut:

• Penggabungan dijadwalkan jika 2 CFP atau lebih berturut-turut dapat dikonsolidasikan, setelah memperhitungkan baris yang dihapus, sehingga baris yang dihasilkan dapat masuk ke dalam 1 CFP ukuran target. Ukuran target data dan file delta sesuai dengan ukuran asli, seperti yang dijelaskan di atas.

• Satu CFP dapat digabungkan sendiri jika file data melebihi ukuran target ganda dan lebih dari setengah baris dihapus. File data dapat tumbuh lebih besar dari ukuran target jika, misalnya, satu transaksi atau beberapa transaksi bersamaan menyisipkan atau memperbarui sejumlah besar data, memaksa file data tumbuh melebihi ukuran targetnya, karena transaksi tidak dapat mencakup beberapa CFP.

Berikut adalah beberapa contoh yang menunjukkan CFP yang akan digabungkan di bawah kebijakan penggabungan:

File Sumber CFPs yang Berdekatan (% penuh)	Gabungkan Pilihan
CFP0 (30%), CFP1 (50%), CFP2 (50%), CFP3 (90%)	(CFP0, CFP1) CFP2 tidak dipilih karena akan membuat file data yang dihasilkan lebih besar dari 100% dari ukuran ideal.
CFP0 (30%), CFP1 (20%), CFP2 (50%), CFP3 (10%)	(CFP0, CFP1, CFP2). File dipilih mulai dari kiri. CTP3 tidak dipilih karena akan membuat file data yang dihasilkan lebih besar dari 100% dari ukuran ideal.
CFP0 (80%), CFP1 (30%), CFP2 (10%), CFP3 (40%)	(CFP1, CFP2, CFP3). File dipilih mulai dari kiri. CFP0 dilewati karena jika dikombinasikan dengan CFP1, file data yang dihasilkan akan lebih besar dari 100% dari ukuran ideal.

Tidak semua CFP dengan ruang yang tersedia memenuhi syarat untuk digabungkan. Misalnya, jika dua CFP yang berdekatan 60% penuh, mereka tidak akan memenuhi syarat untuk penggabungan dan masing-masing CFP ini akan memiliki penyimpanan 40% yang tidak digunakan. Dalam kasus terburuk, semua CFP akan menjadi 50% penuh, pemanfaatan penyimpanan hanya 50%. Meskipun baris yang dihapus mungkin ada di penyimpanan karena CFP tidak memenuhi syarat untuk digabungkan, baris yang dihapus mungkin telah dihapus dari memori oleh pengumpulan sampah dalam memori. Manajemen penyimpanan dan memori independen dari pengumpulan sampah. Penyimpanan yang diambil oleh CFP aktif (tidak semua CFP sedang diperbarui) bisa hingga 2 kali lebih besar dari ukuran tabel tahan lama dalam memori.

Siklus Hidup CFP

Transisi CFP melalui beberapa status sebelum dapat dibatalkan alokasinya. Titik pemeriksaan database dan cadangan log perlu terjadi untuk mentransisikan file melalui fase, dan pada akhirnya membersihkan file yang tidak lagi diperlukan. Untuk deskripsi fase ini, lihat sys.dm_db_xtp_checkpoint_files (Transact-SQL).

Anda dapat memaksa titik pemeriksaan secara manual diikuti dengan pencadangan log untuk mempercepat pengumpulan sampah. Dalam skenario produksi, titik pemeriksaan otomatis dan cadangan log yang diambil sebagai bagian dari strategi pencadangan akan dengan mulus melakukan transisi CFP melalui fase ini tanpa memerlukan intervensi manual. Dampak dari proses pengumpulan sampah adalah bahwa database dengan tabel yang dioptimalkan memori mungkin memiliki ukuran penyimpanan yang lebih besar dibandingkan dengan ukurannya dalam memori. Jika titik pemeriksaan dan pencadangan log tidak terjadi, jejak file titik pemeriksaan pada disk terus bertambah.

Lihat Juga

Membuat dan Mengelola Penyimpanan untuk Objek yang Dioptimalkan Memori