Üzemeltetés kategória bejegyzései

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.

 

 

Linked szerver MySQL-re

Nem régiben találkoztam egy érdekes problémával. Felhasználók linked szerveren keresztül futtattak mindenféle mysql lekérdezést, amiktől időnként eldőlt a mysql. A probléma a “mysql működésében volt”. Ez így csúnya, de nehéz szebben kifejezni. A lényeg, hogy a mysql default izolációs szintje a REPEATABLE READ, ami újraolvasásnál garantálja, hogy a kiolvasott érték másodjára is ugyanaz lesz, illetve hogy alapból nem lock-okat használ, mint az MS, hanem sorverziózik, mint az Oracle. MS-nél ez a SNAPSHOT izolációs szint, amivel a dirty read elkerülhető, ugyanis a sorveziózásnak köszönhetően a sornak egyszerre több verziója van. Az eredeti, és a módosult session-önként. Amíg a tranzakció nincs commit-olva, addig mindenki az eredetit látja. A hátránya, hogy overhead teljesítményben és helyügyileg is (a mysql-nél az erre szánt hely fogyott el), hiszen másolni kell a sorokat és adott ideig megtartani.

Ha az üzleti igények megengedik, akkor egy csapásra megoldja a problémát READ UNCOMMITTED izolációs szint beállítása a mysql-ben az adott linked szerveres session-re. Ezt elég 1 helyen, az ODBC driverben átírni. Ki kell keresni az “Initial Statement” mezőt és beírni a set session transaction isolation level read uncommitted bűvös szavakat.

Nézzünk róla egy képet:
01_mysql_default_transaction_isoldation_level

Ellenőrizni több utasítással is lehet, egy lehetséges (persze mysql-ben): SELECT @@session.tx_isolation;