Есть простая табличка:


Primary Key - REGIM_ID. На эту таблицу по Foreign Key ссылаются еще 18 таблиц (каскадное удаление не назначено).
В таблице около 50 000 записей. Сначала удаляю записи из зависимых таблиц по REGIM_ID - выполняется быстро. Но последний шаг:


выполняется около 4 минут. В чем может быть дело?

Что-то с трудом верится ..

Верится - не верится, а факт. Меня "приставили к стенке" и требуют срочно исправить ситуацию, которая возникла недавно, до этого все работало с удовлетворительной скоростью.

Только с этой таблицей, или с любой?
Лог, случаем, за какой-нибудь большой размер не вылез?

Проблемы только с этой таблицей (отличается от других большим кол-вом FK). Сама база довольно большая 6Гб, под T-Log выделено 150 Мб, занято 18 Мб.

это очистка таблиц? транкейт не работает? (если внешний ключ с удалением из зависимой)
отключить или удалить его перед очисткой? (с последующим восстановлением конечно)

Транкейтить нельзя, т.к. удаляется выборочная информация. Каскадное удаление убрала умышленно, т.к. MSSQL не справляется с таким кол-вом (больше каскадных 5 ключей - и вешается)

Триггер на delete есть?

> Каскадное удаление убрала умышленно
как?
проверка очевидно остается иначе не было бы так долго. вот проверь, скопируй таблицу с данными в независимую от ключей и удали тоже самое из нее (индексы по полям где условию не забудь в ней воссоздать те же что в оригинале). и как? быстро?
если быстро то значит проверки есть и их надо отключать (анчек констраинтам делать)...
в принципе 18 проверок в 18 таблицах к удалению каждой записи... понятно что долго будет.

подожди,
> Primary Key - REGIM_ID.
> ... REGIM_ID=2265
это одна запись удаляется 4 минуты? ....

Асе-таки похоже на "тормоза" при исполнении тела триггера на удаление ..

> это одна запись удаляется 4 минуты? ....


Похоже на то. Что удивительно.

Триггеров нет и галочек на констраинтах нет (зуб даю, это первое, что я проверила), а работает так, как будто они есть.
Что-то с самой таблицей неладно - даже SELECT выполняется медленно.
Изменила незначительно структуру таблицы (чтобы прошел ALTER TABLE), удаление стало работать 1.5 минуты. Но это тоже не годится, нужно около 10 сек.

Похоже что поле первичного ключа перстало быть индексированным.
Либо индекс выключен либо его там вообще никогда не было.

> либо его там вообще никогда не было.
->
> Есть простая табличка:
> ...
его и нет. :)  если по скрипту
разве что в заявлении
> Primary Key - REGIM_ID

да на сервере тупо идет проверка по всей куче ссылающихся таблиц

> sniknik ©   (12.01.09 12:17) [14]



> его и нет


А как тогда автор умудрилась организовать связь с подчиненными таблицами и каскадные операции ?
Или эта СУБД позволяет подобные вольности ? Я просто не в курсе..

не было бы пк, форин констрейнты на REGIMS не создались бы

Ну что вы, господа, я понимаю праздники... но я уж не до такой степени...
PK есть и 18 FK, соответственно, есть. В скрипт не включила, чтобы место сэкономить.

> Или эта СУБД позволяет подобные вольности ? Я просто не в курсе..
не пробовал, но вроде не должен.

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