ProHoster > Blog > διαχείριση > Ορισμένες πτυχές της παρακολούθησης του MS SQL Server. Οδηγίες για τη ρύθμιση των σημαιών ίχνους

Ορισμένες πτυχές της παρακολούθησης του MS SQL Server. Οδηγίες για τη ρύθμιση των σημαιών ίχνους

πρόλογος

Αρκετά συχνά, οι χρήστες, οι προγραμματιστές και οι διαχειριστές του MS SQL Server DBMS αντιμετωπίζουν προβλήματα απόδοσης της βάσης δεδομένων ή του DBMS συνολικά, επομένως η παρακολούθηση του MS SQL Server είναι πολύ σχετική.
Αυτό το άρθρο είναι μια προσθήκη στο άρθρο Χρήση του Zabbix για την παρακολούθηση της βάσης δεδομένων του MS SQL Server και θα καλύψει ορισμένες πτυχές της παρακολούθησης του 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'
  );

Εδώ πρέπει να δώσετε προσοχή στους δείκτες Percentage και AvgWait_S. Εάν είναι σημαντικά στο σύνολό τους, τότε υπάρχει πολύ μεγάλη πιθανότητα να μην υπάρχει αρκετή μνήμη RAM για την παρουσία του MS SQL Server. Οι σημαντικές τιμές καθορίζονται ξεχωριστά για κάθε σύστημα. Ωστόσο, μπορείτε να ξεκινήσετε με τα εξής: Ποσοστό>=1 και Μέσος αναμονής_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.

Μέθοδος ανίχνευσης υπερφόρτωσης 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, να διαμορφωθούν σωστά οι ιδιότητες παραλληλισμού των απαιτούμενων βάσεων δεδομένων:
Ορισμένες πτυχές της παρακολούθησης του MS SQL Server. Οδηγίες για τη ρύθμιση των σημαιών ίχνους

Ορισμένες πτυχές της παρακολούθησης του MS SQL Server. Οδηγίες για τη ρύθμιση των σημαιών ίχνους
Εδώ πρέπει να δώσετε προσοχή στις ακόλουθες παραμέτρους:

  1. Μέγιστος βαθμός παραλληλισμού - ορίζει τον μέγιστο αριθμό νημάτων που μπορούν να εκχωρηθούν σε κάθε αίτημα (η προεπιλογή είναι 0 - περιορίζεται μόνο από το ίδιο το λειτουργικό σύστημα και την έκδοση του MS SQL Server)
  2. Όριο κόστους για παραλληλισμό - εκτιμώμενο κόστος παραλληλισμού (η προεπιλογή είναι 5)
  3. Max DOP - ορίζει τον μέγιστο αριθμό νημάτων που μπορούν να εκχωρηθούν σε κάθε ερώτημα σε επίπεδο βάσης δεδομένων (αλλά όχι μεγαλύτερη από την τιμή της ιδιότητας "Max Degree of Parallelism") (η προεπιλογή είναι 0 - περιορίζεται μόνο από το ίδιο το λειτουργικό σύστημα και η έκδοση του MS SQL Server, καθώς και ο περιορισμός στην ιδιότητα "Max Degree of Parallelism" ολόκληρης της παρουσίας του MS SQL Server)

Εδώ είναι αδύνατο να δώσεις μια εξίσου καλή συνταγή για όλες τις περιπτώσεις, δηλαδή πρέπει να αναλύσεις βαριές ερωτήσεις.
Από τη δική μου εμπειρία, προτείνω τον ακόλουθο αλγόριθμο ενεργειών για συστήματα OLTP για τη ρύθμιση ιδιοτήτων παραλληλισμού:

  1. πρώτα απενεργοποιήστε τον παραλληλισμό θέτοντας τον μέγιστο βαθμό παραλληλισμού σε όλη την περίπτωση σε 1
  2. αναλύστε τα πιο βαριά αιτήματα και επιλέξτε τον βέλτιστο αριθμό νημάτων για αυτά
  3. ορίστε τον μέγιστο βαθμό παραλληλισμού στον επιλεγμένο βέλτιστο αριθμό νημάτων που λήφθηκαν από το βήμα 2 και για συγκεκριμένες βάσεις δεδομένων ορίστε την τιμή Max DOP που λαμβάνεται από το βήμα 2 για κάθε βάση δεδομένων
  4. να αναλύσει τα πιο βαριά αιτήματα και να εντοπίσει την αρνητική επίδραση του multithreading. Εάν είναι, τότε αυξήστε το όριο κόστους για τον παραλληλισμό.
    Για συστήματα όπως το 1C, το Microsoft CRM και το Microsoft NAV, στις περισσότερες περιπτώσεις, η απαγόρευση πολλαπλών νημάτων είναι κατάλληλη

