MS SQL સર્વર મોનિટરિંગના કેટલાક પાસાઓ. ટ્રેસ ફ્લેગ્સ સેટ કરવા માટેની માર્ગદર્શિકા

ફોરવર્ડ

ઘણી વાર, MS SQL સર્વર DBMS ના વપરાશકર્તાઓ, વિકાસકર્તાઓ અને વહીવટકર્તાઓ ડેટાબેઝ અથવા DBMS ની કામગીરીની સમસ્યાઓનો સામનો કરે છે, તેથી MS SQL સર્વર મોનિટરિંગ ખૂબ જ સુસંગત છે.
આ લેખ લેખમાં ઉમેરો છે MS SQL સર્વર ડેટાબેઝને મોનિટર કરવા માટે Zabbix નો ઉપયોગ કરવો અને તે MS SQL સર્વરનું નિરીક્ષણ કરવાના કેટલાક પાસાઓને આવરી લેશે, ખાસ કરીને: કયા સંસાધનો ખૂટે છે તે ઝડપથી કેવી રીતે નક્કી કરવું, તેમજ ટ્રેસ ફ્લેગ સેટ કરવા માટેની ભલામણો.
નીચેની સ્ક્રિપ્ટો કામ કરવા માટે, તમારે નીચે પ્રમાણે ઇચ્છિત ડેટાબેઝમાં એક 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 અને સરેરાશ પ્રતીક્ષા_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'
     );
   

આ બે સૂચકાંકો માટે પ્રાપ્ત મૂલ્યોની ગતિશીલતાના આધારે, અમે તારણ કાઢી શકીએ છીએ કે MS SQL સર્વરના ઉદાહરણ માટે પૂરતી RAM છે કે કેમ.

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 કોરોનો ઉપયોગ કરતા શેડ્યુલર્સ માટે કતારમાં વૃદ્ધિ થાય છે, એટલે કે આવી પરિસ્થિતિઓમાં રનેબલ_ટાસ્ક_કાઉન્ટ સૂચક વધશે.
આ કિસ્સામાં, સીપીયુ કોરોની સંખ્યા વધારતા પહેલા, એમએસ એસક્યુએલ સર્વર ઇન્સ્ટન્સના સમાનતા ગુણધર્મોને યોગ્ય રીતે ગોઠવવું જરૂરી છે, અને 2016 સંસ્કરણથી, જરૂરી ડેટાબેઝના સમાંતર ગુણધર્મોને યોગ્ય રીતે ગોઠવો:



અહીં તમારે નીચેના પરિમાણો પર ધ્યાન આપવું જોઈએ:

1. સમાંતરતાની મહત્તમ ડિગ્રી - દરેક વિનંતીને ફાળવી શકાય તેવા થ્રેડોની મહત્તમ સંખ્યા સેટ કરે છે (ડિફોલ્ટ 0 છે - ફક્ત ઓપરેટિંગ સિસ્ટમ અને MS SQL સર્વરની આવૃત્તિ દ્વારા મર્યાદિત)
2. સમાંતરતા માટે કિંમત થ્રેશોલ્ડ - સમાંતરની અંદાજિત કિંમત (ડિફોલ્ટ 5 છે)
3. મહત્તમ DOP - ડેટાબેઝ સ્તરે દરેક ક્વેરી માટે ફાળવી શકાય તેવા થ્રેડોની મહત્તમ સંખ્યા સેટ કરે છે (પરંતુ "સમાંતરતાની મહત્તમ ડિગ્રી" ગુણધર્મના મૂલ્ય કરતાં વધુ નહીં) (ડિફોલ્ટ 0 છે - ફક્ત ઓપરેટિંગ સિસ્ટમ દ્વારા જ મર્યાદિત છે અને MS SQL સર્વરની આવૃત્તિ, તેમજ MS SQL સર્વરના સમગ્ર ઉદાહરણની "સમાંતરની મહત્તમ ડિગ્રી" ગુણધર્મ પર પ્રતિબંધ)

અહીં બધા કેસ માટે સમાન રીતે સારી રેસીપી આપવી અશક્ય છે, એટલે કે તમારે ભારે પ્રશ્નોનું વિશ્લેષણ કરવાની જરૂર છે.
મારા પોતાના અનુભવ પરથી, હું સમાંતર ગુણધર્મો સેટ કરવા માટે OLTP સિસ્ટમ માટે ક્રિયાઓના નીચેના અલ્ગોરિધમનો ભલામણ કરું છું:

