Et par små problemer med Hekaton prøver

Nogle af jer har adgang til publicerede Hekaton In-Memory OLTP-demoscripts, der involverer AdventureWorks; den seneste prøve er offentliggjort her. Disse eksempler piggyback på AdventureWorks2012-eksempeldatabasen på CodePlex. Hvis du har prøvet disse prøver, er du muligvis stødt på et par problemer, der dramatisk kan ændre din første oplevelse med denne teknologi.

Databasegodkendelse

Mange mennesker downloader "AdventureWorks2012 Data File" – en 200 MB .mdf-fil, som du kan vedhæfte – uden en log – ved hjælp af følgende syntaks:

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

Problemet er, at hvis du er forbundet til SQL Server-instansen som din Windows-konto, kan du utilsigtet ende som databaseejer. Hvilket ikke vil være en stor sag i de fleste scenarier, bortset fra at hvis du opretter lagrede procedurer med EXECUTE AS OWNER , ligesom mange prøver, du støder på, vil gøre, kan dette forårsage et problem. Du kan for eksempel finde denne linje i mange oprindeligt kompilerede lagrede procedurer:

WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER

Medmindre du allerede har afhjulpet dette problem på andre måder, hvis ejeren af ​​databasen er din Windows-konto, vil du sandsynligvis få følgende fejlmeddelelse, når du forsøger at oprette en sådan procedure:

Afhængigt af dit miljø vil du måske seriøst overveje, hvordan du håndterer dette; i mit tilfælde tog jeg den nemme vej og satte bare autorisation på databasen til sa :

ALTER AUTHORIZATION ON DATABASE::AdventureWorks2012 TO sa;

På dette tidspunkt var jeg i stand til at køre demo-scriptet uden problemer (godt, jeg fik fejl, da det forsøgte at tilføje en anden hukommelsesoptimeret filgruppe, men det er et helt andet og ignorerbart problem).

Bucket Count

Der ser ikke ud til at være et væld af praktisk vejledning om, hvordan du vælger bucket count til dine hukommelsesoptimerede borde. Der er denne artikel på MSDN, som går ind i nogle tekniske detaljer, og Klaus Aschenbrenner har skrevet dette indlæg om at træffe smarte valg på dette område. Ud over det er du stort set på egen hånd til at eksperimentere. Den SWAG, jeg oftest har hørt, er 1x-2x antallet af unikke nøgleværdier, så punktopslag er mest effektive. Men nogle af prøverne, du finder derude, bruger enten konsekvent 1.000.000 spande eller mindre tal som 100 (og endda 5 i ét tilfælde) eller en blanding. Husk det, når du begynder at eksperimentere med dit eget skema og dataadgangsmønstre – du skal muligvis rive tabeller ned og prøve igen med forskellige bucket-størrelser for at finde det "sweet spot" til dit scenario.

Gendannelsesmodel

AdventureWorks2012-databasen er indstillet til SIMPLE genopretning. Ligesom problemet med databaseejeren er dette i de fleste tilfælde ikke det store problem for en prøvedatabase. Men når du tester In-Memory OLTP – og sandsynligvis i kombination med andre teknologier, der gør SIMPLE gendan en deal-breaker, såsom tilgængelighedsgrupper – det kan give meget mere mening at udføre din test mod en database med gendannelse sat til FULL . Ellers kan du undlade at observere visse adfærd, der kan være anderledes under forskellige genopretningsmodeller. Du kan ændre AdventureWorks2012 til FULL som følger:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

Og glem ikke at tage en fuld backup, så en backup-kæde er etableret, og databasen ikke fungerer i pseudo-SIMPLE gendannelsestilstand.