Имеем тестовую СУБД Oracle XE (11.2.0.1.x86_64), на Oracle Linux 5.2 x86_64.
При попытке открыть БД из sqlplus получаем ошибку:
ORA-03113: end-of-file on communication channel
Process ID: 4862
Session ID: 91 Serial number: 3
Гугл намекает, что возможны какие-либо проблемы со свободным местом. Смотрим, что с ним:
$ df -h
Видим, что на уровне операционной системы все в порядке.
Смотрим, что в alert.log
$ view /u01/app/oracle/diag/rdbms/xe/XE/trace/alert_XE.log
Видим такую запись после попытки открыть БД:
ORA-19815: WARNING: db_recovery_file_dest_size of 10737418240 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
ARCH: Error 19809 Creating archive log file to '/u01/app/oracle/fast_recovery_area/XE/archivelog/2015_04_21/o1_mf_1_243_%u_.arc'
Errors in file /u01/app/oracle/diag/rdbms/xe/XE/trace/XE_ora_5607.trc:
...
Т.е. вся область восстановления чем-то забита.
Попутно понятно, куда пишутся archivelog:
/u01/app/oracle/fast_recovery_area/XE/archivelog/
Смотрим, чем забита fast recovery area:
du -sh /u01/app/oracle/fast_recovery_area/XE/*
10G /u01/app/oracle/fast_recovery_area/XE/archivelog
Видим, что 10Гб "съели" archivelog. Надо почистить.
Запускаем Recovery manager:
$ rman TARGET /
RMAN> list backup;
...
RMAN-03002: failure of list command at 04/21/2015 14:47:28
ORA-01507: database not mounted
БД должна быть примонтирована, чтобы RMAN показал бэкапы.
Монтируем:
$ sqlplus / as sysdba
SQL> alter database mount;
Database altered.
Смотрим бэкапы:
$ rman TARGET /
RMAN> list backup;
...
specification does not match any backup in the repository
Нет ни одного бэкапа. Что само по себе печально, но для тестовой БД устраивает.
Зато видим порядка 300 архивных логов:
$ rman TARGET /
RMAN> list archivelog all;
...
Чтобы исправить ситуацию, временно увеличиваем db_recovery_file_dest_size, создаем бэкап и удаляем ненужные архивные логи.
$ sqlplus / as sysdba
SQL> alter system set db_recovery_file_dest_size=12G;
System altered.
Делаем бэкап БД, controlfile и архивных логов.
$ rman TARGET /
RMAN> backup as compressed backupset database plus archivelog delete input;
Возвращаем обратно значение параметра инициализации db_recovery_file_dest_size:
$ sqlplus / as sysdba
SQL> alter system set db_recovery_file_dest_size=10G;
System altered.
При попытке открыть БД из sqlplus получаем ошибку:
ORA-03113: end-of-file on communication channel
Process ID: 4862
Session ID: 91 Serial number: 3
Гугл намекает, что возможны какие-либо проблемы со свободным местом. Смотрим, что с ним:
$ df -h
Видим, что на уровне операционной системы все в порядке.
Смотрим, что в alert.log
$ view /u01/app/oracle/diag/rdbms/xe/XE/trace/alert_XE.log
Видим такую запись после попытки открыть БД:
ORA-19815: WARNING: db_recovery_file_dest_size of 10737418240 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
ARCH: Error 19809 Creating archive log file to '/u01/app/oracle/fast_recovery_area/XE/archivelog/2015_04_21/o1_mf_1_243_%u_.arc'
Errors in file /u01/app/oracle/diag/rdbms/xe/XE/trace/XE_ora_5607.trc:
...
Т.е. вся область восстановления чем-то забита.
Попутно понятно, куда пишутся archivelog:
/u01/app/oracle/fast_recovery_area/XE/archivelog/
Смотрим, чем забита fast recovery area:
du -sh /u01/app/oracle/fast_recovery_area/XE/*
10G /u01/app/oracle/fast_recovery_area/XE/archivelog
Видим, что 10Гб "съели" archivelog. Надо почистить.
Запускаем Recovery manager:
$ rman TARGET /
RMAN> list backup;
...
RMAN-03002: failure of list command at 04/21/2015 14:47:28
ORA-01507: database not mounted
БД должна быть примонтирована, чтобы RMAN показал бэкапы.
Монтируем:
$ sqlplus / as sysdba
SQL> alter database mount;
Database altered.
Смотрим бэкапы:
$ rman TARGET /
RMAN> list backup;
...
specification does not match any backup in the repository
Нет ни одного бэкапа. Что само по себе печально, но для тестовой БД устраивает.
Зато видим порядка 300 архивных логов:
$ rman TARGET /
RMAN> list archivelog all;
...
Чтобы исправить ситуацию, временно увеличиваем db_recovery_file_dest_size, создаем бэкап и удаляем ненужные архивные логи.
$ sqlplus / as sysdba
SQL> alter system set db_recovery_file_dest_size=12G;
System altered.
Делаем бэкап БД, controlfile и архивных логов.
$ rman TARGET /
RMAN> backup as compressed backupset database plus archivelog delete input;
Возвращаем обратно значение параметра инициализации db_recovery_file_dest_size:
$ sqlplus / as sysdba
SQL> alter system set db_recovery_file_dest_size=10G;
System altered.
It works!
Комментариев нет:
Отправить комментарий