День добрый, господа

Есть MS SQL 2008, на нем размещена база 1С 8.х
Закончилось место на диске. Помогаю по телефону человеку сделать бэкап базы и сжать лог-файл. Удаленного доступа нет, прислали только два скриншота. На одном из них открыты дерево баз и свойства базы (нужная - везде закрашена черным):

http://dl.dropbox.com/u/1725496/screen.png
Внимание, вопрос. Что это и как теперь с этим жить?

Нехватает прав? Зашел он вроде бы под sa:
http://dl.dropbox.com/u/1725496/screen2.png

а темпдб не смотрел размер?

(1) спс, посмотрим
сегодня уже вряд ли
завтра с ним продолжим, хехе

ещё можно попробовать освободить немного места на диске(ах) и сразу сделать шринк базы. Если не получится, перезагрузить сервер (перезапустить sql).
Потом либо бэкапы лога транзакций настроить, либо лог перевести на модель "Простая".

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

А вот такой вопрос у меня родился:

1) если свободного места на диске с файлами базы мало (положим, менее 3 Гб)
2) файл базы весит 3 с копейками Гб
3) файл с логом - 80 Гб
То удастся ли выполнить shrink над файлом лога (интересует именно, не будет ли проблем из-за п. 1)?

Далее, если неудастся в интерфейсе что-либо сделать - то правильным ли будет выполнение такого скрипта для установки модели восстановления Простая и сжатия файла лога:
USE ИмяБазы
ALTER DATABASE ИмяБазы SET RECOVERY SIMPLE
DBCC SHRINKFILE (ИмяФайлаЛога, ЖелаемыйРазмер);
(взято отсюда: http://www.forum.mista.ru/topic.php?upd&id=451202 )
?

пип - может, у кого есть еще свежие мысли с утра

Самое банальное: выгрузи-загрузи базку... размер-то смешной

переведи базу в симпл,сделай шринк,потом обратно переведи в фул

(4) Можешь в интерфейсе ничего и не делать, скрипт сделает то что надо.
(7) зачем?

в (8) вторую часть читать как - "зачем обратно в фул переводить"? сорри, не проснулся до конца)

(9)настроят регламентные работы,базу смогут при случае восстановить на любой момент времени.Ну это конечно кому как.

(7) - спс, так и сделаем
Еще пара вопросов родились.

1) После того, как сделаю (7), хочу поставить автоматическое сжатие в свойствах базы. Будет ли оно автоматически сжимать сам файл транзакций? И допустимо ли это? Здесь, в примечании, написано, что автоматическое сжатие не рекомендуется:
http://msdn.microsoft.com/ru-ru/library/ms178037(v=sql.105).aspx
Но не написано, почему

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

(11) п.2 - сейчас максимальный размер 2048 Гб (потому и росло, видимо)

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

(10) вряд ли ему НАДО на ЛЮБОЙ момент времени... оставить в симпл, а если НАДО промежуточные, то можно дифференциалы делать...

(11) 1) автошринк будет регулярно увеличивать фрагментацию. Про него лучше читать здесь: http://msdn.microsoft.com/ru-ru/library/ms190488(v=sql.105).aspx (и там же написано почему не рекомендуется).
2) Если хочешь чтобы база данных однажды сказала - "идите к черту, писать в себя ничего не дам" - то, конечно, ставь ограничение на размер журнала транзакций.

(13) нет, само сжатие просто будет кучу i/o-операций генерировать и процессор, возможно, напрягать. А вот на время автоприращения файла БД станет недоступной на запись и если для файлов данных можно использовать Instant Initialization (http://msdn.microsoft.com/en-us/library/ms175935(v=sql.105).aspx ), то на время увеличения файла журнала транзакций, БД по-любому станет недоступной на запись.

(15)насчет сжатия - ясно

http://1c-esse.buter.ru/faq.php?pg=2

Спасибо господа, уговорил человека на модель восстановления симпл, перевел на нее. Создал еще один план обслуживания - полный ночной бэкап именной этой базы (до этого был дифференцированный бэкап всех баз, тоже по ночам).
Автоувеличение размера файла лога поставил не в процентах (стояло "10%"), а фиксированным значением, по 50 Мб.
Сделал SHRINKFILE файлу логов.
Ну и поставил максимальный размер файла логов, в 50 Гб. Хотя, имхо, с моделью восстановления симпл это не так актуально

Еще раз спасибо, лишний раз убеждаюсь, что надо теорию учить!