🥇MS SQL ಸರ್ವರ್: ಸ್ಟೀರಾಯ್ಡ್‌ಗಳ ಮೇಲೆ ಬ್ಯಾಕಪ್

ನಿರೀಕ್ಷಿಸಿ! ನಿರೀಕ್ಷಿಸಿ! ನಿಜ, ಇದು SQL ಸರ್ವರ್ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳ ಬಗೆಗಿನ ಮತ್ತೊಂದು ಲೇಖನವಲ್ಲ. ಚೇತರಿಕೆ ಮಾದರಿಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳು ಮತ್ತು ಮಿತಿಮೀರಿ ಬೆಳೆದ ಲಾಗ್ ಅನ್ನು ಹೇಗೆ ಎದುರಿಸುವುದು ಎಂಬುದರ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡುವುದಿಲ್ಲ.

ಬಹುಶಃ (ಬಹುಶಃ), ಈ ಪೋಸ್ಟ್ ಅನ್ನು ಓದಿದ ನಂತರ, ಪ್ರಮಾಣಿತ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮ್ಮಿಂದ ತೆಗೆದುಹಾಕಲಾದ ಬ್ಯಾಕಪ್ ಅನ್ನು ನಾಳೆ ರಾತ್ರಿ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಅಲ್ಲದೆ, 1.5 ಪಟ್ಟು ವೇಗವಾಗಿ. ಮತ್ತು ನೀವು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಬ್ಯಾಕಪ್ ಡೇಟಾಬೇಸ್ ನಿಯತಾಂಕಗಳನ್ನು ಬಳಸುವುದರಿಂದ ಮಾತ್ರ.

ಪೋಸ್ಟ್‌ನ ವಿಷಯವು ನಿಮಗೆ ಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ಕ್ಷಮಿಸಿ. "habr sql ಸರ್ವರ್ ಬ್ಯಾಕಪ್" ಎಂಬ ಪದಗುಚ್ಛಕ್ಕಾಗಿ Google ಗೆ ಸಿಕ್ಕ ಎಲ್ಲವನ್ನೂ ನಾನು ಓದಿದ್ದೇನೆ ಮತ್ತು ಒಂದೇ ಒಂದು ಲೇಖನದಲ್ಲಿ ಬ್ಯಾಕಪ್ ಸಮಯವನ್ನು ನಿಯತಾಂಕಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಹೇಗಾದರೂ ಪ್ರಭಾವಿಸಬಹುದು ಎಂಬ ಅಂಶದ ಬಗ್ಗೆ ಯಾವುದೇ ಉಲ್ಲೇಖವನ್ನು ನಾನು ಕಂಡುಕೊಂಡಿಲ್ಲ.

ಅಲೆಕ್ಸಾಂಡರ್ ಗ್ಲಾಡ್ಚೆಂಕೊ ಅವರ ಕಾಮೆಂಟ್ಗೆ ನಾನು ತಕ್ಷಣ ನಿಮ್ಮ ಗಮನವನ್ನು ಸೆಳೆಯುತ್ತೇನೆ (@mssqlhelp):

ಉತ್ಪಾದನೆಯಲ್ಲಿ BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE ನಿಯತಾಂಕಗಳನ್ನು ಎಂದಿಗೂ ಬದಲಾಯಿಸಬೇಡಿ. ಅಂತಹ ಲೇಖನಗಳನ್ನು ಬರೆಯಲು ಮಾತ್ರ ಅವುಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನೀವು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಮೆಮೊರಿ ಸಮಸ್ಯೆಗಳನ್ನು ತೊಡೆದುಹಾಕುತ್ತೀರಿ.

ಇದು ಸಹಜವಾಗಿ, ಸ್ಮಾರ್ಟೆಸ್ಟ್ ಆಗಿರುವುದು ಮತ್ತು ವಿಶೇಷ ವಿಷಯವನ್ನು ಪೋಸ್ಟ್ ಮಾಡುವುದು ತಂಪಾಗಿರುತ್ತದೆ, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಹಾಗಲ್ಲ. ಈ ವಿಷಯಕ್ಕೆ ಮೀಸಲಾಗಿರುವ ಇಂಗ್ಲಿಷ್ ಭಾಷೆಯ ಮತ್ತು ರಷ್ಯನ್ ಭಾಷೆಯ ಲೇಖನಗಳು/ಪೋಸ್ಟ್‌ಗಳು ಇವೆ (ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಏನು ಕರೆಯಬೇಕೆಂದು ನಾನು ಯಾವಾಗಲೂ ಗೊಂದಲಕ್ಕೊಳಗಾಗಿದ್ದೇನೆ). ನಾನು ಕಂಡ ಕೆಲವು ಇಲ್ಲಿವೆ: ಬಾರಿ, два, ಮೂರು (sql.ru ನಲ್ಲಿ).

