SQL Server User Group avagy kerekasztal kockáknak

Először is BUÉK mindenkinek. Új évre egy nem annyira új gondolattal kezdek: Már régóta foglalkoztat a gondolata egy olyan klubnak/fórumnak, ahol az emberek megoszthatják SQL-hez bármilyen módon kapcsolódó örömüket/bánatukat, tehát nem olyan, mint a Technet fórum, hanem annál tágabb, kötetlenebb, és alkalmanként interaktív eseményeket is tartalmaz (élőt vagy online-t).

  • Tudtátok, hogy ha megnyomom ezt az izét, akkor zenél is az SQL Server?
  • Olyat kell csinálnom, amit szerintem nem tud az SQL Server. Mit csináljak? (avagy ki tud többet nálam a MSSQL-ről vagy az Oracle-ről:)
  • Ti hogyan kezelitek a failed jobokat? És az inkompetens fejlesztőket?
  • írtam egy scriptet, így néz ki. Van jobb?
  • Mindent tudni akarok az indexekről!

Ami az interaktív dolgokat illeti, arra gondoltam, hogy lehet egy téma, amihez mindenki hoz valami előre definiált kis opcionális házi feladatot, aztán megvitatjuk/előadja valaki a legjobb megoldások egyikét. Például általános szerver üzemeltetés – mindenki hoz egy pár dolgot, amit szerinte tök jól csinál, egy párat, amit tök bénán, megbeszéljük, megértük, aztán megnézünk egy lehetséges működő változatot (kiselőadás), aztán megnézzük, hogy hogyan lehet még jobbá tenni az előtte elhangzott és közben felmerült ötletek alapján. Élőben persze ez sokkal jobban működik, ugyanakkor valószínűleg ez nehezítés lenne annak, aki 200 km-re lakik (lehet viszont, hogy megéri).

Mit szeretnék? Egy olyan közösségnek a tagja lenni, amiben az emberek segítik egymást, akár csak annyival, hogy elmondják azt, hogy ők mit hogyan csinálnak – akár azon az áron is, hogy megszervezem :) Én nagyon sokat tanulok mások scriptjeiből, példáiból, még a rosszakból is sokszor, és szerintem van itt elég sok olyan szakember és ember, akikből ezt meg lehetne csinálni. Nemcsak kifejezetten SQL-esekre gondolok, és nem tömeget képzelek magam elé, hanem egy (-két) tucat embert, akik szeretnének jobb szakemberek lenni, és/vagy látni azt, hogy mások hogy csinálják. Kicsit olyan “Technet gyakorlat” jelleget képzelek el, ahol lehet szidni is a Microsoftot (is, meg mást is – nálunk négyféle adatbáziskezelő van), meg nem csak a technológiáról, hanem a szemléletről, módszertanról is lehet beszélni :)

Nagyon kíváncsi vagyok a véleményetekre, gondolataitokra ebben a témában. Kommentezzetek, fikázzatok, javasoljatok.
Köszönöm.

