Soci blog

Fél nap alatt közel 400-an megnézték vagy belenéztek a screencastba, ennek igazán örülök, nem gondoltam, hogy ennyi embert érdekel a téma.
Közben visszajeleztek barátaim, hogy a probléma -úgy néz ki- megoldódott, az a lekérdezés fullasztotta le a szervert, amit a videóban optimalizáltunk. :)
Hangyál Zoli a NetAcademia SQL szakértője jelezte, hogy a performance counterek és a profiler eredményeinek egyeztetését ügyesebben is meg lehet oldani mint ahogy a screencastban tettem. Én ugye kézzel raktam össze a két adathalmazt.
Az SQL Server 2005 profilere képes az sql trace mellé betölteni az adott időszak peformance logját is, File/Import Performance Data. Ez igen finom dolog, a két adatforrást szinkronban tartva lehet mozogni az időben.
Az alábbi képen az látható, amikor a bűnös lekérdezés éppen lefutott. Ott leesik jó pár perf számláló, és ha a piros függőleges vonallal arra a környékre navigálok felül máris bejön a beteg lekérdezés a profilerbe. Nagyon durva, nem? Köszönet Zolinak a tippért.

(Ez nem az előző heti konferencia felvétele, az az MS honlapján lesz fenn kb. egy hét múlva, majd belinkelem.)
Nemrég segítettem egy barátomnak kinyomozni, hogy mitől hal be a webszerverük illetve mögötte az SQL Server bizonyos időintervallumokban. Ennek a nyomozásnak a folyamatát mutatom be életem első screencastjában. A gyanús lekérdezés IO költségét 300 ezerről 4e-re sikerült lehúzni, ennek a lépéseit is beleraktam a screencastba. Ha valakit érdekel hogyan kell tényleg komplex lekérdezéseket optimalizálni, az szeretni fogja a felvételt. Kicsit visszafogott hangú, mert aludtak a babák amikor rögzítettem, de az enyém. :)
A jövőben sok screencastot fogok készíteni, egy részét csak hobbiból, egy részét az ms részére, így majd fejlődni fog a technika, lesz intro, intro zene, stb, csak ezeket még meg kell szülnöm.
Sreaming avi verzió htmlben, full screenre maximalizálható, avi direkt link (~100M), flash verzió nem olyan jó minőségű, de csak 23M az egész, megállítható, tekerhető, de nem maximalizálható.
Ha valaki veszi a fáradtságot, hogy végignézze (26 perc, nagy idő a mai világban, tudom), akkor kérem jelezzen vissza, hogy van-e igény hasonlóra a jövőben is, mert nagyon sok mindent így sokkal gyorsabban meg tudok mutatni nektek, mint egy full-featured cikkben, ami azért sok energiát és időt igényel.

Update: bocs, rossz avit töltöttem fel, most megy fel a jó. A Camtasia tud smartfocussal is videót létrehozni, ami ránagyít arra a részre, ahol egérrel mutogatunk. Jó ez, de a végrehajtási tervekből pont a lényeg emiatt lemaradt. Egy óra múlva fenn van a rendes verzió, ez ráadásul csak 100 mega lesz. Addig is a flash verzió megfelelő.
Update2: fenn van a jó videó. Firefox alatt nekem befagy az avi-html verzió, IE-ben jól megy. Gondolom bugos a firefox media player addin.

Szerintem egész jó lett, remélem tetszett a hallgatóságnak is. Annak ellenére, hogy nem volt kaja eljött kb. 55% jelentkező (pontosabbat egyelőre nem tudok), és ez nem rossz.

Pptx. Ppt. Lesz belőle screencast is hamarosan, elmondom újra itthon, de csak, ha aludtam rá egyet (ha tudok, mert lehet, hogy skarlátos Bálint, és a két kicsi is beteg). Shit happens.

A Disk Usage riport a Management Studioban kilistázza azt is, mikor-mennyivel nőtt az adatbázisfájlok mérete az AutoGrow miatt. Érdekelt, honnan veszi ezt az infót, hát el is indult a profiler.

Gyorsan kiderült, hogy már 2005-től fut egy default trace a háttérben, ami alap, de fontos dolgokat gyűjt. Pl. adatbázisfájlok méretváltozásai, errorok, missing statisztikák és egyebek, secu audit jellegű dolgok, FT aktivitások, DDL jellegű változások, mem. állapot, stb.

Ebből bányászik a riport. Némi infó a default trace-ről.

Hölgyeim és Uraim, 2008. szeptember 24., Lurdy.

Én az egyik kedvenc, ha nem a legkedvesebb témámról, az SQL Server optimalizálásról fogok beszélni. Nem törekszem rá, hogy mindenáron a 2008-as újdonságokról beszéljek, arról már volt szó májusban, hanem nagyon sok, már sql 7 óta használható technikáról is szó lesz. Persze, szó lesz included column-ökről (2005) és filtered indexekről is (2008), esetleg a Forceseek hintről is (2008).

Erről a témáról nagyon sok mondandóm és gyakorlati élményem van, amit persze nem lehet 70 percbe besűríteni, ezért igen gondosan kigyomláljuk az előadásig azokat a témákat, amelyeket később screencast formájában fogok bemutatni.

Piszok sok screeencast ötlet kavarog a fejemben nem csak sql témakörben, de egyelőre a családi viszonyok nem teszik lehetővé, hogy legyen annyi erőm és csendes nyugalmam, amivel nekivágnék a felvételükhöz. (A ház emeletének végleges beépítése már erősen tervezés alatt…)

De minden változik, a babák lassan csak elkezdenek önállósodni, és akkor majd beindul a gépezet. Stay tuned.

Nem, nem Disk Queue Length, az a múlt. Ezért.

Apró, de hasznos tudnivaló.
Mentésből visszaállított adatbázisok klasszikus problémája, hogy hiába van a visszaállított adatbázisban Józsi nevű felhasználó, és hiába van a szerverszintű loginok között Józsi, a kettő nem akar egymásra találni.
Régebben az sp_change_users_login-t használtuk a párkeresésre.

SQL 2005-től működik az ALTER USER WITH LOGIN is, ez ráadásul az előbbivel ellentétben NEM csak standard loginokra működik.

ALTER USER user_name WITH LOGIN = login_name

Az sp_change_users_login viszont egyszerre sok felhasználót is tud párosítani, így nem érdemes teljesen elfelejteni.

Multimédiás blog híján mindenki játssza le a fejében a hangot. :)

Örülünk, töltünk, telepítünk.

Köszönet Hangyál Zolinak a gyors hírért.

Update: szopás, várni kell még pár napot a VS 2008 miatt.
SQL Server 2008 RTM Available for Download

English downloads are available now and additional languages will be added on a daily basis. Visual Studio 2008 users will need to download and install Service Pack 1 which will be available here after August 11, 2008.

Megléptem ma, ha már beta és ingyen van. Az alábbi témák ismerete ajánlott a vizsgához:

• Maintenance Planek részleteiben
• A Backup új szolgáltatásai (COPY ONLY, titkosítás, stb.)
• CHECKDB új cuccai pl. spatial típusokhoz
• Adatbázisok mozgatása szerverek között
• Jogosultságok. Ezek miatt sokat buktam szerintem, rá kell szánni egy órát, és végignézni az összes securable-t és permissiont, ojjektum, database és szerver szinten is.
• Az upgrade módjai és hatásai az upgrade-elt adatbázis működésére
• Az új audit cuccok
• Konfigurálható szerver jellemzőket tudni
• Árva userek kezelése (nem a régi 2000-es módon!)
• Jogosultságokhoz kapcsolódó nézetek, függvények. Erre most nagyon rámentek (lehet, hogy nekem meg a vizsgám :).
• Transzparens titkosítás titkai
• Profilozáshoz milyen jog kell? Mindenki tudja?
• Data Collector A…Z
• Új profiler eventek, de tényleg, eddig erre se mentek rá ennyire.
• Főbb dm_-ek, de ezeknek oszlop szinten tudni a jelentését!
• Resource Governor A…Z
• DTA
• FTE új működése
• SSAS security! Ez szerintem övön aluli volt, de lehet, hogy ez nem pontozzák, csak kíváncsiak, hogy az SQL-es csávók értenek-e a BI cuccokhoz? Nem. :)
• Database mail működése, architekturális szinten is
• Partíciók kezelése, split, merge, kapcsolódó nézetek, függvények.
• Tudni, hogy az XML és spatial indexek a PK-re épülnek
• Job logolási kérdések, hová logol, mikor törlődik, stb.
• SQL Server Agent szerepkörök
• Karbantartási munkálatok mirroros környezetben
• PBM, elég sok kérdés, nem túl nehezek, de a fogalmakat jól le kell tisztázni, szórakoznak vele
• P2P Repl.
• Titkosítási kulcsok kezelése failover clusteres környezetben
• Snapshot resore-os scenariók, ez elveszett, az elveszett, visszajön-e snapshotból. Ehhez tudni kell pontosan, hogyan működik a database snapshot
• Szokványos, nem nehéz backup kérdések

