Всё о сокращении Transaction Log для MS SQL 2008/2012

Публикация № 277252 08.05.14

База данных - Инструменты администратора БД

Рассмотрены пожалуй все варианты проблем из за которых журнал транзакций может не сокращаться и все варианты решений. От простейших, до "не рекомендуемых".

Для MS SQL 2008/2012 рекомендации ИТС уже устарели, кроме того и раньше они не всегда помогали. В статье попытался собрать наиболее полный комплект информации по данному вопросу.
В своё время в одном месте всего этого не нашел, поэтому думаю будет полезно.


Популярная статья ИТС http://its.1c.ru/db/metod81#content:2373:1 устарела - теперь уменьшение размера журнала транзакций стало не самой простой операцией.

Собственно там рекомендуется следующий скрипт:


BACKUP LOG Имя_Базы_Данных WITH TRUNCATE_ONLY

go

DBCC SHRINKFILE(Имя_Файла_Журнала_Транзакций) 

go


Если выполнить его в MS SQL 2008/2012 получите ошибку: 

'truncate_only' is not a recognized BACKUP option

Подробно:
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/9997e75e-f126-4901-9379-de540a708ec9/backup-log-with-truncateonly


Что теперь делать?
Решения, собственно два:

1) 
USE [Database] 
ALTER DATABASE [Database] SET RECOVERY SIMPLE
go
 

DBCC SHRINKFILE ([Database]_log, 1); 
ALTER DATABASE [Database] SET RECOVERY FULL
go
 

2) 
USE [Database] 
BACKUP LOG [Database]  TO DISK='NUL:'  
go

DBCC SHRINKFILE ([Database]_log, 1)
go
 

Если "Урезанием лога" не злоупотреблять (т.е. сокрашать лог вместе с полной копией) то по большому счету не принципиально каким методом пользоваться.
Второй вроде как правильнее, зато первый "надежнее". 

На этом казалось бы можно и остановиться, но зачем тогда отдельную статью писать. Нет, конечно это ещё не всё. Обычно вопросы про урезание лога возникают когда это сделать не получается.
Притом способы, описанные выше, как правило, описаны не раз, все их освоили и проблем не вызывают.

Итак, если все действия, описанные выше не помогли - лог файл по-прежнему занимает N гигабайт. Переходим к плану B:

select log_reuse_wait_desc from sys.databases

В результате можете получить 3 варианта:

а. Пусто - Обычно это означает что у БД лог можно хоть сейчас полностью сократить, могу предложить только попробовать ещё раз Shrink, а если не поможет - переходить к плану C
b. Log_Backup - Нормальный варинат. В данном случае говорит о том, что Backup Log не выполнено, или выполнено некорректно
b. Replication - значит что ваш лог не обрезается из за репликации - скорее всего ошибки.
с. Active transactions -  Самая частая ситуация - в базе есть подвисшие транзакции, с ними нужно разобраться.

Replication  - Репликация для систем на платформе 1С, пожалуй, бессмысленное дело. Потому как Read only баз MS SQL не бывает, средства создания распределенных систем в 1С есть собственне (да, я про РИБ). Для обеспечения отказоустойчивости гораздо лучше подходят кластерные технологии. Собственно рекоммендация простая:

sp_removedbreplication '[Database]'

Собственно после этого бэкап и Shrink помогут. Если же вопреки здравому смыслу вы всё-таки хотите сохранить репликацию БД то конечно выполнять эту команду нельзя, а нужно разбираться с ошибками репликации. Но это уже тема отдельной статьи.

Active transactions - наиболее популярная история. В базе есть транзакции, которые не завершены, и чего то ожидают. Чащи всего такие транзакции получаются при потере сетевого соединения или "вылете" клиента 1С в момент записи в БД. В этом случае нужно собственно узнать какая транзакция "повисла":

DBCC OPENTRAN

После выполнения этой команды вы получите примерно следующий результат:

Transaction information for database 'master'.
Oldest active transaction:
SPID (server process ID) : 52
UID (user ID) : -1
Name          : user_transaction
LSN           : (518:1576:1)
Start time    : May 5 2014 3:30:07:197PM
SID           : 0x010500000000000515000000a065cf7e784b9b5fe77c87709e611500
DBCC execution completed. If DBCC printed error messages, contact your system administrator.


Из этого обилия информации ключевым является Start Time и SPID. Если транзакция в базе 1С выполняется боле нескольких секунд это уже означает что что-то не так. А если start Time будет минут 10 или более от текущего времени - такие транзакции (сеансы) нужно завершать. Но предварительно я бы рекоммендовал узнать что эта транзакция делала.

Для завершения процесса можно ввести команду

KILL [Process ID]

Где Process ID - это тот самый SPID полученный на предыдущем шаге. При этом незавершенные транзакции откатятся средствами MS SQL Server. Возможно при "убийстве" процесса будут завершены и несколько сеансов 1С, но  вряд ли много. Сервер 1С поддерживает собственный пул соединений с MS SQL, соответственно соединения из этого пула используются только тогда, когда серверу что-то нужно от СУБД. При этом если соединение занято (а оно как видим занято) вряд ли оно будет использоваться для других процессов. 

Но предварительно (!) если хотите всё-таки разобраться в проблеме рекомендую выполнить скрипт вроде:

DECLARE @sqltext VARBINARY(128)
SELECT @sqltext = sql_handle
FROM sys.sysprocesses
WHERE spid = [Process ID]
SELECT TEXT
FROM sys.dm_exec_sql_text(@sqltext)
GO

В результате вы получите текст команды SQL Server, на которой, собственно, всё и "зависло". Из неё вам нужна будет таблица в которую производилась запись, далее используя функцию "ПолучитьСтруктуруХраненияБазыДанных()" вы определите таблицу в терминах объектов метаданных в которую производилась запись и смотрите код. Как правило такие неприятные последствия происходят:

