2All
Давайте всё-ж таки так: журналирование и безопасность - 2 раздельных вопроса. То, что они озвучены в одном сообщении - не 2 же было писать, верно?
2Павел & mir
Угу... двухфазная фиксация... безопасность..
угу... Берём базу статистики (по чему угодно) за прошлые периоды. Для надёжности ставим ей RO (данные то за прошлые периоды всё равно не меняются). Данные испортить не может никто. гарантировано. Значит, журналирование не нужно. Безопасность? Ну, да... читать, теоретически тоже не все могут... Бог с ним, пусть читают все. Зачем тогда нам безопасноть?
Начинаем считать по базе всякие полезные отчеты.
делаем нечто вроде

что происходит? при заполнении таблички #temp в лог пишется: что было и что стало. затем checkpoint переносит это из лога в саму базу. Т.е. Вместо одной операции записи данных я имею 3: Запись "Было" в лог, Запись "Стало" в лог, запись в базу.
Если при выполнении запроса произойдет ошибка - Вам очень будет нужно вернуть табличку #temp в прежнее состояние? Не думаю. Зачем в таком случае мне журналирование? Вроде бы как и ни зачем.
Однако, в случае ошибки пойдет откат, который, кстати, тоже занимает время (причем немало, не меньше, чем было время вставки, но, по моим наблюдениям от 1.5 до 3 раз больше).
Т.е., теоретически (на практике то как это сделаешь?) операции при отключенным журналировании должны быть минимум на 50% быстрее.
Следующее. Если мы всё пишем в лог, в 2-м размере, то и место под этот лог должно быть. Т.е. за ненужную мне возможность я плачу: процессорным временем, временем пользователя, дисковым пространством. Дорого получается.
Далее. В Informix, Oracle и (вроде бы) Sybase есть возможность тем или иным образом отключить журналирование для Таблицы/базы. Следовательно, необходимость в этом возникала и, по всеё видимости, неоднократно.

По поводу отключения безопасности. Произвести замеры возможности нет, т.к. нет возможности отключить систему безопасности. Но, как мне думается, если принять минимально возможные разрешения, то выигрышь от такого отключения действительно будет минималным.
2f_w_P
ну... если Васю охрана пропустит в опечатанную комнату... тогда у него будет доступ к подсети... Я ведь могу изобразить и картинку, где сервер приложений имеет 2 сетевые карты, одна уходит во внешний мир, другая - во внутреннее кольцо с сервером БД и между которыми нет роутинга. По идее.... должно работать.

2Tygra

после ошибки видим, что не вставился не только null, но и 1, т.е. операция вставки атомарна, при ошибке откатывается, т.е. ведеться журналирование. Это подтверржадется также тем, что table var представляются в иде временных табличек в tempdb. Кроме того, таблички у меня используются для передачи данных из процедуры в процедуру (правда, не временные, а постоянные разделенные по spid).
2Gluk
В MS SQL тоже. Для базы, на которой стоит RO. Но проблема в том, что читаю я из базы RO а пишу в tempdb, для которой журналирование ведеться.

2Tygra
Предметную область или всё-же инструмент? Инструмент - да, подтверждаю, знаю не досконально, не боюсь в этом признаться.
Если не сложно - дайте ссылку на ветку обсуждения table vars.
2SergSuper
Поставьте order by по вкусу - всё равно не вставляет, да и судя по описаниям не должна.
2Jimmy
Слышал, есть такая штука, кэширование... И что? То, что кто-то может эффективно выполнять ненужную мне работу - меня не радует ни капельки.

2All
Давайте определимся. Есть транзакции на уровне блока операторов. Есть транзакции (неявные) на уровне одного оператора (insert,update,delete)
Меня в некоторых случаях устраивает "транзакция" на уровне страницы, а не оператора. В чем неправильность моего желания?

2Mir
Первый и второй путь я никогда не отвергал и не отвергаю. Всемерно этим пользуюсь и т.д.
3-й путь - дорого, однако. По крайней мере заказчик считает, что дорого. В чем-то я с ним согласен.
4-й путь - не для меня. Можут быть, увы, может быть - к счастью.
Но! Где-то тут потерялся путь - правильная настройка сервера. И очень досадно, что нету в MS SQL такой настроечки, которая есть у других.
Хотя, если положить руку на сердце, мне вполне бы подошла опция типа

где n - количество строк, после которого надо делать commit
а то приходится делать вот так

2A. Chepack
Не, что касаемо модичикации данных и всё такое - там у меня претензий ни к скорости ни к журналированию ни практически ни к чему претензий нет. А вот к отчетности... Ну, есть. Ну, могу порешать (и решаю). Но хочется то большего и меньшими усилиями :-(