Gibt es Nachteile bei enthaltenen Datenbanken?


33

In SQL Server 2012 wurde das Konzept der "enthaltenen" Datenbanken eingeführt, bei dem alles, was die Datenbank benötigt, in der Datenbank selbst enthalten ist. Dies bietet große Vorteile beim Verschieben von Datenbanken zwischen Servern. Ich würde gerne wissen, ob dies meine Standardstrategie beim Entwerfen einer neuen Datenbank sein sollte.

MSDN listet verschiedene Nachteile der enthaltenen Datenbanken auf, und die großen Nachteile sind die mangelnde Unterstützung für die Änderungsverfolgung und -replikation. Gibt es noch andere Gibt es einen Grund, enthaltene Datenbanken nicht zu verwenden, wenn ich diese Funktionen nicht verwenden möchte?

Antworten:


33

Der Hauptzweck der enthaltenen Datenbanken besteht darin, das Portieren Ihrer Datenbank auf einen neuen Server zu vereinfachen, ohne dass viel Gerüst um sie herum entsteht. In diesem Sinne werde ich einige potenzielle Probleme behandeln, die diese Migration erschweren. Die meisten betreffen die Tatsache, dass enthaltene Datenbanken in SQL Server 2012 nur teilweise enthalten sind (die Eindämmung wird tatsächlich nicht erzwungen).


Verbindungszeichenfolgen

Verbindungszeichenfolgen zu einer enthaltenen Datenbank müssen die Datenbank explizit in der Verbindungszeichenfolge angeben. Sie können sich nicht mehr auf die Standarddatenbank des Logins verlassen, um eine Verbindung herzustellen. Wenn Sie keine Datenbank angeben, durchsucht SQL Server nicht alle enthaltenen Datenbanken und versucht, eine Datenbank zu finden, in der Ihre Anmeldeinformationen möglicherweise übereinstimmen.


Datenbankübergreifende Abfragen

Selbst wenn Sie denselben Benutzer mit demselben Kennwort in zwei verschiedenen enthaltenen Datenbanken auf demselben Server erstellen, kann Ihre Anwendung keine datenbankübergreifenden Abfragen durchführen. Die Benutzernamen und Kennwörter sind möglicherweise identisch, sie sind jedoch nicht derselbe Benutzer. Der Grund hierfür? Wenn Sie Datenbanken auf einem gehosteten Server enthalten haben, sollte nicht verhindert werden, dass Sie denselben Benutzer wie jemand anderen haben, der zufällig denselben gehosteten Server verwendet. Wenn vollständige Eingrenzung eintrifft (wahrscheinlich in der Version nach SQL Server 2012 nie), datenbankübergreifende Abfragen sind auf jeden Fall untersagt. Ich empfehle nachdrücklich, dass Sie keine Anmeldungen auf Serverebene mit demselben Namen wie Benutzer enthaltener Datenbanken erstellen und versuchen, die Erstellung desselben enthaltenen Benutzernamens in allen enthaltenen Datenbanken zu vermeiden. Wenn Sie Abfragen ausführen müssen, die mehrere enthaltene Datenbanken betreffen, verwenden Sie dazu eine Anmeldung auf Serverebene mit entsprechenden Berechtigungen (dies ist möglicherweise der Fall sysadmin, bei schreibgeschützten Abfragen ist dies jedoch CONNECT ANY DATABASEund SELECT ALL USER SECURABLES).


Synonyme

Die meisten 3- und 4-teiligen Namen sind leicht zu identifizieren und erscheinen in einer DMV. Wenn Sie jedoch ein Synonym erstellen, das auf einen 3- oder 4-teiligen Namen verweist, werden diese in der DMV nicht angezeigt. Wenn Sie also häufig Synonyme verwenden, können einige externe Abhängigkeiten übersehen werden. Dies kann zu Problemen führen, wenn Sie die Datenbank auf einen anderen Server migrieren. Ich habe mich über dieses Problem beschwert, es wurde jedoch als "beabsichtigt" geschlossen und hat die Migration auf das neue Feedback-System nicht überstanden . Beachten Sie, dass in der DMV auch 3- und 4-teilige Namen fehlen, die über dynamisches SQL erstellt wurden.