1) Ошибки в сетевых подключениях (для толстого клиента в т.ч. в сетевых подключениях клиентов, для тонкого - только в проблемах сети между сервером 1С и MS SQL). 
2) Каких то неправильных действиях (отправка почты, запись в файл, запуск внешних обработок, чтения из файла) производимых в транзакциях (при записи, при проведении)

Собственно от них надо избавляться.


Если ничего не помогло (или план B)

ВНИМАНИЕ! Перед выполнением процедур, описанных ниже, сделать полную резервную копию файлов БД MS SQL нужно обязательно!!!!

Есть ещё один - более радикальный способ решения вопроса роста журнала транзакций MS SQL. Но я лично его бы не рекомендовал к использованию. Тем не менее, специалисты Microsoft тоже могут ошибаться, 
и SQL Server может содержать ошибки, о которых мы регулярно читаем в BugFix, или же наблюдаем сами, поэтому приведу и этот способ. 

Суть его заключается в том что журнал транзакций просто удаляется и создается новый. При этом вы конечно теряете информацию из него и БД можно будет восстановить только из полной копии (которую вы конечно перед этим сделали).

Конечно при этом, особенно если в базе были всё-таки не зафиксированные может быть нарушена логическая целостность, но для этого запускается CheckDB которая в общем и целом приводит базу в порядок. Для аналогии это то же самое что в 1С проврять ссылочную целостность с опцией "Удалять если не найден". Если транзакция полностью не зафиксирована, но от неё остались частично данные, что противоречит принципу атомарности транзакций - эти данные будут удалены.

Итак приступим:

1) Detach БД из списка

2) Фал *.ldf удаляем (вы же его сохранили уж, да?)

3) Файл *.mdf переименовываем (в любое имя какое нравится)

4) В MS SQL создаём новую (!!!) БД с тем же именем, с каким была "больная" БД

5) Останавливаем MS SQL Server

6) Новый *.mdf файл удаляем, а старый переименовываем под "старое имя", подменяя тем самым файл новой БД

7) Запускаем MS SQL Server. При этом будет "битая БД", далее мы её исправляем

8) ALTER DATABASE [Database] SET EMERGENCY 

9) exec sp_dboption [Database], 'single user', 'TRUE'
Монопольный режим работы с БД

10) DBCC CHECKDB ([Database], REPAIRALLOWDATA_LOSS)
Ключевая операция - "возвращает БД к жизни". Может выполняться достаточно долго - до получаса на больших БД. Ни в коем случае не прерывайте эту операцию. Результат, где будут собраны исправленные ошибки
на всякий случай сохраните

11) exec sp_dboption [Database], 'single user', 'FALSE'
Сбрасываем монопольный режим

12) ALTER DATABASE [Database] SET ONLINE
Делаем базу доступной.

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

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. AlexProg 113 08.05.14 09:47 Сейчас в теме
Если вопрос незакрытых транзакций или пересчетов итогов не принципиален, и есть полная копия, то проще переключиться на простую модель восстановления данных, сжать лог файл, и переключиться на полную опять. Причем при определенных обстоятельствах это можно делать регламентно, даже с пересчетом итогов из 1С. Но это разговор за отдельную плату :)
2. comol 4817 08.05.14 11:10 Сейчас в теме
(1) AlexProg,

Ну написал про это:

USE [Database]
ALTER DATABASE [Database] SET RECOVERY SIMPLE
go
DBCC SHRINKFILE ([Database]_log, 1);
ALTER DATABASE [Database] SET RECOVERY FULL
go

Только если есть подвисшие транзакции всё равно не поможет...

3. AlexProg 113 08.05.14 11:36 Сейчас в теме
(2) не так. target_size можно указать до нуля. Тогда он все не закрытые страницы выведет в конец, и таким образом не надо "ждать", пока он до них дойдет. Всё просто.

А если вы хотите побороться с незакрытыми, повисшими, ошибочными транзакциями, для этого есть отдельная методика, скрипты. Вовсе не обязательно ножом работать.

ALT ER DATABASE ... SET SINGLE_USER WITH ROLLBACK IMMEDIATE
4. comol 4817 08.05.14 14:34 Сейчас в теме
(3) AlexProg,
ALT ER DATABASE ... SET SINGLE_USER WITH ROLLBACK IMMEDIATE
Как то жестоко... Мой вариант Kill [Process ID] как то лояльнее к пользователям :)
5. Babuin 21.05.14 10:38 Сейчас в теме
"Потому как Read only баз MS SQL не бывает". Бывают и даже работают с 1С.
"Второй вроде как правильнее, зато первый "надежнее"." Оба не правильные, правильный это регулярный бэкап лога либо отказ от полной модели восстановления.
Эти методы необходимы только если если возникли проблемы с регулярным бэкапом лога, и в некоторых случаях при операциях с обслуживанием баз (дефрагментация индексов и т.д.)
werd00; alexscamp; +2 Ответить
7. comol 4817 02.06.14 12:39 Сейчас в теме
(5) Babuin,
Эти методы необходимы только если если возникли проблемы с регулярным бэкапом лога
:)))) О чём и речь. Если проблем с бэкапом лога нет, то всё что написано выше изначально "неправильно" :)

Бывают и даже работают с 1С
А вот тут поподробнее? 1C при запуске пишет кое чего в таблицы... Вам удалось это победить?
15. Babuin 04.06.14 09:56 Сейчас в теме
(7)
А вот тут поподробнее? 1C при запуске пишет кое чего в таблицы... Вам удалось это победить?


На 8.2 проблем не возникало, если что то и пишет то во временные таблицы. Возможно в 8.0\1 было по другому.
Работает нормально и как через снэпшот зеркальной базы, так и в AlwaysON AG. Жаль только что AlwaysON AG доступно только в Enterprise редакции...
16. comol 4817 04.06.14 10:03 Сейчас в теме
(15) Babuin,
снэпшот зеркальной базы, так и в AlwaysON
это не о том. Я про Rad Only. Т.е. про репликацию. В таблицу params пишет точно и 8.2 при запуске
17. Babuin 04.06.14 12:10 Сейчас в теме
(16)
это не о том. Я про Rad Only. Т.е. про репликацию. В таблицу params пишет точно и 8.2 при запуске

репликация, зеркалирование, доставка журналов, не суть. 1С точно может работать с read_only базами, прямо сейчас у меня подключена к снэпшоту зеркальной базы типовая УПП, работает отлично (соответственно только на чтение-просмотр).
Профайлером смотрел, при запуске ничего не пишется, только во временные.
Возможно не умеет работать именно с репликацией (с ней не извращался), но с зеркалированием точно могет.
Проверить легко, берете тестовую базу переводите в MS SQL в режим read_only и пробуете зайти
6. rar_xxx 23 02.06.14 10:05 Сейчас в теме
Делайте бекап ldf(журнал транзакций) каждый час и все! Не шринкуйте лог! или шринканите один раз после включения бекапа лога, потом этого делать не нужно! ибо вы заставляете сервер все время расширять ldf, на что тратится время. Так же делайте каждый день полный бекап или если не возможно каждую неделю(это все таки лучше бекапа 1с, особенно если его не жать). И все ! После включения полного бекапа и бекапа лога, после каждого бекапа, лог пишется с начала файла и перестает расширяться, расширится он только в момент серьезных транзакций ну и пусть висит на размер макс транзакции, все таки время когда мы дрожали за гигабайты прошло.
alexscamp; +1 Ответить
8. comol 4817 02.06.14 12:42 Сейчас в теме
(6) rar_xxx, НачатьТранзакцию() Записать() Пока 1 Цикл КонецЦикла

И бэкапьте/не бэкапте тогда лог...

9. rar_xxx 23 02.06.14 17:04 Сейчас в теме
(8) )) зачем так делать ?) Если надо шринкануть самый простой вариант - переключаешь на простой режим восстановления, режешь, переключаешь на полный и Делаешь полный бекап! иначе идея восстановления по журналу транзакций накрываться. Причем все это можно делать на работающей базе.
10. comol 4817 02.06.14 17:28 Сейчас в теме
(9) rar_xxx,
Если надо шринкануть самый простой вариант - переключаешь на простой режим восстановления, режешь, переключаешь на полный
Если перефразировать ваши слова на язык MS SQL:

USE [Database]
ALTER DATABASE [Database] SET RECOVERY SIMPLE
go
DBCC SHRINKFILE ([Database]_log, 1);
ALTER DATABASE [Database] SET RECOVERY FULL
go

О чём и пишу... и писал в (2)... и продолжаю писать что не всегда помогает :)
11. rar_xxx 23 03.06.14 09:59 Сейчас в теме
(10) Ну я описал простым языком что надо сделать(не все знают что такое transact - sql и куда его писать), и у вас нет упоминания о обязательном полном бекапе после этого действа. Ну а если честно я изначально не въехал в тему и думал что тут обсуждают как ежедневно шринковать журнал.
12. adapter 405 03.06.14 14:07 Сейчас в теме
comol - странно слышать от вас такие советы... Больше похоже на вредные советы Григория Остера. Эти советы для тех кто не разобрался в SQL? Типа наделайте чего нить не вникая и будет вам еще лучше?

согласен с rar_xxx. Зачем его трогать вообще? Ведь если лог растет значит это кому нибудь нужно ;)
Если по простому - то MS SQL работает по принципу "не тронь технику и она не подведет". А если по сложному, то надо статьи читать про механизмы работы sql, транзакций, моделей восстановления, закольцованности логов и пр. Но итог один - не надо урезать лог. Разработчики MS SQL в новом релизе сервера даже убрали такую возможность, чтобы разом сделать нерабочими советы из таких вот статей по всей Сети. Нет же, находятся "добрые саморитяне" с обходными решениями запретов....

13. stanru1 91 03.06.14 15:20 Сейчас в теме
(12) adapter, статья поможет тем, у кого лог разросся в силу тех или иных причин и никак не хочет урезаться. За что автору статьи спасибо. Свел воедино рецепты из интернета :)
А по феншую, конечно, лучше делать бэкап лога.
14. comol 4817 03.06.14 20:35 Сейчас в теме
(12) adapter,
не тронь технику и она не подведет
так работает не SQL сервер, а, к сожалению, очень большая доля горе-программистов :((. А потом можно увидеть "транзакцию-долгожителя" которой недельки так две... и LOG который раз в 5 превышает не маленькую и без того базу... Если вы работаете только с типовыми конфигурациями в которых сугубо бухгалтера и их не более нескольких 10-ков, при этом есть квалифицированные системные администраторы конечно можете пропустить эту статью - оно для других ситуаций
18. adapter 405 05.06.14 09:23 Сейчас в теме
как работает большая доля программистов и кто из них относится к "горе" это конечно очень интересная тема. Хотите развить ее по подробнее?

А что касается журналов транзакций то я еще раз говорю категорическое нет. из таких урезаний ничего хорошего не выйдет.
Факты:
- SQL умеет "зацикливать" файлы. т.е. в файле журнала будет по кругу использовать одно и то же место, без дополнительного роста
- "зависшие" транзакции обрабатываются самим SQL без помощи ему корявыми руками
- привести в идеальное состояние файлы и базы можно бакапами, регламентными заданиям, перезагрузкой сервера наконец
- команды T-SQL по вмешательству в работу сервера, или удаление\подмена баз это инструменты квалифицированного специалиста sql. Если нет опыты и понимания то вслепую их применять копипастом из Инета на "боевом" сервере НЕ НАДО.
- журнал растет чтобы обработать потребности базы. Типа реструктуризации всей базы в 1С. Значит уменьшая журнал транзакций мы не уменьшаем потребности, а уменьшаем возможности. Потребности останутся те же, но выполняться будут дольше, журнал опять вырастет. На его рост уйдет время
- нет места на журнал? (денег на железки - мы крутая фирма, у нас 100 гигов мусора в базе мы гордимся этими и вообще мы мегареспектные, а не то что всякие там недоноски с 10 бухами) - поставь модель восстановления Simple, поменяй стратегию архивирования и забудь по рост журнала. Про автомобили будет наглядней? Я купил майбах, но его обслуживать надо в сервисном центре за дорого и спецами - че я дурак что ли ? Пусть вон Петя в гаражном автосервисе за рубль все делает.
- бакапы уже жмутся самим серверов, поэтому "пустое" место в журналах никак не мешает


p.s. у меня ни в одной из 23 региональных баз нет зависших на "две недельки" транзакций, которые еще и чем то журналам мешают. Ни в типовых, ни в отраслевых, ни в собственных. Хотя отвалы интернет-соединений и пр. якобы причины которые указаны в начале статьи часто и густо в любом филиале. А мониторю я их постоянно....
tuzmich007; werd00; teflon; +3 Ответить
19. comol 4817 05.06.14 09:49 Сейчас в теме
(18) adapter,
Хотите развить ее по подробнее
Не хочу, извиняюсь. Просто не всегда могу сдержать эмоции когда вижу фразы вида "работает не трожь".

Что касается ваших знаний о
SQL умеет "зацикливать" файл
и
"зависшие" транзакции обрабатываются самим SQL
журнал растет чтобы обработать потребности базы
Они оставляют желать лучшего....

Дело в том что отсутствие checkpoint в журнале влияет на время восстановления и резервного копирования. Т.е. подвисшая транзакция в журнале приведёт в итоге к тому что база будет "In recovery"... сотвтетствено.

23 региональных баз нет зависших на "две недельки" транзакций
А сколько там пользователей? :)))) Если более 100 тогда можно о чём то говорит :))

Но больше спорить не буду - получится "разговор слепого с глухим".
20. adapter 405 05.06.14 10:36 Сейчас в теме
А сколько там пользователей? :)))) Если более 100 тогда можно о чём то говорит :))

Ну с утра пока вот так набежало.....


ну и раз уж пошли по скринам.... Вот интересная картинка

из 30 гигов журнала транзакций используются копейки, остальное - зерованный кусок файла, который уже понадобился когда то базе для выполнения запросов, поэтому "держится" sql сервером наготове.

Начали с того как зарубить журнал транзакций не смотря на то, что сервер почему то не дает, а кончили фразой вырванной из контекста "что отсутствие checkpoint в журнале влияет на время восстановления и резервного копирования". Типа как "Было бы величайшей ошибкой думать" В.И. Ленин.

насчет слепого с глухим согласен... и желание продолжать общение пропало. Тем более выяснилось что мы тут пользователями меряемся, и вообще оказывается факты работы sql уже даже и не факты, а так... Да Вы еще вдруг решили оценивать мои знания......
GreenDragon; +1 1 Ответить
21. comol 4817 05.06.14 11:00 Сейчас в теме
(20) adapter, Нуу если у вас 25 баз по 400 пользователей.. респект, что я ещё могу сказать. Если внимательно за базами следить, есть админ MS SQL , какие-ить Quest - овские (судя по скринам) продукты. Весь код написан правильно, прошел рефакторинг. Важно - не подключено ТО к базам... ещё лучше если на УФ, проблемы можно избежать.
фразой вырванной из контекста
Ну не буду я тут всю "матчасть" объяснять. Поэтому "из контекста". Хотя бы по-минимум сначала ознакомьтесь с http://msdn.microsoft.com/en-us/library/ms190925.aspx с http://msdn.microsoft.com/en-us/library/ms365418.aspx и с http://msdn.microsoft.com/en-us/library/ms175495.aspx http://msdn.microsoft.com/en-us/library/ms179355.aspx и http://msdn.microsoft.com/en-us/library/ms345382.aspx всё о чём пишу там изложено. Этим вопросам уже 50 лет, любой админ SQL "делал это" хоть раз да приходилось, прекратите плз. "мусор в комменты"
22. adapter 405 05.06.14 11:25 Сейчас в теме
минус в карму? детский сад :)

вы бы сами почитали ссылки эти. А то прям нарочно не придумаешь. там как раз описано как sql сервер зацикливает журнал

Прикрепленные файлы:
23. comol 4817 05.06.14 11:42 Сейчас в теме
(22) adapter, Ткну пальчиком в книжечку http://msdn.microsoft.com/en-us/library/ms190925.aspx#FactorsThatDelayTruncation Как в детском садике, кстати :))) название "When log records remain active for a long time transaction log truncation is delayed, and potentially the transaction log can fill up" переводить на русский не буду, сорри. В кратце там написано что всё это работает и работает круто, кроме перечисленных 14-ти причин :). Но чтобы вам это всё понять изначально лучше начать читать с первой статьи...
24. adapter 405 05.06.14 12:35 Сейчас в теме
Блин, давайте не путать теплое с мягким. В ссылке приведены возможные причины задержки усечения журнала транзакций. Ваша статья про сжатие файла журнала. Это принципиально разные вещи.

Усечение (truncate) системный процесс который происходит на сервере автоматом, происходит на логическом уровне, на уровне чекпоинтов и напрямую связан с механизмом зацикливания, поэтому в 99% не влияет на физический размер файла.

Сжатие (shrinkfile) - физическое уменьшение размера файла, сервер дает его эффективно выполнить только после логического усечения, закрытия зависших, выполнения бакапа и пр. условий.

Вы же сами это наглядно показали в первом t-sql скрипте статьи и всех последующих ссылках, которыми пытались что то доказать мне. Кстати спасибо, мне даже гуглить не пришлось :)

Хорошо конечно что мы тут с вами затеяли этот древний холивар. Народ почитает, задумается. Плохо только что Ваш стиль общения как то направлен на попытки уязвить оппонента. Вам не идет.

В статье не хватает главного - причины уменьшения журнала транзакций? Кому и для чего это надо?
25. comol 4817 05.06.14 13:31 Сейчас в теме
(24) adapter,
Ваша статья про сжатие файла журнала. Это принципиально разные вещи.
А в принципе человека начинает интересовать Transaction Log если он "не сжимается", а не сжимается он потому что "не усекается". В первом скрипте BACKUP LOG Имя_Базы_Данных WITH TRUNCATE_ONLY - это усечение. И по сути 99% статьи про него. Но рад, что вы наконец то разобрались...

P.S. если бы не фраза "Работает не трожь" которая для меня как "красная тряпка" конечно стиль был бы другой.
26. Babuin 05.06.14 13:40 Сейчас в теме
(24) adapter,
В статье не хватает главного - причины уменьшения журнала транзакций? Кому и для чего это надо?


Причина одна, нужно быстро освободить закончившееся место на диске.
1) сломалась СРК
2) выполнялась регламентная операция обслуживания бд или иб 1с.
3) выполнялись большие массовые изменения данных
4) выполнялся "неоптимальный код"
kao_andi; comol; +2 Ответить
27. adapter 405 05.06.14 14:18 Сейчас в теме
я рад что вы тоже разобрались чем одно от другого отличается. Потому что в статье каша. И в ссылках что вы приводите тоже. То вы отрицаете что журнал кольцуется, то "съезжаете" что речь идет о сжатии. Хотя вначале статьи явно сказано что вот мол новый скул не дает сжимать (не работает DBCC SHRINKFILE), и вот вам обходные маневры ....

Да все еще агрессивно и с мнимым превосходством. Фу гадость.
28. comol 4817 05.06.14 15:47 Сейчас в теме
(27) adapter,
То вы отрицаете что журнал кольцуется
О_о
29. comol 4817 05.06.14 15:52 Сейчас в теме
(27) adapter,
Да все еще агрессивно
я больше так не бууудууу... он пееервый начааал :). Всё, "давайте жить дружно".
30. adapter 405 05.06.14 20:18 Сейчас в теме
Согласен. мир, дружба, жвачка :)
31. HolodZar 01.02.16 07:45 Сейчас в теме
Подскажите, пожалуйста, а как могло получится, что select log_reuse_wait_desc from sys.databases возвращает для базы Replication, если репликацию никто никогда не настраивал?
32. comol 4817 01.02.16 22:30 Сейчас в теме
(31) HolodZar, По-моему при восстановлении из бэкапа такие глюки бывают...
33. HolodZar 02.02.16 06:28 Сейчас в теме
(32) спасибо.
Статья пригодилась.
34. simgo83 69 02.03.17 18:50 Сейчас в теме
подключение базы без лога
EXEC sp_attach_single_file_db @dbname = 'Имя_Базы',
@physname = 'полныйпуть\Имя_Базы.mdf'
Этот пункт нужно выполнить взамен всем пунктам с 3 по 12 последнего способа

будет выдано такое сообщение
Сбой при активации файла. Возможно, физическое имя файла "полныйпуть\Имя_Базы.LDF" неправильное.
Создан новый файл журнала "полныйпуть\Имя_Базы.LDF".
tikhmyanov; +1 Ответить
35. МихаилМ 02.03.17 21:08 Сейчас в теме
при реструктуризации журнал вырастит
36. alex_sh2008 4 02.03.17 21:53 Сейчас в теме
Хорошие заметки, но по мне лучше их не применять вообще, лучше потратить время на разработку плана обслуживания, чем потом веселиться с оптимизацией и восстановлением баз, с непредсказуемым результатом.
37. Terve!R 15.11.17 10:39 Сейчас в теме
(36) сделал план обслуживания на полный бекэп и бэкап лога, а толку - лог разросся до 125 гигов при базе в 10 гигов.
Помог способ 2 - оказалось лог ощищается только при повторном (двойном) бэкапе и шринке, а в первый раз уменьшается незначительно.
38. alex_sh2008 4 15.11.17 10:51 Сейчас в теме
(37)Нет, лог очищается после резервного копирования, у вас скорее всего были проблемы в базе или с лог файлом(в момент резервного копирования открылась долгая транзакция, зависшие транзакции, ошибки в базе) поэтому сервер не смог урезать файл, второй раз проблем такого рода не было. по пробуйте скорректировать план так что бы к базе было минимум обращений к базе, за синхронизируйте фоновые задания с планом быкапа.
39. YuryYatskov 27.07.18 10:29 Сейчас в теме
Из документации:
Урезание логов производится автоматически, в зависимости от модели восстановления:

• В простой модели (Simple) — после достижения контрольной точки;
• В модели полного восстановления (Full) — после создания бэкапа логов, при условии что со времени предыдущего бэкапа была достигнута контрольная точка.

А все остальное, это если что-то сломалось.

А если такая статья возникала, значит у вас полная модель восстановления, и не настроен корректно бекап транзакций.
40. comol 4817 27.07.18 13:49 Сейчас в теме
(39)
А все остальное, это если что-то сломалось.
Да вообще наша работа это только "если что-то сломалось" :))))
41. Novichok777 22 30.06.20 12:25 Сейчас в теме
К плану Б дополнение, если баз на SQL сервере много, то можно получить данные в разрезе баз и заодно модель восстановления покажет:

