Soci (Soczó Zsolt) szakmai blogja

2015.10.24.

Befektetésről programozóknak 2.

Filed under: Élet,Tőzsde — Soczó Zsolt @ 13:04

Az előző részt ott hagytam abba, hogy _szerintem_ dolgozó átlagemberként a részvényindexekbe történő rendszeres befektetés sok éven keresztül alkalmazásával lehet egy élhető szintű nyugdíjalapot összerakni.

Ez a rész matekosabb lesz azért, hogy aki érteni akarja, mi történik a pénzével, az maga is utána tudjon számolni. Aki nem szereti az ilyet, annak a végén leírom a konklúziókat.

Az indexek csak számok, nem lehet pénzt tolni beléjük. Vannak viszont olyan termékek, amik szimulálják egy adott számított érték, pl. egy stock index működését, így ezeket proxyként lehet használni az indexhez. Pl. a már emlegetett S&P 500-as indexhez van egy SPY nevű Exchange Traded Fund, röviden ETF. A belső mechanikája számunka közömbös, ami fontos róla, hogy elég pontosan követi az S&P 500-as index értékét. Kívülről pont olyan mint egy részvény, azt mondod a broker GUI-n, hogy venni akarok 10 db SPY-t, és egy pillanat múlva már a tiéd is.
Itt az adatlapja. Ha veszek egy SPY-t, az olyan, mintha minden benne levő 500 részvényből vennék egy picit, mivel a háttérben tényleg nap mint nap utánahúzzák az ETF mögötti részvényállományt. Mivel a piac állandóan mozog, ezért az ETF értéke nem hajszálpontosan követi az index értékét, ezt hívják tracking differencenek. Ez egy költség a befektetőnek, ami spy esetén kb. évi 0.1%. Az előző cikk részletezi, milyen más összetevőkből is áll a költség. Mivel az indexbe nem lehet közvetlenül befektetni, tudomásom szerint ez a legkisebb költségű eszköz, amin keresztül egy átlagember be tud fektetni pl. az S&P 500-ba. Ellenpontként a Unit Linked biztosítások minimum évi 2%-ot visznek el.
Itt látható, hogy 1993 óta, mióta létezik az SPY évi 8.75%-os hozott. Tudom, ez nem olyan szép, mint a kínai vagy indiai alpok elképesztő számai, de nincs ingyen ebéd, ami hatalmas erővel emelkedik, az még nagyobb erővel esik is, amit a legtöbb ember nem bír gyomorral. Aki bátrabb, talál ETF-et bármely piachoz, óvatosan lehet azokba is tolni pénzt.
Vissza az SPY-ra, ha 93-ban befektettem bele, az most kb. 1.0875^(2015-1993)=6.88-szor annyit ér. Ha megnézzük az SPY historikus adatait (magyar beállításoknál importálni kell excelbe, mert amerikai szeparátorok vannak a csv-ben, illetve rendeztetni és érdemes, hogy a múlt felől haladjon a jövő felé), 1993.01.29. az első adatunk, itt a close price, azaz a nap végi záró ár 43.9375 volt. A táblázat végén 2015.10.23-án 207.52 a záró ár. Ez alapján 207.52/43.9375=4.72-szorosára ment fel az ETF ára. Miért nem 6.88? A különbség azért van, mert az ETF mögötti részvények osztalékot is adnak, amit az ETF (részben) odaad az ETF-be fektetőknek. Hoppá, a Unit Linked biztosítások odaadják az osztalékot? :)
Az osztalék készpénzként megérkezik a számládra, a yahoon erről is van adat. Idén pl.

Sep 18, 2015 1.033 Dividend
Jun 19, 2015 1.03 Dividend
Mar 20, 2015 0.931 Dividend

