Existují nevýhody uzavřených databází?
SQL Server 2012 představil koncept „obsažených“ databází, kde vše (dobře, většinou všechno), které databáze potřebuje, je obsaženo v samotné databázi. To nabízí velké výhody při přesunu databází mezi servery. Chtěl bych vědět, jestli by to měla být moje výchozí strategie při navrhování nové databáze.
MSDN uvádí několik nevýhod obsažených v databázích a mezi velké patří nedostatek podpory pro sledování změn a replikaci. Jsou tu další? Pokud nebudu tyto funkce používat, existuje důvod nepoužívat obsažené databáze?
Primárním účelem obsažených databází je usnadnit přenos vaší databáze na nový server bez toho, aby kolem něj bylo mnoho lešení. S ohledem na to se budu zabývat několika potenciálními problémy, které tuto migraci ztěžují - a nejvíce se točí kolem skutečnosti, že obsažené databáze jsou v SQL Server 2012 jen částečně obsažené (zadržování není ve skutečnosti vynuceno).
Připojovací řetězce
Řetězce připojení k uzavřené databázi musí explicitně určit databázi v připojovacím řetězci. Při navazování spojení se již nemůžete spoléhat na výchozí databázi přihlašování; Pokud neurčíte databázi, SQL Server nebude procházet všemi obsaženými databázemi a pokusit se najít jakoukoli databázi, kde by se vaše pověření mohla shodovat.
Cross-db dotazy
I když vytvoříte stejného uživatele se stejným heslem ve dvou různých obsažených databázích na stejném serveru, vaše aplikace nebude moci provádět dotazy napříč databázemi. Uživatelská jména a hesla mohou být stejná, ale nejsou ne stejný uživatel. Důvod pro to? Pokud jste na hostovaném serveru obsahovali databáze, nemělo by vám být zabráněno, aby měl stejného obsaženého uživatele jako někdo jiný, kdo náhodou používá stejný hostovaný server. Když dorazí úplné zadržení (pravděpodobně ve verzi po SQL Server 2012 nikdy ), dotazy napříč databázemi budou stejně zakázány. Velmi, vysoce, vysoce doporučuji, abyste nevytvářeli přihlášení na úrovni serveru se stejným názvem jako uživatelé databáze obsažených v databázi, a pokuste se vyhnout vytváření stejného jména uživatele v databázích, které obsahuje. Pokud potřebujete spouštět dotazy, které zasáhly více obsažených databází, použijte přihlašování na úrovni serveru, které má příslušná oprávnění (můžete si myslet, že je to sysadmin, ale u dotazů jen pro čtení je to CONNECT ANY DATABASE a SELECT ALL USER SECURABLES).
Synonyma
Většina jmen tří a čtyř částí je snadno identifikovatelná a objevují se v DMV. Pokud však vytvoříte synonymum, které odkazuje na název 3 nebo 4 částí, nezobrazí se v DMV. Pokud tedy synonyma intenzivně využíváte, je možné, že vynecháte některé externí závislosti, což může způsobit problémy v okamžiku, kdy migrujete databázi na jiný server. Stěžoval jsem si na tento problém, ale byl uzavřen jako „záměrně“ a nepřežil migraci do nový systém zpětné vazby . Všimněte si, že DMV budou také chybět názvy tří a čtyř částí, které jsou vytvořeny pomocí dynamického SQL.
Zásady pro hesla
Pokud jste vytvořili uživatele databáze obsažené v systému bez zásady hesla, může být obtížné vytvořit téhož uživatele v jiném systému, který má politiku hesla. Důvodem je, že syntaxe CREATE USER Nepodporuje obcházení zásady hesla. O tomto problému jsem podal chybu a zůstává otevřený (a také to nepřežilo tah, když byl Connect v důchodu). A zdá se mi divné, že v systému se zavedenou zásadou hesla můžete vytvořit přihlašovací jméno na úrovni serveru, které tuto zásadu snadno obchází, ale nemůžete vytvořit uživatele databáze, který tak učiní - přestože je tento uživatel ze své podstaty méně bezpečnostního rizika.
řazení
Protože se již nemůžeme spoléhat na řazení tempdb, možná budete muset změnit jakýkoli kód, který v současné době používá explicitní řazení, nebo DATABASE_DEFAULT A místo toho použít CATALOG_DEFAULT. Viz tento článek BOL obsahuje některé potenciální problémy .
IntelliSense
Pokud se jako uzavřený uživatel připojíte k uzavřené databázi, SSMS nebude plně podporovat IntelliSense. Získáte základní podtržení pro chyby syntaxe, ale žádné seznamy s automatickým dokončováním nebo popisy a všechny zábavné věci. O tomto problému jsem podal chybu a zůstává otevřený - a ještě jedna, která tento krok nepřežila.
SQL Server Data Tools
Pokud plánujete použít SSDT pro vývoj databází, aktuálně neexistuje úplná podpora obsažených databází. Což ve skutečnosti znamená, že stavba projektu nezklame, pokud použijete nějakou funkci nebo syntaxi, která narušuje kontejnment, protože SSDT v současné době neví, co je kontejnment a co by ho mohlo narušit.
ALTER DATABASE
Při spuštění příkazu ALTER DATABASE Z kontextu uzavřené databáze, rRather than ALTER DATABASE foo, Budete muset použít ALTER DATABASE CURRENT - to je tak, že pokud se databáze přesune, přejmenuje se atd. tyto příkazy nemusí vědět nic o jejich vnějším kontextu nebo odkazu.
Několik dalších
Některé věci, které byste pravděpodobně ještě neměli používat, ale přesto by měly být uvedeny v seznamu věcí, které nejsou podporovány nebo jsou zastaralé a neměly by být použity v uzavřených databázích:
- číslované postupy
- dočasné postupy
- změny řazení ve vázaných objektech
- změnit sběr dat
- změňte sledování
- replikace
Protože všichni říkají, nejedná se nutně o nevýhody k používání uzavřených databází, jedná se pouze o problémy, o kterých byste měli vědět, a ne všechny jsou výslovně zveřejněny v oficiální dokumentaci.
Musíte se také ujistit, že pokud bude uzavřená databáze migrována nebo je součástí skupiny dostupnosti nebo bude zrcadlena, všechny potenciální cílové servery mají možnost sp_configurecontained database authentication nastaveno na 1.
Možná vám bude tento příspěvek na blog užitečný, stejně jako tento , přestože předcházejí RTM.
Pro ty, kteří mají zájem získat více podrobností o obsažených databázích, mohu jim doporučit přečíst tento článek http://www.sqlshack.com/contained-databases-in-sql-server/
Článek uvádí hlavní výhody/nevýhody používání obsažených databází.
Nevýhody
Částečně obsažené databáze nemohou používat funkce jako replikace, sběr změn dat, sledování změn, objekty vázané na schéma, které závisejí na vestavěných funkcích se změnami řazení.
Výhody
Na druhé straně, jak již bylo zmíněno, existují určité výhody použití obsažených databází, jako například:
- Je docela snadné přesunout databázi z jednoho serveru na druhý,
, protože nedojde k osamělým problémům uživatelů - Metadata jsou uložena v uzavřených databázích, takže jsou jednodušší a přenosnější
- Je možné mít autentizaci SQL Server i Windows pro uživatele obsažené v DB
Článek také pomáhá s:
- vytvoření nové obsažené databáze (vytvořením typu kontejmentu jako částečného na stránce Možnosti na serveru SQL Server a pomocí dotazu T-SQL k vytvoření databáze poté)
- připojení k obsažené DB pomocí SQL Server Management Studio (v parametru připojení je třeba zadat název obsažené DB)
- převedení existující databáze na uzavřenou databázi
- práce na uzavřené databázi a výpis všech přihlášení, která jsou typu uzavřeného uživatele
Jednou nevýhodou je, že uživatel obsažené v databázi nemůže být nucen změnit své vlastní heslo, jako by se mohla přihlašovat (MUST_CHANGE). Uživatelé nemohou spravovat své vlastní heslo, dokud jim neudělíte uživatelské oprávnění a neřeknete jim, jak je změnit pomocí příkazu SQL. Nikde pro ně není snadné to spravovat pomocí uživatelských rozhraní nebo alespoň nevím jak.
Další poznámka je, že jsem v klauzuli "PIVOT" a "UNPIVOT" našel neočekávané a nezdokumentované použití metadat, o kterém jsem si myslel, že by to mělo být pouze v systémovém katalogu (sys.tables/sys.columns/atd.). Jak je uvedeno v msdn :
V uzavřené databázi katalog řazení Latin1_General_100_CI_AS_WS_KS_SC . Tato kolace je stejná pro všechny obsažené databáze ve všech instancích serveru SQL a nelze ji změnit.
Nezmínili však, že klauzule „PIVOT“ a „UNPIVOT“ také používají systémové katalogy jako prováděcí mechanismus. takže při migraci způsobuje konfliktní konfliktní chybu všude blízko použití klauzule „PIVOT“ a „UNPIVOT“. tady je nějaké repro:
/*step1 create a table belongs to a contained database and populate some data*/
create table dbo.test1 (col1 varchar(100),col2 varchar(100))
insert dbo.test1 values('a','x')
insert dbo.test1 values('b','y')
insert dbo.test1 values('c','z')
/*step2 lets see its collation you will see it is correctly as same as its (contained) database */
select name,collation_name from sys.columns where object_name(object_id) = 'test1'
/*step3 reproduce an unpivoted column*/
select * into dbo.test2
from (select * from dbo.test1) a unpivot (val for col in (col1,col2)) a
/*step4 lets check its collation you will see the column specified at "FOR" clause is created as Latin1_General_100_CI_AS_KS_WS_SC */
select name,collation_name from sys.columns where object_name(object_id) = 'test2'
/*step5 make use of the unpivoted table without awareness will cause an error*/
select val + ' = ' + col from dbo.test2
/*step6 clean up*/
drop table dbo.test1
drop table dbo.test2
můžete také vidět, že články o obsažené databázi jsou většinou neúplné. takže rozhodnutí o použití vyžaduje velmi dobrou improvizaci.