एमएस SQL ​​सर्भर अनुगमनका केही पक्षहरू। ट्रेस झण्डाहरू सेट गर्नका लागि दिशानिर्देशहरू

Foreword

प्रायः, प्रयोगकर्ताहरू, विकासकर्ताहरू र MS SQL Server DBMS का प्रशासकहरूले डाटाबेस वा DBMS को समग्र रूपमा कार्यसम्पादन समस्याहरू सामना गर्छन्, त्यसैले MS SQL सर्भर निगरानी धेरै सान्दर्भिक छ।
यो लेख लेखमा थपिएको छ MS SQL सर्भर डाटाबेस मोनिटर गर्न Zabbix प्रयोग गर्दै र यसले एमएस SQL ​​सर्भरको अनुगमनका केही पक्षहरूलाई समेट्नेछ, विशेष गरी: कुन स्रोतहरू छुटेका छन् भनेर द्रुत रूपमा कसरी निर्धारण गर्ने, साथै ट्रेस फ्ल्यागहरू सेट गर्नका लागि सिफारिसहरू।
निम्न स्क्रिप्टहरू काम गर्नको लागि, तपाईंले निम्न रूपमा वांछित डाटाबेसमा एक 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;

त्यसोभए तपाईले निर्धारण गर्न सक्नुहुन्छ कि 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), तपाइँ निम्न दुई प्रश्नहरू सिर्जना गर्न सक्नुहुन्छ:

1. RAM ले प्रतिशतमा कति प्रकारका पर्खाइहरू ओगटेका छन् (यस्ता प्रकारका पर्खाइहरूको योगफल):

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

2. मिलिसेकेन्डमा कति 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'
     );
   

यी दुई सूचकहरूको लागि प्राप्त मानहरूको गतिशीलताको आधारमा, हामी निष्कर्षमा पुग्न सक्छौं कि एमएस SQL ​​सर्भरको उदाहरणको लागि पर्याप्त RAM छ कि छैन।

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;

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



यहाँ तपाईंले निम्न प्यारामिटरहरूमा ध्यान दिनुपर्छ:

1. समानान्तरको अधिकतम डिग्री - प्रत्येक अनुरोधमा आवंटित गर्न सकिने थ्रेडहरूको अधिकतम संख्या सेट गर्दछ (पूर्वनिर्धारित ० हो - केवल अपरेटिङ सिस्टम र MS SQL सर्भरको संस्करण द्वारा सीमित)।
2. समानान्तरको लागि लागत थ्रेसहोल्ड - समानान्तरको अनुमानित लागत (पूर्वनिर्धारित 5 हो)
3. अधिकतम DOP - डाटाबेस स्तरमा प्रत्येक क्वेरीमा आवंटित गर्न सकिने थ्रेडहरूको अधिकतम संख्या सेट गर्दछ (तर "समानान्तरको अधिकतम डिग्री" गुणको मान भन्दा बढी होइन) (पूर्वनिर्धारित ० हो - अपरेटिङ सिस्टम आफैंद्वारा मात्र सीमित र MS SQL सर्भरको संस्करण, साथै MS SQL सर्भरको सम्पूर्ण उदाहरणको "Max Degree of Parallelism" गुणमा प्रतिबन्ध)

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

1. पहिले समानान्तरको अधिकतम डिग्री 1 मा सेट गरेर समानान्तरलाई असक्षम पार्नुहोस्
2. सबैभन्दा भारी अनुरोधहरूको विश्लेषण गर्नुहोस् र तिनीहरूका लागि थ्रेडहरूको इष्टतम संख्या चयन गर्नुहोस्
3. चरण 2 बाट प्राप्त थ्रेडहरूको चयन गरिएको इष्टतम संख्यामा समानान्तरको अधिकतम डिग्री सेट गर्नुहोस्, र विशिष्ट डाटाबेसहरूको लागि प्रत्येक डाटाबेसको लागि चरण 2 बाट प्राप्त अधिकतम DOP मान सेट गर्नुहोस्।
4. सबैभन्दा भारी अनुरोधहरूको विश्लेषण गर्नुहोस् र मल्टिथ्रेडिङको नकारात्मक प्रभाव पहिचान गर्नुहोस्। यदि यो हो भने, समानान्तरताको लागि लागत थ्रेसहोल्ड बढाउनुहोस्।
   1C, Microsoft CRM र Microsoft NAV जस्ता प्रणालीहरूका लागि, धेरै जसो अवस्थामा, मल्टिथ्रेडिङ निषेध गर्नु उपयुक्त छ।

साथै, यदि त्यहाँ मानक संस्करण छ भने, धेरै जसो केसहरूमा मल्टिथ्रेडिङको निषेध उपयुक्त छ किनभने यो संस्करण CPU कोरहरूको संख्यामा सीमित छ।
OLAP प्रणालीहरूको लागि, माथि वर्णन गरिएको एल्गोरिदम उपयुक्त छैन।
मेरो आफ्नै अनुभवबाट, म समानान्तरता गुणहरू सेटअप गर्न OLAP प्रणालीहरूको लागि निम्न कार्यहरूको एल्गोरिदम सिफारिस गर्दछु:

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

