Tuning universal shares
Two key methods for improving performance of universal shares include tuning the number of vpfsd instances and setting the ingest mode.
A universal share uses one vpfsd instance by default. In most cases, one instance is adequate. Increasing the number of vpfsd instances might improve universal share performance, although it also requires more CPU and memory. You can increase the number of vpfsd instances from 1 to up to 16 and distribute the shares cross all the vpfsd instances.
In extensive testing with a maximum recommended 50 concurrently active shares, setting the number of vpfsd instances to 2 resulted in favorable results without overconsuming CPU and memory resources. Increasing the number of vpfsd instances to more than 2 should be done carefully and in conjunction with extensive benchmark testing.
There is no requirement to balance the number of universal shares per vpfsd instance because it is done automatically.
To make this change, set the numOfInstance value in the vpfsd_config.json file on the MSDP server.
Ingest mode was natively introduced in NetBackup 10.0 to give DBAs a way to increase performance of dumps to the universal share. When ingest mode of a universal share is enabled, the share will persist all the data from memory to disk on the client side at the end of the dump. The ingest mode is faster than normal mode as it does not guarantee all the ingested data is persisted to disk until the ingest mode is turn off. Therefore, turning ingest mode off is critical for data dump integrity.
You can enable and disable the ingest mode for a specific share on the NFS/SMB client side.
To leverage ingest mode, the .vpfs_special_control_config file must be updated to turn it on at the beginning of the dump, and then to turn it off at the end of the dump. Ideally, this action would be included in a script that the DBA calls to execute a database dump to the target universal share.
For more information, consult the NetBackup Deduplication Guide.
Improving performance with emergency engineering binaries (EEBs)
When dumping MSSQL data to universal shares, performance can be improved in some deployments by applying an EEB. The following table lists the relevant EEBs that are needed for each release of NetBackup.
NetBackup Version
Required EEB
9.1.0.1
4047040 v24
10.0
4070421 v8
10.0.0.1
4078688 v6
10.1
4091734 v6
10.1.1
4102406 v1
Universal share as a replacement for Oracle incremental forever backup (Co-pilot).
Beginning in NetBackup 10.1.1, universal share is becoming the replacement for Oracle Co-pilot feature. Internal tests have shown performance can be better with the initial dump, however, the merge part is still bottlenecked with the small I/O updates from Oracle RMAN. This blog describes the Oracle incremental merge feature really well:
https://blogs.oracle.com/maa/post/using-oracle-incremental-merge
The merge elapsed time is proportionally increased with the amount of changed data. Internal tests showed that for database change rate greater than 5%, the incremental merge performance can be slower than the full backup. For this reason, we don't recommend the Co-pilot feature if the database change rate is substantially greater than 5%. However, the merge operation has very low overhead on the Oracle client. In other words, normal operation can resume while the merge is in progress with very little impact to Oracle server performance. If this is acceptable, then a universal share can still be a good alternative to stream-based backup even if the change rate is larger.
Another advantage of the incremental forever backup feature is faster restore, as there is always a latest full image of the database available for access, while with stream-based backups, merging of multiple incremental backup images may be necessary to form the final backup image. Additionally, the Oracle incremental forever backups enables instant access capability that allows you to access the database much faster for certain database operations.