🥇 MS SQL Server-ի մոնիտորինգի որոշ ասպեկտներ: Ուղեցույցներ հետքի դրոշների տեղադրման համար

Նախաբան

Շատ հաճախ MS SQL Server DBMS-ի օգտվողները, մշակողները և ադմինիստրատորները բախվում են տվյալների բազայի կամ DBMS-ի աշխատանքի հետ կապված խնդիրների հետ, ուստի MS SQL Server մոնիտորինգը շատ տեղին է:
Այս հոդվածը հոդվածի լրացում է Օգտագործելով Zabbix-ը MS SQL Server տվյալների բազան մոնիտորինգի համար և այն կներառի MS SQL Server-ի մոնիտորինգի որոշ ասպեկտներ, մասնավորապես՝ ինչպես արագ որոշել, թե որ ռեսուրսներն են բացակայում, ինչպես նաև առաջարկություններ՝ հետքի դրոշներ սահմանելու համար:
Որպեսզի հետևյալ սկրիպտները աշխատեն, անհրաժեշտ է ստեղծել ինֆ սխեմա ցանկալի տվյալների բազայում հետևյալ կերպ.
Ինֆ սխեմայի ստեղծում

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

RAM-ի պակասի հայտնաբերման մեթոդ

RAM-ի բացակայության առաջին ցուցիչը այն դեպքն է, երբ MS SQL Server-ի օրինակը խժռում է իրեն հատկացված ամբողջ RAM-ը։
Դա անելու համար մենք կստեղծենք inf.vRAM-ի հետևյալ ներկայացումը.
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;

Այնուհետև կարող եք որոշել, որ MS SQL Server-ի օրինակը սպառում է իրեն հատկացված ամբողջ հիշողությունը հետևյալ հարցման միջոցով.

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

Եթե SQL_server_physical_memory_in_use_Mb-ը մշտապես մեծ է կամ հավասար է SQL_server_committed_target_Mb-ին, ապա պետք է ստուգել սպասման վիճակագրությունը:
Սպասման վիճակագրության միջոցով RAM-ի պակասը որոշելու համար եկեք ստեղծենք inf.vWaits տեսքը.
Inf.vWaits View-ի ստեղծում

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

Այս դեպքում դուք կարող եք որոշել RAM-ի բացակայությունը հետևյալ հարցմամբ.

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

Այստեղ դուք պետք է ուշադրություն դարձնեք տոկոսային և AvgWait_S ցուցանիշներին: Եթե դրանք նշանակալի են իրենց ամբողջության մեջ, ապա շատ մեծ հավանականություն կա, որ MS SQL Server օրինակի համար բավարար RAM չկա: Նշանակալից արժեքները որոշվում են անհատապես յուրաքանչյուր համակարգի համար: Այնուամենայնիվ, կարող եք սկսել հետևյալից՝ տոկոս>=1 և AvgWait_S>=0.005:
Մոնիտորինգի համակարգ (օրինակ՝ Zabbix) ցուցիչները դուրս բերելու համար կարող եք ստեղծել հետևյալ երկու հարցումները.

Քանի՞ տեսակի սպասումներ են զբաղեցնում RAM-ը տոկոսով (այդպիսի բոլոր տեսակի սպասումների գումարը).

select coalesce(sum([Percentage]), 0.00) as [Percentage]
from [inf].[vWaits]
       where [WaitType] in (
           'PAGEIOLATCH_XX',
           'RESOURCE_SEMAPHORE',
            'RESOURCE_SEMAPHORE_QUERY_COMPILE'
  );

RAM-ի սպասման քանի տեսակներ են տևում միլիվայրկյաններում (բոլոր միջին ուշացումների առավելագույն արժեքը բոլոր այդպիսի սպասման տեսակների համար).
```
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'
  );
```

Այս երկու ցուցանիշների համար ստացված արժեքների դինամիկայի հիման վրա մենք կարող ենք եզրակացնել, թե արդյոք կա բավարար RAM MS SQL Server-ի օրինակի համար:

CPU գերբեռնվածության հայտնաբերման մեթոդ

