Nach stundenlanger Fehlleitung durch den offiziellen Oracle-Support habe ich mich selbst darum gekümmert und das Problem behoben. Ich dokumentiere es hier, falls jemand anderes dieses Problem hat.
Um dies zu tun, müssen Sie der Oracle-Benutzer sein:
$ su - oracle
Schritt 1: Sie müssen sich das Alarmprotokoll ansehen. Es befindet sich nicht wie erwartet in / var / log. Sie müssen ein Oracle-Protokollleseprogramm ausführen:
$ adrci
ADRCI: Release 11.2.0.1.0 - Production on Wed Sep 11 18:27:56 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
ADR base = "/u01/app/oracle"
adrci>
Beachten Sie die ADR-Basis. Das ist nicht die Installation. Sie müssen die Häuser sehen, damit Sie eine Verbindung zu dem von Ihnen verwendeten herstellen können.
adrci> show homes
ADR Homes:
diag/rdbms/cci/CCI
diag/tnslsnr/cci/listener
diag/tnslsnr/cci/start
diag/tnslsnr/cci/reload
CCI ist die Heimat. Stellen Sie das ein.
adrci> set home diag/rdbms/cci/CCI
adrci>
Jetzt können Sie die Warnungsprotokolle anzeigen. Es wäre sehr schön, wenn sie in / var / log wären, so dass Sie die Protokolle leicht analysieren könnten. Hören Sie einfach auf zu wollen und beschäftigen Sie sich mit dieser Schnittstelle. Zumindest kannst du tailen (und ich hoffe du hast einen Scrollback Buffer):
adrci> show alert -tail 100
Scrollen Sie zurück, bis Sie Fehler sehen. Du willst den ERSTEN Fehler. Alle Fehler nach dem ersten Fehler werden wahrscheinlich durch den ersten Fehler verursacht. In meinem Fall war der erste Fehler:
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 100.00% used, and has 0 remaining bytes available.
Dies wird durch Transaktionen verursacht. Oracle ist nicht zur Verwendung vorgesehen. Wenn Sie viele Daten in das Verzeichnis übertragen, werden Transaktionsprotokolle gespeichert. Diese gehen in den Wiederherstellungsdateibereich. Sobald das voll ist (50GB in diesem Fall). Dann stirbt Oracle einfach. Wenn irgendetwas durcheinander kommt, wird Oracle automatisch heruntergefahren.
Es gibt zwei Lösungen, die richtige und die schnelle und schmutzige. Das schnelle und schmutzige ist, db_recovery_file_dest_size zu erhöhen. Beenden Sie zunächst adrci.
adrci> exit
Wechseln Sie jetzt zu sqlplus, ohne die Datenbank zu öffnen, und hängen Sie sie einfach ein (Sie können dies möglicherweise tun, ohne die Datenbank zu mounten, aber ich mounte sie trotzdem).
$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Wed Sep 11 18:40:25 2013
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> connect / as sysdba
Connected.
SQL> startup mount
Jetzt können Sie Ihre aktuelle db_recovery_file_dest_size erhöhen, in meinem Fall auf 75G erhöht:
SQL> alter system set db_recovery_file_dest_size = 75G scope=both
Jetzt können Sie das System herunterfahren und neu starten, und der vorherige Fehler sollte behoben sein.
Die richtige Lösung besteht darin, die Wiederherstellungsdateien zu entfernen. Sie tun dies mit RMAN, nicht mit SQLPLUS oder ADRCI.
$ rman
Recovery Manager: Release 11.2.0.1.0 - Production on Wed Sep 11 18:45:11 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
RMAN> backup archivelog all delete input;
Wenn Sie haben RMAN-06171: not connected to target database
, dann versuchen Sie, rman target /
anstatt nur zu verwendenrman
Warten Sie lange, und Ihr Archivprotokoll (das den gesamten Speicherplatz belegt hat) ist verschwunden. So können Sie Ihre Datenbank herunterfahren / starten und wieder im Geschäft sein.
ALTER DATABASE OPEN
und Fehler danach.