Soci blog

Előző héten két érdekes hibát láttam ügyfeleknél.
Az egyikben láttam, hogy a lekérdezés végrehajtási tervében konverzió van, datetime -> integer, emiatt scan volt seek helyett, azaz lassú volt a lekérdezés.
Ami fura volt ebben, hogy egy izeID oszlop volt összehasonlítva egy datetime értékkel. Az ID-k tipikusan intek, megnézve a táblát tényleg az volt. Volt egy lokális változó, ami copy-paszta miatt datetimera sikerült int helyett, és ezzel írták tovább a where szűrést. A lekérdezés már 2 éve ment élesben. :)
Ami érdekes volt benne, hogy funkcionálisan jól működött, a számok szépen konvertálódtak dátumokká és vissza, nem volt vele gond, csak lassú volt az egész. Bizarr hiba.

A másik esetben egy ilyen lekérdezés volt:

declare @a int
while valami
begin
  select @a = oszlop from tabla where ...
end

Furcsa volt, hogy a @a furcsa módon tartalmazott értéket akkor is, amikor nem érintett sort a select a where miatt.
Jobban belegondolva ez nem is fura, hisz a select NEM ad értéket a változónak, ha nem érint sort, és NEM is nullázza ki. Első iterációkor a @a null, hisz nem kapott értéket, a második iterációnál meg benne volt az első futás eredménye, ami már nem null volt, bár azt várták. Nem nagy hiba, de időrabló tud lenni.

Hirtelen egymás utáni napokon 3 cégnél égetett be az SQL Server 2005-től létező option(recompile), miután nem működik.

A hint célja az lenne, hogy a konkrét paraméterértékek ismeretében kérünk egy újrafordítást, így az optimizer ki tud dobni felesleges ágakat a lekérdezésből, ezzel nagyon hatékony terveket tud létrehozni egyes speciálisabb lekérdezésekhez.
Pl. gyakori, hogy a paraméterre csak akkor kell szűrni, ha nem null, ha null, jöjjön vissza minden sor:

… where @param is null or oszlop = @param

Ez alapban scan lenne, lassú. Az option(recompile) hatására azonban ha a @param null, akkor teljesen kiesik a sor, ha nem null, akkor meg leegyszerűsödik erre:

… where oszlop = @param

Ez meg már jó kis gyors seek lesz, megfelelő index esetén.

Mi itt a gond? Csak az, hogy ez sok verzión NEM működik. Pedig működött. :)

Az ok a következő. SQL 2005-ben még nem működött. 2008-ra megcsinálták, ment, csakhogy egy igen durva bugot is beleszereltek: ha többen hajtanak végre ilyen hintelt lekérdezést, akkor összekeveredhetnek az eredményhalmazok. Ez az innye, bazmeg típusú bug. Gyorsan ki ki kommenteltek pár sort, mivel megvarrni meg nem olyan egyszerű, mint elrontani. Így ez most nem megy az újabb SQL Servereken.
Erland barátunk szerint az R2 RTM NEM tartalmazza még a javított verziót (magyarul helyesen működik, nem nem gyorsít).
Viszont ez az R2 CU1 már javítja.
Ezen doksi szerint már 2008-hoz is van javítás, a CU5-ben.

Már csak le kéne cseréni a cégeknek a 2005-öt. :)

Ha egy SQLCLR eljárásból kell meghívni valamilyen külső komponenst.
A trükk az, hogy a külső assembly-t is be kell telepíteni az SQL serverbe CREATE ASSEMBLY-vel, mivel az csak onnan hajlandó betölteni assemblyket (pár fw. alap dllt kivéve).

SQL tanfolyamot tartok egy cégnél (.NET 4-et és Design Patternst meg egy másiknál :). Az oktatások arra jók, hogy mindig rájövök mit nem tudok, így aztán van módom újat tanulni. Azt meg általában szeretek. :)

Na szóval, ha a szerver oldalon történik egy exception valamilyen sql parancs végrehajtási hiba következtében, akkor ez szépen látszik a profilerben, csak az nem, mi váltotta ezt ki.
Most lapozgattam az Inside Microsoft SQL Server 2005: Query Tuning and Optimization könyvet, és ott belefutottam a megoldásba.
Nem csak az Errors And Warnings: Exception eseményt kell bekapcsolni, hanem a User Error Message-et is.
.
A képen látható, az EventSequenceből szépen összerakható az események egymásutánisága.
Ez megint egy olyan apró kérdés volt, amit 5 perc guglizás megold, de hát nem ilyenekkel van tele az ember feje?