Ha az SPY értékét 200-nak vesszük, az 1 az 0,5% osztalékot jelent, azaz csak idén 1.5% jött be csak osztalékokból. Az osztalékot újra be kell fektetni, ezzel számolják ki az SPY adatlapján is a 8.75%-os éves hozamot. Kisebb pénzekkel ezt nem lehet megjátszani, mivel ETF-ből min. 1 egységet lehet venni, ami most pl. 207$, ha ennél kevesebb az osztalék, akkor nem fut ki 1 egységet se.
Azaz azt tehetjük, hogy a következő évi befektetés esetén kicsit kevesebb pénzt utalunk a befektetési számlára, vagy picit többet veszünk az ETF-ből.
Visszatérve, hogyan lehet a számítások során figyelembe venni az osztalékot? Ehhez már két adathalmaz kell, az egyik a részvény (ETF, akármi) árai, a másik az osztalékok időpontja és idejei. Mivel így már nem olyan egyszerű a számítás a következő trükköt követjük el.
Ha ma 100-on zártunk, és holnap 1% osztalékot adnak, akkor változatlan körülmények között holnap 99 lenne a nyitó ár, mivel az 1% osztalékot tükrözni fogja a termék ára. Ha nem tudunk az osztalékról, akkor azt hisszük, hogy 1 nap alatt vesztettünk 1%-ot az üzleten, közben nullszaldón vagyunk. Hogy ne kelljen tudni az osztalékokról az csinálják, hogy a tegnapi és az összes korábbi árat beszorozzák az osztalék által okozott “pénzkivonással”, ezt hívják adjusted close-nak, a yahoo adatsorban ez az utolsó oszlop. Jól látható, hogy 09.16-ig a close és az adj close azonos, előtte már nem. Az osztalék előtti adatokat ugyanis visszacsökkentik az osztalék arányában, azaz mesterségesen belerakják az osztalék okozta nyereségtöbbletet az árba azáltal, hogy a múltbeli árakat csökkentik.
Pl. a szeptember 18.-ai osztalék miatt (199.699997-1.033)/199.699997=0.994827241-gyel szorozzák be a múltbeli záró árakat. Az 1.033 az osztalék, a 199.699997 pedig az osztalék előtti napon a záróár.
És tényleg, ha megnézzük pl. a 15-ei sort, akkor a záróár 198.449997, az adjusted záró 197.423469, a kettő aránya 0.994827271, ami elég pontosan egybevág a saját számításunkkal. Eredetiben itt a módszertan.

Miért kellett ez a bonyolítás? Azért, mert így sima kamatos kamattal, azaz exponenciális függvényekkel tudunk hozamokat számolni. Visszatérve a korábbi példánkra, az SPY kezdetekor, 1993.01.29.-én a close 43.9375, az adjusted close 28.772289. Ennyire sokat számít az osztalékok miatti plusz profit!
207.52 a legutóbbi záró ár, 28.772289 az 1993-as adjusted close, azaz a pénzünk most 207.52/28.772289=7.21-szor többet ér. Az SPY adatlapján számoltak alapján 6.88 jött ki, a különbség a tört évek miatt van.
Az egész gyakorlat célja az volt, hogy bemutassam, a valódi hozamok számításához az adjusted close price-t kell használni.

