ProHoster > Blog > Rêveberî > Hin aliyên çavdêriya MS SQL Server. Pêşniyarên ji bo danîna alayên şopê

Hin aliyên çavdêriya MS SQL Server. Pêşniyarên ji bo danîna alayên şopê

Pêşniyar

Pir caran, bikarhêner, pêşdebir û rêvebirên MS SQL Server DBMS bi pirsgirêkên performansa databasê an DBMS-ê bi tevahî re rû bi rû ne, ji ber vê yekê çavdêriya MS SQL Server pir têkildar e.
Ev gotar pêveka gotarê ye Bikaranîna Zabbix ji bo Çavdêriya Daneyên Servera MS SQL û ew ê hin aliyên çavdêriya MS SQL Serverê vekolîne, bi taybetî: meriv çawa zû diyar dike ka kîjan çavkaniyan winda ne, û her weha pêşniyarên ji bo sazkirina alayên şopandinê.
Ji bo ku skrîptên jêrîn bixebitin, hûn hewce ne ku di databasa xwestinê de şemayek inf bi vî rengî biafirînin:
Afirandina schema info

use <имя_БД>;
go
create schema inf;

Rêbaz ji bo tespîtkirina kêmbûna RAM

Nîşana yekem a kêmbûna RAM-ê ev e ku gava mînakek MS SQL Server hemî RAM-a ku jê re hatî veqetandin dixwe.
Ji bo vê yekê, nûneriya jêrîn inf.vRAM biafirînin:
Afirandina dîtina inf.vRAM

CREATE view [inf].[vRAM] as
select a.[TotalAvailOSRam_Mb]						--сколько свободно ОЗУ на сервере в МБ
		 , a.[RAM_Avail_Percent]					--процент свободного ОЗУ на сервере
		 , a.[Server_physical_memory_Mb]				--сколько всего ОЗУ на сервере в МБ
		 , a.[SQL_server_committed_target_Mb]			--сколько всего ОЗУ выделено под MS SQL Server в МБ
		 , a.[SQL_server_physical_memory_in_use_Mb] 		--сколько всего ОЗУ потребляет MS SQL Server в данный момент времени в МБ
		 , a.[SQL_RAM_Avail_Percent]				--поцент свободного ОЗУ для MS SQL Server относительно всего выделенного ОЗУ для MS SQL Server
		 , a.[StateMemorySQL]						--достаточно ли ОЗУ для MS SQL Server
		 , a.[SQL_RAM_Reserve_Percent]				--процент выделенной ОЗУ для MS SQL Server относительно всего ОЗУ сервера
		 --достаточно ли ОЗУ для сервера
		, (case when a.[RAM_Avail_Percent]<10 and a.[RAM_Avail_Percent]>5 and a.[TotalAvailOSRam_Mb]<8192 then 'Warning' when a.[RAM_Avail_Percent]<=5 and a.[TotalAvailOSRam_Mb]<2048 then 'Danger' else 'Normal' end) as [StateMemoryServer]
	from
	(
		select cast(a0.available_physical_memory_kb/1024.0 as int) as TotalAvailOSRam_Mb
			 , cast((a0.available_physical_memory_kb/casT(a0.total_physical_memory_kb as float))*100 as numeric(5,2)) as [RAM_Avail_Percent]
			 , a0.system_low_memory_signal_state
			 , ceiling(b.physical_memory_kb/1024.0) as [Server_physical_memory_Mb]
			 , ceiling(b.committed_target_kb/1024.0) as [SQL_server_committed_target_Mb]
			 , ceiling(a.physical_memory_in_use_kb/1024.0) as [SQL_server_physical_memory_in_use_Mb]
			 , cast(((b.committed_target_kb-a.physical_memory_in_use_kb)/casT(b.committed_target_kb as float))*100 as numeric(5,2)) as [SQL_RAM_Avail_Percent]
			 , cast((b.committed_target_kb/casT(a0.total_physical_memory_kb as float))*100 as numeric(5,2)) as [SQL_RAM_Reserve_Percent]
			 , (case when (ceiling(b.committed_target_kb/1024.0)-1024)<ceiling(a.physical_memory_in_use_kb/1024.0) then 'Warning' else 'Normal' end) as [StateMemorySQL]
		from sys.dm_os_sys_memory as a0
		cross join sys.dm_os_process_memory as a
		cross join sys.dm_os_sys_info as b
		cross join sys.dm_os_sys_memory as v
	) as a;

