вводная информация:
===========
2005 Microsoft SQL Server Enterprise Edition (64-bit) ver 9.00.4035.00
+SSAS
есть olap-бд с несколькими кубами.
в бд есть довольно толстое измерение:
- 40+ млн записей
- 150+ атрибутов
- 10 гб места на схд.
регламент обновления:
- раз в неделю полный деплоймент
- раз в сутки - update
в норме деплойменты занимают 0,7-:-2 часа - в зависимости от сторонней нагрузки на сервере.
структура измерения не редактировалась уже несколько месяцев.
==========

описание проблемы:
==========
за последние пару недель трижды имела место следующая ситуация:
1. развертывание застревает на последнем\одном из последних шагов (= внешне - продолжается исполнение, но в логе висит состояние: "Построение индексов для данных для атрибута <...key...> завершено." и так в течение нескольких часов)
сиквель при этом всем доволен.
2. служба в двух случаях из трех переставала отвечать, в одном - продолжала благополучно работать.
в последнем случае в трассе можно наблюдать пользовательские запросы, которые исполняются довольно шустро. можно даже параллельно отдеплоить в режиме update другое измерение (экспериментировал с небольшим.)
3. дополнительно за указанный "проблемный" период один раз наблюдались проблемы на СХД. по времени это было близко к одному из описываемых мной сбоев, но например сейчас, когда я пишу этот пост, сбой с развертыванием случился в 4 раз, а СХД всем довольно.
4. места много.
==========
собственно, вопрос: "куды бечь"(Ц) = на что стоит смотреть?
1) вообще
и
2) конкретно сейчас - когда сбой воспроизведен


yahyah

Критик, спасибо за ответ.
про 4 гб я в курсе.
нет: <key>.asstore - самый тяжелый файл в директории измерения - весит 1,2 гб.
ну и еще информация:
в 18:50 отправил службу в ребут, и поставил на развертывание по новой - из студии чтоб попроще смотреть было.
сейчас уже идет процессинг индексов партиций.
по ощущению минут через 20 закончится.
разница по сравнению с _10 часов назад_ в том лишь, что рабочий день кончился.
так что беда на серваке или на схд, но где и чего именно не хватает, понять не могу.

upd: вот только что закончился процессинг - я даже в бассейн не успел удрать :)

Alex_496, доброго времени суток.

прям вот скриптом бросить не смогу - у нас ит-безопасность очень... эээ... целеустремленная...
но на пальцах могу, если это приемлемо вам, ну и на вопросы отвечу, естественно - буде таковые возникнут.

в основе измерения звезда, аккуратно нарисованная в dsv (= все связи есть).
все таблицы, из которых тянутся данные непосредственно или опосредованно - через query \ view - лежат на одном сервере, хотя и в разных базах.
в центре -
named query на 40+ млн записей, который получается из таблицы при помощи where назначение которого - отсекать:
1. помеченные на удаление записи (в БД КИС записи удаляются, а в dwh помечаются на удаление)
2. историю, подернутую пеплом забвения финдепартамента ( rec_Create_DT >='20100101') .

на периферии -
порядка 80+ named query вида:


или


vSimpleEntity и vDubleEntity вьюхи над схемой, в которой живет объектная "база" для хранения junk_attributes.
в измерении 150+ атрибутов.
если ключи, имена и атрибуты для кастомных сортировок можно взять с периферии звездочки, они оттуда и берутся.
для таких атрибутов мощность от 2 до 8000 мемберов (больше тыс экзотика. таких атрибутов ровно две шт, типичные мощности до 100 мемберов)
есть десяток атрибутов мощностью от нескольких тысяч до 0,2 млн и пяток атрибутов от 0,5 до 5+ млн.
для них ключевые коллекции и имена берутся из центра звездочки.

в измерении есть 14 естественных иерархий на 3-6 уровней...
ну т.е. никакой экзотики.
про связи измерения в кубе - возможно, это важно, поскольку описываемая в теме ситуация возникала только в ходе update deployment, хотя - судя логам - еще _ДО_ начала деплоймента индексов партиций:
- с одной гм по факту.
- еще 5 гм связаны с этим измерением регулярно (фактов там от 10 млн до 0,5 млрд)
- еще одна гм на 0,5 млн записей имеет связь м2м
- в референсных связях рассматриваемое измерение прокладкой не работает, по очевидным причинам.

и самое главное - я об этом писал, но повторюсь:
измерение уже продолжительное время живет в неизменном виде и с ежедневными обновлениями, которые идут за 1- 3 часа.
шит стал хэппенз последние две недели, так что правдоподобной выглядит гипотеза, что на серваке что-то не в порядке.
но что саппорт схд\системы, что дба разводят руками и утверждают, что их железо и софт живут без явных патологий, хотя и под возросшей нагрузкой - в связи с предновогодьем .

Критик>>в основе измерения звезда

Это значит, что куб построен по снежинке?
Галка материализации стоит?
референсных связей в кубе нет вообще - галку ставить некуда .
схему данных, лежащую в основе _куба_в_целом_ я б не стал относить ни к одному "чистому" архетипу ;-)

StarikNavy,
нет.
в активити_мониторе виден как выполненный последний из процессов развертывания атрибутов - ну вот ровно для ключевого атрибута.
причем в АМ самого скрипта-то не видно, но процедурой его можно выдернуть.
это именно тот скрипт, который крутится для ключевого атрибута.
ну и в целом сиквель всем доволен:
т.е. там точно нет блокировок.
время от времени появляются подвисшие в ожидании тех или иных ресурсов процессы и дисковые очереди, но они на других базах крутятся.
это неприятно, но не может объяснять ситуацию:
такие PIDы как появляются так и исчезают помногу раз за тот период, когда SSAS уже явно нехорошо.
при этом - повторюсь - активных или зависших запросов от SSAS уже нет.
исключение - тот случай, когда развертывание зависло\отвалилось, а служба оставалась бодрой и даже позволила отдеплоить на том же кубе маленькое измерение в режиме update.
там процессы были, ясен пень, но все с ними завершалось благополучно.

Alex_496,
имеется ввиду процессинг измерения или куба разбить на данные и индексы?
дело в том, что ситуация воспроизводилась только и исключительно при процессинге измерения. куб можно разворачивать как угодно - можно гм по отдельности процессить, можно куб чёхом - предварительно параллелизм обрезав.
там ничего не падает.
копию измерения я уже создал и отпроцессил. нормально все прошло. но измерение свободное пока.
так что моя гипотеза - что баг как-то обусловлен архитектурой именно измерения - пока подтверждения не получил.
Впрочем, она и не отвергнута - потому что main тоже сейчас и сам не падает и службу не роняет.

Alex_496
>> в измерениях ключи, надеюсь, целочисленные?
почти все. исключения -
три атрибута, основанные на полях большой таблицы типа
char(3),
char(6),
char(9)
они тяжелые - третий как раз в категории под 8 млн записей.
без них не обойтись, но они процессятся заведомо нормально.
возможно потому, что это char из цифирек на самом деле - первые три, шесть, девять символов штрихкода.
>> сервер процессинга и сервер запросов - разнесены или все на одной службе?
на одной
>> может серверу OLAP не хватает оперативной памяти во время процесс индексов.
такое бывало. немного в другом контексте. боремся с этим явлением при помощи ограничения на память снизу и параллелизма при развертывании сверху.
кроме того, PAGEIOLATCH_SH и RESOURCE_SEMAPHORE
мониторятся и логируются централизованно на серваке.
и у процессов ссас это бывает крайне редко сейчас.
по кр мере когда наблюдались сбои, которые вынудили меня написать сюда, по моим запросам этого не было.
>> Перейти на версию 2014/2016, уж и не помню какие там болячки у 2005ой
в общих планах есть такое - в течение ближайшего квартала,
мотив, причем именно таков: многие косяки должны рассосаться.
но, не от меня зависит, а непрерывность сервиса надо обеспечивать уже сейчас...
классическая коллизия " а Мойша в постель ложись - план выполняй :)"
>>ProcessUpdate самый затратный, самый тяжелый, я его не испотльзую
с этого места поподробнее. мне как-то казалось, что update = data +index для измерения + index+aggr для всех партиций + скрипты.
нет разве?

Alex_496yah,
замените ключи на
CAST(HASHBYTES('SHA1', UPPER(string_field_1)) AS BIGINT) AS id_field_1
прикольно. а мотивировка общего характера под такое решение есть? ну, кроме, "попробовали, получилось быстрее".
и в связи с этим вопрос чуть в сторону: вот есть необходимость внутри записи таблицы-субстрата измерения что-то посчитать.

вот модельные примеры для понимания:
есть битовая маска, надо вытащить 0-й, 1-й,... 31-й биты по отдельности.

есть EAN, надо вытащить 1-3 цифры, 1-6, 1-9 - как у меня выше
это можно сделать несколькими разными способами:

внутри ETL все посчитать и записать в соотв поля соотв. таблицы в DWH

в упомянутой таблице DWH завести Computed column

написать вьюху и ее подсунуть в DSV как основу для измерения

в DSV написать named query.

как-то еще?
из общих соображений, что предпочтительнее? или, возможно, существуют какие-то контекстно зависимые рекомендации?

Alex_496добавить оперативной памяти насколько можно, например, у себя RAM повышаем до 512 Гб
хех... (грустно смотрит в папку \\Control Panel\All Control Panel Items\System) ясно что лучше быть здоровым и богатым
Alex_496желательно уйти от named query
выше вопрос ровно про это: куда?
Alex_496широкое измерение распилить вертикально на 2, сравнить, что это даст в плане производительности
есть такое в планах, хотя мотивировка - тяжелый ETL, который надо как-то распараллелить.
попутно и измерение попробую распилить.

Критик,
поясните, плз.

Критикyah,

Всякие битовые маски могут присутствовать только в stage-области, в области витрин он должны быть разбиты на отдельные поля.
я ж ровно о том же. вопрос был в том каким механизмом лучше разбивать.

поясню:
Пусть на источнике есть таблица t_Source, которая после ETL превратится в рекордсет t_DWH
который должен стать основой измерения (PrimeryKey из таблицы t_source будет ключевой коллекцией для ключевого (блин, простите за тавтологии :) ) атрибута измерения.

Пусть в t_source есть поле - field int = битовая маска.
и по логике вещей 1-й бит оттуда должен превратиться в атрибут с мемберами "неведомая хрень - да", "неведомая хрень -нет" в нашем измерении.
заводим в какой-то форме рекорсет


для нашего атрибута:
ключ берем из Ex_Id,
name из Ex_Name

но теперь табличку t надо как-то сджойнить с рекордсетом t_DWH,
значит в нем должно появиться поле

вот это case when ... и надо где-то как-то посчитать.
я там выше способы, которые в голову приходят, описал.
и спросил, какой из них с т.зр. уважаемого алекса_496 предпочтительнее.
Если у вас есть по этому поводу соображения, с удовольствием про них почитаю :).

ПС по главному вопросу темы: сбои SSAS похоже-таки привели лиц, принимающих решения, к мнению,
что домик из говна и палок - не самое хорошее место для построения критической отчетности.
так что ждем-с переезда: либо на новое железо, либо на хорошую ВМ на большом хосте.

Alex_496, Критик, спасибо за диалог.
наверное, я криво задал вопрос, но ответы были не о том.
всех с наступающим.
продолжим в новом году.
кампай! :-))