Elmondható, ha valaki ismeri a 2005-ös verziót, és felkészül a 2008 admin újdonságaiból, akkor ez nem lesz egy nehéz vizsga . A jogosultságok kérdések voltak kissé kínosak nekem, rászálltak a secura az sql servernél is, tessék jól megtanulni (én is meg fogom, de valljuk be, ezek k. unalmas dolgok, még, ha életbevágóan fontosak is.)

Habár nem értek az Analysis Serviceshez (még, az SSIS után ez a következő falat), de ez a cikk igen érdekes. Nem annyira az SQL-es, inkább az operendszeres vonatkozásai miatt.
Az átlagfelhasználó az új Windowsokból csak az új shellt tapasztalja meg, meg, hogy több ram kell nekik. Ennek ellenére a háttérben keményen fejlesztik a rendszer magját, csak az nem annyira látványos, még, ha igen hasznos is.
A cikkben arról beszélnek, hogy a Windows 2008-ban új memóriakezelő van, ami sokkal jobban kezeli a sok, apró memóriafoglalást. Ez azonnal látszik, ha az Analysis Services-szel dolgoztatunk fel jelentős mennyiségű adatot, a 2008-on kapásból dupla olyan gyors lett a feldolgozás (tudom, minden teszt csal, de nem hiszem, hogy nagyot hazudnának).
A szerviznek meg lehet mondani, hogy előre allokálja le a memóriát, így 2003-on is hasonló teljesítményt érhetünk el, mint 2008-on.

Az egészből számomra az az érdekes, hogy gyorsabb Windows 2008-ban a memóriakezelés, amiből bármilyen app profitálni fog. Megvettük. :)

Ezt már egy komplett focicsapat írja, de végül is elég nagy a téma.

Elég jó, nem sok minden van benne, de ami van, az jó.
Kár, hogy a szerző nem szereti az IDisposable-t.

Amúgy most már elég sokat foglalkoztam az SSIS-sel, és azt mondom, tetszik. Eddig távol tartottam tőle magam, lustaságból. Most viszont olvasgatom a Pro SQL Server 2005 Integration Services könyvet, közben kattogok néha, és tetszik, okos dolog ez az eszköz.

Hetek óta nincs SQL Serverem (jó, időm se volt), mert nem ment fel az RC0. Egyes komponensek nem mentek fel, pl. a database engine, ami azért hiányzott.
A probléma oka nyilvánvalóan az volt, hogy fenn volt előtte a februári CTP, ami odaganézott a merevlemezre ide-oda.
Ezért bőszen nekiálltam feszítővassal, lángvágóval, és kiszedtem az általam azonosított maradványokat a registryből, a fájlrendszerből, gacból. Erre ilyen hiba kezdett jönni:

2008-07-08 22:19:22 Slp: Microsoft.SqlServer.Setup.Chainer.Workflow.ActionExecutionException: MsiGetProductInfo failed to retrieve ProductVersion for package with Product Code = '{7D3F6746-94DE-4E1F-94F9-933B68EB68C4}'. Error code: 1605. ---> System.InvalidOperationException: MsiGetProductInfo failed to retrieve ProductVersion for package with Product Code = '{7D3F6746-94DE-4E1F-94F9-933B68EB68C4}'. Error code: 1605.
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Configuration.MsiExtension.SetFeatureInstallStateAction.FillInstallPropertyByProductCode(PackageInstallProperty pkg, String prodCode)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Configuration.MsiExtension.SetFeatureInstallStateAction.FillInstallProperty(PackageInstallProperty pkg)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Configuration.MsiExtension.SetFeatureInstallStateAction.ExecuteAction(String actionId)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Chainer.Infrastructure.Action.Execute(String actionId, TextWriter errorStream)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Setup.Chainer.Workflow.ActionInvocation.InvokeAction(WorkflowObject metabase, TextWriter statusStream)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Setup.Chainer.Workflow.PendingActions.InvokeActions(WorkflowObject metaDb, TextWriter loggingStream)

Google nem adott kézzelfogható eredményt.

Reflectorral megnéztem, mi történik ezekben a metódusokban?

private void FillInstallPropertyByProductCode(PackageInstallProperty pkg, string prodCode);
Declaring Type: Microsoft.SqlServer.Configuration.MsiExtension.SetFeatureInstallStateAction
Assembly: Microsoft.SqlServer.Configuration.MsiExtension, Version=10.0.0.0 

Ez a kód a gyanús benne:

errorCode = MsiNativeMethods.MsiGetProductInfo(pkg.ProductCode, "Language", lpValueBuf, ref capacity);
if (errorCode != 0)
 {
 throw new InvalidOperationException(SR.MsiGetProductInfoFailedToRetrieveProductVesrionByProductCode(pkg.ProductCode, errorCode));
}

Ismer valami ProductCode-ot, ennek akarja lekérni a verzióját, de nem sikerül, mert kézzel már leirtottam a darabjait.

Honnan veszi a beteg ProductCode-ot? CTRL-R, analyze. Itt hívják meg a fenti metódust:

private void FillInstallProperty(PackageInstallProperty pkg);

Ebben:

installedProductCodeList = this.msiMetadata.GetInstalledProductCodeList(packageAttributes);
if ((installedProductCodeList != null) && (installedProductCodeList.Count > 0))
{
 this.FillInstallPropertyByProductCode(pkg, installedProductCodeList[0]);
}

Szóval a GetInstalledProductCodeList adja vissza a rossz prod code-ot. Ő belül ezt hívja meg:

errorCode = MsiNativeMethods.MsiEnumRelatedProducts(packageUpgradeCode, 0, iProductIndex, lpProductBuf);

MsiEnumRelatedProducts, ez adja vissza a baromságot. Ez már natív függvény, az MSI.DLL-ben. Elő a debuggerrel! Nem, nem a VS-re lesz szükség, az kis gyík a nagytesóhoz, a WinDbg-hez képest, ehhez az kevés.

UINT MsiEnumRelatedProducts(
  __in   LPCTSTR lpUpgradeCode,
  __in   DWORD dwReserved,
  __in   DWORD iProductIndex,
  __out  LPTSTR lpProductBuf
);

WinDbg-vel töréspont beállít a fenti függvényre. A törésponthoz be lehet állítani akciót a WinDbg-ben, ebben kiíratom a függvény első és 4. paraméterét, az 1-re keres rá, a 4.-ben jön vissza a baromság.

bu msi!MsiEnumRelatedProductsW+0x64 "du poi(esp+0x4);du poi(esp+0x10);g"

Ez a breakpoint szintax. Breapoint Unresolved (szimbolikus, futás közben oldja fel), az msi.dll MsiEnumRelatedProductsW függvényére, de nem a belépési pontjára, hanem 64h offsettel hátrébb (ez a függvény ret utasítása, azért ez kell, mert itt már ki van töltve a 4. paraméter).
Az akció rész idézőjelek között van, ez fut le, ha becsap a töréspont. du: dump unicode data. A poi feloldja az ESP+4 címet, onnan írjuk ki a stringet. Ugye ESP a visszatérési címre mutat, ESP+4 az első paraméterre, ami egy LPCTSTR, esetünkben LPCWSTR, ezt oldja fel a poi, a du meg kííratja. A 10h címen van a 4. paraméter. A g parancs futtatja tovább a kódot, azaz a töréspont valójában csak kiírja a számomra szükséges infókat, és a program fut tovább.

{65A00972-4629-4343-AAF7-9C35CE25CD84} erre kérdeznek rá, és {7D3F6746-94DE-4E1F-94F9-933B68EB68C4} rá a válasz, pont, ami a hibaüzenetben is jött.

No, honnan a francból szedi fel a 65A00972… GUID-ot? Bármennyire is bosszantó, se a fájlrendszerben, se a registryben nem találtam meg azt a kódot. Fukk.

Elő a procmonnal. Ugye az a gond, hogy detektál valami darabkát egy korábbi verzióból, de az MSI-ket már nem leli hozzá. Beállítottam szűrési feltételt, hogy a setup100.exe process név és a Path tartalmazza az UpgradeCode stringet. Kiderült, hogy miután megtalálja ezt:
HKEY_CLASSES_ROOT\Installer\UpgradeCodes\27900A5692643434AA7FC953EC52DC48
leáll a telepítés. Ezek szerint ez valami korábbi SQL Server verzió darabja lehet. Átneveztem ezt kicsit, hogy ne találja meg a telepítő. Ettől továbbment a telepítő, de befagyott. Kiirtottam az összes keresett UpgradeCode-ot és voalá, sikeresen felment a szerver.

Finnyás egy kis köcsög lett ez a verzió. Jó, tudom, nem illik szétszabni kézzel a registry-t, de akkor is. :)

Mostanában éjszakánként SSIS-t tanulmányozok, íme egy érdekes teljesítményoptimalizálási bejegyzés a témában.

Letöltőoldal.

Kulcsok szintén ezen a lapon.

Direkt link az x86-os ISO verzióra.

X64

Valami Akamai Download Manager ActiveX Control Module is települ IE alá, amivel végre normálisan le lehet tölteni a cuccost, FF alatt egy Java Applet látja el ugyananezt a feladatot. Már csak egy CRC érték hiányzik, és el is értük a 20. sz. végét.

Az upsertes vizsgálódásunk utolsó része jön, ebben az új SQL Server 2008 MERGE parancsot használjuk:

create proc dbo.UpsertClient5
  @id int,
  @name nvarchar(100)
as
merge dbo.Client u
using (select * from (values (@id, @name)) t(id, name)) t
on u.id = t.id
when matched then update set u.name = t.name
when not matched then insert(id, name) values(t.id, t.name);

Elegáns, szép, és a harmadik megoldáshoz hasonlóan itt is jöhetne be több sor is, tábla típusú paraméterként. Nincs explicit tranzakciókezelés, mert belül a parancs eleve tranzakcionális, mint minden DML parancs.
Nem biztos, hogy ezzel meggyőztem bárkit is a mergeről, hisz ez csak egy apró alkalmazása, de érdemes mindig szem előtt tartani, hogy most már nem csak insert, update, delete van, hanem merge is.

Itt.

Most jön az a megoldás, amelyik mind között a leggyorsabb, de egyúttal a legkevésbé szép. :)

create proc dbo.UpsertClient4
  @id int,
  @name nvarchar(100)
as
begin try
    insert dbo.Client (id, name) values (@id, @name)
end try
begin catch
    if (error_number() = 2627)
        update dbo.Client set name = @name where id = @id
end catch

Nekiszaladunk az insertnek, ám ha a sor létezik már adott id-vel, akkor visszapattanunk, és jön az update. Csak a constraint violation (2627) esetén jön az update, egyébként újra raise-elni kellene a hibát, ez nincs benne a példában.

Habár normál adatbázisoknál ez a megoldás jóval gyorsabb az előzőeknél, a hibakezelést könnyű elrontani, ezért észnél kell lenni a használata során. De ha a sebesség az úr, ezt a megoldást érdemes választani.

Emlékeztetőül a megoldások futási ideje, a kevesebb a jobb:

procid      dur
----------- -----------
1           152
2           161
3           164
4           64  <---
5           186

Eléggé sok teher van most rajtam, ezért nem iparkodok az upsert cuccokkal, de igyekszek utolérni magam.

A harmadik megoldás már kicsit ravaszabb, SQL Server 2005-ös utasításokat is tartalmaz:

create proc dbo.UpsertClient3
  @id int,
  @name nvarchar(100)
as
set xact_abort on
begin transaction

update dbo.Client set name = @name where id = @id

insert dbo.Client (id, name)
select * from (values (@id, @name)) t(id, name)
except
select * from dbo.Client as t2 with (updlock, serializable)

commit
go

Az except és az intercept halmazműveletek jól jönnek, hogy az update és az insert csak a számára szükséges adatokat kapja meg. Az update-nél nem használtam, hisz ha egy sor nincs benne a táblában úgyse lehet meg update-elni. Az intercept-tel elő lehetett volna szűrni az adatokat, de minek?
Az insert esetén viszont már nem vagánykodhatunk, ki kell venni a bemeneti halmazból a már céltáblában bennlévő sorokat. (Most, hogy ezt írom eszembe jutott, hogy lehet, hogy ezt is ki lehet sprórolni, ha az IGNORE_DUP_KEY be van állítva a kulcs oszlopra. De valahogy rossz érzésem van ezzel kapcsolatban.)

A példa az előző kettővel ellentétben már nem csak 1 bementi sort képes lekezelni, hanem egy tetszőleges számú bementi halmazt is. Tábla típusú paraméterekkel kiválóan együttműködhet.
A megoldás sebessége kb. az előző kettő szintjén van, de ezt utóbbi többsor-lekezelési lehetőség miatt érdemes megfontolni.

Folytatásként mutatok egy második nekifutást az előző rész problémájára. Ebben elkerültem a felesleges if exists-et, amely miatt egyszerűbb lett az eljárás. Azt vártam egyébként, hogy gyorsabb is lesz, de nem, hisz most is kétszer futunk neki a táblának.

create proc dbo.UpsertClient2
  @id int,
  @name nvarchar(100)
as
set xact_abort on
begin transaction

update dbo.Client with (serializable) set name = @name where id = @id

if (@@rowcount = 0)
  insert dbo.Client (id, name) values (@id, @name)

commit

Az előző megoldáshoz képest itt nem kellett updlock hint, hisz az update elve azt használ az olvasási fázisban (másként a sima update-ek is állandóan deadlockolnának, pont ezért van külön update lock).
A serializable az előző részben részletezett okok miatt kell, azaz meg kell fogni az update-elendő kulcsot, ha létezik a sor, ha nem, hogy a következő insertnek “meg legyen ágyazva a hely”.