select name, log_reuse_wait_desc, recovery_model_desc from sys.databases
42. vasyna 08.06.21 15:20 Сейчас в теме
Я извиняюсь за некрофилию, но есть насущная проблема. Так уж получилось что 1с-никам пришлось в регламентные закинуть обработку которая исправляет криворукость пользоватей. И вот эта сама обработка по итогу очень сильно жрет журнал транзакций. За 3 дня 25 гигов... при размере базы в 3 гига. Собственно как я вышел сейчас из ситуации:
1. Каждый день в назначенное время при успешном тестировании и прочих проверок самой бд шринкую лог после этого уже (при любом раскладе) делаю полную копию БД;
2. После этого запускаю до 23:59 каждый час бэкап логов.
Модель восстановления полная. Штатного скульщика нет, 1с-ники в этом шарят меньше моего (архивацию предложили делать просто средствами 1с-обновлятора раз в день...)
Я не могу точно сказать, но мне казало что после того как я сохраню журнал транзакций, то эти сохраненные данные должны удаляться/сжиматься штатными средствами. Может я не так понял? Или у меня что-то не работает?
Спасибо.
43. comol 4817 08.06.21 16:45 Сейчас в теме
(42)
Модель восстановления полная. Штатного скульщика нет

На этом можно закончить. Если некому заниматься не используйте full - или simple или есть managed database в облаке.

1-й пункт не имеет смысл

Журнал транзакций может не очищаться по многим причинам - зависшая транзакция, нет чекпоинта... при full модели у вас должны быть все резервные копии, потом уже подрезание журнала транзакций
44. vasyna 09.06.21 08:45 Сейчас в теме
(43)
при full модели у вас должны быть все резервные копии, потом уже подрезание журнала транзакций

Да так собственно у меня и есть. Грубо говоря в 23:59 у меня делается последняя копия ЖТ. К этому моменту с базой уже в принципе работ ни каких не проводится часов 5 как точно (ну за редким исключением). Потом в 0:15 делается шринк и потом уже полная копия и понеслись опять копии ЖТ. В случае если 1с-ники что-то в ночь там колупают, то ответственность за бэкап на момент работ переносится на их плечи.
Как бы с самой бухгалтерией и зарплатой еще можно как-то на изи вернуться в ночь, там набьют первичку, не проблема. Но у нас документооборот свой. А там в теории в случае чего даже 1 упущенный документ может нести огромные потери для организации.
На практике я уже 2 или 3 раза сталкивался с восстановлением БД из подобного рода архива (только там фулл делается раз в неделю, каждый день делает разностный архив и каждый час ЖТ) и как бы с ростом логов проблемы только в одной базе, и то я даже знаю от куда ноги растут. Как только отключаем регламентную операцию, то логи можно сказать перестают расти и те же архивы жт становятся метров по 100 в час от силы. Быть может, я очень на это надеюсь и скоро сделают по человечески вместо костыля и тогда и проблема исчезнет.
Я спрашиваю правильно ли я поступаю в текущем моменте. Я не рассматриваю это как "жить на постоянку" с этим.

(43)
есть managed database в облаке

152ФЗ передает привет ) Плюс интернет у нас все еще желает лучшего... и хотя у нас 2 провайдера разных, но вот магистральный все равно один. Резервный канал у второго провайдера очень узок, мы просто встанем.
45. comol 4817 09.06.21 12:48 Сейчас в теме
(44)
152ФЗ передает привет ) Плюс интернет у нас все еще желает лучшего

Я про Яндекс облако. Так и сервер 1С туда же.

делается шринк
ну короче вот с этого момента я могу дальше не читать. в модели Full шринк логов бессмысленная операция. Можно организовать их ротацию. Да и вообще шринк всегда бессмысленная операция. Тут или в Облако съезжать или DBA нанимать или SLA снижать. В базе в которой есть транзакционная нагрузка всегда будет рост логов... Это не проблема, это норма жизни.
46. vasyna 09.06.21 20:54 Сейчас в теме
(45)
Я про Яндекс облако. Так и сервер 1С туда же.

А цепляться к нему как? Через что? Только через защищенные каналы связи сертифицированные. Плюс то же я.облако должно сделать тоже самое. соглашение там и... короче очень страшная штука. Нам ни сегодня завтра зик надо будет отдавать для набивания первички в "филиалы" я пока не представлю как. Для нас это больной вопрос.

(45)
я могу дальше не читать

Ну прочли бы... Задача восстановиться на вчерашний день с интервалом в час. Если в 23:59 был сделан шринк, в 00:00 полный бэкап и затем каждый час по копии ЖТ, то я же смогу на этот день восстановиться на любой отрезок резерва ЖТ? Так? Мне больше и не нужно.
47. comol 4817 10.06.21 00:21 Сейчас в теме
(46)
А цепляться к нему как? Через что? Только через защищенные каналы связи сертифицированные. Плюс то же я.облако должно сделать тоже самое. соглашение там и... короче очень страшная штука
там как раз основная ЦА те кому нужны сертифицированные защищенные соединения и 152ФЗ. 3 вида VPN и https с oauth вам сразу предложат это не проблема.

Нам ни сегодня завтра зик надо будет отдавать для набивания первички в "филиалы" я пока не представлю как.
вот это как раз к тебе как :)... но это конечно от бизнеса зависит, увеличение OPEX не все нормально воспринимают...

восстановиться на вчерашний день с интервалом в час
модель full подразумевает восстановление на любую секунду. Шринк ЖТ можно сказать или бессмысленная или бесполезная операция если у вас full
48. MaCCapAkIII 14.07.22 11:13 Сейчас в теме
А как быть в том случае, если у меня непрерывная цепочка бэкапов (раз в сутки полный, каждый час транзакции) в несколько месяцев на MS SQL 2014? Имею в виду - первый способ, переключение режимов восстановления (в моем случае я, к примеру, буду его делать перед ночным полным бэкапом каждый день) не испортит цепочку восстановления? Мне периодически приходится восстанавливать базы месячной давности для бухов...
По логике получается, то после полного бэкапа в полной модели восстановления у меня и так журнал чистится или я неправильно понимаю?
Оставьте свое сообщение

См. также

Структура хранения ИБ - обработка за 5 минут и 2 строки кода - DIY

Инструменты администратора БД Инструментарий разработчика Платформа 1С v8.3 Управляемые формы Платформа 1C v8.2 Бесплатно (free)

