Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
Имеется DualXeon 2Ghz с включенным HT/2Gb/RAID5 SCSI - данные и логи/IDE RAID1 - бэкапы.
Несколько баз 1c начиная от 1gb и заканчивая 4gb (чистых данных).
Бэкапы транзакшион логов делаются с периодами от 15 до 30 минут. Моменты бэкапов для разных баз между собой в большинстве случаев не совпадают.
Размер каждого бэкапа лога в зависимости от активности юзеров за период составляет примерно от 100кб до 5-7мб.

Итак проблема - бэкап одного лога (для самой большой базы - для остальных чуть меньше) делает порядка 1.5-2 минут. Все это время загрузка всех четырех процев на уровне 95-100%. В это время шуршит только scsi raid, и только в последние несколько секунд бэкап сбрасывается на IDE - так что дело не в медленном IDE под бэкап.

Почему так? Как обойти данную проблему не снижая надежности бэкапов?
У дифференциального бэкапа загрузка меньше?
14 окт 03, 11:12    [375572]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
О, блин!
А это не оно - http://support.microsoft.com/default.aspx?scid=kb;en-us;818767?

ps: я хренею с MS - И какой у меня выход теперь?
14 окт 03, 12:11    [375691]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
И еще вот - http://support.microsoft.com/default.aspx?scid=kb;en-us;813645

Оказывается эта проблема была еще в SP2, пообещали пофиксить в SP3...
Теперь обещают пофиксить в SP4...

Я офигеваю...
14 окт 03, 12:18    [375709]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
Проверил.... при дифференциальном бэкапе таких тормозов не происходит.

Есть еще выходы кроме перехода на дифференциальный бэкап?
14 окт 03, 15:19    [376089]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Вообще то точно непонял проблему( слабоват я в английском:)) у меня таких проблем не замечалось.... Ну а почему бы не использовать дифферренциальное резервирование? В принципе что страшного может произойти в 1С при незавершении транзакции? Только незавершенные операции с документами(если конечно отключение не произошло в момент полного пересчета итогов,конфигурационных измен. и т.п. -что мало вероятно) - как следствие возможная неполная агргация данных в итогах по регистрам или по бухитогам ну для этого можно на крайний случай вести на триггерах простейшее логирование того какие документы были изменены и в случае дифференциального востановления эти документы перепроводить(ну 5-7 от силы с незавершенной транзакцией да и то маловероятно) а пользоватеям работавшими с этими документами рассылать письма спросьбой проверить состав документов...

Хм , пока писал понял что сам не до конца понимаю как работает дифференциальное резервирование... То есть конечно понятна концепция что сохраняется не вся база а только та часть которая которая была изменена с момента создания последней копии, но возникают вопросы а как определяется измененная часть.(состовляется список ссылок на измененные записи а потом выгружается иинформация по ним?, попадут ли в этот список записи измененные после начала запуска создания дифференциальной копии?,откуда берется этот список(ну скорее всего из журнала транзакций не сверкой же таблиц) и т.д. и т.п. ) Вообщем на самом деле нужно как нибудь все это проверить...

То Dennizz ... Кстати а какая нагрузка(порядок цифр) при дифференциальном бэкапе?
14 окт 03, 16:14    [376258]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

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

1).У меня не только базы 1с;
2).Нахрена мне этот геморой с триггерами и отслеживанием ситуаций вручную, если _был_ и работал нормальный механизм?

>того какие документы были изменены и в случае дифференциального >востановления эти документы перепроводить(ну 5-7 от силы с незавершенной >транзакцией да и то маловероятно) а пользоватеям работавшими с этими >документами рассылать письма спросьбой проверить состав документов...

на самом деле это скользкий вопрос что при дифференциальном бэкапе, что при бэкапе тлогов. насколько я в курсе - 1с не обеспечивает по умолчанию атомарность транзакций в пределах проведения документа (если это явно не определено операторами НачатьТранзакцию/ЗавершитьТранзакцию). в таком случае мы в любом случае получаем некорректное восстановление (надеюсь понятно почему).

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

