ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Неудачное восстановление инкрементального бэкапа
56 сообщений из 56, показаны все 3 страниц
  все  
Неудачное восстановление инкрементального бэкапа
    #36762106
oldgreengoblin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oldgreengoblin
Гость
Приветствую всех!

Подскажите, есть ли выход из такой ситуации: была попытка восстановить базу из инкрементального бэкапа, которая завершилась неудачно из-за того, что отсутствовала полная резервная копия базы. База предварительно не удалялась, а попытка restore была выполнена поверх имеющейся базы. Есть ли возможность вернуть имеющуюся базу к рабочему состоянию и как это можно сделать? При попытке подключиться к базе теперь появляется сообщение:
SQL1119N Не удается установить или
активировать соединение с базой данных
"STRAH", поскольку предыдущее восстановление
было неполным или еще не завершено.
SQLSTATE=57019


Версия DB2: 9.7.0
RedHat 5.4 x86_64
...
Рейтинг: 0 / 0
27.07.2010, 15:57
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36762701
ctginst1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ctginst1
Гость
oldgreengoblin,

Без полной резервной копии восстановить базу невозможно.
...
Рейтинг: 0 / 0
27.07.2010, 21:32
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36762765
oldgreengoblin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oldgreengoblin
Гость
ctginst1,
Да, все верно и я с этим не спорю. Я лишь хотел с помощью общественности разобраться, находятся ли данные в базе после неудавшейся попытки восстановления в целостности или нет. Ведь по сути никакое восстановление и не начиналось (или я все-таки ошибаюсь?), т.к. не была найдена полная резервная копия. Однако база находится в состоянии restore pending и подключиться к ней невозможно, как было описано в моем предыдущем сообщении.
...
Рейтинг: 0 / 0
27.07.2010, 23:04
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36762910
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mustaccio
Участник
Попробуйте RESTORE DB STRAH ABORT.
...
Рейтинг: 0 / 0
28.07.2010, 02:18
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36763342
oldgreengoblin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oldgreengoblin
Гость
mustaccio,

К сожалению без результата:
db2 restore db имя_базы incremental abort

db2 connect to имя_базы
SQL1119N Не удается установить или
активировать соединение с базой данных
"имя_базы", поскольку предыдущее восстановление
было неполным или еще не завершено.
SQLSTATE=57019

Попытался вытащить данные с помощью db2dart имя_базы /DDEL, но ничего не вышло. В имя_базы.RPT ошибка:
Error: Unable to read pool page 0, object page 0, from pool 0,
Error: parent pool 0, object ID 1, object type Data.
Warning: Object not found in SYSTABLES, SYSDATAPARTITIONS or SYSINDEXES.
Error: Unable to obtain Table ID. Can't complete formatting.
Error: This phase encountered an error and did not complete.
Table object data formatting end.
...
Рейтинг: 0 / 0
28.07.2010, 11:35
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36764576
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mustaccio
Участник
oldgreengoblinmustaccio,

К сожалению без результата:
db2 restore db имя_базы incremental abort



Это, конечно же, неправильно. Посмотрите еще раз, какую команду я написал.
...
Рейтинг: 0 / 0
28.07.2010, 17:25
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36765469
oldgreengoblin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oldgreengoblin
Гость
mustaccio,

Снова неудача:

db2 RESTORE DB STRAH ABORT
DB21080E Для этого алиаса базы данных не была
ранее выполнена команда RESTORE DATABASE с опцией
REDIRECT, или информация об этой команде
утеряна.
...
Рейтинг: 0 / 0
29.07.2010, 10:11
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36771546
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Добрый день.
oldgreengoblinЯ лишь хотел с помощью общественности разобраться, находятся ли данные в базе после неудавшейся попытки восстановления в целостности или нет. Ведь по сути никакое восстановление и не начиналось (или я все-таки ошибаюсь?), т.к. не была найдена полная резервная копия. Однако база находится в состоянии restore pending и подключиться к ней невозможно, как было описано в моем предыдущем сообщении.Восстановление начиналось, когда вы указали инкрементальный архив.
И оно с помощью SQL2539W должно было в ответ на restore db strah incremental сообщить, что база затрётся.
Теперь ищите последний полный архив, после которого был взят этот инкрементальный.
...
Рейтинг: 0 / 0
02.08.2010, 17:27
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36771726
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
Этого архива нет, сеть архив трех недельной давности. После раскатки которого пытаемся провести rollforward , но в ответ получаем сообщение, что

Код: plaintext
1.
2.
3.
SQL1265N  Неправильный последовательный номер
архивного файла журнала "S0006242.LOG" для базы
данных "STRAH" на узле "0"

Если убрать этот журнал, то ругается, что такого журнала нет.
Как заставить отработать rollforward ?
...
Рейтинг: 0 / 0
02.08.2010, 18:58
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36771745
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Guzya,

К архиву логи должны подходить.
У вас скорее всего логи от одной базы, а архив от другой.
...
Рейтинг: 0 / 0
02.08.2010, 19:08
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36771779
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
БД одна архив который раскатываю это архив со старого сервера, т.е. 3 недели назад переехали на новый сервер. Старый сервер законсервировали. Теперь востанавливаемся с архива который использовали при переезде. Т.е. получается у него S0006245.LOG активный журнал, а я ему пытюсь подсовывать с S0006245.LOG по S0006445.LOG. И при rollforward db strah query status
выводится , что следующий журнал на чтение S0006245.LOG.
...
Рейтинг: 0 / 0
02.08.2010, 19:33
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36771874
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
А может быть, что среди тех журналов которые я подсовываю есть журналы не помеченные как архивные. Как определить журнал был закрыт как архивный или нет?
...
Рейтинг: 0 / 0
02.08.2010, 20:55
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36772077
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
Guzya,

Возможен и другой вариант - PRUNE HISTORY/LOGFILE ... :)

С уважением,
Вадим.
...
Рейтинг: 0 / 0
03.08.2010, 01:06
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36772195
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
Я не очень понял, она же удаляет архивные лог файлы. Для чего я её должен использовать?
...
Рейтинг: 0 / 0
03.08.2010, 08:45
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36772282
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
GuzyaБД одна архив который раскатываю это архив со старого сервера, т.е. 3 недели назад переехали на новый сервер. Старый сервер законсервировали. Теперь востанавливаемся с архива который использовали при переезде. Т.е. получается у него S0006245.LOG активный журнал, а я ему пытюсь подсовывать с S0006245.LOG по S0006445.LOG. И при rollforward db strah query status
выводится , что следующий журнал на чтение S0006245.LOG.Я правильно понял, что вы
- восстановились на новом сервере из архива, который использовали на этом новом сервере при создании там базы
- база работала там некоторое время, логи там плодились
- теперь вы восстанавливаетесь на новом сервере из этого же архива и при rollforward ... to end of logs получаете
Код: plaintext
1.
2.
3.
SQL1265N  Неправильный последовательный номер
архивного файла журнала "S0006242.LOG" для базы
данных "STRAH" на узле "0"
но rollforward db strah query status
пишет о файле S000624 5 .LOG?

Если что-то не так, опишите в точности, на какой машине вы восстанавливаетесь и с какой машины логи подсовываете.
...
Рейтинг: 0 / 0
03.08.2010, 10:01
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36772352
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
Да вы правильно поняли, только я ошибся в названии файла(S0006245.LOG ->S0006242.LOG)
...
Рейтинг: 0 / 0
03.08.2010, 10:34
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36772801
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Guzya,

