Best practices für change management mit Indizes

Question

Unsere IT-Abteilung ist, den ersten Start zu bauen eine Gruppe von DBA ist.Alle von uns (mich eingeschlossen) haben, kommen aus der Applikations-Entwicklung/ - Architektur der Welt, so die DBA-Welt ist noch ziemlich neu für uns.

Zusammen mit dem Gebäude eine DBA-Gruppe sind wir auf der Suche zu bauen, ändern, verwalten, Verfahren und Prozesse (hoffentlich basierend auf best practices) für die, wenn wir Sie brauchen, sich zu bewegen änderungen.

Ich habe das folgenden Beitrag das ist hilfreich für die meist trigger, gespeicherte Prozedur, und/oder DDL-änderungen.Aber es muss nicht unbedingt die Adresse Indizes oder Anbieter von Datenbanken.

Wir haben eine Mischung aus sowohl unsere eigenen und Verkäufer Datenbanken.In unserem Fall einige der Anbieter (wenn nicht alle) arbeiten mit unserem Unternehmen zu bauen die Datenbank(en) und-Anwendungen.Wir sind in den Prozess der performance-testen Sie unsere Anwendungen jetzt, bevor Sie "go live".So analysieren wir die Indizes (oder das fehlen davon) ziemlich stark.

Wie kommen wir über Indizes, die wir fühlen, sollten vorgenommen werden, wie wir das beste Angebot in change-management mit Bezug auf diese, sowohl für unsere eigenen Datenbanken sowie für jeden Anbieter?

Was tun Sie in Ihrem shop?Ich bin weniger besorgt über die tools, die dann über den Prozess.

EDIT: So weit bin ich schätzen das feedback, Kommentare und Antworten für diese Frage.Ich habe bemerkt, dass einige der Antworten sind ein bisschen spezifisches Werkzeug.Ich bin auf der Suche nach mehr "Agnostiker" - Praktiken, wenn das werden musste.

Allerdings, wenn Agnostiker ist nicht möglich, dann für Werkzeug-sets, die wir verwenden, IBM DB2 LUW (und tatsächlich auf AIX), meistens.Wir haben einige DB2 auf Windows und DB2 für i (IBM i5/OS), aber wir sind meistens AIX DB2.Wir verwenden source control, die speziell Subversion.

Wieder auf der Suche für die Allgemeine best practices, vor allem aber, was wir verwenden das wäre vendor specific.

EDIT: Aktuelle Entscheidung: Wollen wir track unsere Argumentation sowie unsere änderungen.So werden wir öffnen Sie ein Thema in unserer issue-tracking software (in unserem Fall JIRA).Jetzt können wir hinzufügen, in der Dokumentation was Priorität hat die änderung, Daten sichert, was die Veränderung werden sollte, die änderung und die Ergebnisse der Wechsel von einem anderen - Umgebung, wo der änderung wurde getestet.

Wir haben dann auch wollen halten track von unserem änderungen in Skripten in SVN (viel, wie unten vorgeschlagen).Auf diese Weise können wir verfolgen, welche version der das, was existiert, wo.Diese können aufgezeichnet werden in unserer JIRA-Problem (und in alle andere überwachung software, die wir verwenden, dh.eingefügte links).Wir können wissen, mit mehr Sicherheit, was die ändern gingen zu dem, was Umwelt-und warum.Wir können dann auch zu verfolgen, ob der index war etwas, das wir Hinzugefügt, über den Anbieter Umsetzung oder vor Ihrer Durchführung, usw.)

Answer 1

Ich würde dringend empfehlen, dass Sie behandeln Ihre Datenbank im Grunde die gleiche Weise, wie Sie behandeln Ihre Anwendung code.Sie können ein Skript Ihrer Datenbank heraus um es Einzelteile und überprüfen Sie diese in die Quellcodeverwaltung und dann verwenden die gleichen Bezeichnungen und Versionen gibt, die Sie verwenden für Ihre apps.

Um die Objekte in die Quellcodeverwaltung es gibt eine Reihe von tools, die Sie verwenden können.Microsoft hat ein tool, das den Spitznamen Daten Dude.Es funktioniert mit Visual Studio.Sie sind auch der Vorbereitung auf release ein neues tool namens SQL Server-Datenbank-Tools (SSDT), wieder, der Arbeit mit Visual Studio.Meine Firma Red Gate Software, macht ein Werkzeug, dass arbeitet mit SSMS SQL-Source-Control.

In Bezug auf den Prozess, ich schrieb einige Kapitel für das Buch Rote-Tor-Guide für Team-Entwicklung.Es ist als kostenloser download verfügbar (oder wenn Sie wollen, zu töten, einen Baum können Sie purcahse eine von Amazon).Ich gehe in viel mehr details über die Arbeit mit Datenbanken in der Entwicklung von teams gibt es.

Answer 2

1. Wir verwalten Datenbankskripte als Teil unserer AnwendungscodeBase, die unter Versionskontrolle verwaltet wird. Wir verwenden jedoch unterschiedliche "Prozesse" für Entwicklungs- und Produktionscode

2. Entwicklung Wir pflegen die folgenden Skripte:

   • Base.sql - Erstellt die Schema -Tabellen und Beispieldaten
   • StagingChanges.sql - Nimmt Änderungen an der Basis.sql für die Staging -Umgebung vor, hauptsächlich E -Mail -Adressen, Pfade und andere Vermögenswerte, die sich ändern könnten
   • prodchanges.sql - ändert Änderungen an der Basis.sql für eine Produktionsbereitstellung. Für neue Projekte können wir diese in der Regel in den tatsächlichen Produktionsumgebungen testen

