A model adatbázis és a CREATE DATABASE

Pár hónapja nekiálltam félautomata adatbáziskészítő scriptet írni, és ennek során csodálatos felfeldezést tettem a model adatbázissal kapcsolatosan. Az ugye ismert tény, hogy a model adatbázis az újonnan létrehozott adatbázisok modellje, hogy öndefiniáljak egy kicsit. Tehát a model fájljai másolódnak le, illetve az ő beállításai öröklődnek az új adatbázisra. Méret, recovery model, növekedés, stb.

Akkor itt most megállnék egy pillanatra. A fentiek igazak, ha az ember SSMS-ből hozza létre az új adatbázist. T-SQL, azaz CREATE DATABASE használata esetén jön a meglepetés: az új adatbázis nem a modelnél megadott növekedési opciókat fogja használni, hanem előre beállított standardokat: az adatfájl 1 MB-tal fog nőni, a log pedig 10%-kal. Erre majdnem elkezdtem kiabálni, hogy ez egy bug, de – tapasztalataimból kiindulva – átolvastam a Books Online-t. És igazam volt, ez egy precízen dokumentált meglepetés:

If FILEGROWTH is not specified, the default value is 1 MB for data files and 10% for log files, and the minimum value is 64 KB.

Szóval ha Transact-SQL-lel hoztok létre adatbázist, figyeljetek a növekedésre. Egyéb meglepetést nem tapasztaltam. Eddig.

SQL Server SP kontra CU

Nemrég jött ki az SQL 2005 SP3, és múlt héten a SQL 2008 SP1. Mindenki patchelheti az SQL-jeit – és természetesen a klienseket, a Management Studiokat is. Eddig ez egy teljesen átlagos történet, az érintett emberek általában már tudják is.

Azt viszont nem mindenki tudja, hogy az SQL patch stratégiájának vannak érdekes mellékhatásai. Ezek megismeréséhez először nézzük meg a stratégiát magát: jönnek ki a hotfixek szépen sorban, de mivel sok van belőlük, időről időre összerakják őket egy nagyobb csomagba, melyet cumulative update néven árulnak. Ezek a megelőző service pack (itt most ő lesz az SP, nem a stored procedure) óta kiadott fixeket tartalmazzák, például az SQL 2005 SP2 CU10 az SP2 utáni tizedik csomag, aminek előfeltétele az SP2 telepítése, de a többi CU telepítése nem. Tehát a CU-k egyfajta “SP-n belüli SP-k”. Ez tiszta sor, nézzük a csavart.

Amikor egy SP-t készítenek, akkor először is meghatározzák a tartalmát. A service pack nemcsak a hotfixeket tartalmazza, hanem ebbe kerülnek bizonyos alkalmazásbeli módosítások is (az SQL 2000 SP4 az “önblokkoló” processzeket is blokkoltnak tünteti fel – jelezve, hogy saját magukat blokkolják; SQL 2005 SP1-be került a mirroring támogatása; az SQL 2008 SP1-be a oneclick installálható ReportBuilder). Így ennek a tesztelése egy kicsit nagyobb falat. Ezt kiválóan mutatja az SQL 2000 SP4 esete, ami végül nem lett tökéletes, elrontotta az AWE támogatást, így gyakorlatilag senki nem használ(t) “csak” SP4-es SQL Server 2000-t, hanem a 8.00.2039-es verziójú SP4-re már tolta is rá a 8.00.2040 verziójú hotfixet, ami az AWE támogatást visszaadta.

Ennek a “scope freeze“-nek a hozadéka a fent említett mellékhatás, ami tulajdonképpen annyi, hogy amikor kijön az új service pack, az nem tartalmaz minden addig kiadott hibajavítást, azokat sem, amiket már kiadtak cumlative update-ben is. Például az SQL 2005-nél az SP2 utolsó két halmozott firssítése (avagy cumulative update-je), a CU11 és CU12 már akkor készült el, amikor az SP3 scope freeze megtörtént. Hasonlóan a SQL 2008 SP1 a CU1-3 hotfixeket tartalmazza, a CU4-et már nem. A CU4-ből majd egy SP1 CU1 lesz hamarosan. Ha valakinek tehát tényleg kellett egy olyan hotfix, ami a CU4-ben volt benne, az ne rakja fel az SP1-et még, hanem várjon a CU4 SP1-es “újrakiadásáig”. Ha esetleg valaki felteszi a CU4-et, majd rá az SP1-et, azt veszi észre, hogy eltűntek a CU4-es hotfixek. Ez ugyanígy áll az SQL 2005-re is.

Tehát a CU-k az SP-k előtt bonyodalmat okozhatnak. A modell jóságáról lehet vitatkozni (épp nemrégiben olvastam egyet, az ihletett erre a postra, szerencsére én kellemetlenségek nélkül ismertem meg ezt még a 2005 SP3 kapcsán), mindenesetre tény, hogy így működik. Egy számomra szimpatikus javaslat volt ennek feloldására, hogy service pack scope freeze után ne adjanak ki cumulative update-eket, csak egyedi hotfixeket, így elkerülhetővé válik az akaratlan folteltávolítás (vagy patch uninstall angolul). Remélem a Microsoft megfogadja ezt a tanácsot, nekem is jobban tetszene.

DAC és SQL cluster

Igazából az előző postot a DAC-ról emiatt a kis szösszenet miatt írtam: ha van egy SQL clusterünk, akkor azon alapból nincsen DAC sehol sem, ezt tartsuk észben. Egy standalone SQL-nél alapból fut, csak belologunk az oprendszerbe, és már kapcsolódunk is, ha esetleg nem engedélyeztük volna a remote DAC-ot. Ilyenkor ugyanis a 127.0.0.1-es IP valamely portján figyel a DAC.

Egy clusternél viszont ez nyilvánvalóan nem működhet, ha végiggondoljuk a cluster concepcióját. Az SQL Server csak olyan erőforrásokat használhat, amiken dependál a service (közvetve vagy közvetlenül). Így például maga a SQL Server csak a cluster IP megadott portján tud figyelni, a cluster node-ok saját IP-jén vagy bármi egyében, beleértve a localhostot, nem igazán. Hát így történt. Ha clusterünk van, és akarunk DAC-ot használni, akkor muszáj engedélyeznünk a remote admin connectiont, aminek eredményeképpen a standalone gépen minden IP-n, a clustered instance-nál a cluster IP-n fog figyelni a DAC. Ajánlom mindenkinek, hogy kapcsolja be. Emlékeztetőül a bekapcs:

sp_configure 'remote admin connections', 1;
GO
RECONFIGURE;

Azonnal érvényre jut, lehet ellenőrizni az errorlogban, illetve kapcsolódni DAC-ra előtte-utána.

Dedicated Admin Connection röviden

SQL 2005-öt (vagy 2008-at) használsz? Olvastad az új fícsörök listáját? Akkor tudod, hogy van egy úgynevezett Dedicated Administrator Connection, barátok közt DAC, mely kiskapu egy üzemeltetőnek kínál hátsó bejáratot arra az esetre, ha valami rettenetes dolog történik, és egyébként már nem lehet belogolni se az SQL-be. Tipikus esetek lehetnek: valami durván kihajtja/széjjellockolja az SQL szervert vagy valaki elizélt logon triggereket alkalmaz, melyek nem tudnak lefutni, és így senki nem tud belogolni, még azért sem, hogy kikapcsolja a logon triggereket. Érezhető, hogy a klasszikus “újraindítom, az segíteni szokott” szemlélet az első két esetben segíthet (de soha nem tudod meg, hogy ki vágta haza a szervert és mivel), de az utóbbi esetben csak elodázza az elkerülhetetlent.

DAC-hoz való kapcsolódás alapból csak lokálisan engedélyezett, ez azért jó, mert ha kell a DAC, akkor nem kell azon agyalnod, hogy vajon ki használja az egy darab kapcsolatodat, csak valaki lokálisan lehet, azt meg könnyű kirúgni. Hogyan is működik a DAC? Az SQL Server indulásakor ő is elkezd figyelni egy porton, amit ő véletlenszerűen talál ki (sejtsük, hogy ez tűzfal mögül nem feltétlenül fog jól működni). Amikor hozzá akarunk csatlakozni, akkor a szerver neve elé be kell írnunk az admin: prefixet, azaz a SQL1 szerver DAC kapcsolatához az admin:SQL1 nevet kell megadnunk. Continue reading ‘Dedicated Admin Connection röviden’ »

AMD clock drift bug – fixed for Microsoft SQL

Short comment on my previous post: apparently, MSFT fixed this bug for SQL Server 2005 with SP3. More details are in their KB. It’s pretty detailed and you can get a picture of what you can miss with SP3 :) In the end, I should uninstall the AMD gaming mode stuff from the servers…