>Хм , пока писал понял что сам не до конца понимаю как работает >дифференциальное резервирование... То есть конечно понятна концепция что >сохраняется не вся база а только та часть которая которая была изменена с >момента создания последней копии, но возникают вопросы а как определяется >измененная часть.(состовляется список ссылок на измененные записи а потом >выгружается иинформация по ним?, попадут ли в этот список записи >измененные после начала запуска создания дифференциальной копии?,откуда >берется этот список(ну скорее всего из журнала транзакций не сверкой же >таблиц) и т.д. и т.п. ) Вообщем на самом деле нужно как нибудь все это >проверить...

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

ps: надо порыться - я точно видел где-то описание механизма.

>То Dennizz ... Кстати а какая нагрузка(порядок цифр) при дифференциальном >
>бэкапе?

порядка 5% - так как и должно быть...
15 окт 03, 08:04    [377033]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
тьфу... с квотингом накосячил
15 окт 03, 08:05    [377034]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
МуМу
Member

Откуда:
Сообщений: 1134
То Dennizz . Если вдруг найдете описание механизма вышлите мне его пожалуйста...

во-первых, бэкапятся только закомичченые экстенты - то есть завершенные транзакции.

Во первых :Ну а чем вам это тогда не подходит?
Во вторых: Тогда интересно а в чем принципиальное отличие между дифференциальным бэкапом и бекапом журнала транзакций кроме того что по журналу транзакций можно востановить данные по времени?
15 окт 03, 12:54    [377546]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Да и еще, я немного ошибся когда сказал что у пользователей будет максимум 5-7 документов с незавершенной транзакцией.... На самом деле это будет максимум один документ... Т.к в момент проведения или записи документа в 1С все остальные пользователи не могут проводить свои документы....
Вы правы что 1С не все всю оперцию проведения выполняет в одной транзакции.(если в обработке проведения записать еще несколько записей в справочники а потом остановить обработку то они останутся в базе) Но с другой стороны а чем это нам поможет в случае наличия журнала транзакций? Ведь все равно прийдется определять завершилась ли обработка проведения или нет и востанавливать на определенное время... По моему проще просто перепровести последний изменяемый документ...

То есть я к чему веду - Востановление базы данных по журналу транзакций в контексте 1С отнюдь не гарантирует логической целостности данных. Так что в контексте 1С дифференциальный ничем не хуже.
15 окт 03, 13:10    [377572]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
>То Dennizz . Если вдруг найдете описание механизма вышлите мне его пожалуйста...

ok

>Во первых :Ну а чем вам это тогда не подходит?

я этого не говорил... я просто искал альтернативы.

>Во вторых: Тогда интересно а в чем принципиальное отличие между >дифференциальным бэкапом и бекапом журнала транзакций кроме того что по >журналу транзакций можно востановить данные по времени?

ну например в том, что диф.бэкап делается на основании последнего full backup - если база активно используется на запись и мы сравниваем размеры десяти бэкапов тлогов за день и десяти дифбэкапов за день, то во втором случае мы получим цифру на порядок больше. вобщем смысл в оптимизации бэкапов в зависимости от режима использования базы.
во-вторых, использовани диф.бэкапов крайне не удобно с административной точки (imho) потому как их нет в Maitanance Planes. если нужно хранить n-е кол-во копий за какой-то промежуток времени - облом... - придется ручками.
15 окт 03, 14:37    [377787]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
> На самом деле это будет максимум один документ... Т.к в момент проведения или записи документа в 1С все остальные пользователи не могут проводить свои документы....

вот это для меня новая информация - спасибо... учтем.

>То есть я к чему веду - Востановление базы данных по журналу транзакций в >контексте 1С отнюдь не гарантирует логической целостности данных. Так что в >контексте 1С дифференциальный ничем не хуже.

я же говорю:
1).иметь возможность восстановления на заданную точку времени;
2).у меня не только базы 1с - только в 1с это все не упирается.


2Glory: ну где же ты? ;)
15 окт 03, 14:40    [377790]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Glory
Member

Откуда:
Сообщений: 104760
Ну нет у меня такой OLTP базы. Та, которая есть, в ней от силы 1,5Гб данных(часть уже не обновляется), 10 пользователей и лог за час вырастает на пару сотен мегабайт(и то не всегда). Но там архивация лога каждый час не вытворяет того, что у вас.

Клиентский софт там Alcatel CallcenterOutbond. Прцессор 1, памяти 512 всего
15 окт 03, 14:48    [377813]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
2Glory: :( Все дело в том, что у тебя не SMP система. Данный глюк встречается только для SMP систем - судя по описанию MS.

А кроме диф.бэкапа у меня выход есть какой-либо?

2MyMy: специально сейчас провел исследование по поводу ОработкиПроведения в 1с - таки она включает set implicit on в начале проведения и таким образом обеспеченивает атомарность проведения документа - что уже радует ;))) таким образом я был немного не прав выше... а вот создание документа и его проведение делается уже в разных транзакциях :(
ну хоть проведение атомарно - и то ладно...
15 окт 03, 15:21    [377906]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
Кстати, ради интереса помониторил нагрузку на двух 1с'овских (из 5 1с-овсикх и трех других) базах в течении 7-ми часов - 4392874 запросов. Это в среднем 175 запросов в секунду - не хило :-\

И еще - после отключения бэкапа транзакшин логов в течении дня сегодня загрузка достигала 100% только в пиках и на несколько секунд - что собственно и должно происходить.... таки блин бэкапы виноваты :(
15 окт 03, 15:34    [377938]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
МуМу
Member

Откуда:
Сообщений: 1134
То Dennizz
2MyMy: специально сейчас провел исследование по поводу ОработкиПроведения в 1с - таки она включает set implicit on в начале проведения и таким образом обеспеченивает атомарность проведения документа - что уже радует ;))) таким образом я был немного не прав выше... а вот создание документа и его проведение делается уже в разных транзакциях :(
ну хоть проведение атомарно - и то ладно...


Да агрегация при проведении в одной транзакции(еще бы если бы этого не было то приходилось бы итоги очень часто пересчитывать) .
Но дело в том что в обработке проведения кроме записи по регистрам и проводкам могут быть записи в другие объекты и вот именно по ним в пределах обработки проведения все действия выполняютя не в одной транзакции:(
15 окт 03, 15:52    [377984]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
2MyMy: Это как это? может я торможу к вечеру, но вряд ли это так потому что:
проведение идет по принципу

set implicit_tran on
делаем какие-то действия по проведению
if trancount>0 commit tran
set implicit_tran off

я очень сильно подозреваю, что 1с не умеет использовать явные begin tran/commit tran с переменной в качестве аргумента - а это значит, что врядл ли в проведении будет несколько вложенных транзакий... и даже в этом случае, при вложенных транзакциях мы имеем одну неявную родительскую, которая откатит все закоммиченные вложенные если что-то случится...

или я что-то не так понял?
15 окт 03, 16:17    [378032]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Да вообщем то ты прав(еще раз на всякий случай перепроверил)... Внутри обработки проведения действительно все работает внутри транзакции, но дело в том что из за некоторых ограничений 1С разработчики используют дополнительные конструкции и привязывают их к обработке проведения(ПриЗаписи(),ПриЗаписиПерепроводить()) но с другой стороны это уже проблемы разработчиков.....они должны знать к чему это может привести в случае некорректного завршения операции...
15 окт 03, 16:46    [378079]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
2MyMy: Ага, тут согласен... вот только мало кто из разработчиков знает и вдается в такие тонкости :(
16 окт 03, 05:19    [378635]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

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

Другие мнения будут?
16 окт 03, 05:22    [378637]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
раз работчик
Guest
2 Dennizz

вот только мало кто из разработчиков знает и вдается в такие тонкости :(

Только не надо считать себя умнее разработчиков.
Они и знают и вдаются.

Я например знаю, что нужно делать зарядку по утрам, но не делаю
16 окт 03, 09:35    [378782]     Ответить | Цитировать Сообщить модератору
 Re: Большая загрузка при бэкапе лога  [new]
Dennizz
Member

Откуда:
Сообщений: 226
2раз работчик: я не хотел никого обидеть... и уж тем более не считал себя умнее других ;)
16 окт 03, 09:52    [378822]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить