Informix Recovery
kpas
Подскажите кто знает.
По неопытности поставили параметры
LTXHWM=70 и LTXEHWM=90
Лог загрузился до 100% и сервер остановился.
Теперь при поднятии сервера он зыгружается в Recovery.
Архивной копии базы разумеется нет.
Или хотя бы вытащить данные с раздела rootdbs.
Заранее благодарю.
Shulzhenko Vasyl
"kpas" <kp...@kuban.net> wrote in message news:3AB858D7...@kuban.net...
Боюсь, что благодарить никого не придется, кроме Informix Technical Support
и то, в том случае, если оплачена поддержка :))
--
С уважением,
Василий Шульженко
http://softline.kiev.ua
Sergey E. Volkov
1) Заглуши Informix.
2) Поставь LTAPEDEV на /dev/null ( а заодно и поставь нормальные параметры )
3) Запусти Informix.
Я не пробовал (просто не наступал на эти грабли), но люди в cdi говорят что
это помогает.
Удачи.
Сергей.
"kpas" <kp...@kuban.net> сообщил/сообщила в новостях следующее:
news:3AB858D7...@kuban.net...
kpas
> и то, в том случае, если оплачена поддержка :))
>
А если нет поддержки.?
Неужели нет утилит способных вытащить данные.
kpas
> Попробуй следующее:
>
> 1) Заглуши Informix.
> 2) Поставь LTAPEDEV на /dev/null ( а заодно и поставь нормальные параметры )
> 3) Запусти Informix.
>
> Я не пробовал (просто не наступал на эти грабли), но люди в cdi говорят что
> это помогает.
Увы, не помогает. LTAPEDEV изначально был на /dev/null
А при запуске oncheck -cR дает ошибку,
говорит что в ONCONFIG:
LTXHWM стоит 50 а на самом деле 70
LTXEHWM стоит 60 а на самом деле 90
LTAPEDEV изначально был на /dev/null
Так что весим в воздухе.
Sergey E. Volkov
"kpas" <kp...@kuban.net> сообщил/сообщила в новостях следующее:
news:3AB8BDDA...@kuban.net...
kpas
> Тогда поставь TAPEDEV в /dev/null и попробуй 'ontape -s -L 0'
>
Не помогает. Пишет
Server is in an incompatible state or user authentication failed.
D.Y.Kazarov
news:comp.databases.informix это именно то, за что поддержка И и получает
свои деньги. У них точно есть утилита, способная маркировать транзакцию
прокомиченной и тогда всё поднимается, но на халяву они её не дают - а то
что дают за деньги работает только один раз и на конкретной машине. Тебе
надо либо самому с этим разбираться (искать транзакцию в logical log-е,
маркировать её, маркировать, переносить метку первого log-а в конец и т.д),
либо сервер переинициализировать (и пересоздавать базу), либо деньги на
суппорт доставать.
Дмитрий
"kpas" <kp...@kuban.net> сообщил/сообщила в новостях следующее:
news:3AB858D7...@kuban.net...
kpas
Если я и решусь все восстанавливать ручками, то чем это делать?
А если найти этот злачный лог и стерет его. А потом запучтить oncheck, то
может быть oncheck сам все исправит?
Sergey E. Volkov
Однако надо знать дисковую структуру Informix-а ...
Теоретически это возможно, но даже если у тебя 100% уверенности в успехе
трахаться придется долго...
Alex Banasevich
ловли льва в Африке".
Нужен другой INFORMIX с аналогичными настройками, размерами дбспейсов и т.д.
Можно без баз данных.
Перед экспериментами обязательно нужно сохранить бинарные копии всех дбспйесов -
они не раз нам понядобятся.
1. Берем Африку, делим забором пополам. В смысле двоично копируем половину root
dbspace из "пустого" сервера в "битый".
2. Пробуем подняться.
3. Скорее всего, поднимемся, но баз не увидим.
4. Восстанавливаем файл дбспейса из нашего бэкапа.
5. Ту половину, "в которой лев", делим еще пополам. Пишем "четвертушку", начиная
с вычисленного смещения.
6. Повторяем шаги 4-6 до тех пор, пока не поднимемся, и увидим базы.
7. После этого БЫСТРО делаем dbexport, переинициализируем INFORMIX, и загружаем
наши базы.
В далеком 1996 году, на версии I-X 5.02 for SCO UNIXWARE 3 такая операция,
выполненная бессонной ночью, спасла одну крупную софтверную фирму, и один
крупный украинский банк. :)
Конечный размер копируемого сегмента составил 3 кБ, смещение уже не помню -
давно было.
Конечно, может и не получиться... :(
D.Y.Kazarov
"D.Y.Kazarov" <kaz...@izmiran.rssi.ru> сообщил/сообщила в новостях
следующее: news:99ddpn$o7i$1...@zware.space.ru...
> Если возможно дать команду onstat -l то там есть колонка phybegin -
смещение
> лога от начала dbspace-a в страницах - можно попробовать с помощью dd
> (предварительно положив И и скопировав куда-нить этот dbspace) затереть
> только не освобождённые логи, возможно И и проглотит такое при запуске. Но
я
> не пробовал.
> (Я успел прочитать фак по И до того, как стал его сильно настраивать)
>
> Дмитрий
Ошибся, не phybegin (это начало физлога), а колонка begin в списке логов.
Дмитрий
D.Y.Kazarov
лога от начала dbspace-a в страницах - можно попробовать с помощью dd
(предварительно положив И и скопировав куда-нить этот dbspace) затереть
только не освобождённые логи, возможно И и проглотит такое при запуске. Но я
не пробовал.
(Я успел прочитать фак по И до того, как стал его сильно настраивать)
Дмитрий
"Alex Banasevich" <de...@finexpert.com> сообщил/сообщила в новостях
следующее: news:3ABA2844...@finexpert.com...
Alex Banasevich
упомянутого мной инцидента.
Результат, повторюсь, был положительным, хотя, признаю, что мероприятие было
чистейшей воды хакерством.
Но другого выхода не было - кроме собственно проблемы с INFORMIX'ом, тогда не
прочитались еще и обе копии бэкапа с ленты :(
Бывает и такое...
kpas
Все как и водится получилось и сервер поднялся нормально,
так что как оказалось техническая поддержка и не нужна.
Если у кого возникнет такого рода проблема, предлогаю
способ выхода из подобной ситуации:
1. Создаем на всякий случай копии всех dbspace;
2. Ставим новый сервер Infomix с такими же параметрами как и рухнувший.
( не забываем, что: LTXHWM<50 и LTXEHWM<60 )
3. Смотрим таблицу размещения данных ( oncheck -pe )
4. Ищем расположение PHYSICAL LOG, LOGICAL LOG, syslogmap (они должны
быть расположены одинаково в обоих серверах)
5. Останавливаем сервера.
6. Копируем эти области из нового сервера в файлы с помощью dd
7. Копируем теперь из полученных файлов в старый сервер с помощью того
же dd
8. Молимся, и поднимаем старый сервер.
Sergey E. Volkov
"kpas" <kp...@kuban.net> сообщил/сообщила в новостях следующее:
news:3ABED587...@kuban.net...
Bulat
Так как у нас было SCO OpenServer 5.0.5 , IDS 7.30 СУППОРТ
нас поздравил с тем что SCO - единственная платформа, где не работают
"секретные ключи" для отката последней транзакции.
Еслибыла бы другая-генерят на своем сайте ключ по времени и на время
работы+сер.номер
В нашем случае была утилита tbdido написанная на Си и откомпилированная для
нашей платформы, с помощью ключиков которой были записаны чистые блоки в
необходиму область журнала, адрескоторой был вычислен с помощью обычных
утилит Информикс.
Однозначно нельзя самому поправить, даже в случае наличия этой утилиты, не
зная структуру данных, а если пострадавший знал бы - такой ситуации не
возникло. Утилита простенькая можно написать и самому на люб языке, чанк
положить на писюк и поправить (если -чанк на файле), только нужно точно
знать структуру чанков,страниц, блоков итд.
В общем скорее всего у него самому ничего не получилось.
Булат.
Alex Banasevich <de...@finexpert.com> сообщил в новостях
следующее:3ABB57EC...@finexpert.com...
Alex Banasevich
путем... :)
Единственное, что бы я посоветовал - так это "выгрузить" все базы, и
переинициализировать сервер, так, на всякий случай...
А самое главное, конечно, изменить параметры настроек, чтобы больше так не
"влетать"...
Shulzhenko Vasyl
From: "Shulzhenko Vasyl" <vas...@mail.ru>
Subject: Re: Informix Recovery
Date: 21 марта 2001 г. 19:36
"Sergey E. Volkov" <sergey_...@hotmail.com> wrote in message
news:99a8lp$l1i$1...@news.lucky.net...
> Попробуй следующее:
>
> 1) Заглуши Informix.
> 2) Поставь LTAPEDEV на /dev/null ( а заодно и поставь нормальные
параметры )
> 3) Запусти Informix.
Не поможет .
> Я не пробовал (просто не наступал на эти грабли), но люди в cdi говорят
что
> это помогает.
Это может помочь только в случае, когда логи заполнились обычными
транзакциями и не с архивированы, а в данном случае имеем дело с длинной
транзакцией, которая не смогла откатиться.
В письме "Re: Emergency log backup" за 15.02.2001 в этой же конфе я подробно
объяснял причины.
> Удачи.
>
> Сергей.
Shulzhenko Vasyl
"D.Y.Kazarov" <kaz...@izmiran.rssi.ru> wrote in message
news:99ddpn$o7i$1...@zware.space.ru...
> Если возможно дать команду onstat -l то там есть колонка phybegin -
смещение
> лога от начала dbspace-a в страницах - можно попробовать с помощью dd
> (предварительно положив И и скопировав куда-нить этот dbspace) затереть
> только не освобождённые логи, возможно И и проглотит такое при запуске. Но
я
> не пробовал.
Дело в том, что отметка о заполнености лога, а самое главное, флажок об
использовании-бакапировании находится не в самом логе, а в
специальной паре страниц из первых 12 в rootdbspace, называющихся
PAGE_1CKPT/PAGE_2CKPT (это физически 3-я и 4-я страницы).
Структура этих страниц описана в Библии в самом конце (раздел "Хранение
описателей и данных на диске") и хотя размеры полей не указаны, все же
довольно легко вычислить структуру, особенно глядя на вывод onstat -l.
Там можно попробовать поменять флажки лога (например 0x05 = U+B) и запустить
сервер.
Хотя не все так просто (в Информиксе многое дублируется и контролируется) и
логи не станут свободными, но все же иногда удается уйти от ожидания
контрольной точки и сервер поднимется и тут главное не зевать и быстро
выгружать БД.
Естественно, что после такого насилия сервер лучше переинициализировать, да
и все операции выполнять только в случае ОЧЕНЬ КРАЙНЕЙ НЕОБХОДИМОСТИ.
И вообще, я вам ничего не говорил и никакие претензии не принимаются :))
> (Я успел прочитать фак по И до того, как стал его сильно настраивать)
Очень мудро, но для того , чтобы понимать советы в ФАК-ах уже надо многое
понимать :)
P.S. А метод "ловли льва в Африке" мне понравился :)
Интересно, а какой был размер Рута и почему кусок оказался в 3 кило ?
Alex Banasevich
На "3 килах" остановились потому, что после этого был наконец-то достигнут
желаемый эффект - I-X "поднялся", и базы "увидел".
До этого было либо только первое, но без баз, либо он вообще не стартовал (мы
уже было начали терять надежду, и это всего-то в 4 часа утра)...
Прошу учесть, что тогда UCDI еще и в проекте не было... :)
Shulzhenko Vasyl wrote:
(skipped)
Shulzhenko Vasyl
"Alex Banasevich" <de...@finexpert.com> wrote in message
news:3AC89AED...@finexpert.com...
> Размер рута был, по-моему, около 500 мег. Давно было, точно уже не
помню...
Мда, титанический был труд, это же сколько раз надо было "разделить пополам"
500М, чтобы дойти до кусочка в 3 кило ?
Я просто поражен твоим трудолюбием и упорством :))
Отсюда вывод - главное желание, а способ всегда найдется.
--
С уважением,
Василий Шульженко
http://softline.kiev.ua
Alex Banasevich
Не так уже и много.
Кто не верит - посчитайте.
Кто не понял - почитайте древнюю легенду про мудреца, которому шах предложил
награду (история с шахматной доской, на каждую следующую клетку которой
укладывается ровно в 2 раза больше зерен, чем на предыдущую)... :)))