Dansk it-firma hjælper Microsoft med at 100-doble I/O-hastighed i SQL Server 2012

Michael Frandsen fra det danske konsulentfirma Platon har foreslået Microsoft at flytte placeringen af systemdatabasen tempdb i SQL Server 2012. Resultaterne taler sit eget, lynhurtige sprog.

Han lærte Microsoft-databasen SQL Server at kende i 1993, hvor version 4.21 blev lanceret.

Nu giver han gode råd fra sidelinjen, mens Microsoft skruer og hamrer på den nye SQL Server 2012 op til frigivelsen i første halvdel af 2012.

Læs også: Microsoft SQL Server 2012 klar til download i Release Candidate

Som teknologidirektør i det danske konsulenthus Platon Infrastructure har Michael Frandsen i mere end 10 år været med til at teste og hoste blandt andet SQL Server og Windows Server, inden produkterne kommer på gaden.

Samarbejdet med Microsoft begyndte med SQL Server 2000 under ordningen Technology Adoption Program, TAP.

Det betyder, at Platon gennem kundeinstallationer hjælper Microsoft med at finde fejl og foreslå ny funktionalitet i produkterne.

Til gengæld tilbyder Microsoft sine nye produkter med fuld support til Platon's kunder, mens de endnu er på beta-stadiet. Noget for noget.

»TAP er for slutkunder, der gerne vil afprøve den næste generation af et produkt i produktion, før produktet bliver frigivet. Microsoft yder så support på beta'en mod at få noget feedback,« fortæller Michael Frandsen til Version2.

I den kommende Microsoft SQL Server 2012 står der Platon Infrastructure på en vigtig ændring, der giver ydelsen et solidt los i bagdelen i store databaseinstallationer.

SQL Servers systemdatabase, tempdb, har altid været tvunget til at ligge på miljøets fælles lagerområde, SAN (Storage Area Network.)

Men med SQL Server 2005 skete der en forandring. Den betød kort fortalt, at operationer, der tidligere kunne udføres direkte i ram - hurtigere bliver det ikke - nu skulle igennem tempdb placeret på SAN'et.

Dermed gik det pludselig meget langsommere, når for eksempel to tabeller skulle flettes sammen:

»Når SQL Server skulle lave et midlertidigt resultat - for eksempel join'e to tabeller - blev det nu gjort i tempdb i stedet for i ram. Derfor gik tempdb hurtigt hen og blev akilleshælen, for hvis tempdb kører langsomt, skal alt andet vente på den,« forklarer Michael Frandsen.

Michael Frandsen har derfor foreslået Microsoft, at tempdb kan placeres lokalt på de enkelte servere. Det er der ingen problemer i, da tempdb kun indeholder midlertidige data, som navnet også antyder.

»Tempdb bliver alligevel slettet, hver gang SQL Server startes. Derfor er det ikke så vigtigt, om den ligger ude på SAN'et eller ej,« siger Michael Frandsen.

Ved at placere tempdb lokalt på en lynhurtig SSD-disk fra storagefirmaet Fusion-io på den enkelte server-node kan der opnås I/O-hastigheder, der minder om gamle dage, hvor operationerne blev udført i ram.

Men de hurtige SSD-diske var ikke til megen nytte, hvis tempdb stadig var tvunget til at leve sit liv ude på SAN'et.

Derfor har muligheden for at flytte tempdb ind på SSD'en været på Platon's ønskeseddel siden 2007, og det bliver altså nu muligt i SQL Server 2012.

Det er en ændring, der kan mærkes, fortæller Michael Frandsen:

»Vi kan se en helt vanvittig performanceforskel i de kundeinstallationer, hvor der for eksempel join'es tabeller på kryds og tværs. Vi har set performance gå fra få tusinde og op til flere hundrede tusinde I/O-transaktioner i sekundet,« siger Michael Frandsen.

Kommentarer (20)

Michael Jensen

Hvorfor ikke flytte tempdb helt ind i RAM ?

Hvis det er ligegyldigt hvor den ligger (SAN vs. lokalt) kan den vel også ligge i RAM. Alternativt kan man vel bruge en RAM-disk i stedet for en SSD.

Kennie Nybo Pontoppidan

enten er der noget jeg har misset helt, eller også er der intet nyt under solen.

Ja, man kan godt flytte lokationen af tempdb

Ja, man bliver glad for et fusion IO kort til sin tempdb

Det har vel ikke noget med sqlserver 2012 at gøre.

Michael Frandsen, du må på banen og fortælle hvad det er I konkret har hjulpet Microsoft med, så al denne forvirring kan holde op

Jacob Christian Munch-Andersen

Iflg. EDBpriser kan man nu få 4 GB blokke til 125 kr stykket, dermed burde det ikke være noget problem at udstyre selv de mest skrabede servere med minimum 16 GB ram. Til en lang række formål er det rigeligt til at have hele databasen i ram og kun skrive til disken for at undgå datatab.

Så hvorfor bliver databaserne ved med at være så utroligt diskafhængige?

Kennie Nybo Pontoppidan

@Jacob Christian Munch-Andersen:
hvis du har en lille database, så vil den såmænd også blive cachet i buffercachen efterhånden som du læser blokke/pages op fra disk. Og databasen vil skrive beskidte blokke/pages til disk når den føler at det er nødvendigt.

Men vi er altså mange, der arbejder med noget større datamængder end hvad der kan ligge i memory. Så dit argument holder måske nok for en database for en lille webshop/cms, men ikke for et bare middelstort data warehouse

Mark S. Rasmussen

Det eneste jeg kan forestille mig dette reelt set handler om, og som artiklen fint springer over, er SQL Server 2012 Failover Clustering. Der har aldrig været krav om at tempdb skulle ligge på et SAN, på nær...

Indtil SQL Server 2012 har alle databaser, der var del af en cluster installation, været nødt til at være lagret på et SAN. Dette har også inkluderet tempdb, og det har korrekt nok været en bottleneck i nogle installationer. Det er dog ikke tilfældet at alle operationer nu pludselig skal ramme disken ifh.t. tidligere - det er stadig kun i forbindelse med versioning og queries hvor der foregår disk spills grundet manglende hukommelse (ikke nødvendigvis total hukommelse, men allokeret hukommelse til den enkelte query / SQLOS scheduler).

I SQL Server 2012, ved brug af clustering, kan man nu gemme tempdb på lokale diske og derved nøjes med kun at gemme de normale system & bruger databaser på SANet. Et eksempel på et connect item kan ses her (hvor MS nævner at det ikke vil være muligt i SQL Server 2008):
http://connect.microsoft.com/SQLServer/feedback/details/532759/support-l...

Det har helt sikkert været foreslået tidligere, og jeg skal ikke kunne sige hvornår/hvordan Michael Frandsen har foreslået det.

Når først vi har mulighed for at gemme tempdb på lokale diske, også i et cluster, så er FusionIO/ramdiske naturligvis bare et ekstra boost, men det er der for såvidt intet nyt i - det er blot et spørgsmål om at gemme sine DBs, tempdb som normale, på et hurtigt medie. Altså forekommer artiklen noget sensationalistisk da man blander en mindre ny feature i SQL Server 2012 med et hurtigt lagermedie og således får et voldsomt performance boost - men altså kun med sammenkoblingen af de to uafhængige "features".

Jacob Christian Munch-Andersen

hvis du har en lille database, så vil den såmænd også blive cachet i buffercachen efterhånden som du læser blokke/pages op fra disk. Og databasen vil skrive beskidte blokke/pages til disk når den føler at det er nødvendigt.

Jeg må blot konstatere at hvis det entydigt hang sådan sammen så burde historier såsom den på den ovenfor nævnte af Paul Nielsen ikke forekomme. Selve navnet tempdb mere end antyder at vi snakker om en datamængde der som udgangspunkt burde ligge i rammen, hvorfor eksisterer den ikke blot i virtuel memory og bliver paget efter behov? Hvis vores databaser virkede ordentlig ville det være totalt meningsløst at give dem et ramdrev, den praktiske erfaring er blot at den slags krumspring i visse tilfælde giver ganske god mening.

