Как усечь журнал транзакций MSSQL Server?
Журнал транзакций во всех версиях Microsoft SQL Server имеет тенденцию расти со временем. Иногда он может заполнить все свободное место на сервере. Чтобы избежать этого, в SQL Server есть операция усечения журнала транзакций.
Журналы транзакций SQL Server и модель восстановления базы данных
Журналы транзакций используются для записи всех транзакций перед передачей данных в файл базы данных. Файлы журнала транзакций необходимы для отката базы данных до предыдущего состояния. Как правило, в журнале хранится порядковый номер, тип изменения, выполненные операции и т. д. Скорее всего, вы можете использовать SQL Server и без журнала транзакций, но тогда в в случае сбоя возможна потеря базы данных.
Журнал транзакций состоит из небольших логических элементов, называемых VLF (Virtual Log File). Вы можете узнать их количество, выполнив следующий запрос в контексте базы данных SQL Server:
Количество возвращаемых строк указывает на то, сколько виртуальных файлов сегментировано в журнале. В поле «Status» отображается текущее состояние сегмента. Значение 0 означает, что сегмент в настоящее время не занят и может использоваться. 2 означает, что сегмент используется. Если свободных сегментов нет и в настройках базы данных SQL Server разрешено увеличение журнала транзакций, он будет увеличен и будут созданы новые VLF. Если размер журнала транзакций фиксирован или на диске недостаточно места, все операции по изменению структуры базы данных или ее содержимого станут недоступными. Скорее всего, вы получите ошибку: Журнал транзакций для базы данных переполнен.
- Простая модель восстановления – файлы журнала автоматически обрезаются после достижения контрольной точки (самый простой вариант, требующий администрирования базы данных). При использовании модели простого восстановления журнал транзакций очищается сразу после завершения транзакции. В этом режиме вы можете откатить вашу базу данных только до времени полного резервного копирования базы данных.
- Модель полного восстановления – журнал транзакций не будет очищен, пока не будет завершено резервное копирование журнала транзакций. Этот режим обеспечивает наилучшую возможность восстановления данных после сбоя. В полном режиме журнал транзакций (LDF) может увеличиваться (поскольку изменения базы данных накапливаются в этом журнале). В модели полного восстановления все транзакции SQL записываются в файлы журнала на диске и сохраняются там до создания резервной копии. Хранение журналов позволяет вам при необходимости вернуться к более ранней копии базы данных, и вы можете выполнить восстановление для каждой транзакции.
- С неполным протоколированием – этот режим позволяет сократить занимаемое пространство используя минимальные настройки ведения журнала. Если журнал был поврежден или с момента создания последней резервной копии журналов выполнялись операции с неполным протоколированием, все изменения после этого резервного копирования необходимо внести повторно. Иначе результаты работы потеряны не будут.
Когда используется модель полного восстановления базы данных, необходимо регулярно выполнять резервное копирование журнала транзакций, в противном случае он будет чрезмерно увеличиваться до тех пор, пока не займет все место на диске, и SQL Server не начнет сообщать об ошибке.
Как обрезать журналы транзакций на MS SQL Server?
Мы получили вот такое сообщение:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных “buh” заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1
Это означает, что на диске, где хранится журнал транзакций SQL, недостаточно места, и SQL не может записать новые данные транзакции. В этом случае вы можете обрезать файлы журналов SQL вручную (с помощью графического интерфейса Management Studio).
Чтобы обрезать журналы транзакций SQL, запустите SQL Server Management Studio (SSMS), выберите нужную базу данных, щелкните ее правой кнопкой мыши и выберите «Свойства» в контекстном меню. Перейдите в Параметры и переключите модель восстановления базы .
Меняем модель восстановления с Полной на Простую
Затем в главном меню перейдите в раздел «Задачи» -> «Сжать» -> «Файлы» .
В поле Тип файла выберите Журнал, в поле Имя файла укажите имя файла журнала. В поле «Операции сжатия» выберите « Реорганизовать страницы, перед тем как освободить неиспользуемое пространство» , установите нужный размер файла и нажмите «OK».
Нажимаем «OK». После завершения операции обязательно измените режим восстановления базы данных обратно на Полный.
Это только один из способов быстрого уменьшения размера логов. Не самый лучший, но очень простой и эффективный.
Кроме того, имейте в виду, что при усечении журналов транзакций SQL с помощью этого руководства все предыдущие резервные копии, сделанные в модели полного восстановления, могут быть отброшены. Вот почему этот метод следует использовать только в критических случаях, когда невозможно быстро очистить дисковое пространство другими способами.
DBCC SHRINKFILE to Clear SQL Server Transaction Log File
A Transaction Log is a file that contains all the records of transactions and the database modifications made by each transaction in SQL Server database. The log file plays a very important part of SQL Server database when it comes to disaster recovery and it should not be in corrupted state. The DBCC SHRINKFILE method is also discussed after understadning the user query “how to clear SQL server transaction log”.
We can recover the database with the help of information present in SQL Server transaction log during any disaster. The transaction log should be truncated or cleared regularly to keep the size of log file from filling up. This page will be discussing on how to clear SQL Server Transaction Log.
DBCC SHRINKFILE to Shrink Transaction Data Files
DBCC SHRIKFILE is basically the command to shrink the database size by shrinking the SQL files, especially transaction log files. It can also move data from one file to another residing in the same file group to remove the original file that is no longer needed.
Why to Clear SQL Server Transaction Log?
During SQL Server work, the transaction log grows if any database changes occur. The regular management of the size of transaction log is necessary to prevent the transaction log from becoming full. Log truncation or clear SQL Server transaction log is required to keep the log from filling up. Here, we can use the DBCC SHRINKFILE method as well as the automated solution too.
The truncation process deletes inactive virtual log files from the logical transaction log, freeing space to be reused by the physical transaction log. The transaction log would eventually fill all the disk space allocated to its physical log files, if it is never truncated. Evidently, SQL server clear transaction log task is required to get more space.
Three recovery models are there in SQL Server. Depending on which one is used, truncation process differs:
Simple Recovery Model The transaction log backups are not supported and the truncation process is automatic and space is available for use.
Bulk-logged Recovery Model No automatic log truncation, backups are needed regularly to mark unused space and make it available for overwriting. Log size can be reduced by using minimal logging for bulk operations.
Full Recovery ModelThe truncation process is same as Bulk-logged Recovery model. There is a high chance of growing log file since every transaction that takes place on the database,is logged into it.
The transaction log space can be monitored using command:
How to Clear SQL Server Transaction Log?
Log truncation frees space in the log file for reuse. Therefore, it is also called Log clearing. The transaction Log file is logically divided into small chunks called Virtual Log Files (VLF). Each VLF file is the unit that can be marked as available for reuse (free) or not available for reuse (used). The VLF is marked ‘active’ if it is used and ‘inactive’ if it is free. Clear SQL Server transaction log means searching and making VLFs as free.
Note: It should be kept in mind that Log Truncation is not meant to reduce the size of the physical log file. Log Shrinking is needed to reduce the physical log file.
Clearing SQL Server transaction log involves two steps. Firstly, we need to perform log backup with TRUNCATE_ONLY option and next step is to use the DBCC SHRINKFILE function to shrink file to the required size.
BACKUP LOG WITH TRUNCATE_ONLY is not a good option as it empties all the contents of our transaction log without backing it up. Many people use this command before shrinking the log file with DBCC SHRINKFILE freeing up the drive space. TRUNCATE_ONLY is not available in later versions of SQL Server.
Instead of truncating transaction logs, we can use simple recovery mode by which we do not generate logs we would not be using.
As you just saw the dbcc shrinkfile log method. We have two options to do so. They are:
Use The SQL Server Management Studio
Right click on the database and choose:Tasks followed by Shrink and then select Files:
Change the file type to log.
Shrink SQL Transaction Log File using T-SQL
For Simple Recovery, following command will be used:
DBCC SHRINKFILE (LogFileName, Desired Size in MB)
For Full Recovery (Only when we don’t mind losing data in log file), the commands to be used are –
Another option to shrink SQL transaction log file is to, backup the database log using the following command:
This is how one can get to know how to clear SQL Server Transaction Log file in order to free up the space in it for further storage of transactions. Transactions are very important to keep track of the changes taking place in corresponding database as well as to rollback just in case it is required. Therefore, always keep a check and maintain the transaction log files.
Conclusion
We hope now users are able to make space in their SQL Server database by clearing out the log files. Learning how to clear log file in SQL server using query is easy. However, users must be aware of the right technique. Therefore, the above-mentioned two methods can be a perfect match for users.
Q-1. What is the purpose of DBCC SHRINKFILE command?
Ans: The primary purpose of the SQL Server DBCC Shrikfile is to shrink the physical log file up to the desired limit & fasten the SQL query performance & other operations.
Q-2. What are the risks of using DBCC SHRINKFILE in SQL?
Ans: Several users & experts reported that DBCC SHRINKFILE, causes performance issues but only if not used well. Users need to take care of index fragmentation as well.
Q-3. Do experts recommend shrinking log files?
Ans: Well, it’s not recommended by the experts to shrink the log files as it affects the performance of the server if done falsely. However, in case users are having really heavy SQL log files, there is no harm in adopting this.
Q-4. Are DBCC SHRINKDATABASE & SHRINKFILE different from each other?
Ans: Yes of course, both these are different. Here, the Shrinkfile only allows users to shrink the log data files whereas the other one is to shrink the entire database at once.
Q-5. How to clear the SQL server transaction log without the command?
Ans: Users can simply remove the duplicate files of their database along with corrupted MDF, LDF as well as NDF files.
Шринк лога транзакций MS SQL 2008/2012 в экстренном случае или боремся с ошибкой HRESULT=80040E14
Когда при подключении к базе MS SQL появляются ошибки:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных «ReportServer» заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1
Ошибка СУБД:
Microsoft OLE Provider for SQL Server: The transaction log for database “ReportServer” is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column is sys.database
HRESULT=80040E14, SQLSTATE=4 2000, native=9002
это значит, что на диске, где расположен лог транзакций закончилось место и теперь СУБД некуда записывать данные о новых транзакциях. Чаще всего такое происходит, когда не установлено никаких ограничений на размер лога и в MS SQL не создано соответствующих планов обслуживания.
В таком случае нужно уменьшить размер самого файла транзакций (*.ldf) , другими словами сделать шринк (сжатие) лога. Для этого можно использовать как запрос, так и сжатие лога вручную.
Рассмотрим сжатие лога транзакций вручную:
Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе — Свойства(Properties) — Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Простая(Simple) — OK.
Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе — Задачи(Tasks) — Сжать(Shrink) — Файлы(Files) — установить Тип файла(File type) — Журнал(Log) — в Операция сжатия(Shrink action) — выбрать Реорганизовать страницы, перед тем осводить неиспользуемое место(Reorganize pages before releseasing unused space) — Сжать файл (Shrink file to) —
указать приемлемый размер лога.
Шаг 3. Установить модель восстановления Полная(Full). Правой кнопкой на базе — Свойства(Properties) — Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Полная(Full) — OK.
P.S.: В данной статье даны рекомендации для решения конкретной проблемы. Настройка самого MS SQL здесь не рассматривается!
Специальные предложения
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
Идея неплоха, но в заголовке статьи не хватает надписи «в экстренном случае» или «когда штатные средства не позволяют»
Действительно, бывают запущенные ситуации, когда с логом уже ничего сделать нельзя (ни бэкап, ни шринк).
Я правильно понимаю, что эта операция поможет в случае, когда на диске уже почти не осталось свободного места?
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
Я обычно делаю скриптом. Быстрее получается.
Также можно настроить выполнение по расписанию.
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
У меня база 90 Гб. В режиме Siple, ибо то что делают юзеры и программеры с базой часто в модели Full увеличивало базу раз в 5. Даже в Siple модели лог увеличивается, если есть большое количество изменений (15-30 Гб бывает).
Для откатов, делаете дифференцированные бекапы базы в продолжении для (периодичность скажем час) и всё что нужно есть.
Шринк да базе 90 Гб при полной модели при робочих юзерах (лог файл 50-150 Гб) нивжизнь не пройдёт, или будет делаться очень долго. Так как при полной модели в основной базе ещё нет изменений, которые хранятся в лог-файле, а если юзера работают с данными, изменения по которым должны быть записаны. Ну и немаловажный факт — количество юзеров. У меня их за 100 одновременно работающих. Транзакции никто таки не отменял.
Как одноразовая мера, чтобы если база выжрала всё место на диске и отказывается работать, вполне оно. Все равно никто работать уже не будет. Тогда да, это самый эффективный вариант.
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
как раз такая ситуация пришла. База была брошена, франчи установили, уехали и никому до неё не было дела — никакого бэкапа — так иногда только DT-шники выгружали и то когда вспомнят. НО после проведения реиндексации реструктуризации лог вырос до 300 ГБ при базе в 45 ГБ. и почти кончилось место на диске.
причем реально база 19,5 ГБ в локальной файловой копии.(45 ГБ стала после загрузки в существующую DT-архива — может подскажете как правильно вернуть назад. ).
Сделал все как в статье (не стал БЭКАП делать ибо некуда. ограничился выгрузкой в ДТ-архив.) при неработающих пользователях. размер указал 30 ГБ. Шринк прошел очень быстро. Щас настраиваю планы обслуживания (пока на тестовой базе) и ставлю вопрос о приобритении винта специально под бэкапы.
Но у меня такой вопрос
Вроде установил модель обратно в FULL, но даже сделав реиндексацию таблиц после этого размер журнала не изменился. и мало того уже рабочий день заканчивается — куча проведеных документов была, но размер какой был такой остался и дата изменения не изменяется (последние изменения базы — 0:22 — ночью в базе никто не работает кроме меня:) а лога аж 22 числа, т.е. 2 дня назад) — у меня установлено автоувеличение лога на 200 Мб, а базы на 500 МБ, может быть дата изменения меняется только во время увеличения размера.
Хотя после реиндексации размер лога должен был увеличиться на 25 ГБ (так было до шринка) — может кто нибудь разъяснить почему лог на месте стоит? — планы бэкапов еще не подключал т.е никакого архивирования нет.
- Скопировать ссылку
- Перейти
Есть не самый простой и быстрый, но очень надежный рецепт усечения «пустого» (т.е. данных там нет но файл не уменьшается) файла ldf. Применяю когда ничто другое не помогает. Правда если изначально (при создании базы) файл был создан определенного размера, то этот способ тоже не поможет.
Рецепт простой:
//начинаем транзакцию
BEGIN TRAN
GO
//делаем апдейт какого нибудь поля какой нибудь большой таблицы
UPDATE .
GO
//отменяем транзакцию
ROLLBACK
GO
После этого файл можно усечь на размер заполненных данных в файле ldf.
Рецепт используем столько раз, сколько потребуется.
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
- Скопировать ссылку
- Перейти
При полной модели восстановления бэкапы делаются так часто как это возможно для того чтобы процесс восстановления начинать не с испокон веков существования базы а с последнего полного созданного бэкапа + далее накатывают после этого бэкапы логов транзакций. это очень удобно хотя на практике приходилось пользоваться всего пару раз в жизни. У нас например это раз в неделю по четвергам (самое оптимальное время исходя из всех регламентов скуля + сервера 1С).
При простой модели вы сможете восстановить базу только на момент последнего созданного бэкапа.
Если у вас есть нормальное ПО по управлению бэкапами и логами ТЗ (хотя все это можно написать и на SQL) то делается просто.
Полная модель. Создается бэкап базы, хранится, далее бэкапятся логи раз в нужное вам время у нас это 15 минут, логи тоже хранятся, но каждый раз когда проходит полный бэкап базы НОРМАЛЬНО все старые бэкапы базы и логов трутся и начинается новый отсчет времени. Ну и так же настроено месячное хранение базы полугодичное и годовалое которые хранятся отдельно и трутся соответственно когда создаются подобные бэкапы.
При полной модели и наших настройках мы можем восстановить базу максимум с недельной давностью, далее все остальное накатить логами.
Так же мы можем восстановить базу на начало месяца, начало полугодия и начало года но уже без логов транзакций.
Насчет тормозов не могу согласиться с предыдущими ораторами о том что простая модель работает быстрее, они работают одинаково если нормально настрое сервер SQL, просто лог транзакций должен по умолчанию лежать на другом зеркале, отдельно от того зеркала где располагается база. Много раз проверяли что так что так работает одинаково. Если же логи транзакций лежат на том же массиве что и база — безусловно будет работать медленнее.
Как очистить журнал sql server
Добрый вечер коллеги!
Перечитал кучу статей, но так и не нашел ответа на свой вопрос.
Есть 5 баз 1С в MSQL 2012, Настроен Maintance plan. В конце Задачи"Очистка после обслуживания", и "Очистка журнала". Но логи не удаляются приходиться в ручную очищать после предельного переполнения. Метод восстановления баз стоит полный.
1.Что будет если установлю метод восстановления простой
2. На что влияет если я выполняю сначала переход с полного режима на простой, после очищаю лог и потом снова высталяю метод восстановления полный
3. Возможно есть какая то фишка по очистке логов.
Ответы
На сколько я знаю, переход с полного на простой метод восстановления безопасно выполнять, только после выполнения полной резервной копии баз-данных, как сообстно и очистку transactionLog.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Bien cordialement, Andrei .
MCP
- Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 10 октября 2018 г. 5:47
Вы принципиально не понимаете необходимость и методы управления журналом транзакций. У меня журнал транзакций занимает объем порядка 40GB в нормальном режиме работы базы. И я его не урезаю, т.к. он все равно у вас вырастет до такого объема, если под нагрузкой имеет такой объем.
Идея иметь большой файл — сокращение операций ввода/вывода, которые потребуются сделать сиквелу при приращении файла логов. Операции ввода/вывода априори медленные.
поэтому, если вы используете модель восстановления Full, выполняйте регулярное резервное копирование журнала транзакций, смиритесь с его объемом и не делайте shrink. В противовес к этому, вы получаете возможность восстановления на максимально близкий к падению момент времени.
Если вы все таки хотите урезать логи, то уйдите на Simple и откатывайтесь на последний полный бэкап.
Innovation distinguishes between a leader and a follower — Steve Jobs
- Помечено в качестве ответа Razor1212007 20 ноября 2018 г. 11:41
Все ответы
На сколько я знаю, переход с полного на простой метод восстановления безопасно выполнять, только после выполнения полной резервной копии баз-данных, как сообстно и очистку transactionLog.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Bien cordialement, Andrei .
MCP
- Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 10 октября 2018 г. 5:47
На сколько я знаю, переход с полного на простой метод восстановления безопасно выполнять, только после выполнения полной резервной копии баз-данных, как сообстно и очистку transactionLog.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Bien cordialement, Andrei .
MCP
Innovation distinguishes between a leader and a follower — Steve Jobs
Модель восстановления стоит Full. Создан план обслуживания, настроена очистка логов. Но задача не выполняется. Либо я что то не то делаю.
У вас нет шага по резервному копированию журнала транзакций базы данных.
И очистки логов нет. Очистка журнала делает очистку журналов заданий в базе, но никак не логов.
Поэтому еще раз: или меняйте модель восстановления, как вам уже говорили, или выполняйте резервное копирование журнала транзакций дополнительным шагом.
Innovation distinguishes between a leader and a follower — Steve Jobs
У меня стоит полная модель восстановления, я добавил шаг по резервному копированию журнала транзакций базы данных. Но как теперь очистить лог?
- Изменено Razor1212007 7 ноября 2018 г. 12:02
Microsoft recommends that instead of truncating logs, you switch to simple recovery mode instead. That way you don’t generate logs you won’t be using, and you won’t incur performance impacts from repeatedly filling and truncating the logs. You also remove the need to regularly back up the transaction log.
Innovation distinguishes between a leader and a follower — Steve Jobs
How to BACKUP LOG WITH TRUNCATE_ONLY in SQL Server 2008, R2, 2012
Microsoft recommends that instead of truncating logs, you switch to simple recovery mode instead. That way you don’t generate logs you won’t be using, and you won’t incur performance impacts from repeatedly filling and truncating the logs. You also remove the need to regularly back up the transaction log.
Innovation distinguishes between a leader and a follower — Steve Jobs
Если речь идет о команде Shrink, то скорее всего это сжатие.
Сжатие файлов данных позволяет освободить неиспользуемое пространство путем перемещения страниц данных с конца файла в незанятое пространство ближе к началу файла. Когда в конце файла образуется достаточно свободного места, страницы данных в конце файла могут быть освобождены и возвращены в файловую систему.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Bien cordialement, Andrei .
MCP
Кто нибудь может написать Русским языком сделай так и так и будет тебе счастье. Как всегда слов много а по делу нифига. Ссылками все кидаются. Как и в безопасности администраторов много, а у кого идеальная система безопасности не понятно.
- Изменено Razor1212007 15 ноября 2018 г. 14:08
А вы сходите к своему руководству и попросите уменьшить вам ЗП в пользу сообщества?
Вам дали ссылки на материалы. Это вопрос обсуждался уже даже не 1000 раз. Но вы упорно не хотите сделать работу, вы хотите, чтобы ее за вас сделали.
А вы сходите к своему руководству и попросите уменьшить вам ЗП в пользу сообщества?
Вам дали ссылки на материалы. Это вопрос обсуждался уже даже не 1000 раз. Но вы упорно не хотите сделать работу, вы хотите, чтобы ее за вас сделали.
И что вы плачьтесь по зарплате, вам чего то не хватает, так наверно работу надо искать лучше. А зачем вы тут сидите Гуру администраторы. Ссылки кидать? Сколько я читал информации так и не нашел решения. Логично если бы разобрался, наверно не задавал вопрос.
- Изменено Razor1212007 16 ноября 2018 г. 12:33
т.к. от вас так и не дождались требований к точке восстановления при отказе (RPO) и времени восстановления (RTO), то точно ответить за вас никто не может.
В общем случае, я думаю, вам поможет следующее:
1. Установите режим восстановления Simple
2. Задайте желаемый размер файла логов в свойствах базы
3. переделайте задание резервного копирования, исключив из него резервное копирование журнала транзакций
В данном решении вы восстанавливаетесь на последний полный бэкап. Если он у вас проходит раз в день, то теряете данные, сделанные после бэкапа, если раз в неделю, то максимум за неделю.
Если вас это устраивает, то план действий выше. Если требования иные, то просьба озвучить их
Innovation distinguishes between a leader and a follower — Steve Jobs
Так я спросил но никто не ответил """"Получается нужно переходить на простой режим восстановления. И если что не так с базой то откатиться на вечерний бэкап и все?"""
может не поняли меня. Интересует только восстановление на дату бэкапа, т.е на каждый предыдущий день вечер. Вам спасибо за четкое объяснение.
А для себя было интересно как восстановить базу на момент ее падения. Я так понимаю использовать метод Full, делать резервную копию транзакции, но как их урезать я не понял. Должен быть SQL запрос типа такого
USE ″DBName″
ALTER DATABASE ″DBName″ SET RECOVERY SIMPLE
DBCC SHRINKFILE (″DBName″, ″Размер до которого урезать лог″);
ALTER DATABASE ″DBName″ SET RECOVERY FULL
Или я чего то не понял и это может только навредить? как у вас в компаниях настроено?
- Изменено Razor1212007 19 ноября 2018 г. 12:48
Вы принципиально не понимаете необходимость и методы управления журналом транзакций. У меня журнал транзакций занимает объем порядка 40GB в нормальном режиме работы базы. И я его не урезаю, т.к. он все равно у вас вырастет до такого объема, если под нагрузкой имеет такой объем.
Идея иметь большой файл — сокращение операций ввода/вывода, которые потребуются сделать сиквелу при приращении файла логов. Операции ввода/вывода априори медленные.
поэтому, если вы используете модель восстановления Full, выполняйте регулярное резервное копирование журнала транзакций, смиритесь с его объемом и не делайте shrink. В противовес к этому, вы получаете возможность восстановления на максимально близкий к падению момент времени.
Если вы все таки хотите урезать логи, то уйдите на Simple и откатывайтесь на последний полный бэкап.
Innovation distinguishes between a leader and a follower — Steve Jobs
- Помечено в качестве ответа Razor1212007 20 ноября 2018 г. 11:41
Вы принципиально не понимаете необходимость и методы управления журналом транзакций. У меня журнал транзакций занимает объем порядка 40GB в нормальном режиме работы базы. И я его не урезаю, т.к. он все равно у вас вырастет до такого объема, если под нагрузкой имеет такой объем.
Идея иметь большой файл — сокращение операций ввода/вывода, которые потребуются сделать сиквелу при приращении файла логов. Операции ввода/вывода априори медленные.
поэтому, если вы используете модель восстановления Full, выполняйте регулярное резервное копирование журнала транзакций, смиритесь с его объемом и не делайте shrink. В противовес к этому, вы получаете возможность восстановления на максимально близкий к падению момент времени.
Если вы все таки хотите урезать логи, то уйдите на Simple и откатывайтесь на последний полный бэкап.
Innovation distinguishes between a leader and a follower — Steve Jobs
Прекрасно я понимаю что журнал транзакции нужен для того что бы откатиться на максимально последний момент времени. Мне непонятно когда у него будет свой предел
У вас он 40 Гб, у кого-то 200 и продолжает расти. Получается из ваших слов вы с ним ничего не делаете, он достиг своего предела, возможно у вас не вноситься столько информации как у нас?