Pengantar Tabel yang Dioptimalkan Memori

2025-04-30

Berlaku untuk:SQL Server Azure SQL Database Azure SQL Managed Instance

Tabel yang dioptimalkan memori dibuat menggunakan CREATE TABLE (Transact-SQL).

Tabel yang dioptimalkan memori sepenuhnya tahan lama secara default, dan, seperti transaksi pada tabel berbasis disk (tradisional), transaksi pada tabel yang dioptimalkan memori sepenuhnya atom, konsisten, terisolasi, dan tahan lama (ACID). Tabel yang dioptimalkan memori dan prosedur tersimpan yang dikompilasi secara asli hanya mendukung subset fitur Transact-SQL.

Dimulai dengan SQL Server 2016, dan di Azure SQL Database, tidak ada batasan untuk kolase atau halaman kode yang khusus untuk In-Memory OLTP.

Penyimpanan utama untuk tabel yang dioptimalkan memori adalah memori utama. Baris dalam tabel dibaca dari dan ditulis ke memori. Salinan kedua data tabel dipertahankan pada disk, tetapi hanya untuk tujuan durabilitas. Lihat Membuat dan Mengelola Penyimpanan untuk Objek Memory-Optimized untuk informasi selengkapnya tentang tabel yang tahan lama. Data dalam tabel yang dioptimalkan memori hanya dibaca dari disk selama pemulihan database (misalnya, setelah server dimulai ulang).

Untuk perolehan performa yang lebih besar, OLTP Dalam Memori mendukung tabel tahan lama dengan durabilitas transaksi tertunda. Transaksi tahan lama yang tertunda disimpan ke disk segera setelah transaksi dikomit dan kontrol dikembalikan ke klien. Sebagai imbalan atas peningkatan performa, transaksi yang dicatat tetapi tidak disimpan ke dalam disk akan hilang jika terjadi server crash atau saat pindah alih server.

Selain tabel default yang dioptimalkan memori tahan lama, SQL Server juga mendukung tabel yang dioptimalkan memori yang tidak tahan lama, yang tidak dicatat dan datanya tidak bertahan pada disk. Ini berarti bahwa transaksi pada tabel ini tidak memerlukan IO disk apa pun, tetapi data hilang jika ada crash server atau failover.

OLTP Dalam Memori terintegrasi dengan SQL Server untuk memberikan pengalaman yang mulus di semua bidang seperti pengembangan, penyebaran, pengelolaan, dan dukungan. Database dapat berisi dalam memori serta objek berbasis disk.

Baris dalam tabel yang dioptimalkan memori diberi versi. Ini berarti bahwa setiap baris dalam tabel berpotensi memiliki beberapa versi. Semua versi baris dipertahankan dalam struktur data tabel yang sama. Penerapan versi baris digunakan untuk memungkinkan pembacaan dan penulisan bersamaan pada baris yang sama. Untuk informasi selengkapnya tentang baca dan tulis bersamaan pada baris yang sama, lihat Transaksi dengan tabel Memory-Optimized.

Gambar berikut mengilustrasikan multi-penerapan versi. Gambar memperlihatkan tabel dengan tiga baris dan setiap baris memiliki versi yang berbeda.

Multi-versi.

Tabel memiliki tiga baris: r1, r2, dan r3. r1 memiliki tiga versi, r2 memiliki dua versi, dan r3 memiliki empat versi. Versi yang berbeda dari baris yang sama tidak selalu menempati lokasi memori berturut-turut. Versi baris yang berbeda dapat disebarkan di seluruh struktur data tabel.

Struktur data tabel yang dioptimalkan memori dapat dilihat sebagai kumpulan versi baris. Baris dalam tabel berbasis disk diatur dalam halaman dan jangkauan, dan baris individual yang ditangani menggunakan nomor halaman dan offset halaman, versi baris dalam tabel memori yang dioptimalkan ditangani menggunakan penunjuk memori 8-byte.

Data dalam tabel yang dioptimalkan memori diakses dengan dua cara:

Melalui prosedur tersimpan yang dikompilasi secara asli.
Melalui Transact-SQL yang ditafsirkan, di luar prosedur tersimpan yang dikompilasi secara asli. Pernyataan Transact-SQL ini mungkin berada di dalam prosedur tersimpan yang ditafsirkan atau mungkin pernyataan Transact-SQL ad hoc.

Mengakses Data dalam Tabel yang Dioptimalkan Memori

