MS SQL ਸਰਵਰ: ਸਟੀਰੌਇਡ 'ਤੇ ਬੈਕਅੱਪ

ਉਡੀਕ ਕਰੋ! ਉਡੀਕ ਕਰੋ! ਇਹ ਸੱਚ ਹੈ ਕਿ ਇਹ SQL ਸਰਵਰ ਬੈਕਅੱਪ ਦੀਆਂ ਕਿਸਮਾਂ ਬਾਰੇ ਕੋਈ ਹੋਰ ਲੇਖ ਨਹੀਂ ਹੈ। ਮੈਂ ਰਿਕਵਰੀ ਮਾਡਲਾਂ ਵਿੱਚ ਅੰਤਰ ਅਤੇ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੌਗ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਣਾ ਹੈ ਬਾਰੇ ਵੀ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗਾ।

ਸ਼ਾਇਦ (ਸਿਰਫ਼ ਸ਼ਾਇਦ), ਇਸ ਪੋਸਟ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੇ ਯੋਗ ਹੋਵੋਗੇ ਕਿ ਸਟੈਂਡਰਡ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਹਾਡੇ ਤੋਂ ਹਟਾਏ ਗਏ ਬੈਕਅੱਪ ਨੂੰ ਕੱਲ ਰਾਤ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ, ਠੀਕ ਹੈ, 1.5 ਗੁਣਾ ਤੇਜ਼ੀ ਨਾਲ. ਅਤੇ ਸਿਰਫ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਤੁਸੀਂ ਥੋੜੇ ਹੋਰ ਬੈਕਅੱਪ ਡੇਟਾਬੇਸ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ.

ਜੇਕਰ ਪੋਸਟ ਦੀ ਸਮਗਰੀ ਤੁਹਾਡੇ ਲਈ ਸਪੱਸ਼ਟ ਸੀ, ਤਾਂ ਮੈਨੂੰ ਅਫਸੋਸ ਹੈ। ਮੈਂ ਉਹ ਸਭ ਕੁਝ ਪੜ੍ਹਿਆ ਜੋ ਗੂਗਲ ਨੂੰ "habr sql ਸਰਵਰ ਬੈਕਅਪ" ਵਾਕੰਸ਼ ਲਈ ਮਿਲਿਆ, ਅਤੇ ਇੱਕ ਵੀ ਲੇਖ ਵਿੱਚ ਮੈਨੂੰ ਇਸ ਤੱਥ ਦਾ ਕੋਈ ਜ਼ਿਕਰ ਨਹੀਂ ਮਿਲਿਆ ਕਿ ਬੈਕਅਪ ਸਮਾਂ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਸੇ ਤਰ੍ਹਾਂ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ.

ਮੈਂ ਤੁਰੰਤ ਤੁਹਾਡਾ ਧਿਆਨ ਅਲੈਗਜ਼ੈਂਡਰ ਗਲੈਡਚੇਨਕੋ ਦੀ ਟਿੱਪਣੀ ਵੱਲ ਖਿੱਚਾਂਗਾ (@mssqlhelp):

ਉਤਪਾਦਨ ਵਿੱਚ ਕਦੇ ਵੀ BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਨਾ ਬਦਲੋ। ਉਹ ਅਜਿਹੇ ਲੇਖ ਲਿਖਣ ਲਈ ਹੀ ਬਣਾਏ ਗਏ ਹਨ। ਅਭਿਆਸ ਵਿੱਚ, ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਸਮੇਂ ਵਿੱਚ ਯਾਦਦਾਸ਼ਤ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਓਗੇ.

ਇਹ, ਬੇਸ਼ੱਕ, ਸਭ ਤੋਂ ਚੁਸਤ ਅਤੇ ਪੋਸਟ ਨਿਵੇਕਲੀ ਸਮੱਗਰੀ ਹੋਣ ਲਈ ਠੰਡਾ ਹੋਵੇਗਾ, ਪਰ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਇਸ ਵਿਸ਼ੇ ਨੂੰ ਸਮਰਪਿਤ ਅੰਗ੍ਰੇਜ਼ੀ-ਭਾਸ਼ਾ ਅਤੇ ਰੂਸੀ-ਭਾਸ਼ਾ ਦੇ ਲੇਖ/ਪੋਸਟਾਂ (ਮੈਂ ਹਮੇਸ਼ਾ ਉਲਝਣ ਵਿੱਚ ਰਹਿੰਦਾ ਹਾਂ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕੀ ਕਹਿਣਾ ਹੈ)। ਇੱਥੇ ਕੁਝ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮੈਂ ਮਿਲਿਆ ਹਾਂ: ਵਾਰ, два, ਤਿੰਨ (sql.ru 'ਤੇ).

ਇਸ ਲਈ, ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਮੈਂ ਇਸ ਤੋਂ ਥੋੜ੍ਹਾ ਜਿਹਾ ਸਟ੍ਰਿਪਡ-ਡਾਊਨ ਬੈਕਅੱਪ ਸੰਟੈਕਸ ਨੱਥੀ ਕਰਾਂਗਾ MSDN (ਵੈਸੇ, ਮੈਂ ਉੱਪਰ ਬੈਕਅੱਪ ਡੇਟਾਬੇਸ ਬਾਰੇ ਲਿਖਿਆ ਹੈ, ਪਰ ਇਹ ਸਭ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਬੈਕਅੱਪ ਅਤੇ ਡਿਫਰੈਂਸ਼ੀਅਲ ਬੈਕਅੱਪ ਦੋਵਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਪਰ ਸ਼ਾਇਦ ਘੱਟ ਸਪੱਸ਼ਟ ਪ੍ਰਭਾਵ ਨਾਲ):

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 } - ਬਾਈਟਾਂ ਵਿੱਚ ਭੌਤਿਕ ਬਲਾਕ ਦਾ ਆਕਾਰ ਦਰਸਾਉਂਦਾ ਹੈ। ਸਮਰਥਿਤ ਆਕਾਰ 512, 1024, 2048, 4096, 8192, 16, 384, ਅਤੇ 32 ਬਾਈਟਸ (768 KB) ਹਨ। ਟੇਪ ਡਿਵਾਈਸਾਂ ਲਈ ਡਿਫੌਲਟ ਮੁੱਲ 65 ਅਤੇ ਹੋਰ ਡਿਵਾਈਸਾਂ ਲਈ 536 ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਪੈਰਾਮੀਟਰ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਬੈਕਅੱਪ ਸਟੇਟਮੈਂਟ ਆਪਣੇ ਆਪ ਡਿਵਾਈਸ ਲਈ ਢੁਕਵੇਂ ਬਲਾਕ ਆਕਾਰ ਦੀ ਚੋਣ ਕਰਦੀ ਹੈ। ਬਲਾਕ ਦਾ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਆਟੋਮੈਟਿਕ ਬਲਾਕ ਆਕਾਰ ਚੋਣ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਓਵਰਰਾਈਡ ਕਰਦਾ ਹੈ।

ਬਫਰਕਾਊਂਟ = { ਬਫਰਕਾਉਂਟ | @ buffercount_variable } - I/O ਬਫਰਾਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਬੈਕਅੱਪ ਕਾਰਵਾਈ ਲਈ ਵਰਤੇ ਜਾਣਗੇ। ਤੁਸੀਂ ਕੋਈ ਵੀ ਸਕਾਰਾਤਮਕ ਪੂਰਨ ਅੰਕ ਮੁੱਲ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ Sqlservr.exe ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਰਚੁਅਲ ਐਡਰੈੱਸ ਸਪੇਸ ਦੇ ਕਾਰਨ ਬਫਰਾਂ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ ਇੱਕ ਆਊਟ-ਆਫ-ਮੈਮੋਰੀ ਗਲਤੀ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ।

