День добрый,

2 Xeon 2.4 G, 2 Gb оперативки, сказя 10 rpm, linux, ASE 12.5.1, размер страници 4k, табличка 35 - 40 млн записей, вот нормальным по времени сколько будет считаться ( пусть даже приблизительно ) удаление из той таблички 350 - 400 тыс строк ?

MasterZivЭто от запроса вообще-то зависит. Так не скажешь.

просто

и еще в продолжение delete...

тот запрос блокирует таблицу полностью, если верить `Руководству по настройке производительности` один из способов избежать этого создать индекс. Я правильно понял что в этом конкретном случае это будет индекс по колонке `moment` ?

Как я уже говорил в данном запрсе в транзакции удаляется примерно 350 - 400 тыс строк, стоит ли копать в сторону уменьшения транзакции ?

блин сначала написал, потом подумал и проверил....

sp__helpindex говорит что:

тоесть индекс вроде есть, а таблица блокируется ексклюзивно... :(

MasterZiv g613sp__helpindex говорит что:


Вы пользуетесь sp__helpindex. А вы уверены, что он подходит к вашей версии ASE ? ПРосто если ASE новый, а sp__helpindex старый , то он может писать фигню всякую. Про кластерные индексы ( что их нет ), и т.п.

ну да, я уже ходил по граблям sp_helpindex vs sp__helpindex в ASE 12.5... :)

во в эом конкретном месте разница как раз в том что индекс ' Traffic.Traffic_84452701112 Y ID' d ltqcndbntkmyjcnb rkfcnthysq...

MasterZiv g613

Далено не все так просто
Какие @FROM и @TO , сколько таких записей в таблице, какая сама таблица, какая схема блокировки, какие в ней индексы, триггера ....


moment: datetime, разница @from и @to от суток ( сутки ~ 400 тыс строк ): datetime ( есть не кластерный индекс ),
схема блокировки: data row,
тригер только на insert,
индексы показывал....
....


Не, не могу сказать даже примерно.
Да на самом деле и не за чем.

у меня оно отрабатывает ~ за 2 - 3 часа ( и просто хотелось узнать нормально ли это... ), в связи с чем выбиралось время в течении суток/дня недели когда запускать такие запросы....

MasterZiv g613тот запрос блокирует таблицу полностью, если верить `Руководству по настройке производительности` один из способов избежать этого создать индекс.
Я правильно понял что в этом конкретном случае это будет индекс по колонке `moment` ?


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

А чтобы не блокировалась монопольно таблица, надо настраивать эскалацию блокировок и/или схему блокирования таблицы.
Или уменьшать размер транзакции.


Схема блокировки как уже говорил datarow.

Эскалация где вообще настраивается ? У меня вот подозрение что это sp_configure "lock promotion". если это оно то при описываемы мною размерах ( 400 тыс строк ) там должны быть такие же офигенно большие цифры ( просто 200 которые по умолчанию как то не вяжутся с сотнями тысяч... ) ?



g613
Как я уже говорил в данном запрсе в транзакции удаляется примерно 350 - 400 тыс строк, стоит ли копать в сторону уменьшения транзакции ?

Смотря с какой целью копать. Если в сторону ускорения удаления копать , то не стоит. А если в сторону неблокирования таблицы - стоит.

Вообще время за которое подчистятся устаревшие данные не столь актуально, хочется уйти от блокирования таблицы и вообще максимально сократить время блокировок....

Тоесть вот первое что щас видится это сократить числа 350 - 400 тыс до 35 - 40 тыс за раз...

MasterZivСхема блокировки как уже говорил datarow.

Ну так если у вас datarows , то вы вообще все можете в ONLine удалять, одновременно с работой других пользователей. Например, по 10 записей. Только надо естественно оттьюнить запрос, чтобы он по индексу шел.

Эскалация где вообще настраивается ? У меня вот подозрение что это sp_configure "lock promotion".


Да-да.

Только они настраиваются отдельно для APL и DOL.

В вашем случае sp_configure "row lock promotion".
Но еще можно настраивать и на уровне таблицы, смотрите sp_objattribute или как ее там. Ну sp_help на таблицу сделайте , там они будут болтаться (атрибуты).
Пороги задаются в виде "нижний порог" "процент" "верхний порог".


