nicht angemeldet
Schemaänderungen und Abbruch von Skripten
Hallo!
Also mir stellt sich folgendes Problem:
Wenn ich ein Skript "A" laufen lasse und es sich um eine Transaktion handelt, ist es kein Problem, wenn es zwischendurch abbricht, da Transaktionen ja rückgängig gemacht werden können.
Was passiert aber bei einem Skript "B" in dem Datenbankschemaänderungen gemacht werden?
Prinzipiell, kann man dann ja nicht einfach das Skript "B" von neuem Starten, sondern muss die schon gemachten Änderungen überspringen.
Kann mir da jemand Hilfestellung leisten, in irgendeiner Art und Weise?
Was mir bisher dazu einfiel ist, dass ich ja z.b. bei einem anlegen einer Tabelle vorher prüfen könnte ob sie schon existiert. Somit könnte ich dann diesen Befehl überspringen und den nächsten ausführen. Aber das hilft natürlich nur in manchen Fällen.
Ich kann ja nicht alles Testen.
Wenn ich beispielsweise Tabellen ändern möchte, kann ich ja nicht jedes einzelne Attribut und sonst was testen, ob alles durchgeführt wurde oder nicht!
Es geht hier übrigens um MS SQL Server 2000+2005 Datenbanken.
Bin für jede Hilfe dankbar!
Michael
-
Hallo!
Also mir stellt sich folgendes Problem:
Wenn ich ein Skript "A" laufen lasse und es sich um eine Transaktion handelt, ist es kein Problem, wenn es zwischendurch abbricht, da Transaktionen ja rückgängig gemacht werden können.
Was passiert aber bei einem Skript "B" in dem Datenbankschemaänderungen gemacht werden?
Prinzipiell, kann man dann ja nicht einfach das Skript "B" von neuem Starten, sondern muss die schon gemachten Änderungen überspringen.Kann mir da jemand Hilfestellung leisten, in irgendeiner Art und Weise?
[...]
Wie wäre es denn, Strukturänderungen an der DB auf ein Minimum zu reduzieren und dieses Minimum dann außerhalb der normalen Betriebszeiten der Datenbank (bzw. des DBMS) umzusetzen?
Nick
--
--------------------------------------------------
http://www.xilp.eu
XILP Internet Links People
Dein persoenliches privates Netzwerk
aus Freunden, Verwandten, Bekannten und Kollegen.
---------------------------------------------------
Hallo!
Also mir stellt sich folgendes Problem:
Wenn ich ein Skript "A" laufen lasse und es sich um eine Transaktion handelt, ist es kein Problem, wenn es zwischendurch abbricht, da Transaktionen ja rückgängig gemacht werden können.
Was passiert aber bei einem Skript "B" in dem Datenbankschemaänderungen gemacht werden?
Prinzipiell, kann man dann ja nicht einfach das Skript "B" von neuem Starten, sondern muss die schon gemachten Änderungen überspringen.Kann mir da jemand Hilfestellung leisten, in irgendeiner Art und Weise?
[...]Wie wäre es denn, Strukturänderungen an der DB auf ein Minimum zu reduzieren und dieses Minimum dann außerhalb der normalen Betriebszeiten der Datenbank (bzw. des DBMS) umzusetzen?
Nick
Also es läuft bisher so, dass die Datenbankskripte gesammelt werden und zu einem bestimmten Termin dann die Datenbank auf eine bestimmte Version gehoben werden. Zu dieser Zeit wird natürlich nicht auf der Datenbank gearbeitet. Dennoch liegen natürlich wichtige Daten in der Datenbank, die nicht verloren gehen dürfen.
Aber was genau kann man dagegen machen, wenn ein Skript dann mittendrin abbricht? Am besten wäre es, wenn ich das Skript einfach erneut einspielen würde und es mir den gewünschten Stand der Datenbank herstellt. Aber wie schon erwähnt, wird ein Teil des Skriptes ja dann doppelt ausgeführt.
Dahingehend benötige ich dringend eine Lösung.
Ich meine prinzipiell könnte man sagen, der Datenbankadministrator, der die Skripte einspielt, muss dann halt schauen, dass er die Datenbank entsprechend wieder anpasst, aber ich suche halt nach Möglichkeiten die es evtl. ermöglichen diesen manuellen Schritt zu umgehen. Sodass man abgebrochene Skripte einfach erneut einspielen kann und danach den korrekten Stand der Datenbank erreicht.
-
-
Hallo,
also wogegen möchtest du dich genau schützen?
Vor jeder Schema-Änderung kannst du ein Backup der Datenbank machen und ggf im Problemfall wieder herstellen.
Du könntest ALTER Scripts verwenden um bestehende Objekte zu ändern.*
Für DDL-Scripts wie z.b. CREATE TABLE / VIEW / PROCEDURE haben wir hier Templates im Einsatz (MS SQL 2000 & 2005), die vor dem Erstellen des Objektes auf dessen existenz prüfen und ggf das existierende löschen. Wir brauchen mittels Search & Replace dann nur noch den Objektnamen, das Schema und natürlich den Body (Prozedur-Code, Tabellendefinition) einfügen.
Mit einem geeigneten Tool** kannst du dann auch aus den verwalteten Scripts eine völlig neue Datenbank quasi "from scratch" aufbauen und gegen eine existierende Datenbank vergleichen. Und dann ggf Änderungen übertragen in Form von ALTER scripts.
* das macht u.U. eine Datenmigration notwendig
** DBGhost kann das für MS SQL 2000 sehr gut, ist aber nicht kompatibel zu MS SQL 2005
Grüsse
Frank-
Hallo,
also wogegen möchtest du dich genau schützen?
Vor jeder Schema-Änderung kannst du ein Backup der Datenbank machen und ggf im Problemfall wieder herstellen.
Du könntest ALTER Scripts verwenden um bestehende Objekte zu ändern.*
Für DDL-Scripts wie z.b. CREATE TABLE / VIEW / PROCEDURE haben wir hier Templates im Einsatz (MS SQL 2000 & 2005), die vor dem Erstellen des Objektes auf dessen existenz prüfen und ggf das existierende löschen. Wir brauchen mittels Search & Replace dann nur noch den Objektnamen, das Schema und natürlich den Body (Prozedur-Code, Tabellendefinition) einfügen.
Mit einem geeigneten Tool** kannst du dann auch aus den verwalteten Scripts eine völlig neue Datenbank quasi "from scratch" aufbauen und gegen eine existierende Datenbank vergleichen. Und dann ggf Änderungen übertragen in Form von ALTER scripts.
* das macht u.U. eine Datenmigration notwendig
** DBGhost kann das für MS SQL 2000 sehr gut, ist aber nicht kompatibel zu MS SQL 2005
Grüsse
FrankIch möchte mich dagegen schützen, dass wenn ich ein Skript in die Datenbank einspiele, und es zum Abbruch des Skriptes kommt (aus welchem Grund auch immer), dass dann nur die Hälfte des Skriptes ausgeführt wurde.
Ich bin dabei ein Tool zu entwickeln, welches Skripte sammelt und diese dann automatisch ausführt. Sprich ich habe 10 Skripte um von Version 1.4 auf eine Version 1.5 zu migrieren. Bricht er nach dem 5. Skript ab, kann ich einfach neu starten und mit dem 6. Skript weitermachen. Ist ja kein Problem.
Was kann ich aber machen, wenn 6 bereits gestartet wurde und gewisse Teile ausgeführt wurden?
Klar, könnte man sagen in solch einem Fall muss der Datenbankadministrator (DBA) den Fehler beheben, aber ich suche halt nach Möglichkeiten, die dem DBA die Arbeit erleichern oder ggbf sogar ganz abnehmen. Klar, bei Skripten die einfach eine neue Tabelle erstellen, ist es kein Problem. Wenn die Tabelle existiert, wird sie einfach gelöscht und neu generiert. Aber bei komplexeren Änderungen ist das nicht so leicht möglich.Vor jeder Änderung (also vor jedem Skript) ein komplettes Backup der Datenbank zu erstellen, ist das nicht ein wenig viel Arbeit? Wieviel Aufwand ist sowas?
Die Daten werden natürlich immer an das neue Schema angepasst!!!
btw.: DB Ghost unterstützt doch SQL Server 2000 und SQL Server 2005 oder nicht?
-
Hallo,
bitte kein TOFU und auch kein TUFO ;) (Betrifft das Zitieren)
DBGhost kann recht gut mit MS SQL 2000 ... Aber es scheitert kläglich an jeder neuen Funktion (Schemas, neue Objekttypen, .Net-Sachen sowieso) von MS SQL 2005. Ausserdem vergisst es einfach Fehler bei Problemen mit Linked Servers (z.b. nicht existierende objekte via linked server).
Packe jede einzelne (atomare) Änderung am Schema generell in ein eigenes Script, dann bist du das Problem los, dass Teile von Script X bereits ausgeführt und andere nicht ausgeführt sind.
Packe DML für die allfällige Datenmigration in eine Explizite Transaktion.
Ansonsten kann man auch folgenden Weg gehen:
(1) Baue eine neue DB from-scratch erstmal nur mit Tabelle aus deinen Scripts (zb. mit DBGhost)
(2) DML-migriere die Daten aus der bestehenden alten DB in die neue -> Script(s) in Transaktion
(3) füge Constraints in die neue DB ein (zb. mit DBGhost)
(4) füge weitere Objekte wie SPs, Views hinzu (zb. mit DBGhost)BTW: Backups und Restore kann man auch scripten :)
Cheers, Frank
-
-
-
Schemaänderungen per Script (das irgendwann irgendwie ausgeführt wird, vielleicht sogar routinegemäss) halte ich für keine gute Idee.
-
Schemaänderungen per Script (das irgendwann irgendwie ausgeführt wird, vielleicht sogar routinegemäss) halte ich für keine gute Idee.
Die Skripte werden sorgfältig entwickelt und gesammelt und dann zu einem bestimmten Termin von einem Datenbankadministrator in die Datenbank eingespielt. Also das läuft bisher so, soll aber aufgrund der Arbeit, jedes einzelne Skript manuell einzuspielen, weitestgehend automatisiert werden. Der Datenbankadministrator bedient dann nur noch das Tool und kann dann einfach per mausklick eine Datenbank auf eine neue Version heben.
Ich entwerfe gerade ein Tool, was dieses einspielen automatisieren soll. Und deswegen benötige ich halt eine Lösung, welche es ermöglicht bei Abbruch eines Skriptes im besten Falle selbsständig, das Skript dennoch zu Ende zu führen.
Die komplexeste Variante wäre natürlich vor jedem Skript eine komplettes Backup der Datenbank zu machen und bei einem Fehler dieses Backup wiederherzustellen und das Skript erneut auszuführen. Ist aber sehr aufwändig.
-