FDR⁄UPSTREAM interfaces with Oracle RMAN by operating as an Oracle Media Manager Library. You can schedule the RMAN scripts from Upstream, but control then passes to RMAN which does all the work of identifying what data needs to be copied to make a backup. RMAN then passes this data to Upstream for storage. Recoveries are run from RMAN, which again requests Upstream to pass the data needed for a restore. Your Oracle DBA should do all the configuration and work needed within RMAN, but it is useful to have an overview of the processes needed in case you get problems.
You can find a general description of RMAN in this site, on the Oracle RMAN page
On UNIX systems three files are included in the UPSTREAM distribution to support the interface to Oracle Recovery Manager:
libobk.*, the shared library. The extension for this file depend on the operating system, see below.
usorasbt.cfg.sample, a sample configuration file
usorasbt.dat.sample, a sample UPSTREAM parameter file.
Note that Oracle is shipped with the default media manager software installed. Examine your $ORACLE_HOME/lib directory for any files or symbolic links called libobk.*. Rename or remove those files before installing UPSTREAM Media Manager software.
Go to $ORACLE_HOME/lib directory and either create a link to libobk shared library in your UPSTREAM directory or replace if it already exists:
This file must have execute permissions set. For example:
chmod 777 ln -s /opt/fdrupstream/libobk.so
ln -s /opt/fdrupstream/libobk.so /ora01/oracle/lib/libobk.so
The next time you start Oracle Recovery Manager (RMAN), the UPSTREAM Media Manager is activated. If you are getting error messages referencing libobk or shr.o, double-check the symbolic link libobk.* is created, that the libobk shared library exists in your UPSTREAM directory, and that it has the correct permissions. One problem I encountered was that the oracle installer was following a Word document, and the '-' in the ln command had been substituted for a longer 'smart' hyphen. That one took a bit of tracking down.
If you are running a 64-bit version of Oracle on HP-UX or Solaris system, make sure that you are using the 64-bit version of libobk.sl. These are called ibobk.sl.64 or libobk.so.64 in UPSTREAM directory so rename them to libobk.sl or libobk.so. The directory for libobk.sl or libobk.so on 64-bit HP-UX or Solaris is $ORACLE_HOME/lib64.
If you are running a 64-bit version of Oracle on AIX system, make sure that you are using the correct 64-bit version of libobk.a. For AIX versions 4 rename file libobk.a.64 in the UPSTREAM directory to libobk.a. For AIX version 5 and up rename libobk.a.64.5L.
According to Oracle, specifying BACKUP_TAPE_IO_SLAVES=TRUE in the Oracle initialization parameters may improve the performance.
The UPSTREAM interface to Recovery Manager is the dynamic link library orasbt.dll. It is normally copied into your UPSTREAM directory during the FDR⁄UPSTREAM install together with usorasbt.cfg.sample sample configuration files and usorasbt.dat.sample sample UPSTREAM parameter file. You need to copy the orasbt.dll file into the Oracle library so Oracle picks it up. You may need assistance from your Oracle DBA for starting and stopping Oracle.
To install the UPSTREAM Media Manager library:
Current versions of the UPSTREAM / Oracle interface, usorasbt, operate in multi-user mode with one or more instances of UPSTREAM running in parallel accepting backup/restore requests from different sources. Multi-user mode allows you to take full advantage of RMAN multi-channel backups. You need to create a configuration file for usorasbt that that points to the main UPSTREAM instance and sets usorasbt operational parameters. InnovationDP provides a sample configuration file called usorasbt.cfg.sample. The file can contain a number of parameters and you should consult the Upstream manual for the current set. However some important parameter are:
The configuration file usorasbt.cfg needs to be maintained by the Upstream support staff, but must be read accessable by the Oracle instance owner. It is usually kept in the UPSTREAM directory and then the environment variable USORASBTCFG is used to point to it from RMAN.
If you decide to use the same usorasbt.cfg for backups of multiple databases, make sure that you either have a unique profile for every database (by having USBKPROFILE in the RMAN channel specification) or the names of backup pieces for those databases are unique and identifiable (by using RMAN FORMAT parameter).
Finally, you need to create a template parameter file which is used by UPSTREAM when backing up Oracle. A sample file, usorasbt.dat.sample, is provided. The name and location of this file must match the PARAMETER specification in the usorasbt.cfg file.
You can create it by starting UPSTREAM, going into the backup dialog, specifying the desired options, and then saving the file to match the PARAMETER parm. Note that some settings in this file are overwritten by usorasbt
Multi-terabyte Oracle databases are not unusual and it takes time to copy all that data for backups. To reduce the elasped time, RMAN supports several parallel backup channels, each writing to a separate tape drive. This presents the Storage person with a challenge, as you need to make sure that enough tape drives are available, and also make sure that high capacity tapes are filled efficiently. If you just write a few hundred MB to every 12TB LTO-8 tape, you will quickly run out of tapes. The key to using your tapes efficiently is to get your backup profile for Oracle right.
First, note that the backup profile name must have no more than 7 characters. If you can use the Oracle database name, that would make it easy to identify. If you are defining the profile with the Client Profile Configuration, you need to specify the following:
InnovationDP also recommends that you specify the last file name qualifier in the DSN prefix (for both tape and DASD) to match the name of the backup prefix to ensure that all the backup file names created are unique. For example, if the database is called FP12PC, then the
Backup profile prefix should be set to FP12PC
DSN prefix should be set to MY.BACKUP.FP12PC
This results in backups of:
Channel 1: backup profile is FP12PC0, DSN is MY.BACKUP.FP12PC0..
Channel 2: profile is FP12PC1, DSN is MY.BACKUP.FP12PC1..
and so on ...
You should always let RMAN control tape retention, as it maintains backup information in it's database. This means that from the Upstream side, tapes with RMAN backups should be set to never expire. RMAN should be set to delete it's backups when they expire, using the 'change ... delete' command. When RMAN deletes a backup from its backup list, it sends the request to UPSTREAM to delete the associated backup on the Storage Server side.
RMAN scripts are usually created and maintained by your oracle DBAs. Most sites have a standard RMAN script that is invoked with parameters to make it specific for a particular database. What this means is that the script will be created once, then you should not have to worry about it. However in my experience, when things go wrong you will need to be familiar with the script and how it works.
The one command in the RMAN script that is totally relevent to Upstream is ALLOCATE CHANNEL. ALLOCATE CHANNEL allocates a storage device, in this case sbt_tape, and has a PARMS statement that is used to interface with the product on the end of the channel, in this case, Upstream. The format of the command is
ALLOCATE CHANNEL TYPE "sbt_tape" … PARMS="ENV=(USORASBTCFG=/opt/fdrupstream/usorasbt.cfg,...)"...;
The first thing to note is that the RMAN script can contain a parameter USBKPROFILE which can point to the Upstream profile. In other words, it overwrites the value you placed in usorasbt.cfg. Worth checking out if the backups are not picking up the profile that you expected. Another parameter to watch for is USORASBTCFG, which is the full name of the usorasbt configuration file if not in the UPSTREAMPATH directory.
The USPATH parm specifies the directory where UPSTREAM software, including usorasbt.cfg file, is installed.
USORAUSWAITTO will limit the time (in seconds) usorasbt waits during backup for an UPSTREAM backup channel to become available. The default is 20 seconds.
USORAPROFILEWAITTO will limit the time (in seconds) usorasbt waits during restore until the required profile channel becomes available. Unlimited wait is the default.
DAYSOLD Defines the number of days to keep in usorasbt.log file. If this parm is missed off, then the log file will grow unchecked.
The NEWTAPE parameter can be used in the script to decide when to write the backup data to a new tape. Options are:
You should also specify HOLDTAPE Y in the template parameter file (the file specified in PARAMETER in usorasbt.cfg) if you expect to have more than one backup file created during RMAN backup. It prevents tapes from being unloaded between backups.
The RMAN script should have a CROSSCHECK command in it, usually after the backup has completed. This means RMAN will check that the backups it has in its database also exist in the Upstream repository. This is essential to make sure a database can be recovered as expected, so if you don't see that CROSSCHECK parm, you should discuss this with your DBA.
The UPSTREAM Client use the MSSQL plugin for backups, which is independent of the Windows version that it is run on. You can backup an SQL database while it is open and active, so no application downtime is necessary. You can find a general description of MSSQL databases in this site, on the MSSQL backup and recovery page
Because Upstream uses the MSSQL plugin, configuration at the Upstream server side is just a standard Client install. The steps required are:
You must install an Upstream Client on the same machine as the one hosting the Microsoft SQL Client. Then you need to decide what account you will use to log into the SQL server. You can use an explicit SQL login or a trusted connection using the SQL Server's integrated Windows security mode to authenticate the Windows account under which the Client is executed.
The problem with a explicit login is that you need to code the Login ID and password in plain text in your set of Client parameters. This is obviously a security risk.
The Trusted Connection method avoids this security risk. The default name for the Windows service is UPSTREAM and this Windows service must be configured to run under a specific Windows account (not the Local System account) that is associated with a SQL Server Login ID configured for the Windows account.
Each SQL Server Login ID you create for use by the MSSQL PlugIn must be configured to match the Windows account under which the Client is run. You must then create a database alias of ‘dbo' (the owner of the database) in each database for this Login ID. exec sp_addalias 'AliasUser1','dbo' For example, assume that the Windows account under which the Client runs is named 'UPSTREAM'. A Login ID of 'UPSTREAM' must be created with the default database set to the master database. And then for each database that the UPSTREAM Login ID is to backup or restore, an alias for that database must be assigned to be 'dbo'. The procedure to be used to create Login IDs is different for each Microsoft SQL Server version.
By configuring a special Login ID for the UPSTREAM user account, the MSSQL PlugIn can establish a 'trusted connection' with the server to perform backups, restores and queries. The Login ID does not necessarily have to be 'UPSTREAM', it can be any other Login ID that matches any Windows account name that you choose to run the Client under. You may in fact create two or more Login IDs and may even create a separate unique Login ID for each database you want to backup and restore.
Backups ane restores are effected using the MSSQL PlugIn. The backup type for all MSSQL PlugIn backups must be either First-time Full, Full Merge or Incremental Merge. The MSSQL PlugIn does not support Non-merge backups. MSSQL insists that backups of the Master and MSDB databases are always Full, so whenever these databases are included in an Incremental Merge backup they are backed up using the Full backup method.
To back up a set of SQL Server databases, use the MSSQL Databases dialog in the UPSTREAM Director (by selecting Backup from the Action menu).
Start by selecting a Target Server hosting an SQL Server and a Backup Profile to be used.
Use the Get MSSQL Information button as shown below to detect all SQL instances on the selected backup target.
The Get MSSQL Information dialog displays a tree of available SQL Server instances on the backup target and the databases they own. If a trusted connection is successful a list of that server's databases is displayed, the status for the server is labeled 'Trusted Connection' and the server's version is displayed. If a trusted connection is not successful, the databases are not displayed and the status for the server is labeled 'Not Connected'.
The list of databases includes <ALL>, which is recommended if you wish to backup all the databases on your system. You can create a single SQL Backup job covering multiple instances by expanding each MS SQL Instance and selecting / adding what need to be backed up.
To change the connection options for any server, highlight the server and specify the desired connection options in the Connection Options group. To select a database to be backed up, simply check its check-box. To specify that all the databases for a given server are to be backed up, simply check the server's check-box. Individual databases may then be excluded by un-checking their check-boxes. Also, when all the databases are selected, an individual database not configured with a Recovery Model of 'Full' is automatically excluded.
The DIFFERENTIAL check box is enabled only for Incremental merge backups and when the highlighted database name belongs to a Microsoft SQL Server version 7.0 or higher.
The MSSQL PlugIn uses the parameters specified on the Specify MSSQL Parameters dialog to construct the PLUGINPARAMETERS and FILES file specification (repeating) parameters. The FILES parameter (the file specification) is formatted as follows:
The MSSQL PlugIn requires a specific set of file specification parameters that it sets automatically. As a result, the Backup Parameters dialog does not allow you to modify the Backup Specification field or click the Spec Detail button to alter the rest of the file specification parameters.
The MSSQL PlugIn may be used for multiple file specifications as long as the server and database name combinations are unique for each file specification. The MSSQL PlugIn may also be used in conjunction with other file specifications that do not use PlugIns or use other PlugIns as long as the other PlugIns also allow this combination.
Like all other UPSTREAM backups, those that use the MSSQL PlugIn may also be initiated from the Storage Server via a ustbatch job. The parameters for such a backup or restore are the same as any other backup or restore with the addition of the following parameters in the file specification section (i.e. after the SPECNUMBER parameter):
PLUGINPARAMETERS SERVER=servername DATABASE=databasename …
For a backup, the correct format for the FILES parameter is not crucial since the MSSQL PlugIn overrides it.
Each PlugIn module has a specific set of PlugIn specific parameters. The format for the PlugIn parameters (the PLUGINPARAMETERS repeating parameter) for a MSSQL PlugIn backup file specification is:
SERVER; This is the name of the server which owns the database to be backed up. This parameter is required. The backup job must be targeted to execute on the server that owns the database.
DATABASE; This is the name of the database to be backed up or restored. This parameter is required. The name of the database may also be '*' to indicate that all the databases for a given server are to be backed up (as in DATABASE=*).
LOGINID; This is an optional parameter to be used to specify the Login ID to be used for an explicit connection. Its use is not recommended for security reasons;
LOGINPASSWORD; This is an optional parameter to be used to specify the Login Password to be used for an explicit connection. This parameter must not be specified without the LOGINID parameter. Its use is not recommended for security reasons, a trusted connection is more secure.
DIFFERENTIAL; An optional parameter that may be specified when the backup type is Merge incremental and the Microsoft SQL Server is at version 7.0 or above.
If any of the values for these parameters contain spaces or commas, then enclose them in double quotes.
To start a restore of one or more databases that were backed up with the MSSQL Plugin, use the UPSTREAM Director. In the Director, you have the two cooperating windows. You use the first window to select the target, profile, backup and database(s) to be restored.
Once you have added one or more databases to restore, you then select the details about the restore of each database:
The Specify MSSQL Parameters dialog displays a tree of SQL Servers and databases that were backed up complete with a list of backup versions for each database. These are listed in the Restore Type field.
The MSSQL PlugIn performs a restore by first checking the backup type of the selected backup version to see if it is a full backup version or not. If the backup version selected is a full backup, the restore is performed from that backup version only. If the backup version selected is an incremental backup, it then identifies the previous full backup version and performs as many restores as necessary beginning with the previous full backup version up to and including the incremental backup version selected. This results in two or more restores depending on the number of backup versions between the full backup version and the specified incremental backup version. If you want to change the selected backup version, click the Backups button to select a different backup version.
To select a database to be restored, simply find it in the tree and check its check-box.