Best way to back up one big and 4 small databases parallel?

[hbw]

Hello
We are migrating our datawarehouse infrastructure, and there is a new schedule to do the backup. It's no API backup, and the dbas don't work witch archive-logs.
We do consistent san-snapshots of the db-LUNs and mount them to a dedicated backup-server. So I've a lot of mounted folders with the database-files, each file is between 50 and 450 gb, and I have to bring this data to tape, as fast as possible. The problem is not to backup 10 folders and the db-files in this folders in one job, that works.
My problem is to find out, which are the best settings for mountpoints ans ressourceutilisation, because now the job ends with RC8 or RC4 because of errors withe the ressources (ressourceutil ,mountpoints, threads)

There are 4 databases (database-files, db not online), and I have to do it parallel, because the dbas will work with this dbs after backup. So I have just one night to backup the data. 3 of the dbs are 500 gb, but the great one ist 14 tb. As infrastructure I use an Eternus VTL and there are 16 drives exclusive for this server. There are two hbas for lanfree backup, and 8/16 gbit san. Cache, RAM and CPU are no Problem, it's a "powerfull" server. With 8 -10 drives parallel I can backup roundabout 500 mb/sec without problems. The parallel backup of the small dbs work without problems, each takes one ore two drives per db and I can do backup of this three dbs parallel.
If I start a backup of all 4 dbs, the server runs out of ressources. because the big don't get enough drives.

Is it possible to restrict the ressources for the smal dbs and to determine that the big db takes at least 6 drives?

Any ideas what the optimal settings for ressourceutilisation, max number of mountpoints etc. for this constellation?
Thanks in advance

 

[marclant]

My problem is to find out, which are the best settings for mountpoints ans ressourceutilisation, because now the job ends with RC8 or RC4 because of errors withe the ressources (ressourceutil ,mountpoints, threads)

First need to fix this, RC4 and RC8 are just schedule return codes, means it completed with warnings or errors. Check the dsmsched.log and dsmerror.log to see what they were. Once you identify the errors, you can get more info on these errors in the InfoCenter: http://www.ibm.com/support/knowledg...m.msgs.client.doc/msgs_client_list_intro.html

If the help and Google don't give you enough info to fix those errors, paste the errors you see in the dsmerror.log here.

Is it possible to restrict the ressources for the smal dbs and to determine that the big db takes at least 6 drives?

Not if you back it up in a single schedule, but if you use multiple schedules you can, you would need:
2 nodes (one for big, one for many small)
each their own dsm.opt and corresponding stanza with options for resourceutil with the desired value
2 schedulers or CAD/schedulers running, one for each
2 schedules, one for each node and the schedule would need to include the object option to specify which path to backup.

Alternatively, you could schedule a script to run, and include with something like:
dsmc inc /path/bigdb/* -resourceutil=X
dsmc inc /path/smalldbs/* -resourceutil=Y

 

[marclant]

but the great one ist 14 tb.

Is that 14TB in a single file or multiple file?

I hope multiple for a couple reasons:
- if there is a problem during the backup and it retries, it won't need to resend the entire big file, just the last chunk it was sending
- you can do multiple sessions (resourceutil>2) with multiple files, but not with a single large file.

 

[hbw]

All files are in the backup. The RC 4 ="max number of mountpoints"

RC8=
26.04.2016 12:02:29 ANS0361I DIAG: Maximum number of threads exceeded.
26.04.2016 12:02:29 ANS0361I DIAG: cuIdentifyResp(): Error -72 receiving IdentifyResp
26.04.2016 12:02:29 ANS9201W LAN-free path failed.

If I reduce the number of mountpoints the RC8 messages is gone. We're using Automic (UC4) as scheduling tool, and the boys in the operating aren't amused to investigate where there were errors. Also it takes twice the time to backup the data :-(

Yes, it should be one single schedule. My idea was to start the big db after backing up the small dbs, but the operating won't do so. It's because they have to do a lot of scripting to ensure that the backup of the 3 smal dbs is finished, and that it was faultless before the backup of the big one starts. They want to keep it simple.

The gread db: d:\oracle\oradata\dbname\"bd001-00" , "bd001-01", -02...-10. The folders "bd-001-xx" are mountpoints, each of these folders contains 10 - 15 db files, and each folder is 1,4 tb.


I think I try to use this

Alternatively, you could schedule a script to run, and include with something like:
dsmc inc /path/bigdb/* -resourceutil=X
dsmc inc /path/smalldbs/* -resourceutil=Y

because it seems to be the easiest way to devide the ressources.

Last question:
If I use two nodes to backup the data, do I have to create a second storageagent for this server to do lanfree backup?

 

[marclant]

If I reduce the number of mountpoints the RC8 messages is gone.

You could increase MAXNUMMP for that node, if you have enough drives to handle it.

 

[marclant]

If I use two nodes to backup the data, do I have to create a second storageagent for this server to do lanfree backup?

You can use the same STA.