sql >> Databáze >  >> RDS >> Database

Pár malých problémů se vzorky Hekaton

Někteří z vás mají přístup k publikovanému Hekaton In-Memory OLTP demo skripty zahrnující AdventureWorks; nejnovější ukázka je zveřejněna zde. Tyto příklady jsou připojeny k ukázkové databázi AdventureWorks2012 na CodePlex. Pokud jste vyzkoušeli tyto vzorky, možná jste narazili na několik problémů, které mohou dramaticky změnit vaši první zkušenost s touto technologií.

Autorizace databáze

Mnoho lidí si stahuje „AdventureWorks2012 Data File“ – soubor .mdf o velikosti 200 MB, který můžete připojit – bez protokolu – pomocí následující syntaxe:

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

Problém je v tom, že pokud jste připojeni k instanci SQL Server jako váš účet Windows, můžete se neúmyslně stát vlastníkem databáze. Což ve většině scénářů nebude velký problém, kromě toho, že pokud vytvoříte uložené procedury pomocí příkazu EXECUTE AS OWNER , stejně jako mnoho vzorků, na které narazíte, to může způsobit problém. Tento řádek můžete najít například v mnoha nativně kompilovaných uložených procedurách:

WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER

Pokud jste tento problém již nezmírnili jinými způsoby, pokud je vlastníkem databáze váš účet Windows, pravděpodobně se při pokusu o vytvoření takového postupu zobrazí následující chyba:

Msg 15517, Level 16, State 1, Procedure [název procedury]
Nelze spustit jako hlavní objekt databáze, protože principál "dbo" neexistuje, tento typ objektu nelze zosobnit nebo nemáte oprávnění.

V závislosti na vašem prostředí možná budete chtít vážně zvážit, jak se s tím vypořádáte; v mém případě jsem zvolil jednoduchou cestu a nastavil autorizaci v databázi na sa :

ALTER AUTHORIZATION ON DATABASE::AdventureWorks2012 TO sa;

V tomto okamžiku jsem byl schopen spustit ukázkový skript bez problémů (dobře, dostal jsem chyby, když se pokusil přidat další skupinu souborů optimalizovanou pro paměť, ale to je úplně jiný a ignorovatelný problém).

Počet segmentů

Zdá se, že neexistuje tuna praktických rad, jak vybrat počet segmentů pro vaše tabulky optimalizované pro paměť. Na webu MSDN je tento článek, který jde do některých technických detailů, a Klaus Aschenbrenner napsal tento příspěvek o chytrých rozhodnutích v této oblasti. Kromě toho jste v experimentování do značné míry sami. SWAG, který jsem slyšel nejčastěji, je 1x-2x větší než počet jedinečných klíčových hodnot, takže vyhledávání bodů je nejúčinnější. Nicméně některé vzorky, které tam najdete, buď trvale používají 1 000 000 kbelíků, nebo menší čísla jako 100 (a dokonce 5 v jednom případě), nebo mix. Mějte to na paměti, až začnete experimentovat se svým vlastním schématem a vzory přístupu k datům – možná budete muset roztrhat tabulky a zkusit to znovu s různými velikostmi segmentů, abyste našli „sladké místo“ pro svůj scénář.

Model obnovy

Databáze AdventureWorks2012 je nastavena na SIMPLE zotavení. Stejně jako problém s vlastníkem databáze to ve většině případů není tak velký problém pro vzorovou databázi. Ale když testujete In-Memory OLTP – a pravděpodobně v kombinaci s dalšími technologiemi, díky nimž je SIMPLE obnovte přerušovač obchodů, jako jsou skupiny Availability Groups – může mít mnohem větší smysl provádět testování na databázi s obnovou nastavenou na FULL . V opačném případě se může stát, že nebudete pozorovat určité chování, které by se mohlo v různých modelech obnovy lišit. AdventureWorks2012 můžete změnit na FULL takto:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

A nezapomeňte provést úplnou zálohu, aby se vytvořil řetězec záloh a databáze nefungovala v pseudo-SIMPLE režim obnovení.


  1. Je poskytovatel OraOLEDB v .NET nespolehlivý na polích CLOB?

  2. Rozdíl mezi uživatelem a schématem v Oracle?

  3. existuje nějaká funkce pro překlad dat v sql

  4. MySQL na Azure Performance Benchmark – ScaleGrid vs. Azure Database