ORA-00376: file 11 cannot be read at this time или зачем придумали понедельник?

Alex
19 января 2010 г. в 11:22

Ответить

В данной ситуации или если сразу несколько файлов заблокировано можно выполнить
sqlplus> recover database;
Эта процедура проверит все файлы которым необходим RECOVER, синхронизирует их с control file, а затем переведет в ONLINE. После окончания recover достаточно просто открыть БД.

Oleksandr Denysenko
5 февраля 2010 г. в 20:56

Ответить

>>Выполнялся на выходных холодный бэкап. База остановлена
>>...
>>Она то открылась. Но получено сообщение об ошибке:
>>ORA-00376: file 11 cannot be read at this time
================================================
чего-то я не-до-понимаю в этой жизни...
как она могла вообще открыться то ?
если она была остановлена и нет доступа к файлам,
то она не откроется...

dbstalker
9 февраля 2010 г. в 11:04

Ответить

база данных открылась. оракл не имел доступа к одному файлу, вернее имел доступ, но скорее всего информация в заголовке этого файла данных не соответствовала записи в управляющем файле базы. Recover решил эту проблему

Oleksandr Denysenko
22 февраля 2010 г. в 11:11

Ответить

Проблема только в том, что если при старте экземпляра у него нету доступа
к согласованной версии файла, то БД не откроется! только смонтируется
Короткий пример
SQL> create tablespace TTT datafile '/ora1/oracle/TTT.dbf' size 1m;
Tablespace created.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
--сохраним один на будующее
SQL> !cp /ora1/oracle/TTT.dbf /ora1/oracle/TTT.dbf.SAV
--файлик перемести, чтобы не было доступа
SQL> !mv /ora1/oracle/TTT.dbf /ora1/oracle/TTT.dbf.MOV

SQL> startup
ORACLE instance started.
Total System Global Area 1375731712 bytes
Fixed Size             2056056 bytes
Variable Size         301990024 bytes
Database Buffers       1056964608 bytes
Redo Buffers           14721024 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 9 - see DBWR trace file
ORA-01110: data file 9: '/ora1/oracle/TTT.dbf'

БД не открылась! только смонтирована...

SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.

--вернем файлик на место
SQL> !mv /ora1/oracle/TTT.dbf.MOV /ora1/oracle/TTT.dbf

SQL> startup
ORACLE instance started.
Total System Global Area 1375731712 bytes
Fixed Size             2056056 bytes
Variable Size         301990024 bytes
Database Buffers       1056964608 bytes
Redo Buffers           14721024 bytes
Database mounted.
Database opened.
--ОТКРЫЛАСЬ

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

ВЕРНЕМ СТАРУЮ ВЕРСИЮ ФАЙЛИКА
SQL> !mv /ora1/oracle/TTT.dbf.SAV /ora1/oracle/TTT.dbf

SQL> startup
ORACLE instance started.
Total System Global Area 1375731712 bytes
Fixed Size             2056056 bytes
Variable Size         301990024 bytes
Database Buffers       1056964608 bytes
Redo Buffers           14721024 bytes
Database mounted.
ORA-01113: file 9 needs media recovery
ORA-01110: data file 9: '/ora1/oracle/TTT.dbf'

SQL> select status from v$instance;
STATUS
------------
MOUNTED
--ОПЯТЬ НЕ ОТКРЫЛАСЬ В АВТОМАТЕ
--ТРЕБУЕТСЯ ВОССТАНОВЛЕНИЕ

SQL> recover database;
Media recovery complete.
SQL> alter database open;
Database altered.
--ОТКРЫЛИСЬ

ВЫВОД:
остановленная БД(как было заявлено для холодного бекапа)
не будет открыта автоматически при старте экземпляра
Т.Е. - с большой долей вероятности исходная ситуация была другой....

dbstalker
22 февраля 2010 г. в 12:41

Ответить

ваш вывод неправильный. Обращаю внимание, что база данных была остановлена, файл данных архивировался с помощью winrar, вероятно єтот процесс архивации завис. Администратор просто выдал команду startup. база данных открылась. Но приложение, которое работало с вышеупомянутым файлом данных, получило ошибку упомянутую в посте. Вы же создали немного другую ситуацию :)
Поэтому, если у вас есть сомнения, прошу все ж таки соблюдать чистоту эксперимента.

Очень приятно ваше внимание. Успехов!

Oleksandr Denysenko
22 февраля 2010 г. в 13:11

Ответить

возможно что проблема именно из-за того что платформа Виндовс...
таки при запаковке файлом 7-Zip(как альтертива ВинРАР)
процесс Hiew - не смог записать файл, сказав что тот read-only
возможно данное поведение и есть "причина" проблемы

ИТОГО:
без алерт.лога можно таки только догадываться...

В ДОПОЛНЕНИЕ
--решил проверить что будет с БД если файлу со стутусом в БД "на запись" оставить на уровне Юникс доступ только "на чтение"
далее кусок алерт-лога старта БД
Completed: ALTER DATABASE   MOUNT
Mon Feb 22 13:05:06 2010
ALTER DATABASE OPEN
Mon Feb 22 13:05:06 2010
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=27, OS id=18608
ARC1 started with pid=28, OS id=18610
Mon Feb 22 13:05:06 2010
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
Mon Feb 22 13:05:07 2010
Errors in file /ora1/oracle/admin/R10/bdump/r101_lgwr_18495.trc:
ORA-01110: data file 9: '/ora1/oracle/TTT.dbf'
ORA-01114: IO error writing block to file 9 (block # 1)
ORA-27041: unable to open file
HPUX-ia64 Error: 13: Permission denied
Additional information: 3
Mon Feb 22 13:05:07 2010
ORA-01201: file 9 header failed to write correctly
Mon Feb 22 13:05:07 2010
Errors in file /ora1/oracle/admin/R10/bdump/r101_lgwr_18495.trc:
ORA-01122: database file 9 failed verification check
ORA-01110: data file 9: '/ora1/oracle/TTT.dbf'
ORA-01208: data file is an old version - not accessing current version
LGWR: terminating instance due to error 1122
Mon Feb 22 13:05:07 2010
System state dump is made for local instance
System State dumped to trace file /ora1/oracle/admin/R10/bdump/r101_diag_18483.trc
Mon Feb 22 13:05:07 2010
Trace dumping is performing id=[cdmp_20100222130507]
Mon Feb 22 13:05:12 2010
Instance terminated by LGWR, pid = 18495
==========
как на меня так вполне ожидаемое поведение для БД
но нельзя списывать со счетов, что исходная ситуация была под Виндовс

Zukus
24 февраля 2011 г. в 10:36

Ответить

Вместо полного пути к файлу можно указать его номер:
SQL> recover datafile 11;
В случае если оракл вернет ошибку ora-00280 попробовать указать:
auto

SQL> alter database datafile 11 online;

Zukus
24 февраля 2011 г. в 10:47

Ответить

После указания опции AUTO, если вы посмотрите alert.log,
то увидите что оракл делает команду:

ALTER DATABASE RECOVER   CONTINUE DEFAULT

И автоматом ищет нужные ему архив логи.

Поэтому не вижу смысла в выполении recover database

Ведь отдельный файл восстановить быстрее чем шуршать всю базу.

Andji
7 июня 2013 г. в 04:28

Ответить

УРА-А!!! По Вашим командам я тоже восстановила свою базу. Очень благодарна вам.