Szerdán SQL-es developer meetup

Ezen a héten szerdán ötödik állomásához érkezik a LogMeIn és a Microsoft Magyarország közös szervezésében készülő Enterprise Developer Meetup sorozat. Erre az alkalomra csupa adatbázisos témával készülünk, lesz szó teljesítményről, biztonságról és természetesen a felhőről is. Várunk mindenkit, akit érdekelnek a Microsoft adatbázis platformjának újdonságai, akár távolabbról architektúra szintjén, akár közelebbről, kód szinten.

Az első előadónk Kalen Delaney, aki 26 éve foglalkozik az SQL Serverrel, így nem véletlen, hogy az ő nevéhez kötődik szinte az összes “inside” és “internals” könyv a témában. Kalen kifejezetten a LogMeIn meghívására érkezik hazánkba, és szerdán az SQL Server 2014-ben bevezetett, korábban “Hekaton” kódnéven futó SQL Server In-Memory OLTP-ről fog beszélni. A Hekaton lényege, hogy az adatbázis motort az adatok memóriában történő tárolására optimalizálták, amivel természetesen jelentős teljesítmény növekedést lehet elérni.

 

Második előadónkat, Kószó Károlyt a magyar SQL fejlesztőknek nem kell bemutatni, hiszen 1996 és 2013 között a Microsoft Magyarország munkatársaként számos rendezvényen adott elő az SQL Serverről. Szerdán az SQL Server jogosultságkezeléséről fog beszélni, kitérve olyan kevésbé ismert témákra is, mint a tulajdonosi lánc és az aláírt tárolt eljárások. Érdemes elmélyednünk a témában, hiszen a legféltettebb adataink biztonságáról van szó!

 

 

 

Harmadik előadónk, Dudás Viktor, korábban már szerepelt nálunk, akkor az Azure Machine Learningről és gépi tanulásról beszélt. He is back! Ezúttal a Tabular Analysis Servert veszi górcső alá, természetesen a felhőben.

 

 

 

 

A társaság jó, a részvétel ingyenes, a szervezés érdekében csak annyit kérünk, nyomjatok egy RSVP: Yes-t előre.

Bővebb információ és jelentkezés itt:
http://www.meetup.com/Enterprise-Developer-Meetup/events/221592899/

Szeretettel várunk mindenkit szerdán 19 órakor a LogMeInben (Paulay Ede u. 12.)!

 

Technorati-címkék: esemény,event,SQL

Exception calling "SqlBackup" with "1" argument(s)

Az egyik szerverünkön az alábbi PowerShell script végzi az SQL Server adatbázisok mentését:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SMO") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SmoExtended") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.ConnectionInfo") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SmoEnum") | Out-Null

$server = New-Object ("Microsoft.SqlServer.Management.Smo.Server") $dbInstance
$backup = New-Object ("Microsoft.SqlServer.Management.Smo.Backup")
$backup.Action = "Database"
$backup.BackupSetDescription = "Full backup of " + $dbName
$backup.BackupSetName = $dbName + " backup"
$backup.Database = $dbName
$backup.MediaDescription = "Disk"
$backup.Devices.AddDevice("$localSqlBackupPath", "File")
$backup.SqlBackup($server)

Ez a kód most már évek óta működik rendesen, szépen készülnek a backupok naponta. Ám az utóbbi időben érdekesen kezdett viselkedni a szkript: egyes adatbázisokat mindig lementett, másokat pedig – amikkel korábban nem volt gond – többnyire nem. A naplóba az alábbi hibaüzenet került:

Exception calling "SqlBackup" with "1" argument(s): 
"Backup failed for Server 'MyServer\MySqlInstance'. "
At D:\Backups\BackupSite.ps1:151 char:22
+     $backup.SqlBackup <<<< ($server)
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

Nehezen derült ki, hogy a hibának semmi köze a függvény meghívásának módjához, hanem a problémát az okozza, hogy megnőtt az adatbázis, és az SqlBackup függvény 10 perc után timeoutolódik. A ServerConnection objektum StatementTimeout tulajdonságával lehet kikapcsolni az időtúllépés figyelését:

$server.ConnectionContext.StatementTimeout = 0

 

Technorati-címkék: SQL Server,PowerShell

Meglepő kapcsolat bontások SQL Azure-ban

Gyakran lehet találkozni azzal a ténnyel, hogy mivel az SQL Azure ugyanazt a tabular data stream (TDS) protokollt támogatja, mint a teljes SQL Server, a programozási modell teljesen azonos a két esetben. Ebből viszont – a közhiedelemmel ellentétben – nem következik az, hogy az alkalmazásunk felhőbe költöztetése mindössze annyiból áll, hogy átállítjuk a connection stringet!

Az SQL Azure ugyanis számos olyan esetben is hajlamos bontani a kapcsolatot, amihez nem vagyunk hozzászokva a saját szervereinken. Íme két példa:

• 40197 – The service has encountered an error processing your request. Please try again.
• 40501 – The service is currently busy. Retry the request after 10 seconds.

Ennek az alapvető okai a hibatűrésben és a rendelkezésre állásban keresendőek. Ha a kérés kiszolgálásában részt vevő valamelyik szereplő hibás lesz vagy épp frissül, akkor a felhőnek köszönhetően nem lesz tartós leállásunk, de szolgáltatás visszaállásáig (ami rövid idő) a kapcsolatokat bontani fogja a szerver. A másik ok, hogy mivel az adatbázisok osztoznak bizonyos erőforrásokon, az SQL Azure query és connection throttling szolgáltatásai biztosítják, hogy egyik ügyfél se akaszthassa le teljesen a kiszolgálást. Ha túllépjük a limitet, hibát fogunk kapni.

Mindennek az az eredménye, hogy időnként elszállnak az adatbázis lekérdezéseink, de mivel ezek okai alapvetően átmeneti jelenségek, bátran megismételhetjük a lekérdezést kicsit később. Ez sajnos nagyon kellemetlen, mert általában arra számítva írjuk meg az adatelérési rétegünket, hogy ha az adatbázis nem elérhető, akkor nagy baj van, és nem szoktunk arra számítani, hogy a hiba másodperceken belül megszűnik magától.

Magyarul: SQL Azure-on futó alkalmazások esetén gondoskodnunk kell ezeknek a hibáknak a kezeléséről, és a hiba jellegétől függően meg kell ismételnünk a lekérdezést. Ha korábban nem volt az alkalmazásunkban ilyen intelligens retry-logika, akkor a felhőbe költöztetéskor ezt bele kell tennünk.

Néhány segítség:

• SQL Azure hibakódok, a végén egy fejezet a throttling hibákról
• Windows Azure SQL Database Connection Management: TechNet wiki cikk a throttling limitekről
• Connections and SQL Azure: régebbi SQL Azure Team blogbejegyzés, az okok leírása használható, a kódrészletet már nem érdemes nézni, van jobb.
• Transient Fault Handling Application Block:
  • Patterns and Practices leírás
  • NuGet package

 

Technorati-címkék: SQL,Azure,SQL Azure,error

50 teljesítmény tipp ASP.NET webalkalmazásokhoz

A fejlesztői segédeszközeiről híres RedGate kiadott egy ingyenes, 50 oldalas e-bookot 50 ways to avoid, find and fix ASP.NET performance issues címmel. A könyvben MVP-k SQL Server, ORM, .NET Framework, IIS és ASP.NET tippjeit gyűjtötték össze, melyek alkalmazásával jobb teljesítményt facsarhatunk ki a webalkalmazásainkból.

A könyv 50 javaslatot tartalmaz 50 oldalon, ebből talán már látszik, hogy nem az a célja, hogy minden technikai részlettel megismertesse az olvasót, hanem hogy felhívja a figyelmet olyan beállításokra vagy mintákra, amelyek mellett hajlamosak vagyunk nap mint nap elmenni. Ennek megfelelően a könyvben kevés újdonság van azok számára, akik már foglalkoztak ASP.NET teljesítmény tuningolással, számukra az igazi érték, hogy szinte ellenőrző listaként használható a könyv. Aki számára pedig új ez a terület, annak jó kiinduló pontot adhatnak a könyvben található témakörök és kulcsszavak a további tájékozódáshoz.

A könyv letölthető innen: http://www.red-gate.com/50ways

 

Technorati-címkék: ebook,performance,ASP.NET,SQL,.NET,IIS

Meghalt a BIDS, éljen az SSDT BI!

Az SQL Server csapat tegnap bejelentette, hogy letölthető a Visual Studiohoz az a kiegészítés, aminek segítségével Reporting, Analysis és Integration Services projekteket készíthetünk a 2012-es verzióban.

A korábban Business Intelligence Development Studio néven futó csomag mostantól SQL Server Data Tools – Business Intelligence (SSDT BI) néven érhető el, és mindenféle upgrade/downgrade nélkül képes kezelni a VS 2010-ben készült projekteket, tehát immár nem szükséges csak emiatt telepítenünk a Studio korábbi verzióját.

A bejelentés: http://blogs.msdn.com/b/sqlrsteamblog/archive/2013/03/06/sql-server-data-tools-business-intelligence-for-visual-studio-2012-released-online.aspx

Letöltés (782 MB): http://www.microsoft.com/en-us/download/details.aspx?id=36843

 

Technorati-címkék: SQL Server,Visual Studio

.NET Framework 3.5 telepítése Windows 8-ra és Windows Server 2012-re

SQL Server 2012-t telepítettem Windows Server 2012-re, és látszólag minden a szokásos módon zajlott. Az előkövetelmények ellenőrzése simán megtörtént, ám a telepítés közepén jött egy figyelmeztetés, hogy szükség van .NET Framework 3.5-re. Mivel a dialógus ablakon mindössze egy OK gomb volt, csak bízhattam benne, hogy az operációs rendszerrel települő .NET 4.5 is megfelelő lesz. Hát nem lett, az SQL telepítés nem sikerült. Aztán kiderült, hogy a .NET Framework 3.5 telepítése nem is olyan egyszerű…

