Για να διατηρήσει τους χρήστες του, οποιαδήποτε εφαρμογή ή ιστότοπος πρέπει να λειτουργεί γρήγορα. Για κρίσιμα περιβάλλοντα αποστολής, μια καθυστέρηση δύο χιλιοστών του δευτερολέπτου στη λήψη πληροφοριών μπορεί να δημιουργήσει μεγάλα προβλήματα. Καθώς τα μεγέθη της βάσης δεδομένων αυξάνονται μέρα με τη μέρα, πρέπει να πάρουμε δεδομένα όσο το δυνατόν γρηγορότερα και να γράψουμε τα δεδομένα στη βάση δεδομένων όσο το δυνατόν γρηγορότερα. Για να βεβαιωθούμε ότι όλες οι λειτουργίες εκτελούνται ομαλά, πρέπει να συντονίσουμε τον διακομιστή βάσης δεδομένων για απόδοση.

Σε αυτό το άρθρο θα περιγράψω μια βήμα προς βήμα διαδικασία για βασικό συντονισμό απόδοσης σε έναν από τους κορυφαίους διακομιστές βάσεων δεδομένων στην αγορά: Microsoft Διακομιστής SQL (SQL Server, για συντομία).

# 1 Εύρεση των ενόχων

Όπως και με οποιοδήποτε άλλο λογισμικό, πρέπει να καταλάβουμε ότι ο SQL Server είναι ένα πολύπλοκο πρόγραμμα υπολογιστή. Εάν έχουμε πρόβλημα με αυτό, πρέπει να ανακαλύψουμε γιατί δεν λειτουργεί όπως περιμένουμε.

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

• Οι ρυθμίσεις υλικού και εγκατάστασης, οι οποίες ενδέχεται να χρειαστούν διόρθωση, καθώς οι ανάγκες του SQL Server είναι συγκεκριμένες
• Εάν έχουμε παράσχει τον σωστό κώδικα T-SQL για τον SQL Server για εφαρμογή

Παρόλο που ο SQL Server είναι ιδιόκτητο λογισμικό, η Microsoft έχει προσφέρει πολλούς τρόπους για να το κατανοήσει και να το χρησιμοποιήσει αποτελεσματικά.

Εάν το υλικό είναι ΟΚ και η εγκατάσταση έχει γίνει σωστά, αλλά ο SQL Server εξακολουθεί να λειτουργεί αργά, τότε πρώτα πρέπει να μάθουμε αν υπάρχουν σφάλματα που σχετίζονται με το λογισμικό. Για να ελέγξουμε τι συμβαίνει, πρέπει να παρατηρήσουμε την απόδοση διαφορετικών νημάτων. Αυτό επιτυγχάνεται με τον υπολογισμό των στατιστικών αναμονής διαφορετικών νημάτων. Ο διακομιστής SQL χρησιμοποιεί νήματα για κάθε αίτημα χρήστη και το νήμα δεν είναι τίποτα άλλο από ένα άλλο πρόγραμμα μέσα στο σύνθετο πρόγραμμα που ονομάζεται SQL Server. Είναι σημαντικό να σημειωθεί ότι αυτό το νήμα δεν είναι ένα νήμα λειτουργικού συστήματος στο οποίο είναι εγκατεστημένος ο διακομιστής SQL. σχετίζεται με το νήμα SQLOS, το οποίο είναι ένα ψευδο λειτουργικό σύστημα για τον SQL Server.

Τα μέσα css ερωτά τυπικά σημεία διακοπής

Τα στατιστικά στοιχεία αναμονής μπορούν να υπολογιστούν χρησιμοποιώντας sys.dm_os_wait_stats Dynamic Management View (DMV), η οποία παρέχει πρόσθετες πληροφορίες σχετικά με την τρέχουσα κατάστασή της. Υπάρχουν πολλά σενάρια στο διαδίκτυο για να ρωτήσω αυτήν την προβολή, αλλά το αγαπημένο μου είναι Το σενάριο του Paul Randal επειδή είναι εύκολο να κατανοηθεί και έχει όλες τις σημαντικές παραμέτρους για να παρατηρήσει τα στατιστικά στοιχεία αναμονής:

WITH [Waits] AS (SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [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 [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') AND [waiting_tasks_count] > 0 ) SELECT MAX ([W1].[wait_type]) AS [WaitType], CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S], CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S], CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S], MAX ([W1].[WaitCount]) AS [WaitCount], CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage], CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S], CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S], CAST ((MAX ([W1].[SignalS]) / MAX ([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] HAVING SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 95; -- percentage threshold GO

Όταν εκτελούμε αυτό το σενάριο, πρέπει να επικεντρωθούμε στις κορυφαίες σειρές του αποτελέσματος, επειδή έχουν οριστεί πρώτα και αντιπροσωπεύουν τον μέγιστο τύπο αναμονής.

Πρέπει να κατανοήσουμε τους τύπους αναμονής για να πάρουμε τις σωστές αποφάσεις. Για να μάθουμε για διαφορετικούς τύπους αναμονής, μπορούμε να πάμε στο εξαιρετικό Τεκμηρίωση της Microsoft .

Ας πάρουμε ένα παράδειγμα όπου έχουμε πάρα πολλά PAGEIOLATCH_XX. Αυτό σημαίνει ότι ένα νήμα περιμένει την ανάγνωση της σελίδας δεδομένων από το δίσκο στο buffer, το οποίο δεν είναι παρά ένα μπλοκ μνήμης. Πρέπει να είμαστε σίγουροι ότι καταλαβαίνουμε τι συμβαίνει. Αυτό δεν σημαίνει απαραίτητα ένα φτωχό υποσύστημα I / O ή όχι αρκετή μνήμη, και η αύξηση του υποσυστήματος I / O και της μνήμης θα λύσει το πρόβλημα, αλλά μόνο προσωρινά. Για να βρούμε μια μόνιμη λύση πρέπει να δούμε γιατί διαβάζονται τόσα δεδομένα από το δίσκο: Τι τύποι εντολών SQL προκαλούν αυτό; Διαβάζουμε πάρα πολλά δεδομένα αντί να διαβάζουμε λιγότερα δεδομένα χρησιμοποιώντας φίλτρα, όπως where ρήτρες; Πραγματοποιούνται πάρα πολλές αναγνώσεις δεδομένων λόγω σάρωσης πίνακα ή σάρωσης ευρετηρίου; Μπορούμε να τα μετατρέψουμε σε ευρετήρια αναζητώντας εφαρμόζοντας ή τροποποιώντας υπάρχοντα ευρετήρια; Γράφουμε ερωτήματα SQL που παρανοούνται από το SQL Optimizer (άλλο πρόγραμμα στο πρόγραμμα διακομιστή SQL);

Πρέπει να σκεφτούμε από διαφορετικές οπτικές γωνίες και να χρησιμοποιήσουμε διαφορετικές δοκιμαστικές περιπτώσεις για να βρούμε λύσεις. Κάθε ένας από τους παραπάνω τύπους αναμονής χρειάζεται μια διαφορετική λύση. Ένας διαχειριστής βάσης δεδομένων πρέπει να τους ερευνήσει διεξοδικά προτού προβεί σε οποιαδήποτε ενέργεια. Αλλά τις περισσότερες φορές, η εύρεση προβληματικών ερωτημάτων T-SQL και η ρύθμισή τους θα λύσει το 60 έως 70 τοις εκατό των προβλημάτων.

# 2 Εύρεση προβληματικών ερωτημάτων

Όπως αναφέρθηκε παραπάνω, το πρώτο πράγμα που μπορούμε να κάνουμε είναι να αναζητήσουμε προβληματικά ερωτήματα. Ο ακόλουθος κωδικός T-SQL θα βρει τα 20 ερωτήματα με τη χειρότερη απόδοση:

SELECT TOP 20 total_worker_time/execution_count AS Avg_CPU_Time ,Execution_count ,total_elapsed_time/execution_count as AVG_Run_Time ,total_elapsed_time ,(SELECT SUBSTRING(text,statement_start_offset/2+1,statement_end_offset ) FROM sys.dm_exec_sql_text(sql_handle) ) AS Query_Text FROM sys.dm_exec_query_stats ORDER BY Avg_CPU_Time DESC

Πρέπει να είμαστε προσεκτικοί με τα αποτελέσματα. παρόλο που ένα ερώτημα μπορεί να έχει μέγιστο μέσο χρόνο εκτέλεσης, εάν εκτελείται μόνο μία φορά, το συνολικό αποτέλεσμα στον διακομιστή είναι χαμηλό σε σύγκριση με ένα ερώτημα που έχει μέσο μέσο χρόνο εκτέλεσης και εκτελείται πολλές φορές σε μια μέρα.

διαφορά μεταξύ s corp c corp και llc

# 3 ερωτήματα συντονισμού

Η τελειοποίηση ενός ερωτήματος T-SQL είναι μια σημαντική ιδέα. Το θεμελιώδες πράγμα που πρέπει να καταλάβουμε είναι πόσο καλά μπορούμε να γράψουμε ερωτήματα T-SQL και να εφαρμόσουμε ευρετήρια, έτσι ώστε το SQL optimizer να βρει ένα βελτιστοποιημένο σχέδιο για να κάνει αυτό που θέλαμε να κάνει. Με κάθε νέα έκδοση του SQL Server, έχουμε ένα πιο εξελιγμένο εργαλείο βελτιστοποίησης που θα καλύψει τα λάθη μας κατά τη σύνταξη μη βελτιστοποιημένων ερωτημάτων SQL και θα διορθώσει επίσης τυχόν σφάλματα που σχετίζονται με την προηγούμενη βελτιστοποίηση. Όμως, ανεξάρτητα από το πόσο έξυπνο μπορεί να είναι το εργαλείο βελτιστοποίησης, εάν δεν μπορούμε να το πούμε αυτό που θέλουμε (γράφοντας κατάλληλα ερωτήματα T-SQL), το εργαλείο βελτιστοποίησης SQL δεν θα είναι σε θέση να κάνει τη δουλειά του.

Ο SQL Server χρησιμοποιεί προηγμένη αναζήτηση και αλγόριθμοι ταξινόμησης . Αν είμαστε καλοί στην αναζήτηση και ταξινόμηση αλγορίθμων, τότε τις περισσότερες φορές μπορούμε να μαντέψουμε γιατί ο SQL Server κάνει συγκεκριμένη ενέργεια. Το καλύτερο βιβλίο για την εκμάθηση περισσότερων και την κατανόηση τέτοιων αλγορίθμων είναι Η τέχνη του προγραμματισμού υπολογιστών από τον Donald Knuth .

Όταν εξετάζουμε ερωτήματα που πρέπει να ρυθμιστούν καλύτερα, πρέπει να χρησιμοποιήσουμε το σχέδιο εκτέλεσης αυτών των ερωτημάτων, ώστε να μπορέσουμε να μάθουμε πώς τα ερμηνεύει ο διακομιστής SQL.

Δεν μπορώ να καλύψω όλες τις πτυχές του σχεδίου εκτέλεσης εδώ, αλλά σε βασικό επίπεδο μπορώ να εξηγήσω τα πράγματα που πρέπει να λάβουμε υπόψη.

• Πρώτα πρέπει να μάθουμε ποιοι χειριστές αναλαμβάνουν το μεγαλύτερο μέρος του κόστους του ερωτήματος.
• Εάν ο χειριστής παίρνει πολύ κόστος, πρέπει να μάθουμε τον λόγο. Τις περισσότερες φορές, οι σαρώσεις θα καταλαμβάνουν περισσότερο κόστος από ό, τι οι αναζητήσεις. Πρέπει να εξετάσουμε γιατί συμβαίνει μια συγκεκριμένη σάρωση (σάρωση πίνακα ή σάρωση ευρετηρίου) αντί για αναζήτηση ευρετηρίου. Μπορούμε να λύσουμε αυτό το πρόβλημα εφαρμόζοντας κατάλληλα ευρετήρια σε στήλες πίνακα, αλλά όπως και με οποιοδήποτε περίπλοκο πρόγραμμα, δεν υπάρχει σταθερή λύση. Για παράδειγμα, εάν ο πίνακας είναι μικρός, τότε οι σαρώσεις είναι πιο γρήγορες από τις αναζητήσεις.
• Υπάρχουν περίπου 78 χειριστές, οι οποίοι αντιπροσωπεύουν τις διάφορες ενέργειες και αποφάσεις του προγράμματος εκτέλεσης του SQL Server. Πρέπει να τα μελετήσουμε σε βάθος, συμβουλευόμενοι το Τεκμηρίωση της Microsoft , ώστε να μπορούμε να τους κατανοήσουμε καλύτερα και να αναλάβουμε τη σωστή δράση.

Σχετίζεται με: Εξηγούμενα ευρετήρια SQL, Pt. 1

# 4 Επαναχρησιμοποίηση του σχεδίου εκτέλεσης

Ακόμα κι αν εφαρμόσουμε σωστά ευρετήρια σε πίνακες και γράφουμε καλό κώδικα T-SQL, εάν το σχέδιο εκτέλεσης δεν επαναχρησιμοποιηθεί, θα έχουμε προβλήματα απόδοσης. Αφού τελειοποιήσουμε τα ερωτήματα, πρέπει να διασφαλίσουμε ότι το σχέδιο εκτέλεσης μπορεί να επαναχρησιμοποιηθεί όταν είναι απαραίτητο. Το μεγαλύτερο μέρος του χρόνου της CPU θα δαπανηθεί για τον υπολογισμό του προγράμματος εκτέλεσης που μπορεί να εξαλειφθεί, εάν ξαναχρησιμοποιήσουμε το πρόγραμμα.

Μπορούμε να χρησιμοποιήσουμε το παρακάτω ερώτημα για να μάθουμε πόσες φορές επαναχρησιμοποιείται το σχέδιο εκτέλεσης, όπου usecounts αντιπροσωπεύει πόσες φορές το πρόγραμμα επαναχρησιμοποιείται:

σε τι χρησιμοποιείται το adobe xd

SELECT [ecp].[refcounts] , [ecp].[usecounts] , [ecp].[objtype] , DB_NAME([est].[dbid]) AS [db_name] , [est].[objectid] , [est].[text] as [query_ext] , [eqp].[query_plan] FROM sys.dm_exec_cached_plans ecp CROSS APPLY sys.dm_exec_sql_text ( ecp.plan_handle ) est CROSS APPLY sys.dm_exec_query_plan ( ecp.plan_handle ) eqp

Ο καλύτερος τρόπος για να επαναχρησιμοποιήσετε το σχέδιο εκτέλεσης είναι με την εφαρμογή παραμετροποιημένων αποθηκευμένων διαδικασιών. Όταν δεν είμαστε σε θέση να εφαρμόσουμε αποθηκευμένες διαδικασίες, μπορούμε να χρησιμοποιήσουμε το sp_executesql, το οποίο μπορεί να χρησιμοποιηθεί αντ 'αυτού για την εκτέλεση δηλώσεων T-SQL όταν η μόνη αλλαγή στις δηλώσεις SQL είναι οι τιμές των παραμέτρων. Ο SQL Server πιθανότατα θα επαναχρησιμοποιήσει το σχέδιο εκτέλεσης που δημιούργησε κατά την πρώτη εκτέλεση.

Και πάλι, όπως με οποιοδήποτε περίπλοκο πρόγραμμα υπολογιστή, δεν υπάρχει σταθερή λύση. Μερικές φορές είναι καλύτερο να συντάξετε ξανά το σχέδιο.

Ας εξετάσουμε τα ακόλουθα δύο παραδείγματα ερωτημάτων:

• select name from table where name = 'sri';
• select name from table where name = 'pal';

Ας υποθέσουμε ότι έχουμε ένα δείκτη χωρίς συμπλέγματα στο name Η στήλη και το μισό του πίνακα έχει τιμή sri και λίγες σειρές έχουν pal στο name στήλη. Για το πρώτο ερώτημα, ο SQL Server θα χρησιμοποιήσει τη σάρωση πίνακα, επειδή το ήμισυ του πίνακα έχει τις ίδιες τιμές. Αλλά για το δεύτερο ερώτημα, είναι καλύτερο να χρησιμοποιήσετε τη σάρωση ευρετηρίου επειδή μόνο λίγες σειρές έχουν pal αξία.

Παρόλο που τα ερωτήματα είναι παρόμοια, το ίδιο σχέδιο εκτέλεσης μπορεί να μην είναι καλή λύση. Τις περισσότερες φορές θα είναι μια διαφορετική περίπτωση, οπότε πρέπει να αναλύσουμε προσεκτικά τα πάντα πριν αποφασίσουμε. Εάν δεν θέλουμε να ξαναχρησιμοποιήσουμε το σχέδιο εκτέλεσης, μπορούμε πάντα να χρησιμοποιήσουμε την επιλογή 'recompile' σε αποθηκευμένες διαδικασίες.

Λάβετε υπόψη ότι ακόμα και μετά τη χρήση αποθηκευμένων διαδικασιών ή sp_executesql, υπάρχουν στιγμές που το σχέδιο εκτέλεσης δεν θα επαναχρησιμοποιηθεί. Αυτοί είναι:

• Όταν τα ευρετήρια που χρησιμοποιούνται από το ερώτημα αλλάζουν ή απορρίπτονται
• Όταν αλλάζουν τα στατιστικά στοιχεία, η δομή ή το σχήμα ενός πίνακα που χρησιμοποιείται από το ερώτημα
• Όταν χρησιμοποιούμε την επιλογή 'recompile'
• Όταν υπάρχει μεγάλος αριθμός εισαγωγών, ενημερώσεων ή διαγραφών
• Όταν συνδυάζουμε DDL και DML σε ένα μόνο ερώτημα

# 5 Αφαίρεση περιττών ευρετηρίων

Αφού τελειοποιήσουμε τα ερωτήματα, πρέπει να ελέγξουμε πώς χρησιμοποιούνται τα ευρετήρια. Η συντήρηση ευρετηρίου απαιτεί πολλή CPU και I / O. Κάθε φορά που εισάγουμε δεδομένα σε μια βάση δεδομένων, ο SQL Server πρέπει επίσης να ενημερώνει τα ευρετήρια, επομένως είναι καλύτερα να τα καταργήσετε εάν δεν χρησιμοποιούνται.

κόμβος js express ξεκούραστο api

Ο διακομιστής SQL μας παρέχει dm_db_index_usage_stats DMV για να βρείτε στατιστικά στοιχεία ευρετηρίου. Όταν εκτελούμε τον κώδικα T-SQL παρακάτω, λαμβάνουμε στατιστικά στοιχεία χρήσης για διαφορετικά ευρετήρια. Εάν εντοπίσουμε ευρετήρια που δεν χρησιμοποιούνται καθόλου, ή σπάνια χρησιμοποιούνται, μπορούμε να τα ρίξουμε για να κερδίσουμε απόδοση.

SELECT OBJECT_NAME(IUS.[OBJECT_ID]) AS [OBJECT NAME], DB_NAME(IUS.database_id) AS [DATABASE NAME], I.[NAME] AS [INDEX NAME], USER_SEEKS, USER_SCANS, USER_LOOKUPS, USER_UPDATES FROM SYS.DM_DB_INDEX_USAGE_STATS AS IUS INNER JOIN SYS.INDEXES AS I ON I.[OBJECT_ID] = IUS.[OBJECT_ID] AND I.INDEX_ID = IUS.INDEX_ID

# 6 Εγκατάσταση διακομιστή SQL και ρύθμιση βάσης δεδομένων

Κατά τη δημιουργία μιας βάσης δεδομένων, πρέπει να διατηρούμε ξεχωριστά δεδομένα και αρχεία καταγραφής. Ο κύριος λόγος για αυτό είναι ότι η σύνταξη και η πρόσβαση σε αρχεία δεδομένων δεν είναι διαδοχική, ενώ η σύνταξη και η πρόσβαση σε αρχεία καταγραφής είναι διαδοχική. Αν τα βάλουμε στον ίδιο δίσκο δεν μπορούμε να τα χρησιμοποιήσουμε με βελτιστοποιημένο τρόπο.

Όταν αγοράζουμε το Storage Area Network (SAN), ένας προμηθευτής μπορεί να μας δώσει μερικές προτάσεις σχετικά με τον τρόπο εγκατάστασής του, αλλά αυτές οι πληροφορίες δεν είναι πάντα χρήσιμες. Πρέπει να έχουμε μια λεπτομερή συζήτηση με τους τύπους υλικού και δικτύων για το πώς να διατηρήσουμε τα δεδομένα και τα αρχεία καταγραφής ξεχωριστά και με βελτιστοποιημένο τρόπο.

# 7 Μην υπερφορτώνετε τον SQL Server

Το πρωταρχικό καθήκον κάθε διαχειριστή βάσης δεδομένων είναι να διασφαλίζει ότι ο διακομιστής παραγωγής λειτουργεί ομαλά και εξυπηρετεί όσο το δυνατόν καλύτερα τους πελάτες. Για να συμβεί αυτό πρέπει να διατηρήσουμε ξεχωριστές βάσεις δεδομένων (αν είναι δυνατόν, σε ξεχωριστά μηχανήματα) για τα ακόλουθα περιβάλλοντα:

δείγμα λογιστικού σχεδίου για προσωπικά οικονομικά

• Παραγωγή
• Ανάπτυξη
• Δοκιμές
• Αναλυτικός

Για μια βάση δεδομένων παραγωγής χρειαζόμαστε μια βάση δεδομένων με πλήρη λειτουργία ανάκτησης , και για άλλες βάσεις δεδομένων, αρκεί μια απλή λειτουργία ανάκτησης.

Δοκιμή σε α βάση δεδομένων παραγωγής θα βάλει πολύ φορτίο στο αρχείο καταγραφής συναλλαγών, στα ευρετήρια, στην CPU και στο I / O. Γι 'αυτό πρέπει να χρησιμοποιήσουμε ξεχωριστές βάσεις δεδομένων για παραγωγή, ανάπτυξη, δοκιμή και ανάλυση. Εάν είναι δυνατόν, χρησιμοποιήστε ξεχωριστά μηχανήματα για κάθε βάση δεδομένων, επειδή θα μειώσει το φορτίο της CPU και του I / O.

# 8 Καταγραφή συναλλαγών, tempdb και μνήμη

Το αρχείο καταγραφής πρέπει να έχει αρκετό ελεύθερο χώρο για κανονικές λειτουργίες, επειδή μια λειτουργία αυτόματης ανάπτυξης σε ένα αρχείο καταγραφής είναι χρονοβόρα και θα μπορούσε να αναγκάσει άλλες λειτουργίες να περιμένουν μέχρι να ολοκληρωθεί. Για να μάθετε το μέγεθος του αρχείου καταγραφής για κάθε βάση δεδομένων και πόσο χρησιμοποιείται, μπορούμε να χρησιμοποιήσουμε DBCC SQLPERF(logspace).

Ο καλύτερος τρόπος για να ρυθμίσετε το tempdb είναι να το τοποθετήσετε σε ξεχωριστό δίσκο. Πρέπει να διατηρήσουμε το αρχικό μέγεθος τόσο μεγάλο όσο μπορούμε, γιατί όταν φτάσει σε κατάσταση autogrow, η απόδοση θα μειωθεί.

Όπως αναφέρθηκε προηγουμένως, πρέπει να διασφαλίσουμε ότι ο διακομιστής SQL λειτουργεί σε ξεχωριστό μηχάνημα, κατά προτίμηση σε έναν χωρίς άλλη εφαρμογή σε αυτόν. Πρέπει να διατηρήσουμε κάποια μνήμη για το λειτουργικό σύστημα, καθώς και περισσότερο εάν είναι μέρος ενός συμπλέγματος, οπότε στις περισσότερες περιπτώσεις περίπου 2 GB πρέπει να το κάνουν.

Για κρίσιμα περιβάλλοντα αποστολής, μια καθυστέρηση χιλιοστών του δευτερολέπτου στη λήψη πληροφοριών μπορεί να είναι μια λύση. Τιτίβισμα

Συμπέρασμα:

Οι διαδικασίες και οι προτάσεις που συζητούνται εδώ είναι μόνο για βασικό συντονισμό απόδοσης. Εάν ακολουθήσουμε αυτά τα βήματα, μπορούμε, κατά μέσο όρο, να έχουμε περίπου 40 έως 50 τοις εκατό βελτίωση στην απόδοση. Για να κάνουμε προηγμένο συντονισμό απόδοσης διακομιστή SQL, θα πρέπει να σκάψουμε πολύ βαθύτερα σε κάθε ένα από τα βήματα που καλύπτονται εδώ.

Σχετίζεται με: Oracle to SQL Server και SQL Server to Oracle Migration Guide