Jeg ved at godt at data warehouse folk har en grel foragt for alt hvad der ikke måles i TB, men virkeligheden er at de fleste databaser er backend for små websites eller lignende på computere hvor disken suverænt er den mest sandsynlige flaskehals. Cluster features er i disse tilfælde rimeligt ligegyldige, og det er da rart hvis databasen selv kan finde ud af at køre på disken hvis den bliver for stor til rammen, men ikke særligt optimalt hvis prisen for denne feature er at den fungerer dårligere i småstørrelse.

Selvfølgelig skal der også være databaser i warehouse klassen, det forekommer blot at alle databaseudviklere sigter efter det marked, kun nogle få af dem lykkes rigtig godt med det, og resten forsøger så (og har held med) at overbevise os andre om at deres middelmådige storskala database er den perfekte løsning til småskala behov.

Mark S. Rasmussen

Jeg ved at godt at data warehouse folk har en grel foragt for alt hvad der ikke måles i TB, men virkeligheden er at de fleste databaser er backend for små websites eller lignende på computere hvor disken suverænt er den mest sandsynlige flaskehals. Cluster features er i disse tilfælde rimeligt ligegyldige, og det er da rart hvis databasen selv kan finde ud af at køre på disken hvis den bliver for stor til rammen, men ikke særligt optimalt hvis prisen for denne feature er at den fungerer dårligere i småstørrelse.

Det er så sandelig heller ikke tilfældet at små databaser lider under tempdb arkitekturen. Jeg tror det vil gøre det hele nemmere at anskue ved lige at gennemgå SQL Servers IO arkitektur og tempdb formål lynhurtigt.

SQL Server læser altid data fra hukommelsen - aldrig fra disken. Data bliver læst, i hukommelsen, via en buffer manager. Buffer manageren står til gengæld for at læse data fra disken, såfremt det ikke allerede er i hukommelsen. Ligeledes skrives data altid til hukommelsen - via buffer manageren. Buffer manageren holder styr på hvor mange ændringer der er foretaget og vil som kombination af dette, samt en tidsfrit, foretage jævne checkpoints. Ved et checkpoint skrives alle ændrede data til selve datafilen. Udover checkpoints, så røres datafilerne ikke, pånær når data skal caches i hukommelsen. Lige filen derimod, den skrives der til hver gang en transkation committes.

Tempdb bruges bl.a. til versionering af data ifb.m. snapshot isolation og diverse interne operationer der benytter versionering, samt ved store sorteringer af data der ikke kan lagres i query hukommelsen direkte - et såkaldt query memory spill. Da dette kan kræve en arbitrær stor mængde data, så bliver vi nødt til at lagre dette i en reel database, og ikke bare hukommelsen - husk også at vi på 32 bit systemer ikke nødvendigvis har uendeligt stort paging område.

Dvs. der lagres data i tempdb, på fuldstændig samme vis som normale databaser - det skrives til hukommelsen og bliver lazily spooled til disk ved et jævnt interval. Da dataene typisk har et kort liv, så vil dataområderne i hukommelsen typisk blive genbrugt, hvorfor footprintet på disk er relativt småt (relativt værende... relativt, afhængig af workload). Tempdbs log fil derimod, den vil der typisk være godt gang i, såfremt der er gang i tempdb. En transaktion kan sagtens blive committed til tempdb - hvorved der skrives til loggen, og herefter bliver dataene slettet igen - inden de overhovedet har rørt datafilen. Bottlenecken er således ikke nødvendigvis bare datafilen, men også logfilen, som nu engang er nødvendig for at leve op til D'et i ACID.

Summa summarum - tempdb'en eksisterer for at tillade arbitrært store queries på arbitrært store datamængder. Ved små databaser bruges tempdb også, men typisk vil dataene sjældent ramme datafilen, eller ihvertfald i ubetydeligt små datamængder. Log filen vil der derimod være brug for, men igen, typisk i så lille et omfang at det ikke mærkes ifh.t. brugen af de normale databaser.

Mark S. Rasmussen

Nej, det har du reelt set ikke - og mit argument omkring ACID compliance holder teknisk set heller ikke jvf. at tempdb cleares ved genstart af SQL Server. Dvs. tempdb er ACID compliant under selve kørslen af SQL Server, men er ikke durable imellem genstarter af SQL Server.

