Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Хорошо бы иметь возможность отключать логгирование  [new]
babona
Member [заблокирован]

Откуда: Батуринск
Сообщений: 1816
MSSQL сервер.

Предположим, выполняете команду

INSERT INTO (....)
SELELCT ... FROM

при этом вам нужна максимальная скорость, а запись в журнал транзакций не нужна.
Почему бы не иметь возможность указать соотв. хинт
13 дек 14, 01:37    [16992323]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
o-o
Guest
вот же упертый-то, а?
у меня память на лица. и на дурацкие вопросы тоже
babona: otkluchit-loggirovanie-update
потрудитесь что-ли почитать, зачем нужно логирование.
уж за время, что прошло с момента публикации того поста, УЧИТАТьСЯ можно было
13 дек 14, 02:01    [16992340]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37050
babona
при этом вам нужна максимальная скорость, а запись в журнал транзакций не нужна.
Почему бы не иметь возможность указать соотв. хинт
Если вам что-то не нужно, это не значит, что серверу это не нужно. Или хотите после каждой незакомиченной транзакции базу из бэкапа восстанавливать?
13 дек 14, 10:52    [16992727]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31430
babona
Почему бы не иметь возможность указать соотв. хинт
Потому что люди без знаний будут это отключать, и это уменьшит скорость.

Есть варианты уменьшения логирования, посмотрите в BOL режим "Минимальное протоколирование"
http://msdn.microsoft.com/ru-ru/library/ms190925.aspx
Есть ещё специальный трейс-флаг, но он совсем опасный, скорее всего уменьшит скорость.
13 дек 14, 11:33    [16992810]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
babona
Member [заблокирован]

Откуда: Батуринск
Сообщений: 1816
Подобную фичу можно было бы применять с умом, под ответственность разработчика, наконец разрешать правами.
Если вы решаете задачи расчетного характера, перебираете варианты, используете часто Update, Insert в рабочие таблицы,
то вам вовсе не понадобится восстанавливать данные из журналов. В то же время запись в журнал
транзакций - дорогостоящая операция, по сравнению с собственно запись в таблицу.

А отправить в задумчивость SQL Server можно и другими командами.

alexeyvg,
спасибо за ссылку, попробую опцию .WRITE
13 дек 14, 13:15    [16993003]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31430
babona
Подобную фичу можно было бы применять с умом, под ответственность разработчика, наконец разрешать правами.
Если вы решаете задачи расчетного характера, перебираете варианты, используете часто Update, Insert в рабочие таблицы,
то вам вовсе не понадобится восстанавливать данные из журналов. В то же время запись в журнал
транзакций - дорогостоящая операция, по сравнению с собственно запись в таблицу.
Я же вам написал - по сравнению с записью в журнал транзакций запись в таблицу - дорогостоящая операция. Поэтому и сделали запись через журнал, а не только для восстановления, а и для ускорения тоже. Причём именно для такого рода задач - "Если вы решаете задачи расчетного характера, перебираете варианты, используете часто Update, Insert в рабочие таблицы"

Вот поэтому сделали подобную фичу достаточно сложной (нужно взвести переключатель, или написать ключевое слово в INSERT), так что большинство начинающих разработчиков, вроде вас, не увидит это даже в описании по ссылке, которая только этому и посвящена :-)
babona
спасибо за ссылку, попробую опцию .WRITE
Конструкция .WRITE вам вряд ли пригодится, она совсем о другом.
13 дек 14, 19:40    [16993914]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
babona,

В 2014 можно сделать in-memory tables, без блокировок и логирования. Правда, при каждой остановке / выключении сервера данные из них будут исчезать, но вам же скорость нужна...
15 дек 14, 00:23    [16996572]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
INSERT INTO (....)
SELELCT ... FROM

insert выполняется гораздо быстрее SELECT с журналированием или без. Это всё маниловщина.
15 дек 14, 10:58    [16997486]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
babona
Member [заблокирован]

Откуда: Батуринск
Сообщений: 1816
Ennor Tiegael,

про in-memory tables в 2014 знаю, одна из плюшек-доводов миграции на него, но не всега сразу есть возможность мигрировать.

Кстати,
в Oracle есть опция nologging, которую можно включить безапеллиационно на уровне сервера, а можно и нет
15 дек 14, 11:11    [16997591]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
Glory
Member

Откуда:
Сообщений: 104760
babona
в Oracle есть опция nologging, которую можно включить безапеллиационно на уровне сервера, а можно и нет

Вы бы хоть читали сначала, что делает эта опция

