MS SQL സെർവർ നിരീക്ഷണത്തിന്റെ ചില വശങ്ങൾ. ട്രെയ്സ് ഫ്ലാഗുകൾ സജ്ജീകരിക്കുന്നതിനുള്ള മാർഗ്ഗനിർദ്ദേശങ്ങൾ

മുൻവാചകം

മിക്കപ്പോഴും, MS SQL സെർവർ DBMS-ന്റെ ഉപയോക്താക്കളും ഡെവലപ്പർമാരും അഡ്മിനിസ്ട്രേറ്റർമാരും ഡാറ്റാബേസിന്റെയോ മൊത്തത്തിലുള്ള DBMS-ന്റെയോ പ്രകടന പ്രശ്നങ്ങൾ നേരിടുന്നു, അതിനാൽ MS SQL സെർവർ നിരീക്ഷണം വളരെ പ്രസക്തമാണ്.
ഈ ലേഖനം ലേഖനത്തിന്റെ ഒരു കൂട്ടിച്ചേർക്കലാണ് MS SQL സെർവർ ഡാറ്റാബേസ് നിരീക്ഷിക്കാൻ Zabbix ഉപയോഗിക്കുന്നു കൂടാതെ ഇത് MS SQL സെർവർ നിരീക്ഷിക്കുന്നതിന്റെ ചില വശങ്ങൾ ഉൾക്കൊള്ളുന്നു, പ്രത്യേകിച്ചും: ഏതൊക്കെ ഉറവിടങ്ങൾ നഷ്‌ടപ്പെട്ടുവെന്ന് എങ്ങനെ വേഗത്തിൽ നിർണ്ണയിക്കും, കൂടാതെ ട്രെയ്സ് ഫ്ലാഗുകൾ സജ്ജീകരിക്കുന്നതിനുള്ള ശുപാർശകളും.
ഇനിപ്പറയുന്ന സ്‌ക്രിപ്‌റ്റുകൾ പ്രവർത്തിക്കുന്നതിന്, ഇനിപ്പറയുന്ന രീതിയിൽ ആവശ്യമുള്ള ഡാറ്റാബേസിൽ നിങ്ങൾ ഒരു ഇൻഫ് സ്കീമ സൃഷ്‌ടിക്കേണ്ടതുണ്ട്:
ഒരു ഇൻഫർമേഷൻ സ്കീമ സൃഷ്ടിക്കുന്നു

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

റാമിന്റെ അഭാവം കണ്ടെത്തുന്നതിനുള്ള രീതി

MS SQL സെർവറിന്റെ ഒരു ഉദാഹരണം അതിന് അനുവദിച്ചിട്ടുള്ള എല്ലാ റാമും തിന്നുതീർക്കുന്നതാണ് റാമിന്റെ അഭാവത്തിന്റെ ആദ്യ സൂചകം.
ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ 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-നേക്കാൾ വലുതോ തുല്യമോ ആണെങ്കിൽ, കാത്തിരിപ്പ് സ്ഥിതിവിവരക്കണക്കുകൾ പരിശോധിക്കേണ്ടതാണ്.
കാത്തിരിപ്പ് സ്ഥിതിവിവരക്കണക്കുകൾ വഴി റാമിന്റെ അഭാവം നിർണ്ണയിക്കാൻ, നമുക്ക് 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];

ഈ സാഹചര്യത്തിൽ, ഇനിപ്പറയുന്ന ചോദ്യം ഉപയോഗിച്ച് നിങ്ങൾക്ക് റാമിന്റെ അഭാവം നിർണ്ണയിക്കാനാകും:

SELECT [Percentage]
      ,[AvgWait_S]
  FROM [inf].[vWaits]
  where [WaitType] in (
    'PAGEIOLATCH_XX',
    'RESOURCE_SEMAPHORE',
    'RESOURCE_SEMAPHORE_QUERY_COMPILE'
  );

ഇവിടെ നിങ്ങൾ സൂചകങ്ങളുടെ ശതമാനം, AvgWait_S എന്നിവ ശ്രദ്ധിക്കേണ്ടതുണ്ട്. അവയുടെ മൊത്തത്തിൽ അവ പ്രാധാന്യമർഹിക്കുന്നുണ്ടെങ്കിൽ, MS SQL സെർവർ ഉദാഹരണത്തിന് മതിയായ റാം ഇല്ലെന്നതിന് വളരെ ഉയർന്ന സംഭാവ്യതയുണ്ട്. ഓരോ സിസ്റ്റത്തിനും കാര്യമായ മൂല്യങ്ങൾ വ്യക്തിഗതമായി നിർണ്ണയിക്കപ്പെടുന്നു. എന്നിരുന്നാലും, നിങ്ങൾക്ക് ഇനിപ്പറയുന്നവ ഉപയോഗിച്ച് ആരംഭിക്കാം: ശതമാനം>=1, AvgWait_S>=0.005.
ഒരു മോണിറ്ററിംഗ് സിസ്റ്റത്തിലേക്ക് ഇൻഡിക്കേറ്ററുകൾ ഔട്ട്പുട്ട് ചെയ്യുന്നതിന് (ഉദാഹരണത്തിന്, Zabbix), നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന രണ്ട് ചോദ്യങ്ങൾ സൃഷ്ടിക്കാൻ കഴിയും:

1. എത്ര തരം കാത്തിരിപ്പുകൾ ശതമാനത്തിൽ റാം ഉൾക്കൊള്ളുന്നു (അത്തരം കാത്തിരിപ്പുകളുടെ ആകെത്തുക):

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

2. മില്ലിസെക്കൻഡിൽ എത്ര റാം വെയിറ്റ് തരങ്ങൾ എടുക്കും (അത്തരത്തിലുള്ള എല്ലാ കാത്തിരിപ്പ് തരങ്ങൾക്കുമുള്ള എല്ലാ ശരാശരി കാലതാമസങ്ങളുടെയും പരമാവധി മൂല്യം):

   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 സെർവറിന്റെ ഒരു ഉദാഹരണത്തിന് മതിയായ റാം ഉണ്ടോ എന്ന് നമുക്ക് നിഗമനം ചെയ്യാം.

സിപിയു ഓവർലോഡ് കണ്ടെത്തൽ രീതി

പ്രോസസ്സർ സമയക്കുറവ് തിരിച്ചറിയാൻ, 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 സെർവറിന്റെ ഒരു ഉദാഹരണത്തിനായി മതിയായ പ്രോസസ്സർ സമയം (സിപിയു കോറുകളുടെ എണ്ണം) ഉണ്ടോ എന്ന് നമുക്ക് നിഗമനം ചെയ്യാം.
എന്നിരുന്നാലും, അഭ്യർത്ഥനകൾക്ക് ഒരേസമയം ഒന്നിലധികം ത്രെഡുകൾ അഭ്യർത്ഥിക്കാൻ കഴിയും എന്ന വസ്തുത മനസ്സിൽ സൂക്ഷിക്കേണ്ടത് പ്രധാനമാണ്. ചിലപ്പോൾ ഒപ്റ്റിമൈസറിന് ചോദ്യത്തിന്റെ സങ്കീർണ്ണത കൃത്യമായി കണക്കാക്കാൻ കഴിയില്ല. അപ്പോൾ അഭ്യർത്ഥന നൽകിയ സമയത്ത് ഒരേ സമയം പ്രോസസ്സ് ചെയ്യാൻ കഴിയാത്ത നിരവധി ത്രെഡുകൾ അനുവദിച്ചേക്കാം. കൂടാതെ ഇത് പ്രൊസസർ സമയക്കുറവുമായി ബന്ധപ്പെട്ട ഒരു തരം കാത്തിരിപ്പിനും നിർദ്ദിഷ്‌ട സിപിയു കോറുകൾ ഉപയോഗിക്കുന്ന ഷെഡ്യൂളറുകൾക്കുള്ള ക്യൂവിന്റെ വളർച്ചയ്ക്കും കാരണമാകുന്നു, അതായത് അത്തരം സാഹചര്യങ്ങളിൽ runnable_tasks_count സൂചകം വളരും.
ഈ സാഹചര്യത്തിൽ, സിപിയു കോറുകളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നതിന് മുമ്പ്, MS SQL സെർവർ ഉദാഹരണത്തിന്റെ തന്നെ സമാന്തര സവിശേഷതകൾ ശരിയായി ക്രമീകരിക്കേണ്ടത് ആവശ്യമാണ്, കൂടാതെ 2016 പതിപ്പിൽ നിന്ന്, ആവശ്യമായ ഡാറ്റാബേസുകളുടെ സമാന്തര സവിശേഷതകൾ ശരിയായി കോൺഫിഗർ ചെയ്യുക:



ഇവിടെ നിങ്ങൾ ഇനിപ്പറയുന്ന പാരാമീറ്ററുകൾ ശ്രദ്ധിക്കണം:

