🥇 MS SQL सर्व्हरचे निरीक्षण करण्याचे काही पैलू. ट्रेस फ्लॅग सेट करण्यासाठी शिफारसी

प्रस्तावना

बर्‍याचदा, MS SQL Server DBMS चे वापरकर्ते, विकासक आणि प्रशासकांना डेटाबेस किंवा संपूर्ण DBMS च्या कार्यप्रदर्शन समस्यांचा सामना करावा लागतो, म्हणून MS SQL सर्व्हरचे निरीक्षण करणे खूप संबंधित आहे.
हा लेख लेखात भर घालणारा आहे MS SQL सर्व्हर डेटाबेसचे परीक्षण करण्यासाठी Zabbix वापरणे आणि हे एमएस एसक्यूएल सर्व्हरचे निरीक्षण करण्याच्या काही पैलूंचे परीक्षण करेल, विशेषतः: कोणती संसाधने गहाळ आहेत हे त्वरीत कसे ठरवायचे, तसेच ट्रेस फ्लॅग सेट करण्यासाठी शिफारसी.
खालील स्क्रिप्ट कार्य करण्यासाठी, तुम्हाला खालीलप्रमाणे इच्छित डेटाबेसमध्ये एक inf स्कीमा तयार करणे आवश्यक आहे:
inf स्कीमा तयार करणे

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

RAM ची कमतरता शोधण्याची पद्धत

RAM च्या कमतरतेचे पहिले सूचक जेव्हा MS SQL सर्व्हरचे उदाहरण त्याला वाटप केलेली सर्व 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;

त्यानंतर तुम्ही हे निर्धारित करू शकता की एमएस एसक्यूएल सर्व्हरचे एक उदाहरण खालील क्वेरी वापरून त्यास वाटप केलेली सर्व मेमरी वापरत आहे:

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'
  );
```

या दोन निर्देशकांसाठी प्राप्त केलेल्या मूल्यांच्या गतिशीलतेवर आधारित, आम्ही असा निष्कर्ष काढू शकतो की एमएस एसक्यूएल सर्व्हर उदाहरणासाठी पुरेशी RAM आहे की नाही.

जास्त CPU लोड शोधण्याची पद्धत

CPU वेळेची कमतरता ओळखण्यासाठी, फक्त sys.dm_os_schedulers प्रणाली दृश्य वापरा. येथे, जर रन करण्यायोग्य_टास्क_काउंट इंडिकेटर सतत 1 पेक्षा जास्त असेल, तर MS SQL सर्व्हर उदाहरणासाठी कोरची संख्या पुरेशी नसण्याची उच्च संभाव्यता आहे.
मॉनिटरिंग सिस्टममध्ये निर्देशक प्रदर्शित करण्यासाठी (उदाहरणार्थ, Zabbix), तुम्ही खालील विनंती तयार करू शकता:

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

या निर्देशकासाठी प्राप्त केलेल्या मूल्यांच्या गतिशीलतेच्या आधारावर, आम्ही असा निष्कर्ष काढू शकतो की एमएस एसक्यूएल सर्व्हर उदाहरणासाठी पुरेसा प्रोसेसर वेळ (सीपीयू कोरची संख्या) आहे की नाही.
तथापि, हे सत्य लक्षात ठेवणे महत्त्वाचे आहे की क्वेरी स्वतः एकाच वेळी अनेक थ्रेड्सवर क्वेरी करू शकतात. आणि कधीकधी ऑप्टिमायझर स्वतः क्वेरीच्या जटिलतेचा अचूक अंदाज लावू शकत नाही. मग विनंतीला बर्याच थ्रेडचे वाटप केले जाऊ शकते, जे एका दिलेल्या वेळी एकाच वेळी प्रक्रिया केली जाऊ शकत नाही. आणि यामुळे प्रोसेसर वेळेच्या कमतरतेशी संबंधित एक प्रकारची प्रतीक्षा देखील होते आणि विशिष्ट CPU कोर वापरणार्‍या शेड्यूलर्सच्या रांगेत वाढ होते, म्हणजेच अशा परिस्थितीत रन करण्यायोग्य_टास्क_काउंट इंडिकेटर वाढतो.
या प्रकरणात, CPU कोरची संख्या वाढवण्यापूर्वी, तुम्हाला MS SQL सर्व्हर उदाहरणाचे समांतर गुणधर्म योग्यरित्या कॉन्फिगर करणे आवश्यक आहे आणि आवृत्ती 2016 पासून, आवश्यक डेटाबेसचे समांतर गुणधर्म योग्यरित्या कॉन्फिगर करणे आवश्यक आहे:

येथे आपण खालील पॅरामीटर्सकडे लक्ष दिले पाहिजे:

समांतरतेची कमाल पदवी—प्रत्येक विनंतीला वाटप केल्या जाऊ शकणार्‍या थ्रेड्सची कमाल संख्या सेट करते (डीफॉल्ट 0 आहे—केवळ ऑपरेटिंग सिस्टम आणि MS SQL सर्व्हरच्या आवृत्तीद्वारे मर्यादित)
समांतरतेसाठी खर्च थ्रेशोल्ड - समांतरतेची अंदाजे किंमत (डीफॉल्ट 5 आहे)
मॅक्स डीओपी- डेटाबेस स्तरावर प्रत्येक क्वेरीसाठी वाटप केल्या जाऊ शकणार्‍या थ्रेड्सची कमाल संख्या सेट करते (परंतु "समांतरपणाची कमाल पदवी" गुणधर्माच्या मूल्यापेक्षा जास्त नाही) (डिफॉल्टनुसार ते 0 असते—फक्त ऑपरेटिंग सिस्टमद्वारे मर्यादित स्वतः आणि MS SQL सर्व्हरची आवृत्ती, तसेच संपूर्ण MS SQL सर्व्हरच्या उदाहरणाच्या “मॅक्स डिग्री ऑफ पॅरललिझम” गुणधर्मावर मर्यादा)

सर्व प्रकरणांसाठी तितकीच चांगली रेसिपी देणे अशक्य आहे, म्हणजे, आपल्याला कठीण प्रश्नांचे विश्लेषण करणे आवश्यक आहे.
माझ्या स्वतःच्या अनुभवावर आधारित, मी समांतर गुणधर्म कॉन्फिगर करण्यासाठी ओएलटीपी सिस्टमसाठी खालील अल्गोरिदमची शिफारस करतो:

प्रथम संपूर्ण उदाहरणाच्या स्तरावर समांतरतेची कमाल पदवी 1 वर सेट करून समांतरता अक्षम करा
सर्वात भारी प्रश्नांचे विश्लेषण करा आणि त्यांच्यासाठी थ्रेड्सची इष्टतम संख्या निवडा
स्टेप 2 मधून मिळवलेल्या थ्रेड्सच्या निवडलेल्या इष्टतम संख्येवर समांतरतेची कमाल पदवी सेट करा आणि विशिष्ट डेटाबेससाठी प्रत्येक डेटाबेससाठी चरण 2 वरून मिळवलेले कमाल DOP मूल्य सेट करा.
सर्वात भारी प्रश्नांचे विश्लेषण करा आणि मल्टीथ्रेडिंगचा नकारात्मक प्रभाव ओळखा. तसे असल्यास, समांतरतेसाठी खर्च मर्यादा वाढवा.
1C, मायक्रोसॉफ्ट सीआरएम आणि मायक्रोसॉफ्ट एनएव्ही सारख्या प्रणालींसाठी, बहुतेक प्रकरणांमध्ये मल्टीथ्रेडिंग प्रतिबंधित करणे योग्य आहे

तसेच, आपल्याकडे मानक आवृत्ती असल्यास, बहुतेक प्रकरणांमध्ये मल्टी-थ्रेडिंगवर बंदी घालणे योग्य आहे कारण ही आवृत्ती CPU कोरच्या संख्येत मर्यादित आहे.
वर वर्णन केलेले अल्गोरिदम OLAP सिस्टमसाठी योग्य नाही.
माझ्या स्वतःच्या अनुभवावर आधारित, मी समांतर गुणधर्म कॉन्फिगर करण्यासाठी OLAP सिस्टमसाठी खालील अल्गोरिदमची शिफारस करतो:

सर्वात भारी प्रश्नांचे विश्लेषण करा आणि त्यांच्यासाठी थ्रेड्सची इष्टतम संख्या निवडा
स्टेप 1 मधून मिळवलेल्या थ्रेड्सच्या निवडलेल्या इष्टतम संख्येवर समांतरतेची कमाल पदवी सेट करा आणि विशिष्ट डेटाबेससाठी प्रत्येक डेटाबेससाठी चरण 1 वरून मिळवलेले कमाल DOP मूल्य सेट करा.
सर्वात जास्त प्रश्नांचे विश्लेषण करा आणि एकरूपता मर्यादित करण्याचा नकारात्मक प्रभाव ओळखा. असे असल्यास, एकतर समांतर मूल्यासाठी किंमत मर्यादा कमी करा किंवा या अल्गोरिदमच्या 1-2 चरणांची पुनरावृत्ती करा

म्हणजेच, ओएलटीपी सिस्टमसाठी आम्ही सिंगल-थ्रेडिंगवरून मल्टी-थ्रेडिंगकडे जातो आणि ओएलएपी सिस्टमसाठी, त्याउलट, आम्ही मल्टी-थ्रेडिंगवरून सिंगल-थ्रेडिंगकडे जातो. अशा प्रकारे तुम्ही विशिष्ट डेटाबेससाठी आणि संपूर्ण 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 कमांड वापरून ट्रेस फ्लॅगची स्थिती मिळवू शकता: अधिक
एमएस एसक्यूएल सर्व्हर सेवेच्या ऑटोस्टार्टमध्ये ट्रेस फ्लॅग समाविष्ट करण्यासाठी, तुम्हाला एसक्यूएल सर्व्हर कॉन्फिगरेशन मॅनेजरवर जाणे आवश्यक आहे आणि सेवा गुणधर्मांमध्ये -T द्वारे हे ट्रेस ध्वज जोडणे आवश्यक आहे:

परिणाम

या लेखात एमएस एसक्यूएल सर्व्हरचे निरीक्षण करण्याच्या काही पैलूंचे परीक्षण केले आहे, ज्याच्या मदतीने आपण RAM आणि विनामूल्य CPU वेळेची कमतरता तसेच इतर अनेक कमी स्पष्ट समस्या त्वरीत ओळखू शकता. सर्वात सामान्यपणे वापरल्या जाणार्‍या ट्रेस ध्वजांचे पुनरावलोकन केले गेले.

स्त्रोत:

» SQL सर्व्हर प्रतीक्षा आकडेवारी
» SQL सर्व्हर प्रतीक्षा आकडेवारी किंवा कृपया मला सांगा कुठे दुखत आहे
» सिस्टम दृश्य sys.dm_os_schedulers
» MS SQL सर्व्हर डेटाबेसचे परीक्षण करण्यासाठी Zabbix वापरणे
» SQL जीवनशैली
» ट्रेस ध्वज
» sql.ru

स्त्रोत: www.habr.com

एमएस एसक्यूएल सर्व्हरचे निरीक्षण करण्याचे काही पैलू. ट्रेस ध्वज सेट करण्यासाठी शिफारसी