Платформа "1С:Предприятие 8" не держит в секрете информацию об именах таблиц SQL (или внутренней БД для файловой). Для получения подробнейшей информации - есть штатная функция "ПолучитьСтруктуруХраненияБазыДанных". Данная обработка - лишь обертка над функцией. Думаю, нет смысла качать и тратить $m на то, что можно сделать самому за 5 минут.

10.11.2022    3830    DrAku1a    12    

39

Легкий способ регистрации библиотеки COMCNTR.DLL (для COM-соединения)

Инструменты администратора БД Платформа 1С v8.3 Бесплатно (free)

Устали от командных строк, нюансов с разрядностью 32х/64х или ручного создания V83COMConnector в службе компонентов? Предлагаю простой способ регистрации библиотеки COMCNTR.DLL.

22.12.2020    63836    vakrikun    32    

87

Распознавание и загрузка документов в 1С Промо

Универсальная программа-обработка для распознавания любых сканов или фото первичных документов в 1С (счета-фактуры, УПД, ТТН, акты и тд). Точность распознания до 98%.

от 11 рублей

Пошаговая инструкция по установке веб-сервера Apache и завязка с 1С

Инструменты администратора БД Администрирование веб-серверов Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Данная статья больше предназначена для начинающих администраторов, но «бывалые» тоже могут освежить свои знания и в этой статье в деталях расскажу, как устанавливать Apache и использовать веб-сервер для работы с 1С.

10.03.2020    13165    dy4amaks    10    

37

Самые распространенные заблуждения об индексах в мире 1С

Инструменты администратора БД Администрирование СУБД Бесплатно (free)

"Магия" индексов привела к множеству заблуждений об их работе. Попробуем развеять некоторые из них в контексте 1С.

28.11.2019    47859    Infostart    53    

328

Тонкая настройка ежедневного резервного копирования базы данных 1С средствами SQL ver. 2014 (SP3) - 12.0.6024.0 (X64)

Архивирование (backup) Платформа 1С v8.3 Россия Бесплатно (free)

Хочу вам предложить небольшой пример, как можно реализовать резервное копирование 1С-ых баз данных средствами SQL. Данный материал не претендует на пулитцеровскую премию. Но возможно кому-то будет интересно узнать, что-то новенькое. Данный материал для резервного копирования только одной базы данных. А именно, если у вас 20-ть баз, то вам придется создавать 20-ть планов обслуживания для каждой базы индивидуально. (Слава разработчикам SQL, они разрешили копировать блоки из одного плана в другой, вам остается только произвести небольшую настройку для каждого скопированного блока - некоторые настройки блоков сбрасываются и выставляются значением по умолчанию и остаются неактивными)

07.10.2019    18295    DrZombi    53    

48

Видеокурс-практикум: как подготовить и написать ТЗ, ЗНР, ЧТЗ. Промо

В курсе обобщен опыт работы аналитика на проектах в течение пяти лет, в нескольких фирмах. Подходы к написанию документов унифицированы и по возможности не привязаны к конфигурациям 1С.

3 500 рублей

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Инструменты администратора БД Мониторинг Платформа 1С v8.3 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    27313    Sloth    80    

127

Нарушение целостности системы

Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Причины возникновения ошибки "Обнаружено нарушение целостности системы" и способы ее устранения.

07.09.2019    61127    Rain88    28    

114

Установка 1С Сервера взаимодействия на Linux

Инструменты администратора БД Россия Бесплатно (free)

В статье описан пошаговый процесс установки Сервера взаимодействия 1C на Linux CentOS 7.6.

06.09.2019    16145    KlSergey    35    

29

1С + PostgreSQL + SSD: Куда уходит ресурс хост-записей?

Инструменты администратора БД Россия Бесплатно (free)

Работа PostgreSQL на SSD начиная с 10 версии, резко увеличивает нагрузку на ресурс SSD, даже когда к базе нет коннектов.

06.09.2019    10795    2tvad    8    

38

1СПАРК РИСКИ. Сервис оценки благонадежности контрагентов. Промо

СПАРК помогает предотвратить мошенничество со стороны компаний и предпринимателей, благодаря актуальным сведениям о компаниях и системе выявления факторов риска.Сервис позволяет управлять налоговыми рисками и комплексно оценивать благонадежность контрагентов.

Почему Вы не обслуживаете итоги?

Инструменты администратора БД Платформа 1С v8.3 Бесплатно (free)

Небольшая заметка по обслуживанию итогов. Все ли Вы делаете правильно?

04.07.2019    32704    Infostart    36    

120

Обновление PostgreSQL на Windows

Инструменты администратора БД Бесплатно (free)

Указана последовательность действий при обновлении PostgreSQL на примере Windows. Также описаны некоторые особенности.

11.06.2019    28188    extalionos    11    

43

Вопросы и ответы по лицензированию Microsoft Windows

Инструменты администратора БД Россия Бесплатно (free)

То, что интересует покупателей настольной операционной системы Microsoft.

20.05.2019    45348    accounting_cons    8    

19

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Способы проверки доступности TCP-портов

Инструменты администратора БД Бесплатно (free)

Как проверить доступен ли порт сервера? Или внешний веб-сервис? Приведены несколько способов для использования на Windows-системах.

12.05.2019    135420    VKislitsin    9    

64

Опыт обновления до 8.3.14 - лицензии и утилита ring

Инструменты администратора БД Платформа 1С v8.3 Бесплатно (free)

На выходных было скучно, поэтому решили обновить 1с до 8.3.14.1694. С лицензиями пришлось немного повозиться.

29.04.2019    49516    Sander80    31    

82

Практика перехода на Linux и Postgres в небольшой компании (10 пользователей)

Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Почему я решил поставить давнему клиенту Linux + Postgres вместо Windows + MS SQL? Что меня останавливало раньше?

22.04.2019    39138    starik-2005    183    

121

PID процесса в сборщиках PerfMon

Инструменты администратора БД Россия Бесплатно (free)