ಆದ್ದರಿಂದ, ಪ್ರಾರಂಭಿಸಲು, ನಾನು ಸ್ವಲ್ಪ ಸ್ಟ್ರಿಪ್ಡ್-ಡೌನ್ ಬ್ಯಾಕಪ್ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಲಗತ್ತಿಸುತ್ತೇನೆ ಎಂಎಸ್‌ಡಿಎನ್ (ಮೂಲಕ, ಬ್ಯಾಕಪ್ ಡೇಟಾಬೇಸ್ ಕುರಿತು ನಾನು ಮೇಲೆ ಬರೆದಿದ್ದೇನೆ, ಆದರೆ ಇವೆಲ್ಲವೂ ವಹಿವಾಟು ಲಾಗ್ ಬ್ಯಾಕಪ್ ಮತ್ತು ಡಿಫರೆನ್ಷಿಯಲ್ ಬ್ಯಾಕಪ್ ಎರಡಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಆದರೆ ಬಹುಶಃ ಕಡಿಮೆ ಸ್ಪಷ್ಟ ಪರಿಣಾಮದೊಂದಿಗೆ):

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 ಗೆ ಭೇಟಿ ನೀಡಿದ್ದೀರಾ? ಒಂದೂವರೆ ಪರದೆಗಳಿಗೆ ಆಯ್ಕೆಗಳಿವೆ ಎಂದು ನೀವು ನೋಡಿದ್ದೀರಾ? ನಾನೂ ನೋಡಿದೆ...

ಕೋಡ್‌ನ ಮೊದಲ ಬ್ಲಾಕ್‌ನಲ್ಲಿ ಉಳಿದಿರುವ ಮೂರು ನಿಯತಾಂಕಗಳ ಬಗ್ಗೆ ನಾವು ಮಾತನಾಡುತ್ತೇವೆ ಎಂದು ನೀವು ಈಗಾಗಲೇ ಅರಿತುಕೊಂಡಿದ್ದೀರಿ - ಬ್ಲಾಕ್‌ಸೈಜ್, ಬಫರ್‌ಕೌಂಟ್ ಮತ್ತು ಮ್ಯಾಕ್ಸ್‌ಟ್ರಾನ್ಸ್‌ಫರ್ಸೈಜ್. MSDN ನಿಂದ ಅವರ ವಿವರಣೆಗಳು ಇಲ್ಲಿವೆ:

ಬ್ಲಾಕ್ ಗಾತ್ರ = { ಬ್ಲಾಕ್ಸೈಜ್ | @ blocksize_variable } - ಬೈಟ್‌ಗಳಲ್ಲಿ ಭೌತಿಕ ಬ್ಲಾಕ್ ಗಾತ್ರವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಬೆಂಬಲಿತ ಗಾತ್ರಗಳು 512, 1024, 2048, 4096, 8192, 16, 384, ಮತ್ತು 32 ಬೈಟ್‌ಗಳು (768 KB). ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವು ಟೇಪ್ ಸಾಧನಗಳಿಗೆ 65 ಮತ್ತು ಇತರ ಸಾಧನಗಳಿಗೆ 536 ಆಗಿದೆ. ವಿಶಿಷ್ಟವಾಗಿ ಈ ಪ್ಯಾರಾಮೀಟರ್ ಅಗತ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ ಬ್ಯಾಕಪ್ ಹೇಳಿಕೆಯು ಸಾಧನಕ್ಕೆ ಸೂಕ್ತವಾದ ಬ್ಲಾಕ್ ಗಾತ್ರವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಬ್ಲಾಕ್ ಗಾತ್ರವನ್ನು ಹೊಂದಿಸುವುದು ಸ್ವಯಂಚಾಲಿತ ಬ್ಲಾಕ್ ಗಾತ್ರದ ಆಯ್ಕೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಅತಿಕ್ರಮಿಸುತ್ತದೆ.

ಬಫರ್‌ಕೌಂಟ್ = { ಬಫರ್ ಎಣಿಕೆ | @ ಬಫರ್‌ಕೌಂಟ್_ವೇರಿಯಬಲ್ } - ಬ್ಯಾಕಪ್ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ಬಳಸಲಾಗುವ I/O ಬಫರ್‌ಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ನೀವು ಯಾವುದೇ ಧನಾತ್ಮಕ ಪೂರ್ಣಾಂಕ ಮೌಲ್ಯವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು, ಆದರೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಬಫರ್‌ಗಳು Sqlservr.exe ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ಮಿತಿಮೀರಿದ ವರ್ಚುವಲ್ ವಿಳಾಸ ಸ್ಥಳದ ಕಾರಣದಿಂದಾಗಿ ಮೆಮೊರಿಯ ದೋಷವನ್ನು ಉಂಟುಮಾಡಬಹುದು.
ಬಫರ್‌ಗಳು ಬಳಸುವ ಒಟ್ಟು ಜಾಗವನ್ನು ಈ ಕೆಳಗಿನ ಸೂತ್ರದಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ: BUFFERCOUNT * MAXTRANSFERSIZE.

