(ARHIV)
Konfigurimi i serverit MS SQL për mjedise më të mëdha Pantheon™

Konfigurimi i serverit MS SQL për mjedise më të mëdha Pantheon™

  Nëse po vendosim për mjedise më të mëdha, versioni i lirë i MS SQL Express nuk është i mjaftueshëm, prandaj përdorim versionet Standard ose Enterprise. Më poshtë janë disa udhëzime të thjeshta për planifikimin dhe përgatitjen e sistemit, ku do të funksionojë serveri Pantheon™.  

Fushat e diskut

Na nevojiten të paktën tre fusha të ndara raid1, të përbëra nga të paktën gjashtë disqe:

• fusha e parë përdoret për sistemin, pagefile, instalimin e SQL

• fusha e dytë përdoret për bazat e të dhënave sistemike, përfshirë TEMPDB

• fusha e tretë përdoret për bazat e prodhimit

Nëse kemi në dispozicion 8 disqe, përdorim fushën e katërt për loge.

Është e dëshirueshme që fusha e raid-it të jetë e rregulluar. Për fushat e diskut, ku ndodhen bazat SQL, kjo është e domosdoshme. Në rastin e përdorimit të sistemit operativ Windows Server 2008, kjo bëhet automatikisht, ndërsa në rastin e Windows Server 2003, e bëjmë manualisht me komandën diskpart. Shembulli më poshtë tregon procesin e përgatitjes së një particioni të rregulluar në një nga fushat raid:

• diskpart

• list disk

• select disk <x>

• create partition primary align=1024

• assign

• exit

Particionet, ku ndodhen bazat SQL, duhet të formatohen me madhësinë e klasterit 64KB.

Nëse sistemi SQL është tashmë i vendosur, mund të kontrollojmë rregullimin e particioneve me komandën:

    wmic partition get BlockSize, StartingOffset, Name, Index

    Vlera e offset-it fillestar ndahet me madhësinë e bllokut. Nëse marrim një vlerë të çuditshme (p.sh. 63), particionet nuk janë përgatitur siç duhet, që do të thotë 20% - 40% ngadalësim të performancës SQL nën ngarkesa të ndryshme IO.

Po ashtu, mund të kontrollojmë përshtatshmërinë e madhësisë së klasterit, me komandën:

    fsutil fsinfo ntfsinfo c:

    Nëse midis vlerave të shfaqura "Bytes Per Cluster" është ndryshe nga 65536, atëherë particioni nuk është formatuar siç duhet, që ndikon negativisht në performancën IO të serverit SQL.   Kapacitetet e procesorëve dhe memorja Kërkesat mund të jenë shumë të ndryshme, minimumi i rekomanduar është të paktën sisteme dual core Xeon dhe 8GB memorie dhe sistem 64 bit.

TempDB

• Është e rekomanduar të kemi një skedë të dhënash për çdo bërthamë fizike CPU në sistem. Si shembull mund të përdorim procesorin shumë të njohur Intel Xeon E5620, i cili ka 4 bërthama fizike ose 8 virtuale (hyperthreading). Në këtë rast, është optimale të kemi 4 skeda të dhënash për tempdb. Të gjitha skedat e dhënash duhet të jenë të njëjta në madhësi

• me skedën e dhënash për tempdb, është e rekomanduar të alokojmë paraprakisht hapësirën e diskut, për të shmangur fragmentimin.

• Shembulli i përgatitjes së një skede të dhënash shtesë me 10GB hapësirë të alokuar paraprakisht:

USE [master]

GO

ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdata2', FILENAME = N'e:\sql\templog2.mdf' , SIZE = 10240000KB , FILEGROWTH = 10%)

GO  

Analizat e shpejtësisë së funksionimit të bazës së të dhënave Pantheon™ - sistem

Kur vërejmë ngadalësime në funksionim, hapi i parë i rekomanduar është realizimi i procesit të përmirësimit të bazës Pantheon™, pasi kështu krijohet një gjendje optimale e bazës së të dhënave:

• korrigjohen indeksat dhe çelësat në tabela

• korrigjohet integriteti referencial midis tabelave

• shtohen fusha të reja, rregullohen ato ekzistuese dhe hiqen ato të tepërta

Gjatë përmirësimit, duhet të jemi të kujdesshëm që të aktivizojmë opsionin "Përmirësimi i të gjitha objekteve". Kjo kontrollon të gjithë strukturën e Pantheon™ dhe eliminon gabimet që mund të ketë shkaktuar një faktor të jashtëm (implementime shtesë).

Është e rekomanduar të monitorojmë numrat e performancës, në nivelin e sistemit operativ Microsoft:

• Memory Commited Bytes – nëse ka më shumë memorie të alokuar se sa ka sistemi, është e nevojshme të zgjerohet memoria, sepse bëhet fjalë për swapping.

• Memory Available Mbytes – nëse kjo bie nën 5%, është e nevojshme të zgjerohet memoria

• PhysicalDisk Idle Time – nëse kjo bie disa herë nën 15%, do të thotë se fushat e diskut janë të mbingarkuara

