Мастера 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 минут. В чем может быть дело?

(2009-04-01 13:06:00) [1]
Удалено модератором

(2009-04-01 13:06:00) [2]
Удалено модератором

Petr V. Abramov (2009-01-15 21:47:00) [3]

> sniknik © (15.01.09 00:38) [44]
> > Если никто дальше на таблицу не ссылается ...
> 18 таблиц в fk.

имеется в виду "ссылающиеся" таблицы, у которых pk большой.
P.S. из постов вроде следует, что к чему

Anatoly Podgoretsky (2009-01-15 00:53:00) [4]
> Petr V. Abramov (15.01.2009 0:14:43) [43]

Взял да испортил, второе как раз дополняло первое и было прекрасно.

sniknik (2009-01-15 00:38:00) [5]
> Если никто дальше на таблицу не ссылается ...
18 таблиц в fk.

Petr V. Abramov (2009-01-15 00:14:00) [6]

> yb d where

блин,
ни в where
;)

Petr V. Abramov (2009-01-15 00:14:00) [7]

> ни в цруку

yb d where

Petr V. Abramov (2009-01-15 00:14:00) [8]

> Ega23 © (14.01.09 20:02) [40]

причем тут суррогатный ключ???
если по логике какая-то комбинация уникальная, она и должна быть объявлена unique или pk. Если никто дальше на таблицу не ссылается, то нафих еще и суррогатный ключ городить - поле, которое никогда не будет не будет ни в select <field list>, ни в цруку

Ega23 (2009-01-14 20:02:00) [9]

> его достаточно, если REGIM_ID первым полем в PK.

Ага.
Вот наглядный пример преимущества суррогатного ключа.

Petr V. Abramov (2009-01-14 19:23:00) [10]

> Ольга © (14.01.09 09:44) [36]

> Да, не было. На таблицах были только PK (из 3-5 полей, одно
> из которых REGIM_ID). Я считала, что этого индекса достаточно.
>

его достаточно, если REGIM_ID первым полем в PK.

Ольга (2009-01-14 10:27:00) [11]
Эх, пивко, да с рыбкой, да в хорошей компании... Но, конечно, далековато, потому остается только виртуальное общение: roeva@tsgrp.ru
Круг моих интересов, в общем, должен быть уже понятен - построение оптимальных БД промышленного масштаба (то бишь куча данных, ежесекундно в БД что-нибудь пишется и что-нибудь удаляется). Буду рада любой полезной информации на эту тему.

Ega23 (2009-01-14 10:08:00) [12]

> Конечно, хотелось бы понять, где в MSSQL лежат грабли (для
> которых 7 и 8 млн. зап. - большая разница), чтобы при проектировании
> следующей БД либо не наступать на них, либо вообще ликвидировать.

Надо эксперементировать. Я сейчас точно не скажу (а врать неохота..), была некая рекомендация по построению индексов.
И время-от-времени надо индексы перестраивать. Когда данные изменились ~на 20% от первоначальных - надо перестраивать, ибо может оказаться, что с индексами даже хуже.

> А это где? Я бы с удовольствием подключилась к всемирному
> разуму...

э-э-э-э.... Дело в том, что с Абрамовым мы регулярно обсуждаем всякое... Под пиво.... На Савёловском вокзале есть 2 чудных места - "Салун Бочка" и "Золотая Вобла". Ну а поскольку мне как раз оттуда домой ехать (в Дубну) - то сам Аллах велел.
Так что ежели тебе из Ебурга до Москвы недалеко - милости просим, клуб не закрытый... :) Мыло давай.. :)

Ольга (2009-01-14 09:44:00) [13]

> У Вас его не было? Да на таких-то объёмах???

Да, не было. На таблицах были только PK (из 3-5 полей, одно из которых REGIM_ID). Я считала, что этого индекса достаточно. Да и работало все нормально (6 млн. зап., согласитесь, тоже не мало), я и не задумывалась.
Конечно, хотелось бы понять, где в MSSQL лежат грабли (для которых 7 и 8 млн. зап. - большая разница), чтобы при проектировании следующей БД либо не наступать на них, либо вообще ликвидировать.

> на следующей неделе обсудим в стандартном месте...

А это где? Я бы с удовольствием подключилась к всемирному разуму...

ЮЮ (2009-01-14 08:31:00) [14]

> если у индекса отключена проверка

индеса нет. есть только Constraint

> то "обеспечение" как таковое не производится

И в чем же тогда Constraint состоит? :)
Ибо сказано The constraint enforces referential integrity by guaranteeing that changes cannot be made to data in the primary key table if those changes invalidate the link to data in the foreign key table. If an attempt is made to delete the row in a primary key table or to change a primary key value, the action will fail when the deleted or changed primary key value corresponds to a value in the FOREIGN KEY constraint of another table. To successfully change or delete a row in a FOREIGN KEY constraint, you must first either delete the foreign key data in the foreign key table or change the foreign key data in the foreign key table, which links the foreign key to different primary key data.

> (uncheck у fk)

Имхо, не для тех целей. Forcing a FOREIGN KEY Constraint by Using WITH NOCHECK относится к непроверке уже существующих до создания Constraint-а данных.

sniknik (2009-01-13 21:07:00) [15]
> обеспечения Foreign Key - отсюда и тормоза.
если у индекса отключена проверка (uncheck у fk) то "обеспечение" как таковое не производится.

Ega23 (2009-01-13 20:04:00) [16]

> ля каждой из 18 зависимых таблиц создала индекс по REGIM_ID

У Вас его не было? Да на таких-то объёмах???

> почему критическая масса 8, а не 6.5 и не 12? :) Как ее
> предсказать, есть какая-нить методика?

На досуге поковыряюсь, на следующей неделе обсудим в стандартном месте... :)

Petr V. Abramov (2009-01-13 18:23:00) [17]

> Как только в одной из таблиц перевалило за 8 млн. (достигло
> критической массы) - все резко (без объявления войны) затормозилось.
>

теперь один вопрос остался - почему критическая масса 8, а не 6.5 и не 12? :) Как ее предсказать, есть какая-нить методика?
P.S. спрашиваю из праздного любопытства ;)

Ольга (2009-01-13 13:03:00) [18]

> В тех таблицах, который ссылаются на "проблемную", нужно
> ещё и индексы по полю связи иметь, ибо без них происходит
> полный скан тех самых таблиц для обеспечения Foreign Key
> - отсюда и тормоза.

Как только прочитала этот пост, сразу поняла, что это и есть решение проблемы. Восстановила все FK на таблицу REGIMS, для каждой из 18 зависимых таблиц создала индекс по REGIM_ID, до кучи выполнила DBCC INDEXDEFRAG на REGIMS. Теперь все летает!
Почему это решение не пришло мне самой в голову? Видимо, потому, что замедление началось не постепенно, а сразу. Пока в зависимых таблицах было по 6-7 млн. записей, все было благополучно. Как только в одной из таблиц перевалило за 8 млн. (достигло критической массы) - все резко (без объявления войны) затормозилось.
Большое спасибо всем за помощь.

clickmaker (2009-01-12 14:21:00) [19]
DBCC INDEXDEFRAG сделай
почисти лог транзакций
посмотри, что вызывает такие тормоза
http://msdn.microsoft.com/ru-ru/magazine/cc135978.aspx

ЮЮ (2009-01-12 13:15:00) [20]

> Временно удалила все FK - удаление работает за 1 сек. Причину
> пока так и не определила.
> Все, пошла "на ковер", сдаваться.

> На эту таблицу по Foreign Key ссылаются еще 18 таблиц

В тех таблицах, который ссылаются на "проблемную", нужно ещё и индексы по полю связи иметь, ибо без них происходит полный скан тех самых таблиц для обеспечения Foreign Key - отсюда и тормоза.

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

Наверх

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