Попробуйте так:
- переместите на новом сервере все логи из your_active_log_path в какой-нибудь каталог, скажем overflow_path
- вытащите логи из полного архива:
restore db strah LOGS from ... LOGTARGET your_active_log_path
- запустите
rollforward db strah to end of logs overflow log path ( overflow_path )
...
Рейтинг: 0 / 0
03.08.2010, 13:29
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36773286
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
Как я понял надо:
раскатать архив(старый), потом заменить логи, и ролфорвард?
...
Рейтинг: 0 / 0
03.08.2010, 15:59
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36773414
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
Guzya,

а можно в нормальных терминах, не "раскатать", а покажите команду, которую вы использовали для восстановления базы.
как архивировали журналы транзакций.
...
Рейтинг: 0 / 0
03.08.2010, 16:42
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36773617
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
GuzyaКак я понял надо:
раскатать архив(старый), потом заменить логи, и ролфорвард?Да.
Если вы ещё не восстановили архив, то можно:
restore db strah from ... LOGTARGET your_active_log_path
Оно и базу восстановит и логи из архива вытащит (я приводил команду выше только для витаскивания логов из архива).
Правда из-за проблемы с несовместимой логовой последовательностью далеко вы можете не накатиться.
Но это уже другая история...
...
Рейтинг: 0 / 0
03.08.2010, 17:45
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36773623
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
GuzyaКак я понял надо:
раскатать архив(старый), потом заменить логи, и ролфорвард?Да.
Если вы ещё не восстановили архив, то можно:
restore db strah from ... LOGTARGET your_active_log_path
Оно и базу восстановит и логи из архива вытащит (я приводил команду выше только для витаскивания логов из архива).
Правда из-за проблемы с несовместимой логовой последовательностью далеко вы можете не накатиться.
Но это уже другая история...
...
Рейтинг: 0 / 0
03.08.2010, 17:46
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36773642
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
видимо я опять что-то не понял, зачем мне вытаскивать логи из архива трех недельной давности?
...
Рейтинг: 0 / 0
03.08.2010, 17:57
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36773673
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Guzyaвидимо я опять что-то не понял, зачем мне вытаскивать логи из архива трех недельной давности?Если архив онлайновый и у вас проблема с накатом по логам вне архива (несовместимая логовая последовательность), то это поможет вам накатиться хотя бы до конца архива.
Если архив оффлайновый, то логов там нет, и можно восстанавливаться вообще без наката по логам.
...
Рейтинг: 0 / 0
03.08.2010, 18:13
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36773795
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
Архив оффлайновый, у нас нет проблемы восстановиться с этого архива, нам нужно восстановить за эти три недели данные по журналам транзакций.
...
Рейтинг: 0 / 0
03.08.2010, 19:02
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36773885
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Mark Barinstein,Чтобы не было неясностей расскажу подробно как все было. Есть приложение, работающее с базой STRAH. В конце июня была выпущена новая версия этого приложения и нам было рекомендовано перейти на нее. Новую версию решили ставить на новом сервере. Вечером 28 июня июня сделали полный бэкап базы со старого сервера и 29 восстановили ее на новом. Работы по переходу на новую версию и переводу приложения на новый сервер велись 3 дня и до окончания этих работ пользователи не имели доступа к приложению. В ночь на 24 июля произошел сбой. Утром, в 10.46 6ыла сделана попытка восстановить базу из последнего бэкапа. Оказалось, что у нас в наличии на момент сбоя только 4 дельта-инкрементальных бэкапа, сделанных в новой версии приложения(за 21-24 июля). Сейчас мы пытаемся восстановить данные, введенные в базу за три недели работы 160-ю пользователями, путем повторения действий, проделанных по переходу на новую версию приложения, на другом (таком же) сервере. Т.е. восстанавливаем бэкап из предыдущей версии, проделываем комплекс работ по переходу на новую версию, бэкапим базу, подменяем журнал транзакций журналом с сервера, на котором произошел сбой, и пытаемся восстановиться уже с бэкапа, сделанного после перехода на новую версию и повторить транзакции Вот это и не получается сделать. Т.е. база вроде и та же, но и не та
...
Рейтинг: 0 / 0
03.08.2010, 20:34
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36773997
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
madija,

