Restore - THREADPRIORITY vs Backup - THREADCOUNT

Dje

Hi,

It exists in the backup command the option THREADCOUNT but not in the restore command.
In the restore command it only exists a THREADPRIORITY option.

Does the restore command automatically use the maximum number of threads possible ?
Is the restore command using the same number of threads as used to backup the DB ?
How could we optimise the restore of a DB ?

Thanks in advance for your replies,
Jerome

petey

The restore uses the same number of threads as that used during the backup.

Dje

Your answer makes me wondering the following :
Could this lead to a CPU (ressources in general) overflow on our development servers if we optimise our backups on production servers where we have more processors than on development ?
How is SQL Backup handling this ?

petey

When you create a backup using the THREADCOUNT option, say using a value of 4, SQL Backup is receiving backup data from SQL Server for 4 'backup files'. However, SQL Backup consolidates the compressed backup data for these 4 'files', and stores them on a single file.

During the restore process, SQL Server will expect to receive data from 4 separate 'files', which SQL Backup will need to provide. Each of these 4 'files' will be handled by a separate thread. If the number of processors on your system is less than the number of restore threads, there will be more frequent context switching on each processor, which will affect throughput.

>> How is SQL Backup handling this ?
SQL Backup has no choice but to create the same number of restore threads internally to service each of SQL Server's restore thread.

Dje

Thanks Petey.