(АРХИВА)
Поставки на MS SQL сервер за поголеми Pantheon™ околини

Поставки на MS SQL сервер за поголеми Pantheon™ околини

  Ако одлучуваме за поголеми околини, приложената бесплатна верзија MS SQL Express не е доволна, па затоа се одлучуваме за Standard или Enterprise верзии. Во продолжение следат неколку основни упатства, при планирањето и подготовката на системот, каде ќе се одвива Pantheon™ серверот.  

Дисковни полиња

Потребни се најмалку три одвоени raid1 полиња, составени од најмалку шест дискови:

• првото поле го користиме за систем, pagefile, инсталација на SQL

• второто поле го користиме за системски бази, меѓу другото и TEMPDB

• третото поле го користиме за продукциски бази

Ако имаме на располагање 8 дискови, четвртото поле го користиме за логови.

Посакувано е, системското raid поле да биде поравнато. За дисковни полиња, каде се наоѓаат SQL бази, тоа е неопходно. Во случај на користење на оперативниот систем Windows Server 2008, тоа се прави автоматски, а во случај на Windows Server 2003, тоа го правиме рачно со командата diskpart. Долниот пример покажува процесот на подготовка на aligned партиција на едно од raid полињата:

• diskpart

• list disk

• select disk <x>

• create partition primary align=1024

• assign

• exit

Партициите, каде се наоѓаат SQL бази, треба да се форматираат со 64KB cluster size.

Ако SQL системот веќе го имаме воспоставено, можеме да провериме alignment на партициите со командата:

    wmic partition get BlockSize, StartingOffset, Name, Index

    Испечатениот starting offset го делиме со blocksize. Ако добиеме непарна вредност (нпр. 63), партициите не се правилно подготвени, што значи 20% - 40% побавно работење на SQL при различни IO оптоварувања.

Можеме да провериме и соодветноста на cluster големината, и тоа со командата:

    fsutil fsinfo ntfsinfo c:

    Ако меѓу испечатените вредности „Bytes Per Cluster“ е различно од 65536, партицијата не е правилно форматирана, што негативно влијае на IO перформансите на SQL серверот.   Процесорски перформанси и меморија Барањата можат да бидат многу различни, препорачан минимум се најмалку dual core Xeon системи и 8GB меморија и 64-битен систем.

TempDB

• Препорачливо е да имаме еден data file за секој физички CPU core во системот. Како пример можеме да користиме многу распространет процесор Intel Xeon E5620, кој има 4 физички core или 8 виртуелни (hyperthreading). Во овој случај, оптимално е да имаме 4 data file за tempdb. Сите data file-ови мора да бидат исто големи

• data file-от за tempdb е препорачливо однапред да се алоцира дисковен простор, за да се избегне фрагментација.

• Пример за подготовка на дополнителен datafile со 10GB предалокирано пространство:

USE [master]

GO

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

GO  

Анализа на брзината на работењето на Pantheon™ базата на податоци - систем

При забележување на забавување на работењето, првиот чекор е препорачливо да се изврши процесот на надградба на Pantheon™ базата, бидејќи така се воспоставува оптимално состояние на базата на податоци:

• се поправат индексите и клучевите на табелите

• се поправи референтната интегритет помеѓу табелите

• се додаваат нови полиња, се уредуваат постојните и се отстрануваат непотребните

При надградбата мораме да бидеме внимателни да ја вклучиме опцијата „Надградба на сите објекти“. Со тоа се проверува целата Pantheon™ структура и се отстрануваат грешките, кои можеби ги предизвикал надворешен фактор (дополнителни имплементации).

Препорачливо е да се следат перформансните контра, на ниво на оперативниот систем на Microsoft:

• Memory Commited Bytes – ако е алоцирана меморија повеќе од она што го има системот, потребно е да се прошири меморијата, бидејќи се работи за т.н. swapping.

• Memory Available Mbytes – ако оваа падне под границата од 5%, потребно е да се прошири меморијата

• PhysicalDisk Idle Time – ако оваа повеќе пати падне под 15%, тоа значи дека дисковните полиња се преоптоварени

• PhysicalDisk Read Latency & Write Latency – ако повеќе пати ги надминуваат 30ms, потребно е да се прегледа структурата на дисковните полиња, sql барањата, усогласеноста на партициите со најдобрите практики итн.  

Анализа на брзината на работењето на Pantheon™ базата на податоци – SQL

Проверуваме колку време податоците остануваат во кешот. Вредностите „page life expectancy“ се критични, а препорачаните се во опсег околу 1000. За правилна слика, најдобро е долниот захтев да се извршува на секои 5 минути низ доволно долго време, за да примерокот биде репрезентативен. При вклучување на повеќе серверски надзорни системи (првенствено вграден локален MS data collection), тоа може негативно да влијае на целокупната перформанса на серверот, бидејќи анализата на податоците се одвива локално.

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

Проверуваме најзахтевните операции по CPU и со долните упити. Повеќето проблеми се јавуваат по корисничките доделби на процесите (sloppy programming, индексите, full table scani,...). На основа на резултатите, најзахтевните операции се анализираат и по потреба оптимизираат.

-- 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

Препорачливо е да се провери интегритетот на базата на податоци со:

USE Pantheon

GO

DBCC CHECKDB WITH NO_INFOMSGS

Неправилната поставеност или недостасувачките индекси често се причина за перформансни проблеми. Често проблемите ги предизвикува и фрагментацијата на индексите или обновувањето на статистиките на табелите. Фрагментацијата на индексите ја проверуваме со:

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

Препорачливо е неделно да се извршува rebuild на индексите и обновување на статистиките со:

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