SQL Server Reporting Services 1/3

Tak ako v prípade relačnej databázy SQL Server 2008, inovácia neobišla ani Reporting Services 2008. V tejto časti nášho seriálu sa pokúsime odpovedať na otázku, či túto inováciu môžeme považovať za zásadnú alebo či sa jedná len o tzv. facelifting.

Škálovateľná architektúra
Jedným z problémov predchádzajúcej verzie Reporting Services bola nedostatočná škálovateľnosť pri generovaní reportov obsahujúcich väčšie množstvo dát – ak report pozostával zo stoviek strán, tak jeho rendering trval príliš dlho. Navyše pri väčšom množstve nasadených reportov často dochádzalo k problémom s nedostatkom pamäte Report servra, ktorý obsadil celú dostupnú pamäť servera na úkor ostatných aplikácií. A administrátori neboli práve najšťastnejší z nutnosti inštalácie Internet Information Servra len pre potreby Reporting Services.
Aj tieto nedostatky sú adresované v novej verzii Reporting Services, ktorá prináša od základu prepracovanú architektúru Report Servra – od natívnej podpory ASP.NET a HTTP.SYS, konsolidácie všetkých aplikácií Report Servera (web services Report Servra, Report Manager a ostatné úlohy bežiace na pozadí) do jednej služby, pridanie autentikačnej vrstvy, možnosť konfigurácie pamäte a end-to-end logovanie.


Obr. č.1 Architektúra Reporting Services 2008

Natívna podpora HTTP.SYS a ASP.NET
Požiadavka na odstránenie závislosti od webového servra IIS bola realizovaná implementovaním http listenera, ktorý odchytáva požiadavky prichádzajúce požiadavky smerované na HTTP.SYS, ktorý je súčasťou operačného systému. HTTP listener odchytené požiadavky presmeruje na autentikačnú vrstvu. Ak budete teda chcieť využívať Reporting Services 2008 bez Internet Information Services, tak budete musieť používať operačný systém so zabudovaným HTTP.SYS (Windows Server 2003 a vyšší).

Konsolidácia web služieb Reporting Services
Report Server pozostáva z nasledovných aplikačných komponentov –web služba samotného Report Servera určená pre interaktívne procesovanie reportov, Report Manager a úlohy, zabezpečujúce rendering a doručovanie reportov na pozadí. Všetky tieto komponenty sú teraz implementované ako Windows service, a teda sú spúšťané v rámci jedného procesu, zdieľajú kontext jedného užívateľského účtu, používajú tie isté konfiguračné súbory a pristupujú k jednej konfiguračnej databáze. Tieto aplikačné komponenty sú prevádzkované v samostatných aplikačných doménach, čiže je možné každú komponentu konfigurovať zvlášť a je možné nevyužívané komponenty vypnúť. Na druhej strane ale konfigurácia památe je spoločná pre celý Windows service. V prípade potreby je možné každý komponent nainštalovať do samostatnej inštancie a potom konfigurácia pamäte Windows service v každej inštancii zodpovedá konfigurácii príslušného aplikačného komponentu Report Servra.

Autentikácia
Nakoľko bola odstránená závislosť na IIS, bolo potrebné pre verifikovanie identity užívateľov dopracovať autentikačnú vrstvu priamo do Reporting Services. Autentikačná vrstva podporuje nasledovné spôsoby autentikácie:
•        Windows Integrated Security
•        NTLM
•        Basic
•        Forms
•        Custom authentication
•        Anonymous (podporovaná jedine prostredníctvom rozšírenia custom authentication)

Spôsob autentikácie sa nastavuje v konfiguračnom xml súbore RSReportServer.config:

<Authentication>
        <AuthenticationTypes>
                <RSWindowsNegotiate/>
        </AuthenticationTypes>
        <EnableAuthPersistence>
                true
        </EnableAuthPersistence>
</Authentication>

