🥇MS SQL సర్వర్‌ను పర్యవేక్షించే కొన్ని అంశాలు. ట్రేస్ ఫ్లాగ్‌లను సెట్ చేయడానికి సిఫార్సులు

ముందుమాట

చాలా తరచుగా, MS SQL సర్వర్ DBMS యొక్క వినియోగదారులు, డెవలపర్లు మరియు నిర్వాహకులు డేటాబేస్ లేదా మొత్తం DBMS యొక్క పనితీరు సమస్యలను ఎదుర్కొంటారు, కాబట్టి MS SQL సర్వర్‌ను పర్యవేక్షించడం చాలా సందర్భోచితంగా ఉంటుంది.
ఈ వ్యాసం వ్యాసానికి అదనం MS SQL సర్వర్ డేటాబేస్‌ను పర్యవేక్షించడానికి Zabbixని ఉపయోగించడం మరియు ఇది ప్రత్యేకంగా MS SQL సర్వర్‌ని పర్యవేక్షించే కొన్ని అంశాలను పరిశీలిస్తుంది: ఏ వనరులు తప్పిపోయాయో త్వరగా ఎలా గుర్తించాలి, అలాగే ట్రేస్ ఫ్లాగ్‌లను సెటప్ చేయడానికి సిఫార్సులు.
కింది స్క్రిప్ట్‌లు పని చేయడానికి, మీరు ఈ క్రింది విధంగా కావలసిన డేటాబేస్‌లో inf స్కీమాను సృష్టించాలి:
ఇన్ఫ్ స్కీమాను సృష్టిస్తోంది

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

RAM లోపాన్ని గుర్తించే విధానం

MS SQL సర్వర్ యొక్క ఒక ఉదాహరణ దానికి కేటాయించిన మొత్తం RAMని తినేస్తే, 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 సర్వర్ యొక్క ఉదాహరణ కింది ప్రశ్నను ఉపయోగించి దానికి కేటాయించిన మొత్తం మెమరీని వినియోగిస్తోందని మీరు నిర్ధారించవచ్చు:

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 వీక్షణను సృష్టిస్తోంది

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 సర్వర్ ఇన్‌స్టాన్స్‌లో తగినంత 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'
  );
```

ఈ రెండు సూచికల కోసం పొందిన విలువల డైనమిక్స్ ఆధారంగా, MS SQL సర్వర్ ఉదాహరణకి తగినంత RAM ఉందో లేదో మేము నిర్ధారించగలము.

అధిక CPU లోడ్‌ను గుర్తించే విధానం

CPU సమయం లేకపోవడాన్ని గుర్తించడానికి, sys.dm_os_schedulers సిస్టమ్ వీక్షణను ఉపయోగించండి. ఇక్కడ, runnable_tasks_count సూచిక నిరంతరం 1 కంటే ఎక్కువగా ఉంటే, MS SQL సర్వర్ ఉదాహరణకి కోర్ల సంఖ్య సరిపోకపోయే అధిక సంభావ్యత ఉంది.
పర్యవేక్షణ వ్యవస్థలో సూచికను ప్రదర్శించడానికి (ఉదాహరణకు, Zabbix), మీరు క్రింది అభ్యర్థనను సృష్టించవచ్చు:

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

ఈ సూచిక కోసం పొందిన విలువల యొక్క డైనమిక్స్ ఆధారంగా, MS SQL సర్వర్ ఉదాహరణ కోసం తగినంత ప్రాసెసర్ సమయం (CPU కోర్ల సంఖ్య) ఉందో లేదో మేము నిర్ధారించగలము.
అయితే, ప్రశ్నలే ఒకేసారి బహుళ థ్రెడ్‌లను ప్రశ్నించగలవు అనే వాస్తవాన్ని గుర్తుంచుకోవడం ముఖ్యం. మరియు కొన్నిసార్లు ఆప్టిమైజర్ ప్రశ్న యొక్క సంక్లిష్టతను సరిగ్గా అంచనా వేయదు. అప్పుడు అభ్యర్థనకు చాలా ఎక్కువ థ్రెడ్‌లు కేటాయించబడవచ్చు, ఇది ఒక నిర్దిష్ట సమయంలో ఏకకాలంలో ప్రాసెస్ చేయబడదు. మరియు ఇది ప్రాసెసర్ సమయం లేకపోవడంతో అనుబంధించబడిన ఒక రకమైన నిరీక్షణకు కారణమవుతుంది మరియు నిర్దిష్ట CPU కోర్లను ఉపయోగించే షెడ్యూలర్‌ల కోసం క్యూ పెరుగుదల, అంటే, అటువంటి పరిస్థితుల్లో runnable_tasks_count సూచిక పెరుగుతుంది.
ఈ సందర్భంలో, CPU కోర్ల సంఖ్యను పెంచే ముందు, మీరు MS SQL సర్వర్ ఉదాహరణ యొక్క సమాంతర లక్షణాలను సరిగ్గా కాన్ఫిగర్ చేయాలి మరియు వెర్షన్ 2016 నుండి, కావలసిన డేటాబేస్‌ల సమాంతర లక్షణాలను సరిగ్గా కాన్ఫిగర్ చేయాలి:

ఇక్కడ మీరు ఈ క్రింది పారామితులకు శ్రద్ధ వహించాలి:

సమాంతరత యొక్క గరిష్ట డిగ్రీ-ప్రతి అభ్యర్థనకు కేటాయించబడే గరిష్ట థ్రెడ్‌ల సంఖ్యను సెట్ చేస్తుంది (డిఫాల్ట్ 0-ఆపరేటింగ్ సిస్టమ్ మరియు MS SQL సర్వర్ ఎడిషన్ ద్వారా మాత్రమే పరిమితం చేయబడింది)
సమాంతరత కోసం ఖర్చు థ్రెషోల్డ్ - సమాంతరత యొక్క అంచనా వ్యయం (డిఫాల్ట్ 5)
Max DOP—డేటాబేస్ స్థాయిలో ప్రతి ప్రశ్నకు కేటాయించబడే గరిష్ట థ్రెడ్‌ల సంఖ్యను సెట్ చేస్తుంది (కానీ "మాక్స్ డిగ్రీ ఆఫ్ ప్యారలలిజం" ప్రాపర్టీ విలువ కంటే ఎక్కువ కాదు) (డిఫాల్ట్‌గా ఇది 0-కేవలం ఆపరేటింగ్ సిస్టమ్ ద్వారా పరిమితం చేయబడింది స్వయంగా మరియు MS SQL సర్వర్ యొక్క ఎడిషన్, అలాగే మొత్తం MS SQL సర్వర్ ఉదాహరణ యొక్క "మాక్స్ డిగ్రీ ఆఫ్ ప్యారలలిజం" ప్రాపర్టీపై పరిమితి)

అన్ని సందర్భాల్లో సమానంగా మంచి రెసిపీని ఇవ్వడం అసాధ్యం, అంటే, మీరు కష్టమైన ప్రశ్నలను విశ్లేషించాలి.
నా స్వంత అనుభవం ఆధారంగా, సమాంతరత లక్షణాలను కాన్ఫిగర్ చేయడానికి OLTP సిస్టమ్‌ల కోసం నేను క్రింది చర్యల అల్గారిథమ్‌ని సిఫార్సు చేస్తున్నాను:

మొత్తం ఉదాహరణ స్థాయిలో సమాంతరత యొక్క గరిష్ట డిగ్రీని 1కి సెట్ చేయడం ద్వారా మొదట సమాంతరతను నిలిపివేయండి
భారీ ప్రశ్నలను విశ్లేషించి, వాటి కోసం సరైన సంఖ్యలో థ్రెడ్‌లను ఎంచుకోండి
స్టెప్ 2 నుండి పొందిన థ్రెడ్‌ల యొక్క ఎంచుకున్న సరైన సంఖ్యకు సమాంతరత యొక్క గరిష్ట డిగ్రీని సెట్ చేయండి మరియు నిర్దిష్ట డేటాబేస్‌ల కోసం ప్రతి డేటాబేస్ కోసం దశ 2 నుండి పొందిన గరిష్ట DOP విలువను సెట్ చేయండి
భారీ ప్రశ్నలను విశ్లేషించండి మరియు మల్టీథ్రెడింగ్ యొక్క ప్రతికూల ప్రభావాన్ని గుర్తించండి. అలా అయితే, సమాంతరత కోసం ఖర్చు థ్రెషోల్డ్‌ని పెంచండి.
1C, Microsoft CRM మరియు Microsoft NAV వంటి సిస్టమ్‌ల కోసం, చాలా సందర్భాలలో మల్టీథ్రెడింగ్‌ను నిషేధించడం సరైనది

అలాగే, మీరు స్టాండర్డ్ ఎడిషన్‌ని కలిగి ఉంటే, చాలా సందర్భాలలో ఈ ఎడిషన్ CPU కోర్ల సంఖ్యలో పరిమితం చేయబడినందున బహుళ-థ్రెడింగ్‌పై నిషేధం సరైనది.
పైన వివరించిన అల్గోరిథం OLAP సిస్టమ్‌లకు తగినది కాదు.
నా స్వంత అనుభవం ఆధారంగా, సమాంతరత లక్షణాలను కాన్ఫిగర్ చేయడానికి OLAP సిస్టమ్‌ల కోసం నేను క్రింది చర్యల అల్గారిథమ్‌ని సిఫార్సు చేస్తున్నాను:

భారీ ప్రశ్నలను విశ్లేషించి, వాటి కోసం సరైన సంఖ్యలో థ్రెడ్‌లను ఎంచుకోండి
స్టెప్ 1 నుండి పొందిన థ్రెడ్‌ల యొక్క ఎంచుకున్న సరైన సంఖ్యకు సమాంతరత యొక్క గరిష్ట డిగ్రీని సెట్ చేయండి మరియు నిర్దిష్ట డేటాబేస్‌ల కోసం ప్రతి డేటాబేస్ కోసం దశ 1 నుండి పొందిన గరిష్ట DOP విలువను సెట్ చేయండి
భారీ ప్రశ్నలను విశ్లేషించండి మరియు సమకాలీకరణను పరిమితం చేయడం వల్ల కలిగే ప్రతికూల ప్రభావాన్ని గుర్తించండి. అలా అయితే, సమాంతరత విలువ కోసం ధర థ్రెషోల్డ్‌ని తగ్గించండి లేదా ఈ అల్గారిథమ్‌లోని 1-2 దశలను పునరావృతం చేయండి

అంటే, OLTP సిస్టమ్‌ల కోసం మేము సింగిల్-థ్రెడింగ్ నుండి మల్టీ-థ్రెడింగ్‌కు వెళ్తాము మరియు OLAP సిస్టమ్‌ల కోసం, దీనికి విరుద్ధంగా, మేము మల్టీ-థ్రెడింగ్ నుండి సింగిల్-థ్రెడింగ్‌కి వెళ్తాము. ఈ విధంగా మీరు నిర్దిష్ట డేటాబేస్ మరియు మొత్తం MS SQL సర్వర్ ఉదాహరణ కోసం సరైన సమాంతరత సెట్టింగ్‌లను ఎంచుకోవచ్చు.
MS SQL సర్వర్ పనితీరును పర్యవేక్షించే ఫలితాల ఆధారంగా, కాలక్రమేణా కాన్‌కరెన్సీ ప్రాపర్టీస్ సెట్టింగ్‌లు మార్చబడాలని అర్థం చేసుకోవడం కూడా చాలా ముఖ్యం.

ట్రేస్ ఫ్లాగ్‌లను సెట్ చేయడానికి సిఫార్సులు

నా స్వంత అనుభవం మరియు నా సహోద్యోగుల అనుభవం నుండి, సరైన పనితీరు కోసం, 2008-2016 వెర్షన్‌ల కోసం MS SQL సర్వర్ సర్వీస్ రన్ లెవెల్‌లో క్రింది ట్రేస్ ఫ్లాగ్‌లను సెట్ చేయమని నేను సిఫార్సు చేస్తున్నాను:

610 - ఇండెక్స్ చేయబడిన పట్టికలలోకి ఇన్సర్ట్‌ల లాగింగ్‌ను తగ్గించండి. పెద్ద సంఖ్యలో రికార్డులు మరియు అనేక లావాదేవీలతో పట్టికలలోకి ఇన్సర్ట్ చేయడంలో సహాయపడవచ్చు, తరచుగా సుదీర్ఘమైన WRITELOG ఇండెక్స్‌లలో మార్పుల కోసం వేచి ఉంటుంది
1117 - ఫైల్‌గ్రూప్‌లోని ఫైల్ ఆటో-గ్రో థ్రెషోల్డ్‌కు అనుగుణంగా ఉంటే, ఫైల్‌గ్రూప్‌లోని అన్ని ఫైల్‌లు పెరుగుతాయి
1118 - అన్ని ఆబ్జెక్ట్‌లను వేర్వేరు ఎక్స్‌టెండ్‌లలో ఉండేలా బలవంతం చేస్తుంది (మిశ్రమ విస్తరణలను అనుమతించదు), ఇది మిశ్రమ విస్తరణలను ట్రాక్ చేయడానికి ఉపయోగించే SGAM పేజీని స్కాన్ చేయవలసిన అవసరాన్ని తగ్గిస్తుంది.
1224 - లాక్ కౌంట్ ఆధారంగా లాక్ ఎస్కలేషన్‌ను నిలిపివేస్తుంది. అయినప్పటికీ, అధిక మెమరీ వినియోగం లాక్ ఎస్కలేషన్‌ను ప్రారంభించగలదు
2371 - స్థిర ఆటోమేటిక్ స్టాటిస్టిక్స్ అప్‌డేట్ థ్రెషోల్డ్‌ను డైనమిక్ ఆటోమేటిక్ స్టాటిస్టిక్స్ అప్‌డేట్ థ్రెషోల్డ్‌కి మారుస్తుంది. పెద్ద టేబుల్‌లపై ప్రశ్న ప్లాన్‌లను అప్‌డేట్ చేయడం ముఖ్యం, ఇక్కడ రికార్డుల సంఖ్యను తప్పుగా నిర్వచించడం వలన తప్పు అమలు ప్రణాళికలు ఏర్పడతాయి
3226 - ఎర్రర్ లాగ్‌లో బ్యాకప్ విజయ సందేశాలను అణిచివేస్తుంది
4199 - SQL సర్వర్ అప్‌డేట్ రోల్‌అప్‌లు మరియు సర్వీస్ ప్యాక్‌లలో విడుదలైన క్వెరీ ఆప్టిమైజర్‌కు మార్పులను కలిగి ఉంటుంది
6532-6534 - ప్రాదేశిక డేటా రకాలతో ప్రశ్నల కోసం పనితీరు మెరుగుదలలను కలిగి ఉంటుంది
8048 - NUMA-విభజించిన మెమరీ ఆబ్జెక్ట్‌లను CPU-విభజించిన వాటికి మారుస్తుంది
8780 - ప్రశ్న ప్రణాళిక కోసం అదనపు సమయ కేటాయింపును ప్రారంభిస్తుంది. ఈ ఫ్లాగ్ లేని కొన్ని అభ్యర్థనలు తిరస్కరించబడవచ్చు ఎందుకంటే వాటికి ప్రశ్న ప్రణాళిక లేదు (చాలా అరుదైన లోపం)
8780 - 9389 - బ్యాచ్ మోడ్ ఆపరేటర్‌ల కోసం అదనపు డైనమిక్ తాత్కాలిక మెమరీ బఫర్‌ను ప్రారంభిస్తుంది, అదనపు మెమరీని అభ్యర్థించడానికి బ్యాచ్ మోడ్ ఆపరేటర్‌ను అనుమతిస్తుంది మరియు అదనపు మెమరీ అందుబాటులో ఉంటే tempdbకి డేటాను బదిలీ చేయకుండా చేస్తుంది

సంస్కరణ 2016కి ముందు ట్రేస్ ఫ్లాగ్ 2301ని ప్రారంభించడం కూడా ఉపయోగకరంగా ఉంటుంది, ఇది అధునాతన నిర్ణయ మద్దతు ఆప్టిమైజేషన్‌ను ప్రారంభిస్తుంది మరియు తద్వారా మెరుగైన ప్రశ్న ప్రణాళికలను ఎంచుకోవడంలో సహాయపడుతుంది. అయినప్పటికీ, వెర్షన్ 2016 నుండి, ఇది చాలా ఎక్కువ మొత్తం ప్రశ్న అమలు సమయాలపై తరచుగా ప్రతికూల ప్రభావాన్ని చూపుతుంది.
అలాగే, చాలా ఇండెక్స్‌లు ఉన్న సిస్టమ్‌ల కోసం (ఉదాహరణకు, 1C డేటాబేస్‌ల కోసం), ట్రేస్ ఫ్లాగ్ 2330ని ప్రారంభించాలని నేను సిఫార్సు చేస్తున్నాను, ఇది ఇండెక్స్ వినియోగ సేకరణను నిలిపివేస్తుంది, ఇది సాధారణంగా సిస్టమ్‌పై సానుకూల ప్రభావాన్ని చూపుతుంది.
మీరు ట్రేస్ ఫ్లాగ్‌ల గురించి మరింత తెలుసుకోవచ్చు ఇక్కడ
ఎగువ లింక్ నుండి, MS SQL సర్వర్ యొక్క సంస్కరణలు మరియు బిల్డ్‌లను పరిగణనలోకి తీసుకోవడం కూడా చాలా ముఖ్యం, కొత్త వెర్షన్‌ల కోసం, కొన్ని ట్రేస్ ఫ్లాగ్‌లు డిఫాల్ట్‌గా ప్రారంభించబడతాయి లేదా ప్రభావం చూపవు.
మీరు వరుసగా DBCC TRACEON మరియు DBCC TRACEOFF ఆదేశాలను ఉపయోగించి ట్రేస్ ఫ్లాగ్‌ను ప్రారంభించవచ్చు లేదా నిలిపివేయవచ్చు. మరిన్ని వివరాలను చూడండి ఇక్కడ
మీరు DBCC TRACESTATUS ఆదేశాన్ని ఉపయోగించి ట్రేస్ ఫ్లాగ్‌ల స్థితిని పొందవచ్చు: మరింత సమాచారం
MS SQL సర్వర్ సేవ యొక్క ఆటోస్టార్ట్‌లో ట్రేస్ ఫ్లాగ్‌లను చేర్చడానికి, మీరు SQL సర్వర్ కాన్ఫిగరేషన్ మేనేజర్‌కి వెళ్లి, సేవా లక్షణాలలో -T ద్వారా ఈ ట్రేస్ ఫ్లాగ్‌లను జోడించాలి:

ఫలితాలు

ఈ వ్యాసం MS SQL సర్వర్‌ను పర్యవేక్షించే కొన్ని అంశాలను పరిశీలించింది, దీని సహాయంతో మీరు RAM మరియు ఉచిత CPU సమయం లేకపోవడం, అలాగే అనేక ఇతర తక్కువ స్పష్టమైన సమస్యలను త్వరగా గుర్తించవచ్చు. అత్యంత సాధారణంగా ఉపయోగించే ట్రేస్ ఫ్లాగ్‌లు సమీక్షించబడ్డాయి.

వర్గాలు:

» SQL సర్వర్ నిరీక్షణ గణాంకాలు
» SQL సర్వర్ గణాంకాల కోసం వేచి ఉండండి లేదా దయచేసి ఎక్కడ బాధిస్తుందో చెప్పండి
» సిస్టమ్ వీక్షణ sys.dm_os_schedulers
» MS SQL సర్వర్ డేటాబేస్‌ను పర్యవేక్షించడానికి Zabbixని ఉపయోగించడం
» SQL జీవనశైలి
» ట్రేస్ జెండాలు
» sql.ru

మూలం: www.habr.com

MS SQL సర్వర్‌ను పర్యవేక్షించే కొన్ని అంశాలు. ట్రేస్ ఫ్లాగ్‌లను సెట్ చేయడానికి సిఫార్సులు