Sql a kérdésekben és a válaszokban - migráció, teljesítmény-tuning, backup és
Paul S. Randal
Új lemeztáblába költözött
Először tegye az adatbázist offline üzemmódba az alábbi parancs segítségével. Ha a felhasználók csatlakoznak az adatbázishoz, először vissza kell állítania kapcsolataikat:
Rövid távú oldalzárak
K: Nem tudok kitalálni néhány dolgot a teljesítmény hangolásáról. Többször olvastam, hogy kerülni kell az "oldalak rövid távú blokkolását". Nem értem, hogy mi az "oldal" vagy a "blokkolás", vagy miért lehet rövid távú oldalzáró probléma. Meg tudná magyarázni mindezt részletesebben?
Válasz: Az SQL Server adatbázis összes adata adatfájlokba kerül. Ezeknek a fájloknak a belső struktúrája olyan, hogy 8 KB hosszúságú tömbökből álló sorozatok formájában szerveződnek. Page - az SQL Server felügyeleti rendszer fő tároló és I / O egysége. Az oldalakat rendszerint a lemezen lévő adatfájlok tárolják, és a kérelem feldolgozása előtt az SQL Servernek le kell olvasnia és el kell osztania a megfelelő oldalakat a gyorsítótárban (más néven puffertartományként is).
Az SQL Server különféle típusú oldalakat használ különböző relációs adatok tárolására (például táblázat sorok, nem klaszteres indexsorok, szöveges vagy LOB-adatok). Vannak olyan oldalak is, amelyek tárolják az SQL Server által igényelt belső adatstruktúrák részét a relációs adattárolási oldalak szervezéséhez és eléréséhez.
A rövid távú zár (retesz) egy könnyű belső mechanizmus, amelyet az SQL Server használ a szinkronizáláshoz a gyorsítótárban lévő oldalhoz való hozzáféréshez. Kétféle rövid távú zárat kell ellenőrizni: a normál reteszelést és az I / O blokkolást. Ha az SQL Server szálnak meg kell várnia, hogy az egyik zárolás beérkezzen, ez negatív hatást gyakorol a teljesítményre.
Amikor az SQL Server vár az adatfájl egy részéről a lemezről történő olvasásra, az oldal I / O blokkolása hozható létre. Ha az ilyen zárak túl sok időt vesz igénybe, akkor általában a lemez alrendszer teljesítményével (vagyis annak túlterhelésével) kapcsolatos problémákat jelez.
Ha több SQL Server szálat próbál meg elérni a memóriában tárolt adatfájl egy oldalához egy versenykörnyezetben, ez a hozzáférés az oldalzárolás várakozásához vezethet. Leggyakrabban ez akkor fordul elő, amikor intenzív kis ideiglenes objektumokat használnak a tempdb adatbázisban.
Az oldal rövid távú letiltásának problémájának megfigyelésére és megoldására vonatkozó részletes leírás túlmutat ezen a rovaton, és részletesebb információért kérjük, olvassa el az alábbi forrásokat:
Adatbázis pillanatfelvételek áttelepítése
K: Most már felfedeztem az adatbázisok pillanatfelvételeit. Most úgy látom őket, mint egy alternatívát a teljes visszaállítás és a naplófájlok biztonsági mentése. Úgy tervezem, hogy pillanatok alatt elkészítem egy pillanatképet, és ha valami rosszul sikerül, visszaállíthatom a sérült adatokat. Ez az adatvisszaadás sokkal kevésbé problémás és sokkal gyorsabb. Van valami baj ezzel a tervvel?
Az adatbázis pillanatfelvétele lehetővé teszi a véletlenül törölt adatok helyreállítását, ha az adatbázis még mindig rendelkezésre áll. Ha például az adatbázisból törölt táblázat még mindig a pillanatképben van, akkor visszaállíthatja a törölt táblát.
Azonban az ötlet, hogy túl sok pillanatfelvételt készítsen az adatbázisból (a tranzakciós napló biztonsági másolatának cseréjéig minden 1,5 óra), egyértelműen sikertelen az esetleges teljesítményproblémák miatt. Mielőtt megváltoztatná az adatbázis oldalon (a részleteket lásd. „A záró oldal retesz” fejezetben), szükség van a szinkron bemásolja az összes létező adatbázis pillanatképeket, amelyek verziójú oldalt még. Az adatbázis több képét, annál több oldalt kell másolni, és a teljesítmény csökken.
A másik ok, hogy nem készítünk túl sok pillanatfelvételt az adatbázisból, hogy mindegyikük tartalmazni fogja az adatbázis oldalak másolatait, mielőtt módosítja őket. Mindegyikük növekedni fog, ahogy az adatbázisban bekövetkezett változások száma nő. Ez problémákat okozhat a lemezterület és a teljesítmény terén.
Fényem, tükör.
K: Felkérést kaptam, hogy hozzon létre egy tükröt az adatbázisunkhoz, de attól tartok, hogy az adatbázis tükrözése nem oldja meg a problémát. Problémákkal szembesültünk a tárolóhálózaton (SAN) lévő adatokkal kapcsolatos korrupcióval kapcsolatban, ezért tervezzünk egy tükör adatbázist létrehozni a biztosításhoz. Nem minden torzulás automatikusan esik a tükörre? Hogyan segíthet az adatbázis-tükrözés megoldani ezt a problémát?
Válasz: Ez egy nagyon érdekes és bonyolult kérdés, sokan félreértést és zavart okoznak. Úgy tűnik, hogy az adatbázis redundáns másolatait létrehozó technológiákkal az adatok torzulása a fő adatbázisból a tükörbe kerül, de a valóságban ez nem történik meg.
A kulcs az, hogy megértsük, hogyan működik az adatbázis-tükör. Természetesen a torzítások a tükörhöz jutnak, ha a szinkronizáló motor teljesen átmásolja az adatbázis oldalt a fő adatbázisból a tükörbe. A fő adatbázisban torzított oldalak ebben az esetben a tükörre esnek.
Még ha az adatbázis oldalt is megsérti a fő adatbázis alapvető adatbázis- I / O alrendszere, a kár nem tud közvetlenül elérni a tükröt. A legrosszabb, ami történhet - az SQL Server nem tudja érzékelni sérült lapok (mivel a túllógó checksums) és a sérült az oszlop értéke fogják használni az érték kiszámítására vonatkozó adatbázisban tárolt. Ennek eredményeképpen a rossz eredmény az adatbázis tükrébe esik - ez az úgynevezett másodrendű kár. Mint mondtam, ha az oldal ellenőrzőösszegeinek ellenőrzése engedélyezett, akkor a torzítás észrevétlen marad az oldal lemezről történő olvasásakor, és a második sorrend nem torzul.
Ez a viselkedés azt is megmagyarázza, hogy a fő adatbázis integritás-ellenőrzése miért nem nyújt semmilyen információt a tükrözött adatbázis-állapot integritásáról és fordítva. Ezek két független adatbázisból állnak, amelyeket szinkron állapotban tartanak azáltal, hogy fizikai változásokat írnak le az adatbázisba, nem pedig a konkrét adatbázis-oldalakon.