🥇MS SQL सर्वर की निगरानी के कुछ पहलू। ट्रेस फ़्लैग स्थापित करने के लिए दिशानिर्देश

प्रस्तावना

अक्सर, MS SQL सर्वर DBMS के उपयोगकर्ता, डेवलपर्स और प्रशासक डेटाबेस या संपूर्ण DBMS की प्रदर्शन समस्याओं का सामना करते हैं, इसलिए MS SQL सर्वर मॉनिटरिंग बहुत प्रासंगिक है।
यह लेख लेख के अतिरिक्त है एमएस एसक्यूएल सर्वर डेटाबेस की निगरानी के लिए ज़ैबिक्स का उपयोग करना और इसमें एमएस एसक्यूएल सर्वर की निगरानी के कुछ पहलुओं को शामिल किया जाएगा, विशेष रूप से: कैसे जल्दी से निर्धारित किया जाए कि कौन से संसाधन गायब हैं, साथ ही ट्रेस फ्लैग सेट करने के लिए सिफारिशें भी।
निम्नलिखित स्क्रिप्ट को काम करने के लिए, आपको वांछित डेटाबेस में निम्नानुसार एक inf स्कीमा बनाने की आवश्यकता है:
एक inf स्कीमा बनाना

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

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 से अधिक या उसके बराबर है, तो प्रतीक्षा आँकड़ों की जाँच की जानी चाहिए।
प्रतीक्षा आंकड़ों के माध्यम से रैम की कमी का निर्धारण करने के लिए, आइए 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 सर्वर उदाहरण के लिए पर्याप्त RAM नहीं है। प्रत्येक प्रणाली के लिए महत्वपूर्ण मान व्यक्तिगत रूप से निर्धारित किए जाते हैं। हालाँकि, आप निम्नलिखित से शुरुआत कर सकते हैं: प्रतिशत>=1 और औसतWait_S>=0.005।
मॉनिटरिंग सिस्टम (उदाहरण के लिए, ज़ैबिक्स) में संकेतक आउटपुट करने के लिए, आप निम्नलिखित दो क्वेरीज़ बना सकते हैं:

प्रतिशत में RAM द्वारा कितने प्रकार की प्रतीक्षा की जाती है (ऐसे सभी प्रकार की प्रतीक्षा का योग):
```
select coalesce(sum([Percentage]), 0.00) as [Percentage]
from [inf].[vWaits]
       where [WaitType] in (
           'PAGEIOLATCH_XX',
           'RESOURCE_SEMAPHORE',
            'RESOURCE_SEMAPHORE_QUERY_COMPILE'
  );
```
मिलीसेकंड में कितने रैम प्रतीक्षा प्रकार लगते हैं (ऐसे सभी प्रतीक्षा प्रकारों के लिए सभी औसत विलंब का अधिकतम मूल्य):
```
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 है या नहीं।

सीपीयू अधिभार का पता लगाने की विधि

प्रोसेसर समय की कमी की पहचान करने के लिए, sys.dm_os_schedulers सिस्टम दृश्य का उपयोग करना पर्याप्त है। यहां, यदि runnable_tasks_count लगातार 1 से अधिक है, तो इस बात की बहुत अधिक संभावना है कि MS SQL सर्वर इंस्टेंस के लिए कोर की संख्या पर्याप्त नहीं है।
किसी मॉनिटरिंग सिस्टम (उदाहरण के लिए, ज़ैबिक्स) में एक संकेतक आउटपुट करने के लिए, आप निम्नलिखित क्वेरी बना सकते हैं:

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

इस सूचक के लिए प्राप्त मूल्यों की गतिशीलता के आधार पर, हम यह निष्कर्ष निकाल सकते हैं कि MS SQL सर्वर के उदाहरण के लिए पर्याप्त प्रोसेसर समय (सीपीयू कोर की संख्या) है या नहीं।
हालाँकि, इस तथ्य को ध्यान में रखना महत्वपूर्ण है कि अनुरोध स्वयं एक साथ कई थ्रेड का अनुरोध कर सकते हैं। और कभी-कभी ऑप्टिमाइज़र क्वेरी की जटिलता का सही अनुमान नहीं लगा पाता है। फिर अनुरोध को बहुत सारे थ्रेड आवंटित किए जा सकते हैं जिन्हें दिए गए समय पर एक ही समय में संसाधित नहीं किया जा सकता है। और यह प्रोसेसर समय की कमी से जुड़े एक प्रकार के इंतजार का भी कारण बनता है, और विशिष्ट सीपीयू कोर का उपयोग करने वाले शेड्यूलरों के लिए कतार की वृद्धि, यानी ऐसी स्थितियों में runnable_tasks_count संकेतक बढ़ेगा।
इस मामले में, सीपीयू कोर की संख्या बढ़ाने से पहले, एमएस एसक्यूएल सर्वर इंस्टेंस के समानांतरवाद गुणों को सही ढंग से कॉन्फ़िगर करना आवश्यक है, और 2016 संस्करण से, आवश्यक डेटाबेस के समानांतरवाद गुणों को सही ढंग से कॉन्फ़िगर करना आवश्यक है:

यहां आपको निम्नलिखित मापदंडों पर ध्यान देना चाहिए:

समांतरता की अधिकतम डिग्री - प्रत्येक अनुरोध के लिए आवंटित किए जा सकने वाले थ्रेड्स की अधिकतम संख्या निर्धारित करती है (डिफ़ॉल्ट 0 है - केवल ऑपरेटिंग सिस्टम और MS SQL सर्वर के संस्करण द्वारा सीमित)
समांतरता के लिए लागत सीमा - समांतरता की अनुमानित लागत (डिफ़ॉल्ट 5 है)
अधिकतम डीओपी - थ्रेड्स की अधिकतम संख्या निर्धारित करता है जिसे डेटाबेस स्तर पर प्रत्येक क्वेरी के लिए आवंटित किया जा सकता है (लेकिन "समानांतरता की अधिकतम डिग्री" संपत्ति के मूल्य से अधिक नहीं) (डिफ़ॉल्ट 0 है - केवल ऑपरेटिंग सिस्टम द्वारा ही सीमित है और MS SQL सर्वर का संस्करण, साथ ही MS SQL सर्वर के संपूर्ण उदाहरण की "समानांतरता की अधिकतम डिग्री" संपत्ति पर प्रतिबंध)

यहां सभी मामलों के लिए समान रूप से अच्छा नुस्खा देना असंभव है, यानी आपको भारी प्रश्नों का विश्लेषण करने की आवश्यकता है।
अपने स्वयं के अनुभव से, मैं समांतरता गुणों को स्थापित करने के लिए ओएलटीपी सिस्टम के लिए क्रियाओं के निम्नलिखित एल्गोरिदम की अनुशंसा करता हूं:

सबसे पहले उदाहरण-व्यापी अधिकतम समानता की डिग्री को 1 पर सेट करके समानता को अक्षम करें
सबसे भारी अनुरोधों का विश्लेषण करें और उनके लिए थ्रेड की इष्टतम संख्या का चयन करें
चरण 2 से प्राप्त थ्रेड्स की चयनित इष्टतम संख्या के लिए समानांतरवाद की अधिकतम डिग्री सेट करें, और विशिष्ट डेटाबेस के लिए प्रत्येक डेटाबेस के लिए चरण 2 से प्राप्त अधिकतम डीओपी मान सेट करें
सबसे भारी अनुरोधों का विश्लेषण करें और मल्टीथ्रेडिंग के नकारात्मक प्रभाव की पहचान करें। यदि ऐसा है, तो समांतरता के लिए लागत सीमा बढ़ाएँ।
1सी, माइक्रोसॉफ्ट सीआरएम और माइक्रोसॉफ्ट एनएवी जैसे सिस्टम के लिए, ज्यादातर मामलों में, मल्टीथ्रेडिंग को प्रतिबंधित करना उपयुक्त है

इसके अलावा, यदि कोई मानक संस्करण है, तो ज्यादातर मामलों में मल्टीथ्रेडिंग का निषेध इस तथ्य के कारण उपयुक्त है कि यह संस्करण सीपीयू कोर की संख्या में सीमित है।
OLAP सिस्टम के लिए, ऊपर वर्णित एल्गोरिदम उपयुक्त नहीं है।
अपने स्वयं के अनुभव से, मैं समांतरता गुणों को स्थापित करने के लिए OLAP सिस्टम के लिए क्रियाओं के निम्नलिखित एल्गोरिदम की अनुशंसा करता हूं:

सबसे भारी अनुरोधों का विश्लेषण करें और उनके लिए थ्रेड की इष्टतम संख्या का चयन करें
चरण 1 से प्राप्त थ्रेड्स की चयनित इष्टतम संख्या के लिए समानांतरवाद की अधिकतम डिग्री सेट करें, और विशिष्ट डेटाबेस के लिए प्रत्येक डेटाबेस के लिए चरण 1 से प्राप्त अधिकतम डीओपी मान सेट करें
सबसे भारी प्रश्नों का विश्लेषण करें और समवर्तीता को सीमित करने के नकारात्मक प्रभाव की पहचान करें। यदि ऐसा है, तो या तो समांतरता मान के लिए लागत सीमा कम करें, या इस एल्गोरिदम के चरण 1-2 को दोहराएं

यानी, ओएलटीपी सिस्टम के लिए हम सिंगल-थ्रेडिंग से मल्टी-थ्रेडिंग की ओर जाते हैं, और ओएलएपी-सिस्टम के लिए, इसके विपरीत, हम मल्टी-थ्रेडिंग से सिंगल-थ्रेडिंग की ओर जाते हैं। इस प्रकार, आप एक विशिष्ट डेटाबेस और MS SQL सर्वर के संपूर्ण उदाहरण दोनों के लिए इष्टतम समानता सेटिंग्स चुन सकते हैं।
यह समझना भी महत्वपूर्ण है कि MS SQL सर्वर के प्रदर्शन की निगरानी के परिणामों के आधार पर, समांतरता गुणों की सेटिंग्स को समय के साथ बदलने की आवश्यकता है।

ट्रेस फ़्लैग स्थापित करने के लिए दिशानिर्देश

अपने स्वयं के अनुभव और अपने सहकर्मियों के अनुभव से, इष्टतम प्रदर्शन के लिए, मैं संस्करण 2008-2016 के लिए MS SQL सर्वर सेवा के रन स्तर पर निम्नलिखित ट्रेस फ़्लैग सेट करने की अनुशंसा करता हूँ:

610 - अनुक्रमित तालिकाओं में प्रविष्टियों की कम लॉगिंग। कई रिकॉर्ड्स और कई लेन-देन वाली तालिकाओं में प्रविष्टियों में मदद मिल सकती है, लगातार लंबे समय तक WRITELOG अनुक्रमणिका में बदलावों की प्रतीक्षा करता है
1117 - यदि फ़ाइल समूह में कोई फ़ाइल ऑटोग्रोथ थ्रेशोल्ड आवश्यकताओं को पूरा करती है, तो फ़ाइल समूह की सभी फ़ाइलें बढ़ती हैं
1118 - सभी वस्तुओं को अलग-अलग विस्तारों में स्थित होने के लिए बाध्य करता है (मिश्रित विस्तारों का निषेध), जो एसजीएएम पृष्ठ को स्कैन करने की आवश्यकता को कम करता है, जिसका उपयोग मिश्रित विस्तारों को ट्रैक करने के लिए किया जाता है
1224 - तालों की संख्या के आधार पर ताला वृद्धि को अक्षम करता है। हालाँकि, अत्यधिक मेमोरी उपयोग लॉक एस्केलेशन को ट्रिगर कर सकता है
2371 - निश्चित स्वचालित सांख्यिकी अद्यतन सीमा को गतिशील स्वचालित सांख्यिकी अद्यतन सीमा में बदलता है। बड़ी तालिकाओं के लिए क्वेरी योजनाओं को अद्यतन करने के लिए महत्वपूर्ण है, जहां रिकॉर्ड की गलत गणना के परिणामस्वरूप गलत निष्पादन योजनाएं बनती हैं
3226 - त्रुटि लॉग में बैकअप सफलता संदेशों को दबा देता है
4199 - सीयू और एसक्यूएल सर्वर सर्विस पैक में जारी क्वेरी ऑप्टिमाइज़र में परिवर्तन शामिल हैं
6532-6534 - स्थानिक डेटा प्रकारों पर क्वेरी संचालन के लिए प्रदर्शन सुधार शामिल है
8048 - NUMA विभाजित मेमोरी ऑब्जेक्ट को CPU विभाजित मेमोरी ऑब्जेक्ट में परिवर्तित करता है
8780 - क्वेरी योजना के लिए अतिरिक्त समय आवंटन सक्षम करता है। इस ध्वज के बिना कुछ अनुरोध अस्वीकार किए जा सकते हैं क्योंकि उनके पास कोई क्वेरी योजना नहीं है (बहुत दुर्लभ बग)
8780 - 9389 - बैच मोड स्टेटमेंट के लिए अतिरिक्त डायनेमिक ग्रांट मेमोरी बफर को सक्षम करता है, जो बैच मोड ऑपरेटर को अतिरिक्त मेमोरी का अनुरोध करने और अतिरिक्त मेमोरी उपलब्ध होने पर डेटा को tempdb पर ले जाने से बचने की अनुमति देता है।

इसके अलावा 2016 से पहले, ट्रेस फ़्लैग 2301 को सक्षम करना उपयोगी है, जो उन्नत निर्णय समर्थन अनुकूलन को सक्षम बनाता है और इस प्रकार अधिक सही क्वेरी योजनाओं को चुनने में मदद करता है। हालाँकि, संस्करण 2016 के अनुसार, इसका अक्सर लंबे समग्र क्वेरी निष्पादन समय पर नकारात्मक प्रभाव पड़ता है।
साथ ही, बहुत सारे इंडेक्स वाले सिस्टम के लिए (उदाहरण के लिए, 1सी डेटाबेस के लिए), मैं ट्रेस फ्लैग 2330 को सक्षम करने की सलाह देता हूं, जो इंडेक्स उपयोग के संग्रह को अक्षम कर देता है, जिसका आमतौर पर सिस्टम पर सकारात्मक प्रभाव पड़ता है।
ट्रेस फ़्लैग के बारे में अधिक जानकारी के लिए देखें यहां
उपरोक्त लिंक से, MS SQL सर्वर के संस्करणों और बिल्ड पर विचार करना भी महत्वपूर्ण है, क्योंकि नए संस्करणों के लिए, कुछ ट्रेस फ़्लैग डिफ़ॉल्ट रूप से सक्षम होते हैं या उनका कोई प्रभाव नहीं होता है।
आप क्रमशः DBCC TRACEON और DBCC TRACEOFF कमांड के साथ ट्रेस फ़्लैग को चालू और बंद कर सकते हैं। अधिक जानकारी के लिए देखें यहां
आप DBCC TRACESTATUS कमांड का उपयोग करके ट्रेस फ़्लैग की स्थिति प्राप्त कर सकते हैं: अधिक
MS SQL सर्वर सेवा के ऑटोस्टार्ट में ट्रेस फ़्लैग को शामिल करने के लिए, आपको SQL सर्वर कॉन्फ़िगरेशन प्रबंधक पर जाना होगा और सेवा गुणों में -T के माध्यम से इन ट्रेस फ़्लैग को जोड़ना होगा:

परिणाम

इस आलेख में, MS SQL सर्वर की निगरानी के कुछ पहलुओं का विश्लेषण किया गया, जिसकी सहायता से आप RAM की कमी और खाली CPU समय के साथ-साथ कई अन्य कम स्पष्ट समस्याओं की तुरंत पहचान कर सकते हैं। सबसे अधिक उपयोग किए जाने वाले ट्रेस फ़्लैग की समीक्षा की गई है।

सूत्रों का कहना है:

» SQL सर्वर प्रतीक्षा आँकड़े
» SQL सर्वर प्रतीक्षा आँकड़े या कृपया मुझे बताएं कि यह कहाँ दर्द देता है
» सिस्टम दृश्य sys.dm_os_schedulers
» एमएस एसक्यूएल सर्वर डेटाबेस की निगरानी के लिए ज़ैबिक्स का उपयोग करना
» एसक्यूएल लाइफस्टाइल
» ट्रेस झंडे
» sql.ru

स्रोत: www.habr.com

MS SQL सर्वर मॉनिटरिंग के कुछ पहलू। ट्रेस फ़्लैग स्थापित करने के लिए दिशानिर्देश