Պրոցեսորի ժամանակի պակասը բացահայտելու համար բավական է օգտագործել sys.dm_os_schedulers համակարգի տեսքը։ Այստեղ, եթե runnable_tasks_count-ը մշտապես 1-ից մեծ է, ապա մեծ հավանականություն կա, որ միջուկների թիվը բավարար չէ MS SQL Server օրինակի համար։
Մոնիտորինգի համակարգ (օրինակ՝ Zabbix) ցուցիչ դուրս բերելու համար կարող եք ստեղծել հետևյալ հարցումը.

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

Այս ցուցանիշի համար ստացված արժեքների դինամիկայի հիման վրա մենք կարող ենք եզրակացնել, թե արդյոք կա բավարար պրոցեսորի ժամանակը (CPU միջուկների քանակը) MS SQL Server-ի օրինակի համար:
Այնուամենայնիվ, կարևոր է հիշել այն փաստը, որ հարցումներն իրենք կարող են միանգամից մի քանի շղթա պահանջել: Եվ երբեմն օպտիմիզատորը չի կարող ճիշտ գնահատել հարցման բարդությունը: Այնուհետև հարցումին կարող են հատկացվել չափազանց շատ թելեր, որոնք չեն կարող միաժամանակ մշակվել տվյալ պահին: Եվ սա նաև առաջացնում է սպասման մի տեսակ՝ կապված պրոցեսորի ժամանակի պակասի հետ, և հերթի աճը ժամանակացույցների համար, որոնք օգտագործում են հատուկ պրոցեսորի միջուկներ, այսինքն՝ runnable_tasks_count ցուցանիշը կաճի նման պայմաններում:
Այս դեպքում, նախքան պրոցեսորի միջուկների քանակը ավելացնելը, անհրաժեշտ է ճիշտ կարգավորել MS SQL Server-ի օրինակի զուգահեռության հատկությունները, իսկ 2016 թվականի տարբերակից՝ ճիշտ կարգավորել անհրաժեշտ տվյալների բազաների զուգահեռականության հատկությունները.

Այստեղ դուք պետք է ուշադրություն դարձնեք հետևյալ պարամետրերին.

Զուգահեռության առավելագույն աստիճան - սահմանում է թելերի առավելագույն քանակը, որոնք կարող են հատկացվել յուրաքանչյուր հարցումին (կանխադրվածը 0 է - սահմանափակվում է միայն օպերացիոն համակարգով և MS SQL Server-ի խմբագրությամբ)
Զուգահեռության արժեքի շեմ - զուգահեռության գնահատված արժեքը (կանխադրվածը 5 է)
Max DOP - սահմանում է շղթաների առավելագույն քանակը, որոնք կարող են հատկացվել յուրաքանչյուր հարցմանը տվյալների բազայի մակարդակում (բայց ոչ ավելի, քան «Max Degree of Parallelism» հատկության արժեքը) (կանխադրվածը 0 է - սահմանափակվում է միայն օպերացիոն համակարգով և MS SQL Server-ի հրատարակությունը, ինչպես նաև MS SQL Server-ի ամբողջ օրինակի «Զուգահեռության առավելագույն աստիճան» հատկության սահմանափակումը)

Այստեղ անհնար է բոլոր դեպքերի համար հավասարապես լավ բաղադրատոմս տալ, այսինքն՝ պետք է վերլուծել ծանր հարցումները։
Իմ սեփական փորձից ելնելով, ես խորհուրդ եմ տալիս OLTP համակարգերի գործողությունների հետևյալ ալգորիթմը՝ զուգահեռության հատկությունների ստեղծման համար.

նախ անջատեք զուգահեռությունը՝ ամբողջ օրինակի վրա Զուգահեռության առավելագույն աստիճանը դնելով 1-ի
վերլուծել ամենածանր հարցումները և ընտրել դրանց համար թելերի օպտիմալ քանակը
Զուգահեռության առավելագույն աստիճանը սահմանեք 2-րդ քայլից ստացված թելերի ընտրված օպտիմալ քանակին, իսկ հատուկ տվյալների բազաների համար սահմանեք 2-րդ քայլից ստացված Max DOP արժեքը յուրաքանչյուր տվյալների բազայի համար:
վերլուծել ամենածանր խնդրանքները և բացահայտել բազմաթելերի բացասական ազդեցությունը: Եթե դա այդպես է, ապա ավելացրեք Զուգահեռության համար ծախսերի շեմը:
Համակարգերի համար, ինչպիսիք են 1C-ը, Microsoft CRM-ը և Microsoft NAV-ը, շատ դեպքերում հարմար է բազմաթելերի արգելումը

