Temat: Optymalizacja: Analysis Services 2000

Hej,
Probuję rozgryźć temat optymalizacji czasów procesowania kostek Analysis Services - w wersji 2000, stojące na bazie 2000, niestety (bo nie ma DMV + cała reszta związana z 2000..).

Odpalam profilera, podłączam się do bazy z której korzysta AS. Odpalam procesowanie kostki. Proifiler wyrzuca mi kod TSQL, te zapytania które się najdłużej wykonują wrzucam sobie w SMS, odpalam plan zapytania, zmieniam indexy, zakładam indexy, zmieniam kod widoków itp itd, czyli do tej pory standard. Testuje poprawioną bazę - widzę powiedzmy 1000% wzrost wydajności podczas odpalania zapytań z AS bezpośrednio w SMS.

Zadowolony odpalam procesowanie kostki i ... No w sumie nic, bo procesowanie zajmuje tyle samo czasu co wcześniej.

Pytanie: w jaki sposób sprawdzić co i gdzie mogę poprawić, żeby przyspieszyć procesowanie kostek? Na co zwrócić uwagę? Dodam, że zapuszczałem już perfmon i sprawdzałem waitstats servera, niestety nie dają żadnej odpowiedzi na moje pytanie.

[EDIT] Pytanie pomocnicze: co sie dzieje kiedy analysis manager pisze: "Read xxxx rows". To jest to, co mu zapytanie zwraca, czy cos co sobie sam kalkuluje? Bo mam wrazenie, ze zapytania sa zwyczajnie nie skalowalne i dla np 1000 wierszy mam 1000% wzrost wydajnosci, dla miliona 50%, dla 100 milionow 2%..Bartosz Ślepowronski edytował(a) ten post dnia 22.03.11 o godzinie 09:26

Temat: Optymalizacja: Analysis Services 2000

Zoptymalizowane zapytanie to już jakiś plus, ale to akurat niewiele czasu pochłania. A indeksy kosztują - szczególnie gdy zasilanie nie będzie przyrostowe.
"read ## rows" oznacza, że SQL zwraca już dane a SSAS zaczyna je tłoczyć w fizyczny storage kostek. Sposoby na przyspieszenie to:
- szybsze dyski, RAID 10 czy nawet 101 czyli standard
- mniej miar i mniej wymiarów w kostce - ładowanie wtedy jest zdecydowanie szybsze
- mniejsze klucze (np. int zamiast varchar)
- podział na partycje i równoległe procesowanie partycji (ale tu nie za bardzo pamiętam jak SSAS2000 to robi, nowsze wersje dużo tu zyskują).
Po załadowaniu danych zaczyna się tworzenie agregacji - tutaj można powyrzucać agregacje niepotrzebne lub/i nieużywane - mniej agregacji to szybsze procesowanie.

pozdrawiamGrzegorz Stolecki edytował(a) ten post dnia 27.03.11 o godzinie 00:05

Temat: Optymalizacja: Analysis Services 2000

Grzegorz Stolecki:
Zoptymalizowane zapytanie to już jakiś plus, ale to akurat niewiele czasu pochłania. A indeksy kosztują - szczególnie gdy zasilanie nie będzie przyrostowe.
"read ## rows" oznacza, że SQL zwraca już dane a SSAS zaczyna je tłoczyć w fizyczny storage kostek. Sposoby na przyspieszenie to:
- szybsze dyski, RAID 10 czy nawet 101 czyli standard
- mniej miar i mniej wymiarów w kostce - ładowanie wtedy jest zdecydowanie szybsze
- mniejsze klucze (np. int zamiast varchar)
- podział na partycje i równoległe procesowanie partycji (ale tu nie za bardzo pamiętam jak SSAS2000 to robi, nowsze wersje dużo tu zyskują).
Po załadowaniu danych zaczyna się tworzenie agregacji - tutaj można powyrzucać agregacje niepotrzebne lub/i nieużywane - mniej agregacji to szybsze procesowanie.

Dzięki, dokładnie to zasugerowałem. Wszystkie statystyki jakie jestem w stanie wyciagnąć sugerują że problemem jest wydajność dysków (zresztą nawet nie dysków tylko całego SAN) - przynajmniej przy obecnej architekturze procesu ETL. A architektury to ja zmieniać nie zamierzam :-)