Няколко малки проблема с пробите на Hekaton

Някои от вас имат достъп до публикуван Hekaton In-Memory OLTP демо скриптове, включващи AdventureWorks; най-новата извадка е публикувана тук. Тези примери са вградени в примерната база данни на AdventureWorks2012 на CodePlex. Ако сте изпробвали тези мостри, може да сте се сблъскали с няколко проблема, които могат драстично да променят първия ви опит с тази технология.

Оторизиране на база данни

Много хора изтеглят „файла с данни AdventureWorks2012“ – 200 MB .mdf файл, който можете да прикачите – без регистрационен файл – като използвате следния синтаксис:

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

Проблемът е, че ако сте свързани към екземпляра на SQL Server като вашия акаунт в Windows, може да се окажете по невнимание като собственик на базата данни. Което няма да е голяма работа в повечето сценарии, с изключение на това, че ако създадете съхранени процедури с EXECUTE AS OWNER , както много проби, които срещате, ще направят, това може да създаде проблем. Можете да намерите този ред, например, в много компилирани в собствен произход съхранени процедури:

WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER

Освен ако вече не сте смекчили този проблем по други начини, ако собственикът на базата данни е вашият акаунт в Windows, е вероятно да получите следната грешка, когато се опитвате да създадете такава процедура:

В зависимост от вашата среда, може да искате сериозно да прецените как се справяте с това; в моя случай поех по лесния път и просто зададох оторизацията на базата данни на sa :

ALTER AUTHORIZATION ON DATABASE::AdventureWorks2012 TO sa;

В този момент успях да стартирам демонстрационния скрипт без проблем (е, получих грешки, когато се опита да добави друга файлова група, оптимизирана за памет, но това е съвсем различен и игнориран проблем).

Брой на кофата

Изглежда, че няма много практически насоки за това как да изберете броя на кофата за вашите оптимизирани за памет таблици. Има тази статия в MSDN, която навлиза в някои технически подробности и Клаус Ашенбренер е написал тази публикация за вземането на интелигентен избор в тази област. Извън това, вие сте до голяма степен сами да експериментирате. SWAG, който съм чувал най-често, е 1x-2x броя на уникалните ключови стойности, така че търсенето на точки е най-ефективно. Въпреки това някои от пробите, които ще откриете там, или постоянно използват 1 000 000 кофи, или по-малки числа като 100 (и дори 5 в един случай), или смес. Имайте това предвид, когато започнете да експериментирате със собствената си схема и модели за достъп до данни – може да се наложи да разкъсате таблици и да опитате отново с различни размери на кофата, за да намерите „сладкото място“ за вашия сценарий.

Модел за възстановяване

Базата данни AdventureWorks2012 е настроена на SIMPLE възстановяване. Подобно на проблема със собственика на базата данни, в повечето случаи това не е толкова голяма работа за примерна база данни. Но когато тествате In-Memory OLTP – и вероятно в комбинация с други технологии, които правят SIMPLE възстановяване на нарушение на сделката, като групите за наличност – може да има много по-разумно да извършите тестването си срещу база данни с възстановяване, зададено на FULL . В противен случай може да не спазвате определени поведения, които могат да бъдат различни при различните модели за възстановяване. Можете да промените AdventureWorks2012 на FULL както следва:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

И не забравяйте да направите пълно архивиране, така че да бъде създадена верига за архивиране и базата данни да не работи псевдо-SIMPLE режим на възстановяване.