Բացի այդ, եթե կա Ստանդարտ հրատարակություն, ապա շատ դեպքերում բազմաթելերի արգելքը հարմար է այն պատճառով, որ այս հրատարակությունը սահմանափակ է CPU միջուկների քանակով:
OLAP համակարգերի համար վերը նկարագրված ալգորիթմը հարմար չէ:
Իմ սեփական փորձից ելնելով, ես առաջարկում եմ OLAP համակարգերի գործողությունների հետևյալ ալգորիթմը՝ զուգահեռականության հատկությունների ստեղծման համար.

վերլուծել ամենածանր հարցումները և ընտրել դրանց համար թելերի օպտիմալ քանակը
Զուգահեռության առավելագույն աստիճանը սահմանեք 1-րդ քայլից ստացված թելերի ընտրված օպտիմալ քանակին, իսկ հատուկ տվյալների բազաների համար սահմանեք 1-րդ քայլից ստացված Max DOP արժեքը յուրաքանչյուր տվյալների բազայի համար:
վերլուծել ամենածանր հարցումները և բացահայտել միաժամանակության սահմանափակման բացասական ազդեցությունը: Եթե այդպես է, ապա կամ իջեցրեք Զուգահեռության արժեքի արժեքը, կամ կրկնեք այս ալգորիթմի 1-2 քայլերը:

Այսինքն՝ OLTP համակարգերի համար մենք անցնում ենք միաշղթայականից դեպի բազմաթելային, իսկ OLAP համակարգերի համար, ընդհակառակը, բազմաթելայինից անցնում ենք միաթելայինի։ Այսպիսով, դուք կարող եք ընտրել զուգահեռության օպտիմալ կարգավորումները ինչպես հատուկ տվյալների բազայի, այնպես էլ MS SQL Server-ի ամբողջ օրինակի համար:
Կարևոր է նաև հասկանալ, որ զուգահեռության հատկությունների կարգավորումները ժամանակի ընթացքում պետք է փոխվեն՝ հիմնվելով MS SQL Server-ի աշխատանքի մոնիտորինգի արդյունքների վրա:

Ուղեցույցներ հետքի դրոշների տեղադրման համար

Իմ սեփական փորձից և իմ գործընկերների փորձից, օպտիմալ կատարման համար, ես խորհուրդ եմ տալիս MS SQL Server ծառայության գործարկման մակարդակում տեղադրել հետևյալ հետագծային դրոշները 2008-2016 տարբերակների համար.

610 - Նվազեցված ներդիրների գրանցումը ինդեքսավորված աղյուսակներում: Կարող է օգնել բազմաթիվ գրառումներով և բազմաթիվ գործարքներով աղյուսակների ներդիրներով, հաճախակի երկար WRITELOG սպասումներով ինդեքսների փոփոխությունների համար:
1117 - Եթե ֆայլի խմբի ֆայլը համապատասխանում է ինքնաճի շեմի պահանջներին, ֆայլի խմբի բոլոր ֆայլերը մեծանում են
1118 - Ստիպում է բոլոր օբյեկտներին տեղակայել տարբեր չափերով (խառը չափերի արգելում), ինչը նվազագույնի է հասցնում SGAM էջը սկանավորելու անհրաժեշտությունը, որն օգտագործվում է խառը չափերը հետևելու համար:
1224 - Անջատում է կողպեքի էսկալացիան՝ ելնելով կողպեքների քանակից: Այնուամենայնիվ, հիշողության չափից ավելի օգտագործումը կարող է առաջացնել արգելափակման սրացում
2371 - Փոխում է վիճակագրության ավտոմատ թարմացման ֆիքսված շեմը դինամիկ ավտոմատ վիճակագրության թարմացման շեմին: Կարևոր է մեծ աղյուսակների հարցումների պլանները թարմացնելու համար, որտեղ գրառումների սխալ հաշվարկը հանգեցնում է կատարման սխալ պլանների:
3226 - Չեղարկում է պահուստային հաջողության հաղորդագրությունները սխալների մատյանում
4199 - Ներառում է հարցումների օպտիմիզատորի փոփոխությունները, որոնք թողարկվել են CU-ներում և SQL Server ծառայության փաթեթներում
6532-6534 - Ներառում է կատարողականի բարելավում տարածական տվյալների տեսակների վերաբերյալ հարցումների գործողությունների համար
8048 - Փոխակերպում է NUMA բաժանված հիշողության օբյեկտները պրոցեսորի բաժանվածների
8780 - Միացնում է լրացուցիչ ժամանակի բաշխում հարցումների պլանավորման համար: Առանց այս դրոշի որոշ հարցումներ կարող են մերժվել, քանի որ չունեն հարցման պլան (շատ հազվադեպ վրիպակ)
8780 - 9389 - Միացնում է լրացուցիչ դինամիկ դրամաշնորհային հիշողության բուֆեր խմբաքանակի ռեժիմի հայտարարությունների համար, որը թույլ է տալիս խմբաքանակի ռեժիմի օպերատորին պահանջել լրացուցիչ հիշողություն և խուսափել տվյալների տեղափոխումից tempdb, եթե առկա է լրացուցիչ հիշողություն:

Նաև մինչև 2016 թվականը, օգտակար է միացնել հետագծային դրոշակ 2301-ը, որը հնարավորություն է տալիս ընդլայնված որոշումների աջակցության օպտիմալացումներ և այդպիսով օգնում է ընտրել հարցումների ավելի ճիշտ պլաններ: Այնուամենայնիվ, 2016 թվականի տարբերակի դրությամբ այն հաճախ բացասական ազդեցություն է ունենում հարցումների կատարման բավականին երկար ժամանակի վրա:
Նաև շատ ինդեքսներ ունեցող համակարգերի համար (օրինակ՝ 1C տվյալների բազաների համար), ես խորհուրդ եմ տալիս միացնել trace flag 2330, որն անջատում է ինդեքսների օգտագործումը, ինչը ընդհանուր առմամբ դրական է ազդում համակարգի վրա:
Հետքի դրոշների մասին լրացուցիչ տեղեկությունների համար տե՛ս այստեղ
Վերևի հղումից կարևոր է նաև դիտարկել MS SQL Server-ի տարբերակներն ու կառուցումները, քանի որ ավելի նոր տարբերակների համար որոշ հետագծային դրոշներ լռելյայն միացված են կամ ազդեցություն չունեն:
Դուք կարող եք միացնել և անջատել հետքի դրոշակը համապատասխանաբար DBCC TRACEON և DBCC TRACEOFF հրամաններով: Լրացուցիչ մանրամասների համար տե՛ս այստեղ
Դուք կարող եք ստանալ հետքի դրոշակների կարգավիճակը՝ օգտագործելով DBCC TRACESTATUS հրամանը. ավելի շատ
Որպեսզի հետագծային դրոշները ներառվեն MS SQL Server ծառայության ավտոմատ մեկնարկի մեջ, դուք պետք է գնաք SQL Server-ի կազմաձևման կառավարիչ և ավելացնեք այս հետագծային դրոշները -T-ի միջոցով ծառայության հատկություններում.

Արդյունքները

Այս հոդվածում վերլուծվել են MS SQL Server-ի մոնիտորինգի որոշ ասպեկտներ, որոնց օգնությամբ դուք կարող եք արագ բացահայտել RAM-ի և CPU-ի ազատ ժամանակի բացակայությունը, ինչպես նաև մի շարք այլ ոչ այնքան ակնհայտ խնդիրներ: Վերանայվել են առավել հաճախ օգտագործվող հետքի դրոշները:

Աղբյուրները

» SQL Server սպասման վիճակագրություն
» SQL Server-ի սպասման վիճակագրություն կամ խնդրում եմ ասեք, թե որտեղ է դա ցավում
» Համակարգի դիտում sys.dm_os_schedulers
» Օգտագործելով Zabbix-ը MS SQL Server տվյալների բազան մոնիտորինգի համար
» SQL Lifestyle
» Հետք դրոշներ
» sql.ru

Source: www.habr.com

MS SQL Server մոնիտորինգի որոշ ասպեկտներ: Ուղեցույցներ հետքի դրոշների տեղադրման համար