Уменьшить Ldf (Log) файлов в SQL Server 2005
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Скорее всего, база в SQL находится в режиме Full, т.е. с фиксацией всех произведенных транзаций. Переход в режим Simple приведет к тому, что в файле LDF будут находиться только незавершенные транзакции, что уменьшит размер этого файла. Модель Full позволяет восстановить состояние базы SQL на любое время, в то время, как модель Simple не позволяет этого сделать, а только восстановить базу из бэкапа. Это как бы теория в самом первом приближении. Теперь по делу. Перевести базу в модель восстановления Simple (при этом настроить механизм создания беэкапов базы, если этого до сих пор не сделано). Эту операцию можно делать "на ходу". Однако, перевод в simple автоматически не уменьшает размер файла транзакций. Можно, провести операцию shrink (сжатие базы) сразу, но лучше сначала сделать полный бэкап базы средствами SQL (есть там в SQL-е по этому поводу одна маленькая хитрость), а потом сделать shrink как файлу базы MDF, так и файлу журнала транзакций LDF. Размер базы тоже должен уменьшиться, но не на много, а, вот, размер файла транзакций LDF, если было сделано все правильно, должен стать практически нулевым (в случае, когда в этом момент в базе нет активной работы пользователей). Операции бэкапа средствами SQL, и shrink-а, можно делать не выгоняя пользователей, эти операции могут, разве что, сказаться на производительности. Настоятельная рекомендация сделать резервные копии перед началом этой операции, как говорится, запас карман не тянет.
в параметрах модель восстановления стоит Полная, значит Full, там есть еще варианты "С неполным протоколированием" и "Простая".
Бекапы делается еженочно полные.
при переходе на Simple смогу ли я с ночной копии восстановить полностью работоспособную базу?
Бекапы делается еженочно полные.
при переходе на Simple смогу ли я с ночной копии восстановить полностью работоспособную базу?
Всем привет! А у нас файлы mdf и ldf лежат вместе на одном диске (raid-1 sata). Рекомендуется их разносить. Есть raid-10 (sas) , можно туда перекинуть ldf, а будет ли заметен толк о такой процедуры, кто ощущал эффект от переноса?
Kom-off
погоняйте меня еще по теории, или дайте ссылку на чтиво по этому вопросу
как это на любое время, если я возьму остановлю сервак SQL и перенесу файлы MDF и LDF на другой комп? я что смогу восстановиться не только на данный момент, но и на вчера позавчера? хочу понять этот момент. Еще хочу понять можно ли если допусим нужно копию базы сделать, не делать выгрузку SQL и загрузку в чистую базу, а к примеру в SQL две базы рабочая и копия. Я останавливаю сервер SQL, копирую с рабочей базы файлы MDF LDF и обзываю их как копию, и после этого стартую SQL сервер, такое прокатит?
С восстановление из ночной копии и так понятно, в любом случае это будет успешно. Про запись транзакций в LDF я не совсем понимаю этого момента, а программист 1С на работе вообще этого не шарит, говорит что мое дело код писать, а твое обслуживать. Вот и пытаюсь разобраться.
погоняйте меня еще по теории, или дайте ссылку на чтиво по этому вопросу
Модель Full позволяет восстановить состояние базы SQL на любое время
как это на любое время, если я возьму остановлю сервак SQL и перенесу файлы MDF и LDF на другой комп? я что смогу восстановиться не только на данный момент, но и на вчера позавчера? хочу понять этот момент. Еще хочу понять можно ли если допусим нужно копию базы сделать, не делать выгрузку SQL и загрузку в чистую базу, а к примеру в SQL две базы рабочая и копия. Я останавливаю сервер SQL, копирую с рабочей базы файлы MDF LDF и обзываю их как копию, и после этого стартую SQL сервер, такое прокатит?
С восстановление из ночной копии и так понятно, в любом случае это будет успешно. Про запись транзакций в LDF я не совсем понимаю этого момента, а программист 1С на работе вообще этого не шарит, говорит что мое дело код писать, а твое обслуживать. Вот и пытаюсь разобраться.
(6) Смысл модели Full в том, что в журнал транзакций LDF записываются ВСЕ транзакции и там остаются, ну до определенного времени, например, до операции shrink. Таким образом SQL последовательным откатом транзакций назад может восстановить состояние базы на любой момент времени периода записанных в LDF транзакций. Хочу сказать, что сам ни разу не пользовался такой возможностью и людей, которые бы ею пользовались не встречал, хотя, наверняка, есть такие. Вопросы по SQL лучше задавать не здесь а на .
(7) Kom-off,
На самом деле вообще не "любой момент" откатить БД при recovery model = Full не возможно. Есть некоторые принципиальные ограничения. Но зато, если при recovery model = Full делать бэкапы журнала транзакций, например, каждые 15 минут, то с дискретностью в 15 минут можно будет восстановиться на любое время.
Бэкап журнала транзакций выполняется намного быстрее, чем бэкап базы данных. Естественно, он занимает и меньший объем.
Отсюда вытекает и еще один метод использования. У удаленных клиентов, в процессе внедрения, мы в офис забираем по интернету полный бэкап базы ночью, а каждые полчаса (или 15 минту) - бэкап журнала транзакций. Таким образом имеем в офисе всегда практически актуальную копию БД клиента. Особенно актуально это оказалось, для клиента на Камчатке. Туда через терминальный клиент ходит уж точно не для слабонервныйх - пинг до трех секунд.
На самом деле вообще не "любой момент" откатить БД при recovery model = Full не возможно. Есть некоторые принципиальные ограничения. Но зато, если при recovery model = Full делать бэкапы журнала транзакций, например, каждые 15 минут, то с дискретностью в 15 минут можно будет восстановиться на любое время.
Бэкап журнала транзакций выполняется намного быстрее, чем бэкап базы данных. Естественно, он занимает и меньший объем.
Отсюда вытекает и еще один метод использования. У удаленных клиентов, в процессе внедрения, мы в офис забираем по интернету полный бэкап базы ночью, а каждые полчаса (или 15 минту) - бэкап журнала транзакций. Таким образом имеем в офисе всегда практически актуальную копию БД клиента. Особенно актуально это оказалось, для клиента на Камчатке. Туда через терминальный клиент ходит уж точно не для слабонервныйх - пинг до трех секунд.
(6) "если я возьму остановлю сервак SQL и перенесу файлы MDF и LDF на другой комп? я что смогу восстановиться не только на данный момент, но и на вчера позавчера? хочу понять этот момент".
Нет.
Вы должны делать кроме бекапа базы еще бекапы логов. Например, каждые 15 минут.
Тогда, имея полный бекап базы и цепочку логов после, Вы можете восстановить базу на любой момент в интервале между полным бекапом базы и последним бекапом логов.
Кстати, при регулярных бекапах лога бесконтрольный рост его прекращается.
Нет.
Вы должны делать кроме бекапа базы еще бекапы логов. Например, каждые 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 бухгалтерия(при выполнении запроса указанного выше лог файл уменьшается всего на несколько МБ)?
BACKUP LOG [kk_smb] WITH TRUNCATE_ONLY
DBCC SHRINKFILE(2, TRUNCATEONLY)
,где kk_smb - имя вашей базы
У нас такое прокатывает на sql базе 1с 7.7 торговля(лог файл с 10Гб урезается до 10Мб). Каким образом почистить логи sql базы 1с 8.1 бухгалтерия(при выполнении запроса указанного выше лог файл уменьшается всего на несколько МБ)?
Как вариант можно использовать вот такой скрипт.
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
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 гиг оперативы
Когда много человек работает процесс sqlserv.exe разростается до 6 гиг, при этом когда все из базы выходят, то он таким и остается. Он и не должен уменьшаться: ведь когда никто не работает зачем ему занимать 6 гиг оперативы
Размер процесса сервера, если его рост не ограничен настройками ( ну и естественно физическим объЁмом памяти ;) ) будет примерно равен совокупному размеру мдф файлов всех используемых баз. После этого рост процесса прекратится а вот уменьшаться он сам по себе без ребута не будет. Из вышеперечесленого могу еще добавить что при там размере лдф файла сиквел скорее всего для него установит автоматом и соответствующий минимальный размер, поэтому не удивляйтесь если после шринка 8гб файла он станет скажем 6Гб, просто измените мин размер файла и опять сделайте шринкдб.
Поправка к DBCC SHRINKFILE (<Логическое_имя_базы>_Log, 1); тет не <Логическое_имя_базы>_Log а имя файла лога а оно может и отличаться.
Поправка к DBCC SHRINKFILE (<Логическое_имя_базы>_Log, 1); тет не <Логическое_имя_базы>_Log а имя файла лога а оно может и отличаться.
я только сейчас заметил что в свойствах базы в настройках лога, где выставляется размер увеличения есть пункт "Ограничение размера файла" равный 2097152 мб. Причем на старом сервере такой же пункт есть и там лог файл как раз 2 гига, а на новом сервере смотрю стоит такая же опция но размер лога 6 гигов.
(19) 2 097 152 мб это не 2 гига! а 2 000 Гб (т.е. без ограничений!)
ограничивать log-файл НЕЛЬЗЯ!
при достижении выбранного размера 2048 Мб (2 Гб) - база просто "встанет" и ничего не даст делать!
надо просто делать shrink... периодически руками или по регл.заданию
ограничивать log-файл НЕЛЬЗЯ!
при достижении выбранного размера 2048 Мб (2 Гб) - база просто "встанет" и ничего не даст делать!
надо просто делать shrink... периодически руками или по регл.заданию
1Скрипт-менеджер - простая конфигурация для 1С:Предприятие 8.2., позволяющая просто и эффективно решить насущные задачи, связанные с обслуживанием баз данных в большинстве организаций, использующих MSSQL, в том числе и бесплатную версию Express, не имеющую встроенных средств для настройки обслуживания.
Весь процесс настройки и установки занимает 15 минут!
Сайт продукта:
Тут без проблем настраивается всё, что нужно.
Весь процесс настройки и установки занимает 15 минут!
Сайт продукта:
Тут без проблем настраивается всё, что нужно.
"Ограничение размера файла" равный 2097152 мб. Причем на старом сервере такой же пункт есть и там лог файл как раз 2 гига, а на новом сервере смотрю стоит такая же опция но размер лога 6 гигов.
Может я ошибаюсь, но мне кажется что 2097152 мб = 2 Терабайта.
У меня тоже стоит такая же опция причем я не могу её изменить может может потому что не owner, (пароль ownera благополучно утерян), но другие операции над базой делает-же.??? еще не разобрался. А лог шринканул с 300 до 30 Гб. провел реиндексацию таблиц - размеры не изменились, что очень странно??? потому что после шринка вернул обратно из Simple в Full.
База(mdf-файл) 45 ГБ. причем реально файловая копия выгруженая из ДТ-архива весит около 20 ГБ.
до 45 выросла после заливки поверх имеющийся базы из ДТ-файла.
Вопрос что нужно сделать чтоб вернуть размер обратно к 20 Гб. (кроме загрузки ДТ-шника в свежесозданную базу SQL - это на крайний случай (неохота бегать по пользователям и перенастраивать подключение))
И еще вопрос чтобы тему новую не создавать.
Для экспериментов создал на SQL 2005 базу с помощью 1С. Потом Её удалил чеерез SQL manager studio и теперь не создается база с таким же именем. Где это все можно очистить? возможно криво удалил. - Как исправить??
Вот ошибка:
________________________________________________________
Ошибка при создании информационной базы:
Ошибка при выполнении операции с информационной базой
Ошибка СУБД:
Microsoft SQL Native Client: Login failed for user 'SA1'.
HRESULT=80040E4D, SQLSrvr: SQLSTATE=28000? state=1? Severity=E, Native=18456, line=1
____________________________________________________________
базу пытаюсь создать от другого пользователя (SA2) т.к. пароль от SA1 то же утерян:)
пароль на пользователя можно изменить из консоли или если есть другой пользователь с правами "раздавать права" )) то из менедж студии в ветке безопасность.
Ошибка Серьезность Запись в журнал Описание (текст сообщения)
28000 16 Нет Непредвиденная длина расшифрованного ключа сеанса.
-
Пользователя как создавали?
Ошибка Серьезность Запись в журнал Описание (текст сообщения)
28000 16 Нет Непредвиденная длина расшифрованного ключа сеанса.
-
Пользователя как создавали?
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот