Rollback

Épp eszembe jutott, és gondoltam megosztom mindenkivel: pár hónapja SP3-at installáltunk a SQL-re, és azt találtuk, hogy elfrakkol az install. Újrakezdve is elfrakkolt. Meg kellett nézni a logot (programkönyvtár\Setup Bootstrap könyvtárban laknak ezek az izék), és kiderült a hiba: a distmodel.mdf fájl hiányzott a drágámnak, mert ott kereste, ahol a master.mdf volt, de mi átmozgattuk máshova időközben. Úgyhogy baráti jótanács: ha elmozgatjátok a rendszeradatbázisokat, mozgassátok az összes adatfájlt együtt :) Kicsit deja vu érzésem van – lehet, hogy ezt már megírtam egyszer?

(mostanság nem volt időm írni, mivel dolgozom :), ha nem a munkahelyemen, akkor pedig egy menedzsment adatbázist reszelek, ami reményeim szerint tök kényelmessé teszi a DBA életét)

Az SQL 2005 profilerben megjelent egy érdekes eseménycsalád, a Deprecation, azaz elavulás. Ez mutatja meg, hogy milyen dolgokat használunk az SQL Serverben azokból, amik meg lesznek szüntetve. Két esemény van benne: a Deprecation Announcement, ami azt mondja, hogy vigyázz, mert ezt rátettük a halállistára, és a Deprecation Final Support, ami azt mondja, hogy ez a lista tetején van, és a következő major release-ben már kiveszik. A következő major release SQL 2005-nél a 2008, 2008-nál pedig a 2008 R2.

Könnyű kipróbálni: indítsunk el egy profilert a Deprecation eseményekre (ha bepipáljuk a show all events boxot, akkor biztos meglesz), és nyissunk egy query window-t a profilerezett SQL szerveren! (Amennyiben a szervert használjuk másra is, mint játékra, akkor szűrjük le a profilert a query window spidjére, amit a status baron megtalálunk a felhasználónevünk után zárójelben.) Abba pedig írjuk bele a következőt:

SELECT name FROM msdb.dbo.sysjobs (NOLOCK)

Majd nézzük meg a profilert!

Specifying table hints without using a WITH keyword is a deprecated feature and will be removed in a future version.

Tehát működik. A haszna nyilvánvaló: migráció előtt látja az ember, hogy mivel lehet probléma, de én egy kicsit továbbmegyek ennél: éppen most készülök bedobni azt, hogy nem veszünk át olyan adatbázist vagy módosítást, ahol deprecation warning van. Javítsák ki most, ne legyen még egy csontváz a szekrényben, az már így is tele van…

Szerintem érdemes időnként futtatni egy kicsit, és megnézni, hogy miket kap el. Nálam a master, msdb és AdventureWorks adatbázisokat :) Szóval érdemes szűrni felhasználói adatbázisokra (databaseid > 4) éles üzemben, a Microsoft meg majd rendet tesz a rendszeradatbázisokban.

Ha az ember egy erősebb vason SQL Server Standard Editiont futtat, akkor találkozhat a kedves hibaüzenettel az errorlogban:
A significant part of sql server process memory has been paged out. This may result in performance degradation
Ez kellemetlen lehet, a oprendszer kitalálja, hogy neki másra (is) kell memória, és kiülteti az SQL-t a kispadra, aminek a teljesítménye tényleg leromolhat ilyenkor, nem viccel az errorlog.

Enterprise Edition esetén ez nem probléma, mivel az rendelkezik a mágikus “Lock pages in memory” képességgel (feltéve, hogy a futtató user megkapta a szükséges OS-szintű jogot), de a standardon bizony sokat szívtak ezzel emberek, beleértve engemet is. Éppen ezért örülök nagyon annak, hogy végre kivették ezt a bosszantó korlátozást, pontosabban kiveszik hamarosan. Még pontosabban egy trace flag segítségével be lehet majd kapcsolni azt, hogy lehessen lockolni a memóriába a lapokat. A várható szállítási idők:

• SQL 2008 SP1 CU 2 – 2009 május
• SQL 2005 SP3 CU 4 – 2009 június

Én már felírtam a naptáramba :) A PSS blogon az eredeti post itt olvasható.

A cím nem a személyiségfejlődéshez, inkább a más accountok megszemélyesítéséhez kapcsolódik. Az SQL Server ugyanis lehetőséget ad arra, hogy egy megfelelő jogosultságokkal rendelkező login alól egy másik loginra (vagy userre) váltsunk át, és annak a nevében futtassunk lekérdezéseket. Ez különösen hasznos lehet például hibakeresésnél vagy ha vissza akarunk élni a hatalmunkkal.

SQL 2000 alatt már megvolt a SETUSER nevű parancs, ami átváltott egy megadott user alá, és viszonylag lehetett használni, de az igazi boldog élet a 2005-tel köszöntött be, ő hozta el az EXECUTE AS utasítást. Itt már megmondhatjuk, hogy database user vagy server login szinten akarunk imperszonálni, lehet ezt a privilégiumot bárkinek megadni (SETUSER csak sysadmin vagy dbo joggal megy), illetve lehet több szint mélyre lemászni, és onnan visszajönni.
Continue reading ‘Az légy, aki lenni akarsz’ »

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’ »