1. સૌપ્રથમ સમાંતરતાની ઇન્સ્ટન્સ-વાઇડ મેક્સ ડિગ્રીને 1 પર સેટ કરીને સમાંતરતાને અક્ષમ કરો
2. સૌથી ભારે વિનંતીઓનું વિશ્લેષણ કરો અને તેમના માટે થ્રેડોની શ્રેષ્ઠ સંખ્યા પસંદ કરો
3. સમાંતરતાની મહત્તમ ડિગ્રીને સ્ટેપ 2 માંથી મેળવેલા થ્રેડોની પસંદ કરેલ શ્રેષ્ઠ સંખ્યા પર સેટ કરો અને ચોક્કસ ડેટાબેસેસ માટે દરેક ડેટાબેઝ માટે સ્ટેપ 2 થી મેળવેલ મહત્તમ DOP મૂલ્ય સેટ કરો.
4. સૌથી ભારે વિનંતીઓનું વિશ્લેષણ કરો અને મલ્ટિથ્રેડિંગની નકારાત્મક અસરને ઓળખો. જો તે હોય, તો સમાંતરતા માટે ખર્ચ થ્રેશોલ્ડ વધારો.
   1C, Microsoft CRM અને Microsoft NAV જેવી સિસ્ટમો માટે, મોટા ભાગના કિસ્સાઓમાં, મલ્ટિથ્રેડિંગ પર પ્રતિબંધ મૂકવો યોગ્ય છે

ઉપરાંત, જો ત્યાં પ્રમાણભૂત આવૃત્તિ છે, તો મોટાભાગના કિસ્સાઓમાં મલ્ટિથ્રેડિંગ પર પ્રતિબંધ એ હકીકતને કારણે યોગ્ય છે કે આ આવૃત્તિ સીપીયુ કોરોની સંખ્યામાં મર્યાદિત છે.
OLAP સિસ્ટમો માટે, ઉપર વર્ણવેલ અલ્ગોરિધમ યોગ્ય નથી.
મારા પોતાના અનુભવ પરથી, હું સમાંતર ગુણધર્મો સેટ કરવા માટે OLAP સિસ્ટમો માટે ક્રિયાઓના નીચેના અલ્ગોરિધમનો ભલામણ કરું છું:

1. સૌથી ભારે વિનંતીઓનું વિશ્લેષણ કરો અને તેમના માટે થ્રેડોની શ્રેષ્ઠ સંખ્યા પસંદ કરો
2. સમાંતરતાની મહત્તમ ડિગ્રીને સ્ટેપ 1 માંથી મેળવેલા થ્રેડોની પસંદ કરેલ શ્રેષ્ઠ સંખ્યા પર સેટ કરો અને ચોક્કસ ડેટાબેસેસ માટે દરેક ડેટાબેઝ માટે સ્ટેપ 1 થી મેળવેલ મહત્તમ DOP મૂલ્ય સેટ કરો.
3. સૌથી ભારે પ્રશ્નોનું પૃથ્થકરણ કરો અને સંમતિ મર્યાદિત કરવાની નકારાત્મક અસરને ઓળખો. જો તે છે, તો કાં તો સમાંતર મૂલ્ય માટે કિંમત થ્રેશોલ્ડ ઘટાડો અથવા આ અલ્ગોરિધમના 1-2 પગલાંને પુનરાવર્તિત કરો

એટલે કે, OLTP સિસ્ટમ્સ માટે આપણે સિંગલ-થ્રેડીંગથી મલ્ટિ-થ્રેડીંગ તરફ જઈએ છીએ, અને OLAP-સિસ્ટમ માટે, તેનાથી વિપરીત, આપણે મલ્ટી-થ્રેડીંગથી સિંગલ-થ્રેડીંગ તરફ જઈએ છીએ. આમ, તમે ચોક્કસ ડેટાબેઝ અને MS SQL સર્વરના સમગ્ર ઉદાહરણ બંને માટે શ્રેષ્ઠ સમાનતા સેટિંગ્સ પસંદ કરી શકો છો.
એ સમજવું પણ અગત્યનું છે કે MS SQL સર્વરના પ્રદર્શનની દેખરેખના પરિણામોના આધારે, સમયાંતરે સમાનતા ગુણધર્મોની સેટિંગ્સ બદલવાની જરૂર છે.

