MS SQL ਸਰਵਰ ਨਿਗਰਾਨੀ ਦੇ ਕੁਝ ਪਹਿਲੂ। ਟਰੇਸ ਫਲੈਗ ਸੈੱਟ ਕਰਨ ਲਈ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼

ਮੁਖਬੰਧ

ਅਕਸਰ, MS SQL ਸਰਵਰ DBMS ਦੇ ਉਪਭੋਗਤਾਵਾਂ, ਵਿਕਾਸਕਰਤਾਵਾਂ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਡਾਟਾਬੇਸ ਜਾਂ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ DBMS ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਇਸ ਲਈ MS SQL ਸਰਵਰ ਨਿਗਰਾਨੀ ਬਹੁਤ ਢੁਕਵੀਂ ਹੈ।
ਇਹ ਲੇਖ ਲੇਖ ਵਿੱਚ ਇੱਕ ਜੋੜ ਹੈ MS SQL ਸਰਵਰ ਡਾਟਾਬੇਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ Zabbix ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਅਤੇ ਇਹ MS 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।
ਇੱਕ ਨਿਗਰਾਨੀ ਸਿਸਟਮ (ਉਦਾਹਰਨ ਲਈ, ਜ਼ੈਬਿਕਸ) ਵਿੱਚ ਸੂਚਕਾਂ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਦੋ ਸਵਾਲ ਬਣਾ ਸਕਦੇ ਹੋ:

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 ਸਰਵਰ ਉਦਾਹਰਣ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ।
ਇੱਕ ਮਾਨੀਟਰਿੰਗ ਸਿਸਟਮ (ਉਦਾਹਰਨ ਲਈ, ਜ਼ੈਬਿਕਸ) ਵਿੱਚ ਇੱਕ ਸੂਚਕ ਆਉਟਪੁੱਟ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਹੇਠ ਦਿੱਤੀ ਪੁੱਛਗਿੱਛ ਬਣਾ ਸਕਦੇ ਹੋ:

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

ਇਸ ਸੂਚਕ ਲਈ ਪ੍ਰਾਪਤ ਮੁੱਲਾਂ ਦੀ ਗਤੀਸ਼ੀਲਤਾ ਦੇ ਅਧਾਰ ਤੇ, ਅਸੀਂ ਇਹ ਸਿੱਟਾ ਕੱਢ ਸਕਦੇ ਹਾਂ ਕਿ ਕੀ MS SQL ਸਰਵਰ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਲਈ ਕਾਫ਼ੀ ਪ੍ਰੋਸੈਸਰ ਸਮਾਂ (CPU ਕੋਰਾਂ ਦੀ ਗਿਣਤੀ) ਹੈ ਜਾਂ ਨਹੀਂ।
ਹਾਲਾਂਕਿ, ਇਸ ਤੱਥ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਬੇਨਤੀਆਂ ਖੁਦ ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਥ੍ਰੈਡਾਂ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਅਤੇ ਕਈ ਵਾਰ ਆਪਟੀਮਾਈਜ਼ਰ ਖੁਦ ਪੁੱਛਗਿੱਛ ਦੀ ਗੁੰਝਲਤਾ ਦਾ ਸਹੀ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾ ਸਕਦਾ। ਫਿਰ ਬੇਨਤੀ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਥ੍ਰੈੱਡ ਅਲਾਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਦਿੱਤੇ ਸਮੇਂ 'ਤੇ ਇੱਕੋ ਸਮੇਂ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ। ਅਤੇ ਇਹ ਪ੍ਰੋਸੈਸਰ ਸਮੇਂ ਦੀ ਘਾਟ ਨਾਲ ਸੰਬੰਧਿਤ ਇੱਕ ਕਿਸਮ ਦੀ ਉਡੀਕ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ, ਅਤੇ ਖਾਸ CPU ਕੋਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਸ਼ਡਿਊਲਰਾਂ ਲਈ ਕਤਾਰ ਦੇ ਵਾਧੇ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਰਨਏਬਲ_ਟਾਸਕ_ਕਾਉਂਟ ਸੂਚਕ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਵਧੇਗਾ।
ਇਸ ਸਥਿਤੀ ਵਿੱਚ, CPU ਕੋਰਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, MS SQL ਸਰਵਰ ਉਦਾਹਰਣ ਦੇ ਸਮਾਨੰਤਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਅਤੇ 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 ਵਰਗੇ ਸਿਸਟਮਾਂ ਲਈ, ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਦੀ ਮਨਾਹੀ ਉਚਿਤ ਹੈ

ਨਾਲ ਹੀ, ਜੇਕਰ ਕੋਈ ਸਟੈਂਡਰਡ ਐਡੀਸ਼ਨ ਹੈ, ਤਾਂ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਦੀ ਮਨਾਹੀ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਢੁਕਵੀਂ ਹੈ ਕਿ ਇਹ ਐਡੀਸ਼ਨ CPU ਕੋਰਾਂ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਸੀਮਿਤ ਹੈ।
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 ਸਰਵਰ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੇ ਕੁਝ ਪਹਿਲੂਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਦੀ ਮਦਦ ਨਾਲ ਤੁਸੀਂ ਰੈਮ ਦੀ ਕਮੀ ਅਤੇ ਮੁਫਤ CPU ਸਮੇਂ ਦੇ ਨਾਲ ਨਾਲ ਕਈ ਹੋਰ ਘੱਟ ਸਪੱਸ਼ਟ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪਛਾਣ ਕਰ ਸਕਦੇ ਹੋ। ਸਭ ਤੋਂ ਵੱਧ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਟਰੇਸ ਫਲੈਗ ਦੀ ਸਮੀਖਿਆ ਕੀਤੀ ਗਈ ਹੈ।

ਸਰੋਤ:

» SQL ਸਰਵਰ ਉਡੀਕ ਅੰਕੜੇ
» SQL ਸਰਵਰ ਦੇ ਅੰਕੜਿਆਂ ਦੀ ਉਡੀਕ ਕਰੋ ਜਾਂ ਕਿਰਪਾ ਕਰਕੇ ਮੈਨੂੰ ਦੱਸੋ ਕਿ ਇਹ ਕਿੱਥੇ ਦੁਖਦਾਈ ਹੈ
» ਸਿਸਟਮ ਦ੍ਰਿਸ਼ sys.dm_os_schedulers
» MS SQL ਸਰਵਰ ਡਾਟਾਬੇਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ Zabbix ਦੀ ਵਰਤੋਂ ਕਰਨਾ
» SQL ਜੀਵਨ ਸ਼ੈਲੀ
» ਟਰੇਸ ਫਲੈਗ
» sql.ru

ਸਰੋਤ: www.habr.com