1. സമാന്തരതയുടെ പരമാവധി ബിരുദം - ഓരോ അഭ്യർത്ഥനയ്ക്കും അനുവദിക്കാവുന്ന പരമാവധി ത്രെഡുകളുടെ എണ്ണം സജ്ജീകരിക്കുന്നു (സ്ഥിരസ്ഥിതി 0 ആണ് - ഓപ്പറേറ്റിംഗ് സിസ്റ്റവും MS SQL സെർവറിന്റെ പതിപ്പും മാത്രം പരിമിതപ്പെടുത്തിയിരിക്കുന്നു)
2. പാരലലിസത്തിനായുള്ള ചെലവ് പരിധി - സമാന്തരതയുടെ കണക്കാക്കിയ ചെലവ് (സ്ഥിരസ്ഥിതി 5 ആണ്)
3. Max 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 - ഇൻഡെക്‌സ് ചെയ്‌ത പട്ടികകളിലേക്ക് ഇൻസെർട്ടുകളുടെ ലോഗ്ഗിംഗ് കുറച്ചു. ഇൻഡെക്സുകളിലെ മാറ്റങ്ങൾക്കായി ഇടയ്ക്കിടെയുള്ള റൈറ്റലോഗ് കാത്തിരിപ്പിനൊപ്പം, നിരവധി റെക്കോർഡുകളും നിരവധി ഇടപാടുകളുമുള്ള പട്ടികകളിലേക്ക് തിരുകാൻ സഹായിക്കാനാകും
2. 1117 - ഒരു ഫയൽ ഗ്രൂപ്പിലെ ഒരു ഫയൽ ഓട്ടോഗ്രോത്ത് ത്രെഷോൾഡ് ആവശ്യകതകൾ നിറവേറ്റുന്നുവെങ്കിൽ, ഫയൽ ഗ്രൂപ്പിലെ എല്ലാ ഫയലുകളും വളരുന്നു
3. 1118 - എല്ലാ ഒബ്‌ജക്‌റ്റുകളും വ്യത്യസ്‌ത പരിധികളിൽ സ്ഥാപിക്കാൻ നിർബന്ധിക്കുന്നു (മിക്‌സഡ് എക്‌സ്‌റ്റേഴ്‌സിന്റെ നിരോധനം), ഇത് മിക്‌സഡ് എക്‌സ്‌റ്റേൻസ് ട്രാക്ക് ചെയ്യാൻ ഉപയോഗിക്കുന്ന എസ്‌ജിഎഎം പേജ് സ്കാൻ ചെയ്യേണ്ടതിന്റെ ആവശ്യകത കുറയ്ക്കുന്നു.
4. 1224 - ലോക്കുകളുടെ എണ്ണം അടിസ്ഥാനമാക്കി ലോക്ക് വർദ്ധിപ്പിക്കൽ പ്രവർത്തനരഹിതമാക്കുന്നു. എന്നിരുന്നാലും, അമിതമായ മെമ്മറി ഉപയോഗം ലോക്ക് വർദ്ധിപ്പിക്കുന്നതിന് കാരണമാകും
5. 2371 - ഫിക്സഡ് ഓട്ടോമാറ്റിക് സ്റ്റാറ്റിസ്റ്റിക്സ് അപ്ഡേറ്റ് ത്രെഷോൾഡ് ഡൈനാമിക് ഓട്ടോമാറ്റിക് സ്റ്റാറ്റിസ്റ്റിക്സ് അപ്ഡേറ്റ് ത്രെഷോൾഡിലേക്ക് മാറ്റുന്നു. വലിയ ടേബിളുകൾക്കായുള്ള അന്വേഷണ പ്ലാനുകൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിന് പ്രധാനമാണ്, ഇവിടെ തെറ്റായ എക്‌സിക്യൂഷൻ പ്ലാനുകൾക്ക് കാരണമാകുന്ന റെക്കോർഡുകളുടെ എണ്ണം തെറ്റാണ്
6. 3226 - പിശക് ലോഗിലെ ബാക്കപ്പ് വിജയ സന്ദേശങ്ങൾ അടിച്ചമർത്തുന്നു
7. 4199 - CU-കളിലും 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 സെർവർ നിരീക്ഷിക്കുന്നതിന്റെ ചില വശങ്ങൾ വിശകലനം ചെയ്‌തു, അതിന്റെ സഹായത്തോടെ നിങ്ങൾക്ക് റാമിന്റെയും സൗജന്യ സിപിയു സമയത്തിന്റെയും അഭാവവും മറ്റ് കുറച്ച് വ്യക്തമായ പ്രശ്‌നങ്ങളും വേഗത്തിൽ തിരിച്ചറിയാൻ കഴിയും. ഏറ്റവും സാധാരണയായി ഉപയോഗിക്കുന്ന ട്രെയ്സ് ഫ്ലാഗുകൾ അവലോകനം ചെയ്തിട്ടുണ്ട്.

ഉറവിടങ്ങൾ:

» SQL സെർവർ കാത്തിരിപ്പ് സ്ഥിതിവിവരക്കണക്കുകൾ
» SQL സെർവർ സ്ഥിതിവിവരക്കണക്കുകൾക്കായി കാത്തിരിക്കുക അല്ലെങ്കിൽ അത് എവിടെയാണ് വേദനിപ്പിക്കുന്നതെന്ന് എന്നോട് പറയുക
» സിസ്റ്റം കാഴ്ച sys.dm_os_schedulers
» MS SQL സെർവർ ഡാറ്റാബേസ് നിരീക്ഷിക്കാൻ Zabbix ഉപയോഗിക്കുന്നു
» SQL ജീവിതശൈലി
» ട്രെയ്സ് ഫ്ലാഗുകൾ
» sql.ru

അവലംബം: www.habr.com