[ТЕМА ЗАКРЫТА]
28.08.2006 12:27
twix
 
Олег, объясни, с чем такое связано:

ORA-01115: ошибка ввода/вывода при чтении блока из файла 3 (блок # 253897)
ORA-01110: файл данных 3: 'C:\ORACLE\ORADATA\BEREZA01\USERS01.DBF'
ORA-27091: skgfqio: невозможно очередизировать ввод/вывод
OSD-04006: ёсющ ReadFile(), эх т ёюёђюџэшш їшђрђќ шч єрщыр
O/S-Error: (OS 23) Ошибка в данных (CRC).
ORA-06512: на "SUPERMAG.CASH", line 1416
ORA-06512: на "SUPERMAG.CASH", line 1458
ORA-06512: на "SUPERMAG.DOC3", line 1252
ORA-06512: на "SUPERMAG.SMDOCCREATECS", line 6
ORA-06512: на line 1
28.08.2006 12:37
OlegON
 
Связано с невозможностью получить доступ к файлу. Причем, скорее всего это не секьюрность, а просто диск не читается. Дохнет т.е., либо контроллер дурит. Озаботься поиском бэкапа и нового диска.
28.08.2006 12:41
twix
 
блин...
я думал, что ты меня обнадежишь. )8
28.08.2006 12:51
OlegON
 
А тут особо мудрить не надо, смотри сразу на O/S-Error: (OS 23) Ошибка в данных (CRC).
01.09.2006 12:42
twix
 
вот блин......
бэкапа нет. винт купили.
придется, видимо, на ночь оставаться в магазине... сервак из офиса привезти... ))))8
может ли помочь полный экспорт/импорт?
хоть какую-то часть спасти...
01.09.2006 12:51
reddevil
 
придется, видимо, на ночь оставаться в магазине... сервак из офиса привезти... - это зачем? с данными то пока ничего еще не произошло.
01.09.2006 12:52
reddevil
 
после замены dbv прогнать и все
01.09.2006 12:53
twix
 
кстати, 30-го числа в одном магазине случился потоп...
сервак оказался на треть погруженным в воду. *10
залило свитч все блоки питания и сетевые фильтры.
мать сдохла... память сдохла... сидюк и раньше не работал. (% винт не был прикручен - полностью оказался в воде. *10
думал, капец... но базу вытащить с винта удалось:
отвез к знакомым мастерам - оказалось, у винта электроника сдохла, а железо выжило, хоть и стало стучать. вытащили базу, архивы кассовые... и некоторые документы. потом винт окончательно сдох.
но ничего. радует, хоть базу не пришлось с нуля восстанавливать (%
сделал recover, перестроил все индексы аналитической базы (себестоимость не расчитывалась). вот. магазин снова запустили. все работает... надо только 2 кабеля на весы перетянуть.
теперь предусмотрительно поставил новый системник на подставку. (%
01.09.2006 12:53
kadr
 
Цитата:
twix вот блин......
бэкапа нет. винт купили.
придется, видимо, на ночь оставаться в магазине... сервак из офиса привезти... ))))8
может ли помочь полный экспорт/импорт?
хоть какую-то часть спасти...
Как я понял у тебя навернулась база одного из магазинов. В таком случае создаёшь новую базу, генеришь схему супермага и почтовиком из офиса пересылаешь все данные. Зачем тебе экспорт/импорт?
01.09.2006 12:53
twix
 
reddevil, дык users01.dbf, как я понял, лежит на бэдах...
там, правда, z-отчеты только, о все-равно неприятно.
01.09.2006 12:55
twix
 
