ptr128Имеем запросы, на выходе которых несколько десятков миллионов строк. Запросы не сложные, но требуют то сортировки для MERGE, то памяти для построения HASH таблиц. Параметр max degree of parallelism скромно 4. При 1 эти запросы работают в два раза дольше. При больше 4 - выгода малозаметна.
Проблема в том, что эти запросы упорно требуют по 25-45 гигабайт оперативки и покорно ждут, пока сервер не сможет им столько выделить. Причем, при выполнении, рекордный результат реального потребления памяти был меньше 10 гигабайт. Статистики обновлял, даже с FULLSCAN. Не помогает. В плане запроса количество записей в разы превышает реальное. Пока для хранилища не был выделен отдельный сервер, max degree of parallelism был 1 и памяти вполне хватало. Когда стало 4 - запросы стали выполнятся быстрее, но по одному. То есть, свыше половины времени, пока SSAS считывает результаты запроса, SQL сервер просто отдыхает.
Можно ли как то вручную ограничить размер памяти запрашиваемую запросом у сервера при старте?
Резюмирую. У Вас есть измерение чеков (или скидочных карт или еще чего). Вы вместо view поверх плоской таблицы сделали view как сцепка из основной таблицы и присоединенных через left join с разными служебными (перечень id и названий типов чека или перечень id и названий видов скидочных карт и так далее).

А дальше SSAS при попытке обновления измерения ProcessUpdate кидает в сторону SQL запросы select distinct [столбец_с_key_ключевого_атрибута_измерения],[столбец_с_name_ключевого_атрибута_измерения],[столбец_с_key_неключевого_атрибута1_измерения],[столбец_с_key_неключевого_атрибута2_измерения] from view, затем для каждого атрибута измерения select distinct [столбец_с_key_неключевого_атрибута1_измерения],[столбец_с_name_неключевого_атрибута1_измерения] from view - и в какой-то момент SQL строит совсем неверный план. Когда он считает, что key_неключевого совсем мало в большой таблице - он делает предварительный merge и использует несколько ядер, когда Вы ему зажимаете яйца в тисках степень MAXDOP в единицу - он отжирает память для HASH таблицы.

А совсем все таки печально и некошерно, когда у Вас внутри view используется openquery на другой сервер и джойнится что-либо из локальной SQL базы. И еще прав нет на просмотр статистики на удаленном сервере.

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

TaPaKptr128,

судя по вашему описанию вы хотите нажать кнопку - "сделать хорошо". Кривые запросы правятся конкретно каждый
Кнопка "сделать хорошо" в ее различных вариациях подробно описана в статьях блога Александра Южакова, который широко известен в узких кругах как уважаемый пользователь этого форума под ником Alex_496.

ptr128То есть, свыше половины времени, пока SSAS считывает результаты запроса, SQL сервер просто отдыхает.

Вы посмотрите, сколько служебных файлов типа map он обрабатывает внутри кубов, которые связаны с тем измерением, для которого Вы запустили ProcessUpdate, по дисковому монитору - и Вы таки удивитесь.
Строки со свежими данными из SQL - это далеко не все. Внутри SSAS своя черная магия.

ptr128,

ptr128Andy_OLAPПоэтому - сначала выгружаете в плоскую таблицу измерения.
Классная рекомендация, но не выполнимая. Не лезет.
Есть операции и есть их строки. До этого момента все классно. Меньше 20 млн. строк. Однако каждая операция сопоставляется с несколькими другими построчно, причем частично и разными датами. В итоге на выходе, после JOIN с таблицей сопоставления, возникают 300 млн. строк. И пишется этот результат на диск в случае плоской таблицы 12-16(!) часов. При том, что SSAS процессит это все из VIEW даже последовательно за 4-6 часов. Если запараллелить хотя бы по 2 крупных запроса, будет уже 3-4 часа. Вопрос однако...


Так у Вас есть виртуальная таблица фактов в 300 миллионов строк, поверх которой Вы соорудили несколько групп мер (в том числе с агрегациями distinct count).
Но инкрементальную подзагрузку плоской таблицы Вы почему-то не хотите. Потому как у Вас реализовано может быть только полная перевыгрузка за 12-16 часов (?!!!).
В таком случае, нужно разобраться, почему выгрузка из view со всеми ключами в плоскую занимает 12 часов, а выгрузка части столбцов, которые нужны для группы мер - 4-6 часов или 2-3 часа.
И перевыгружать порциями по 10-20 миллионов строк в цикле в плоскую таблицу. А далее поверх нее группы мер.

А иначе как Вы вообще сверяете факты в кубе и в исходной учетной системе, без построения витрин?

"эти запросы упорно требуют по 25-45 гигабайт оперативки и покорно ждут, пока сервер не сможет им столько выделить" - нет, Вы ведь кидаете запросы к операциям и их строкам напрямую на учетной системе, в этот момент пользователи активно вбивают новые документы, все в блокировках, все тормозит и ждет и душит друг друга.
Не надо так. Это грабли.