Ebból következik, hogy a legegyszerűbb nem-belépés az, ha elbukjuk az autentikációt. De az túl egyszerű. Inkább nézzük meg, hogyan lehet elbukni az authorizációt olyan mértékben, hogy be sem jutunk.

A legegyszerűbb a letiltás:

CREATE LOGIN [SQL01\ddisable] FROM WINDOWS;
ALTER LOGIN [SQL01\ddisable] DISABLE;

Csináltunk egy SQL logint egy domain usernek, majd letiltottuk a logint. Könnyű és nyilvánvaló, pipa.

Egy kicsit régebbi történet a DENY LOGIN:

EXEC sp_denylogin 'SQL01\ddeny';

Ez létrehozza az SQL logint a domain userhez, és annak rögtön meg is tiltja, hogy belogoljon. Erről a tárolt eljárásról egyébként azt írja a BOL, hogy elavult:
This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Use ALTER LOGIN instead.

Oké, és hogy használjuk az ALTER LOGIN-t? Hát, lehet DISABLE-t mondani, mint az előbb. De az nem egészen ugyanaz: a disable a sys.server_principals catalog is_disabled mezőjét állítja. A deny login pedig nem. Ő a sys. server_permissions catalog view-t bővíti egy sorral, amiben a CONNECT SQL jogot tiltja. Vagyis a fenti deny login script igazából így néz ki modernül:

CREATE LOGIN [SQL01\ddeny] FROM WINDOWS;
DENY CONNECT SQL TO [SQL01\ddeny];

És hab a tortán: ha ez nem elég, akár még ki is lockolhatunk egy accountot. Mi kell ehhez? egy olyan local account (vagy domain) policy, amiben van account lockout N próbálkozás után, plusz be kell állítanunk, hogy az SQL login ellenőrizze a policyt.

CREATE LOGIN slocked WITH PASSWORD='Password2',  CHECK_POLICY=ON;

Természetesen ez csak SQL loginra igaz, mivel a windows accountok lockoutját a Windows maga végzi. Rontsuk el párszor a jelszavát, és azt fogja mondani a jó jelszóra, hogy ki vagyunk lockolva. Erre két lehetőség van: vagy a jelszó ismeretében az ALTER LOGIN UNLOCK, vagy anélkül az ALTER LOGIN CHECK_POLICY=OFF, majd ON:

ALTER LOGIN slocked WITH PASSWORD='Password2' UNLOCK;
ALTER LOGIN slocked CHECK_POLICY=OFF;
ALTER LOGIN slocked CHECK_POLICY=ON;

Már csak egy kérdés maradt: mi a különbség a disable meg a deny között? Hát, a disable kb. arra jó, mint a Windows account disable: fel lehet vele függeszteni valaki-valami hozzáférését egy időre. A deny viszont azt a problémát tudja orvosolni, amikor egy csoportnak adtunk jogot, de azon belül egy kisebb csoportnak, vagy egyes személyeknek nem akarunk hozzáférést adni mégsem. A deny segítségével “kitakarhatjuk” őket a jogosultak köréből.

Az unlocknak pedig az a varázsa, hogy ha beállítjuk egy alkalmazásusernek, akkor simán ki tudja zárni az alkalmazást bárki az adatbázisból… :)

Először is: van egy komoly vallási kérdés a témában, miszerint vajon a count(1) vagy a count(*) a jobb. Ezt mind Oracle, mind MSSQL platformon keményen nyomják emberek. Legyünk egyszerűek, nézzünk meg egy végrehajtási tervet, és lássuk a valót: pontosan ugyanazt csinálja a szerver mindkét esetben. Lelke mélyén ő tudja, hogy pontosan ugyanaz a kérdés. Na de honnan van a válasz? Mivel azt kérdezzük ilyenkor, hogy hány sor is van a táblában, ez egy index scan lesz. És mivel az SQL Server okos, ezért a legkisebb lapszámú indexet fogja felolvasni. Nézzétek meg sok indexet hordozó táblákon, hogy milyen lehetetlen indexet bök ki. Általában azokat, amiknek nagy a NULL aránya, mivel azok kicsik. Persze filtered indexre nem ugrik.