Tabel yang dioptimalkan memori dapat diakses paling efisien dari prosedur tersimpan yang dikompilasi secara asli (Prosedur Tersimpan yang Dikompilasi Secara Asli). Tabel yang dioptimalkan memori juga dapat diakses dengan Transact-SQL yang ditafsirkan (tradisional). Transact-SQL yang ditafsirkan mengacu pada mengakses tabel yang dioptimalkan memori tanpa prosedur tersimpan yang dikompilasi secara asli. Beberapa contoh akses Transact-SQL yang ditafsirkan termasuk mengakses tabel yang dioptimalkan memori dari pemicu DML, batch Transact-SQL ad hoc, tampilan, dan fungsi bernilai tabel.

Tabel berikut ini meringkas akses Transact-SQL asli dan ditafsirkan untuk berbagai objek.

Fitur	Akses Menggunakan Prosedur Tersimpan yang Dikompilasi Secara Asli	Akses Transact-SQL yang Ditafsirkan	Akses CLR
Tabel yang dioptimalkan memori	Ya	Ya	Nomor¹
Jenis tabel yang dioptimalkan memori	Ya	Ya	Tidak
Prosedur tersimpan yang dikompilasi secara asli	Penumpasan prosedur tersimpan yang dikompilasi secara asli sekarang didukung. Anda dapat menggunakan sintaks EXECUTE di dalam prosedur tersimpan, selama prosedur yang dirujuk juga dikompilasi secara asli.	Ya	Tidak*

¹Anda tidak dapat mengakses tabel yang dioptimalkan memori atau prosedur tersimpan yang dikompilasi secara asli dari koneksi konteks (koneksi dari SQL Server saat menjalankan modul CLR). Namun, Anda dapat membuat dan membuka koneksi lain tempat Anda dapat mengakses tabel yang dioptimalkan memori dan prosedur tersimpan yang dikompilasi secara asli.

Data sensitif dalam tabel yang dioptimalkan memori dapat dilindungi dengan menggunakan Always Encrypted. Batasan berikut berlaku:

Saat menggunakan Always Encrypted dengan enklave aman, penggunaan kunci yang diaktifkan enklave untuk kolom dalam tabel yang dioptimalkan memori tidak didukung. Ini berarti bahwa enkripsi di tempat tidak dapat digunakan, dan enkripsi awal dilakukan pada klien.
Always Encrypted tidak didukung untuk kolom apa pun dalam tabel yang dioptimalkan memori saat tabel direferensikan dalam modul yang dikompilasi secara asli.

Performa dan skalabilitas

Faktor-faktor berikut memengaruhi perolehan performa yang dapat dicapai dengan In-Memory OLTP:

Komunikasi: Aplikasi yang menggunakan banyak panggilan prosedur tersimpan singkat mungkin melihat perolehan performa yang lebih kecil dibandingkan dengan aplikasi dengan lebih sedikit panggilan dan lebih banyak fungsionalitas yang diterapkan di setiap prosedur tersimpan.

Transact-SQL Eksekusi: In-Memory OLTP mencapai performa terbaik saat menggunakan prosedur tersimpan yang dikompilasi secara asli daripada prosedur tersimpan yang ditafsirkan atau eksekusi kueri. Mungkin ada manfaat untuk mengakses tabel yang dioptimalkan memori dari prosedur tersimpan tersebut.

Pemindaian Rentang vs Pencarian Titik: Indeks non-kluster yang dioptimalkan memori mendukung pemindaian rentang dan pemindaian yang diurutkan. Untuk pencarian titik, indeks hash yang dioptimalkan memori memiliki performa yang lebih baik daripada indeks nonclustered yang dioptimalkan memori. Indeks nonkluster yang dioptimalkan memori memiliki performa yang lebih baik daripada indeks berbasis disk.

Mulai SQL Server 2016, rencana kueri untuk tabel yang dioptimalkan memori dapat memindai tabel secara paralel. Ini meningkatkan performa kueri analitik.
- Indeks hash juga menjadi dapat dipindai secara paralel di SQL Server 2016.
- Indeks nonclustered juga menjadi dapat dipindai secara paralel di SQL Server 2016.

Operasi indeks: Operasi indeks tidak dicatat, dan hanya ada dalam memori.

Concurrency: Aplikasi yang performanya dipengaruhi oleh konkurensi tingkat mesin, seperti persaingan atau pemblokiran kait, mengalami peningkatan signifikan ketika aplikasi beralih ke In-Memory OLTP.

Tabel berikut mencantumkan masalah performa dan skalabilitas yang umumnya ditemukan dalam database relasional dan bagaimana OLTP Dalam Memori dapat meningkatkan performa.

