Файлы журнала SQL Server 2008 R2 заполнили диск

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

    USE [databaseName] 
    GO 
    DBCC SHRINKFILE('databaseName_log', 1) 
    BACKUP LOG databaseName WITH TRUNCATE_ONLY 
    DBCC SHRINKFILE('databaseName_log', 1)

и я уверен, что вы все знаете, что усечение только устарело.

Итак, решения, которые я нашел до сих пор, - это установить recovery = simple, затем сжать, а затем установить обратно ... однако это ускользнуло от нас, прежде чем мы смогли туда добраться.

Теперь у нас есть полный диск, и происходящее зеркальное отображение застряло в полузавершенном состоянии с постоянными ошибками, когда мы не можем изменить какие-либо базы данных. Мы не можем даже открыть половину из них в проводнике объектов.

Итак, прочитав об этом, способ обойти это в будущем — составить план обслуживания. (упс. :/ ), но хотя мы можем создать его, мы не можем запустить его без места на диске, а SQL Server застрял в состоянии ошибки (средство просмотра событий показывает, что он записывает ошибки около 5 в секунду ... это продолжается со вчерашнего вечера)

У кого-нибудь есть опыт в этом?


sql-server-2008-r2 shrink truncate-log database-mirroring
person Jon    schedule 01.11.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

person David    schedule 01.11.2013
comment
У меня недостаточно очков репутации, чтобы оценить это, но вы были правы, спасибо. Я волновался, к чему все идет, но у нас были резервные копии, и как только мы сломали зеркало, мы смогли адекватно уменьшить размеры файлов... они были настроены на полные резервные копии, которые нам не нужны, поэтому сейчас мы работаем над планом обслуживания, чтобы уменьшить все это.. Еще раз спасибо! - person Jon; 01.11.2013
comment
@Jon Если это ответило на ваш вопрос, вы можете пометить его как ответ. Просто помните, что если вы используете зеркалирование, вы вынуждены выполнять полное восстановление и, следовательно, должны делать эти резервные копии TLog. - person David; 01.11.2013