Best Practices für das Änderungsmanagement mit Indizes

Unser IT-Shop beginnt zunächst mit dem Aufbau einer Gruppe von Datenbankadministratoren. Wir alle (ich selbst eingeschlossen) sind aus der Welt der Anwendungsentwicklung / Architektur gekommen, daher ist die DBA-Welt für uns noch ziemlich neu.

Neben dem Aufbau einer DBA-Gruppe möchten wir Änderungsverwaltungsverfahren und -prozesse (hoffentlich basierend auf Best Practices) für den Fall erstellen, dass Änderungen verschoben werden müssen.

Ich habe den folgenden Beitrag gefunden, der hauptsächlich für Trigger-, gespeicherte Prozedur- und / oder DDL-Änderungen hilfreich ist. Es werden jedoch nicht unbedingt Indizes oder Lieferantendatenbanken angesprochen.

Wir haben eine Mischung aus eigenen und Anbieterdatenbanken. In unserem Fall arbeiten einige (wenn auch nicht alle) Anbieter mit unserem Unternehmen zusammen, um die Datenbank (en) und Anwendungen zu erstellen. Wir sind gerade dabei, unsere Anwendungen auf Leistung zu testen, bevor sie "live" gehen. Daher analysieren wir Indizes (oder deren Fehlen) ziemlich intensiv.

Wie gehen wir am besten mit dem Änderungsmanagement um, wenn wir auf Indizes stoßen, die unserer Meinung nach erstellt werden sollten, sowohl für unsere eigenen Datenbanken als auch für Anbieter?

Was machst du in deinem Shop? Ich mache mir weniger Sorgen um Werkzeuge als um den Prozess.

EDIT: Bisher freue ich mich über das Feedback, die Kommentare und die Antworten auf diese Frage. Mir ist aufgefallen, dass einige der Antworten etwas werkzeugspezifisch sind. Ich suche nach "agnostischeren" Praktiken, wenn das möglich ist.

Wenn jedoch keine Agnostik möglich ist, verwenden wir für Tool-Sets hauptsächlich IBM DB2 LUW (und das tatsächlich unter AIX). Wir haben einige DB2 unter Windows und DB2 für i (IBMs i5 / OS), aber wir sind meistens AIX DB2. Wir verwenden die Quellcodeverwaltung, insbesondere Subversion.

Auch hier suchen wir nach allgemeinen Best Practices, aber oben ist das, was wir verwenden, herstellerspezifisch.

EDIT: Aktuelle Entscheidung: Wir beabsichtigen, unsere Argumentation sowie unsere Änderungen zu verfolgen. Daher werden wir ein Problem in unserer Issue-Tracking-Software (in unserem Fall JIRA) eröffnen. Jetzt können wir in der Dokumentation hinzufügen, welche Priorität die Änderung hat, Daten, die die Änderung bestätigen, die Änderung und die Ergebnisse der Änderung aus einer anderen Umgebung, in der die Änderung getestet wurde.

Wir beabsichtigen dann auch, unsere Änderungen an Skripten in SVN zu verfolgen (ähnlich wie unten vorgeschlagen). Auf diese Weise können wir verfolgen, welche Version von was wo existiert. Dies kann in unserer JIRA-Ausgabe (und in jeder anderen von uns verwendeten Überwachungssoftware, dh eingefügten Links) aufgezeichnet werden. Wir können mit größerer Sicherheit wissen, welche Veränderungen in welcher Umgebung stattgefunden haben und warum. Wir können dann auch verfolgen, ob der Index etwas war, das wir über die Implementierung des Anbieters hinaus oder vor dessen Implementierung usw. hinzugefügt haben.)

Ich würde Ihnen dringend empfehlen, Ihre Datenbank grundsätzlich genauso zu behandeln wie Ihren Anwendungscode. Sie können Ihre Datenbank in ihre Bestandteile skripten und diese in die Quellcodeverwaltung einchecken und dort dieselben Labels und Versionen verwenden, die Sie für Ihre Apps verwenden.

Um die Objekte in die Quellcodeverwaltung zu bringen, können Sie eine Reihe von Tools verwenden. Microsoft hat ein Tool mit dem Spitznamen Data Dude. Es funktioniert mit Visual Studio. Sie bereiten auch die Veröffentlichung eines neuen Tools namens SQL Server Database Tools (SSDT) ​​vor, das wieder mit Visual Studio zusammenarbeitet. Meine Firma, Red Gate Software, stellt ein Tool her, das mit SSMS funktioniert und SQL Source Control heißt.

In Bezug auf den Prozess habe ich mehrere Kapitel für das Buch Red Gate Guide to Team Development geschrieben . Es ist als kostenloser Download erhältlich (oder wenn Sie einen Baum töten möchten, können Sie einen von Amazon kaufen). Ich gehe dort auf viel mehr Details zur Arbeit mit Datenbanken in Entwicklungsteams ein.

1. Wir verwalten Datenbankskripte als Teil unserer Anwendungscodebasis, 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 Schematabellen und Beispieldaten
   • stagingchanges.sql - nimmt Änderungen an der base.sql für die Staging-Umgebung vor, hauptsächlich E-Mail-Adressen, Pfade und andere Elemente, die sich möglicherweise ändern
   • prodchanges.sql - nimmt Änderungen an der base.sql für eine Produktionsbereitstellung vor. Bei neuen Projekten können wir diese normalerweise in tatsächlichen Produktionsumgebungen testen