• PhysicalDisk Read Latency & Write Latency – nëse këto kalojnë disa herë 30ms, është e nevojshme të kontrollohet struktura e fushave të diskut, kërkesat sql, përputhshmëria e particioneve me praktikat më të mira etj.  

Analizat e shpejtësisë së funksionimit të bazës së të dhënave Pantheon™ – SQL

Kontrollojmë se sa kohë të dhënat qëndrojnë në cache. Vlerat "page life expectancy" janë kritike, ndërsa ato të rekomanduara janë në rreth 1000. Për një pamje të saktë, kërkesa më poshtë duhet të ekzekutohet çdo 5 minuta për një periudhë të mjaftueshme kohore, që të jetë mostra përfaqësuese. Me aktivizimin e disa sistemeve të monitorimit të serverëve (sidomos MS data collection të integruar lokal), kjo mund të ndikojë negativisht në performancën e përgjithshme të serverit, pasi analiza e të dhënave ndodh lokalisht.

select b.total - a.db as 'Plan Cache Size', c.ple as 'Page Life Expectancy'

from

( select cntr_value as db

from sys.dm_os_performance_counters

where object_name like '%Buffer Manager%' and counter_name like 'Database pages%' ) a, 

( select distinct cntr_value as total

from sys.dm_os_performance_counters

where object_name like '%Buffer Manager%' and counter_name like 'Total pages%' ) b,

( SELECT cntr_value AS ple

FROM sys.dm_os_performance_counters

WHERE object_name like '%Buffer Manager%'

AND counter_name = 'Page life expectancy' ) c

Kontrollojmë operacionet më të kërkuara p oCPU dhe me kërkesat më poshtë. Shumica e problemeve ndodhin pas ndarjes së procedurave nga përdoruesit (programim i dobët, indekse, skanime të plota të tabelave,...). Bazuar në rezultatet, operacionet më të kërkuara analizohen dhe optimizohen sipas nevojës.

-- top 10 CPU

SELECT TOP 10

  qs.execution_count,

  total_CPU_secs = qs.total_worker_time/1000000,

  average_CPU_secs = (qs.total_worker_time/1000000) / qs.execution_count,

  total_elapsed_time_secs = qs.total_elapsed_time/1000000,

  query = st.text,

  qp.query_plan

FROM

  sys.dm_exec_query_stats AS qs

  CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st

  CROSS apply sys.dm_exec_query_plan (qs.plan_handle) AS qp

  ORDER BY qs.total_worker_time DESC

-- top 10 I/O

SELECT TOP 10

  qs.execution_count, qs.total_logical_reads, 

  qs.total_elapsed_time, qs.max_elapsed_time,

  qs.last_elapsed_time, qs.last_execution_time,

    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,

    ((CASE qs.statement_end_offset

    WHEN -1 THEN DATALENGTH(qt.text)

    ELSE qs.statement_end_offset

    END - qs.statement_start_offset)/2)+1) as query,

  qp.query_plan

FROM sys.dm_exec_query_stats qs

  CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt

  CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp

  WHERE qt.encrypted=0

  ORDER BY qs.total_logical_reads DESC

Është e rekomanduar të kontrollohet integriteti i bazës së të dhënave me:

USE Pantheon

GO

DBCC CHECKDB WITH NO_INFOMSGS

Konfigurimi i gabuar ose indekset e munguar shpesh janë shkaku i problemeve të performancës. Shpesh, problemet shkaktohen gjithashtu nga fragmentimi i indekseve ose përditësimi i statistikave të tabelave. Fragmentimin e indekseve e kontrollojmë me:

USE Pantheon;

SELECT a.index_id, name, index_type_desc, avg_fragmentation_in_percent

FROM sys.dm_db_index_physical_stats (DB_ID(), OBJECT_ID(N'Production.Product'),

     NULL, NULL, NULL) AS a

    JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id

WHERE name not like 'NULL' AND avg_fragmentation_in_percent > 10

ORDER by avg_fragmentation_in_percent DESC

GO

Është e rekomanduar të kryhet çdo javë rindërtimi i indekseve dhe përditësimi i statistikave me:

USE Pantheon;

GO

DECLARE @TableName VARCHAR(255)

DECLARE @sql NVARCHAR(500)

DECLARE @fillfactor INT

SET @fillfactor = 80

DECLARE TableCursor CURSOR FOR

SELECT OBJECT_SCHEMA_NAME([object_id])+'.'+name AS TableName

FROM sys.tables

OPEN TableCursor

FETCH NEXT FROM TableCursor INTO @TableName

WHILE @@FETCH_STATUS = 0

BEGIN

SET @sql = 'ALTER INDEX ALL ON ' + @TableName + ' REBUILD WITH (FILLFACTOR = ' + CONVERT(VARCHAR(3),@fillfactor) + ')'

EXEC (@sql)

SET @sql = 'UPDATE STATISTICS ' + @TableName + ' WITH FULLSCAN'

EXEC (@sql)

FETCH NEXT FROM TableCursor INTO @TableName

END

CLOSE TableCursor

DEALLOCATE TableCursor

GO