Вы уверенны, что используя offline backup, можете делать rollforward ?
Может для offline backup, следует выполнить восстановление с опцией "WITHOUT ROLLING FORWARD" ?!

Вы делали On-Line-й backup или OFF-Line-й backup для базы данных ?

Напишите команды, которые Вы использовали и последовательность их выпонения.
Какие параметры конфигурации БД использовались (режимы ведение логов - циклические, архивные и т.д.).

С уважением,
Вадим.
...
Рейтинг: 0 / 0
03.08.2010, 22:09
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774013
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Вадим,

Повторив "задним чилом" на тестовом сервере работы по переходу на новую версию, пробовали делать и онлайновый, и оффлайный бэкап. Результат один и тот же. Режим ведения логов нециклический.
Точные комады и последовательность их выполнения, а также параметры конфигурации базы смогу выложить завтра.
...
Рейтинг: 0 / 0
03.08.2010, 22:34
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774034
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
madija,

как только выполнили востановление со старого backup и сделали это без указания WITHOUT ROLLING FORWARD, с последующим db2 connect to strah - всё, у вас активировалась новая цепочка последовательностей журналов транзакций.
А вы не просто connect делаете - вы кучу действий в базе выполняете.
И после этого вы ожидаете, что база примет журналы транзакций из совсем другой цепочки последовательностией???
Они уже совсем чужие для вашей уже новой базы.
...
Рейтинг: 0 / 0
03.08.2010, 22:54
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774048
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
йо, напутал, С УКАЗАНИЕМ without rolling forward.
то есть последовательность
- restore db without rolling forward
- connect to
приводит к образованию новой последовательности журналов транзакций.
чтобы накатить ваши старые журналы, надо вернуть базу на старую последовательность журналов, и после накатывать, в вашем случае - resore и накатывать. и никаких without rolling forward и промежуточных действий в базе, с последующим db2rfpen (вот он для чего вам нужен был) и попыткой rollforward журналов, которые уже совсем чужие для совсем новой базы с новой последовательностью журналов.
...
Рейтинг: 0 / 0
03.08.2010, 23:09
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774055
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
ппм,

Мы указываем WITHOUT ROLLING FORWARD при восстанавлении базы. После воостановления подменяем папку с журналами транзакций и, если после этого даем команду
db2 rollforward db strah to end of logs and stop
получаем
SQL1261N База данных "strah" не находится в состоянии отложенного повтора на узлах "0", поэтому не требуется повтор транзакций на этих узлах.

Если даем команду
db2rfpen on strah
а затем

db2 rollforward db strah to end of logs and stop,

то получаем

SQL1265N Неправильный последовательный номер архивного файла журнала "S0006242.LOG" для базы данных "STRAH" на узле "0".
...
Рейтинг: 0 / 0
03.08.2010, 23:22
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774059
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Вадим,

оказывается есть с собой информация о конфигурации базы
...
Рейтинг: 0 / 0
03.08.2010, 23:27
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774068
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
ппм,

Пробовали восстанавливаться и без WITHOUT ROLLING FORWARD, предавительно подменив папку с журналами. Информации из журналов в базе не попадает.
...
Рейтинг: 0 / 0
03.08.2010, 23:35
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774219
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
madija,

трудно понять, что вы делаете, но ещё раз
восстанавливаться without rolling forward, затем выполнять действия по изменению базы, затем выполнять db2rfpen и пытаться выполнить rollforward - не имеет смысла. Журналы транзакций уже чужие стали для базы, вы их сделали такими первым же соединением с базой после restore without rolling forward

а вот про информация не попадает из журналов - давайте подробнее.
Она не попадает в том случае, если её там нет - выполнили не журналируемую операцию. Выполнили не восстанавливаемый LOAD.
...
Рейтинг: 0 / 0
04.08.2010, 07:56
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774240
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Вадим,

