Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#214<< #215 |
СОДЕРЖАНИЕ
Операции с большими объемами данных в SQL Server (начало)
По материалам статьи
Joe Chang
Large Data Operations in SQL Server В статьях серии Анализ производительности рассматривались формулы внутренних затрат ресурсов, использующиеся в оптимизаторе запросов SQL Server для определения плана выполнения и сами затраты ресурсов на выполнение запросов для конфигураций с данными в памяти. Предыдущие статьи ограничились анализом затрат ресурсов на выполнение запросов для случаев, когда все нужные данные находятся в памяти, так что производительность не ограничивалась конфигурацией диска. Эта статья дает представление о запросах, работающим с объемом данных, большим, чем доступная память, и запросах, выполняющих операции записи, где производительность ограничена конфигурацией диска. Пример, представленный в этой статье, показывает, что формулы внутренних затрат ресурсов SQL Server для операций ввода-вывода основаны на времени доступа к диску. Величины затрат ресурсов на операции ввода-вывода были зафиксированы несколько лет назад. Они неточно отражают производительность современных дисков, как и действительные затраты ресурсов на операции в памяти. Кроме того, модель затрат ресурсов на выполнение запросов SQL Server не совсем аккуратно отражает затраты ресурсов на операции ввода-вывода для Insert, Update и Delete (IUD). Для операций с небольшим количеством строк разница между внутренней моделью затрат ресурсов SQL Server и действительными затратами на выполнение запросов незначительно влияет на эффективность плана выполнения. В операциях с большим количеством строк план по умолчанию может работать существенно медленнее, чем план выполнения для определенного количества операций ввода-вывода. Обзор формул оценки затрат ресурсов для построения плана выполнения Для начала, может оказаться полезным обзор формул оценки затрат ресурсов для построения плана выполнения SQL Server, рассмотренных в статьях серии 'Анализ производительности'. Формула оценки затрат ресурсов на операцию Index Seek показана ниже. Затраты ресурсов на ввод-вывод зависят от количества физической памяти. Затраты ресурсов на ввод-вывод (I/O Cost) = 0.006328500 + 0.000740741 на каждую следующую страницу (до 1GB) или 0.003203425 + 0.000740741 на каждую следующую страницу (больше 1GB) Затраты ресурсов процессора (CPU Cost) = 0.000079600 + 0.000001100 на каждую следующую строку Формула оценки затрат ресурсов для множества операций Bookmark Lookup показана ниже. Затраты ресурсов на ввод-вывод (I/O Cost) = сумма значений 0.006250000 для всех операций (до 1GB) сумма значений 0.003124925 для всех операций (больше 1GB) Затраты ресурсов процессора (CPU Cost) = 0.0000011 на строку Множество операций Bookmark Lookup - это не точное количество строк, а часть этого количества, обычно >95% от большого количества строк. Для обеих операций Index Seek и Bookmark Lookup базовые затраты ресурсов на ввод-вывод зависят от конфигурации памяти компьютера. Если объем памяти меньше или равен 1 гигабайту, то базовые затраты ресурсов для Index Seek составляют 0.063285. Если объем памяти больше 1 гигабайта, то затраты ресурсов на ввод-вывод составляют 0.003203425. Все другие затраты ресурсов на ввод-вывод не зависят от системной памяти (если только не используется неявным образом поиск по индексу). Ниже показана формула оценки затрат ресурсов на операцию Table Scan, хотя она также может применяться для сканирования кластерных и некластерных индексов. Затраты ресурсов на ввод-вывод (I/O Cost) = 0.0375785 + 0.000740741 на каждую следующую страницу Затраты ресурсов процессора (CPU Cost) = 0.0000785 + 0.0000011 на каждую следующую строку Для всех операций изменения содержимого таблицы - Insert, Update и Delete (IUD) - затраты ресурсов на ввод-вывод примерно соответствуют формулам, приведенным ниже. Затраты ресурсов процессора точно соответствуют формуле. Общие затраты ресурсов на операции Update и Delete включают затраты на поиск по индексу или на сканирование таблицы, но они могут быть не включены в отдельные значения затрат ресурсов на ввод-вывод и затрат ресурсов процессора. Затраты ресурсов на ввод-вывод (I/O Cost) ~ 0.01002 - 0.01010 (>100 строк) Затраты ресурсов процессора (CPU Cost) = 0.000001 на каждую строку Интересный момент заключается в том, что затраты ресурсов на ввод-вывод для операций IUD фиксированные, несмотря на количество строк и страниц. Сравните это с затратами ресурсов на ввод-вывод для операций Index Seek, Bookmark Lookup и Table Scan, которые зависят от количества страниц. Похоже, не существует никакой документации от Microsoft о единицах измерения затрат ресурсов плана выполнения SQL Server. Единица измерения может быть некой величиной времени или загрузки процессора. Статья 'Параллельные планы выполнения' показывает, что единица измерения является скорее категорией времени, чем загрузки процессора. В качестве основного доказательства этого утверждения можно привести то, что план выполнения с параллельными операциями требует меньше затрат ресурсов, чем эквивалентный план с непараллельными операциями. Логическим объяснением может быть то, что параллельные операции на двухпроцессорных компьютерах выполняются за половину времени плюс некоторые затраты времени на объединение результатов от каждого процессора. Если бы единицей измерения для плана выполнения выступала загруженность процессора, то параллельная операция показала бы более высокие затраты ресурсов. Это связано с тем, что разделение задачи между двумя процессорами не сократит общую сумму циклов процессора, и еще понадобятся дополнительные затраты ресурсов на объединение результатов. Если предположить, что затраты ресурсов плана выполнения SQL Server измеряются единицами времени, то можно сделать следующее предположение, что единицей измерения является секунда. Значения затрат ресурсов не зависят от типа процессора и они не изменились при переходе с SQL Server 7.0 на 2000. Можно предположить, что затраты ресурсов были настроены на некой системе, когда SQL Server 7.0 был в разработке, где-то между 1995 и 1997 годами. Обоснованием этого периода является то, что среда, на которой были настроены единицы затрат ресурсов SQL Server, была базой данных с объемом данных, намного превышающим доступную системную память. В этом случае операции SQL часто сопроаождались бы операциями дисковыми ввода-вывода. Для современного диска со скоростью 15K затраты ресурсов ввода-вывода для Index Seek в 0.0063285 секунды (или 6.33мс) являются достаточно произвольным временем доступа. Хотя этот результат и является чрезмерно низким для дисков со скоростью вращения 7200 RPM, доступных в середине 1990-х годов. Возможно, что был установлен коэффициент кэша буфера в 50% для затрат ресурсов на ввод-вывод для операций Index Seek и Bookmark Lookup для систем с памятью меньше 1 гигабайта и 75% для систем с памятью больше 1 гигабайта. Однако нет нужды ограничиваться только двумя возможными вариантами единиц измерения затрат ресурсов на ввод-вывод. Дополнительные затраты ресурсов на ввод-вывод в 0.0007407 на каждую страницу могут быть объяснены как время последовательного ввода-вывода (0.74мс), подразумевая, что скорость последовательной передачи данных диска равна 1350 операций ввода-вывода в секунду по 8KB каждая или 169 операций ввода-вывода в секунду по 64KB. Вообще-то, память системы не может быть надежным показателем для коэффициента кэша буфера. Лучшей стратегией для настройки затрат ресурсов на ввод-вывод могло быть использование недавней истории коэффициента кэша буфера. Для операций с большим количеством строк также имеет смысл определить, сколько из необходимого количества данных уже находится в памяти. Тестовая среда Сервером тестовой среды является двухпроцессорный Xeon 2.4GHz/512K кэш, системная шина 533MHz и 2 гигабайта памяти на материнской плате с чипсетом ServerWorks GC-LE. Файл данных тестовой базы данных находится на двух 18-гигабайтных SCSI U160 дисках со скоростью вращения 15K, все log файлы находятся на одном SCSI диске со скоростью вращения 10K, а файл данных базы tempdb находится на диске IDE/ATA. Модель восстановления базы данных установлена в SIMPLE и 4 гигабайта дискового пространства заранее распределены для данных и лога. Кроме того, максимальный уровень параллельности был ограничен в большинстве тестов одним процессором. Результаты являются измерениями времени выполнения единственного запроса. Существуют некоторые отличия между измерениями, т.к. нет никакого простого способа определить содержание кэша буфера. Была сделана попытка произвести оценку с повторяющимися значениями. Следующий скрипт создает тестовую таблицу и заполняет ее тестовыми данными. Таблица содержит 8 столбцов типа integer по 4 байта каждый, столбец типа char из 10 байт, столбец типа decimal из 5 байт, и 3 других столбца по 8 байт каждый, в сумме составляющие 71 байт. Вместе с метаданными все это требует примерно 81 байт на строку, позволяя 99 строкам поместиться в каждую 8-килобайтную страницу с коэффициентом заполнения 99%, оставляя свободными 77 байт. CREATE TABLE M3C_00 ( ID int NOT NULL, ID2 int NOT NULL, ID3 int NOT NULL, ID4 int NOT NULL, ID5 int NOT NULL, ID6 int NOT NULL, SeqID int NOT NULL, DistID int NOT NULL, Value char(10) NOT NULL, randDecimal decimal (9,4) NOT NULL, randMoney money NOT NULL, randDate datetime NOT NULL, seqDate datetime NOT NULL ) Следующий скрипт заполняет таблицу 10 миллионами строк. Столбец ID - это последовательность от 1 до 10 миллионов, но он не объявлен явно как столбец типа identity. Столбцы с ID2 по ID6 не важны в этих сериях тестов, и в них могут быть использованы любые значения. Значения столбца SeqID последовательны, а значения столбца DistID разнесены по таблице. В этом примере таблица имеет 10 миллионов строк. Первые 100 000 строк имеют значение столбца SeqID, равное 1; следующие 100 000 имеют значение столбца SeqID, равное 2, и т.д. Первая строка имеет значение столбца DistID, равное 1; следующая строка со значением столбца DistID - строка 101, и т.д. Все строки с определенным SeqID являются смежными строками. Все строки с определенным значением DistID разделены 100 строками, что приводит к тому, что каждое отдельное значение DistID находится в отдельной 8-килобайтной странице. Таблица не кластерная, поэтому т.к. нет гарантии определенного размещения строк, то строки вставляются последовательно. BEGIN TRANSACTION DECLARE @I int, @rowCnt int, @p int, @sc1 int, @dv1 int SELECT @I = 1, @rowCnt = 10000000, @p =100, @sc1 = 100000 SELECT @dv1 = @rowCnt/100000 WHILE @I <= @RowCnt BEGIN INSERT M3C_00 (ID, ID2, ID3, ID4, ID5, ID6, SeqID, DistID, Value, randDecimal, randMoney, randDate, seqDate) VALUES ( @I, @I, @I/2, @I/4, @I/10, @I/20, (@I-1)/@sc1 + 1, -- Последовательные значения (@I-1)%(@dv1) + 1, -- Разнесенные значения CHAR(65 + 26*rand())+CHAR(65 + 26*rand())+CHAR(65 + 26*rand()) +CONVERT(char(6),CONVERT(int,100000*(9.0*rand()+1.0)))+CHAR(65 + 26*rand()), 10000*rand(), 10000*rand(), DATEADD(hour,100000*rand(),'1990-01-01'), DATEADD(hour,@I/5,'1990-01-01') ) SET @I = @I+1 END COMMIT TRANSACTION CHECKPOINT Этот скрипт требует 17 минут 45 секунд для выполнения, вставляя в среднем 9380 строк в секунду. Таблица M3C_00 заканчивается на 105 264 странице со степенью заполнения 95%. Несмотря на генерацию таблицы каждый раз, когда нужен свежий набор данных, исходный набор данных сохранен в таблице M3C_00 и копия исходного набора создается при помощи команды SELECT INTO, показанной ниже. SELECT ID,ID2,ID3,ID4,ID5,ID6,SeqID,DistID,Value,randDecimal,randMoney,randDate,seqDate INTO M3C_01 FROM M3C_00 CHECKPOINT Эта таблица имеет 101 012 страниц, примерно 99 строк на страницу со степенью заполнения 99%, и размера чуть больше 789 мегабайт. Команда SELECT INTO выполняется примерно 28 секунд, вставляя в среднем 357 000 строк в секунду. Следующие 2 индекса создаются на столбцах SeqID и DistID. Каждый индекс занимает 18 554 страницы или 145 мегабайт. CREATE INDEX IX_M3C_01_Seq ON M3C_01 (SeqID) WITH SORT_IN_TEMPDB CHECKPOINT CREATE INDEX IX_M3C_01_Dist ON M3C_01 (DistID) WITH SORT_IN_TEMPDB CHECKPOINT Первый индекс требует примерно 30 секунд для создания с использованием памяти в 256 мегабайт, а второй требует 60 секунд. (Продолжение следует) Статьи на русском языке
Пять заблуждений связанных с .NET
Lookup Table Madness Самые популярные темы недели
Кто на чем пишет клиентов под SQL Server?
Не могу составить запрос
|
http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться |
В избранное | ||