powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Map
Форумы / Informix [игнор отключен] [закрыт для гостей] / назначение параметра LOG_INDEX_BUILDS
48 сообщений из 48, показаны все 2 страниц
назначение параметра LOG_INDEX_BUILDS
    #37278090
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
насколько я понял этот параметр при репликации нужен для передачи страниц индекса с основного на вторичный.

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

Так ли я все понял?
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37278357
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88,


Informix Library Справочник администратора IBM Informix Dynamic Server
LOG_INDEX_BUILDS
Значение onconfig.std
0 (выключено)
В случае отсутствия
0 (выключено)
Диапазон значений
0, 1 (0 = выключить, 1 = включить)
Вступает в силу
После остановки и перезапуска сервера баз данных
Утилиты
onmode -wf
onmode -wm
Смотрите
Следующие разделы в публикации IBM Informix Administrator's Reference (Справочник администратора IBM Informix):
onmode -wf, -wm: Динамическое изменение отдельных параметров конфигурации
Утилита onmode

Параметр LOG_INDEX_BUILDS позволяет включить или выключить запись страниц индекса в журнал. Если функция LOG_INDEX_BUILDS включена, степень использования пространства файла логического журнала возрастает в зависимости от размера индексов. Это может привести к тому, что придется чаще производить резервное копирование файла логического журнала. При изменении состоянии записи страниц индекса в журнал в файл online.log записывается сообщение.

Команда onmode -wm позволяет включить или выключить запись страниц индекса в журнал только для текущего сеанса и не влияет на значение данного параметра в файле onconfig. При остановке и перезапуске сервера то, будет ли включена запись страниц индекса в журнал, определяется значением данного параметра в файле onconfig. Поэтому при использовании вторичных серверов RS не рекомендуется включать запись страниц индекса в журнал при помощи команды onmode -wm; вместо этого обновите файл onconfig при помощи команды onmode -wf, тогда после перезапуска сервера запись страниц индекса в журнал будет включена. Запись страниц индекса в журнал при использовании вторичных серверов RS является обязательной.

Дополнительную информацию об утилите onmode смотрите в публикации onmode -wf, -wm: Динамическое изменение отдельных параметров конфигурации.


ТСвторичный будет получать эти страницы, раскатывать у себя и тем самым перестраивать индекс, что приведет к улучшению производительности .
Выделенное не связано с параметром, и совершенно автоматически не следует из факта наличия индекса на первичном ли сервере, на вторичном ли... По факту - вторичный по-любому должен получать эти данные...
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37278522
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛойПо факту - вторичный по-любому должен получать эти данные...
Пардон, точнее по факту - вторичный RS . Остальные вторичные могут либо брать страницы из журнала - либо сами править индекс. При этом индекс на вторичном всё равно остаётся "работоспособным". И, повторюсь, эффект повышения производительности - не обязателен (индексы могут быть как "полезны", так и "вредны").
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37278774
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

я прекрасно понимаю назначение и смысл индексов,а также прочитал доку неоднократно.

Из всего ответа самым полезным была строка:

"Остальные вторичные могут либо брать страницы из журнала - либо сами править индекс."

Вот за это огромное спасибо.Просто иногда при прочтении документации не сразу доходит смысл и поэтому спросил физический смысл данного процесса простыми словами.

Спасибо
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37278876
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88АнатоЛой,
Из всего ответа самым полезным была строка:
"Остальные вторичные могут либо брать страницы из журнала - либо сами править индекс."
...
Спасибо

На здоровье.
Добавлю, что когда говорил "остальные" подразумевал только HDR :).
Итого:
0. RS - берёт индекс только из журнала.
Интересно, если не включить логирование страниц индекса - не заработает RS - или на вторичном просто не будет индекса, или он будет поломан? Ау, кто проверить может?

1. собственно HDR - может править индекс сам или брать из журнала, если он там есть.

2. SD - использует одни и те же диски - этой проблемы нет в принципе.

3. Механизм ER - подразумевает репликацию только данных - и "вторичный" сервер всегда сам занимается своими индексами...

Если любопытно - вот ссылки на доку, из которых делался вывод на "простых словах":

Informix Library1. Руководство администратора IBM Informix Dynamic Server
Воспроизведение обновлений на вторичном сервере баз данных
На всех типах вторичных серверов для репликации данных с первичного сервера используются журналы. Вторичным серверам RS требуется запись в журнал страниц индекса, но вторичные серверы HDR и SD также используют запись в журнал страниц индекса, если она включена.

2. HDR и индексы

3. RS и индексы
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37278910
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

я пробовал RSS. без включенного параметра RSS не поднимается.
В HDR он просит,а в RSS требует)))


Анатолий,подскажите плиз еще 1 вопрос.

Если включить этот параметр LOG_INDEX_BUILDS на вторичном сервере-это помешает работе репликации?

Я считаю,что нет,т.к. этот параметр влияет только на отправку копии страниц в репликационный буфер,а это делает только праймари.

Хочу включить этот параметр на тот случай,если основной поломается и резерв станет основным.

Подтвердите мои слова для уверенности или опровергните)))
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37278916
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88, только практика может подтвердить :(. У меня пока нет возможности проверить.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37278933
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

файл логического журнала это и есть logical buffer, который потом и отправляется на вторичный.ведь так?

ну тогда получается что запись страниц в этот буфер приведет к его более быстрому заполнению и следовательно к более частым checkpoint'ам..

Ведь так?
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37279045
яфшуеі
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Денис_88АнатоЛой,

файл логического журнала это и есть logical buffer, который потом и отправляется на вторичный.ведь так?

ну тогда получается что запись страниц в этот буфер приведет к его более быстрому заполнению и следовательно к более частым checkpoint'ам..

Ведь так?

Н-да ...
Скажу токо 1 - установка этого параметра приводит к тому, что весь индекс после создания попадает в лог.
Поэтому, нужно внимательно относиться к соданию больших индексов - проблемы очевидны.

Если не ошибаюсь - индекс пишется в одной транзакции, хотя с моего последнего занятия вопросом м.б. что-то изменилось.
Обычно для создания больших индексов меняю LTX параметры, поэтому не скажу - есть ли там Long TX.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37279281
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88АнатоЛой,

файл логического журнала это и есть logical buffer, который потом и отправляется на вторичный.ведь так?

ну тогда получается что запись страниц в этот буфер приведет к его более быстрому заполнению и следовательно к более частым checkpoint'ам..

Ведь так?

"файл логического журнала это и есть logical buffer" - ммм.... нет:

1. файл логического журнала - это "область" на диске
2. logical buffer = logical log buffer - это область памяти - ну никак не одно и то же...
3. ...

"ну тогда получается что запись страниц в этот буфер приведет к его более быстрому заполнению "

В общем вы правильный вывод сделали, при полностью ложных предпосылках :)
Если при этом и дальше будете пользоваться "интуитивно-понятными понятиями" - мы так далеко-далеко уедем - но не в ту сторону.... читайте доку по теории :).

"более быстрое заполнению (файла логического журнала приведёт) к более частым checkpoint'ам.." - тут полный бред...

Вы не понимаете ни что такое checkpoint, ни по каким правилам он инициируется...
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37279369
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Денис_88АнатоЛой,

я пробовал RSS. без включенного параметра RSS не поднимается.
В HDR он просит,а в RSS требует)))


Анатолий,подскажите плиз еще 1 вопрос.

Если включить этот параметр LOG_INDEX_BUILDS на вторичном сервере-это помешает работе репликации?

Я считаю,что нет,т.к. этот параметр влияет только на отправку копии страниц в репликационный буфер,а это делает только праймари.

Хочу включить этот параметр на тот случай,если основной поломается и резерв станет основным.

Подтвердите мои слова для уверенности или опровергните)))

Когда Вы включаете LOG_INDEX_BUILDS на Primary и RSS-сервере, то ничинает работать механизм
не блокирующего CheckPoint.

Включение контрольных точек без блокировки задается параметрами конфигурации LOG_STAGING_DIR (на вторичном сервере HDR) и LOG_INDEX_BUILDS (на первичном сервере и на вторичном сервере HDR). Значение параметра LOG_INDEX_BUILDS на обоих указанных серверах должно быть одним и тем же.

При включенных контрольных точках без блокировок задержка применения данных на вторичном сервере может произойти в результате временного сохранения данных журнала на сервере в процессе обработки контрольной точки.

С уважением,
Вадим.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37279375
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Денис_88,

Вы установили RSS_FLOW_CONTRO = -1 на HDR и RSS ?!
Какой результат ?

С уважением,
Вадим.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37279611
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

"более быстрое заполнению (файла логического журнала приведёт) к более частым checkpoint'ам.." - тут полный бред...
Вы не понимаете ни что такое checkpoint, ни по каким правилам он инициируется...


Анатолий, вы неправильно поняли.Более быстрое заполнение логического буфера,а не журнала приведет к более частым к.т. или Вы со мной в этом несогласны?
Да я неправ по поводу сравнения журнала и буфера,но я прекрасно понимаю смысл к.т. и правил инициализации.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37279618
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GVF112GVF,

Вы установили RSS_FLOW_CONTRO = -1 на HDR и RSS ?!

К сожалению нет,потому что начальство поставило сжатые сроки для репликации и пришлось поднять асинхронную hdr.Теперь нет серверов для тестирования RSS. При первой же возможности попробую и отпишусь.
Может быть есть какие-нить другие Ваши контакты,чтобы можно было общаться в течение дня на экстренный случай поднятия RSS?


Включение контрольных точек без блокировки задается параметрами конфигурации LOG_STAGING_DIR (на вторичном сервере HDR) и LOG_INDEX_BUILDS (на первичном сервере и на вторичном сервере HDR). Значение параметра LOG_INDEX_BUILDS на обоих указанных серверах должно быть одним и тем же.


А вот тут могу не согласиться.Я поднимал репликацию RSS при включенном параметре только лишь на основном сервере и логи передавались нормально.Во всех доках и мануалах написано,что должно быть включено на первичном.Также при запуске hdr репликации только лишь в логе основного появилась запись о необходимости включения данного параметра,а вторичный промолчал.
Ведь вторичный получает этот журнал и восстанавливает у себя все,что есть в этом журнале.И если первичный ему отправит копии страниц индекса,то он их и восстановит,чтобы самому не пересобирать индекс..Зачем ему этот параметр?
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37279894
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
то есть этот параметр необходимо включить на обоих серверах для того,чтобы первичный при создании индекса записал данные в журнал,а вторичный при получении журнала и восстановлении записал эту информацию к себе в журнал и потом оттуда ее брал,да?

именно за этим нужно на обоих серверах?
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280068
яфшуеі
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Денис_88то есть этот параметр необходимо включить на обоих серверах для того,чтобы первичный при создании индекса записал данные в журнал,а вторичный при получении журнала и восстановлении записал эту информацию к себе в журнал и потом оттуда ее брал,да?

именно за этим нужно на обоих серверах?

Нет, достаточно на первичном.
Включать LOG_INDEX_BUILDS стоит на всех серверах из соображений, что любой сервер может стать PRI.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280177
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
яфшуеі,

подскажите пожалуйста по поводу физического понимания всего этого процесса?


1) на первичном создается новый индекс, копия этого индекса записывается в журнал при включенном параметре log_index_builds и отправляется на вторичный.вторичный получает этот журнал и создает у себя этот индекс из журнала.А если бы не было индекса в журнале,то вторичному пришлось бы самостоятельно создавать индекс,так?

2)на первичном сервере внесли данные в таблицу, индекс перестроился-как он попадает на вторичный?ситуация аналогична пункту 1 или все неновые индексы автоматически посылают свои изменения?

3)по идее вторичному серверу этот параметр вообще не нужен,если его не будут переводить в первичный сервер,т.к. он лишь накатывает изменения.НО во всех мануалах написано что этот параметр необходимо включить на вторичном и при включении репликации именно вторичный отругался,что должен быть включен этот параметр.

Подскажите плиз?
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280239
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88АнатоЛой,

"более быстрое заполнению (файла логического журнала приведёт) к более частым checkpoint'ам.." - тут полный бред...
Вы не понимаете ни что такое checkpoint, ни по каким правилам он инициируется...


Анатолий, вы неправильно поняли.Более быстрое заполнение логического буфера,а не журнала приведет к более частым к.т. или Вы со мной в этом несогласны?
Да я неправ по поводу сравнения журнала и буфера,но я прекрасно понимаю смысл к.т. и правил инициализации.

1. Я действительно из-за Вашего определения "файл логического журнала это и есть logical buffer" проинтерпретировал фразу "запись страниц в этот буфер приведет к его более быстрому заполнению и следовательно к более частым checkpoint'ам" не так, как вы это объяснили сейчас.

2. "Более быстрое заполнение логического буфера (буфера логического журнала = logical log buffer),а не (самого логического) журнала приведет к более частым к.т., или Вы со мной в этом несогласны?".
Не согласен. Вы путаете причину и следствие.

Ибо не заполнение буфера логического журнала приводит к инициации контрольной точки, а инициация контрольной точки (по любым причинам) является однйо из причин сброса буфера логического журнала собственно в журнал.

Если Вы знаете, переполнение логического журнала может привести к невозможности выполнения контрольной точки (требующей тоже записи в логический журнал).
Поэтому в последних версиях Informix при включенном режиме AUTO_CKPTS сервер теоретически может из-за угрозы переполнения логического журнала (заметьте: не одного из "файлов" этого журнала, а именно всего объёма этого журнала) инициировать контрольную точку.
Вот в такой интерпретации Ваша фраза выглядит истинной :).
А на практике логический журнал в промышленной системе уже давно достаточно растянут, и контрольные точки инициируются другими событиями гораздо чаще, чем происходит переполнение журнала (особенно если резервное копирование отрабатывает по факту заполнения файла журнала, а не по расписанию).
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280302
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

Ибо не заполнение буфера логического журнала приводит к инициации контрольной точки, а инициация контрольной точки (по любым причинам) является однйо из причин сброса буфера логического журнала собственно в журнал.

Анатолий,а как же то,что при заполнение буфера логического журнала приводит к к.т.?Ведь сервер боится переполнения!

Если запустить ресурсоемкий процесс,то буфер будет заполняться быстрее,сервер будет бояться переполнения и сбрасывать этот буфер в журнал.То есть получается так,что чем больше процесс делает изменений, тем чаще происходят к.т.

У нас есть огромный опер. процесс, который выполняется час,так вот во время этого процесса к.т. происходят в разы чаще,чем при простаивании сервера.Больше никто ничего не делает,поэтому других причин для к.т. нет..

Я Вас не понимаю
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280323
яфшуеі
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Денис_88яфшуеі,

подскажите пожалуйста по поводу физического понимания всего этого процесса?


1) на первичном создается новый индекс, копия этого индекса записывается в журнал при включенном параметре log_index_builds и отправляется на вторичный.вторичный получает этот журнал и создает у себя этот индекс из журнала.А если бы не было индекса в журнале,то вторичному пришлось бы самостоятельно создавать индекс,так?

2)на первичном сервере внесли данные в таблицу, индекс перестроился-как он попадает на вторичный?ситуация аналогична пункту 1 или все неновые индексы автоматически посылают свои изменения?

3)по идее вторичному серверу этот параметр вообще не нужен,если его не будут переводить в первичный сервер,т.к. он лишь накатывает изменения.НО во всех мануалах написано что этот параметр необходимо включить на вторичном и при включении репликации именно вторичный отругался,что должен быть включен этот параметр.

Подскажите плиз?

1. После создания индекс передается на вторичный HDR независимо от установки параметра.
Если параметр равен 1 - индекс передается через запись лог. журнала.
Если не установлен - индекс передается напрямую - в логе появляется запись:
DR: Sending ....

2. Изменение значения в индексном поле это логгируемая операция, она пападает в лог. журнал.

3. Какой именно вторичный?
Для RSS не помню - настраивал давно, параметр у меня стоит но с каких соображений - не помню.
Для HDR у меня на 11.50.FC5W2 не ругается.
В принципе, это не так и важно.
Если используете РСС то параметр установили везде и забыли, большие индексы обычно
не создают при активной работе пользователей.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280398
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88АнатоЛой,

Ибо не заполнение буфера логического журнала приводит к инициации контрольной точки, а инициация контрольной точки (по любым причинам) является однйо из причин сброса буфера логического журнала собственно в журнал.

Анатолий,а как же то,что при заполнение буфера логического журнала приводит к к.т.?Ведь сервер боится переполнения!

Если запустить ресурсоемкий процесс,то буфер будет заполняться быстрее,сервер будет бояться переполнения и сбрасывать этот буфер в журнал.То есть получается так,что чем больше процесс делает изменений, тем чаще происходят к.т.

У нас есть огромный опер. процесс, который выполняется час,так вот во время этого процесса к.т. происходят в разы чаще,чем при простаивании сервера.Больше никто ничего не делает,поэтому других причин для к.т. нет..

Я Вас не понимаю

1. Сброс буфера логического журнала (из памяти) в логический журнал (на диск) - это не контрольная точка ... Данный сброс - это регулярный процесс, выполняемый и без контрольной точки...

Повторюсь,
а) причиной сброса буфера может являться контрольная точка, но не только.
б) контрольная точка всегда приводит к сброс буфера.

2. "Ведь сервер боится переполнения!" - следите за руками: "боится переполнения" = "боится переполнения логического журнала ( на диске )" = "боится возникновения заполнения на диске всех "файлов" логического журнала" = "боится возникновения ситуации: на диске некуда записать очередной буфер логического журнала"...

Сервер не "боится" переполнения самого буфера логического журнала . Во-первых, у него их 3 штуки. Во-вторых, единственное узкое место - успеть сбросить хотя бы один, пока заполняются два других... Чтобы сбросить буфер логического журнала на диск (в логический журнал), контрольная точка не нужна - процесс сброса выполняется и без контрольных точек.

Сколько ещё раз всё это повторить?

To All: если я ошибаюсь - поправьте...
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280399
Ikir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88Анатолий,а как же то,что при заполнение буфера логического журнала приводит к к.т.?Ведь сервер боится переполнения!


Сервер "боится" переполнения физического журнала и при заполнении его на 75% инициирует К.Т.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280402
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
яфшуеі,

ОГРОМНОЕ СПАСИБО ЗА ОБЪЯСНЕНИЕ.

вот теперь действительно стало ясно.

я понял то,что на первичном он играет еще какую-то роль,а вот на вторичном на всякий случай на день сбоя и замены на первичный.А в повседневной работе вторичный ничего не пишет и этот параметр ему не нужен.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280446
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88, вдогонку

Посмотрите у себя на сервере LOGBUFF. Рекомендуемое значение буфера логического журнала = 64КБ.
Думаю, что у Вас оно не сильно отличается от рекомендуемого.

Допустим, пихаем мы в БД картинку на 1МБ (не в blob-пространство, чтобы она в логический журнал попадала и на вторичный сервер реплицировалась). И что, по Вашему, нас ждёт 1024 КБ / 64 КБ = 16 контрольных точек?!!!

И с какой частотой и длительностью они выполняются, если у меня сервер успевает без проблем в течение 1 сек записать этот 1 МБ?
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280591
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

LOG_BUFF установлен 2048Кб

Одними из причин к.т. являются заполнение логического буфера или наступление ckptinterval (я не говорю о бэкапах и изменениях табличного пространства).

Так вот расскажу 2 ситуации,которые наблюдал сам лично:

1-на сервере установлен параметр ckptinterval 60
Запускаю опер. процесс и к.т. делаются либо раз в минуту,либо чаще,но его продолжительность была около 30сек, т.е. очень долго, потому что ему нужно было сбросить большое кол-во информации, которая попала в буфер за это время

2-устанавливаю параметр RTO_SERVER_RESTART 60
и к.т. при этом же процессе начинает делаться чаще,но время выполнения становится меньше 0-2сек.
А потому что он делает к.т. с таким расчетом,что на восстановление у него уйдет 60секунд.А за меньшее время и меньше изменений произошло, поэтому к.т. 0-2сек.
Если на сервере не проводить никаких изменений,то к.т. может не выполняться и по 20мин при этом параметре.

Значит все-таки скорость заполнения буфера прямо влияет на частоту и продолжительность к.т.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280594
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Основная тема топика раскрыта, поэтому считаю его закрытым.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280621
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хотя нет...поторопился

кто-нибудь создавал большие индексы с включенным параметром на основном сервере?какие проблемы?Может лучше тогда его не использовать и пусть вторичный сам создает индекс?

Когда Вы включаете LOG_INDEX_BUILDS на Primary и RSS-сервере, то ничинает работать механизм
не блокирующего CheckPoint.
Включение контрольных точек без блокировки задается параметрами конфигурации LOG_STAGING_DIR (на вторичном сервере HDR) и LOG_INDEX_BUILDS (на первичном сервере и на вторичном сервере HDR). Значение параметра LOG_INDEX_BUILDS на обоих указанных серверах должно быть одним и тем же.
При включенных контрольных точках без блокировок задержка применения данных на вторичном сервере может произойти в результате временного сохранения данных журнала на сервере в процессе обработки контрольной точки.
С уважением,
Вадим.


Вадим,поясните плиз свой ответ относительно HDR репликации(не RSS)..Каково Ваше мнение по поводу этого параметра и его предназначения?

Спасибо
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280700
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88АнатоЛой,
...
Одними из причин к.т. являются заполнение логического буфера или ....
На всё вышесказанное мной по этому поводу я давал или могу дать ссылку на офиц.документацию.
Откуда Вы сделали такой вывод - непонятно.

Денис_88Так вот расскажу 2 ситуации,которые наблюдал сам лично:

...
Значит все-таки скорость заполнения буфера прямо влияет на частоту и продолжительность к.т.
Если б не слово "прямо" - можно было бы согласиться...
Если буфер увеличить в два раза при прочих равных условиях работы сервера - думаю, никто не возьмётся "прямо" посчитать хоть приблизительно, изменятся ли частота и продолжительность к.т. и на сколько :). За сим откланиваюсь...
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280708
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88Основная тема топика раскрыта, поэтому считаю его закрытым.
Сорри, не заметил "закрытие" на второй странице. По вопросу к.т. желания что-нить добавить уже не имею :) :(.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280749
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

Если б не слово "прямо" - можно было бы согласиться...
Если буфер увеличить в два раза при прочих равных условиях работы сервера - думаю, никто не возьмётся "прямо" посчитать хоть приблизительно, изменятся ли частота и продолжительность к.т. и на сколько :). За сим откланиваюсь...


Если не брать все остальные причины,по которым может случиться к.т. и представить себе такую идеальную картину,то именно так и будет,что к.т. станет выполняться в 2 раза реже,но дольше..

НО никто не возьмется прямо посчитать это по той причине,что такой чистый эксперимент провести нельзя!Есть много других причин к.т.
Но чисто теоретически это так.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280912
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я не удержался таки :)

Денис_88АнатоЛой,

1-на сервере установлен параметр ckptinterval 60
Запускаю опер. процесс и к.т. делаются либо раз в минуту,либо чаще,но его продолжительность была около 30сек, т.е. очень долго, потому что ему нужно было сбросить большое кол-во информации, которая попала в буфер за это время

Продолжительность к.т. большая, "потому что ему нужно было сбросить большое кол-во (ИЗМЕНЁННОЙ) информации, которая попала в буфер(НЫЙ ПУЛ) за это время"... почувствуйте разницу... Попробуйте при этих настройках уменьшить буферный пул до 64 КБ - и Вы таки всё ещё думаете, что к.т. будут выполняться чаще?

Денис_882-устанавливаю параметр RTO_SERVER_RESTART 60
и к.т. при этом же процессе начинает делаться чаще,но время выполнения становится меньше 0-2сек.
А потому что он делает к.т. с таким расчетом,что на восстановление у него уйдет 60секунд.А за меньшее время и меньше изменений произошло, поэтому к.т. 0-2сек.
Если на сервере не проводить никаких изменений,то к.т. может не выполняться и по 20мин при этом параметре.

Значит все-таки скорость заполнения буфера прямо влияет на частоту и продолжительность к.т.
Если "скорость заполнения буфера" логического журнала мерять в КБ/сек - то да, а если в буферах/сек - то при прочих равных - несущественно :)
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280942
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88АнатоЛой,

Если б не слово "прямо" - можно было бы согласиться...
Если буфер увеличить в два раза при прочих равных условиях работы сервера - думаю, никто не возьмётся "прямо" посчитать хоть приблизительно, изменятся ли частота и продолжительность к.т. и на сколько :). За сим откланиваюсь...


Если не брать все остальные причины,по которым может случиться к.т. и представить себе такую идеальную картину,то именно так и будет,что к.т. станет выполняться в 2 раза реже,но дольше...
Я очень надеюсь, что вы хорошо отличаете между собой такие понятия, как:
1. физический журнал
2. буфферы физического журнала
3. логический журнал
4. буфферы логического журнала
5. буфферный пул.
Всё, устал :(...
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37280980
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

Я очень надеюсь, что вы хорошо отличаете между собой такие понятия, как:
1. физический журнал

файл на диске, содержащий все физические изменения (PHYSLOG).
2. буфферы физического журнала
буффер(кусок памяти), который создается в совместной памяти сервера и хранит физические изменения,а потом сбрасывает их в журнал на диск
3. логический журнал
файл на диске (logical log),содержащий все логические изменения.Именно они передаются на вторичный
4. буфферы логического журнала
буффер(кусок памяти), создаваемый в совместной памяти сервера и временно хранящий логические изменения до сбрасывания на диск в logical log
5. буфферный пул.
кусок совместной памяти необходимый для хранения информации о последних извлеченных данных.Он нужен для более быстрого извлечения данных,чтобы сервер каждый раз не делал заново,а пользовался уже тем,что есть..


Если я в чем-то неправ, буду рад услышать правильный ответ от спеца..

Сам в информиксе 3месяца.

спасибо
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37281181
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88, супер, по основным архитектурым понятиям у нас расхождений нет.
Значит расхождения остались либо только в нюансах этих понятий, либо в понимании процессов по взаимодействию всей этой "дребедени". Если интересно "найти истину" в наших расхождениях - может откроем новый топик?
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37281314
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

может откроем новый топик?

с удовольствием

можно поговорить о физике чекпойнтов и о том,что такое физический журнал..

В физ.журнал попадает только физическое изменение:добавление чанков,изменение размера пространства,да?а что еще?
когда мы делаем любые изменения в физике,это попадает в лог журнала,потом в сам журнал на диск и хранится там.При восстановлении из бэкапа сервер прочитывает этот журнал и восстанавливает физическое строение базы,ведь так всё?
Т.е. в этом журнале содержится информация о табличных пространствах,чанках и т.д.

А вот в логическом журнале хранятся все изменения,связанные с insert,update,drop,delete,alter table add col....,да?
Все эти изменения попадают в буфер лог журнала,потом в журнал и потом во время бэкапа архивируются и хранятся в бэкапе вместе с физ. журналом.А при восстановлении сервер читает сначала физ журнал,а потом уже на восстановленную физику накатывает весь логический журнал.так?

Но вопрос?сколько логических журналов хранится?ведь если я буду делать бэкап каждый день,то получается в каждом файле бэкапа будет новый журнал(допустим что у меня за сутки заполняется весь лог.журнал) и сервер потом будет читать их все?
Например, у меня на сервере всего 100логических логов и каждый имеет размер 262000 страниц
Вот тут немного недопонимаю пока :(

А вот что хранится в бэкапе, который весит под 35Гб?там все физ и логические журналы?и каждый раз он растет за счет того,что во время бэкапа в архивируются новые логические журналы?

Рад пообсуждать
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37281337
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88В физ.журнал попадает только физическое изменение:добавление чанков,изменение размера пространства,да?а что еще?
когда мы делаем любые изменения в физике,это попадает в лог журнала,потом в сам журнал на диск и хранится там.При восстановлении из бэкапа сервер прочитывает этот журнал и восстанавливает физическое строение базы,ведь так всё?
Т.е. в этом журнале содержится информация о табличных пространствах,чанках и т.д.

совсем нет. Физический журнал обеспечивает восстановление после сбоев (выключение питания) и резервное копирование на момент времени (игнорируя изменения транзакций, которые выполняются или выполнились после старта процесса резервного копирования 0, 1 или 2-го уровня). Т.е. запись в физ.журнал напрямую связана с модификациями данных пользователями БД...

Читать для начала здесь .

Денис_88А вот в логическом журнале хранятся все изменения,связанные с insert,update,drop,delete,alter table add col....,да?
Все эти изменения попадают в буфер лог журнала,потом в журнал и потом во время бэкапа архивируются и хранятся в бэкапе вместе с физ. журналом.А при восстановлении сервер читает сначала физ журнал,а потом уже на восстановленную физику накатывает весь логический журнал.так?

физ. журнал в бекапе не хранится. он нужен при быстром восстановлении при краше сервера...

Денис_88Но вопрос?сколько логических журналов хранится?ведь если я буду делать бэкап каждый день,то получается в каждом файле бэкапа будет новый журнал(допустим что у меня за сутки заполняется весь лог.журнал) и сервер потом будет читать их все?
Например, у меня на сервере всего 100логических логов и каждый имеет размер 262000 страниц
Вот тут немного недопонимаю пока :(

А вот что хранится в бэкапе, который весит под 35Гб?там все физ и логические журналы?и каждый раз он растет за счет того,что во время бэкапа в архивируются новые логические журналы?

Рад пообсуждать

бекап - отдельная песня. Позже отвечу....
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37281469
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Денис_88хотя нет...поторопился

кто-нибудь создавал большие индексы с включенным параметром на основном сервере?какие проблемы?Может лучше тогда его не использовать и пусть вторичный сам создает индекс?

Когда Вы включаете LOG_INDEX_BUILDS на Primary и RSS-сервере, то ничинает работать механизм
не блокирующего CheckPoint.
Включение контрольных точек без блокировки задается параметрами конфигурации LOG_STAGING_DIR (на вторичном сервере HDR) и LOG_INDEX_BUILDS (на первичном сервере и на вторичном сервере HDR). Значение параметра LOG_INDEX_BUILDS на обоих указанных серверах должно быть одним и тем же.
При включенных контрольных точках без блокировок задержка применения данных на вторичном сервере может произойти в результате временного сохранения данных журнала на сервере в процессе обработки контрольной точки.
С уважением,
Вадим.


Вадим,поясните плиз свой ответ относительно HDR репликации(не RSS)..Каково Ваше мнение по поводу этого параметра и его предназначения?

Спасибо

Денис,
это относится к конфигурации HDR(primary) <->RSS. Любой RSS потенциально может стать как HDR(Secondary) или
в перспективе HDR(Primary) ... если используется кластерное решение MACH11.

С уважением,
Вадим.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37281494
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GVF112GVF,

Вадим,а если на вторичном сервере hdr не будет указана LOG_STAGING_DIR, то что тогда?

И какая тогда польза от включения этого параметра, если может происходить задержка в накате лога?
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37283262
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Денис_88GVF112GVF,

Вадим,а если на вторичном сервере hdr не будет указана LOG_STAGING_DIR, то что тогда?

И какая тогда польза от включения этого параметра, если может происходить задержка в накате лога?

Если Вы не указали на вторичном сервере LOG_STAGING_DIR, ничего не будет. Этот параметр, используется только
для RSS-сервера. Кто значет, может когда-нибудь, Ваш "Secondary", захочет стать RSS ... ;)

The directory specified by the LOG_STAGING_DIR configuration parameter is used to store logs sent
from the primary server when using the DELAY_APPLY configuration parameter to delay application of log files
on an RS secondary server.


С уважением,
Вадим.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37284617
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GVF112GVF,

ясно..

всем спасибо.

тема закрыта
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37285788
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛойДенис_88В физ.журнал попадает только физическое изменение:добавление чанков,изменение размера пространства,да?а что еще?
когда мы делаем любые изменения в физике,это попадает в лог журнала,потом в сам журнал на диск и хранится там.При восстановлении из бэкапа сервер прочитывает этот журнал и восстанавливает физическое строение базы,ведь так всё?
Т.е. в этом журнале содержится информация о табличных пространствах,чанках и т.д.

совсем нет. Физический журнал обеспечивает восстановление после сбоев (выключение питания) и резервное копирование на момент времени (игнорируя изменения транзакций, которые выполняются или выполнились после старта процесса резервного копирования 0, 1 или 2-го уровня). Т.е. запись в физ.журнал напрямую связана с модификациями данных пользователями БД...

Читать для начала здесь .

Денис_88А вот в логическом журнале хранятся все изменения,связанные с insert,update,drop,delete,alter table add col....,да?
Все эти изменения попадают в буфер лог журнала,потом в журнал и потом во время бэкапа архивируются и хранятся в бэкапе вместе с физ. журналом.А при восстановлении сервер читает сначала физ журнал,а потом уже на восстановленную физику накатывает весь логический журнал.так?

физ. журнал в бекапе не хранится. он нужен при быстром восстановлении при краше сервера...

Денис_88Но вопрос?сколько логических журналов хранится?ведь если я буду делать бэкап каждый день,то получается в каждом файле бэкапа будет новый журнал(допустим что у меня за сутки заполняется весь лог.журнал) и сервер потом будет читать их все?
Например, у меня на сервере всего 100логических логов и каждый имеет размер 262000 страниц
Вот тут немного недопонимаю пока :(

А вот что хранится в бэкапе, который весит под 35Гб?там все физ и логические журналы?и каждый раз он растет за счет того,что во время бэкапа в архивируются новые логические журналы?

Рад пообсуждать

бекап - отдельная песня. Позже отвечу....
Анатолий, мои аплодисменты вашему терпению! У меня терпения не хватило бы, по доброму завидую.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37286277
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88
А вот что хранится в бэкапе, который весит под 35Гб?

Рад пообсуждать

бекапы есть разные. вы про какой сейчас говорите? откуда он у вас взялся?...

Есть бекапы (БД):
0) 0-го уровня - (полный) хранит полную копию всех (грубо говоря) пространств (dbspaces) сервера на момент времени X.
1) 1-го уровня - (инкрементальный) хранит отличия пространств (dbspaces) сервера от последнего бекапа 0-го уровня (момента X) до момента времени Y. Требует для использования наличия бекапа 0-го уровня.
2) 2-го уровня - (инкрементальный) хранит отличия пространств (dbspaces) сервера от последнего бекапа 1-го уровня (момента Y) до момента времени Z. Требует для использования наличия бекапа 1-го уровня.
L) бекапы логических журналов (инкрементальный) хранят последовательность транзакций, позволяющие (при их наличии) докатить сервер от любого из моментов X, Y, Z до нужного (грубо говоря) вам момента времени.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37287740
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilisАнатолий, мои аплодисменты вашему терпению! У меня терпения не хватило бы, по доброму завидую.