Подменив на тестовом сервере каталог с журналами транзакций пытаюсь восстановиться с offline копии командой
db2 restore db strah from /home/db2inst/20100629 to /home/db2inst/STRAH without prompting


SQL2540W Восстановление успешно, однако при
работе утилиты Database "2539".
...
Рейтинг: 0 / 0
04.08.2010, 08:21
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774355
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
madija... Сейчас мы пытаемся восстановить данные, введенные в базу за три недели работы 160-ю пользователями, путем повторения действий, проделанных по переходу на новую версию приложения, на другом (таком же) сервере. Т.е. восстанавливаем бэкап из предыдущей версии, проделываем комплекс работ по переходу на новую версию, бэкапим базу, подменяем журнал транзакций журналом с сервера, на котором произошел сбой, и пытаемся восстановиться уже с бэкапа, сделанного после перехода на новую версию и повторить транзакции Вот это и не получается сделать. Т.е. база вроде и та же, но и не таМожете не пытаться - не получится.
Как только вы начали работу на тестовом сервере после восстановления, логовые последовательности на нём и на том, где сбой произошёл, разошлись и стали несовместимыми.
...
Рейтинг: 0 / 0
04.08.2010, 09:59
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774365
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
А можете подробнее рассказать в чем заключается логовая последовательность? Т.е. там идет привязка имя журнала ко времени или как?
...
Рейтинг: 0 / 0
04.08.2010, 10:03
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774424
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Mark Barinstein,

Очень, очень жаль. Ведь мы на тестовом сервере до какого-то момента попадаем в такую же с виду логовую последовательность, она начинается с того имени, что и на основном, размеры файлов совпадают.... Важно было восстановить данные именно из сбойной базы, чтобы исключить последующие проблемы, которые возникнут после восстановления данных другим путем, т.к. это приложение оперативно обменивалось данными с 3-мя другими приложениями.
...
Рейтинг: 0 / 0
04.08.2010, 10:23
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774453
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
GuzyaА можете подробнее рассказать в чем заключается логовая последовательность? Т.е. там идет привязка имя журнала ко времени или как? Log file management
...
Рейтинг: 0 / 0
04.08.2010, 10:32
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774498
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
madija,

Если по-простому:
Записи в логе ссылаются на идентификаторы из системного каталога (id таблицы, например).
Теперь представьте, что у вас есть старые логи этой базы.
Вы восстановили базу, произвели какие-то изменения в данных (что-то удалили, что-то изменили) или может быть, даже удалили таблицы
Потом пытаетесь подсунуть старые логи, из которых надо изменения применять к потенциально новой базе (ведь там всё может сильно поменяться). При этом можно столкнуться с огромным количеством конфликтов, с которыми даже непонятно, как разбираться.
Поэтому DB2 автоматически определяет, что ей подсовывают неправильную логовую последовательность, и отказывается накатывать изменения, что есть абсолютно правильно.
...
Рейтинг: 0 / 0
04.08.2010, 10:50
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774500
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
madija,

судя по конфигурации вашей базы, ваши архивные журналы транзакций никуда не преносятся.
В таком случае после restore without rolling forward и выполнении активностей на восстановленной базе ваши журналы транзакций были перезаписаны. То есть имена у них остались прежние, а содержание у многих перезаписано.
Если вам надо восстановить данные из архивных журналов - вам надо
1) выполнить восстановление из резервной копии
2) взять оригинальные журналы транзакций, которые вы должны юыли скопировать, и не брать те, которые находятся в каталоге активных журналов, потому как они уже перезаписаны
3) rollforward при указании пути к оригинальным архивным журналам

Это если надо восстановиться по архивным журналам.
Имейте в виду, что данные с невосстановимых операций LOAD будут утеряны - на то она и невосстановимая операция.
...
Рейтинг: 0 / 0
04.08.2010, 10:50
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774679
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Mark Barinstein,

"Вы восстановили базу, произвели какие-то изменения в данных (что-то удалили, что-то изменили) или может быть, даже удалили таблицы"

