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

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

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

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

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

Автору надо в школу.
22 fisher
 
11.09.20
13:10
Если в модели full делается регулярный бэкап лога журнала транзакций (освобождающий виртуальные журналы), то журнал транзакций точно также не растет в размерах.
Просто в симпл и в фулл средний размер будет разный (у фулл ессно больше).
23 fisher
 
11.09.20
13:14
Другими словами, механизм работы с логом в фулл и симпл абсолютно одинаков. У симпла просто "цикл ротации" лога короче (каждая контрольная точка), вот и все.
24 shiling
 
11.09.20
13:15
(23) абсолютно верно
25 Cyberhawk
 
11.09.20
13:36
(20) Если проблем нет, то какие тогда вопросы?
Ты походу путаешь/смешиваешь журналирование и транзакции.
26 fisher
 
11.09.20
13:47
(25) У меня никаких вопросов нет. Я пытался тебе объяснить, почему симпл не быстрее фулл. Если не получилось, что ж - значит плохой из меня объяснятель.
27 Zamkadysh
 
11.09.20
13:58
(17) Не замечал.
Правда специально ничего и не замерял на эту тему.
Но по ощущениям скорее медленнее (хотя статьи с заголовками аналогичными (17) видел).
28 Zamkadysh
 
11.09.20
14:04
(26) В теории это неплохо звучит.
Но после принудительного переключения режима транзакционного лога в simplе, тесты стали существенно быстрее работать.
Правда только с MsSql развернутым под linux, виндовый вариант от этого не ускорился.
Почему так - не анализировал, возможно на винде дисковый кеш более агрессивный или у меня linux криво настроен (что вполне вероятно, сварщик я совсем не настоящий).
29 fisher
 
11.09.20
14:08
(28) Хм... Я тоже не настоящий сварщик. Возможно, есть какая-то зависимость от размера файла и выбранной файловой системы и ее параметров. Либо все гораздо банальнее и тесты ты проводил на "непрогретом" логе. Т.е. он у тебя в фулл постоянно рос в процессе тестов. А это, естественно, сразу просадка по производительности.
30 Zamkadysh
 
11.09.20
14:10
(29) "Непрогретый" лог из гипотез можно вычеркнуть - база на каждом запуске создаётся заново.
31 fisher
 
11.09.20
14:13
(30) Не. Нельзя вычеркивать. Возможно просто в твоей линуксовой конфигурация операция выделения дискового пространства более дорогая, чем под виндой. Или по каким-то причинам разные дефолтные политики роста лога (под виндой - более крупными кусками). Суть в том, что для объективного теста нужно сразу создать журнал транзакций такого размера, чтобы в процессе тестирования он не рос.
32 Zamkadysh
 
11.09.20
14:13
+(30) Выкинуть в том смысле что он каждый раз "непрогретый" - и на винде и под линуксом.
33 Zamkadysh
 
11.09.20
14:14
(31) Это всё может быть и даже скорее всего.
Ни линукс, ни MsSql под ним я особо не настраивал.
34 mistеr
 
11.09.20
14:26
(0) Смотря что понимать под "быстрее". Если длительность бэкапа, то да, быстрее.
А если кто-то залез кривыми ручками и грохнул что-то, и нужно восстановить, то картина резко меняется. Без Full это значит откатываемся на последний бэкап и сажаем пользователей забивать последние несколько дней.
35 Cyberhawk
 
11.09.20
14:44
(26) Не увидел ни в одном из твоих сообщений попытки объяснения. Вместо этого ты зачем-то какую-то механику использование места стал описывать.
36 Zamkadysh
 
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 противопоказан.
37 fisher
 
11.09.20
14:53
(35) > Вместо этого ты зачем-то какую-то механику использование места стал описывать.
Чтобы подвести тебя к выводу, что simple и full работают абсолютно одинаково и не имеют разницы по оверхеду. Не, не получилось?
38 Mikeware
 
11.09.20
14:56
(36) сейчас гуглопереводчик доступен, большинство админов уже могут перевести...
39 Cyberhawk
 
11.09.20
15:14
(37) Это ложный вывод. А мы ведь должны быть хорошими инженерами. А инженерная мысль может базироваться только на точном знании.

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

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

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