_d_m_ пишет:

> MZ>Да какой же будет bulk insert в триггере-то ?
> MZ>Или bulk delete.
>
> Ты лучше на вопрос ответь — альтернатива моему решению. А я скажу, чем
> она хуже.

Я не понимаю, в чём решение.

Вот оно:

[quot]
Зато есть представления и замещающие триггеры.
Создать представление, например так:

create view vTabDelete
as
select
*
from
Tab
where
1 = 0


Вешаем на него замещающий триггер на вставку, который будет удалять данные — вот
и получился bulk delete
[/quot]


Т.е.
-- мы создаём View, ничего не возвращающий, содержащий только PK таблицы
(можно и другие поля, но не обязательно)
-- Вместо того, чтобы удалять данные из основной таблицы, мы вставляем
данные во VIEW
-- На VIEW висит триггер INSTEAD OF INSERT, который вставленные в эту таблицу
записи удаляет из основной таблицы.
(тут надо сказать, что эта операция уже не bulk, потому что серверу для
формирования INSERTED/DELETED надо физически данные записать куда-то.
Это куда-то -- лог и/или tempdb)

(правильно ли я понял предлагаемое решение ?)

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

Так в чём выигрыш-то ? Чем это лучше обычного DELETE на
ту же таблицу, выполненный непосредственно с клиента ?
или вызова хранимой процедуры ?

Операция BULK INSERT сама разбивает все записи на пакеты, размер которых задается параметром BATCHSIZE (или KILOBYTES_PER_BATCH). Для каждого пакета создается своя транзакция, поэтому для оптимального быстродействия нужно указать такой размер пакета, чтобы транзакция помещалась в оперативную память без особых напрягов. ПО УМОЛЧАНИЮ BULK INSERT выполняет всю вставку в одном пакете, что приводит к записи на диск в случае нехватки памяти.

Аноним это я

Здравствуйте, MasterZiv, Вы писали:

MZ>Так в чём выигрыш-то ? Чем это лучше обычного DELETE на
MZ>ту же таблицу, выполненный непосредственно с клиента ?
MZ>или вызова хранимой процедуры ?

На вход delete подается множество ключей строк, которые надо удалить. Как выполнить такой delete с клиента?

Здравствуйте, MasterZiv, Вы писали:

MZ>Ты посчитай внимательно, пальчики позагибай, делаем это , потом это,
MZ>потом это ... и -- в двух вариантах. Увидешь, что в одном (твоём)
MZ>пальчиков загнётся больше.

Один апдейт, обновляющий 1000 записей, выполняется быстрее , чем 1000 отдельный апдейтов.
Закачав bulk insert-ом новые значения во временную таблицу можно будет обновить все записи за одну операцию.

Здравствуйте, sergunok, Вы писали:

S>Имеется БД, управляемая SQL Server 2008..
S>Периодически в ней необходимо INSERT'ить и UPDATE'ить
S>приличное кол-во данных. Это происходит разово и массово. Десятки миллионов записей в ~ 100 таблицах.

S>Каким образом обеспечить наибольшую производительность перечисленных запросов?

S>Для INSERT'а рассматривается вариант BULK INSERT.
S>Есть мысль про одну или несколько больших транзакций. Это будет быстрее чем транзакция на каждый запрос?

Имею опыт оптимизации данной ситуации.
Первое, что нужно сделать — "пересадить" инстанс из аппаратного узла "NODE 0", допустим на "NODE 1".
Второе — включить режим AWE. Это делается с помощью следующего кода:

sp_configure 'awe enabled', 1
RECONFIGURE
GO

Третье, что нужно сделать — обеспечить привязку потоков ввода-вывода SQL Server'. Это делается с помощью параметра affinity I/O mask. Его надо установить в 1.

_d_m_ пишет:

> На вход delete подается множество ключей строк, которые надо удалить.
> Как выполнить такой delete с клиента?

