ទិដ្ឋភាពមួយចំនួននៃការត្រួតពិនិត្យម៉ាស៊ីនមេ MS SQL ។ គោលការណ៍ណែនាំសម្រាប់ការកំណត់ទង់ដាន

បុព្វកថា

ជាញឹកញាប់ អ្នកប្រើប្រាស់ អ្នកអភិវឌ្ឍន៍ និងអ្នកគ្រប់គ្រង MS SQL Server DBMS ប្រឈមមុខនឹងបញ្ហាដំណើរការនៃមូលដ្ឋានទិន្នន័យ ឬ DBMS ទាំងមូល ដូច្នេះការត្រួតពិនិត្យ MS SQL Server គឺពាក់ព័ន្ធខ្លាំងណាស់។
អត្ថបទនេះគឺជាការបន្ថែមលើអត្ថបទ ការប្រើប្រាស់ Zabbix ដើម្បីត្រួតពិនិត្យ MS SQL Server Database ហើយវានឹងពិនិត្យមើលទិដ្ឋភាពមួយចំនួននៃការត្រួតពិនិត្យ MS SQL Server ជាពិសេស៖ របៀបកំណត់យ៉ាងរហ័សនូវធនធានណាមួយដែលបាត់ ក៏ដូចជាការណែនាំសម្រាប់ការដំឡើងទង់ដាន។
ដើម្បីឱ្យស្គ្រីបខាងក្រោមដំណើរការ អ្នកត្រូវបង្កើតគ្រោងការណ៍ inf នៅក្នុងមូលដ្ឋានទិន្នន័យដែលចង់បានដូចខាងក្រោម៖
ការបង្កើតគ្រោងការណ៍ 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 instance មិនមាន 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 ប៉ុន្មានត្រូវចំណាយពេលគិតជាមិល្លីវិនាទី (តម្លៃអតិបរមានៃការពន្យាពេលជាមធ្យមទាំងអស់សម្រាប់ប្រភេទរង់ចាំទាំងអស់)៖

   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 ដែរឬទេ។

វិធីសាស្រ្តរកឃើញការផ្ទុកស៊ីភីយូលើស

ដើម្បីកំណត់អត្តសញ្ញាណកង្វះពេលវេលាស៊ីភីយូ គ្រាន់តែប្រើទិដ្ឋភាពប្រព័ន្ធ 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;

ដោយផ្អែកលើសក្ដានុពលនៃតម្លៃដែលទទួលបានសម្រាប់សូចនាករនេះ យើងអាចសន្និដ្ឋានថាតើមានពេលវេលាដំណើរការគ្រប់គ្រាន់ (ចំនួនស្នូលស៊ីភីយូ) សម្រាប់ឧទាហរណ៍ MS SQL Server ដែរឬទេ។
ទោះជាយ៉ាងណាក៏ដោយ វាជារឿងសំខាន់ក្នុងការចងចាំនូវការពិតដែលថា សំណួរខ្លួនឯងអាចសួរខ្សែស្រឡាយជាច្រើនក្នុងពេលតែមួយ។ ហើយពេលខ្លះកម្មវិធីបង្កើនប្រសិទ្ធភាពមិនអាចប៉ាន់ស្មានបានត្រឹមត្រូវនូវភាពស្មុគស្មាញនៃសំណួរដោយខ្លួនឯងនោះទេ។ បន្ទាប់មកសំណើអាចត្រូវបានបែងចែកខ្សែស្រឡាយច្រើនពេក ដែលនៅពេលកំណត់មិនអាចដំណើរការក្នុងពេលដំណាលគ្នាបានទេ។ ហើយនេះក៏បណ្តាលឱ្យប្រភេទនៃការរង់ចាំដែលត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងការខ្វះខាតពេលវេលាដំណើរការ ហើយការកើនឡើងនៃជួរសម្រាប់អ្នកកំណត់ពេលដែលប្រើស្នូលស៊ីភីយូជាក់លាក់ នោះគឺជាសូចនាករ runnable_tasks_count នឹងកើនឡើងនៅក្នុងលក្ខខណ្ឌបែបនេះ។
ក្នុងករណីនេះ មុននឹងបង្កើនចំនួន CPU cores អ្នកត្រូវកំណត់រចនាសម្ព័ន្ធ parallelism យ៉ាងត្រឹមត្រូវនៃ instance MS SQL Server ខ្លួនវា ហើយពី version 2016 កំណត់រចនាសម្ព័ន្ធ parallelism យ៉ាងត្រឹមត្រូវនៃ databases ដែលត្រូវការ៖



នៅទីនេះអ្នកគួរយកចិត្តទុកដាក់លើប៉ារ៉ាម៉ែត្រដូចខាងក្រោម:

