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…

SQL 2005 cluster telepítés – Remote setup failed

Már többször telepítettem SQL 2005 clustert, de eddig ezzel a fícsörrel még nem találkoztam. végigballagtunk a telepítővel a mindenféle kérdéseken – ki mit futtasson, mi menjen fel, mi a cluster IP, satöbbi, satöbbi, majd megböktem az install gombot, és elmentem mítingelni, hogy kettőnk közül legalább a gép dolgozzon. Amikor visszajöttem, azt láttam, hogy setup failed. Egész pontosan ezt:

Setup failed to start on the remote machine. Check the Task Scheduler event log on the remote machine.

Hát ennek nem örültem. Megnéztem az event logot a másik node-on, a scheduled tasks menüjében, semmi okosat nem láttam. Aztán interneteztem, és megtaláltam a választ itt: http://support.microsoft.com/kb/910851.
Mint kiderült, ez azért történt, mert be voltam logolva a passzív node-ra is, amit nem szabad ezek szerint. Kilogoltam, újrakezdtem, és tényleg hiba nélkül lement. Szóval kedves szakik, ne installáljatok úgy SQL clustert, hogy valaki be van lépve a passzív node(ok)ra.

Mire jó a snapshot

A Technet üzemeltetői szemináriumon beszéltem többek között a database snapshotról is, és a felkészülés során egy kicsit belementem a málnásba. Lúzerségemet büszkén felvállalva megosztom mindenkivel, nehogy más is kitalálja ezt a bénázást.
A database snapshot egy olyan read-only adatbázis, amit egy meglévő adatbázis (ez a forrásadatbázis) alapján hozunk létre, és a forrásadatbázisnak a snapshot készítésekori állapotát tartalmazza. Létrehozása nem igényel erőforrást, fenntartása igen. Létrehozáskor ugyanis az SQL Server sparse file-okként hozza létre a fájljait, azaz igazából nem foglal helyet, mert csak azokat a lapokat tartalmazza, amik megváltoztak a forrásadatbázisban. Ez a copy-on-write nevű varázslat, azaz a snapshot tulajdonképpen készít egy backupot magának a forrásadatbázis lapjairól, mielőtt azok megváltoznának. A snapshotnak amellett, hogy egy múltbeli állapotot elérhetővé tesz, van egy másik nagyon előnyös tulajdonsága: segítségével vissza lehet állni az általa tárolt állapotra.
Egy adatbázisról gyakorlatilag akárhány snapshotot tudunk készíteni, de a snapshotnak megvannak a korlátai is: Először is, a snapshot teljesen függ a forrásadatbázistól. Ha a forrásadatbázis elpusztul, vele hal a snapshot is, mivel az adatainak az a része, ami nem változott, csak a forrásadatbázisban található meg. Ebből következik az, hogy nem alkalmas a backup pótlására.
Egy adatbázisról készíthetünk rengeteg snapshotot, ezek egymástól teljesen függetlenek lesznek. Azaz ha egy forrásadatbázisról készítünk tíz snapshotot, minden egyes lap változás a forrásadatbázisban tizenegy írást fog generálni – minden snapshotban egyet, plusz a forrásadatbázisban egyet. Ennek már lehet hatása a teljesítményre. Ráadásul ha vissza akarunk állni valamelyik snapshotra, akkor az összes többit el kell dobnunk. Ez az apró kellemetlenség abból ered, hogy a snapshotolt adatbázist nem lehet restorolni, márpedig a snapshotra való visszaállás erősen hasonlít egy restore-ra, konkrétan azt írjuk bele a SSMS-be, hogy RESTORE DATABASE ForrasAdatbazis FROM SNAPSHOT Snapshot. Vagy valami hasonló.
Tehát az az elképzelésem, hogy az adatbázisról készítek egy snapshotot egy változtatás előtt, majd ha vissza kell állni, előtte is készítek egy snapshotot, meglehetősen kivitelezhetetlen. Próbáltam tovább csavarni a dolgot: ha mirrorozva van az adatbázis, akkor a mirrorról csinálok egy snapshotot visszaállás előtt, és akkor… eszembe jutott az amikor mirrorozott adatbázist kellett restore-olnom. Először tükröt kell törni, mert a mirrorozott adatbázist sem lehet restore-olni. Végül is ez lett a végállomás: tükörtörés, és amikor a restore elindul, felhozom online-ba a mirrort, és ott a visszaállás előtti utolsó adat. Persze addig nincsen mirrorom, de az akkor amúgy sem lenne. Kicsit nyakatekert, kicsit savanyú, de a mienk!
Én meg majd legközelebb elolvasom a Books Online-t, tényleg :)

SQL Server uptime

Az uptime egy nagyon kedves és szeretett funkció számomra az operációs rendszerekben, jó látni, hogy mi mióta fut. Az SQL szerver esetében is lehet igény erre a szolgáltatásra, amit nem nehéz megvalósítani, ha egy aprócska tényt kihasználunk.

USE master

CREATE PROCEDURE sp_uptime
AS
DECLARE @up DATETIME
SELECT @up = login_time FROM sys.dm_exec_sessions WHERE session_id = 1

DECLARE @day varchar(4), @hour char(2), @minute varchar(10)
SELECT @minute = DATEDIFF(minute, @up, getdate())
SELECT @day = @minute / 1440, @minute = @minute % 1440, 
		@hour = @minute / 60, @minute = @minute % 60
PRINT @@SERVERNAME + ' has been up for ' + @day + ' day(s), ' + @hour + ' hour(s), ' + @minute + ' minute(s).'

Az alapötlet a hatodik sorban látható: az 1-es SPID-del rendelkező processz, a resource monitor a szerver indulásakor logol be, és ott is marad, amíg fut a SQL. Ezek után némi favágással a dátumot a megszokott uptime küllemre hoztam. A végén a print került be select helyett, mivel így nem kell azon bénázni, hogy az oszlopszélességet állítgassuk (persze aki szereti, írja át bátran). SQL 2000-nél a sys.dm_exec_sessions helyett master..sysprocesses van, session_id helyett pedig spid.
Azért a master adatbázis, mert így akárhol bemondhatjuk, hogy sp_uptime, az le fog futni, mivel az SQL minden sp_ kezdetű tárolt eljárást először a masterban keres, és csak aztán az aktuális adatbázisban. (Ezért nem jó ötlet sp_ kezdetű tárolt eljárásokat csinálni az alkalmazásainkhoz, mert mindig be fog nézni a masterba is a SQL szerver.)
Hogy mire használható? Öööö… fogalmam sincs. Én akkor találtam ki, amikor időnként megszakadt a kapcsolatom a szerverhez, ami amúgy is sztochasztikusan működött, néha újraindult, néha csak az oprendszer tűnt el a hálózatról, és jó volt tudni, hogy éppen hányadán állok a kis döggel.