Een paar kleine problemen met Hekaton-samples

Sommigen van jullie hebben toegang tot gepubliceerde Hekaton In-Memory OLTP-demoscripts met AdventureWorks; het meest recente voorbeeld wordt hier gepubliceerd. Deze voorbeelden maken gebruik van de voorbeelddatabase van AdventureWorks2012 op CodePlex. Als je deze voorbeelden hebt geprobeerd, ben je misschien een aantal problemen tegengekomen die je eerste ervaring met deze technologie drastisch kunnen veranderen.

Databaseautorisatie

Veel mensen downloaden het "AdventureWorks2012-gegevensbestand" - een .mdf-bestand van 200 MB dat u kunt bijvoegen - zonder een logboek - met de volgende syntaxis:

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

Het probleem is dat, als u verbonden bent met de SQL Server-instantie als uw Windows-account, u per ongeluk de eigenaar van de database kunt worden. Wat in de meeste scenario's geen probleem zal zijn, behalve dat als u opgeslagen procedures maakt met EXECUTE AS OWNER , zoals veel voorbeelden die u tegenkomt, kan dit een probleem veroorzaken. U vindt deze regel bijvoorbeeld in veel native gecompileerde opgeslagen procedures:

WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER

Tenzij u dit probleem al op andere manieren hebt verholpen en de eigenaar van de database uw Windows-account is, krijgt u waarschijnlijk de volgende foutmelding wanneer u een dergelijke procedure probeert te maken:

Afhankelijk van je omgeving wil je misschien serieus afwegen hoe je hiermee omgaat; in mijn geval heb ik de gemakkelijke weg gekozen en de autorisatie op de database ingesteld op sa :

ALTER AUTHORIZATION ON DATABASE::AdventureWorks2012 TO sa;

Op dit punt kon ik het demoscript probleemloos uitvoeren (nou, ik kreeg fouten toen het probeerde een andere voor geheugen geoptimaliseerde bestandsgroep toe te voegen, maar dat is een heel ander en onaanvaardbaar probleem).

Emmertelling

Er lijkt niet veel praktische begeleiding te zijn over het kiezen van het aantal buckets voor uw voor geheugen geoptimaliseerde tabellen. Er is dit artikel op MSDN, dat ingaat op enkele technische details, en Klaus Aschenbrenner heeft dit bericht geschreven over het maken van slimme keuzes op dit gebied. Buiten dat ben je vrijwel alleen om te experimenteren. De SWAG die ik het vaakst heb gehoord, is 1x-2x het aantal unieke sleutelwaarden, dus het opzoeken van punten is het meest efficiënt. Sommige van de voorbeelden die u daar zult vinden, gebruiken echter consequent 1.000.000 emmers, of kleinere aantallen zoals 100 (en zelfs 5 in één geval), of een mix. Houd daar rekening mee als u begint te experimenteren met uw eigen schema en patronen voor gegevenstoegang. Mogelijk moet u tabellen opsplitsen en het opnieuw proberen met verschillende bucketgroottes om de 'sweet spot' voor uw scenario te vinden.

Herstelmodel

De AdventureWorks2012-database is ingesteld op SIMPLE herstel. Net als het probleem met de database-eigenaar, is dit in de meeste gevallen niet zo'n groot probleem voor een voorbeelddatabase. Maar wanneer u In-Memory OLTP test – en waarschijnlijk in combinatie met andere technologieën die SIMPLE herstel een dealbreaker, zoals Beschikbaarheidsgroepen – het kan veel logischer zijn om uw tests uit te voeren met een database met herstel ingesteld op FULL . Anders kan het zijn dat u bepaalde gedragingen niet waarneemt die bij verschillende herstelmodellen anders zouden kunnen zijn. U kunt AdventureWorks2012 wijzigen in FULL als volgt:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

En vergeet niet een volledige back-up te maken, zodat er een back-upketen tot stand komt en de database niet pseudo-SIMPLE werkt herstelmodus.