Det er vigtigt at huske på at tempdb er en fuld database ligesom alle andre - dvs. den understøtter locking, versioning, forskellige transaction isolation modes, osv. Flere af disse features kræver at man har en log for at kunne lave rollbacks af transaktioner der er gennemført på dataene in memory. Hvis en given transaktion aldrig vil være større end der er plads til i hukommelsen, så kunne den teoretisk set godt holdes 100% in memory. Igen skal vi dog huske på at grunden til vi typisk rammer disken er netop at vi skal tage højde for arbitrært store datamængder.

Således kunne vi teoretisk godt undgå tempdb på disken ved små queries/databaser, men det er så også tilfældet hvor vi generelt overhovedet ikke mærker tempdb ifh.t. andet arbejde. Ved store queries kan vi ikke undgå at ramme disken, da der simpelthen ikke er nok hukommelse til at garantere alt vores arbejde kan være deri (husk også at mere hukommelse til memory baseret tempdb log = mindre hukommelse til data = flere disk læsninger).

Jacob Christian Munch-Andersen

Flere af disse features kræver at man har en log for at kunne lave rollbacks af transaktioner der er gennemført på dataene in memory.

Fair nok, men der burde vel ikke være noget i vejen for at den log også kunne ligge i memory? Så længe vi altså går ud fra at tempdb + log ikke bliver for stor til rammen.

Jeg må i øvrigt stille mig noget tvivlende overfor den generelle nødvendighed af queries som forårsager meget store mængder data i tempdb. Man kan jo sagtens trawle igennem en stor tabel og lede efter en betingelse som der ikke er indekseret for uden behov for at oprette midlertidige tabeller, det tager tid, men det behøver ikke at tage ekstra lagerplads. Det går først galt hvis vi foretager et tabelkryds af tilstrækkeligt store tabeller som der ikke er indekseret tilstrækkeligt for, i det tilfælde bør enhver programmør overveje ret kraftigt om det er den rigtige løsning til opgaven.

Mark S. Rasmussen

Fair nok, men der burde vel ikke være noget i vejen for at den log også kunne ligge i memory? Så længe vi altså går ud fra at tempdb + log ikke bliver for stor til rammen.

Korrekt, det kunne godt lade sig gøre. Det vil dog være en væsentlig udvidelse af arkitekturen at skulle understøtte to forskellige log modes. Kigger vi på de to scenarier så er de igen at når der ikke er det store brug for tempdb/loggen, så vinder vi ikke noget ved kun at persistere den i memory, hvorimod ved stor brug, der har vi behovet for at persistere den på disk. Altså risikerer vi blot at tilføje en masse arkitektur uden reelt set at vinde noget ved det.

Jeg må i øvrigt stille mig noget tvivlende overfor den generelle nødvendighed af queries som forårsager meget store mængder data i tempdb. Man kan jo sagtens trawle igennem en stor tabel og lede efter en betingelse som der ikke er indekseret for uden behov for at oprette midlertidige tabeller, det tager tid, men det behøver ikke at tage ekstra lagerplads. Det går først galt hvis vi foretager et tabelkryds af tilstrækkeligt store tabeller som der ikke er indekseret tilstrækkeligt for, i det tilfælde bør enhver programmør overveje ret kraftigt om det er den rigtige løsning til opgaven.

Korrekt, simple queries med prædikater på ikke indekserede kolonner kræver ikke brug af tempdb, så længe vi ikke kører med snapshot isolation. Der er dog mange queries der henter store mængder data og foretager sorts der ikke følge en clustered key, og således skal sorteres in memory - disse vil typisk spilde til tempdb såfremt de er store nok.

Du vil også risikere at bruge tempdb ved hash matches, group by og generelt aggregation funktioner som kører over store mængder data - hvilket absolut ikke er en uvant situation for et RDBMS.

Joins på større mængder data vil også, korrekt nok, potentielt set spilde til tempdb. Her kan man naturligvis overveje om man kan denormalisere sine data, men faktum er at mange databaser er stærkt denormaliserede - hvilket generelt er en god tommelfingerregel at følge, ihvertfald til tredje grad.