त्यो हो, OLTP प्रणालीहरूको लागि हामी एकल-थ्रेडिङबाट बहु-थ्रेडिङमा जान्छौं, र OLAP-प्रणालीहरूको लागि, यसको विपरीत, हामी बहु-थ्रेडिङबाट एकल-थ्रेडिङमा जान्छौं। यसरी, तपाइँ एक विशेष डाटाबेस र MS SQL सर्भरको सम्पूर्ण उदाहरण दुवैको लागि इष्टतम समानान्तर सेटिङहरू छनौट गर्न सक्नुहुन्छ।
एमएस SQL ​​सर्भरको कार्यसम्पादन अनुगमनका नतिजाहरूमा आधारित, समानान्तर गुणहरूको सेटिङहरू समयसँगै परिवर्तन गर्न आवश्यक छ भनी बुझ्नु पनि महत्त्वपूर्ण छ।

ट्रेस झण्डाहरू सेट गर्नका लागि दिशानिर्देशहरू

मेरो आफ्नै अनुभव र मेरा सहकर्मीहरूको अनुभवबाट, इष्टतम कार्यसम्पादनको लागि, म 2008-2016 संस्करणहरूको लागि MS SQL Server सेवाको रन स्तरमा निम्न ट्रेस फ्ल्यागहरू सेट गर्न सिफारिस गर्दछु:

1. 610 - अनुक्रमित तालिकाहरूमा सम्मिलितहरूको लगिङ घटाइयो। धेरै रेकर्डहरू र धेरै लेनदेनहरूसँग तालिकाहरूमा सम्मिलित गर्न मद्दत गर्न सक्छ, लगातार लामो WRITELOG अनुक्रमणिकाहरूमा परिवर्तनहरूको लागि पर्खन्छ।
2. 1117 - यदि फाइलसमूहमा भएको फाइलले स्वत:वृद्धि थ्रेसहोल्ड आवश्यकताहरू पूरा गर्छ भने, फाइलसमूहका सबै फाइलहरू बढ्छन्
3. 1118 - सबै वस्तुहरूलाई विभिन्न विस्तारहरूमा अवस्थित हुन बाध्य पार्छ (मिश्रित विस्तारहरूको निषेध), जसले SGAM पृष्ठ स्क्यान गर्ने आवश्यकतालाई कम गर्छ, जुन मिश्रित विस्तारहरू ट्र्याक गर्न प्रयोग गरिन्छ।
4. 1224 - लकहरूको संख्यामा आधारित लक एस्केलेसन असक्षम गर्दछ। यद्यपि, अत्यधिक मेमोरी प्रयोगले लक एस्केलेसन ट्रिगर गर्न सक्छ
5. 2371 - स्थिर स्वचालित तथ्याङ्क अद्यावधिक थ्रेसहोल्डलाई गतिशील स्वचालित तथ्याङ्क अद्यावधिक थ्रेसहोल्डमा परिवर्तन गर्दछ। ठूला तालिकाहरूका लागि क्वेरी योजनाहरू अद्यावधिक गर्न महत्त्वपूर्ण छ, जहाँ रेकर्डहरूको गलत गणनाले त्रुटिपूर्ण कार्यान्वयन योजनाहरूमा परिणाम दिन्छ।
6. 3226 - त्रुटि लगमा ब्याकअप सफलता सन्देशहरू दबाउँछ
7. 4199 - CUs र SQL Server Service Packs मा जारी गरिएको क्वेरी अप्टिमाइजरमा परिवर्तनहरू समावेश गर्दछ
8. 6532-6534 - स्थानिय डेटा प्रकारहरूमा क्वेरी सञ्चालनका लागि प्रदर्शन सुधारहरू समावेश गर्दछ
9. 8048 - NUMA विभाजन गरिएको मेमोरी वस्तुहरूलाई CPU विभाजन गरिएका वस्तुहरूमा रूपान्तरण गर्दछ
10. 8780 - क्वेरी योजनाको लागि अतिरिक्त समय आवंटन सक्षम गर्दछ। यो झण्डा बिना केही अनुरोधहरू अस्वीकार गर्न सकिन्छ किनभने तिनीहरूसँग क्वेरी योजना छैन (धेरै दुर्लभ बग)
11. 8780 - 9389 - ब्याच मोड स्टेटमेन्टहरूको लागि अतिरिक्त गतिशील अनुदान मेमोरी बफर सक्षम गर्दछ, जसले ब्याच मोड अपरेटरलाई थप मेमोरी अनुरोध गर्न र थप मेमोरी उपलब्ध छ भने tempdb मा डाटा सार्नबाट बच्न अनुमति दिन्छ।

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

परिणामहरू

यस लेखमा, एमएस एसक्यूएल सर्भरको अनुगमनका केही पक्षहरू विश्लेषण गरिएको थियो, जसको मद्दतले तपाईंले चाँडै RAM र नि: शुल्क CPU समयको कमी, साथै अन्य धेरै कम स्पष्ट समस्याहरू पहिचान गर्न सक्नुहुन्छ। सबैभन्दा सामान्य रूपमा प्रयोग हुने ट्रेस झण्डाहरू समीक्षा गरिएको छ।

स्रोतहरू:

» SQL सर्भर प्रतीक्षा तथ्याङ्क
» SQL सर्भर तथ्याङ्क पर्खनुहोस् वा कृपया मलाई भन्नुहोस् कि यो कहाँ दुख्छ
» प्रणाली दृश्य sys.dm_os_schedulers
» MS SQL सर्भर डाटाबेस मोनिटर गर्न Zabbix प्रयोग गर्दै
» SQL जीवनशैली
» ट्रेस झण्डा
» sql.ru

स्रोत: www.habr.com