Rollback

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 fenti kérdésre a válasz mindenkinél változó, de az SQL Server egyszerű lélek:

• master adatbázis data file
• master adatbázis log file
• errorlog

Ha ezt a három fájlt meg tudja nyitni, már boldog. És ha nem? Mindig az errorloggal kezdjük vizsgálódásainkat. Ha nem találjuk az errorlogot, nézzük meg, hogy van-e joga oda írni a SQL-t futtató accountnak. Ha megtaláljuk az errorlogot, akkor meg olvassuk el.
A fenti paraméterek egyébként az SQL Server Configuration Managerben láthatóak és állíthatóak (meg a registryben).

Éppen építem a félautomata SQL Servert (mint már párszor említettem), és ennek egyik állomása az, hogy a szakmailag kevéssé felkészült, ámde elszánt fejlesztők ellen, akik hibernate-ben mindent összedobálnak, elveszem az alkalmazások dbo jogát, és helyette csak írni-olvasni tudnak majd. Ez jó ötlet, hiszen ott van a beépített db_datareader és db_datawriter role minden adatbázisban, de…

A problémát a tárolt eljárások és függvények okozzák, amelyekhez külön-külön kell jogot grantolni. Ezt persze lehet scriptből is, de azért elég jó esély van arra, hogy ezt el fogom izélni valamikor, és nem lesz joga az alkalmazás usernek vmit csinálni, mire azt mondják, hogy azonnal adjam vissza a dbo jogot. Ennek a problémának a kivédésén agyaltam, és már-már kezdtem hajlani a DDL triggerek felé (minden SP gyártás után automatikusan adjuk rá jogot a megfelelő usernek), amikor egy számomra sokkal szimpatikusabb ötletbe botlottam.
Continue reading ‘Gyorsan jogot az összes tárolt eljárásra’ »

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

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.