Большая загрузка при бэкапе лога

Имеется 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 под бэкап.

Почему так? Как обойти данную проблему не снижая надежности бэкапов?
У дифференциального бэкапа загрузка меньше?

О, блин!
А это не оно - http://support.microsoft.com/default.aspx?scid=kb;en-us;818767?

ps: я хренею с MS - И какой у меня выход теперь?

И еще вот - http://support.microsoft.com/default.aspx?scid=kb;en-us;813645

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

Я офигеваю...

Проверил.... при дифференциальном бэкапе таких тормозов не происходит.

Есть еще выходы кроме перехода на дифференциальный бэкап?

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

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

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

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

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

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

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

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

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

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

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

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

порядка 5% - так как и должно быть...

тьфу... с квотингом накосячил

То Dennizz . Если вдруг найдете описание механизма вышлите мне его пожалуйста...

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

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

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

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

>То Dennizz . Если вдруг найдете описание механизма вышлите мне его пожалуйста...

ok

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

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

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

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