none
Огромный лог RRS feed

  • Вопрос

  • SQL 2008 r2 

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

    Тут такая ситуация, лог базы за несколько дней вырос до максимального значения, заполнил весь диск. То есть на диске место в 0... Сама база вести около 2гб, а лог 100гб с лишнем ... Мне бы как то ужать это лог...

    Я понимаю что нужно сделать бекап базы, но диск заполнен... База критична к работе... ТО бишь выключать её крайне не желательно... Может поможете советом... 

    28 ноября 2011 г. 9:47

Ответы

  • Скриншот мой.


    Упс... Однако, если бы реально было 0%, сервер не разрешил бы транзакции к базе. Похоже, не установлены патчи и в окошке брехня. Давайте попросим автора вопроса выполнить в контексте его базы даных этот сценарий:

    SELECT s.physical_name AS [Путь и имя к файлу журнала]
    	,  (s.size * CONVERT(float,8))/1024 AS [Размер файла в Мб]
    	,  (CAST(FILEPROPERTY(s.name, 'SpaceUsed') AS float)* CONVERT(float,8))/1024 AS [Использовано Мб]
    FROM   sys.master_files AS s
    WHERE (s.type = 1 and s.database_id = db_id())
    

    Результат, как водится встудию :)

     

    • Помечено в качестве ответа Dmitry Davydov 9 декабря 2011 г. 12:44
    29 ноября 2011 г. 10:19
  • Что и следовало доказать :)

    Файл 114182 Мб
    Занято  14136 Мб

    Т.о. почти весь файл пустой, можно не переживать, что пользователи будут отваливаться и дотерьпеть до следующего даунтайма...

    • Помечено в качестве ответа Dmitry Davydov 9 декабря 2011 г. 12:44
    29 ноября 2011 г. 10:50
  • Че делать то вообщем ...

    Поправте меня:

    1. Переводу базув симпл

     

    ALTER DATABASE EOMDB

    SET RECOVERY SIMPLE 

    2. Стараюсь делать шрик

    DBCC SHRINKFILE (EOMDB_log, 1000); 

    3. Если не получается, отключа сервер засовываю в него еще винт... и чего мне надо расширить партицию за счет диск, я правда не догоняю как я С-то расширю... Динамический диск и мапить папку data?

    4. Бекап

    5. Если это не получается , то отмаплю базу

    6. Удалю лог

    7. Маплю база заного, создаю новый лог...

    Все верно? 

     

    между 1 и 2 не забудьте CHECKPOINT

    Убедитесь, что ваш дисковый контроллер позволяет добавлять диски в существующий массив. Например, если диск С это RAID1, вам потребуется добавить в массив ещё 2 диска, тогда он превратиться в RAID10. Увеличить раздел позволяет команда DISKPART.

    Если вы собираетесь делать резервную копию базы, то сделайте её перед шагом 1. Копии журнала невозможны в простой модели...

    Файл журнала не удаляйте, а переместите в другое место (на всякий случай).

    Прикремление фалов делайте через CRESTE DATABASE...

     

    • Помечено в качестве ответа Dmitry Davydov 9 декабря 2011 г. 12:44
    29 ноября 2011 г. 11:15
  • Сегодня проверил ситуацию с полным отсутствием места на диске логов. По предложенному алгоритму все отработало.

    Александр Гладченко, к сожалению, без разбора зеркала так и не удалось подрезать файл журнала. Данная процедура точно должна работать в режиме зеркального отображения БД?

    • Помечено в качестве ответа Dmitry Davydov 9 декабря 2011 г. 12:44
    2 декабря 2011 г. 11:22

Все ответы

  • Можно попробовать изменить Recovery Model с Full на Simple

    Хотя не уверен, что это освободит логи.


    Innovation distinguishes between a leader and a follower - Steve Jobs
    28 ноября 2011 г. 9:56
  • Большое спасибо за ответ!

    Да, я тоже подумываю так как мы не используем откаты с помощью лога, но это надо переводить базу в оффлайн что крайне не желательно... Может еще мысли будут...

    28 ноября 2011 г. 10:05
  • но это надо переводить базу в оффлайн что крайне не желательно...


    эээ...а это ещё зачем? переключаете режим в симпл и дальше работает...никакого офлайна не нужно
    http://www.t-sql.ru
    28 ноября 2011 г. 11:21
    Отвечающий
  • После перевода базы в Simple режим восстановления файлы журнала нужно будет подрезать до приемлимого размера (Shrink).
    28 ноября 2011 г. 11:25
  • Да по сути можно просто отключить базу детачем, потом удалить лог, и заатачить базу ... при этом лог создастся заного и будет пустой, при этом при детаче все изменения сохранятся в базе... Лог будет пустой ...

    Дело в том что мне бы на лету при работающей базе это сделать ... 

    Еще путь есть это подключить диск и сделать бекап на это диск, но опять надо отключить базу...

    Тут КРИТИЧЕСКИ что бы база работала! может скрипт какой вот я тут набросал посмотрите сработает ли это?*!

    ALTER DATABASE EOMDB

    SET RECOVERY SIMPLE 

    DBCC SHRINKFILE (EOMDB_log, 1000); 

    ALTER DATABASE EOMDB SET RECOVERY FULL

    28 ноября 2011 г. 11:34
  • но это надо переводить базу в оффлайн что крайне не желательно...


    эээ...а это ещё зачем? переключаете режим в симпл и дальше работает...никакого офлайна не нужно
    http://www.t-sql.ru
    По подробнее
    28 ноября 2011 г. 11:38
  • Да хотел бы заменить что у меня база в зеркале ... Как это может повлиять?! 
    28 ноября 2011 г. 11:40
  • Так с этого надо было начинать!!!

    1. Разбираете зеркало

    2. Удаляете вторую, зеркалирующую базу (проверяете что файлы удалились)

    3. Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).

    4. Делаете Shrink файла журнала

    5. Включаете Full режим восстановления

    6. Делаете полную резервную копию базы и резервную копию лога

    7. Восстанавливаете базу на втором, зеркалирующем сервере

    8. Собираете зеркало.

    А теперь ОБЯЗАТЕЛЬНО настраиваете регулярное полное резервное копирование базы!

    28 ноября 2011 г. 11:51
  • Александр, спасибо за ответ.

    Бекап базы делается регулярно... каждые 15 минут.

    Шринк сделать не удается места нету... на диск 0 мб...

    С 6 пункта:

    Сделать бекап базы .. место нет на диске... 

    То есть в любом случае нужно будет планировать отключать базу?


    • Изменено butunin 28 ноября 2011 г. 11:57
    28 ноября 2011 г. 11:55
  • Нет. Можно на время снятия резервынх копий и настройки зеркалирования ограничить доступ пользователей в базу

    Зеркалирование в режиме восстановения Simple невозможно


    Innovation distinguishes between a leader and a follower - Steve Jobs
    28 ноября 2011 г. 12:24
  • Каким образом делается резервное копирование? Судя по размеру лога - резервное копирование не происходит.

    Если честно, с 0 МБ не сталкивался, но с 70МБ - Shrink прекрасно сработал. Вы попробовали пройти по шагам? Какие ошбки выдает?

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

    28 ноября 2011 г. 12:34
  • Нет. Можно на время снятия резервынх копий и настройки зеркалирования ограничить доступ пользователей в базу

    Зеркалирование в режиме восстановения Simple невозможно


    Innovation distinguishes between a leader and a follower - Steve Jobs
    Благодарю, поясните что такое ограничить доступ к базе ... 
    28 ноября 2011 г. 12:34
  • Каким образом делается резервное копирование? Судя по размеру лога - резервное копирование не происходит.

    Если честно, с 0 МБ не сталкивался, но с 70МБ - Shrink прекрасно сработал. Вы попробовали пройти по шагам? Какие ошбки выдает?

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

    да не че не происходить жму, сжать - файлы журнала - ОК

    Окно закрывается и все... в логах все пусто ... (?)

    28 ноября 2011 г. 12:56
  • Так?


    28 ноября 2011 г. 13:13
  • Все верно! Так и делаю.

    База в зеркале может из-за этого не работает шринк?! 

     

    • Изменено butunin 28 ноября 2011 г. 13:24
    28 ноября 2011 г. 13:20
  • Вы внимательно читали мой пост?

    1. Разбираете зеркало

    ...

    3. Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).

    4. Делаете Shrink файла журнала

    28 ноября 2011 г. 13:25
  • Вы внимательно читали мой пост?

    1. Разбираете зеркало

    ...

    3. Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).

    4. Делаете Shrink файла журнала

    Александр, я бы хотел уточнить... и дополнить вопрос.

    >1. Разбираете зеркало

    Повлияет ли это на работу базы (клиенты во время разбития зеркала, и после разбития будут ли работать с этой базой)

    Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).

    Места нет ... 0мб свободно на диске... Куда его делать в сеть сделать нельзя SQL не позволяется сохранять бекапы на сетевой ресурс. (как сделать бекап на сетевой диск)

     

    28 ноября 2011 г. 13:35
  • 1. Пользователи работают с активной копией базы, соответственно - нет, не повлияет.

    2. или переводите базу в Simple режим восстановления (не правильное).

    28 ноября 2011 г. 13:38
  • SQL 2008 r2 

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

    Тут такая ситуация, лог базы за несколько дней вырос до максимального значения, заполнил весь диск. То есть на диске место в 0... Сама база вести около 2гб, а лог 100гб с лишнем ... Мне бы как то ужать это лог...

    Я понимаю что нужно сделать бекап базы, но диск заполнен... База критична к работе... ТО бишь выключать её крайне не желательно... Может поможете советом... 


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

    Настройте резервное копирование журнала!

    Уменьшить размер журнала сможете потом, с оказией...

    28 ноября 2011 г. 13:40
  • 1. Пользователи работают с активной копией базы, соответственно - нет, не повлияет.

    2. или переводите базу в Simple режим восстановления (не правильное).

    Благодарю, какие "камни" будут при переходи в Simple mode?
    28 ноября 2011 г. 13:42
  • SQL 2008 r2 

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

    Тут такая ситуация, лог базы за несколько дней вырос до максимального значения, заполнил весь диск. То есть на диске место в 0... Сама база вести около 2гб, а лог 100гб с лишнем ... Мне бы как то ужать это лог...

    Я понимаю что нужно сделать бекап базы, но диск заполнен... База критична к работе... ТО бишь выключать её крайне не желательно... Может поможете советом... 


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

    Настройте резервное копирование журнала!

    Уменьшить размер журнала сможете потом, с оказией...

    Журнал бекапируется, были ошибки в работе программы и она послыла кучу запросов в SQL что привело за 2 дня к увеличению объема лога. (как я понял, но журнал я бекаплю)
    28 ноября 2011 г. 13:43
  • Вы утверждаете, что резервные копи создаются каждые 15 минут, мне кажется маловероятным увеличение журнала на 100ГБ за это время. Соответственно напрашивается вывод, что резервные копии либо не делаются, либо делаются некорректно. Также возможены некоторые другие варианты:

    http://msdn.microsoft.com/ru-ru/library/ms345414.aspx

    На данный момент база работает в штатном режиме? Если да, то подождите возможности обслужить базу и выполните вышеприведенную последовательность. На данном сервере расположена только эта база? Сколько места свободно в файле журнала (можно быстро посмотреть в мастере Shrink file)?


    28 ноября 2011 г. 13:56
  • Возможно, нужно чаще резервировать журнал или размер его файла недостаточен для журналировани текущих транзакций. В последнем случае, заполнение журнала чревато остановкой работы с базой пользователей. Для решения этой проблемы можно добавить ещё файлы для размещения журнала. Также, стоит исследовать код и постараться оптимизировать размер и время жизни транзакций.

    28 ноября 2011 г. 13:57
  • Вы утверждаете, что резервные копи создаются каждые 15 минут, мне кажется маловероятным увеличение журнала на 100ГБ за это время. Соответственно напрашивается вывод, что резервные копии либо не делаются, либо делаются некорректно. Также возможены некоторые другие варианты:

    http://msdn.microsoft.com/ru-ru/library/ms345414.aspx

    На данный момент база работает в штатном режиме? Если да, то подождите возможности обслужить базу и выполните вышеприведенную последовательность. На данном сервере расположена только эта база? Сколько места свободно в файле журнала (можно быстро посмотреть в мастере Shrink file)?


    Да, база бекапится каждые 15 минут. 

    База работает в штатном режиме.

    На сервере только эта база.

    (можно быстро посмотреть в мастере Shrink file)?

    Можно по подробнее

    28 ноября 2011 г. 14:19
  • Скриншот выше, поле "Available free space".

    28 ноября 2011 г. 14:35
  • А вы использовать Shrink не пробывали ? +)))))))

     

    • Предложено в качестве ответа Dalex83 28 ноября 2011 г. 14:52
    • Отменено предложение в качестве ответа Dmitry Davydov 9 декабря 2011 г. 12:35
    28 ноября 2011 г. 14:52
  • Скриншот выше, поле "Available free space".

    792,20 МБ (0 %)
    28 ноября 2011 г. 15:23
  • А вы использовать Shrink не пробывали ? +)))))))

     

    Спасибо за ответ. Побывал.
    28 ноября 2011 г. 15:23
  • Вы зеркало разобрали ?  Если да переводите Модель востановления в Simple и Шринкуйте !

    потом оборптно в full.  Если у вас растет лог тогда надо джоб поставить на шринк несколько раз в день ....

    Убидитесь что последний параметр у вас равен 0.  В меню Shirnk Action выбирите пункт - Reorganize и ставьте значение min)
    • Изменено Dalex83 29 ноября 2011 г. 5:22
    29 ноября 2011 г. 5:18
  • Коллега, не надо давать вредные советы! Какой shrink несколько раз в день?

    1. База в зеркале

    2. Даже если база не в зеркале, это приведет к дикой фрагментации базы

    29 ноября 2011 г. 6:59
  • Коллега, не надо давать вредные советы! Какой shrink несколько раз в день?

    1. База в зеркале

    2. Даже если база не в зеркале, это приведет к дикой фрагментации базы

    Естественно =)  но надо понимать что за такой мостр лог плодит... ну так тадо и план обсулживания смотреть что у него делается....

    Все от этого и плясать..

    29 ноября 2011 г. 7:03
  • Вы зеркало разобрали ?  Если да переводите Модель востановления в Simple и Шринкуйте !

    потом оборптно в full.  Если у вас растет лог тогда надо джоб поставить на шринк несколько раз в день ....

    Убидитесь что последний параметр у вас равен 0.  В меню Shirnk Action выбирите пункт - Reorganize и ставьте значение min)

    Бывает очень полезно читать предыдущие рекомендации и ответы ;)

    Ещё раз хочу повторить, что ничего страшного в том, что на диске не осталось места нет, главное, место есть внутри файла журнала транзакций. Можно просто дождаться следующего окна технического обслуживания и тогда попытаться
    уменьшить размер файла сценарием, котрый ниже:

    CHECKPOINT
    DBCC SHRINKFILE (ЛОГИЧЕСКОЕИМЯФАЙЛАЖУРНАЛАТРАНЗАКЦИЙ, 128)
    CHECKPOINT
    EXEC sp_helpfile
    
    


    Часто, забывают сделать CHECKPOINT, и оставшиеся не сброшенными на диск "грязные" страницы не дают уменьшить размер файла...

    Если не получится с первого раза, повторяйте сценарий несколько раз.

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

    Самое же просто и правильное, добавиь в массив журнала ещё шпинделей и увеличить разме партиции ;)

     

     


    29 ноября 2011 г. 7:05
  • Available free space: 792,20 МБ (0 %)

    Без очистки журнала он не сожмется.


    Однако подход правильный, возможно удастся сжать лог без разбиения зеркала.
    29 ноября 2011 г. 8:04
  • На скриншоте другие цифры...

    29 ноября 2011 г. 9:25
  • Скриншот мой.

    29 ноября 2011 г. 9:47
  • Скриншот мой.


    Упс... Однако, если бы реально было 0%, сервер не разрешил бы транзакции к базе. Похоже, не установлены патчи и в окошке брехня. Давайте попросим автора вопроса выполнить в контексте его базы даных этот сценарий:

    SELECT s.physical_name AS [Путь и имя к файлу журнала]
    	,  (s.size * CONVERT(float,8))/1024 AS [Размер файла в Мб]
    	,  (CAST(FILEPROPERTY(s.name, 'SpaceUsed') AS float)* CONVERT(float,8))/1024 AS [Использовано Мб]
    FROM   sys.master_files AS s
    WHERE (s.type = 1 and s.database_id = db_id())
    

    Результат, как водится встудию :)

     

    • Помечено в качестве ответа Dmitry Davydov 9 декабря 2011 г. 12:44
    29 ноября 2011 г. 10:19
  • Все спасибо за ответ.

    Зеркало я сегодня разбил. Базу пока не трогал, ьекапы встали пока жду точного ответа или мысли что делать... Боюсь наломать дров , уж простите меня ... 

     

    Путь и имя к файлу журнала Размер файла в Мб Использовано Мб

    C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\EOMDB_log.ldf 114182,46875 114136,390625
    • Изменено butunin 29 ноября 2011 г. 10:39
    29 ноября 2011 г. 10:32
  •  

    CHECKPOINT
    DBCC SHRINKFILE (ЛОГИЧЕСКОЕИМЯФАЙЛАЖУРНАЛАТРАНЗАКЦИЙ, 128)
    CHECKPOINT
    EXEC sp_helpfile
    
    


    Часто, забывают сделать CHECKPOINT, и оставшиеся не сброшенными на диск "грязные" страницы не дают уменьшить размер файла...

     

     

     


    Не удалось сжать файл журнала 2 (EOMDB_Log) из-за необходимого минимального пространства для журналов.
    (строк обработано: 1)
    Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.
    29 ноября 2011 г. 10:36
  • Скриншот мой.


    Упс... Однако, если бы реально было 0%, сервер не разрешил бы транзакции к базе. Похоже, не установлены патчи и в окошке брехня. Давайте попросим автора вопроса выполнить в контексте его базы даных этот сценарий:

    SELECT s.physical_name AS [Путь и имя к файлу журнала]
    	,  (s.size * CONVERT(float,8))/1024 AS [Размер файла в Мб]
    	,  (CAST(FILEPROPERTY(s.name, 'SpaceUsed') AS float)* CONVERT(float,8))/1024 AS [Использовано Мб]
    FROM   sys.master_files AS s
    WHERE (s.type = 1 and s.database_id = db_id())
    

    Результат, как водится встудию :)

     

    C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\EOMDB_log.ldf 114182,46875 114136,390625
    29 ноября 2011 г. 10:40
  • Он покажет сколько в файле журнала занято места. Есть сомнения, что у Вас в SSMS эта информация отображается верно... Это обычная выборка из системной таблицы... Ничего деструктивного ;)

    29 ноября 2011 г. 10:47
  • Че делать то вообщем ...

    Поправте меня:

    1. Переводу базув симпл

    ALTER DATABASE EOMDB

    SET RECOVERY SIMPLE 

    2. Стараюсь делать шрик

    DBCC SHRINKFILE (EOMDB_log, 1000); 

    3. Если не получается, отключа сервер засовываю в него еще винт... и чего мне надо расширить партицию за счет диск, я правда не догоняю как я С-то расширю... Динамический диск и мапить папку data?

    4. Бекап

    5. Если это не получается , то отмаплю базу

    6. Удалю лог

    7. Маплю база заного, создаю новый лог...

    Все верно? 

    29 ноября 2011 г. 10:47
  • Что и следовало доказать :)

    Файл 114182 Мб
    Занято  14136 Мб

    Т.о. почти весь файл пустой, можно не переживать, что пользователи будут отваливаться и дотерьпеть до следующего даунтайма...

    • Помечено в качестве ответа Dmitry Davydov 9 декабря 2011 г. 12:44
    29 ноября 2011 г. 10:50
  • Не удалось сжать файл журнала 2 (EOMDB_Log) из-за необходимого минимального пространства для журналов.
    (строк обработано: 1)
    Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

    Что бы впредь такое не повторялось, настраивайте автоприращение файла не так, как предложено по умолчанию. Например, задайте 128Мб (или как вендор рекомендует - 256Мб). Тогда у вас не будет ситуации, когда места на диске не остаётся. Применительно к этому случаю, если бу был хотя бы мегабайт свободен, можно было бы на него увеличить размер файла и потом выполнить шринк. Эта уловка помогает, когда файл не хочет сжиматься...
    29 ноября 2011 г. 10:55
  • Че делать то вообщем ...

    Поправте меня:

    1. Переводу базув симпл

     

    ALTER DATABASE EOMDB

    SET RECOVERY SIMPLE 

    2. Стараюсь делать шрик

    DBCC SHRINKFILE (EOMDB_log, 1000); 

    3. Если не получается, отключа сервер засовываю в него еще винт... и чего мне надо расширить партицию за счет диск, я правда не догоняю как я С-то расширю... Динамический диск и мапить папку data?

    4. Бекап

    5. Если это не получается , то отмаплю базу

    6. Удалю лог

    7. Маплю база заного, создаю новый лог...

    Все верно? 

     

    между 1 и 2 не забудьте CHECKPOINT

    Убедитесь, что ваш дисковый контроллер позволяет добавлять диски в существующий массив. Например, если диск С это RAID1, вам потребуется добавить в массив ещё 2 диска, тогда он превратиться в RAID10. Увеличить раздел позволяет команда DISKPART.

    Если вы собираетесь делать резервную копию базы, то сделайте её перед шагом 1. Копии журнала невозможны в простой модели...

    Файл журнала не удаляйте, а переместите в другое место (на всякий случай).

    Прикремление фалов делайте через CRESTE DATABASE...

     

    • Помечено в качестве ответа Dmitry Davydov 9 декабря 2011 г. 12:44
    29 ноября 2011 г. 11:15
  • Так че делать то )
    29 ноября 2011 г. 11:16
  • Если честно, не сталкивался с ситуацией полного отсутствия места на диске. На диске совсем нет мусора, который можно было бы удалить/переместить?
    29 ноября 2011 г. 13:25
  • Если честно, не сталкивался с ситуацией полного отсутствия места на диске. На диске совсем нет мусора, который можно было бы удалить/переместить?

    Неа, система чистая стоит только SQL и один профиль ... 

     

    29 ноября 2011 г. 13:32
  • Так че делать то )

    Вначале хорошенько проштудируйте BOL, по всем перечисленным в Вашем плане пунктам. Потом следуйте плану с учётом всех замечаний, высказанных по нему и того, что прочитаете в документации.
    30 ноября 2011 г. 7:56
  • Сегодня проверил ситуацию с полным отсутствием места на диске логов. По предложенному алгоритму все отработало.

    Александр Гладченко, к сожалению, без разбора зеркала так и не удалось подрезать файл журнала. Данная процедура точно должна работать в режиме зеркального отображения БД?

    • Помечено в качестве ответа Dmitry Davydov 9 декабря 2011 г. 12:44
    2 декабря 2011 г. 11:22
  • Сегодня проверил ситуацию с полным отсутствием места на диске логов. По предложенному алгоритму все отработало.

    Александр Гладченко, к сожалению, без разбора зеркала так и не удалось подрезать файл журнала. Данная процедура точно должна работать в режиме зеркального отображения БД?


    Я не встречал ограничений сжатия при зеркалировании: http://msdn.microsoft.com/ru-ru/library/ms189493.aspx

    Однако, агент чтения журнала метит транзакции, которые относятся к зеркальной базе и снимает метки с LSN, которые примененены на зеркале. Это вполне может мешать сжатию, т.к. сжимается лог до первого активного LSN. Можно попробовать переключаться с асинхронного на синхронное зеркалирование и пробовать шринковать, думаю, при синхронном больше шансов для удачного шринкования, хотя не пробовал.

    А вообще, я стараюсь на журнале не экономить. Это самое чувствительное место и под него нужно много шпинделей... т.е. места на его диске много из-за большого числа шпинделей, старайтесь просто его ни под что другое не занимать. Если журнал вырастет, ну и пусть, в следующий раз не понадобится тратить ресурсы на прирост файла ;)

    2 декабря 2011 г. 12:14
  • ...вот добавление файла в базу, хоти и не ломает зеркало сразу, но нежелательная операция. После этого нужно зеркало заново пересоздавать...
    2 декабря 2011 г. 12:18
  • Согласен, шринк журнала, как и базы - опарация крайне нежелательная. Если разрослось, значит столько и надо для работы. Однако бывают ситуации когда без этого не обойтись, например, сбой резервного копирования, очумелые ручки 1Сника, выполнившего разовую загрузку в базу огромного количества информации и т.п.

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

    2 декабря 2011 г. 12:48