Dear All,
thank you for your valuable feedback. please find below the details.
we have the following backup infrastructure:
As the size of our databases grow the backups take more and more time and so the restores too. The Oracle way we backup oracle databases had also it’s own evolution:
-
We started with Template based backups.
-
Templates are difficult to maintain
-
Templates are not flexible
-
Later on we switched to script based backups
-
We also achieved significant performance gain by setting FILESPERSET=1 for database backups – instead of using the default value – which helps for deduplication. (for archivelog backups we use FILESPERSET=20)
-
Backups are not compressed and not encrypted in order to achieve the best deduplication rate.
-
The backups are done using VTLs (Virtual tape Library) which has it constraints:
-
When we run out of VTLs the backups fail
-
VTLs limit the access to one client (only one thread can backup/restore at a time from a single VTL)
To overcome these limitations and further enhance our backups/restores we have started looking into a technology called “DD Boost” (Data Domain Boost).
DD Boost is a software plugin provided by EMC which needs to be install along with the Netbackup software on the Database Server itself.
The Database server needs to be promoted to a Media Server too and both the Client and Server Netbackup Software needs to be installed on it including the OST Plugin.
When executing a backup/restore in OST mode there aren’t any VTLs used. It is still the Netbackup where backup jobs will be scheduled – there is an other way too which skips the Netbackup completely, this is out of the scope of this document – and we can still use rman command line to restore databases.
Using Netbackup this way is fully transparent to the database team. There is no change required to the RMAN scripts (we’ll still use SBT_TAPE device type for backup/restore)
When doing backups the Database Server acts like a Media Server and does deduplication. This adds an extra cpu cost (<10% total ) to each thread when the backup is running and only those data pieces are sent to the Data Domain which are new. On one hand this has the biggest impact when doing FULL (LEVEL 0) database backups, on the other hand the database still needs to be read from the disk. The benefits of using this mode:
-
When only 10% of the database has changed since the last full backup, only 10% of the database will be sent across the network and only this amount needs to be written to the data domain.
-
Boost will allow you to run recover sessions at the same time as you’re running backup sessions to the same volumes, and also allow you to run multiple restore sessions at the same time
-
Reduce the write pressure on the Data Domain during the weekend backup windows and give more throughput to other systems
-
Backups taken using the OST plugin can be restored ony any database server. In other words a database server doesn’t any special configuration to restore the backup taken using the OST plugin.
The disadvantages:
Limitations:
huge Databases (>20TB)
Reason: the benefit here would be the option to perform multiple restores at the same time.
The numbers were taken on xxxxxxx which was running on SATA disks. The bottleneck during all the below tests were the Storage array, so the below numbers are relative numbers.
Testcase
|
Type
|
Backup Type
|
Channels
|
Filesperset
|
Input Bytes
|
Output Bytes
|
Input Bytes per sec
|
Output Bytes per sec
|
Time taken
|
1
|
VTL
|
Full
|
8
|
64
|
431.03G
|
422.04G
|
231.21M
|
226.39M
|
00:31:49
|
2
|
OST
|
Full
|
8
|
64
|
431.03G
|
422.04G
|
226.11M
|
221.40M
|
00:32:32
|
3
|
OST
|
Full
|
8
|
64
|
431.03G
|
422.04G
|
202.09M
|
197.88M
|
00:36:24
|
4
|
OST
|
Full
|
8
|
1
|
431.03G
|
422.05G
|
259.48M
|
254.07M
|
00:28:21
|
5
|
OST
|
Full
|
8
|
1
|
431.03G
|
422.05G
|
251.64M
|
246.40M
|
00:29:14
|
6
|
OST
|
Full
|
20
|
1
|
431.03G
|
422.05G
|
384.81M
|
376.79M
|
00:19:07
|
7
|
OST
|
Full
|
24
|
1
|
431.03G
|
422.05G
|
449.47M
|
440.10M
|
00:16:22
|