SQL Server bruges også ofte med SSAS og SSRS ovenpå og disse vil også trawle igennem store mængder data for at opsamle og rapportere på det aggregerede data, så igen her risikerer du tempdb brug.

Om det er den rigtige løsning til opgaven, tjah. Hvis du vil ud i NoSQL vs RDBMS så er det ikke denne diskussion det skal foregå i, for det kræver en hel anden kontekst. Kan man undgå queries der spilder til tempdb? Ja, bare sørg for du ikke har så meget data. Eller accepter at tempdb findes og at du i 99% af installationerne rundt omkring aldrig lægger mærke til den.

Thorbjørn Andersen

Generelt har jeg svært ved at forstå, at 'vi' udviklere altid skal bruge MS til alt. Visual studios compiler er mega langsom og overgås af alle andre - bl.a. er gcc både bedre mht kvalitet og især hastighed.

Skifter vi til subjekt med databaser er "SQL Server" nu der, hvor jeg vil medgive at det er en (rigtig) database. Tilgengæld havde den jo popularitet lang tid før, hvor den nærmest var håbløs - og blot båret frem af navnet MS.

Den har altid været bagefter Oracle (og sandsynligvis også DB2, Postgres og flere andre). Jeg erkender, at det er let at tage en database og flytte den / tage backup eller andet - men snakker vi performance og især programmeringsmuligheder har SQL i lang tid ligget langt bagefter - og jeg antager at den stadig er bagefter. Nu må I korrigere mig, hvis jeg tager fejl performance. (PL/SQL-pakker lader dog til at være ubetinget bedre end T-sql)

Kennie: Men vi er altså mange, der arbejder med noget større datamængder end hvad der kan ligge i memory. Så dit argument holder måske nok for en database for en lille webshop/cms, men ikke for et bare middelstort data warehouse

Her vil jeg da mene at tempdb burde kunne flyttes til rammen. Rammen er billig - og nogle servere kan tage temmelig meget ram - og såfremt dette stadig ikke skulle være nok forstår jeg slet ikke valget af SQL Server fremfor en moden database.

(Men tillykke til Platon for at få MS til at lytte og fixe et problem ...)

Mark S. Rasmussen

Jeg bider på...

Generelt har jeg svært ved at forstå, at 'vi' udviklere altid skal bruge MS til alt. Visutal studio er en langsom compiler, der overgås af gcc både mht kvalitet og især hastighed.

Hvorfor blande VS ind i det her? VS har ligeså meget med en compiler at gøre som notepad har det. VS er et IDE som understøtter en stor mængde sprog, som hver især har deres egen compiler. Der er intet i vejen for at du kan skrive C++ i VS og benytte gcc som compiler. Vurderer vi VS som et IDE, så skal du søge langt for at finde et ligeså godt og velintegreret (ihvertfald med de natively understøttede sprog) IDE som VS.

Herudover så er der ingen der siger vi skal bruge MS til alt - the right tool for the job vil altid trumfe. At nogle ikke formår at se udover MS's tilbud, det er super ærgeligt, både for dem og deres arbejdsgivere. Betyder det så til gengæld at et MS produkt aldrig er the right tool? Bestemt ikke.

Skifter vi til subjekt med databaser er "SQL Server" nu der, hvor jeg vil medgive at det er en (rigtig) database. Tilgengæld havde den jo popularitet lang tid før, hvor den nærmest var håbløs - og blot båret frem af navnet MS.

Siden SQL Server 2005 har SQL Server været en seriøs contender, indtil da vil jeg gerne give at den har været voldsomt bagude.

Den har altid været bagefter Oracle (og sandsynligvis også DB2, Postgres og flere andre). Jeg erkender, at det er let at tage en database og flytte den / tage backup eller andet - men snakker vi performance og især programmeringsmuligheder har SQL i lang tid ligget langt bagefter - og jeg antager at den stadig er bagefter. Nu må I korrigere mig, hvis jeg tager fejl performance. (PL/SQL-pakker lader dog til at være ubetinget bedre end T-sql)

Ifh.t. Orcale der er SQL Server stadig bagude rent programmability mæssigt, alt efter hvilken vinkel du kigger på. SQL Server haler dog hastighed ind.