Konfigurácia pamäte
V prechádzajúcej verzii Report Server využíval celú dostupnú pamäť servera – Reporting Services 2008 umožňujú nastaviť veľkosť pamäte pre Report Server, a to dokonca nielen po jednotlivých aplikačných doménach (v prípade využívania viacerých inštancií), ale máme k dispozícii aj možnosť nastavenia spôsobu odozvy Report Servra na nedostatok pamäte. Nastavenie pamäte sa definuje v konfiguračnom súbore RSReportServer.config:

        <MemorySafetyMargin>80</MemorySafetyMargin>
        <MemoryThreshold>90</MemoryThreshold>
        <WorkingSetMaximum>4000000</WorkingSetMaximum>
        <WorkingSetMinimum>2400000</WorkingSetMinimum>

Parametrami WorkingSetMinimum a WorkingSetMaximum definujeme veľkosť pamäte, ktorú môže využívať Report Server. V našom prípade je minimum 2,4 GB a maximum 4 GB.


Obr. č.2 Konfigurácia pamäte Report Servera

Parametrami MemorySafetyMargin a MemoryThreshold môžeme definovať spôsob odozvy Report servera na nedostatok pamäte. Report Server sa správa podľa nasledovných pravidiel:

Využitie pamäte	Spôsob odozvy Report Servera
Low	Existujúce požiadavky sú procesované, nové požiadavky sú väčšinou akceptované, požiadavkam na background processing je znížená priorita
Medium	Existujúce požiadavky sú procesované, nové požiadavky môžu byť akceptované, požiadavkam na background processing je znížená priorita. Veľkosť pamäte pre všetky aplikačné komponenty je redukovaná, najviac však pre background processing
High	Veľkosť pamäte je všetkým aplikačným komponentom ďalej redukovaná, ďalšie požiadavky aplikácií Report servera na pridelenie pamäte sú zamietnuté. Procesovane existujúcich požiadaviek je spomalené a nové požiadavky sú odmietnuté. Report Server môže swapovať dáta z pamäte na disk.

End-to-end logovanie
Všetky HTTP požiadavky smerované na Report Server (teda na všetky jeho aplikačné komponenty – Report Server web service, Report Manager, background processing) sú zaznamenávané do jedného logovacieho súboru ReportServerService_<timestamp>.log, ktorý je ekvivalentom IIS log súboru. Okrem toho je k dispozícii Report Server Execution Log uložený v databáze Report Servera, Report Server Service Trace Log obsahujúci detailné informáce použiteľné len pre prípadnú diagnostiku, Windows apliačný log, Windows Performance Log pre monitorovanie výkonnosti Report Servera a pre riešenie prípadných inštalačných problémov aj Setup log súbory.
V ďalšej časti sa pozrieme bližšie na tvorbu a nové možnosti procesovania reportov.

Microsoft SQL Server 2008 – Nové vlastnosti T-SQL.

Po základnom prehľade noviniek SQL Server 2008, ktoré boli viacmenej určené pre databázových administrátorov, prichádzajú na rad novinky pre programátorov. Niektoré novinky boli už na stránkach tohto časopisu predstavené (LINQ, ...), my sa budeme v tejto časti venovať novinkám v oblasti jazyka Transact SQL.

Dátumové dátové typy
Pravdepodobne najžiadanejšou zmenou pred uvedením SQL Server 2008 bolo zlepšenie dátumových dátových typov – špeciálne zavedenie oddeleného dátumového a časového dátového typu. SQL Server 2008 uvádza úplne nové dátové typy DATE, TIME a DATETIMEOFFSET a vylepšuje existujúci dátový typ DATETIME zavedením dátového typu DATETIME2. V nasledovnej tabuľke sú zhrnuté ich charakteristiky:

Dátový typ	Rozsah	Presnosť	Použitie
DATE	1.1. 0001-31.12.9999	1 deň	2009-10-05
TIME	-	100 ns	12:15:55.1234567
DATETIME2	1.1. 0001-31.12.9999	100 ns	2009-10-05 12:15:55.1234567
DATETIMEOFFSET	1.1. 0001-31.12.9999	100 ns	2009-10-05 12:15:55.1234567 + 03:00

