Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#192<< #193 |
СОДЕРЖАНИЕ
Введение в SQL Server 2000 Analysis Services: Создание первого куба. Часть 6. По материалам статьи William Pearson: Introduction to SQL Server 2000 Analysis Services: Creating Our First Cube
Введение в Analysis Manager Проектирование хранилища и процессинг куба Analysis Services предлагает несколько вариантов хранилищ и агрегации данных для нашего первого куба:
∙ Multidimensional OLAP (MOLAP)
Завершив разработку структуры куба, мы должны выбрать один из предлагаемых типов хранилища и указать условия
агрегации, или сделать предварительный расчёт для получения оптимального соотношения производительности
запросов и эффективности куба. Далее, нам необходимо будет выполнить процессинг куба, в процессе которого будет
выполнена загрузка данных из выбранного нами источника и будут сделаны все необходимые вычисления, которые
заложены в используемых кубом командах агрегации.
Иллюстрация 40: Welcome to the Design Storage Wizard После нажатия кнопки Next будет вызвано окно Select the Type of Data Storage, где присутствуют радио-кнопки для каждого из показанных ранее возможных режимов, а также их краткое описание (подробную информации по ним можно найти в Books Online и Reference Library). В качестве хранилища нам подойдёт значение по умолчанию - MOLAP, как это показано на Иллюстрации 41, и поэтому можно снова нажать кнопку Next.
Иллюстрация 41: Диалоговое окно Select the Type of Data Storage Следующим окном будет Set Aggregation Options, где мы должны указать Analysis Services обеспечить производительность работы с кубом на уровне 65% от максимально возможной, без учёта занимаемого кубом дискового пространства. Для этого нужно выбрать радио-кнопку Performance Gain Reaches и ввести число "65" в качестве процента от максимальной производительности, как это показано ниже на Иллюстрации 42. Как Вы можете видеть на следующей иллюстрации, это окно может помочь найти компромиссное решение между занимаемым кубом дисковым пространством и производительностью исполнения запросов к кубу.
Иллюстрация 42: Диалоговое окно Set Aggregation Options После того, как Вы выберете наиболее подходящие для Вас параметры хранилища куба, нужно нажать кнопку Start и наблюдать процесс процессинга куба, как будет изменятся его размер и соответствующая ему производительность. Как Вы сможете увидеть, чем выше производительность, тем больше занимаемое кубом дисковое пространство. Изображение возможного графика распределения (который может отличаться от Вашего из-за разной информационной и аппаратной конфигурации системы) показано ниже на Иллюстрации 43.
Иллюстрация 43. Далее, нажмите кнопку Next и Вы попадёте диалоговое окно Finish the Storage Design Wizard. В ответ на вопрос этого окна What do you want to do?, нужно отметить радио-кнопку Process Now, как это показано на Иллюстрации 44. Следующим шагом будет выполняться процессинг куба или его сохранение (если Вы решите запустить процессинг позже или собираетесь вернуться к разработке куба для внесения каких - либо изменений). Мы же выберем Process Now, и нажимаем кнопку Finish.
Иллюстрация 44: Диалоговое окно Finish the Storage Design Wizard
Окно Process, которое вы увидите следующим, позволяет контролировать процессинг куба по всем его стадиям,
процессам и статистике работы, выводимой в нижней части окна. Когда процессинг закончится, Вы должны увидеть
в нижней строке сообщение "Processing completed successfully", как это показано на Иллюстрации 45.
Иллюстрация 45: Ход процессинга куба ПРОДОЛЖЕНИЕ СЛЕДУЕТ Распределенные секционированные представления MS SQL Server
По материалам статьи Don Schlichting:
MS SQL Server Distributed Partitioned Views В этой статье рассматривается использование распределенных секционированных представлений для доступа к множеству серверов MS SQL Server, сконфигурированных как объединение серверов БД.
В случае, когда необходимо получить дополнительную производительность на сверхбольших базах данных, а ваши
хранимые процедуры уже оптимизированы, программное обеспечение является многоуровневым и аппаратные средства
модернизированы, настает время для распределения вашей базы данных по нескольким серверам. Для SQL Server это
делается путем горизонтального секционирования больших таблиц по множеству серверов. Если разделение таблицы с
множеством столбцов на несколько таблиц с меньшим количеством столбцов является вертикальным секционированием,
то горизонтальным секционированием считается разделение таблицы с множеством записей на множество таблиц с меньшим
количеством записей. Если эти новые таблицы меньшего размера будут размещены на разных серверах, то это называется
объединенной базой данных. Здесь используется слово "объединенный", потому что все задействованные серверы могут
работать совместно для балансировки нагрузки. Они действуют как некое объединение. Как только ваши данные
распределяются по нескольким серверам, для выборки записей становится необходимым новый тип выражений. Эти новые
выражения называются распределенными секционированными представлениями. Они используют стандартные выражения SQL
вместе с ключевым словом UNION для получения данных со всех распределенных серверов. Выражения DML (INSERT, UPDATE,
и DELETE) также могут использоваться при соблюдении нескольких специальных правил, касающихся таблиц, лежащих в
основе распределенного секционированного представления. Хотя прирост производительности варьируется в зависимости
от используемых приложений, обычно он составляет от 20 до 30%.
Более детальное объяснение связанных серверов находится в предыдущей статье
Linked Servers PART1
Параметру @server передается наш алиас. @datasrc - это имя связываемого сервера. Если бы существовало несколько
экземпляров сервера, то был бы использован синтаксис ИмяСервера\ИмяЭкземпляра.
Чтобы проверить связь между серверами, выполните:
В результате должны быть выбраны все записи из таблицы "Authors". Теперь мы должны повторить то же самое со второго сервера. Это создаст обратную связь с первым сервером server1. Все то же самое, кроме названия сервера и алиаса. Войдите в Query Analyzer второго сервера под "sa" и выполните:
Если бы были задействованы дополнительные серверы, то потребовалось бы связать их все друг с другом. Такую же схему мы бы имели с многодоменными, доверительными соединениями NT. Если бы в нашем объединении было четыре сервера, то была бы реализована следующая схема:
Сервер1 имеет связанные серверы Сервер2, Сервер3 и Сервер4. При этом нет никакой автоматизации ни при создании, ни при проверке таких обоюдных связей. В этом примере мы будем работать с подмножеством таблицы "Authors" базы данных "pubs". Представим себе, что таблица очень большая и большинство наших запросов используют поиск по фамилии. В этом случае мы могли бы разделить таблицу "Authors" на две части, храня на одном сервере фамилии от A до M, а на другом - от N до Z. Создайте и заполните тестовую таблицу на первом сервере server1.
Критической частью кода является ограничение. Ограничение CHECK должно гарантировать, что запись будет расположена в одной-единственной таблице. Во время выполнения нашего представления Query Optimizer использует эти ограничения для определения, какие серверы, какую часть распределенной работы получат. Распределенные секционированные представления
Последним шагом является собственно создание представлений. Оператор UNION используется для слияния результатов
выборки из обеих таблиц в один результирующий набор. См. BOL "Union operator" для более детальных объяснений и
правил.
На втором сервере server2 код опять практически тот же самый. Меняются только имена таблиц и сервера.
Простая выборка на первом сервере server1 создает следующий план выполнения: Видно, что результат сканирования локальной таблицы на первом сервере server1 сливается с результатом выполнения удаленного запроса на втором сервере server2. Наше представление следует всем стандартным правилам для представлений. Поэтому выборка части записей не требует ничего более, чем стандартное выражение:
Т.к. настройка объединения серверов не является быстровыполнимой задачей, то увеличение производительности путем использования распределенных секционированных представлений на больших таблицах может сделать такое решение более выгодным. В следующей статье эта тема будет продолжена обсуждением требований к DML на объединении серверов и методов оптимизации. Статьи на русском языке
Царь Горы Новые и обновлённые технические статьи Microsoft
Уважаемые подписчики! Это последний выпуск рассылки, в котором присутствует раздел: "Новые и обновлённые
технические статьи Microsoft". Связано это с тем, что недавно в сети появился замечательный ресурс kbAlertz.com,
который справляется с этой задачей намного лучше, избирательней и удобней для пользователей. Вы можете подписаться
только на ту информацию, которая Вас интересует, и получать информацию о новых статьях более оперативно. Поэтому,
я приглашаю Вас посетить сайт http://www.kbalertz.com/ и подписаться на
их замечательную рассылку. SQL Server
837969
FIX: You may receive an access violation in the CRowsetTraceData::FGetNextRow function when you trace server
activity with SQL Profiler ADO
314383
How to use the CDOEX Library to retrieve messages from a user's Inbox by using Visual Basic .NET Data Access Components
836799
FIX: Hotfixes are available for MDAC 2.7 Service Pack 1 Message Queue
839485
You receive a "MQSec.dll could not be found" error message after you install the Message Queuing component in
Windows 2000 OLE DB
837001
MS04-014: Vulnerability in the Microsoft Jet Database Engine could permit code execution
What is OLAP? Самые популярные темы недели
Ваше мнение об упражнениях SELECT на http://sql.ipps.ru
Транзакционность DDL операций - друг или враг
|
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
В избранное | ||