|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
Вкратце, описание проблемы. Есть рухнувший сервер, есть архив 0, сделанный через onbar, есть журналы. Данных очень много. Решил восстанавливать в два этапа, в первую очередь сначала самые нужные чанки, потом менее нужные. После первого этапа восстановления сервер в онлайне, новые данные подгружаются, старые пока недоступны, поэтому стартую второй этап, начинаю их восстанавливать из архива. Физическое восстановление второго этапа длилось неделю, начинается логическое восстановление, и тут проблема, не хватает темпового пространства для накатывания логических журналов, onbar вываливается c ошибкой, чанки вновь в дауне. Что делать, как начать с точки останова, чтобы не повторять второй этап сначала? PS: Естественно, наученный горьким опытом, темпового пространства я добавил. С уважением, Виктор ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2013, 15:35 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
victor16Вкратце, описание проблемы. Есть рухнувший сервер, есть архив 0, сделанный через onbar, есть журналы. Данных очень много. Решил восстанавливать в два этапа, в первую очередь сначала самые нужные чанки, потом менее нужные. После первого этапа восстановления сервер в онлайне, новые данные подгружаются, старые пока недоступны, поэтому стартую второй этап, начинаю их восстанавливать из архива. Физическое восстановление второго этапа длилось неделю, начинается логическое восстановление, и тут проблема, не хватает темпового пространства для накатывания логических журналов, onbar вываливается c ошибкой, чанки вновь в дауне. Что делать, как начать с точки останова, чтобы не повторять второй этап сначала? PS: Естественно, наученный горьким опытом, темпового пространства я добавил. С уважением, Виктор Пробывали сделать: onbar -RESTART (Restarting a failed restore) ? С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2013, 21:52 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
GVF112GVFvictor16Вкратце, описание проблемы. Есть рухнувший сервер, есть архив 0, сделанный через onbar, есть журналы. Данных очень много. Решил восстанавливать в два этапа, в первую очередь сначала самые нужные чанки, потом менее нужные. После первого этапа восстановления сервер в онлайне, новые данные подгружаются, старые пока недоступны, поэтому стартую второй этап, начинаю их восстанавливать из архива. Физическое восстановление второго этапа длилось неделю, начинается логическое восстановление, и тут проблема, не хватает темпового пространства для накатывания логических журналов, onbar вываливается c ошибкой, чанки вновь в дауне. Что делать, как начать с точки останова, чтобы не повторять второй этап сначала? PS: Естественно, наученный горьким опытом, темпового пространства я добавил. С уважением, Виктор Пробывали сделать: onbar -RESTART (Restarting a failed restore) ? С уважением, Вадим. FYI ... Do not use the -RESTART option if a failure occurs during a warm logical restore !!! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2013, 21:54 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
GVF112GVFGVF112GVFпропущено... Пробывали сделать: onbar -RESTART (Restarting a failed restore) ? С уважением, Вадим. FYI ... Do not use the -RESTART option if a failure occurs during a warm logical restore !!! Да, Вы правы, если сбой произошел на этапе логического восстановления onbar -RESTART бесполезен. Мне больше понравилась опция onbar -r -e <dbspace>, после которой чанки перешли в online, однако Informix категорически отказался накатывать на них логические журналы :) У меня по всей видимости вариантов нет, времени тоже, или техсаппорт с ихней луковицей, или начать восстанавливать заново. Честно говоря, после ихнего onion, по-любому они не гарантируют нормальной работы сервера и рекомендуют выполнить полный экспорт/импорт данных, что в конечном итоге только еще больше увеличит общее время восстановления. А у меня в принципе, работа уже идет, новые данные поступают и обрабатываются. Ну что ж, видимо руководству придется еще неделю обходится без их любимых отчетов :) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2013, 07:15 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
victor16GVF112GVFпропущено... FYI ... Do not use the -RESTART option if a failure occurs during a warm logical restore !!! Да, Вы правы, если сбой произошел на этапе логического восстановления onbar -RESTART бесполезен. Мне больше понравилась опция onbar -r -e <dbspace>, после которой чанки перешли в online, однако Informix категорически отказался накатывать на них логические журналы :) У меня по всей видимости вариантов нет, времени тоже, или техсаппорт с ихней луковицей, или начать восстанавливать заново. Честно говоря, после ихнего onion, по-любому они не гарантируют нормальной работы сервера и рекомендуют выполнить полный экспорт/импорт данных, что в конечном итоге только еще больше увеличит общее время восстановления. А у меня в принципе, работа уже идет, новые данные поступают и обрабатываются. Ну что ж, видимо руководству придется еще неделю обходится без их любимых отчетов :) Для отчетов очень хорошо подходит IDS +IWA или связка DB2 BLU v.10.5 + Cognos BI. Относительно onion - это инструмент работает на уровне дисковых структур сервера Informix. Для работы на уровне SQL, используется другой инструмент. Вообще, ребята из группы поддержки все правильно сказали. Должны быть отработы процедуры восстановления и действие персонала в случае форс-мажорных ситуаций. Были такие случае, когда резервное архивирование выполнялось, но никто никогда не пробывал восстановить данные. Соответственно, когда пробил час "X" - все оказались в ситуации - "Шеф - все пропало ..." ... :) Нужен хорошо проработанный "action plan" и навыки работы внештатной ситуации. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2013, 21:43 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
victor16... не хватает темпового пространства для накатывания логических журналов, onbar вываливается c ошибкой, чанки вновь в дауне. Что делать, как начать с точки останова, чтобы не повторять второй этап сначала? PS: Естественно, наученный горьким опытом, темпового пространства я добавил. С уважением, Виктор Сколько места не хватило если не секрет? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2013, 10:20 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
Andronvictor16... не хватает темпового пространства для накатывания логических журналов, onbar вываливается c ошибкой, чанки вновь в дауне. Что делать, как начать с точки останова, чтобы не повторять второй этап сначала? PS: Естественно, наученный горьким опытом, темпового пространства я добавил. С уважением, Виктор Сколько места не хватило если не секрет? Нет, не секрет. По моим расчетам должно было хватить 850 гБ, именно столько я и добавил. Однако для меня оказалось неприятным сюрпризом, что новые данные, поступившие уже после восстановления, тоже будут обрабатываться в процессе логического восстановления. Не хватило всего каких-то 50 гБ. Сейчас, учитывая, что данные продолжают поступать, добавил еще 850 гБ. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2013, 10:58 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
Я правильно понял, что вам нужно для развертывания базы 900ГБ tempdbs? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2013, 21:47 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
bk0010Я правильно понял, что вам нужно для развертывания базы 900ГБ tempdbs? да, правда, сейчас уже чуть больше ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2013, 15:00 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
Для чего у вас используется столько места в tempdbs при восстановлении? Индексы пересоздаются? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2013, 17:30 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
AndronДля чего у вас используется столько места в tempdbs при восстановлении? Индексы пересоздаются? Из документации: "To avoid overwriting the current logical log, the database server writes the logical-log files that you designate for replay to temporary space. Therefore, a warm restore requires enough temporary space to hold the logical log or the number of log files being replayed" Соответственно ответ таков: чтобы при warm restore в фазе логического восстановления хватило место для проигрывания ВСЕХ логических журналов, в том числе и созданных после завершения cold restore. Индексы здесь ни причем. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2013, 20:07 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
А какой версии у вас информикс? Вообще какой то странный механизм - вытащить все необходимые журналы из StorageManager и только потом их начать накатывать. Тем более в приведенной вами цитате не написано что информикс должен вытащить вообще все эти журналы сразу. Может имеет место баг? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 14:44 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
Andron, Да никакой это не баг. Просто когда это все разрабатывалось, никто не думал, что люди будут по 900Гб логических журналов восстанавливать. А в поддержке скорее всего сказали бы, что надо бэкапы делать чаще, чтоб так много логов не накатывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 07:17 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
DrGonzoнадо бэкапы делать чаще Куда уж чаще, архив 0 еженедельно запускается вечером по пятницам, к понедельнику заканчивается. Мне кажется надо грешить на скорость связки onbar+ISM, потому что ontape работает much faster. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 09:06 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
DrGonzo, Ну хорошо, реализация была сделана давно, с тех пор базы подросли :) вполне реальная ситуация когда размер базы настолько большой что и бэкап часто не сделаешь (доп. нагрузка на систему), а транзакции генерят журналы на многие десятки гигов, если не сотни. Наверно для victor16 будет логично зарегистрировать в саппорте проблему, чтобы такое поведение исправили, вопрос про версию информикса был, может в новой уже работает не так? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 11:16 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
victor16Куда уж чаще, архив 0 еженедельно запускается вечером по пятницам, к понедельнику заканчивается. Мне кажется надо грешить на скорость связки onbar+ISM, потому что ontape работает much faster. У OnBar серьезный лимит размера траспортного буффера (около 64K), чего у ontape нет. Поэтому ontape может быть реально быстрее. Этот недостаток вроде исправили в 12й версии - транспортный буффер теперь куда больше при работе с PSM. Кажется обещали сделать и для Tivoli Storage Manager (TSM), т.к. он IBM-овский и XBSA либа может быть легко поправлена. Со всеми остальными сторадж менеджерами ситуация в 12й версии такая же, как и в предыдущих. AndronDrGonzo, Ну хорошо, реализация была сделана давно, с тех пор базы подросли :) вполне реальная ситуация когда размер базы настолько большой что и бэкап часто не сделаешь (доп. нагрузка на систему), а транзакции генерят журналы на многие десятки гигов, если не сотни. Наверно для victor16 будет логично зарегистрировать в саппорте проблему, чтобы такое поведение исправили, вопрос про версию информикса был, может в новой уже работает не так? Не слышал о каких-либо изменениях в этой области. Полагаю, что так все и осталось до сих пор. Проблему зарегистрировать можно и на худой конец попросить расценить ее как feature request. Только вот victor16 это вряд ли поможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 11:38 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
Andronвопрос про версию информикса был 11.70FC7W2 DrGonzoТолько вот victor16 это вряд ли поможет. Это точно DrGonzoУ OnBar серьезный лимит размера траспортного буффера (около 64K), чего у ontape нет. Этот недостаток вроде исправили в 12й версии Мы решили, что переходить на 12-ю версию рановато пока ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 11:46 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
victor16, а делать архив 1-го level ежедневно, не решило бьі вопрос? Или в onbar такого счастья нет? Ето я как крестьянин от сохи спрашиваю, погрязший в ontape, видимо на всегда. С 1-го октября у меня Informix снят с боевого дежурства. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 11:57 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
Daugavaа делать архив 1-го level ежедневно, не решило бьі вопрос? обычно делалось, но в тот раз была не судьба, это вопрос отдельного топика и не связанного с Informix :) Да и не в этом дело-то, на самом деле, а в том, что при warm restore какого-нибудь пространства накатываются ВСЕ логи, а не только сделанные ПЕРЕД падением сервера. Т.е. сервер упал, я восстановил требуемые в первую очередь пространства (cold restore), работа пошла, логи опять заполняются с немалой скоростью, я начинаю восстанавливать остальные пространства (warm restore), и тут, бац, засада, серверу обязательно нужно прокатывать ВСЕ журналы, в том числе и новые, уже СДЕЛАННЫЕ ПОСЛЕ cold restore, т.е. никаким боком не относящиеся к новым пространствам. А это уже совсем другие numbers ... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 12:20 |
|
Проблема при восстановлении
|
|||
---|---|---|---|
#18+
victor16засада, серверу обязательно нужно прокатывать ВСЕ журналы, в том числе и новые, уже СДЕЛАННЫЕ ПОСЛЕ cold restore, никаким боком не относящиеся к восстанавливаевым через warm restore пространствам. А это уже совсем другие numbers ... Подумалось, а если скорость заполнения новых журналов будет выше скорости накатывания старых, то теоретически возможно, что архив и не восстановится совсем :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 16:13 |
|
|
start [/forum/topic.php?fid=44&tid=1607013]: |
0ms |
get settings: |
23ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
561ms |
get tp. blocked users: |
2ms |
others: | 16ms |
total: | 683ms |
0 / 0 |