Механизм в T-SQL похож на SAVE EXCEPTIONS в Oracle

Question

Существует ли механизм, аналогичный Oracle PL / SQL SAVE EXCEPTIONS в Microsoft T-SQL? В настоящее время я делаю обновление с помощью курсора, и это очень медленно.

Описание SAVE EXCEPTIONS с сайта Oracle:

СОХРАНИТЬ ИСКЛЮЧЕНИЯ позволяет ОБНОВЛЕНИЕ, INSERT или DELETE продолжить выполнение после того, как он выдает исключение. Когда заявление заканчивается, выдается ошибка, чтобы сигнализировать что по крайней мере одно исключение произошло. Исключения собраны в массив что вы можете проверить с помощью % BULK_EXCEPTIONS после выписки выполнил.

ссылка на определение сохранения исключений: http://download.oracle.com/docs/cd/E11882_01/timesten.112/e13076/sqlexamples.htm#TTPLS364

Answer 1

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

Если вы используете Oracle, вам нужно прекратить использовать курсоры и использовать вместо них логику на основе множеств. SQL Server плохо работает с курсорами.

Answer 2

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

Я не верю, что в MS SQL есть что-то эквивалентное тому, что вы описываете.Несколько идей сделать что-то похожее:

• Вы можете использовать TRY ... CATCH в SQL, но это приведет к провалу всего пакета, если что-то пойдет не так, а не только проблемных строк.
• Задача массовой вставки служб SSIS может быть настроена на отдельный путь для «сбойных» строк, которые затем можно обрабатывать по своему усмотрению.
• Если вы говорите о уникальных дубликатах индекса (вставьте все эти строки, и, если они есть, то просто дублируйте их, но не проваливайте весь пакет), тогда вы можете объявитьуникальный индекс с опцией IGNORE_DUP_KEY (см. этот вопрос SO )

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

Answer 3

Я думаю, что ближе всего к моделированию этого поведения можно было бы отключить / включить (с проверкой) ограничения.Недостатком этого подхода является то, что неверные данные теперь находятся в вашей таблице, и вы не можете включить ограничения, пока они не будут очищены.Вам нужно будет решить, является ли это приемлемым риском в вашем конкретном случае.

ALTER TABLE YourTable NOCHECK CONSTRAINT ALL

/* Perform your DML operations */

ALTER TABLE YourTable WITH CHECK CHECK CONSTRAINT ALL

/* Deal with any errors that are thrown: 
   'The ALTER TABLE statement conflicted with the CHECK constraint ...' 
   clean up the bad data then enable constraints again */