Üzemeltetés kategória bejegyzései

SQL SERVER 2016 Bulk insert optimalizáció

Az SQL Server 2016-ban a bulk insert gyorsabb lett. Persze nem ingyen.
A gyorsulást úgy érik el, hogy 1-1 bulk insert-et érintő page-en több szabad helyet hagy az SQL szerver, mint eddig, arra számítva hogy még érkezik oda sor.
Nagy mennyiségű adat betöltésénél ez jól jön, de kis mennyiségnél azt látni, hogy jelentősen megnő a db mérete, mert sok üres hely marad a page-eken.

Ráadásul ez a működés nem befolyásolható, nincs visszafele kompatibilitás, stb.
Útálom az ilyen visszafele nincs kompatiblitás változtatásokat, ráadásul megint beigazolódott, a kevesebb feature kevesebb gond elmélet.

 

Reklámok

A nagy, a sok és a konkurencia

A fenti 3 dologban közös, hogy mindhárom ellensége a DBA-nak. Ahhoz, hogy tartósan megfelelően működjenek a szerverek, a fenti dolgokat figyelembe kell venni. Bár relatív fogalmak, mert függ a hardvertől is, hogy mikor érik el a kritikus szintet, de amelyik alkalmazás fejlődik ott figyelni kell ezekre.

Nézzük sorra, hogy melyik hol gond:

Nagy méret: (Ami nagy lesz az gond lesz, csak idő kérdése)

  • Nagy méretű adatbázisok: Minél nagyobb az adatbázis mérete, annál tovább tartanak rajta a karbantartási, mentési, helyreállítási műveletek, annál több hely kell a backup-oknak. Jó megoldás az adatbázisok elosztása. Pl.: Készül egy archív adatbázis a product adatbázis mellé, ahova az archive adatok kerülnek.
  • Nagy méretű táblák, indexek: Ezekben az esetekben is a karbantartási műveletek (pl: index rebuild, index reorganize, update statistics) kerülnek sok időbe. Célszerű darabolni a táblát (pl.: partition).

Sok: (Amiből sok lesz, az gond lesz, csak idő kérdése)

  • Sok sor: Minél több egy táblában a sor, annál mélyebbek lesznek az indexek, több lépésből tart megtalálni egy-egy sort is. A particionálás ebben az esetben jól jöhet.
  • Sok nyitott kapcsolat: Minden kapcsolat plusz erőforrásba kerül a szervernek. Amikor kezd kritikussá válni a mennyisége, akkor célszerű új szervereket beállítani a kiszolgálásba.
  • Sok utasítás egységnyi idő alatt: Amikor sok utasítás érdekezik be egységnyi idő alatt, akkor célszerű felülvizsgálni az alkalmazás(oka)t, mert lehet kódhibáról van szó, de az is lehet, hogy DML utasítások helyett a tárolt eljárás a nyerő. Egyéb esetben meg új szervereket célszerű beállítani a kiszolgálásba.

Konkurencia: (Ami konkurál egymással az össze fog akadni, csak idő kérdése)

  • Tranzakciós lock: Ezek a lock-ok a válaszidőket növelik meg. Márpedig a gyors válaszidőket jobban szeretjük. Ehhez vagy jól tervezzük az adatbázisokat és vele az alkalmazást is, vagy átnyargalunk az in-memory technológiára, ha van rá lehetőségünk.

 

A problémákra az ajánlások általános ajánlások, lehet másképp is megoldani, erősen esetfüggő.

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.