Beberapa masalah kecil dengan sampel Hekaton

Beberapa dari Anda memiliki akses ke Hekaton yang diterbitkan Skrip demo OLTP dalam Memori yang melibatkan AdventureWorks; sampel terbaru diterbitkan di sini. Contoh-contoh ini mendukung database sampel AdventureWorks2012 di CodePlex. Jika Anda telah mencoba sampel ini, Anda mungkin menemukan beberapa masalah yang secara dramatis dapat mengubah pengalaman pertama Anda dengan teknologi ini.

Otorisasi Basis Data

Banyak orang mengunduh "File Data AdventureWorks2012" – file .mdf 200 MB yang dapat Anda lampirkan – tanpa log – menggunakan sintaks berikut:

CREATE DATABASE AdventureWorks2012 ON
(
  NAME = AdventureWorks2012_Data, FILENAME = '<path>\AdventureWorks2012_Data.mdf'
)
FOR ATTACH_REBUILD_LOG;

Masalahnya adalah, jika Anda terhubung ke instance SQL Server sebagai akun Windows Anda, Anda mungkin secara tidak sengaja berakhir sebagai pemilik database. Yang tidak akan menjadi masalah besar di sebagian besar skenario, kecuali jika Anda membuat prosedur tersimpan dengan EXECUTE AS OWNER , seperti banyak sampel yang Anda temui, ini dapat menyebabkan masalah. Anda mungkin menemukan baris ini, misalnya, dalam banyak prosedur tersimpan yang dikompilasi secara native:

WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER

Kecuali jika Anda telah mengurangi masalah ini dengan cara lain, jika pemilik database adalah akun Windows Anda, kemungkinan besar Anda akan mendapatkan kesalahan berikut saat mencoba membuat prosedur seperti itu:

Tergantung pada lingkungan Anda, Anda mungkin ingin mempertimbangkan secara serius bagaimana Anda menghadapinya; dalam kasus saya, saya mengambil jalan yang mudah dan hanya mengatur otorisasi pada database ke sa :

ALTER AUTHORIZATION ON DATABASE::AdventureWorks2012 TO sa;

Pada titik ini saya dapat menjalankan skrip demo tanpa masalah (well, saya mendapatkan kesalahan ketika mencoba menambahkan filegroup lain yang dioptimalkan memori, tetapi itu adalah masalah yang sama sekali berbeda dan dapat diabaikan).

Jumlah Bucket

Tampaknya tidak ada banyak panduan praktis tentang cara memilih jumlah ember untuk tabel yang dioptimalkan memori Anda. Ada artikel ini di MSDN, yang membahas beberapa detail teknis, dan Klaus Aschenbrenner telah menulis posting ini tentang membuat pilihan cerdas di bidang ini. Di luar itu, Anda cukup banyak bereksperimen sendiri. SWAG yang paling sering saya dengar adalah 1x-2x jumlah nilai kunci unik, sehingga pencarian titik paling efisien. Namun beberapa sampel yang akan Anda temukan di sana secara konsisten menggunakan 1.000.000 ember, atau angka yang lebih kecil seperti 100 (dan bahkan 5 dalam satu kasus), atau campuran. Ingatlah hal itu saat Anda mulai bereksperimen dengan skema dan pola akses data Anda sendiri – Anda mungkin harus membongkar tabel dan mencoba lagi dengan ukuran bucket yang berbeda untuk menemukan "titik tepat" untuk skenario Anda.

Model Pemulihan

Database AdventureWorks2012 diatur ke SIMPLE pemulihan. Seperti masalah pemilik database, dalam banyak kasus ini bukan masalah besar untuk database sampel. Namun saat Anda menguji OLTP Dalam Memori – dan kemungkinan dikombinasikan dengan teknologi lain yang membuat SIMPLE memulihkan pemecah kesepakatan, seperti Grup Ketersediaan – mungkin jauh lebih masuk akal untuk melakukan pengujian Anda terhadap database dengan pemulihan yang disetel ke FULL . Jika tidak, Anda mungkin gagal mengamati perilaku tertentu yang mungkin berbeda di bawah model pemulihan yang berbeda. Anda dapat mengubah AdventureWorks2012 menjadi FULL sebagai berikut:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

Dan jangan lupa untuk mengambil cadangan lengkap, sehingga rantai cadangan dibuat, dan database tidak beroperasi di pseudo-SIMPLE mode pemulihan.