MS SQL სერვერის მონიტორინგის ზოგიერთი ასპექტი. რეკომენდაციები კვალი დროშების დასაყენებლად

წინასიტყვაობა

საკმაოდ ხშირად, MS SQL Server DBMS-ის მომხმარებლები, დეველოპერები და ადმინისტრატორები აწყდებიან პრობლემებს მონაცემთა ბაზის ან მთლიანად DBMS-ის მუშაობასთან დაკავშირებით, ამიტომ MS SQL Server-ის მონიტორინგი ძალიან მნიშვნელოვანია.
ეს სტატია სტატიის დამატებაა Zabbix-ის გამოყენება MS SQL Server მონაცემთა ბაზის მონიტორინგისთვის და ის მოიცავს MS SQL Server-ის მონიტორინგის ზოგიერთ ასპექტს, კერძოდ: როგორ სწრაფად დავადგინოთ, რომელი რესურსები აკლია, ასევე რეკომენდაციებს კვალის დროშების დასაყენებლად.
შემდეგი სკრიპტების მუშაობისთვის, თქვენ უნდა შექმნათ inf სქემა სასურველ მონაცემთა ბაზაში შემდეგნაირად:
ინფ სქემის შექმნა

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

არასაკმარისი ოპერატიული მეხსიერების გამოვლენის მეთოდი

ოპერატიული მეხსიერების ნაკლებობის პირველი მაჩვენებელია, როდესაც MS SQL Server-ის ინსტანცია შთანთქავს მისთვის გამოყოფილ მთელ ოპერატიულ მეხსიერებას.
ამისათვის შევქმნათ შემდეგი 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 Server-ის ინსტანცია მოიხმარს მისთვის გამოყოფილ მთელ მეხსიერებას შემდეგი შეკითხვის გამოყენებით:

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'
  );

აქ ყურადღება უნდა მიაქციოთ Percentage და AvgWait_S ინდიკატორებს. თუ ისინი მთლიანობაში მნიშვნელოვანია, მაშინ ძალიან მაღალი ალბათობაა, რომ MS SQL Server-ის ინსტანციას არ აქვს საკმარისი ოპერატიული მეხსიერება. მნიშვნელოვანი მნიშვნელობები განისაზღვრება ინდივიდუალურად თითოეული სისტემისთვის. თუმცა, შეგიძლიათ დაიწყოთ შემდეგი ინდიკატორით: Percentage>=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 Server-ის ინსტანციისთვის.

CPU-ს გადაჭარბებული დატვირთვის გამოვლენის მეთოდი

პროცესორის დროის ნაკლებობის დასადგენად, საკმარისია სისტემის ხედის sys.dm_os_schedulers გამოყენება. აქ, თუ runnable_tasks_count ინდიკატორი მუდმივად 1-ზე მეტია, მაშინ დიდი ალბათობაა, რომ ბირთვების რაოდენობა არ არის საკმარისი MS SQL Server-ის ეგზემპლარისთვის.
ინდიკატორის მონიტორინგის სისტემაში (მაგალითად, Zabbix) გამოსატანად, შეგიძლიათ შექმნათ შემდეგი მოთხოვნა:

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

ამ ინდიკატორისთვის მიღებული მნიშვნელობების დინამიკის საფუძველზე, შეგვიძლია დავასკვნათ, არის თუ არა საკმარისი პროცესორის დრო (CPU ბირთვების რაოდენობა) MS SQL Server-ის ინსტანციისთვის.
თუმცა, მნიშვნელოვანია გვახსოვდეს ის ფაქტი, რომ თავად შეკითხვებს შეუძლიათ ერთდროულად რამდენიმე ნაკადის მოთხოვნა. ზოგჯერ ოპტიმიზატორს არ შეუძლია სწორად შეაფასოს თავად შეკითხვის სირთულე. შემდეგ მოთხოვნას შეიძლება გამოეყოს ძალიან ბევრი ნაკადი, რომელთა დამუშავება ერთდროულად შეუძლებელია მოცემულ დროს. ეს ასევე იწვევს ლოდინის ტიპს, რომელიც დაკავშირებულია პროცესორის დროის ნაკლებობასთან და რიგის ზრდასთან იმ დამგეგმავებისთვის, რომლებიც იყენებენ კონკრეტულ CPU ბირთვებს, ანუ runnable_tasks_count ინდიკატორი გაიზრდება ასეთ პირობებში.
ამ შემთხვევაში, CPU ბირთვების რაოდენობის გაზრდამდე, აუცილებელია თავად MS SQL Server ინსტანციის პარალელიზმის თვისებების სწორად კონფიგურაცია, ხოლო 2016 წლის ვერსიიდან, საჭირო მონაცემთა ბაზების პარალელიზმის თვისებების სწორად კონფიგურაცია:



აქ ყურადღება უნდა მიაქციოთ შემდეგ პარამეტრებს:

1. პარალელიზმის მაქსიმალური ხარისხი - ადგენს თითოეული მოთხოვნისთვის გამოყოფილი ნაკადების მაქსიმალურ რაოდენობას (ნაგულისხმევი მნიშვნელობაა 0 - შემოიფარგლება მხოლოდ ოპერაციული სისტემით და MS SQL Server-ის ვერსიით)
2. პარალელიზმის ღირებულების ზღვარი - პარალელიზმის სავარაუდო ღირებულება (ნაგულისხმევია 5)
3. Max DOP - განსაზღვრავს თითოეული შეკითხვისთვის მონაცემთა ბაზის დონეზე გამოყოფილი ნაკადების მაქსიმალურ რაოდენობას (მაგრამ არაუმეტეს "პარალელიზმის მაქსიმალური ხარისხის" თვისების მნიშვნელობისა) (ნაგულისხმევი მნიშვნელობაა 0 - შეზღუდულია მხოლოდ ოპერაციული სისტემით და MS SQL Server-ის ვერსიით, ასევე შეზღუდვაა მთელი MS SQL Server-ის ეგზემპლარის "პარალელიზმის მაქსიმალური ხარისხის" თვისებაზე)

შეუძლებელია ყველა შემთხვევისთვის თანაბრად კარგი რეცეპტის მოცემა, ანუ აუცილებელია რთული მოთხოვნების ანალიზი.
საკუთარი გამოცდილებიდან გამომდინარე, პარალელიზმის თვისებების კონფიგურაციისთვის OLTP სისტემებისთვის გირჩევთ მოქმედებების შემდეგ ალგორითმს:

1. პირველ რიგში, გამორთეთ პარალელიზმი პარალელიზმის მაქსიმალური ხარისხის 1-ზე დაყენებით ეგზემპლარის დონეზე.
2. გააანალიზეთ ყველაზე რთული მოთხოვნები და შეარჩიეთ მათთვის თემების ოპტიმალური რაოდენობა
3. დააყენეთ პარალელიზმის მაქსიმალური ხარისხი მე-2 ნაბიჯიდან მიღებული ნაკადების არჩეულ ოპტიმალურ რაოდენობაზე, ხოლო კონკრეტული მონაცემთა ბაზებისთვის დააყენეთ მაქსიმალური DOP მე-2 ნაბიჯიდან მიღებული თითოეული მონაცემთა ბაზისთვის.
4. გააანალიზეთ ყველაზე რთული მოთხოვნები და დაადგინეთ მრავალძაფიანი ვერსიის უარყოფითი ეფექტი. თუ ის არსებობს, მაშინ გაზარდეთ პარალელიზმის ღირებულების ზღვარი.
   ისეთი სისტემებისთვის, როგორიცაა 1C, Microsoft CRM და Microsoft NAV, მრავალძაფიანი ტექნოლოგიის გამორთვა უმეტეს შემთხვევაში იმუშავებს.

ასევე, თუ თქვენ გაქვთ სტანდარტული გამოცემა, მაშინ უმეტეს შემთხვევაში მრავალძაფიანი რეჟიმის გამორთვა შესაფერისი იქნება იმის გამო, რომ ეს გამოცემა შეზღუდულია CPU ბირთვების რაოდენობით.
ზემოთ აღწერილი ალგორითმი არ არის შესაფერისი OLAP სისტემებისთვის.
საკუთარი გამოცდილებიდან გამომდინარე, პარალელიზმის თვისებების კონფიგურაციისთვის OLAP სისტემებისთვის გირჩევთ მოქმედებების შემდეგ ალგორითმს:

1. გააანალიზეთ ყველაზე რთული მოთხოვნები და შეარჩიეთ მათთვის თემების ოპტიმალური რაოდენობა
2. დააყენეთ პარალელიზმის მაქსიმალური ხარისხი მე-1 ნაბიჯიდან მიღებული ნაკადების არჩეულ ოპტიმალურ რაოდენობაზე, ხოლო კონკრეტული მონაცემთა ბაზებისთვის დააყენეთ მაქსიმალური DOP მე-1 ნაბიჯიდან მიღებული თითოეული მონაცემთა ბაზისთვის.
3. გააანალიზეთ ყველაზე რთული მოთხოვნები და დაადგინეთ პარალელიზმის შეზღუდვის უარყოფითი ეფექტი. თუ ის არსებობს, მაშინ ან შეამცირეთ პარალელიზმის ღირებულების ზღვარი, ან გაიმეორეთ ამ ალგორითმის 1-2 ნაბიჯები.

ანუ, OLTP სისტემებისთვის ჩვენ ერთძაფიანიდან მრავალძაფიანზე გადავდივართ, ხოლო OLAP სისტემებისთვის, პირიქით - მრავალძაფიანიდან ერთძაფიანზე. ამ გზით, თქვენ შეგიძლიათ აირჩიოთ ოპტიმალური პარალელიზმის პარამეტრები როგორც კონკრეტული მონაცემთა ბაზისთვის, ასევე მთელი MS SQL Server ეგზემპლარისთვის.
ასევე მნიშვნელოვანია გვესმოდეს, რომ პარალელიზმის თვისებების პარამეტრები დროთა განმავლობაში უნდა შეიცვალოს, MS SQL Server-ის მუშაობის მონიტორინგის შედეგების საფუძველზე.

რეკომენდაციები კვალის დროშების დასაყენებლად

ჩემი და ჩემი კოლეგების გამოცდილების საფუძველზე, ოპტიმალური მუშაობისთვის გირჩევთ, MS SQL Server სერვისის გაშვების დონეზე 2008-2016 ვერსიებისთვის დააყენოთ შემდეგი კვალის დროშები:

1. 610 - ინდექსირებულ ცხრილებში ჩანართების ჟურნალირების შემცირება. შეიძლება დაგეხმაროთ ცხრილებში ჩასმაში, სადაც ბევრი ჩანაწერი და ტრანზაქციაა, რაც ხშირად იწვევს WRITELOG-ის ინდექსებში ცვლილებების ხანგრძლივი ლოდინის პერიოდს.
2. 1117 - თუ ფაილების ჯგუფში არსებული ფაილი აკმაყოფილებს ავტომატური ზრდის ზღვარს, ფაილების ჯგუფში არსებული ყველა ფაილი გაიზრდება.
3. 1118 - აიძულებს ყველა ობიექტს სხვადასხვა არეალში იყოს (არ იძლევა შერეულ არეალებს), რაც მინიმუმამდე ამცირებს შერეული არეალების თვალყურის დევნებისთვის გამოყენებული SGAM გვერდის სკანირების საჭიროებას.
4. 1224 - ბლოკირების ესკალაციის გამორთვა ბლოკირების რაოდენობის მიხედვით. თუმცა, მეხსიერების ჭარბმა გამოყენებამ შეიძლება გამოიწვიოს ესკალაციის გააქტიურება.
5. 2371 — ცვლის სტატისტიკის ფიქსირებულ ავტომატური განახლების ზღურბლს დინამიური ავტომატური განახლების ზღურბლით. მნიშვნელოვანია დიდ ცხრილებზე შეკითხვის გეგმების განახლებისთვის, სადაც რიგების რაოდენობის არასწორად შეფასება იწვევს შესრულების არასწორ გეგმებს.
6. 3226 - შეცდომების ჟურნალში სარეზერვო ასლის შექმნის წარმატების შესახებ შეტყობინებების დაბლოკვა
7. 4199 - მოიცავს ცვლილებებს SQL Server-ის კუმულაციურ განახლებებსა და სერვის პაკეტებში გამოშვებულ შეკითხვის ოპტიმიზატორში
8. 6532-6534 - მოიცავს სივრცითი მონაცემების ტიპებით შეკითხვის ოპერაციების შესრულების გაუმჯობესებას
9. 8048 - გარდაქმნის NUMA დანაყოფად მეხსიერების ობიექტებს CPU დანაყოფად მეხსიერების ობიექტებად
10. 8780 - დამატებითი დროის გამოყოფა საშუალებას იძლევა შეკითხვის გეგმის გენერირებისთვის. ზოგიერთი მოთხოვნა ამ დროშის გარეშე შეიძლება უარყოფილი იყოს, რადგან მათ არ აქვთ შეკითხვის გეგმა (ძალიან იშვიათი შეცდომა)
11. 8780 - 9389 - ჩართავს დამატებითი დინამიური მეხსიერების მინიჭებას პაკეტური რეჟიმის ოპერატორებისთვის, რაც საშუალებას აძლევს პაკეტური რეჟიმის ოპერატორს მოითხოვოს დამატებითი მეხსიერება და თავიდან აიცილოს მონაცემების გადატანა tempdb-ში, თუ დამატებითი მეხსიერება ხელმისაწვდომია.

ასევე, 2016 წლამდე სასარგებლო იყო 2301 კვალის დროშის ჩართვა, რომელიც საშუალებას იძლევა გაფართოებული გადაწყვეტილების მხარდაჭერის ოპტიმიზაციისთვის და ამით ხელს უწყობს უკეთესი შეკითხვის გეგმების შერჩევას. თუმცა, 2016 წლიდან დაწყებული, ეს ხშირად უარყოფით გავლენას ახდენს შეკითხვის შესრულების საკმაოდ ხანგრძლივ საერთო დროზე.
ასევე, ბევრი ინდექსის მქონე სისტემებისთვის (მაგალითად, 1C მონაცემთა ბაზებისთვის), გირჩევთ ჩართოთ კვალის დროშა 2330, რომელიც გამორთავს ინდექსის გამოყენების შეგროვებას, რაც, როგორც წესი, დადებითად მოქმედებს სისტემაზე.
დამატებითი ინფორმაცია კვალის დროშების შესახებ შეგიძლიათ იხილოთ აქ აქ
ზემოთ მოცემულ ბმულში ასევე მნიშვნელოვანია MS SQL Server-ის ვერსიებისა და ბილდების გათვალისწინება, რადგან უფრო ახალი ვერსიებისთვის ზოგიერთი კვალის დროშა ნაგულისხმევად ჩართულია ან არანაირი ეფექტი არ აქვს.
შეგიძლიათ ჩართოთ და გამორთოთ კვალის დროშა, შესაბამისად, DBCC TRACEON და DBCC TRACEOFF ბრძანებების გამოყენებით. დამატებითი ინფორმაციისთვის იხილეთ აქ
კვალის დროშების სტატუსის მიღება შეგიძლიათ DBCC TRACESTATUS ბრძანების გამოყენებით: მეტი
MS SQL Server სერვისის ავტომატურ გაშვებაში კვალის დროშების ჩასართავად, თქვენ უნდა გადახვიდეთ SQL Server კონფიგურაციის მენეჯერში და დაამატოთ ეს კვალის დროშები სერვისის თვისებებში -T ბრძანების მეშვეობით:

შედეგები

ამ სტატიაში განხილული იყო MS SQL Server-ის მონიტორინგის ზოგიერთი ასპექტი, რომელთა გამოყენება შესაძლებელია ოპერატიული მეხსიერებისა და პროცესორის თავისუფალი დროის ნაკლებობის, ასევე სხვა ნაკლებად აშკარა პრობლემების სწრაფად იდენტიფიცირებისთვის. განხილული იყო ყველაზე ხშირად გამოყენებული კვალის დროშები.

წყაროები:

» SQL Server-ის ლოდინის სტატისტიკა
» SQL Server-ის ლოდინის სტატისტიკა ან გთხოვთ მითხრათ, სად არის მტკივნეული
» სისტემის ხედი sys.dm_os_schedulers
» Zabbix-ის გამოყენება MS SQL Server მონაცემთა ბაზის მონიტორინგისთვის
» SQL ცხოვრების წესი
» კვალის დროშები
» sql.ru

წყარო: www.habr.com