Windows 8-ban és Windows Server 2012-ben a .NET Framework 3.5 ún. Feature on Demand. Ez azt jelenti, hogy az operációs rendszerrel csak a telepítéshez szükséges metaadatok települnek, a szükséges binárisok nem. Azokat máshonnan kell beszereznünk.

 

Windows 8

Windows 8 esetén nyissuk meg a Programs and Features ablakot, amit szerintem legegyszerűbben a Windows+X-es rendszergazdai menüből tehetünk meg:

Pipáljuk be a .NET Framework 3.5 (includes .NET 2.0 and 3.0) sort, majd kattintsunk az OK-ra. Jön egy kis keresgélés:

Majd a kérdés, hogy indulhat-e a letöltés a Windows Update-ről:

Biztos én vagyok túl igényes, de nekem innen nagyon hiányzik, hogy mégis mennyit akarna letölteni és hogy meg lehessen adni másik útvonalat. Ha valóban akarunk .NET 3.5-öt, akkor kattintsunk a Download files from Windows Update gombra. Jön egy kis töltögetés:

Majd ha pechünk van, akkor ez a képernyő:

A Tell me how to solve this problem link kivételesen egészen hasznos, ugyanis a KB2734782 cikkre (Error codes when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012) visz, ami valóban tud segíteni. Nálam az volt a gond, hogy a gép tartományban van, csoportházirend tolja le rá a WSUS beállításokat.

Mivel nem volt lehetőségem ezen módosítani, maradt a másik megoldás, parancssorból telepíteni a Frameworköt. Szerencsére a .NET 3.5 megtalálható a Windows 8 telepítő médián, parancssorból így kell telepíteni:

dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

Pillanatok alatt megtörténik, biztosan gyorsabb, mint Windows Update-ről:

 

Windows Server 2012

A dism-es, parancssoros telepítés tökéletesen működik Windows Server 2012 esetén is, a szükséges fájlok ott is megtalálhatók a telepítő lemezen. Szerencsére itt GUI-n is meg tudjuk oldani a telepítést. Ehhez indítsuk el az Add Roles and Features Wizard-ot és jelöljük be a .NET Framework 3.5 Features opciót (katt a teljes képért):

A Next után a következő oldalon találunk egy végigolvashatatlan sárga hibaüzenetet:

A hibaüzenet azt akarja mondani, hogy ha kicsivel több esélyt akarunk magunknak a sikeres telepítésre, akkor alul kattintsunk a Specify an alternate source path linkre:

A sok szöveg lényege, hogy adjuk meg a telepítő fájlok helyét, például D:\Sources\SxS:

Innen már simán végigmegy a varázsló és az SQL Server is gond nélkül települ.

 

Technorati-címkék: Windows 8,Windows Server 2012,.NET Framework,SQL Server

SQL Server publikálása más porton

Ha félünk attól, hogy a 1433-as port túlságosan is közkedvelt célpontja a támadóknak és kártevőknek, publikálhatjuk az SQL Serverünket más porton is. Ehhez nyissuk meg az SQL Server Configuration Managert, majd navigáljunk el az SQL Server Network Configuration –> Protocols for [instance neve] –> TCP/IP ágig, majd nyissuk meg a Properties ablakot (katt a teljes képért):

Itt a második, IP Addresses fülön tudjuk beállítani, hogy az SQL példányunk milyen IP címeken és milyen portokon legyen elérhető, például áttehetjük akár a 8765-ös portra is:

Természetesen ezt a portot ki kell nyitnunk a tűzfalon. Megtehetjük azt, hogy a tűzfal szabályok közé is bevéssük a port számot, de akár az SQL Server processznek is engedélyezhetjük a kommunikációt, így egyszerűbb lesz az életünk. A Windows Firewall with Advanced Security mmc-ben az Inbound Rule-ok közé vegyünk fel egy új szabályt a New Rule… gomb megnyomásával. Itt jön a trükk: ne portot nyissuk, hanem a Program-ot:

És adjuk meg az adott SQL példányhoz tartozó sqlservr.exe elérési útját:

A varázsló többi lépése a szokásos, üssük ki a téglát a tűzfalon.

Ha nem az alapértelmezett porton fülel a szerver, honnan fogják tudni a klienseink, hogy hova kell kapcsolódniuk? Épp erre szolgál az SQL Browser Service, ami nevesített SQL példányok esetén elárulja a kliensnek a példány portját. Viszont nem sokat érnénk a port változtatással, ha az SQL Browser Service-t elérhetővé tennénk és így bárki automatikusan lekérdezhetné a példányhoz tartozó port számát. Nincs más hátra, mint a kapcsolat tulajdonságai között kézzel megadni a portot. Vigyázat, szokatlan a szintaktika, nem kettőspont kell, hanem vessző a példány neve után:

A port megadása persze kényelmetlennek tűnhet, de szerencsére ezt csak távolról kell megtennünk, hiszen a tűzfal mögött bátran futtathatjuk az SQL Browser Service-t, így az SQL Serveren futó alkalmazások a port megadása nélkül meg fogják találni az adatbázis kiszolgálót.

 

Technorati-címkék: SQL Server,security