Kezdjük a végén?!

Az adatok valahol megszületnek, ami általában egy alkalmazás szerver szokott lenni. Amikor adatbázisba készülünk letárolni, akkor hosszú vándorútra indulnak a születési helyüktől az adatbázisig. Vannak, amik “messzebbről” indulnak és hamarabb érkeznek meg és van fordítva is. Itt már lehet sejteni, hogy az adatok nem feltétlen abban a(z) (idő)sorrendben kerülnek be az adatbázisba, ahogy létrejönnek. Az esetek többségében ez nem is probléma, mert nem lényeges, viszont van, amikor a legfontosabb tényezővé válik. Ezzel az esettel már többféle formában is találkoztam, most egy egyszerűbb példán keresztül mutatnám be.

 

Legyen egy felhasznalok táblánk, ami az alábbiként néz ki és azt rögzíti, hogy ki és mit csinált a weboldalon:

id: sorszam

felhasznalo: akire vonatkozik ez a sor

tevekenyseg: amit csinált a felhasználó

tevekenyseg_kezdete: amikor elkezdte a tevékenységét a felhasználó az alkalmazás szerint

sor_keletkezesi_ideje: amikor az adatbázisba került a sor

 

Az elvárt működés, hogy belép a felhasználó, végez tevékenységeket, végül kilép.

Nézzünk egy képet, ami erre rácáfol:

01_order

 

A fenti képen tisztán látszik, hogy Kati utolsó három sorának a “tevekenyseg_kezdete” mező ugyanazt a dátumot tartalmazza (aminek nem kell így legyen, hogy a probléma valós maradjon), viszont a “kilépés” tevékenysége (id = 5) hamarabb érkezett be az adatbázisba, mint a “negyedik tevékenység” sora (id = 6).

Most, hogy ismerjük a problémát már bármilyen mesét köré lehet szőni, hogy ez miért rossz. A mienk legyen az, hogy, ha a felhasználó kilép, akkor elindul egy folyamat, ami minden tevékenységéért jóváír neki x összeget. Itt meg kimaradna egy tevékenység.

Ha ezt még nem ismertük, akkor jó ha tudunk róla. Viszont rossz hír, hogy nincs általános megoldás ahány eset annyi féle.

 

 

Itt az év vége, engedjük ki a gőzt

Így év vége tájékán megosztanék néhány vicces esetet.

 

1.) Kivételkezlés alkalmazás oldalon:
Hibaüzenet: “No MSSQL”.
2.) Kódoptimalizálás:
— És most frissítjük a gyorsítótáblát
/*
UPDATE table SET mezők WHERE …
*/
3.) A régi idők szekvenciája:
declare @new_id int = (select max(id) + 1 from tábla)
declare @new_id2 int = @new_id + 1

/Aztán mindkét id ment a táblába, amit párhuzamosan is írhattak./
4.) Állásinterjú:
D: Mi a clustered index?
U: Az a primay key. /Határozottan kijelentve/
D: Mi a különbség a primary key és a clustered index között?

A választ meghagyom “logi sztorinak”, de ha követed a felvételiző gondoldatmenetét, akkor könnyen kitalálod 🙂

5.) Felvételi feladat:
D: Ezek a lekérdezések nem használnak az indexet.
U: Olyan kevés a sor a táblában, hogy nem fognak a lekérdezések indexet használni. /Határozottan kijelentve/
U: Csatolva küldöm az új indexeket a régiek helyett…

6.) Tuning:
U: Vegyünk SSD-t! /A proci volt a szűk keresztmetszet/
7.) Statisztika:
U: Nem jó a stat.
D: Okés, milyen szám kell?
U: Nem, ezt nem így kell csinálni. Itt a logika, ami alapján meg kell írni a queryt.

U: Még mindig nem jó a stat.
D: Oké, milyen szám kell?
U: Nem, ezt nem így kell csinálni. Itt a javított logika, ami alapján meg kell írni a queryt.

U: Még mindig nem jó a stat. Ezt a számot kéne kihozni.

8.) Jogosultságok:
U: Kéne sysadmin jog a szerverre.
D: Jó, de akkor nektek kell adminisztrálni a szervert ezentúl.
U: Persze, nem probléma.

U: Kéne egy linked szerver, tudtok segíteni?

9.) Munka:
U: Ezt és ezt kéne csinálni.
D: Okés. De még mondd meg, hogy mi történik ‘A’ esetre.
U: Elmegyek megkérdezem… Szóval, akkor ‘A’ esetre ez van.
D: Okés. Hmmm, ‘B’ esetre mi a teendő?
U: Úúú, erre nem gondoltunk, de elmegyek megkérdezem… Szóval ‘B’ esetre ezt van.
D: Okés. Őőőő, ‘C’ esetre mi van?
U: Mindjárt visszajövök… Az a helyzet, hogy nektek nem lesz vele feladatotok, mi fogjuk csinálni.

10.) Új oszlop:
U: Bele kellene tenni ebbe a táblába is az oszlopot, mert úgy is *-al kérdezzük le, erőforrás meg nincs mindenhol átírni a kódot.
D: Okés, viszont soha nem szűrhettek rá, mert nem indexelt.
U: Persze, úgy lesz.
/Tanultunk az esetből/

11.) Öngól kérdés a management felé:
D: A jó vagy a gyors fejlesztést akarjátok?

12.) Mindent mi sem tudunk:
U: Mi a szuperkulcs?
D: Mi van?
13.) Tervezés:
U: Nem kell, majd alkalmazás oldalon megoldjuk.
D: Okés. /Kevesebb munka, kevesebb gond./

U: Mégiscsak SQL oldalon kéne megoldani.

14.) Scrum:
U: Hogy szoktátok tervezni a napi munkát?
D: Nem tudjuk tervezni, mert napi szinten 5-10 ad-hoc kérés esik be.
U: Jól van, akkor mostantól nektek is lesz scrum.

15.) Scrum-on:
U: Van valami ami akadályoz a munkában?
D: Semmi.
U: Ne csináljátok már, sosincs semmi, had intézzek nektek valamit.
D: Jó, kéne egy új egérpad.

SQL Server Linuxon

Juhúú, megjelent az SQL Server Linuxon. Install segédlet itt: https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup

Mint látszik jelenleg 3 platformon érhető el:

  • Red Hat Enterprise Linux
  • Ubuntu
  • Docker Engine

Én Ubuntura raktam fel teszt jelleggel. Ebben a postban néhány fontos konfigurációs  beállítást mutatok be, hogy az SQL Server ne nyűg, hanem használható társ legyen.

Telepítás után rendelkezésre áll az sqlcmd konzol. Gyorsan felejtsük el, keressünk valami használható toolt helyette. Ilyen pl.: a Heidi SQL. Én windows alól, távolról kapcsolódtam az Ubuntura telepített szerverhez SSMS-el. Szerintem ez a legjobb tool a kezeléséhez.

Csatlakozzunk az SQL szerverhez, példa itt: https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-connect-and-query-sqlcmd

 

Most állítsuk be, hogy ne zabálja ki alólunk a memóriát a szerver:

use master
go

EXEC sys.sp_configure N'show advanced options', N'1'  RECONFIGURE WITH OVERRIDE
GO
-- Min memory
EXEC sys.sp_configure N'min server memory (MB)', N'512'
GO
-- Max memory
EXEC sys.sp_configure N'max server memory (MB)', N'1024'
GO
-- Optimize memory for ad hoc queries
EXEC sys.sp_configure N'optimize for ad hoc workloads', N'1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'show advanced options', N'0'  RECONFIGURE WITH OVERRIDE
GO

--Nézzük meg, hogy sikerült e:
select
name,
minimum,
value_in_use
from sys.configurations
where name like '%server memory%'
or name like '%optimize for ad hoc workloads%'
go

 

02_memory_config

 

Állítsuk be a modell adatbázist SIMPLE recovery-re. Ez azért fontos, mert az újonnan létrehozott adatbázisok ennek az adatbázisnak a mintájára fognak létrejönni. Aki nem tudja, hogy ez mire való, annak érdemes átállítani. A lényege, hogy az adatbázisok nem fogják felzabálni a diszket.

 

-- Deault recovery modell
ALTER DATABASE [model] SET RECOVERY SIMPLE WITH NO_WAIT
GO

 

Ha esetleg valami baj van a szerverrel, azt az error logban lehet megnézni, nekem default ide települt: var/opt/mssql/log

 

Ami engem érdekelt telepítés után, az az OP rendszer és az SQL Server kapcsolata. Itt olyan jellegű SQL utasításokra gondolok, amik Windows-on pl.: a registryben matatnak vagy a fájlokhoz köthetőek valahogy. Voltak, amik nem ment ment, szóval majd doksikat kell néznem 🙂 De ezt leszámítva eddig minden más rendben volt.