Вход | Регистрация
 
Информационные технологии :: Администрирование

MS SQL. Simple быстрее Full?

MS SQL. Simple быстрее Full?
Я
   Бишбармак
 
11.09.20 - 12:40
1. Simple быстрее60% (3)
4. Автору надо в школу.40% (2)
2. Full быстрее0% (0)
3. Зависит от структуры базы0% (0)
Всего мнений: 5

(пятничный вброс)
Одному мне кажется, что на небольших базах (надцать гб) базы модели simple быстрее чем full?
   fisher
 
1 - 11.09.20 - 12:41
Одному тебе.

4. Автору надо в школу.
   Cyberhawk
 
2 - 11.09.20 - 12:42
Лог есть и там, и там, но какие могут быть сомнения? Если оверхеда на регистрацию транзакций меньше

1. Simple быстрее
   fisher
 
3 - 11.09.20 - 12:44
(2) > оверхеда на регистрацию транзакций меньше
За счет чего?
   Вафель
 
4 - 11.09.20 - 12:44
быстрее по идее не должно быть, просто лог не сохранется в симпле
   Cyberhawk
 
5 - 11.09.20 - 12:45
(4) Хорошая шутка
   Вафель
 
6 - 11.09.20 - 12:47
транзакции и в симпле есть. а раз они есть, то и лог юзается в полную.
просто по окончании транзакции все это дело не сохраняется
   Cyberhawk
 
7 - 11.09.20 - 12:50
(3) За счет отсутствия журналирования т.н. "всего эффекта" от каждой операции / транзакции
   Guk
 
8 - 11.09.20 - 12:51
(6) а куда ж они деваются? и почему тогда файл лога со временем все растет и растет?...
   Вафель
 
9 - 11.09.20 - 12:52
(7) а как же тогда ACID без WAL соблюдается?
   Вафель
 
10 - 11.09.20 - 12:53
(8) в симпле растет?
   Cyberhawk
 
11 - 11.09.20 - 12:54
(9) Так стандартные CRUD не относится к минимально журналируемым.
А вот SELECT…INTO постоянно в запросах СУБД видны, они относятся.
   Cyberhawk
 
12 - 11.09.20 - 12:55
Ну и с обслуживанием базы, связанного с индексами, тоже оверхеда меньше: https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms191484(v=sql.105)
   Guk
 
13 - 11.09.20 - 12:59
(10) ну да. где-то раз в месяц шринк делаю. хотя везде пишут, что по идее он должен хранить транзакции за один день и расти не должен...
   Вафель
 
14 - 11.09.20 - 12:59
(13) посмотри внимательнее может и не симпл там
   fisher
 
15 - 11.09.20 - 13:00
(7) И как же, по-твоему, будет обеспечиваться отказоустойчивость без журналирования?
Единственное отличие симпла - как только данные зафиксированной в логе транзакции записываются в основной файл БД по контрольной точке, это место в журнале транзакций помечается как доступное для переиспользования и может быть перезаписано очередными транзакциями. Физическая запись в журнал транзакций разбита на виртуальные журналы и "закольцована" - когда запись подходит к концу файла система сначала пытается писать в "освободившиеся" виртуальные журналы с начала файла. В итоге журнал транзакций в модели симпл не растет в размерах.
   Вафель
 
16 - 11.09.20 - 13:00
по идее он должен хранить только незакрытые транзакции
   Leonardo1c
 
17 - 11.09.20 - 13:01
(0) на linux ms sql быстрее работает.
   Cyberhawk
 
18 - 11.09.20 - 13:04
(15) Какие проблемы?
   shuhard
 
19 - 11.09.20 - 13:04
(0) вброс не засчитан

1. Simple быстрее
   fisher
 
20 - 11.09.20 - 13:06
(18) Проблем никаких нет. Есть обоснованное мнение, что никакого оверхеда модель full не имеет.
   ptiz
 
21 - 11.09.20 - 13:08
(0) Нет разницы. Файл лога и в simple используется, только обрезается чаще.

4. Автору надо в школу.
   fisher
 
22 - 11.09.20 - 13:10
Если в модели full делается регулярный бэкап лога журнала транзакций (освобождающий виртуальные журналы), то журнал транзакций точно также не растет в размерах.
Просто в симпл и в фулл средний размер будет разный (у фулл ессно больше).
   fisher
 
23 - 11.09.20 - 13:14
Другими словами, механизм работы с логом в фулл и симпл абсолютно одинаков. У симпла просто "цикл ротации" лога короче (каждая контрольная точка), вот и все.
   shiling
 
24 - 11.09.20 - 13:15
(23) абсолютно верно
   Cyberhawk
 
25 - 11.09.20 - 13:36
(20) Если проблем нет, то какие тогда вопросы?
Ты походу путаешь/смешиваешь журналирование и транзакции.
   fisher
 
26 - 11.09.20 - 13:47
(25) У меня никаких вопросов нет. Я пытался тебе объяснить, почему симпл не быстрее фулл. Если не получилось, что ж - значит плохой из меня объяснятель.
   Zamkadysh
 
27 - 11.09.20 - 13:58
(17) Не замечал.
Правда специально ничего и не замерял на эту тему.
Но по ощущениям скорее медленнее (хотя статьи с заголовками аналогичными (17) видел).
   Zamkadysh
 
28 - 11.09.20 - 14:04
(26) В теории это неплохо звучит.
Но после принудительного переключения режима транзакционного лога в simplе, тесты стали существенно быстрее работать.
Правда только с MsSql развернутым под linux, виндовый вариант от этого не ускорился.
Почему так - не анализировал, возможно на винде дисковый кеш более агрессивный или у меня linux криво настроен (что вполне вероятно, сварщик я совсем не настоящий).
   fisher
 
29 - 11.09.20 - 14:08
(28) Хм... Я тоже не настоящий сварщик. Возможно, есть какая-то зависимость от размера файла и выбранной файловой системы и ее параметров. Либо все гораздо банальнее и тесты ты проводил на "непрогретом" логе. Т.е. он у тебя в фулл постоянно рос в процессе тестов. А это, естественно, сразу просадка по производительности.
   Zamkadysh
 
30 - 11.09.20 - 14:10
(29) "Непрогретый" лог из гипотез можно вычеркнуть - база на каждом запуске создаётся заново.
 
 Рекламное место пустует
   fisher
 
31 - 11.09.20 - 14:13
(30) Не. Нельзя вычеркивать. Возможно просто в твоей линуксовой конфигурация операция выделения дискового пространства более дорогая, чем под виндой. Или по каким-то причинам разные дефолтные политики роста лога (под виндой - более крупными кусками). Суть в том, что для объективного теста нужно сразу создать журнал транзакций такого размера, чтобы в процессе тестирования он не рос.
   Zamkadysh
 
32 - 11.09.20 - 14:13
+(30) Выкинуть в том смысле что он каждый раз "непрогретый" - и на винде и под линуксом.
   Zamkadysh
 
33 - 11.09.20 - 14:14
(31) Это всё может быть и даже скорее всего.
Ни линукс, ни MsSql под ним я особо не настраивал.
   mistеr
 
34 - 11.09.20 - 14:26
(0) Смотря что понимать под "быстрее". Если длительность бэкапа, то да, быстрее.
А если кто-то залез кривыми ручками и грохнул что-то, и нужно восстановить, то картина резко меняется. Без Full это значит откатываемся на последний бэкап и сажаем пользователей забивать последние несколько дней.
   Cyberhawk
 
35 - 11.09.20 - 14:44
(26) Не увидел ни в одном из твоих сообщений попытки объяснения. Вместо этого ты зачем-то какую-то механику использование места стал описывать.
   Zamkadysh
 
36 - 11.09.20 - 14:50
(34) Я живьем только одного админа видел, который умел откатывать состояние по журналу транзакции.
Но зато виде кучу тех, которые говорят: что-то ваша кривая 1С не работает, выдаёт ошибку: Could not allocate space for object 'XXX' in database 'YYY' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
По ощущениям, таких большинство (по крайней мере было 10 лет назад когда я ещё с клиентами общался) - и им точно full противопоказан.
   fisher
 
37 - 11.09.20 - 14:53
(35) > Вместо этого ты зачем-то какую-то механику использование места стал описывать.
Чтобы подвести тебя к выводу, что simple и full работают абсолютно одинаково и не имеют разницы по оверхеду. Не, не получилось?
   Mikeware
 