Amikor rendszeresen befektetünk, akkor mindenféle árakon veszünk a kiválasztott papírból, ezért az eredő hozamhoz minden befektetési időponthoz pontosan ismernünk kell az adjusted close árakat. Erre láthatóan ott a yahoo, így már csak a költségeket kell ismernünk, hogy egész pontosan kiszámoljuk, hogyan alakult volna befektetésünk a múltban.
Mi értelme a múltbeli hozamokat számolni, ha egyszer azok semmiféle garanciát nem jelentenek a jövőre nézve? Azért fontos ez, mert így objektíven, számszerűen tudunk értékelni különböző befektetési lehetőségeket. Ha valami a múltban is leszedte a gatyánkat is az óriási költségekkel (Unit Linked biztosítás), akkor a jövőben se lesz jobb, minek másnak termeli pénzt, nem magunknak?
Lássuk tételesen a költségeket, amiket bele kell venni egy reális modellbe.
1. A termékbe épített költség. Alapoknál ez általában 2% körül szokott lenni. Ez a teljes összegből levesz évente 2%-ot, ezért ennek költsége igen jelentős, minél több pénzünk halmozódott már össze. Pl. 10m esetén 2% már 200e Ft! Sokféle más termékbe befektető alapoknál ez a költség teljesen követhetetlen, ezért is nem szeretem ezeket (pl. a bankok által forgalmazott alapok ilyenek, illetve a biztosítók alapjai is). Praktikusan ez azt jelenti, hogy van valami vagy valamik, amikbe befektetnek, de a kisbefektetőknek már nem az eredeti árfolyamot mutatják, hanem egy, a költségekkel csökkentettet. Mivel ráadásul általában más devizában vannak a befektetések még a Ft-adott deviza árfolyam is befolyásolja az eredő árat, így a tényleges kezelési költség kívülről kiszámíthatatlan. Kivéve, ha egy konkrét dologba fektetünk be. Pl. az előző részben említett Unit Linked biztosításban minden évben a Warren Buffet alapba raktuk a pénzt, ami zömében büfé úr BRK-B nevű részvényébe fektet be. (Megjegyzem, az ügynökduma arról szól, hogy büfé úr részvényét nem tudja megvenni az átlagember, mivel annak értéke 200000$. Igen, az a BRK-A, de a biztosító a BRK-B-be fektet be, aminek értéke kb. 100$. Hivatkozás a biztosító hivatalos tájékoztatójában. “… BERKSHIRE HATHAWAY (B sorozat) …”)
Lássunk, mit kapna az, aki venne BRK-B-t közvetlenül vs. mit mutat ebből a biztosító:
CIG Warren vs. BRK-B

Az számításokat a mellékelt CIG1.xls mutatja be., az adatok forrása a yahoo finance, az MNB és a CIG (benne vannak a forrásadatok is, bárki ellenőrizheti a számításokat).

