Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
| Информационный Канал Subscribe.Ru |
| #153<< #154 |
|
СОДЕРЖАНИЕ
Счётчики производительности SQL Server и Windows
1. Введение 7.1. Поиск узких мест использования дисковой подсистемы сервера Windows 2000
Во время исследования производительности дисковой подсистемы Вы должны попытаться локализовать причину возникновения
узкого места в операциях дискового ввода/вывода, осуществляемых SQL Server, используя вначале собственные счётчики
сервера баз данных, а для более детального контроля, счетчики PhysicalDisk и LogicalDisk. Счётчики логических дисков
контролируют логические диски NT (т.е. имена дисков) в то время как счетчики физических дисков контролируют то,
что в оснастке управления дисками видно, как отдельные физические устройства. Формат команды: diskperf [-y[d|v]|-n[d|v] [\\компьютер] Где:
Отсутствие параметров - выдаёт информацию о том, включены ли счетчики производительности диска на локальном или
указанном компьютере и показывает включенные счетчики: для физических дисков, логических дисков или для дисков
обоих типов.
Во время сбора данных по счётчикам производительности диска, журнал статистики счётчиков располагайте на другом
диске или компьютере, чтобы процесс журналирования не мешал исследованию диска.
7.2. Набор счётчиков мониторинга дисковой подсистемы Для контроля производительности дисковой подсистемы сервера Windows 2000, используйте следующий набор, дополнительных к указанным выше, счётчиков:
ПРОДОЛЖЕНИЕ СЛЕДУЕТ Динамика иерархии при навигации во многомерных кубах Автор: Александр Денисенко В распространённых системах анализа многомерных кубов в хранилищах данных (типа[1]) группировка элементов по каждой координате (иерархия) задается при создании куба. Если одной из координат является время, то иерархии по другим координатам оказываются динамическими - при этом стандарные функции аггрегирования (сумма значений на нижележащих в иерархии элементах) становятся некорректными. Предлагается один из вариантов решения этой проблемы. Постановка задачи
Имеется иерархическая структура и набор элементов. Элементы отображены на узлы структуры. Пример 1 (Торговля) Имеется разветвленная сеть магазинов, в которой размещены кассовоые аппараты. Аппараты могут перемещаться по отделам, магазинам и территориям. С каждого аппарата поступает кассовая лента, отражающая платежи за товары или услуги. Наблюдателю - управляющему или аналитику (бухгалтеру, аудитору, налоговому инспектору) - необходимы суммарные показатели по различным узлам и уровням сети (магазинам, отделам, территориям) и в заданные интервалы времени.
Пример 2 (Производство) Машиностроительный завод состоит из производственных участков, цехов, отделов и бригад (иерархическая структура). Персонал предприятия - набор элементов (струдников), которые время от времени меняют место в структуре. Для каждого сотрудника ведется ежедневный учет затрат рабочего времени по совокупности позиций (функция). Наблюдатель - сотрудник службы управления персоналом нуждается в оперативном и ретроспектином представлении суммарных показателей табельного учета по узлам иерархии (бригада, цех, отдел, служба) в заданный интервал времени. При этом на протяжении интервала наблюдения происходили перемещения сотрудников по подразделениям. Особенности навигационного подхода Набор программ для каждого из приведенных примеров на любом распространенном языке программирования не очень сложен. Но почти всегда при перемещении элементов он должен меняться в некоторых местах кода, то есть программный код неустойчив. В таких системах как [1] суммарные (и другие аггрегирующие) значения получаются автоматически при навигации наблюдателя по соотвествующим координатам и узлам иерархии. Можно сказать, что типовые фрагменты программного кода автоматически запускаются в ответ на то или иное движение наблюдателя по экрану. Во многих случаях вообще не требуется программного кода либо он незначителен. Это достигается за счет проектирования координат куба в виде иерархической структуры элементов по каждой из координатных осей и встроенных способов получения суммирующих данных при восхождении по иерархии элементов. Однако при смене иерархии (перемещении элементов по узлам) вообще говоря требуется заново формировать куб, что приводит к потере информации об элементах в прошлые моменты времени (в соответствии с отображением элементов на узлы структуры в предшествующие моменты времени). В примере из торговли при перемещении кассового аппарата в другую торговую точку вся итоговая отчетность искажается так, как если бы аппарат все время находился в новом месте. В производственном примере при перестройке куба, необходимой после перемещения сотрудника в другой цех (так называемое обновление куба - термин "refresh" в [1]) рабочее время сотрудника будет зачтено в новом подразделении и утрачено в старом - как если бы он весь период работал на новом рабочем месте. Нам потребуется один вспомогательный термин из смежных проблемных областей - понятие "морф" элемента, то есть его разновидность, зависимая от временного (ударение на предпоследнем слоге) контекста. При перемещении элемента по узлам иерархии создается его новый морф (или редакция). В морфе есть две части - бесконтекстная (постоянная, глобальная, универсальная - примером может служить GUID в [1]) и контекстная (переменная, локальная, динамическая). Отображение элементов на узлы иерархии подменим отображением их морфов на узлы в соответствии с интервалом существования морфа. Остается заменить в функции на каждом элементе (то есть в ленте кассового аппарата или табеле рабочего времени сотрудника) элемент на его текущий морф. Это несложное (однопроходное преобразование) так называемой фактовой таблицы. Теперь наблюдатель увидит действительные значения суммарных показателей, так как аггрегируются данные по морфам, а морфы существуют в каждом узле в пределах интервала времени. Чтобы увидеть данные по каждому элементу за интервал времени, охватыввающий несколько разных его морфов, необходимо все морфы элемента собрать в иерархию, где вышестоящим узлом будет общий для морфов элемент. Все описанные операцию могут быть выполнены стандартными средствами. Несколько сложнее дело обстоит с динамикой не только элементов по узлам иерархии, но самих узлов (переход всей бригады на другой участок, слияние или разделение организаций). В этом случае неободимы также морфы вышестоящих узлов иерархии. И необходимо при порождении нового морфа узла порождать новые морфы для всех его нижележащих элементов. Для удобства навигации между элементом и его морфами можно поместить еще один уровень, отражающий интервал жизни морфа. Так, если наблюдатель пеерместиться в узел, соответствующий магазину и захочет увидеть сводку по кассовым аппаратам, то сводк будет содержать также дополнительную информация о том, в какой интервал времени было то или иное значение итогов. Приведем небольшой пример Штатное расписание завода (иерархическая структура) включает отдел 2, в составе которого две Лаборатории, в которых предусмотрены должности инженеров, экономистов и операторов. В отделе кадров хранится список сотрудников (элементы), среди которых мы выделим Абрамова, Баранова и Васильева. Для удобства перенумеруем рабочие места и сотрудников (фамилии и названия подразделений могут изменяться). Штатное расписание:
Персоналии:
Динамика иерархии: 03 января Борисов переходит из Лаборатории 21 в Лабораторию 22 Фрагмент табеля учета рабочего времени (таблица фактов):
Для Борисова необходимы два морфа с периодами до 3 января и после:
Используем соответствие морфов и штатных единиц:
Теперь преобразуем фактовую таблицу с учетом морфов:
Теперь стандартные функции аггрегирования будут отражать корректные значения функции. Рабочее время Абрамова до 3 января будет учитываться в составе Лаборатории 21, а с 3 января - в составе Лаборатории 22. Если ввести дополнительную координату 'Морф', то наблюдатель сможет увидеть обобщенные значения по каждому сотруднику за весь период. Таблица для этой координаты имеет два столбца - соответственно двум уровням иерархии:
Наконец, для удобства просмотра координаты сотрудников можно ввести дополнительный уровень иерархии - период жизни морфа. Тогда просмотр списка сотрудников по подразделениям предприятия будет содержать дополнительные сведения о времени. В нашем случае при просмотре состава Отдела 2 за год от наблюдателя будет требоваться указать более точно дату, либо он получит несколько вариантов с указанием дат, что вполне согласуется с практическими потребностями. Источники: [1]. Микрософт. SQL2000-OLAP. Электронная документация. Как быстро можно сортировать натуральные числа? Автор: Александр Денисенко Сортировка Шелла является асимптотически оптимальной по сложности в смысле числа попарных сравнений элементов множества, предназначенного для сортировки. Если множество состоит из N элементов, то сложность такой сортировки - примерно N*LogN (логарифм двоичный). В больших базах и хранилищах данных значительное время могут занимать сортировки множеств специфической природы - натуральных чисел ограниченного диапазона (это порядковая нумерация типа Identity и аналогичные ей). Особенно актуально это в многозвенной клиент-серверной модели, когда основные массовые алгоритмы удобно делать на сервере, а на клиентской или промежуточной машине - переходить от натуральных кодов объектов к их изображению на экране в виде текстовых строк. В этом случае интерес может представлять специальная сортировка, асимптотически более эффективная (на натуральных числах).
Итак, имеется множество М={i1,…,ik} причем все i1,…,ik<N.
Нетрудно видеть, что алгоритм линеен, то есть его сложность - C*K. Что касается теоретико-множественных операций над множествами рассматриваемой природы, то они сводятся очевидным образом к сортировке. В самом деле, для двух множеств M1 и M2 следует завести по вектору из нулей, затем выполнить Шаг 2 сортировки. Далее остается провести необходимую булевскую операцию (дизъюнкцию для объединения множеств, конъюнкцию - для пересечения и т.д.) и результат готов. Уместно заметить, что во многих системах разность множеств строится существенно сложнее суммы - что неестественно (сумма и разность чисел в процесссоре идет одинаково быстро, так как никакой разницы в алгоритмах нет). Кажущийся парадокс нарушения известного теоретического результата связан со спецификой данных и сменой функционального базиса. Сортировка Шелла оптимальна при базисе, состоящем из операций попарного сравнения двух элементов. Мы просто выбрали другой функциональный базис. С физической точки зрения парадокса и нет - так как поиск нужного бита в массиве требуе двоичного логарифма прохода по массиву. Но это операция, погруженная в элментную базу машины и потому представляющаяся атомарной. Статьи на русском языке
Birdstep XML. Реализация стандартов SAX, DOM и XPATH
Новые и обновлённые технические статьи Microsoft
BUG: Error Message: "The colv1 parameter is shorter..." Occurs When Replicated Column is Updated
DDL Archive Utility
Самые популярные темы недели
Start dll with extended store procedure
pomogite s sql query Рассылка: Вопросы и ответы по Microsoft SQL Server
Автор рассылки: Сергей Кошкин
Выпуск No. 22 от 2003-07-18
|
| http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
| В избранное | ||