38 - 11.09.20 - 14:56
(36) сейчас гуглопереводчик доступен, большинство админов уже могут перевести...
   Cyberhawk
 
39 - 11.09.20 - 15:14
(37) Это ложный вывод. А мы ведь должны быть хорошими инженерами. А инженерная мысль может базироваться только на точном знании.

Я вот только что в очередной раз проверил одну и ту же операцию "insert into ... with (tablock)" на симпле и фулле. Разница в 2.6 раз. Без хинта - одинаково. Это и есть то самое минимальное журналирование, о котором я говорил еще в (7). Ссылка из (12) тоже почему-то тобою была проигнорирована, но это простительно, т.к. там уже речь про операции обслуживания.

Ты конечно можешь и дальше продолжать рассказывать теорию про нолики-байтики, цикличность записи в лог, чекпоинты. Про все, в общем-то, не играющее какой-либо значащей роли в производительности.
А можешь перейти к практике и увидеть разницу в разы. Хотя складывается впечатление, что вместо этого ты вновь попытаешься получившийся у меня на практике результат обосновать с помощью еще какой-нибудь теории и остаться при своем мнении.
   Cyberhawk
 
40 - 11.09.20 - 15:17
Если уж совсем лениво, то переведи темпдб из симпла в фулл и погоняй-сравни какие-нибудь тяжелые и нагружающие эту БД операции в 1С.
Даже без написания каких-либо SQL-запросов.
   Гобсек
 
41 - 11.09.20 - 15:22
И что теперь, есть смысл переводить базы с Full на Simple?
   mistеr
 
42 - 11.09.20 - 15:25
(37) Как бы смысл Simple в том, чтобы логировать меньший объем. По определению.
   fisher
 
43 - 11.09.20 - 15:34
(39) В части упрощенного журналирования для BULK-операций - ты прав. Но в обычной работе базы данных оно никакой погоды не делает.
Я уже обратил внимание, что каким-то образом тебя раздражаю. Поэтому впредь не буду тратить время на дискуссии с тобой, чтобы не тратить твое и мое время.
   fisher
 
44 - 11.09.20 - 15:38
(40) tempdb постоянно использует BULK-операции по своей специфике. А база 1С когда их использует в своей нормальной работе?
   ДНН
 
45 - 11.09.20 - 15:42
Но заметно это будет только при массовой вставке большого объема данных

1. Simple быстрее
   fisher
 
46 - 11.09.20 - 15:48
(40) Давай проще. Приведи мне пример операции в 1С (не какой-то регламентной, а вполне себе рядовой - например, перепроведение пачки документов) для которой разница в модели восстановления должна сыграть роль по твоему мнению. Я готов провести тесты и признать свою неправоту, если ты окажешься прав.
   mistеr
 
47 - 11.09.20 - 15:55
(36) Из этого можно разные выводы сделать. Например, что толковые DBA с 1С не связываются. :)
   mistеr
 
48 - 11.09.20 - 15:57
(44) В запросах 1С постоянно и повсеместно используются временные таблицы. Ваш кэп.
   fisher
 
49 - 11.09.20 - 16:02
(48) Они отрабатывают в tempdb, которая всегда simple. Два капитана.
   trad
 
50 - 11.09.20 - 16:30
Всегда измененные страницы пишутся в лог, и в simple и full.
Усечение (truncate) журнала транзакций, т.е. сброс страниц уже завершившихся транзакций, происходит
- в full в момент бекапа лога или принудительно 'backup log with truncate_only'
- в simple в момент checkpoint или также принудительно. Периодичность checkpoint определяется сервером самостоятельно и может быть пару минут, может быть больше.
   trad
 
51 - 11.09.20 - 16:34
Усечение журнала (truncate) не надо путать со сжатием файла журнала (shrink).
Когда журнал усекается файл не сжимается.
Поэтому и в simple файл может вырасти, если были большие транзакции (в которых изменяется много страниц), или много транзакций между чекпоинтами


Список тем форума
Рекламное место пустует  Рекламное место пустует
Кaк может человек ожидaть, что его мольбaм о снисхождении ответит тот, кто превыше, когдa сaм он откaзывaет в милосердии тем, кто ниже его? Петр Трубецкой
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.