[DoublE_zone]

kim-aa, не связываться, к сожалению, не получится... Дисковая система скоро отдаст концы, за неимением свободного места.

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

Меня вот это сильно озадачило, именно этого я и боялся, просто не мог сформулировать... Но, ожидал. Придется тогда оставлять Full и резать файлы логов.
Попробовал это сделать (обрезать 15GB файл логов до 10GB) на тестовой модели, путем ограничения по размеру из свойств. Он, собака (при нажатии ОК), переводит установленное мной значение 10000MB снова в 15000MB (то есть, в данном случае, это для него минимальное ограничение, насколько я понял) и закрывает окно. Может, нужно как-то по-другому на него воздействовать? Не знаю.
Жду, мнений, а то места скоро не останется совсем...

[Busla]

Я ,честно говоря давно с MS SQL не работал, лет так восемь »

ну и зачем тогда давать конкретные советы?

Файлы лучше выделять вручную, т.е. откулючить авторасширение. »

это плохая идея. Т.к. некоторая нетипичная операция может потребовать больше пространства, чем задумано непредусмотрительным админом. В итоге БД упадёт - лог транзакции не сможет записаться до конца, в итоге будет не откатить операцию, но и завершить операцию не получится из-за "нехватики" места.

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

как вы связываете зрение и слух? - Если уши отрезать - папаха на глаза упадёт. Если серьёзно, то какая связь между разрядностью системы и объёмом файла?
Я бы советовал увеличивать объём файлов меньшими порциями - за раз откушать 2Гб - достаточно ресурсоёмкая операция даже для современного сервера.

Т.е. размера лог-файла должно хватать на операции между двумя полными архивированиями. »

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

Сделайте Дамп базы - если что, вы поднимитесь с нее на любом сервере. »

Это в MySQL можно дамп БД сделать, в MS SQLServer такого понятия нет.

2 DoublE_zone:
По умолчанию архивирование журнала транзакций (Transaction Log) осуществляет и его усечение. IMHO самым простым (и правильным, с точки зрения возможности отката) является настройка так же и резервного копирования журнала транзакций.
Урезать по объёму бессмысленно. Урезать надо по времени!

[DoublE_zone]

Busla, а как по времени резать? Таких настроек я там (в свойствах базы) не видел. Может, через интерфейс 1С это можно как-то сделать??? Просто, мне ближе непосредственно SQL. А 1С у нас занимается цельный отдел, правда, ничего вразумительного по данной проблеме сказать не в состоянии.... Даже не смогли сказать вот это:

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

Поэтому, пытаюсь решить проблему через SQL, на более низком уровне. Печально.

[Busla]

Не совсем корректно выразился. Урезать так чтобы остались "последние 243 минуты и 15 секунд" нельзя. Имелось ввиду, что планировать бэкапы и усечения нужно по отрезкам времени - тогда будет ясно от каких отправных точек плясать. А какой период влезет в заданный объём предугадать можно только в исключительных случаях.

Усечь TL можно только полность и в данный момент. Ограничение его объёма приведёт к тому, то не будут писаться последующие операции. Т.к. используют его в прямом направлении - повторяют операции на резервной копии. А не откатывают назад рабочую БД.

[DoublE_zone]

Busla, спасибо, конечно, за информацию.

Тогда у меня к вам несколько вопросов:

1 - Как мне, в таком случае, реализовать урезание (уменьшение) файла логов, скажем, если я представляю примерный объем, который нагребается за некоторый нужный мне промежуток времени? Сейчас файл весит 53GB, режем до 5GB (например).

2 - Вы пишите, что необходимо, помимо бэкапа самой базы, иметь бэкап транзакций, логи которых начинаются ДО создания бэкапа данных. Это вполне логично и понятно, если проблематично делать полный бэкап данных. Если мы назначаем файлу транзакций логов автоматический рост, одновременно ограничивая его по размеру, то логи будут заменяться в нем циклически (при достижении Max-значения) или заполнился и стоп (вы говорите, что не будут писаться последующие операции)? Но тогда где-то незавершенные транзакции должны храниться все-равно.... Где они будут храниться, если файл тр. логов будет забит? Не понятно...

3 - Смысл мне бэкапить логи, если есть возможность сливать файл данных каждую ночь? Будет просто избыточность.

4 - Как вы относитесь к мнению kim-aa по поводу

Потому что MS SQL считает завершения по своим транзакциям, а вам важно сохранять транзакции уровня приложения - 1С, которая может состоять из кучи MS SQL-ских транзакций »

?

Видится мне такое решение... Выгнать всех из 1С, заглушить 1С, сделать свеженький бэкап файла данных (через SQL, а не через 1С), развернуть НОВУЮ базу из этого бэкапа (на модели Full, создать и ограничить по размеру файл транзакций, установить шаг роста). Запустить 1С и все проверить. Снести нах старую базу и старый файл логов.

5 - Все верно из предыдущего абзаца?

[Busla]

1. SQL Server (2000 по крайней мере) не предусматривает возможности усечения файла журнала транзакций по объёму или временным отрезкам. Можно задать, скажем так, аварийный предел который нельзя превышать. Т.е. данные просто не будут в него добавляться.

2. А они и не будут хранится. Вызовет это останов или просто отключит транзакции - не скажу, не знаю.

3. Журнал транзакций позволяет получить состояние БД не только на момент формирования бекапа, но и любое промежуточное состояние. Если этого не требуется - можно переключить Recovery Model в Simple. Требует это перезапуска или перехода в Single user - не помню. Как-то переключал, но давно.

4. Что считает 1С логически неделимой операцией - мне неведомо. SQL Server позволяет обозначить "пользовательскую" транзакцию, а вот насколько этими возможностями воспользовались программисты 1С - большой вопрос.

5. Неверно, файл транзакций быстренько забъётся и перестанет выполнять свою функцию.

Я бы перешёл на модель Simple и вообще не ограничивал файл транзакций.

[kim-aa]

как вы связываете зрение и слух? - Если уши отрезать - папаха на глаза упадёт. Если серьёзно, то какая связь между разрядностью системы и объёмом файла? Я бы советовал увеличивать объём файлов меньшими порциями - за раз откушать 2Гб - достаточно ресурсоёмкая операция даже для современного сервера. »

Если серьезно - учите матчасть.
Могу привести два аргумента, теоретический и практический:
1) В 32х битной системе процессу больше двух гигабайт памяти не выделяется.
Потоки делят память внутри процесса.
Идеальный случай:
- у вас много памяти, по крайней мере достаточно для безпроблемного кеширования всего и вся, или размер данных не велик и полностью влезает в память.
- один файл данных обслуживает один процесс кэширования операций чтения/записи.
- Файлов много, процессов кеширования тоже.
Так вот, дорогой друг, при размере файла данных более 2 гигабайт, даже при наличии свободной памяти, один процесc не сможет обслужить файл данных, дабы тот целиком влез в кэш.
А при не равном соотношении количестве процессов - файлов это уже конкуренция за ресурсы.
Естественно на это имеет смысл обращать внимание лишь в высоконагруженных системах.

2) Есть такая фирма SAP AG со своим продуктом ERP SAR R/3. Он работает на многих RDBMS (в том числе и MS SQL) как 32х,
так и 64х битных.
Продукт часто старше IT-шников которые его обслуживают. Ну да ладно, оставим лирику.
Для 32 битных систем, файлы данных в RDBMS выделяются размерами по 2 ГБ.

Естественно все зависит от размера базы данных. Все вышеперчисленные замечания верны для больших DB.
SAP R/3 4.7 при развертывании с нуля создает базу около 60 ГБ.
SAP NetWeaver - соответственно больше.
Даже если резать кусками по 2 ГБ - это уже 120 файлов "пустой" базы.

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

Да, сказано не удачно, привычка к большим базам, - признаю.

Вот как это звучало бы верно:
Для 32х битных систем размер файла данных не должен превышать предела выделения памяти процесу - 2 ГБ.
Возможно использование файлов меньшего размера, однако нужно осознавать что при росте колличества мелких файлов кеширование на уровне RDBMS станет все менее эффективным, т. к. узкое место переместится в область файловых и I/O операций.
Так же необходимо соизмерять размер наибольшей логической структуры данных - таблицы, с наименьшим размером физической структуры данных - файлом, где сия таблица будет пребывать.

При наличии свободного места на HDD, рекомендуется заранее создавать файлы данных ( файл устройств - в терминах MS SQL 6.x).
Этим вы как резервируете место на будущее, так и обеспечиваете нефрагментированность файла данных на уровене файловой системы. В MS SQL 6.x можно было создать файлы устройств, но не выделять их базам - т.е. зарезервировать место.
Как обстоит дело сейчас - не ведаю.
--------------------------------------------------------------------------

это плохая идея. Т.к. некоторая нетипичная операция может потребовать больше пространства, чем задумано непредусмотрительным админом. В итоге БД упадёт - лог транзакции не сможет записаться до конца, в итоге будет не откатить операцию, но и завершить операцию не получится из-за "нехватики" места. »

Это стандартная идея.
Опять же два аргумента:
1) В умных книжках рекомендуют делать все руками - надежнее знаете ли.
Да, при неизвестной нагрузке и абсолютно новой базе, лучше включить все на автомат, т. к. разработчику виднее.
Но если администратор BD, после квартала эксплуатации не может сформировать график роста данных и зафиксировать
максимальные нагрузки, то - "Вон из профессии!" (с) art lebedev
2) Если в системе появились "нетипичные операции", то нужно убивать либо программистов (обычно они первые гадят), либо пользователя, либо администратора.
---------------------------------------------------------------------------

Это в MySQL можно дамп БД сделать, в MS SQLServer такого понятия нет. »

Да вы что? А команда DUMP DATABASE ?

[kim-aa]

Смысл мне бэкапить логи, если есть возможность сливать файл данных каждую ночь? Будет просто избыточность. »

Логи бэкапят во временной интервал МЕЖДУ полными бэкапами, естественно.
В свое время, я бекапил логи в обед, а полные бекапы делал ночью, как и Вы.
Естественно после полного бекапа есть смысл полностью очистить текущий лог-файл.

Не забывайте архивировать master.

Дисковая система скоро отдаст концы, за неимением свободного места. »

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

[DoublE_zone]

А просто добавить диск? Если вы разложите Данные и Журнылы по разным физическим устройствам .у вас еще и скорость выростет. »

у меня 5 сказевых винтов, закрученных в Raid 5, все это на 1 логический раздел. Так он был сконфигурирован еще до меня.

В итоге, пришли к тому, с чего начинали.... Лучший вариант - развернуться со свежего бэкапа и перейти на Simple...
Основной вопрос же остался нерешенным: что в этом случае скажет 1С (1С8.0), а именно, соответствие завершения его транзакций завершениям транзакций SQL. Может случиться такое, что 1 транзакция уровня приложения - есть несколько транзакций уровня SQL. Отдел 1С молчит.

[kim-aa]

Я, все таки за Full.

Человек прав

По умолчанию архивирование журнала транзакций (Transaction Log) осуществляет и его усечение. »

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

Например, если вы проводите DUMB DATABASE раз в день, то выгрузку лог-файлов можно проводить раз в два дня.
Если вы не желаете хранить копии, то выгрузку можно осуществлять просто в один и тот же файл.

Правда, я не знаю за какой временной период вы храните полные выгрузки.

Кстати, если хотите разобраться с моделями архивирования в MS SQL изучите команду DUMP.