ਬਫਰਾਂ ਦੁਆਰਾ ਵਰਤੀ ਗਈ ਸਪੇਸ ਦੀ ਕੁੱਲ ਮਾਤਰਾ ਹੇਠਾਂ ਦਿੱਤੇ ਫਾਰਮੂਲੇ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ: BUFFERCOUNT * MAXTRANSFERSIZE.

ਅਧਿਕਤਮ ਟ੍ਰਾਂਸਫਰਸਾਈਜ਼ = { maxtransfersize | @ maxtransfersize_variable } SQL ਸਰਵਰ ਅਤੇ ਬੈਕਅੱਪ ਸੈੱਟ ਮੀਡੀਆ ਵਿਚਕਾਰ ਵਟਾਂਦਰਾ ਕਰਨ ਲਈ, ਬਾਈਟਾਂ ਵਿੱਚ, ਸਭ ਤੋਂ ਵੱਡੇ ਡੇਟਾ ਪੈਕੇਟ ਦਾ ਆਕਾਰ ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ। 65 ਬਾਈਟ (536 MB) ਤੱਕ 64 ਬਾਈਟਸ (4 KB) ਦੇ ਮਲਟੀਪਲ ਸਮਰਥਿਤ ਹਨ।

ਮੈਂ ਸਹੁੰ ਖਾਂਦਾ ਹਾਂ - ਮੈਂ ਇਸਨੂੰ ਪਹਿਲਾਂ ਪੜ੍ਹਿਆ ਹੈ, ਪਰ ਇਹ ਮੈਨੂੰ ਕਦੇ ਨਹੀਂ ਆਇਆ ਕਿ ਉਹਨਾਂ ਦਾ ਉਤਪਾਦਕਤਾ 'ਤੇ ਕਿੰਨਾ ਪ੍ਰਭਾਵ ਪੈ ਸਕਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜ਼ਾਹਰ ਤੌਰ 'ਤੇ, ਮੈਨੂੰ ਇਕ ਕਿਸਮ ਦਾ "ਬਾਹਰ ਆਉਣਾ" ਅਤੇ ਇਹ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਹੁਣ ਵੀ ਮੈਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਝ ਨਹੀਂ ਆਉਂਦੀ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰ ਰਹੇ ਹਨ. ਮੈਨੂੰ ਸ਼ਾਇਦ ਬਫਰ ਕੀਤੇ I/O ਅਤੇ ਹਾਰਡ ਡਰਾਈਵ ਨਾਲ ਕੰਮ ਕਰਨ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੈ। ਕਿਸੇ ਦਿਨ ਮੈਂ ਇਹ ਕਰਾਂਗਾ, ਪਰ ਹੁਣ ਲਈ ਮੈਂ ਸਿਰਫ਼ ਇੱਕ ਸਕ੍ਰਿਪਟ ਲਿਖ ਸਕਦਾ ਹਾਂ ਜੋ ਇਹ ਜਾਂਚ ਕਰੇਗਾ ਕਿ ਇਹ ਮੁੱਲ ਬੈਕਅੱਪ ਲੈਣ ਦੀ ਗਤੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ.

ਮੈਂ ਇੱਕ ਛੋਟਾ ਡੇਟਾਬੇਸ ਬਣਾਇਆ, ਲਗਭਗ 10 GB ਦਾ ਆਕਾਰ, ਇਸਨੂੰ SSD 'ਤੇ ਪਾ ਦਿੱਤਾ, ਅਤੇ HDD 'ਤੇ ਬੈਕਅੱਪ ਲਈ ਡਾਇਰੈਕਟਰੀ ਪਾ ਦਿੱਤੀ।

ਮੈਂ ਨਤੀਜਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ ਅਸਥਾਈ ਸਾਰਣੀ ਬਣਾਉਂਦਾ ਹਾਂ (ਮੇਰੇ ਕੋਲ ਇਹ ਅਸਥਾਈ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਮੈਂ ਨਤੀਜਿਆਂ ਨੂੰ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਖੋਜ ਸਕਦਾ ਹਾਂ, ਪਰ ਤੁਸੀਂ ਆਪਣੇ ਲਈ ਫੈਸਲਾ ਕਰੋ):

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

