View Full Version : Journaling für alle Tabellen eines Schemas einschalten
Hallo zusammen,
ich bin ein AS/400 newbie und in einem AS/400-DB2 Projekt. Sehe die AS/400 also eher von der DB2/SQL-Schiene. Wir hatten jetzt folgendes Problem. Wir hatten ein Schema a mit Tabellen und den ganzen Schnickschnack. Dieses sollte von der Administration in das Schema b umkopiert werden. (Mit allen Rechten etc.)
1. Rechte Objektrechte stimmen danach natürlich nicht, wie erwartet.-> Haben wir jetzt mühsam umsetzen lassen.
2.) Schlimmer ist, wir müssen das Journaling für jede Tabelle einzeln im iseries-Navigator setzen.
-> Gibt es keine andere Möglichkeit alle Tabellen eines Schemas auf Journaling zu setzen?:confused:
Kann ich ja kaum glauben.
Hinsweis: unser Schema hat ca. 300 Tabellen.
Gruss
Remo2010
Hallo,
normalerweise hat man ein (oder mehrere) Erstellungsskripte für eine SQL Datenbank inklusive der Erstellung des Schemas und wenn ich sowas mehrfach (mit neuem Schema Namen ) rattern lassen, dann brauche ich nix zu machen. Wenn ich mir den Kram natürlich mit dem Mäusekino zusammen knipse, dann darf ich mich zumindest bei Ooops Nerv nicht zu wundern, wenn dann nix passt. Wenn nun das Kind bereits im Brunnen sitzt, dann muss man da halt durch.
Auf der grünen Seite kann man immer noch WRKOBJPDM MYSCHEMA *ALL *FILE OBJATR('PF-DTA') machen und dann mit einer PDM User Option und F13 Journaling starten, oder halt ein kleines CL schreiben.
mfg
Dieter Bender
Hallo zusammen,
ich bin ein AS/400 newbie und in einem AS/400-DB2 Projekt. Sehe die AS/400 also eher von der DB2/SQL-Schiene. Wir hatten jetzt folgendes Problem. Wir hatten ein Schema a mit Tabellen und den ganzen Schnickschnack. Dieses sollte von der Administration in das Schema b umkopiert werden. (Mit allen Rechten etc.)
1. Rechte Objektrechte stimmen danach natürlich nicht, wie erwartet.-> Haben wir jetzt mühsam umsetzen lassen.
2.) Schlimmer ist, wir müssen das Journaling für jede Tabelle einzeln im iseries-Navigator setzen.
-> Gibt es keine andere Möglichkeit alle Tabellen eines Schemas auf Journaling zu setzen?:confused:
Kann ich ja kaum glauben.
Hinsweis: unser Schema hat ca. 300 Tabellen.
Gruss
Remo2010
Hallo Dieter,
vielen Dank, werde ich mal ausprobieren lassen.
Klar haben wir Skripte für unsere Datenbank (ERWIN :-) ) aber wir haben in der umzukopierenden Datenbank schon Daten drin und fahren vom Fachbereich Tests. Da wir aber weiterentwickeln wollen mußten wir eine Abbild inkl. der Daten aus der Datenbank haben, weil wir die Testdaten noch benötigen.
Vielen Dank
Thorsten (Remo)
Hallo,
überzeugt mich nur zum Teil, das hinterher nötige kopieren der Daten kann ebenfalls mit einem SQL Script erfolgen. Das Problem ist ja meist, dass bei allen Frickel Aktionen, sei es mit Mäusekino oder mit Save Restore, oder CPYF, CRTDUPOBJ etc. dann irgendwas übersehen wird; sowas hat man zwar schnell angefangen, aber bis es dann wirklich fertig ist, hätte man es auch ordentlich machen können. Und spätestens, wenn man das zweimal machen muss, dann hat die automatisierte Variante Vorteile und aus der SQL Perspektive sind das dann SQL Scripte.
mfg
Dieter Bender,
der durchaus weiß, dass das auch mit AS400 spezifischen Bordmitteln geht
Hallo Dieter,
vielen Dank, werde ich mal ausprobieren lassen.
Klar haben wir Skripte für unsere Datenbank (ERWIN :-) ) aber wir haben in der umzukopierenden Datenbank schon Daten drin und fahren vom Fachbereich Tests. Da wir aber weiterentwickeln wollen mußten wir eine Abbild inkl. der Daten aus der Datenbank haben, weil wir die Testdaten noch benötigen.
Vielen Dank
Thorsten (Remo)
Hallo,
ja bin ich eigentlich auch dafür, nur
da unsere ganze DB natürlich über RI's/Constraints verfügt ist das mit dem Daten exp./import nicht so einfach. Oder gibt es wie bei Oracle eine Möglichkeit alle RI/Constraints abzuschalten.
Dann würden wir nämlich das Schema per Skript aufbauen, aus dem alten die Daten exportieren, in dem neuen die RI/Constraints abschalten und die Daten wieder importieren.
Leider habe ich keine Möglichkeit gefunden diese abzuschalten.
Gruss
Thorsten (Remo)
Hallo,
das geht, allerdings von der native Oberfläche, mit CHGPFCST, da kann man die auf disabled und enabled setzen, wenn man das in einem SQL script einbauen will, dann kann man das via stored procedure machen, die (parametrisiert) diesen Command bedient.
Von Maschine zu Maschine geht auch SAVLIB und RSTLIB, der da alles mitnimmt und macht und tut, was aber zum duplizieren nicht geeignet ist, wg. Einschränkungen beim rename des Schemas.
mfg
Dieter Bender
Hallo,
ja bin ich eigentlich auch dafür, nur
da unsere ganze DB natürlich über RI's/Constraints verfügt ist das mit dem Daten exp./import nicht so einfach. Oder gibt es wie bei Oracle eine Möglichkeit alle RI/Constraints abzuschalten.
Dann würden wir nämlich das Schema per Skript aufbauen, aus dem alten die Daten exportieren, in dem neuen die RI/Constraints abschalten und die Daten wieder importieren.
Leider habe ich keine Möglichkeit gefunden diese abzuschalten.
Gruss
Thorsten (Remo)
Hallo,
vielleicht stehe ich ja auf dem Schlauch aber:
Wenn ich mittels Reverse Engeneering mit die SQL-Skripte aus meiner ursprünglichen Bibliothek erstelle, werden für die Constraints separate ALTER Table Statements generiert.
Was spricht also dagegen, Skripte für die Tabellen erstellen zu lassen, die Create Table Statements ausführen. Dann die Daten kopieren.
Und zum Schluss die Skripte mit den Alter Table Statements für die Constraints ausführen.
Übrigens kann man über den iSeries Navigator (zumindest unter V5R4) Constraits en bloque Enabeln oder Disabeln.
Schema --> Constraints --> Constraints markieren --> Rechtsclick und Enable/Disable.
Hallo,
dazu brauche ich den Ooops Nerv nicht, das wäre gegenüber Erwin ein Rückschritt, der generiert die Skripte aus dem Datenmodell, auch da kann ich die Constraints per alter table entfernen und zufügen; was aber den enable, disable von Constraints nicht überflüssig macht. Beim additiven hinzufügen hat der drop constraint zur Folge, dass der Zugriffspfad völlig neu erstellt werden muss und beim disable nur additiv.
Zur Automatisierung bringt mir das Mäusekino nix, oder willst du ein Tastatur Makro auf den Ooops Nerv loslassen?
mfg
Dieter Bender
Hallo,
vielleicht stehe ich ja auf dem Schlauch aber:
Wenn ich mittels Reverse Engeneering mit die SQL-Skripte aus meiner ursprünglichen Bibliothek erstelle, werden für die Constraints separate ALTER Table Statements generiert.
Was spricht also dagegen, Skripte für die Tabellen erstellen zu lassen, die Create Table Statements ausführen. Dann die Daten kopieren.
Und zum Schluss die Skripte mit den Alter Table Statements für die Constraints ausführen.
Übrigens kann man über den iSeries Navigator (zumindest unter V5R4) Constraits en bloque Enabeln oder Disabeln.
Schema --> Constraints --> Constraints markieren --> Rechtsclick und Enable/Disable.