none
После перехода c SQL 2000 на SQL 2005 время резервного копирования увеличилось в 5 раз! RRS feed

  • Вопрос

  • После перехода с SQL 2000 на SQL 2005 время резервного копирования в тоже самое устройство увеличилось в 5 раз. Размер бэкапа тот-же.
    (Скорость выполнения бэкапа упало с 50 Мб/с до 10 Мб/с). На втором сервере точно такая-же картина, т.е. проблема не в железе.
    Упала и общая производительность системы.  Но в этом случае хоть можно сослаться на то, что какие-то запросы стали обрабатываться не оптимально.
    А почему backup стал настолько медленнее выполняться?
    Пробовал делать переиндексацию, отключал распаралеливание, гипертрейдинг - результат не меняется.
    25 августа 2009 г. 9:50

Ответы

Все ответы

  • А в какое устройство вы бэкапите?
    Подключено это устройство по сети?

    По изменению скорости выполнения бэкапа с 50 до 10 Мб/с очень похоже что у вас изменилось сетевое подключение с Gigabit Ethernet (1000 Mbit) на Ethernet (100 Mbit).


    MCITP: Database Administrator
    25 августа 2009 г. 10:32
  • Бэкап идет на тот-же диск, где лежит база. Контролер RAID 5 c пятью SAS дисками. С контролером все в порядке. Да и не могут на двух разных, но абсолютно одинаковых по конфигурации машинах одновременно с переходом возникнуть проблемы с RAID-ом. Под SQL выделено с AWE 6.5 Гб ОЗУ из 8 Гб установленных.
    SQL 2000 такая конфигурация вполне устраивала. Непонятно, чем она не нравится 2005-му :-)

    25 августа 2009 г. 10:50
  • Это плохой сценарий. Вы сознательно устраиваете себе i/o bottleneck. Вероятно, 2005 более умно приоритезирует i/o и не даёт ухудшиться response time для пользовательских запросов ценой увеличения продолжительности backup.
    Если сервер у вас под нагрузкой во время резервного копирования, то должен начинаться дикий seek. Как выглядят очереди к дискам до начала backup'а и в процессе? 
    25 августа 2009 г. 17:05
  • попробуйте провести аналогичный бэкап в сетевую папку и замерьте скорость.


    MCITP: Database Administrator
    25 августа 2009 г. 17:34
  • Это плохой сценарий. Вы сознательно устраиваете себе i/o bottleneck. Вероятно, 2005 более умно приоритезирует i/o и не даёт ухудшиться response time для пользовательских запросов ценой увеличения продолжительности backup.
    Если сервер у вас под нагрузкой во время резервного копирования, то должен начинаться дикий seek. Как выглядят очереди к дискам до начала backup'а и в процессе? 

    На сервере 2 логических диска на разных контроллерах. На С:  аппаратное зеркало с системой и логом базы. На D: RAID 5 с SQL и пользовательской базой.
    Бэкап на С , естественно сразу попробовал, как столкнулся с проблемой. Идет с нормальной скоростью 50 Мб/с. Но там нет места для бэкапов.
    В том-то и дело, что SQL 2000 такая конфигурация устраивала, а SQL 2005 тоже самое делает в пять раз медленнее.
    Тестирование провожу на резервном сервере, где никакие другие задачи не выполняются и нет подключенных пользователей.
    Очередь к диску перед началом соответственно 0, после запуска бэкапа 1.8 Сама операционка файл внутри диска D переносит со скоростью 50 Мб/с, т.е. тормоз именно в SQL .
    Если предположить, что 2005 более умно приоритезирует i/ oценой увеличения продолжительности backup, то у него должно хватить ума определить в
    данной ситуации, что других запросов к базе и даже подключенных пользователей, кроме админа нет, и не зачем тормозить бэкап.
    А если не хватает, то вот и хотелось бы получить совет, что в нем "подкрутить", чтоб больше так не умничал :-) Не покупать же в самом деле из-за этого новый сервер.
    Кстати обратил внимание, что процес бэкапа по долгу висит в режиме ожидания типа BACKUPBUFFER. Как написано в документации, "этот тип ожидания имеет
    место при ожидании задачей резервного копирования данных или буфера для их записи. Этот тип встречается редко, преимущественно при ожидании задачей монтирования магнитной ленты."
    Бэкап указан на диск, лента тут вроде не причем. Чего он ждет в таком случае, непонятно.

     

    26 августа 2009 г. 6:30
  • Попробуйте явно BLOCKSIZE в 64к указать.

    26 августа 2009 г. 12:33