Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE
John Felts_2 Absent Member.
Absent Member.
961 views

Restoring SQL Database to different client...

I am attempting to restore a SQL2000 database (actually multiple databases) to a different client. I have followed the steps in the NT Integration guide, and am still receiving the error:

Error number: " Time: 11/4/2002 2:52:47 PM
Error has occurred while executing a SQL statement.
Error message: '
The restore job will finish, and says it's successful, however, I don't have any data. I have created new, empty databases on the target server with the same name(s) as the source databases. What am I doing wrong?, or is there a whitepaper anyone can point me towards that explains all of this?

Thanks in advance...
0 Likes
7 Replies
Joseph T. Wycko Absent Member.
Absent Member.

Re: Restoring SQL Database to different client...

I have seen that error as a security issue recently, in a slightly different scenario.

Here is my best advice on this one:

1. install sql on your restore-to box (I will call it server-b)

2. install the Omniback disk agent on server-b
-Also install the sql agent.

3. do a backup and restore of a few file system files to verify we are functioning at this simpler level.

4. Configure a backup of sql on server-b.

5. backup the whole of sql on server-b (is master, model, pubs, northwind...)

6. restore pubs or northwind
from server-a via omniback, to server-b

7. restore your good data.

If you do this, in this order, we will have a really good idea of what the failure point is, when you get an error.

Odds are good it is some sort of permissions issue - for example, what user is the OMNIBACK II INET process running as, on server-b. Does that user have priviliges within the trivial copy of sql? within the restored copy of sql? Within Omniback? Within NT?

What user are you when you run the GUI... same questions apply...

--
You didn't mention which version of Omniback (or DataProtector) - and that may be relevant, some earlier versions didn't really allow of a server move using the gui. You wind up having to use a command line command. If you are 3.5 and later, I dont expect this to be an issue... but it is worth note.

Just to be complete... you might also take a look at patches, although I do not know of an issue there.

Omniback

http://support.openview.hp.com/cpe/patches/ob/ob.jsp

Data Protector

http://support.openview.hp.com/cpe/patches/dp/dp.jsp

Good Luck.
Omniback and NT problems? double check name resolution, DNS/HOSTS...
0 Likes
Malcolm McGrath Absent Member.
Absent Member.

Re: Restoring SQL Database to different client...

John,

I too am having the same problem, I was wondering what you did to resolve it?

Malcolm
0 Likes
Pedro Guerreiro Absent Member.
Absent Member.

Re: Restoring SQL Database to different client...

I have the same problem. I tried to backup a specific database and i restore it, and nothing happens. I did the same with the NorthWind and the Data Protector restores it, with no problem. I will trie today or monday, to do the backup of all databases that i have.
0 Likes
Kurt Beyers. Absent Member.
Absent Member.

Re: Restoring SQL Database to different client...

Pedro,

Start a new thread with a good description of your environment and the problem messages. Then you can get more performant answers.

Kurt
0 Likes
Pedro Guerreiro1 Absent Member.
Absent Member.

Re: Restoring SQL Database to different client...

I do the restore and nothing happens. And don´t know what i'am doping wrong. What should i do. I call to HP i they say to me that i've got to upgrade 5.1, i made the upgrade, and the problem persists. Can someone help m
0 Likes
Mark Connors Absent Member.
Absent Member.

Re: Restoring SQL Database to different client...

People,

I eventually got this working, after doing the following...

- the big problem I eventually found was to do with "pre-zeroing" the DB, which for the biggest DB I was trying was 75gb or so. This took Omniback (just as it would take SQL Server to do) apx 6 hours to build, and then to pre-zero. By default Omniback will only wait 120 minutes or so for this operation, so the Media and Disk Agents needed their time-outs to be manually re-defined. These timeouts live in a config file somewhere, details of which can be found at: http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000068695617

- sometimes it helped to have a DB of the same name on that other (or indeed existing server), but this DB would be still empty. If there is an empty DB, this would still be pre-zeroed by Omniback. If no DB present, then a new "pre-zeroed" one would be created by Omniback.

- the other thing you GOTTA remember to do is force the restore over any existing DBs with the same name. Seems obvious, but I forgot this step a few times, and wasted 3 lots of 6 hours doing so ! The force restore option is (I think) available by right clicking the host's DB you want to restore, after selecting your host from the list of available (restore) clients.

Let me know how you guys get on.

MC
Silva Trusted Contributor.
Trusted Contributor.

Re: Restoring SQL Database to different client...

Hi guys,

I found the same problem with pre-zeroing steps. It takes a very long time in the resport session. What actually this step do? Because when I create a blank database from SQL side, this step very quick. So that I doubt which side will take this step? Is from SQL side or DP side? And what is the reason why this step taking so long if we don't create a bank (zero) database first?

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.