[ОТВЕТИТЬ]
Опции темы
01.10.2009 16:09  
akonev
Цитата:
Сообщение от StriderNN
Угу, понятно. Однако, по совету Andrew_Konev, ныне все три контрол файла - идентичные копии бывшего control02.
они одинаковые между собой. но "подошедший" 2-й не соответствует состоянию чего-то из остальных файлов базы: данным или редушкам.

ВСЕ файлы должны быть за один и тот же период времени. если контрольники копировал из бэкапа, то для запуска надо и файлы данных взять оттуда же.

если дело в редушках, то должен помочь рецепт Mtirt.

попробуй еще
alter database backup controlfile to trace
если сработает, то можно будет просто пересоздать контрольники.
 
01.10.2009 16:22  
akonev
Цитата:
Сообщение от Mtirt
Т.е. перед тем, как начать экспериментировать, ты не сделал копию того, что осталось?
А еще на сис.админа ругаешься...
Погоди ругаться. Человек основательно подошел:
Цитата:
Сообщение от StriderNN
...Сделал полную копию Ora81, Oradata, Admin при остановленных сервисах...
Похоже, просто не уловил, что речь о consistency не только контрльников, но и всего остального
 
01.10.2009 16:41  
OlegON
Предлагаю из текущего состояния сделать:
Цитата:
alter database open;
и посмотреть сначала, что же inconsistent на самом деле. Логи пока не обнулять.
И, по многократному совету друзей, не пользоваться DBA Studio при поднятии базы.
 
01.10.2009 16:46  
OlegON
Да, на этапе разбора полетов можно не мучиться с кучей контрольников, а в ini.ora сменить кучу путей в control_files на один.
Есть подозрение, что с контрольниками все таки накосячили.
 
02.10.2009 09:40  
StriderNN
Цитата:
Сообщение от Mtirt
Т.е. перед тем, как начать экспериментировать, ты не сделал копию того, что осталось?
А еще на сис.админа ругаешься...
Копию я сделал. А ирония ситуации в том, что сис.админ - это я. На мне 2003-2008, MS SQL 2000, 1C, VPN сетка на 6 узлов и обычный юзерский зоопарк. И долгое время админ Супермага работал самостоятельно, не допуская меня ни к СМ, ни к Oracle. Я считал и считаю, что это правильно. Что я знаю, за то я и отвечаю. Не знаю Oracle - не лезу. А теперь DBA нет, его расхваленная безотказность = последний бэкап весной*54 . И разбираться мне. И взять control файл мне неоткуда, только из моей же копии битой базы или из весеннег бэкапа, что, как я думаю, бесполезная трата времени.
 
02.10.2009 09:49  
akonev
из весеннего - да, пустая трата.
сейчас тебе надо делать то, что советовал Олег
Цитата:
alter database open;
и вывод сюда копировать
 
02.10.2009 10:27  
StriderNN
Еще раз спасибо всем за участие в решении проблемы.
Короткий отчет.

1. При остановленных сервисах заменил все три control0x.ctl на control02.ctl из моей копии.
2. Запустил сервисы.Прочитал dbnamealrt.log (см. выше)
3. Запустил DBA Studio. Попытался подключиться к базе. Удалось. База в состоянии "Started"
4. Обрадовался. При попытке изменить на "Mount" или "Open" получил сообщение "ORA-00214: controlfile 'D:\ORACLE\ORADATA\DBELENA\CONTROL02.CTL' version 286054
inconsistent with file 'D:\ORACLE\ORADATA\DBELENA\CONTROL03.CTL' version 286042"
5. Огорчился. Прочитал мнение OlegON насчет DBA Studio и перешел на SqlPlus.

D:\Oracle>sqlplus /nolog

SQL*Plus: Release 8.1.6.0.0 - Production on Thu Oct 1 21:58:29 2009

(c) Copyright 1999 Oracle Corporation. All rights reserved.

SQL> connect sys/qqq as sysdba
Connected.
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 718390236 bytes
Fixed Size 70620 bytes
Variable Size 171282432 bytes
Database Buffers 536870912 bytes
Redo Buffers 10166272 bytes
ORA-00214: controlfile 'D:\ORACLE\ORADATA\DBELENA\CONTROL02.CTL' version 286054
inconsistent with file 'D:\ORACLE\ORADATA\DBELENA\CONTROL03.CTL' version 286042

6. По совету OlegON отредактировал init.ora. Закомментировал coontrol01 и control03. Рестартовал сервис базы.

alrt.log
Fri Oct 02 10:09:34 2009
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=11
Fri Oct 02 10:09:35 2009
ARCH: STARTING ARCH PROCESSES COMPLETE
Fri Oct 02 10:09:35 2009
alter database mount exclusive
Fri Oct 02 10:09:36 2009
ARC0: Archival started
Fri Oct 02 10:09:40 2009
Successful mount of redo thread 1, with mount id 3021872804.
Fri Oct 02 10:09:40 2009
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Fri Oct 02 10:09:40 2009
alter database open
Fri Oct 02 10:09:40 2009
Rolling back half complete log switch of thread 1
***
Corrupt block relative dba: 0x0000005f file=0. blocknum=95.
Bad header found during controlfile block read
Data in bad block - type:255. format:255. rdba:0xffffffff
last change scn:0xffff.ffffffff seq:0xff flg:0xff
consistancy value in tail 0xffffffff
check value in block header: 0xffff, calculated check value: 0x0
spare1:0xff, spare2:0xff, spare2:0xffff
LGWR: terminating instance due to error 227
Instance terminated by LGWR, pid = 20772

SqlPlus
SQL> startup mount
ORACLE instance started.

Total System Global Area 718390236 bytes
Fixed Size 70620 bytes
Variable Size 171282432 bytes
Database Buffers 536870912 bytes
Redo Buffers 10166272 bytes
Database mounted.
SQL> alter database open
2 /
alter database open
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel

SQL> alter database backup controlfile to trace
2 /
alter database backup controlfile to trace
*
ERROR at line 1:
ORA-03114: not connected to ORACLE


SQL> ALTER DATABASE OPEN RESETLOGS
2 /
ALTER DATABASE OPEN RESETLOGS
*
ERROR at line 1:
ORA-03114: not connected to ORACLE

7. В печальном раздумии штудирую документацию и жду совета.
 
02.10.2009 10:41  
Mtirt
shutdown immediate;
startup mount;
restore database using backup controlfile until cancel;
 
02.10.2009 10:42  
akonev
по двум последним командам у тебя not connected
попробуй перед ними снова коннектиться
 
02.10.2009 10:49  
StriderNN
2 Mtirt
SQL> restore database using backup controlfile until cancel
SP2-0734: unknown command beginning "restore da..." - rest of line ignored.
 
 


Опции темы



Часовой пояс GMT +3, время: 08:00.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.