Dûv re hûn dikarin diyar bikin ku mînakek MS SQL Server bi karanîna pirsa jêrîn hemî bîranîna ku jê re hatî veqetandin vedixwe:

select  SQL_server_physical_memory_in_use_Mb,  SQL_server_committed_target_Mb
from [inf].[vRAM];

Ger nîşana SQL_server_physical_memory_in_use_Mb bi berdewamî ji SQL_server_committed_target_Mb ne kêmtir e, wê hingê hûn hewce ne ku statîstîkên bendê kontrol bikin.
Ji bo destnîşankirina kêmbûna RAM-ê bi statîstîkên li bendê, werin em dîmenek inf.vWaits biafirînin:
Afirandina dîtina inf.vWaits

CREATE view [inf].[vWaits] as
WITH [Waits] AS
    (SELECT
        [wait_type], --имя типа ожидания
        [wait_time_ms] / 1000.0 AS [WaitS],--Общее время ожидания данного типа в миллисекундах. Это время включает signal_wait_time_ms
        ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],--Общее время ожидания данного типа в миллисекундах без signal_wait_time_ms
        [signal_wait_time_ms] / 1000.0 AS [SignalS],--Разница между временем сигнализации ожидающего потока и временем начала его выполнения
        [waiting_tasks_count] AS [WaitCount],--Число ожиданий данного типа. Этот счетчик наращивается каждый раз при начале ожидания
        100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
        ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
    FROM sys.dm_os_wait_stats
    WHERE [waiting_tasks_count]>0
		and [wait_type] NOT IN (
        N'BROKER_EVENTHANDLER',         N'BROKER_RECEIVE_WAITFOR',
        N'BROKER_TASK_STOP',            N'BROKER_TO_FLUSH',
        N'BROKER_TRANSMITTER',          N'CHECKPOINT_QUEUE',
        N'CHKPT',                       N'CLR_AUTO_EVENT',
        N'CLR_MANUAL_EVENT',            N'CLR_SEMAPHORE',
        N'DBMIRROR_DBM_EVENT',          N'DBMIRROR_EVENTS_QUEUE',
        N'DBMIRROR_WORKER_QUEUE',       N'DBMIRRORING_CMD',
        N'DIRTY_PAGE_POLL',             N'DISPATCHER_QUEUE_SEMAPHORE',
        N'EXECSYNC',                    N'FSAGENT',
        N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX',
        N'HADR_CLUSAPI_CALL',           N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
        N'HADR_LOGCAPTURE_WAIT',        N'HADR_NOTIFICATION_DEQUEUE',
        N'HADR_TIMER_TASK',             N'HADR_WORK_QUEUE',
        N'KSOURCE_WAKEUP',              N'LAZYWRITER_SLEEP',
        N'LOGMGR_QUEUE',                N'ONDEMAND_TASK_QUEUE',
        N'PWAIT_ALL_COMPONENTS_INITIALIZED',
        N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
        N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP',
        N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESOURCE_QUEUE',
        N'SERVER_IDLE_CHECK',           N'SLEEP_BPOOL_FLUSH',
        N'SLEEP_DBSTARTUP',             N'SLEEP_DCOMSTARTUP',
        N'SLEEP_MASTERDBREADY',         N'SLEEP_MASTERMDREADY',
        N'SLEEP_MASTERUPGRADED',        N'SLEEP_MSDBSTARTUP',
        N'SLEEP_SYSTEMTASK',            N'SLEEP_TASK',
        N'SLEEP_TEMPDBSTARTUP',         N'SNI_HTTP_ACCEPT',
        N'SP_SERVER_DIAGNOSTICS_SLEEP', N'SQLTRACE_BUFFER_FLUSH',
        N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
        N'SQLTRACE_WAIT_ENTRIES',       N'WAIT_FOR_RESULTS',
        N'WAITFOR',                     N'WAITFOR_TASKSHUTDOWN',
        N'WAIT_XTP_HOST_WAIT',          N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG',
        N'WAIT_XTP_CKPT_CLOSE',         N'XE_DISPATCHER_JOIN',
        N'XE_DISPATCHER_WAIT',          N'XE_TIMER_EVENT')
    )
, ress as (
	SELECT
	    [W1].[wait_type] AS [WaitType],
	    CAST ([W1].[WaitS] AS DECIMAL (16, 2)) AS [Wait_S],--Общее время ожидания данного типа в миллисекундах. Это время включает signal_wait_time_ms
	    CAST ([W1].[ResourceS] AS DECIMAL (16, 2)) AS [Resource_S],--Общее время ожидания данного типа в миллисекундах без signal_wait_time_ms
	    CAST ([W1].[SignalS] AS DECIMAL (16, 2)) AS [Signal_S],--Разница между временем сигнализации ожидающего потока и временем начала его выполнения
	    [W1].[WaitCount] AS [WaitCount],--Число ожиданий данного типа. Этот счетчик наращивается каждый раз при начале ожидания
	    CAST ([W1].[Percentage] AS DECIMAL (5, 2)) AS [Percentage],
	    CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgWait_S],
	    CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgRes_S],
	    CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgSig_S]
	FROM [Waits] AS [W1]
	INNER JOIN [Waits] AS [W2]
	    ON [W2].[RowNum] <= [W1].[RowNum]
	GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
	    [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
	HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95 -- percentage threshold
)
SELECT [WaitType]
      ,MAX([Wait_S]) as [Wait_S]
      ,MAX([Resource_S]) as [Resource_S]
      ,MAX([Signal_S]) as [Signal_S]
      ,MAX([WaitCount]) as [WaitCount]
      ,MAX([Percentage]) as [Percentage]
      ,MAX([AvgWait_S]) as [AvgWait_S]
      ,MAX([AvgRes_S]) as [AvgRes_S]
      ,MAX([AvgSig_S]) as [AvgSig_S]
  FROM ress
  group by [WaitType];

Di vê rewşê de, hûn dikarin kêmbûna RAM-ê bi karanîna pirsa jêrîn diyar bikin:

SELECT [Percentage]
      ,[AvgWait_S]
  FROM [inf].[vWaits]
  where [WaitType] in (
    'PAGEIOLATCH_XX',
    'RESOURCE_SEMAPHORE',
    'RESOURCE_SEMAPHORE_QUERY_COMPILE'
  );

Li vir hûn hewce ne ku bala xwe bidin nîşaneyên Sedî û AvgWait_S. Ger ew bi tevahîya xwe girîng in, wê hingê îhtîmalek pir mezin heye ku mînaka MS SQL Server têra RAM-ê nebe. Nirxên bingehîn ji bo her pergalê bi rengek kesane têne destnîşankirin. Lêbelê, hûn dikarin bi nîşana jêrîn dest pê bikin: Ji sedî>=1 û AvgWait_S>=0.005.
Ji bo deranîna nîşanan li ser pergalek çavdêriyê (mînak, Zabbix), hûn dikarin du pirsên jêrîn biafirînin:

  1. Rêjeya celebên bendê ji bo RAM-ê çi ye (hevdeng ji bo hemî celebên bendê yên weha): 
    select coalesce(sum([Percentage]), 0.00) as [Percentage]
from [inf].[vWaits]
       where [WaitType] in (
           'PAGEIOLATCH_XX',
           'RESOURCE_SEMAPHORE',
            'RESOURCE_SEMAPHORE_QUERY_COMPILE'
  );
  2. çend celebên benda RAM-ê di milî çirkeyan de digirin (nirxa herî zêde ya hemî derengiyên navîn ji bo hemî celebên bendê): 
    select coalesce(max([AvgWait_S])*1000, 0.00) as [AvgWait_MS]
from [inf].[vWaits]
       where [WaitType] in (
           'PAGEIOLATCH_XX',
           'RESOURCE_SEMAPHORE',
            'RESOURCE_SEMAPHORE_QUERY_COMPILE'
  );

Li ser bingeha dînamîkên nirxên hatine bidestxistin ji bo van her du nîşanan, em dikarin encam bidin ka ji bo mînaka MS SQL Server bes RAM heye.

Rêbaza ji bo tespîtkirina barkirina zêde ya CPU

Ji bo naskirina kêmbûna dema CPU, tenê dîtina pergalê sys.dm_os_schedulers bikar bînin. Li vir, heke nîşana runnable_tasks_count bi domdarî ji 1-ê mezintir be, wê hingê îhtimalek mezin heye ku hejmara navokan ji bo mînaka MS SQL Server têrê neke.
Ji bo ku di pergalek çavdêriyê de nîşanek nîşan bide (mînak, Zabbix), hûn dikarin daxwaza jêrîn biafirînin:

select max([runnable_tasks_count]) as [runnable_tasks_count]
from sys.dm_os_schedulers
where scheduler_id<255;

Li ser bingeha dînamîkên nirxên ku ji bo vê nîşankerê hatine wergirtin, em dikarin encam bidin ka ji bo mînaka MS SQL Server têra wextê pêvajoyê (hejmara core CPU) heye.
Lêbelê, girîng e ku meriv vê rastiyê bi bîr bîne ku pirs bixwe dikarin di yekcarê de gelek mijaran bipirsin. Û carinan optimîzator nikare bi rast tevliheviya pirsê bixwe texmîn bike. Dûv re dibe ku daxwaz pir pir mijarên were veqetandin, ku di demek diyarkirî de nekarin bi hevdemî werin pêvajo kirin. Û ev jî dibe sedema celebek bendewariyê ya ku bi kêmbûna dema pêvajoyê ve girêdayî ye, û mezinbûna dorê ji bo plansazkerên ku korikên taybetî yên CPU bikar tînin, ango, nîşana runnable_tasks_count dê di şert û mercên weha de zêde bibe.
Di vê rewşê de, berî ku hûn hejmara navikên CPU zêde bikin, hûn hewce ne ku taybetmendiyên paralelîzmê yên mînaka MS SQL Server bixwe bi rêkûpêk mîheng bikin, û ji guhertoya 2016-an ve, bi rast taybetmendiyên paralelîzmê yên databasên pêwîst mîheng bikin:
Hin aliyên çavdêriya MS SQL Server. Pêşniyarên ji bo danîna alayên şopê

Hin aliyên çavdêriya MS SQL Server. Pêşniyarên ji bo danîna alayên şopê
Li vir divê hûn bala xwe bidin parametreyên jêrîn:

  1. Rêjeya herî zêde ya paralelîzmê-hejmara herî zêde ya mijarên ku dikare ji her daxwazê ​​re were veqetandin destnîşan dike (xweber 0 e - tenê ji hêla pergala xebitandinê bixwe û guhertoya MS SQL Server ve hatî sînordar kirin)
  2. Bendavê lêçûnê ji bo paralelîzmê - lêçûna texmînkirî ya paralelîzmê (pêşniyaz 5 e)
  3. Max DOP-jimara herî zêde ya mijarên ku dikare ji her pirsê re di asta databasê de were veqetandin (lê ne ji nirxa taybetmendiya "Max Degree of Parallelism") destnîşan dike (bi xwerû ew 0 ye - tenê ji hêla pergala xebitandinê ve tête sînor kirin. xwe û weşana MS SQL Server, û her weha sînorkirinek li ser taybetmendiya "Max Degree of Parallelism" ya tevahiya mînaka MS SQL Server)

Ne gengaz e ku meriv ji bo hemî bûyeran reçeteyek wekhev baş bide, ango, hûn hewce ne ku pirsên dijwar analîz bikin.
Li ser bingeha ezmûna xwe, ez ji bo pergalên OLTP algorîtmaya çalakiyan ya jêrîn pêşniyar dikim ku taybetmendiyên paralelîzmê mîheng bikin:

  1. pêşî paralelîzmê neçalak bike bi danîna Rêjeya Maxê ya Paralelîzmê di asta tevahîya nimûneyê de 1
  2. Pirsên herî giran analîz bikin û ji bo wan jimara herî baş a mijaran hilbijêrin
  3. Rêjeya Max-ê ya Paralelîzmê li ser hejmara optîmal a hilbijartî ya têlên ku ji gava 2-an hatî wergirtin bicîh bikin, û her weha ji bo databasên taybetî nirxa Max DOP-ê ya ku ji gava 2-an hatî wergirtin ji bo her databasê destnîşan bikin.
  4. Pirsên herî giran analîz bikin û bandora neyînî ya pirzimanî nas bikin. Ger ew be, wê hingê ji bo Parallelîzmê Mesrefê zêde bikin.
    Ji bo pergalên wekî 1C, Microsoft CRM û Microsoft NAV, di pir rewşan de qedexekirina pirzimanî guncan e.

Di heman demê de, heke we guhertoya Standard heye, wê hingê di pir rewşan de qedexekirina pir-mijaran guncan e ji ber vê yekê ku ev çap di hejmara core CPU de sînordar e.
Algorîtmaya ku li jor hatî destnîşan kirin ji bo pergalên OLAP ne maqûl e.
Li ser bingeha ezmûna xwe, ez ji bo pergalên OLAP algorîtmaya çalakiyan a jêrîn pêşniyar dikim ku taybetmendiyên paralelîzmê mîheng bikin:

  1. Pirsên herî giran analîz bikin û ji bo wan jimara herî baş a mijaran hilbijêrin
  2. Rêjeya Max-ê ya Paralelîzmê li ser hejmara optîmal a hilbijartî ya têlên ku ji gava 1-an hatî wergirtin bicîh bikin, û her weha ji bo databasên taybetî nirxa Max DOP-ê ya ku ji gava 1-an hatî wergirtin ji bo her databasê destnîşan bikin.
  3. pirsên herî giran analîz bikin û bandora neyînî ya sînorkirina hevdemiyê nas bikin. Ger wusa be, wê hingê yan ji bo nirxa Parallelîzmê Berava Mesrefê kêm bikin, an gavên 1-2 yên vê algorîtmê dubare bikin.

Ango ji bo pergalên OLTP em ji yek-threading diçin pir-threading, û ji bo pergalên OLAP, berevajî, em ji pir-threading diçin yek-threading. Bi vî rengî hûn dikarin hem ji bo databasek taybetî hem jî ji bo tevahiya mînaka MS SQL Server mîhengên paralelîzmê yên çêtirîn hilbijêrin.
Di heman demê de girîng e ku meriv fêm bike ku pêdivî ye ku mîhengên taybetmendiyên hevdemî bi demê re bêne guheztin, li ser bingeha encamên şopandina performansa MS SQL Server.

Pêşniyarên ji bo danîna alayên şopê