3. Wartung

   • Base.sql - Eine sanitäre Version der Produktionsdatenbank
   • stagingchanges.sql und prodchanges.sql - wie oben
   • ChecheSequest.sql (normalerweise hat die ID der Änderungsanforderung), in der Schema -Änderungen für die aktuelle Änderungsanforderung angewendet werden, an der wir arbeiten
   • ChangeRequest -Rollback.sql - Umkehrt die Änderungen für die Änderungsanforderung und setzt die Datenbank wieder auf die Produktion zurück
   • Archiv (Ordner) für vorherige Änderungsanforderungsskripte

Im Wartungsmodus müssen wir also nur das Skript von ChangeRequest.sql während der Bereitstellung zur Produktion anwenden

Answer 3

In der Datenbank der Versionskontrolle Platz für 5 Jahre (als director of product management bei DBmaestro) und arbeitete als DBA für über zwei Jahrzehnten, ich kann Ihnen sagen, die einfache Tatsache, dass Sie nicht behandeln, die Datenbank-Objekte wie behandeln Sie Ihre Java -, C# oder andere Dateien.

Es gibt viele Gründe und ich werde ein paar Namen zu nennen:

• Dateien sind gespeichert lokal auf dem Entwickler-PC und die Veränderung, s/er
  lässt sich nicht beeinflussen von anderen Entwicklern.Ebenfalls, der Entwickler ist nicht betroffen von änderungen, die von Ihrer Kollegin.In der Datenbank ist dies
  (in der Regel) nicht der Fall ist, und Entwickler teilen sich die gleiche Datenbank
  Umgebung, so dass jede änderung, die begangen wurden, um die Datenbank zu beeinflussen andere.
• Die Veröffentlichung von code-änderungen erfolgt durch Check-In / Änderungen Senden / etc.(abhängig von der source-control-tool, das Sie verwenden).An diesem Punkt, den code aus dem lokalen Verzeichnis, in der die Entwickler eingefügt
  in das source control repository.Entwickler erhalten möchte
  neueste code anfordern müssen es aus dem source-control-tool.In
  Datenbank die änderung bereits vorhanden ist und Auswirkungen auf andere Daten-selbst wenn es wurde nicht überprüft-in in das repository.
• Während die Datei beim check-in die source-control-tool führt zu einem Konflikt überprüfen Sie, ob die gleiche Datei geändert wurde eingecheckt und von einem anderen Entwickler während der Zeit, Sie verändert Ihre lokale Kopie.Wieder da nicht prüfen, ob diese in der Datenbank.Wenn Sie ändern ein Verfahren aus Ihr lokaler PC und zur gleichen Zeit, die ich ändern die gleiche Prozedur mit code-Formular meinem lokalen PC, dann überschreiben wir die änderungen gegenseitig.
• Der build-Prozess des Codes erfolgt, indem man das Etikett / neueste version code in ein leeres Verzeichnis und führen Sie dann einen build – kompilieren.Die Ausgabe sind Binärdateien, in denen wir kopieren & ersetzen vorhandenen.Wir kümmern uns nicht, was vorher war.In der Datenbank können wir nicht erstellen Sie die Datenbank wie wir benötigen, um die Daten beibehalten!Auch die Bereitstellung führt SQL-Skripte, die erstellt wurden, in das build Prozess.
• Bei der Ausführung des SQL-Skripts (mit der DDL, DCL DML (für statische Inhalt) - Befehle) Sie übernehmen der aktuellen Struktur des Umgebung der Struktur entspricht, die beim erstellen der Skripte.Wenn nicht, dann Ihre Skripts fehlschlagen kann, wie Sie versuchen, neue Spalte hinzufügen, die bereits vorhanden ist.
• Behandlung von SQL-Skripten als code und manuelle Generierung von Ihnen verursachen syntax-Fehler, Datenbank Abhängigkeiten Fehler Drehbücher, die sich nicht wiederverwendbare erschweren die Aufgabe, Entwicklung, Wartung, Erprobung des Skripts.Zusätzlich, diese Skripte ausführen kann, auf eine die Umwelt ist von dem unterscheidet, das Sie, obwohl es laufen würde auf.
• Manchmal wird das Skript in der version control repository nicht mit die Struktur des Objekts, das getestet wurde und dann Fehler geschehen in der Produktion!

Es gibt viele mehr, aber ich denke, Sie haben das Bild.

Was ich gefunden habe, die funktioniert, ist die folgende:

1. Verwenden Sie ein erzwungenes version control system erzwingt, dass check-out/check-in-Vorgänge auf der Datenbank-Objekte.Dieser wird stellen Sie sicher, dass die version control repository mit der code wurde aufgegebenes es liest die Metadaten des Objekts in die check-in Betriebs-und nicht als eine getrennte Schritt manuell durchgeführt
2. Verwenden Sie einen impact-Analyse nutzen, die Grundlinien als Bestandteil der Vergleich, Konflikte zu identifizieren und zu identifizieren, wenn eine änderung (wenn vergleicht man die Struktur des Objekts zwischen dem source-control repository und die Datenbank) ist eine echte Veränderung, die Herkunft von Entwicklung oder eine Veränderung, die Herkunft aus einem anderen Pfad und es sollte dann übersprungen werden, wie anderen Zweig oder ein Notfall fix.

Ein Artikel schrieb ich über dieses veröffentlicht wurde hier, Sie sind willkommen, es zu Lesen.