Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#264<< #265 |
СОДЕРЖАНИЕ Секционированные таблицы и индексы SQL Server 2005
По материалам статьи Kimberly L. Tripp:
SQL Server 2005. Partitioned Tables and Indexes Не смотря на то, что секционированные таблицы и индексы всегда были неотъемлемой частью больших баз данных, призванной улучшать их производительность и управляемость, в Microsoft SQL Server 2005 появились новые возможности, упрощающие процесс разработки таких решений. Данный доклад посвящен эволюции секционирования таблиц в SQL Server: от ручного секционирования данных путем предварительного создания таблиц в качестве подготовительного шага (в SQL Server 7.0 и SQL Server 2000) до процедур реального секционирования таблиц. В SQL Server 2005 новые табличные функции секционирования значительно упрощают разработку и администрирование секционированных таблиц, в месте с тем еще более увеличивая их производительность. Основная задача статьи - составить для Вас представление о секционировании в SQL Server 2005, о том зачем, где и как применять его с большей пользой для Ваших сверхбольших баз данных (VLDB - Very Large Database). Но несмотря на то, что секционирование в SQL Server 2005 нацелено прежде всего на работу с VLDB, следует помнить, что не все базы данных большие с самого начала. SQL Server 2005 обеспечивает гибкость и производительность, значительно упрощая создание и обслуживание секционированных таблиц. Прочтите эту статью, чтобы получить подробную информацию о том, почему Вам стоит знать о секционированных таблицах, что они могут Вам предложить, и, наконец, как разрабатывать, реализовывать и обслуживать секционированные таблицы. Материалы к статье: Все примеры, демонстрируемые в данной статье, Вы сможете скачать здесь: SQLServer2005PartitionedTables.zip Для чего нужно секционирование?
Прежде, чем говорить о том, как осуществлять секционирование и использовать его возможности,
сначала нужно понять, насколько оно необходимо, что такое секционирование и кому стоит
его использовать? Когда Вы создаете таблицы, Вы проектируете их таким образом, чтобы
хранить информацию о сущностях, например, о покупателях или продажах. Каждая таблица
должна иметь атрибуты, которые описывают только эту сущность, и, например, для всех
покупателей и продаж исторически сложилось так, что все Ваши покупатели и все Ваши
продажи создаются в соответствующих таблицах. История секционирования Концепция секционирования для SQL Server не нова. По сути, секционирование в разных формах присутствовало в каждом релизе. Однако, без функций, помогающих в создании и поддержке вашей схемы секционирования, секционирование было неудобным. А, как правило, если инструмент неудобен в работе, то и преимущества от технологии уменьшаются. Тем не менее, из-за существенного выигрыша в производительности, присущего секционированию, с SQL Server 7.0 началось его усовершенствование, от секционированных представлений, поддерживавших некоторые формы секционирования, до наиболее усовершенствованных секционированных таблиц в SQL Server 2005. Ручное секционирование Объектов в версиях, предшествовавших SQL Server 7.0 В SQL Server 6.5 и более ранних версиях, секционирование должно было быть частью вашего проекта, а заодно и встраивалось во все ваши инструкции доступа к данным и запросы. Путем создания нескольких таблиц, и затем управления доступом к необходимым таблицам через хранимые процедуры, представления или клиентские приложения, вы могли часто улучшить производительность некоторых операций, но за счет сложности разработки. Каждый пользователь и разработчик должны были знать и должным образом ссылаться на соответствующие таблицы. Каждая секция создавалась и управлялась отдельно, а представления использовались, для упрощения доступа; тем не менее, это решение давало некоторые преимущества. Когда для упрощения пользовательского и программного доступа применялось объединенное представление (использующее инструкцию UNION), процессор запросов должен был получить доступ к каждой базовой таблице, чтобы определить, находись ли в ней данные, необходимые для результирующей выборки. Если для выполнения запроса была необходима только часть тех базовых таблиц, то каждый пользователь или разработчик должны были разбираться в модели данных, чтобы ссылаться только на необходимые таблицы. Секционированные Представления в SQL Server 7.0
Основные претензии, которые предъявлялись к ручному созданию секций в версиях,
предшествовавших SQL Server 7.0, касались в первую очередь производительности. В то
время как представления упростили разработку приложений, пользовательский доступ и
написание запросов не упростились. С выпуском SQL Server 7.0, представления были
объединены с ограничениями целостности, что позволило оптимизатору запросов удалять
лишние таблицы из плана исполнения запроса (т.е. исключать секции) и значительно
уменьшать стоимость плана исполнения, когда объединенное (UNIONed) представление
обращалось к нескольким таблицам.
Пользователи, которые будут обращаться к представлению YearlySales со следующим ниже запросом, будут адресоваться ТОЛЬКО к таблице SalesJanuary2003.
Пока ограничения целостности являются "доверительными" ("trusted"), и запросы к представлениям используют инструкцию WHERE для ограничения результатов выборок, основываясь на ключе секционирования (столбце, по которому определено ограничение целостности), до тех пор SQL Server будет обращаться только к необходимым базовым таблицам. "Доверительное" ограничение целостности - это ограничение целостности, для которого SQL Server в состоянии гарантировать, что все его данные придерживаются свойств, заданных ограничением целостности. По умолчанию, ограничение целостности создается с опцией WITH CHECK. Этот параметр вызывает блокировку схемы таблицы для того, чтобы данные могли быть сверены с ограничением целостности. Ограничение целостности будет добавлено, как только верификация проверит достоверность существующих данных; но если вдруг блокировка схемы будет удалена, последующие операторы INSERT, UPDATE и DELETE должны будут самостоятельно соблюдать ограничения целостности. Благодаря "доверительным" ограничениям целостности, разработчики могут значительно упростить создание представлений, поскольку им уже не нужно напрямую обращаться к интересующим их таблицам. Благодаря "доверительным" ограничениями целостности SQL Server улучшает производительность запросов, исключая ненужные таблицы из плана исполнения. Примечание: ограничение целостности может стать "не доверяемым" ("untrusted") по нескольким причинам; например, если при выполнении оператора bulk-insert не задан аргумент CHECK_CONSTRAINTS. Как только ограничение целостности станет "не доверяемым", процессор запросов вернется к сканированию всех базовых таблиц, поскольку нет никакого способа подтвердить, что запрашиваемые данные действительно расположены в искомой таблице. Секционированные Представления в SQL Server 2000 Не смотря на то, что SQL Server 7.0 значительно упростил разработку и улучшил производительность операторов SELECT, операторы модификации данных не претерпели никаких изменений; операторы INSERT, UPDATE и DELETE поддерживались только для базовых таблиц, и не поддерживались для представлений, объединявших наборы данных (с помощью оператора UNION). SQL Server 2000 позволил операторам модификации данных также извлекать выгоду из возможностей секционированных представлений, разрешая через представления модифицировать соответствующие базовые таблицы. И хотя существуют дополнительные ограничения на создание ключа секционирования, тем не менее, основной принцип заключается в том, что не только операторы SELECT, но и операторы модификации данных будут направляться непосредственно соответствующим базовым таблицам. За более полной информацией об ограничениях, настройке, конфигурации и некоторых приемах секционирования в SQL Server 2000 вы можете обратиться к статье: http://msdn.microsoft.com/library/techart/PartitionsInDW.htm ПРОДОЛЖЕНИЕ СЛЕДУЕТ Руководство по работе с Microsoft SQL Server 2000 Analysis Services (продолжение)
По материалам статьи Carl Rabeler и Dave Wickert, Microsoft Corporation:
Microsoft SQL Server 2000 Analysis Services Operations Guide Содержание
Введение Временная папка Вам надо поместить папку Temporary, если она используется, на RAID массив для повышения скорости записи и проследить, чтобы она находилась не на том же на физическом диске, на котором находится папка Data. Используйте RAID 0, 1, 0+1 или 10 в зависимости от возможностей Вашего бюджета и интенсивности использования RAID. Как бы то ни было, для лучшей производительности более важным будет выделение достаточно большого буфера обработки, чтобы избежать использования временных файлов во время обработки. Если обработка требует наличия временных файлов, то алгоритм работает в разы медленнее, чем если бы буфер обработки был достаточно большим, чтобы выполнить всю обработку в памяти. Если Вы обнаружите, что файлы в папке Temporary интенсивно используются и Вы не можете от них отказаться, то Вы можете добавить вторую папку Temporary на другом физическом диске, добавив ключ реестра TempDirectory2 (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server\Current Version) и определив путь на отдельном физическом диске для второй папки Temporary. Если Вы вынуждены использовать временные файлы, то использование двух папок Temporary увеличивает производительность обработки, потому что данные из первой папки Temporary последовательно считываются, объединяются с новыми данными из сегмента и записываются во вторую папку Temporary 64-килобайтными сегментами. После этого данные из второй папки Temporary считываются, объединяются с новыми данными из сегмента и записываются в первую папку Temporary. Этот процесс продолжается, пока не будут выполнены все расчеты агрегатов. Чтобы определить, используется ли у Вас папка Temporary, смотрите Приложение С "Как настроить размер буфера обработки" далее в этой статье. Конфигурирование источника данных Когда Вы создаете новую базу данных в экземпляре Analysis Services, одной из первых Ваших задач является определение источника данных для базы данных. Источник данных содержит информацию, необходимую для доступа к данным, которые требуются для объектов базы данных. Понятие "источник данных" на самом деле относится к созданному объекту источника данных, а не к самим данным источника. Когда Вы определяете источник данных в Analysis Manager, именем для него будет или <имя_сервера>-<имя_базы_данных>, или <имя хоста>-<имя_базы_данных>. Однако, чтобы избежать проблем при перемещении базы данных на другой сервер, Вам следует изменить именование объекта источника данных по умолчанию, создав для него логическое имя, не связанное с именем компьютера, на котором изначально была создана база данных. Чтобы создать логическое имя для объекта источника данных в Analysis Manager, создайте сам объект источника данных. После этого скопируйте новый объект источника данных и вставьте его в ту же самую базу данных Analysis Services. После этого Вам будет предложено определить новое имя для объекта источника данных. Выбранное Вами имя должно отражать логический тип данных, например, "Данные по продажам" или "Данные по сотрудникам". После того, как Вы определите новое логическое имя, удалите исходный объект источника данных. Затем, когда Вы будете перемещать базу данных Analysis Services между компьютерами, Вы сможете легко изменить текущий сервер и базу данных в строке соединения, изменив настройки объекта источника данных в Analysis Manager (или в Вашем скрипте). В добавление к смене физических имен Ваших источников данных на логические, Вы должны быть уверены, что Ваши компьютеры используют то же самое имя. Если Ваш компьютер для разработки имеет источник данных, названный "Данные по продажам", то Ваш компьютер, на котором стоит Query Analyzer, также должен иметь источник данных "Данные по продажам", и рабочий компьютер тоже должен иметь источник данных "Данные по продажам". Использование постоянных имен на всех компьютерах для разработки, на компьютерах, где запущен QA, и на рабочих компьютерах делает перемещение отдельных частей баз данных проще, вырезая их из баз данных и вставляя их в базы данных Analysis Services. Если Вы не измените имя объекта источника данных перед созданием объектов в базе данных, то Вы не сможете изменить имя объекта источника данных без использования утилит сторонних производителей. Для дополнительной информации по инструментам, которые Вы можете использовать при перемещении базы данных между экземплярами Analysis Services, смотрите "Управление выпуском" далее в этой статье. Учетные записи служб Чтобы понять, какие права необходимы для учетных записей служб MSSQLServerOLAPService и SQL Server Agent, Вам нужно знать контекст безопасности, в котором выполняются различные операции. Определенные задания могут выполняться в контексте текущего подключенного пользователя, другие же задания выполняются в контексте безопасности учетной записи службы MSSQLServerOLAPService. Когда Вы отправляете на Analysis Manager команду создания нового объекта или просмотра существующего, эта команда выполняется в контексте безопасности интерактивной учетной записи пользователя, выполняющего эту команду. Если же Analysis Services обрабатывает измерения, разделы и модели сбора данных, то эта команда выполняется в контексте безопасности учетной записи службы MSSQLServerOLAPService. Вы должны дать соответствующие права этой учетной записи, чтобы обработка прошла успешно. Пользователи часто считают, что если они могут создавать объекты, то они могут и обрабатывать их. В то время как это является частым случаем в простой среде разработки с одним компьютером, в рабочем отделе с множеством компьютеров Вы скорее всего столкнетесь с проблемами. Если у Вашего приложения исходные базы данных находятся не на том же сервере, где расположена база данных Analysis Services, и экземпляр Analysis Services управляется удаленно, то часто первой проблемой, с которой Вы столкнетесь, выводя приложение в реальную эксплуатацию, будут недостаточные права. Вы должны убедиться, что учетные записи служб MSSQLServerOLAPService и SQL Server Agent имеют достаточные права для требуемых задач. Как минимум, учетная запись должна быть членом группы OLAP Administrators. Эти права необходимы для любого пользователя (или службы, действующей от имени пользователя), который управляет сервером Analysis Services. ПРОДОЛЖЕНИЕ СЛЕДУЕТ Статьи на русском языке
PMML: возможности data mining для всех?
Cool new OVER Clause (Transact-SQL) in SQL Server 2005 Самые популярные темы недели
Кто на чем пишет клиентов под SQL Server?
Доступен для скачивания: SQL Server 2005 JDBC Driver Beta 1 |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться
Вспомнить пароль |
В избранное | ||