Сборка мусора по индексам
Модераторы: kdv, Alexey Kovyazin
-
- Сообщения: 7
- Зарегистрирован: 29 авг 2006, 12:12
Сборка мусора по индексам
Добрый день!
По некоторым индексам в базе скапливается много дубликатов, на FB 1.5 лечили при помощи INACTIVE/ACTIVE, на 2.0 такое не прокатывает, ругается на уникальный CONSTRAINT. Как вариант рассматривали ... DROP CONSTRAINT/... CREATE CONSTRAINT, однако если есть активные транзакции, интересующеся этим индексом, то CREATE не проходит. А главная проблема в том, что потенциально БД может работать круглосуточно и 7 дней в неделю, гарантии отсутствия подключений нет.
Есть ли еще какой способ сборки дубликатов в индексах?
Может есть какие-нибудь статьи на тему обслуживания круглосуточных БД? Буду рад ссылкам.
Спасибо!
По некоторым индексам в базе скапливается много дубликатов, на FB 1.5 лечили при помощи INACTIVE/ACTIVE, на 2.0 такое не прокатывает, ругается на уникальный CONSTRAINT. Как вариант рассматривали ... DROP CONSTRAINT/... CREATE CONSTRAINT, однако если есть активные транзакции, интересующеся этим индексом, то CREATE не проходит. А главная проблема в том, что потенциально БД может работать круглосуточно и 7 дней в неделю, гарантии отсутствия подключений нет.
Есть ли еще какой способ сборки дубликатов в индексах?
Может есть какие-нибудь статьи на тему обслуживания круглосуточных БД? Буду рад ссылкам.
Спасибо!
-
- Сообщения: 7
- Зарегистрирован: 29 авг 2006, 12:12
Речь идет о статистике, выдаваемой gstat'ом и анализируемой при помощи IBAnalyst.WildSery писал(а):Каких ещё дубликатов? О чём вообще речь идёт?
А самое интересное мне - как сказываются эти "дубликаты" на работе?
например:
INDEX UNQ_.... keys: 3183, MaxDups: 1060, TotalDup: 3180
дубликаты замедляют поиск при помощи этого индекса
SELECT COUNT(*) для индексов не помогает к сожалению, а почему не собирает автоматически - непонятно.Сборке мусора всё едино - что в индексах, что не в индексах. Главное - чтоб долгоиграющих транзакций не было.
-
- Сообщения: 7
- Зарегистрирован: 29 авг 2006, 12:12
dimitr писал(а):да вы там весельчаки - при круглосуточной нагрузке выключать индексы констрейнтам.
Пока это на рабочую базу не пошло, просто неудачные эксперименты
Это оставляем на совести конечного юзера.Вы хоть контрольный рестор бекапов практикуете?
Т.е. SELECT COUNT(*) FROM TABLENAME теоретически должен собрать мусор по ВСЕМ индексам таблицы TABLENAME ? Правильно понимаю?ищите причину, должен помогать
-
- Сообщения: 7
- Зарегистрирован: 29 авг 2006, 12:12
Ужас. И сильно замедляют?StriderMan писал(а):INDEX UNQ_.... keys: 3183, MaxDups: 1060, TotalDup: 3180
дубликаты замедляют поиск при помощи этого индекса
Мы вона пока на 2-ку не перелезли (там сборка мусора шустрая), наоборот сборку выключаем на весь день, чтоб не мешалась. По полтора лимона версий кое-где получается. Сколько там дупов - а фиг его знает.
Люди!!! Читайте хелп к ibanalyst!!! Откройте содержание хелпа, там есть "дополнительные вопросы и ответы". И написано как перестраивать индексы по констрейнтам. В любом случае, "скапливается много дубликатов" - это ахинея полная. Дубликатов в ключе столько, сколько их в столбце. Если мусор не собирается, опять же читайте хелп к IBA, там статья есть о том что вы видите на экране IBAnalyst, почему индексы "плохие" и т.п.
Есть такая особенность. Но наступить на неё - это нужно постараться.StriderMan писал(а):ну это понятно. Однако вот есть база, в которой версий записей в таблице нет, а ключей индекса по одному полю в несколько раз больше чем записей
Постоянно вставляете и удаляете одни и те же ключи на один и теже места (db_key).
Лучше иметь лишние ключи в индексе, чем отсутствующие...
-
- Сообщения: 7
- Зарегистрирован: 29 авг 2006, 12:12
Да, индекс уникальный, в том вся и засада. теоретически дубликатов быть не должно.stix-s писал(а):индекс уникальный?
если да, то как там вообще дубликаты получены?
специфика базы такова что в нее делается большое количество INSERT'ов и UPDATE'ов ЕЖЕДНЕВНО, вплоть до удаления и вставки почти всех записей всех таблиц, при этом размер базы относительно небольшой - как правило 10-100мб после backup/restoreЕсть такая особенность. Но наступить на неё - это нужно постараться.
Постоянно вставляете и удаляете одни и те же ключи на один и теже места (db_key).
Лучше иметь лишние ключи в индексе, чем отсутствующие...
БД используется во фронтофисном решении, соответственно идет очень активный обмен с бэком.