Luulin kerran lukeneen jonnekin, että tempdb: hen kirjoittaminen on nopeampaa kuin varsinainen taulukko, jota ei ole tempdb: ssä. Onko tämä totta missään ominaisuudessa? Ajattelin, että muistan sanoneeni jotain erityistä tempdb: stä ja tietojen tallentamisesta muistiin?
Vastaa
tempdb: hen kirjoittaminen on nopeampaa kuin varsinainen taulukko, jota ei ole tempdb: ssä
Se on totta. TempDb: ssä on kaksi IO-parannusta.
Käyttäjätietokannan taulukkoon kirjoitettavien lokitietueiden on oltava huuhdeltuja levylle suorituksen yhteydessä, tai jos minimaalisesti kirjatun lisäosan (kuten SELECT … INTO) tietokannan sivujen on oltava huuhdeltu levylle Käyttäjätietokannassa minimaalinen kirjaaminen toimii siten, että tietokannan sivut kirjoitetaan suoraan levylle. Kun SELECT … INTO valmistuu, kaikki uudet sivut on kirjoitettu fyysisiin tiedostoihin.
TempDb-kirjoituksia ei tarvitse tyhjentää levylle suorituksessa, koska TempDb-tiedostoa ei koskaan palauteta vian jälkeen. Joten ne eivät yksinkertaisesti ole ”t”. Muutoksesi synnyttävät lokitietueita, mutta lokipuskuri huuhdellaan levylle vasta, kun se on täynnä, ei jokaisesta sitoutumisesta.
EG ajaa seuraava erä tempdb: ssä, täydellinen palautustietokanta ja yksinkertainen palautustietokanta nähdäksesi erot.
drop table if exists foo go declare @data bigint declare @log bigint select @log = sum(case when type_desc = "LOG" then num_of_bytes_written end) ,@data = sum(case when type_desc = "ROWS" then num_of_bytes_written end) from sys.database_files f cross apply sys.dm_io_virtual_file_stats(db_id(),f.file_id) fs select * into foo from sys.objects select -@log + sum(case when type_desc = "LOG" then num_of_bytes_written end) log_bytes ,-@data + sum(case when type_desc = "ROWS" then num_of_bytes_written end) data_bytes , (select recovery_model_desc from sys.databases where database_id = db_id()) recovery_model from sys.database_files f cross apply sys.dm_io_virtual_file_stats(db_id(),f.file_id) fs ja näet jotain tällaista:
Yksinkertaista palautusta varten:
log_bytes data_bytes recovery_model -------------------- -------------------- --------------- 24576 16384 SIMPLE täydelliseen palautukseen:
log_bytes data_bytes recovery_model -------------------- -------------------- --------------- 36864 0 FULL ja tempdb:
log_bytes data_bytes recovery_model -------------------- -------------------- --------------- 0 0 SIMPLE Joskus tempdb: n kohdalla näet lokipuskurin huuhdellun:
log_bytes data_bytes recovery_model -------------------- -------------------- --------------- 61440 0 SIMPLE Kommentit
- On tapauksia, joissa alkuperäinen lisäys on nopeampi, mutta se palaa kuitenkin puremaan sinua myöhemmin. Tämä esittely näyttää kyselyn, joka tuo tietoja puskurivälimuistiin, kestää paljon kauemmin, kun laiska kirjoittaja on kiireinen kirjoittamaan levytempdb-sivuille, jotka ovat likaisia sellaiselle tempitaulukolle, jota ei enää ole youtube .com / watch? v = X60ipwYv1Ms & feature = youtu.be
- Kyllä. Siellä ' on mahdollista tulevaa parannusta poistamaan puskurivaraston sivut, joita ei ole kohdistettu mihinkään objektiin. Suuren temp-taulukon lataaminen ajaa kuitenkin IO: ta joko suoraan tai epäsuorasti vähentämällä välimuistiin käytettävissä olevaa muistia.
Vastaa
Sen lisäksi, että kirjoitat tempdb: hen, ei usein kaikkia osuvia levy / verkko-IO: ta, kuten laajennetaan David Brownen vastauksessa , IO: sta riippuen kokoonpanossa saatat huomata, että vaikka tiedot ovat riittävän suuria, jotta ne on taitettava levylle, se on silti nopeampi kuin valinta ”normaaliin” taulukkoon:
-
TempDB voi olla eri asemia, joten sinulla on oma IO-kaistanleveys. Tämä on erityisen merkittävää pyörivien asemien sijaan SSD-asemien kanssa. Lukeminen ja kirjoittamalla samaan tietokantaan (tai toiseen tietokantaan samoilla asemilla) edellyttää enemmän pääliikkeitä, jotka lisää IO-viivettä ja saatat rajoittaa tehokasta IO-kaistanleveyttäsi. Tietojen kopioinnilla eri asemien / taulukoiden tietokantojen välillä ei ole sama ylimääräinen viive.
-
TempDB voi olla jopa fa steriä kuin päämuisti. Ehkä paikallisilla asemilla, joissa päämuisti on verkossa, tai NVMe SSD -asemilla, joissa päämyymälä on perinteisillä asemilla.
Molemmat näistä eroista voidaan nähdä myös saman sisällä tietokanta, jos käytät useita tiedostoryhmiä tietojen levittämiseen eri asemien / taulukkojen välillä.
Päinvastoin voi olla totta myös, jos sinulla on useita aktiivisesti käytössä olevia tietokantoja. Koska TempDB on jaettu resurssi, se ja sitä isännöivät asemat / verkko saattavat olla enemmän kuormitettuja kuin yksittäisen tietokannan datatiedostot.