Как очистить журнал транзакций в sql 2018: MS SQL очистка журнала транзакций

Лекция 3. Резервное копирование и восстановление БД. Журналы транзакций

**1.1. Компоненты резервного копирования базы данных.**
Следующей ключевой функцией администрирования многопользовательских баз данных является проведение мероприятий по резервному копированию (backup) и восстановлению (restore) баз данных.
Данные функции неразрывно связаны с обеспечением безопасности баз данных и сопутствуют жизненному циклу любой базы данных. В контексте этой лекции процедура резервного копирования и восстановления баз данных будет рассмотрена теоретически, а также в контексте инструкций языков tSQL, PostgreSQL, а также для СУБД mongoDB.
***Резервное копирование базы данных*** – это процедура сохранения копии данных на носителе, не являющимся основным местом их хранения. Цель данной процедуры – получить возможность восстановления данных в случае их потери на основном сервере. Технически, для правильного проведения процедур резервного копирования, помимо скриптов, речь о которых пойдет ниже, необходимо иметь фундаментальное представление о структуре файлов баз данных, видах резервных копий и сопровождающей процесс документации. Структура необходимых знаний схематично показана на рис. 1.

Сразу отметим, что файловая структура баз данных и возможные типы резервных копий могут существенно различаться, в зависимости от выбранной СУБД. Принцип функционирования файловой структуры MS SQL Server 2018 будет подробно разобран на практических занятиях, сопровождающих эту лекцию. Ниже будут приведены типы резервного копирования для СУБД MS SQL Server 2018. Типы резервных копий СУБД PostgreSQL и mongoDB будут кратко рассмотрены в части лекции, посвященной скриптам резервного копирования.
Для СУБД MS SQL Server 2018 выделяют 3 основных типа резервного копирования баз данных: полная резервная копия базы данных, разностная резервная копия базы данных и резервная копия журналов транзакций. Также, отдельно отметим возможность частичного резервного копирования файлов баз данных. На рис. 2 показано соотношение типов копий по объему данных.

На рисунке самый большой круг (синий), это ***полная резервная копия*** базы данных. Она отображает состояние всей базы данных на момент копирования. Как правило, такая копия весьма внушительна по размеру и процесс ее создания занимает значительное время, создавая сильную нагрузку на сервер баз данных. Копия содержит все данные заданной базы данных и журналы транзакций, которые будут сопровождать процесс восстановления данных в случае необходимости.
Второй по размеру круг на рис. 2 (коричневый) – это ***разностная (дифференцированная)*** резервная копия базы данных. Копия этого типа зависит от предварительно созданной полной резервной копии базы данных. Разностная копия содержит в себе только те данные, которые были изменены в базе с момента последнего создания полной резервной копии базы данных. Дело в том, что, как было сказано выше, процесс создания полной резервной копии зачастую бывает весьма объемным, длительным по времени и может сильно нагрузить сервер. Отсюда невозможно регулярно (например, каждый день) создавать полные резервные копии и создаются они, как правило, с промежутком в неделю. Чтобы не потерять массивы данных, которые добавляются или изменяются в базе данных в промежутке между снятием полных копий, применяется разностное копирование.
Наконец последний, самый маленький круг на рис. 2 (черный), это ***резервная копия журналов*** транзакций. В эту самую маленькую по объему резервную копию базы данных входят все записи журнала транзакций, которые не вошли во все предыдущие резервные копии журналов.
**1.2. Структура журнала транзакции и восстановление баз данных.**
Журнал транзакций – один из ключевых элементов СУБД. В этот файл записываются все транзакции, которые были осуществлены в соответствующей СУБД. Именно благодаря этому файлу, который ведется СУБД в автоматическом режиме, сама СУБД сможет определить, когда, где и какие изменения были осуществлены пользователями в базе данных. Это является критически важным при многих системных процедурах СУБД, не исключая процедуры восстановления баз данных. Упрощенная типовая структура журнала транзакций показана на рис. 3.