Работы на старом сервере ( с предыдущей версией приложения) были остановлены 28 июня вечером. Было сделано архивное копирование и получен файл со штампом времени 10200628153342. Далее:
1)Архив10200628153342 по инструкции по установке новой версии приложения был восстановлен с ключом without rolling на новом сервере .
2)Была выполнена переустановка БД с сохранением данных (из скрипта).
3)Была выполнена установка приложения (тоже из скрипта).
Эти работы были завершены к вечеру 29 июня. На следующий день (30 июня) велись работы по настройке приложения и проверки его работы. И только 1 июля сервер был открыт для пользователей.
Сейчас мы на тестовом сервере проделываем последовательность действий 1-3, страраясь попасть в те же временные отметки, и как нам кажется, по отношению к журналам, сформированным с 30 июня на основном сервере, мы стоим на той же контрольной точке, на которой база на основном сервере была на эту дату.

"DB2 автоматически определяет, что ей подсовывают неправильную логовую последовательность, и отказывается накатывать изменения, что есть абсолютно правильно."

С этим спорить невозможно, но нам в нашей ситуации это так не подходит....
...
Рейтинг: 0 / 0
04.08.2010, 11:54
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774715
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
madija
Сейчас мы на тестовом сервере проделываем последовательность действий 1-3, страраясь попасть в те же временные отметки, и как нам кажется, по отношению к журналам, сформированным с 30 июня на основном сервере, мы стоим на той же контрольной точке, на которой база на основном сервере была на эту дату.

И именно теперь "старые" архивные журналы стали чужими для вашей восстановленой базы, и никакие старания попасть в те же временные отметки здесь не помогут - журналы стали чужими после первого же connect, и могли быть перезаписаны вашими действиями.
Лучше думайте, что у вас две разные базы.
Одна, на которой вы работали и получили архивные журналы.
И вторая, которую вы восстановили из резервной копии, и с которой работали, выполняя изменения в ней.
...
Рейтинг: 0 / 0
04.08.2010, 12:04
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774817
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
ппм,

И "породнить" базу с тестового сервера с логами сбойного сервера невозможно?
Очень жаль.
...
Рейтинг: 0 / 0
04.08.2010, 12:36
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774823
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
madija,

именно эту мысль я вам и стараюсь донести.
...
Рейтинг: 0 / 0
04.08.2010, 12:38
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36774831
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
Кстати, если вы таки прочитаете документацию по ссылке, любезно предоставленной Марком, то там то же самое написано правильными словами, с картинками.
...
Рейтинг: 0 / 0
04.08.2010, 12:40
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36775914
Anka_S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anka_S
Гость
Найдите
1. выписки из ЕГРИП/ЕГРЮЛа,
2. выписки по казночейству
3. если были старые АДВ-11 то их файлы, если кто сдавал корректировки за прошлые периоды
4. запросите с налоговой реестр страхователей для сверки у них информация которую Вы отдавали должна быть
можно попробовать посмотреть классификатор страхователей, который выгружается для спу, адв-11 то же для него выгружаемые, с платежами хуже, но попробовать найти в асв хвосты можно
остануться ещё всякие внебанковские и передачи м/д районами
Всё это на самый худщий случай Вам потребуется.
Вы хоть напишите отчего базу скрючило, что было?
...
Рейтинг: 0 / 0
04.08.2010, 19:02
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36776081
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Anka_S,

К восстановлению по худшему сценарию подготовились. Восстановились на другом сервере по состоянию на 1 июля, загрузили платежи. Ждем помощи от Красноярка по синхронизации с АСВ. Надеемся, что завтра они нам что-нибудь предложат. Выписки из ЕГРИЛ имеются. Спасибо за подсказку по выгрузке классификатора страхователей и АДВ-11 для СПУ.

