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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

ну и зачем тогда давать конкретные советы?
это плохая идея. Т.к. некоторая нетипичная операция может потребовать больше пространства, чем задумано непредусмотрительным админом. В итоге БД упадёт - лог транзакции не сможет записаться до конца, в итоге будет не откатить операцию, но и завершить операцию не получится из-за "нехватики" места.
как вы связываете зрение и слух? - Если уши отрезать - папаха на глаза упадёт. Если серьёзно, то какая связь между разрядностью системы и объёмом файла?
Я бы советовал увеличивать объём файлов меньшими порциями - за раз откушать 2Гб - достаточно ресурсоёмкая операция даже для современного сервера.
Не так. Логи и данные хранятся и архивируются практически независимо. Для восстановления состояния БД на определённый момент нужно получить старую копию БД - всё равно как - хоть из образа диска, хоть из разностного backup. Наложить на неё цепочку бэкапов транзакций. Лишь бы эти логи начинались до создания бэкапа БД.
Это в MySQL можно дамп БД сделать, в MS SQLServer такого понятия нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если серьезно - учите матчасть.
Могу привести два аргумента, теоретический и практический:
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х битных систем размер файла данных не должен превышать предела выделения памяти процесу - 2 ГБ.
Возможно использование файлов меньшего размера, однако нужно осознавать что при росте колличества мелких файлов кеширование на уровне RDBMS станет все менее эффективным, т. к. узкое место переместится в область файловых и I/O операций.
Так же необходимо соизмерять размер наибольшей логической структуры данных - таблицы, с наименьшим размером физической структуры данных - файлом, где сия таблица будет пребывать.

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

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

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

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

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

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

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

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

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

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

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

Матчасть я, как раз, знаю, спасибо:
1) ключ 3gb файла boot.ini позволяет перераспредилить адресное пространство, и пользовательским процессам будет отведено до 3Гб
2) памяти у нас всё же меньше чем объём данных, и для чтения-записи какой-то части файла его ОС целиком в память не грузит
3) ОС работает с дисковой системой не на уровне байтов, а на уровне секторов (512 байт); кластеров (как правило больше секторов); SQL Server на уровне - страниц (8Кб) и групп страниц (extent - 64Кб). Соответственно и чтение-запись осуществляется блоками по 8-64 Кб, а не массивами "сколько в память влезет".
4) У нас речь и о величине прироста файла или об абсолютном размере файла? Прирост я как раз рекомендовал делать меньше 2Гб. А разбивать БД на множество мелких файлов в большинстве случаев неэффективно.

нету больше DUMP - в 2k это уже нерекомендуемая операция, которая оставлена исключительно для совместимости (как и LOAD). Нужно пользоваться BACKUP и RESTORE.

Операции/мероприятия проводимые раз в квартал, год - можно назвать типичными? - Сомневаюсь. Тем не менее, они очень даже присутствуют в бухгалтерской деятельности (раз уж речь про 1С). Открытие нового филиала, какая-нибудь ревизия-инвентаризация - вообще непериодические операции - вряд ли о каждом подобном действе будут сообщать администратору ;)

Busla,
Типичные-типичные.
Любой стандартный отчет типичный. Главное период наблюдения.

Да. Вы правы. Но это не изменит win32. Это изменит выделение памяти нескольким процессам.

Честно говоря не понял аргумента. Какая разница в страницах или секторах, 2 ГБ будет всегда.


Значитсо мы говорим об одном и том же. Я уже поправился.
На счет разового выделения 2ГБ - Вы правы. Не хилая операция. Но в тех же рекомендациях MS, рекомендуется выделять пространство заранее.
---------------------------------

Busla,
На самом деле, тут у нас эстетский тред, вызванный кривостью реализации 1C.

А насколько происходит усечение файла журнала транзакций при бэкапе (в процентах, примерно, если не существует точных данных)? Отобразится ли это на его фактическом размере (он станет меньше в GB) или просто файл останется таким же по размеру (но освободится зарезервированное пространство внутри самого файла под новые логи)?
И сколько может весить такой бэкап, опять же в процентах от файла транзакций логов?

Да

kim-aa, при резервировании файла транзакций логов на тестовой базе (файл равнялся 612MB), урезка файла получилась (если получилась) совсем крошечной... Смотрел через "Свойства базы - Задачи - Сжать - Файлы", там четко видно, сколько реально занято пространства из файла. То есть, ощутимой выгоды по урезке файла логов резервирование оного не дает.

Вы не поняли. Очищает файл логов не сама процедура архивирования.
Просто при архивировании файла логов есть опция очищать его.
Вы можете сделать то же самое написав SQL-скриптик который будет просто очищать файл логов.

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

kim-aa, извиняюсь, видимо, галка эта по умолчанию не стояла, а так я ее не заметил. :)
В понедельник попробую.
А вот скрипт, который позволяет очистить журнал транзакций без проведения резервного копирования (еще не проверял, нашел в умной книге): BACKUP LOG имя базы TRUNCATE_ONLY.

Нашел хорошую книгу... Ростислав Михеев. "MS SQL Server 2005 для администраторов". Рассмотрены многие важные моменты, которые упущены в других изданиях. Очень рекомендую.

это можно было найти и в "умном хэлпе". Формально:
BACKUP LOG имя_БД WITH TRUNCATE_ONLY
хотя мне тоже попадались примеры без with

К вопросу об "автоинременциях" и прочем автоматизме

Эту цитату необходимо пояснить:
администратор БД - вполне конкретная отдельная должность
небольшие прикладные системы - это десятки и даже сотни компьютеров
этап внедрения - в контексте 1С обычно никогда не прекращается