DWH

Отнюдь не всегда получается воспользоваться LDAP-запросом к AD для получения данных из домена, т.к. некоторые показатели AD содержат не одно, а несколько значений.
Это можно обойти, написав ScriptComponent следующим образом:

1) В SSIS-пакете объявляем 2 переменные:
domain - отображаемое имя домена, которое пойдет в таблицу
FQDN - имя домена в формате LDAP://xxxx.xxxx.xxxx
2) Создаем ForEach Loop, где в коллекции перечисляем руками сопоставление
FQDN(в Column0) - domain(в Column1)
3) В ForEach добавляем DataFlow
4) В DataFlow в качестве источника добавляем ScriptComponent, не забываем добавить объявленные выше переменный в область видимости ScriptComponent`а
5) В ScriptComponent`е объявляем нужные выходы
6) В код ScriptComponent`а в CreateNewOutputRows добавляем следующее (предполагаю, что можно написать оптимальнее и намного короче)

Пример приложен
читать дальше...

Существуют две интересные, однако малоизвестные утилиты от MS, которые позволяют проверить обновления системы и следование лучшим практикам разработки и администрирования:

1) Анализ сервиспаков и безопасности системы:
Microsoft Baseline Security Analyzer (MBSA) - устанаваливается отдельно, интерфейс и пакеты проверки в одном комплекте (после запуска качает информацию о последних обновлениях с сайта MS)
скачать можно тут: http://technet.microsoft.com/ru-ru/security/cc184923

2) Интерфейс для набора "вопросов" из best practices:
Microsoft Baseline Configuration Analyzer (MBCA), скачать можно тут http://www.microsoft.com/en-us/download/details.aspx?id=16475
SQL Server 2012 BPA - собственно, сам набор "вопросов" к системе на базе MS SQL, http://www.microsoft.com/en-us/download/details.aspx?id=29302

Существуют и другие наборы, например BizTalk Server Best Practices Analyzer (http://www.microsoft.com/en-us/download/details.aspx?id=15963)
или Microsoft Exchange Best Practices Analyzer (http://www.microsoft.com/en-us/download/details.aspx?id=22485)

Также есть документ по описанию процесса разработки своих наборов:
Microsoft Baseline Configuration Analyzer Model Authoring Guide, http://www.microsoft.com/en-us/download/details.aspx?id=16475

Часто через 3-4-5 лет после начала работы ОЛАП-отчетности, система начинает работать несколько медленнее, что раньше. Вобщем-то понятно почему - объемы данных растут, а оборудование как правило остается тем же самым.
читать дальше...

Когда мы создаем в SSAS меру типа distinct count, она по-умолчанию создается в новой группе мер, причем метаданные источника данных копируется из исходной группы мер. То есть, если исходная группа мер содержала в себе 50 секций, то определения(запросы) этих секций абсолютно таком же виде скопируются в новую группу мер.

Удобно? На первый взгляд да.
читать дальше...

За долгое время накопилась куча весьма простых хитростей, которые недостойны отдельной статьи, но способны существенно облегчить жизнь разработчикам, а в некоторых случаях даже существенно повысить производительность.

Поэтому я решил их опубликовать с кратким описанием. Часть где-то найдена, часть придумана. Возможно кому-то пригодится. Необходимое ПО - SSAS 2005+

читать дальше...

Парочка скритов для объектов, необходимых в каждом хранилище
читать дальше...

Полезные скрипты для анализа производительности и администрирования MS SQL.
Большая часть найдена в интернете.

Работают на версии 2008R2, на младших версиях - как повезет.
На 2008R2 часть скриптов работает только с уровнем совместимости 100, с более низким уровнем может потребоваться ручная правка, например замена sys.dm_db_index_physical_stats(db_id(),null, null, null, null) на sys.dm_db_index_physical_stats(<тут указанный руками номер БД>,null, null, null, null)

updt: внес некоторые правки в соответствии с комментариями
читать дальше...

Как известно, агрегаты в SSAS делятся на гибкие и жесткие. Соответственно гибкие строятся на гибких связях, жесткие - на жестких.

А если более понятно и на примерах:

Рассмотрим измерение "Календарь", которое имеет иерархию "Год->Месяц->День".
Его элемент "21 января" (уровень "День") связан с элементом более высокого уровня "январь". И связан жестко, так как не может переместится по воле судьбы или пользователей в "февраль" или "март".

При гибких же связях допускается возможность такого перемещения. Например, любой знает, что товар ценовой группы "100-200 рублей" очень легко может переместится в ценовую группу "200-300 рублей". Более того, мы сами в этом можем убедится, посетив любой магазин!

SSAS же обрабатывает агрегаты, построенные на таких связях, по разному: при процессинге измерений (Process Update) жесткие агрегаты не затрагиваются, а вот гибкие удаляются.

Самое простое решение - сделать все связи жесткими - не подходит, так как вызовет ошибку при обработке измерения (если все же элемент поменял свое месторасположение в иерархии). И далее потребуется полная обработка всего проблемного измерения (Full Process), а затем и всех кубов, связанных с этим измерением. На больших системах это чревато недоступность данных в течении достаточно длительного времени, что недопустимо. Поэтому, как правило, жесткие связи между элементами назначают только для измерения "Календарь".

Что же делать с гибкими агрегатами, если они удаляются в каждое окно расчета?

Существует несколько вариантов решения проблемы:

1) В дополнении к Process Full актуальных секций куба, можно делать Process Index старых секций.
Например, так:
секция 2010.12->(проверка: еще есть время для обработки?)->
секция 2012.11->(проверка: еще есть время для обработки?)->
...
секция 2001.01
Для актуальных секций этого делать не нужно, так как Process Full = Process Data + Process Index

2) Или при процессинге измерений можно ставить флаг "Process Affected Object", это вызовет пересчет поменявшихся агрегатов всех секций. Однако это рекомендуется делать только в том случае, если измерения обрабатываются параллельно. Если же они обрабатываются последовательно, то можем получить такую последовательность действий:
обработка измерения 1 -> пересчет агрегата A-> обработка измерения 2 ->пересчет агрегата А (еще раз!)
Это достаточно существенно затянет шаг обработки измерений.
Кроме того, с каждой новой секцией время обработки измерений будет всегда расти, а не оставаться постоянной величиной. Этот путь требует минимальных трудозатрат, но с точки зрения стабильности временени обработки кубов это малопривлекательно.

Для секций со старыми данными можно создать свой набор агрегатов. Принято включать в этот набор несколько меньше агрегатов, чем в актуальные секции, ведь к достаточно старым данным и их агрегатным значениям обращаются не часто. Для очень больших кубов (при наличии малого окна обработки) этот набор может содержать только жесткие агрегаты.


Все)

Для анализа производительности практически всегда требуется собирать данные счетчиков.

Можно использовать множество разнообразных приложений, или создать свою миниподсистему по сбору данных.

Рассмотрим второй вариант.

Для начала требуется создать задачу сбора и указать, данные каких счетчиков мы будем сохранять для последующего анализа.
Это делается в оснастке Administrative Tools->Performance (или тут %SystemRoot%\system32\perfmon.msc /s).
После запуска оснастки в левой навигационной панели выбираем Performance Log And Alerts->Counter Logs.
Затем в правой панели с помощью пункта контекстного меню "New Log Setting" создаем пакет сбора данных.
При создании можно выбрать необходимые счетчики, место хранения данных, даты начала и окончания сбора.

Запустить или остановить задачу также можно с помощью контекстного меню.

Но бывают ситуации, когда машина перезагружается либо место храниния более недоступно (например, если логи хранятся в БД, а сервис СУБД рестартует).
После этого нужно не забыть перезапустить пакет сбора данных счетчиков. Это можно сделать руками, но лучше автоматизировать.

Для этого в планировщике MS SQL создаем CmdExec-задачу, создержащую следующую команду (без скобок):

CmdExec
start LOGMAN START <НазваниеПакетаСбораДанных>

и ставим ее на выполнение каждые N минут.

Первая команда start скрывает ошибку, если(или когда) пакет сбора данных уже работает.
Если на машине не установлен MS SQL Server, то также можно воспользоваться планировщиком Windows.

Часто при работе с DWH возникают "необъяснимые" изменения данных за старые периоды.
Пользователи жалуются - "мы ничего не меняли за двухтысячный год", а поддержка сервиса не может объяснить эти изменения, т.к. организация просто не имеет ресурсов для хранения большого числа бэкапов

У этих изменений есть несколько возможных причин:
1) реальное изменение фактов в DWH
2) изменение атрибутов измерений
3) Некорректная работа клиентского ПО

Рассмотрим их более подробно:

Реальное изменение фактов в DWH

Этот случай возникает при проведении/правке документов задним числом.
Чтобы иметь возможность назвать этот фактор как причину изменений данных, требуется соответствующим образом проектировать систему:
- хранить дату добавления факта
- не удалять факты, а отмечать их пометкой "удалено", вместо них добавлять новые
Все это справедливо для инкрементально наполняющегося хранилища данных(ХД), если же ХД каждый раз полностью перезаполняется, то тут только один вариант - резервные копии (много-много копий).
читать дальше...