Table 6 - Online Dump Of Inactive Database With Arcserve - Compaq 219700-001 - ProLiant - 1500 White Paper

Compaq Backup and Recovery for Microsoft SQL Server 6.x
75% of
Maximum

Table 6 - Online Dump of Inactive Database with ARCserve

Transactions Before Dump
Transaction
Rate:
No User
Transactions
25% of
Maximum
75% of
Maximum
When dumping an inactive database with SQL Server, the user transactions per second throughput (to
the active database) and the average transaction response times do not change considerably under either
of the load conditions. The fact that we have isolated our two databases on separate disk arrays helps
to produce this situation - I/O requests from the backup job do not interfere with user transaction I/O.
The dump throughput, while it remained unaffected during the moderate (25%) user load condition,
dropped from 9.1 GB/hr (maximum dump throughput achieved with 2 DLT drives with no user
activity) to 6.6 GB/hr under the high (75%) load. Here, the dump threads compete with other SQL
Server threads processing user transactions against another database. Since no artificial bottleneck is
imposed on any of the user transactions, SQL Server schedules them equally with the threads
performing the dump operation. SQL Server can have as many worker threads as there are users, up to
a certain limit, which, once reached, causes user connections to share a worker thread. Naturally, the
two dump threads receive only a fraction of the execution time, resulting in low backup throughput
when a high user load is present. With a lighter user load, backup throughput does not suffer because
there is enough CPU time for all threads (in Table 5, CPU usage is at 32% during the dump with light
load, vs. 80% for the heavy load). Note that the results may be somewhat different if you are dumping
to a greater number of backup devices, in which case there will be a greater number of backup threads.
When doing the ARCserve assisted dump, the results for the moderate user load condition are the same
(neither user transaction throughput nor backup throughput are affected), but the results for the heavy
load condition are a bit different: The user transaction rate dropped from 75% of the maximum
throughput to 44% of max, and the average response times increased about 19 times. The backup
throughput on the other hand, only dropped from 10.0 to 9.3 GB/hr.
Here, the SQL Server user transaction threads must compete with ARCserve application threads which
are external to SQL Server. Since we have the SMP Stat parameter set to 0, Windows NT will move
SQL Server threads off of one of the CPU's to make room for other applications' threads when the
CPU's near saturation (Table 6 shows CPU usage at 99% in this case). When SQL threads are
deprived of some time on this CPU, user transactions are affected. If we had set SMP Stat to 2 or -1,
the user transactions would not have been affected, but the ARCserve backup process would have
suffered or even halted entirely (see discussion on SMP Stat earlier in this section).
From our results we can make the following general conclusions about backup of an inactive database
during activity on another database: Neither the backup throughput nor the transaction throughput will
be affected as long as there is adequate CPU time to service all threads and I/O is separated. If CPU
usage becomes high however, the backup throughput will suffer (with the SQL Server dump
¤
1997 Compaq Computer Corporation, All Rights Reserved
.15 sec ~70% 75% of
Maximum
Response CPU Transaction
Time: Usage: Rate:
n/a ~ 0% No User
Transactions
.12 sec ~26% 25% of
Maximum
.15 sec ~70% 44% of
Maximum
0.17 sec ~80%
Transactions During Dump
Response CPU
Time: Usage:
n/a ~ 60%
0.13 sec ~80%
2.90 sec ~99%
Page 65
6.6 GB/hour
Dump
Throughput:
10.0 GB/hour
10.0 GB/hour
9.3 GB/hour
Doc No 444A/0797