3. Instandhaltung

   • base.sql - eine bereinigte Version der Produktionsdatenbank
   • stagingchanges.sql und prodchanges.sql - wie oben
   • changerequest.sql (hat normalerweise die ID der Änderungsanforderung), die alle Schemaänderungen für die aktuelle Änderungsanforderung anwendet, an der wir arbeiten
   • changerequest-rollback.sql - kehrt die für die Änderungsanforderung vorgenommenen Änderungen um und setzt die Datenbank auf die Produktion zurück
   • Archiv (Ordner) für vorherige Änderungsanforderungsskripte

Im Wartungsmodus müssen wir also nur das Skript changerequest.sql während der Bereitstellung auf die Produktion anwenden

Ich bin seit 5 Jahren im Bereich der Datenbankversionskontrolle (als Director of Product Management bei DBmaestro ) tätig und habe über zwei Jahrzehnte als DBA gearbeitet. Ich kann Ihnen die einfache Tatsache sagen, dass Sie die Datenbankobjekte nicht so behandeln können, wie Sie Ihr Java behandeln. C # oder andere Dateien.

Es gibt viele Gründe und ich werde einige nennen:

• Dateien werden lokal auf dem PC des Entwicklers gespeichert, und die von ihm vorgenommenen Änderungen
  wirken sich nicht auf andere Entwickler aus. Ebenso ist die Entwicklerin von Änderungen ihrer Kollegin nicht betroffen. In der Datenbank ist dies
  (normalerweise) nicht der Fall, und Entwickler verwenden dieselbe Datenbankumgebung
  , sodass sich alle Änderungen, die an der Datenbank vorgenommen wurden, auf andere auswirken.
• Das Veröffentlichen von Codeänderungen erfolgt über das Einchecken / Senden von Änderungen / usw. (abhängig davon, welches Versionsverwaltungswerkzeug Sie verwenden). Zu diesem Zeitpunkt wird der Code aus dem lokalen Verzeichnis des Entwicklers
  in das Quellcodeverwaltungs-Repository eingefügt . Entwickler, die den
  neuesten Code erhalten möchten, müssen ihn vom Quellcodeverwaltungstool anfordern. In der
  Datenbank ist die Änderung bereits vorhanden und wirkt sich auf andere Daten aus, auch wenn sie nicht in das Repository eingecheckt wurden.
• Während des Eincheckens von Dateien führt das Quellcodeverwaltungstool eine Konfliktprüfung durch, um festzustellen, ob dieselbe Datei während der Änderung Ihrer lokalen Kopie von einem anderen Entwickler geändert und eingecheckt wurde. Auch hier gibt es keine Überprüfung in der Datenbank. Wenn Sie eine Prozedur von Ihrem lokalen PC aus ändern und gleichzeitig dieselbe Prozedur mit Code von meinem lokalen PC ändern, überschreiben wir die Änderungen der anderen.
• Der Code-Erstellungsprozess wird durchgeführt, indem das Label / die neueste Version des Codes in ein leeres Verzeichnis verschoben und anschließend eine Build-Kompilierung durchgeführt wird. Die Ausgabe sind Binärdateien, in die wir die vorhandenen kopieren und ersetzen. Es ist uns egal, was vorher war. In der Datenbank können wir die Datenbank nicht neu erstellen, da wir die Daten pflegen müssen! Außerdem führt die Bereitstellung SQL-Skripts aus, die im Erstellungsprozess generiert wurden.
• Bei der Ausführung der SQL-Skripte (mit den Befehlen DDL, DCL, DML (für statischen Inhalt)) wird davon ausgegangen, dass die aktuelle Struktur der Umgebung mit der Struktur beim Erstellen der Skripte übereinstimmt. Wenn nicht, können Ihre Skripte fehlschlagen, wenn Sie versuchen, eine bereits vorhandene neue Spalte hinzuzufügen.
• Wenn SQL-Skripte als Code behandelt und manuell generiert werden, entstehen Syntaxfehler, Datenbankabhängigkeitsfehler und nicht wiederverwendbare Skripte, die das Entwickeln, Verwalten und Testen dieser Skripte erschweren. Darüber hinaus können diese Skripte in einer Umgebung ausgeführt werden, die sich von der unterscheidet, in der sie ausgeführt werden.
• Manchmal stimmt das Skript im Versionskontroll-Repository nicht mit der Struktur des getesteten Objekts überein, und dann treten Fehler in der Produktion auf!

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

Was ich gefunden habe, dass das funktioniert, ist das Folgende:

1. Verwenden Sie ein erzwungenes Versionskontrollsystem, das Auscheck- / Eincheckvorgänge für die Datenbankobjekte erzwingt. Dadurch wird sichergestellt, dass das Versionskontroll-Repository mit dem eingecheckten Code übereinstimmt, wenn es die Metadaten des Objekts beim Einchecken liest, und nicht als separater Schritt, der manuell ausgeführt wird
2. Verwenden Sie eine Auswirkungsanalyse, bei der Baselines als Teil des Vergleichs verwendet werden, um Konflikte zu identifizieren und festzustellen, ob eine Änderung (beim Vergleich der Objektstruktur zwischen dem Quellcodeverwaltungs-Repository und der Datenbank) eine echte Änderung ist, die aus der Entwicklung stammt, oder eine Änderung, aus der sie stammt ein anderer Pfad und dann sollte es übersprungen werden, wie z. B. ein anderer Zweig oder eine Notfalllösung.

Ein Artikel, den ich dazu geschrieben habe, wurde hier veröffentlicht. Sie können ihn gerne lesen.