Egyéb kategória bejegyzései

A nagy, a sok és a konkurencia

A fenti 3 dologban közös, hogy mindhárom ellensége a DBA-nak. Ahhoz, hogy tartósan megfelelően működjenek a szerverek, a fenti dolgokat figyelembe kell venni. Bár relatív fogalmak, mert függ a hardvertől is, hogy mikor érik el a kritikus szintet, de amelyik alkalmazás fejlődik ott figyelni kell ezekre.

Nézzük sorra, hogy melyik hol gond:

Nagy méret: (Ami nagy lesz az gond lesz, csak idő kérdése)

  • Nagy méretű adatbázisok: Minél nagyobb az adatbázis mérete, annál tovább tartanak rajta a karbantartási, mentési, helyreállítási műveletek, annál több hely kell a backup-oknak. Jó megoldás az adatbázisok elosztása. Pl.: Készül egy archív adatbázis a product adatbázis mellé, ahova az archive adatok kerülnek.
  • Nagy méretű táblák, indexek: Ezekben az esetekben is a karbantartási műveletek (pl: index rebuild, index reorganize, update statistics) kerülnek sok időbe. Célszerű darabolni a táblát (pl.: partition).

Sok: (Amiből sok lesz, az gond lesz, csak idő kérdése)

  • Sok sor: Minél több egy táblában a sor, annál mélyebbek lesznek az indexek, több lépésből tart megtalálni egy-egy sort is. A particionálás ebben az esetben jól jöhet.
  • Sok nyitott kapcsolat: Minden kapcsolat plusz erőforrásba kerül a szervernek. Amikor kezd kritikussá válni a mennyisége, akkor célszerű új szervereket beállítani a kiszolgálásba.
  • Sok utasítás egységnyi idő alatt: Amikor sok utasítás érdekezik be egységnyi idő alatt, akkor célszerű felülvizsgálni az alkalmazás(oka)t, mert lehet kódhibáról van szó, de az is lehet, hogy DML utasítások helyett a tárolt eljárás a nyerő. Egyéb esetben meg új szervereket célszerű beállítani a kiszolgálásba.

Konkurencia: (Ami konkurál egymással az össze fog akadni, csak idő kérdése)

  • Tranzakciós lock: Ezek a lock-ok a válaszidőket növelik meg. Márpedig a gyors válaszidőket jobban szeretjük. Ehhez vagy jól tervezzük az adatbázisokat és vele az alkalmazást is, vagy átnyargalunk az in-memory technológiára, ha van rá lehetőségünk.

 

A problémákra az ajánlások általános ajánlások, lehet másképp is megoldani, erősen esetfüggő.

Reklámok

Megtartottam az első SQL Workshop-om :)

Pár hete, igaz cégen belül, de jó tapasztalás volt. Kérték, hogy érdekes legyen, ne az SQL működésébe menjünk bele, így hát megpróbáltam univerzális (adatbázis kezelőtől független) szabályokat a miértekkel és esettanulmányokat bemutatni, az egyiket itt közzé is tettem. Egyértelműen az esettanulmányok voltak sikeresebbek.

Maga az előadás nem volt profi, viszont hasznos, utólag a tények ezt mutatják. A tervezett hossz 1 óra volt, de a sok kérdés miatt, 2×1 óra lett belőle.

Az előadás után sokat töprengtem, mire helyre állt a fejemben, hogy hogyan lehetne jobbá tenni egy-egy ilyen előadást. Egyelőre ezekre jutottam:

  • Az előadásban felváltva legyenek a pihentetőbb, gyakorlati (érdekes) részek (pl. esettanulmány) és a fárasztóbb, elméleti részek, amik a tudást adják
  • A tanagyag egyszerű, lényegre törő és logikus legyen, gyakorlati példákkal alátámasztva
  • Legyenek vicces részek, mert nevetni mindenki szeret
  • Legyen egy jegyzet, amit megkaphat a hallgató

 

