|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
01.09.2011, 17:34
|
|||
|---|---|---|---|
Инкрементальный бэкап 1го уровня |
|||
|
#18+
Коллеги, добрый день! Н.у.: Solaris 10 IDS 9.40FC9 бэкап проводится с помощью Veritas NetBackup(утилита onbar) После переезда на новое железо и на новый Informix Server(c IDS 9.40FC6 на IDS 9.40FC9) возникла следующая проблема: https://www-304.ibm.com/support/docview.wss?uid=swg21429486 Бэкап 0-го уровня помогает только на полдня. После чего снова возникает данная ошибка. Может кто сталкивался? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.09.2011, 17:46
|
|||
|---|---|---|---|
Инкрементальный бэкап 1го уровня |
|||
|
#18+
rhps, В новых версиях делались правки, чтобы timestamp реже инкрементился. Речь про v11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.09.2011, 18:00
|
|||
|---|---|---|---|
Инкрементальный бэкап 1го уровня |
|||
|
#18+
DrGonzo, миграция на 11 версию стоит в планах. Но в данный момент невозможна. Что и где нужно подправить, чтобы решить данную проблему? До переезда с одной машины с IDS 9.40 FC6 на другую с IDS 9.40 FC9 все работало в штатном режиме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.09.2011, 18:06
|
|||
|---|---|---|---|
Инкрементальный бэкап 1го уровня |
|||
|
#18+
rhpsБэкап 0-го уровня помогает только на полдня. После чего снова возникает данная ошибка. А какая у вас стратегия бэкапа? Если после бэкапа 0-го уровня проводились действия над чанками и dbspace-ами, необходимо произвести бэкап 0-го уровня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.09.2011, 18:13
|
|||
|---|---|---|---|
Инкрементальный бэкап 1го уровня |
|||
|
#18+
Ikir, фуллбэкап проходит раз в неделю, инкрементальные бэкапы раз в день. Плюс бэкапы логов по заполнению... Изменения чанков и спейсов не проводились. Бэкап 0го уровня провел вне расписания, потому что было рекомендовано в описании ошибки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.09.2011, 16:21
|
|||
|---|---|---|---|
Инкрементальный бэкап 1го уровня |
|||
|
#18+
в дополнение запуск бэкапа логов по заполнению происходит через log_full.sh 15:01:05.969 [5674] <2> process_request: user backup request = 329199 53 informix informix database db database /usr /openv/netbackup/logs/user_ops/dbext/logs/2080.0.1314961265 NONE NONE 0 0 6 0 C C C C C 0 0 0 0 0 запуск руками onbar -b -l 09:55:15.211 [13882] <2> process_request: user backup request = 329199 53 informix informix db db db /usr/openv/netb ackup/logs/user_ops/dbext/logs/1047.0.1314942914 NONE NONE 0 0 6 0 C C C C C 0 0 0 0 0 То есть ошибка в первом механизме, так как второй отрабатывает штатно. database - имя хоста до миграции db - текущий хост Может ли где-то в базе или в параметрах базы остаться старое имя хоста? Где еще можно поискать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.09.2011, 11:14
|
|||
|---|---|---|---|
|
|||
Инкрементальный бэкап 1го уровня |
|||
|
#18+
rhpsКоллеги, добрый день! Н.у.: Solaris 10 IDS 9.40FC9 бэкап проводится с помощью Veritas NetBackup(утилита onbar) После переезда на новое железо и на новый Informix Server(c IDS 9.40FC6 на IDS 9.40FC9) возникла следующая проблема: https://www-304.ibm.com/support/docview.wss?uid=swg21429486 Бэкап 0-го уровня помогает только на полдня. После чего снова возникает данная ошибка. Может кто сталкивался? Гм, аналогичная картина была тоже на IDS 10.00FC5 на платформе Solaris 10 Но, у меня немного другие взгляды на расписание бекапов, в силу ряда причин я приверженец токо бекапа 0 уровня. Было несколько серверов Информикс на AIX и 2 на Solaris - один нагружен поболее, другой меньше. Бекап 0 делался каждый день ночью(запускали руками в силу регламента). На сервере, который нагружен поболее, каждый день в р-не 10:00 появлялись сообщения - след. бекап должен быть 0 уровня. Так как у нас бекапы делались все время 0 уровня - просто забили на этот момент. Timestamp это такое специфическое явление, что его можно накрутить, а зная ошибки пред. версий связанные с ним, делаем все время архив 0. Если разбираетесь в процессах, которые работают с сервером Информикс, можете помониторить timestamp и связать его изменение с сессией/процессом. Сейчас, на другой системе на 11.50FC5W2, подобные сообщения несколько раз попадались на RSS сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
04.10.2011, 14:59
|
|||
|---|---|---|---|
Инкрементальный бэкап 1го уровня |
|||
|
#18+
Прислали ответ от IBM: "In case you absolutely need to perform L 1 backups, there's a configuration (onconfig) parameter CCFLAGS which, when set to 0x400000, would internally switch to an alternate physical log mechanism and no longer increment the timestamp such quickly." Буду пробовать на днях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.10.2011, 12:31
|
|||
|---|---|---|---|
Инкрементальный бэкап 1го уровня |
|||
|
#18+
rhpsCCFLAGS which, when set to 0x400000 Этот же флаг лет 7+ назад рекомендовали к установке, чтобы ontape при бекапе "очень старых" по его мнению страниц не перезаписывал их. У меня на 9-ке архив 0-го уровня 100Гб базы выполнялся от 2-ух часов до 2-ух дней (в последнем случае сервер практически не вылазил из чекпоинта). CCFLAGS кстати тогда мне не помог, возможно из-за достаточно старой версии Informix 9.21UC2 под Solaris X86. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.10.2011, 10:16
|
|||
|---|---|---|---|
Инкрементальный бэкап 1го уровня |
|||
|
#18+
rhpsПрислали ответ от IBM: "In case you absolutely need to perform L 1 backups, there's a configuration (onconfig) parameter CCFLAGS which, when set to 0x400000, would internally switch to an alternate physical log mechanism and no longer increment the timestamp such quickly." Буду пробовать на днях. Ну, вроде как помогло =) "2011-10-08 22:30:12 18336 18334 /opt/informix/Ifx940FC6/bin/onbar_d complete, returning 0 (0x00) 2011-10-09 01:01:19 6241 6239 /opt/informix/Ifx940FC6/bin/onbar_d -b -w -L 1 2011-10-09 01:01:19 6241 6239 Working with veritas-netbackup as generic storage manager. 2011-10-09 01:02:04 6241 6239 Begin level 1 backup rootdbs. 2011-10-09 01:02:05 6241 6239 Successfully connected to Storage Manager. 2011-10-09 01:05:44 6241 6239 Completed level 1 backup rootdbs (Storage Manager copy ID: 1 1318107818). 2011-10-09 01:05:44 6241 6239 Begin level 1 backup log_dbs. 2011-10-09 01:09:39 6241 6239 Completed level 1 backup log_dbs (Storage Manager copy ID: 1 1318108067). 2011-10-09 01:09:39 6241 6239 Begin level 1 backup blobs_2. 2011-10-09 01:16:39 6241 6239 Completed level 1 backup blobs_2 (Storage Manager copy ID: 1 1318108323). 2011-10-09 01:16:39 6241 6239 Begin level 1 backup idx_dbs. 2011-10-09 01:21:51 6241 6239 Completed level 1 backup idx_dbs (Storage Manager copy ID: 1 1318108780). 2011-10-09 01:21:51 6241 6239 Begin level 1 backup sblobs. 2011-10-09 01:25:06 6241 6239 Completed level 1 backup sblobs (Storage Manager copy ID: 1 1318108993). 2011-10-09 01:25:06 6241 6239 Begin level 1 backup workdbs. 2011-10-09 01:49:04 6241 6239 Completed level 1 backup workdbs (Storage Manager copy ID: 1 1318109229). 2011-10-09 01:49:05 6241 6239 Begin backup logical log 238393. 2011-10-09 01:49:05 6241 6239 Successfully connected to Storage Manager. 2011-10-09 01:52:40 12897 12895 /opt/informix/Ifx940FC6/bin/onbar_d -b -l 2011-10-09 01:52:40 12897 12895 Working with veritas-netbackup as generic storage manager. 2011-10-09 01:52:41 12897 12895 (-43395) A log backup is already running. Can't start another. 2011-10-09 01:52:46 12897 12895 (-43395) A log backup is already running. Can't start another. 2011-10-09 01:52:51 12897 12895 (-43395) A log backup is already running. Can't start another. 2011-10-09 01:52:56 12897 12895 /opt/informix/Ifx940FC6/bin/onbar_d complete, returning 152 (0x98) 2011-10-09 01:53:02 6241 6239 Completed backup logical log 238393 (Storage Manager copy ID: 1 1318110660). 2011-10-09 01:53:03 6241 6239 /opt/informix/Ifx940FC6/bin/onbar_d complete, returning 0 (0x00) 2011-10-09 04:34:51 1141 1139 /opt/informix/Ifx940FC6/bin/onbar_d -b -l" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=44&tablet=1&tid=1607232]: |
0ms |
get settings: |
4ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
49ms |
get topic data: |
4ms |
get forum data: |
0ms |
get page messages: |
322ms |
get tp. blocked users: |
2ms |
| others: | 306ms |
| total: | 695ms |
| 0 / 0 |