Hvad der dog er meget mere interessant når vi snakker RDBMS'er, data warehouses, osv., det er selve storage engine ydelsen. Den ligger til grunds for alle dataene, og hvadend udviklingsværktøjer du vil lægge ovenpå, så skal du igennem storage enginen. Hér er SQL Server rigtig godt med, og du vil finde at en velkonfigureret SQL Server står side om side med en velkonfigureret Oracle database. Begge systemer har områder hvor de brillierer, samt områder hvor de halter, som det nu engang typisk foregår.

Her vil jeg da mene at tempdb burde kunne flyttes til rammen. Rammen er billig - og nogle servere kan tage temmelig meget ram - og såfremt dette stadig ikke skulle være nok forstår jeg slet ikke valget af mere moden database end SQL Server.

Det gælder altid om at undgå skyklapperne når vi kigger på at løse et performance problem. Forestil dig vi flytter hele tempdb ind i hukommelsen, samt sørger for at der altid vil være nok hukommelsen tilgængelig. I så fald vil vi unægteligt blive nødt til at reservere noget hukommelse til netop det formål - hukommelse som ellers kunne være brugt til buffer cache, plan cache, osv. For at kunne vurdere hvad der bedst kan svare sig, så bliver vi nødt til at måle gevinsten ved at lægge tempdb i hukommelsen, med tabet i at skulle ramme disken oftere ved tilgang til brugerdata. Som nævnt tidligere så er tempdb sjældent din første bottleneck og det vil således være mindre klogt at kaste sandsækkene over bord udelukkende for at sikre tempdb performance.

Michael Frandsen

Så må jeg vist hellere selv komme med lidt input.

Microsoft vs andre på både RDBMS, compilere etc. det vil jeg høfligt holde mig ude af at diskutere.

Men SQL Server det kan vi snakke om.

I har alle lidt ret.

Flytte TempDB til DAS:
Det er korrekt hvad Mark S. Rasmussen antager, nemlig at det gælder i den situation hvor SQL Server kører i et Windows cluster setup.
Her har der altid været et krav om at alle de diske SQL Server servicen er afhængig af, skulle være shared storage alle cluster noder kan se.
Jeg havde en del store virksomheder der kørte SQL Server 2005 ca. 2 år før den blev frigivet. De erfaringer inklusive et års drift af RTM udgaven, gav os store problemer hos de kunder der kørte med SQL Server i et Windows cluster, fordi Microsoft med netop SQL Server 2005 lavede en meget stor omskrivning af hvordan relational engine virkede.
Jeg skrev så en spec., på hvordan vi kom ud over de problemer, i 2007 og har været igennem nogle kunde cases med produktgruppen. Forslag på connect som en referer til gav kun ekstra skyts - så altid stem på features på connect.microsoft.com - men med Microsofts opkøb af Data Allegro i Californien, det der er blevet til SQL Server Parallel Data Warehouse (PDW), havde de store problemer med at portere fra linux og ingres til SQL Server, hvor det også i deres scenarie viste sig at være SQL Servers meget store afhængighed af TempDB der var flaskehalsen.
Så det blev derfor indarbejdet i kodebasen på SQL Server 2008 R2, at afhængigheden til at TempDB skulle ligge på shared storage forsvandt. Dette blev så back-portet til SQL Server 2008 kodebasen, som PDW er baseret på, men ikke i den kommercielt tilgængelige version af SQL Server 2008 - så rent faktisk kan man få SQL Server 2008 R2 til at placere TempDB på en DAS disk, selvom instancen kører Windows cluster, det er dog ikke officielt tilgæneligt hvordan man gør og det er bestemt 100% usupporteret fra Microsofts side - så hvis nogen finder ud af hvordan, så lad være, vil være min anbefaling.
På Denali har Microsoft haft ordentlig tid til at regressions teste den del af kodebasen, så det nu er en officiel feature.

