SQL Server 2005 relációs adattárház technológiák Kószó Károly rendszermérnök Microsoft Magyarország karolyk@microsoft.com

Tartalom Partícionálás Tömörítés Indexelt nézetek Adatváltozások észlelése, átvétele Konfigurálás, optimalizálás

Partícionálás Mikor? Hogyan? Több tábla, vagy egy, partícionált tábla Az optimalizáló viselkedése („partíció kizárás”) Csúszó időablak kezelés Több fájlcsoport – read-only adatok („adat öregítés”) Mentés, helyreállítás

Mikor partícionáljunk? Legalább 100 GB-os tábla, vagy Lassú a karbantartás Adatbetöltés Indexelés Mentés Lassú lekérdezések Költséges tárolás

A partícionált táblák előnyei Kezelhetőség Gyors adatbetöltés és törlés Darabonkénti mentés/visszatöltés a „régi” adatokra Partíciónkénti index kezelés Nincs index töredezettség a régi adatokra Eltérő tárolási mód lehetséges a régi adatokra Jobb lekérdezési sebesség a nagy táblák esetén Hatékony join, ha az illeszkedő táblák azonosan partícionáltak Kisebb index fát és adatpartíciót kell bejárni Manageability 1. Deletion and data loading can be very fast if done by partition. 2. Backup and restore of partitions provides flexibility – only backup those partitions that change rather than entire monolithic table. Create a backup of historic data once. Can recover a single partition without bringing the table down, as long as queries are not accessing the partition being recovered, query activity continues uninterrupted. 3. Can reorganize, optimize and rebuild indices by partition. Less intrusive, faster to do a partition at a time. Spread maintenance over days rather than bringing a 3TB table down for maintenance. 4. Less fragmentation of indexes because history doesn’t change. Hot spots in current partition, easier to manage rather than a single object with page split & fragmentation. This allows you to concentrate on the hot partitions and reorganize as needed. 5. Alternative storage: example, can use NTFS file compression on historical data in SQL2005. Historical unchanging data on a compressed filegroup will the current data can be kept on high performance RAID10 file group. Performance Faster joins – special performance advantages with aligned tables (e.g. partitioned in the same manner) Smaller b-trees for each partition makes partition access fast, especially when we limit rows by partition key, accessing a subset of data. 3. In SQL2000, the time it takes to optimize a partitioned view is a function of how many tables are in the underlying partitioned view. Treating a SQL2005 partitioned table as a single object means smaller more concise query plans, optimization is fast, and many operations can be done in parallel. 4. Another example of performance benefits in terms of concurrency, lock escalation stops at the partition level.

Hogyan partícionáljunk? SQL Server 2005 előtt Több tábla, partícionált nézet; „manuális” (-) Akár több gépes tárolás, független indexelés (+) A nézet nem használható, ha egy tábla kiesik (-) Már nem igazán javasolt technológia (-) SQL Server 2005 „Valódi” partícionált tábla Az alkalmazások számára egyetlen tábla; a tároló motor osztja szét a partíciókat A partíciók egy adatbázison belül vannak (-) A tábla elérhető marad, ha egy partíció offline (+) Ez a további fejlesztések iránya (+)

Partícionált táblák létrehozása create partition function az osztáspontok felsorolása create partition scheme a tárolás megadása: partíció  fájlcsoport create table … on <partition scheme> create index… on <partition scheme> Célszerű ugyanazt a sémát használni a táblára és indexeire, illetve több táblára

Partícionált táblák illesztése SELECT o.OrderID, o.OrderDate, o.VendorID, od.ProductID, od.OrderQty FROM dbo.Orders AS o INNER JOIN dbo.OrderDetails AS od ON o.OrderID = od.OrderID AND o.OrderDate = od.OrderDate WHERE o.OrderDate >= '20040701' AND o.OrderDate <= '20040930 11:59:59.997'

Partíció kizárás SELECT o.OrderID, o.OrderDate, o.VendorID, od.ProductID, od.OrderQty FROM dbo.Orders AS o INNER JOIN dbo.OrderDetails AS od ON o.OrderID = od.OrderID AND o.OrderDate = od.OrderDate WHERE o.OrderDate >= '20040701' AND o.OrderDate <= '20040930 11:59:59.997'

Csúszó időablak kezelés Új adatok betöltése 2002-01-01 2003-01-01 2004-01-01 2005-01-01 2006-01-01 [üres] [üres] [üres] Partíció # 1 2 3 4 5 6 2001 & korábbi 2002 adatok 2003 adatok 2004 adatok 2005 adatok 2005 & későbbi 2006 & későbbi Előkészítő tábla létrehozása Split az utolsó partíción (alter partition func.) Bulk load és index az előkészítő táblán Switch (alter table … switch partition) Main design point for sliding window is you always reserve an empty partition at either end. This means switching operations will be instantaneous for either adding (switching in) or archiving (switching out) The idea of doing this as efficiently as possible – keep table available, meta data only e.g. pointer switches. When you build the staging table, it is outside of the partitioned table. Thus, you have no availability hit while loading the staging table, and then add indexes to the staging table. Lastly, the pointer switch is instantaneous. 2005 Staging Table

Csúszó időablak kezelés A legrégebbi adatok törlése 1 2 3 4 5 2002-01-01 2001 & korábbi [üres] 6 2003-01-01 2004-01-01 2005-01-01 2006-01-01 [üres] [üres] Partíció # 1 2 3 4 5 2002 & korábbi 2003 adatok 2004 adatok 2005 adatok 2006 & későbbi Getting rid of 2002 data. Remember that the 2001 data that was once in partition 1 is already emptied in keeping with the recommendation to keep a partition on either end EMPTY. Üres tábla létrehozása az eltávolítandó adatok számára Switch (alter table …) Merge (alter partition function …) 2002 Unload Table

Az adatbázis fizikai szerkezete 4/4/2017 2:24 PM Az adatbázis fizikai szerkezete Adatbázis Fájlcsoportok Fájlok Extent-ek Lapok Adatbázis Backup Primary Read write fájlcsoport File1 File2 2004 File3 Read only fájlcsoportok 4 8 12 16 20 24 28 2003 File4 File Header 1 5 9 13 17 21 25 29 … 2002 File5 2 6 10 14 18 22 26 30 2001 File6 3 7 11 15 19 23 27 31 extent 0 extent 1 extent 2 extent 3 Log © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Tárolás, mentés, helyreállítás A „régi” adatok partícióit tárolhatjuk „read-only” fájlcsoportokon RO fájlcsoport tömörített diszken/mappában is lehet A RO fájlcsoportot nem kell újra és újra menteni Gyorsabb adatbázis mentés A RO fájlcsoport bármikor helyreállítható – tranzakció napló mentés nélkül is A partícionált tábla on-line marad egy fájlcsoport elvesztése esetén is On-line visszatöltés lehetséges

További információ a partícionálásról Partitioned Tables and Indexes in SQL Server 2005 msdn2.microsoft.com/en-us/library/ms345146.aspx Strategies for Partitioning Relational Data Warehouses in Microsoft SQL Server www.microsoft.com/technet/prodtechnol/sql/2005/spdw.mspx Project REAL: Data Lifecycle – Partitioning www.microsoft.com/technet/prodtechnol/sql/2005/realpart.mspx

Adat(bázis) tömörítés RO fájlcsoportok kerülhetnek tömörített meghajtóra, ill. tömörített mappába Vardecimal adattípus (SP2) -- A várható megtakarítás becslése sp_estimated_rowsize_reduction_for_vardecimal 'table' -- Adatbázis szinten lekérdezés, engedélyezés, tiltás sp_db_vardecimal_storage_format 'SalesDB', 'ON' | 'OFF' -- Bekapcsolás tábla szinten sp_tableoption 'table', 'vardecimal storage format', 'true' -- Lekérdezés SELECT name, object_id, type_desc FROM sys.objects WHERE OBJECTPROPERTY(object_id, N'TableHasVarDecimalStorageFormat') = 1

Indexelt nézetek Feltételek Használat (automatikus) a nézetben szereplő táblákra SET opciók a session-re a nézet legyen determinisztikus create view ... WITH SCHEMABINDING create unique clustered index on ... view Használat (automatikus) Frissítés (automatikus) Database Engine Tuning Advisor select * from sys.indexes i join sys.objects o on i.object_id=o.object_id where o.type='V‘ -------------

Az indexelt nézetek korlátai Outer join nem lehet a nézetben Partícionált tábla SWITCH előtt a SCHEMABINDING miatt a nézetet el kell dobni Az első index kötelezően UNIQUE, CLUSTERED A használat nem mindig automatikus Például, ha egy lekérdezés nem hivatkozik a nézetben szereplő összes táblára Megoldás: NOEXPAND hint INDEXED VIEW CON’S: OUTER JOINS are not allowed. - Indexed views are schema-bound to their source tables. A SWITCH operation on a partitioned fact table thereby requires that any indexed views based on that table be dropped and recreated. Indexed views require a unique, clustered index as the first index. This may require the addition of columns into the index that don’t really need to be there. There are conditions that must exist in order for a query to automatically use an indexed view over the table specified in the query. This could require the creation of additional indexed views that are expensive to build and maintain (or that queries explicitly name the relevant indexed views combined with the NOEXPAND hint). One example of this is that all tables that are referenced in the indexed view must be referenced in the query. If the indexed view references Tbl_Fact_Store_Sales, Tbl_Dim_Store, Tbl_Dim_Date and Tbl_Dim_Item, but the query only references the first three tables, the optimizer will not consider using the indexed view to satisfy the query.

Automatikus indexelt nézet használat

Database Tuning Advisor

Adatváltozások észlelése Különbség képzés („except”) Az adatok átmozgatása a távoli kiszolgálóról - kis táblák esetén elfogadható Esetleg LogShipping, adatbázis tükrözés Időbélyeg a forrás sorokon A forrás adatbázis módosításával jár Trigger a forrás táblákon Lassíthatja a forrás adatbázis működését Tranzakcionális replikáció Testre szabott tárolt eljárásokkal: sp_MSins_< tábla >, sp_MSupd_< tábla >, sp_MSdel_< tábla> Minden változást rögzít – kérdés, kell-e?

Optimalizálás – HW CPU: X64, IA64 Diszk: SAN, sok „spindle” RAID10 (tempdb és adatbázis naplók) RAID5 – az adatok számára elfogadható

Optimalizálás - SQL Server Max degree of parallelism A fizikai processzorszám / 2 MAXDOP opció a lekérdezésekben Több tempdb adatfájl Fizikai processzorszám, ill. max. 10 www.microsoft.com/technet/prodtechnol/sql/2005/workingwithtempdb.mspx Azonnali fájl inicializálás „Perform volume maintenance tasks” jog az SQL Server fiókjának Read only adatbázis, vagy NOLOCK opció a lekérdezésekben 10-25% nyereség

Optimalizálás - SQL Server (2) Adatbázis opciók Tilos: autoclose, autoshrink Auto update statistics: aszinkron Recovery model: simple Ne deklaráljunk idegen kulcsokat A referenciális integritás a betöltő folyamat feladata Elsődleges kulcs, vagy egyedi index a dimenzió táblák mesterséges kulcsán A tény tábla indexei Mesterséges, identity oszlopra PK; nem fürtözött index a hivatkozásokra, vagy Összetett PK a hivatkozás oszlopokra sys.dm_db_index_usage_stats

Manuális lekérdezés optimalizálás Ha lehet, kerüljük Join előírás loop, hash, merge Tábla szintű előírások nolock, noexpand, index, … Lekérdezés opciók HASH GROUP,  FORCE ORDER,   MAXDOP OPTIMIZE FOR, KEEP PLAN, … USE PLAN N'xml_plan'

További információ SQL Server Best Practices www.microsoft.com/technet/prodtechnol/sql/bestpractice SQL Server 2005 Data Warehousing www.microsoft.com/sql/solutions/dw SQL Server 2005 – Operations www.microsoft.com/technet/prodtechnol/sql/2005/library/operations.mspx