А, я понял, ты знаешь MSSQL, но не знаешь SQL.

delete [from] MyTable t
where t.pk in ( 1,2,34,45,6454,2000 )


или

delete [from] MyTable t
where t.pkfld1 = 'a' and t.pkfld2 = 1
or t.pkfld1 = 'b' and t.pkfld2 = 2
or t.pkfld1 = 'c' and t.pkfld2 = 3
...

Аноним 315 пишет:

> Операция BULK INSERT сама разбивает все записи на пакеты, размер которых
> задается параметром BATCHSIZE (или KILOBYTES_PER_BATCH). Для каждого
> пакета создается своя транзакция, поэтому для оптимального

Ну и ?

Здравствуйте, MasterZiv, Вы писали:

MZ>_d_m_ пишет:

>> На вход delete подается множество ключей строк, которые надо удалить.
>> Как выполнить такой delete с клиента?

MZ>А, я понял, ты знаешь MSSQL, но не знаешь SQL.

MZ>delete [from] MyTable t
MZ>where t.pk in ( 1,2,34,45,6454,2000 )

MZ>или

MZ>delete [from] MyTable t
MZ>where t.pkfld1 = 'a' and t.pkfld2 = 1
MZ> or t.pkfld1 = 'b' and t.pkfld2 = 2
MZ> or t.pkfld1 = 'c' and t.pkfld2 = 3
MZ>...



Ключей 100000 — как быть?
1) Сразу напарываемся на ограничение размера батча.
2) Мне этот оператор надо в памяти конструировать в виде строки.

В случае использования .Net класса SqlBulkCopy я просто открываю DataReader на одном сервере и передаю его на выполнение в SqlBulkCopy на другом сервере.

_d_m_ пишет:

> Ключей 100000 — как быть?

А ты поглянь на спецификации ограничений, там кол-во
элементов в IN очень-очень большое. Вполне возможно, что
все 100000 и влезут.

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

Ну и остаётся вариант с OR -ами.

И потом, такие большие пачки данных так и так плохо удалять
одним махом.

Здравствуйте, MasterZiv, Вы писали:

MZ>_d_m_ пишет:

>> Ключей 100000 — как быть?

MZ>А ты поглянь на спецификации ограничений, там кол-во
MZ>элементов в IN очень-очень большое. Вполне возможно, что
MZ>все 100000 и влезут.

Я же говорю, на ограничение размера батча напарываемся: макс размер батча = размер сетевого пакета * 8. Да и преобразование всего этого хозяйства в строку тоже небесплатно.

MZ>Я не большой сторонник такого подхода, но раз уж ты
MZ>заикнулся, что это вроде бы как невозможно, то ...

MZ>Ну и остаётся вариант с OR -ами.

Я же говорю, на ограничение размера батча напарываемся: макс размер батча = размер сетевого пакета * 8. Да и преобразование всего этого хозяйства в строку тоже небесплатно.

MZ>И потом, такие большие пачки данных так и так плохо удалять
MZ>одним махом.

Ну тем не менее — на все-провсе один оператор: delete ... from ... inner join inserted

Здравствуйте, _d_m_, Вы писали:

___>Ключей 100000 — как быть?
___>1) Сразу напарываемся на ограничение размера батча.
Дробить на куски которые входят.
___>2) Мне этот оператор надо в памяти конструировать в виде строки.
Параметры отменили? Генерация "delete from T where id in (@p1, @p2, ....., @pN ) настолько дешевая операция, что ей можно пренебречь (хинт: генерируем всю строку заранее, потом берем начало с нужным числом параметров и добавляем закрывающую скобку).

___>В случае использования .Net класса SqlBulkCopy я просто открываю DataReader на одном сервере и передаю его на выполнение в SqlBulkCopy на другом сервере.

Как обычно есть плюсы и минусы:

