Archive for August, 2012

SQL Server mirroring monitorozása

Thursday, August 30th, 2012

Ha a mirroringgal gond van, arról fontos azonnal tudni. Két esetet szoktunk figyelni. Az egyik a state change, azaz ha valamiért átvándorol a kiszolgálás az egyik lábról a másikra, illetve, ha feltorlódnak a tranzakciók valamelyik oldalon.

A monitorozásra vannak beépített dolgok, ezekről itt lehet bővebben olvasni, itt szinte minden infó megvan az alertezés felépítéséhez.
Két problémás pontba akadtunk bele. Az előbbi cikkben a WMI események hatására csak számok jöttek vissza státuszként, ezek nem túl beszédesek egy emailben. Ezeket elég könnyű visszafejteni stringekké:

declare @msg nvarchar(4000) = 'State of $(ESCAPE_SQUOTE(WMI(DatabaseName))) database changed to ''';
declare @state nvarchar(50) = '$(ESCAPE_SQUOTE(WMI(State)))';
declare @newStateString nvarchar(100) =
case @state
when '2' then 'Synchronized Principal without Witness'
when '7' then 'Manual Failover'
...
end;

set @msg += @newStateString + ''' on $(ESCAPE_SQUOTE(WMI(StartTime)))';

EXEC msdb..sp_send_dbmail @profile_name='SQL Server 2008 Mirroring Notifications',
@recipients='foo@bar.com',
@subject= 'DB Mirroring Alert',
@body=@msg;

Lehetne elegánsabban is lookup táblával, de a célnak ez megfelelt.

A másik kérdés macarásabb. Egy job percenként mintavételezi a mirror queue-jainak a mértét, és ezeket beírja egy rendszertáblába. Ha valamelyik túlmegy egy megadott határértéken, akkor ez beírja az event logba, onnan egy alert ki tudja olvasni, és emailt küldeni róla. Csak éppen a lényeg nincs ebben benne, melyik adatbázissal van a baj. Ez bug, ez van.
Hogy valami képünk mégis legyen már email alapján mi a gond, az alábbi jobot futtatjuk le a threshold alert alapján:

EXEC msdb..sp_send_dbmail @profile_name='SQL Server 2008 Mirroring Notifications',
@recipients='foo@bar.com',
@subject= 'DB Mirroring Alert',
@execute_query_database = 'msdb',
@query = '
select * from (select distinct(database_id) id from dbo.dbm_monitor_data) d
cross apply
(select top 5 cast(DB_NAME(database_id) as nvarchar(20)) db, local_time, redo_queue_size, send_queue_size
from dbo.dbm_monitor_data
where ((send_queue_size > 0 or redo_queue_size > 0) and local_time > GETDATE() - 3  and database_id = d.id)) t
order by db, local_time desc'

Ez az utóbbi 3 nap torlódásait küldi el emailben, ebből már látszik, melyik db akadt el.

400 Bad Request – Request header too long

Tuesday, August 28th, 2012

Reporting Services elérése közben jött a hiba, de IIS alatt is ugyanez lett volna a gond. A hiba oka, hogy a http.sys alapban 16kban korlátozza a http request hossszát, egy AD user access tokenje viszont nagyobb lehet ennél. Mivel a Kerberos auth (majdnem minden auth) a http headerben tolja át az auth infót, ha egy user nagyon sok csoportnak tagja az auth header nagyon nagy lehet. Esetünkben akinél jól ment 7k volt az össz kérés hossz, a beteg usernél 26 (Fiddlerrel néztük meg). Ez több mint 16, így természetes, hogy a http.sys kivágta.
A megoldás a limitek felemelése volt (MaxFieldLength és MaxRequestBytes registry értékek).
Bővebben az okról és a beállításokról itt. A beállítás a http stackre vonatkozik, user módú fogyasztótól (IIS, SQL Server, stb.) függetlenül.
Még egy dolog. A 2. cikk szerint újra kell indítani a http valamit. Ez látszólag szerviz, de nem az, hanem device driver. Mint ismert, 2003-tól és XP SP2-től a http.sys kernel módú driver fogadja a http kéréseket, ehhez írtak device drivert, mivel NT alatt így lehet kernel módban futtatni valamit. A service-ek között tehát nem látszik, hanem a Device Mangerben a Non Plug and Play kategória alatt lesz. Csak akkor hajlandó leállni, ha semmilyen user módú processz nem épít rá. Az összes http kiszolgáló erre épít, így az IIS és a Reporting Services is (meg az SQL Server http endpointjai, stb.). Esetünkben nem akart leállni, de a Reporting Services leállítása után azonnal leállt. Megúsztunk egy gép restartot, ami fájt volna, mivel ezen volt az SQL Server is.

Optional parameter zűrzavar

Monday, August 27th, 2012

Érdekes, hogy egy ártatlannak tűnő kis bővítésnek, mint a C# 4-ben bejött default paramétereknek milyen furcsaságai jönnek elő, ha beleütközik a polimorfizmusba.

Mellesleg, gondolom az mindenkinek tiszta, hogy a default paraméterek hasonló verziózási problémákat okoznak, mint az enumok: a hívó oldalba beég a konkrét érték, így a hívott library újrafordítása NINCS hatással a hívó által átadott értékre. Még nem láttam emiatt szívást, de jó észben tartani.

Mohó bankok

Thursday, August 2nd, 2012

Nyilvánvaló, hogy a bankok a pénzügyileg képzetlen tömegekből élnek. Hitelkártya-használat és más példák helyett álljon itt egy pénzváltási példa.
El akarok menni nyaralni Horvátországba. Venni akarok pl. 1000 eurót és 5000 kunát.
Ha ezt pl. a CIB-nél teszem meg (itt van számlám azért ezzel példálózok), akkor ezért adnom kell:
292.33 * 1000 + 41.24 * 5000 = 292,330 + 207,100 = 498,530 Ft-ot.

Egy pénzváltóban:
282.8 * 1000 + 38.35 * 5000 = 282,800 + 191,750 = 474,550 Ft.

A különbség 24e Ft! Ez 5%. Ennyiből kijön két ebéd a családnak, vagy az üzemanyag zöme. Vagy a bank következő negyedévi profitja. Lehet választani.

A cikk nem a CIB-et vagy a linkelt pénzváltót reklámozza, csak a spead (Bid-Ask különbség, azaz az eladási és a vételi ár távolság) fontosságára akarom felhívni a figyelmet.

Spreadek:
CIB: 292.33 – 269.85 = 22.48.
CorrectChange: 282.8 – 281.05 = 1.75.
A spreadek hányadosa: 12.84. Szerintem ez igen durva.

Annál a brókernél ahol tradelek, az Interative Brokersnél egyébként a spread 0.2-0.3 Ft, de ez persze nem papírpénz. Ez még a correctnek is a töredéke.

Persze, lehet azt mondani, bankban nem váltunk, kártyát használunk. Hisz a kártya használata ingyenes. Tényleg? “There is no such thing as a free lunch”. Ez olyan mint az energiamegmaradás a fizikában.
“If You Can’t See the Sucker, You’re It”. Szóval ingyen használjuk a kártyát. Ha fizetek vele Horvátországban, akkor először a kártyaszolgáltató átváltja a pénzt kunáról euróra vagy dollárra, társaságtól függően. Utána a bank ezt továbbváltja forintra. Utóbbit persze el lehet kerülni, ha van megfelelő deviza számlád.
Azaz ebben az esetben két spreadet kell kifizetni. Mondhatnánk, a deviza spreadek kisebbek, elvégre nem kell bankjegyeket kezelni, virtuális az egész ügyet. Lássuk csak:
CIB: 286.71 – 275.47 = 11.24. Pont a fele a valutának, de még így is sok, és a kártya cég spreadjét nem tudjuk, de látható, hogy a correct még valutában is sokszorosan olcsóbb, mint kártyázni.
Szóval leszarom a kártyát, és viszek kpt. Benéztem valamit? Még vissza tudom váltani, kicsi a spread. :)
Egy helyen viszont biztos kártyázok, a horvát autópálya fizetésnél. Francnak van kedve sorban állni. Az idő is pénz.