Best Practice für SQL Server 2008 Schemaänderung

Question

Ich bin auf der Suche nach Informationen über die folgenden:

Was ist die Best Practices für die Aktualisierung des Schemas meiner dev DB meiner Produktion DB ist, oder auch kurz und bündig zu machen DB-Schemaänderungen im Allgemeinen.

Die Produktionsdatenbank ist das Back-End für zwei verschiedene ASP.NET-Websites.

Unser Schema Veränderungsprozess ist ziemlich robust mit jeder „Migration“ tatsächlich eine CS-Datei enthält die Schemaänderungen zu sein. Wir werden dann mit ADO.NET die Schemaänderungen gegen die db anzuwenden.

Meine Frage ist, mehr über die Anbindung der Datenbank.

Soll ich die beiden Websites stoppen, die die DB zugreifen. Ich nehme an, ich sollte. Soll ich die DB in den Single-User-Modus. Es sieht aus wie ich sollte, aber ich bin nicht ganz sicher, dass auf.

Was könnte ich fehlen? Was sind die Dinge, die Sie in der Hand vor über DB-Schemaänderungen gebissen haben.

Answer 1

Wenn die Updates Dinge wie Spaltennamen, gespeicherte Prozedur Parameter ändern, etc dann nimmt immer die Anwendungen offline vor einem Schema Update zu tun.

Wenn die Updates nur für die Dinge, die die normale Verarbeitung der Daten nicht Sie beeinflussen dann können der Lage sein, dies zu tun, „heiß“. Diese Kategorie ist, wenn Sie Dinge wie Indizes hinzufügen, Tabellen, usw.

Wenn jemand die App verwendet, während ein Schema Update verarbeitet man sehr gut könnten sich in einer Situation, wo die Datenkonsistenz nicht beeinträchtigt wird.

Wenn dieses Update ein entsprechendes Update für Ihre Web-Anwendung Dateien erfordert dann die Seite nehmen (s) offline vor dem Update. Sie wissen nicht, wer könnte eine Seite werden sehen und etwa nur zu klicken Sie auf Absenden, um einen Fehler ...

Normalerweise Wartung dieser Art ist während außerhalb der Spitzenzeiten durchgeführt. Sie finden die Benutzer vor der Zeit, wann die Website wird nach unten informieren wollen und für wie lange.

Außerdem verwenden wir Tools wie SQL Redgate Vergleich zum Skript unseres db-Updates. Dies wird auf einem Staging-Server ausgeführt, die von Produktionsdaten aufgefrischt worden war, vor dem eigentlichen Push, um sicherzustellen, dass es keine Überraschungen geben und es kann sehr schnell durchgeführt werden.

In Bezug auf Einzelbenutzermodus, verwenden Sie in der Regel dies zu beschränken Sie den Zugriff auf eine Datenbank mit einer einzigen Management-Studio-Instanz. Es ist nicht etwas, was wir normalerweise als Teil unserer Implementierungen tun.

Answer 2

Ich habe nicht die CS- / ado.net Route zu machen Schemaänderungen berücksichtigt. Was wir tun, ist erstellen ‚Delta‘ SQL-Dateien - SQL die Änderungen vorzunehmen. Diese werden ausgeführt gegen ein Schema bekannter-Revision, um die Änderungen zu machen, und laufen die .SQL Teil einer Bereitstellung ist.

Wie am besten können wir, wir versuchen auch, diese sicher zu machen mehrere Male ausführen, indem Schema für bestimmte Dinge wie die Existenz einer Spalte überprüft, Index, usw. So können sie ausgeführt ‚aus Versehen‘ mehrere Male werden könnten.

Wenn wir wir haben bestimmte Zeiten des Tages / Woche bereitstellen, warnen Nutzer / Kunden, Abschalt-Websites, etc. Mit ‚Praxis‘ Einsätze fast los jeden Tag auf Entwickler und Staging-Server die letzten Tage vor dem Release, endgültige Bereitstellung Vertrauen ist hoch.

Keeping Schemaänderungen in SQL sie mehr aussehen wie die ‚Master‘ Schema SQL sie modifify und sind daher leichter zu verfolgen. Weniger zu debuggen auch!

Sie werden auch in TFS zusammen mit dem Rest des Codes verwaltet werden.

Answer 3

Ideale Lage, aber nicht immer erreichbar: Sie machen Schemaänderungen, die mit V kompatibel sind Version Ihrer Website. Sie geben dann V , um Ihren Web-Server. Sobald alle Ihre Web-Server V sind bis , können Sie führen dann alle Bereinigungen (Bevöl fehlende Werte, usw.), und dann geeignete NULL-Zulässigkeit Änderungen vornehmen.