Msg 11305

Execute a query on SQL Server 2008 such as this:

1. SELECT COUNT (ItemID) OVER (ORDER BY OrderID) FROM OrderDetails;

You get the following error message:

Msg 11305, Level 15, State 10, Line 1
The Parallel Data Warehouse (PDW) features are not enabled.

Really? Thank you for telling me but what can I do now?

OK, the reason of failure is simple. ORDER BY in OVER clause on an aggregate function works only in version 2012. But this message doesn't help much in debugging.

Hány bit egy byte?

Két napja kérdezték tőlem, hogy egy bit típusú oszlop mennyivel növeli meg egy sor méretét? Kis gondolkodás után azt válaszoltam, hogy egy byte-tal. És kettő? Két byte-tal - válaszoltam gyanútlanul, és már bele is sétáltam a csapdába.

Az SQL Server ugyanis trükkösen tárolja a bit típusú adatokat. Nyolc bit egy byte, ennek megfelelően nyolc bit típusú oszlop fér el egyetlen byte-on. Ha az oszlopok száma 1 és 8 között van, akkor 1 byte-ot foglalnak, ha 9 és 16 között, akkor 2 byte-ot, és így tovább.

T-SQL lottószám generátor

Komolytalan, szombat esti móka, de legalább jó példa arra, hogy a RAND() függvénnyel hogyan kaphatunk vissza 1 és 90 közti egész számot.

1. DECLARE @i tinyint;  
2. DECLARE @t as table (nNumber tinyint);  
3.   
4. WHILE (SELECT COUNT(*) FROM @t) < 5  
5.     BEGIN  
6.         SET @i = ROUND (((90-1) * RAND()) +1, 0)  
7.         IF NOT EXISTS (SELECT nNumber FROM @t WHERE nNumber = @i)  
8.             BEGIN  
9.                 INSERT INTO @t (nNumber) VALUES (@i)  
10.             END  
11.     END;  
12.       
13. SELECT nNumber FROM @t ORDER BY nNumber;

Akinek ezzel a kóddal sikerül elvinnie az ötöst, az ne feledkezzen meg rólam! ;)

ISNULL vagy COALESCE

Két napja bukkantam egy érdekes cikkre az MSSQLTips-en, Aaron Bertrand-tól, amiben az ISNULL és a COALESCE viselkedését hasonlítja össze. Talán nem egy millió forintos kérdés, de hibakeresésnél, vagy milliszekundumokra kihegyezett lekérdezéseknél jól jöhet, érdemes elolvasni.

Akinek nincs ennyi ideje, vagy csak lusta :), azoknak hajtás utánra kanyarítottam egy összefoglalót.

Láthatatlan szóközök

Ma hajnalban a cég egyik adatkockája a betöltésnél elhasalt. A hibaüzenet pontosan megadta, melyik package, melyik lookup transzformációja a hibás. BIDS-ben futtatva szépen reprodukálható volt a hiba, bizonyos értékeket nem talált meg a referencia táblában. Nosza, a "no match" kimeneten elkaptam néhány rekordot, a hiányzó értékeket pedig SQL-ből ellenőriztem a referencia táblában... És ott voltak. Nahát. Ráadásul úgy nézett ki a dolog, mintha ugyanahhoz a kulcshoz hol találna párt, hol nem.

Nos, egy jó adag kínlódás - és sok guglizás -  után lehullt a lepel: a T-SQL nem törődik a karakteres mezők végén található szóközökkel, az SSIS lookup viszont igen (legalábbis Full Cache esetén). Az igazán gonosz dolog az, hogy gondoltam is erre, és a LEN() függvénnyel ellenőriztem is az értékeket, csakhogy a LEN() szintén nem számolja ezeket a szóközeket.

1. SELECT LEN('WHITESPACE'), LEN('WHITESPACE ')  

Az eredmény 10 és 10, a LEN() az utolsó szóközt nem látja. Viszont a DATALENGTH() már igen:

1. SELECT DATALENGTH('WHITESPACE'), DATALENGTH('WHITESPACE ')  

Itt már 10 és 11 a függvény értéke.

Ilyen esetekben megoldás lehet, ha SSIS-ben a TRIM() függvényt, SQL oldalon pedig az RTRIM()-et használjuk, vagy ha a lookup transzformációnál nem a Full Cache-t állítjuk be.

Jegyezzük meg: az SSIS lookup nem csak a kis- és nagybetűkre érzékeny, de a sorvégi szóközökre is!

SSIS csomagok listája 2.

Első posztomban írtam arról, hogyan kérdezhetjük le az SSIS csomagok listáját PowerShell-el SQL Server 2008 alatt. Az új, 2012-es kiadásban azonban egy teljesen új módszert és környezetet kapunk csomagjaink telepítéséhez és kezeléséhez. (Ezzel párhuzamosan – a korábbi SQL Server-ekkel való kompatibilitás miatt – a korábbi struktúra is megmarad egyelőre.)

Ha a csomagok listájára van szükségünk, az SQL Server 2012 (RC0)-ban az SSISDB-ben (T-SQL) vagy a Microsoft.SqlServer.Management.IntegrationServices névtérben (.Net, PowerShell) kell kutakodnunk. A T-SQL megoldás nagyjából így néz ki:

1. use SSISDB  
2. go  
3.   
4. select  
5.     pack.name as [PackageName]  
6.     ,pack.[description] as [Description]  
7.     ,fold.name as [Folder Name]  
8.     ,proj.name as [Project Name]  
9.     ,fold.created_by_name as [OwnerName]  
10.     ,proj.created_time as [Project Created Time] 
11.     ,proj.last_deployed_time as [Project Last Deployed Time]  
12.     ,cast (pack.version_major as varchar(10))
13.      + '.' + cast (pack.version_minor as varchar(10))  
14.      + '.' + cast (pack.version_build as varchar(10))  
15.      as [Version]  
16.     ,pack.version_comments  
17.     ,proj.object_version_lsn as [Project Version]  
18. from  
19.     catalog.packages pack  
20.     inner join catalog.projects proj on pack.project_id = proj.project_id  
21.     inner join catalog.folders fold on proj.folder_id = fold.folder_id;  

Érdemes azonban alaposabban végigbogarászni az SSISDB-t, mert olyan információkra bukkanhatunk, amikről korábban nem is álmodtunk (pl. catalog.executions).

PowerShell-el közelítve a dologhoz, hasonló listát kaphatunk, ha végigzongorázzuk a Catalogs.Folders.Projects.Packages matrjoskát:

1. Add-type -path "C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.Management.IntegrationServices\11.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.Management.IntegrationServices.dll";  
2.   
3. $ssis = New-Object Microsoft.SqlServer.Management.IntegrationServices.IntegrationServices;  
4. $constr = "Data Source=localhost;Initial Catalog=master;Integrated Security=SSPI;"                          
5.   
6. $con = New-Object System.Data.SqlClient.SqlConnection $constr  
7. $ssis.Connection = $con;  
8.   
9. # Well, we can use here a foreach in the catalogs, but currently only the SSISDB catalog supported.  
10. $folders = $ssis.Catalogs["SSISDB"].Folders;  
11.   
12. $regex = [regex]"(?i)[0-9]"  
13.   
14. foreach ($folder in $folders)  
15.     {      
16.     foreach ($project in $folder.Projects)  
17.         {          
18.         $project.Packages | ft name, `  
19.             @{name="Folder name"; expression={$folder.name}}, `  
20.             @{name="Project name"; expression={$project.name}}, `  
21.             @{name="Actual Version"; expression={$project.objectversionLsn}; align="center"}, `  
22.             @{name="All Version"; expression={$regex.matches($project.versions)}; align="center"}, `  
23.             @{name="Last Deployed Time"; expression={$project.LastDeployedTime.LocalDateTime}; align="center"} `  
24.             -autosize -wrap | out-string | sort -property name;  
25.         }        
26.     };  

Persze, az új struktúra előnyei nem a csomagok listázásánál csúcsosodnak ki. Az SSIS 2012 (RC0) egyik remek újdonsága például, hogy a már telepített project verziók között szabadon válthatunk (feltéve, hogy az SSISDB katalógus Periodically Remove Old Versions tulajdonsága False, mert ellenkező esetben a Maximum Number of Versions per Project-nél régebbi verzióinkat az SQL Server szanálja).

Erre – természetesen – nem csak a GUI-n keresztül van lehetőségünk. Az SSISDB tárolt eljárásai közt ott lapul a catalog.restore_project,

1. exec catalog.restore_project 'Sample Folder', 'Sample Project', 5;  

az IntegrationServices assembly-ben pedig az Restore() metódus.

1. $ssis.Catalogs["SSISDB"].Folders["Version Rollback Sample"].Projects["Sample Project 3"].Versions[5].Restore();  

(Az $ssis változóból sejthető, de azért tisztázzuk: ez akkor működik, ha az adott session-ben már betöltöttük az assembly-t és csatlakoztunk a szerverhez (ő lenne az $ssis)).