Ett par små problem med Hekaton-prover

Några av er har tillgång till publicerade Hekaton In-Memory OLTP-demoskript som involverar AdventureWorks; det senaste provet publiceras här. Dessa exempel kan hämtas i exempeldatabasen AdventureWorks2012 på CodePlex. Om du har provat dessa prover kan du ha stött på ett par problem som dramatiskt kan förändra din första erfarenhet av den här tekniken.

Databasauktorisering

Många laddar ner "AdventureWorks2012 Data File" – en 200 MB .mdf-fil som du kan bifoga – utan logg – med följande syntax:

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

Problemet är att om du är ansluten till SQL Server-instansen som ditt Windows-konto kan du oavsiktligt hamna som databasägare. Vilket inte kommer att vara en stor sak i de flesta scenarier, förutom att om du skapar lagrade procedurer med EXECUTE AS OWNER , precis som många prover du stöter på, kan detta orsaka problem. Du kan hitta den här raden, till exempel, i många inbyggt kompilerade lagrade procedurer:

WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER

Om du inte redan har åtgärdat problemet på andra sätt, om ägaren till databasen är ditt Windows-konto, kommer du sannolikt att få följande felmeddelande när du försöker skapa en sådan procedur:

Beroende på din miljö kanske du vill seriöst väga hur du hanterar detta; i mitt fall tog jag den enkla vägen och ställde bara in auktorisering på databasen till sa :

ALTER AUTHORIZATION ON DATABASE::AdventureWorks2012 TO sa;

Vid det här laget kunde jag köra demoskriptet utan problem (ja, jag fick fel när det försökte lägga till en annan minnesoptimerad filgrupp, men det är ett helt annat och ignorerbart problem).

Bucket Count

Det verkar inte finnas massor av praktisk vägledning om hur du väljer bucket count för dina minnesoptimerade tabeller. Det finns den här artikeln på MSDN, som går in på några tekniska detaljer, och Klaus Aschenbrenner har skrivit det här inlägget om att göra smarta val inom detta område. Utöver det är du i stort sett på egen hand att experimentera. Den SWAG jag har hört oftast är 1x-2x antalet unika nyckelvärden, så att punktsökningar är mest effektiva. Men några av proverna du hittar där använder antingen konsekvent 1 000 000 hinkar eller mindre siffror som 100 (och till och med 5 i ett fall), eller en blandning. Tänk på det när du börjar experimentera med ditt eget schema och dataåtkomstmönster – du kanske måste riva ner tabeller och försöka igen med olika bucket-storlekar för att hitta "sweet spot" för ditt scenario.

Återställningsmodell

AdventureWorks2012-databasen är inställd på SIMPLE återhämtning. Precis som problemet med databasägaren är detta i de flesta fall inte så stor sak för en exempeldatabas. Men när du testar In-Memory OLTP – och troligen i kombination med andra tekniker som gör SIMPLE återställa en deal-breaker, som Tillgänglighetsgrupper – det kan vara mycket mer meningsfullt att utföra dina tester mot en databas med återställning inställd på FULL . Annars kanske du misslyckas med att observera vissa beteenden som kan vara olika under olika återställningsmodeller. Du kan ändra AdventureWorks2012 till FULL enligt följande:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

Och glöm inte att ta en fullständig säkerhetskopia så att en säkerhetskopieringskedja upprättas och databasen inte fungerar i pseudo-SIMPLE återställningsläge.