03-27-2014 02:25 AM
We have a SQL system which is backed up on a nightly basis and i'm trying to make a script which will use the omnir command to restore this backup to another SQL host. The destination host is running a different named instance of SQL and the paths for the files are also different.
The current command i've built looks like this:
omnir -mssql -barhost sql-source.contoso.com -destination sql-dest.contoso.com -destinstance SQL2008R2 -base Logihold -replace -file LogiholdDotNet "D:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Logihold_Da
Unfortunately running this command results in the following error:
[Critical] From: OB2BAR_SQLBAR@sql-dest.contoso.com "SQL2008R2" Time: 2
There are no objects in the Data Protector Internal Database for object
I've used the omnidb command to verify the object name and it is correct. We also test restored to another location with no issues and right now it's looking like the issue is to do with us restoring to a named instance which differs from the original location. Surely this isn't the case?
Can anyone make any suggestions on this one please?
Solved! Go to Solution.
03-27-2014 08:47 AM
Looking at the SQL Integration Guide for DP 7, at Figure 19, I can see where you are given tyhe option to restore to a different server, and restore to a differnet instance, so, it should be possible to do the same restore from the command line
On pg 40, it states these requirements:
Restoring to a different SQL Server instance or/and different SQL Server
• Both SQL Servers must have the same local settings (code page and sort order). This information
is displayed in the session monitor for each backup.
• The target SQL Server must be configured and reside in the same Data Protector cell as the
original SQL Server
Looking at the CLI documentation in the Integration Guide, one thing that I am seeing that I am not seeing in your command is "-instance SourceInstanceName", although it is in square brackets [ ] which means it is optional
The SourceInstanceName is case-sensitive; it has to be the same as the name of the SQL
Server instance that you specified in the backup specification
It may be useful here to see the 'detail' output of the backup to be sure that everything si correct
omnidb -session 2014/03/25-0524 -detail > 25-0254_detail.txt
I am also starting to wonder if that leading '0' in the session ID '0524' might have something to do with this, because teh 'omnir' command is so syntax-senstive
03-28-2014 07:26 AM
In our case the -SourceInstanceName doesn't appear to be a valid parameter, so i'm guessing maybe we're running an older version. But there is an option of '-Instance' which we'd already tried with no luck.
However, I ran the omnidb command you mention and I noted that the instance name listed there was actually (DEFAULT) and not just DEFAULT as i'd been trying.
Sure enough the same command with '-instance (DEFAULT)' in it causes the restore to work. So it's not optional in this case. I presume it's only optional if you're not also specifying a destination instance.
Thanks for your help :-)
03-28-2014 07:47 AM
Great, I am so glad to hear this... I have found the the '-detail' information helps me an awful lot when trying to do things from the command line