Вообще время за которое подчистятся устаревшие данные не столь актуально, хочется уйти от блокирования таблицы и вообще максимально сократить время блокировок....

Тоесть вот первое что щас видится это сократить числа 350 - 400 тыс до 35 - 40 тыс за раз...

Ну я не думаю, что это обязательно. Можно и не снижать, только добиться , чтобы таблица не блокировалась. Почитайте про пороги, если не поймете -
спрашивайте.

с блокировкой вроде разобрался ( sp_setrowlockpromote 'table', Traffic, 500000, 500000, 100; )


план запроса
[1336] billing.bill_2.1> set showplan on;
[1337] billing.bill_2.1> dbcc traceon(302);

QUERY PLAN FOR STATEMENT 1 (at line 1).


STEP 1
The type of query is DBCC.

DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
[1338] billing.bill_2.1> delete from traffic where moment between "07/09/2005" and "07/09/2005 14:00";

QUERY PLAN FOR STATEMENT 1 (at line 1).


STEP 1
The type of query is DELETE.
The update mode is direct.

FROM TABLE
traffic
Nested iteration.
Index : TrafficFKMoment
Forward scan.
Positioning by key.
Keys are:
Moment ASC
Using I/O Size 16 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
TO TABLE
traffic
Using I/O Size 4 Kbytes for data pages.

(147668 rows affected)


период был несколько укорочен, отработал за 13 минут, я вот подозреваю что некоторые тормоза были из за фрагментации ( в эти выходные reorg rebuild отработал ).

я вот несколько не понял смысл фразы "Ну так если у вас datarows , то вы вообще все можете в ONLine удалять, одновременно с работой других пользователей. Например, по 10 записей. Только надо естественно оттьюнить запрос, чтобы он по индексу шел."

Конкретно про 10 записей. Это про то что я говорил - уменьшить размер транзакции ?

MasterZivс блокировкой вроде разобрался
sp_setrowlockpromote 'table', Traffic, 500000, 500000, 100;

500000, 5000000 , 50 было бы лучше. А то так слишком жестко.

если это не опечатка, то боюсь у меня не будет 'лишних' 400 с хвостиком метров на поддержку такого количества блокировок... А вот про 50 процентов - я если чесно не совсем понял, если можно задать верхний и нижний пороги, то какой глубинный смысл задавать еще и проценты...

MasterZivПлан нормальный, индекс используется. Только IO здесь вот :
g613
Using I/O Size 16 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
TO TABLE
traffic


большое очень, если будете удалять по немногу.

Ну и даже если не понемгогу, то Using I/O Size 16 Kbytes for data pages
странновато выглядит - некластерный же индекс. Зачем читать 16к ?
Не понятно. Но надо смотреть на попадание в кэш.


хз, может от того что этот самый Moment не очень сильно 'размазан', то есть нет того, что сегодня данные добавляли с Moment = '10/17/2005' а вчера с Moment = '10/18/2005'....


g613я вот несколько не понял смысл фразы "Ну так если у вас datarows , то вы вообще все можете в ONLine удалять, одновременно с работой других пользователей. Например, по 10 записей. Только надо естественно оттьюнить запрос, чтобы он по индексу шел."

Конкретно про 10 записей. Это про то что я говорил - уменьшить размер транзакции ?


Да, про уменьшить. Но нужно это скорее не для разведения одновременных транзакций, потому как у вас datarows, а для уменьшения нагрузки на сервер по работе с логом и по выделению блокировок.


в общем предполагается что этот запрос будет отрабатываться когда сервер не сильно загружен, я вот щас выделил для себя отрезок в 3 часа, пока оно укладывается, если разбить на более мелкие транзакции я боюсь что оно не уложится и сумарная загрузка будет ни чуть не меньше.

Кстати, не забудьте убедиться в итоге, что вам будет хватать блокировок, в вашем случае одна удаляемая запись внутри одной транзакции - одна блокировка. Ну и чтобы другим еще хватало.

да, у меня number of lock 1_000_000 - 128 метров памяти откушало... :)

MasterZiv
Обычно задают Tlow < Percent < Thigh -- я вам про это и хотел сказать.
5миллионов - это конечно просто с потолка цифра.

Ok. Понятно.