ບາງດ້ານຂອງການກວດສອບ MS SQL Server. ຄໍາແນະນໍາສໍາລັບການຕັ້ງທຸງຕິດຕາມ

ຄໍາອະທິຖານ

ເລື້ອຍໆ, ຜູ້ໃຊ້, ຜູ້ພັດທະນາແລະຜູ້ບໍລິຫານຂອງ MS SQL Server DBMS ປະເຊີນກັບບັນຫາການປະຕິບັດຂອງຖານຂໍ້ມູນຫຼື DBMS ໂດຍລວມ, ດັ່ງນັ້ນການຕິດຕາມ MS SQL Server ແມ່ນມີຄວາມກ່ຽວຂ້ອງຫຼາຍ.
ບົດຄວາມນີ້ເປັນການເພີ່ມເຕີມຂອງບົດຄວາມ ການນໍາໃຊ້ Zabbix ເພື່ອຕິດຕາມກວດກາຖານຂໍ້ມູນ MS SQL Server ແລະມັນຈະກວດສອບບາງດ້ານຂອງການກວດສອບ MS SQL Server, ໂດຍສະເພາະ: ວິທີການກໍານົດຢ່າງໄວວາວ່າຊັບພະຍາກອນໃດທີ່ຂາດຫາຍໄປ, ເຊັ່ນດຽວກັນກັບຄໍາແນະນໍາສໍາລັບການຕັ້ງທຸງຕິດຕາມ.
ເພື່ອໃຫ້ສະຄິບຕໍ່ໄປນີ້ເຮັດວຽກ, ທ່ານຈໍາເປັນຕ້ອງສ້າງ inf schema ໃນຖານຂໍ້ມູນທີ່ຕ້ອງການດັ່ງຕໍ່ໄປນີ້:
ການສ້າງ schema inf

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

ວິທີການກວດສອບການຂາດ RAM

ຕົວຊີ້ວັດທໍາອິດຂອງການຂາດ 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 ບໍ່ມີ RAM ພຽງພໍ. ຄ່າທີ່ສໍາຄັນແມ່ນຖືກກໍານົດເປັນສ່ວນບຸກຄົນສໍາລັບແຕ່ລະລະບົບ. ຢ່າງໃດກໍ່ຕາມ, ທ່ານສາມາດເລີ່ມຕົ້ນດ້ວຍຕົວຊີ້ວັດຕໍ່ໄປນີ້: ເປີເຊັນ>=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 ເທົ່າໃດໃຊ້ເວລາເປັນ milliseconds (ຄ່າສູງສຸດຂອງການຊັກຊ້າສະເລ່ຍທັງຫມົດສໍາລັບປະເພດການລໍຖ້າດັ່ງກ່າວທັງຫມົດ):

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