+ быстрее (возможно) доставляем данные к серверу, это преимущество возможно сыграет при плохих каналах
+ проще код клиента
— сложнее код на стороне сервера
— сервер может сделать поиск и удаление нескольких записей сразу более оптимальным чем удаление каждой из них по одному

Хотя насчет массового insert or update идея BULK INSERT + INSTEAD OF INSERT TRIGGER интересная.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, _d_m_, Вы писали:

___>>Ключей 100000 — как быть?
___>>1) Сразу напарываемся на ограничение размера батча.
Z>Дробить на куски которые входят.

Усложнение кода.

___>>2) Мне этот оператор надо в памяти конструировать в виде строки.
Z>Параметры отменили? Генерация "delete from T where id in (@p1, @p2, ....., @pN ) настолько дешевая операция, что ей можно пренебречь (хинт: генерируем всю строку заранее, потом берем начало с нужным числом параметров и добавляем закрывающую скобку).

Ага, а потом эти параметры надо еще присвоить. Перебрать эти записи из рекордсета... Нафига? Когда есть простой вариант SqlBulkCopy.

___>>В случае использования .Net класса SqlBulkCopy я просто открываю DataReader на одном сервере и передаю его на выполнение в SqlBulkCopy на другом сервере.

Z>Как обычно есть плюсы и минусы:

Z>+ быстрее (возможно) доставляем данные к серверу, это преимущество возможно сыграет при плохих каналах
Z>+ проще код клиента
Z>- сложнее код на стороне сервера

Какие сложности то? В коде замещающего триггера:
1) для новых и обновленных данных: два оператора — update/insert или один merge для MS SQL 2008;
2) для удаленных: один delete

Z>- сервер может сделать поиск и удаление нескольких записей сразу более оптимальным чем удаление каждой из них по одному

Эээ... Чего?

Здравствуйте, _d_m_, Вы писали:

___>Какие сложности то? В коде замещающего триггера:
___>1) для новых и обновленных данных: два оператора — update/insert или один merge для MS SQL 2008;
___>2) для удаленных: один delete

Для каждой таблицы. По мне так это совсем не проще, десятка строк в коде репликации для генерации делита.

Z>>- сервер может сделать поиск и удаление нескольких записей сразу более оптимальным чем удаление каждой из них по одному

___>Эээ... Чего?

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

Здравствуйте, sergunok, Вы писали:

S>Имеется БД, управляемая SQL Server 2008..
S>Периодически в ней необходимо INSERT'ить и UPDATE'ить
S>приличное кол-во данных. Это происходит разово и массово. Десятки миллионов записей в ~ 100 таблицах.

S>Каким образом обеспечить наибольшую производительность перечисленных запросов?

S>Для INSERT'а рассматривается вариант BULK INSERT.
S>Есть мысль про одну или несколько больших транзакций. Это будет быстрее чем транзакция на каждый запрос?

S>Посоветуйте plz!!!
Даже интересно как с этим делом обстоит в 2008 SQL Server, но попробуй удалить индексы, а после вставки/обновления их пересоздать.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, _d_m_, Вы писали:

___>>Какие сложности то? В коде замещающего триггера:
___>>1) для новых и обновленных данных: два оператора — update/insert или один merge для MS SQL 2008;
___>>2) для удаленных: один delete

Z>Для каждой таблицы. По мне так это совсем не проще, десятка строк в коде репликации для генерации делита.

Ну естественно мы рассматриваем таблицу. Но эту проблему мы решаем кодогенерацией.

Z>>>- сервер может сделать поиск и удаление нескольких записей сразу более оптимальным чем удаление каждой из них по одному

___>>Эээ... Чего?

Z>Страница на которой мы уже удаляли запись и будем удалять еще одну может быть сброшена на диск, так как серверу неоткуда узнать, что в этом же контексте мы удалим еще одну запись с нее же. Если же сервер знает про обе записи — он удалит сразу обе, повторное обращение к странице не потребуется.

Спасибо Капитан Очевидность. Ну и к чему это ты вообще?

Здравствуйте, _d_m_, Вы писали:

Z>>Для каждой таблицы. По мне так это совсем не проще, десятка строк в коде репликации для генерации делита.

___>Ну естественно мы рассматриваем таблицу. Но эту проблему мы решаем кодогенерацией.

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

Z>>>>- сервер может сделать поиск и удаление нескольких записей сразу более оптимальным чем удаление каждой из них по одному

___>>>Эээ... Чего?

Z>>Страница на которой мы уже удаляли запись и будем удалять еще одну может быть сброшена на диск, так как серверу неоткуда узнать, что в этом же контексте мы удалим еще одну запись с нее же. Если же сервер знает про обе записи — он удалит сразу обе, повторное обращение к странице не потребуется.

___>Спасибо Капитан Очевидность. Ну и к чему это ты вообще?

К выделенному естественно. Как видно по истории, я тоже считал это очевидным и не стал разжевывать сразу.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, _d_m_, Вы писали:

Z>>>Для каждой таблицы. По мне так это совсем не проще, десятка строк в коде репликации для генерации делита.

___>>Ну естественно мы рассматриваем таблицу. Но эту проблему мы решаем кодогенерацией.

Z>Ага, т.е. чтобы не писать 10 строк мы напишем тыщу, но автоматизируем это кодогенерацией, интересный ход мысли.

Не надо передергивать. Какую нафиг тыщу? Пара представлений на таблицу с тригерами из одного/двух операторов каждый.

Z>>>>>- сервер может сделать поиск и удаление нескольких записей сразу более оптимальным чем удаление каждой из них по одному

___>>>>Эээ... Чего?

Z>>>Страница на которой мы уже удаляли запись и будем удалять еще одну может быть сброшена на диск, так как серверу неоткуда узнать, что в этом же контексте мы удалим еще одну запись с нее же. Если же сервер знает про обе записи — он удалит сразу обе, повторное обращение к странице не потребуется.

___>>Спасибо Капитан Очевидность. Ну и к чему это ты вообще?

Z>К выделенному естественно. Как видно по истории, я тоже считал это очевидным и не стал разжевывать сразу.

Собственно какое отношение это имеет к предложенному мною подходу? Где там удаляется по одной записи? Донеси до нас свою мысль.

Здравствуйте, _d_m_, Вы писали:

___>Не надо передергивать. Какую нафиг тыщу? Пара представлений на таблицу с тригерами из одного/двух операторов каждый.

Итого 3 строки на таблицу. Таблиц сколько?

Z>>К выделенному естественно. Как видно по истории, я тоже считал это очевидным и не стал разжевывать сразу.

___>Собственно какое отношение это имеет к предложенному мною подходу? Где там удаляется по одной записи? Донеси до нас свою мысль.

Опять вызываем Капитана Очевидность? Сколько записей удаляет триггер за одну операцию? Он выполняет операцию поиска и записи удаления для каждого PK. По одной записи.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, _d_m_, Вы писали:

___>>Не надо передергивать. Какую нафиг тыщу? Пара представлений на таблицу с тригерами из одного/двух операторов каждый.

Z>Итого 3 строки на таблицу. Таблиц сколько?

А какая разница? Я же сказал — кодогенерация.

Z>>>К выделенному естественно. Как видно по истории, я тоже считал это очевидным и не стал разжевывать сразу.

___>>Собственно какое отношение это имеет к предложенному мною подходу? Где там удаляется по одной записи? Донеси до нас свою мысль.

Z>Опять вызываем Капитана Очевидность? Сколько записей удаляет триггер за одну операцию? Он выполняет операцию поиска и записи удаления для каждого PK. По одной записи.

Ах вот она где собака порылась! Ты оказывацо не знаешь как работает триггер. Так вот триггер выполняется ровно один раз на ровно один оператор.