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

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

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

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

RAM-ის ნაკლებობის გამოვლენის მეთოდი

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

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 Server ინსტანციისთვის.

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

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 სერვერის გამოცემა)
2. პარალელურობის ღირებულების ზღვარი - პარალელიზმის სავარაუდო ღირებულება (ნაგულისხმევი არის 5)
3. Max DOP - ადგენს ძაფების მაქსიმალურ რაოდენობას, რომელიც შეიძლება გამოყოს თითოეულ მოთხოვნას მონაცემთა ბაზის დონეზე (მაგრამ არა უმეტეს "Max Degree of Parallelism" თვისების მნიშვნელობისა) (ნაგულისხმევად ეს არის 0 - შეზღუდულია მხოლოდ ოპერაციული სისტემის მიერ. თავად და MS SQL Server-ის გამოცემა, ისევე როგორც მთელი MS SQL სერვერის ინსტანციის „პარალელიზმის მაქსიმალური ხარისხი“ თვისების შეზღუდვა)

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

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

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

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

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

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

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

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

შედეგები

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

წყაროები:

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

წყარო: www.habr.com