1. Max Degree of Parallelism—កំណត់ចំនួនអតិបរិមានៃខ្សែស្រឡាយដែលអាចត្រូវបានបែងចែកទៅតាមសំណើនីមួយៗ (លំនាំដើមគឺ 0—កំណត់ដោយប្រព័ន្ធប្រតិបត្តិការផ្ទាល់ និងការបោះពុម្ពរបស់ MS SQL Server)
2. កម្រិតចំណាយសម្រាប់ភាពស្របគ្នា - តម្លៃប៉ាន់ស្មាននៃភាពស្របគ្នា (លំនាំដើមគឺ 5)
3. Max DOP - កំណត់ចំនួនអតិបរមានៃខ្សែស្រឡាយដែលអាចត្រូវបានបម្រុងទុកសម្រាប់សំណួរនីមួយៗនៅកម្រិតមូលដ្ឋានទិន្នន័យ (ប៉ុន្តែមិនលើសពីតម្លៃនៃទ្រព្យសម្បត្តិ "សញ្ញាបត្រអតិបរមានៃភាពស្របគ្នា") (តាមលំនាំដើមវាគឺ 0 - កំណត់ដោយប្រព័ន្ធប្រតិបត្តិការតែប៉ុណ្ណោះ។ ខ្លួនវាផ្ទាល់ និងការបោះពុម្ពរបស់ MS SQL Server ក៏ដូចជាការកំណត់លើទ្រព្យសម្បត្តិ "កម្រិតអតិបរមានៃភាពស្របគ្នា" នៃ MS SQL Server ទាំងមូល)

វាមិនអាចទៅរួចទេក្នុងការផ្តល់នូវរូបមន្តដ៏ល្អស្មើគ្នាសម្រាប់គ្រប់ករណីទាំងអស់ នោះគឺអ្នកត្រូវវិភាគសំណួរពិបាកៗ។
ដោយផ្អែកលើបទពិសោធន៍ផ្ទាល់ខ្លួនរបស់ខ្ញុំ ខ្ញុំសូមណែនាំក្បួនដោះស្រាយខាងក្រោមនៃសកម្មភាពសម្រាប់ប្រព័ន្ធ OLTP ដើម្បីកំណត់រចនាសម្ព័ន្ធភាពស្របគ្នា៖

1. ទីមួយបិទភាពស្របគ្នាដោយកំណត់ Max Degree of Parallelism ទៅ 1 នៅកម្រិតនៃឧទាហរណ៍ទាំងមូល
2. វិភាគ​សំណួរ​ដែល​ធ្ងន់​បំផុត ហើយ​ជ្រើស​ចំនួន​ខ្សែ​ស្រឡាយ​ដ៏​ល្អ​បំផុត​សម្រាប់​ពួកគេ។
3. កំណត់កំរិតអតិបរិមានៃភាពស្របគ្នាទៅនឹងចំនួនខ្សែស្រឡាយល្អបំផុតដែលបានជ្រើសរើសពីជំហានទី 2 ហើយសម្រាប់មូលដ្ឋានទិន្នន័យជាក់លាក់កំណត់តម្លៃ DOP អតិបរមាដែលទទួលបានពីជំហានទី 2 សម្រាប់មូលដ្ឋានទិន្នន័យនីមួយៗ។
4. វិភាគសំណួរដែលធ្ងន់បំផុត និងកំណត់ពីឥទ្ធិពលអវិជ្ជមាននៃ multithreading ។ ប្រសិនបើវាគឺ នោះត្រូវបង្កើនកម្រិតចំណាយសម្រាប់ភាពស្របគ្នា។
   សម្រាប់ប្រព័ន្ធដូចជា 1C, Microsoft CRM និង Microsoft NAV ក្នុងករណីភាគច្រើនការហាមឃាត់ការបញ្ចូលពហុខ្សែគឺសមរម្យ

ដូចគ្នានេះផងដែរប្រសិនបើអ្នកមាន Standard edition នោះក្នុងករណីភាគច្រើនការហាមប្រាមលើ multi-threading គឺសមរម្យដោយសារតែការពិតដែលថាការបោះពុម្ពនេះត្រូវបានកំណត់ក្នុងចំនួន CPU cores ។
ក្បួនដោះស្រាយដែលបានពិពណ៌នាខាងលើគឺមិនសមរម្យសម្រាប់ប្រព័ន្ធ 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 rollups និងកញ្ចប់សេវាកម្ម
8. 6532-6534 - រួមបញ្ចូលការកែលម្អការអនុវត្តសម្រាប់សំណួរដែលមានប្រភេទទិន្នន័យទំហំ
9. 8048 - បំប្លែងវត្ថុអង្គចងចាំដែលបានបែងចែក NUMA ទៅជាវត្ថុដែលមានការបែងចែកស៊ីភីយូ
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 Server ដោយមានជំនួយដែលអ្នកអាចកំណត់អត្តសញ្ញាណកង្វះ RAM និងពេលវេលាស៊ីភីយូដោយឥតគិតថ្លៃ ព្រមទាំងបញ្ហាមួយចំនួនផ្សេងទៀតដែលមិនសូវច្បាស់។ ទង់ដានដែលប្រើជាទូទៅបំផុតត្រូវបានពិនិត្យ។

ប្រភព:

» SQL Server រង់ចាំស្ថិតិ
» SQL Server រង់ចាំស្ថិតិ ឬសូមប្រាប់ខ្ញុំពីកន្លែងដែលវាឈឺ
» ទិដ្ឋភាពប្រព័ន្ធ sys.dm_os_schedulers
» ការប្រើប្រាស់ Zabbix ដើម្បីត្រួតពិនិត្យ MS SQL Server Database
» របៀបរស់នៅ SQL
» ទង់ដាន
» sql.ru

ប្រភព: www.habr.com