Database "opbygning" Dette områder falder mest under en DBA's ansvarsområde. Det kan sagtens tænkes at en database udvikler i nogle situationer vil blive nød til at oprette produktions og test) databaser, og derfor vil det være områder en udvikler kan komme i berøring med. De følgende paragrafer er mest for at give et overblik da det hurtigt kan gå hen og blive et meget komplekst og abstrakt område for en udvikler. Disse oplysninger er også specifikke til SQL Server 2005 og 2008. Jeg vil dog antage at andre relationelle database systemer har tilsvarende mekanismer og opbygning. Filer data) SQL Server består af flere filer. Der vil altid være mindst en datafil og en transaktionslog fil, men flere kan eksisterer. Datafiler er som navnet indikerer det sted hvor en databases data persisteres. Disse består af 1 primær datafil normalt.mdf) og nul til flere sekundære database filer normalt.ndf). Den primære datafil's opgave er blandt andet at kontrollere og administrere de sekundære filer ud over opbevaring af data. Sekundære datafiler benyttes kun til opbevaring af data. Der ud over findes mindst en log fil, hvilket jeg kommer ind på senere. Hvorfor så benytte multiple filer? Der er en række årsager til hvorfor der kan bør) benyttes flere data filer end blot den ene som oprettes som standard. En årsag er med hensyn til backup administration. Fordi man kan backup/restore på fil niveau giver det en fordel med store databaser at man kan nøjes med at arbejde med en fil frem for hele databasen. Samt kan man gøre sine data filer mindre så der hurtigere og nemmere kan køres en backup/restore. Så frem for at have en 20GB data fil, kan man have 4 på 5 GB der gør det nemmere at tage den backup og hurtigere at restore den igen. Der er ikke nogen performance fordel i flere filer på samme drev, ud over de fordele det kan give ved backup/restore. En anden årsag er at man ønsker sin database spredt ud over flere fysiske drev. Dette kan have performance fordele, fordi data der ofte bruges kan deles ud over flere diske og grupperes med data der bruges mindre. Fil håndtering Vurderinger der også kommer ind i overvejelserne når man arbejder med flere filer, er størrelsen på filer, må filerne vokse og hvis ja, hvor meget. Store filer der vokser med en fast procent sats kan give performance problemer mens den vokser.
Eksempelvis en 10 GB fil der har tilladelse til at vokse med 10% vil så vokse med 1 GB når der er brug for det hvilket kunne være ved indsættelse af en ny række. Er der plads på drevet? Gør det noget at SQL Server brugere tid og ressourcer på det? Rammer det ind i noget kritisk kørelse. Tilsvarende kan en fil sættes til at "mindskes" auto shrink). Og igen er de fleste af de samme overvejelser relevante fordi det kræver ressourcer. Hver fil vil også benytte sin egen tråd i SQL Server, så derfor er dette også en ressource man bør overveje da det betyder øget hukommelsesforbrug. Som eksempel har jeg her oprettet en database med 2 filer: CREATE DATABASE [ASH_TestFilePlacement] ON PRIMARY NAME = N'ASH_TestFilePlacement', FILENAME = N'D:\Databaser\MSSQL10.MSSQLSERVER\MSSQL\DATA\ASH_TestFilePlacement.mdf', ), NAME = N'ASH_TestFileSeconday', FILENAME = N'C:\ASH_Test\ASH_TestFileSeconday.ndf', ) LOG ON NAME = N'ASH_TestFilePlacement_log', FILENAME = N'D:\Databaser\MSSQL10.MSSQLSERVER\MSSQL\DATA\ASH_TestFilePlacement_log.ldf ', SIZE = 1024KB, MAXSIZE = 2048GB, FILEGROWTH = 10% ) GO Efter at have indsat 750.000 rækker i en table bestående af ID/Value så er filerne sådan her: Til sammenligning, hvis jeg kun havde en data fil:
Filgrupper data) En database vil derudover bestå af 1 eller flere filgrupper, der er en logisk gruppering af de individuelle datafiler i strukturer. En filgruppe vil altid være den primære filgruppe som benyttes som default, med mindre andet specificeres på fil niveau. Hvorfor benytte filgrupper. En af de primære grunde til man benytter filgrupper er at det gøre det nemmere at administrere hvis man ønsker at dele sin database ud over flere fysiske medier. Så kan man tilknytte sine datafiler til disse forskellige fil grupper. En fordel er at man herved også kan bestemme hvilke tabeller ligger i hvilke filgrupper, og dermed selv har kontrol over dele af I/O processen. Eksempelvis hvis man har 2 tabeller der bruges meget og 2 der bruges lidt mindre, så kan der være en fordel i at dele I/O ud således der er en tabel der bruges meget på to forskellige diske. En tommelfinger regel som jeg sjældent selv benytter er at efter databasen er oprettet, så lave en sekundær datafil og sæt den som default. Så vil alle data og data strukturer gemmes i den fil mens den primære fil kun vil skulle håndterer databasens struktur. Eksempelvis CREATE DATABASE [ASH_TestFilegroup] ON PRIMARY NAME = N'ASH_TestFilegroup', FILENAME = N'D:\Databaser\MSSQL10.MSSQLSERVER\MSSQL\DATA\ASH_TestFilegroup.mdf', ), FILEGROUP [Secondary] DEFAULT NAME = N'SecondaryFile', FILENAME = N'C:\ASH_Test\SecondaryFile.ndf', ), FILEGROUP [Tertiary] NAME = N'ThirdFile', FILENAME = N'C:\ASH_Test\ThirdFile.ndf', ) LOG ON NAME = N'ASH_TestFilegroup_log', FILENAME = N'D:\Databaser\MSSQL10.MSSQLSERVER\MSSQL\DATA\ASH_TestFilegroup_log.ldf', SIZE = 1024KB, MAXSIZE = 2048GB, FILEGROWTH = 10% ) GO
Jeg har markeret Secondary filgruppen som default, så hvis jeg ikke specificerer andet, så vil alle data blive oprettet i denne filgruppe benyttende de underliggende filer. Men nu kan jeg specificerer hvilket drev og filgruppe de forskellige tabeller bliver placeret i og derved selv påvirke I/O performance. CREATE TABLE TABLE1 ID INT, VALUE NVARCHARMAX)) ON Secondary CREATE TABLE TABLE2 ID INT, VALUE NVARCHARMAX)) ON Tertiary Transaktions log Transaktions loggen normalt.ldf) er den struktur hvor SQL Server gemme ændringer foretaget i data som navnet indikerer via transaktioner. Her menes ikke kun transaktioner som "BEGIN TRANSACTION" men kørsler der modificerer data insert/delete/update). Transaktion loggen skrives til løbende for at SQL Server kan garanterer data konsistens og gør at selv de fleste ændringer til data i memory kan genskabes ved nedbrud. Essentielt set vil der blive skrevet til transaktions loggen før en "commit" er blevet sendt til klient processen for at kunne garanterer denne konsistens. En feature der er forvirrende for mange med hensyn til transaktions loggen er at den ikke automatisk gøres mindre når der tages backup, hvilket gør at den vokser voldsomt i pladsbrug hvis der er mange data modificeringer. Eksempler fra min egen verden er at jeg har set databaser på ~200 300 MB have 5GB og større transaktions log filer. Dette er normalt noget man bør håndterer i sin backup strategi, hvilket igen gør at vi falder ind i DBA området. Backup/restore er et meget stort område med mange overvejelser. Det er også transaktions loggen der gør differentiel backup /restore mulig mellem fulde backup, fordi man der kun tager backup af dataændringer. Fordi der skrives kontinuerligt og ofte til transaktions loggen, så er disk I/O en overvejelse hvis performance er et højt krav. Der er ingen grund til den ligges på samme drev som data filerne således disse skal konkurrerer over I/O tid. Og som ved data filer vil transaktions loggen også kunne vokse, og igen fordi der skrives ofte til denne fil, så kan det give problemer hvis en 5GB log fil skal vokse med 10% fordi det kan betyde at andre transaktioner må venter og eventuelt time ud. Derfor hvis man arbejder på fil niveau med en database, så bør der være noget omtanke bag håndteringen af transaktions loggen. Og hvis man står for backup/restore er det vigtigt at huske størrelses problemet med loggen. Pages På "nederste" niveau er databasen inddelt i "pages" som er enheder på 8KB stykket. Det er disse der er komponenterne internt i filerne. Der findes mange typer af index pages, data pages, hvilke pages er allokeret, oplysninger om fri plads, hvilke pages er ændret og meget andet.
Det er områder som er dybt inde i database opbygningen og meget komplekse, og jeg vil henvise til litteratur hvis man er interesseret Eks. Inside Microsoft SQL Server 2005: The Storage Engine). En ting der dog er nyttigt viden omkring pages er at man sågar kan backup/restore på page niveau. Det er dog sjældent en brugt feature med mindre ens database er meget stor der gør fil backup/restore problematisk enten pga oppetid eller størrelse. Litterateur for dem der er interesseret blandt andet): Inside Microsoft SQL Server 2005: The Storage Engine Microsoft SQL Server 2005 Administrator's Companion http://msdn.microsoft.com/en us/library/ms179316.aspx Files and Filegroups Architecture) http://msdn.microsoft.com/en us/library/ms179355.aspx Transaction Log Physical Architecture)