MS SQL ಸರ್ವರ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಕೆಲವು ಅಂಶಗಳು. ಟ್ರೇಸ್ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು ಮಾರ್ಗಸೂಚಿಗಳು

ಮುನ್ನುಡಿ

ಆಗಾಗ್ಗೆ, MS SQL ಸರ್ವರ್ DBMS ನ ಬಳಕೆದಾರರು, ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ನಿರ್ವಾಹಕರು ಡೇಟಾಬೇಸ್ ಅಥವಾ ಒಟ್ಟಾರೆಯಾಗಿ DBMS ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ MS SQL ಸರ್ವರ್ ಮಾನಿಟರಿಂಗ್ ಬಹಳ ಪ್ರಸ್ತುತವಾಗಿದೆ.
ಈ ಲೇಖನವು ಲೇಖನಕ್ಕೆ ಸೇರ್ಪಡೆಯಾಗಿದೆ MS SQL ಸರ್ವರ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು Zabbix ಅನ್ನು ಬಳಸುವುದು ಮತ್ತು ಇದು ನಿರ್ದಿಷ್ಟವಾಗಿ MS SQL ಸರ್ವರ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಕೆಲವು ಅಂಶಗಳನ್ನು ಚರ್ಚಿಸುತ್ತದೆ: ಯಾವ ಸಂಪನ್ಮೂಲಗಳು ಕಾಣೆಯಾಗಿದೆ ಎಂಬುದನ್ನು ತ್ವರಿತವಾಗಿ ನಿರ್ಧರಿಸುವುದು ಹೇಗೆ, ಹಾಗೆಯೇ ಟ್ರೇಸ್ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು ಶಿಫಾರಸುಗಳು.
ಕೆಳಗಿನ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಕೆಲಸ ಮಾಡಲು, ನೀವು ಬಯಸಿದ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಈ ಕೆಳಗಿನಂತೆ inf ಸ್ಕೀಮಾವನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ:
ಇನ್ಫ್ ಸ್ಕೀಮಾವನ್ನು ರಚಿಸುವುದು

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

RAM ಕೊರತೆಯನ್ನು ಕಂಡುಹಿಡಿಯುವ ವಿಧಾನ

MS SQL ಸರ್ವರ್‌ನ ನಿದರ್ಶನವು ಅದಕ್ಕೆ ನಿಗದಿಪಡಿಸಿದ ಎಲ್ಲಾ RAM ಅನ್ನು ತಿನ್ನುವಾಗ 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), ನೀವು ಈ ಕೆಳಗಿನ ಎರಡು ಪ್ರಶ್ನೆಗಳನ್ನು ರಚಿಸಬಹುದು:

ಶೇಕಡಾವಾರು ಪ್ರಮಾಣದಲ್ಲಿ 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'
  );
```

ಈ ಎರಡು ಸೂಚಕಗಳಿಗೆ ಪಡೆದ ಮೌಲ್ಯಗಳ ಡೈನಾಮಿಕ್ಸ್ ಅನ್ನು ಆಧರಿಸಿ, 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 ಕೋರ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಮೊದಲು, MS SQL ಸರ್ವರ್ ನಿದರ್ಶನದ ಸಮಾನಾಂತರ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಅವಶ್ಯಕ, ಮತ್ತು 2016 ರ ಆವೃತ್ತಿಯಿಂದ, ಅಗತ್ಯವಿರುವ ಡೇಟಾಬೇಸ್‌ಗಳ ಸಮಾನಾಂತರ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿ:

ಇಲ್ಲಿ ನೀವು ಈ ಕೆಳಗಿನ ನಿಯತಾಂಕಗಳಿಗೆ ಗಮನ ಕೊಡಬೇಕು:

ಸಮಾನಾಂತರತೆಯ ಗರಿಷ್ಠ ಪದವಿ - ಪ್ರತಿ ವಿನಂತಿಗೆ ಹಂಚಬಹುದಾದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಥ್ರೆಡ್‌ಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ (ಡೀಫಾಲ್ಟ್ 0 - ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಸ್ವತಃ ಮತ್ತು MS SQL ಸರ್ವರ್‌ನ ಆವೃತ್ತಿಯಿಂದ ಮಾತ್ರ ಸೀಮಿತವಾಗಿದೆ)
ಸಮಾನಾಂತರತೆಯ ವೆಚ್ಚದ ಮಿತಿ - ಸಮಾನಾಂತರತೆಯ ಅಂದಾಜು ವೆಚ್ಚ (ಡೀಫಾಲ್ಟ್ 5)
ಮ್ಯಾಕ್ಸ್ DOP - ಡೇಟಾಬೇಸ್ ಮಟ್ಟದಲ್ಲಿ ಪ್ರತಿ ಪ್ರಶ್ನೆಗೆ ಹಂಚಬಹುದಾದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಥ್ರೆಡ್‌ಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ (ಆದರೆ "ಸಮಾನಾಂತರತೆಯ ಗರಿಷ್ಠ ಪದವಿ" ಆಸ್ತಿಯ ಮೌಲ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿಲ್ಲ) (ಡೀಫಾಲ್ಟ್ 0 - ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಮಾತ್ರ ಸೀಮಿತವಾಗಿದೆ ಮತ್ತು MS SQL ಸರ್ವರ್‌ನ ಆವೃತ್ತಿ, ಹಾಗೆಯೇ MS SQL ಸರ್ವರ್‌ನ ಸಂಪೂರ್ಣ ನಿದರ್ಶನದ "ಸಮಾನಾಂತರತೆಯ ಗರಿಷ್ಠ ಪದವಿ" ಆಸ್ತಿಯ ಮೇಲಿನ ನಿರ್ಬಂಧ)

ಇಲ್ಲಿ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಮಾನವಾಗಿ ಉತ್ತಮವಾದ ಪಾಕವಿಧಾನವನ್ನು ನೀಡುವುದು ಅಸಾಧ್ಯ, ಅಂದರೆ ನೀವು ಭಾರೀ ಪ್ರಶ್ನೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಬೇಕಾಗಿದೆ.
ನನ್ನ ಸ್ವಂತ ಅನುಭವದಿಂದ, ಸಮಾನಾಂತರ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿಸಲು OLTP ಸಿಸ್ಟಮ್‌ಗಳಿಗಾಗಿ ಕೆಳಗಿನ ಕ್ರಮಗಳ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ:

ನಿದರ್ಶನ-ವೈಡ್ ಮ್ಯಾಕ್ಸ್ ಡಿಗ್ರಿ ಆಫ್ ಪ್ಯಾರೆಲಲಿಸಮ್ ಅನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಮೊದಲು ಸಮಾನಾಂತರತೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ
ಭಾರೀ ವಿನಂತಿಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ ಮತ್ತು ಅವುಗಳಿಗೆ ಸೂಕ್ತವಾದ ಥ್ರೆಡ್‌ಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ
ಹಂತ 2 ರಿಂದ ಪಡೆದ ಆಯ್ದ ಅತ್ಯುತ್ತಮ ಸಂಖ್ಯೆಯ ಥ್ರೆಡ್‌ಗಳಿಗೆ ಸಮಾನಾಂತರತೆಯ ಗರಿಷ್ಠ ಪದವಿಯನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಪ್ರತಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಹಂತ 2 ರಿಂದ ಪಡೆದ ಗರಿಷ್ಠ DOP ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸಿ
ಭಾರೀ ವಿನಂತಿಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ ಮತ್ತು ಮಲ್ಟಿಥ್ರೆಡಿಂಗ್ನ ಋಣಾತ್ಮಕ ಪರಿಣಾಮವನ್ನು ಗುರುತಿಸಿ. ಹಾಗಿದ್ದಲ್ಲಿ, ಸಮಾನಾಂತರತೆಗಾಗಿ ವೆಚ್ಚದ ಮಿತಿಯನ್ನು ಹೆಚ್ಚಿಸಿ.
1C, Microsoft CRM ಮತ್ತು Microsoft NAV ಯಂತಹ ವ್ಯವಸ್ಥೆಗಳಿಗೆ, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಮಲ್ಟಿಥ್ರೆಡಿಂಗ್ ಅನ್ನು ನಿಷೇಧಿಸುವುದು ಸೂಕ್ತವಾಗಿದೆ

ಅಲ್ಲದೆ, ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಆವೃತ್ತಿ ಇದ್ದರೆ, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಮಲ್ಟಿಥ್ರೆಡಿಂಗ್ನ ನಿಷೇಧವು ಈ ಆವೃತ್ತಿಯು CPU ಕೋರ್ಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಸೀಮಿತವಾಗಿದೆ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ ಸೂಕ್ತವಾಗಿದೆ.
OLAP ವ್ಯವಸ್ಥೆಗಳಿಗೆ, ಮೇಲೆ ವಿವರಿಸಿದ ಅಲ್ಗಾರಿದಮ್ ಸೂಕ್ತವಲ್ಲ.
ನನ್ನ ಸ್ವಂತ ಅನುಭವದಿಂದ, ಸಮಾನಾಂತರ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿಸಲು OLAP ಸಿಸ್ಟಮ್‌ಗಳಿಗಾಗಿ ಕೆಳಗಿನ ಕ್ರಮಗಳ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ:

ಭಾರೀ ವಿನಂತಿಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ ಮತ್ತು ಅವುಗಳಿಗೆ ಸೂಕ್ತವಾದ ಥ್ರೆಡ್‌ಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ
ಹಂತ 1 ರಿಂದ ಪಡೆದ ಆಯ್ದ ಅತ್ಯುತ್ತಮ ಸಂಖ್ಯೆಯ ಥ್ರೆಡ್‌ಗಳಿಗೆ ಸಮಾನಾಂತರತೆಯ ಗರಿಷ್ಠ ಪದವಿಯನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಪ್ರತಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಹಂತ 1 ರಿಂದ ಪಡೆದ ಗರಿಷ್ಠ DOP ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸಿ
ಭಾರೀ ಪ್ರಶ್ನೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ ಮತ್ತು ಏಕಕಾಲಿಕತೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಋಣಾತ್ಮಕ ಪರಿಣಾಮವನ್ನು ಗುರುತಿಸಿ. ಹಾಗಿದ್ದಲ್ಲಿ, ಸಮಾನಾಂತರ ಮೌಲ್ಯಕ್ಕಾಗಿ ವೆಚ್ಚದ ಮಿತಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಿ ಅಥವಾ ಈ ಅಲ್ಗಾರಿದಮ್‌ನ 1-2 ಹಂತಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ

ಅಂದರೆ, OLTP ವ್ಯವಸ್ಥೆಗಳಿಗೆ ನಾವು ಏಕ-ಥ್ರೆಡಿಂಗ್‌ನಿಂದ ಬಹು-ಥ್ರೆಡಿಂಗ್‌ಗೆ ಹೋಗುತ್ತೇವೆ ಮತ್ತು OLAP- ವ್ಯವಸ್ಥೆಗಳಿಗೆ, ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ನಾವು ಬಹು-ಥ್ರೆಡಿಂಗ್‌ನಿಂದ ಏಕ-ಥ್ರೆಡಿಂಗ್‌ಗೆ ಹೋಗುತ್ತೇವೆ. ಹೀಗಾಗಿ, ನೀವು ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್ ಮತ್ತು MS SQL ಸರ್ವರ್‌ನ ಸಂಪೂರ್ಣ ನಿದರ್ಶನ ಎರಡಕ್ಕೂ ಸೂಕ್ತವಾದ ಸಮಾನಾಂತರ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು.
MS SQL ಸರ್ವರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಸಮಾನಾಂತರ ಗುಣಲಕ್ಷಣಗಳ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸಹ ಮುಖ್ಯವಾಗಿದೆ.

ಟ್ರೇಸ್ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು ಮಾರ್ಗಸೂಚಿಗಳು

ನನ್ನ ಸ್ವಂತ ಅನುಭವ ಮತ್ತು ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳ ಅನುಭವದಿಂದ, ಅತ್ಯುತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ, 2008-2016 ಆವೃತ್ತಿಗಳಿಗಾಗಿ MS SQL ಸರ್ವರ್ ಸೇವೆಯ ರನ್ ಮಟ್ಟದಲ್ಲಿ ಈ ಕೆಳಗಿನ ಟ್ರೇಸ್ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ:

610 - ಸೂಚ್ಯಂಕಿತ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಒಳಸೇರಿಸಿದ ಲಾಗಿಂಗ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲಾಗಿದೆ. ಅನೇಕ ದಾಖಲೆಗಳು ಮತ್ತು ಅನೇಕ ವಹಿವಾಟುಗಳೊಂದಿಗೆ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಒಳಸೇರಿಸುವಿಕೆಗೆ ಸಹಾಯ ಮಾಡಬಹುದು, ಆಗಾಗ್ಗೆ ದೀರ್ಘ ಬರವಣಿಗೆಯ ಸೂಚಿಕೆಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳಿಗಾಗಿ ಕಾಯುತ್ತದೆ
1117 - ಫೈಲ್‌ಗ್ರೂಪ್‌ನಲ್ಲಿರುವ ಫೈಲ್ ಸ್ವಯಂ ಬೆಳವಣಿಗೆಯ ಮಿತಿ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಿದರೆ, ಫೈಲ್‌ಗ್ರೂಪ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳು ಬೆಳೆಯುತ್ತವೆ
1118 - ಎಲ್ಲಾ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ವಿಭಿನ್ನ ವಿಸ್ತಾರಗಳಲ್ಲಿ ಇರಿಸಲು ಒತ್ತಾಯಿಸುತ್ತದೆ (ಮಿಶ್ರ ವಿಸ್ತಾರಗಳ ನಿಷೇಧ), ಇದು ಮಿಶ್ರ ವಿಸ್ತಾರಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಬಳಸುವ SGAM ಪುಟವನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಅಗತ್ಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ
1224 - ಲಾಕ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಆಧರಿಸಿ ಲಾಕ್ ಹೆಚ್ಚಳವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಅತಿಯಾದ ಮೆಮೊರಿ ಬಳಕೆಯು ಲಾಕ್ ಹೆಚ್ಚಳವನ್ನು ಪ್ರಚೋದಿಸಬಹುದು
2371 - ಸ್ಥಿರ ಸ್ವಯಂಚಾಲಿತ ಅಂಕಿಅಂಶಗಳ ನವೀಕರಣ ಮಿತಿಯನ್ನು ಡೈನಾಮಿಕ್ ಸ್ವಯಂಚಾಲಿತ ಅಂಕಿಅಂಶಗಳ ನವೀಕರಣ ಮಿತಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ. ದೊಡ್ಡ ಕೋಷ್ಟಕಗಳಿಗಾಗಿ ಪ್ರಶ್ನೆ ಯೋಜನೆಗಳನ್ನು ನವೀಕರಿಸಲು ಮುಖ್ಯವಾಗಿದೆ, ಅಲ್ಲಿ ದಾಖಲೆಗಳ ತಪ್ಪಾದ ಎಣಿಕೆಯು ತಪ್ಪಾದ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಯೋಜನೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ
3226 - ದೋಷ ಲಾಗ್‌ನಲ್ಲಿ ಬ್ಯಾಕ್‌ಅಪ್ ಯಶಸ್ಸಿನ ಸಂದೇಶಗಳನ್ನು ನಿಗ್ರಹಿಸುತ್ತದೆ
4199 - CU ಗಳು ಮತ್ತು SQL ಸರ್ವರ್ ಸರ್ವಿಸ್ ಪ್ಯಾಕ್‌ಗಳಲ್ಲಿ ಬಿಡುಗಡೆಯಾದ ಪ್ರಶ್ನೆ ಆಪ್ಟಿಮೈಜರ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ
6532-6534 - ಪ್ರಾದೇಶಿಕ ಡೇಟಾ ಪ್ರಕಾರಗಳಲ್ಲಿನ ಪ್ರಶ್ನೆ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಣೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ
8048 - NUMA ವಿಭಜಿತ ಮೆಮೊರಿ ವಸ್ತುಗಳನ್ನು CPU ವಿಭಜಿತ ವಸ್ತುಗಳಿಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ
8780 - ಪ್ರಶ್ನೆ ಯೋಜನೆಗಾಗಿ ಹೆಚ್ಚುವರಿ ಸಮಯದ ಹಂಚಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಈ ಫ್ಲ್ಯಾಗ್ ಇಲ್ಲದ ಕೆಲವು ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು ಏಕೆಂದರೆ ಅವುಗಳು ಪ್ರಶ್ನೆ ಯೋಜನೆಯನ್ನು ಹೊಂದಿಲ್ಲ (ಅತ್ಯಂತ ಅಪರೂಪದ ದೋಷ)
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

MS SQL ಸರ್ವರ್ ಮಾನಿಟರಿಂಗ್‌ನ ಕೆಲವು ಅಂಶಗಳು. ಟ್ರೇಸ್ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು ಮಾರ್ಗಸೂಚಿಗಳು