|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
Сервер IDS 9.40UC2 под RHEL 4.6 При восстановлении из резервной копии с помощью ontape -r получаю неработающий сервер с сообщениями об ощибках: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.
На сервере, с которого делалась резервная копия имеем: Запрос: select * from systabname where partnum = 9437185 дает: Код: plaintext 1. 2. 3. 4. 5.
Выполнение 'oncheck -pt 9437185' дает: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
На сервере, который восстанавливаю: DBSpace datadbs2 состоит из одного чанка и находится в OffLine. Этот DBSpace восстановился до нормального размера, а следующие за ним не восстановились. Т.к. восстановление из архива было плановым, есть время спокойно подумать, что делать дальше. Т.к. в этом DBSpace занято всего 1.5 ГБ под таблицы справочники, то можно просто перенести их в другое место и грохнуть пустой DBSpace. Но хотелось бы узнать и другие пути решения проблемы. Так же тревожит, что у меня нет актуальных резервных копий :-( Прошу советов. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.04.2010, 13:41 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
повторное восстановление дает такой же результат? Чанки как делали? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.04.2010, 14:45 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
некому Т.к. восстановление из архива было плановым, есть время спокойно подумать, что делать дальше. Т.к. в этом DBSpace занято всего 1.5 ГБ под таблицы справочники, то можно просто перенести их в другое место и грохнуть пустой DBSpace. Но хотелось бы узнать и другие пути решения проблемы. Так же тревожит, что у меня нет актуальных резервных копий :-( Прошу советов. Чтобы дать хоть какие-то советы нужно понять все, что вы написали. Лично мне далеко не все понятно. Например: Что мешает сделать актуальную резервную копию ? Как (какой командой) вы делали копию, с которой восстанвливаетесь ? На каком сервере выполнялся oncheck ? Зачем переносить таблицы и грохать пустой dbspace и на каком сервере? Ранее вы делали такое восстановление сервера с резервной копии и на этой платформе ? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.04.2010, 15:52 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
vasilisнекому Т.к. восстановление из архива было плановым, есть время спокойно подумать, что делать дальше. Т.к. в этом DBSpace занято всего 1.5 ГБ под таблицы справочники, то можно просто перенести их в другое место и грохнуть пустой DBSpace. Но хотелось бы узнать и другие пути решения проблемы. Так же тревожит, что у меня нет актуальных резервных копий :-( Прошу советов. Чтобы дать хоть какие-то советы нужно понять все, что вы написали. Лично мне далеко не все понятно. Например: Что мешает сделать актуальную резервную копию ? Как (какой командой) вы делали копию, с которой восстанвливаетесь ? На каком сервере выполнялся oncheck ? Зачем переносить таблицы и грохать пустой dbspace и на каком сервере? Ранее вы делали такое восстановление сервера с резервной копии и на этой платформе ? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.04.2010, 16:49 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
Может среди нас и есть провидцы, но большинство к ним не относится. Форум может помочь, но обучаться с 0 в форуме это самоубийство. если не знаете что у вас спросили, то просто опишите ПОДРОБНЫЙ порядок ваших действий с командами. Тут после работы ходил в бювет за водичкой и чет вспомнилась подобная ситуация. еще вопросы: 1. вы восстанавливаетесь с помощью утилиты onbar? 2. в момент восстановления на сервере, откуда был сделан архив активно пишутся логи? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 01:27 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
zaietsесли не знаете что у вас спросили, то просто опишите ПОДРОБНЫЙ порядок ваших действий с командами. абсолютно верно, а то вопросов можно задавать много ... zaiets1. вы восстанавливаетесь с помощью утилиты onbar? нет некомуПри восстановлении из резервной копии с помощью ontape -r zaiets2. в момент восстановления на сервере, откуда был сделан архив активно пишутся логи? тут я сам вопрос не понял :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 11:37 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
Ага - ontape в самом начале написано - не досмотрел. была подобная ситуация с onbar. Когда восстанавливали тестовый сервер с помощью onbar и во время лог. восстановления основной сервер активно писал логи (логи маленькие), восстановление тоже вылетало с подобной ошибкой. Поэтому и этот непонятный вопрос. Тогда поличилось восстановлением на указанный момент. С ontape вроде ни разу не было подобных проблем, правда все время работаем с raw devices. ошибка вроде как при лог восстановлении - если никак не восстанавливается - можно сделать физ. восстановление и перевести сервер в стандард. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 11:54 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
Спасибо за участие. Постараюсь ответить на ваши вопросы: авторЧто мешает сделать актуальную резервную копию ? Я имел ввиду, что архив, с которого не получается восстановиться, не совсем архив :-) авторКак (какой командой) вы делали копию, с которой восстанвливаетесь ? ontape -s -L 0 . архивирование делается каждую ночь в 23.30. В это время нагрузка на сервер минимальна. авторНа каком сервере выполнялся oncheck ? На сервере, где создавался архив. авторЗачем переносить таблицы и грохать пустой dbspace и на каком сервере? На сервере, где создавался архив. Т.к. мне кажется, что проблема именно в этом dbspace Код: plaintext 1. 2.
Наблюдая за процессом восстановления могу сказать, то вначале создается несколько чанков, затем они заполняются данными. Затем создается тот самый проблемный Chunk 13. После того, как он достигнет своего реального размера в логе полявляются сообщения об ошибках, а ontape спрашивает "Восстановить архив 1 уровня?". Т.е. это случается в момент когда в созданный чанк начинают заливаться данные из архива. Остальные чанки не создаются, т.е. файлы остаются нулевого размера. Вот еще раз кусок лога (более полный): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64.
авторРанее вы делали такое восстановление сервера с резервной копии и на этой платформе ? Восстановление делаю ~1 раз в два месяца. Последнее успешное восстановление было как раз 2 месяца назад. Пока эту копию найти не могу, т.к. политика компании, в которой я работаю, не предусматривает длительное хранение архивов. Восстановление пытался делать на сервере, который был снят с боевого дежурства. На нем раньше крутилась другая БД ( больше по объему). Конфигурация всех серверов одинакова. Также я попробовал восстановить на этом сервере ту БД, которая на нем была раньше. Она восстановилась успешно. Попытки восстановить проблемную БД из 4 имеющихся архивом закончились неудачей с одинаковой ощибкой. Была предпринята попытка восстановить проблемную БД на другом тестовом сервере. Ошибка та же. авторЧанки как делали? Чанки на файлах. Создавалить по такой схеме: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 12:32 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
автор Я имел ввиду, что архив, с которого не получается восстановиться, не совсем архив :-) Если сделанній с помощью ontape - то архив, хотя здесь часто путаница между резервной и архивной копией автор Наблюдая за процессом восстановления могу сказать, то вначале создается несколько чанков, затем они заполняются данными. Затем создается тот самый проблемный Chunk 13. После того, как он достигнет своего реального размера в логе полявляются сообщения об ошибках, а ontape спрашивает "Восстановить архив 1 уровня?". Т.е. это случается в момент когда в созданный чанк начинают заливаться данные из архива. Остальные чанки не создаются, т.е. файлы остаются нулевого размера. 1. При восстановлении с архива 0 файлы должны быть не нулевыми. 2. ошибка возникает совсем не в момент когда в чанки начинают заливаться данные. Смотрим лог: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Код: plaintext 1.
В данном случае я могу гадать только на кофейной гуще - что-то не то с логами. Скорее нужно обращаться в саппорт. автор Также я попробовал восстановить на этом сервере ту БД, которая на нем была раньше. Она восстановилась успешно. Попытки восстановить проблемную БД из 4 имеющихся архивом закончились неудачей с одинаковой ощибкой. Была предпринята попытка восстановить проблемную БД на другом тестовом сервере. Ошибка та же. Эти 4 архива были свежие? и за 2 месяца на сервере не было никаких нештатных ситуаций? Могу предложить проверить тиакой вариант восстановления: ontape -p onmode -d secondary xxx (на прописанный в sqlhosts но не существующий сервер) onmode -d standard возможно прокатит, когда-то таким пользовались на 9.21, но это было давно ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 13:17 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
автор1. При восстановлении с архива 0 файлы должны быть не нулевыми. 2. ошибка возникает совсем не в момент когда в чанки начинают заливаться данные. Чанки на файлах. Когда они создаются командой touch, то их размер равен 0. Если во время восстановления наблюдать за активностью дисковой подсистемы, то хорошо видно, что сначала создаются файлы нужного размера, затем туда заливаются данные из архива. Т.е. вначале идет запись на жесткий диск с чанками и размер файлов чанков растет (скажем 5 минут). При этом с диска с архивом ничего не читается. Затем идет чтение с диска с архивом и запись на жесткий диск с чанками (еще 5 минут). К сож. картинки с виртуалки под рукой нет, но наверное на винде это хорошо видно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 13:27 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
авторМогу предложить проверить тиакой вариант восстановления: ontape -p Сделал физическое восстановление. Не помогло :-(( Затык на том же месте. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 13:40 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
некому[quot автор]К сож. картинки с виртуалки под рукой нет А сервер у вас на виртуалке стоит ? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 13:45 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
авторЭти 4 архива были свежие? и за 2 месяца на сервере не было никаких нештатных ситуаций? Каждые две недели. При этом 2 месяца и 2 дня назад на этом сервере была натянута репликация. Т.е. на это время был рабочий архив. Были падения сервера. Все таки версия не слишком удачная :-(( ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 13:45 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
авторА сервер у вас на виртуалке стоит ? пытался восстанавливать и на виртуалке тоже. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 13:47 |
|
Проблема с восстановлением из архива
|
|||
---|---|---|---|
#18+
Скорее за все битый архив и вполне возможно это как-то связано с падениями. Хотя вполне возможно что и признаная бага. Версия старая и вполне возможно, что ошибки таки какие-то были. Попробуйте восстановиться не на uc2 а на версии постарше - uc9 вроде последняя (мы остановились на fc6 в свое время) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2010, 14:30 |
|
|
start [/forum/topic.php?fid=44&msg=36568517&tid=1607594]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
75ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 173ms |
0 / 0 |