Masalah	Dampak OLTP Dalam Memori
Performa Penggunaan sumber daya tinggi (CPU, I/O, jaringan, atau memori).	CPU (unit pemrosesan pusat) Prosedur tersimpan yang dikompilasi secara asli dapat menurunkan penggunaan CPU secara signifikan karena memerlukan lebih sedikit instruksi untuk menjalankan pernyataan Transact-SQL dibandingkan dengan prosedur tersimpan yang ditafsirkan. In-Memory OLTP dapat membantu mengurangi investasi pada perangkat keras dalam beban kerja yang diperluas karena satu server berpotensi memberikan throughput setara dengan beberapa server. Masukan/Keluaran (I/O) Jika Anda mengalami hambatan I/O dari pemrosesan ke halaman data atau indeks, OLTP Dalam Memori dapat mengurangi hambatan. Selain itu, proses checkpointing pada objek OLTP In-Memory berlangsung terus-menerus dan tidak menyebabkan lonjakan tiba-tiba dalam operasi I/O. Namun, jika kumpulan kerja tabel-tabel yang kritis terhadap performa tidak muat di dalam memori, In-Memory OLTP tidak berlaku karena memerlukan data untuk berada di dalam memori. Jika Anda mengalami hambatan I/O dalam pengelogan, OLTP Dalam Memori dapat mengurangi hambatan karena tidak terlalu banyak pengelogan. Jika satu atau beberapa tabel yang dioptimalkan memori dikonfigurasi sebagai tabel yang tidak tahan lama, Anda dapat menghilangkan pengelogan untuk data. Memori In-Memory OLTP tidak menawarkan manfaat performa apa pun. OLTP Dalam Memori dapat memberikan tekanan ekstra pada memori karena objek harus menjadi residen memori. Jaringan In-Memory OLTP tidak menawarkan manfaat performa apa pun. Data perlu dikomunikasikan dari tingkat data ke tingkat aplikasi.
Skalabilitas Sebagian besar masalah penskalaan dalam aplikasi SQL Server disebabkan oleh masalah konkurensi seperti ketidakcocokan pada kunci, kait, dan spinlock.	Pertikaian Kait Skenario umum adalah ketidakcocokan pada halaman terakhir indeks saat menyisipkan baris secara bersamaan dalam urutan kunci. Karena In-Memory OLTP tidak mengambil kait saat mengakses data, masalah skalabilitas yang terkait dengan ketidakcocokan kait akan dihapus sepenuhnya. Pertikaian Spinlock Karena In-Memory OLTP tidak mengambil kait saat mengakses data, masalah skalabilitas yang terkait dengan kontensi spinlock sepenuhnya dihilangkan. Mengunci Ketidakcocokan Terkait Jika aplikasi database Anda mengalami masalah pemblokiran antara operasi baca dan tulis, OLTP Dalam Memori menghapus masalah pemblokiran karena menggunakan bentuk baru kontrol konkurensi optimis untuk mengimplementasikan semua tingkat isolasi transaksi. In-Memory OLTP tidak menggunakan TempDB untuk menyimpan versi baris. Jika masalah penskalaan disebabkan oleh konflik antara dua operasi tulis, seperti dua transaksi bersamaan yang mencoba memperbarui baris yang sama, OLTP Dalam Memori memungkinkan satu transaksi berhasil dan gagal pada transaksi lainnya. Transaksi yang gagal harus dikirim ulang baik secara eksplisit atau implisit, mencoba kembali transaksi. Dalam kedua kasus, Anda perlu membuat perubahan pada aplikasi. Jika aplikasi Anda sering mengalami konflik antara dua operasi tulis, nilai penguncian optimis berkurang. Aplikasi ini tidak cocok untuk In-Memory OLTP. Sebagian besar aplikasi OLTP tidak memiliki konflik tulis kecuali konflik tersebut merupakan hasil dari eskalasi kunci.

Masalah

Dampak OLTP Dalam Memori

Performa

Penggunaan sumber daya tinggi (CPU, I/O, jaringan, atau memori).

CPU (unit pemrosesan pusat)
Prosedur tersimpan yang dikompilasi secara asli dapat menurunkan penggunaan CPU secara signifikan karena memerlukan lebih sedikit instruksi untuk menjalankan pernyataan Transact-SQL dibandingkan dengan prosedur tersimpan yang ditafsirkan.

In-Memory OLTP dapat membantu mengurangi investasi pada perangkat keras dalam beban kerja yang diperluas karena satu server berpotensi memberikan throughput setara dengan beberapa server.

Masukan/Keluaran (I/O)
Jika Anda mengalami hambatan I/O dari pemrosesan ke halaman data atau indeks, OLTP Dalam Memori dapat mengurangi hambatan. Selain itu, proses checkpointing pada objek OLTP In-Memory berlangsung terus-menerus dan tidak menyebabkan lonjakan tiba-tiba dalam operasi I/O. Namun, jika kumpulan kerja tabel-tabel yang kritis terhadap performa tidak muat di dalam memori, In-Memory OLTP tidak berlaku karena memerlukan data untuk berada di dalam memori. Jika Anda mengalami hambatan I/O dalam pengelogan, OLTP Dalam Memori dapat mengurangi hambatan karena tidak terlalu banyak pengelogan. Jika satu atau beberapa tabel yang dioptimalkan memori dikonfigurasi sebagai tabel yang tidak tahan lama, Anda dapat menghilangkan pengelogan untuk data.

