MS SQL சேவையகத்தை கண்காணிப்பதற்கான சில அம்சங்கள். சுவடு கொடிகளை அமைப்பதற்கான வழிகாட்டுதல்கள்

முன்னுரையில்

பெரும்பாலும், MS SQL சர்வர் DBMS இன் பயனர்கள், டெவலப்பர்கள் மற்றும் நிர்வாகிகள் தரவுத்தளத்தின் செயல்திறன் அல்லது ஒட்டுமொத்த DBMS இன் செயல்திறன் சிக்கல்களை எதிர்கொள்கின்றனர், எனவே MS SQL சர்வர் கண்காணிப்பு மிகவும் பொருத்தமானது.
இக்கட்டுரை அக்கட்டுரையில் கூடுதலாக உள்ளது MS SQL சர்வர் தரவுத்தளத்தை கண்காணிக்க Zabbix ஐப் பயன்படுத்துதல் மேலும் இது MS SQL சேவையகத்தை கண்காணிப்பதற்கான சில அம்சங்களை உள்ளடக்கும், குறிப்பாக: எந்த ஆதாரங்கள் காணவில்லை என்பதை விரைவாக எவ்வாறு தீர்மானிப்பது, அத்துடன் ட்ரேஸ் கொடிகளை அமைப்பதற்கான பரிந்துரைகள்.
பின்வரும் ஸ்கிரிப்டுகள் வேலை செய்ய, நீங்கள் விரும்பிய தரவுத்தளத்தில் பின்வருமாறு ஒரு inf ஸ்கீமாவை உருவாக்க வேண்டும்:
ஒரு தகவல் திட்டத்தை உருவாக்குதல்

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), நீங்கள் பின்வரும் இரண்டு வினவல்களை உருவாக்கலாம்:

ரேம் சதவீதத்தில் எத்தனை வகையான காத்திருப்புகளை ஆக்கிரமித்துள்ளது (அத்தகைய அனைத்து வகையான காத்திருப்புகளின் கூட்டுத்தொகை):
```
select coalesce(sum([Percentage]), 0.00) as [Percentage]
from [inf].[vWaits]
       where [WaitType] in (
           'PAGEIOLATCH_XX',
           'RESOURCE_SEMAPHORE',
            'RESOURCE_SEMAPHORE_QUERY_COMPILE'
  );
```
எத்தனை ரேம் காத்திருப்பு வகைகள் மில்லி விநாடிகளில் எடுக்கும் (அத்தகைய காத்திருப்பு வகைகளுக்கான அனைத்து சராசரி தாமதங்களின் அதிகபட்ச மதிப்பு):
```
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 சேவையகத்திற்கு போதுமான ரேம் உள்ளதா என்பதை நாம் முடிவு செய்யலாம்.

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 கோர்களைப் பயன்படுத்தும் திட்டமிடுபவர்களுக்கான வரிசையின் வளர்ச்சியை ஏற்படுத்துகிறது, அதாவது runnable_tasks_count காட்டி இத்தகைய நிலைமைகளில் வளரும்.
இந்த வழக்கில், CPU கோர்களின் எண்ணிக்கையை அதிகரிப்பதற்கு முன், MS SQL சர்வர் நிகழ்வின் இணையான பண்புகளை சரியாக உள்ளமைக்க வேண்டியது அவசியம், மேலும் 2016 பதிப்பிலிருந்து, தேவையான தரவுத்தளங்களின் இணையான பண்புகளை சரியாக உள்ளமைக்கவும்:

இங்கே நீங்கள் பின்வரும் அளவுருக்களுக்கு கவனம் செலுத்த வேண்டும்:

பேரலலிசத்தின் அதிகபட்ச பட்டம் - ஒவ்வொரு கோரிக்கைக்கும் ஒதுக்கக்கூடிய அதிகபட்ச நூல்களின் எண்ணிக்கையை அமைக்கிறது (இயல்புநிலை 0 - இயக்க முறைமை மற்றும் MS SQL சேவையகத்தின் பதிப்பால் மட்டுமே வரையறுக்கப்பட்டுள்ளது)
பேரலலிசத்திற்கான செலவு வரம்பு - இணையான மதிப்பிடப்பட்ட விலை (இயல்புநிலை 5)
மேக்ஸ் டிஓபி - தரவுத்தள மட்டத்தில் ஒவ்வொரு வினவலுக்கும் ஒதுக்கக்கூடிய அதிகபட்ச நூல்களின் எண்ணிக்கையை அமைக்கிறது (ஆனால் "இணைநிலையின் அதிகபட்ச பட்டம்" சொத்தின் மதிப்பை விட அதிகமாக இல்லை) (இயல்புநிலை 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 சேவையகத்தை கண்காணிப்பதற்கான சில அம்சங்கள் பகுப்பாய்வு செய்யப்பட்டன, இதன் உதவியுடன் நீங்கள் ரேம் மற்றும் இலவச CPU நேரமின்மை மற்றும் பல குறைவான வெளிப்படையான சிக்கல்களை விரைவாக அடையாளம் காணலாம். பொதுவாகப் பயன்படுத்தப்படும் சுவடு கொடிகள் மதிப்பாய்வு செய்யப்பட்டுள்ளன.

ஆதாரங்கள்:

» SQL சர்வர் காத்திருப்பு புள்ளிவிவரங்கள்
» SQL சர்வர் புள்ளி விவரங்களுக்காக காத்திருக்கவும் அல்லது எங்கே வலிக்கிறது என்று சொல்லவும்
» கணினி காட்சி sys.dm_os_schedulers
» MS SQL சர்வர் தரவுத்தளத்தை கண்காணிக்க Zabbix ஐப் பயன்படுத்துதல்
» SQL வாழ்க்கை முறை
» சுவடு கொடிகள்
» sql.ru

ஆதாரம்: www.habr.com

MS SQL சர்வர் கண்காணிப்பின் சில அம்சங்கள். சுவடு கொடிகளை அமைப்பதற்கான வழிகாட்டுதல்கள்