Ji ezmûna xwe û ezmûna hevkarên min, ji bo performansa çêtirîn, ez pêşniyar dikim ku di asta xebitandina karûbarê MS SQL Server-ê de ji bo guhertoyên 2008-2016 alayên şopê yên jêrîn bicîh bikin:

  1. 610 - Têketina navberan di tabloyên pêvekirî de kêm bike. Dikare bi têxistina tabloyên bi hejmareke mezin ji tomar û gelek danûstendinan re bibe alîkar, digel ku gelek caran WRITELOG li benda guhertinên di navnîşan de ye.
  2. 1117 - Ger pelek di komek pelan de bi sînorê mezinbûna otomatîkî bigire, hemî pelên di koma pelan de mezin dibin.
  3. 1118 - Bi zorê dide hemî tiştan ku di dereceyên cihêreng de bi cih bibin (destûrê nade rêjeyên tevlihev), ku hewcedariya şopandina rûpela SGAM-ê ya ku ji bo şopandina rêjeyên tevlihev tê bikar anîn kêm dike.
  4. 1224 - Li ser bingeha hejmartina qeflê zêdekirina qeflê neçalak dike. Lêbelê, karanîna zêde ya bîranînê dikare zêdekirina kilît bike
  5. 2371 - Rêjeya nûvekirina statîstîkên otomatîkî yên rastkirî diguhezîne sînorê nûvekirina statîstîkên otomatîkî yên dînamîkî. Ji bo nûvekirina planên lêpirsînê yên li ser tabloyên mezin girîng e ku bi xeletî destnîşankirina hejmara tomaran dibe sedema planên înfazê yên xelet.
  6. 3226 - Peyamên serkeftina paşvekişandinê di têketina xeletiyê de vedişêre
  7. 4199 - Guhertinên optimîzatora pirsê ya ku di berhevokên nûvekirina SQL Server û pakêtên karûbarê de hatî berdan vedihewîne
  8. 6532-6534 - Pêşveçûnên performansê ji bo pirsên bi celebên daneya cîhê vedihewîne
  9. 8048 - Tiştên bîranînê yên dabeşkirî yên NUMA vediguhezîne yên CPU-parvekirî
  10. 8780 - Ji bo plansaziya lêpirsînê veqetandina wextê zêde çalak dike. Dibe ku hin daxwazên bêyî vê alayê bêne red kirin ji ber ku nexşeyek wan a pirsê tune (çewtiyek pir kêm)
  11. 8780 - 9389 - Ji bo operatorên moda hevîrê tamponek bîranîna demkî ya dînamîkî ya zêde çalak dike, rê dide operatorê moda hevîrê ku daxwaza bîranîna zêde bike û ger bîra zêde peyda bibe ji veguheztina daneyan ji tempdb re dûr bixe.

Di heman demê de kêrhatî ye ku berî guhertoya 2016-an ala şopandina 2301 çalak bike, ku xweşbîniya piştevaniya biryara pêşkeftî çalak dike û bi vî rengî di hilbijartina plansaziyên lêpirsînê yên çêtir de dibe alîkar. Lêbelê, ji guhertoya 2016-an vir ve, ew pir caran bandorek neyînî li ser demên darvekirina giştpirsiya pir dirêj dike.
Di heman demê de, ji bo pergalên bi gelek navnîşan (mînak, ji bo databasên 1C), ez pêşniyar dikim ku ala şopê 2330 çalak bikin, ku berhevkirina karanîna pêvekê asteng dike, ku bi gelemperî bandorek erênî li pergalê dike.
Hûn dikarin di derbarê alayên şopê de bêtir fêr bibin vir
Ji zencîreya jor, di heman demê de girîng e ku meriv guherto û avahîyên MS SQL Server-ê jî bihesibîne, ji ber ku ji bo guhertoyên nûtir, hin alayên şopandinê ji hêla xwerû ve têne çalak kirin an jî bandorek wan tune.
Hûn dikarin ala şopê bi rêzdarî bi karanîna fermanên DBCC TRACEON û DBCC TRACEOFF çalak bikin an neçalak bikin. Zêdetir hûrgulî bibînin vir
Hûn dikarin bi karanîna fermana DBCC TRACESTATUS statûya alayên şopandinê bistînin: bêhtir agahdariyê
Ji bo ku alayên şopandinê di destpêka otomatîkî ya karûbarê MS SQL Server de cih bigirin, hûn hewce ne ku biçin Gerînendeyê Vesazkirina Servera SQL û van alayên şopandinê bi riya -T di taybetmendiyên karûbarê de zêde bikin:
Hin aliyên çavdêriya MS SQL Server. Pêşniyarên ji bo danîna alayên şopê

Encam

Vê gotarê hin aliyên çavdêriya MS SQL Server lêkolîn kir, bi alîkariya wan hûn dikarin zû kêmbûna RAM û dema CPU-ya belaş, û her weha hejmarek pirsgirêkên din ên kêmtir eşkere nas bikin. Alên şopê yên ku herî zêde têne bikar anîn hatin vekolîn.

Çavkaniyên

» SQL Server Statistics Wait
» SQL Server statîstîkên bendê an ji kerema xwe ji min re bêje ku ew diêşe
» Dîtina pergalê sys.dm_os_schedulers
» Bikaranîna Zabbix ji bo Çavdêriya Daneyên Servera MS SQL
» SQL Lifestyle
» alayên şopandinê
» sql.ru

Source: www.habr.com

Add a comment