Memori
In-Memory OLTP tidak menawarkan manfaat performa apa pun. OLTP Dalam Memori dapat memberikan tekanan ekstra pada memori karena objek harus menjadi residen memori.

Jaringan
In-Memory OLTP tidak menawarkan manfaat performa apa pun. Data perlu dikomunikasikan dari tingkat data ke tingkat aplikasi.

Skalabilitas

Sebagian besar masalah penskalaan dalam aplikasi SQL Server disebabkan oleh masalah konkurensi seperti ketidakcocokan pada kunci, kait, dan spinlock.

Pertikaian Kait
Skenario umum adalah ketidakcocokan pada halaman terakhir indeks saat menyisipkan baris secara bersamaan dalam urutan kunci. Karena In-Memory OLTP tidak mengambil kait saat mengakses data, masalah skalabilitas yang terkait dengan ketidakcocokan kait akan dihapus sepenuhnya.

Pertikaian Spinlock
Karena In-Memory OLTP tidak mengambil kait saat mengakses data, masalah skalabilitas yang terkait dengan kontensi spinlock sepenuhnya dihilangkan.

Mengunci Ketidakcocokan Terkait
Jika aplikasi database Anda mengalami masalah pemblokiran antara operasi baca dan tulis, OLTP Dalam Memori menghapus masalah pemblokiran karena menggunakan bentuk baru kontrol konkurensi optimis untuk mengimplementasikan semua tingkat isolasi transaksi. In-Memory OLTP tidak menggunakan TempDB untuk menyimpan versi baris.

Jika masalah penskalaan disebabkan oleh konflik antara dua operasi tulis, seperti dua transaksi bersamaan yang mencoba memperbarui baris yang sama, OLTP Dalam Memori memungkinkan satu transaksi berhasil dan gagal pada transaksi lainnya. Transaksi yang gagal harus dikirim ulang baik secara eksplisit atau implisit, mencoba kembali transaksi. Dalam kedua kasus, Anda perlu membuat perubahan pada aplikasi.

Jika aplikasi Anda sering mengalami konflik antara dua operasi tulis, nilai penguncian optimis berkurang. Aplikasi ini tidak cocok untuk In-Memory OLTP. Sebagian besar aplikasi OLTP tidak memiliki konflik tulis kecuali konflik tersebut merupakan hasil dari eskalasi kunci.

Keamanan Tingkat Baris dalam Tabel yang Dioptimalkan Memori

Row-Level Security didukung dalam tabel yang dioptimalkan memori. Menerapkan kebijakan Keamanan Tingkat Baris ke tabel yang dioptimalkan memori pada dasarnya sama dengan tabel berbasis disk, kecuali bahwa fungsi bernilai tabel sebaris yang digunakan sebagai predikat keamanan harus dikompilasi secara asli (dibuat menggunakan opsi WITH NATIVE_COMPILATION). Untuk detailnya, lihat bagian Kompatibilitas Lintas Fitur di topik keamananRow-Level .

Berbagai fungsi keamanan bawaan yang penting untuk keamanan tingkat baris tersedia untuk tabel yang dioptimalkan memori. Untuk detailnya, lihat Fungsi Bawaan dalam Modul yang Dikompilasi Secara Asli.

EXECUTE AS CALLER - Semua modul asli sekarang mendukung dan menggunakan EXECUTE AS CALLER secara default, bahkan jika petunjuk tidak ditentukan. Ini karena diharapkan bahwa semua fungsi predikat keamanan tingkat baris menggunakan EXECUTE AS CALLER sehingga fungsi, dan fungsi bawaan apa pun yang digunakan di dalamnya, dievaluasi dalam konteks pengguna panggilan.
EXECUTE AS CALLER memiliki hit performa kecil (sekitar10%) yang disebabkan oleh pemeriksaan izin pada pemanggil. Jika modul menentukan EXECUTE AS OWNER atau EXECUTE AS SELF secara eksplisit, pemeriksaan izin ini dan biaya performa terkait dihindari. Namun, menggunakan kedua opsi ini bersama dengan fungsi bawaan yang disebutkan menyebabkan pengaruh performa yang lebih tinggi karena diperlukan peralihan konteks.

Skenario

Untuk diskusi singkat tentang skenario umum di mana In-Memory OLTP dapat meningkatkan performa, lihat In-Memory OLTP.

Lihat Juga

In-Memory Pengoptimalan OLTP (In-Memory)