12
Migration Oracle 7 auf Oracle 8i
Nach Migration unserer steinzeitalterlichen Oracle 7 Datenbank nach Oracle 8i kann ich keine selects mehr auf die syscolumns machen -> diverse Anwendung verlangen danach und können nicht getartet werden.
Hallo Freaks,
ich habs mich endlich getraut und auf einem Testsystem versucht unsere alte Oracle 7 Datenbank auf Oracle8i upzugraden.
Mit Hilfe des Migrationsassistenten hat die konvertierung eigentlich reibungslos funktioniert.
Das Problem jedoch ist, dass die SYSCOLUMNS nicht zu selecten sind.
Ich verstehe nicht woran das liegen kann?
Ist da bei der Migration was falsch gelaufen?
Die Datenbank war ordnungsgemäß heruntergefahren und sämtl. Dienste gestoppt.
Angeneldet war ich als SYSDBA bei der Migration.
Das Endprotokoll nach der Migration war auch ehlerfrei.
Hab ich was wichtiges vergessen? Oder habt Ihr Tips woran der Fehler liegen kann?
Ich habe selbstverständlich Backups der alten Datenbank und probiere nun schon seit Tagen immer und immer wieder.
Eine Hilfe währe echt super.
Das ist der select über die Oracle7 Datenbank:
Das ist der select über die Oracle8i Datenbank:
Hallo Freaks,
ich habs mich endlich getraut und auf einem Testsystem versucht unsere alte Oracle 7 Datenbank auf Oracle8i upzugraden.
Mit Hilfe des Migrationsassistenten hat die konvertierung eigentlich reibungslos funktioniert.
Das Problem jedoch ist, dass die SYSCOLUMNS nicht zu selecten sind.
Ich verstehe nicht woran das liegen kann?
Ist da bei der Migration was falsch gelaufen?
Die Datenbank war ordnungsgemäß heruntergefahren und sämtl. Dienste gestoppt.
Angeneldet war ich als SYSDBA bei der Migration.
Das Endprotokoll nach der Migration war auch ehlerfrei.
Hab ich was wichtiges vergessen? Oder habt Ihr Tips woran der Fehler liegen kann?
Ich habe selbstverständlich Backups der alten Datenbank und probiere nun schon seit Tagen immer und immer wieder.
Eine Hilfe währe echt super.
Das ist der select über die Oracle7 Datenbank:
Das ist der select über die Oracle8i Datenbank:
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 92313
Url: https://administrator.de/contentid/92313
Ausgedruckt am: 23.11.2024 um 07:11 Uhr
12 Kommentare
Neuester Kommentar
Moin enno1980,
Hey, bevor Du irgend etwas anderes anfängst:
Bestell mal Deine Anwendungs-ZusammenschroterInnen zu einem Termin ein.
Dann fragst Du die, wer denn diese tolle Idee umgesetzt hat.
Und haust ihm/ihr die Finger platt.
Die Tabellenspalten kannst Du z.B. abfragen mit
Grüße
Biber
... der auch einen Baseballschläger-Verleih erfolgreich betreibt...
kann ich keine selects mehr auf die syscolumns machen -> diverse Anwendung verlangen danach und können nicht getartet werden.
Hey, bevor Du irgend etwas anderes anfängst:
Bestell mal Deine Anwendungs-ZusammenschroterInnen zu einem Termin ein.
Dann fragst Du die, wer denn diese tolle Idee umgesetzt hat.
Und haust ihm/ihr die Finger platt.
Die Tabellenspalten kannst Du z.B. abfragen mit
SELECT * from USER_TAB_COLUMNS" Grüße
Biber
... der auch einen Baseballschläger-Verleih erfolgreich betreibt...
Hallo Biber,
ja da kannst du ja recht haben.
Aber das Problem ist ganz einfach, dass ich versuchen möchte die Datenbank unseres System ohne die Hilfe unserer Dienstleister zu migrieren.
Wer diese Idee hatte keine Ahnung.
Jedenfalls habe ich schon so einige Datenbanken von 7 auf 8 und dannach dann im großen Sprung auf die 10 geschaukelt und so gut wie keine Probleme gehabt.
Nichts desto trotz brauche ich ne Lösung was soll denn da bei der Umstellung falsch gelaufen sein?
Vielleicht haben die den Fallstrick auch mit Absicht eingebaut, so dass kein anderer als unser Dienstleister dieses Vorhaben durchziehen kann.
ja da kannst du ja recht haben.
Aber das Problem ist ganz einfach, dass ich versuchen möchte die Datenbank unseres System ohne die Hilfe unserer Dienstleister zu migrieren.
Wer diese Idee hatte keine Ahnung.
Jedenfalls habe ich schon so einige Datenbanken von 7 auf 8 und dannach dann im großen Sprung auf die 10 geschaukelt und so gut wie keine Probleme gehabt.
Nichts desto trotz brauche ich ne Lösung was soll denn da bei der Umstellung falsch gelaufen sein?
Vielleicht haben die den Fallstrick auch mit Absicht eingebaut, so dass kein anderer als unser Dienstleister dieses Vorhaben durchziehen kann.
Wie Biber schon sagt,
Du wirst um die Anwendungsersteller nicht drum rum kommen.
Wir haben InforNT auf einer Oracle 7 Datenbank am laufen.
Ich hab wirklich lange gesucht und bin immer wieder darauf gestoßen das wir dann auch Infor austauschen müssten.
Du wirst um die Anwendungsersteller nicht drum rum kommen.
Wir haben InforNT auf einer Oracle 7 Datenbank am laufen.
Ich hab wirklich lange gesucht und bin immer wieder darauf gestoßen das wir dann auch Infor austauschen müssten.
Moin enno1980,
rein theoretisch hast Du als DBA natürlich auch die Möglichkeit, den Jungs und Mädels einen VIEW so_syscolumns genau in dieser Form zusammenzubraten, wie die ihn in der Oracle 7er-Version vorgefunden hatten.
Ist denen/der Appz doch egal, ob Oracle den mitgeliefert hat oder Du den bereitstellst.
Dann bleibt alles friedlich und keiner merkt, dass die dort absolut unmigrierbare Shice zusammengeschrotet haben.
Also->in Oracle7 das DDL-Skript der so_syscolums rauskramen, in Oracle-Neuzeit-Version diesen View sinngemäß anlegen, SELECT-Rechte granten und gut.
Auf das Finger-Platthauen würde ich dennoch auf keinen Fall verzichten wollen.
Grüße
Biber
rein theoretisch hast Du als DBA natürlich auch die Möglichkeit, den Jungs und Mädels einen VIEW so_syscolumns genau in dieser Form zusammenzubraten, wie die ihn in der Oracle 7er-Version vorgefunden hatten.
Ist denen/der Appz doch egal, ob Oracle den mitgeliefert hat oder Du den bereitstellst.
Dann bleibt alles friedlich und keiner merkt, dass die dort absolut unmigrierbare Shice zusammengeschrotet haben.
Also->in Oracle7 das DDL-Skript der so_syscolums rauskramen, in Oracle-Neuzeit-Version diesen View sinngemäß anlegen, SELECT-Rechte granten und gut.
Auf das Finger-Platthauen würde ich dennoch auf keinen Fall verzichten wollen.
Grüße
Biber
Hi Biber,
also danke erstmal, dass du mir versuchst zu helfen.
Allerdings das mit dem DDL-Skript und dem granten hab ich jetzt peinlicherweise nicht verstanden.
Kann ich das nicht irgendwie aus der noch voll aktiven Echtdatenbak exportieren bzw. auslesen und dann in die migrierte Oracle 8i Datenbank importieren bzw. einlesen?
Denn so teif in der Materie von Oracle bin ich jetzt dann doch wieder nicht.
Hatte bis dato auch noch nie so ein rießiges Problem.
also danke erstmal, dass du mir versuchst zu helfen.
Allerdings das mit dem DDL-Skript und dem granten hab ich jetzt peinlicherweise nicht verstanden.
Kann ich das nicht irgendwie aus der noch voll aktiven Echtdatenbak exportieren bzw. auslesen und dann in die migrierte Oracle 8i Datenbank importieren bzw. einlesen?
Denn so teif in der Materie von Oracle bin ich jetzt dann doch wieder nicht.
Hatte bis dato auch noch nie so ein rießiges Problem.
Moin enno1980,
ich versteh nicht ganz, was Du erhoffst...
Ein View namens "so_syscolumns" in der Oracle-Welt ist mir nicht geläufig.
Hört sich für mich eher danach an, als hätte ein anderer Datenbank-Frickler, der aus der M$-Datenbank-Welt kam für sich (bzw. für einen Query/Reportgenerator) eben mal ein Äquivalent zum M$-syscolumns-View zusammengeharkt.
Bedeutet, unter diesem "so_syscolumns"-View (das "so_" ist garantiert selbst ausgedacht und soll bedeuten "System-Objekte") liegen die Oracle-Tabellen/Views xxx_TAB_COLS bzw xxx_TAB_COLUMNS.
Wenn dieser View nicht migriert wurde, dann kann es an 57899 verschiedenen Ursachen liegen - die Zugriffe auf die darunterliegenden Views funktionieren nicht wegen anderer namen, fehlender Rechte, nicht gesetzter Aliase oder Synonyme...
Also musst Du doch erst mal schauen in Oracle 7:
Wieso meinst Du denn, dass es Deine Aufgabe ist, eine Appz zu migrieren?
Du als angehender Oracle-DBA musst die Datenbank migrieren.
Und davon alles, was dokumentiert ist.
Unbekannte Tabellen/Views oder Procedures/Packages ohne Owner und erkennbaren Zweck- die sollst Du bestimmt nicht migrieren.
Was sind denn das für ominöse Appz?
Und aufgrund welcher Qualifikation haben diese "Entwickler" geglaubt, Applikationen zusammenharken zu dürfen?
Grüße
Biber
ich versteh nicht ganz, was Du erhoffst...
Migration unserer steinzeitalterlichen Oracle 7 Datenbank nach Oracle 8i kann ich keine selects mehr auf die syscolumns machen
diverse Anwendung verlangen danach und können nicht getartet werden.
diverse Anwendung verlangen danach und können nicht getartet werden.
Ein View namens "so_syscolumns" in der Oracle-Welt ist mir nicht geläufig.
Hört sich für mich eher danach an, als hätte ein anderer Datenbank-Frickler, der aus der M$-Datenbank-Welt kam für sich (bzw. für einen Query/Reportgenerator) eben mal ein Äquivalent zum M$-syscolumns-View zusammengeharkt.
Bedeutet, unter diesem "so_syscolumns"-View (das "so_" ist garantiert selbst ausgedacht und soll bedeuten "System-Objekte") liegen die Oracle-Tabellen/Views xxx_TAB_COLS bzw xxx_TAB_COLUMNS.
Wenn dieser View nicht migriert wurde, dann kann es an 57899 verschiedenen Ursachen liegen - die Zugriffe auf die darunterliegenden Views funktionieren nicht wegen anderer namen, fehlender Rechte, nicht gesetzter Aliase oder Synonyme...
Also musst Du doch erst mal schauen in Oracle 7:
- Wo liegt dieser VIEW?
- wem gehört er (Owner, Schema)?
- wie wird er angelegt -> die DDL ist der Text mit dem "CREATE VIEW AS...")
- welche Oracle-Systemtabellen liegen drunter?
- und vor allem what the ### bloody ### wird mit diesem VIEW in einer produktiven Appz gemacht???
- und wer hat das zu verantworten?
Wieso meinst Du denn, dass es Deine Aufgabe ist, eine Appz zu migrieren?
Du als angehender Oracle-DBA musst die Datenbank migrieren.
Und davon alles, was dokumentiert ist.
Unbekannte Tabellen/Views oder Procedures/Packages ohne Owner und erkennbaren Zweck- die sollst Du bestimmt nicht migrieren.
Was sind denn das für ominöse Appz?
Und aufgrund welcher Qualifikation haben diese "Entwickler" geglaubt, Applikationen zusammenharken zu dürfen?
Grüße
Biber
Hallo nochmal,
ja ich weiß, dass es den view so_syscolumns nicht gibt.
Das kürzel "SO" kann ich mir nur so erklären, als dass dies wohl möglich ein eigenkonstrukt unserer WAWI-Anbieter ist.
Denn das Programmierhaus usneres Warenwirtschaftssystems nennt isch "SO Businesssoftware ..."
Aber hab trotzdem vielen Dank auch wenn ich nun nicht wirklich weitergekommen bin uns wohl doch die mehreren tausend EURONEN in die Hand nehmen muss um das Oracle-Update zu vollziehen.
Schade.
Denn ich bin mir ziemlich sicher, dass unser Anbieter nicht so ohne weiteres mit der Sprache rausrückt.
Erschwerend hinzu kommt dann sicherlich, dass er dann die Wartung usneres WaWi nicht mehr durchführen würde, wenn er wüßte, dass ich die Datenbank selber aufrüste.
ja ich weiß, dass es den view so_syscolumns nicht gibt.
Das kürzel "SO" kann ich mir nur so erklären, als dass dies wohl möglich ein eigenkonstrukt unserer WAWI-Anbieter ist.
Denn das Programmierhaus usneres Warenwirtschaftssystems nennt isch "SO Businesssoftware ..."
Aber hab trotzdem vielen Dank auch wenn ich nun nicht wirklich weitergekommen bin uns wohl doch die mehreren tausend EURONEN in die Hand nehmen muss um das Oracle-Update zu vollziehen.
Schade.
Denn ich bin mir ziemlich sicher, dass unser Anbieter nicht so ohne weiteres mit der Sprache rausrückt.
Erschwerend hinzu kommt dann sicherlich, dass er dann die Wartung usneres WaWi nicht mehr durchführen würde, wenn er wüßte, dass ich die Datenbank selber aufrüste.
Moin enno1980,
Hey, nicht dass ich die heutige Jugend für zu verweichlicht halten würde, aber..
Vielleicht liest Du noch mal meine Kommentare oben.
Es gibt zwei grundsätzliche Varianten:
Haben die aber nicht behauptet. Oracle 7.x wird seit 6 Jahren nicht mehr supportet.
Aber is' auch wurscht: es hat überhaupt nichts mit Migration zu tun:
Deren Appz braucht an irgendeiner Ecke einen View, der halt von denen unter "Systemvoraussetzungen" nicht aufgeführt wurde.
Ergo: leih Dir einen Baseballschläger, fahr zu denen ins Büro, gehe an der Empfangspraktikantin straigth vorbei zum Oberfrickler, schliess die Tür hinter Dir ab, lass die Jalousien runter und frag ihn mal, ob er kurz Zeit für Dich hat.
---> Lies auf jeden Fall vorher die Verträge mit denen.
Ein automatisches Geld-in-den-Rachen-Werfen-Müssen sehe ich nicht als gegeben an.
Grüße
Biber
auch wenn ich nun nicht wirklich weitergekommen bin uns wohl doch die mehreren tausend EURONEN in die Hand nehmen muss um das Oracle-Update zu vollziehen.
Denn ich bin mir ziemlich sicher, dass unser Anbieter nicht so ohne weiteres mit der Sprache rausrückt.
Denn ich bin mir ziemlich sicher, dass unser Anbieter nicht so ohne weiteres mit der Sprache rausrückt.
Hey, nicht dass ich die heutige Jugend für zu verweichlicht halten würde, aber..
Vielleicht liest Du noch mal meine Kommentare oben.
Es gibt zwei grundsätzliche Varianten:
- entweder die SO-Heinzis haben in ihrem Vertrag mit Euch schriftlich
Haben die aber nicht behauptet. Oracle 7.x wird seit 6 Jahren nicht mehr supportet.
Aber is' auch wurscht: es hat überhaupt nichts mit Migration zu tun:
Deren Appz braucht an irgendeiner Ecke einen View, der halt von denen unter "Systemvoraussetzungen" nicht aufgeführt wurde.
Ergo: leih Dir einen Baseballschläger, fahr zu denen ins Büro, gehe an der Empfangspraktikantin straigth vorbei zum Oberfrickler, schliess die Tür hinter Dir ab, lass die Jalousien runter und frag ihn mal, ob er kurz Zeit für Dich hat.
---> Lies auf jeden Fall vorher die Verträge mit denen.
Ein automatisches Geld-in-den-Rachen-Werfen-Müssen sehe ich nicht als gegeben an.
Grüße
Biber
Hallo nochmal,
ich habe jetzt unseren Programmierer mal angeschrieben, dass er uns hinter das ominöse Geheimnis des o.g. Views oder Tables führen soll.
Hier mal die Fehlermeldung, welche ich erhalte, wenn ich die Aplikation starte:
Variablen:
???: lsMakro = ???
Modul: Artikelverwaltung
Datum: 21.07.2008 17:51:59
Benutzer: SUSER
Fehler: 942
Position: 47
Fehlertext: SQL-Fehler 942 an Position 47
ORA-00942: Tabelle oder View nicht vorhanden
Letztes registriertes SQL-Kommando:
SELECT length
INTO :nArtNrLength
FROM so_syscolumns
WHERE tbname='ARTIKEL' AND name = 'ARTNR1'
Text an Fehlerposition:
... so_syscolumns
WHERE tbname ...
Variablen:
Number: nArtNrLength =
ich habe jetzt unseren Programmierer mal angeschrieben, dass er uns hinter das ominöse Geheimnis des o.g. Views oder Tables führen soll.
Hier mal die Fehlermeldung, welche ich erhalte, wenn ich die Aplikation starte:
Variablen:
???: lsMakro = ???
Modul: Artikelverwaltung
Datum: 21.07.2008 17:51:59
Benutzer: SUSER
Fehler: 942
Position: 47
Fehlertext: SQL-Fehler 942 an Position 47
ORA-00942: Tabelle oder View nicht vorhanden
Letztes registriertes SQL-Kommando:
SELECT length
INTO :nArtNrLength
FROM so_syscolumns
WHERE tbname='ARTIKEL' AND name = 'ARTNR1'
Text an Fehlerposition:
... so_syscolumns
WHERE tbname ...
Variablen:
Number: nArtNrLength =
Moin enno1980,
ich weiss ja nicht, was der Frickler Deines Vertrauens empfielt, aber ich empfehle eine Änderung in...
Aber geht mich auch nix an...
P.S. Habe ich schon erwähnt, dass meine Haupteinnahmequelle ein florierender Baseballschlägerverleih in Bremen ist?
P.P.S. Andererseits.... du kannst doch ebensogut die Länge des Felds ARTNR1 fest verdrahten... es ist doch in dieser eingefrorenen Appz definitiv nicht variabel. Kommentiere die View-Zugriffe aus und setze :nArtNrLength auf 12 oder 15 oder wie lang es halt ist.
Grüße
Biber
ich weiss ja nicht, was der Frickler Deines Vertrauens empfielt, aber ich empfehle eine Änderung in...
SELECT DATA_LENGTH INTO :nArtNrLength
FROM USER_TAB_COLUMNS
WHERE table_name='ARTIKEL' AND Column_name = 'ARTNR1' Aber geht mich auch nix an...
P.S. Habe ich schon erwähnt, dass meine Haupteinnahmequelle ein florierender Baseballschlägerverleih in Bremen ist?
P.P.S. Andererseits.... du kannst doch ebensogut die Länge des Felds ARTNR1 fest verdrahten... es ist doch in dieser eingefrorenen Appz definitiv nicht variabel. Kommentiere die View-Zugriffe aus und setze :nArtNrLength auf 12 oder 15 oder wie lang es halt ist.
Grüße
Biber
Hey Biber,
ich glaube ich bin dir zu Dank verpflichtet.
Ich habe doch rotzfrech unseren DB Frickler angeschrieben und ihm den Sachverhalt erklärt und was war die Antwort:
"Die Objekte vom SYS-User wurden nicht übernommen. Per Mail erhalten Sie eine Datei mit den für SO notwendigen Views/Synonymen. Die Befehle müssen in SQLPlus als SYSDBA ausgeführt werden."
Und da hab ich doch glatt die SQL-Scripts bekommen, eingelesen und siehe da....ES GEHT...LUFTSPRUNG FREU
ich glaube ich bin dir zu Dank verpflichtet.
Ich habe doch rotzfrech unseren DB Frickler angeschrieben und ihm den Sachverhalt erklärt und was war die Antwort:
"Die Objekte vom SYS-User wurden nicht übernommen. Per Mail erhalten Sie eine Datei mit den für SO notwendigen Views/Synonymen. Die Befehle müssen in SQLPlus als SYSDBA ausgeführt werden."
Und da hab ich doch glatt die SQL-Scripts bekommen, eingelesen und siehe da....ES GEHT...LUFTSPRUNG FREU
Moin enno1980,
ich sag doch: Wenn man/frau mit den Leuten vernünftig redet, dann klappt das auch....
Schreib ihm ein nettes Danke-Mail mit der kleinen Insider-Spitze:
"... trotz alledem vielen Dank für Ihre schnelle und kompetente Unterstützung.
Um künftig derartige Migrationsprobleme zu vermeiden, habe ich Ihre Nachdokumentation einfach mit in den Schnellhefter an die restliche SO--Applikations-Dokumentation gelegt.
Die drei unnötigen Recherche-Manntage werde ich gegenüber meinem Chef als "Hardware-Probleme" abrechnen. Sie brauchen sich also keine Sorgen um etwaige Regressforderungen machen.
Sollten noch weitere interne Dokumentationen zu der von uns gekauften Software existieren, bitte ich um zeitnahe Zusendung, da diese uns bei der Raumausstattung in unserem Pilotprojekt 'Qualtätssicherung Frickelsoftware' als ständige Mahnung dienlich sein können."
Grüße
Biber
ich sag doch: Wenn man/frau mit den Leuten vernünftig redet, dann klappt das auch....
Schreib ihm ein nettes Danke-Mail mit der kleinen Insider-Spitze:
"... trotz alledem vielen Dank für Ihre schnelle und kompetente Unterstützung.
Um künftig derartige Migrationsprobleme zu vermeiden, habe ich Ihre Nachdokumentation einfach mit in den Schnellhefter an die restliche SO--Applikations-Dokumentation gelegt.
Die drei unnötigen Recherche-Manntage werde ich gegenüber meinem Chef als "Hardware-Probleme" abrechnen. Sie brauchen sich also keine Sorgen um etwaige Regressforderungen machen.
Sollten noch weitere interne Dokumentationen zu der von uns gekauften Software existieren, bitte ich um zeitnahe Zusendung, da diese uns bei der Raumausstattung in unserem Pilotprojekt 'Qualtätssicherung Frickelsoftware' als ständige Mahnung dienlich sein können."
Grüße
Biber
