Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#269<< #270 |
СОДЕРЖАНИЕ Секционированные таблицы и индексы SQL Server 2005 (продолжение)
По материалам статьи Kimberly L. Tripp:
SQL Server 2005. Partitioned Tables and Indexes Объединение секционированных таблиц Когда объединяются выровненные таблицы, SQL Server 2005 может выбирать между объединением таблиц за один шаг, либо в несколько этапов, когда вначале объединяются отдельные секции, а затем подмножества складываются. Но независимо от того, как объединяются секции, SQL Server всегда пытается оценить, насколько возможно исключить из объединения какие-нибудь секции. Исключение секций В следующем примере данные запрашиваются из таблиц Order и OrderDetails, созданных в предыдущем сценарии. Запрос возвращает данные о продажах только за третий квартал. Как правило, в третьем квартале потребительский спрос на товары невысок; однако в третьем квартале 2004 года, напротив, был зафиксирован один из самых высоких уровней объема продаж. В данном случае нам интересно, была ли (в третьем квартале) какая-либо взаимосвязь между объемами заказов и датами продаж. Для того чтобы гарантировать, что выровненные секционированные таблицы при объединении извлекают выгоду из исключения секций, Вы должны убедиться, что установили диапазоны секционирования для каждой из таблиц. В данном случае, поскольку первичный ключ (Primary Key) таблицы Orders является составным (OrderDate + OrderID), объединение между таблицами Order и OrderDetails должно производиться не только по равенству OrderID, но и по равенству дат. SARG (Search Argument - Аргумент Поиска) будет применен к обеим секционированным таблицам. В итоге, наш запрос будет выглядеть следующим образом:
На Рисунке 14 представлено несколько ключевых моментов, на которые стоит обратить внимание, изучая реальный или расчетный планы исполнения. Для этого нам придется воспользоваться SQL Server Management Studio. Обратите внимание на значения "Estimated Number of Executions" (расчетное количество выполнений) или "Number of Executions" (количество выполнений) для обеих таблиц. В нашем случае, мы рассматриваем один квартал, т.е. три месяца. Данные за каждый месяц располагаются в своей собственной секции, и поэтому поиск данных выполняется трижды - по одному разу для каждой таблицы.
Как можно увидеть из Рисунка 15, SQL Server устраняет все лишние секции и оставляет только те, которые содержат необходимые данные, для чего анализирует PARTITION ID:([PtnIds1017]). Вы можете задаться вопросом, откуда взялось выражение PtnIds1017? Если вы обратите внимание на значок "Constant Scan" в верхней части плана исполнения, то увидите что в списке аргументов у него VALUES(((21)), ((22)), ((23))). Это не что иное, как номера секций.
Для того чтобы проверить, что данные располагаются в тех (и только в тех) секциях, вы можете воспользоваться слегка модифицированной версией созданного ранее запроса, а заодно обратиться к новым встроенным системным функциям для работы с секциями.
Из Рисунков 14 и 15 видно как происходит исключение секций. Если секционированные таблицы и индексы выровнены по отношению к таблицам, с которыми объединяются, то могут использоваться и другие методики оптимизации. SQL Server может выполнить "множественные" объединения, объединив вначале все секции. Предварительное объединение выровненных таблиц В приведенном ранее запросе SQL Server не только исключает лишние секции, но также производит объединение между оставшимися секциями - по отдельности. Помимо наблюдения за количеством обращений к таблицам во время исполнения запроса вы также должны были обратить внимание на значок "merge join". Если вы присмотритесь, то увидите, что объединение слиянием (merge join) также выполняется три раза.
Обратите внимание, на Рисунке 16 представлен еще один элемент - "nested loops" (объединение "вложенных циклов"). Может показаться, будто это объединение выполняется после объединения слиянием, но на самом деле оказывается, что это объединение является избыточным. Идентификаторы секций к тому моменту уже были переданы для поиска в каждую из таблиц, и это заключительное объединение только сводит вместе две порции данных, удостоверяя, что каждая из них придерживается идентификатора секции, объявленного в начале (в выражении "Constant Scan"). Сценарий "Скользящее Окно"
Как только станут доступными данные следующего месяца (в нашем случае это Октябрь 2004),
Вам потребуется руководствоваться определенной последовательностью действий, для того
чтобы используя существующие файловые группы "двигать" ("включать"/"выключать") в них
данные. По данному сценарию в файловой группе FG1 в настоящее время находятся данные
за октябрь 2002. Теперь, когда появились данные за Октябрь 2004, у Вас есть два пути,
в зависимости от доступного Вам дискового пространства и требований к архивации.
Помните, чтобы "включение" или "выключение" секции из таблицы прошло быстро, оно должно
затрагивать ИСКЛЮЧИТЕЛЬНО метаданные. Другими словами, новая таблица (источник или
целевая - т.е. скрытая секция) должна быть создана в переключаемой файловой группе.
Если Вы планируете продолжать использовать те же самые файловые группы, в данном случае
FG1, то тогда Вы должны будете решить, как управлять дисковым пространством и требованиями
к архивации. Если у Вас достаточно места на диске, то Вы можете загрузить текущие
данные (октябрь 2004) в FG1, не удаляя данных, которые будут заархивированы (октябрь 2002).
Рассмотрим каждый из шагов более детально. Дополнительно каждый шаг содержит примечания, помогающие автоматизировать процесс с помощью динамического SQL. Управление "включаемой" каскадной таблицей
ПРОДОЛЖЕНИЕ СЛЕДУЕТ Использование статистики оптимизатором запросов Microsoft SQL Server 2005 (продолжение)
По материалам статьи Eric N. Hanso: Statistics Used by the Query Optimizer in Microsoft SQL Server 2005 Резюме статистики по строке SQL Server 2005 использует патентованную технологию оценки селективности для условий с LIKE. Он формирует резюме статистики по частотности распределения подстроки в символьных полях (резюме по строке). Это относится к полям следующих типов: text, ntext, char, varchar и nvarchar. Использование резюме по строке помогает SQL Server точно оценить селективность условий с LIKE, где образец поиска может иметь любое количество знаков подстановки и в любой их комбинации. Например, SQL Server может оценивать селективность предикатов следующей формы:
Если в образце LIKE используется указанный пользователем символ замены (то есть, образец
поиска имеет форму LIKE образец ESCAPE escape_character), то только в этом случае SQL Server
2005 угадывает селективность. Статистика по вычисляемым полям
SQL Server 2005 поддерживает создание, обновление и использование статистики по вычисляемым
полям, даже в тех случаях, когда сам запрос не содержит имени вычисляемого поля, а содержит
его выражение (формулу). SQL Server 2000 мог создавать, обновлять и использовать статистику
по вычисляемым полям только в автоматическом режиме, и только если вычисляемое поле указывалось
в запросе явно.
SQL Server 2005 не поддерживает статистику по не сохраняемым вычисляемым полям, которые используют выражения CLR (common language runtime), например, вызывающих в выражении определяемую пользователем CLR - функцию. Для того, что бы собирать статистику по использующему CLR вычисляемому полю, это поле должно быть отмечено, как: PERSISTED. Статистика по полям, основанным на определяемых пользователем CLR - типах данных SQL Server 2005 поддерживает создание, обновление и использование статистики по полям, основанным на определяемых пользователем CLR - типах, если такой пользовательский тип данных поддерживает бинарное упорядочивание, иначе, статистика поддерживаться не будет. Тип данных поддерживает бинарное упорядочивание, если у атрибута SqlUserDefinedType, который является частью спецификации определения типов данных, опция IsByteOrdered установлена в "true". Когда тип поддерживает бинарное упорядочивание, это означает, что стандартная бинарная сортировка упорядочивает данные в семантически правильном порядке для этого типа. Статистика и индексированные представления
Обычно, статистика не требуется для индексированных представлений. Это происходит потому,
что подстановка индексированных представлений в план исполнения запроса происходит только
после того, как все статистические данные для используемых в запросе таблиц и индексов будут
присоединены к плану запроса. Есть одно исключение: статистика будет использоваться в том
случае, когда в предложениях FROM присутствует ссылка непосредственно на представление, и
применяется подсказка оптимизатору NOEXPAND. Обратите внимание, что возникнет ошибка и план
не будет создан, если NOEXPAND задан для представления, которое не имеет индекса. ПРОДОЛЖЕНИЕ СЛЕДУЕТ Репликация через Интернет или между доменами без доверительных отношений
По материалам статьи Paul Ibison:
SQL Server Replication Across Domains and the Internet
Репликация через Интернет или домены, не имеющие доверительных отношений, обычно
выполняется с использованием Виртуальной Частной Сети (VPN), и, следовательно, при
этом используется такая же конфигурация как в LAN. В данной статье не рассматривается
случай, когда VPN недоступна.
Из этого следует необходимость некоторых изменений в конфигурации, призванных решить эти проблемы. Настройка сети
Для организации подключения SQL Server, на издателе должен быть открыт доступ к порту,
с которым работает этот сервис. По умолчанию используется порт 1433, в то время как
FTP - протокол обмена файлами по умолчанию использует порт 21. Кроме того, правила
доступа на эти порты через брандмауэр с IP-адресов подписчика должны предусматривать
наличие у подписчика фиксированного IP-адреса, и он не должен получать его от службы
выделения адресов DHCP. Настройка публикации
Распределённая на издателе для пользователей сети папка Repldata, которая обычно
используется для хранения файлов моментальных снимков использующаяся при инициализации
подписок, будет недоступна - поскольку для входа в систему издателя будет использоваться
гостевая учетная запись Windows (Guest), что также считается небезопасным - поэтому
необходим альтернативный метод инициализации.
Однако, эта статья посвящена использованию встроенного, автоматического метода передачи
снимка через FTP, который настраивается на издателе на вкладке Snapshot Location
свойств публикации. Если все подписчики настраиваются схожим образом (домены без
доверительных отношений и т.д.) тогда на этой вкладке можно выбрать только второй
переключатель сверху, не создавая снимок в стандартном местоположении. Папка для
создания снимка находится внутри папки FTPROOT, а также должен быть выбран переключатель
'Subscribers can access this folder using FTP'. Настройка псевдонимов на подписчике Для того чтобы подписчик 'видел' издателя, перед регистрацией издателя в Enterprise Manager, для него с помощью Client Network Utility должен быть создан псевдоним. Это обязательное условие, поскольку использование IP-адреса в EM позже может привести к разного рода ошибкам. Старайтесь соблюдать следующие рекомендации:
Редактирование файла hosts на подписчике Запрос подписчика к FTP должен иметь возможность правильно привязывать NETBIOS имя издателя/дистрибьютора к его IP - адресу. Поскольку у нас сеть не имеет доверительных отношений, то имени сервера издателя/дистрибутора не будет в службе имён локальной сети (DNS), с которой взаимодействует подписчик. Поэтому мы должны вручную добавить сопоставление имени удалённого сервера издателя/дистрибьютора его IP-адресу, что можно сделать в файле hosts на сервере подписчика, который расположен в каталоге C:\WINNT\system32\drivers\etc. После внесенных изменений, текст этого файла должен содержать представленные ниже строки, где DOHXXX-SQL - это условное NETBIOS - имя издателя/дистрибьютора.
Если этого не сделать, то при инициализации подписчика посредством FTP, вы получите следующее сообщение об ошибке: "Message: The process could not connect to FTP site 'DOHCOL-SQL' using port 21". Создание pull - подписки При использовании мастера создания pull - подписки, в окне "Choose Publication" можно увидеть список публикаций издателя. На этой стадии, издателя можно зарегистрировать в EM, либо он уже должен быть там зарегистрирован. Если на предыдущих шагах все было сделано правильно, список публикаций должен быть виден. В качестве учетной записи агента репликации должна быть выбрана учетная запись SQL Server (можно и по-другому, но давайте пока не будем рассматривать этот вариант), уже добавленная в лист доступа публикации (PAL). Если подписчик зарегистрирован на издателе, это будет именованная подписка, иначе - анонимная. При установке, в окне формы Snapshot Delivery следует выбрать опцию "Download using FTP". Сайт автора в Интернет: www.replicationanswers.com. Статьи на русском языке
Security Configuration Wizard из Windows 2003 SP1
Code and Reporting Services project from DM-BI Integration Webcast Самые популярные темы недели
Ваше мнение об упражнениях SELECT на http://sql.ipps.ru
переключение QA на русскую раскладку если резалтсет в руск.кодировке
Журнал "Алгоритм", третий номер Выложена электронная версия третьего номера журнала "Алгоритм". Общий размер архива около 1МБ, формат архива - zip. В номере:
Первый номер можно скачать здесь, второй номер можно скачать здесь |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться
Вспомнить пароль |
В избранное | ||