Jól látható, hogy nyílik az olló a két árfolyam között, minél több idő telik el, annál nagyobb a gáz.
Ez emésszétek, aztán jön a többi költség a következő részben. Látni fogjátok, ha az ügyfél megkopasztásáról van szó, elképesztő fantáziájuk van. :(

2015.10.21.

Befektetésről programozóknak 1.

Filed under: Élet,Tőzsde — Soczó Zsolt @ 23:22

Pár napja utánanéztem egy 2008-ban feleségem részére kötött életbiztosításnak (álcázott befektetésnek), CIG Signumnak. Mivel tudtam, hogy milyen részvény van mögötte, és ismert az USD/HUF historikus árfolyama is, elég egyszerűen utána tudtam számolni, mennyi lenne a befektetés valódi értéke egy költségmentes befektetés esetén. 7*400e lett befizetve, a szerződés pillanatnyi értéke 5.6M Ft lenne, a biztosító szerint IS. A valódi értéke 3.5M, ha most 8 év után kilépnénk belőle 3.2M lenne.

Ezen durva költségek vettek rá arra, hogy kicsit írjak róla, milyen alternatívák vannak. A kiszámoló blog sokat írt erről, én is megpróbálok erről úgy írni, hogy informatikus társaim is megértsék.

Az alábbi gondolatok nem jelentenek pénzügyi tanácsadást, csak leírom a véleményem a témáról. Sok ponton nem fogok precízen fogalmazni, hogy ne legyen terjedelmes az írás. Az alap koncepciókat akarom csak megmutatni.

Unit linked biztosítás esetén 2008-ban és 2014-ben, illetve idén is igénybe lehetne venni a 20% max. 130e Ft-ot az SZJA-ból. Nekem a 3 gyerek miatt nem marad SZJA, így ez az opció nem él.
Ez a lehetőség ráadásul illékony, mint kormányunk minden törvénye. Mivel a biztosítók költségei még többet is felemésztenek mint ez az adó támogatás, én ezt a lehetőséget bújtatott pénzszivattyúnak tartom, amivel csak gazdagodnak a biztosítók és a közvetítő cégek (bnet és társai).

Emellett 10 év után szja mentesen lehet kivenni belőlük a pénzt, de erre van TBSZ is, szívatós kötöttségek nélkül.

Cégből nem kívánok biztosítást fizetni, a meglévő meg nem is az én nevemre szól, illetve 2018-tól 52% adó terheli. Bővebben a témáról itt.

Ma voltam a CIG irodájában, nem sikerült egy részletes számítást kapnom, pontosan milyen képletek alapján vonják le a költségeket. Benne van a szerződésben, de én a saját szememmel akarom látni a számokat, mivel magam lemodellezve nem tudtam kihozni azokat a költségeket, amit ők, de ami érdekes, hogy ha minden évben levonok 8.5%-ot a _teljes_ befektetett összegből, akkor pont kijön a számla végösszege.

Amíg nem küldenek egy tényleg részletes elszámolást, addig nem tudom összehasonlítani egy ilyen UL költségeit egy bróker számláéval. Ha megértem, leírom majd.

Számomra, aki fegyelmezetten képes a pénzügyeit kezelni, nincs szükségem a Unit Linked biztosítások zavaros és óriási költségeire, nem kérek külső kényszert, hogy befizessem az éves díjat.

Tehát, a következő az alapállás. Jól kereső informatikus vagy. Felelősséggel gondoskodni akarsz a jövődről, szeretnél valami nyugdíjalapot magadnak összerakni hajlott korodra. Megvan benned a szándék és a kitartás is, hogy külső ostor nélkül is évente egyszer vagy kétszer átutalj egy adag pénzt, amelyet befektetsz valahová. Ha ezek teljesülnek, akkor nézzük, az én fejemben milyen lehetőségeid vannak.

1. Mindenféle lenyúlós unit linked biztosítások: big no, ne másnak gyűjts pénzt, magadnak.

2. A bankodnál vásárolható alapokba fektetsz be.

3. Keresel egy kis költségű de stabil brókert (nem Kajmán szigeteki, meg ciprusi), és direktben fektetsz be.

Én nagyon utálom, ha egy befektetés költségei nem transzparensek, ebből a szempontból a 3. a legkövethetőbb költségű.

Mibe lehet befektetni átlagemberként? Bármibe, a részvényektől, állampapíroktól addig, hogy hány fok lesz decemberben, szinte bármibe. De mi az, ami hosszú távon valami értelmes hozamot képes összehozni (hozam >= 10%)? Részvények.
Részvény vásárlásával egy pici tulajrészt szerzel a cégben, ha a cég árfolyama felmegy, akkor a te részvényed értéke is felmegy, így ha később eladod, hozamot generál neked.
A részvényekkel azonban két baj van:
1. Az árfolyamuk veszettül tud fel-le menni, pár nap alatt tudnak akár 20-40%-ig pattogni. Ezt a legtöbb ember nem bírja idegekkel.
2. Cégek becsődölhetnek, így a részvényed értéke 0 Ft lesz.

Van ennél egy konzervatívabb és biztonságosabb lehetőség is: részvény indexek. Ez egyszerűen arról szól, hogy fogják egy adag részvény árfolyamát, és folyamatosan képeznek belőlük egy súlyozott átlagot. Pl. van a DOW 30, ez 30 nagyon nagy amerikai cég részvényeinek átlagára. Ilyenek vannak benne, mint Apple, Coca Cola, Nike, stb.
Itt a chartja.

Nem kell megijedni a kis zöld és piros gyertyáktól, egyszerűen kompakt módon mutatják meg az adatokat. Az előbbi charton 1 gyertya 1 hónapot fog át. Azaz fogják az adott hónap összes kereskedésének árfolyamát, és képeznek belőle egy Min, Max értéket, az a kis pálcika alja és teteje, illetve egy First és Last értéket, ez a gyertya törzsének alja és teteje. Ha zöld, akkor abban az időszakban felfele ment az ár, ha piros, lefele. Azaz 4 aggregált értéket ábrázolnak egy gyertyában, semmi mágia nincs benne.

Másik híres index az S&P 500, ez 500 nagy amerikai cég súlyozott átlagára. Így nézi ki.

Kb. olyan, mint a dow, csak ez nagyobbakat pattog, volatilisebb. Emiatt többet is tud hozni, a dow 6470-ről ment fel 18351-re, azaz 2.83-szor többet ér, mint a mélyponton 2009 márciusában. Az S&P500 666-ról (viccesek a traderek) ment fel 2134-re, 320%-os hozamot generálva annak, aki beszállt volna a mélyponton, és kiszállt volna a tetején. Ilyen ember persze nincs.

Ha egy index komponens cég bedöglik, akkor kidobják, és beraknak helyette másikat, így index esetén nem kell félni, hogy lemegy nullára. Vagy ha igen, akkor már úgyis vége az általunk ismert világnak.

Az indexek nem olyan volatilisek, mint az egyedi részvények, de ezért van itt is rendesen szívdobogtató esemény. Pl. aki 2007 októberében vett SP-t 1576-on, az 2009 márciusában kétségbeesetten látta, hogy a befektetése 666-on áll. Berakott mondjuk 1 millió forintot, és rá másfél évre az már leolvadt 422 ezerre. Aki ebben benne ül, az úgy érzi itt a világvége.

És ez itt az első probléma: ha valaki rendes hozamokat akar elérni (ahogy írtam 10% éves hozam már rendben van), annak fel kell készülni az ilyen időszakokra. Gyomor kell hozzá, vasfegyelem, önkontroll. Akiben ez nincs meg, az ne akarjon ilyen hozamokat maga elérni!

Minden befektető álma, hogy csak a pozitív dőlésszögű szakaszokban üljön benne, de amikor lefele megy az adott részvény vagy index, akkor meg pl. állampapírban vagy más, nagyon kis, de elég biztos pénzt hozó alapban tartsa a pénzét. Ezt hívják tudományosan portfolio reallocationnek.

A csapda az, hogy egy átlag befektető, aki valamilyen normál munkából él, pl. te IT-s kolléga, az NEM képes erre. Ne legyünk naivak, a nagy fundok iszonyatos okos emberi és nagy kapacitású számítógépes infrastruktúrával is csak nagyon kevesen képesek legyőzni a piacot, azaz pl. az S&P 500-nál konzisztensen, hosszú távon nagyobb hozamot elérni. Se te, de egy macsakajancsi megmondóember valamelyik brókercégtől vagy banktól, se egy előfizetéses guru NEM FOG HOSSZÚTÁVON PROFITÁBILIS TANÁCSOKAT ADNI! Az egyik részvényből kiugraszt -5%-on, beugrasz egy másikba, az felmegy 20-szal, hogy aztán rémülten kiszállj -30%-on, mert történt valami a világban, amitől csobbant egy nagyot.
A piacra ki-be szállogatni, a befektetést időzíteni trading. A trading az egy külön szakma, és nagyon nehéz. Ne ringasd magad abba a tévhitbe, hogy te konzisztensen, hosszútávon jó leszel benne a portfólió.hu-t meg más elemzéseit olvasva. A te dolgod pénzt keresni a szakmáddal, és azt a lehető legjobban megnövelni pár 10 év alatt, nem elcseszni a tőzsdén rossz tradekkel.
(Aki tudja rólam, hogy tradelek az ellentmondásosnak ítélheti meg, amit írtam, de én kb. 2 emberévet raktam bele az aktív, algoritmikus tradingbe, és még nem biztos, hogy hoz annyit, mintha eladtam volna magam konzulensként. De inspirál, ezért csinálom.)

Szóval szerintem kétféle módon lehet hatékonyan elégetni a kemény munkával megkeresett pénzt: nagy költségekkel (UL, bankok), vagy béna aktív tradinggel.

Mi maradt akkor? Szerintem amire egy átlag ember építhet, az az buy and hold, amibe rendszeresen rak pénzt. Azaz periodikusan veszel egy kicsit valamiből, ami hosszútávon felfele megy. Az indexek ilyenek. Lesznek benne szopó időszakok, mint 2008. De ha elhiszed, hogy az indexek állandóan felfele mennek, csak vannak benne huplik, akkor még örülsz is a hupliknak, hisz ott olcsóbban tudsz befektetni.

Itt van pl. az S&P 500 1950 óta.
Látszik, hogy felfele megy, de pl. aki 2000-ben a csúcson vett, az 2007-ban elkezdett örülni, hogy végre visszatért a befektetett árhoz az index, hogy aztán újra a szakadékba zuhanjon, és végül csak 2013 körül tudta meghaladni a 2000-es csúcsot. Ez 13 csapkodó év! Aki rövid, pár éves távra tervez, annak ez nem való, azért is kezdtem azzal, hogy azokhoz beszélek, akinek még van 20-25 éve a nyugdíjig.
Viszont aki minden évben befektetett, az vett 2008 és 2009-ben potom áron is részvényeket, az most nagyon örül, mert az a befektetett pénze most 3x annyit ér.

A következő részben számszerűen bemutatom, hogy mit jelent ez, mennyit tud hozni egy minden évben befektetett pénzt egy indexbe. Aztán megmutatom, mennyire arcul vágják ezt a szép folyamatot a költségek, hogy aztán senkit ne vágjanak át zsíros biztosításokkal. Végül bemutatom, ETF-eken keresztül hogyan lehet tényleg megvalósítani a felvázolt rendszeres befektetést.

Stay tuned. :)

Ps. nem kérek UL ügynök kommeneteket, teljesen felesleges győzködni a szokásos érvekkel.

2015.09.17.

SQL Server change tracking cikk

Filed under: Adatbázisok,SQL Server,SQL Server 2008,Szakmai élet — Soczó Zsolt @ 20:21

Annak idején írtam egy jó hosszú cikket a témában, hogyan lehet offline, disconnected appokat írni, amiben adatokat kell szinkronizálni. Valamiért már nem volt kinn a weben, ezért most kiraktam ide újra.

Olvassátok egészséggel.

2015.06.24.

2 karakter, és máris más az execution plan

Az eredeti lekérdezésben az ORDER BY így nézett ki: order by BDT.
Ez a számított oszlopra vonatkozott, azért a szervernek meg kellett oldania a rendezést egy külön lépésben. A b.BDT után viszont már tudja használni az alatta levő index rendezettségét, így nem kell rendeznie. 4x teljesítménynövekedést okozott ez a 2 karakter.

select
dateadd(second, @dtModifier, BDT) BDT,
cast(O as real) O, 
cast(H as real) H, 
cast(L as real) L,
cast(C as real) C,
V
from dbo.Bar b with (nolock)
where b.TickerID = @TickerID
and b.BDT >= @StartDate
and I = @I
order by b.BDT