Persze el is lehetne olvasni egy (szakmai) könyvet, hogy milyen is egy jó előadás, de most úgy gondolom, hogy még nem érné meg a befektetett időt 🙂

Itt az év vége, engedjük ki a gőzt

Így év vége tájékán megosztanék néhány vicces esetet.

 

1.) Kivételkezlés alkalmazás oldalon:
Hibaüzenet: “No MSSQL”.
2.) Kódoptimalizálás:
— És most frissítjük a gyorsítótáblát
/*
UPDATE table SET mezők WHERE …
*/
3.) A régi idők szekvenciája:
declare @new_id int = (select max(id) + 1 from tábla)
declare @new_id2 int = @new_id + 1

/Aztán mindkét id ment a táblába, amit párhuzamosan is írhattak./
4.) Állásinterjú:
D: Mi a clustered index?
U: Az a primay key. /Határozottan kijelentve/
D: Mi a különbség a primary key és a clustered index között?

A választ meghagyom “logi sztorinak”, de ha követed a felvételiző gondoldatmenetét, akkor könnyen kitalálod 🙂

5.) Felvételi feladat:
D: Ezek a lekérdezések nem használnak az indexet.
U: Olyan kevés a sor a táblában, hogy nem fognak a lekérdezések indexet használni. /Határozottan kijelentve/
U: Csatolva küldöm az új indexeket a régiek helyett…

6.) Tuning:
U: Vegyünk SSD-t! /A proci volt a szűk keresztmetszet/
7.) Statisztika:
U: Nem jó a stat.
D: Okés, milyen szám kell?
U: Nem, ezt nem így kell csinálni. Itt a logika, ami alapján meg kell írni a queryt.

U: Még mindig nem jó a stat.
D: Oké, milyen szám kell?
U: Nem, ezt nem így kell csinálni. Itt a javított logika, ami alapján meg kell írni a queryt.

U: Még mindig nem jó a stat. Ezt a számot kéne kihozni.

8.) Jogosultságok:
U: Kéne sysadmin jog a szerverre.
D: Jó, de akkor nektek kell adminisztrálni a szervert ezentúl.
U: Persze, nem probléma.

U: Kéne egy linked szerver, tudtok segíteni?

9.) Munka:
U: Ezt és ezt kéne csinálni.
D: Okés. De még mondd meg, hogy mi történik ‘A’ esetre.
U: Elmegyek megkérdezem… Szóval, akkor ‘A’ esetre ez van.
D: Okés. Hmmm, ‘B’ esetre mi a teendő?
U: Úúú, erre nem gondoltunk, de elmegyek megkérdezem… Szóval ‘B’ esetre ezt van.
D: Okés. Őőőő, ‘C’ esetre mi van?
U: Mindjárt visszajövök… Az a helyzet, hogy nektek nem lesz vele feladatotok, mi fogjuk csinálni.

10.) Új oszlop:
U: Bele kellene tenni ebbe a táblába is az oszlopot, mert úgy is *-al kérdezzük le, erőforrás meg nincs mindenhol átírni a kódot.
D: Okés, viszont soha nem szűrhettek rá, mert nem indexelt.
U: Persze, úgy lesz.
/Tanultunk az esetből/

11.) Öngól kérdés a management felé:
D: A jó vagy a gyors fejlesztést akarjátok?

12.) Mindent mi sem tudunk:
U: Mi a szuperkulcs?
D: Mi van?
13.) Tervezés:
U: Nem kell, majd alkalmazás oldalon megoldjuk.
D: Okés. /Kevesebb munka, kevesebb gond./

U: Mégiscsak SQL oldalon kéne megoldani.

14.) Scrum:
U: Hogy szoktátok tervezni a napi munkát?
D: Nem tudjuk tervezni, mert napi szinten 5-10 ad-hoc kérés esik be.
U: Jól van, akkor mostantól nektek is lesz scrum.

15.) Scrum-on:
U: Van valami ami akadályoz a munkában?
D: Semmi.
U: Ne csináljátok már, sosincs semmi, had intézzek nektek valamit.
D: Jó, kéne egy új egérpad.