This makes for a clean way to push out common scripts or code, maintenance tasks,
and so on. The jobs themselves, although defined on the master server, are executed on the target
server. You can also set up target server groups to filter which servers get which jobs.
That being said, the target server cannot change the configuration of a job. The frequent checking
for new schedules can put a bit of a load on the master job server in a large environment, but in those
cases, that SQL Server instance wouldn??™t be doing much other than centralizing jobs.
One word of caution: you may want to use the master job server as a way to push out scripts
that create local jobs on the target servers. I??™ve had a few bad experiences with certain types of jobs
in this configuration under SQL Server 7.0 and 2000. I haven??™t seen anything unusual with SQL
Server 2005, though.
CHAPTER 5 n CREATING A BACKUP/RECOVERY PLAN 123
Base BRPs
As I mentioned previously, disaster recovery planning of any kind, including basic
backup/restore schemes, should be an iterative process. The first step in designing
a backup/recovery plan should be coming up with a basic, bare-bones, meets-therequirements
approach and then enhancing it from that point on.
Pages:
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252