Спасибо, значит в переписке я менее эмоционален, чем сам себя воспринимаю .
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37288275
Денис_88
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой,

это бэкап 0 уровня..

Как происходит процесс восстановления и бэкапа 0 уровня?

бэкап 0 уровня делает копию всех данных в табл пространствах+логический журнал+физический журнал.

а при восстановлении сервер сначала берет физический журнал,в котором хранится инфа о физ. данных сервера,потом восстанавливает сервер по физике с данными в табл. пространствах и потом накатывает логический журнал,так?

а если восстанавливать с бэкапа не нулевого уровня,то он просто накатывает лог. журнал,то есть изменения,произошедшие ав базе с момента 0 бэкапа.

так ли это?

спасибо за терпение.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37288555
Фотография Andron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88...
а если восстанавливать с бэкапа не нулевого уровня,то он просто накатывает лог. журнал,то есть изменения,произошедшие ав базе с момента 0 бэкапа.

так ли это?

спасибо за терпение.

Чтобы восстановить с бэкапа не нулевого уровня, надо сначала восстановить предыдущие бэкапы от 0 уровня включая накат журналов между ними. Это минус при восстановлении из инкрементальных бэкапов, плюс же в том что инкрементальный бэкап копирует только измененные страницы прошедшие с предыдущего бэкапа уровня n-1, т.е. инкрементальный бэкап более быстрый (иногда значительно) если изменений относительно немного с момента бэкапа n-1 уровня.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37288675
Фотография Andron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В предыдущем сообщении надо правильно так:

Чтобы восстановить с бэкапа не нулевого уровня, надо сначала восстановить предыдущие бэкапы от 0 уровня включая накат журналов между ними а затем выполнить накат журналов которые были архивированы после последнего восстановленного инкрементального бэкапа.

Т.е. если например сделали level-0, затем было N журналов, потом level-1, затем M журналов, level-2 и еще I журналов, то восстановление будет идти так: восстановить по порядку level-0,1,2 и затем сделать накат I журналов которые были архивированы после level-2. Сервер все это делает автоматически при восстановлении.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37288831
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денис_88бэкап 0 уровня делает копию всех данных в табл пространствах+логический журнал+физический журнал.
а при восстановлении сервер сначала берет физический журнал,в котором хранится инфа о физ. данных сервера,потом восстанавливает сервер по физике с данными в табл. пространствах и потом накатывает логический журнал,так?


Вы невнимательно читали моё сообщение про физический журнал

У вас в корне неверное представление о том, что такое физический журнал: для Вас это какая-то абстрактная "инфа о физ. данных сервера"...
В физическом журнале хранятся копии страниц из буферов (буферного пула, того самого кеша в памяти, в который считываются данные из ТАБЛИЦ БД, прежде чем они будут обрабатываться сервером). Копии страниц из буферного пула сохраняются в физический журнал при модификации данных пользователями. И используются сервером для получения с диска части информации о том, какое было состояние сервера в предыдущие моменты времени без учёта незавершённых транзакций (Что необходимо при
1) быстром восстановлении системы после некорректного завершения работы сервера
2) при выполнении резервного копирования 0, 1 и 2-го уровня, что позволяет игнорировать изменения, выполняемые пользователями в "БД" в то время, когда идёт резервное копирование).

Поэтому при восстановлении РЕЗЕРВНЫХ копий (то есть процесса, инициируемого администратором, в отличие от БЫСТРОГО восстановления, инициируемого сервером при старте, если обнаружено некорректное завершение работы) физический журнал не используется для считывания из него каких-то данных резервной копии.

П.С.: по поводу регулярно используемого Вами понятия "физика сервера". Или детализируйте его, или не используйте - оно не несёт конкретной смысловой нагрузки для читателей форума.
...
Рейтинг: 0 / 0
назначение параметра LOG_INDEX_BUILDS
    #37288870
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
корректнее так:
АнатоЛойИ используются сервером для получения с диска части информации о том, какое было состояние страниц БД сервера в предыдущие моменты времени без учёта незавершённых транзакций
...
Рейтинг: 0 / 0
48 сообщений из 48, показаны все 2 страниц
Форумы / Informix [игнор отключен] [закрыт для гостей] / назначение параметра LOG_INDEX_BUILDS
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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