ਜੇ ਤੁਹਾਨੂੰ ਅਚਾਨਕ ਇੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਬਾਰੇ ਸਪਸ਼ਟੀਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਲਿਖੋ ਜਾਂ ਪ੍ਰਧਾਨ ਮੰਤਰੀ. ਹੁਣ ਲਈ, ਮੈਂ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਉਹਨਾਂ ਪੈਰਾਮੀਟਰਾਂ ਬਾਰੇ ਦੱਸਾਂਗਾ ਜੋ ਮੈਂ ਬੈਕਅੱਪ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੱਖੇ ਹਨ।

BLOCKSIZE ਲਈ ਸਾਡੇ ਕੋਲ ਮੁੱਲਾਂ ਦੀ "ਬੰਦ" ਸੂਚੀ ਹੈ, ਅਤੇ ਮੈਂ BLOCKSIZE <4KB ਨਾਲ ਬੈਕਅੱਪ ਨਹੀਂ ਕੀਤਾ ਹੈ। 64KB ਤੱਕ - 64KB ਤੋਂ 4MB ਤੱਕ - ਕਿਸੇ ਵੀ ਸੰਖਿਆ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਟ੍ਰਾਂਸਫਰਸਾਈਜ਼ ਕਰੋ। ਮੇਰੇ ਸਿਸਟਮ 'ਤੇ ਡਿਫੌਲਟ 1024KB ਹੈ, ਮੈਂ 512 - 1024 - 2048 - 4096 ਲਿਆ.

ਇਹ BUFFERCOUNT ਨਾਲ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਸੀ - ਇਹ ਕੋਈ ਵੀ ਸਕਾਰਾਤਮਕ ਨੰਬਰ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਲਿੰਕ ਕਹਿੰਦਾ ਹੈ ਬੈਕਅੱਪ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇਸਦੀ ਗਣਨਾ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਵੱਡੇ ਮੁੱਲ ਖ਼ਤਰਨਾਕ ਕਿਉਂ ਹਨ?. ਇਹ ਇਹ ਵੀ ਕਹਿੰਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਸ BUFFERCOUNT ਨਾਲ ਬੈਕਅੱਪ ਬਣਾਇਆ ਗਿਆ ਹੈ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਵੇ - ਮੇਰੇ ਲਈ ਇਹ 7 ਹੈ. ਇਸ ਨੂੰ ਘਟਾਉਣ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਸੀ, ਅਤੇ ਉਪਰਲੀ ਸੀਮਾ ਨੂੰ ਪ੍ਰਯੋਗਾਤਮਕ ਤੌਰ 'ਤੇ ਖੋਜਿਆ ਗਿਆ ਸੀ - BUFFERCOUNT = 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 MB/ਸੈਕੰਡ) ਵਿੱਚ 157.227 ਪੰਨਿਆਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ।

ਸਕ੍ਰਿਪਟ ਖੁਦ, ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਜਾਂਚ ਕਰ ਰਹੀ ਹੈ, ਕੁਝ ਘੰਟਿਆਂ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ, ਸਾਰੇ ਮਾਪ ਅੰਦਰ ਸਨ ਗੂਗਲ ਸਪ੍ਰੈਡਸ਼ੀਟ. ਅਤੇ ਇੱਥੇ ਤਿੰਨ ਵਧੀਆ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਿਆਂ ਦੇ ਨਾਲ ਨਤੀਜਿਆਂ ਦੀ ਇੱਕ ਚੋਣ ਹੈ (ਮੈਂ ਇੱਕ ਵਧੀਆ ਗ੍ਰਾਫ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪਰ ਪੋਸਟ ਵਿੱਚ ਮੈਨੂੰ ਇੱਕ ਸਾਰਣੀ ਨਾਲ ਕਰਨਾ ਪਏਗਾ, ਅਤੇ ਟਿੱਪਣੀਆਂ ਵਿੱਚ @mixsture ਜੋੜਿਆ ਗਿਆ ਬਹੁਤ ਵਧੀਆ ਗਰਾਫਿਕਸ).

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;

