Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
← Октябрь 2004 → | ||||||
2
|
3
|
|||||
---|---|---|---|---|---|---|
4
|
5
|
6
|
8
|
9
|
10
|
|
11
|
12
|
13
|
14
|
16
|
17
|
|
18
|
19
|
20
|
21
|
22
|
23
|
|
25
|
26
|
27
|
28
|
29
|
30
|
31
|
Статистика
-20 за неделю
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#217<< #218 |
СОДЕРЖАНИЕ Репликация & Особенности разработки приложений
Дата: 12.10.2004г. 18:30 1. Создание глобализованного кода и SQL Server. Алексей Халяко 2. Обзор репликации SQL Server 2000. Александр Гладченко Для регистрации на семинар, пришлите письмо в свободной форме на адрес mssqlhelp@rambler.ru, с указанием Вашей фамилии, имени и отчества (полностью). Количество мест в аудитории семинара ограничено, поэтому прошу Вас не откладывать регистрацию. За день до даты проведения семинара, всем кто был успешно зарегистрирован, по электронной почте придёт письмо с подтверждением регистрации. Для того, что бы пройти в помещение проведения семинара, при себе необходимо иметь паспорт или другое удостоверение личности. Карта проезда в представительство Microsoft
Операции с большими объемами данных в SQL Server. Часть 2 (окончание)
По материалам статьи
Joe Chang
Large Data Operations in SQL Server Операции поиска по индексу и сканирования таблицы являются аналогами предыдущих запросов Select и Update. Операции Top в каждой из двух команд Delete также идентичны операциям в соответствующих командах Update. В отличие от Update, команда Delete не имеет операции Compute Scalar. Однако поиск по индексу требует 0.250619 затрат, Top добавляет 0.010000, получая в сумме 0.260619, Table Delete добавляет 0.110068, однако общие затраты операции Table Delete получаются равными 0.380687, т.е. в них каким-то образом попали дополнительные 0.010000. Операция Table Delete имеет фиксированную величину затрат ввода-вывода в 0.010068, независимо от количества используемых страниц и строк.
Затраты на операции Table Spool объяснить сложнее. Операции в обоих запросах показывают затраты ввода-вывода в 0.931 и загрузку процессора в 0.0188, но Spool вверху показывает общие затраты в 0.768492, а Spool внизу показывает общие затраты в 1.149179. Обе операции Spool показывают полные затраты в 1.149179.
Верхний Spool для плана выполнения команды Delete с использованием поиска по индексу.
Нижний Spool для плана выполнения команды Delete с использованием поиска по индексу. Затраты на Table Delete и верхний Table Spool действительно добавляются к полным затратам в 1.149179, но тогда нет никакого видимого объяснения, как затраты ввода-вывода и загрузка процессора для нижнего Table Spool приводят к тем же полным затратам. Каждый Index Delete показывает затраты ввода-вывода в 0.0100125 и загрузку процессора в 0.100000, что несколько меньше, чем затраты ввода-вывода, и равно загрузке процессора для Table Delete. Обе операции Index Delete показывают полные затраты, равные 1.2591919.
Верхний Index Delete.
Нижний Index Delete. Последняя операция SQL - это Sequence, которая показывает нулевые затраты ввода-вывода и загрузку процессора, равную 0.200000. Общие затраты равны 2.7183836, предыдущие операции внесли 2.5183836 из общих затрат, оставляя по 1.2591919 на каждый из Index Delete.
Это не очевидно, но вполне может быть, что затраты на операции, предшествующие операциям Table Spool, делятся поровну в общих затратах каждой операции Table Spool. Поэтому значения затрат добавляются не точно, а достаточно приблизительно. Следующая таблица показывает измеренное время на выполнение команды Delete для обоих планов выполнения и обоих поисковых аргументов. План выполнения, использующий поиск по индексу, не учитывает затраты на получение строк и страниц данных, но измеренные затраты ясно показывают, что эти затраты входят в затраты реального плана выполнения. Неясно, почему сканирование таблицы, которое удаляет последовательные строки, требует большего времени, чем сканирование таблицы, удаляющее разнесенные строки. Когда все данные находятся в памяти, план выполнения с поиском по индексу оказывается немного быстрее сканирования таблицы. Операция Checkpoint выполняется очень быстро, если были изменены только несколько страниц данных, и выполняется медленнее, если все страницы были изменены, что ожидаемо.
Ниже показан план выполнения команды Delete для этой же таблицы без индексов. Затраты на выполнение операций внутри команды такие же, как у таких же операций в рассмотренных выше планах выполнения.
Ниже показаны измеренные затраты времени на выполнение запроса и команды Checkpoint для удаления 100 000 строк из таблицы с 10M строк и 101 012 страниц.
Как и ожидалось, операция Delete на таблице без индексов (которая должна использовать сканирование таблицы) работает быстрее, чем операция Delete, которая использует план выполнения со сканированием таблицы и должна также удалять данные из индексов. Однако разница в затратах между этими двумя операциями, учитывая затраты на удаление данных из индексов, небольшая, кроме необычного поведения при удалении последовательных строк, включающем сканирование таблицы с диска. Есть мнение, что намного быстрее обновлять или удалять большое количество строк, удаляя существующие индексы, обновляя или удаляя данные из таблицы без индексов, а затем пересоздавая индексы, чем обновлять или удалять данные из таблицы с индексами. Теперь видно, что причиной такого мнения является то, что план выполнения не учитывает затраты на получение страниц данных и использует план выполнения с поиском по индексу тогда, когда план выполнения со сканированием таблицы гораздо более эффективен. Время построения двух индексов, использованных в примерах, составляет в сумме около 90 секунд (30 секунд для SeqID и 60 секунд для DistID). Команды Update и Delete на таблице с индексами с использованием хинта сканирования таблицы в большинстве случаев работают быстрее, чем удаление индексов перед командами Update или Delete и последующее пересоздание этих индексов. На сервере с 256 мегабайтами памяти время выполнения запроса Delete несколько больше, чем время выполнения запроса Select, для последовательных строк, и примерно в 2.5 раза больше для разнесенных строк. Время выполнения команды Checkpoint очень незначительно для последовательных строк, где задействовано небольшое количество страниц (1010 страниц данных и 185 страниц индексов) и более существенно, если требуется записать на диск большое количество страниц. Заключение Несколько важных заключений могут быть сделаны после рассмотрения планов выполнения SQL Server и действительных затрат на выполнение запросов для конфигурации с данными в памяти и конфигурации с интенсивным обменом с диском. Есть хорошие основания полагать, что единицами измерения значений затрат плана выполнения SQL Server являются секунды, и что эти значения по крайней мере частично основаны на операциях с диском. Значения затрат были зафиксированы еще во время SQL Server 7.0 и с тех пор не обновлялись. Оптимизатор запросов SQL Server недооценивает скорость последовательной передачи данных современных дисков по сравнению с произвольным дисковым вводом-выводом. Когда данные находятся в памяти, затраты Bookmark Lookup на строку меньше, чем затраты сканирования таблицы на страницу. Время выполнения запроса будет сильно зависеть от того, находятся ли данные в памяти или необходимы дисковые операции. Для операций с интенсивной работой с диском также важна производительность диска при последовательных и произвольных операциях ввода-вывода. Современные технологии позволяют диску с частотой вращения 7200RPM иметь такую же производительность при последовательной передаче данных, как у диска с частотой вращения 15K, но однако вдвое меньшую производительность при произвольных операциях ввода-вывода. В принципе, можно получить намного лучший план выполнения в определенных случаях, если можно определить, что данные уже находятся в памяти. Даже менее аккуратная оценка с использованием Buffer Cache Hit Ratio и оценка размера данных, относящаяся к Target Server Memory, должны давать лучший план выполнения, чем жестко фиксированные оценки, основанные только на системной памяти. Наиболее важным заключением является то, что операции SQL Server Insert, Update и Delete могут неправильно рассчитывать полные затраты на операции ввода-вывода. Это может приводить к тому, что команды Update и Delete начинают использовать план выполнения с поиском по индексу в случаях, когда он гораздо менее эффективен, чем план выполнения со сканированием таблицы. Необязательно удалять индексы перед выполнением массивных удалений и затем пересоздавать их. Простое указание хинта сканирования таблицы является лучшим решением во многих случаях. Статьи на русском языке
Компоненты для доступа к БД
MDX in Analysis Services: Mastering Time: Moving Averages - Another Approach Самые популярные темы недели
Кто на чем пишет клиентов под SQL Server?
Вопрос про распределенные транзакции и TSQL
|
Вопросы, предложения, коментарии, замечания, критику и т.п. присылайте Виталию Степаненко и Александру Гладченко
|
http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться |
В избранное | ||