Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#116<< #117 |
СОДЕРЖАНИЕ
Тюнинг подсистем I/O для SQL Server Статья посвящена вопросам мониторинга семи основных счётчиков эффективности работы MS SQL Server. При установке SQL Server в Performance Monitor добавляются его специфические счетчики эффективности. Вы можете использовать их вместе с привычными счетчиками Win2K или NT, чтобы отслеживать производительность системы при изменении нагрузки. Чтобы устанавливать точку отсчёта, начинайте контроль счётчиков, когда система не испытывает пиковых нагрузок. Представленные в этой статье семь наиболее важных счетчиков помогут Вам быстро оценить производительность вашей системы с SQL Server и получить общее представление о её состоянии. Счетчик Bytes Total/sec, который находится среди объектов Network Interface, может помочь Вам определить, является ли сетевой адаптер узким местом. Сравните значение этого счётчика с максимальной пропускной способностью вашей сетевой платы. Вообще, этот счётчик должен показать не более 50% утилизации пропускной способности сетевого адаптера. Этот счетчик, расположенный среди объектов SQL Server: Memory Manager, показывает общую сумму динамически выделяемой памяти в килобайтах. Необходимо увеличить размер памяти, если среднее значение этого счётчика постоянно выше, чем доступное количество физической памяти в системе. (Замечание автора перевода: эта рекомендация не относится к тем случаям, когда для SQL Server установлен максимальный, фиксированный размер занимаемой им оперативной памяти). Этот счетчик показывает эффективность дисковой подсистемы и расположен среди объектов PhysicalDisk. Средняя длина очереди диска - это среднее общее количество запросов на чтение и на запись, которые были поставлены в очередь для соответствующего диска в течение интервала измерения. Согласно рекомендациям Microsoft, среднее число запросов ожидающих I/O не должно быть больше, чем в 1,5 - 2 раза числа шпинделей физических дисков. (Замечание автора перевода: по-видимому, автор статьи имеет ввиду значение с учётом масштаба по умолчанию для этого счётчика, т.к. на графике представляются умноженные на 100 значения). Если значения этого счётчика постоянно выше рекомендованных, Вы можете поднять производительность дисковой подсистемы установим более быстрые диски или увеличив их количество. Этот счетчик среди объектов SQL Server: Cache Manager показывает, может ли SQL Server размещать полностью планы исполнения запросов в кэше процедур. В идеале, это значение должно всегда быть выше 85 процентов. Если Вы наблюдаете снижение среднего значения этого счётчика, рассмотрите возможность добавление ОЗУ или оптимизации ваших запросов. Счетчик Buffer Cache Hit Ratio среди объектов SQL Server: Buffer Manager показывает, насколько полно SQL Server может разместить данные в буфере кэша. Чем выше это значение, тем лучше, т.к. для эффективного обращения SQL сервера к страницам данных, они должны находиться в буфере кэша, и операции физического ввода-вывода (I/O) должны отсутствовать. Если Вы наблюдаете устойчивое снижение среднего значения этого счётчика, рассмотрите возможность добавление ОЗУ. Счетчик Pages/Sec, расположенный среди объектов Memory, показывает число страниц, которые SQL Server считал с диска или записал на диск для того, чтобы разрешить обращения к страницам памяти, которые не были загружены в оперативную память в момент обращения. Эта величина является суммой величин Pages Input/sec и Pages Output/sec, а также учитывает страничный обмен (подкачку/свопинг) системной кэш-памяти для доступа к файлам данных приложений. Кроме того, сюда включается подкачка не кэшированных файлов, непосредственно отображаемых в память. Это основной счетчик, за которым следует следить в том случае, если наблюдается большая нагрузка на использование памяти и связанный с этим избыточный страничный обмен. Этот счётчик характеризует величину свопинга и его нормальное (не пиковое) значение должно быть близко к нолю. Увеличение свопинга говорит о необходимости наращивания ОЗУ или уменьшения числа исполняемых на сервере прикладных программ. Один из наиболее жизненно-важных счетчиков, который необходимо контролировать, это счетчик % Processor Time среди объектов Processor. Этот счетчик показывает процентное отношение времени, которое процессор был занят выполнением операций для не простаивающих потоков (non-Idle thread). Эту величину можно рассматривать как долю времени, приходящегося на выполнение полезной работы. Каждый процессор может быть назначен простаивающему потоку, который потребляет непродуктивные циклы процессора, не используемые другими потоками. Для этого счётчика характерны непродолжительные пики, которые могут достигать 100 процентов. Однако, если Вы видите продолжительные периоды, когда утилизация процессора выше 80 процентов, ваша система будет более эффективной при использовании большего числа процессоров. Краткие рекомендации по настройке и оптимизации репликации транзакций
По материалам статьи Bren Newman, Xavier Schildwachter и Greg Yvkoff
Transactional Replication Performance Tuning and Optimization Эта статья посвящена повышению производительности и эффективности репликации транзакций MS SQL Server.
Повышение производительности репликации Вы можете увеличить производительность всех типов репликации, если будете следовать следующим рекомендациям:
· Оптимизируйте при разработке вашу БД и с точки зрения репликации.
Повышение производительности репликации транзакций Вы можете увеличить производительно репликации транзакций, если будете следовать следующим рекомендациям:
· Используйте постоянно запущенный Distribution Agent вместо запуска агента по расписанию.
Повышение производительности при применении первоначального моментального снимка Применение первоначального снимка может занимать довольно-таки значительное количество времени, особенно если вы переносите большой объем данных по сети или у вас низкое качество соединения. Следующие примеры показывают увеличение производительности Shapshot-агента при оптимизации параметра -MaxBCPThread и при использование параметра -UseInprocLoader
Использование параметра -MaxBCPThread
В репликации транзакций, параметр -MaxBCPThread может быть применен как к Shapshot-агенту, так и к Distribution-агенту.
Данный параметр указывает количество параллельно выполняемых операций bulk-copy. Максимальное количество потоков и
ODBC-соединении, которые могут быть выполнены одновременно - это и есть значение параметра -MaxBCPThread.
Публикация №1
Генерация начального снимка Shapshot Agent'ом Следующие данные были получены на двухпроцессорном сервере: 450 Mhz Xeon, RAM 256Mb. При установленном значение параметра -MaxBCPThreads в "7", время генерации снимка в 1.6 раза происходит быстрее, чем когда данный параметр имеет значение равное "1". На однопроцессорной машине, использование значение "7" для параметра -MaxBCPThreads ускорило генерацию снимка в 1.27 раза относительно результата для значения равного "1". Установка значения "7" на однопроцессорной системе не дает существенных преимуществ, и только больше загружает процессор.
Применение начального снимка Distribution Agent Следующие данные показывают, что на двухпроцессорной машине, при использование значения "7" для параметра -MaxBCPThreads, применение начального снимка происходит в 1.3 раза быстрее, чем при использовании значения равное "1". На однопроцессорной машине, CPU является, скажем так, "узким местом" и изменение данного значения не даст прироста в производительности. При использование значения "7" для параметра -MaxBCPThreads, применение снимка происходит в 1.3 раза быстрее, чем при использовании значения равного "1". Использование двухпроцессорной машины, несомненно, дает больше прирост производительности, чем использование однопроцессорной машины. Применение снимка происходит в 1.75 раз быстрее, чем на однопроцессорной машине.
Использование параметра -UseInprocLoader Данный параметр может быть использован Distribution-агентом во время применения снимка на подписчике. Когда используется указанный параметр, Distribution-агент будет использовать BULK INSERT операции, что уменьшает время, необходимое для применения первоначального снимка на подписчике. Для увеличения производительности репликации в дальнейшем используйте параметр -UseInprocLoader совместно с параметром -MaxBCPThread. Следующий пример показывает публикацию, включающую в себя 10 статей общим объемом 46 мегабайт.
Публикация №2
Когда вы используете только параметр -UseInprocLoader, снимок применяется в 1.4 раза быстрее, чем без использования данного параметра. Когда -UseInprocLoader используется совместно с параметром -MaxBCPThread с установленным значением равным "5", снимок применяется в 2.1 раза быстрее. Время применения снимка на подписчике
В последнем примере вы можете наблюдать явное увеличение производительности. По умолчанию, данный параметр не
используется, потому что он негативно влияет на количество свободной памяти на издателе и пропускную способность
сети. Для начала я бы рекомендовал использовать данный параметр для подписчика с небольшим кол-вом публикаций и
некоторое время понаблюдать за работой сервера. Я использовал данный параметр для подписчика с 2-мя публикациями
по 3 таблицы в одной публикации и с 1 таблицей во второй публикации. При этом количество появления интернет-заказов
в минуту для нашей системы увеличилось приблизительно в 3-3.5 раза. То есть, если раньше время появления заказа в
системе шло со скоростью 1 заказ в 2 минуты (причем по так и не выясненным причинам), то на данный момент это происходит
со скоростью 2-3 заказа в 1 минуту.
Использование сжатых моментальных снимков Использование данной опции рекомендуется, когда вы используете pull или удаленного push подписчика. Эта опция также предоставляет дополнительные возможности, когда вы используете для размещения снапшотов FTP. Сжатие файлов моментальных снимков в указанном для хранения снимков пути может уменьшать размер дискового пространства, необходимого для хранения файлов снимков и, в некоторых случаях, может увеличить производительность, когда есть необходимость передать файл снимка по линии с низким качеством связи. Однако, сжатие файлов снимков требует дополнительного расхода ресурсов системы при создании и применении файла моментального снимка. А это, соответственно, может привести к увеличению времени генерации и применения снимка. В публикации №2, состав которой был приведен выше, Shapshot-агент создаёт 20 файлов, включая файлы со схемами данных и файлы данных, общий размер которых составит 130 мегабайт. Если Вы используете сжатие указанных файлов, Shapshot-агент создаст .cab файл размером около 65 мегабайт, фактически подписчику нужно загрузить вдвое меньший файл. Несмотря на это, для хранения сжатых файлов снимков требуется больше места на диске. Сжатые снимки могут занимать больше места на дистрибуторе (сохраняется и сжатый снимок, и обычный снимок), также время генерации файла снимка увеличивается приблизительно в 4.5 раза по сравнению со временем, необходимым для генерации несжатого файла снимка, т.к. оно расходуется на сжатие файла снимка.
Использование параллельных процессов для генерации снимка
Когда Вы используете установки по умолчанию для генерации файла снимка, SQL Server накладывает разделяемую блокировку
на все таблицы, включенные в статью для репликации. Это предотвращает изменение данных во время генерации файла снимка.
При параллельных процессах генерации снимка (доступно только для репликации транзакций) также происходит наложение
разделяемой блокировки, но на непродолжительное время, т.е. все пользователи могут спокойно продолжать работать с
данными. Отечественные статьи
Самообслуживание в
информационных системах Новые технические статьи Microsoft
BUG:
Cannot Upload Null Values in Sql_variant Data Type by Using SQL Server CE Merge
Replication
Alternatives to SQL Backups
Человек несовершенен. И это явственно прослеживается в историях взаимоотношений администраторов баз данных и Microsoft
SQL Server. Забытое сделаться вовремя архивирование базы - типичный наглядный пример такого несовершенства. Что здесь
сыграло, забывчивость, случай или "авось", уже становиться совершенно неважным в ситуации, когда администратор остается
один на один с убитым диском, на котором располагался журнал транзакций, единственным сохранившимся файликом MDF и
статусом базы "suspect". Ощущая холодные мурашки, администратор явственно себе представляет сколько важных
данных оказалось положено на алтарь нерадивости, какие это может иметь последствия лично для него, и лихорадочно
пытается найти выход из создавшегося положения. Обращения на форумы к коллегам и (как заключительный этап) поиски в
документации дают ценнейшую пищу к дальнейшим размышлениям: наличие в составе MSSQL гениальных по абсолютной
бесполезности процедур sp_resetstatus и sp_attach_single_file_db. Танцы с бубном и шаманские заклинания не уменьшают
безрезультативность конвульсивных попыток использования этих средств. Зато количество вышеупомянутых мурашек начинает
возрастать, так как других средств восстановить данные (хотя бы по большей части) первоисточники больше не упоминают.
Практически безвыходная ситуация до недавнего времени. Теперь же появилось средство, помогающее в такой безнадежной
ситуации - новая утилита, с которой можно познакомиться на сайте http://forcedattach.nm.ru Самые популярные темы недели
Линк
к гадскому ORACLE... Выполнение "его" процедур?!?
MSSQL
<-> MySQL - автоматическая репликация? [new]
|
#116<< #117 |
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
В избранное | ||