ਧਿਆਨ, ਇੱਕ ਬਹੁਤ ਹੀ ਮਹੱਤਵਪੂਰਨ ਨੋਟ @mixsture ਤੱਕ ਟਿੱਪਣੀ:

ਅਸੀਂ ਭਰੋਸੇ ਨਾਲ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਮੁੱਲਾਂ ਦੀਆਂ ਇਹਨਾਂ ਰੇਂਜਾਂ ਦੇ ਅੰਦਰ ਪੈਰਾਮੀਟਰਾਂ ਅਤੇ ਬੈਕਅੱਪ ਸਪੀਡ ਵਿਚਕਾਰ ਸਬੰਧ ਬੇਤਰਤੀਬ ਹੈ, ਕੋਈ ਪੈਟਰਨ ਨਹੀਂ ਹੈ। ਪਰ ਬਿਲਟ-ਇਨ ਪੈਰਾਮੀਟਰਾਂ ਤੋਂ ਦੂਰ ਜਾਣ ਨਾਲ ਨਤੀਜੇ 'ਤੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਚੰਗਾ ਪ੍ਰਭਾਵ ਪਿਆ

ਉਹ. ਸਿਰਫ਼ ਮਿਆਰੀ ਬੈਕਅੱਪ ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਨਾਲ ਬੈਕਅੱਪ ਹਟਾਉਣ ਦੇ ਸਮੇਂ ਵਿੱਚ 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 MB/ਸੈਕੰਡ) ਵਿੱਚ 205.141 ਪੰਨਿਆਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ।

ਹੁਣ ਮੈਂ ਬਦਲੇ ਹੋਏ BLOCKSIZE, BUFFERCOUNT ਅਤੇ MAXTRANSFERSIZE ਨਾਲ ਲਏ ਗਏ ਬੈਕਅੱਪਾਂ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ।

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

ਰੀਸਟੋਰ ਡੇਟਾਬੇਸ ਨੇ 1070074 ਸਕਿੰਟਾਂ (32.283 MB/ਸੈਕੰਡ) ਵਿੱਚ 258.958 ਪੰਨਿਆਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ।

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

ਰੀਸਟੋਰ ਡੇਟਾਬੇਸ ਨੇ 1070074 ਸਕਿੰਟਾਂ (32.682 MB/ਸੈਕੰਡ) ਵਿੱਚ 255.796 ਪੰਨਿਆਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ।

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

ਰੀਸਟੋਰ ਡੇਟਾਬੇਸ ਨੇ 1070074 ਸਕਿੰਟਾਂ (32.091 MB/ਸੈਕੰਡ) ਵਿੱਚ 260.507 ਪੰਨਿਆਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ।

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

ਰੀਸਟੋਰ ਡੇਟਾਬੇਸ ਨੇ 1070074 ਸਕਿੰਟਾਂ (32.401 MB/ਸੈਕੰਡ) ਵਿੱਚ 258.015 ਪੰਨਿਆਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ।

