Alcuni di voi hanno accesso a Hekaton pubblicato Script demo OLTP in memoria che coinvolgono AdventureWorks; il campione più recente è pubblicato qui. Questi esempi sono riportati sul database di esempio AdventureWorks2012 su CodePlex. Se hai provato questi campioni, potresti aver riscontrato un paio di problemi che possono cambiare radicalmente la tua prima esperienza con questa tecnologia.
Autorizzazione database
Molte persone scaricano "AdventureWorks2012 Data File" – un file .mdf da 200 MB che puoi allegare – senza log – usando la seguente sintassi:
CREATE DATABASE AdventureWorks2012 ON ( NAME = AdventureWorks2012_Data, FILENAME = '<path>\AdventureWorks2012_Data.mdf' ) FOR ATTACH_REBUILD_LOG;
Il problema è che, se sei connesso all'istanza di SQL Server come account Windows, potresti finire inavvertitamente come proprietario del database. Il che non sarà un grosso problema nella maggior parte degli scenari, tranne per il fatto che se crei procedure archiviate con EXECUTE AS OWNER , come fanno molti campioni che incontri, questo può causare un problema. È possibile trovare questa riga, ad esempio, in molte stored procedure compilate in modo nativo:
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
A meno che tu non abbia già attenuato questo problema in altri modi, se il proprietario del database è il tuo account Windows, è probabile che tu riceva il seguente errore quando tenti di creare una procedura del genere:
Msg 15517, livello 16, stato 1, procedura [nome procedura]Impossibile eseguire come entità database perché l'entità "dbo" non esiste, questo tipo di entità non può essere rappresentato o non si dispone dell'autorizzazione.
A seconda del tuo ambiente, potresti voler valutare seriamente come gestirlo; nel mio caso, ho preso il percorso facile e ho appena impostato l'autorizzazione sul database su sa :
ALTER AUTHORIZATION ON DATABASE::AdventureWorks2012 TO sa;
A questo punto sono stato in grado di eseguire lo script demo senza problemi (beh, ho ricevuto errori quando ha provato ad aggiungere un altro filegroup ottimizzato per la memoria, ma questo è un problema completamente diverso e ignorabile).
Conteggio secchio
Non sembrano esserci molte indicazioni pratiche su come scegliere il conteggio dei bucket per le tabelle ottimizzate per la memoria. C'è questo articolo su MSDN, che entra in alcuni dettagli tecnici, e Klaus Aschenbrenner ha scritto questo post su come fare scelte intelligenti in quest'area. A parte questo, sei praticamente da solo per sperimentare. Lo SWAG che ho sentito più spesso è 1x-2x il numero di valori chiave univoci, quindi le ricerche di punti sono più efficienti. Tuttavia, alcuni dei campioni che scoprirai lì utilizzano costantemente 1.000.000 di secchi o numeri più piccoli come 100 (e anche 5 in un caso) o un mix. Tienilo a mente quando inizi a sperimentare il tuo schema e i tuoi modelli di accesso ai dati:potresti dover abbattere le tabelle e riprovare con dimensioni di bucket diverse per trovare il "punto ottimale" per il tuo scenario.
Modello di recupero
Il database AdventureWorks2012 è impostato su SIMPLE recupero. Come il problema del proprietario del database, nella maggior parte dei casi questo non è un grosso problema per un database di esempio. Ma quando stai testando In-Memory OLTP, e probabilmente in combinazione con altre tecnologie che rendono SIMPLE ripristino un problema, come i gruppi di disponibilità:potrebbe avere molto più senso eseguire i test su un database con il ripristino impostato su FULL . In caso contrario, potresti non riuscire a osservare determinati comportamenti che potrebbero essere diversi in base a diversi modelli di ripristino. Puoi modificare AdventureWorks2012 in FULL come segue:
ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;
E non dimenticare di eseguire un backup completo, in modo che venga stabilita una catena di backup e il database non funzioni in pseudo-SIMPLE modalità di ripristino.