2015.06.16.

Intra query deadlock

Ma láttam egy újfajta deadlockot, amiben az SQL Server által párhuzamosan végrehajtott lekérdezés szálai akadtak össze. Azaz ugyanaz a PID akadt össze magával.

Először arra gondoltam, lefogom 1 szálra a lekérdezést maxdoppal, de szerencsére nem volt jól optimalizálva, így jól fel lehetett gyorsítani. 240000 lapolvasásról 4-re. :) Így már magától soros lett a plan, volt deadlock, nincs deadlock.

Bob is írt már erről.

2015.05.22.

SQL ad-hoc gyöngyszem

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 13:47

Itt egy csodaszép szerver, amin az AD-HOC beállítás 6G RAM-ot spórolna.

PlanCacheTeleSzemettel

Előzmény.

Exam 70-459: https://www.microsoft.com/learning/en-in/exam-70-459.aspx done

Na, ez is megvan. :)

Ez is upgrade, két vizsgát tartalmazott, és ebben már volt 2014-es tartalom. Két témakört érintettek, az egyik az In-Memory DB (mi más?), a másik a delayed durability. Ja, és a clustered columnstore index is előjött egy kérdésben.

Szokás szerint volt pár nem jól definiált kérdés, ezeknél már kommenteztem, mert utálom, hogy ennyire nem nézetik át a kérdéseket.

Az in-memory-snál elég sokat elidőztem, mivel belementek, hogy milyen izolációs szintek vannak benne, és melyik alkalmas az adott feladatra, amit a scenarióban leírtak. A scenariók itt is km hosszúak, kicsit be is tojtam az elején, hogy nem lesz elég időm. De kiderült, hogy sok nem scenarió alapú kérdés is volt, azokat gyorsan meg lehet válaszolni.

Csak az inmemory-s rész a maga kb. 5 kérdésével elvitt vagy 20 percet, de a többi már emészthetőbb volt.

