iBase.ru Forum

Добрый день!

По некоторым индексам в базе скапливается много дубликатов, на FB 1.5 лечили при помощи INACTIVE/ACTIVE, на 2.0 такое не прокатывает, ругается на уникальный CONSTRAINT. Как вариант рассматривали ... DROP CONSTRAINT/... CREATE CONSTRAINT, однако если есть активные транзакции, интересующеся этим индексом, то CREATE не проходит. А главная проблема в том, что потенциально БД может работать круглосуточно и 7 дней в неделю, гарантии отсутствия подключений нет.
Есть ли еще какой способ сборки дубликатов в индексах?

Может есть какие-нибудь статьи на тему обслуживания круглосуточных БД? Буду рад ссылкам.

Спасибо!

Каких ещё дубликатов? О чём вообще речь идёт?
А самое интересное мне - как сказываются эти "дубликаты" на работе?

Сборке мусора всё едино - что в индексах, что не в индексах. Главное - чтоб долгоиграющих транзакций не было.

WildSery писал(а):Каких ещё дубликатов? О чём вообще речь идёт?
А самое интересное мне - как сказываются эти "дубликаты" на работе?

Речь идет о статистике, выдаваемой gstat'ом и анализируемой при помощи IBAnalyst.
например:
INDEX UNQ_.... keys: 3183, MaxDups: 1060, TotalDup: 3180

дубликаты замедляют поиск при помощи этого индекса

Сборке мусора всё едино - что в индексах, что не в индексах. Главное - чтоб долгоиграющих транзакций не было.

SELECT COUNT(*) для индексов не помогает к сожалению, а почему не собирает автоматически - непонятно.

да вы там весельчаки - при круглосуточной нагрузке выключать индексы констрейнтам. Вы хоть контрольный рестор бекапов практикуете?

SELECT COUNT(*) для индексов не помогает к сожалению, а почему не собирает автоматически - непонятно

ищите причину, должен помогать

dimitr писал(а):да вы там весельчаки - при круглосуточной нагрузке выключать индексы констрейнтам.

Пока это на рабочую базу не пошло, просто неудачные эксперименты

Вы хоть контрольный рестор бекапов практикуете?

Это оставляем на совести конечного юзера.

ищите причину, должен помогать

Т.е. SELECT COUNT(*) FROM TABLENAME теоретически должен собрать мусор по ВСЕМ индексам таблицы TABLENAME ? Правильно понимаю?

StriderMan писал(а): Т.е. SELECT COUNT(*) FROM TABLENAME теоретически должен собрать мусор по ВСЕМ индексам таблицы TABLENAME ? Правильно понимаю?

Если его не держит какая-нибудь застрявшая транзакция. Особенно снапшот.

Merlin писал(а):Если его не держит какая-нибудь застрявшая транзакция. Особенно снапшот

ну это понятно. Однако вот есть база, в которой версий записей в таблице нет, а ключей индекса по одному полю в несколько раз больше чем записей

StriderMan писал(а):INDEX UNQ_.... keys: 3183, MaxDups: 1060, TotalDup: 3180
дубликаты замедляют поиск при помощи этого индекса

Ужас. И сильно замедляют?

Мы вона пока на 2-ку не перелезли (там сборка мусора шустрая), наоборот сборку выключаем на весь день, чтоб не мешалась. По полтора лимона версий кое-где получается. Сколько там дупов - а фиг его знает.

Люди!!! Читайте хелп к ibanalyst!!! Откройте содержание хелпа, там есть "дополнительные вопросы и ответы". И написано как перестраивать индексы по констрейнтам. В любом случае, "скапливается много дубликатов" - это ахинея полная. Дубликатов в ключе столько, сколько их в столбце. Если мусор не собирается, опять же читайте хелп к IBA, там статья есть о том что вы видите на экране IBAnalyst, почему индексы "плохие" и т.п.

Судя по

INDEX UNQ_....

названию индекс уникальный?
если да, то как там вообще дубликаты получены?

StriderMan писал(а):ну это понятно. Однако вот есть база, в которой версий записей в таблице нет, а ключей индекса по одному полю в несколько раз больше чем записей

Есть такая особенность. Но наступить на неё - это нужно постараться.
Постоянно вставляете и удаляете одни и те же ключи на один и теже места (db_key).
Лучше иметь лишние ключи в индексе, чем отсутствующие...

stix-s писал(а):индекс уникальный?
если да, то как там вообще дубликаты получены?

Да, индекс уникальный, в том вся и засада. теоретически дубликатов быть не должно.

Есть такая особенность. Но наступить на неё - это нужно постараться.
Постоянно вставляете и удаляете одни и те же ключи на один и теже места (db_key).
Лучше иметь лишние ключи в индексе, чем отсутствующие...

специфика базы такова что в нее делается большое количество INSERT'ов и UPDATE'ов ЕЖЕДНЕВНО, вплоть до удаления и вставки почти всех записей всех таблиц, при этом размер базы относительно небольшой - как правило 10-100мб после backup/restore

БД используется во фронтофисном решении, соответственно идет очень активный обмен с бэком.