Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Долго выполняется DELETE [MSSQL]

Страницы: < 1 2 3 >
Ольга © (2009-01-12 11:01:00)
Есть простая табличка:
CREATE TABLE [dbo].[REGIMS] ( [REGIM_ID] [int] NOT NULL , [OPERMODE] [int] NULL , [CREATED] [datetime] NULL , [FINISHED] [datetime] NULL , [FIXED] [int] NULL , [SHORT_NAME] [varchar] (20) , [BALANCED] [int] NULL , [DESCRIPTION] [varchar] (240) NULL ) ON [PRIMARY]
Primary Key - REGIM_ID. На эту таблицу по Foreign Key ссылаются еще 18 таблиц (каскадное удаление не назначено).
В таблице около 50 000 записей. Сначала удаляю записи из зависимых таблиц по REGIM_ID - выполняется быстро. Но последний шаг:
DELETE FROM REGIMS WHERE REGIM_ID=2265
выполняется около 4 минут. В чем может быть дело?

sniknik (2009-01-12 12:57:00) [21]
> удаление работает за 1 сек.
из 50 тыс? долго. у меня из миллиона одна запись по ключу удаляется 0,01 сек.

sniknik (2009-01-12 12:55:00) [22]
> Временно удалила все FK - удаление работает за 1 сек.
а я предлагал... но только анчек сделать, а после удаления восстановить. но вообще даже 18 проверок для удаления одной записи это слишком (что 4 что 1.5 мин)

sniknik (2009-01-12 12:52:00) [23]
> Что произошло сегодня?
вопрос конечно интересный, но как быть без достоверной инфы???

зайди в QA, найди в браузере объектов свою таблицу и сделай скрипт на ее создание (реальный скрипт, реальной таблицы!), и приведи его (получившийся скрипт) весь as is не экономя место (переживем как нибудь дополнительную сотню другую байт)...

и то же самое для таблицы с fk ссылающейся на эту, любой из 18 если они однотипны.

Ольга (2009-01-12 12:49:00) [24]
Временно удалила все FK - удаление работает за 1 сек. Причину пока так и не определила.
Все, пошла "на ковер", сдаваться.

Медвежонок Пятачок (2009-01-12 12:48:00) [25]
А мне не очень, что вчера проверок не было? Что произошло сегодня?

о! моя любимая жалоба пользователей.
"почему сломалось, ведь вчера же работало?!"

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

и так далее.

итого: в "калинке" продают вечные чайники.

Ольга (2009-01-12 12:41:00) [26]
в
> ну ежу же понятно.

А мне не очень, что вчера проверок не было? Что произошло сегодня? Возможно, конечно, что база сегодня уже потежелее...

Медвежонок Пятачок (2009-01-12 12:36:00) [27]
тормоза из за проверок 18 таблиц на возможные нарушение fk после удаления ключа.

ну ежу же понятно.

sniknik (2009-01-12 12:35:00) [28]
и кстати скрипт похож (очень похож) на автосгенеренный в QA.

sniknik (2009-01-12 12:34:00) [29]
> В скрипт не включила, чтобы место сэкономить.
утаивание инфы обычно приводит к обратному... даже к многостраничному флуду.

sniknik (2009-01-12 12:33:00) [30]
> Или эта СУБД позволяет подобные вольности ? Я просто не в курсе..
не пробовал, но вроде не должен.

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

Ольга (2009-01-12 12:32:00) [31]
Ну что вы, господа, я понимаю праздники... но я уж не до такой степени...
PK есть и 18 FK, соответственно, есть. В скрипт не включила, чтобы место сэкономить.

Медвежонок Пятачок (2009-01-12 12:29:00) [32]
не было бы пк, форин констрейнты на REGIMS не создались бы

Сергей М. (2009-01-12 12:24:00) [33]

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

> его и нет

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

Медвежонок Пятачок (2009-01-12 12:24:00) [34]
да на сервере тупо идет проверка по всей куче ссылающихся таблиц

sniknik (2009-01-12 12:17:00) [35]
> либо его там вообще никогда не было.
->
> Есть простая табличка:
> ...
его и нет. :) если по скрипту
разве что в заявлении
> Primary Key - REGIM_ID

Сергей М. (2009-01-12 12:07:00) [36]
Похоже что поле первичного ключа перстало быть индексированным.
Либо индекс выключен либо его там вообще никогда не было.

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

Ega23 (2009-01-12 11:53:00) [38]

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

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

Сергей М. (2009-01-12 11:52:00) [39]
Асе-таки похоже на "тормоза" при исполнении тела триггера на удаление ..

sniknik (2009-01-12 11:50:00) [40]
подожди,
> Primary Key - REGIM_ID.
> ... REGIM_ID=2265
это одна запись удаляется 4 минуты? ....

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »