စကားချီး
မကြာခဏဆိုသလို၊ MS SQL Server DBMS ၏အသုံးပြုသူများ၊ ဆော့ဖ်ဝဲအင်ဂျင်နီယာများနှင့် စီမံခန့်ခွဲသူများသည် ဒေတာဘေ့စ် သို့မဟုတ် DBMS တစ်ခုလုံး၏ စွမ်းဆောင်ရည်ပြဿနာများကို ကြုံတွေ့ရသောကြောင့် MS SQL Server စောင့်ကြည့်ခြင်းသည် အလွန်သက်ဆိုင်ပါသည်။
ဤဆောင်းပါးသည် ဆောင်းပါး၏ အပိုဆောင်းဖြစ်သည်။ အထူးသဖြင့် MS SQL Server ကို စောင့်ကြည့်ခြင်း၏ အချို့သော ကဏ္ဍများကို အကျုံးဝင်သည်- မည်သည့် အရင်းအမြစ်များ ပျောက်ဆုံးနေသည်ကို လျင်မြန်စွာ ဆုံးဖြတ်နည်းနှင့် ခြေရာခံ အလံများ သတ်မှတ်ခြင်းအတွက် အကြံပြုချက်များ ပါဝင်သည်။
အောက်ဖော်ပြပါ scripts များအလုပ်လုပ်ရန်အတွက်၊ သင်အလိုရှိသောဒေတာဘေ့စ်တွင် အောက်ပါအတိုင်း inf schema ကိုဖန်တီးရန်လိုအပ်သည်-
inf schema ဖန်တီးခြင်း။
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 ၏ စံနမူနာတစ်ခုသည် အောက်ပါမေးမြန်းချက်ဖြင့် ၎င်းအတွက် ခွဲဝေပေးထားသော memory အားလုံးကို စားသုံးကြောင်း သင်ဆုံးဖြတ်နိုင်သည်-
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 View ကို ဖန်တီးခြင်း။
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) သို့ ညွှန်ကိန်းများကို ထုတ်ပေးရန်အတွက် အောက်ပါမေးခွန်းနှစ်ခုကို သင်ဖန်တီးနိုင်သည်-
- ရာခိုင်နှုန်းဖြင့် RAM က စောင့်ဆိုင်းမှု အမျိုးအစား မည်မျှကို သိမ်းပိုက်သည် (ထိုကဲ့သို့သော စောင့်ဆိုင်းမှု အမျိုးအစားအားလုံး၏ ပေါင်းလဒ်)။
select coalesce(sum([Percentage]), 0.00) as [Percentage] from [inf].[vWaits] where [WaitType] in ( 'PAGEIOLATCH_XX', 'RESOURCE_SEMAPHORE', 'RESOURCE_SEMAPHORE_QUERY_COMPILE' ); - 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 ၏ဥပမာတစ်ခုအတွက် RAM လုံလောက်မှုရှိမရှိ ကောက်ချက်ချနိုင်ပါသည်။
CPU Overload Detection နည်းလမ်း
ပရိုဆက်ဆာအချိန်မရှိခြင်းကို ဖော်ထုတ်ရန်၊ sys.dm_os_schedulers စနစ်မြင်ကွင်းကို အသုံးပြုရန် လုံလောက်ပါသည်။ ဤတွင်၊ runnable_tasks_count သည် 1 ထက် အဆက်မပြတ် ကြီးနေပါက၊ MS SQL Server ဥပမာအတွက် cores အရေအတွက် မလုံလောက်ခြင်း ဖြစ်နိုင်ခြေ မြင့်မားပါသည်။
စောင့်ကြည့်ရေးစနစ် (ဥပမာ Zabbix) သို့ ညွှန်ပြချက်တစ်ခု ထုတ်ပေးရန် သင်သည် အောက်ပါမေးခွန်းကို ဖန်တီးနိုင်သည်-
select max([runnable_tasks_count]) as [runnable_tasks_count]
from sys.dm_os_schedulers
where scheduler_id<255;
ဤအညွှန်းအတွက်ရရှိသောတန်ဖိုးများ၏ဒိုင်နနမစ်များကိုအခြေခံ၍ MS SQL Server ၏ဥပမာတစ်ခုအတွက် ပရိုဆက်ဆာအချိန် (CPU cores အရေအတွက်) လုံလောက်မှုရှိမရှိ ကောက်ချက်ချနိုင်ပါသည်။
သို့သော် တောင်းဆိုမှုများသည် တစ်ကြိမ်တည်းတွင် စာတွဲများစွာကို တောင်းဆိုနိုင်သည်ဟူသောအချက်ကို မှတ်သားထားရန် အရေးကြီးသည်။ တစ်ခါတစ်ရံတွင် optimizer သည် query ၏ရှုပ်ထွေးမှုကို သူ့ဘာသာသူ မှန်ကန်စွာ ခန့်မှန်း၍မရပါ။ ထို့နောက် တောင်းဆိုချက်သည် သတ်မှတ်အချိန်အတွင်း တစ်ချိန်တည်းတွင် လုပ်ဆောင်၍မရသော စာတွဲများစွာကို ခွဲဝေပေးနိုင်သည်။ ထို့အပြင် ၎င်းသည် ပရိုဆက်ဆာအချိန်မရှိခြင်းနှင့် ဆက်စပ်နေသော စောင့်ဆိုင်းမှုအမျိုးအစားကိုလည်း ဖြစ်စေပြီး သီးခြား CPU cores များကို အသုံးပြုသည့် အစီအစဉ်ဆွဲသူများအတွက် တန်းစီတိုးတက်မှု၊ ဆိုလိုသည်မှာ ထိုအခြေအနေများတွင် runnable_tasks_count ညွှန်ကိန်းသည် ကြီးထွားလာမည်ဖြစ်သည်။
ဤကိစ္စတွင်၊ CPU cores အရေအတွက်များမတိုးမီ၊ MS SQL Server ၏ဥပမာကိုယ်တိုင်၏ parallelism ဂုဏ်သတ္တိများကို မှန်ကန်စွာသတ်မှတ်ရန်လိုအပ်ပြီး 2016 ဗားရှင်းမှ လိုအပ်သောဒေတာဘေ့စ်များ၏ parallelism ဂုဏ်သတ္တိများကို မှန်ကန်စွာပြင်ဆင်သတ်မှတ်ရန် လိုအပ်ပါသည်။
ဤနေရာတွင် သင်သည် အောက်ပါ parameters များကို ဂရုပြုသင့်သည်-
- Max Parallelism ဒီဂရီ - တောင်းဆိုချက်တစ်ခုစီအတွက် ခွဲဝေပေးနိုင်သည့် အများဆုံးအရေအတွက်ကို သတ်မှတ်ပေးသည် (မူရင်းမှာ 0 - လည်ပတ်မှုစနစ်ကိုယ်တိုင်နှင့် MS SQL ဆာဗာ၏ ထုတ်ဝေမှုတွင်သာ ကန့်သတ်ထားသည်)
- Parallelism အတွက် ကုန်ကျစရိတ် ကန့်သတ်ချက် - ပြိုင်တူဝါဒ၏ ခန့်မှန်းကုန်ကျစရိတ် (မူရင်းမှာ 5)
- Max DOP - ဒေတာဘေ့စ်အဆင့်တွင် စုံစမ်းမှုတစ်ခုစီအတွက် ခွဲဝေပေးနိုင်သည့် အများဆုံးအရေအတွက်ကို သတ်မှတ်ပေးသည် (သို့သော် "မတူညီမှု၏ အမြင့်ဆုံးဒီဂရီ" ပိုင်ဆိုင်မှုတန်ဖိုးထက် မပိုပါ) (မူလသည် 0 - လည်ပတ်မှုစနစ်ကိုယ်တိုင်ကသာ ကန့်သတ်ထားပြီး၊ MS SQL Server ၏ထုတ်ဝေမှုအပြင် MS SQL Server ၏ဥပမာတစ်ခုလုံး၏ "Max Degree of Parallelism" ပိုင်ဆိုင်မှုအပေါ် ကန့်သတ်ချက်များ)
ဤတွင် ကိစ္စအားလုံးအတွက် အညီအမျှ ကောင်းမွန်သော စာရွက်တစ်ခု ပေးရန် မဖြစ်နိုင်ပါ၊ ဆိုလိုသည်မှာ သင်သည် လေးလံသော မေးခွန်းများကို ခွဲခြမ်းစိတ်ဖြာရန် လိုအပ်ပါသည်။
ကျွန်ုပ်၏ကိုယ်ပိုင်အတွေ့အကြုံအရ၊ parallelism ဂုဏ်သတ္တိများသတ်မှတ်ခြင်းအတွက် OLTP စနစ်များအတွက် အောက်ပါ algorithm လုပ်ဆောင်ချက်များကို အကြံပြုပါသည်။
- ပထမဦးစွာ ဥပမာ-ကျယ်ပြန့်သော Max Degree of Parallelism ကို 1 သို့ သတ်မှတ်ခြင်းဖြင့် ပြိုင်တူဝါဒကို ပိတ်ပါ။
- အလေးဆုံးတောင်းဆိုမှုများကို ခွဲခြမ်းစိတ်ဖြာပြီး ၎င်းတို့အတွက် အကောင်းဆုံး အရေအတွက်ကို ရွေးချယ်ပါ။
- အဆင့် 2 မှရရှိသော ရွေးချယ်ထားသော အကောင်းဆုံးသော အတွဲအရေအတွက်ကို မျဉ်းပြိုင်၏ Max Degree ကို သတ်မှတ်ပြီး ဒေတာဘေ့စ်တစ်ခုစီအတွက် အဆင့် 2 မှရရှိသော Max DOP တန်ဖိုးကို သတ်မှတ်ပါ။
- အပြင်းထန်ဆုံးတောင်းဆိုမှုများကို ခွဲခြမ်းစိတ်ဖြာပြီး multithreading ၏ ဆိုးကျိုးများကို ခွဲခြားသတ်မှတ်ပါ။ ဖြစ်ပါက Parallelism အတွက် ကုန်ကျစရိတ် ကန့်သတ်ချက်ကို တိုးမြှင့်ပါ။
1C၊ Microsoft CRM နှင့် Microsoft NAV ကဲ့သို့သော စနစ်များအတွက်၊ ကိစ္စအများစုတွင်၊ multithreading ကိုတားမြစ်ခြင်းသည် သင့်လျော်ပါသည်။
ထို့အပြင်၊ Standard ထုတ်ဝေမှုရှိပါက၊ ကိစ္စအများစုတွင် CPU cores အရေအတွက်ကန့်သတ်ထားသည့်အချက်ကြောင့် multithreading ကိုတားမြစ်ခြင်းသည် သင့်လျော်ပါသည်။
OLAP စနစ်များအတွက်၊ အထက်တွင်ဖော်ပြထားသော algorithm သည် မသင့်လျော်ပါ။
ကျွန်ုပ်၏ကိုယ်ပိုင်အတွေ့အကြုံအရ၊ parallelism ဂုဏ်သတ္တိများသတ်မှတ်ခြင်းအတွက် OLAP စနစ်များအတွက် အောက်ပါ algorithm လုပ်ဆောင်ချက်များကို အကြံပြုပါသည်။
- အလေးဆုံးတောင်းဆိုမှုများကို ခွဲခြမ်းစိတ်ဖြာပြီး ၎င်းတို့အတွက် အကောင်းဆုံး အရေအတွက်ကို ရွေးချယ်ပါ။
- အဆင့် 1 မှရရှိသော ရွေးချယ်ထားသော အကောင်းဆုံးသော အတွဲအရေအတွက်ကို မျဉ်းပြိုင်၏ Max Degree ကို သတ်မှတ်ပြီး ဒေတာဘေ့စ်တစ်ခုစီအတွက် အဆင့် 1 မှရရှိသော Max DOP တန်ဖိုးကို သတ်မှတ်ပါ။
- အပြင်းထန်ဆုံးမေးခွန်းများကို ခွဲခြမ်းစိတ်ဖြာပြီး တူညီသောငွေကြေးကို ကန့်သတ်ခြင်း၏ ဆိုးကျိုးများကို ခွဲခြားသတ်မှတ်ပါ။ အကယ်၍ ၎င်းသည် Parallelism တန်ဖိုးအတွက် Cost Threshold ကို လျှော့ချပြီး သို့မဟုတ် ဤ algorithm ၏ အဆင့် 1-2 ကို ထပ်လုပ်ပါ။
ဆိုလိုသည်မှာ၊ OLTP စနစ်များအတွက် ကျွန်ုပ်တို့သည် single-threading မှ multi-threading သို့သွားသည်၊ နှင့် OLAP-systems အတွက်၊ ဆန့်ကျင်ဘက်တွင်၊ multi-threading မှ single-threading သို့သွားပါသည်။ ထို့ကြောင့်၊ သင်သည် သီးခြားဒေတာဘေ့စ်တစ်ခုနှင့် MS SQL Server ၏ဥပမာတစ်ခုလုံးအတွက် အကောင်းဆုံးပြိုင်တူဆက်တင်များကို သင်ရွေးချယ်နိုင်သည်။
MS SQL Server ၏စွမ်းဆောင်ရည်ကိုစောင့်ကြည့်ခြင်း၏ရလဒ်များအပေါ်အခြေခံ၍ parallelism ဂုဏ်သတ္တိများ၏ဆက်တင်များကိုအချိန်နှင့်အမျှပြောင်းလဲရန်လိုအပ်ကြောင်းနားလည်ရန်လည်းအရေးကြီးပါသည်။
ခြေရာခံအလံများ သတ်မှတ်ခြင်းအတွက် လမ်းညွှန်ချက်များ
ကျွန်ုပ်၏ကိုယ်ပိုင်အတွေ့အကြုံနှင့် ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များ၏အတွေ့အကြုံအရ၊ အကောင်းဆုံးစွမ်းဆောင်ရည်အတွက်၊ ဗားရှင်း 2008-2016 အတွက် MS SQL Server ဝန်ဆောင်မှု၏ run အဆင့်တွင် အောက်ပါခြေရာခံအလံများကို သတ်မှတ်ရန် အကြံပြုပါသည်။
- 610 - အညွှန်းကိန်းဇယားများအတွင်း ထည့်သွင်းမှုများကို လျှော့ချခြင်း။ မှတ်တမ်းများစွာနှင့် ငွေပေးငွေယူများစွာရှိသော ဇယားများအတွင်းသို့ ထည့်သွင်းရာတွင် ကူညီပေးနိုင်ပြီး၊ မကြာခဏ ရေးမှတ်ထားသော အညွှန်းကိန်းများကို အပြောင်းအလဲများအတွက် မကြာခဏ ကြာမြင့်စွာ စောင့်ဆိုင်းခြင်းဖြင့်၊
- 1117 - filegroup ရှိ ဖိုင်တစ်ခုသည် autogrowth threshold လိုအပ်ချက်များနှင့် ကိုက်ညီပါက၊ filegroup ရှိ ဖိုင်များအားလုံးသည် ကြီးထွားလာသည်
- 1118 - အရာဝတ္တုအားလုံးကို မတူညီသော အတိုင်းအတာများအတွင်း ထားရှိရန် အတင်းအကျပ် (ရောစပ်ထားသော အတိုင်းအတာများကို တားမြစ်ထားသည်)၊ ရောစပ်ထားသော အတိုင်းအတာများကို ခြေရာခံရန် အသုံးပြုသည့် SGAM စာမျက်နှာကို စကင်န်ဖတ်ရန် လိုအပ်မှုကို လျော့နည်းစေသည်
- 1224 - သော့ခလောက်အရေအတွက်ပေါ်မူတည်၍ လော့ခ်တိုးခြင်းကို ပိတ်ပါ။ သို့သော်၊ အလွန်အကျွံ မမ်မိုရီအသုံးပြုခြင်းသည် လော့ခ်ကျခြင်းကို ဖြစ်ပေါ်စေနိုင်သည်။
- 2371 - ပုံသေ အလိုအလျောက် စာရင်းအင်းများ အပ်ဒိတ်အဆင့်ကို ပြောင်းလဲနေသော အလိုအလျောက် စာရင်းအင်းများ အပ်ဒိတ်အဆင့်သို့ ပြောင်းလဲပါ။ မှားယွင်းသော လုပ်ဆောင်ချက်အစီအစဉ်များကို မှားယွင်းစွာ ဖြစ်ပေါ်စေသည့် ဇယားကြီးများအတွက် မေးမြန်းမှုအစီအစဉ်များကို အပ်ဒိတ်လုပ်ခြင်းအတွက် အရေးကြီးပါသည်။
- 3226 - အမှားမှတ်တမ်းရှိ အရန်အောင်မြင်မှုစာတိုများကို ဖိနှိပ်သည်။
- 4199 - CUs နှင့် SQL Server Service Packs များတွင် ထုတ်ပြန်ထားသော query optimizer တွင် အပြောင်းအလဲများ ပါဝင်သည်
- 6532-6534 - spatial data အမျိုးအစားများတွင် query operations အတွက် စွမ်းဆောင်ရည်မြှင့်တင်မှုများ ပါဝင်သည်
- 8048 - NUMA ပိုင်းခြားထားသော မမ်မိုရီအရာဝတ္ထုများကို CPU ပိုင်းခြားထားသော အရာများအဖြစ်သို့ ပြောင်းသည်။
- 8780 - စုံစမ်းမေးမြန်းမှုအစီအစဉ်အတွက် ထပ်လောင်းအချိန်ခွဲဝေမှုကို ဖွင့်ပါ။ ဤအလံမပါဘဲ တောင်းဆိုချက်အချို့သည် ၎င်းတို့တွင် မေးမြန်းမှုအစီအစဉ်မရှိသောကြောင့် (အလွန်ရှားပါးသည့် ချွတ်ယွင်းချက်)၊
- 8780 - 9389 - batch မုဒ်ထုတ်ပြန်ချက်များအတွက် ထပ်လောင်း dynamic grant memory buffer ကိုဖွင့်ပေးသည်
2016 ခုနှစ်မတိုင်မီတွင်လည်း၊ ပိုမိုကောင်းမွန်သောဆုံးဖြတ်ချက်ပံ့ပိုးမှု ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်နိုင်စေသည့် trace flag 2301 ကိုဖွင့်ရန် အသုံးဝင်ပြီး ပိုမိုမှန်ကန်သောမေးမြန်းမှုအစီအစဉ်များကိုရွေးချယ်ရာတွင် အထောက်အကူဖြစ်စေပါသည်။ သို့သော်၊ ဗားရှင်း 2016 တွင်၊ ၎င်းသည် ရှည်လျားသော အလုံးစုံမေးမြန်းမှုလုပ်ဆောင်မှုအချိန်များအပေါ်တွင် အပျက်သဘောဆောင်သည့် သက်ရောက်မှုရှိသည်။
ထို့အပြင်၊ အညွှန်းကိန်းများစွာရှိသောစနစ်များ (ဥပမာ၊ 1C ဒေတာဘေ့စ်များအတွက်)၊ စနစ်အပေါ် ယေဘုယျအားဖြင့် အပြုသဘောဆောင်သောအကျိုးသက်ရောက်မှုရှိသည့် အညွှန်းအသုံးပြုမှုစုစည်းမှုကို ပိတ်ထားသည့် ခြေရာခံအလံ 2330 ကိုဖွင့်ရန် ကျွန်ုပ်အကြံပြုပါသည်။
ခြေရာခံအလံများအကြောင်း နောက်ထပ်အချက်အလက်များအတွက် ကြည့်ပါ။
အထက်ဖော်ပြပါ လင့်ခ်မှနေ၍ MS SQL Server ၏ ဗားရှင်းများနှင့် တည်ဆောက်မှုများကို ထည့်သွင်းစဉ်းစားရန် အရေးကြီးပြီး ဗားရှင်းအသစ်များအတွက်၊ အချို့သော ခြေရာခံအလံများကို ပုံသေဖြင့် ဖွင့်ထားသည် သို့မဟုတ် အကျိုးသက်ရောက်မှုမရှိပါ။
DBCC TRACEON နှင့် DBCC TRACEOFF ညွှန်ကြားချက်များဖြင့် သဲလွန်စအလံကို အဖွင့်အပိတ်လုပ်နိုင်ပါသည်။ အသေးစိတ်အချက်အလက်များကို ကြည့်ရှုပါ။
DBCC TRACESTATUS အမိန့်ကို အသုံးပြု၍ ခြေရာခံအလံများ၏ အခြေအနေကို သင်ရနိုင်သည်-
MS SQL Server ဝန်ဆောင်မှု၏ အလိုအလျောက်စတင်ခြင်းတွင် ခြေရာခံအလံများ ထည့်သွင်းရန်အတွက်၊ သင်သည် SQL Server Configuration Manager သို့သွား၍ ဝန်ဆောင်မှုဂုဏ်သတ္တိများတွင် -T မှတစ်ဆင့် ဤခြေရာခံအလံများကို ပေါင်းထည့်ရမည်-
ရလဒ်များကို
ဤဆောင်းပါးတွင်၊ MS SQL Server ကို စောင့်ကြည့်ခြင်း၏ အချို့သော ကဏ္ဍများကို ခွဲခြမ်းစိတ်ဖြာပြီး RAM ချို့တဲ့မှုနှင့် CPU အခမဲ့အချိန်တို့အပြင် အခြားသော လူမသိနိုင်သော ပြဿနာများစွာကို လျင်မြန်စွာ ဖော်ထုတ်နိုင်မည်ဖြစ်သည်။ အသုံးအများဆုံး ခြေရာခံအလံများကို သုံးသပ်ပြီးပါပြီ။
သတင်းရင်းမြစ်:
»
»
»
»
»
»
»
source: www.habr.com