iBase.ru Forum

Условия задачи:
Сервер: 1.5.3.4870-Суперсервер
База данных: 0.5-1.5 Гб
Достаточно активная работа в течение дня (документооборот)
В конце дня запускается несколько массовых обработок (удаление, обновление, вставка)

Суть вопроса:
если база "без истории", т.е. таблицы с историческими движениями, регистры - почти пустые, то
б/р в конце дня идет быстро - до 5 мин макс, после массовых обработок - 10 мин макс
Это все продолжается ежедневно в течение 1-1.5 месяцев, а потом по каким-то причинам
начинается увеличение времени цикла б/р линейно, с достижением совершенно невозможных значений
типа 2-3 часов на б/р еще через месяц.

Предположения и собственно сам вопрос:
понятно что тут задействована сборка мусора, вопрос в том, почему 2 месяца живем нормально,
а потом начинается рост? если влияет длина истории - она увеличивается каждый день на одинаковую
величину, количество записей тоже увеличивается равномерно.

Заранее благодарю за советы и рекомендации.

Николай

ЗЫ. По поводу IB Analysta и "плохих" индексов. Да, есть "плохие" индексы. С плохой селективностью (2-10 значений на индекс).
Но избавится от них не получится, т.к. это внешние ключи. И опять таки, эти "плохие" индексы должны сразу портить времена б/р,
а не спустя 1.5 месяца. (Поправьте, если не прав).

www.ibase.ru/devinfo/gbak.htm
www.ibase.ru/devinfo/gargbage.htm

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

смотрите в IBAnalyst, есть там мусор или нет.

ЗЫ. По поводу IB Analysta и "плохих" индексов. Да, есть "плохие" индексы. С плохой селективностью (2-10 значений на индекс).
Но избавится от них не получится, т.к. это внешние ключи. И опять таки, эти "плохие" индексы должны сразу портить времена б/р,

во-первых, про это написано в справке по IBAnalyst. Нажмите F1, выберите "дополнительные вопросы и ответы".
Во-вторых, не надо смотреть в IBAnalyst только на индексы.
В третьих, не бывает линейного увеличения И backup И restore. Поэтому, пожалуйста, не складывайте время бэкапа и время рестора. Всегда смотрите на них отдельно.
И не надо бэкапить со сборкой мусора (см. выше gbak.htm).

Вот статистика в процессе работы, ближе к концу рабочего дня:
Oldest transaction 163450
Oldest active 163451
Oldest snapshot 1563
Next transaction 393538

После того как все клиенты все завершили и вышли из системы:
Oldest transaction 394144
Oldest active 394145
Oldest snapshot 394145
Next transaction 394148
Как я предполагаю, мусора здесь нет (он собран кооперативной сборкой).

Цикл б/р после этого этапа идет порядка 5 минут, отдельно б/р не помню, но вообще restore в любом случае идет достаточно быстро.
Далее, как я уже писал, запускаются некоторые групповые обработки, после которых тем не менее статистика тоже выглядит внешне прилично:

Oldest transaction 1161
Oldest active 1162
Oldest snapshot 1162
Next transaction 1163

Тут тоже мусора нет
Или я ошибаюсь? Т.к. тут IBAnalyst выдает сообщение, что есть таблицы с массовым удалением/изменением. Да, такие таблицы действительно есть. Разбиты на несколько этапов, каждый в отдельной транзакции.
А вот после этого этапа начинается непонятность.
Бекап без сборки мусора - 5 минут, со сборкой мусора - до 20 минут (если в базе история документов на 1.5-2 месяца). Подчеркну: каждый день бекап со сборкой мусора идет около 20 минут.
Через 1.5-2 месяца начинается увеличение времени бекапа (со сборкой мусора), линейно, к 3-му месяцу до 1.5 часов и дальше - больше.
Без сборки мусора - по прежнему 5 минут. Даже на исходе 3 месяца.

Озвучу еще раз вопросы:
1) если есть мусор, в статистике транзакций его не видно потому что массовые обновления/удаления были в одной транзакции?
2) если есть мусор в этих таблицах (исторических), которые массово обрабатываются, то почему время сбора мусора при бекапе не растет с самого начала работы с базой, а начинает расти через некоторое время?
3) если мусор в этих таблицах, то почему select count(*) по таблице, где были массовые обновления/удаления выполняется за 30 сек, а
бекап со сборкой мусора - 1.5 часа?

Буду очень благодарен за объяснения, или укажите чего еще посмотреть.
Все статьи с ibase.ru так или иначе связанные с данной темой уже прочел, но не просветлился

Николай

Вот статистика в процессе работы, ближе к концу рабочего дня:

Вам надо было не сюда цифры писать, а смотреть статистику в IBAnalyst, и если что непонятно - спрашивать. А так Вы меня заставляете Вам объяснять то, что и так скажет IBAnalyst -
у Вас приложения держат открытыми транзакции, долго, примерно по половине рабочего дня. Ткните в отчеты в меню IBAnalyst.

Как я предполагаю, мусора здесь нет (он собран кооперативной сборкой).

не надо предполагать! Соберите статистику и посмотрите в IBAnalyst. Там будет видно, есть версии или нет.

Далее, как я уже писал, запускаются некоторые групповые обработки, после которых тем не менее статистика тоже выглядит внешне прилично:

1000 транзакций это ерунда. другое дело, сколько в одной транзакции можно наплодить версий.

Тут тоже мусора нет

где "тут"??? В транзакциях мусора нет, не бывает, и быть не может. Мусор или версии может быть только У ЗАПИСЕЙ, в таблицах

Т.к. тут IBAnalyst выдает сообщение, что есть таблицы с массовым удалением/изменением.

ну так ткните в эти таблицы, посмотрите, сколько там версий. Вы меня как автора IBAnalyst убиваете морально - я то надеялся что я специально сделал простой и понятный для ПРОСМОТРА статистики инструмент, а выясняется что нет?

Через 1.5-2 месяца начинается увеличение времени бекапа (со сборкой мусора), линейно, к 3-му месяцу до 1.5 часов и дальше - больше.

Зачем делать бэкап со сборкой мусора ? Вы разве sweep не можете запустить отдельно?

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

см.выше. Откройте в IBAnalyst Ваши таблицы, и если Вы собирали по ним статистику, увидите, где есть версии, а где нет. "В транзакциях" мусора нет.

2) если есть мусор в этих таблицах (исторических), которые массово обрабатываются, то почему время сбора мусора при бекапе не растет с самого начала работы с базой, а начинает расти через некоторое время?

Потому что "мусор" - это никому не нужные версии, которые сервер может удалить при чтении. А версии записей - не мусор. Возможно, у Вас накапливается и то и другое - не даром приложения держат активными транзакции по пол-дня а может и больше.

3) если мусор в этих таблицах, то почему select count(*) по таблице, где были массовые обновления/удаления выполняется за 30 сек, а
бекап со сборкой мусора - 1.5 часа?

значит мусорные версии В ДРУГИХ таблицах.

Все статьи с ibase.ru так или иначе связанные с данной темой уже прочел, но не просветлился

читайте еще. например
http://www.ibase.ru/devinfo/mga.htm
http://www.ibase.ru/devinfo/garbage.htm
http://www.ibase.ru/devinfo/gbak.htm

p.s. а еще в IBAnalyst есть справка по F1.