A best parctice az lenne, ha az adattárház és az Analysis Services (OLAP) külön vason futna. Csakhogy ennek megvalósítására ritkán van lehetőségünk. Inkább az a jellemző, hogy az adattárház vasára rátelepítjük az Analysis Services-t is. Persze a közös vasra telepített Analysis Services adattárház párosnak vannak előnyei is: Jobban kihasználható a gépek erőforrása, ha közös gépen fut az SSAS és az adattárház, kevesebb energiát fogyaszt,nem függ az SSAS felösszegzése a hálózat terheltségétől, stb. De amikor arról döntünk, hogy szeparáljuk-e az adattárházat és az Analysis Services-t, akkor a fentiek helyett inkább az anyagi lehetőségeink azok, amik determinálják a döntésünket.

Hogyan tudjuk optimalizálni a közös vason futó Analysis Services és adattárház teljesítményét? Erről szól a Microsoft SQL Server 2008 Analysis Services Consolidation Best Practices című cikk, melyből két gondolatot emelnék ki:

1. Érdemes korlátozni az SQL server memória felhasználását

Az SQL Szerver felzabálja a számára szükséges memóriát és utána nem nagyon ad belőle másnak. Ez jó. Ezt szeretjük benne J Csakhogy egy konszolidált környezetben, ahol az adattárház mellett fut az Analysis Services is, szegény Analysis Services-nek nem marad memória. Így célszerű lehet korlátozni az SQL Server számára elérhető memória méretét.

2. Felösszegzés közben konfiguráljuk át az SQL Servert

Egy Analysis Services adatkocka felösszegzése két fázisra bontható:

-          Process Data: amikor az Analysis Services átemeli az adatokat a relációs adatbázisból

-          Process index: amikor az Analysis Services kiszámolja a kocka aggregált pontjait.

Ez utóbbihoz (Process Index) már nem szükséges az SQL Server relációs motorja, így logikusnak tűnik, hogy a Process Data fázis után vegyük el az SQL Servertől a hardver erőforrásokat majd a Process Index művelet lezárulta után adjuk vissza neki azt.

További részletek a Microsoft SQL Server 2008 Analysis Services Consolidation Best Practices című cikkben.

A derived column taszk egy szinkron transzformációt megvalósító egység, így definíció szerint a taszk részfeladatokra történő bontásával nem tudunk párhuzamosítani, hiszen nem fog létrejönni új execution tree, és így minden egy szálon fog futni továbbra is. Na ez így bonyolult, úgyhogy inkább mutatok egy példát.

Tegyük fel, hogy adattárházat töltünk, és minden egyes adattárházba érkező sorthoz hozzáfűzünk két oszlopot. Az egyik tartalmazza, hogy melyik betöltéssel került be a rekord, a másik tartalmazza, hogy melyik forrásrendszerből érkezetett a rekord.

Definíció szerint nem érdemes két taszkban hozzáadni a bejövő rekordokhoz ezen azonosítókat, mert az SSIS nem párhuzamosan, hanem sorosan fogja őket végrehajtani. Ez igaz is. De az SQLCat-osok felfigyeltek arra, hogy egy Execution tree-n belül az SSIS képes egy execution tree-hez több puffert (max 5-öt forrásonként) is allokálni, így végső soron a szinkron transzformációk bontásával egy execution tree-n belül is lehet párhuzamosítani.

Ha tehát az alábbi derived column taszkot

Felbontjuk 4-5 derived column taszkra,

Akkor jelentősen, esetenként felére csökkenthető a betöltés időszükséglete. Érdekes.

Akiket érdekelnek a részletek az olvassa el az Increasing Throughput of Pipelines by Splitting Synchronous Transformations into Multiple Tasks című cikket. (De nem árt, ha előtte utánanéz az SSIS architektúrájának)

Idén október 19.-én kerül megrendezésre a harmadik Open Source BI konferencia, melyre szeptember 15.-ig még kedvezményesen lehet jelentkezni. (Korábbi rendezvények résztvevői augusztus 31.-ig további kedvezményt kaphatnak)

