Сборка мусора, автоматический бэкап/рестор

Ремонт и восстановление баз данных InterBase, Firebird, Yaffil

Модераторы: kdv, Alexey Kovyazin

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 07 июл 2008, 15:53

Ulme писал(а):после этого запрос делается за 30-90 ms
План изменился?

Ulme
Сообщения: 16
Зарегистрирован: 27 июн 2008, 14:31

Сообщение Ulme » 07 июл 2008, 16:33

WildSery писал(а):
Ulme писал(а):после этого запрос делается за 30-90 ms
План изменился?
запрос№1
был

Код: Выделить всё

Plan
PLAN SORT (JOIN (JOIN (C NATURAL, DC INDEX (RDB$FOREIGN47), D INDEX (RDB$PRIMARY5)), AO INDEX (Ind_Run_Time_Archive)))

Adapted Plan
PLAN SORT (JOIN (JOIN (C NATURAL, DC INDEX (FK_DriverCar_Signal), D INDEX (PK_Drivers)), AO INDEX (Ind_Run_Time_Archive)))
стал

Код: Выделить всё

Plan 
PLAN SORT (JOIN (JOIN (DC NATURAL, C INDEX (RDB$33), D INDEX (RDB$PRIMARY5)), AO INDEX (Ind_Run_Time_Archive))) 

Adapted Plan 
PLAN SORT (JOIN (JOIN (DC NATURAL, C INDEX (INTEG_38), D INDEX (PK_Drivers)), AO INDEX (Ind_Run_Time_Archive)))
планы запросов №2,3 не изменились, скорость их тоже стала 30-90ms

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 07 июл 2008, 19:26

Твоё "стал" как раз соответствует тому, что ты раньше показывал, а вот "был" я ещё не видел.
Что-то ты либо запутался, либо сказки рассказываешь (по поводу одинаковости плана).
Никакой бэкап-рестор не может так БД размером в жалкие полтора гига ускорить, хоть там три четверти мусорных записей будет.

Ulme
Сообщения: 16
Зарегистрирован: 27 июн 2008, 14:31

Сообщение Ulme » 07 июл 2008, 21:51

WildSery писал(а):Твоё "стал" как раз соответствует тому, что ты раньше показывал, а вот "был" я ещё не видел.
Дейстительно, надо поменять местами :oops:

про то, что невозможно такого ускорения...то я бы был только рад что такое не возможно, так как делать выезды к 20 клиентам(мало кто разрешает RAdmin ставить) для бэкап/рестора это мягко говоря гемморно. Но IBExpert показывает именно то, что запрос для базы упал с 40 секунд до 30-90мс.
Кстати для базы А после бекап/рестора этот же запрос обрабатывался за 1,5-2с, а стал тоже за 30-90мс

Интересно, что можно в базе еще "обновлять/исправлять", кроме свипа и обновления статистики индексов?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 07 июл 2008, 22:51

приложение надо исправлять. чтобы не плодило мусор.

Ulme
Сообщения: 16
Зарегистрирован: 27 июн 2008, 14:31

Сообщение Ulme » 10 июл 2008, 17:17

kdv писал(а):приложение надо исправлять. чтобы не плодило мусор.
А если есть таблица RunOrders, т.е. текущие заказы (которые через некоторое время попадают в ArchiveOrders), и в которой постоянно происходят Delete'ы и Update'ы, и мусора там в любом случае будет много.

Но сейчас интересно другое - что делает бэкап/рестор кроме очистки от мусора(не занятого транзакциями) + обновление статистики индексов + ... Х.Борри говорит о "освобождение пространства, занимаего удаленными записями и упаковку остальных данных что часто улучшает производительность", однако подробнее про последний момент не написано.

Мой запрос более-менее вменяемый, работает с нормальными индексам, мусор собран свипом. Так что же такое сделал бэкап/рестор, что время выполнения уменшилось на порядок?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 10 июл 2008, 18:21

что делает бэкап/рестор кроме очистки от мусора(не занятого транзакциями) + обновление статистики индексов +
"мусор, не занятый транзакциями"?
Вы бы лучше читали вот это:
www.ibase.ru/devinfo/garbage.htm#backup
Так что же такое сделал бэкап/рестор, что время выполнения уменшилось на порядок?
изменился план запроса.
из-за
1. пересчета статистики (при ресторе)
2. "дефрагментации" таблиц. Это надо было смотреть до и после IBAnalyst-ом.

p.s.
- бэкап читает все последние committed-версии запис и сохраняет их в файл
- рестор создает новую пустую БД и наливает туда данные из бэкапа

Ответить