Επίσης, εάν υπάρχει Standard edition, τότε στις περισσότερες περιπτώσεις ενδείκνυται η απαγόρευση του multithreading λόγω του γεγονότος ότι αυτή η έκδοση είναι περιορισμένη στον αριθμό των πυρήνων της CPU.
Για συστήματα OLAP, ο αλγόριθμος που περιγράφεται παραπάνω δεν είναι κατάλληλος.
Από τη δική μου εμπειρία, προτείνω τον ακόλουθο αλγόριθμο ενεργειών για συστήματα OLAP για τη ρύθμιση ιδιοτήτων παραλληλισμού:

  1. αναλύστε τα πιο βαριά αιτήματα και επιλέξτε τον βέλτιστο αριθμό νημάτων για αυτά
  2. ορίστε τον μέγιστο βαθμό παραλληλισμού στον επιλεγμένο βέλτιστο αριθμό νημάτων που λήφθηκαν από το βήμα 1 και για συγκεκριμένες βάσεις δεδομένων ορίστε την τιμή Max DOP που λαμβάνεται από το βήμα 1 για κάθε βάση δεδομένων
  3. να αναλύσει τα πιο βαριά ερωτήματα και να εντοπίσει την αρνητική επίδραση του περιορισμού της συγχρονικότητας. Εάν είναι, τότε είτε χαμηλώστε την τιμή ουδού κόστους για παραλληλισμό είτε επαναλάβετε τα βήματα 1-2 αυτού του αλγορίθμου

Δηλαδή, για τα συστήματα OLTP περνάμε από το single-threading στο multi-threading και για τα OLAP-systems, αντίθετα, από το multi-threading στο single-threading. Έτσι, μπορείτε να επιλέξετε τις βέλτιστες ρυθμίσεις παραλληλισμού τόσο για μια συγκεκριμένη βάση δεδομένων όσο και για ολόκληρη την παρουσία του 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 - Περιλαμβάνει αλλαγές στο πρόγραμμα βελτιστοποίησης ερωτημάτων που κυκλοφόρησε σε CU και SQL Server Service Pack
  8. 6532-6534 - Περιλαμβάνει βελτιώσεις απόδοσης για λειτουργίες ερωτήματος σε τύπους χωρικών δεδομένων
  9. 8048 - Μετατρέπει αντικείμενα μνήμης με διαμερίσματα NUMA σε διαμερισμένα με CPU
  10. 8780 - Επιτρέπει την κατανομή επιπλέον χρόνου για τον προγραμματισμό ερωτημάτων. Ορισμένα αιτήματα χωρίς αυτήν τη σημαία ενδέχεται να απορριφθούν επειδή δεν έχουν σχέδιο ερωτημάτων (πολύ σπάνιο σφάλμα)
  11. 8780 - 9389 - Ενεργοποιεί πρόσθετη προσωρινή μνήμη δυναμικής παραχώρησης για δηλώσεις λειτουργίας δέσμης, η οποία επιτρέπει στον χειριστή της λειτουργίας δέσμης να ζητά περισσότερη μνήμη και να αποφεύγει τη μετακίνηση δεδομένων στο tempdb εάν υπάρχει περισσότερη μνήμη

Επίσης, πριν από το 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. Οδηγίες για τη ρύθμιση των σημαιών ίχνους

Αποτελέσματα της

Σε αυτό το άρθρο, αναλύθηκαν ορισμένες πτυχές της παρακολούθησης του MS SQL Server, με τη βοήθεια των οποίων μπορείτε να εντοπίσετε γρήγορα την έλλειψη μνήμης RAM και ελεύθερου χρόνου CPU, καθώς και μια σειρά από άλλα λιγότερο προφανή προβλήματα. Οι πιο συχνά χρησιμοποιούμενες σημαίες ίχνους έχουν αναθεωρηθεί.

Πηγές:

» Στατιστικά αναμονής του SQL Server
» Στατιστικά αναμονής του SQL Server ή πείτε μου πού πονάει
» Προβολή συστήματος sys.dm_os_schedulers
» Χρήση του Zabbix για την παρακολούθηση της βάσης δεδομένων του MS SQL Server
» SQL Lifestyle
» Σημαίες ιχνών
» sql.ru

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο