Привет.
Если каму интересно, суть истории в том что у нас на SQL сервере неприлично распухает лог одной реляционной базы выполняющей роль хранилища. Ну и собственно получается борьба бобра с ослом: админы орут что надо оптимизировать процедуры загрузки, а разрабы орут что времени и сил нет, мол дайте нам места. В опрделённый момент начался троллинг.
Древняя узбекская притча.
А пастушок кричал: волки, волки!!!
А дба-шники ему: иди в жопу!
А пастушок опять: волки! Ну волки же!
А дба-шники ему: заткнись, лошара, в крайнем случае овцы регенерировать должны!
А волки сожрали всё стадо… J
Древняя еврейская сказка.
Пастухи орали: мне нужно больше овец больше овец.
А СХДэшники ему: у нас ресурсы хлева уже исчерпаны.
А пастухи орали: нет нам нужно больше овец.
ДБАшники пытались сказать что надо оптимизировать использование пастбища и процесс стрижки шерсти, но их никто не слушал.
Древняя русская сказка.
А хлев должен быть бесконечным, ибо в нем хранится вся мировая мудрость.
И отправился Иванушка-дурачок хлева бесконечные искать. Да так и не вернулся.
А Василиса спилась и стала проституткой.
Конец.
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Здравствуйте, ZAMUNDA, Вы писали: ZAM>Если каму интересно, суть истории в том что у нас на SQL сервере неприлично распухает лог одной реляционной базы выполняющей роль хранилища. Ну и собственно получается борьба бобра с ослом: админы орут что надо оптимизировать процедуры загрузки, а разрабы орут что времени и сил нет, мол дайте нам места.
Самое грустное, что админы (да и разработчики тоже, но это не их проблема) нынче вообще не в курсе, откуда распухают логи... Все, что касается лога, это на 100% задача DBA, программеры тут совсем ни при чем.
ЗЫ. Мой совет — сначала уволить админов по несоответствию, а потом программистов за неумение гуглить. Блин, это ж надоть придумать, "оптимизировать процедуры загрузки".
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Привет. ZAM>Если каму интересно, суть истории в том что у нас на SQL сервере неприлично распухает лог одной реляционной базы выполняющей роль хранилища.
1с?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Р>Самое грустное, что админы (да и разработчики тоже, но это не их проблема) нынче вообще не в курсе, откуда распухают логи... Все, что касается лога, это на 100% задача DBA, программеры тут совсем ни при чем.
По большей части согласен. Однако, если грузить в одной транзакции несколько (десятков? сотен?) гектар подряд, то лога может и не хватить
Или периодическую фиксацию в ETL напрасно придумали? По мне так — разумный компромисс.
Здравствуйте, Ромашка, Вы писали:
Р>Все, что касается лога, это на 100% задача DBA, программеры тут совсем ни при чем.
Ну да, обслуживание БД, в том числе журналов, лежит 100% на DBA. Только вот во многих случаях правильным решением этой задачи является "отрубание рук" излишне изобретательных программеров. Которые совсем ни при чем, разумеется.
Р>ЗЫ. Мой совет — сначала уволить админов по несоответствию, а потом программистов за неумение гуглить.
Я бы сначала вник в детали конфликта, ибо нежелание программеров исправлять даже банальные косяки — объективная реальность нашего мира.
Р>Блин, это ж надоть придумать, "оптимизировать процедуры загрузки".
Есть подозрение, что DBA даже показали и разжевали, что именно следует изменить, но:
П>По большей части согласен. Однако, если грузить в одной транзакции несколько (десятков? сотен?) гектар подряд, то лога может и не хватить
Вообще пофигу, в одной или нет. Лог растет пока ему не сделали бэкап (если мы про МС СКЛ говорим и режим базы не Simple). Настройка плана бэкапов, очевидно, задача админов.
Здравствуйте, avpavlov, Вы писали:
A>Давай пример что можно изменить на уровне приложения, чтобы логи не распухали. Меньше и реже обновлять?
Не могу давать советы, не видя приложения.
Но учитывая, что споры идут вокруг процедуры загрузки в хранилище, а разрабы оправдываются не невозможностью исправления, а банальной ленью, можно предположить, что есть определенная свобода маневра у разработчиков.
Я тебя прошу пример вообще из твоей практики.
_AB>Но учитывая, что споры идут вокруг процедуры загрузки в хранилище, а разрабы оправдываются не невозможностью исправления, а банальной ленью, можно предположить, что есть определенная свобода маневра у разработчиков.
Админы, как справедливо заметил Ромашка, плохо представляют, от чего зависит размер лога, и, судя по всему, стрельнули наугад, посоветовав "изменить процедуры загрузки".
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Ромашка, Вы писали:
Р>>Здравствуйте, Sshur, Вы писали: S>>>1с? Р>>А там разве есть транзакции?
_AB>Вроде как есть.
Недавно в БД был топик про длящийся полдня роллбек после прерывания какой-то особо замороченной обработки в 1С. Учитывая, что принципиальных проблем с распуханием лога быть не может, я решил что проблемы чисто в "особенностях" конкретной системы
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, avpavlov, Вы писали:
A>Вообще пофигу, в одной или нет. Лог растет пока ему не сделали бэкап (если мы про МС СКЛ говорим и режим базы не Simple). Настройка плана бэкапов, очевидно, задача админов.
А зачем в описанном случае full recovery model? Там же программеры и постоянный ETL для тестов (как мне телепатор протелепал), а при simple — сам сожмется, если нормально настроено.
Здравствуйте, пыщьпышь, Вы писали:
П>Здравствуйте, avpavlov, Вы писали:
A>>Вообще пофигу, в одной или нет. Лог растет пока ему не сделали бэкап (если мы про МС СКЛ говорим и режим базы не Simple). Настройка плана бэкапов, очевидно, задача админов.
П>А зачем в описанном случае full recovery model? Там же программеры и постоянный ETL для тестов (как мне телепатор протелепал), а при simple — сам сожмется, если нормально настроено.
Мне протелепатило что они сотню гигабайт в одной транзакции лопатят
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, пыщьпышь, Вы писали:
П>Здравствуйте, avpavlov, Вы писали:
A>>Вообще пофигу, в одной или нет. Лог растет пока ему не сделали бэкап (если мы про МС СКЛ говорим и режим базы не Simple). Настройка плана бэкапов, очевидно, задача админов.
П>А зачем в описанном случае full recovery model? Там же программеры и постоянный ETL для тестов (как мне телепатор протелепал), а при simple — сам сожмется, если нормально настроено.
В исходном сообщении нет ничего про "постоянный ETL для тестов", а есть только "одной реляционной базы выполняющей роль хранилища".
Учитывая, что есть проблемы с распуханием лога, изменений в хранилище много. Как при таком кол-ве изменений адины собираются восстанавливать потерянные данные в случае крэша сервера, если режим simple? А, знаю — предложат юзерам заново всё ввести/проимпортировать/обработать. Собственно, если у них действительно стоит режим simple, то Ромашка всё равно прав — гнать поганой метлой
Здравствуйте, avpavlov, Вы писали:
A>Вообще пофигу, в одной или нет. Лог растет пока ему не сделали бэкап (если мы про МС СКЛ говорим и режим базы не Simple). Настройка плана бэкапов, очевидно, задача админов.
Если одна большая загрузка упакована в одну транзакцию, то делай бэкап, не делай бэкап — толку-то не будет...
A>Админы, как справедливо заметил Ромашка, плохо представляют, от чего зависит размер лога
Бред.
Здравствуйте, avpavlov, Вы писали:
A>Учитывая, что есть проблемы с распуханием лога, изменений в хранилище много.
И что? Для определения нужной модели восстановления важно не количество изменений, а их распределение во времени.
A>Как при таком кол-ве изменений адины собираются восстанавливать потерянные данные в случае крэша сервера, если режим simple? А, знаю — предложат юзерам заново всё ввести/проимпортировать/обработать.
Если весь характер изменений — это одна большая загрузка ночью или еще реже, то полный бэкап + диффы (опционально) полностью решают поставленную задачу в подавляющем большинстве случаев.
A>Собственно, если у них действительно стоит режим simple, то Ромашка всё равно прав — гнать поганой метлой
Гнать надо людей, которые не в состоянии рационально использовать предоставленные инструменты.
Здравствуйте, avpavlov, Вы писали:
A>В исходном сообщении нет ничего про "постоянный ETL для тестов", а есть только "одной реляционной базы выполняющей роль хранилища".
Хранилище, в моем представлении, содержится не самая часто меняемая информация. Хотя в данном конкретном случае могу и ошибаться, говорю ж — догадки. Просто в случае full recovery model не вижу, что бы такого могли предложить админы для "оптимизации процедур загрузки данных".
П>>По большей части согласен. Однако, если грузить в одной транзакции несколько (десятков? сотен?) гектар подряд, то лога может и не хватить
A>Вообще пофигу, в одной или нет. Лог растет пока ему не сделали бэкап (если мы про МС СКЛ говорим и режим базы не Simple). Настройка плана бэкапов, очевидно, задача админов.
И, кстати, всё равно не пофигу Даже если фул-рикавери и бэкапы настроены хоть на каждые 10 минут — одна огромная транзакция не даст его сжать, пока не закоммитится или не откатится.
Проблемы на стыке зон ответственности часто чреваты такой распасовкой, пока "судья" штрафной не назначит. Особенно, если каждая сторона априори считает другую идиотами
Все, что касается лога, это на 100% задача DBA, программеры тут совсем ни при чем. 
