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

Одному тебе.

Лог есть и там, и там, но какие могут быть сомнения? Если оверхеда на регистрацию транзакций меньше

(2) > оверхеда на регистрацию транзакций меньше
За счет чего?

быстрее по идее не должно быть, просто лог не сохранется в симпле

(4) Хорошая шутка

транзакции и в симпле есть. а раз они есть, то и лог юзается в полную.
просто по окончании транзакции все это дело не сохраняется

(3) За счет отсутствия журналирования т.н. "всего эффекта" от каждой операции / транзакции

(6) а куда ж они деваются? и почему тогда файл лога со временем все растет и растет?...

(7) а как же тогда ACID без WAL соблюдается?

(8) в симпле растет?

(9) Так стандартные CRUD не относится к минимально журналируемым.
А вот SELECT…INTO постоянно в запросах СУБД видны, они относятся.

Ну и с обслуживанием базы, связанного с индексами, тоже оверхеда меньше: https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms191484(v=sql.105)

(10) ну да. где-то раз в месяц шринк делаю. хотя везде пишут, что по идее он должен хранить транзакции за один день и расти не должен...

(13) посмотри внимательнее может и не симпл там

(7) И как же, по-твоему, будет обеспечиваться отказоустойчивость без журналирования?
Единственное отличие симпла - как только данные зафиксированной в логе транзакции записываются в основной файл БД по контрольной точке, это место в журнале транзакций помечается как доступное для переиспользования и может быть перезаписано очередными транзакциями. Физическая запись в журнал транзакций разбита на виртуальные журналы и "закольцована" - когда запись подходит к концу файла система сначала пытается писать в "освободившиеся" виртуальные журналы с начала файла. В итоге журнал транзакций в модели симпл не растет в размерах.

по идее он должен хранить только незакрытые транзакции

(0) на linux ms sql быстрее работает.

(15) Какие проблемы?

(0) вброс не засчитан

(18) Проблем никаких нет. Есть обоснованное мнение, что никакого оверхеда модель full не имеет.

(0) Нет разницы. Файл лога и в simple используется, только обрезается чаще.

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

Другими словами, механизм работы с логом в фулл и симпл абсолютно одинаков. У симпла просто "цикл ротации" лога короче (каждая контрольная точка), вот и все.

(23) абсолютно верно

(20) Если проблем нет, то какие тогда вопросы?
Ты походу путаешь/смешиваешь журналирование и транзакции.

(25) У меня никаких вопросов нет. Я пытался тебе объяснить, почему симпл не быстрее фулл. Если не получилось, что ж - значит плохой из меня объяснятель.

(17) Не замечал.
Правда специально ничего и не замерял на эту тему.
Но по ощущениям скорее медленнее (хотя статьи с заголовками аналогичными (17) видел).

(26) В теории это неплохо звучит.
Но после принудительного переключения режима транзакционного лога в simplе, тесты стали существенно быстрее работать.
Правда только с MsSql развернутым под linux, виндовый вариант от этого не ускорился.
Почему так - не анализировал, возможно на винде дисковый кеш более агрессивный или у меня linux криво настроен (что вполне вероятно, сварщик я совсем не настоящий).

(28) Хм... Я тоже не настоящий сварщик. Возможно, есть какая-то зависимость от размера файла и выбранной файловой системы и ее параметров. Либо все гораздо банальнее и тесты ты проводил на "непрогретом" логе. Т.е. он у тебя в фулл постоянно рос в процессе тестов. А это, естественно, сразу просадка по производительности.

(29) "Непрогретый" лог из гипотез можно вычеркнуть - база на каждом запуске создаётся заново.

(30) Не. Нельзя вычеркивать. Возможно просто в твоей линуксовой конфигурация операция выделения дискового пространства более дорогая, чем под виндой. Или по каким-то причинам разные дефолтные политики роста лога (под виндой - более крупными кусками). Суть в том, что для объективного теста нужно сразу создать журнал транзакций такого размера, чтобы в процессе тестирования он не рос.

+(30) Выкинуть в том смысле что он каждый раз "непрогретый" - и на винде и под линуксом.

(31) Это всё может быть и даже скорее всего.
Ни линукс, ни MsSql под ним я особо не настраивал.

(0) Смотря что понимать под "быстрее". Если длительность бэкапа, то да, быстрее.
А если кто-то залез кривыми ручками и грохнул что-то, и нужно восстановить, то картина резко меняется. Без Full это значит откатываемся на последний бэкап и сажаем пользователей забивать последние несколько дней.

(26) Не увидел ни в одном из твоих сообщений попытки объяснения. Вместо этого ты зачем-то какую-то механику использование места стал описывать.

(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 противопоказан.

(35) > Вместо этого ты зачем-то какую-то механику использование места стал описывать.
Чтобы подвести тебя к выводу, что simple и full работают абсолютно одинаково и не имеют разницы по оверхеду. Не, не получилось?

(36) сейчас гуглопереводчик доступен, большинство админов уже могут перевести...

(37) Это ложный вывод. А мы ведь должны быть хорошими инженерами. А инженерная мысль может базироваться только на точном знании.

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

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

Если уж совсем лениво, то переведи темпдб из симпла в фулл и погоняй-сравни какие-нибудь тяжелые и нагружающие эту БД операции в 1С.
Даже без написания каких-либо SQL-запросов.

И что теперь, есть смысл переводить базы с Full на Simple?

(37) Как бы смысл Simple в том, чтобы логировать меньший объем. По определению.

(39) В части упрощенного журналирования для BULK-операций - ты прав. Но в обычной работе базы данных оно никакой погоды не делает.
Я уже обратил внимание, что каким-то образом тебя раздражаю. Поэтому впредь не буду тратить время на дискуссии с тобой, чтобы не тратить твое и мое время.

(40) tempdb постоянно использует BULK-операции по своей специфике. А база 1С когда их использует в своей нормальной работе?

Но заметно это будет только при массовой вставке большого объема данных

(40) Давай проще. Приведи мне пример операции в 1С (не какой-то регламентной, а вполне себе рядовой - например, перепроведение пачки документов) для которой разница в модели восстановления должна сыграть роль по твоему мнению. Я готов провести тесты и признать свою неправоту, если ты окажешься прав.

(36) Из этого можно разные выводы сделать. Например, что толковые DBA с 1С не связываются. :)

(44) В запросах 1С постоянно и повсеместно используются временные таблицы. Ваш кэп.

(48) Они отрабатывают в tempdb, которая всегда simple. Два капитана.

Всегда измененные страницы пишутся в лог, и в simple и full.
Усечение (truncate) журнала транзакций, т.е. сброс страниц уже завершившихся транзакций, происходит
- в full в момент бекапа лога или принудительно 'backup log with truncate_only'
- в simple в момент checkpoint или также принудительно. Периодичность checkpoint определяется сервером самостоятельно и может быть пару минут, может быть больше.

Усечение журнала (truncate) не надо путать со сжатием файла журнала (shrink).
Когда журнал усекается файл не сжимается.
Поэтому и в simple файл может вырасти, если были большие транзакции (в которых изменяется много страниц), или много транзакций между чекпоинтами