|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
насколько я понял этот параметр при репликации нужен для передачи страниц индекса с основного на вторичный. вторичный будет получать эти страницы, раскатывать у себя и тем самым перестраивать индекс,что приведет к улучшению производительности. Так ли я все понял? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 11:28 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_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: Динамическое изменение отдельных параметров конфигурации. ТСвторичный будет получать эти страницы, раскатывать у себя и тем самым перестраивать индекс, что приведет к улучшению производительности . Выделенное не связано с параметром, и совершенно автоматически не следует из факта наличия индекса на первичном ли сервере, на вторичном ли... По факту - вторичный по-любому должен получать эти данные... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 13:05 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛойПо факту - вторичный по-любому должен получать эти данные... Пардон, точнее по факту - вторичный RS . Остальные вторичные могут либо брать страницы из журнала - либо сами править индекс. При этом индекс на вторичном всё равно остаётся "работоспособным". И, повторюсь, эффект повышения производительности - не обязателен (индексы могут быть как "полезны", так и "вредны"). ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 14:20 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, я прекрасно понимаю назначение и смысл индексов,а также прочитал доку неоднократно. Из всего ответа самым полезным была строка: "Остальные вторичные могут либо брать страницы из журнала - либо сами править индекс." Вот за это огромное спасибо.Просто иногда при прочтении документации не сразу доходит смысл и поэтому спросил физический смысл данного процесса простыми словами. Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 16:11 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88АнатоЛой, Из всего ответа самым полезным была строка: "Остальные вторичные могут либо брать страницы из журнала - либо сами править индекс." ... Спасибо На здоровье. Добавлю, что когда говорил "остальные" подразумевал только HDR :). Итого: 0. RS - берёт индекс только из журнала. Интересно, если не включить логирование страниц индекса - не заработает RS - или на вторичном просто не будет индекса, или он будет поломан? Ау, кто проверить может? 1. собственно HDR - может править индекс сам или брать из журнала, если он там есть. 2. SD - использует одни и те же диски - этой проблемы нет в принципе. 3. Механизм ER - подразумевает репликацию только данных - и "вторичный" сервер всегда сам занимается своими индексами... Если любопытно - вот ссылки на доку, из которых делался вывод на "простых словах": Informix Library1. Руководство администратора IBM Informix Dynamic Server Воспроизведение обновлений на вторичном сервере баз данных На всех типах вторичных серверов для репликации данных с первичного сервера используются журналы. Вторичным серверам RS требуется запись в журнал страниц индекса, но вторичные серверы HDR и SD также используют запись в журнал страниц индекса, если она включена. 2. HDR и индексы 3. RS и индексы ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 16:42 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, я пробовал RSS. без включенного параметра RSS не поднимается. В HDR он просит,а в RSS требует))) Анатолий,подскажите плиз еще 1 вопрос. Если включить этот параметр LOG_INDEX_BUILDS на вторичном сервере-это помешает работе репликации? Я считаю,что нет,т.к. этот параметр влияет только на отправку копии страниц в репликационный буфер,а это делает только праймари. Хочу включить этот параметр на тот случай,если основной поломается и резерв станет основным. Подтвердите мои слова для уверенности или опровергните))) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 16:51 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88, только практика может подтвердить :(. У меня пока нет возможности проверить. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 16:54 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, файл логического журнала это и есть logical buffer, который потом и отправляется на вторичный.ведь так? ну тогда получается что запись страниц в этот буфер приведет к его более быстрому заполнению и следовательно к более частым checkpoint'ам.. Ведь так? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 17:01 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88АнатоЛой, файл логического журнала это и есть logical buffer, который потом и отправляется на вторичный.ведь так? ну тогда получается что запись страниц в этот буфер приведет к его более быстрому заполнению и следовательно к более частым checkpoint'ам.. Ведь так? Н-да ... Скажу токо 1 - установка этого параметра приводит к тому, что весь индекс после создания попадает в лог. Поэтому, нужно внимательно относиться к соданию больших индексов - проблемы очевидны. Если не ошибаюсь - индекс пишется в одной транзакции, хотя с моего последнего занятия вопросом м.б. что-то изменилось. Обычно для создания больших индексов меняю LTX параметры, поэтому не скажу - есть ли там Long TX. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 17:58 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88АнатоЛой, файл логического журнала это и есть logical buffer, который потом и отправляется на вторичный.ведь так? ну тогда получается что запись страниц в этот буфер приведет к его более быстрому заполнению и следовательно к более частым checkpoint'ам.. Ведь так? "файл логического журнала это и есть logical buffer" - ммм.... нет: 1. файл логического журнала - это "область" на диске 2. logical buffer = logical log buffer - это область памяти - ну никак не одно и то же... 3. ... "ну тогда получается что запись страниц в этот буфер приведет к его более быстрому заполнению " В общем вы правильный вывод сделали, при полностью ложных предпосылках :) Если при этом и дальше будете пользоваться "интуитивно-понятными понятиями" - мы так далеко-далеко уедем - но не в ту сторону.... читайте доку по теории :). "более быстрое заполнению (файла логического журнала приведёт) к более частым checkpoint'ам.." - тут полный бред... Вы не понимаете ни что такое checkpoint, ни по каким правилам он инициируется... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 20:02 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_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 на обоих указанных серверах должно быть одним и тем же. При включенных контрольных точках без блокировок задержка применения данных на вторичном сервере может произойти в результате временного сохранения данных журнала на сервере в процессе обработки контрольной точки. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 21:12 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88, Вы установили RSS_FLOW_CONTRO = -1 на HDR и RSS ?! Какой результат ? С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2011, 21:16 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, "более быстрое заполнению (файла логического журнала приведёт) к более частым checkpoint'ам.." - тут полный бред... Вы не понимаете ни что такое checkpoint, ни по каким правилам он инициируется... Анатолий, вы неправильно поняли.Более быстрое заполнение логического буфера,а не журнала приведет к более частым к.т. или Вы со мной в этом несогласны? Да я неправ по поводу сравнения журнала и буфера,но я прекрасно понимаю смысл к.т. и правил инициализации. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 01:20 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
GVF112GVF, Вы установили RSS_FLOW_CONTRO = -1 на HDR и RSS ?! К сожалению нет,потому что начальство поставило сжатые сроки для репликации и пришлось поднять асинхронную hdr.Теперь нет серверов для тестирования RSS. При первой же возможности попробую и отпишусь. Может быть есть какие-нить другие Ваши контакты,чтобы можно было общаться в течение дня на экстренный случай поднятия RSS? Включение контрольных точек без блокировки задается параметрами конфигурации LOG_STAGING_DIR (на вторичном сервере HDR) и LOG_INDEX_BUILDS (на первичном сервере и на вторичном сервере HDR). Значение параметра LOG_INDEX_BUILDS на обоих указанных серверах должно быть одним и тем же. А вот тут могу не согласиться.Я поднимал репликацию RSS при включенном параметре только лишь на основном сервере и логи передавались нормально.Во всех доках и мануалах написано,что должно быть включено на первичном.Также при запуске hdr репликации только лишь в логе основного появилась запись о необходимости включения данного параметра,а вторичный промолчал. Ведь вторичный получает этот журнал и восстанавливает у себя все,что есть в этом журнале.И если первичный ему отправит копии страниц индекса,то он их и восстановит,чтобы самому не пересобирать индекс..Зачем ему этот параметр? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 01:23 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
то есть этот параметр необходимо включить на обоих серверах для того,чтобы первичный при создании индекса записал данные в журнал,а вторичный при получении журнала и восстановлении записал эту информацию к себе в журнал и потом оттуда ее брал,да? именно за этим нужно на обоих серверах? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 10:11 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88то есть этот параметр необходимо включить на обоих серверах для того,чтобы первичный при создании индекса записал данные в журнал,а вторичный при получении журнала и восстановлении записал эту информацию к себе в журнал и потом оттуда ее брал,да? именно за этим нужно на обоих серверах? Нет, достаточно на первичном. Включать LOG_INDEX_BUILDS стоит на всех серверах из соображений, что любой сервер может стать PRI. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 11:30 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
яфшуеі, подскажите пожалуйста по поводу физического понимания всего этого процесса? 1) на первичном создается новый индекс, копия этого индекса записывается в журнал при включенном параметре log_index_builds и отправляется на вторичный.вторичный получает этот журнал и создает у себя этот индекс из журнала.А если бы не было индекса в журнале,то вторичному пришлось бы самостоятельно создавать индекс,так? 2)на первичном сервере внесли данные в таблицу, индекс перестроился-как он попадает на вторичный?ситуация аналогична пункту 1 или все неновые индексы автоматически посылают свои изменения? 3)по идее вторичному серверу этот параметр вообще не нужен,если его не будут переводить в первичный сервер,т.к. он лишь накатывает изменения.НО во всех мануалах написано что этот параметр необходимо включить на вторичном и при включении репликации именно вторичный отругался,что должен быть включен этот параметр. Подскажите плиз? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 12:05 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88АнатоЛой, "более быстрое заполнению (файла логического журнала приведёт) к более частым checkpoint'ам.." - тут полный бред... Вы не понимаете ни что такое checkpoint, ни по каким правилам он инициируется... Анатолий, вы неправильно поняли.Более быстрое заполнение логического буфера,а не журнала приведет к более частым к.т. или Вы со мной в этом несогласны? Да я неправ по поводу сравнения журнала и буфера,но я прекрасно понимаю смысл к.т. и правил инициализации. 1. Я действительно из-за Вашего определения "файл логического журнала это и есть logical buffer" проинтерпретировал фразу "запись страниц в этот буфер приведет к его более быстрому заполнению и следовательно к более частым checkpoint'ам" не так, как вы это объяснили сейчас. 2. "Более быстрое заполнение логического буфера (буфера логического журнала = logical log buffer),а не (самого логического) журнала приведет к более частым к.т., или Вы со мной в этом несогласны?". Не согласен. Вы путаете причину и следствие. Ибо не заполнение буфера логического журнала приводит к инициации контрольной точки, а инициация контрольной точки (по любым причинам) является однйо из причин сброса буфера логического журнала собственно в журнал. Если Вы знаете, переполнение логического журнала может привести к невозможности выполнения контрольной точки (требующей тоже записи в логический журнал). Поэтому в последних версиях Informix при включенном режиме AUTO_CKPTS сервер теоретически может из-за угрозы переполнения логического журнала (заметьте: не одного из "файлов" этого журнала, а именно всего объёма этого журнала) инициировать контрольную точку. Вот в такой интерпретации Ваша фраза выглядит истинной :). А на практике логический журнал в промышленной системе уже давно достаточно растянут, и контрольные точки инициируются другими событиями гораздо чаще, чем происходит переполнение журнала (особенно если резервное копирование отрабатывает по факту заполнения файла журнала, а не по расписанию). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 12:28 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, Ибо не заполнение буфера логического журнала приводит к инициации контрольной точки, а инициация контрольной точки (по любым причинам) является однйо из причин сброса буфера логического журнала собственно в журнал. Анатолий,а как же то,что при заполнение буфера логического журнала приводит к к.т.?Ведь сервер боится переполнения! Если запустить ресурсоемкий процесс,то буфер будет заполняться быстрее,сервер будет бояться переполнения и сбрасывать этот буфер в журнал.То есть получается так,что чем больше процесс делает изменений, тем чаще происходят к.т. У нас есть огромный опер. процесс, который выполняется час,так вот во время этого процесса к.т. происходят в разы чаще,чем при простаивании сервера.Больше никто ничего не делает,поэтому других причин для к.т. нет.. Я Вас не понимаю ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 12:52 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88яфшуеі, подскажите пожалуйста по поводу физического понимания всего этого процесса? 1) на первичном создается новый индекс, копия этого индекса записывается в журнал при включенном параметре log_index_builds и отправляется на вторичный.вторичный получает этот журнал и создает у себя этот индекс из журнала.А если бы не было индекса в журнале,то вторичному пришлось бы самостоятельно создавать индекс,так? 2)на первичном сервере внесли данные в таблицу, индекс перестроился-как он попадает на вторичный?ситуация аналогична пункту 1 или все неновые индексы автоматически посылают свои изменения? 3)по идее вторичному серверу этот параметр вообще не нужен,если его не будут переводить в первичный сервер,т.к. он лишь накатывает изменения.НО во всех мануалах написано что этот параметр необходимо включить на вторичном и при включении репликации именно вторичный отругался,что должен быть включен этот параметр. Подскажите плиз? 1. После создания индекс передается на вторичный HDR независимо от установки параметра. Если параметр равен 1 - индекс передается через запись лог. журнала. Если не установлен - индекс передается напрямую - в логе появляется запись: DR: Sending .... 2. Изменение значения в индексном поле это логгируемая операция, она пападает в лог. журнал. 3. Какой именно вторичный? Для RSS не помню - настраивал давно, параметр у меня стоит но с каких соображений - не помню. Для HDR у меня на 11.50.FC5W2 не ругается. В принципе, это не так и важно. Если используете РСС то параметр установили везде и забыли, большие индексы обычно не создают при активной работе пользователей. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 13:02 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88АнатоЛой, Ибо не заполнение буфера логического журнала приводит к инициации контрольной точки, а инициация контрольной точки (по любым причинам) является однйо из причин сброса буфера логического журнала собственно в журнал. Анатолий,а как же то,что при заполнение буфера логического журнала приводит к к.т.?Ведь сервер боится переполнения! Если запустить ресурсоемкий процесс,то буфер будет заполняться быстрее,сервер будет бояться переполнения и сбрасывать этот буфер в журнал.То есть получается так,что чем больше процесс делает изменений, тем чаще происходят к.т. У нас есть огромный опер. процесс, который выполняется час,так вот во время этого процесса к.т. происходят в разы чаще,чем при простаивании сервера.Больше никто ничего не делает,поэтому других причин для к.т. нет.. Я Вас не понимаю 1. Сброс буфера логического журнала (из памяти) в логический журнал (на диск) - это не контрольная точка ... Данный сброс - это регулярный процесс, выполняемый и без контрольной точки... Повторюсь, а) причиной сброса буфера может являться контрольная точка, но не только. б) контрольная точка всегда приводит к сброс буфера. 2. "Ведь сервер боится переполнения!" - следите за руками: "боится переполнения" = "боится переполнения логического журнала ( на диске )" = "боится возникновения заполнения на диске всех "файлов" логического журнала" = "боится возникновения ситуации: на диске некуда записать очередной буфер логического журнала"... Сервер не "боится" переполнения самого буфера логического журнала . Во-первых, у него их 3 штуки. Во-вторых, единственное узкое место - успеть сбросить хотя бы один, пока заполняются два других... Чтобы сбросить буфер логического журнала на диск (в логический журнал), контрольная точка не нужна - процесс сброса выполняется и без контрольных точек. Сколько ещё раз всё это повторить? To All: если я ошибаюсь - поправьте... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 13:24 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88Анатолий,а как же то,что при заполнение буфера логического журнала приводит к к.т.?Ведь сервер боится переполнения! Сервер "боится" переполнения физического журнала и при заполнении его на 75% инициирует К.Т. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 13:24 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
яфшуеі, ОГРОМНОЕ СПАСИБО ЗА ОБЪЯСНЕНИЕ. вот теперь действительно стало ясно. я понял то,что на первичном он играет еще какую-то роль,а вот на вторичном на всякий случай на день сбоя и замены на первичный.А в повседневной работе вторичный ничего не пишет и этот параметр ему не нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 13:24 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88, вдогонку Посмотрите у себя на сервере LOGBUFF. Рекомендуемое значение буфера логического журнала = 64КБ. Думаю, что у Вас оно не сильно отличается от рекомендуемого. Допустим, пихаем мы в БД картинку на 1МБ (не в blob-пространство, чтобы она в логический журнал попадала и на вторичный сервер реплицировалась). И что, по Вашему, нас ждёт 1024 КБ / 64 КБ = 16 контрольных точек?!!! И с какой частотой и длительностью они выполняются, если у меня сервер успевает без проблем в течение 1 сек записать этот 1 МБ? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 13:35 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, LOG_BUFF установлен 2048Кб Одними из причин к.т. являются заполнение логического буфера или наступление ckptinterval (я не говорю о бэкапах и изменениях табличного пространства). Так вот расскажу 2 ситуации,которые наблюдал сам лично: 1-на сервере установлен параметр ckptinterval 60 Запускаю опер. процесс и к.т. делаются либо раз в минуту,либо чаще,но его продолжительность была около 30сек, т.е. очень долго, потому что ему нужно было сбросить большое кол-во информации, которая попала в буфер за это время 2-устанавливаю параметр RTO_SERVER_RESTART 60 и к.т. при этом же процессе начинает делаться чаще,но время выполнения становится меньше 0-2сек. А потому что он делает к.т. с таким расчетом,что на восстановление у него уйдет 60секунд.А за меньшее время и меньше изменений произошло, поэтому к.т. 0-2сек. Если на сервере не проводить никаких изменений,то к.т. может не выполняться и по 20мин при этом параметре. Значит все-таки скорость заполнения буфера прямо влияет на частоту и продолжительность к.т. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 14:28 |
|
|
start [/forum/topic.php?fid=44&startmsg=37278090&tid=1607343]: |
0ms |
get settings: |
15ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
50ms |
get topic data: |
3ms |
get forum data: |
1ms |
get page messages: |
397ms |
get tp. blocked users: |
0ms |
others: | 285ms |
total: | 759ms |
0 / 0 |