ಗರಿಷ್ಠ ವರ್ಗಾವಣೆ = { ಗರಿಷ್ಠ ವರ್ಗಾವಣೆ | @ maxtransfersize_variable } SQL ಸರ್ವರ್ ಮತ್ತು ಬ್ಯಾಕಪ್ ಸೆಟ್ ಮೀಡಿಯಾ ನಡುವೆ ವಿನಿಮಯ ಮಾಡಲು ಬೈಟ್‌ಗಳಲ್ಲಿ ದೊಡ್ಡ ಡೇಟಾ ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. 65 ಬೈಟ್‌ಗಳವರೆಗೆ (536 MB) 64 ಬೈಟ್‌ಗಳ (4 KB) ಮಲ್ಟಿಪಲ್‌ಗಳು ಬೆಂಬಲಿತವಾಗಿದೆ.

ನಾನು ಪ್ರತಿಜ್ಞೆ ಮಾಡುತ್ತೇನೆ - ನಾನು ಇದನ್ನು ಮೊದಲು ಓದಿದ್ದೇನೆ, ಆದರೆ ಉತ್ಪಾದಕತೆಯ ಮೇಲೆ ಅವು ಎಷ್ಟು ಪ್ರಭಾವ ಬೀರುತ್ತವೆ ಎಂಬುದು ನನಗೆ ಎಂದಿಗೂ ಸಂಭವಿಸಲಿಲ್ಲ. ಇದಲ್ಲದೆ, ಸ್ಪಷ್ಟವಾಗಿ, ನಾನು ಒಂದು ರೀತಿಯ "ಹೊರಬರುವ" ಮಾಡಬೇಕಾಗಿದೆ ಮತ್ತು ಈಗಲೂ ಅವರು ನಿಖರವಾಗಿ ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆಂದು ನನಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು. ನಾನು ಬಹುಶಃ ಬಫರ್ಡ್ I/O ಮತ್ತು ಹಾರ್ಡ್ ಡ್ರೈವ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಕುರಿತು ಇನ್ನಷ್ಟು ಓದಬೇಕಾಗಿದೆ. ಒಂದು ದಿನ ನಾನು ಇದನ್ನು ಮಾಡುತ್ತೇನೆ, ಆದರೆ ಇದೀಗ ನಾನು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬರೆಯಬಹುದು ಅದು ಬ್ಯಾಕಪ್ ತೆಗೆದುಕೊಳ್ಳುವ ವೇಗವನ್ನು ಈ ಮೌಲ್ಯಗಳು ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

ನಾನು ಸುಮಾರು 10 ಜಿಬಿ ಗಾತ್ರದ ಸಣ್ಣ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತಯಾರಿಸಿದೆ, ಅದನ್ನು ಎಸ್‌ಎಸ್‌ಡಿಯಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಎಚ್‌ಡಿಡಿಯಲ್ಲಿ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳಿಗಾಗಿ ಡೈರೆಕ್ಟರಿಯನ್ನು ಹಾಕಿದೆ.

ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾನು ತಾತ್ಕಾಲಿಕ ಕೋಷ್ಟಕವನ್ನು ರಚಿಸುತ್ತೇನೆ (ನನ್ನ ಬಳಿ ಅದು ತಾತ್ಕಾಲಿಕವಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಫಲಿತಾಂಶಗಳನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಅಗೆಯಬಹುದು, ಆದರೆ ನೀವೇ ನಿರ್ಧರಿಸಿ):

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
);

ಸ್ಕ್ರಿಪ್ಟ್‌ನ ತತ್ವವು ಸರಳವಾಗಿದೆ - ನೆಸ್ಟೆಡ್ ಲೂಪ್‌ಗಳು, ಪ್ರತಿಯೊಂದೂ ಒಂದು ಪ್ಯಾರಾಮೀಟರ್‌ನ ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಈ ನಿಯತಾಂಕಗಳನ್ನು ಬ್ಯಾಕಪ್ ಆಜ್ಞೆಯಲ್ಲಿ ಸೇರಿಸಿ, msdb.dbo.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

ಇಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದರ ಕುರಿತು ನಿಮಗೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಸ್ಪಷ್ಟೀಕರಣ ಅಗತ್ಯವಿದ್ದರೆ, ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಅಥವಾ PM ನಲ್ಲಿ ಬರೆಯಿರಿ. ಸದ್ಯಕ್ಕೆ, ನಾನು ಬ್ಯಾಕಪ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಇರಿಸಿರುವ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳ ಬಗ್ಗೆ ಮಾತ್ರ ಹೇಳುತ್ತೇನೆ.

BLOCKSIZE ಗಾಗಿ ನಾವು "ಮುಚ್ಚಿದ" ಮೌಲ್ಯಗಳ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು BLOCKSIZE < 4KB ಯೊಂದಿಗೆ ನಾನು ಬ್ಯಾಕಪ್ ಅನ್ನು ನಿರ್ವಹಿಸಲಿಲ್ಲ. 64KB ಯಿಂದ 64MB ವರೆಗೆ - 4KB ಯ ಬಹುಸಂಖ್ಯೆಯ ಯಾವುದೇ ಸಂಖ್ಯೆಯನ್ನು ಗರಿಷ್ಠವಾಗಿ ಪರಿವರ್ತಿಸಿ. ನನ್ನ ಸಿಸ್ಟಂನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ 1024KB ಆಗಿದೆ, ನಾನು 512 - 1024 - 2048 - 4096 ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇನೆ.

BUFFERCOUNT ನೊಂದಿಗೆ ಇದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿತ್ತು - ಇದು ಯಾವುದೇ ಧನಾತ್ಮಕ ಸಂಖ್ಯೆಯಾಗಿರಬಹುದು, ಆದರೆ ಲಿಂಕ್ ಹೇಳುತ್ತದೆ ಬ್ಯಾಕಪ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಲೆಕ್ಕ ಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡ ಮೌಲ್ಯಗಳು ಏಕೆ ಅಪಾಯಕಾರಿ?. ಬ್ಯಾಕ್‌ಅಪ್ ಅನ್ನು ನಿಜವಾಗಿ ಯಾವ ಬಫರ್‌ಕೌಂಟ್‌ನೊಂದಿಗೆ ಮಾಡಲಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಹೇಗೆ ಪಡೆಯುವುದು ಎಂದು ಸಹ ಇದು ಹೇಳುತ್ತದೆ - ನನಗೆ ಇದು 7 ಆಗಿದೆ. ಅದನ್ನು ಕಡಿಮೆ ಮಾಡುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ, ಮತ್ತು ಮೇಲಿನ ಮಿತಿಯನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕಂಡುಹಿಡಿಯಲಾಗಿದೆ - ಬಫರ್‌ಕೌಂಟ್ = 896 ಮತ್ತು MAXTRANSFERSIZE = 4194304 ಜೊತೆಗೆ ಬ್ಯಾಕಪ್ ಕುಸಿಯಿತು ದೋಷ (ಮೇಲಿನ ಲಿಂಕ್‌ನಲ್ಲಿ ಬರೆಯಲಾದ ಬಗ್ಗೆ):

ಸಂದೇಶ 3013, ಹಂತ 16, ರಾಜ್ಯ 1, ಸಾಲು 7 ಬ್ಯಾಕಪ್ ಡೇಟಾಬೇಸ್ ಅಸಹಜವಾಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತಿದೆ.
ಸಂದೇಶ 701, ಹಂತ 17, ರಾಜ್ಯ 123, ಸಾಲು 7 ಈ ಪ್ರಶ್ನೆಯನ್ನು ಚಲಾಯಿಸಲು ಸಂಪನ್ಮೂಲ ಪೂಲ್ 'ಡೀಫಾಲ್ಟ್' ನಲ್ಲಿ ಸಾಕಷ್ಟು ಸಿಸ್ಟಮ್ ಮೆಮೊರಿ ಇಲ್ಲ.

ಹೋಲಿಕೆಗಾಗಿ, ಯಾವುದೇ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದೆ ಬ್ಯಾಕಪ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುವ ಫಲಿತಾಂಶಗಳನ್ನು ನಾನು ಮೊದಲು ತೋರಿಸುತ್ತೇನೆ:

BACKUP DATABASE [bt]
TO DISK = 'D:SQLServerbackupbt.bak'
WITH COMPRESSION;

ಸರಿ, ಬ್ಯಾಕಪ್ ಮತ್ತು ಬ್ಯಾಕಪ್:

ಡೇಟಾಬೇಸ್ 'bt' ಗಾಗಿ 1070072 ಪುಟಗಳನ್ನು ಸಂಸ್ಕರಿಸಲಾಗಿದೆ, ಫೈಲ್ 1 ನಲ್ಲಿ 'bt' ಫೈಲ್.
ಡೇಟಾಬೇಸ್ 'bt' ಗಾಗಿ 2 ಪುಟಗಳನ್ನು ಸಂಸ್ಕರಿಸಲಾಗಿದೆ, ಫೈಲ್ 1 ನಲ್ಲಿ 'bt_log' ಫೈಲ್.
ಬ್ಯಾಕಪ್ ಡೇಟಾಬೇಸ್ 1070074 ಪುಟಗಳನ್ನು 53.171 ಸೆಕೆಂಡುಗಳಲ್ಲಿ (157.227 MB/sec) ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದೆ.

