Περίμενε! Περίμενε! Είναι αλήθεια ότι αυτό δεν είναι άλλο ένα άρθρο σχετικά με τους τύπους αντιγράφων ασφαλείας του SQL Server. Δεν θα μιλήσω καν για τις διαφορές μεταξύ των μοντέλων ανάκτησης και τον τρόπο αντιμετώπισης ενός κατάφυτου "κούτσουρου".
Ίσως (μόνο δυνατό), αφού διαβάσετε αυτήν την ανάρτηση, θα μπορείτε να δημιουργήσετε το αντίγραφο ασφαλείας, το οποίο αφαιρέθηκε από εσάς με τυπικά μέσα, αφαιρεθεί αύριο το βράδυ, 1.5 φορές πιο γρήγορα. Και μόνο λόγω του γεγονότος ότι χρησιμοποιείτε λίγο περισσότερες παραμέτρους BACKUP DATABASE.
Εάν το περιεχόμενο της ανάρτησης ήταν προφανές για εσάς, λυπάμαι. Έχω διαβάσει όλα όσα έχει φτάσει η Google για τη φράση "habr sql server backup" και δεν έχω βρει καμία αναφορά σε κανένα άρθρο ότι ο χρόνος δημιουργίας αντιγράφων ασφαλείας μπορεί να επηρεαστεί με κάποιο τρόπο χρησιμοποιώντας παραμέτρους.
Θα επιστήσω αμέσως την προσοχή σας στο σχόλιο του Alexander Gladchenko ():
Μην αλλάζετε ποτέ τις παραμέτρους BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE στο προϊόν. Είναι φτιαγμένα μόνο για τη συγγραφή τέτοιων άρθρων. Στην πράξη, θα έχετε προβλήματα μνήμης για τα καλά.
Φυσικά, θα ήταν ωραίο να είσαι ο πιο έξυπνος και να δημοσιεύεις αποκλειστικό περιεχόμενο, αλλά αυτό, δυστυχώς, δεν συμβαίνει. Υπάρχουν άρθρα/αναρτήσεις τόσο στα αγγλικά όσο και στα ρωσικά (πάντα μπερδεύομαι για το πώς να τα αποκαλώ σωστά) αφιερωμένα σε αυτό το θέμα. Εδώ είναι μερικά από αυτά που πήρα: , , .
Έτσι, για να ξεκινήσω, θα επισυνάψω μια ελαφρώς περικομμένη σύνταξη BACKUP από (παρεμπιπτόντως, έγραψα για το BACKUP DATABASE παραπάνω, αλλά όλα αυτά ισχύουν τόσο για τη δημιουργία αντιγράφων ασφαλείας αρχείου καταγραφής συναλλαγών όσο και για τη διαφορική δημιουργία αντιγράφων ασφαλείας, αλλά ίσως με λιγότερο προφανές αποτέλεσμα):
BACKUP DATABASE { database_name | @database_name_var }
TO <backup_device> [ ,...n ]
<...>
[ WITH { <...>
| <general_WITH_options> [ ,...n ] } ]
[;]
<general_WITH_options> [ ,...n ]::=
<...>
--Media Set Options
<...>
| BLOCKSIZE = { blocksize | @blocksize_variable }
--Data Transfer Options
BUFFERCOUNT = { buffercount | @buffercount_variable }
| MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }
<...><...> - σημαίνει ότι υπήρχε κάτι εκεί, αλλά το αφαίρεσα, γιατί τώρα δεν ισχύει για το θέμα.
Πώς λαμβάνετε συνήθως ένα αντίγραφο ασφαλείας; Πώς «διδάσκουν» να παίρνουν αντίγραφο ασφαλείας σε δισεκατομμύρια άρθρα; Γενικά, αν χρειαστεί να δημιουργήσω εφάπαξ αντίγραφο ασφαλείας κάποιας όχι πολύ μεγάλης βάσης δεδομένων, θα γράψω αυτόματα κάτι σαν αυτό:
BACKUP DATABASE smth
TO DISK = 'D:Backupsmth.bak'
WITH STATS = 10, CHECKSUM, COMPRESSION, COPY_ONLY;
--ладно, CHECKSUM я написал только чтобы казаться умнееΚαι, γενικά, πιθανώς το 75-90% όλων των παραμέτρων που αναφέρονται συνήθως σε άρθρα σχετικά με τα αντίγραφα ασφαλείας παρατίθενται εδώ. Λοιπόν, υπάρχει INIT, SKIP περισσότερα. Έχετε πάει στο MSDN; Έχετε δει ότι υπάρχουν επιλογές για μιάμιση οθόνη; Είδα και εγώ...
Πιθανότατα έχετε ήδη καταλάβει ότι περαιτέρω θα μιλήσουμε για τις τρεις παραμέτρους που παρέμειναν στο πρώτο μπλοκ κωδικών - BLOCKSIZE, BUFFERCOUNT και MAXTRANSFERSIZE. Ακολουθούν οι περιγραφές τους από το MSDN:
ΜΠΛΟΚΣΙΖΕ = { μπλοκ | @ blocksize_variable } - υποδεικνύει το μέγεθος του φυσικού μπλοκ σε byte. Τα υποστηριζόμενα μεγέθη είναι 512, 1024, 2048, 4096, 8192, 16, 384 και 32 byte (768 KB). Η προεπιλεγμένη τιμή είναι 65 για συσκευές ταινίας και 536 για άλλες συσκευές. Αυτή η παράμετρος δεν απαιτείται συνήθως επειδή η εντολή BACKUP επιλέγει αυτόματα ένα μέγεθος μπλοκ κατάλληλο για τη συσκευή. Η ρητή ρύθμιση του μεγέθους του μπλοκ παρακάμπτει την αυτόματη επιλογή μεγέθους μπλοκ.
BUFFERCOUNT = { buffercount | @ buffercount_variable } - Καθορίζει τον συνολικό αριθμό των buffer I/O που θα χρησιμοποιηθούν για τη λειτουργία δημιουργίας αντιγράφων ασφαλείας. Μπορείτε να καθορίσετε οποιαδήποτε θετική ακέραια τιμή, αλλά ένας μεγάλος αριθμός buffers μπορεί να προκαλέσει σφάλμα εκτός μνήμης λόγω υπερβολικού χώρου εικονικών διευθύνσεων στη διαδικασία Sqlservr.exe.
Η συνολική ποσότητα χώρου που χρησιμοποιείται από τα buffer καθορίζεται από τον ακόλουθο τύπο:
BUFFERCOUNT * MAXTRANSFERSIZE.
MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable } Καθορίζει το μεγαλύτερο πακέτο δεδομένων, σε byte, για ανταλλαγή δεδομένων μεταξύ του SQL Server και του εφεδρικού σετ μέσων. Υποστηρίζονται πολλαπλάσια από 65 byte (536 KB) έως 64 byte (4 MB).
Το ορκίζομαι, το έχω διαβάσει στο παρελθόν, αλλά δεν είχα σκεφτεί τι αντίκτυπο μπορεί να έχουν στην απόδοση. Επιπλέον, προφανώς, είναι απαραίτητο να κάνουμε ένα είδος «coming out» και να παραδεχτώ ότι ακόμη και τώρα δεν καταλαβαίνω πλήρως τι ακριβώς κάνουν. Πιθανώς, πρέπει να διαβάσετε περισσότερα σχετικά με το I/O με buffer και την εργασία με σκληρό δίσκο. Κάποια μέρα θα το κάνω, αλλά τώρα μπορώ απλώς να γράψω ένα σενάριο που θα ελέγχει πώς αυτές οι τιμές επηρεάζουν την ταχύτητα με την οποία λαμβάνεται το αντίγραφο ασφαλείας.
Έφτιαξα μια μικρή βάση δεδομένων, μεγέθους περίπου 10 GB, την έβαλα στον SSD και έβαλα τον κατάλογο αντιγράφων ασφαλείας στον σκληρό δίσκο.
Δημιουργώ έναν προσωρινό πίνακα για την αποθήκευση των αποτελεσμάτων (δεν έχω προσωρινό πίνακα για να μπορώ να συλλέξω τα αποτελέσματα με περισσότερες λεπτομέρειες, αλλά αποφασίζετε μόνοι σας):
DROP TABLE IF EXISTS ##bt_results;
CREATE TABLE ##bt_results (
id int IDENTITY (1, 1) PRIMARY KEY,
start_date datetime NOT NULL,
finish_date datetime NOT NULL,
backup_size bigint NOT NULL,
compressed_size bigint,
block_size int,
buffer_count int,
transfer_size int
);Η αρχή του σεναρίου είναι απλός - ένθετοι βρόχοι, καθένας από τους οποίους αλλάζει την τιμή μιας παραμέτρου, εισάγετε αυτές τις παραμέτρους στην εντολή BACKUP, αποθηκεύστε την τελευταία εγγραφή με το ιστορικό από το msdb.dbo.backupset, διαγράψτε το αρχείο αντιγράφου ασφαλείας και το επόμενο επανάληψη. Δεδομένου ότι τα δεδομένα εκτέλεσης αντιγράφων ασφαλείας λαμβάνονται από το backupset, η ακρίβεια χάνεται κάπως (δεν υπάρχουν κλάσματα δευτερολέπτου), αλλά θα το επιβιώσουμε.
Πρώτα πρέπει να ενεργοποιήσετε τη χρήση του xp_cmdshell για τη διαγραφή αντιγράφων ασφαλείας (μετά μην ξεχάσετε να το απενεργοποιήσετε εάν δεν το χρειάζεστε):
EXEC sp_configure 'show advanced options', 1;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
GOΛοιπόν, στην πραγματικότητα:
DECLARE @tmplt AS nvarchar(max) = N'
BACKUP DATABASE [bt]
TO DISK = ''D:SQLServerbackupbt.bak''
WITH
COMPRESSION,
BLOCKSIZE = {bs},
BUFFERCOUNT = {bc},
MAXTRANSFERSIZE = {ts}';
DECLARE @sql AS nvarchar(max);
/* BLOCKSIZE values */
DECLARE @bs int = 4096,
@max_bs int = 65536;
/* BUFFERCOUNT values */
DECLARE @bc int = 7,
@min_bc int = 7,
@max_bc int = 800;
/* MAXTRANSFERSIZE values */
DECLARE @ts int = 524288, --512KB, default = 1024KB
@min_ts int = 524288,
@max_ts int = 4194304; --4MB
SELECT TOP 1
@bs = COALESCE (block_size, 4096),
@bc = COALESCE (buffer_count, 7),
@ts = COALESCE (transfer_size, 524288)
FROM ##bt_results
ORDER BY id DESC;
WHILE (@bs <= @max_bs)
BEGIN
WHILE (@bc <= @max_bc)
BEGIN
WHILE (@ts <= @max_ts)
BEGIN
SET @sql = REPLACE (REPLACE (REPLACE(@tmplt, N'{bs}', CAST(@bs AS nvarchar(50))), N'{bc}', CAST (@bc AS nvarchar(50))), N'{ts}', CAST (@ts AS nvarchar(50)));
EXEC (@sql);
INSERT INTO ##bt_results (start_date, finish_date, backup_size, compressed_size, block_size, buffer_count, transfer_size)
SELECT TOP 1 backup_start_date, backup_finish_date, backup_size, compressed_backup_size, @bs, @bc, @ts
FROM msdb.dbo.backupset
ORDER BY backup_set_id DESC;
EXEC xp_cmdshell 'del "D:SQLServerbackupbt.bak"', no_output;
SET @ts += @ts;
END
SET @bc += @bc;
SET @ts = @min_ts;
WAITFOR DELAY '00:00:05';
END
SET @bs += @bs;
SET @bc = @min_bc;
SET @ts = @min_ts;
ENDΕάν ξαφνικά χρειάζεστε εξηγήσεις για το τι συμβαίνει εδώ - γράψτε στα σχόλια ή σε ένα προσωπικό μήνυμα. Προς το παρόν, θα μιλήσω μόνο για τις παραμέτρους που εισάγω στη BACKUP DATABASE.
Για το BLOCKSIZE, έχουμε μια "κλειστή" λίστα τιμών και δεν είχα αντίγραφο ασφαλείας με BLOCKSIZE < 4KB. ΜΕΓΙΣΤΙΚΗ ΜΕΤΑΦΟΡΑ οποιουδήποτε πολλαπλάσιου των 64KB, από 64KB σε 4MB. Από προεπιλογή στο σύστημά μου 1024KB, πήρα 512 - 1024 - 2048 - 4096.
Ήταν πιο δύσκολο με το BUFFERCOUNT - μπορεί να είναι οποιοσδήποτε θετικός αριθμός, αλλά ο σύνδεσμος λέει . Λέει επίσης πώς να λάβετε πληροφορίες για το BUFFERCOUNT με το οποίο λαμβάνεται πραγματικά το αντίγραφο ασφαλείας - το έχω 7. Δεν είχε νόημα να το μειώσω και το ανώτατο όριο βρέθηκε εμπειρικά - με BUFFERCOUNT = 896 και MAXTRANSFERSIZE = 4194304 το αντίγραφο ασφαλείας έπεσε με ένα σφάλμα (για το οποίο δημοσιεύτηκε στον παραπάνω σύνδεσμο):
Msg 3013, Level 16, State 1, Line 7 BACKUP DATABASE τερματίζεται ασυνήθιστα.
Μήνυμα 701, Επίπεδο 17, Κατάσταση 123, Γραμμή 7 Δεν υπάρχει επαρκής μνήμη συστήματος στο χώρο συγκέντρωσης πόρων «προεπιλογή» για την εκτέλεση αυτού του ερωτήματος.
Για σύγκριση, πρώτα θα δείξω τα αποτελέσματα της δημιουργίας αντιγράφου ασφαλείας χωρίς να προσδιορίσω καθόλου παραμέτρους:
BACKUP DATABASE [bt]
TO DISK = 'D:SQLServerbackupbt.bak'
WITH COMPRESSION;Λοιπόν, δημιουργία αντιγράφων ασφαλείας και δημιουργία αντιγράφων ασφαλείας:
Επεξεργασμένες 1070072 σελίδες για τη βάση δεδομένων 'bt', το αρχείο 'bt' στο αρχείο 1.
Έγινε επεξεργασία 2 σελίδων για τη βάση δεδομένων "bt", αρχείο "bt_log" στο αρχείο 1.
Η BACKUP DATABASE επεξεργάστηκε με επιτυχία 1070074 σελίδες σε 53.171 δευτερόλεπτα (157.227 MB/sec).
Το ίδιο το σενάριο, δοκιμάζοντας τις παραμέτρους, λειτούργησε σε μερικές ώρες, όλες οι μετρήσεις μέσα . Και εδώ είναι μια επιλογή αποτελεσμάτων που έχουν τους τρεις καλύτερους χρόνους εκτέλεσης (προσπάθησα να φτιάξω ένα όμορφο γράφημα, αλλά, στη δημοσίευση, πρέπει να τα βγάλω πέρα με ένα σημάδι και στα σχόλια πρόσθεσε ).
SELECT TOP 7 WITH TIES
compressed_size,
block_size,
buffer_count,
transfer_size,
DATEDIFF(SECOND, start_date, finish_date) AS backup_time_sec
FROM ##bt_results
ORDER BY backup_time_sec ASC;
Προσοχή, μόνο μια πολύ σημαντική σημείωση από του :
Μπορούμε να πούμε με βεβαιότητα ότι η σύνδεση μεταξύ των παραμέτρων και της ταχύτητας δημιουργίας αντιγράφων ασφαλείας σε αυτά τα εύρη τιμώνείναι τυχαία, δεν υπάρχει μοτίβο. Αλλά η απομάκρυνση από τις ενσωματωμένες παραμέτρους είχε προφανώς καλή επίδραση στο αποτέλεσμα.
Εκείνοι. Μόνο με τον έλεγχο των τυπικών παραμέτρων BACKUP υπήρξε διπλάσιο κέρδος στον χρόνο αφαίρεσης του εφεδρικού αντιγράφου: 2 δευτερόλεπτα, έναντι 26 στην αρχή. Και δεν είναι κακό, σωστά; Αλλά πρέπει να δείτε τι υπάρχει με την αποκατάσταση. Τι θα συμβεί αν τώρα θα είναι 53 φορές περισσότερο για να ανακάμψει;
Αρχικά, ας μετρήσουμε πόσο χρόνο χρειάζεται για να επαναφέρετε ένα αντίγραφο ασφαλείας με προεπιλεγμένες ρυθμίσεις:
RESTORE DATABASE [bt]
FROM DISK = 'D:SQLServerbackupbt.bak'
WITH REPLACE, RECOVERY;Λοιπόν, εσείς οι ίδιοι το ξέρετε αυτό, τα μονοπάτια είναι εκεί, αντικατάσταση-όχι αντικατάσταση, ανάκτηση-όχι ανάκτηση. Και το κάνω ως εξής:
Επεξεργασμένες 1070072 σελίδες για τη βάση δεδομένων 'bt', το αρχείο 'bt' στο αρχείο 1.
Έγινε επεξεργασία 2 σελίδων για τη βάση δεδομένων "bt", αρχείο "bt_log" στο αρχείο 1.
Η RESTORE DATABASE επεξεργάστηκε με επιτυχία 1070074 σελίδες σε 40.752 δευτερόλεπτα (205.141 MB/sec).
Και τώρα θα προσπαθήσω να επαναφέρω τα αντίγραφα ασφαλείας που έχουν ληφθεί με άλλαξα BLOCKSIZE, BUFFERCOUNT και MAXTRANSFERSIZE.
BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304Η RESTORE DATABASE επεξεργάστηκε με επιτυχία 1070074 σελίδες σε 32.283 δευτερόλεπτα (258.958 MB/sec).
BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304Η RESTORE DATABASE επεξεργάστηκε με επιτυχία 1070074 σελίδες σε 32.682 δευτερόλεπτα (255.796 MB/sec).
BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152Η RESTORE DATABASE επεξεργάστηκε με επιτυχία 1070074 σελίδες σε 32.091 δευτερόλεπτα (260.507 MB/sec).
BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304Η RESTORE DATABASE επεξεργάστηκε με επιτυχία 1070074 σελίδες σε 32.401 δευτερόλεπτα (258.015 MB/sec).
Η δήλωση RESTORE DATABASE δεν αλλάζει κατά την ανάκτηση, αυτές οι παράμετροι δεν καθορίζονται σε αυτήν, ο ίδιος ο SQL Server τις καθορίζει από το αντίγραφο ασφαλείας. Και είναι σαφές ότι ακόμη και με την αποκατάσταση μπορεί να υπάρξει κέρδος - σχεδόν 20% πιο γρήγορα (για να είμαι ειλικρινής, δεν αφιέρωσα πολύ χρόνο στην αποκατάσταση, τρύπησα αρκετά από τα πιο «γρήγορα» αντίγραφα ασφαλείας και βεβαιώθηκα ότι δεν υπήρχε επιδείνωση).
Σε κάθε περίπτωση, θα διευκρινίσω - δεν περιγράφονται εδώ ορισμένες παράμετροι που είναι βέλτιστες για όλους. Μπορείτε να αποκτήσετε τις καλύτερες παραμέτρους για τον εαυτό σας μόνο με δοκιμή. Πήρα αυτά τα αποτελέσματα, θα έχετε διαφορετικά. Αλλά βλέπετε ότι τα αντίγραφα ασφαλείας σας μπορούν να "συντονιστούν" και μπορούν πραγματικά να σχηματιστούν και να αναπτυχθούν πιο γρήγορα.
Συνιστώ επίσης ανεπιφύλακτα να διαβάσετε την τεκμηρίωση στο σύνολό της, γιατί μπορεί να υπάρχουν αποχρώσεις για το σύστημά σας.
Από τότε που άρχισα να γράφω για αντίγραφα ασφαλείας, θέλω να γράψω αμέσως για μια ακόμη "βελτιστοποίηση", η οποία είναι πιο κοινή από τις παραμέτρους "συντονισμού" (απ' όσο καταλαβαίνω, χρησιμοποιείται από τουλάχιστον μερικά από τα βοηθητικά προγράμματα δημιουργίας αντιγράφων ασφαλείας, πιθανώς μαζί με τις παραμέτρους που περιγράφηκαν προηγουμένως), αλλά δεν έχει ακόμη περιγραφεί ούτε στο Habré.
Αν κοιτάξουμε τη δεύτερη γραμμή της τεκμηρίωσης, ακριβώς κάτω από τη ΒΑΣΗ ΔΕΔΟΜΕΝΩΝ ΑΝΤΙΓΡΑΦΩΝ, βλέπουμε:
TO <backup_device> [ ,...n ]Τι πιστεύετε ότι θα συμβεί εάν καθορίσετε πολλές εφεδρικές_συσκευές; Η σύνταξη κάνει. Και θα υπάρχει ένα πολύ ενδιαφέρον πράγμα - το αντίγραφο ασφαλείας απλά θα "κηλιδωθεί" σε πολλές συσκευές. Εκείνοι. κάθε "συσκευή" ξεχωριστά θα είναι άχρηστη, έχασε μία, έχασε ολόκληρο το αντίγραφο ασφαλείας. Αλλά πώς θα επηρεάσει μια τέτοια κηλίδα την ταχύτητα δημιουργίας αντιγράφων ασφαλείας;
Ας προσπαθήσουμε να δημιουργήσουμε ένα αντίγραφο ασφαλείας σε δύο "συσκευές" που βρίσκονται δίπλα-δίπλα στον ίδιο φάκελο:
BACKUP DATABASE [bt]
TO
DISK = 'D:SQLServerbackupbt1.bak',
DISK = 'D:SQLServerbackupbt2.bak'
WITH COMPRESSION;Άγιοι Πατέρες, γιατί γίνεται αυτό;
Επεξεργασμένες 1070072 σελίδες για τη βάση δεδομένων 'bt', το αρχείο 'bt' στο αρχείο 1.
Επεξεργασίες 2 σελίδων για βάση δεδομένων 'bt', αρχείο 'bt'log' στο αρχείο 1.
Η BACKUP DATABASE επεξεργάστηκε με επιτυχία 1070074 σελίδες σε 40.092 δευτερόλεπτα (208.519 MB/sec).
Η δημιουργία αντιγράφων ασφαλείας έγινε κατά 25% πιο γρήγορη; Και αν προσθέσετε μερικές ακόμη συσκευές;
BACKUP DATABASE [bt]
TO
DISK = 'D:SQLServerbackupbt1.bak',
DISK = 'D:SQLServerbackupbt2.bak',
DISK = 'D:SQLServerbackupbt3.bak',
DISK = 'D:SQLServerbackupbt4.bak'
WITH COMPRESSION;Η BACKUP DATABASE επεξεργάστηκε με επιτυχία 1070074 σελίδες σε 34.234 δευτερόλεπτα (244.200 MB/sec).
Συνολικά, το κέρδος είναι περίπου το 35% του χρόνου δημιουργίας αντιγράφων ασφαλείας μόνο λόγω του γεγονότος ότι το αντίγραφο ασφαλείας εγγράφεται αμέσως σε 4 αρχεία σε έναν δίσκο. Έλεγξα έναν μεγαλύτερο αριθμό - δεν υπάρχει κέρδος στο φορητό υπολογιστή μου, βέλτιστα - 4 συσκευές. Για εσάς - δεν ξέρω, πρέπει να ελέγξετε. Και, παρεμπιπτόντως, εάν έχετε αυτές τις συσκευές - αυτοί είναι πραγματικά διαφορετικοί δίσκοι, συγχαρητήρια, το κέρδος θα πρέπει να είναι ακόμη πιο σημαντικό.
Τώρα ας μιλήσουμε για το πώς να αποκαταστήσετε αυτήν την ευτυχία. Για να το κάνετε αυτό, θα πρέπει να αλλάξετε την εντολή ανάκτησης και να απαριθμήσετε όλες τις συσκευές:
RESTORE DATABASE [bt]
FROM
DISK = 'D:SQLServerbackupbt1.bak',
DISK = 'D:SQLServerbackupbt2.bak',
DISK = 'D:SQLServerbackupbt3.bak',
DISK = 'D:SQLServerbackupbt4.bak'
WITH REPLACE, RECOVERY;Η RESTORE DATABASE επεξεργάστηκε με επιτυχία 1070074 σελίδες σε 38.027 δευτερόλεπτα (219.842 MB/sec).
Λίγο πιο γρήγορα, αλλά κάπου κοντά, όχι ουσιαστικό. Γενικά, το αντίγραφο ασφαλείας αφαιρείται πιο γρήγορα και αποκαθίσταται με τον ίδιο τρόπο - επιτυχία; Σε ό,τι με αφορά, είναι αρκετά επιτυχημένο. Αυτό важно, έτσι επαναλαμβάνω - αν εσείς Εάν χάσετε τουλάχιστον ένα από αυτά τα αρχεία, χάνετε ολόκληρο το αντίγραφο ασφαλείας.
Αν κοιτάξετε τις πληροφορίες αρχείου καταγραφής σχετικά με το αντίγραφο ασφαλείας που εμφανίζεται χρησιμοποιώντας το Trace Flag 3213 και το 3605, μπορείτε να παρατηρήσετε ότι κατά τη δημιουργία αντιγράφων ασφαλείας σε πολλές συσκευές, αυξάνεται τουλάχιστον ο αριθμός των BUFFERCOUNT. Πιθανώς, μπορείτε να προσπαθήσετε να επιλέξετε πιο βέλτιστες παραμέτρους για BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE, αλλά δεν τα κατάφερα αμέσως και να πραγματοποιήσω ξανά τέτοιες δοκιμές, αλλά ήμουν πολύ τεμπέλης για διαφορετικό αριθμό αρχείων. Ναι, και οι δίσκοι είναι κρίμα. Αν θέλετε να οργανώσετε τέτοιες δοκιμές στο χώρο σας, δεν είναι δύσκολο να ξαναφτιάξετε το σενάριο.
Τέλος, ας μιλήσουμε για την τιμή. Εάν ένα αντίγραφο ασφαλείας λαμβάνεται παράλληλα με την εργασία των χρηστών, είναι απαραίτητο να προσεγγίσετε τις δοκιμές πολύ υπεύθυνα, γιατί εάν το αντίγραφο ασφαλείας γίνει πιο γρήγορα, οι δίσκοι καταπονούνται περισσότερο, το φορτίο στον επεξεργαστή αυξάνεται (ακόμα πρέπει να το συμπιέσετε η μύγα), αντίστοιχα, η συνολική απόκριση του συστήματος μειώνεται.
Αστεία, αστεία, αλλά καταλαβαίνω απόλυτα ότι δεν έκανα καμία αποκάλυψη. Αυτό που γράφεται παραπάνω είναι απλώς μια επίδειξη του πώς μπορείτε να επιλέξετε τις βέλτιστες παραμέτρους για τη λήψη αντιγράφων ασφαλείας.
Να θυμάστε ότι ό,τι κάνετε - το κάνετε με δικό σας κίνδυνο και κίνδυνο. Ελέγξτε τα αντίγραφα ασφαλείας σας και μην ξεχάσετε το DBCC CHECKDB.
Πηγή: www.habr.com