ਰੀਸਟੋਰ ਡੇਟਾਬੇਸ ਸਟੇਟਮੈਂਟ ਰਿਕਵਰੀ ਦੇ ਦੌਰਾਨ ਨਹੀਂ ਬਦਲਦੀ ਹੈ; ਇਹ ਪੈਰਾਮੀਟਰ ਇਸ ਵਿੱਚ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ; SQL ਸਰਵਰ ਖੁਦ ਉਹਨਾਂ ਨੂੰ ਬੈਕਅੱਪ ਤੋਂ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਰਿਕਵਰੀ ਦੇ ਨਾਲ ਵੀ ਇੱਕ ਲਾਭ ਹੋ ਸਕਦਾ ਹੈ - ਲਗਭਗ 20% ਤੇਜ਼ੀ ਨਾਲ (ਇਮਾਨਦਾਰ ਹੋਣ ਲਈ, ਮੈਂ ਰਿਕਵਰੀ 'ਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਨਹੀਂ ਲਗਾਇਆ, ਮੈਂ ਕਈ "ਸਭ ਤੋਂ ਤੇਜ਼" ਬੈਕਅੱਪਾਂ ਵਿੱਚੋਂ ਲੰਘਿਆ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਕਿ ਕੋਈ ਖਰਾਬੀ ਨਹੀਂ ਸੀ).

ਸਿਰਫ਼ ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਮੈਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਦਿਓ ਕਿ ਇਹ ਕੁਝ ਮਾਪਦੰਡ ਨਹੀਂ ਹਨ ਜੋ ਹਰੇਕ ਲਈ ਅਨੁਕੂਲ ਹਨ। ਤੁਸੀਂ ਸਿਰਫ ਟੈਸਟ ਕਰਕੇ ਆਪਣੇ ਲਈ ਅਨੁਕੂਲ ਮਾਪਦੰਡ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਮੈਨੂੰ ਇਹ ਨਤੀਜੇ ਮਿਲੇ ਹਨ, ਤੁਸੀਂ ਵੱਖੋ ਵੱਖਰੇ ਪ੍ਰਾਪਤ ਕਰੋਗੇ. ਪਰ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਬੈਕਅੱਪ ਨੂੰ "ਟਿਊਨ" ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਉਹ ਅਸਲ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਬਣ ਸਕਦੇ ਹਨ ਅਤੇ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹਨ।

ਮੈਂ ਇਹ ਵੀ ਜ਼ੋਰਦਾਰ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਸਿਸਟਮ ਲਈ ਖਾਸ ਸੂਖਮਤਾਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।

ਜਦੋਂ ਤੋਂ ਮੈਂ ਬੈਕਅੱਪ ਬਾਰੇ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਹੈ, ਮੈਂ ਤੁਰੰਤ ਇੱਕ ਹੋਰ "ਓਪਟੀਮਾਈਜੇਸ਼ਨ" ਬਾਰੇ ਲਿਖਣਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਜੋ ਕਿ "ਟਿਊਨਿੰਗ" ਪੈਰਾਮੀਟਰਾਂ ਨਾਲੋਂ ਵਧੇਰੇ ਆਮ ਹੈ (ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, ਇਹ ਘੱਟੋ ਘੱਟ ਕੁਝ ਬੈਕਅੱਪ ਉਪਯੋਗਤਾਵਾਂ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਸ਼ਾਇਦ ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਨਾਲ। ਪਹਿਲਾਂ ਵਰਣਿਤ ਕੀਤਾ ਗਿਆ ਹੈ), ਪਰ ਇਸ ਦਾ ਅਜੇ ਤੱਕ ਹਾਬਰੇ 'ਤੇ ਵੀ ਵਰਣਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਜੇਕਰ ਅਸੀਂ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਦੂਜੀ ਲਾਈਨ ਨੂੰ ਵੇਖਦੇ ਹਾਂ, ਬੈਕਅੱਪ ਡੇਟਾਬੇਸ ਦੇ ਬਿਲਕੁਲ ਹੇਠਾਂ, ਉੱਥੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ:

TO <backup_device> [ ,...n ]

ਤੁਸੀਂ ਕੀ ਸੋਚਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਕਈ ਬੈਕਅੱਪ_ਡਿਵਾਈਸ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ? ਸੰਟੈਕਸ ਇਸਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਇੱਕ ਬਹੁਤ ਹੀ ਦਿਲਚਸਪ ਗੱਲ ਹੋਵੇਗੀ - ਬੈਕਅੱਪ ਕਈ ਡਿਵਾਈਸਾਂ ਵਿੱਚ "ਫੈਲਿਆ" ਜਾਵੇਗਾ। ਉਹ. ਹਰੇਕ "ਡਿਵਾਈਸ" ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਬੇਕਾਰ ਹੋ ਜਾਵੇਗਾ, ਇੱਕ ਗੁਆਚ ਜਾਵੇਗਾ, ਪੂਰਾ ਬੈਕਅੱਪ ਗੁਆ ਦਿੱਤਾ ਜਾਵੇਗਾ। ਪਰ ਅਜਿਹੇ ਸਮੀਅਰਿੰਗ ਬੈਕਅੱਪ ਸਪੀਡ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਤ ਕਰੇਗੀ?

ਆਉ ਦੋ "ਡਿਵਾਈਸਾਂ" ਤੇ ਬੈਕਅੱਪ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਜੋ ਇੱਕੋ ਫੋਲਡਰ ਵਿੱਚ ਨਾਲ-ਨਾਲ ਸਥਿਤ ਹਨ:

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

ਦੁਨੀਆਂ ਦੇ ਪਿਓ, ਅਜਿਹਾ ਕਿਉਂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ?

ਡਾਟਾਬੇਸ 'bt' ਲਈ 1070072 ਪੰਨਿਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਗਈ, ਫ਼ਾਈਲ 1 'ਤੇ 'bt' ਫ਼ਾਈਲ।

ਡਾਟਾਬੇਸ 'bt', ਫਾਈਲ 'bt' ਲਈ 2 ਪੰਨਿਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਗਈਫਾਈਲ 1 'ਤੇ ਲੌਗ ਕਰੋ।

ਬੈਕਅੱਪ ਡੇਟਾਬੇਸ ਨੇ 1070074 ਸਕਿੰਟਾਂ (40.092 MB/ਸੈਕੰਡ) ਵਿੱਚ 208.519 ਪੰਨਿਆਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ।

ਕੀ ਬੈਕਅੱਪ ਨੀਲੇ ਰੰਗ ਤੋਂ 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 MB/ਸੈਕੰਡ) ਵਿੱਚ 244.200 ਪੰਨਿਆਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ।

ਕੁੱਲ ਮਿਲਾ ਕੇ, ਲਾਭ ਬੈਕਅੱਪ ਲੈਣ ਦੇ ਸਮੇਂ ਦਾ ਲਗਭਗ 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 MB/ਸੈਕੰਡ) ਵਿੱਚ 219.842 ਪੰਨਿਆਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ।

ਥੋੜਾ ਤੇਜ਼, ਪਰ ਕਿਤੇ ਨੇੜੇ, ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ। ਆਮ ਤੌਰ 'ਤੇ, ਬੈਕਅੱਪ ਤੇਜ਼ੀ ਨਾਲ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਰੀਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਸਫਲਤਾ? ਮੇਰੇ ਲਈ, ਇਹ ਕਾਫ਼ੀ ਸਫਲਤਾ ਹੈ. ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਇਸ ਲਈ ਮੈਂ ਦੁਹਰਾਉਂਦਾ ਹਾਂ - ਜੇ ਤੁਸੀਂ ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਫਾਈਲ ਗੁਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪੂਰਾ ਬੈਕਅੱਪ ਗੁਆ ਦਿੰਦੇ ਹੋ.

ਜੇਕਰ ਤੁਸੀਂ ਟਰੇਸ ਫਲੈਗਸ 3213 ਅਤੇ 3605 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪ੍ਰਦਰਸ਼ਿਤ ਬੈਕਅੱਪ ਜਾਣਕਾਰੀ 'ਤੇ ਲੌਗ ਵਿੱਚ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵੇਖੋਗੇ ਕਿ ਜਦੋਂ ਕਈ ਡਿਵਾਈਸਾਂ ਦਾ ਬੈਕਅੱਪ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਘੱਟੋ-ਘੱਟ BUFFERCOUNT ਦੀ ਗਿਣਤੀ ਵੱਧ ਜਾਂਦੀ ਹੈ। ਸੰਭਵ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE ਲਈ ਹੋਰ ਅਨੁਕੂਲ ਮਾਪਦੰਡਾਂ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਮੈਂ ਤੁਰੰਤ ਸਫਲ ਨਹੀਂ ਹੋਇਆ, ਅਤੇ ਮੈਂ ਅਜਿਹੀ ਜਾਂਚ ਨੂੰ ਦੁਬਾਰਾ ਕਰਨ ਲਈ ਬਹੁਤ ਆਲਸੀ ਸੀ, ਪਰ ਫਾਈਲਾਂ ਦੀ ਇੱਕ ਵੱਖਰੀ ਸੰਖਿਆ ਲਈ। ਅਤੇ ਇਹ ਪਹੀਏ ਬਾਰੇ ਸ਼ਰਮ ਦੀ ਗੱਲ ਹੈ. ਜੇਕਰ ਤੁਸੀਂ ਘਰ 'ਤੇ ਅਜਿਹੇ ਟੈਸਟਿੰਗ ਦਾ ਆਯੋਜਨ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਕ੍ਰਿਪਟ ਨੂੰ ਰੀਮੇਕ ਕਰਨਾ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਆਓ ਕੀਮਤ ਬਾਰੇ ਗੱਲ ਕਰੀਏ. ਜੇ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਕੰਮ ਦੇ ਸਮਾਨਾਂਤਰ ਬੈਕਅੱਪ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਟੈਸਟਿੰਗ ਲਈ ਬਹੁਤ ਜ਼ਿੰਮੇਵਾਰ ਪਹੁੰਚ ਅਪਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਜੇ ਬੈਕਅੱਪ ਤੇਜ਼ੀ ਨਾਲ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਡਿਸਕਾਂ ਜ਼ਿਆਦਾ ਦਬਾਅ ਪਾਉਂਦੀਆਂ ਹਨ, ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਲੋਡ ਵਧਦਾ ਹੈ (ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਸੰਕੁਚਿਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇਹ ਫਲਾਈ 'ਤੇ), ਅਤੇ ਇਸ ਅਨੁਸਾਰ, ਸਿਸਟਮ ਦੀ ਸਮੁੱਚੀ ਪ੍ਰਤੀਕਿਰਿਆ ਘੱਟ ਜਾਂਦੀ ਹੈ।

ਬੱਸ ਮਜ਼ਾਕ ਕਰ ਰਿਹਾ ਹਾਂ, ਪਰ ਮੈਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਦਾ ਹਾਂ ਕਿ ਮੈਂ ਕੋਈ ਖੁਲਾਸਾ ਨਹੀਂ ਕੀਤਾ। ਉੱਪਰ ਜੋ ਲਿਖਿਆ ਗਿਆ ਹੈ ਉਹ ਸਿਰਫ਼ ਇਸ ਗੱਲ ਦਾ ਇੱਕ ਪ੍ਰਦਰਸ਼ਨ ਹੈ ਕਿ ਤੁਸੀਂ ਬੈਕਅੱਪ ਲੈਣ ਲਈ ਅਨੁਕੂਲ ਮਾਪਦੰਡ ਕਿਵੇਂ ਚੁਣ ਸਕਦੇ ਹੋ।

ਯਾਦ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਜੋ ਵੀ ਕਰਦੇ ਹੋ ਉਹ ਤੁਹਾਡੇ ਆਪਣੇ ਜੋਖਮ ਅਤੇ ਜੋਖਮ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਆਪਣੇ ਬੈਕਅੱਪ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ DBCC CHECKDB ਬਾਰੇ ਨਾ ਭੁੱਲੋ।

ਸਰੋਤ: www.habr.com