[kim-aa]

DoublE_zone,
1) Перед операцией застопте 1С, и вообще изгоните всех пользователей.
2) Сделайте Дамп базы - если что, вы поднимитесь с нее на любом сервере.
3) Пропорции Лог/Данные зависят от того какая у вас нагрузка.
Транзакционная (OLTP) или хранилища данных (в основном идут массовые чтения).
В 7.7 рекомендовалось соотношение один к двум.
Плохо видно, за сколько лог файл вырос до 50 Гиг, но думаю рос он достаточно долго.
Думаю вы можете ограничить Лог файл 2-мя Гигабайтами, правда еще вопрос какую политику архивации вы используете.
Т.е. размера лог-файла должно хватать на операции между двумя полными архивированиями.
Т.е. если вы полностью архивируетесь раз в неделю, то размер лог-файла нужно выбрать чтобы хватило на недельные операции (а лучше на две недели).


Т.к. вы используете 32х битную систему, я бы рекомендовал выделять файлы данных под данные и логи размером в 2GB.
Файлы лучше выделять вручную, т.е. откулючить авторасширение.

[DoublE_zone]

kim-aa, спасибо. Как созрею - обязательно попробую.

[DoublE_zone]

kim-aa, а какое действо наступает после выставления (урезания, сейчас 50Г - текущее, сделаю 10Г - max) файла транзакций логов и нажатия кнопки ОК? Файл сразу обрубится и освободит место на винтах или это длительный процесс? Нужно ли перезапускать SQL?

[kim-aa]

DoublE_zone,
По моему, сразу. Я ,честно говоря давно с MS SQL не работал, лет так восемь, и работал всегда с англоязычным окружением. По моему там это звучало как "Trunckate log"

Операция выполняется немедленно. Просто отбрасываются старые операции.

Что касаемо места на дисках, я убей бог не вспомню сейчас модель выделения места MS SQL в 2000.

В MS SQL 6.x серии были устройства данных, это собственно сами файлы хранения или неформатированные сегменты диска. Сегменты данных и сегменты логов, размещались в устройствах данных.
После обрезания сегмента логов, высвобождалось место в устройстве данных, но само файл устройства данных оставался прежним по размеру и изменить размер было возможно, но не всегда удобно
(Expand, Shrink)
Именно по этому есть рекомендации выдавать не одним файловым устройством, а кучей мелких по
2 GB (собственно так поступает Exchange, который суть изуродованный MS SQL)

В 2000 вроде бы модель хранения лог-файлов изменили, однако раз они сжимались в старой модели, то должны сжиматься и вновой.

По прежнему напоминаю, для избежания экцессов отключите все приложения от MS SQL перед операцией. Для надежности можете либо положить сетевой стек, либо просто выдернуть кабель из сервера (если вы работаете непосредственно на сервере)

[DoublE_zone]

kim-aa, было решено на ближайших регламентных работах перейти на всех базах на модель Simple. Сам SQL, когда его затачивал "профи" 1С (из конторы 1С, еще до меня), был сконфигурирован просто никак. Сейчас все эти проблемы и посыпались, при увелечении нагрузки. Полные бэкапы (без логов, только сами базы) сливаются каждую ночь.
Вопрос в следующем... Как отреагирует (и отреагирует ли вообще) 1С 8.0, который прикручен к моему SQL2000, на то, что я переведу модель Full на Simple (естественно, всех из 1С выгоню). Возможно, просто восстановлю базу из свежего Backup-а с тем же именем (предварительно снеся полностью старую) уже с пустым файлом логов.
По книжкам, в теории, все просто и быстро, но что-то я ожидаю подводных камней.... Поможите дельным советом.

[kim-aa]

DoublE_zone,
Не ведаю я, о отрок,
терминологии MS-современной.
В чем Full от Simple разнятся?
Или это, суть 1С словеса диавольские?

----------------------------------------------------
Или ты про архивирование глаголешь?
Коли эти уроды, кои Мастера MS SQL создавали,
Богомерзким словом Full - полную выгрузку базы нарекают,
а Simple это инкрементное резирвирование суть есть?

[Insomnia]

На всяки случай атоттачь базу и скопируй лог и саму базу куданить, был както такой случай что после урезге лога база вобше никак не реагировала, говорит лог не тот и всё тут!

[DoublE_zone]

kim-aa, не, немного не так. Имеется в виду модель восстановления (Recovery Model), которая может принимать значения Full, Bulk_logged, Simple. Full - все транзакции записываются и хранятся в журнале транзакций. Simple - журнал транзакций может автоматически усекаться, такое значение позволяет очищать журнал, когда транзакции завершились. То есть хранятся только незавершенные транзакции. Размер файла транзакций, в этом случае, как правило, не превышает гигабайта. Вот, что я имел ввиду.

[kim-aa]

DoublE_zone,
Ааа, понятно. Только если система у вас не высоконагруженная - я бы не связывался.
Потому что MS SQL считает завершения по своим транзакциям, а вам важно сохранять транзакции уровня приложения - 1С, которая может состоять из кучи MS SQL-ских транзакций.


В старых MS SQL я поступал вот как:
- Измерял прирост сегмента логов (транзакций) за время равное двойным полным архивированиям. Т.е. если вы архивируетесь раз в неделю, то измерния прироста - за две недели.
- Затем выставлял размер файла в данное значение и режим, не помню как называется, когда устаревшие транзакции стираются - новые записываются, а размер сохраняется.
В некоторых SQL-серверах можно тупо указать временной диапазон - 2 недели и не мучатся.