Category Archives: SQL 2008

Audit na Microsoft SQL Serveru

Posted on by

Víte, kdo přistupuje k vašemu serveru a pracuje s vašimi daty? SQL Server 2008 představil jako jednu z novinek v Enterprise edici SQL Audit, který zaznamená veškeré informace.

C2 Audit

Možnost auditu je na SQL Serveru dostupná již od verze 2000, kde bylo možné zapnout tzv. C2 audit tracing, který ukládal informace o přístupu k objektům nebo spouštění jednotlivých dotazů, ať již úspěšné nebo neúspěšné. Při využití tohoto režimu byl audit soubor ukládán do výchozí složky pro data SQL serveru, a vždy po 200MB byl vytvořen další soubor. Velkou nevýhodou tohoto režimu je jeho značná náročnost na systémové prostředky a také jedno z pravidel C2 režimu, kdy v případě nemožnosti uložit informaci o auditu bude celá instance SQL Serveru vypnuta.

Continue reading →

Optimalizace nastavení SQL Serveru pro SharePoint 2010/2013

Posted on by

Při nasazení SharePoint Server 2010 nebo 2013 je jedním ze základních stavebních kamenů celé farmy i SQL Server, který nabízí nepřeberné množství konfiguračních položek. Pro optimální výkon celého prostředí je vhodné nastavit některé konfigurační volby tak, aby vyhovovaly právě SharePoint serveru. Mnohdy jsou tyto volby odlišné od těch, které bychom chtěli mít pro jiné produkční systémy, proto je také doporučeno pro nasazení SharePoint serveru mít dedikovaný SQL Server.

Auto Create and Update Statistics

Každá databáze vytvořená na SQL Serveru má několik „auto“ vlastností, které mají vliv na výkon dané aplikace. U všech SharePoint databází (konfigurační, servisní, obsahové) je vhodné nastavit tuto volbu na false, alespoň taková informace je k dispozici na stránce technet.microsoft.com. SharePoint server si řeší údržbu databáze pomocí Healt Analyzer pravidla, které je spouštěno každý den a stará se právě o statistiky na jednotlivých databázích. Toto pravidlo ale pouze volá uloženou proceduru, která není v každé SharePoint databázi a u takových je vhodné nechat tyto volby nastavené na true.

Continue reading →

SQL Server a vysoká dostupnost – IV.

Posted on by

V dnešním díle seriálu o vysoké dostupnosti se zaměříme na log shipping. Jedná se o funkci dostupnou v běžných edicích tj. Standard, Enterprise, Business Intelligence a Web. Log shipping automaticky zasílá zálohu transakčního logu z primárního serveru na několik sekundárních serverů. Na těchto sekundárních serverech je následně záloha transakčního logu obnovena.

Log Shipping nabízí několik zajímavých funkcí, mezi které patří Disaster Recovery pro jednotlivé databáze. Bohužel toto DR řešení nenabízí vysokou dostupnost, protože log shipping neumožňuje konfiguraci pro failover jako např. mirroring nebo AlwaysOn, které byly představeny v minulých dílech.

Konfigurace

Konfigurace log shipping je dostupná ve vlastnostech jednotlivých databází, stejně jako database mirroring. Při zapnutí je nejprve nutné nastavit zálohování transakčního logu databáze na dostupné úložiště pro ostatní log shipping partnery a intervaly pro jednotlivé zálohy. Čím kratší bude zvolený interval (výchozí hodnota je 15 minut) tím více budou databáze mezi servery synchronizované.

Continue reading →

SQL Server a vysoká dostupnost – I.

Posted on by

Vysoká dostupnost a Disaster Recovery (HA a DR) jsou u mnoha produktů často zaměňovány a často nesprávně požadovány při nasazení jednotlivých funkcí systému. Zatímco vysoká dostupnost se spíše zaměřuje na výpadky systému a služby, Disaster Recovery je využitá v mnohem širším spektru problémů. V případě využití SQL Server se mezi HA možnosti, které jsou nabízeny, řadí

  • Database Mirroring
  • Log Shipping
  • Failover Clustering
  • Replikace
  • AlwaysOn (od verze 2012)

Jednotlivé technologie pro vysokou dostupnost a jejich možnosti jsou odlišné v závislosti na použité edici SQL Serveru, zejména pro AlwaysOn je nutná edice Enterprise.

Continue reading →

Vliv Instant File Initialization na výkon SQL Serveru

Posted on by

SQL Server pokud je správně nastaven dokáže použít „Instant File Initialization (dále jen IFI) pro optimalizaci práce s diskovým systémem. Každá databáze SQL Serveru je tvořena minimálně dvěma soubory – souborem datovým (přípona mdf, master data file) a souborem pro transakční log (ldf, log data file). Při vytváření obou souborů je za výchozího nastavení nutné provést „nulování“ souboru, tj. nastavení jednotlivých bitů na hodnotu 0 pro celou velikost souboru. K těmto operacím dochází pří použití příkazů CREATE DATABASE, ALTER DATABASE (týká-li se IO), RESTORE DATABASE a v případě autogrow operací (každý soubor může být nastaven na autogrow v procentuelní velikosti, nebo v pevné velikosti přírůstku). Zejména v případě autogrow a restore je nutnost čekat na nulování souboru zdlouhavá a zbytečná (vezměme v úvahu případ obnovy databáze o velikosti 200GB, poté čekáme na zapsání nulových hodnot, než proběhne samotná obnova databáze i několik desítek minut). Celé nulování provádí samotný SQL Server, a ne NTFS filesystém.

Continue reading →

Práce s recovery modely na SQL Serveru

Posted on by

SQL Server ukládá veškeré informace do dvou typů souborů. Každá databáze je tvořena datovým souborem a souborem pro uložení transakčního logu. Každá databáze na SQL Serveru má ve svých vlastnostech nastaven tzv. režim logování (Recovery Model). Celkem máme k dispozici 3 režimy, které ovlivňují styl práce s transakčním logem a také mění nároky na Disaster Recovery procesy.

sqlrecovery01

V případě manipulace s daty je třeba, aby veškerá data potřebná pro danou operaci byla nejprve načtena do tzv. data bufferu. Následně v bufferu SQL Server uzamkne v několika krocích data, tak, aby zajistil, že uživatel nemůže data, která se právě mění, číst. Toto chování je ovlivnitelné pomocí několika režimů pro izolace transakcí, případně je ovlivnitelné pomocí tzv. hints v rámci dotazů. Po uzamčení veškerých dat může SQL Server provést např. změnu požadovaných dat a zároveň s touto změnou jsou veškeré údaje uloženy do transakčního logu.

Continue reading →

Šifrování dat na SQL Serveru

Posted on by

Zabezpečení dat na SQL serveru se dá uchopit mnoha různými způsoby. Ve verzi SQL Server 2008 Enterprise byla představena nová možnost ochrany dat, označována jako Transparent Data Encryption. Styl práce TDE je poněkud odlišný od tradičního šifrování dat na úrovni jednotlivých sloupců. Při využití TDE je celá databáze šifrována zcela automaticky bez zásahu uživatele a hlavně bez změny programového kódu užívaného pro databázové aplikace. Velké využití získává TDE v případech fyzického zabezpečení datových nosičů a záloh jednotlivých databází. Ano! I samotné databázové zálohy jsou stále pod ochranou TDE a tedy již není běžně možné vzít si backup databáze a bez problémů jej obnovit na jiný server. Proces šifrování a dešifrování probíhá na úrovni načítání datových stránek do paměťového bufferu. V paměti se poté již nachází data v rozšifrované podobě. Cílem TDE je tedy chránit data ve fyzických souborech určených pro ukládání dat (mdf), transakčním logu (ldf) a záloze (bak). K šifrování dat dochází při jejich uložení na disk z paměťového bufferu zcela automaticky bez jakéhokoli zásahu uživatele. Celý proces vyžaduje určitý výpočetní výkon, obě operace – šifrování i dešifrování – potřebují pro svou práci systémové prostředky serveru. Tyto nároky jsou však mnohem nižší než u klasického šifrování sloupců, které bylo dostupné na dřívějších verzích SQL Serveru. Microsoft udává, že dochází ke zpomalení v řádu cca 3 – 5 %, což může být vzhledem k vyšší bezpečnosti dat přijatelná hodnota. Velkou výhodou TDE je také zachování možností indexace dat a bezproblémového využití cizích klíčů.

Implementace Transparent Data Encryption

Samotná implementace TDE spočívá ve 4 krocích, které je nutné provést

· Vytvoření master key

· Vytvoření nebo instalace certifikátu, chráněného master key

· Vytvoření databázového šifrovacího klíče a jeho ochrana certifikátem

· Konfigurace TDE v databázi.

Continue reading →

Integrace SharePoint 2010 a SQL Server Reporting Services

Posted on by

Jedním z pilířů Microsoft Business Intelligence jsou SQL Server Reporting Services. Jedná se o komplexní platformu pro generování sestav z mnoha datových zdrojů, jako je:

  • SQL Server
  • Oracle
  • DB2
  • SAP
  • Hyperion
  • SharePoint atd.

01ssrs01Při instalaci SSRS je nutné zvolit, jestli chceme, aby běžely v tzv. nativním režimu, nebo byly integrovány s platformou SharePoint. V tomto článku si ukážeme, jak propojit SSRS a SharePoint 2010.

Tento režim integrace lze měnit i po konfiguraci Reporting Services.

Nativní režim SSRS umožňuje instalaci nezávisle na SharePoint platformě. Pro správu prostředí poté můžeme využít webovou aplikaci Report Manager.

Při instalaci SSRS v integrovaném režimu, což je varianta kterou v následujících odstavcích popisujeme, je tato aplikace vypnuta a správa probíhá na straně SharePoint. V tomto režimu jsou všechny reporty ukládány přímo do SharePoint dokumentových knihoven a tím jsou dostupné příslušným uživatelům. Navíc v tuto chvíli celé zabezpečení stojí na straně SharePoint a nemusíme tedy zvlášť nastavovat SSRS a SharePoint skupiny zabezpečení.

Na straně SharePoint musí být nainstalován SQL Server Reporting Services Add-in, o tuto operaci se postará sám instalátor SharePoint v rámci instalace prerekvizit. Všechny tyto prerekvizity jsou stahovány během instalace z internetu, v případě že byste chtěli jednotlivé komponenty instalovat ručně, najdete tento addin jako součást SQL Server 2008 R2 Feature Pack.

Continue reading →