[решено] Обрезаем файл транзакций логов...

[DoublE_zone]

Доброго времени суток! Последнее время, на некоторых корпоративных базах, на моем SQL Server 2000 сильно разрослись файлы транзакции логов. Вот и надумал их урезать: Свойства базы - Транзакции логов - Максимальный размер файла. Поставить там ограничение гектар на 10 (при условии, что сам файл данных весит 2,7 GB). Вообще, сейчас работает связка 1С8.0 - SQL Server 2000.
Вопрос следующий... Поскольку, я урезаю файл транзакции логов впервые, подкажите, нет ли там каких подводных камней или нюансов, которые необходимо знать. Сейчас размер файла транзакции логов (в одной из баз) равен 50 ГБ, порежу до 10 ГБ. Как долго будет идти процесс обрезания? Потребуется ли ребут SQL? Удалятся наиболее старые логи или не факт?
Как вариант, рассматриваю переход на схему восстановления Simple. В этом случае логи всех завершенных транзакций должны автоматом делиться. Как долго будет идти процесс смены схемы восстановления? Заблочится ли база на это время? Потребуется ли ребут SQL?
P.S. Умную книгу почитал, но такие нюансы освещены плохо. :(
Спасибо. Жду авторитетных мнений.

[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 недели и не мучатся.

[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.