(etwas off-topic, aber dringend) Oracle: Versehentlich Datei gelöscht (Rollback-Segment) - was nun?

[Stefan Bion]

Hi Cracks,

bin wahrscheinlich nicht der Einzige, der am Neujahrstag arbeiten muß. Y2K-mäßig ist auch alles ok; gut, dachte ich mir, dann optimiere ich noch ein bißchen die Datenbank, d.h. lege das Rollback-Segment neu an. Nur leider habe ich die dazugehörigen Dateien auf Unix-Ebene gelöscht, als das Segment noch online war - shit! Jetzt kriege ich die DB nicht mehr hoch, und die Oracle-Hotline ist heute nicht erreichbar (Murphy...). Ok, dachte ich, sichere ich die zum Rollback-Tablescape gehörenden Dateien vom Band zurück. Kein Problem, außer daß diese Dateien offensichtlich einen älteren Stand haben als die übrigen Datenbankdateien, und deshalb bekomme ich die Datenbank zwar gemounted, aber nicht geöffnet. Um das Rollbacksegment ordnungsgemäß zu löschen, muß die DB aber geöffnet sein - irgendwie beißt sich da die Katze in den Schwanz...

Kurz und gut - weiß jemand zufällig, ob es eine Möglichkeit gibt, die DB *ohne* das (doch eigentlich ohnehin unwichtige) Rollbacksegment hochzukriegen? Ein Auskommentieren in der init.ora-Datei half nichts; Oracle sucht trotzdem nach der Datei bzw. meint, sie bräuchte Media Recovery. (Ich könnte zwar *alle* Dateien zurücksichern, nur würden dann einige Abschlüsse fehlen, die dann wiederholt werden müßten.)

Auf Tips hoffend,
Stefan

P.S.: Ich weiß, das ist hier off-topic, aber vielleicht kennt jemand ja auch ein ORACLE-Forum - oder eine Newsgroup?

[Michael Schröpl]

optimiere ich noch ein bißchen die Datenbank, d.h. lege das Rollback-Segment neu an.

Hast Du etwa nur *ein* Rollback-Segment?

Wenn man eine Oracle-Datenbank neu anlegt, bekommt, man ein paar kleine Rollback-Segmente mitgeliefert. Für "richtige" Anwendungen reichen die natürlich nicht, aber für ein Not-Login schon.

Also habe ist diese Segmente zwar leben lassen, mir aber zusätzlich einen eigenen Rollback-Tablespace mit zwei richtig schönen großen 100MB-Segmenten angelegt. Wenn ich an dem herumschraube, kann ich ihn mir zwar kaputt machen, aber ich ruiniere damit die Datenbank nicht komplett.

Außerdem habe ich den Source Code der Definition dieser Segmente als SQL-Skript und kann dieses mit SQL*Plus jederzeit wieder laufen lassen.

Ich darf mir halt nur nicht das *letzte* Rollback-Segment ruinieren ... sonst habe ich mich ausgesperrt.

Nur leider habe ich die dazugehörigen Dateien auf Unix-Ebene gelöscht, als das Segment noch online war - shit!

Das ist eine schöne Leistung ... unter welcher Benutzerkennung warst Du denn da unterwegs?
Meine Datenbank ist unter "oracle" installiert und andere Benutzer haben kein Schreibrecht auf dessen Dateien. (Du wirst doch nicht etwa mit "root" ... pfui Teufel!)

Jetzt kriege ich die DB nicht mehr hoch, und die Oracle-Hotline ist heute nicht erreichbar (Murphy...).

Aua, das ist aber eine schwache Leistung. Die 0130-irgendwas (aus dem Gedächnis: 5658???) hat mich bisher noch nie im Stich gelassen.
(Welche Wartungsvertragklasse hast Du denn?)

Ok, dachte ich, sichere ich die zum Rollback-Tablescape gehörenden Dateien vom Band zurück. Kein Problem, außer daß diese Dateien offensichtlich einen älteren Stand haben als die übrigen Datenbankdateien, und deshalb bekomme ich die Datenbank zwar gemounted, aber nicht geöffnet. Um das Rollbacksegment ordnungsgemäß zu löschen, muß die DB aber geöffnet sein - irgendwie beißt sich da die Katze in den Schwanz...

Eine Oracle-Datenbank kriegst Du m. E. nur am Stück zum Laufen - eine Delta-Sicherung nützt gar nichts.

Kurz und gut - weiß jemand zufällig, ob es eine Möglichkeit gibt, die DB *ohne* das (doch eigentlich ohnehin unwichtige) Rollbacksegment hochzukriegen? Ein Auskommentieren in der init.ora-Datei half nichts; Oracle sucht trotzdem nach der Datei bzw. meint, sie bräuchte Media Recovery.

Klar, weil Oracle ohne Rollback-Segmente keine Transaktion mitprotokollieren kann.

Hmmm ... man kann irgendwie bei der Durchführung einer Transaktion explizit das Transaktions-Logging abschalten. Ich habe das noch nie gemacht und hier (zuhause) auch keine Oracle-Handbücher - aber vielleicht gibt es in der "ini.ora" einen Parameter, mit dem man *das* global für alle Vorgänge abschalten kann. *Dann* wäre das Rollback-Segment möglicherweise nicht notwendig ... bedenke, daß Du dann aber mit der Rasierklinge  ohne Griff am offenen Herzen operierst!

Andere Möglichkeit: Du kannst mit "sqldba" auch ohne laufende Datenbank einiges drehen (nach "connect internal"). Damit kann man die Datenbank nicht nur hoch- und runterfahren, sondern auch Tablespaces verwalten etc.
Schau mal dessen Menü-Optionen durch - vielleicht ist auch dort der Schalter verfügbar, wie man das Transaktions-Logging komplett abschalten kann.
Wenn Du Pech hast, dann geht *das* auch nur bei laufender Datenbank - aber testen solltest Du es auf jeden Fall.

Kannst Du den Tablespace, der das Rollbacksegment enthält, mit "sqldba" auf "offline" setzen? Vielleicht startet die Datenbank dann ...

Ich erinnere mich vage, daß man in Oracle für jede Benutzerkennung einstellen kann, welches Rollback-Segment sie benutzen soll. (Irgendwie mußte ich meiner Datenbank ja beibringen, daß sie nicht den mitgelieferten "Kinderkram", sondern meine Großsegmente verwenden soll.)
Vielleicht ist also die Stelle, wo man diese Benutzer konfiguriert, diejenige, wo Du das Transaktionslogging abschalten kannst?

(Ich könnte zwar *alle* Dateien zurücksichern, nur würden dann einige Abschlüsse fehlen, die dann wiederholt werden müßten.)

Wenn Du genug Zeit hast, dann lohnt es sich, noch ein paar Stunden um die Daten zu kämpfen.

P.S.: Ich weiß, das ist hier off-topic, aber vielleicht kennt jemand ja auch ein ORACLE-Forum - oder eine Newsgroup?

Oracle ist kein sooo völlig fremdes Thema hier. (Vielleicht weiß Kess noch irgendwas, das Dir weiterhilft?)

[Kess]

Hallo Stefan und Michael,

Oracle ist kein sooo völlig fremdes Thema hier. (Vielleicht weiß Kess noch irgendwas, das Dir weiterhilft?)

nur der Vollständigkeit wegen: Hier muß ich passen.
So weit in die Interna reichen meine Kenntnisse nicht.

Ich hoffe Du bekommst es hin, Stefan.

Viele Grüße
  Kess

[Stefan Bion]

Hi Michael,

Hast Du etwa nur *ein* Rollback-Segment?

Ähm, zu dem Zeitpunkt ja - ein etwa 6 GB großes, das nur zur Durchführung bestimmter Jahresabschlüsse gebraucht wurde. Im Normalbetrieb sind es so 10-12 Segmente à 200 bis 300 MB.

Wenn man eine Oracle-Datenbank neu anlegt, bekommt, man ein paar kleine Rollback-Segmente
mitgeliefert. Für "richtige" Anwendungen reichen die natürlich nicht, aber für ein Not-Login
schon.

Also habe ist diese Segmente zwar leben lassen, mir aber zusätzlich einen eigenen
Rollback-Tablespace mit zwei richtig schönen großen 100MB-Segmenten angelegt. Wenn ich an dem
herumschraube, kann ich ihn mir zwar kaputt machen, aber ich ruiniere damit die Datenbank
nicht komplett.

