30.06.2013 Views

SQL Server Backup and Restore - Simple Talk

SQL Server Backup and Restore - Simple Talk

SQL Server Backup and Restore - Simple Talk

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 8: Database <strong>Backup</strong> <strong>and</strong> <strong>Restore</strong> with <strong>SQL</strong> <strong>Backup</strong> Pro<br />

• HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\<strong>SQL</strong> <strong>Backup</strong>\<br />

<strong>Backup</strong>SettingsGlobal\\MAXTRANSFERSIZE (32-bit)<br />

• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Red Gate\<strong>SQL</strong> <strong>Backup</strong>\<br />

<strong>Backup</strong>SettingsGlobal\\MAXTRANSFERSIZE (64-bit)<br />

The maximum data block option (by default 2 MB) determines the size of the actual data<br />

blocks on disk, when storing backup data. For optimal performance, we want this value<br />

to match or fit evenly in the block size of the media to which the files are being written;<br />

if the data block sizes overlap the media block boundaries, it may result in performance<br />

degradation. Generally speaking, <strong>SQL</strong> <strong>Server</strong> will automatically select the correct block<br />

size based on the media.<br />

However, if necessary, we can create a registry entry to overwrite the default value:<br />

• HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\<strong>SQL</strong> <strong>Backup</strong>\<br />

<strong>Backup</strong>SettingsGlobal\\MAXDATABLOCK (32-bit)<br />

• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Red Gate\<strong>SQL</strong> <strong>Backup</strong>\<br />

<strong>Backup</strong>SettingsGlobal\\MAXDATABLOCK (64-bit)<br />

The network resilience options determine how long to wait before retrying a failed<br />

backup operation, <strong>and</strong> how many times to retry; when the retry count has been<br />

exhausted, a failure message will be issued. We want to be able to retry a failed backup<br />

a few times, but we don't want to retry so many times that a problem in the network or<br />

disk subsystem is masked for too long; in other words, rather than extend the backup<br />

operation as it retries again <strong>and</strong> again, it's better to retry only a few times <strong>and</strong> then fail,<br />

therefore highlighting the network issue. This is especially true when performing full<br />

backup operations on large databases, where we'll probably want to knock that retry<br />

count down from a default of 10 to 2–3 times. Transaction log backups, on the other<br />

h<strong>and</strong>, are typically a short process, so retrying 10 times is not an unreasonable number in<br />

this case.<br />

249

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!