NOLOGGING can be used to minimize the amount of redo generated by Oracle. Only the following operations can make use of nologging:

* SQL*Loader in direct mode
* INSERT /*+APPEND*/ ...
* CTAS
* ALTER TABLE statements (move/add/split/merge partitions)
* CREATE INDEX
* ALTER INDEX statements (move/add/split/merge partitions)


Т.е. NOLOGGING может быть использован для уменьшения количества реду, генерируемых ораклом.
Т.е. это аналог minimally logged operations в SQL Server
15 дек 14, 11:16    [16997618]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
babona
Member [заблокирован]

Откуда: Батуринск
Сообщений: 1816
Glory,

с nologging операции INSERT /*+APPEND*/ выполнялись процентов на 15% быстрее на больших объемах
про Redo - конешн, четали
15 дек 14, 11:42    [16997832]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
Glory
Member

Откуда:
Сообщений: 104760
babona
с nologging операции INSERT /*+APPEND*/ выполнялись процентов на 15% быстрее на больших объемах
про Redo - конешн, четали

И поэтому эта опция "отключает логирование" ?
Что вам мешает попробоать minimally logged operations в SQL Server ?
15 дек 14, 11:45    [16997856]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
Crimean
Member

Откуда:
Сообщений: 13148
в 14 можно кроме InMemory включить "отложенное логирование" еще, если не путаю
17 дек 14, 14:14    [17010725]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Glory
babona
с nologging операции INSERT /*+APPEND*/ выполнялись процентов на 15% быстрее на больших объемах
про Redo - конешн, четали

И поэтому эта опция "отключает логирование" ?
Что вам мешает попробоать minimally logged operations в SQL Server ?


Я извиняюсь, а что при minimally logged operations (BULK LOGGED) не происходит запись в лог, или в SIMPLE RECOVERY не происходит запись в лог? Очень даже происходит. Отличие лишь в том, что сразу после КОММИТА/РОЛЛБЕКА место это в логе объявляется неиспользуемым. Это влияет на размеры логов и лог бекапов, но не на скорость.

У меня вопрос к ТС, а данные которые вы вставляете, это перманентные данные, которые перманентно должны остаться в БД, или это что-то промежуточное? В случае перманентных данных вы вряд ли отключите запись в лог. Даже InMemory SCHEMA_AND_DATA пишет в лог. В случае временных данных, можно попробовать переменные типа таблицы или InMemory (SCHEMA_ONLY) -- вот здесь можно что-то выиграть.

Ещё одно место, где можно добиться обработки данных без логирования, -- это SSIS/DataFlow. Кроме естественно конечной вставки.


Насколько я вижу речь идёт о месте, а не о скорости.
Under the full recovery model, all bulk operations are fully logged. However, you can minimize logging for a set of bulk operations by switching the database to the bulk-logged recovery model temporarily for bulk operations. Minimal logging is more efficient than full logging, and it reduces the possibility of a large-scale bulk operation filling the available transaction log space during a bulk transaction. However, if the database is damaged or lost when minimal logging is in effect, you cannot recover the database to the point of failure.
17 дек 14, 15:08    [17011074]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
babona
Glory,

с nologging операции INSERT /*+APPEND*/ выполнялись процентов на 15% быстрее на больших объемах
про Redo - конешн, четали


Насколько я помню INSERT /*+APPEND*/ выигрывает за счёт того, что добавляет записи в конец таблицы, а не занимается перестроением страниц таблицы. При этом никак не отключается логирование. Зато увеличивается фрагментация таблицы.

Если вы хотите, чтобы применялась транзакция, то логирования не избежать. Если вы не хотите транзакции -- так пишите в текстовый файл. Зачем вам БД?
17 дек 14, 15:20    [17011144]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
a_voronin,

+1 существуют прекрасные текстовые СУБД с потрясающей скоростью записи. Не надо пытаться из автомобиля делать котлеты, надо предметы использовать по назначению.
17 дек 14, 15:23    [17011158]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
o-o
Guest
a_voronin

Я извиняюсь, а что при minimally logged operations (BULK LOGGED) не происходит запись в лог, или в SIMPLE RECOVERY не происходит запись в лог? Очень даже происходит. Отличие лишь в том, что сразу после КОММИТА/РОЛЛБЕКА место это в логе объявляется неиспользуемым. Это влияет на размеры логов и лог бекапов, но не на скорость.

да ни за что не извиним.
еще и просьба к вам личная: потрудитесь что-ли отсебятину соответствующим комментарием помечать.
или поищите несуществующие ссылки, подтверждающие вышеописанный бред.
даже на этом форуме до кучи тестов приводилось, что же идет в лог при минимальном логировании
и что при полном.
и уж конечно, чем меньше в лог пишешь, тем скорость выполнения всей операции выше,
это как такое можно не понимать???
17 дек 14, 15:38    [17011245]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
o-o
Guest
a_voronin
Under the full recovery model, all bulk operations are fully logged. However, you can minimize logging for a set of bulk operations by switching the database to the bulk-logged recovery model temporarily for bulk operations. Minimal logging is more efficient than full logging, and it reduces the possibility of a large-scale bulk operation filling the available transaction log space during a bulk transaction. However, if the database is damaged or lost when minimal logging is in effect, you cannot recover the database to the point of failure.

с инглишем у вас тоже проблемы, выделяю правильный кусок:
it reduces the possibility of filling the available transaction log space
и перевод дам, сохраняющий смыл, наезды на качество не принимаю, хочу лишь донести то,
что тут написано:

"В полной модели восстановления bulk-операции тоже полностью логируются.
Тем не менее, вы можете уменьшить логирование таких операций,
временно переведя базу в режим минимального логирования.
Минимальное логирование эффективнее полного,
и еще оно уменьшает вероятность переполнения лога."

да-да, дословно там "вероятность того, что большого объема bulk-операция заполнит (все) имеющееся в логе место за время bulk-транзакции.

"Тем не менее, если база крякнет во время минимального логирования, вы не сможете восстановиться на произвольный момент времени"
17 дек 14, 15:51    [17011369]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
o-o
a_voronin
Я извиняюсь, а что при minimally logged operations (BULK LOGGED) не происходит запись в лог, или в SIMPLE RECOVERY не происходит запись в лог? Очень даже происходит. Отличие лишь в том, что сразу после КОММИТА/РОЛЛБЕКА место это в логе объявляется неиспользуемым. Это влияет на размеры логов и лог бекапов, но не на скорость.

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


Господин O-O, моё видение, что в данном случае ваш комментарий относиться исключительно к вам. Вы не знаете как TRANSACTION log связан с транзакциями? А-а...? Интересно, почему у этого перца лог переполнился при SIMPLE модели?

http://stackoverflow.com/questions/14043943/sql-server-log-file-fills-under-simple-recovery-model

Может это гон полный? А-а-а-а ... ?
17 дек 14, 15:52    [17011383]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
o-o
a_voronin
Under the full recovery model, all bulk operations are fully logged. However, you can minimize logging for a set of bulk operations by switching the database to the bulk-logged recovery model temporarily for bulk operations. Minimal logging is more efficient than full logging, and it reduces the possibility of a large-scale bulk operation filling the available transaction log space during a bulk transaction. However, if the database is damaged or lost when minimal logging is in effect, you cannot recover the database to the point of failure.

с инглишем у вас тоже проблемы, выделяю правильный кусок:
it reduces the possibility of filling the available transaction log space
и перевод дам, сохраняющий смыл, наезды на качество не принимаю, хочу лишь донести то,
что тут написано:

"В полной модели восстановления bulk-операции тоже полностью логируются.
Тем не менее, вы можете уменьшить логирование таких операций,
временно переведя базу в режим минимального логирования.
Минимальное логирование эффективнее полного,
и еще оно уменьшает вероятность переполнения лога."

да-да, дословно там "вероятность того, что большого объема bulk-операция заполнит (все) имеющееся в логе место за время bulk-транзакции.

"Тем не менее, если база крякнет во время минимального логирования, вы не сможете восстановиться на произвольный момент времени"


И где у меня проблемы с английским? Я что-то не вижу, где в вашем переводе сказано про то, что в лог будет записано меньше байт? Речь не идёт об увеличении размера файла, а о записи конкретного количества байт в лог. Которые в случае FULL пишутся на новое место, если оно не освобождено бекапом, а в случае SIMPLE пишутся в том же количестве, но на СТАРОЕ (повторно его используя без бекапа). Вы этот момент понимаете?
17 дек 14, 15:57    [17011436]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
o-o
Guest
вот это -- беззастенчивая ложь:
a_voronin
Я извиняюсь, а что при minimally logged operations (BULK LOGGED) не происходит запись в лог, или в SIMPLE RECOVERY не происходит запись в лог? Очень даже происходит. Отличие лишь в том, что сразу после КОММИТА/РОЛЛБЕКА место это в логе объявляется неиспользуемым. Это влияет на размеры логов и лог бекапов, но не на скорость.

во-первых, никакое это не единственное отличие,
главное отличие от как раз в том, ЧТО падает в лог.
во-вторых, в той вашей цитате про SIMPLE вообще ни слова.
там говорят о том, как уменьшить нагрузку на лог, не отказываясь от от возможности делать бэкапы лога,
т.е. НЕ ПРЕРЫВАЯ ЦЕПОЧКУ БЭКАПОВ ЛОГА.
и тут, стрелочник вы наш любезный, никакие кивания в сторону SIMPLE не прокатят.
при переключении FULL -> BULK LOGGED никакой повторной перезаписи лога нет и в помине,
лог продолжает расти до очередного бэкапа лога.

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

для тех, кто сомневается или не узнал статью по воронинскому отрывку:

К сообщению приложен файл. Размер - 102Kb
17 дек 14, 16:19    [17011627]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
o-o
Guest
a_voronin
И где у меня проблемы с английским? Я что-то не вижу, где в вашем переводе сказано про то, что в лог будет записано меньше байт?

точно. проблемы глубже, они с элементарной логикой.
вменяемым людям понятно, что лог растет за счет записи в него.
и что расти будет меньше, только если писАть в него будут меньше.
но если ВАМ это не понятно, извините, это не ко мне.
17 дек 14, 16:23    [17011668]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
o-o
что расти будет меньше, только если писАть в него будут меньше.


Вот здесь проблемы с логикой у вас. Вам не приходила мысль, что можно писАть в середину файла, на то место, которое под файл уже выделено? Не увеличивая его размер.
17 дек 14, 16:37    [17011765]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
o-o
вот это -- беззастенчивая ложь:
a_voronin
Я извиняюсь, а что при minimally logged operations (BULK LOGGED) не происходит запись в лог, или в SIMPLE RECOVERY не происходит запись в лог? Очень даже происходит. Отличие лишь в том, что сразу после КОММИТА/РОЛЛБЕКА место это в логе объявляется неиспользуемым. Это влияет на размеры логов и лог бекапов, но не на скорость.

во-первых, никакое это не единственное отличие,
главное отличие от как раз в том, ЧТО падает в лог.
во-вторых, в той вашей цитате про SIMPLE вообще ни слова.
там говорят о том, как уменьшить нагрузку на лог, не отказываясь от от возможности делать бэкапы лога,
т.е. НЕ ПРЕРЫВАЯ ЦЕПОЧКУ БЭКАПОВ ЛОГА.
и тут, стрелочник вы наш любезный, никакие кивания в сторону SIMPLE не прокатят.
при переключении FULL -> BULK LOGGED никакой повторной перезаписи лога нет и в помине,
лог продолжает расти до очередного бэкапа лога.

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

для тех, кто сомневается или не узнал статью по воронинскому отрывку:


Я готов допустить, что будет записываться немного меньше байт, что не всё, что записывается при FULL будет писаться в лог, но не с тем, что записи в лог вообще не будет, или что это принципиально изменит ситуацию с логом.
17 дек 14, 16:47    [17011823]     Ответить | Цитировать Сообщить модератору
 Re: Хорошо бы иметь возможность отключать логгирование  [new]
o-o
Guest
привожу правильную цитату.

Understanding Minimally Logged Operations

To support high-volume data loading scenarios, SQL Server implements minimally logged operations. Unlike fully logged operations, which use the transaction log to keep track of every row change, minimally logged operations keep track of extent allocations and metadata changes only. Because much less information is tracked in the transaction log, a minimally logged operation is often faster than a fully logged operation if logging is the bottleneck. Furthermore, because fewer writes go the transaction log, a much smaller log file with a lighter I/O requirement becomes viable.

The Data Loading Performance Guide

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

у вас сейчас путаница между моделями и логированием.
вы правильно понимаете разницу между SIMPLE и и не-SIMPLE recovery model,
но это НЕ ЗАВЯЗАНО на "минимальное логирование".
в моей цитaте разъясняют, что при минимальном логировании в лог вместо самих данных идет extent allocations and metadata changes only.
минимальное логирование может применяться как в SIMPLE, так и в BULK-LOGGED recovery model.
в лог пойдет абсолютно одно и то же, но в случае SIMPLE лог усечется по checkpoint, как вы и написали, a в случае BULK-LOGGED -- нет.
но в обоих случаях в лог запишется не то, что бы записалось при полном логировании.
т.е. или, простите, полностью данные записать в лог (это и есть полное логирование)
или только extent allocations (минимальное).
надеюсь, так понятнее.
17 дек 14, 16:53    [17011881]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить