Имя пользователя:
Пароль:  
Помощь | Регистрация | Забыли пароль?  | Правила  

Компьютерный форум OSzone.net » Программирование, базы данных и автоматизация действий » Программирование и базы данных » MSFT SQL Server - [решено] Обрезаем файл транзакций логов...

Ответить
Настройки темы
MSFT SQL Server - [решено] Обрезаем файл транзакций логов...

Старожил


Сообщения: 174
Благодарности: 0

Профиль | Отправить PM | Цитировать


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

Отправлено: 16:22, 26-11-2007

 

Ветеран


Сообщения: 3806
Благодарности: 824

Профиль | Отправить PM | Цитировать


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

Отправлено: 12:57, 21-12-2007 | #21



Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.

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


Ветеран


Сообщения: 3806
Благодарности: 824

Профиль | Отправить PM | Цитировать


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

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

Отправлено: 13:34, 21-12-2007 | #22


Аватара для kim-aa

Назгул


Сообщения: 2633
Благодарности: 345

Профиль | Отправить PM | Цитировать


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

Цитата Busla:
и пользовательским процессам будет отведено до 3Гб »
Да. Вы правы. Но это не изменит win32. Это изменит выделение памяти нескольким процессам.

Цитата Busla:
ОС работает с дисковой системой не на уровне байтов, а на уровне секторов (512 байт); кластеров (как правило больше секторов); SQL Server на уровне - страниц (8Кб) и групп страниц (extent - 64Кб). Соответственно и чтение-запись осуществляется блоками по 8-64 Кб, а не массивами "сколько в память влезет" »
Честно говоря не понял аргумента. Какая разница в страницах или секторах, 2 ГБ будет всегда.


Цитата Busla:
У нас речь и о величине прироста файла или об абсолютном размере файла? Прирост я как раз рекомендовал делать меньше 2Гб. А разбивать БД на множество мелких файлов в большинстве случаев неэффективно. »
Значитсо мы говорим об одном и том же. Я уже поправился.
На счет разового выделения 2ГБ - Вы правы. Не хилая операция. Но в тех же рекомендациях MS, рекомендуется выделять пространство заранее.
---------------------------------

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

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


Отправлено: 14:07, 21-12-2007 | #23


Старожил


Сообщения: 174
Благодарности: 0

Профиль | Отправить PM | Цитировать


Цитата kim-aa:
По умолчанию архивирование журнала транзакций (Transaction Log) осуществляет и его усечение »
А насколько происходит усечение файла журнала транзакций при бэкапе (в процентах, примерно, если не существует точных данных)? Отобразится ли это на его фактическом размере (он станет меньше в GB) или просто файл останется таким же по размеру (но освободится зарезервированное пространство внутри самого файла под новые логи)?
И сколько может весить такой бэкап, опять же в процентах от файла транзакций логов?

Отправлено: 14:17, 21-12-2007 | #24


Аватара для kim-aa

Назгул


Сообщения: 2633
Благодарности: 345

Профиль | Отправить PM | Цитировать


Цитата DoublE_zone:
или просто файл останется таким же по размеру (но освободится зарезервированное пространство внутри самого файла под новые логи)? »
Да

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


Отправлено: 14:54, 21-12-2007 | #25


Старожил


Сообщения: 174
Благодарности: 0

Профиль | Отправить PM | Цитировать


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

Отправлено: 17:56, 21-12-2007 | #26


Аватара для kim-aa

Назгул


Сообщения: 2633
Благодарности: 345

Профиль | Отправить PM | Цитировать


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

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

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


Отправлено: 23:19, 21-12-2007 | #27


Старожил


Сообщения: 174
Благодарности: 0

Профиль | Отправить PM | Цитировать


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

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

Последний раз редактировалось DoublE_zone, 22-12-2007 в 22:39.


Отправлено: 18:22, 22-12-2007 | #28


Ветеран


Сообщения: 3806
Благодарности: 824

Профиль | Отправить PM | Цитировать


Цитата DoublE_zone:
(еще не проверял, нашел в умной книге): BACKUP LOG имя базы TRUNCATE_ONLY »
это можно было найти и в "умном хэлпе". Формально:
BACKUP LOG имя_БД WITH TRUNCATE_ONLY
хотя мне тоже попадались примеры без with

Отправлено: 12:47, 23-12-2007 | #29


Аватара для kim-aa

Назгул


Сообщения: 2633
Благодарности: 345

Профиль | Отправить PM | Цитировать


Изображения
Тип файла: png ms-sql-2000.png
(209.3 Kb, 51 просмотров)

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

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


Отправлено: 13:55, 30-12-2007 | #30



Компьютерный форум OSzone.net » Программирование, базы данных и автоматизация действий » Программирование и базы данных » MSFT SQL Server - [решено] Обрезаем файл транзакций логов...

Участник сейчас на форуме Участник сейчас на форуме Участник вне форума Участник вне форума Автор темы Автор темы Шапка темы Сообщение прикреплено

Похожие темы
Название темы Автор Информация о форуме Ответов Последнее сообщение
Службы - [решено] Координатор распределенных транзакций __sa__nya Microsoft Windows 2000/XP 6 24-01-2021 11:21
Разное - Поиск USB hubа с мультитрансляцией транзакций (Multi-TT) skyfish Прочее железо 2 17-01-2010 14:49
MSFT SQL Server - Процент заполненности файла журнала транзакций и журнал счетчиков TywkaH4uk Программирование и базы данных 2 21-10-2008 14:39
сервер не нестроен на выполнение транзакций slaine Сетевые технологии 4 17-02-2006 11:25
Проблема транзакций phoner Microsoft Windows NT/2000/2003 1 28-01-2006 13:35




 
Переход