Az idei rendezvényen is lesznek felhasználó oldali esettanulmányok,szoftverbemutatók, szállító oldali prezentációk és az Open Source BI eszközök kiválasztásához, beszerzéséhez segítséget nyújtó előadások is.

Részletes program itt, regisztrálni itt lehet. Bencéék még augusztus 31-ig várják előadók jelentkezését, úgyhogy ha van egy jó témája, akkor hajrá!

Néhány gondolat Chris Webb Building a Better Cache-Warmer, Part 2: The Formula Engine Cache című cikkéből:

1. A hiedelemmel ellentétben, az SSAS cache-li a számított mezők eredményét (azaz nem mindig röptében számolja ki azokat)

2. Csak azokat az értékeket cache-li, amelyek a kocka vázába térnek vissza. (Pl db*egységár) De nem tudha cache-elni a bonyolult lekérdezés eredményeként előálló dimenzió elem halmazokat (de az azokhoz tartozó értékeket már igen) például nem tudja lekeselni azokat a vevőket, akik forgalma 10%-kal tér el az átlagtól. De ha ezt egyszer megcsinálja, akkor a vevők forgalmát már le tudja cache-elni, csak magukat a vevőket nem.

3. A cache élettartama. A számított mezők által visszaadott értékek a kocka felösszegzéséig (vagy a cache törléséig) tárolódnak a cache-ben. A with member-es, subselect-es lekérdezések eredménye viszont addig tárolódik a cache-ben, amíg a lekérdezés le nem fut. Utána törlődik. Mi következik ebből? Hogy az Excel 2007 által előállított lekérdezések eredménye nem cache-elődik! Az Excel 2007 ugyanis szinte mindig ilyen lekérdezéseket generál. Ergo tök felesleges bemelegíteni a formula engine cache-ét, az egy pillanat alatt ki fog hűlni és a következő lekérdezést ugyanúgy hideg cache-ből fogja kiszolgálni, mintha nem csináltunk volna semmit. Brrrrr

Eddig nem értettem, hogy miért nem lett gyorsabb néhány számított mezőt tartalmazó lekérdezésem a cache melegítés hatására, de most már  világos…

Adott a következő probléma: 1500 felhasználóhoz kell eljuttatnunk felhasználónként kb. 4-5 paraméterezett riportot. Azaz összesen mintegy 6-8000 riportot kell napi, heti rendszerességgel előállítanunk, olyan felhasználóknak, akik nem találhatóak meg a vállalat hálózatában. A jelentéseket egy könyvtárba kell elhelyezni (és onnan egy másik alkalmazás elhúzza majd), de szükség lehet az e-mailen történő disztribúcióra is. További követelmény, hogy a riportok az adatpiac feltöltése után automatikusan, vagy egy külső program által meghívva igény szerinti időpontban álljanak elő.

A fenti korlátozó tényezők miatt (on-demand futtatás, hálózaton kívüli felhasználók) a Reporting Services előfizetés alapú disztribúciós útja nem járható. Helyette más módszert kell találnunk az igények kielégítésére.

Megoldás itt található. Még nem jutottunk el oda, hogy kipróbáljuk, de mindenesetre lejegyzetelem, hogy erre kell indulnunk.

Analysis Services adatbázisok dokumentálását támogató ingyenes szoftver. Előnye, hogy ingyenes, hogy click-once alkalmazás (böngészőből fut), és hogy kliensről is futtatható (nem kell a szerverre telepíteni semmit). Hátránya, hogy iszonyú ronda html dokumentumot generál. Arra mindenesetre tökéletes, hogy

1)      legyen egy kereshető, portábilis, naprakész doksink az adatbázisról,

2)      ki tudjuk belőle másolni a fontos részeket és azt be tudjuk másolni dokumentációkba, prezentációkba

A U2U Analysis Services Documenter letölthető erről a címről: http://www.u2u.be/Tools/SQL05_ASDoc.aspx