Pozn.
Dátový typ DATETIMEOFFSET rozširuje existujúci dátový typ DATETIME2 o podporu časovej zóny.

HIERARCHYID
Ďalším novým dátovým typom je HierarchyID, ktorý je určený pre manipuláciu s hierarchickými údajmi. Interne je tento dátový typ implementovaný ako VARBINARY hodnota určujúca aktuálnu pozíciu uzla v hierarchii. Pre manipuláciu s hierachickými dátami môžeme použiť definované metódy HIERARCHYID:GetRoot(), GetLevel(), GetDescendant(), GetAncestor(), Parse(), GetReparentedValue(), Read(), Write(), ktoré sú prístupné prostredníctvom T-SQL alebo klientskeho API.

Large UDT
V predchádzajúcej verzii SQL Server 2005 bola maximálna veľkost user-defined types (UDT) v CLR stanovená na 8000 bytov. SQL Server 2008 rozširuje maximálnu veľkosť UDT na 2 GB. Ak hodnota UDT je menšia ako 8000 bytov, SQL Server s ňou zaobchádza ako v predchádzajúcej verzii SQL Server 2005. Ak hodnota prekročí 8000 bytov, databázový engine ju interpretuje ako large object s unlimited veľkosťou. Jeden zo spôsobov uplatnenia large UDT je implementácia priestorových dátových typov - SQL Server 2008 podporuje dátové typy GEOMETRY a GEOGRAPHY, ktoré sú implemetované práve ako CLR UDT.

Row Constructor
V najnovšej verzii SQL Server 2008 je podporovaná aj vlastnosť row constructor, pomocou ktorej môžeme napríklad vložiť viacero záznamov jedným príkazom INSERT:

INSERT INTO dbo.Customers(custid, companyname, phone, address)
VALUES
  (1, 'cust 1', '(111) 111-1111', 'address 1'),
  (2, 'cust 2', '(222) 222-2222', 'address 2'),
  (3, 'cust 3', '(333) 333-3333', 'address 3'),
  (4, 'cust 4', '(444) 444-4444', 'address 4'),
  (5, 'cust 5', '(555) 555-5555', 'address 5');

Rovnako môžeme túto vlastnosť využiť aj pri definovaní vnútornej query CTE.

Table-valued parameter
SQL Server 2008 podporuje aj zadávanie parametrov vo forme tabuľky – táto vlastnosť je nazývaná table–valued parameters. O čo v skratke ide – vývojári majú teraz možnosť vytvoriť uloženú procedúru alebo funkciu, ktorá akceptuje parameter typu table. Pred volaním danej procedúry alebo funkcie sa parameter naplní údajmi, ktoré chceme spracovať v procedúre, a následne sa zavolá procedúra s naplneným parametrom typu table. Parameter musí byť definovaný ako READONLY. Jedno z možných použití je náhrada temporary tabuliek, nakoľko table typ nevytvára štatistiky a nie je potrebná rekompilácia procedúry. Na druhej strane neexistencia štatistík prináša j nevýhodu – je potrebné zvážiť aj výkonnosť procedúry pri väčšom množstve záznamov.

MERGE
Príkaz MERGE je štandardný príkaz, ktorým môžeme súčasne vykonať príkazy INSERT, UPDATE a DELETE podľa definovaných podmienok. Výhoda používania MERGE príkazu je v tom, že okrem toho, že je tento príkaz atomický, tak jeho výkonnosť je lepšia ako v prípade vykonania individuálnych príkazov INSERT, UPDATE, DELETE. MERGE môžeme využíva pri porovnávaní obsahu 2 tabuliek – jedna je definovaná ako zdrojová príkazom USING a druhá ako cieľová príkazom MERGE INTO. Definovanie podmienky je podobné ako pri JOIN – špecifikovaním predikátu ON príkazom, ktorým definujeme ktoré záznamy zo zdrojovej tabuľky sa zhodujú so záznamami v cieľovej tabuľke, ktoré záznamy sa nachádzajú len v zdrojovej tabuľke a ktoré sa nachádzajú len v zdrojovej tabuľke. Na základe takto definovanej podmienky môžeme určiť, ktoré záznamy sa majú vložiť do cieľovej tabuľky, ktoré sa majú aktualizovať a ktoré prípadne zmazať:

MERGE INTO dbo.Customers AS TGT
USING dbo.CustomersStage AS SRC
  ON TGT.custid = SRC.custid
WHEN MATCHED THEN
  UPDATE SET
    TGT.companyname = SRC.companyname,
    TGT.phone = SRC.phone,
    TGT.address = SRC.address
WHEN NOT MATCHED THEN
  INSERT (custid, companyname, phone, address)
  VALUES (SRC.custid, SRC.companyname, SRC.phone, SRC.address)
WHEN NOT MATCHED BY SOURCE THEN
  DELETE

Grouping sets
Vďaka rozšíreniu príkazu GROUP BY o tzv. GROUPING SETS majú vývojári možnosť definovať viacnásobné zoskupovanie výsledného resultset-u v query. Logicky rovnaký výsledok je možné dosiahnuť aj viacnásobným spustením tej istej query s rôznym triedením a výsledok spojiť pomocou UNION ALL. Výhoda GROUPING SETS je v tom, že výsledný kód je prehľadnejší a vďaka optimalizácii prístupu k dátam a prípadnom počítaní agregácií aj rýchlejší.

SELECT custid, empid, YEAR(orderdate) AS orderyear, SUM(qty) AS qty
FROM dbo.Orders
GROUP BY GROUPING SETS (
  ( custid, empid, YEAR(orderdate) ),
  ( custid, YEAR(orderdate)        ),
  ( empid, YEAR(orderdate)         ),
  () );

Samostaný článok by si zasluhovali aj ďalšie nové vlastnosti, ako napr. Sparse columns, filtrované indexy a štatistiky, rozšírenia DDL triggrov a pod., alebo aj podrobnejšie predstavenie a použitie nového dátového typu HIERARCHYID. Vzhľadom na rozsah článku sa budeme tejto problematike venovať podrobnejšie v niektorom z ďalších článkov.

Resource Governor – riadenie zdrojov SQL Server 2008

Možnosť spravovania zdrojov databázového servera je vlastnosť, ktorú by mal mať každý databázový systém s ambíciou uplatniť sa v tom najnáročnejšom – podnikovom – prostredí. Spoločnosť Microsoft takúto ambíciu pre SQL Server deklaruje už dávnejšie a postupne tento jeden zo svojich vlajkových serverovských produktov dopĺňa o vlastnosti potrebné na uplatnenie sa v tomto segmente. Tak je to aj v prípade najnovšej verzie SQL Server 2008, ktorý prvý krát obsahuje aj nástroj na riadenie zdrojov servera.
Resource Governor – tak sa tento nástroj v terminológii Microsoft nazýva – je novou technológiou na spravovanie zdrojov SQL Server 2008. V súčasnej verzii je možné riadiť CPU a pamäť a pozrime sa teda bližšie na to, čo vlastne riadenie zdrojov predstavuje. V prípade SQL 2008 Resource Governor prideľuje podľa vopred nastavených pravidiel zdroje (ako sme spomínali množstvo CPU a pamäte) prichádzajúcim požiadavkám (dotazom). Ak teda vieme našich užívateľov rozdeliť (klasifikovať) do logických skupín (napr. analytici, bežní užívatelia, management a pod.), tak potom môžeme týmto skupinám prideliť podľa priorít príslušné zdroje – tak napr. bežným užívateľom pridelíme 40% CPU, analytikom 30% CPU a managementu 20% CPU. V prípade, že tieto skupiny užívateľov budú v rovnakom čase súťažiť o zdroje servera, Resource Governor uplatní nadefinovanú politiku rozdelenia zdrojov a tak zabezpečí, že nenastane preťaženie servera a server bude vykazovať konzistentný čas odozvy v danom čase.
Ako sa teda dopracujeme k danému stavu ? Resource Governor sa skladá z nasledovných komponentov:

Klasifikačná funkcia
Pomocou tejto funkcie zabezpečíme klasifikáciu našich užívateľov pri prihlasovaní sa na server do skupín, ktorým budeme neskôr prideľovať zdroje nášho servera. Túto funkciu si musíme napísať sami, v danom čase môžeme využívať len jednu funkciu a táto funkcia musí byť skalárna. Užívateľov môžeme klasifikovať podľa nasledovných systémových funkcií:

        •        HOST_NAME()
        •        APP_NAME()
        •        SUSER_NAME()
        •        SUSER_SNAME()
        •        IS_SRVROLEMEMBER()
        •        IS_MEMBER()

Okrem týchto funkcií môžeme využívať aj funkcie LOGINPROPERTY a CONNECTIONPROPERTY.

Resource Pool
Resource Pool reprezentuje fyzické zdroje servera (ako sme spomínali CPU a pamäť). Defaultne server využíva 2 resource pooly – default a internal. Okrem týchto 2 default-ných poolov si môžeme vytvoriť aj vlastné resource pooly. V zásade má resource pool 2 časti pre každý zdroj servera:

        •        MIN a MAX pre CPU
        •        MIN a MAX pre pamäť

Workload Group
Všetky požiadavky (sessions) prichádzajúce na server sú klasifikované funkciou a zoskupené do skupín – tzv. Workload Groups. Na všetky sessions zo skupiny je potom aplikovaná príslušná politika riadenia zdrojov.
Najlepšie si koncept fungovania Resource Governor ozrejmíme podľa nasledovného obrázku:
1.        Užívateľ alebo aplikácia vytvorí session na SQL Server 2008
2.        Táto session je klasifikovaná klasifikačnou funkciou
3.        Klasifikovaná session je priradená do príslušnej skupiny (Workload Group)
4.        Príslušná skupina využíva pridelený Resource Pool, ktorý limituje využívanie pridelených zdrojov danými užívateľmi alebo aplikáciou

Obr. Architektúra Resource Governor

Administrácia zdrojov SQL Servera v praxi
Prideľovanie zdrojov SQL Servera sa nám osvedčí v prípade, ak potrebujeme navzájom od seba oddeliť definované typy záťaže – napr. v prípade, že náš OLTP systém využívajú užívatelia počas dňa na zadávanie dát a súčasne vedúci pracovníci alebo analytici využívajú ten istý db server na analytický reporting, čím môžu nepriaznivo ovplyvňovať odozvy prvej skupiny užívateľov.
Ďalším príkladom môže byť nasadenie a využívanie jednej z noviniek SQL Server 2008, a to Backup Compression – pri využívaní tejto vlastnosti môžeme očakávať mierny nárast záťaže CPU (v porovnaní so zálohovaním bez kompresie), ale s pomocou Resource Governora je možné nastaviť limit využívania CPU pre zálohovanie s kompresiou a zabezpečiť tak ponechanie pôvodných zdrojov na prevádzku.
Resource Governor je možné využívať aj na monitorovanie behu jednotlivých dotazov/procedúr – ak niekorá query presiahne nastavený časový limit – dajme tomu 60 sekúnd – tak máme možnosť odchytiť alert vygenerovaný Resource Governorom, identifikovať danú query a online upraviť konfiguráciu Resource Governora tak, aby daná query mohla využívať len obmedzené zdroje servera.
Čo dodať na záver ? Snáď ešte zopár odporúčaní pre nasadzovanie do prevádzky – Resource Governor je úplne nová technológia a preto je vhodné dodržať istú ostražitosť pri jej implementácii. Ako prvý krok je vhodné použiť Resource Governor len na monitorovanie existujúcej záťaže a podľa týchto výsledkov potom pripraviť politiku rozdeľovania záťaže. A zároveň je vhodné pre administrátorov využívanie DAC – Dedicated Administrator Connection – nakoľko táto connection nespadá do správy Resource Governor-a a v prípade potreby je možné použiť ju na prípadné riešenie problémov s nesprávne nastavenými politikami.