Sql kérdések és válaszok a méret nem számít
Adatbázis méret, index töredezettség és a rendelkezésre állás után failover - ez az, ami számít az érdekelt adminoknak ebben a hónapban.
Paul S. Randal
Legyen óvatos, ne töredezettség
Kérdés: Olvastam néhány blogbejegyzések, amely a jelek szerint azt jelentette, hogy nem kellene vigyázni index töredezettség adatbázisokban tárolt szilárdtest (SSD) meghajtók, mivel sokkal gyorsabb, mint a hagyományos merevlemezek. Értem helyesen, hogy a teljesítmény csökkenés megállt, de ha tudnám, csak figyelmen kívül hagyja index töredezettség?
Függetlenül attól, hogy a válasz lemezek - hagyományos vagy szilárd állapotban, meg kell, hogy nagyon szorosan nyomon követi a töredezettség. Fragmentáció indexek két jelenséggel kapcsolatos - rendezetlen index oldalak és lapok sűrűsége problémákat. Az első jelenség csökkenti a hatékonyságot előreolvasó beolvasásakor oldaltartományokat, a második csökkenti az adatsűrűség.
Igaz, hogy a késedelem az SSD-meghajtók írni és olvasni, nagyon kicsi. Ennek megfelelően, szükség van több gyakori és kisebb I / O műveletek által okozott fragmentáció index, nem olyan erős hatást a teljesítményre, mint a hagyományos merevlemezek.
Csökkentése azonban adatsűrűség miatt az index töredezettség még lehet probléma. Index töredezettség jelentkezik elsősorban a műveletek, amelyek az úgynevezett „törés az oldalt.” Az a tény, hogy az új szabad hely az oldalon van kialakítva átadó fél az index sorban egy új oldalt. Ebben az esetben a régi és az új oldalak tele vannak körülbelül a fele. Abban az esetben, a nagy töredezettség az index nagyon gyakran előfordul, hogy az oldal átlagos sűrűsége 70% vagy kisebb (azaz az oldalon 30% szabad hely).
Ez azt jelenti, hogy ha van egy nagy számú indexek az adatbázisokat, drága SSD tárolni nagy mennyiségű üres tér, akkor egyértelmű, hogy ez a helyzet messze nem optimális. Továbbá, bár az extra I / O műveletek szükségesek az oldalak kis sűrűségű, nem jelentenek jelentős probléma az SSD-meghajtók, ők több helyet a puffer medence SQL Server (cache adatfájlok memória). Ez azt is jelenti, hogy az értékes szerver memória nem optimális.
Emellett az indexelő kódokat kell figyelembe venni az ok: az oldalon osztja. Ez drága művelet, hogy létrehoz egy csomó tranzakciók nyilvántartásait a lapban (az én következő blogjához elmondom, hogy mennyit ronthatja a helyzetet: blogbejegyzést Ezek a további naplóbejegyzések jelzik szükség további feldolgozásra, minden alkatrész, olvassa el a tranzakciós napló (például tranzakciós replikáció, archiválás, adatbázis tükrözés, naplótovábbítási.) Ez csökkenését okozhatja a teljesítménye ezekben a folyamatokban. Ezért nem hagyhatjuk figyelmen kívül töredezettség, ha használ ete gyors SSD-meghajtók.
Ne nézz a tükörbe
A mechanizmus adatbázis tükrözés nem támogatja előfizetés a tükör adatbázis (mivel a tükrözés közzétett adatbázis létezik Log Reader Agent). Azonban, akkor használja a „inicializálni az LSN» módszer, amely biztosítja a gyors újraépítése váltás után a tükrözés rendszert.
Ezt a technikát alapul meghatározása a regisztrációs számot a legutóbbi tranzakció replikációs műveletek alkalmazzák az előfizetői adatbázis mielőtt tükrözés. Fogjuk nevezni ezt LSN2.
Egyes műveleteket is tükröződik a tükör adatbázis előtt. Ez lehet például létrehozni LSN3 szám, ami egy kicsit tovább az időben, mint LSN2. Vannak is ügyletek, amelyek nem vonatkoznak előfizetői adatbázishoz. Ők korábban LSN2 vagy LSN3. Nevezzük őket LSN1.
Minden művelet akár LSN2 alkalmazni az alapvető előfizetési adatbázis. Minden művelet húst LSN3 alkalmazni az alapvető előfizetési adatbázis és másolja a tükör adatbázis. Ahhoz, hogy az inicializálás működését LSN új előfizetést az átállás után a tükör érvként sp_addsubscription kell átadni LSN3.
túl sok
A kérdés méret a mester adatbázis elérte 9 TB. Kiderült, hogy egyszerűen nincs elég ereje, hogy rendszeres karbantartást, hogy ez nem lesz hatással a folyamatban lévő munkát a vállalkozás. Legfőképpen aggódunk archiválás adatbázis helyreállítás engedélyezéséhez a baleset esetén. Mit tanácsol ebben a helyzetben?
Mindenesetre, a kulcskérdés az, hogy több fájlt csoportok az adatbázisban. Particionálása nagy egyes szakaszainak táblázatok vagy indexek található egyedi Fájlcsoportok. A kézi partíció nagy asztal található egy külön fájlban csoport (valószínűleg minden indexek).
Ilyen körülmények között, a helyreállítási meghibásodás esetén is gyorsabb (ha felülvizsgálata Enterprise Edition). Csak meg kell gyorsan helyreállítani a filegroups, amely szükséges a OLTP rendszerek. Használhatja a részleges helyreállítás, ami után használja részlegesen hozzáférhető adatbázist, hogy visszatérjen az adatbázis interaktív módban. Fájl helyreállítása tartalmazó csoportok régebbi adatokat később a részleges csökkentését, ha OLTP-műveletek már rendelkezésre állnak a fájl csoportokban.
A túlterhelési feltételek
Maga az egyik érték PLE kevés információ. Meg kell vizsgálnunk, hogy az értékek a trend. Lehetséges, hogy ez egy legitim működését SQL Server vezet jelentős csökkenését PLE vallomását. leolvasások gyakran jönnek vissza a normális. Ha az olvasás PLE hanyatlás és alacsony marad, akkor aggódni.
A küszöböt, amelynek szeretne reagálni, nem egy fix érték, milyen gyakran írnak róla. Az érték a 300 azt jelenti, hogy a teljes puffer medence helyett 300 másodpercenként. Ha van egy medence 100 GB méretű, ez azt jelenti, hogy a 100 GB-os új adat olvasni a memóriába ötpercenként. Van egy teljesítmény problémát. Azonban, akkor óriási probléma a teljesítmény sokáig PLE eléri a 300 Meg lehet számítani egy ésszerű érték (<размер буферного пула в ГБ> / 4) × 300, ahogy az a következő rekordot bejegyzéseket:
PLE a számláló, amelyre meg kell követni, de a kijelentések azt jelenti, ha esik jelentősen alatta marad a normál és hosszú ideig ebben a helyzetben. Ez egy általános ajánlás, és ez, sajnos, nem megfelelő minden helyzetben.