Журналы SQL Server 2008 R2 заполняли диск

Question

Итак, некоторые из нас, разработчики, начинают использовать некоторые из наших ящиков 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) 

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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