TempDB i RAM:
Hvor ikke blot køre TempDB i RAM? Tjo, det forunderlige er jo at det har man tidligere kunnet. For de af jer der har været med længe på SQL Server - jeg startede selv med version 4.21a der var den første Microsoft frigav i 1993 på Windows NT 3.1 (før det kørte SQL Server kun på OS/2) og har været med på alle versioner lige siden.
Dengang var der en feature, hvor man kunne pin'e TempDB i RAM (det samme galt specifikke tabeller med DBCC PINTABLE).
Jeg har været ved at grave i de små grå for hvornår det at pin'e TempDB i RAM forsvandt, men mener det var omkring SQL Server 2000, det var i hvertfald væk i SQL Server 2005, hvor også DBCC PINTABLE holdt op med at virke - man kunne stadig skrive koden og man fik en success tilbage, men der skete ikke noget.
Hvorfor fjernede Microsoft sådan en feature? Husk på, SQL Server 2005 var på tegnebrættet omkring 2000-2001, der havde vi kun lige fået Itanium med ægte 64-bit, så RAM var en begrænset ressource. Når så brugere af SQL Server begynder at pin'e både TempDB og måske også en elelr flere tabeller fra bruger databaser, så bliver buffer pool'en lige pludseligt ret presset for ressourcer, til alt det andet den skal lave - nemlig hovedsagligt at gemmme pages i RAM fra bruger databaser.
Så da det der ligger i TempDB i sagens natur er temporært, så er det ikke så interessant i et RAM udfordret system at spilde buffer pool plads på den slags.
Derfor lavede de en kæmpe omskrivning af hele buffer pool'en med 2005 releasen, så den blev baseret på en slags LRU algoritme, der med nogle meget sofistikerede algoritmer sørger for at holde de "rigtige" pages i buffer pool'en. Derfor er aktivitet i TempDB ikke helt det samme som en normal bruger database, hvor SQL Servers WAL protocol kræver at log writes er committed til stable storage (ex. batteri backed up cache på en RAID controller), før en latch eller transaktion bliver comitted til en klient, for så at lade lazy writeren skrive de pågældende pages til data filen/filerne ved lejlighed, under idle tid. Tænk på TempDB's datafiler mere som transaktionsloggen i bruger databaser, da buffer pool manageren ikke er interesserert i at have ting liggende fra TempDB, hvilket kun vil sænke page life expectancy for de pages der rent faktisk skal bruges igen.
Men tilbage til TempDB i RAM. I dag har alle x64 servere der med 40-44 bit RAM adressering kan klare noget mere hukommelse end 4GB og samtidig er RAM blevet en meget billig ressource at tilføre en server.
Burde Microsoft omskrive buffer pool'en igen, sandsynligvis, men måske ikke lige på dette område.
Jeg er lige vendt hjem fra en tur hvor jeg havde møde med en fra produktgruppen, hvor vi diskuterede om ikke man skulle tænke på NAND flash som memory og ikke storage, eg CPU'erne har level 1, 2 og 3 cache - så skulle main memory være level 4 og NAND flash implementering som Fusion-io ses som level 5 cache, for så først at kalde noget storage når man rammer noget med et legacy SAS interface (uanset om det er en SSD eller et roterende medie).
Vi er der i dag at med de nyeste generationer af NAND implementeringer, ex. ioDrive2 Duo, så er det Windows kernel med DPC der er begrænsingen og så er STORPORT en meget kompleks stack at komme igennem.
Det ville jeg personligt hellere have at Microsoft fik på plads, end at pille ved om TempDB igen kan pin'es til RAM.

Håber dette gav mening.

Mark S. Rasmussen

Interessant at høre din egen melding om historien, Michael!

Mht. PINTABLE som en måde hvorpå vi kan gemmer tempdb i ram, så er jeg ikke helt enig. Som du nævner så var PINTABLE en generel feature i SQL Server til at tvinge en tabels pages til at forblive i hukommelsen - dvs. ikke nødvendigvis at blive læst ind i hukommelsen, men ihvertfald sørge for at de ikke forsvandt fra bufferen igen når først de var blevet læst ind. Dvs. en let måde at tvinge tabellen i hukommelsen på ville være at pinne den og tvinge et scan igennem af alle indexes efterfølgende.

PINTABLE ændrer dog ikke på SQL Servers mønster mht. writes og checkpoints - dvs. alle page ændringer blev fortsat foretaget 100% i hukommelsen - fuldstændig som normale tabeller. Ligeledes blev ændrede pages også flushed til disken ved faste intervaller, også for tempdb tabeller der er pinned. Det eneste PINTABLE således sikrer er at en tabels pages aldrig bliver fjernet fra hukommelsen - hvilket kunne være brugbart til f.eks. statiske fact tabeller. I tempdbs tilfælde er dataene dog i sagens natur meget temporære og vi vinder således relativt lidt ved at pinne dem i hukommelsen.

Tempdb bruger i forvejen loggen væsentligt mindre end normale tabeller grundet de fleste operationer er minimally logged, men vi slipper stadig ikke for at skrive til loggen ved afslutning af visse transaktioner, uanset om tabellerne er pinned eller ej. Ligeledes slipper vi heller ikke for at flushe ændrede data pages ved checkpoints, om de er pinned eller ej. Men da tempdb sjældent gemmer længerevarende data, så vinder vi relativt lidt ved at pinne dem, givet at vi ikke slipper for lazy writeren.

Michael Frandsen

Jeg fik vist ikke forklaret mig tydeligt nok, det beklager jeg.

Jeg snakkede om to fuldstændigt uafhængige features, nemlig en hardcoded feature til at beholde TempDB i ram og en helt anden feature, med at pin'e en bruger tabel.
grunden til at jeg fremhævede begge, var at de begge er blevet fjernet, da brugen af dem i starten af dette årtusinde var et problem på en 32-bit server, da de kraftigt reducerede buffer pool managerens råderum over tilgængelig allokeret RAM.

Den første feature med at holde TempDB i RAM, var noget de tidlige udgaver af SQL Server kunne, via en property på TempDB. Den feature forsvandt omkring SQL Server 2000, kan dog ikke helt huske hvornår, men den var helt sikkert væk i 2005. Samtidigt pinnede man ikke tabeller i TempDB til RAM, da hele TempDB netop lå i RAM.
Men hvis man har langsomme skrivninger og ledig RAM, vandt man meget ved at lade TempDB blive i RAM, hvilket vi så i de sidste ca. 4 år har kommet om ved med Fusion-io kort på non-clusterede instancer og altså nu med 2012 også med clusterede instancer, hvilket de fleste SQL Server installationer med mange IOPS som regel er.

Den anden feature med at kunne pin'e en bruger tabel i buffer pool'en ved hjælp af DBCC PINTABLE forsvandt i SQL Server 2005, man kan stadig skrive kommandoen og få en success tilbage, men den bliver ignoreret af DBCC kommandoen internt.

Så altså to vidt forskellige funktioner, men som begge reducerede råderummet over pages i buffer pool'en.

Jeg har ikke skrevet at PINTABLE ændrer på opførslen af hvornår ting bliver skrevet til disk, for det gør den ikke.

Jeg har heller ikke sagt at TempDB ikke bruger dens log, for det gør den, men jeg har sagt at grundet de avancerede LRU algoritmer i buffer pool'en, så bliver datafilerne i TempDB brugt næsten som en log, altså tæt på direkte til disk med det samme, for ikke at forurene buffer pool'en med ting der ikke skal bruges igen.

Ps. det er ikke nødvendigt at scanne alle indexes igennem for at læse en tabel i RAM, blot lav en SELECT COUNT(*) på tabellen med et index hint til at bruge enten index 0 (hvis tabellen er et heap) eller index 1.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

Digital kommunikation - klar tale på digitale kanaler

Hvornår: 2015-12-08 Hvor: Østjylland Pris: kr. 4990.00

Vanskelige samtaler

Hvornår: 2015-11-30 Hvor: Storkøbenhavn Pris: kr. 11400.00

Forvaltningsret

Hvornår: 2015-08-31 Hvor: Vestjylland Pris: kr. 8100.00

C# kursus grundlæggende

Hvornår: 2015-08-31 Hvor: Storkøbenhavn Pris: kr. 10200.00

Developing Windows Azure and Web Services [20487]

Hvornår: 2015-10-20 Hvor: Østjylland Pris: kr. 19500.00