Гавриленко Сергей АлексеевичВарианты, которые имею право на жизнь:
loopback linked server

Service Broker

CLR

Мы протестили у себя, в наших условиях с небольшим отрывом по производительности победил CLR (на нем и сделали).
Вернее, я наврал немного. CLR и SB были примерно одинаковы, чтобы не заморачиваться с последним, выбрали CLR.

Видимо, речь идет о том, что в catch идет переливка лога из времянки в табличную переменную и роллбэк.

Данный подход плох тем, что:

а) часть ошибок переводит транзакцию в разряд нефиксируемых, после чего любые операции, которые требуют записи в лог, отваливаются с соответсвующим егогом, а запсиь в табличные переменные как раз требует записи в лог
б) в некоторых ситуациях (высокое severity, kill или дамп сессии, дамп сервера, свет закончился и т.п.) до catch дело не дойдет вовсе

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

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