Идентификатор транзакции – уникальный номер, выдаваемый каждой транзакции СУБД, позволяющий однозначно отличить одну транзакцию от всех остальных.
Указатель назад – номер этапа транзакции, на котором осуществляется указанное в данной записи действие. Указатель назад в положении 0 говорит о начале транзакции на этой этапе.
Указатель вперед – номер следующего этапа транзакции. Указатель вперед в положении 0 говорит об окончании транзакции на этом этапе.
Время – системное время в тот момент, когда было осуществлено действие в рамках транзакции.
Тип операции – одна из инструкций, входящих в состав транзакции (BEGIN, INSERT, UPDATE и так далее).
Объект – объект базы данных, в котором были внесены изменения транзакцией.
Исходный образ – значение до изменения транзакцией.
Конечный образ – значение после изменения транзакцией.
В табл. 1 показан образец журнала для группы произвольных транзакций.
Логика процесса восстановления данных для случая, описанного в тексте конспекта Лекции 2 показана на рис. 4.

Продавец магазина последовательно, с помощью транзакции заносит данные в таблицы КЛИЕНТ и ПРОДАВЕЦ. При попытке добавить новую строку в таблицу ЗАКАЗ происходит крах системы (перебой питания, переполнение физической или оперативной памяти и так далее). После восстановления системы, процессор восстановления с помощью записей журнала транзакций откатывает изменения, внесенные некорректно законченной транзакцией, возвращая таблицы КЛИЕНТ и ПРОДАВЕЦ в состояние «до транзакции». Транзакцию можно повторить снова, уже с положительным результатом.
Ниже приведены основные правила взаимодействия администратора баз данных с журналами транзакций.
1. Правильным решением всегда будет размещать копию журнала транзакций на твердотелый, ленточный или иной быстрый и надежный отдельный накопитель.
2. Ввиду их небольшого размера, резервные копии журналов следует делать по возможности чаще, и точно не реже чем через час.
3. После создания очередной полной резервной копии базы данных, все ранее сохраненные копии журнала транзакций (как и разностные копии) можно и следует удалить.
4. Постоянный мониторинг состояния и наличия свободного места на диске, на котором происходит журналирование и создание резервных копий журнала транзакций. В случае возникновения проблем с журналом транзакций, СУБД потеряет возможность осуществлять дальнейшие транзакции.
5. Добавление в скрипты резервного копирования журналов транзакций функции усечения (SHRINK) для того, чтобы избежать их переполнения (действие опционально).
***1.3. Документация и скрипты резервного копирования.***
Сам процесс резервного копирования в организациях регламентируется соответствующей нормативной документацией. В контексте нашей лекции мы рассмотрим документацию, связанную с анализом параметров сервера баз данных и его окружения, а также план резервного копирования.
Исследование параметров функционирования базы данных позволяет определить эффективное время процедуры резервного копирования баз данных, а также усредненную длительность этого процесса и нагрузку на сетевое оборудования. Пример документа «Планируемые характеристики объекта резервного копирования» показан в табл. 2.
Перед составлением плана резервного копирования, в результате коллективной работы пользователей и администраторов баз данных составляется набор бизнес-требований к процедуре резервного копирования баз данных. В этих требованиях, в произвольной форме отмечаются базы данных, которые подлежат резервному копированию, а также периодичность и время снятия резервных копий. Приведем пример фрагмента таких бизнес-требований.
1. Полная копия базы данных Adventure Works должна создаваться один раз в неделю.
2. Разностная копия базы данных Adventure Works делается каждый день.
3. Копии журнала транзакций базы данных Adventure Works делаются каждый час.
4. Копия системной базы данных master делается раз в неделю.
5. Копия системной базы данных msdb делается раз в неделю.
6. Копии с высокой и длительной нагрузкой на сервер баз данных (в первую очередь полная копия базы данных Adventure Works) должны выполняться в нерабочее время офиса организации.
Сам документ План резервного копирования регламентирует день, время и частоту регулярных процедур резервного копирования и является базой для автоматизации этого рутинного процесса. Пример документа показан в табл. 3.
В поле описание добавлены дополнительные заметки, которые необходимо учитывать при осуществлении настройки процедуры копирования. В приведенном примере указаны следующие дополнительные указания – необходимость применения функции SHRINK для всех журналов транзакций, необходимость удаления старых резервных копий, регулярная проверка целостности базы данных и согласованности данных.
На основании плана резервного копирования настраиваются агенты автоматизации СУБД, после чего обслуживание резервных копий проходит в полуавтоматическом режиме. О принципах автоматизации функций администратора баз данных будет рассказано в одной из последующих лекций курса.
Типовые скрипты резервного копирования и восстановления данных для языка tSQL приведены в Рабочей тетради студента по дисциплине «Проектирование и администрирование хранилищ и баз данных, Часть 2» и будут разобраны в ходе курса в рамках соответствующей практической работы. Ниже будут разобраны базовые скрипты резервного копирования и восстановления для СУБД PostgreSQL и MongoDB.
Базовым методом резервного копирования PostgreSQL является применение процедуры pg_dump. В ходе своего выполнения, данная процедура соединяется с целевой базой данных и открывает большую транзакцию с настройкой Repeatable Read (см. глава 3), которая считывает все данные с целевой базы данных. Благодаря функции Repeatable Read, на действия транзакции, осуществляющей копирование не сможет повлиять ни одна другая транзакция, параллельно происходящая в базе данных, и итоговый массив данных гарантированно будет согласованным. Результатом работы процедуры pg_dump по умолчанию является простой текстовый документ со всеми данными целевой базы данных. Приведем базовую команду процедуры pg_dump:
[linuxpc ~] $ pg_dump -U /пользователь БД/ /копируемая БД/ > /путь к файлу и название файла.sql/
Флаг -U указывает на пользователя, от имени которого будет осуществляться резервное копирование. Если СУБД не требует такого рода проксирования, этот флаг можно опустить. Перечислим иные важные флаги для процедуры pg_dump.
-d, —dbname = /название базы данных/, явное указание целевой базы данных.
-h, —host = /название хоста/, имя хоста на котором находится целевой сервер баз данных.
-p, —port = /номер порта/, указание на порт доступа к БД на стороне хоста.
-W, —password, указание на то, что при использовании пользователя необходимо указать его пароль.
Также, с помощью флагов можно добиться более гибкой настройки массива копируемых данных.
-a: копируются только данные, структура данных не копируется;
-s: копируется только структура данных, без данных;
-n: копируется только указанная схема данных;
-N: копируется все, кроме указанных схем данных;
-t: копируются только указанные таблицы;
-T: копируется все, кроме указанных таблиц.
В случае возникновения необходимости скопировать не какую-то отдельную базу данных, а все содержимое сервера целиком используется процедура pg_dumpall.
[linuxpc ~] $ pg_dumpall > /путь к файлу и название файла.sql/
Восстановление базы данных из резервной копии происходит с использованием процедуры pg_restore. При восстановлении следует обратить внимание на то, что процедура может добавлять данные даже в существующие базы данных (возможна ошибка, но технически данные будут добавлены).
[linuxpc ~] $ pg_restore -d /целевая база данных/ /путь к файлу и название файла/
Процедура pg_dump хорошо показывает себя на маленьких и средних массивах данных, хранимых в базах. В случае больших массивов данных будет целесообразным рассмотреть возможность настройки репликации базы данных. Об этом будет рассказано в последующих лекциях.
Базовым методом резервного копирования документальной СУБД MongoDB является применение процедуры mongo_dump. Приведем базовую команду процедуры mongo_dump:
mongodump —host /имя хоста целевой базы данных/ —port /номер порта доступа к серверу/ —username /имя пользователя/ —password /пароль пользователя/ —out /путь к файлу резервной копии/
Для масштабирования резервной копии можно применять флаги —db /имя базы данных для резервной копии/ и —collection /имя коллекции для резервной копии/. Восстановление базы данных из резервной копии происходит с использованием процедуры mongorestore.
mongorestore —host /имя хоста/ —port /номер порта доступа к серверу/ —username /имя пользователя/ —password /пароль пользователя/ —out /путь к файлу резервной копии/
***1.4. Вопросы для самостоятельного изучения по итогам лекции.***
1. С помощью какой инструкции SQL вызвать просмотр журнала транзакций MS SQL Server?
2. Как настроить инструкцию SQL, чтобы увидеть журнал транзакций, максимально приближенный к образцу на рисунке 17?
3. Составьте таблицу и скрипты резервного копирования для вашего проекта из Курсовой работы по дисциплине Проектирование и администрирование хранилищ и баз данных.
3.5. Тестовые задания для самопроверки.
1. Для получения списка файлов данных и журналов транзакций, входящих в набор резервных копий используется следующий оператор Transact-SQL:
А) RESTORE labelOnly FROM
Б) RESTORE headerOnly FROM
В) RESTORE data FROM
Г) RESTORE fileListOnly FROM
2. При применении модели восстановления SIMPLE для восстановления БД минимум необходимо:
А) только разностные копии
Б) соответствующая полная копия БД и при необходимости разностные копии
В) соответствующая полная копия и вся цепочка копий журналов транзакций
Г) полный набор копий (полная, разностная, журнал транзакций)
3. Какая из предложенных инструкций установит полную модель восстановления для конкретной БД.
А) ALTER DATABASE dbname SET RECOVERY FULL
Б) RECOVERY MODEL FULL TO DATABASE dbname
В) ALTER DATABASE dbname RECOVERY AS FULL
Г) ALTER TABLE dbname SET RECOVERY FULL
4. Какие модели восстановления поддерживает компонент Database Engine?
А) простая, полная, с неполным протоколированием
Б) простая, сложная, комбинированная
В) простая, полная, комбинированная
Г) простая, полная, простая с протоколированием
5. Что из перечисленного нельзя реализовать с помощью журнала транзакций?
А) восстановление отдельных транзакций
Б) восстановление всех незавершенных транзакций
В) накат файла, файловой группы
Г) все перечисленное реализуемо
6. Усечение журнала транзакций происходит с использованием команды:
А) DBCC LOW
Б) DBCC SMALL
В) DBCC SHRINK
Г) DBCC CLEAR
7. Резервная копия, содержащая данные, накопленные «между» полным копированием, называется
А) дифференцированная
Б) диверсифицированная
В) дискриминированная
8. Резервная копия, каждый раз подлежащая ручной настройке со стороны администратора, называется
А) файловая копия
Б) полная копия
В) копия журнала транзакций
9. Последовательность восстановления БД MS SQL Server «по умолчанию»:
А) полная копия – файловая копия
Б) полная копия – дифференцированная копия
В) файловая копия – копия журнала транзакций
10 Обязательно исполнение условия копирования журнала транзакций:
А) копирование с периодичностью в 10 минут
Б) проверка файла после создания резервной копии
В) копирование на отдельный носитель

Почему растет LOG в MS SQL ?

Почему растет LOG в MS SQL ?

Друзья, почти ежедневно сталкиваюсь с тем, что на курсе: Администратор 1С, при опросе студентов, на предмет «Как Вы организовали бэкап в MS SQL?». Очень редко кто пишет: «Да, помимо «полного» я делаю и бэкап журналов транзакций».

К сожалению, редко кто делает бэкап ЖТР (

И тем самым открывает прямой путь к таким проблемам как:

«Распух лог в MS SQL», «Сильно увеличился LDF», «Разрастается log, что делать?», «Журнал занял все свободное место на диске», и многое, многое другое.

В этой статье я не буду рассыпать терминами и сложными понятиями гуру специалиста DBA, нет!

Так как вижу реальную картину, реальную проблематику вопроса, на более чем 5000 тыс студентов (Что проходили у нас курс: Администратор 1С). И реальность она несколько в другом!

Большинство не делает бэкапов журналов транзакций, так как не понимает зависимостей (связей), между их созданием и размерами самого журнала (*ldf).

Собственно цель данной статьи, максимально понятно, на простом языке, объяснить  и закрыть раз и навсегда проблему растущего лога в MS SQL!

Приступим…

Кратко пройдемся по основам, чтоб даже новички быстро смогли уловить суть и не потеряться в терминах.

Файл *LDF он же и есть наш журнал транзакций!

Что там хранится?

Каждая база данных SQL Server имеет журнал транзакций, в котором фиксируются все транзакции и производимые ими в базе изменения.

Журнал транзакций — это важная составляющая базы данных. Если система даст сбой, этот журнал поможет вам вернуть базу данных в согласованное состояние.

Если говорить еще проще, благодаря бэкапу ЖТР есть возможность восстановить базу фактически на любой момент времени (вплоть до нужной секунды)!

При этом следует понимать, что никаких по факту данных из 1С в прямом смысле этого слова в журнале нет!

Все данные пишутся в файл *mdf, а вот фиксация этих действий пишется в *ldf, по каждому действию (транзакции), что происходит у Вас в 1С. Все что делают пользователи в 1С, фиксируется в журнале транзакций, только сам факт (фиксация) произошедших событий в базе, а не сами данные.

Собственно отсюда и название «Журнал транзакций». Конечно на практике все сложнее, но в упрощенном для понимания виде все именно так.

Почему растет лог файл в MS SQL (*ldf) ?

Конечно, если учитывать что каждое действие сделанное пользователем в 1С фиксируется в журнале транзакций, то он просто не может не расти! И здесь также стоит отметить, что не только действие пользователя влияет на рост журнала, но и различные регламентные задачи (фоновые различные процессы), особенно сильно заметен рост, когда происходит в базе 1С реструктуризация. Собственно при обновлении конфигурации также можем замечать “взрывной” рост журнала транзакций.

К слову мы только что ответили на частый вопрос: «Вот у меня лог не разрастался» в базе «А», а в базе «Б» растет очень быстро».

Конечно если с базой «Б» пользователи работают интенсивно или различные фоновые, регламентные задачи (их много), безусловно, он будет расти быстрее, такова физика работы «MS SQL»!

MS SQL всегда (в “полной” модели восстановления) будет пытаться зафиксировать, фактически все действия в базе. И журнал будет расти до тех пор, пока мы не сделаем его бэкап, этим мы и «усекаем» его!

«Простая» и «полная» модель восстановления

Да, «полная» модель восстановления подразумевает, что в журнал будем писать «По максимуму» все возможное.  Все что сможет записать MS SQL, он туда запишет. Исключения конечно есть. К примеру, когда свободное место закончилось на диске или есть ограничения на сам лог (если установили). Есть и другие причины, но мы сейчас не об этом.

Нам важно понимать одно: «Полная» модель = «Полный» лог! А значит, есть возможность не терять данные, при необходимости восстановится на любой момент времени (фактически до секунды), а выполнив бэкап еще и «заключительного фрагмента журнала» и вообще ничего не потерять!

На сайте Microsoft можно найти информацию о том, что единственная  «рабочая» модель, предназначенная для реальной работы, есть только  «Полная» модель восстановления! Так как в работе недопустимо терять данные, а это гарантированно произойдет в «Простой» модели восстановления, если случится “сбой”.

«Простая» модель восстановления может использоваться для тестирования, разработки, для временного переключения (Обязательно! С предварительным бэкапом базы и лога). К примеру, только на время реструктуризации ее можно включить, а потом обратно вернуть в «Полную» модель. Есть и другие случаи, когда мы только временно переключаем режим с «Полной в Простой» Но работаем всегда в “полной” модели восстановления!

В “простой” модели мы никак не можем восстановиться (в случаи чего) на интересующий нас момент времени. Только на тот момент, когда сделан либо «полный» бэкап, либо «полный» + «разностный»!

Вывод:

Только в «полной» модели мы должны работать! Она не зря «по умолчанию» в MS SQL!

«Активная» и «Неактивная» часть журнала

Сперва дадим ответ на вопрос:  «Что происходит в момент создания бэкапа ЖТР ?»

Чтоб разобраться в этом вопросе, нам нужно понимать, что журнал транзакций может быть «условно разделен» на две части: «Активная» и «Неактивная» часть журнала.

«Активная» – содержит изменения, которые были сделаны в базе, но еще не зафиксированы на диске.

«Неактивная» – изменения уже зафиксированы на диске, следовательно, можно усекать неактивную часть журнала (делать бэкап), вплоть до его активной части!

Неактивная часть журнала транзакций содержит информацию о завершенных транзакциях и не используется сервером SQL Server в процессе восстановления данных. Вместо увеличения размера файла журнала транзакций SQL Server будет повторно использовать освободившееся пространство.

И вот в момент, когда мы создаем бэкап журналов транзакций, мы тем самым «усекаем» его «неактивную» часть (точнее это делает сам MS SQL), вплоть до начала его активной части!

При этом вначале всегда происходит его бэкап, а только после уже «усечение», как на рисунке выше.

Бэкап журналов нужно делать довольно часто (раз на 30-60 мин), особенно если с базой активно работают пользователи, он может вырасти довольно быстро, и конечно без автоматизации этого процесса не обойтись!

Также мы можем сделать и бэкап «заключительного фрагмента журнала транзакций», если нужно восстановить базу на самый последний момент времени. В таком случаи мы также усекаем журнал (ту часть, что есть на момент создания самого заключительного фрагмента журнала).

Вывод:

В «полной» модели восстановления бэкап журналов транзакций НЕОБХОДИМ! Если Вы не хотите в один прекрасный день обнаружить, что свободное место на диске, где он находится, уже закончилось!

Если ЛОГ уже вырос ?

Конечно, если Вы раньше не делали бэкапов журналов, лог соответственно вырос, то здесь одним бэкапом журналов транзакций не обойтись!

И вот почему:

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Успехов Вам, Коллега!

С уважением, Богдан.

Метки:MS SQL и 1С, Администрирование, Администрирование в 1С, Базы в 1С Предприятии, информационные базы в 1С, Настройка 1С, Проблемы в 1С Предприятии, Ускорить работу 1С

Усечение файла журнала транзакций SQL Server

спросил
11 лет, 5 месяцев назад

Изменено
7 лет, 7 месяцев назад

Просмотрено
57 тысяч раз

На локальном диске C: у меня есть файл ldf для базы данных, размещенной на одном из наших серверов. У меня есть локальная копия одной из баз данных размером 1 ГБ и ldf (файл журнала) этой базы данных размером 16 ГБ. Это съедает много моего локального пространства на моем жестком диске. Я хотел бы обрезать этот файл. Многое из того, что я читал в Интернете, не соответствует действительности, но кажется, что они говорят о файлах на сервере, на котором находится база данных. Здесь это не так, это на моей локальной машине.

Расположение файла на моем компьютере:

 C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
 

Почему у меня есть локальная копия этого файла журнала, а также локальная база данных?

Как мне обрезать этот файл?

Спасибо!

• sql-server

Перейдите в панель Object Explorer в SSMS и щелкните правой кнопкой мыши нужную базу данных. Выберите задачи -> сжать -> файлы. Измените параметр типа файла на «Журнал», щелкните параметр «Реорганизовать страницы перед освобождением неиспользуемого пространства» и установите значение 1 МБ. Нажмите ОК.

Если это не сработает, проверьте, настроена ли для вашей базы данных модель полного восстановления базы данных. Щелкните правой кнопкой мыши базу данных и перейдите в свойства. Выберите «Параметры» и установите флажок «Восстановить модель». Установите простой (если можете!!!), а затем уменьшите журналы.

7

Другой вариант, который вы можете попробовать, это использовать WITH TRUNCATE_ONLY:

 BACKUP LOG имя базы данных WITH TRUNCATE_ONLY
DBCC SHRINKFILE ( журнал adventureworks_Log, 1)
 

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

 ALTER DATABASE mydatabase SET RECOVERY SIMPLE
 DBCC SHRINKFILE (adventureworks_Log, 1)
 

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

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

tsql — Как обрезать/очистить огромные файлы журнала SQL

Задавать вопрос

спросил
2 года 11 месяцев назад

Изменено
2 года, 11 месяцев назад

Просмотрено
6к раз

У меня есть несколько баз данных размером около 500 МБ с файлами журналов размером более 50 ГБ.

чтение Я видел, что резервные копии журналов транзакций не делались, поэтому я подозреваю, что это причина такого роста с годами. Я настраиваю репликацию Always on и хотел бы очистить файлы журнала транзакций перед настройкой Always on.

Я следил за некоторыми ответами, такими как:
https://theitbros.com/truncate-sql-server-2012-transaction-logs/
https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

Но я не могу уменьшить файлы до любого умеренного размера. Есть ли способ очистить файлы журнала и уменьшить их размер до +- 100 МБ?

Я установил для базы данных простую модель восстановления, запустил приведенный ниже TSQL, но он все еще не освобождается. При открытии отчетов я вижу, что нет свободного места для освобождения даже после установки в простой режим восстановления. Я согласен с потерей восстановления на момент времени, так как после изменения размера журналов я верну все обратно к полному и сделаю полную резервную копию.

 ИСПОЛЬЗОВАНИЕ [AdventureWorks2016CTP3]
ИДТИ
DBCC SHRINKFILE (N'AdventureWorks2016CTP3_Log', 0, TRUNCATEONLY)
ИДТИ
 

Я уже сделал полные резервные копии, прежде чем что-либо делать, просто для безопасности.
Любые советы / рекомендации приветствуются.

• tsql
• sql-server-2019

Удалить TRUNCATEONLY .

 ИСПОЛЬЗОВАНИЕ [AdventureWorks2016CTP3]
ИДТИ
DBCC SHRINKFILE (N'AdventureWorks2016CTP3_Log', 100)
ИДТИ
 

3

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

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