Das Problem in meinem Fall war, daß die Datenfiles des Rollback-Tablespaces nach dem versehentlichen Löschen und anschließenden Zurücksichern einen anderen Stand hatten als die übrigen Files (Daten, Index, Temp., usw.). Oracle merkt sich das ja anhand dieser Log-Sequence-Numbers im Header dieser Dateien, und wenn die nicht bei allen Dateien übereinstimmen, ist für Oracle die Datenbank nicht konsistent. Ist ja im Prinzip auch richtig, nur war die Datenbank vor der Sicherung ordnungsgemäß heruntergefahren worden, alle Transaktionen abgeschlossen und das Rollback-Segment also leer - also eigentlich doch unwichtig... aber leider sieht Oracle das anders; wie gesagt bekomme ich die DB zwar gemountet, aber nicht geöffnet ("Datafile 3 '/oracle6/oradata/MEGA/mega_rbs.dbf' needs media recovery", sinngemäß).

Außerdem habe ich den Source Code der Definition dieser Segmente als SQL-Skript und kann
dieses mit SQL*Plus jederzeit wieder laufen lassen.

Würde in meinem Fall nichts nützen, denn solange die DB nicht geöffnet ist, funktioniert kein 'ALTER TABLESPACE ...' etc., um das Tabelspace zu löschen oder neu anzulegen. Die DB kann aber nur mit funktionierendem Tablespace geöffnet werden. Wie gesagt - Katze/Schwanz...

Ich darf mir halt nur nicht das *letzte* Rollback-Segment ruinieren ... sonst habe ich mich
ausgesperrt.

Ich glaub', das war wohl der Fehler; dieses vorgefertigte kleine Beispiel-RBS wurde gleich zu Anfang gelöscht - braucht ja eh keiner... ;-)

Nur leider habe ich die dazugehörigen Dateien auf Unix-Ebene gelöscht, als das Segment noch
online war - shit!

Das ist eine schöne Leistung ... unter welcher Benutzerkennung warst Du denn da unterwegs?
Meine Datenbank ist unter "oracle" installiert und andere Benutzer haben kein Schreibrecht auf
dessen Dateien. (Du wirst doch nicht etwa mit "root" ... pfui Teufel!)

Ich habe unter 'oracle' gearbeitet, direkt auf der Shell, was aber in diesem Fall wohl unrelevant ist...

Jetzt kriege ich die DB nicht mehr hoch, und die Oracle-Hotline ist heute nicht erreichbar
(Murphy...).

Aua, das ist aber eine schwache Leistung. Die 0130-irgendwas (aus dem Gedächnis: 5658???) hat
mich bisher noch nie im Stich gelassen.
(Welche Wartungsvertragklasse hast Du denn?)

Ist ein Rahmenvertrag unseres Konzerns; gilt glaub' ich nur werktags... ;-(

Eine Oracle-Datenbank kriegst Du m. E. nur am Stück zum Laufen - eine Delta-Sicherung nützt
gar nichts.