A másik egy személyes élmény. Azt vettem észre egy szép napon, hogy a szerverek nagyon sok időt töltenek azzal, hogy select count(*) from sysfiles vagy select count(*) from sysobjects lekérdezéseket futtatnak. Hamar rájöttem, hogy ez egy marék Java alkalmazás műve, melyek sok kicsi lekérdezést indítottak, melyek előtt a JDBC driver futtatott egy health check kverit, hogy tudja, hogy jó az adatbáziskapcsolat, amit a poolból vett ki. Történetesen a health check drágább volt, mint sokszor a lekérdezés maga. A masteren a resourcedb miatt még join is van az execution planben. Mi egyszerűen átálltunk az alulmúlhatatlan select 1-re, de ha valakinek van hasonló gondja, inkább azt ajánlom, hogy válasszon egy táblát, és abból kérje le az első sort. Nekem ez sajnos a sok kis adatbázis miatt nem menő, mert senki nem fog mindegyikben táblát keresni, de másnak bejöhet. Nálam ez hatszoros telejsítménykülönbséget jelentett: 0.003 vs 0.018 total subtree costok jelentek meg.

Az első tennivaló, hogy az összes létező tamtamot elkezdjük verni, és lepereg előttünk életünk filmje. Mert ha ez az egy adatbázis megsérült, megsérülhet más is – akár hardver, akár szoftver, akár csillagállás, igaz a többiekre is. Ha van mirror vagy log shipping secondary adatbázis, akkor aktiváljuk, ellenőrizzük, és nézzük meg, hogy ott vannak-e az adatok. Ha nem, akkor vakarjuk meg a fejünket, és olvassunk tovább.

Ezután igyunk egy kávét/kólát/ánizsteát, dohányosok szívjanak el egy cigit, és gondolkodjunk el azon, hogy hogy lehet a legjobban kimászni a helyzetből: itt jön a legutóbbi backupok kérdése,valamint a legutóbbi sikeres DBCC CHECKDB ideje, hogy lehetőleg ne állítsuk vissza mentésből a sérült adatbázist. A korrupt adatbázisra a hozzáértők egybehangzó tanácsa: állítsd vissza mentésből. És ez így igaz. Ez az egyetlen tuti módszer van, ha nincs egy működő tartalékod. Ha meg tudná csinálni tutibiztosan a SQL Server, megcsinálná magától, és nem lenne sérült az adatbázis.

Persze lehet, hogy a backup nem épp a legfrissebb (olyat nem írok, hogy nincs), és mégis kell valami adat a beteg db-ből. Ekkor nem ússzuk meg a hősi munkát. Az én általános DR tervem a következő:

0. Ellenőrzöm, hogy van-e elég szabad helyem ahhoz, amit fogok csinálni: adatfájloknak, tranlognak (jó nagy lesz, amit a #2 csinál), backupnak.
1. Elkezdem a restore-t, amilyen gyorsan csak tudom, egy új adatbázisba.
2. A suspect adatbázist felhozom emergency módba (ALTER DATABASE Titanic SET EMERGENCY), és elkezdem kitolni belőle amit csak lehet: a teljes sémát megpróbálom kiscriptelni egy új adatbázisba (indexekkel, foreign keyekkel, default értékekkel, de legfőképpen identity oszlopokkal), aztán megpróbálom az adatokat is átpumpálni bele. Itt jön az izgalom: ha a db korrupt, akkor valahol valami nem fog sikerülni. Jó esetben hibát is dob a SQL. De nekünk itt pl. nem dobott hibát, csak csendben lenyelte az utolsó három napnyi adatot. Tehát mindenképpen kell a humán adatellenőrzés.
3. Ha a #2 lement, rátolok egy DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS-t a db-re, hátha többet vissza tud utána adni, mint a #2-ben. Persze lehet, hogy kevesebbet.
4. Ha megvan a működő adatbázisom valahogy a háromból, akkor leellenőrzöm logikailag az adatokat, tolok rá egy DBCC-t, egy backupot, beállítom a backup jobot hozzá, és ráengedem az alkalmazást.

Miért szivatom magamat mind a hárommal egyszerre? Mert a backup-restore jól hangzik, de ha kiderül, hogy baja van már a backupnak is, akkor az az elvesztett idő később fájni fog. Plusz ha nem csináltam az elmúlt pár percben tranlog backupot, akkor még adatot is veszítek tutira. Ha ki tudom szedni a legutolsó adatokat a sérült DB-ből, az lefedheti az így keletkezett hézagot. A #2 egy logikus lépés, a #3 szintén, és mint jeleztem, más adatokra számíthatunk. Pl. ha megsérült egy tábla közepén a clustered index, amit a repair ki tud vágni, akkor egy 10000 soros táblából #2 visszaadhatja az 1-2450 sorokat, #3 pedig az 1-2100 és 2900-10000 sorokat. Igen, hiányzik a közepe. Na és? Ha annyira fontos, akkor tessék mirrorozni.

Itt jegyzem meg, hogy szerintem az egyetlen tuti biztonságos tartalékképzési módszer a High Safety, azaz szinkron mirroring. Itt ugyanis nem a diszkről olvassa vissza az SQL Server, hogy mit is csinált az aktív adatbázis, hanem a memóriából kitolja mindkét helyre. Ez pl. egy esetlegesen felbukkanó hibánál sokat számít, például ha csak időnként ront el valamit a diszk kontroller, és ráadásul egy ideig még érvényes adat is marad a tranzakciós logba került szemét. Na nem mintha láttam volna már ilyet, csak úgy mondom. Cserébe a szinkorn mirroringnak van hatása a teljesítményre is, konkrétan csökkenti, mivel minden commit előtt van egy rövid megbeszélés a principal (aktív) és mirror (passzív) adatbázis szerverek között.

Végül hadd vonjam le a tanulságokat:

• Legyenek backupjaid, ellenőizd, hogy készülnek-e, teszteld őket időnként.
• Futtass rendszeresen DBCC CHECKDB-t. Ideális esetben legalább minden full backup előtt, így lényegesen nagyobb esélyed van arra, hogy a backupod jó lesz.
• Legyen DR terved, és próbáld is ki, amennyire csak tudod.
• Legyen tartalékod a fontosabb adatbázisaidból. Fantasztikus tud lenni 5 perc alatt megoldani egy DR-nek induló szituációt.

Ez persze nem baj, van már SQL 2008 meg SQL 2008 R2, meg még ki sem jött a hivatalos SP4, aminek a kiadásától még lesz egy darabig support – hogy meddig, azt itt lehet majd megnézni, a Microsoft Product Lifecycle oldalon. Ezt egyébként mindenkinek ajánlom, aki új installációt/rendszert/akármit tervez: előbb nézd meg, hogy hogy állsz supporttal, mert pl. ma SQL 2005-re nem érdemes építeni, csak ha nincs jobb dolgod, mint upgrade-elni jövőre, vagy nagy a nyomás. Nincs annál kellemetlenebb, mint amikor az ember felhívja a supportot, és ők kedvesen közlik, hogy két hónapja not supported az SP, amit használsz, please upgrade és aztán telefonálj megint. Na jó, van egy csomó, de sarkítani akartam.

Jogos kérdés, hogy mi az értelme az SP-nek, ha végül is nem több, mint a CU11 volt? Hát, egyrészt a support így nyúlik majd meg egy kicsit a SQL 2005-nek – lásd fent :) Másrészt pedig a hotfixek meg CU-k olyanok, hogy a Microsoft azt ajánlja, hogy akkor tedd fel őket, ha van valami olyan problémád, ami indokolja. Persze az ember attól még néha patchel, mert nem szeret lemaradni. A MSFT meg azért mondja ezt, mert a CU-k nincsenek úgy rommá tesztelve, mint az SP-k, mert egy SP tesztelés az elég intenzív élmény. Hát ezért. Mindenesetre én az SQL 2005-öt úgy fogom megőrizni az emlékezetemben, mint a verziót, amivel az SQL Server teljesen nagykorúvá vált.

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