ອີງຕາມນະໂຍບາຍດ້ານຂອງຄ່າທີ່ໄດ້ຮັບສໍາລັບທັງສອງຕົວຊີ້ວັດນີ້, ພວກເຮົາສາມາດສະຫຼຸບໄດ້ວ່າມີ RAM ພຽງພໍສໍາລັບຕົວຢ່າງ 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 cores) ສໍາລັບ MS SQL Server ຕົວຢ່າງ.
ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຈື່ຈໍາຄວາມຈິງທີ່ວ່າຄໍາຖາມດ້ວຍຕົນເອງສາມາດສອບຖາມຫຼາຍຫົວຂໍ້ໃນເວລາດຽວກັນ. ແລະບາງຄັ້ງ optimizer ບໍ່ສາມາດປະເມີນຄວາມສັບສົນຂອງການສອບຖາມໄດ້ຢ່າງຖືກຕ້ອງ. ຫຼັງຈາກນັ້ນ, ການຮ້ອງຂໍອາດຈະຖືກຈັດສັນຫຼາຍຫົວຂໍ້ເກີນໄປ, ເຊິ່ງໃນເວລາໃດຫນຶ່ງບໍ່ສາມາດດໍາເນີນການພ້ອມກັນໄດ້. ແລະນີ້ຍັງເຮັດໃຫ້ເກີດປະເພດຂອງການລໍຖ້າທີ່ກ່ຽວຂ້ອງກັບການຂາດເວລາຂອງໂປເຊດເຊີ, ແລະການຂະຫຍາຍຕົວຂອງແຖວສໍາລັບຜູ້ກໍານົດເວລາທີ່ໃຊ້ CPU cores ສະເພາະ, ນັ້ນແມ່ນ, ຕົວຊີ້ວັດ runnable_tasks_count ຈະເພີ່ມຂຶ້ນໃນເງື່ອນໄຂດັ່ງກ່າວ.
ໃນກໍລະນີນີ້, ກ່ອນທີ່ຈະເພີ່ມຈໍານວນຂອງ CPU cores, ທ່ານຈໍາເປັນຕ້ອງ configure ຄຸນສົມບັດຂະຫນານຂອງ MS SQL Server ຕົວຂອງມັນເອງຢ່າງຖືກຕ້ອງ, ແລະຈາກສະບັບ 2016, ຢ່າງຖືກຕ້ອງ configure ຄຸນສົມບັດຂະຫນານຂອງຖານຂໍ້ມູນທີ່ກໍານົດໄວ້:



ທີ່ນີ້ທ່ານຄວນເອົາໃຈໃສ່ກັບຕົວກໍານົດການດັ່ງຕໍ່ໄປນີ້:

1. Max Degree of Parallelism - ກໍານົດຈໍານວນຫົວຂໍ້ສູງສຸດທີ່ສາມາດຈັດສັນໃຫ້ກັບແຕ່ລະຄໍາຮ້ອງຂໍ (ຄ່າເລີ່ມຕົ້ນແມ່ນ 0 - ຈໍາກັດພຽງແຕ່ໂດຍລະບົບປະຕິບັດການຂອງມັນເອງແລະສະບັບຂອງ MS SQL Server)
2. ຄ່າ​ໃຊ້​ຈ່າຍ​ສໍາ​ລັບ​ການ​ຂະ​ຫນານ - ການ​ຄາດ​ຄະ​ເນ​ຄ່າ​ໃຊ້​ຈ່າຍ​ຂອງ​ຂະ​ຫນານ (ຄ່າ​ເລີ່ມ​ຕົ້ນ​ແມ່ນ 5​)
3. Max DOP - ກໍານົດຈໍານວນຫົວຂໍ້ສູງສຸດທີ່ສາມາດຈັດສັນໃຫ້ກັບແຕ່ລະແບບສອບຖາມໃນລະດັບຖານຂໍ້ມູນ (ແຕ່ບໍ່ເກີນມູນຄ່າຂອງຄຸນສົມບັດ "ລະດັບຄວາມຂະຫນານສູງສຸດ") (ໂດຍຄ່າເລີ່ມຕົ້ນມັນແມ່ນ 0 - ຈໍາກັດໂດຍລະບົບປະຕິບັດການເທົ່ານັ້ນ. ຕົວຂອງມັນເອງແລະສະບັບຂອງ MS SQL Server, ເຊັ່ນດຽວກັນກັບຂໍ້ຈໍາກັດກ່ຽວກັບຄຸນສົມບັດ "ລະດັບສູງສຸດຂອງຂະຫນານ" ຂອງ MS SQL Server ທັງຫມົດຕົວຢ່າງ)

ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະໃຫ້ສູດທີ່ດີເທົ່າທຽມກັນສໍາລັບທຸກໆກໍລະນີ, ນັ້ນແມ່ນ, ທ່ານຈໍາເປັນຕ້ອງວິເຄາະຄໍາຖາມທີ່ຫຍຸ້ງຍາກ.
ອີງຕາມປະສົບການຂອງຂ້ອຍເອງ, ຂ້ອຍຂໍແນະນໍາ algorithm ຕໍ່ໄປນີ້ຂອງການປະຕິບັດສໍາລັບລະບົບ OLTP ເພື່ອກໍານົດຄຸນສົມບັດຂະຫນານ:

1. ທໍາອິດປິດການຂະຫນານໂດຍການກໍານົດລະດັບສູງສຸດຂອງຂະຫນານເປັນ 1 ໃນລະດັບຂອງຕົວຢ່າງທັງຫມົດ.
2. ວິເຄາະການສອບຖາມທີ່ໜັກທີ່ສຸດ ແລະເລືອກຈຳນວນຫົວຂໍ້ທີ່ເໝາະສົມສຳລັບພວກມັນ
3. ກໍານົດລະດັບສູງສຸດຂອງຂະຫນານເປັນຈໍານວນທີ່ດີທີ່ສຸດທີ່ເລືອກຂອງກະທູ້ທີ່ໄດ້ຮັບຈາກຂັ້ນຕອນທີ 2, ແລະສໍາລັບຖານຂໍ້ມູນສະເພາະກໍານົດຄ່າ Max DOP ທີ່ໄດ້ຮັບຈາກຂັ້ນຕອນທີ 2 ສໍາລັບແຕ່ລະຖານຂໍ້ມູນ.
4. ວິເຄາະການສອບຖາມທີ່ຫນັກທີ່ສຸດແລະກໍານົດຜົນກະທົບທາງລົບຂອງ multithreading. ຖ້າມັນເປັນ, ຫຼັງຈາກນັ້ນເພີ່ມຄ່າໃຊ້ຈ່າຍໃນຂອບເຂດສໍາລັບຂະຫນານ.
   ສໍາລັບລະບົບເຊັ່ນ 1C, Microsoft CRM ແລະ Microsoft NAV, ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ການຫ້າມ multithreading ແມ່ນເຫມາະສົມ

ນອກຈາກນີ້, ຖ້າທ່ານມີສະບັບມາດຕະຖານ, ຫຼັງຈາກນັ້ນໃນກໍລະນີຫຼາຍທີ່ສຸດ, ການຫ້າມຫຼາຍ threading ແມ່ນເຫມາະສົມເນື່ອງຈາກຄວາມຈິງທີ່ວ່າສະບັບນີ້ແມ່ນຈໍາກັດໃນຈໍານວນຂອງ CPU cores.
ສູດການຄິດໄລ່ທີ່ອະທິບາຍຂ້າງເທິງນີ້ບໍ່ເຫມາະສົມສໍາລັບລະບົບ OLAP.
ອີງໃສ່ປະສົບການຂອງຂ້ອຍເອງ, ຂ້ອຍຂໍແນະນໍາ algorithm ຕໍ່ໄປນີ້ຂອງການປະຕິບັດສໍາລັບລະບົບ OLAP ເພື່ອກໍານົດຄຸນສົມບັດຂະຫນານ:

1. ວິເຄາະການສອບຖາມທີ່ໜັກທີ່ສຸດ ແລະເລືອກຈຳນວນຫົວຂໍ້ທີ່ເໝາະສົມສຳລັບພວກມັນ
2. ກໍານົດລະດັບສູງສຸດຂອງຂະຫນານເປັນຈໍານວນທີ່ດີທີ່ສຸດທີ່ເລືອກຂອງກະທູ້ທີ່ໄດ້ຮັບຈາກຂັ້ນຕອນທີ 1, ແລະສໍາລັບຖານຂໍ້ມູນສະເພາະກໍານົດຄ່າ Max DOP ທີ່ໄດ້ຮັບຈາກຂັ້ນຕອນທີ 1 ສໍາລັບແຕ່ລະຖານຂໍ້ມູນ.
3. ວິເຄາະການສອບຖາມທີ່ຫນັກຫນ່ວງທີ່ສຸດແລະກໍານົດຜົນກະທົບທາງລົບຂອງການຈໍາກັດຄວາມສອດຄ່ອງ. ຖ້າມັນເປັນ, ຫຼັງຈາກນັ້ນໃຫ້ຫຼຸດຂອບເຂດຄ່າໃຊ້ຈ່າຍສໍາລັບຄ່າຂະຫນານ, ຫຼືເຮັດຊ້ໍາຂັ້ນຕອນ 1-2 ຂອງສູດການຄິດໄລ່ນີ້.

ນັ້ນແມ່ນ, ສໍາລັບລະບົບ OLTP ພວກເຮົາໄປຈາກກະທູ້ດຽວໄປຫາຫຼາຍກະທູ້, ແລະສໍາລັບລະບົບ OLAP, ໃນທາງກົງກັນຂ້າມ, ພວກເຮົາໄປຈາກຫຼາຍກະທູ້ໄປຫາກະທູ້ດຽວ. ວິທີນີ້ທ່ານສາມາດເລືອກການຕັ້ງຄ່າຂະຫນານທີ່ດີທີ່ສຸດທັງສໍາລັບຖານຂໍ້ມູນສະເພາະແລະສໍາລັບຕົວຢ່າງ MS SQL Server ທັງຫມົດ.
ມັນຍັງມີຄວາມສໍາຄັນທີ່ຈະເຂົ້າໃຈວ່າການຕັ້ງຄ່າຄຸນສົມບັດທີ່ສອດຄ່ອງກັນຕ້ອງມີການປ່ຽນແປງໃນໄລຍະເວລາ, ອີງຕາມຜົນຂອງການຕິດຕາມການປະຕິບັດຂອງ MS SQL Server.

ຄໍາແນະນໍາສໍາລັບການຕັ້ງທຸງຕິດຕາມ

ຈາກປະສົບການຂອງຕົນເອງແລະປະສົບການຂອງເພື່ອນຮ່ວມງານ, ສໍາລັບການປະຕິບັດທີ່ດີທີ່ສຸດ, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ຕັ້ງທຸງຕິດຕາມຕໍ່ໄປນີ້ໃນລະດັບການບໍລິການ MS SQL Server ສໍາລັບຮຸ່ນ 2008-2016:

1. 610 - ຫຼຸດຜ່ອນການຕັດໄມ້ຂອງ inserts ເຂົ້າໄປໃນຕາຕະລາງດັດສະນີ. ສາມາດຊ່ວຍໃນການແຊກເຂົ້າໄປໃນຕາຕະລາງທີ່ມີຈໍານວນຫລາຍຂອງບັນທຶກແລະການເຮັດທຸລະກໍາຫຼາຍ, ໂດຍມີ WRITELOG ເລື້ອຍໆລໍຖ້າການປ່ຽນແປງໃນດັດສະນີ.
2. 1117 - ຖ້າໄຟລ໌ໃນກຸ່ມໄຟລ໌ກົງກັບເກນການເຕີບໂຕອັດຕະໂນມັດ, ໄຟລ໌ທັງໝົດໃນກຸ່ມໄຟລ໌ຈະຖືກຂະຫຍາຍ.
3. 1118 - ບັງຄັບໃຫ້ວັດຖຸທັງໝົດຕັ້ງຢູ່ໃນຂອບເຂດຕ່າງກັນ (ບໍ່ອະນຸຍາດຂອບເຂດປະສົມ), ເຊິ່ງຫຼຸດຜ່ອນຄວາມຈໍາເປັນໃນການສະແກນຫນ້າ SGAM, ເຊິ່ງຖືກນໍາໃຊ້ເພື່ອຕິດຕາມຂອບເຂດປະສົມ.
4. 1224 - ປິດ​ການ​ໃຊ້​ງານ​ການ lock escalation ໂດຍ​ອີງ​ໃສ່​ການ​ນັບ​lock​. ຢ່າງໃດກໍ່ຕາມ, ການໃຊ້ຄວາມຊົງຈໍາຫຼາຍເກີນໄປສາມາດເຮັດໃຫ້ການເພີ່ມການລັອກໄດ້
5. 2371 - ປ່ຽນແປງຂອບເຂດການປັບປຸງສະຖິຕິອັດຕະໂນມັດຄົງທີ່ເປັນຂອບເຂດການປັບປຸງສະຖິຕິອັດຕະໂນມັດແບບເຄື່ອນໄຫວ. ສິ່ງສໍາຄັນສໍາລັບການປັບປຸງແຜນການສອບຖາມໃນຕາຕະລາງຂະຫນາດໃຫຍ່ທີ່ກໍານົດຈໍານວນບັນທຶກທີ່ບໍ່ຖືກຕ້ອງເຮັດໃຫ້ແຜນການປະຕິບັດຜິດພາດ.
6. 3226 - ສະກັດກັ້ນຂໍ້ຄວາມສໍາເລັດການສໍາຮອງຂໍ້ມູນໃນບັນທຶກຄວາມຜິດພາດ
7. 4199 - ລວມມີການປ່ຽນແປງຕໍ່ກັບຕົວເພີ່ມປະສິດທິພາບແບບສອບຖາມທີ່ປ່ອຍອອກມາໃນ SQL Server rollups ແລະຊຸດບໍລິການ.
8. 6532-6534 - ລວມມີການປັບປຸງປະສິດທິພາບສໍາລັບການສອບຖາມທີ່ມີປະເພດຂໍ້ມູນທາງກວ້າງຂອງພື້ນ
9. 8048 - ແປງວັດຖຸໜ່ວຍຄວາມຈຳທີ່ແບ່ງສ່ວນ NUMA ໄປເປັນອັນທີ່ຈັດແບ່ງ CPU
10. 8780 - ເປີດໃຊ້ການຈັດສັນເວລາເພີ່ມເຕີມສໍາລັບການວາງແຜນການສອບຖາມ. ບາງຄໍາຮ້ອງຂໍທີ່ບໍ່ມີທຸງນີ້ອາດຈະຖືກປະຕິເສດເພາະວ່າພວກເຂົາບໍ່ມີແຜນການສອບຖາມ (ຄວາມຜິດພາດທີ່ຫາຍາກຫຼາຍ)
11. 8780 - 9389 - ເປີດໃຊ້ buffer ຄວາມຊົງຈໍາຊົ່ວຄາວແບບໄດນາມິກເພີ່ມເຕີມສໍາລັບຕົວປະຕິບັດການ batch mode, ອະນຸຍາດໃຫ້ຜູ້ປະກອບການ batch mode ຮ້ອງຂໍຄວາມຈໍາເພີ່ມເຕີມແລະຫຼີກເວັ້ນການໂອນຂໍ້ມູນໄປ 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 Server, ດ້ວຍການຊ່ວຍເຫຼືອທີ່ທ່ານສາມາດກໍານົດການຂາດ RAM ແລະເວລາ CPU ຟຣີ, ເຊັ່ນດຽວກັນກັບບັນຫາອື່ນໆທີ່ບໍ່ຄ່ອຍຊັດເຈນ. ທຸງຕິດຕາມທີ່ໃຊ້ທົ່ວໄປທີ່ສຸດໄດ້ຖືກທົບທວນຄືນ.

ແຫຼ່ງຂໍ້ມູນ:

» SQL Server ລໍຖ້າສະຖິຕິ
» SQL Server ລໍຖ້າສະຖິຕິຫຼືກະລຸນາບອກຂ້ອຍບ່ອນທີ່ມັນເຈັບປວດ
» ມຸມມອງລະບົບ sys.dm_os_schedulers
» ການນໍາໃຊ້ Zabbix ເພື່ອຕິດຕາມກວດກາຖານຂໍ້ມູນ MS SQL Server
» SQL ຊີວິດ
» ທຸງຕິດຕາມ
» sql.ru

ແຫຼ່ງຂໍ້ມູນ: www.habr.com