Причину сбоя не знаем. Представитель фирмы-разработчика ответил, что по db2diag установить причину сбоя невозможно. В субботу (24 июня) около 10 часов утра позвонили пользователи с тем, что не могут войти в приложение. Проверила. При попытке регистрации обычным пользователем выводилось сообщение о том, что сервер не может обобразить страницу, т.к занят обслуживанием, а при попытке регистации администторской учеткой вывелось сообщение
SRCE 0232E: Internal Server Error /
Exception Message: {RemoteException occured in server thead;
nested exception is: java.rmi.RemoteException;;
nested exception is: {code=ERR_INTERVAL_ERROR,messge=___
The error occured in ibatis_resources/Admin.xml.-
The error occured while applying a parametr map.___
Chek the Admin.userTerrDptPfrParamMap.
Check the result (failed to retrive results).
Cause: com.ibm.db2/jcc.am.SqlException:
DB2 SQL Error:
SQLCODE=-290, SQLSTATE=55038, SQLERRMC=null, DRIVER=3.58.82,

Перезапуск веб-сферы и db2 не поправили ситуацию. Тогда я решила восстановиться с последнего инкрементального архива, который был выполнен автоматически ночью 24-го июля в 00:01:02. В восстановлении мне было отказано. Причина отказа - база находится в несогласованном состоянии.

Если кто-то может помочь в выяснении причны сбоя, готова предложить необходимые логи.
...
Рейтинг: 0 / 0
04.08.2010, 22:07
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36776374
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
madijaЕсли кто-то может помочь в выяснении причны сбоя, готова предложить необходимые логи.Дайте db2diag.log заархивированный с сервера.
...
Рейтинг: 0 / 0
05.08.2010, 09:34
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36776427
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Mark Barinstein,
...
Рейтинг: 0 / 0
05.08.2010, 10:11
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36776454
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Mark Barinstein,
...
Рейтинг: 0 / 0
05.08.2010, 10:26
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36776459
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Mark Barinstein,
...
Рейтинг: 0 / 0
05.08.2010, 10:27
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36776465
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Mark Barinstein,
...
Рейтинг: 0 / 0
05.08.2010, 10:29
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36776604
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
madija,

Оно обнаружило проблему - файл или каталог /home/db2inst/STRAH/sth_cntr_dict недоступен:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
2010-07-24-10.46.57.045578+240 I12877813E550       LEVEL: Severe
PID     : 5906                 TID  : 47406443915584PROC : db2sysc
INSTANCE: db2inst              NODE : 000          DB   : STRAH
APPHDL  : 0-7                  APPID: GA051EEF.C909.100724064519
AUTHID  : DB2INST 
EDUID   : 20                   EDUNAME: db2agent (STRAH)
FUNCTION: DB2 UDB, buffer pool services, sqlbFetchAndStoreContainerFSInfo, probe:10
MESSAGE : ECF=0x90000002=-1879048190=ECF_FAILED
          Failed
DATA #1 : File name, 33 bytes
/home/db2inst/STRAH/sth_cntr_dict

2010-07-24-10.46.57.048946+240 I12878364E563       LEVEL: Error
PID     : 5906                 TID  : 47406443915584PROC : db2sysc
INSTANCE: db2inst              NODE : 000          DB   : STRAH
APPHDL  : 0-7                  APPID: GA051EEF.C909.100724064519
AUTHID  : DB2INST 
EDUID   : 20                   EDUNAME: db2agent (STRAH)
FUNCTION: DB2 UDB, buffer pool services, sqlbStartUsingDir, probe:815
MESSAGE : ECF=0x90000002=-1879048190=ECF_FAILED
          Failed
DATA #1 : <preformatted>
Error starting to use directory /home/db2inst/STRAH/sth_cntr_dict.

Выдало приложению SQLCODE -290:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
2010-07-24-10.46.57.052693+240 E12879399E587       LEVEL: Info
PID     : 5906                 TID  : 47406443915584PROC : db2sysc
INSTANCE: db2inst              NODE : 000          DB   : STRAH
APPHDL  : 0-7                  APPID: GA051EEF.C909.100724064519
AUTHID  : DB2INST 
EDUID   : 20                   EDUNAME: db2agent (STRAH)
FUNCTION: DB2 UDB, buffer pool services, sqlbStartPools, probe:30
MESSAGE : ADM6023I  The table space "STH_TBSP_DICT" (ID "12") is in state 
          0x"0".  The table space cannot be accessed.  Refer to the 
          documentation for SQLCODE -290.

Поместило tablespace STH_TBSP_DICT в OFFLINE & ROLLFORWARD PENDING:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
2010-07-24-10.46.57.060272+240 E12881005E567       LEVEL: Error
PID     : 5906                 TID  : 47406443915584PROC : db2sysc
INSTANCE: db2inst              NODE : 000          DB   : STRAH
APPHDL  : 0-7                  APPID: GA051EEF.C909.100724064519
AUTHID  : DB2INST 
EDUID   : 20                   EDUNAME: db2agent (STRAH)
FUNCTION: DB2 UDB, buffer pool services, sqlbStartPoolsErrorHandling, probe:39
MESSAGE : ADM6080E  The table space "STH_TBSP_DICT" (ID "12"), was put OFFLINE 
          and in ROLLFORWARD_PENDING. Tablespace state is 0x"00004080".

Проблемы с недоступностью решились, STH_TBSP_DICT переключилось в ROLLFORWARD PENDING:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
2010-07-24-11.19.59.246570+240 E12908033E589       LEVEL: Info
PID     : 5906                 TID  : 47406230006080PROC : db2sysc
INSTANCE: db2inst              NODE : 000          DB   : STRAH
APPHDL  : 0-246                APPID: 10.5.30.115.45969.100724071955
AUTHID  : DB2INST 
EDUID   : 291                  EDUNAME: db2agent (STRAH)
FUNCTION: DB2 UDB, buffer pool services, sqlbStartPools, probe:62
MESSAGE : ADM6048I  The table space "STH_TBSP_DICT" (ID "12"), which was 
          previously OFFLINE has been brought back ONLINE.  The table space 
          state is 0x"00000080".

Дальше вам надо было просто накатить STH_TBSP_DICT до конца логов.
Но вы стали восстанавливать базу из архива...
...
Рейтинг: 0 / 0
05.08.2010, 11:23
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36776703
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
А в чем причина изначальной недоступности контейнера?
...
Рейтинг: 0 / 0
05.08.2010, 11:57
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36776818
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
GuzyaА в чем причина изначальной недоступности контейнера?Не знаю.
Это средствами ОС надо смотреть.
У вас в 2010-07-24-00.26.30 какая-то авария произошла - даже в лог не дописалось до конца.
И только в 2010-07-24-10.46.43 db2start был.
Что происходило между этими отменками времени - неизвестно.
...
Рейтинг: 0 / 0
05.08.2010, 12:34
| Ответить | Цитировать | Написать  
Неудачное восстановление инкрементального бэкапа
    #36778089
madija
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
madija
Гость
Mark Barinstein,
Db2 я перезапустила после того как перезапуск веб-сферы не решил проблему с невозможностью подключения.
Пользователи меня торопили.
И, так как перезапуск db2 тоже не решил проблему, решилась восстанавливаться и команду на восстановление я дала еще да 11 часов. И мне ведь было отказано в всосстановлении. Да и не разобралась бы я этим сама. Это я за эти 10 дней много чего начиталась, а тогда, в отсутствии администратора. который был в отпуске, для меня это решение не казалось рискованным, тем более, что я считала. что еженочно выполняется полный бэкап базы. Обидно, стыдно, но, к сожалению, невозможно вернуть ситуциию назад.
С
...
Рейтинг: 0 / 0
05.08.2010, 18:53
| Ответить | Цитировать | Написать  
56 сообщений из 56, показаны все 3 страниц
  все  
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Неудачное восстановление инкрементального бэкапа
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]