Kennwortrichtlinie

Wenn Sie einen enthaltenen Datenbankbenutzer auf einem System ohne Kennwortrichtlinie erstellt haben, kann es schwierig sein, denselben Benutzer auf einem anderen System zu erstellen, auf dem eine Kennwortrichtlinie vorhanden ist. Dies liegt daran, dass die CREATE USERSyntax das Umgehen der Kennwortrichtlinie nicht unterstützt. Ich habe einen Fehler zu diesem Problem gemeldet, der weiterhin besteht (und den Umzug nach dem Rücktritt von Connect auch nicht überstanden hat). Mir kommt es merkwürdig vor, dass Sie auf einem System mit einer vorhandenen Kennwortrichtlinie eine Anmeldung auf Serverebene erstellen können, die die Richtlinie leicht umgeht. Sie können jedoch keinen Datenbankbenutzer erstellen, der dies tut - obwohl dieser Benutzer von Natur aus ein Benutzer ist weniger ein Sicherheitsrisiko.


Kollation

Da wir nicht mehr auf die Zusammenstellung von tempdb verlassen können, müssen Sie einen Code ändern , dass derzeit explizite Sortierung oder verwendet DATABASE_DEFAULTzu verwenden , CATALOG_DEFAULTstatt. In diesem BOL-Artikel finden Sie einige mögliche Probleme .


IntelliSense

Wenn Sie als ein enthaltener Benutzer eine Verbindung zu einer enthaltenen Datenbank herstellen, wird IntelliSense von SSMS nicht vollständig unterstützt. Sie erhalten grundlegende Informationen zu Syntaxfehlern, aber keine automatisch vervollständigten Listen oder QuickInfos und all das, was Spaß macht. Ich habe einen Fehler zu diesem Problem gemeldet, der offen bleibt - und einer, der den Umzug nicht überstanden hat.


SQL Server-Datentools

Wenn Sie vorhaben, SSDT für die Datenbankentwicklung zu verwenden, werden enthaltene Datenbanken derzeit nicht vollständig unterstützt. Was wirklich nur bedeutet, dass das Erstellen des Projekts nicht fehlschlägt, wenn Sie eine Funktion oder Syntax verwenden, die die Eindämmung aufhebt, da SSDT derzeit nicht weiß, was Eindämmung ist und was sie möglicherweise aufhebt.


ALTER DATABASE

Wenn Sie einen ALTER DATABASEBefehl aus dem Kontext einer enthaltenen Datenbank ausführen, müssen ALTER DATABASE fooSie stattdessen r verwenden. ALTER DATABASE CURRENTDies bedeutet, dass diese Befehle beim Verschieben , Umbenennen usw. nichts über den externen Kontext oder die Referenz wissen müssen .


Ein paar andere

Einige Dinge, die Sie wahrscheinlich noch nicht verwenden sollten, sollten jedoch in der Liste der Dinge erwähnt werden, die nicht unterstützt werden oder veraltet sind und nicht in enthaltenen Datenbanken verwendet werden sollten:

  • nummerierte Prozeduren
  • vorübergehende Verfahren
  • Sortierungsänderungen in gebundenen Objekten
  • Datenerfassung ändern
  • Änderungsverfolgung
  • Replikation

Dies sind jedoch nicht unbedingt Nachteile bei der Verwendung der enthaltenen Datenbanken, sondern lediglich Probleme, die Sie kennen sollten, und die nicht alle ausdrücklich in der offiziellen Dokumentation aufgeführt sind.

Sie müssen auch sicherstellen, dass für alle potenziellen Zielserver die sp_configureOption contained database authentication1 festgelegt ist, wenn eine enthaltene Datenbank migriert wird, Teil einer Verfügbarkeitsgruppe ist oder gespiegelt wird .

Sie können feststellen , diese Blog - Post nützlich, aber auch diese ein , auch wenn sie im Voraus Datum RTM.


Wissen Sie, warum vorübergehende Eingriffe nicht erlaubt sind?
Jon Seigel