kadr, дык, по нашим каналам связи почтовиком оно будет месяц рассылаться.... лучше на ночь принесу сервак - там через 1Gbit LAN махом все пройдет (%

насчет экспорта - вытащить таблицы, которые смогу, чтобы с серваком не тра..ться.
еще. можно как-нибуть вытащить часть таблицы, в которой з-отчеты хранятся? скажем, с открытия магазина по 31.07.2006? а остальное потом с касс выгрузить.
01.09.2006 13:00
kadr
 
Цитата:
еще. можно как-нибуть вытащить часть таблицы, в которой з-отчеты хранятся?
настроить dblink и через него тянуть запросами
01.09.2006 13:06
reddevil
 
Цитата:
twix reddevil, дык users01.dbf, как я понял, лежит на бэдах...
там, правда, z-отчеты только, о все-равно неприятно.
Дак копированию средствами ОС он поддается?
01.09.2006 13:09
twix
 
reddevil, нет.в том и проблема
01.09.2006 13:13
reddevil
 
тады упс(
еще. можно как-нибуть вытащить часть таблицы, в которой з-отчеты хранятся? скажем, с открытия магазина по 31.07.2006? у EXP есть параметр QUERY
01.09.2006 13:20
OlegON
 
а Query не отработает, если по индексу не пойдет (и тот не побился). Кстати, я на сайте у себя клал уже.

Вопрос:
Как бы вытащить хотя бы часть данных из поврежденной таблицы?
Ответ:
SELECT /* +index(Х X_1) */ a, b FROM X WHERE rowid not like номер_поврежденного_блока||'.%.'||номер_файла;

01.09.2006 13:22
OlegON
 
twix, задумайся о резервном копировании на объект, который в другом месте находится. К главбуху копирование бэкапа настрой. Днем! Маленькая, но оправданная месть *04
01.09.2006 13:23
reddevil
 
Боюсь ошибиться, но по моему этот способ для DATA BLOCK CORRUPTION а здесь мы имеем дело с поврждением файла на уровне ФС/ОС/железа не знаю как правильнее будет.
01.09.2006 13:28
twix
 
olegon, к гб через 136kbps будет долго сливаться... (%
настрою на манагерский комп
01.09.2006 13:31
OlegON
 
Цитата:
reddevil Боюсь ошибиться, но по моему этот способ для DATA BLOCK CORRUPTION а здесь мы имеем дело с поврждением файла на уровне ФС/ОС/железа не знаю как правильнее будет.
На самом деле без разницы. Блок битый знаем? Знаем. Вот и обойдем его...
01.09.2006 13:34
reddevil
 
спорить не будем)) доступа к телу все равно нету.
01.09.2006 13:34
OlegON
 
Цитата:
twix olegon, к гб через 136kbps будет долго сливаться... (%
настрою на манагерский комп
Ну тогда настрой, чтобы по шедалеру архивировалось содержимое всего его (буховского) диска раз в час с максимальным приоритетом (% Чтобы жизнь медом не казалась.
01.09.2006 22:43
YuraZ
 
Цитата:
olegon а Query не отработает, если по индексу не пойдет (и тот не побился). Кстати, я на сайте у себя клал уже.

Вопрос:
Как бы вытащить хотя бы часть данных из поврежденной таблицы?
Ответ:
SELECT /* +index(Х X_1) */ a, b FROM X WHERE rowid not like номер_поврежденного_блока||'.%.'||номер_файла;
Кстати, Олег, буквально пару дней назад занимался данным вопросом. Условие WHERE rowid not like номер_поврежденного_блока||'.% подходит для 7-го Оракла. На 8-ом не прокатит. И кстати вопрос: после пересоздания таблицы она создается в новом блоке, но старый блок так и остается поврежденным. Как его убрать или починить?
01.09.2006 22:51
OlegON
 
Как это не прокатит?! Принципы генерации номера ROWID не менялись... Насчет починить - не знаю, может просто пересоздать файл или само TS?
02.09.2006 00:02
YuraZ
 
Как я понял из статьи и собственного опыта - поменялись :)
02.09.2006 15:18
twix
 
YuraZ, спасибо за ссылку. она мне пригодится.

2All,
в общем, скопировали на новый винт файл users01.dbf при помощи программы CDCheck. 49 Кб где-то в начале последней трети файла забились нулями. база поднялась. работает все, кроме приемки новых выгрузок с касс. при попытке принять выгрузку с помощью кассового модуля сервис базы моментально стопится, оставив всего лишь одну запись в журнале системы. alertlog говорит, что поврежден блок данных в таком-то файле с таким-то смещением.

все остальное работает нормально: накладные забиваются нормально, весы прогружаются нормально, выгрузка (!) на кассы тоже идет так, как надо. почтовик тоже отрабатывает на ура (кажется, даже лучше чем раньше *04 )

в понедельник разберусь и с битыми блоками. как раз сегодня перед сном статейку почитаю. (%
04.09.2006 08:10
RKuzmin
 
совет: нарезайте бекапы базы на DVD-R :))
04.09.2006 09:50
twix
 
все-таки проблема есть...
время от времени сервис базы все же вылетает. только Service Control Manager отписывет в журнал системы "Служба OracleServiceBEREZA01 была неожиданно завершена."
так что остается выбивать у начальства комп и спасать все данные методом экспорта/импорта.... )8
04.09.2006 09:58
Mtirt
 
Цитата:
RKuzmin совет: нарезайте бекапы базы на DVD-R :))
Может и не спасти...
Или места не хватит, или копия кривая выйдет...
04.09.2006 09:59
OlegON
 
Журнал системы в данном случае не источник. Надо alert*.log смотреть.


Опции темы


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

 

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