Idén már csak két tervem van, az MVC vizsga és a BI-os SQL rész. Az MVC-t valszeg letolom jövő héten még, amíg tart a second shot, ki tudja, hátha egyszer megbukom, nyugalmat ad, hogy nem dobok ki 75EUR-t az ablakon.

2015.05.21.

Szeméttel teli plan cache

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 19:17

Ha a plan cache tele van csak egyszer használt planekkel, akkor azok csak feleslegesen eszik a memóriát.
Az alábbi lekérdezés erre világít rá:

SELECT objtype AS [CacheType]
        , count_big(*) AS [Total Plans]
        , sum(cast(size_in_bytes as decimal(18,2)))/1024/1024 AS [Total MBs]
        , avg(cast(usecounts as bigint)) AS [Avg Use Count]
        , sum(cast((CASE WHEN usecounts = 1 THEN size_in_bytes ELSE 0 END) as decimal(18,2)))/1024/1024 AS [Total MBs – USE Count 1]
        , sum(CASE WHEN usecounts = 1 THEN 1 ELSE 0 END) AS [Total Plans – USE Count 1]
FROM sys.dm_exec_cached_plans
GROUP BY objtype
ORDER BY [Total MBs – USE Count 1] DESC

Megkérnélek benneteket, akik éles, nagy terheltségű SQL szervert üzemeltetnek, hogy futtassátok le a fenti parancsot, és küldjétek el az eredményt, kíváncsi vagyok, hol-milyen eredmények jönnek vissza.

2015.05.20.

SQL Server 2014 SP1 letölthető

Filed under: Adatbázisok,SQL Server,SQL Server 2014,Szakmai élet — Soczó Zsolt @ 19:39

Innen.

Itt a fixek listája. Átszaladva a listán a túlnyomó többsége fix, nem sok új dolog van benne. Érdekes, hogy az in memory db részhez nincs benne fix. Kevesen használják még…

2015.05.15.

SQL Server 2016 In-Memory OLTP

Filed under: Adatbázisok,SQL Server 2014,SQL Server 2016,Szakmai élet — Soczó Zsolt @ 18:19

Úgy tűnik 2016-ra felnő, 1.0-ssá az In-Memory OLTP az SQL Serverben. Gondolkodik valaki a bevezetésén (úgy értem 14-ben) ?

Exam 70-457 Transition Your MCTS on SQL Server 2008 to MCSA: SQL Server 2012 done :)

Ma volt egy szabad napom, gyorsan lenyomtam ezt is.

A vizsga a szokásos volt, 0,8-e normál, rendes kérdések, 20% nehezen megragadható marhaság. 50 kérdés volt, ezzel le van tudva a 70-461 és a 70-462. 700 ponttól lehet átmenni, nekem 833 volt a 461-es rész, 900 a 462-es. Látszik, hogy developer agyam van. :)

Ha jól emlékszem nem volt benne egyetlen 2014-es kérdés sem, ez számomra szomorú. Valójában én a 2014 vizsgákat akartam letenni, de nincsenek most ilyenek. Gondolom majd a 2016-osnál lesznek új vizsgák, nem akarják lejáratni két évente a certeket.

Ami érdekes volt, eléggé rámentek a Windowing Functionökre, erre érdemes mindenkinek gyúrni (egyébként is hasznosak). De csak a 2005-ös szinten kérdezték, nem mentek bele a 2012-es újdonságokba (framing), pedig itt vannak az igazi csemegék.

A következő lukas napon jön a 459, abban már tényleg várhatóak 2014-es kérdések, majd megírom, mire kíváncsiak.

2015.05.10.

Érdekes sorozat interval query-k optimalizálásáról

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 19:16

Messze nem olyan egyszerű az ügy, mint amilyennek elsőre látszik.

Unicode file bulk import

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 17:10

Leírom magamnak, hogy ne felejtsem el: unicode fájlok esetén az fmt format fáljban nem \t a tab szeparátor, hanem \t\0, a sor szeparátor pedig \r\0\n\0.

2015.05.08.

Task.Run Etiquette Examples: Don’t Use Task.Run in the Implementation

Filed under: .NET,.NET 4,.NET 4.5,ASP.NET,Szakmai élet — Soczó Zsolt @ 11:34

