Mi lesz az extra a tranzakcionális replikáció elemzésében? Hát, például az olyanok, hogy central subscriber berhelése, adat inkonzisztencia kezelése is leíródik, amiket eredetileg nem terveztem. A central subscriber kevés embert hoz lázba, mert homályos. Arról van pedig csak szó, hogy van egy szerver, ami több hasonló és/vagy kapcsolódó adatbázis publikációira iratkozott fel, és összefésüli az adatot. Például több régióba telepített ugyanolyan alkalmazások adatbázisait rántja össze. Ebben az első kihívás az inicializálás: a második subscription már békén kell, hogy hagyja a létező adatokat. És az igazi öröm az, amikor ez eltörik, és újra kell gyártani. Ami egyébként nem nehéz, ne hintsük itt a port :) Majd részletezem, ahogy haladok.

Viszont azt előre megmondom, hogy a konferenciáig az Availability Groupokról egy betűt nem fogok írni. Inkább gyertek el ;) Amúgy tényleg.

The question outlined in the title can be interpreted in many ways. The typical things in my head are the following:

• Programming: set-based, declarative approach vs sequential, procedural programming
• Operations: RDBMS is quite different from OS and other standard apps (including server products)

Going through the items: a typical problem with application development is that most developers just can’t digest that SQL is not procedural language. It hates when you tell it how to do something. And it will punish you with amazing performance hits. Believe it or not but I really got T-SQL code like this:

DECLARE @tranid bigint, @processor int
DECLARE tranitem CURSOR FOR
SELECT transaction_id, processor
FROM transaction_history;
OPEN tranitem;
FETCH NEXT FROM tranitem INTO @tranid, @processor;
WHILE @@FETCH_STATUS = 0
   BEGIN
      IF @processor BETWEEN 31 AND 44
         UPDATE transaction_history SET processed = 1 WHERE transaction_id = @tranid;
      FETCH NEXT FROM tranitem INTO @tranid, @processor;
   END;
CLOSE tranitem;
DEALLOCATE tranitem;

Needless to say, transaction_history had 300 million lines and the column processor had an index on it. With the supplied script, we couldn’t wait for the completion. With the rewritten one, all the few thousand matching rows were updated in less than a minute. Oh, yes, this is what I wrote:

UPDATE transaction_history SET processed = 1 WHERE processor BETWEEN 31 AND 44

So a DBA is someone who can write effective T-SQL code? Sounds like a database developer… :)

Looking at the second item: why is a relational database engine so special? Well, because I like them :) Seriously, they should use a different approach in some cases than an OS or a webserver. Most obvious part is the scheduling I think. OSes usually use preemptive scheduler, that is, every process gets a time slice to run, then they should wait in the queue. With SQL Server that would be disastrous as the SQL processes would wait in the queue holding locks and it would bring down server performance. Instead, SQL Server goes for a cooperative scheduler, trying to give enough room for a process to finish completely as quick as possible. In general, SQL Server thrills to minimize lock holding time. And as a DBA, you should be good at understanding the locking mechanism, lock compatibilites and understand how online exactly is online indexing.

Also, if you’re a DBA, you should know that SQL Server is optimistic. It expects that if a transaction is started, it’ll be committed and in 99.99% of the cases, it’s right. In the remaining 0.01%, rollback is a bit more expensive than it could be if someone had optimized for it. Needles to say, you won’t restart your server if you abort a batch running for two hours and the rollback is not done after 30/60/90/120 minutes. Do you? You would wait a bit more to get back your database…

So far, the DBA is a guy who can write well-performing T-SQL code and understand the SQL Server architecture.

Let me add one more thing: they should be good at operational thinking as well – this differentiate a DBA from a developer and a Windows admin. Operational mindset is that you’re sensitive to potential pitfalls and you know how to avoid them. So if you see the T-SQL code, your only question is not if it’s good as it looks but you also ask if it’ll run fine in 25 instances in parallel. You know that things shoudl be tested first and test environment should be as mush similar to production as possible. (You know you should have a test environment, do you?) And you know when you can/should make bold moves, going with something untested.

Why are DBA skills necessary? Because otherwise you screw up your database server. Either by bringing it down and/or wasting its capacity. I’m no angel here. I was an involuntary DBA a few years ago and there was an issue with the backup partition in one of our clusters. To suspend all tranlog backups, I decided to stop the SQL Agent instead of disabling all the backup jops one by one. Smart idea, you may say. So I said SQL Agent service stop in Computer management and started to work. A few unexpected things happened in the next few minutes (e.g. I saw new backups appearing on the drive), so I checked the cluster and found that the agent started magically. Then I found that the whole cluster failed over. Later I realized that the cluster service detected that the agent was dead and did a failover. I should have used the cluster administrator or cluster.exe for this task. Since then, I’m very well aware of it.

One interesting thing is that people has a very dishonesting picture about SQL Server and what I see is that it partially comes from the fact that if you picked a SQL 7/2000 installer without any idea about all the things I wrote, you could still install and use it (and got surpised on the big transaction log). And these guys ran into serious problems – not because SQL Server was crap but because they had no idea about how it works. On the other side of the wall, if you had no experience with Oracle, no way on earth you could install one. That was a separate art. This way if you had an up and running Oracle server, there must have been someone with at least average skills around. (For the record: I’m not challenging the fact that Oracle had a better database engine at that time.)

A Microsoft számomra az a cég, amelyiknek olyan kiváló fejlesztői vannak, hogy csak na, és olyan marketingesei, hogy ha nem lennének olyan kiválók a fejlesztők, talán be is csuktak volna már. Erre az egyik kirívó példa az SQL 2008 kampány volt. Hányan szenvedtek azzal, hogy hiába volt clusterük, nem tudtak installálni SP-t 10-15 perc leállás nélkül, ami alapjaiban döntötte meg a nagy rendelkezésreállás élményét. Ehhez képest SQL 2008-at lehet node-onként patchelni, egy failovernyi, azaz 25-55 másodperc kieséssel. Ég és föld szerintem – de csak véletlen, egy technikai blogon tudtam ezt meg. Ugyanakkor a tonnányi marketingvacak meg már égette a szememet, ha megnéztem az SQL Server honlapot.

Most az R2-nél valahogy hiányzott az egységes kommunikáció, mint olyan. Különböző emberek különböző dolgokat tudtak, hogy hogy fog kinézni a végleges termék, de pl. a 10 GB-os Express mérethatárt csak a bejelentés napján az SQL Express blogban olvastam először. Az amerikai MVP-k meg azon buktak ki, hogy miért 2008-as feature-öket marketingelnek a 2008 R2 bemutatón, miért nem 2008 R2-eseket.

Sebaj, majd a Denali (SQL Server 11) talán jobb lesz… A nevet Dan Jones hozta nyilvánosságra, tévedésből (azt hitte,hogy publikus), le is szúrták érte, a http://blogs.msdn.com/dtjones/archive/2010/02/14/codename-denali.aspx pedig hamar el is tűnt, de akkorra már késő volt… Az MVP Summiton ki is röhögte mindenki szegényt, amikor az NDA fontosságára hívta fel a figyelmünket az előadása kezdetén. Ő is nevetett, bár nem pont úgy, mint mi.

Megnéznék egy céget, ahol az Apple marketingesei dolgoznak a Microsoft fejlesztőivel. Az nagyot szólna…
</puffogás>

• 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.

Maga az interjú egyébként elolvasható a Techneten.