Már el is felejtettem, hogy van ilyen. Öregszem. :)

Felírom magamnak, hasznos lehet.
http://www.sommarskog.se/share_data.html

Az alábbi kérdezték tőlem pár perce:

SELECT [text]  FROM [table1] WHERE [text] like '%rekes%'

A rekesz szót nem találja meg, ha magyar a collation az oszlopon. Ez természetes, a kettős betűket ezzel a logikával kezeli a szerver, azaz egy betűnek tekinti őket. A where-be kell egy collation cast, mondjuk latin1-re, amiben nincsenek kettős betűk. Mondjuk ezután nem fog indexet használni a szerver, de a kezdő % miatt eleve nem használva.
Az alábbi példában az egyikkel collationnel megtalálja, másikkal nem.

SELECT [text]  FROM [table1] WHERE [text] like '%rekes%'
--  collate Hungarian_CI_AS
collate Latin1_General_CI_AS

Lehet csinálni indexelt, számított oszlopot is más collationnel, és arra szűrni, az gyorsabb lesz.

Error: Incorrect syntax near valami.
Akkor jön elő, ha az SQLCLR assemblyt és benne a függvényeket akarja az VS deployolni. Több oka lehet, most az volt, hogy egy .NET oldalon double-t visszaadó függvény véletlenül így lett deklarálva:

[SqlFunction(..., TableDefinition = "Datum datetime, Szazalek double")]

Mi a hiba benne? SQL Serverben nincs double, csak real és float. Ráadásul a C# float az az SQL real és a C# double az SQL Server float (kb.). :)

Az előbbi helyesen:

[SqlFunction(..., TableDefinition = "Datum datetime, Szazalek float")]

Miért kellett SQLCLR függvényt írni? A futó aggregálások (én legalábbis nem tudok jobbat kurzor nélkül) o(n2)-es algoritmusok, ezt CLR-ben könnyen meg lehet írni o(n)-re. Pl:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;

public class UserDefinedFunctions
{
    internal class Result
    {
        public long RowId;
        public double CumDollarGain;
        public double TopDollarGain;
        public double DollarDrawDown;
    }

    //Input table: create table #trades(RowId long, DollarGain money, other columns possible)
    [SqlFunction(FillRowMethodName = "FillRow", DataAccess = DataAccessKind.Read,
        TableDefinition = "RowId bigint, CumDollarGain float, TopDollarGain float, DollarDrawDown float")]
    public static IEnumerable Cumul()
    {
        using (var conn = new SqlConnection("Context connection=true"))
        {
            using (var cmd = new SqlCommand("select RowID, DollarGain from #trades", conn))
            {
                var res = new List<Result>();
                conn.Open();
                double cumulPrice = 0, topPrice = 0, drawDawn = 0;

                using (SqlDataReader r = cmd.ExecuteReader())
                {
                    int idCol = r.GetOrdinal("RowID");
                    int gainCol = r.GetOrdinal("DollarGain");

                    while (r.Read())
                    {
                        var price = r.GetDouble(gainCol);

                        cumulPrice += price;
                        topPrice = Math.Max(price, topPrice);

                        drawDawn += price;
                        drawDawn = Math.Min(drawDawn, 0);

                        res.Add(new Result
                                    {
                                        RowId = r.GetInt64(idCol),
                                        CumDollarGain = cumulPrice,
                                        TopDollarGain = topPrice,
                                        DollarDrawDown = drawDawn
                                    });
                    }
                    return res;
                }
            }
        }
    }
    public static void FillRow(object obj,
    out long id,
    out double cumDollarGain,
    out double topDollarGain,
    out double dollarDrawDown)
    {
        var r = (Result)obj;
        id = r.RowId;
        cumDollarGain = r.CumDollarGain;
        topDollarGain = r.TopDollarGain;
        dollarDrawDown = r.DollarDrawDown;
    }
};

Sajnos nem lehet átpasszolni a megnyitott SqlDataReadert a két metódus között, ezért kénytelen az ember letárolni az eredményhalmazt. Persze pár ezer sornál ez nem gond.

Az SQL Serveren szokásos orderby newid() szerveroldali megoldást csak linq to SQL esetén tudjuk kihasználni, szerveroldali függvénnyel. Az EF-ben az ilyesmi nem megy:

... orderby Guid.NewID() ...

Ez az EF verzió még nem tudja lefordítani szerveroldali kifejezéssé az orderby kifejezését.
Viszont a random rendezést át lehet nyomni kliensoldalra, ha a lekérdezést “materializáluk” (AsEnumerable) előbb:

Random rnd = new Random();
(from s in ATSEntities.Instance.Symbol
select s).AsEnumerable().OrderBy(o => rnd.Next()));

Nem guidot használtam, hanem Randomot, az kisebb költségű, és az én célomra nem baj, ha csak pszeudo-random a sorrend.

Párhuzamos bulk betöltések esetén deadlockolhatnak egymással a másoló szálak, főleg, ha vannak FK-ek a táblákon.

Sokféle megoldás adható a problémára.
1. Átmeneti táblába töltünk, amin nincsenek indexek és fk-k.
2. Lekezeljük a deadlockot, és ismétlünk.
3. tablock-kal töltünk be, ezzel azonban súlyosan visszavethetjük a párhuzamosságot.
Ezt ki lehet kényszeríteni központilag is:
EXEC sp_tableoption ‘Tick’, ‘table lock on bulk load’, ‘1′

Nekem ez jó volt, mert nálam az adatforrás volt lassú 1 szálon, ezért kellett 40, az SQL betöltések sorosítva is elég gyorsak, és nincs deadlock.

A RS 2008-ban ez más, mint 2005-ben, itt leírják miért és hogyan.

Ha valakit tud tippet arra, hogyan lehet _saját_ _running_ aggregate-eket írni, az érdekelne. Nem sikerült megbízható módon megcsinálnom, működik, de nem mindig.

SQL magazinból.
Fenn van az SQL Magazine 2000-2004 között itt az msdnen, jó cikkek vannak benne.

A legtöbb riport item az RS-ben intuitív, na, ez nem az. Ezzel a chart fajtával nagyon jól lehet szemléltetni nagyszámú minta eloszlását, jól látszik pl. hol tömörödnek az értékek csoportokba (clusterekbe).

Nekem pl. intraday trade-ek elemzésére kiváló (példaként itt a rendszerem egyik riportja, a pötyösek a scatterek), mivel több mint ezer trade történik 2-3 évnyi adat tesztelése során, amelyek teljesítményét jól lehet vizualizálni a scatter chart segítségével valamely változó függvényében.

A chart beélesztésében ez segített.

Na, ezt nem ismertem, pedig már 10 éve nyüvöm az SQL Servert.

Az egyik MCP vizsgán céloztak arra, hogy ha egy adatbázis valamely filegroupját read only-vá tesszük, akkor nem fog lockokat rárakni a szerver, hisz minek, úgyse lesznek módosító folyamatok.

Nos, ez elméletileg így lehetne, de nem így van. Ha az egész adatbázis read only, akkor viszont tényleg nem lockol, ami adhat némi teljesítmény nyereséget.

Másra azért jó:

Read-only filegroups, They provide you the following three benefits:

1. Can be compressed (using NTFS compression)
2. During recovery you don’t need to apply logs to recover a read-only file group
3. Protection of data from accidental modifications

Erről elfelejtettem írni, online minden anyag, így a screencastok is - az én részem a Reporting Services volt.

Az utóbbi időben sokat használom a Reporting Servicest a kereskedő algoritmusaim teszteredményeinek megjelenítésére, és egyre jobban szeretem.

Az Entity Frameworköt is gyúrom, na erről már vegyesebb véleményem van, de egyelőre még korai lenne világgá kürtölni, ha már jobban kiismertem, majd írok róla.

Kicsit későn szólok, de ha valakit érdekel, még jelentkezhet, április 15-én lesz.
3×1 órában beszélek arról, hogyan lehet bevetni az SQL Serverek (2000-2008) okosságait egy új alkalmazásarchitektúra kidolgozása során. A cél nem annyira mélységi, mint szélességi bemutatása annak, mit lehet kihozni az SQL Serverből. Igyekszek olyan dolgokról is beszélni, amiről ritkán esik szó (pl. Query Notification, Service Broker), világnézet tágítás végett. Szeretném megmutatni, hogy az SQL Server nem egy egyszerű CRUD adatbázismotor, ahogy sajnos nagyon sokan használják.

Az egyik folyó munkámban profilerrel szerettünk volna szétnézni egy szerveren, hogy lássuk, kik a lassú lekérdezések. Eddig ez minden cégnél zökkenőmentesen ment, mondjuk egy min. 5000-es read filter mellett szépen jött a lista. Esetünkben azonban a profiler bekapcsolása után gyakorlatilag elérhetetlenné vált az sql server, de olyannyira, hogy még be se tudtunk rá lépni, újra kellett indítani. Először azzal ideologizáltuk meg a dolgot, hogy lassú volt a kapcsolat a profilert futtató gép és az sql server között, de ugyanígy lefagyott akkor is, ha egy azonos LAN-on levő gépről futott a kliens.
Esetünkben nem egy sima terhelési minta kellett, hanem kellettek az XML Planek is, gondolom ez feküdte meg a gyomrát, ezek előállítása.
Kevésbé megterhelő módja a valódi planek kinyerésének a management view-k használata. A következő lekérdezés visszaadja a hangoláshoz számomra fontos infókat:

SELECT top 500
OBJECT_NAME(st.objectid) object_name, 

SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE QS.statement_end_offset END
- QS.statement_start_offset)/2) + 1) statement_text,

qs.last_execution_time,
qs.execution_count, 

qs.total_worker_time,
qs.total_worker_time / qs.execution_count agv_worker_time,
qs.last_worker_time,

qs.total_logical_reads,
qs.total_logical_reads / qs.execution_count avg_logical_reads,
qs.last_logical_reads,
qp.query_plan as query_plan_text,
xp.query_plan
--into tempdb.dbo.Plans
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(sql_handle) as st
CROSS APPLY sys.dm_exec_text_query_plan(qs.plan_handle,
qs.statement_start_offset, qs.statement_end_offset) AS qp
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) xp
order by total_worker_time desc

Az utolsó oszlop az xml plan, csak rá kell kattintani, és máris látszik grafikusan a terv. Szenzációsan kényelmes.

Az extended event-ökre épülő dolog, ez, amelyet problémák esetén érdemes megnézni a szokásos logok mellett:

SELECT CAST (xest.target_data AS XML)
FROM sys.dm_xe_session_targets xest
JOIN sys.dm_xe_sessions xes ON
xes.address = xest.event_session_address
WHERE xes.name = 'system_health';

A háttérben fut egy extended event session, ami a gázosabb helyzetekben logol. Igaz, csak korlátozott méretekben és memóriában, de lehet benne hasznos infó.
Ezekről van benne infó:
* The sql_text and session_id for any sessions that encounter an error with severity >=20
* the sql_text and session_id for any sessions that encounter a “memory” type of error such as 17803, 701, etc (we added this because not all memory errors are severity >=20)
* A record of any “non-yielding” problems (you have sometimes seen these in the ERRORLOG as Msg 17883)
* Any deadlocks that are detected
* The callstack, sql_text, and session_id for any sessions who have waited on latches (or other interesting resources) for > 15 seconds
* The callstack, sql_text, and session_id for any sessions who have waited on locks for > 30 seconds
* The callstack, sql_text, and session_id for any session that have waited for an extended period of time for “external” waits or “pre-emptive waits”.

Jó tudni még, hogy az sql log könyvtárában vannak trc fájlok is, amelyek meg a már 2005 óta létező, háttérben futó default trace nyomait rögzíti. Ebben is lehetnek értékes morzsák hibakereséshez.

Yes, we do recommend to turn on Lock pages in memory so that OS doesn’t page SQL Server out. On 64 bit you only need to grant the right “Lock Pages in Memory” to the SQL account for SQL Server to utilize this feature.

Kapcsolódik még.

Ha ez a hiba előjön főleg nézzetek utána:
“A significant part of sql server process memory has been paged out. This may result in performance degradation”

De már megyek is vissza a munkához, mert igencsak beindult az élet, egyszerre 6 cég számára futnak munkáim, és most adok ajánlatot a jövő héten egy újabb, várhatóan elég nagy volumenű feladatra. Igaza van Marcellnak, válság más cégnél van, nálunk miért lenne? Ezzel nem akarom nagyképűen lebecsülni sok ember nagyon is valós gondját kölcsönproblémák és egyáltalán a megélhetés miatt, csak azt akarom megerősíteni, hogy attól, hogy a gazdasági folyamatok nem a helyükön vannak, attól még megy az élet, folyik az építkezés sok helyen. Van egy ismerősöm, aki kereskedelemből él, és mondta, hogy a ő cégére is igen nehéz idők járnak, nem tudja, nyáron is létezni fog-e még a cége.
Nehéz kikapcsolni a sok negatív hangot, ami az utóbbi hónapokban a csapból is folyik, nem tesz jót az ember motivációjának. De jön a tavaszi szél, remélem ez sok mindenben új vizet áraszt. Az amerikai tőzsde már mocorog (de még messze nincs vége a medveszezonnak), akkor talán 1 év múlva már nálunk is fog. És utána talán a magyar gazdaság is megindul.