2
@ JonSeigel Sie dürfen immer noch teilweise enthalten sein, verstoßen jedoch gegen die Bestimmungen zur Eindämmung (was bedeutet, dass es keine Möglichkeit gibt, zu überprüfen, auf welche Entitäten die Prozedur zugreift, da Metadaten und Definitionen an anderer Stelle gespeichert sind). Von msdn.microsoft.com/en-us/library/ff929071.aspx#Limitations : Temporär gespeicherte Prozeduren sind derzeit zulässig. Da temporär gespeicherte Prozeduren die Eindämmung verletzen, wird nicht erwartet, dass sie in zukünftigen Versionen der enthaltenen Datenbank unterstützt werden.
Aaron Bertrand

9

Für diejenigen, die mehr Details über enthaltene Datenbanken erfahren möchten, kann ich diesen Artikel empfehlen: http://www.sqlshack.com/contained-databases-in-sql-server/

Der Artikel zeigt die wichtigsten Vor- und Nachteile der Verwendung von Datenbanken auf.

Nachteile

Teilweise enthaltene Datenbanken können keine Funktionen wie Replikation, Änderungsdatenerfassung, Änderungsnachverfolgung und schemagebundene Objekte verwenden, die von integrierten Funktionen mit Sortierungsänderungen abhängen.

Vorteile

Andererseits bietet die Verwendung von enthaltenen DBs, wie bereits erwähnt, einige Vorteile, wie z.

  • Es ist ganz einfach, die Datenbank von einem Server auf einen anderen zu verschieben,
    da keine Probleme mit verwaisten Benutzern auftreten
  • Metadaten werden in enthaltenen Datenbanken gespeichert, sodass sie einfacher und portabler sind
  • Es ist möglich, sowohl SQL Server- als auch Windows-Authentifizierung für enthaltene DB-Benutzer zu verwenden

Artikel hilft auch bei:

  • Erstellen einer neuen enthaltenen Datenbank (indem Sie den Containment-Typ in SQL Server auf der Seite "Optionen" als "Teilweise" festlegen und anschließend mithilfe der T-SQL-Abfrage eine Datenbank erstellen)
  • Herstellen einer Verbindung mit der enthaltenen Datenbank mithilfe von SQL Server Management Studio (der Name der enthaltenen Datenbank muss im Verbindungsparameter angegeben werden)
  • Konvertieren einer vorhandenen Datenbank in eine enthaltene Datenbank
  • Arbeiten an einer enthaltenen Datenbank und Auflisten aller Anmeldungen, die vom enthaltenen Benutzertyp sind

4

Ein Nachteil ist, dass ein Benutzer der enthaltenen Datenbank nicht gezwungen werden kann, sein eigenes Kennwort zu ändern, wie dies bei logins ( MUST_CHANGE) der Fall ist . Benutzer können ihr eigenes Kennwort nur verwalten, wenn Sie ihnen eine Änderungsberechtigung erteilen und ihnen mitteilen, wie sie es mithilfe einer SQL-Anweisung ändern sollen. Es ist nirgendwo einfach für sie, es über Benutzeroberflächen zu verwalten, oder zumindest weiß ich nicht wie.

Ein weiterer Hinweis ist, dass ich die unerwartete und undokumentierte Verwendung von Metadaten in den Klauseln "PIVOT" UND "UNPIVOT" gefunden habe, von denen ich dachte, dass sie nur im Systemkatalog vorhanden sein sollten (sys.tables / sys.columns / etc). Wie in msdn dokumentiert :

In einer Datenbank enthalten ist , der Katalog Sortierungs Latin1_General_100_CI_AS_WS_KS_SC . Diese Sortierung ist für alle enthaltenen Datenbanken in allen Instanzen von SQL Server gleich und kann nicht geändert werden.

Sie haben jedoch nicht erwähnt, dass die Klausel "PIVOT" AND "UNPIVOT" auch die Systemkataloge als Ausführungsmechanismus verwendet. Daher wird überall in der Nähe der Verwendung der Klauseln "PIVOT" UND "UNPIVOT" während der Migration ein Kollationskonfliktfehler erzeugt. Hier ist ein 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

Sie können auch sehen, dass die Artikel über die enthaltene Datenbank größtenteils unvollständig sind. Um es zu benutzen, braucht es eine sehr gute Improvisation.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.