ಸ್ಕ್ರಿಪ್ಟ್ ಸ್ವತಃ, ನಿಯತಾಂಕಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು, ಒಂದೆರಡು ಗಂಟೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದೆ, ಎಲ್ಲಾ ಅಳತೆಗಳು ಇದ್ದವು google ಸ್ಪ್ರೆಡ್‌ಶೀಟ್. ಮತ್ತು ಮೂರು ಅತ್ಯುತ್ತಮ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯಗಳೊಂದಿಗೆ ಫಲಿತಾಂಶಗಳ ಆಯ್ಕೆ ಇಲ್ಲಿದೆ (ನಾನು ಉತ್ತಮ ಗ್ರಾಫ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದೆ, ಆದರೆ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾನು ಟೇಬಲ್‌ನೊಂದಿಗೆ ಮಾಡಬೇಕಾಗಿದೆ ಮತ್ತು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ @ಮಿಶ್ರಣ ಸೇರಿಸಲಾಗಿದೆ ತುಂಬಾ ತಂಪಾದ ಗ್ರಾಫಿಕ್ಸ್).

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;

ಗಮನ, ಬಹಳ ಮುಖ್ಯವಾದ ಟಿಪ್ಪಣಿ @ಮಿಶ್ರಣ ನಿಂದ ಕಾಮೆಂಟ್ ಮಾಡಿ:

ಈ ಮೌಲ್ಯಗಳ ವ್ಯಾಪ್ತಿಯೊಳಗಿನ ನಿಯತಾಂಕಗಳು ಮತ್ತು ಬ್ಯಾಕಪ್ ವೇಗದ ನಡುವಿನ ಸಂಬಂಧವು ಯಾದೃಚ್ಛಿಕವಾಗಿದೆ, ಯಾವುದೇ ಮಾದರಿಯಿಲ್ಲ ಎಂದು ನಾವು ವಿಶ್ವಾಸದಿಂದ ಹೇಳಬಹುದು. ಆದರೆ ಅಂತರ್ನಿರ್ಮಿತ ನಿಯತಾಂಕಗಳಿಂದ ದೂರ ಹೋಗುವುದು ನಿಸ್ಸಂಶಯವಾಗಿ ಫಲಿತಾಂಶದ ಮೇಲೆ ಉತ್ತಮ ಪರಿಣಾಮ ಬೀರಿತು

ಆ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಬ್ಯಾಕಪ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಮಾತ್ರ ಬ್ಯಾಕಪ್ ತೆಗೆಯುವ ಸಮಯದಲ್ಲಿ 2-ಪಟ್ಟು ಲಾಭವಾಯಿತು: 26 ಸೆಕೆಂಡುಗಳು, ಆರಂಭದಲ್ಲಿ 53. ಅದು ಕೆಟ್ಟದ್ದಲ್ಲ, ಸರಿ? ಆದರೆ ಪುನಃಸ್ಥಾಪನೆಯಿಂದ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಬೇಕಾಗಿದೆ. ಈಗ ಚೇತರಿಸಿಕೊಳ್ಳಲು 4 ಪಟ್ಟು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ ಏನು?

ಮೊದಲಿಗೆ, ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಬ್ಯಾಕಪ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಅಳೆಯೋಣ:

RESTORE DATABASE [bt]
FROM DISK = 'D:SQLServerbackupbt.bak'
WITH REPLACE, RECOVERY;

ಸರಿ, ನೀವೇ ತಿಳಿದಿರುವಿರಿ, ಮಾರ್ಗಗಳಿವೆ, ಬದಲಿ ಬದಲಿಗೆ ಅಲ್ಲ, ಚೇತರಿಕೆ ಚೇತರಿಕೆ ಅಲ್ಲ. ಮತ್ತು ನಾನು ಈ ರೀತಿ ಮಾಡುತ್ತೇನೆ:

ಡೇಟಾಬೇಸ್ 'bt' ಗಾಗಿ 1070072 ಪುಟಗಳನ್ನು ಸಂಸ್ಕರಿಸಲಾಗಿದೆ, ಫೈಲ್ 1 ನಲ್ಲಿ 'bt' ಫೈಲ್.
ಡೇಟಾಬೇಸ್ 'bt' ಗಾಗಿ 2 ಪುಟಗಳನ್ನು ಸಂಸ್ಕರಿಸಲಾಗಿದೆ, ಫೈಲ್ 1 ನಲ್ಲಿ 'bt_log' ಫೈಲ್.
ಮರುಸ್ಥಾಪಿಸಿ ಡೇಟಾಬೇಸ್ 1070074 ಪುಟಗಳನ್ನು 40.752 ಸೆಕೆಂಡುಗಳಲ್ಲಿ (205.141 MB/sec) ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದೆ.

ಈಗ ನಾನು ಬದಲಾದ BLOCKSIZE, BUFFERCOUNT ಮತ್ತು MAXTRANSFERSIZE ನೊಂದಿಗೆ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304
ಮರುಸ್ಥಾಪಿಸಿ ಡೇಟಾಬೇಸ್ 1070074 ಪುಟಗಳನ್ನು 32.283 ಸೆಕೆಂಡುಗಳಲ್ಲಿ (258.958 MB/sec) ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದೆ.
BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304
ಮರುಸ್ಥಾಪಿಸಿ ಡೇಟಾಬೇಸ್ 1070074 ಪುಟಗಳನ್ನು 32.682 ಸೆಕೆಂಡುಗಳಲ್ಲಿ (255.796 MB/sec) ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದೆ.
BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152
ಮರುಸ್ಥಾಪಿಸಿ ಡೇಟಾಬೇಸ್ 1070074 ಪುಟಗಳನ್ನು 32.091 ಸೆಕೆಂಡುಗಳಲ್ಲಿ (260.507 MB/sec) ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದೆ.
BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304
ಮರುಸ್ಥಾಪಿಸಿ ಡೇಟಾಬೇಸ್ 1070074 ಪುಟಗಳನ್ನು 32.401 ಸೆಕೆಂಡುಗಳಲ್ಲಿ (258.015 MB/sec) ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದೆ.

ರಿಸ್ಟೋರ್ ಡೇಟಾಬೇಸ್ ಹೇಳಿಕೆಯು ಚೇತರಿಕೆಯ ಸಮಯದಲ್ಲಿ ಬದಲಾಗುವುದಿಲ್ಲ; ಈ ನಿಯತಾಂಕಗಳನ್ನು ಅದರಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿಲ್ಲ; SQL ಸರ್ವರ್ ಸ್ವತಃ ಅವುಗಳನ್ನು ಬ್ಯಾಕಪ್‌ನಿಂದ ನಿರ್ಧರಿಸುತ್ತದೆ. ಮತ್ತು ಚೇತರಿಕೆಯೊಂದಿಗೆ ಸಹ ಲಾಭವಾಗಬಹುದು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ - ಸುಮಾರು 20% ವೇಗವಾಗಿ (ನಿಜ ಹೇಳಬೇಕೆಂದರೆ, ನಾನು ಚೇತರಿಸಿಕೊಳ್ಳಲು ಹೆಚ್ಚು ಸಮಯ ಕಳೆಯಲಿಲ್ಲ, ನಾನು ಹಲವಾರು "ವೇಗದ" ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳ ಮೂಲಕ ಓಡಿದೆ ಮತ್ತು ಯಾವುದೇ ಕ್ಷೀಣತೆ ಇಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿದೆ).

ಒಂದು ವೇಳೆ, ಇವುಗಳು ಎಲ್ಲರಿಗೂ ಸೂಕ್ತವಾದ ಕೆಲವು ನಿಯತಾಂಕಗಳಲ್ಲ ಎಂದು ನಾನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತೇನೆ. ಪರೀಕ್ಷೆಯ ಮೂಲಕ ಮಾತ್ರ ನೀವು ಸೂಕ್ತವಾದ ನಿಯತಾಂಕಗಳನ್ನು ಪಡೆಯಬಹುದು. ನಾನು ಈ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇನೆ, ನೀವು ವಿಭಿನ್ನವಾದವುಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಆದರೆ ನಿಮ್ಮ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ನೀವು "ಟ್ಯೂನ್" ಮಾಡಬಹುದು ಮತ್ತು ಅವು ನಿಜವಾಗಿ ರೂಪಿಸಬಹುದು ಮತ್ತು ವೇಗವಾಗಿ ನಿಯೋಜಿಸಬಹುದು ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ.

ನೀವು ದಸ್ತಾವೇಜನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಓದಬೇಕೆಂದು ನಾನು ಬಲವಾಗಿ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ಗೆ ನಿರ್ದಿಷ್ಟವಾದ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು ಇರಬಹುದು.

ನಾನು ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳ ಬಗ್ಗೆ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗಿನಿಂದ, "ಟ್ಯೂನಿಂಗ್" ಪ್ಯಾರಾಮೀಟರ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಾಮಾನ್ಯವಾದ ಇನ್ನೊಂದು "ಆಪ್ಟಿಮೈಸೇಶನ್" ಬಗ್ಗೆ ನಾನು ತಕ್ಷಣ ಬರೆಯಲು ಬಯಸುತ್ತೇನೆ (ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಇದನ್ನು ಕನಿಷ್ಠ ಕೆಲವು ಬ್ಯಾಕಪ್ ಉಪಯುಕ್ತತೆಗಳಿಂದ ಬಳಸಲಾಗುತ್ತದೆ, ಬಹುಶಃ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳೊಂದಿಗೆ. ಮೊದಲೇ ವಿವರಿಸಲಾಗಿದೆ), ಆದರೆ ಇದನ್ನು ಇನ್ನೂ ಹ್ಯಾಬ್ರೆಯಲ್ಲಿ ವಿವರಿಸಲಾಗಿಲ್ಲ.

ನಾವು ದಾಖಲಾತಿಯಲ್ಲಿ ಎರಡನೇ ಸಾಲನ್ನು ನೋಡಿದರೆ, ಬ್ಯಾಕಪ್ ಡೇಟಾಬೇಸ್ ಅಡಿಯಲ್ಲಿ, ನಾವು ನೋಡುತ್ತೇವೆ:

TO <backup_device> [ ,...n ]

ನೀವು ಹಲವಾರು backup_devices ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನೀವು ಯೋಚಿಸುತ್ತೀರಿ? ಸಿಂಟ್ಯಾಕ್ಸ್ ಅದನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಮತ್ತು ಬಹಳ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯ ಸಂಭವಿಸುತ್ತದೆ - ಬ್ಯಾಕಪ್ ಸರಳವಾಗಿ ಹಲವಾರು ಸಾಧನಗಳಲ್ಲಿ "ಹರಡುತ್ತದೆ". ಆ. ಪ್ರತಿಯೊಂದು "ಸಾಧನ" ಪ್ರತ್ಯೇಕವಾಗಿ ನಿಷ್ಪ್ರಯೋಜಕವಾಗುತ್ತದೆ, ಒಂದನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ, ಸಂಪೂರ್ಣ ಬ್ಯಾಕಪ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಆದರೆ ಅಂತಹ ಸ್ಮೀಯರಿಂಗ್ ಬ್ಯಾಕ್ಅಪ್ ವೇಗವನ್ನು ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?

ಒಂದೇ ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಇರುವ ಎರಡು “ಸಾಧನಗಳಲ್ಲಿ” ಬ್ಯಾಕಪ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸೋಣ:

BACKUP DATABASE [bt]
TO 
    DISK = 'D:SQLServerbackupbt1.bak',
    DISK = 'D:SQLServerbackupbt2.bak'   
WITH COMPRESSION;

ಪ್ರಪಂಚದ ಪಿತಾಮಹರೇ, ಇದನ್ನು ಏಕೆ ಮಾಡಲಾಗುತ್ತಿದೆ?

ಡೇಟಾಬೇಸ್ 'bt' ಗಾಗಿ 1070072 ಪುಟಗಳನ್ನು ಸಂಸ್ಕರಿಸಲಾಗಿದೆ, ಫೈಲ್ 1 ನಲ್ಲಿ 'bt' ಫೈಲ್.
ಡೇಟಾಬೇಸ್ 'bt' ಗಾಗಿ 2 ಪುಟಗಳನ್ನು ಸಂಸ್ಕರಿಸಲಾಗಿದೆ, ಫೈಲ್ 'bt'ಫೈಲ್ 1 ರಲ್ಲಿ ಲಾಗ್'.
ಬ್ಯಾಕಪ್ ಡೇಟಾಬೇಸ್ 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;

ಬ್ಯಾಕಪ್ ಡೇಟಾಬೇಸ್ 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;

ಮರುಸ್ಥಾಪಿಸಿ ಡೇಟಾಬೇಸ್ 1070074 ಪುಟಗಳನ್ನು 38.027 ಸೆಕೆಂಡುಗಳಲ್ಲಿ (219.842 MB/sec) ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದೆ.

ಸ್ವಲ್ಪ ವೇಗವಾಗಿ, ಆದರೆ ಎಲ್ಲೋ ಹತ್ತಿರದಲ್ಲಿದೆ, ಗಮನಾರ್ಹವಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ, ಬ್ಯಾಕ್ಅಪ್ ಅನ್ನು ವೇಗವಾಗಿ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ಅದೇ ರೀತಿಯಲ್ಲಿ ಪುನಃಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ - ಯಶಸ್ಸು? ನನ್ನ ಪ್ರಕಾರ, ಇದು ಸಾಕಷ್ಟು ಯಶಸ್ವಿಯಾಗಿದೆ. ಈ ಮುಖ್ಯ, ಆದ್ದರಿಂದ ನಾನು ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ - ನೀವು ಇದ್ದರೆ ನೀವು ಈ ಫೈಲ್‌ಗಳಲ್ಲಿ ಕನಿಷ್ಠ ಒಂದನ್ನಾದರೂ ಕಳೆದುಕೊಂಡರೆ, ನೀವು ಸಂಪೂರ್ಣ ಬ್ಯಾಕಪ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.

ಟ್ರೇಸ್ ಫ್ಲ್ಯಾಗ್‌ಗಳು 3213 ಮತ್ತು 3605 ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರದರ್ಶಿಸಲಾದ ಬ್ಯಾಕಪ್ ಮಾಹಿತಿಯಲ್ಲಿ ನೀವು ಲಾಗ್‌ನಲ್ಲಿ ನೋಡಿದರೆ, ಹಲವಾರು ಸಾಧನಗಳಿಗೆ ಬ್ಯಾಕಪ್ ಮಾಡುವಾಗ, ಕನಿಷ್ಠ BUFFERCOUNT ಸಂಖ್ಯೆ ಹೆಚ್ಚಾಗುವುದನ್ನು ನೀವು ಗಮನಿಸಬಹುದು. ಬಹುಶಃ, ನೀವು BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE ಗಾಗಿ ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ನಿಯತಾಂಕಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಬಹುದು, ಆದರೆ ನಾನು ಈಗಿನಿಂದಲೇ ಯಶಸ್ವಿಯಾಗಲಿಲ್ಲ, ಮತ್ತು ಅಂತಹ ಪರೀಕ್ಷೆಯನ್ನು ಮತ್ತೊಮ್ಮೆ ಕೈಗೊಳ್ಳಲು ನಾನು ತುಂಬಾ ಸೋಮಾರಿಯಾಗಿದ್ದೆ, ಆದರೆ ಬೇರೆ ಸಂಖ್ಯೆಯ ಫೈಲ್‌ಗಳಿಗಾಗಿ. ಮತ್ತು ಇದು ಚಕ್ರಗಳ ಬಗ್ಗೆ ನಾಚಿಕೆಗೇಡಿನ ಸಂಗತಿಯಾಗಿದೆ. ನೀವು ಮನೆಯಲ್ಲಿ ಅಂತಹ ಪರೀಕ್ಷೆಯನ್ನು ಆಯೋಜಿಸಲು ಬಯಸಿದರೆ, ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರೀಮೇಕ್ ಮಾಡುವುದು ಕಷ್ಟವೇನಲ್ಲ.

ಅಂತಿಮವಾಗಿ, ಬೆಲೆಯ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ. ಬಳಕೆದಾರರ ಕೆಲಸಕ್ಕೆ ಸಮಾನಾಂತರವಾಗಿ ಬ್ಯಾಕಪ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿದರೆ, ನೀವು ಪರೀಕ್ಷೆಗೆ ಬಹಳ ಜವಾಬ್ದಾರಿಯುತ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಬ್ಯಾಕಪ್ ಅನ್ನು ವೇಗವಾಗಿ ತೆಗೆದುಹಾಕಿದರೆ, ಡಿಸ್ಕ್ಗಳು ಹೆಚ್ಚು ಒತ್ತಡಕ್ಕೊಳಗಾಗುತ್ತವೆ, ಪ್ರೊಸೆಸರ್ನಲ್ಲಿನ ಲೋಡ್ ಹೆಚ್ಚಾಗುತ್ತದೆ (ನೀವು ಇನ್ನೂ ಸಂಕುಚಿತಗೊಳಿಸಬೇಕು ಅದು ಹಾರಾಡುತ್ತ), ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ವ್ಯವಸ್ಥೆಯ ಒಟ್ಟಾರೆ ಪ್ರತಿಕ್ರಿಯೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ.

ತಮಾಷೆಗಾಗಿ, ಆದರೆ ನಾನು ಯಾವುದೇ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯನ್ನು ಮಾಡಿಲ್ಲ ಎಂದು ನಾನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ನೀವು ಸೂಕ್ತವಾದ ನಿಯತಾಂಕಗಳನ್ನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡಬಹುದು ಎಂಬುದರ ಪ್ರದರ್ಶನವನ್ನು ಮೇಲೆ ಬರೆಯಲಾಗಿದೆ.

ನೀವು ಮಾಡುವ ಎಲ್ಲವನ್ನೂ ನಿಮ್ಮ ಸ್ವಂತ ಗಂಡಾಂತರ ಮತ್ತು ಅಪಾಯದಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ನಿಮ್ಮ ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು DBCC CHECKDB ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ.

ಮೂಲ: www.habr.com