Можно ли удалить ldf файл
Для MS SQL 2008/2012 рекомендации ИТС уже устарели, кроме того и раньше они не всегда помогали. В статье попытался собрать наиболее полный комплект информации по данному вопросу.
В своё время в одном месте всего этого не нашел, поэтому думаю будет полезно.
Собственно там рекомендуется следующий скрипт:
BACKUP LOG Имя_Базы_Данных WITH TRUNCATE_ONLY
go
DBCC SHRINKFILE(Имя_Файла_Журнала_Транзакций)
go
Если выполнить его в MS SQL 2008/2012 получите ошибку:
'truncate_only' is not a recognized BACKUP option
Что теперь делать?
Решения, собственно два:
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
Делаем базу доступной.
После чего получаем БД с чистым новеньким логом. На самом деле операция достаточно проста и в большинстве случае не несёт никаких критических последствий. Но всё-таки рекомендую прибегать к ней только в крайнем случае. Описана она не раз и в разных вариациях. Привожу свой вариант, который показался наиболее простым и понятным.
Как удалить лог файл базы данных файл _log.ldf?
Подробности --> 31.01.2021 0 3647
В процессе работы с базой 1С, которая размещена в СУБД Microsoft SQL Server, происходит постепенный рост файла с логами, который может достигать приличных размеров. Решение вопроса крайне простое. Для этого вам потребуется Microsoft SQL Server Management Studio. Запускаем его и переходим в соответствующую базу.
Прежде чем делать любые манимуляции, необходимо сделать бэкап базы данных! Если возникли трудности, напишите комментарий к статье, мы поможем.
Если у вас рускоязычная версия, то выполните следующую последовательность действий:
1. Заходите в "Свойства";
2. Находите в раздел "Параметры";
3. В пункте "Модель восстановления" выбираем "Простая"
4. Выбираем для параметра "Автоматическое сжатие" значение "True"
5. Выбираем для параметра "Статистика автоматического создания" значение "True"
6. Нажимаем ок и снова возвращаемся к базе данных
7. Нажимаем правой клавишей на нашей базе - "Задачи" - > "Сжать" -> "База данных" - выполняем задачу
Для англоязычкой версии, выполните следующие пункты:
1. Заходите в "Properties";
2. Находите в раздел "Options";
3. В пункте "Модель восстановления" выбираем "Simple"
4. Выбираем для параметра "Auto Shrink" значение "True"
5. Выбираем для параметра "Auto update statistics" значение "True"
6. Нажимаем ок и снова возвращаемся к базе данных
7. Нажимаем правой клавишей на нашей базе - "All Tasks" - > "Shrink" -> "Database" - выполняем задачу
После этого, файл с логами должен уменьшиться до 1 Мб.
P.S. Если вам помогла статья, помогите и вы нам либо комментарием под ней либо поделитесь ссылочкой на нее.
P.S.S. Если у вас возникли проблемы с техникой воспользуйтесь услугой ремонт компьютеров, либо закажите выезд компьютерного мастера.
Если я остановлю SQL-сервер, а затем удалю файл .LDF(файл транзакций) в базу данных, что произойдет? Будет ли база данных отмечена подозрительной или SQL-сервер просто создаст новый автоматически? SQL Server 2008 R2 И размер моего .LDF файла слишком большой, поэтому как управлять им, могу ли я его сжать или удалить Plz Предложите в форме запроса
ОТВЕТЫ
Ответ 1
Вы не должны удалять какие-либо файлы базы данных, так как это может серьезно повредить вашу базу данных!
Если вам не хватает места на диске, вы можете разделить свою базу данных на несколько частей. Это можно сделать в свойствах базы данных. Таким образом, вы можете поместить каждую часть базы данных в другой объем хранилища.
Вы также можете сжать файл журнала транзакций, если вы измените режим восстановления с полного на простой, используя следующие команды:
Также возможно переключение на полное восстановление:
Обновление о SHRINKDATABASE - или что я не знал при ответе на этот вопрос:
Несмотря на то, что вышеприведенный метод избавляет от некоторого неиспользуемого пространства, он имеет некоторые серьезные недостатки в файлах базы данных (MDF) - это повредит ваши индексы, фрагментируя их, ухудшая производительность вашей базы данных. Поэтому вам нужно будет перестроить индексы впоследствии, чтобы избавиться от фрагментации, вызванной командой сокращения.
Если вы хотите сжать только файл журнала, возможно, захотите вместо этого использовать SHRINKFILE. Я скопировал этот пример из MSDN:
Ответ 2
Не рискуйте удалить файлы LDF вручную! Если вам не нужны файлы транзакций или вы хотите уменьшить их до любого выбранного вами размера, выполните следующие действия: (Обратите внимание, что это повлияет на ваши резервные копии, поэтому обязательно перед этим)
- Щелкните правой кнопкой мыши базу данных
- Выберите "Свойства"
- Перейдите на вкладку "Параметры".
- Установить модель восстановления в SIMPLE
- Затем выберите вкладку FILES
- Теперь убедитесь, что вы выбрали файл LOG и прокрутите вправо. Под заголовком "Авторазработка" щелкните точки.
- Затем отключите Autogrowth (это необязательно и ограничит дополнительный рост)
- Затем нажмите "ОК" и установите "Начальный размер" в размере, который вы хотите иметь (я установил 20 МБ).
- Нажмите "ОК", чтобы сохранить изменения.
- Затем щелкните правой кнопкой мыши DB и выберите "Tasks > Shrink > Database", нажмите OK.
- Теперь сравните размеры ваших файлов!:)
Ответ 3
Я сделал это с помощью
- Отсоедините базу данных (включая Drop Connections)
- Удалить файл *.ldf
- Прикрепите базу данных, но удалите ожидаемый файл *.ldf
Было ли это для 4 разных баз данных в SQL 2012, я должен быть одинаковым для SQL 2008
Ответ 4
Как вы можете читать комментарии, это нехорошее решение для удаления журнала. Но если вы уверены, что ничего не потеряете, вы можете просто изменить режим восстановления БД на простой, а затем использовать
DBCC shrinkdatabase ('here your database name')
чтобы очистить журнал.
Самое худшее, что вы можете сделать, это удалить файл журнала с диска. Если ваш сервер имел незавершенные транзакции в момент остановки сервера, эти транзакции не будут откатываться после перезагрузки, и вы получите поврежденные данные.
Ответ 5
Вы должны создать резервную копию своего журнала транзакций, тогда будет свободное место для его сжатия. Переход к простому режиму, а затем сокращение означает, что вы потеряете все данные транзакций, которые были бы полезны в случае восстановления.
Ответ 6
Лучший способ очистить ВСЕ файлы ldf (файлы журналов транзакций) во всех базах данных на сервере MS SQL, если все базы данных были скопированы ранее, конечно:
Иногда стоит постоянно включать MODOVER MODEL = SIMPLE в некоторые базы данных и, таким образом, раз и навсегда избавиться от проблем журнала. Особенно, когда мы резервируем данные (или сервер) ежедневно и дневные изменения, не являются критическими с точки зрения безопасности.
Есть база данных для 1С 7.7
MDF файл занимает 6 гигабайт, я так понимаю это сама база данных, а вот LDF файл занимает 8 гигабайт места, я так понимаю это лог файл какой-то, зачем он такой большой нужен? и можно ли его уменьшить?
(1) Скорее всего, база в SQL находится в режиме Full, т.е. с фиксацией всех произведенных транзаций. Переход в режим Simple приведет к тому, что в файле LDF будут находиться только незавершенные транзакции, что уменьшит размер этого файла. Модель Full позволяет восстановить состояние базы SQL на любое время, в то время, как модель Simple не позволяет этого сделать, а только восстановить базу из бэкапа. Это как бы теория в самом первом приближении. Теперь по делу. Перевести базу в модель восстановления Simple (при этом настроить механизм создания беэкапов базы, если этого до сих пор не сделано). Эту операцию можно делать "на ходу". Однако, перевод в simple автоматически не уменьшает размер файла транзакций. Можно, провести операцию shrink (сжатие базы) сразу, но лучше сначала сделать полный бэкап базы средствами SQL (есть там в SQL-е по этому поводу одна маленькая хитрость), а потом сделать shrink как файлу базы MDF, так и файлу журнала транзакций LDF. Размер базы тоже должен уменьшиться, но не на много, а, вот, размер файла транзакций LDF, если было сделано все правильно, должен стать практически нулевым (в случае, когда в этом момент в базе нет активной работы пользователей). Операции бэкапа средствами SQL, и shrink-а, можно делать не выгоняя пользователей, эти операции могут, разве что, сказаться на производительности. Настоятельная рекомендация сделать резервные копии перед началом этой операции, как говорится, запас карман не тянет.
в параметрах модель восстановления стоит Полная, значит Full, там есть еще варианты "С неполным протоколированием" и "Простая".
Бекапы делается еженочно полные.
при переходе на Simple смогу ли я с ночной копии восстановить полностью работоспособную базу?
Всем привет! А у нас файлы mdf и ldf лежат вместе на одном диске (raid-1 sata). Рекомендуется их разносить. Есть raid-10 (sas) , можно туда перекинуть ldf, а будет ли заметен толк о такой процедуры, кто ощущал эффект от переноса?
как это на любое время, если я возьму остановлю сервак SQL и перенесу файлы MDF и LDF на другой комп? я что смогу восстановиться не только на данный момент, но и на вчера позавчера? хочу понять этот момент. Еще хочу понять можно ли если допусим нужно копию базы сделать, не делать выгрузку SQL и загрузку в чистую базу, а к примеру в SQL две базы рабочая и копия. Я останавливаю сервер SQL, копирую с рабочей базы файлы MDF LDF и обзываю их как копию, и после этого стартую SQL сервер, такое прокатит?
С восстановление из ночной копии и так понятно, в любом случае это будет успешно. Про запись транзакций в LDF я не совсем понимаю этого момента, а программист 1С на работе вообще этого не шарит, говорит что мое дело код писать, а твое обслуживать. Вот и пытаюсь разобраться.
(7) Kom-off,
На самом деле вообще не "любой момент" откатить БД при recovery model = Full не возможно. Есть некоторые принципиальные ограничения. Но зато, если при recovery model = Full делать бэкапы журнала транзакций, например, каждые 15 минут, то с дискретностью в 15 минут можно будет восстановиться на любое время.
Бэкап журнала транзакций выполняется намного быстрее, чем бэкап базы данных. Естественно, он занимает и меньший объем.
Отсюда вытекает и еще один метод использования. У удаленных клиентов, в процессе внедрения, мы в офис забираем по интернету полный бэкап базы ночью, а каждые полчаса (или 15 минту) - бэкап журнала транзакций. Таким образом имеем в офисе всегда практически актуальную копию БД клиента. Особенно актуально это оказалось, для клиента на Камчатке. Туда через терминальный клиент ходит уж точно не для слабонервныйх - пинг до трех секунд.
(6) "если я возьму остановлю сервак SQL и перенесу файлы MDF и LDF на другой комп? я что смогу восстановиться не только на данный момент, но и на вчера позавчера? хочу понять этот момент".
Нет.
Вы должны делать кроме бекапа базы еще бекапы логов. Например, каждые 15 минут.
Тогда, имея полный бекап базы и цепочку логов после, Вы можете восстановить базу на любой момент в интервале между полным бекапом базы и последним бекапом логов.
Кстати, при регулярных бекапах лога бесконтрольный рост его прекращается.
штатная процедура чистки логов - в MS SQL Server Management Studio Express создаем новый запрос к требуемой базе
BACKUP LOG [kk_smb] WITH TRUNCATE_ONLY
DBCC SHRINKFILE(2, TRUNCATEONLY)
,где kk_smb - имя вашей базы
У нас такое прокатывает на sql базе 1с 7.7 торговля(лог файл с 10Гб урезается до 10Мб). Каким образом почистить логи sql базы 1с 8.1 бухгалтерия(при выполнении запроса указанного выше лог файл уменьшается всего на несколько МБ)?
Это не "вариант", а "шринк лога" в SQL 2008.
Соответственно, первый вариант не работает во втором случае, а второй - бессмысленен в первом случае.
откатиться можно на любое указанное время, если оно покрывается логами транзакций, с точностью до секунды.
ShrinkDatabase вам в помощь. А вообще, вопрос достаточно избитый уже, логи растут только от кривизны настройки SQL сервера.
Как вариант можно использовать вот такой скрипт.
USE ;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE
SET RECOVERY FULL;
GO
Если не охота париться с запросами можно сделать через гуй.Это если кто не умеет строить запросы :). правой кнопкой на базе, задачи, шринк, файлы, выбираем лог (там сразу видно на сколько процентов можно уменьшить). Иногда, если лог большой - например гигов 50, то уменьшать (шринкать) его надо 2 раза - с первого раза уменьшаеться, но не полностью.
вот так вот :).
а еще хочу спросить в этой теме, чтобы новую не создавать.
Когда много человек работает процесс sqlserv.exe разростается до 6 гиг, при этом когда все из базы выходят, то он таким и остается. Он и не должен уменьшаться: ведь когда никто не работает зачем ему занимать 6 гиг оперативы
Размер процесса сервера, если его рост не ограничен настройками ( ну и естественно физическим объЁмом памяти ;) ) будет примерно равен совокупному размеру мдф файлов всех используемых баз. После этого рост процесса прекратится а вот уменьшаться он сам по себе без ребута не будет. Из вышеперечесленого могу еще добавить что при там размере лдф файла сиквел скорее всего для него установит автоматом и соответствующий минимальный размер, поэтому не удивляйтесь если после шринка 8гб файла он станет скажем 6Гб, просто измените мин размер файла и опять сделайте шринкдб.
Поправка к DBCC SHRINKFILE (_Log, 1); тет не _Log а имя файла лога а оно может и отличаться.
я только сейчас заметил что в свойствах базы в настройках лога, где выставляется размер увеличения есть пункт "Ограничение размера файла" равный 2097152 мб. Причем на старом сервере он такой
я только сейчас заметил что в свойствах базы в настройках лога, где выставляется размер увеличения есть пункт "Ограничение размера файла" равный 2097152 мб. Причем на старом сервере такой же пункт есть и там лог файл как раз 2 гига, а на новом сервере смотрю стоит такая же опция но размер лога 6 гигов.
(19) 2 097 152 мб это не 2 гига! а 2 000 Гб (т.е. без ограничений!)
ограничивать log-файл НЕЛЬЗЯ!
при достижении выбранного размера 2048 Мб (2 Гб) - база просто "встанет" и ничего не даст делать!
надо просто делать shrink. периодически руками или по регл.заданию
MSQL 2012 щелкнул на базу затем сжать выбрал лог файл и все сжалось до 1 мб с 99Гигов модель базы Simpl бекап делаю ежечастно в одно место и еженочно в другое
Тут без проблем настраивается всё, что нужно.
"Ограничение размера файла" равный 2097152 мб. Причем на старом сервере такой же пункт есть и там лог файл как раз 2 гига, а на новом сервере смотрю стоит такая же опция но размер лога 6 гигов.
Может я ошибаюсь, но мне кажется что 2097152 мб = 2 Терабайта.
У меня тоже стоит такая же опция причем я не могу её изменить может может потому что не owner, (пароль ownera благополучно утерян), но другие операции над базой делает-же. еще не разобрался. А лог шринканул с 300 до 30 Гб. провел реиндексацию таблиц - размеры не изменились, что очень странно. потому что после шринка вернул обратно из Simple в Full.
База(mdf-файл) 45 ГБ. причем реально файловая копия выгруженая из ДТ-архива весит около 20 ГБ.
до 45 выросла после заливки поверх имеющийся базы из ДТ-файла.
Вопрос что нужно сделать чтоб вернуть размер обратно к 20 Гб. (кроме загрузки ДТ-шника в свежесозданную базу SQL - это на крайний случай (неохота бегать по пользователям и перенастраивать подключение))
Когда при подключении к базе 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 здесь не рассматривается!
Специальные предложения
(0) а зачем возвращать в состояние "Полная"?
Можно оставаться на Простой и рассчитывать только на бэкапы.
(1) Полная более гибкая. А для больших баз еще и быстрая: с одной стороны можно обеспечить маленькие интервалы восстановления, с другой быстрый бэкап в рабочее время.
(2) aspirator23,
Полный бред! Не видела ни разу ни одной фирмы, где в течение дня начинали восстанавливать бакап, а потом еще пол-дня чесали репу, какие доки/транзашки были сделаны, а какие нет(учитывая, что 30-50тичисленное стадо манагеров постоянно разбредается и никого не собрать по тубзикам-курилкам, чтобы выяснить где был реал-тайм).
Выводы: простой режим восстановления, ночной бакап + в обед, если уж так плющит(видела в одной конторке, где сотрудников принудительно выгоняют на хавчик из офиса и базы) и получасовые снапшоты, если уж совсем фобия.
ние дня начинали восстанавливать бакап, а потом еще пол-дня чесали репу, какие доки/транзашки были сделаны, а какие нет(учитывая, что 30-50тичисленное стадо манагеров постоянно разбредается и никого не собрать по тубзикам-курилкам, чтобы выяснить где был реал-тайм).
Выводы: простой режим восстановления, ночной бакап + в обед,
(46)
Мне казалось, что здесь идет около1С'ный тред, а не за банковскую, биллинговую, провайдерскую или какую-то еще сферу, где критически важны состояния баз данных на сотые доли секунды. В конце концов, я совершенно не представляю, что в хозяйстве, скажем, Грефа, администраторы БД режут логи.
ЗЫ. можно не вступать в дискуссию. просто мысли вслух. Всех благ.
у меня есть конкретный 1сный кейс где идет реплицирование транзакций на резервную ноду, восстановление при отказе порядка 2х минут, вариант отката на утро совсем не приемлем, так как к середине дня будет потеряно около 800 документов.
(48)
Не, не, не. Я не попадусь на вашу уловку безотказных кластеров, мирроринга и т.п. :)
Как говорится, это совсем другая история.
(6)
Несколько раз были случаи, когда главные бухгалтера ошибочно портили данные - перезакрывали закрытый месяц, удаляли документы в закрытом периоде. Вот тут и пригождались почасовые бэкапы. Благо места занимают мало.
(50)
Ну, не знаю. Удалять документы в закрытом - запрет редактирования. В конце концов, повторюсь, проще делать снапшоты пока главбуня развлекается с ограниченным периодом полураспада(жизни)
(13) Важное замечание сделал(11).
1.Насчет того что "разрастается лог, который часто занимает весь диск" - это не обсуждаем.
SQL сервер тоже нужно настраивать, а не просто поставить по умолчанию.
2."предпочтительно использовать именно простую модель, с каждодневным бакапом" - я уже писал, что простая модель хороша для небольших баз. А также в случае если требования по восстановлению
никто не заявляет. А вот если заявляет и база большая, то простой моделью не выкрутишься.
Либо не обеспечишь нормальную периодичность восстановления, либо если обеспечишь, то тогда база будет ложиться
в момент выполнения полного бэкапа при простой модели.
- я уже писал, что простая модель хороша для небольших баз. А также в случае если требования по восстановлению
никто не заявляет.
Простая модель хороша для любых баз (и больших и не больших), если нет требований по восстановлению на любой момент времени.
Отчего же не обсуждаем? Вы знакомы с проблемой "база загружена не полностью" и её причиной?
(21) МихаилМ,
как бы работа самой базы? Наставляемые обновления? Изменения в конфе? Нет?
Это все не приводит к увеличению лога?
(3) batan, данная процедура нужна в том случае, если логи сильно разрастаются. Было у меня на практике, когда нерадивые сисадмины не следили за логами и они разрастались до размеров нескольких сотен ГБ (240 Гб если быть точным, был и в 70 Гб). Поэтому и приходилось выполнять такие манипуляции.
(5) То что написано делается без "выгоняния" пользователей.
(6) Попробуйте поработать с большими базами данных. Тогда и опыт появился бы и понимание как это работает.
То что вы не видели, не означает, что у всех также.
если про "Усечь журнал транзакций" в 2012 - то он не всегда отрабатывает. А лог нужно урезать обязательно.
(5) caponid,
Когда у вас будут вводить по десятку документов в секунду, тогда и оцените восстановление на любой момент времени.
(9) dvv01,
А потому, что принудительно лог очищается ВСЕГДА. А не как придется в случае автошринка при выгрузке.
А есть случаи, когда нужно обрезать только лог, без бэкапа.
делаем то же самое. работает на 100%. Выгонять пользователей не нужно. Место на диске за 3 минуты освобождается.
На одной из картинок в параметрах есть такое свойство как "автоматическое сжатие = FALSE".
А почему сразу его не поставить в TRUE? И забыть про все вышеописанное?
(9) dvv01, можно даже настроить, чтобы с логом вообще проблем не было, но в данном примере рассмотрено как это можно сделать просто и быстро
Вредительская статья. Уходить на простую модель без предварительного полного бэкапа - мягко говоря опрометчиво. Ну в общем то и формулировка задачи странная. Проще 1 раз настроить задания по созданию бэкапов и обрезанию логов (о боже с запросами, да да) и забыть об этом.
criptid; Areal; Gang031; Andre_ultra; nvv1970; msvd; DmitrySinichnikov; alest; Дмитрий74Чел; tehas; DissideNtAGiTatoR; randa; Den_D; + 13 – 3 Ответить
Автор забыл добавить что после обратного перехода на полную модель нужно собственно сделать полный бэкап, так как он предыдущими действиями прервал цепочку восстановления, соответственно если есть задания по бэкапу оно не будет выполнятся, пока не пройдет новый фул бэкап.
Метод описанный в статье имеет право на жизнь, но лучше все изначально грамотно спроектировать, что бы проблема с "внезапно" выросшим журналом не было в принципе.
(11) Babuin, по-поводу полного бэкапа добавлю. А вот насчет настройки - это отдельная тема. Я лишь показал, как по-быстрому место освободить. У самого базы висят и все настроено. Так что настройку тут не рассматриваю.
(11) Внезапно выросший журнал, говорите? Легко!
Работает всё давно. Клиент без обслуживания админом, зовёт раз в пятилетку на проблемы. И тут решает он переработать каталог. И в течении двух недель его активной деятельности шлёпаются изменения по паре гигов в час. Внезапно диск под архивы заканчивается и покуда никто за этим не следит, следом, так же внезапно заканчивается и место на диске с логами. И всё. Ничего никуда не едет. Вот теперь можно и админа звать )))
Идея неплоха, но в заголовке статьи не хватает надписи "в экстренном случае" или "когда штатные средства не позволяют"
Действительно, бывают запущенные ситуации, когда с логом уже ничего сделать нельзя (ни бэкап, ни шринк).
Я правильно понимаю, что эта операция поможет в случае, когда на диске уже почти не осталось свободного места?
(12) bforce, дельное замечание по-поводу названия. Да, когда места нет, а его нужно срочно освободить.
Я обычно делаю скриптом. Быстрее получается.
Также можно настроить выполнение по расписанию.
без предварительного выяснения, почему увеличился размер transaction log,
нет смысла его усекать. втом числе и автоусекать.
У меня база 90 Гб. В режиме Siple, ибо то что делают юзеры и программеры с базой часто в модели Full увеличивало базу раз в 5. Даже в Siple модели лог увеличивается, если есть большое количество изменений (15-30 Гб бывает).
Для откатов, делаете дифференцированные бекапы базы в продолжении для (периодичность скажем час) и всё что нужно есть.
Шринк да базе 90 Гб при полной модели при робочих юзерах (лог файл 50-150 Гб) нивжизнь не пройдёт, или будет делаться очень долго. Так как при полной модели в основной базе ещё нет изменений, которые хранятся в лог-файле, а если юзера работают с данными, изменения по которым должны быть записаны. Ну и немаловажный факт - количество юзеров. У меня их за 100 одновременно работающих. Транзакции никто таки не отменял.
Как одноразовая мера, чтобы если база выжрала всё место на диске и отказывается работать, вполне оно. Все равно никто работать уже не будет. Тогда да, это самый эффективный вариант.
(23) echo77, не захотел создавать тестовую базу вот на ней и показал. Действительно, нужно будет изменить скрины.
как раз такая ситуация пришла. База была брошена, франчи установили, уехали и никому до неё не было дела - никакого бэкапа - так иногда только 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.
Рецепт используем столько раз, сколько потребуется.
Зачем используете ПОЛНУЮ модель, если шринкуете транзакционный лог? НУ да ладно это другая тема, а по этой можно просто выполнить запрос (Для примера имя БД "Base"):
Спасибо автору реально помогло. Такой вопрос а где можно почитать по поводу настройки SQL сервера поделитесь ссылками )))
Вчера столкнулись с проблемой большого лога. Спасибо автору, статья полезная. Мне не понятно одно, 1С Сервер может вопрос логов как-то регулировать?
1С вообще практически ничего не может на SQL. SQL-сервер - он сам по себе, и сам управляет своими логами.
Из всего сказанного и из комментариев я что то не совсем понял. Если мы используем полную модель восстановления, сделали полный бэкап, обрезали лог базы, и если вдруг понадобиться восстановиться из бэкапа, то ничего не получиться?
все получится - восстановится на момент бекапа полностью.
Полная же модель подразумевает - восстановление на любой момент времени, что невозможно, если данные транзакций уничтожены (лог транзакций стерт). Поэтому его в таком случае не трут, а также бэкапят вместе с базой. Но это именно для тех, кто понимает, что ему нужно. Для остальных - SIMPLE режим :)
Из всего сказанного и из комментариев я что то не совсем понял. Если мы используем полную модель восстановления, сделали полный бэкап, обрезали лог базы, и если вдруг понадобиться восстановиться из бэкапа, то ничего не получиться?
При полной модели восстановления бэкапы делаются так часто как это возможно для того чтобы процесс восстановления начинать не с испокон веков существования базы а с последнего полного созданного бэкапа + далее накатывают после этого бэкапы логов транзакций. это очень удобно хотя на практике приходилось пользоваться всего пару раз в жизни. У нас например это раз в неделю по четвергам (самое оптимальное время исходя из всех регламентов скуля + сервера 1С).
При простой модели вы сможете восстановить базу только на момент последнего созданного бэкапа.
Если у вас есть нормальное ПО по управлению бэкапами и логами ТЗ (хотя все это можно написать и на SQL) то делается просто.
Полная модель. Создается бэкап базы, хранится, далее бэкапятся логи раз в нужное вам время у нас это 15 минут, логи тоже хранятся, но каждый раз когда проходит полный бэкап базы НОРМАЛЬНО все старые бэкапы базы и логов трутся и начинается новый отсчет времени. Ну и так же настроено месячное хранение базы полугодичное и годовалое которые хранятся отдельно и трутся соответственно когда создаются подобные бэкапы.
При полной модели и наших настройках мы можем восстановить базу максимум с недельной давностью, далее все остальное накатить логами.
Так же мы можем восстановить базу на начало месяца, начало полугодия и начало года но уже без логов транзакций.
Насчет тормозов не могу согласиться с предыдущими ораторами о том что простая модель работает быстрее, они работают одинаково если нормально настрое сервер SQL, просто лог транзакций должен по умолчанию лежать на другом зеркале, отдельно от того зеркала где располагается база. Много раз проверяли что так что так работает одинаково. Если же логи транзакций лежат на том же массиве что и база - безусловно будет работать медленнее.
Читайте также: