Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#265<< #266 |
СОДЕРЖАНИЕ Секционированные таблицы и индексы SQL Server 2005 (продолжение)
По материалам статьи Kimberly L. Tripp:
SQL Server 2005. Partitioned Tables and Indexes Секционированные Таблицы в SQL Server 2005
В то время как усовершенствования SQL Server 7.0 и SQL Server 2000 значительно улучшили
производительность секционированных представлений, они не упрощали их администрирования,
разработки или развертывания. Все таблицы, на основе которых строилось секционированное
представление, создавались и управлялись по отдельности. Разработка приложений становилась
проще за счет того, что разработчику уже не приходилось обращаться непосредственно к
базовым таблицам, однако администрирование было затруднено, поскольку приходилось управлять
каждой отдельной таблицей, входящей в состав секционированного представления, и его
ограничениями целостности. Из-за сложностей управления, разделение таблиц зачастую
использовалось только тогда, когда данные нужно было "заархивировать" или загрузить.
Операции добавления/удаления из доступной только на чтение таблицы (read-only) были
слишком дорогостоящими - они занимали время, место в журнале транзакций, и часто
создавали блокировки.
Еще лучше обстоят дела в случае, если данные необходимо удалить. Если база данных
нуждается только в "sliding window" ("скользящее окно") наборе данных, то, когда
новые данные будут готовы к переселению (например, в текущий месяц), тогда самые
старые данные (например, данные того же месяца за предыдущий год) смогут быть удалены.
В этом случае, Вы, вероятно, добьетесь улучшения производительности от использования
секционирования на несколько порядков. Поскольку это может показаться неправдоподобным,
давайте рассмотрим имеющиеся тут отличия. А кроме того, знаете ли Вы, что использование файловых групп (filegroups) совместно с секциями является идеальным механизмом секционирования? Файловые группы позволяют Вам размещать отдельные таблицы на различных физических дисках. Если отдельная таблица располагается в нескольких файлах, благодаря использованию filegroups, то тогда фактическое расположение данных предсказать невозможно. В системах, которые не допускают параллельной обработки данных, SQL Server, благодаря применению файловых групп, улучшает производительность за счет использования всех дисков более равномерно и поэтому конкретное размещение данных в них не является столь принципиальным. На Рисунке 2 представлена файловая группа, состоящая из трех файлов. В ней располагаются две таблицы: Orders и OrderDetails. Когда данные таблиц размещаются в файловой группе, SQL Server пропорционально заполняет файлы файловой группы, захватывая в них необходимое дисковое пространство для своих объектов экстентами (кусками по 64 Kb, что равно 8 страницам данных по 8 Kb). В момент создания таблиц Orders и OrderDetails файловая группа будет пуста. Когда приходит новый заказ, в таблице Orders создается соответствующая запись, и по одной записи в таблице OrderDetails для каждого заказанного товара. SQL Server выделяет один экстент для таблицы Orders в File1, и затем еще один экстент для таблицы OrderDetails в File2. По всей вероятности, таблица OrderDetails будет расти быстрее, чем таблица Orders, и поэтому следующие несколько экстентов будут выделены для нее: следующий экстент для таблицы OrderDetails будет располагаться в файле File3. На приведенном ниже рисунке продемонстрировано размещение экстентов данных таблиц Orders и OrderDetails в файловой группе. Рисунок 2. Пропорциональное заполнение файлов SQL Server и дальше продолжит балансировать (уравновешивать) размещение всех объектов в пределах этой файловой группы. Наряду с тем, что SQL Server получает выгоду от использования большего количества дисков для данной операции, это не так оптимально с точки зрения управления или перспективы обслуживания (лишние неудобства), или для ситуации, когда модели использования достаточно предсказуемы (и обособлены). В SQL Server 2005 секционированная таблица может быть спроектирована (используя "функции" и "схемы") таким образом, чтобы строки, имеющие одинаковый ключ секционирования, размещались бы в строго указанном месте. Функция секционирования определяет границы секций и то, в какую секцию должно быть занесено первое значение. В случае LEFT-функции, первое значение будет являться верхней границей в первой секции. В случае RIGHT-функции, первое значение будет являться нижней границей во второй секции. Мы еще рассмотрим подробно особенности функций секционирования дальше в этой статье. Как только функция определена, может быть создана схема секционирования для того, чтобы определить физическое расположение секций в базе данных. Если несколько таблиц используют одну и ту же функцию (но не обязательно одну и ту же схему), строки, имеющие один и тот же ключ секционирования, будут располагаться на диске вместе. Этот принцип называется выравниванием. Выравнивая строки нескольких таблиц по ключу секционирования, SQL Server может (если оптимизатор запросов предпочтет) работать только с необходимыми группами данных (в каждой из таблиц). Для того чтобы выровняться, две секционированные таблицы или два индекса должны иметь некоторое соответствие между их соответствующими секциями. Они должны использовать "эквивалентные" функции секционирования и быть связаны по столбцам секционирования. Две функции секционирования могут использоваться для выравнивания данных, если:
Внимание! Даже если две функции секционирования рассчитаны на выравнивание данных, ваши таблицы могут остаться не выровненными из-за не выровненных индексов, если они не секционированы по тем же столбцам, что и таблицы. Локализация (Collocation) - более строгая форма выравнивания, когда два выровненных объекта объединены с предикатом equi-объединения (inner), где equi-объединение производится по столбцу секционирования. Это становится важным в контексте запроса, подзапроса или другой подобной конструкции, где могут встретиться предикаты equi-объединения. Локализация эффективна, поскольку запросы, объединяющие таблицы по столбцам секционирования, выполняются тогда значительно быстрее. Возьмем, например, таблицы Orders и OrderDetails, описанные выше. Вместо того чтобы заполнять файлы пропорционально, Вы можете создать схему секционирования, которая разнесет БД по трем файловым группам. Вы определяете таблицы Orders и OrderDetails таким образом, чтобы они использовали одну и ту же схему. Связанные данные (по ключу секционирования) будут помещены в один и тот же файла, таким образом, изолируя необходимые для объединения данные. Когда связанные строки из нескольких таблиц секционированы по одному и тому же принципу, SQL Server может объединять секции, не имея необходимости рыться во всей таблице или нескольких секциях (если к таблицам применялись разных функций секционирования) для сопоставления строк. В этом случае, объекты не просто выровнены, они, как говорится, являются выровненным хранилищем, поскольку связанные данные располагаются в одних и тех же файлах. Следующий рисунок демонстрирует, как два объекта могут использовать одну и ту же схему секционирования, когда все строки данных с одинаковым ключом секционирования окажутся в одной и той же файловой группе. Когда связанные данные выровнены, SQL Server 2005 может эффективно работать с большими наборами данных параллельно. Все данные о продажах за январь (как для Orders, так и для OrderDetails) будут располагаться в первой файловой группе, данные за февраль - во второй файловой группе и т.д. Рисунок 3. Таблицы выровненных хранилищ
SQL Server поддерживает секционирование, основанное на диапазонах. Таблицы, так же
как и индексы могут использовать одну и ту же схему для лучшего выравнивания. Хорошее
проектирование способно значительно улучшить производительность системы, но что, если
использование данных все время меняется? Что, если потребуется дополнительная секция?
Простота администрирования при добавлении и удалении секций, а также управления секциями
извне секционированной таблицы была главной целью при разработке SQL Server 2005.
Определения и терминология Чтобы создавать секции в SQL Server 2005, Вам необходимо познакомиться с несколькими новыми понятиями, терминами и синтаксисом. В предыдущих выпусках SQL Server таблица была всегда физическим и логическим понятием, теперь в SQL Server 2005 для Секционированных Таблиц и Индексов у вас есть на выбор несколько вариантов того, как и где хранить таблицу. В SQL Server 2005, таблицы и индексы могут быть созданы с точно таким же синтаксисом, как и в предыдущих релизах - как простая табличная структура, помещенная в DEFAULT filegroup или определенную пользователем файловую группу (user-defined filegroup). Кроме того, в SQL Server 2005 таблица и индексы также могут быть основаны на схеме секционирования. Схема секционирования отобразит объект на одну или возможно несколько файловых групп. Для определения того, какие данные где размещать, схема секционирования использует функцию секционирования. Функция секционирования определяет алгоритм, используемый для маршрутизации строк, а схема связывает секции с их соответствующим физическим местоположением (т.е. файловой группой). Другими словами, таблица по-прежнему является логическим понятием, но её физическое расположение на диске может радикально отличаться от более ранних выпусков SQL Server; таблица может иметь схему. Диапазонные секции Диапазонные секции - это табличные секции, описанные определенными и настраиваемыми диапазонами данных. Границы диапазонных секций выбираются разработчиком, и могут быть изменены, если изменится модель использования данных. Как правило, эти диапазоны основываются на дате или на упорядоченных группировках данных.
Основное применение диапазонных секций - архивирование данных, поддержка принятия
решений (когда зачастую необходимы только определенные диапазоны данных, например,
только заданный месяц или квартал), и объединение OLTP и DSS (Decision Support System
- система поддержки принятия решений), где использование данных меняется в течение
всего жизненного цикла записи базы данных. Самое большое преимущество новой технологии
(особенно для архивирования и обслуживания) состоит в способности манипулировать крайне
специфичными диапазонами данных. Диапазонные секции архивируют старые данные и загружают
новые чрезвычайно быстро. Секции диапазона лучше всего подходят для ситуации, когда
доступ к данным осуществляется для поддержки принятия решений и основывается на больших
диапазонах данных. В этом случае Вы заботитесь о том, где конкретно расположены данные,
так чтобы обращение велось только к подходящим секциям. Когда появляются новые бизнес
- данные, Вы естественно захотите добавлять их - легко и быстро. Рисунок 4: Диапазонная секционированная таблица - 12 Секций. Определение ключа секционирования Первый шаг в секционировании таблиц и индексов состоит в определении "ключа". Ключ секционирования - это столбец(ы) таблицы, который удовлетворяет определенным критериям. Функция секционирования определяет тип данных, на котором базируется логическое разделение данных. Физическое размещение данных определено схемой секционирования. Другими словами, схема отображает данные на файловые группы, которые в свою очередь отображают данные на конкретные файлы. Для этого схема всегда использует функцию - если функция определяет пять секции, тогда схема должна использовать пять файловых групп. Однако совсем не обязательно, чтобы все файловые группы были разными; тем не менее, Вы получите больший выигрыш в производительности, если будете использовать систему из нескольких дисков, предпочтительно многопроцессорную. При использовании схемы вы определяете столбец, который будет выступать в качестве аргумента для функции секционирования. Данные в диапазонных секциях разделены логически. Фактически, секции данных в действительности не могут быть сбалансированы вообще. Однако использование данных навязывает диапазонную секцию, поскольку модель использования этой таблицы определяет специальные границы для анализа (иначе называемые "диапазонами"). Ключ секционирования для диапазонной функции может состоять только из одного столбца, и функция секционирования будет включать всю область данных, даже если эти данные недопустимы для таблицы. Другими словами, границы определены для каждой секции, но первая и последняя секции позволят включать бесконечно малые (первая) и бесконечно большие (последняя) значения. Для секций должны быть заданы ограничения целостности CHECK для реализации Ваших бизнес-правил и обеспечения целостности данных (т.е. ограничения области данных конечным, а не бесконечным диапазоном). Диапазонные секции идеальны, когда обслуживание и администрирование требуют архивирования больших диапазонов данных на регулярной основе, и когда запросы обращаются к большим массивам данных - но только в пределах нескольких диапазонов. ПРОДОЛЖЕНИЕ СЛЕДУЕТ Использование статистики оптимизатором запросов Microsoft SQL Server 2005
По материалам статьи Eric N. Hanso: Statistics Used by the Query Optimizer in Microsoft SQL Server 2005 Microsoft SQL Server 2005 собирает статистику по индексам и полям данных, хранимых в базе. Эта статистика используется оптимизатором запроса SQL Server при выборе оптимального плана исполнения запросов на выборку или обновление данных. В этой статье описывается то, какие данные собираются сервером, где они хранятся, и какие команды нужно использовать для обновления и удаления статистики. По умолчанию, SQL Server 2005 создает и обновляет статистику автоматически, когда решит, что это будет полезным. В этой статье описано, как можно изменять заданные по умолчанию значения конфигурации сбора статистики на разных уровнях (столбец, таблица и база данных). Статистика в SQL Server 2005 Microsoft SQL Server 2005 собирает статистику для отдельных столбцов или для набора столбцов. Статистика используется оптимизатором запросов для оценки селективности выражений, определяя, таким образом, объём промежуточных и конечных выборок. Хорошие статистические данные позволяют оптимизатору точно оценивать стоимость разных планов исполнения запроса, и выбирать наиболее хороший план. Вся информация об одном объекте статистики хранится в нескольких столбцах одной записи таблицы sysindexes, и в большом бинарном объекте статистики statblob, хранящемся в одной из внутренних таблиц. Кроме того, информация о статистике может быть найдена в новых представлениях метаданных sys.stats и sys.indexes. Обзор механизмов сбора статистики
SQL Server 2005 имеет много обслуживающих статистику механизмов. Самый важный из них
- это возможность автоматически создавать и обновлять статистику. Этот механизм
задействуется по умолчанию в SQL Server 2005 и SQL Server 2000. Приблизительно 98 %
инсталляций SQL Server 2000 оставляют задействованным механизм автоматического обновления
статистики, что принято считать хорошей практикой. В большинстве приложений баз данных,
разработчики и администраторы могут положиться на автоматическое создание и обновление
статистики, которое в достаточной мере обеспечивает всестороннюю и точную статистику
данных, по которой оптимизатор запросов SQL Server 2005 выбирает хорошие планы исполнения,
и в то же время снижаются затраты на разработку и администрирование. Если же Вам нужно
в большей мере управлять созданием и обновлением статистики, чтобы получить боле
соответствующие Вашим нуждам планы исполнения запросов, или более тонко управлять
сбором статистики, Вы можете использовать ручное создание и обновление статистики.
Кроме того, SQL Server Management Studio позволяет в графическом интерфейсе просматривать и управлять объектами статистики, которые можно просматривать в Проводнике Объектов в специальной папке под каждым объектом таблицы. Новшества в статистике SQL Server 2005 В SQL Server 2005 применено множество влияющих на статистику новшеств, которые позволяют оптимизатору запросов улучшить выбор плана исполнения запроса за счёт анализа более широкого диапазона запросов, или же предоставить возможность более тонко управлять сбором статистики. Можно выделить следующие новшества:
Также в новой версии есть и некоторые другие, менее значительные изменения в поведении механизмов сбора статистики. В частности, поле statblob в sys.sysindexes теперь всегда устанавливается в NULL, а сам statblob хранится в скрытой, внутренней таблице каталога. Определения В этой главе определяются термины, применяемые при описании статистики SQL Server 2005:
ПРОДОЛЖЕНИЕ СЛЕДУЕТ Статьи на русском языке
Версионная эпидемия Visual Studio 2005
Measure Expressions Самые популярные темы недели
Кто на чем пишет клиентов под SQL Server?
SQL Mail, ошибка 22022 |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться
Вспомнить пароль |
В избранное | ||