ટ્રેસ ફ્લેગ્સ સેટ કરવા માટેની માર્ગદર્શિકા

મારા પોતાના અનુભવ અને મારા સાથીદારોના અનુભવ પરથી, શ્રેષ્ઠ કામગીરી માટે, હું 2008-2016 આવૃત્તિઓ માટે MS SQL સર્વર સેવાના રન લેવલ પર નીચેના ટ્રેસ ફ્લેગ્સ સેટ કરવાની ભલામણ કરું છું:

1. 610 - અનુક્રમિત કોષ્ટકોમાં ઇન્સર્ટ્સનું લોગિંગ ઓછું. વારંવાર લાંબા WRITELOG અનુક્રમણિકાઓમાં ફેરફારો માટે રાહ જુએ છે સાથે, ઘણા રેકોર્ડ્સ અને ઘણા વ્યવહારો સાથે કોષ્ટકોમાં દાખલ કરવામાં મદદ કરી શકે છે
2. 1117 - જો ફાઇલગ્રુપમાંની ફાઇલ ઑટોગ્રોથ થ્રેશોલ્ડ જરૂરિયાતોને પૂર્ણ કરે છે, તો ફાઇલગ્રુપની બધી ફાઇલો વધે છે
3. 1118 - તમામ ઑબ્જેક્ટ્સને વિવિધ હદમાં સ્થિત કરવાની ફરજ પાડે છે (મિશ્ર હદનો પ્રતિબંધ), જે SGAM પૃષ્ઠને સ્કેન કરવાની જરૂરિયાતને ઘટાડે છે, જેનો ઉપયોગ મિશ્ર હદને ટ્રૅક કરવા માટે થાય છે.
4. 1224 - તાળાઓની સંખ્યાના આધારે લૉક એસ્કેલેશનને અક્ષમ કરે છે. જો કે, વધુ પડતી મેમરીનો ઉપયોગ લોક એસ્કેલેશનને ટ્રિગર કરી શકે છે
5. 2371 - સ્થિર સ્વચાલિત આંકડા અપડેટ થ્રેશોલ્ડને ગતિશીલ સ્વચાલિત આંકડા અપડેટ થ્રેશોલ્ડમાં બદલો. મોટા કોષ્ટકો માટે ક્વેરી પ્લાન અપડેટ કરવા માટે મહત્વપૂર્ણ, જ્યાં રેકોર્ડની ખોટી ગણતરી ભૂલભરેલી એક્ઝેક્યુશન પ્લાનમાં પરિણમે છે
6. 3226 - ભૂલ લોગમાં બેકઅપ સફળતા સંદેશાઓને દબાવી દે છે
7. 4199 - CUs અને SQL સર્વર સર્વિસ પેકમાં પ્રકાશિત ક્વેરી ઑપ્ટિમાઇઝરમાં ફેરફારોનો સમાવેશ કરે છે
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 દ્વારા આ ટ્રેસ ફ્લેગ્સ ઉમેરવા જોઈએ:

પરિણામો

આ લેખમાં, MS SQL સર્વરનું નિરીક્ષણ કરવાના કેટલાક પાસાઓનું વિશ્લેષણ કરવામાં આવ્યું હતું, જેની મદદથી તમે ઝડપથી RAM અને ફ્રી CPU સમયની અછત તેમજ અન્ય ઘણી ઓછી સ્પષ્ટ સમસ્યાઓને ઓળખી શકો છો. સૌથી વધુ ઉપયોગમાં લેવાતા ટ્રેસ ફ્લેગ્સની સમીક્ષા કરવામાં આવી છે.

સ્ત્રોતો:

» SQL સર્વર રાહ આંકડા
» SQL સર્વર આંકડાઓની રાહ જુઓ અથવા કૃપા કરીને મને કહો કે તે ક્યાં દુખે છે
» સિસ્ટમ દૃશ્ય sys.dm_os_schedulers
» MS SQL સર્વર ડેટાબેઝને મોનિટર કરવા માટે Zabbix નો ઉપયોગ કરવો
» SQL જીવનશૈલી
» ટ્રેસ ફ્લેગ્સ
» sql.ru

સોર્સ: www.habr.com