Az async – await dolgokkal fel lehet szabadítani pl. as ASP.NET által is használt ThreadPool szálakat, hogy míg egy hosszú ideig tartó nem CPU hanem IO intenzív folyamat fut, addig legyen szabad szál kiszolgálni a rendes, kicsi, gyors kéréseket.

De ha úgy aszinkronítunk egy blokkoló, IO intenzív kérést, hogy becsomagoljuk Task.Run-ba, akkor adtunk a sznak egy pofont, mert pont ugyanabból a ThreadPoolból vettünk el szálat, mint amit az ASP.NET is használ (feltételezve az alap TaskSchedulert használjuk). Ráadásul még context switch is lesz a szálak között, stb.

Az igazi aszinkron cuccosok (pl. .NET szerviz hívó osztályok és adatbázis kezelő osztályok) IO completion portot használnak, amivel sok blokkoló folyamatot tudnak monitorozni kevés szálon, nem minden egyes folyamathoz egy szálat használva, mint a Task.Run-os megoldás.

Bővebben a témáról itt.

2015.05.06.

Fragmentation from using snapshot isolation

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 19:08

Ez érdekes.

Visual Studio 2015 debugger

Filed under: .NET,Szakmai élet,Visual Studio,Visual Studio 2015 — Soczó Zsolt @ 14:31

Amellett, hogy nagyon frankón néz ki a kis chartokkal a tetején, amit kiemelnék, alul a watch ablak. Működnek a lambdák a watchban, lehet debug time linqzgatni! :)

VS2015Debugger

2015.05.05.

Új tanfolyam ötlet – Winternals

Filed under: Szakmai élet — Soczó Zsolt @ 18:17

Két új tanfolyamon töröm a fejem, kíváncsi vagyok, volna-e rá érdeklődés?

Az egyik egy Windows Internals jellegű tanfolyam. Annak idején le is vizsgáztam a témából, ideje lenne mindenkinek átadni a téma érdekes és hasznos részeit. A témák adottak, Russinovich-ék könyve az alap, ezt egészíteném ki developer specifikus dolgokkal, mint WinDB, SOS, mi látszik az egészből .NET-ből programozva, GC és Win mem kapcsolata, a sysinternalsos toolok mire valók, stb. Még nincs kialakult kép a fejemben a pontos tematikáról, ez még csak puhatolózás. Szóval, érdekelne valakit? Esetleg témajavaslat, mi az, ami miatt befizetnél egy ilyen tanfolyamra?

A másikról majd egy külön bejegyzésben írok.

2015.04.19.

MVC tanfolyam vége – Aurelia jön

Filed under: Szakmai élet — Soczó Zsolt @ 17:03

A héten MVC tanfolyamot tartottam Szegeden egy cégnek, és nagyon élveztem. Az utóbbi pár évben inkább desktop alkalmazásokkal dolgoztam, ezért marha sokat tanultam rá, gyúrtam az MVC forrását, stb. de jó érzés, hogy végre újra felszívtam magam webes tudásból is. Ahol még hiány van, az a javascript, látom, hogy erre még igen sokat kell gyúrni, mivel bármilyen fura is, ez a nyelv tűnik annak, ami mindenen futni fog. A java is ezt ígérte persze sok évvel ezelőtt, de most úgy nézni ki, a js közelebb fog kerülni ehhez.

A cimbik is javasolták, illetve az internetes infók alapján is az Aurelia lesz a következő, amit alaposan meg fogok tanulni.

2015.04.16.

Mire használja az MVC a machinekeyt?

Filed under: .NET,ASP.NET,mvc,Szakmai élet — Soczó Zsolt @ 22:51

A source alapján nekem úgy tűnik csak az AntiForgeryTokenhez. Van még szerintetek valami más szerepe is (nem webformsról beszélünk).

Tovább nézve látom az ASP.NET Identity is használja, a Tokeneket védeni.

2015.04.09.

Resharper most már C++-hoz is

Filed under: Szakmai élet — Soczó Zsolt @ 15:36

Kedvenc eszközöm most már megy C++-ra is. :)

« Older PostsNewer Posts »

Powered by WordPress