Highlighted
Absent Member.
Absent Member.
237 views

interleaving backup sessions to one device

Jump to solution
We are currently looking at moving from filesystem offline backups to rman online or offline backups for our oracle databases.

Issue is with the current settup using the oracle integration component it would mean 5-7 times the amount of tape mounts. From ~500 sessions to ~3200 sessions a week.

With a 20 drive ESL712e and 2 4 drive MSL6060 I think that will prove a problem for the hardware.

Can DP be configured to interleave backup sessions to a specific device? Currently each session get exclusive use of the number of drives specified for it.

Anyone else backing up over 200 databases to tape daily using rman throuhg DP5.5?
0 Likes
1 Solution

Accepted Solutions
Highlighted
Absent Member.
Absent Member.
Hi,

No, this is not possible. Each database must be backed up in a separate session and DP do not interleave data from different sessions.

Filesystem backups is different as several objects (filesystems) can be backed up in one session and can be interleaved by setting concurrency.

This is not the only problem with backing up a large number of databases. As every database needs a separate job you have to manage 200 schedules (or perhaps 400 if you back up transaction logs).

Some kind of group scheduling would be a nice feature.

View solution in original post

3 Replies
Highlighted
Absent Member.
Absent Member.
Hi!

I haven't set up so many databases to tape but to disk it's ok. One session writes to one or more devices depending if it's load balanced or not. You can't have two session writing to the same device at one time. But when you say that each session takes use of x number of drives is that wrong? If you loadbalance say min=2 and max=5 and you specify 5 devices as possible to write to the session will start writing as soon there's 2 available devices and can use up to 5 if it's necessay and possible.

//Mats
0 Likes
Highlighted
Absent Member.
Absent Member.
Hi,

No, this is not possible. Each database must be backed up in a separate session and DP do not interleave data from different sessions.

Filesystem backups is different as several objects (filesystems) can be backed up in one session and can be interleaved by setting concurrency.

This is not the only problem with backing up a large number of databases. As every database needs a separate job you have to manage 200 schedules (or perhaps 400 if you back up transaction logs).

Some kind of group scheduling would be a nice feature.

View solution in original post

Highlighted
Absent Member.
Absent Member.
Thanks for the info. Load balancing is great if you've got one massive backup and loads of tape. We've found when the objects are not well balanced i.e. theres one large filesystem, it can tie up drives even when its just using one.

Leif has brought up another issue for us. At the moment there is a log manager zipping up and removing logs depending on space available and backups taken. To ensure the same level of service we think we'll need 3 or 4 archive log backups a day for each DB in archivelog mode. Plus individual backups for every other DB means we would be running 4 - 5 times the number of schedules.

Has anyone used the File library device. I'm looking at that for small backups then copying the objects to tape regularly or alternatively telling the DBAs to increase the archivelog areas to cut down the frequency of the log backups.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.