19 Comments

  1. hgyorgy:

    Szia,

    ez nagyon jó kezdeményezés. Igaz én jelenleg tanulom az SQL-t (dba), így első körben valószínűleg okulnék, kérdeznék, mintsem hozzá is tudnék tenni érdemben. Kíváncsian várom a fejleményeket.

  2. krizsi:

    Szia!
    Nagyon jó ötlet, úgy érzem nekem is van mit tanulnom bőven, nagyon jól jönne egy ilyen – megvalósult – kezdeményezés!

  3. István:

    Szia!

    Jó ötletnek tartom, élvezettel olvasom a blogodat, mindig tanulok belőle valamit, de – csatlakozva az előttem szólóhoz – inkább tanulási célzattal tudnék hozzáállni. Ez úgy érzem nem teljesen egyezik meg azzal a célközönséggel, akire te szeretnéd szervezni, tervezni. Vagy tévedek?

    P

  4. Erik:

    Sziasztok!

    Köszönöm a kommenteket (első két nap kissé megijedtem, hogy nem érdekel senkit a dolog). Töredelmesen be kell valljam, én is tanulom az SQL-t :) Szóval megegyeztek a célközönséggel, mert érdekel titeket a dolog, és szeretnétek jobban csinálni, mint most. Nem elit klubot akarok csinálni, van már olyan fórum, ahol kérdezni sem merek, mert nem fogom megérteni a választ (SQL a téma) :)

  5. krizsi:

    Szia!

    Akkor itt a helyem :o). Ez azért is nagyon jó, mert hiába van tonnányi könyve az embernek, azok javarésze – sajnos – leegyszerűsített példákon keresztül mutat meg dolgokat, és sehogy sem jut túl a szimpla megoldásokon. Márpedig ha valaki használja az SQL-t nem hiszem, hogy pölö csak egyfelhasználós környezetben teszi, jogosultság kezelés nélkül, és még sorolhatnám. Többet tanultam Tőled, Socitól és még sorolhatnék néhány nevet, webcímet, mint jónéhány könyvből… És így egyre jobban frusztrál is a dolog, hogy mi mindent csinálok rosszul, vagy nem szépen, nem elegánsan. Persze erre mondhatják mások, hogy el kell végezni egy tanfolyamot (vagy többet). Évek óta tervezem én is, csak az az időfaktor ne lenne…
    A kérdezős fórumos dologról nekem is van bőven tapasztalatom, biztosan időnként nagyon bosszantó lehet egy hülye kérdés, de nyilván ha az ember tudná, nem kérdezné meg. Aztán jön a kioktatás, az érthetetlen válasz, és az értetlenkedés, hogy mit nem lehet ezen érteni.

  6. zsorzs:

    Tesztik az ötlet.
    És hogy konstruktív is legyek, első téma legyen mondjuk a … zegyik kedvencem, a performancia. Számos mindenféle dolog fellelhető ebben témában, ugye mivan akkor ha döglik a szerver, mit csinál a jó dba,ha lassú a szerver… nem erre gondolok, hanem a békeidőkre, amikor nincs baj. Hiszen a háborúra az ember a békében készül fel. Vagyis perfomaciaanalízis békeidőben is kell, hogy amikor beüt a ménkű, akkor legyen a mihez képest. És az is tapasztalat, hogy ritka az az eset aminek nincs előzménye. Ebben talán az ötödik pecsét c. magyar filmben Latinovits által játszott “Tanár úr” véleménye a mérvadó, sajnos pontosan nem tudom idézni, de a lényeg: ha egy lázadó megöl egy nyilast, vagy röplapokkal uszít, az piti ügy, mert azonnal lefülelik, alkapják, kivégzik, de amikor 4-5 jóravaló polgár az éjszaka leple alatt szidja a rendszert, na az a komoly ügy, és ezeket kellene leginkább elkapni és … innen nem spoilerezek. Szal a lényeg, jó tudni egy dba-nak, hogy a rája bízott rendszer hogy érzi magát, akkor amikor látszólag jól van. Hívhatjuk ezt preventív elemzésnek. én ezt a következőképpen csinálom: minden fontos sql szerverünkön teljes napi trace-t futtatok, 0:00:0től 23:59:59.59-ig. És ezeket a traceket szépen kielemeztetem egy robottal. Ez a robot egy saját fejlesztésű kisalkalmazás ami a Microsoft SMO c++ és c# libjeire épült (mert kettő van belőle), és ügyesen, akár egy text fájlt tudja soronként olvasni a trészeket. minden olvasáskor egy passzra több kérdést teszünk fel neki, ilyeneket: mond meg nekem, hogy a Application, loginname, hostname alapján mely rendszerek (applikációk) mennyi cput, IO-t esznek, és ez mennyi durationbe került, és hány ilyen trace sort olvastál ,vagy ki verte hátba direkt SSMS-en keresztül a melyik db melyik tábláját. Azt is érdemes tudni, hogy trace fájlban az audit logout event sorok a belogolt kliens addigi fogysztását, mint végszámla tartalmazza spidre (CPU, IO, Duration), vagyis ha nem akarsz beleveszni a részletekbe, akkor elég egy rövidebb csak az AuditLogout eventet trészelő trészt olvasgatni. Na tehát a sok fajta kérdésből összejön egy nagy csomó adat (csv fájlokban, mert az mindenki, még az xls is , azt meg a menedzsment is meg tudja emészteni) . És ezt szépen éjfélkor indulva, az összes szervertől elkérve a progi magától megcsinálja, és reggelre tálalja nekem, én meg össze tudom hasonlítani az elmúlt évek bmelyik napjával, és ha valmi disznóságot látok, akkor intézkedek, mivel előre lehet látni a bajt. Ez nagyon hasznos amikor a fejlsztőink egy új prgrammal, vagy annak módosításával lepnek meg minket, és majdnem rögtön látszik, hogy bizony nem volt túl okos a megoldás.
    Ez asszem hosszú lett, de röviden erről nem lehet értekezni, lehet hogy ez lesz ennek a fórumnak az egyik gyöngéje: egy téma még rövidítve is háborúésbékévé dagadhat. Kérdezzetek, ha valakit a téma bővebben érdekel.

  7. zsorzs:

    eehh.. persze hoogy tetszik, sőt épp most írtam be egy több kilobájtos szösszenetet a trace fáljok elemzéséről, de devnullba ment. hm…

  8. zsorzs:

    eeeh.. persze hogy tetszik, sőt épp most írtam be egy több kilobájtos szösszenetet a trace fájlok elemzéséről, de a dev/null ba ment…hmm, vagy én nem látok jól.

  9. zsorzs:

    bocs , megvan, csak türlemetlen voltam így 10 óra fele. Cserébe egy másik téma: a recovery model: egy hosszú távra és nem a gyors kirúgására tervező dba az ületileg fontos db-ire ugye full logot tesz. ami meg hajlamos a végtelenbe menő hízásra. Ezt úgy előzöd meg, hogy időzített sql jobbal tranzakciós logot mentesz mondjuk 5 percenként. Tegyük fel hogy napi mentésed van, és mondjuk naponta chekdb-zel a torn page-k után nyomozva, mert azoktól még a backup sem véd. Ekkor a legbiztonságosabb a két napi full log részek őrzése (vagyis kétnaponta ciklikusan írod felül őket pld. az első az 1. a második 5 perces a 2. … stb.).
    De persze azt is tudjuk Eriknek hála, hogy a tranzakciós log mentés csak abban esetben eredményez log rövidülést, ha nincs beszakadt tranzakció, és a replikáció is szépen dolgozik (nálunk bizony van tranz. push replikáció). Tehát nem biztos, hogy az időzített sql job elég. Ezért egy dupla-vészfék is van a rendszerben: egy másik job ami félóránként ébred fel, meg azt nézi, hogy a full logos dbék-nek mekkora a logja (perflogsapce), illetve hány %-ban szabad. Ha azt látja, hogy 85%-ig tele van, akkor gyorsintézkedésként sms-t küld a dba-knak, és nem várva rájuk, egy alternatív 2. logfáljt csatol a db-hez (egy másik jónagy -terás- vinyón), és ha ez is kezd betelni (megint eléri a 85%-ot), akkor a dba-k valszeg alszanak, így sajnálkozva visszaállítja a db-t simple logra. Azután majd a követekző db backup utána lusta dba majd leszedi az alternatív tarce fájlt, és újra kacsolja a full logot, és kissé széggyelli magát. Ez a módszer nálunk bevált, volt perzse 1. és 2. szintű ilyen eseményünk is (én igazoltan távol voltam akkor), és nem dőlt be a db a full log miatt.
    Lehet kérdezni, tudok scriptet is küldeni, ha melóhelyemen leszek hétfőn. Ja és mindfelett van egy ellenőr sql job , és neki egy naplótáblája, ami meg azt figyeli, hogy mely jobok futnak és melyek haltak be, és a szerverek meg egymás ilyen naplóit auditálják (hátha behalt a szomszéd sqlagent szervize), így kerek a történet.

  10. Erik:

    “10 óra fele”??? Te a Kanári-szigeteken vagy? :)

  11. zsorzs:

    bárcsak…
    nem. elgépeltem.

  12. zsorzs:

    A mai napra: mi lesz a rekordok sorrendje egy order by vagy group by nélküli clust.indexelt nagy tábla selectjénél?
    A helyes válasz: attól függ, hogy van-e a táblából valami már bent a memóriában vagy sem, vagyis éppen az olvasáskor előttünk nem kezdte el valaki más is már olvasni. Mivel nem írtuk elő a szervernek a sorrendet, így ő úgy ömleszti a kliensnek (vagyis nekünk) vissza ahogy neki a legjobb. És ha már van bent a memóriában valami, akkor naná hogy azzal kezd, aztán közben olvassa a többit a vinyóról. úgyhogy ne gondoljunk többet a clust.index mögé, mint ami: a tárolás sorrendje, de nem a default sorrendje a felolvasásnak, és visszböfögésnek. Ennek egyébként van tudományos neve is, a jól tudom valami körhinta (merry-go-round) technika. hányszor mosolyogtam azon a fejlesztői rácsodálkozáson, hogy dehát ez a tábla hogyhogy nem a clust. index sorrendjében jelenik meg nekem? Ha annyi ezresem lenne, akkor tuti a Kanári-szigetekről írnék nektek…

  13. zsorzs:

    Most kéredezek: ki hogyan menti a db-it? milyen eszközt használ? És azt a másikat meg miért nem? Válaszolni úgy ér, hogy mellérakod a db méretét is (hacsak nem üzleti titok nállatok).
    Nálunk a mentés alapja a SUN storage-ra alkalmazott HP snapshot technika, ehhez vannak MS SQL 2005 -ös szerverek, tranzakciós push replikáció 2 publisher, egy distributor, és 3 subscriber. Napi differenciális mentésünk 1,5 tera, hétvégén full mentés 3 tera, (mert ebben benne vannak az archivum adatbázisok is) szalagos mentőegységekre. A mentés ideje 20 perc , mivel a HP snapshot technika úgy ment, hogy készít egy pillanatfelvételt a logikai kötetről, és onattól az eltérést gyűjti , és háttérben írja a szalagra.A felvétel, ami kb 1 perc, közben a szervereket megfagyasztja, mint aza boszi abban a béna amcsi sorozatban a 3 banya testvérről.
    Ugyanzzel a technikával képezzük a napi frissítésű tesztkörnyezetünket (1,5 tera), ami az éles rendszer reggel 7 órakkori pillanatfelvétele, és 8-ra üzemképesen várja a látogatókat, saját replikációval, külön életet élve (és itt is megy a check db, keresve a torn-page-t). Mindezt teljesen automatán scriptelve, évente 2-3 alkalommal botlik meg, és akkor is inkább emberi hülyeség miatt. Ha érdekel valakit, akkor küldök részleteket, scripteket is, ha kell.
    Na, ti hogy csináljátok?

  14. zsorzs:

    Naná hogy elírtam, és naná hogy a SUN az SAN! A többi viszont igaz.

  15. zsorzs:

    Erik!
    A te blogod órája jár rosszul, illetve hozzám képest a jövőben! nállam most (Szsged, Csongrád megye, Magyarország, Európa, Föld, Naprendszer, Tejút (egyszerűbben ZZ9 Plurális Alfa) most épp 10:43 van.

  16. Horvath Zoltan:

    A Microsoft SQL Server Magyarorszagi Felhasznaloinak Csoportja szeretettel var mindenkit. Egy moderalt letszamu, de nagyon lelkes csapat alakult ki. Tavaly szeptemberben kezdtunk, es a tapasztalatok azt mutatjak, hogy minden negyedevben egy fix osszejovetelre lesz szukseg.

    A kozelgo esemenyekre javaslatokat is lehet tenni: http://www.meetup.com/hug-mssql

    Udv:
    Zoli
    (bocs Erik a keretlen promoert, de elegge a temaba vag :))

  17. Erik:

    megpromóztam főoldalon is, remélem nem baj :)

  18. Erik:

    Zsorzs, nemtom mi van az órával. most pl. téli időszámításon maradt.

  19. Horvath Zoltan:

    Ohhohó, dehogyis :) Köszi! :)

Leave a comment