|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Основная тема топика раскрыта, поэтому считаю его закрытым. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 14:28 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
хотя нет...поторопился кто-нибудь создавал большие индексы с включенным параметром на основном сервере?какие проблемы?Может лучше тогда его не использовать и пусть вторичный сам создает индекс? Когда Вы включаете LOG_INDEX_BUILDS на Primary и RSS-сервере, то ничинает работать механизм не блокирующего CheckPoint. Включение контрольных точек без блокировки задается параметрами конфигурации LOG_STAGING_DIR (на вторичном сервере HDR) и LOG_INDEX_BUILDS (на первичном сервере и на вторичном сервере HDR). Значение параметра LOG_INDEX_BUILDS на обоих указанных серверах должно быть одним и тем же. При включенных контрольных точках без блокировок задержка применения данных на вторичном сервере может произойти в результате временного сохранения данных журнала на сервере в процессе обработки контрольной точки. С уважением, Вадим. Вадим,поясните плиз свой ответ относительно HDR репликации(не RSS)..Каково Ваше мнение по поводу этого параметра и его предназначения? Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 14:40 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88АнатоЛой, ... Одними из причин к.т. являются заполнение логического буфера или .... На всё вышесказанное мной по этому поводу я давал или могу дать ссылку на офиц.документацию. Откуда Вы сделали такой вывод - непонятно. Денис_88Так вот расскажу 2 ситуации,которые наблюдал сам лично: ... Значит все-таки скорость заполнения буфера прямо влияет на частоту и продолжительность к.т. Если б не слово "прямо" - можно было бы согласиться... Если буфер увеличить в два раза при прочих равных условиях работы сервера - думаю, никто не возьмётся "прямо" посчитать хоть приблизительно, изменятся ли частота и продолжительность к.т. и на сколько :). За сим откланиваюсь... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 15:07 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88Основная тема топика раскрыта, поэтому считаю его закрытым. Сорри, не заметил "закрытие" на второй странице. По вопросу к.т. желания что-нить добавить уже не имею :) :(. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 15:10 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, Если б не слово "прямо" - можно было бы согласиться... Если буфер увеличить в два раза при прочих равных условиях работы сервера - думаю, никто не возьмётся "прямо" посчитать хоть приблизительно, изменятся ли частота и продолжительность к.т. и на сколько :). За сим откланиваюсь... Если не брать все остальные причины,по которым может случиться к.т. и представить себе такую идеальную картину,то именно так и будет,что к.т. станет выполняться в 2 раза реже,но дольше.. НО никто не возьмется прямо посчитать это по той причине,что такой чистый эксперимент провести нельзя!Есть много других причин к.т. Но чисто теоретически это так. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 15:20 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Я не удержался таки :) Денис_88АнатоЛой, 1-на сервере установлен параметр ckptinterval 60 Запускаю опер. процесс и к.т. делаются либо раз в минуту,либо чаще,но его продолжительность была около 30сек, т.е. очень долго, потому что ему нужно было сбросить большое кол-во информации, которая попала в буфер за это время Продолжительность к.т. большая, "потому что ему нужно было сбросить большое кол-во (ИЗМЕНЁННОЙ) информации, которая попала в буфер(НЫЙ ПУЛ) за это время"... почувствуйте разницу... Попробуйте при этих настройках уменьшить буферный пул до 64 КБ - и Вы таки всё ещё думаете, что к.т. будут выполняться чаще? Денис_882-устанавливаю параметр RTO_SERVER_RESTART 60 и к.т. при этом же процессе начинает делаться чаще,но время выполнения становится меньше 0-2сек. А потому что он делает к.т. с таким расчетом,что на восстановление у него уйдет 60секунд.А за меньшее время и меньше изменений произошло, поэтому к.т. 0-2сек. Если на сервере не проводить никаких изменений,то к.т. может не выполняться и по 20мин при этом параметре. Значит все-таки скорость заполнения буфера прямо влияет на частоту и продолжительность к.т. Если "скорость заполнения буфера" логического журнала мерять в КБ/сек - то да, а если в буферах/сек - то при прочих равных - несущественно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 16:05 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88АнатоЛой, Если б не слово "прямо" - можно было бы согласиться... Если буфер увеличить в два раза при прочих равных условиях работы сервера - думаю, никто не возьмётся "прямо" посчитать хоть приблизительно, изменятся ли частота и продолжительность к.т. и на сколько :). За сим откланиваюсь... Если не брать все остальные причины,по которым может случиться к.т. и представить себе такую идеальную картину,то именно так и будет,что к.т. станет выполняться в 2 раза реже,но дольше... Я очень надеюсь, что вы хорошо отличаете между собой такие понятия, как: 1. физический журнал 2. буфферы физического журнала 3. логический журнал 4. буфферы логического журнала 5. буфферный пул. Всё, устал :(... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 16:20 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, Я очень надеюсь, что вы хорошо отличаете между собой такие понятия, как: 1. физический журнал файл на диске, содержащий все физические изменения (PHYSLOG). 2. буфферы физического журнала буффер(кусок памяти), который создается в совместной памяти сервера и хранит физические изменения,а потом сбрасывает их в журнал на диск 3. логический журнал файл на диске (logical log),содержащий все логические изменения.Именно они передаются на вторичный 4. буфферы логического журнала буффер(кусок памяти), создаваемый в совместной памяти сервера и временно хранящий логические изменения до сбрасывания на диск в logical log 5. буфферный пул. кусок совместной памяти необходимый для хранения информации о последних извлеченных данных.Он нужен для более быстрого извлечения данных,чтобы сервер каждый раз не делал заново,а пользовался уже тем,что есть.. Если я в чем-то неправ, буду рад услышать правильный ответ от спеца.. Сам в информиксе 3месяца. спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 16:37 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88, супер, по основным архитектурым понятиям у нас расхождений нет. Значит расхождения остались либо только в нюансах этих понятий, либо в понимании процессов по взаимодействию всей этой "дребедени". Если интересно "найти истину" в наших расхождениях - может откроем новый топик? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 17:48 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, может откроем новый топик? с удовольствием можно поговорить о физике чекпойнтов и о том,что такое физический журнал.. В физ.журнал попадает только физическое изменение:добавление чанков,изменение размера пространства,да?а что еще? когда мы делаем любые изменения в физике,это попадает в лог журнала,потом в сам журнал на диск и хранится там.При восстановлении из бэкапа сервер прочитывает этот журнал и восстанавливает физическое строение базы,ведь так всё? Т.е. в этом журнале содержится информация о табличных пространствах,чанках и т.д. А вот в логическом журнале хранятся все изменения,связанные с insert,update,drop,delete,alter table add col....,да? Все эти изменения попадают в буфер лог журнала,потом в журнал и потом во время бэкапа архивируются и хранятся в бэкапе вместе с физ. журналом.А при восстановлении сервер читает сначала физ журнал,а потом уже на восстановленную физику накатывает весь логический журнал.так? Но вопрос?сколько логических журналов хранится?ведь если я буду делать бэкап каждый день,то получается в каждом файле бэкапа будет новый журнал(допустим что у меня за сутки заполняется весь лог.журнал) и сервер потом будет читать их все? Например, у меня на сервере всего 100логических логов и каждый имеет размер 262000 страниц Вот тут немного недопонимаю пока :( А вот что хранится в бэкапе, который весит под 35Гб?там все физ и логические журналы?и каждый раз он растет за счет того,что во время бэкапа в архивируются новые логические журналы? Рад пообсуждать ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 18:44 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88В физ.журнал попадает только физическое изменение:добавление чанков,изменение размера пространства,да?а что еще? когда мы делаем любые изменения в физике,это попадает в лог журнала,потом в сам журнал на диск и хранится там.При восстановлении из бэкапа сервер прочитывает этот журнал и восстанавливает физическое строение базы,ведь так всё? Т.е. в этом журнале содержится информация о табличных пространствах,чанках и т.д. совсем нет. Физический журнал обеспечивает восстановление после сбоев (выключение питания) и резервное копирование на момент времени (игнорируя изменения транзакций, которые выполняются или выполнились после старта процесса резервного копирования 0, 1 или 2-го уровня). Т.е. запись в физ.журнал напрямую связана с модификациями данных пользователями БД... Читать для начала здесь . Денис_88А вот в логическом журнале хранятся все изменения,связанные с insert,update,drop,delete,alter table add col....,да? Все эти изменения попадают в буфер лог журнала,потом в журнал и потом во время бэкапа архивируются и хранятся в бэкапе вместе с физ. журналом.А при восстановлении сервер читает сначала физ журнал,а потом уже на восстановленную физику накатывает весь логический журнал.так? физ. журнал в бекапе не хранится. он нужен при быстром восстановлении при краше сервера... Денис_88Но вопрос?сколько логических журналов хранится?ведь если я буду делать бэкап каждый день,то получается в каждом файле бэкапа будет новый журнал(допустим что у меня за сутки заполняется весь лог.журнал) и сервер потом будет читать их все? Например, у меня на сервере всего 100логических логов и каждый имеет размер 262000 страниц Вот тут немного недопонимаю пока :( А вот что хранится в бэкапе, который весит под 35Гб?там все физ и логические журналы?и каждый раз он растет за счет того,что во время бэкапа в архивируются новые логические журналы? Рад пообсуждать бекап - отдельная песня. Позже отвечу.... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 19:01 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_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. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 21:35 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
GVF112GVF, Вадим,а если на вторичном сервере hdr не будет указана LOG_STAGING_DIR, то что тогда? И какая тогда польза от включения этого параметра, если может происходить задержка в накате лога? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2011, 21:55 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_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. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.05.2011, 20:36 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
GVF112GVF, ясно.. всем спасибо. тема закрыта ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2011, 23:45 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛойДенис_88В физ.журнал попадает только физическое изменение:добавление чанков,изменение размера пространства,да?а что еще? когда мы делаем любые изменения в физике,это попадает в лог журнала,потом в сам журнал на диск и хранится там.При восстановлении из бэкапа сервер прочитывает этот журнал и восстанавливает физическое строение базы,ведь так всё? Т.е. в этом журнале содержится информация о табличных пространствах,чанках и т.д. совсем нет. Физический журнал обеспечивает восстановление после сбоев (выключение питания) и резервное копирование на момент времени (игнорируя изменения транзакций, которые выполняются или выполнились после старта процесса резервного копирования 0, 1 или 2-го уровня). Т.е. запись в физ.журнал напрямую связана с модификациями данных пользователями БД... Читать для начала здесь . Денис_88А вот в логическом журнале хранятся все изменения,связанные с insert,update,drop,delete,alter table add col....,да? Все эти изменения попадают в буфер лог журнала,потом в журнал и потом во время бэкапа архивируются и хранятся в бэкапе вместе с физ. журналом.А при восстановлении сервер читает сначала физ журнал,а потом уже на восстановленную физику накатывает весь логический журнал.так? физ. журнал в бекапе не хранится. он нужен при быстром восстановлении при краше сервера... Денис_88Но вопрос?сколько логических журналов хранится?ведь если я буду делать бэкап каждый день,то получается в каждом файле бэкапа будет новый журнал(допустим что у меня за сутки заполняется весь лог.журнал) и сервер потом будет читать их все? Например, у меня на сервере всего 100логических логов и каждый имеет размер 262000 страниц Вот тут немного недопонимаю пока :( А вот что хранится в бэкапе, который весит под 35Гб?там все физ и логические журналы?и каждый раз он растет за счет того,что во время бэкапа в архивируются новые логические журналы? Рад пообсуждать бекап - отдельная песня. Позже отвечу.... Анатолий, мои аплодисменты вашему терпению! У меня терпения не хватило бы, по доброму завидую. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2011, 16:30 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88 А вот что хранится в бэкапе, который весит под 35Гб? Рад пообсуждать бекапы есть разные. вы про какой сейчас говорите? откуда он у вас взялся?... Есть бекапы (БД): 0) 0-го уровня - (полный) хранит полную копию всех (грубо говоря) пространств (dbspaces) сервера на момент времени X. 1) 1-го уровня - (инкрементальный) хранит отличия пространств (dbspaces) сервера от последнего бекапа 0-го уровня (момента X) до момента времени Y. Требует для использования наличия бекапа 0-го уровня. 2) 2-го уровня - (инкрементальный) хранит отличия пространств (dbspaces) сервера от последнего бекапа 1-го уровня (момента Y) до момента времени Z. Требует для использования наличия бекапа 1-го уровня. L) бекапы логических журналов (инкрементальный) хранят последовательность транзакций, позволяющие (при их наличии) докатить сервер от любого из моментов X, Y, Z до нужного (грубо говоря) вам момента времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2011, 20:54 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
vasilisАнатолий, мои аплодисменты вашему терпению! У меня терпения не хватило бы, по доброму завидую. Спасибо, значит в переписке я менее эмоционален, чем сам себя воспринимаю . ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2011, 16:39 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
АнатоЛой, это бэкап 0 уровня.. Как происходит процесс восстановления и бэкапа 0 уровня? бэкап 0 уровня делает копию всех данных в табл пространствах+логический журнал+физический журнал. а при восстановлении сервер сначала берет физический журнал,в котором хранится инфа о физ. данных сервера,потом восстанавливает сервер по физике с данными в табл. пространствах и потом накатывает логический журнал,так? а если восстанавливать с бэкапа не нулевого уровня,то он просто накатывает лог. журнал,то есть изменения,произошедшие ав базе с момента 0 бэкапа. так ли это? спасибо за терпение. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2011, 21:43 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88... а если восстанавливать с бэкапа не нулевого уровня,то он просто накатывает лог. журнал,то есть изменения,произошедшие ав базе с момента 0 бэкапа. так ли это? спасибо за терпение. Чтобы восстановить с бэкапа не нулевого уровня, надо сначала восстановить предыдущие бэкапы от 0 уровня включая накат журналов между ними. Это минус при восстановлении из инкрементальных бэкапов, плюс же в том что инкрементальный бэкап копирует только измененные страницы прошедшие с предыдущего бэкапа уровня n-1, т.е. инкрементальный бэкап более быстрый (иногда значительно) если изменений относительно немного с момента бэкапа n-1 уровня. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2011, 08:28 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
В предыдущем сообщении надо правильно так: Чтобы восстановить с бэкапа не нулевого уровня, надо сначала восстановить предыдущие бэкапы от 0 уровня включая накат журналов между ними а затем выполнить накат журналов которые были архивированы после последнего восстановленного инкрементального бэкапа. Т.е. если например сделали level-0, затем было N журналов, потом level-1, затем M журналов, level-2 и еще I журналов, то восстановление будет идти так: восстановить по порядку level-0,1,2 и затем сделать накат I журналов которые были архивированы после level-2. Сервер все это делает автоматически при восстановлении. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2011, 09:58 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
Денис_88бэкап 0 уровня делает копию всех данных в табл пространствах+логический журнал+физический журнал. а при восстановлении сервер сначала берет физический журнал,в котором хранится инфа о физ. данных сервера,потом восстанавливает сервер по физике с данными в табл. пространствах и потом накатывает логический журнал,так? Вы невнимательно читали моё сообщение про физический журнал У вас в корне неверное представление о том, что такое физический журнал: для Вас это какая-то абстрактная "инфа о физ. данных сервера"... В физическом журнале хранятся копии страниц из буферов (буферного пула, того самого кеша в памяти, в который считываются данные из ТАБЛИЦ БД, прежде чем они будут обрабатываться сервером). Копии страниц из буферного пула сохраняются в физический журнал при модификации данных пользователями. И используются сервером для получения с диска части информации о том, какое было состояние сервера в предыдущие моменты времени без учёта незавершённых транзакций (Что необходимо при 1) быстром восстановлении системы после некорректного завершения работы сервера 2) при выполнении резервного копирования 0, 1 и 2-го уровня, что позволяет игнорировать изменения, выполняемые пользователями в "БД" в то время, когда идёт резервное копирование). Поэтому при восстановлении РЕЗЕРВНЫХ копий (то есть процесса, инициируемого администратором, в отличие от БЫСТРОГО восстановления, инициируемого сервером при старте, если обнаружено некорректное завершение работы) физический журнал не используется для считывания из него каких-то данных резервной копии. П.С.: по поводу регулярно используемого Вами понятия "физика сервера". Или детализируйте его, или не используйте - оно не несёт конкретной смысловой нагрузки для читателей форума. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2011, 11:19 |
|
назначение параметра LOG_INDEX_BUILDS
|
|||
---|---|---|---|
#18+
корректнее так: АнатоЛойИ используются сервером для получения с диска части информации о том, какое было состояние страниц БД сервера в предыдущие моменты времени без учёта незавершённых транзакций ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2011, 11:39 |
|
|
start [/forum/topic.php?fid=44&msg=37281494&tid=1607343]: |
0ms |
get settings: |
25ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
417ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 542ms |
0 / 0 |