Ja, das habe ich jetzt auch gemerkt. Aber ich dachte halt, die RBS (und somit auch die Files auf der Platte) könnten ohne größere Probleme gelöscht bzw. neu angelegt werden. Normalerweise wäre das auch gegangen, wenn ich zuvor die RBS offline geschaltet und gelöscht hätte, denn dann wären die Files ja unbenutzt gewesen... Daß die Dateien unter HP-UX aber auch nicht gelockt sind, solange sie in Benutzung sind... :-(

Kurz und gut - weiß jemand zufällig, ob es eine Möglichkeit gibt, die DB *ohne* das (doch
eigentlich ohnehin unwichtige) Rollbacksegment hochzukriegen? Ein Auskommentieren in der
init.ora-Datei half nichts; Oracle sucht trotzdem nach der Datei bzw. meint, sie bräuchte
Media Recovery.

Klar, weil Oracle ohne Rollback-Segmente keine Transaktion mitprotokollieren kann.

Ich hätte ja nach dem Öffnen direkt ein RBS anlegen können... Aber wahrscheinlich braucht Oracle grundsätzlich ein RBS, denn es könnten ja noch Redo-Logs nachgefahren werden müssen...

Hmmm ... man kann irgendwie bei der Durchführung einer Transaktion explizit das
Transaktions-Logging abschalten. Ich habe das noch nie gemacht und hier (zuhause) auch keine
Oracle-Handbücher - aber vielleicht gibt es in der "ini.ora" einen Parameter, mit dem man
*das* global für alle Vorgänge abschalten kann. *Dann* wäre das Rollback-Segment
möglicherweise nicht notwendig ... bedenke, daß Du dann aber mit der Rasierklinge  ohne Griff
am offenen Herzen operierst!

Wäre ja auch nur solange, bis ein RBS angelegt ist...

Andere Möglichkeit: Du kannst mit "sqldba" auch ohne laufende Datenbank einiges drehen (nach
"connect internal"). Damit kann man die Datenbank nicht nur hoch- und runterfahren, sondern
auch Tablespaces verwalten etc.

Leider nicht; mit dem SVRMGRL kann man sich zwar noch connecten und interne Views (v$datafiles etc.) abfragen, aber dba_rollback_segs geht schon nicht mehr, und auch bei 'alter tablespace ...'-Kommandos wird der nette Hinweis ausgegeben, daß diese Operation nur bei geöffneter DB möglich ist.

Kannst Du den Tablespace, der das Rollbacksegment enthält, mit "sqldba" auf "offline" setzen?
Vielleicht startet die Datenbank dann ...

Nein, geht leider nicht (s.o.).

Ich erinnere mich vage, daß man in Oracle für jede Benutzerkennung einstellen kann, welches
Rollback-Segment sie benutzen soll. (Irgendwie mußte ich meiner Datenbank ja beibringen, daß
sie nicht den mitgelieferten "Kinderkram", sondern meine Großsegmente verwenden soll.)
Vielleicht ist also die Stelle, wo man diese Benutzer konfiguriert, diejenige, wo Du das
Transaktionslogging abschalten kannst?

Soweit ich weiß, geht das auch nur bei geöffneter Datenbank.

(Ich könnte zwar *alle* Dateien zurücksichern, nur würden dann einige Abschlüsse fehlen,
die dann wiederholt werden müßten.)

Wenn Du genug Zeit hast, dann lohnt es sich, noch ein paar Stunden um die Daten zu kämpfen.

Naja, es hat leider nichts genutzt; wir werden morgen die Sicherung zurückholen und die glücklicherweise nachvollziehbaren Änderungen erneut vornehmen. Tja, und ich werde mich wohl zu 'nem DBA-Kurs anmelden... ;-)

Oracle ist kein sooo völlig fremdes Thema hier. (Vielleicht weiß Kess noch irgendwas, das Dir
weiterhilft?)

Naja, die DB ist ja nicht webmäßig angebunden, deswegen...

Aber danke jedenfalls für die Tips.

Gruß,
Stefan

[Michael Schröpl]

Meine Datenbank ist unter "oracle" installiert und andere Benutzer haben kein Schreibrecht auf
dessen Dateien. (Du wirst doch nicht etwa mit "root" ... pfui Teufel!)
Ich habe unter 'oracle' gearbeitet, direkt auf der Shell, was aber in diesem Fall wohl unrelevant ist...

Okay, für Deinen Jahresabschluß und die temporären Segmente mag das angehen - das hätte ich genauso gemacht. (Bloß halt nicht Dateien gelöscht, während die Datenbank läuft ... ;-)

Für normale Aktionen habe ich eine eigene Kennung für mein Produkt. Die ist in der Gruppe "dba", darf also die Datenbank hoch- und runter fahren und Programme, aber sie hat kein Schreibrecht auf die Dateisysteme, in denen meine Datenbankdateien liegen. Unter der hätte ich die Skripte laufen lassen können, um Tablespaces einzurichten etc.

6 GB sind übrigens nicht gerade wenig. Läßt sich diese Transaktion nicht irgendwie in kleinere Häppchen zerhacken?
(Was macht Ihr denn, wenn die Transaktion abstürzt - wie lange dauert so ein Abschluß?)

Naja, es hat leider nichts genutzt; wir werden morgen die Sicherung zurückholen und die glücklicherweise nachvollziehbaren Änderungen erneut vornehmen.

Siehste wohl - man muß bloß genügend Sicherheitsnetze haben. Viel Spaß beim Eintippen ... ;-)

Tja, und ich werde mich wohl zu 'nem DBA-Kurs anmelden... ;-)

Diese Investition scheint sich bei Eurem Datenvolumen zu lohnen. (Ich mit meiner Micker-DB mit gerade mal 10 GB habe so etwas natürlich nicht besucht ... ;-)

Naja, die DB ist ja nicht webmäßig angebunden, deswegen...

Meine auch nicht (naja, ich habe mal so eine Fingerübung gemacht ...).

Je mehr demnächst im Web 'richtige' Transaktionen ablaufen werden (und nicht nur Homepages a la FortuneCity), desto mehr werden diese Skills zusammenwachsen, denke ich mal.
Deshalb hatte ich neulich zu einer Frage mit Oracle8 und irgendwelchen Web-Tools ja auch mein Interesse gepostet.