Одним из неудобств при работе с PerfMon является то, что одноименные процессы именуются по-порядку, с добавлением суффикса #n к имени процесса. Описана настройка, позволяющая устранить этот недостаток.

06.04.2019    8466    VKislitsin    26    

22

Переход на 64-х разрядный сервер 1С

Журнал регистрации Инструменты администратора БД Платформа 1С v8.3 Бесплатно (free)

Переход с 32-х разрядной версии сервера 1С на 64-х разрядную с сохранением данных журналов регистрации информационных баз, используемых в 32-х разрядной версии.

05.04.2019    36536    ids79    25    

65

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Подключение к серверу лицензирования (получение лицензий с другого сервера) (+видео)

Инструменты администратора БД Платформа 1С v8.3 Бесплатно (free)

В данной статье описано, как подключиться к серверу лицензирования и иметь возможность использовать разными серверами один/несколько комплектов лицензий, активированных на одном сервере...

25.03.2019    44311    ellavs    72    

45

Введение в лицензирование ПО Microsoft

Инструменты администратора БД Россия Бесплатно (free)

Поговорим о принципах лицензирования программных продуктов Microsoft.

19.03.2019    53425    accounting_cons    49    

20

Собираю Новый бюджетный Сервер для 1С ЗУП на 50 пользователей за 160 тысяч рублей (новый)

Инструменты администратора БД Бесплатно (free)

В продолжение темы https://infostart.ru/public/987835/ На данный момент подбираю бюджетный Сервер для 1С ЗУП на 50 пользователей за 160 тысяч рублей

06.03.2019    8728    Indgo    100    

2

Вопросы и ответы по лицензированию Microsoft SQL Server

Инструменты администратора БД Россия Бесплатно (free)

Продолжение темы лицензирования серверных продуктов Microsoft.

26.02.2019    46495    accounting_cons    57    

30

Скорость работы 1С: Предприятие с разными СУБД: MS SQL и с PostgreSQL

Инструменты администратора БД Платформа 1С v8.3 Бесплатно (free)

Рассмотрим несколько вариантов работы 1С: Предприятие с различными СУБД.

20.02.2019    37190    valentinko    174    

75

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Восстановление файловой базы с помощью tools 1cd

Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Небольшая заметка, как удалось вылечить битую файловую базу 1С, с помощью утилиты tools 1cd.

19.02.2019    26513    rzabolotin    70    

61

Вопросы и ответы по лицензированию Microsoft Windows Server

Инструменты администратора БД Россия Бесплатно (free)

Все, что вы хотели знать о лицензировании Microsoft Windows Server.

13.02.2019    48966    accounting_cons    66    

49

А еще был такой случай

Инструменты администратора БД Бесплатно (free)

Сервер, Сеть и два Сеанса.

04.02.2019    6404    kraynev-navi    12    

6

Debian 9.7 + PostgreSQL для 1С. Как завести с пол-оборота

Инструменты администратора БД Платформа 1С v8.3 Бесплатно (free)

Предлагаю взять на заметку информацию по установке и настройке в формате typical, typical, done.

02.02.2019    32902    valentinko    15    

79

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Собираем бюджетный б/у сервер 1С:Предприятия 8.3 на 250+ Пользователей за 100 тыс. рублей

Инструменты администратора БД Бесплатно (free)

В последнее время в виду дорогого доллара, санкций и прочих проблем покупка нового сервера за 500 и более тысяч рублей стала недостижимой роскошью.  Ввиду этого попытаемся собрать его из б/у сервера на Авито.

24.01.2019    22221    Indgo    138    

37

1С и Яндекс.Облако Compute Cloud. Вдоль и поперек

Инструменты администратора БД Платформа 1С v8.3 Бесплатно (free)

Бороться и искать. Найти и перепрятать. Достаточно популярная поговорка во времена Союза. Вот и сейчас, те у кого сервер 1С в локальной сети мечтают вынести его в облако, а те у кого в облаке прикупить свой в локальную сеть. Тестирование Яндекс.Облако Compute Cloud для 1С Предприятие оставило у меня приятное впечатление. Возможно кто-то повторит его и внесет больше ясности в настройки виртуальных серверов, использованию API и так далее. Пока же пользуйтесь чем я послал. Интересующихся прошу под кат…

20.01.2019    21106    capitan    31    

95

Копирование числовых ячеек из 1С в Excel

Загрузка и выгрузка в Excel Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Решение проблемы, когда значения скопированных ячеек из табличных документов 1С в Excel воспринимаются последним как текст, т.е. без дополнительного форматирования значений невозможно применить арифметические операции. Поводом для публикации послужило понимание того, что целое предприятие с более сотней активных пользователей уже на протяжении года мучилось с такой, казалось бы на первый взгляд, тривиальной проблемой. Варианты решения, предложенные специалистами helpdesk, обслуживающими данное предприятие, а так же многочисленные обсуждения на форумах, только подтвердили убеждение в необходимости описания способа, который позволил мне качественно и быстро справиться с ситуацией.

15.01.2019    43590    itriot11    27    

33

Установка Windows без загрузочной флэшки и загрузочного DVD-диска

Инструменты администратора БД Бесплатно (free)

Что делать, если нужно установить Windows на ПЭВМ со старой системной платой, а под рукой нет dvd-привода, а с флэшки загрузка невозможна или идет очень медленно.

09.01.2019    7668    independ    5    

40

Семь рекомендуемых бесплатных курсов Microsoft для ИТ-администраторов

Инструменты администратора БД Бесплатно (free)

Образовательный портал «Нетология» предлагает вам пройти семь онлайн-курсов по облачным сервисам Microsoft бесплатно и получить сертификат об их завершении. Все курсы основаны на самых популярных сценариях использования облачных технологий в компаниях малого и среднего бизнеса. Разберемся, что же эти учебные программы предлагают.

28.12.2018    19262    VKuser24342747    2    

34