Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / Informix Topics / December 2006

Tip: Looking for answers? Try searching our database.

Ontape restore to another server

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Gary Quiring - 28 Dec 2006 15:01 GMT
I have a need to restore our production DB (9.4) to a junk box to
salvage a table that recently lost some data.  I am not very familiar
with the steps required.  The production server is running Solaris 9
with raw devices.  I was hoping to restore to a Red Hat box using
cooked files.  Is that possible?

I also need to remotely restore the data from the tape drive as my RH
box has no tape device.  I assume just changing the TAPEDEV to
server:/dev/rmt/0 will work.  Will issuing the ontape -r from the red
hat server restore the data to the local drives?  I obviously don't
want to restore the data over the production server.

Thanks
Gary Quiring
Sebastian, Norma J. - 28 Dec 2006 15:12 GMT
You are going from one OS to another....  that in itself is probably a
no-no.

But hey, why not try...

Restoring to cooked files when the backup was from raw devices should
not be an issue assuming on the raw setup, you used links to point to
the raw devices, and those links are what informix will look for.  So on
test system, make same named links, but point them to the cooked files.
(same size of course)

The change to TAPEDEV to get the data from remote server should work,
will you need to roll logs as well (thus need change to LTAPEDEV?).

Since you are using ontape, it should first give you some display of
what it intends to do and you can confirm before actually doing it (at
least that's what I remember of ontape, it's been years since I have
used it).
AND I think ontape would tell you that it can't restore because the DB
is up (that is if it was going to try to restore over PRD).

Norma Jean Sebastian
ERP Support Administration
IT -  Enterprise Technical Services

-----Original Message-----
From: informix-list-bounces@iiug.org
[mailto:informix-list-bounces@iiug.org] On Behalf Of Gary Quiring
Sent: Thursday, December 28, 2006 9:02 AM
To: informix-list@iiug.org
Subject: Ontape restore to another server

I have a need to restore our production DB (9.4) to a junk box to
salvage a table that recently lost some data.  I am not very familiar
with the steps required.  The production server is running Solaris 9
with raw devices.  I was hoping to restore to a Red Hat box using
cooked files.  Is that possible?

I also need to remotely restore the data from the tape drive as my RH
box has no tape device.  I assume just changing the TAPEDEV to
server:/dev/rmt/0 will work.  Will issuing the ontape -r from the red
hat server restore the data to the local drives?  I obviously don't
want to restore the data over the production server.

Thanks
Gary Quiring

_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
Keith Simmons - 28 Dec 2006 15:24 GMT
> I have a need to restore our production DB (9.4) to a junk box to
> salvage a table that recently lost some data.  I am not very familiar
[quoted text clipped - 15 lines]
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list

Gary

Forget it, there is no way this will even begin to work!
dbexport/dbimport is your only option between different O/S.

Keith
Gary Quiring - 28 Dec 2006 15:33 GMT
> Forget it, there is no way this will even begin to work!
> dbexport/dbimport is your only option between different O/S.

WOW!  Data is not compatible between OS's?  Why would Informix be so
inflexible about the data between hardware platforms?
Madison Pruet - 28 Dec 2006 17:04 GMT
>> Forget it, there is no way this will even begin to work!
>> dbexport/dbimport is your only option between different O/S.
>>
> WOW!  Data is not compatible between OS's?  Why would Informix be so
> inflexible about the data between hardware platforms?

Integers are not the same on intel chips as they are on the solaris
sparc chip.  It has nothing to do with the OS, but rather the format of
integers used by the chip.  For the number 67305985, Intel would use
0x01020304 while the sparc chip would use 0x04030201.
Art S. Kagel - 29 Dec 2006 16:28 GMT
>>Forget it, there is no way this will even begin to work!
>>dbexport/dbimport is your only option between different O/S.
>
> WOW!  Data is not compatible between OS's?  Why would Informix be so
> inflexible about the data between hardware platforms?

When sending data to remote clients network protocols are used and data is
converted to be compatible withthe client, but on disk IDS stores native
server CPU format for data types supported by the platform like integers
('C' int), smallint ('C short), smallfloat (ie  'C' float) and floats ('C'
double) for maximum efficiency with local and native remote clients.  Think
about it and it makes perfect sense.  Orable's insistence on storing BCD for
integers and floats is the one I don't fathom.

Art S. Kagel
Sebastian, Norma J. - 28 Dec 2006 15:37 GMT
Don't think that's different than other DB products.

Use the right tool (dbexport/import like Keith said), and it'll work
fine.

Norma Jean Sebastian
ERP Support Administration
IT -  Enterprise Technical Services

-----Original Message-----
From: informix-list-bounces@iiug.org
[mailto:informix-list-bounces@iiug.org] On Behalf Of Gary Quiring
Sent: Thursday, December 28, 2006 9:33 AM
To: informix-list@iiug.org
Subject: Re: Ontape restore to another server

Keith Simmons wrote:
> Forget it, there is no way this will even begin to work!
> dbexport/dbimport is your only option between different O/S.

WOW!  Data is not compatible between OS's?  Why would Informix be so
inflexible about the data between hardware platforms?

_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
Sebastian, Norma J. - 28 Dec 2006 16:57 GMT
Excellent idea Keith!!

A second informix instance on the same solaris box is a great idea,
informix has such a small footprint anyway.  And if you PRD db is a
large memory instance, you can make the second instance much smaller,
restore take longer, but who cares, you don't want to impact PRD much.

If your solaris box doesn't have the disk space, heck..... nfs mount the
space from the linux box u were going to use.....   you can leave it
cooked, informix don't care, .........

BUT.... would there be a problem with the links?
     If DB1 (production) has dbspace-root set to linkX to raw deviceB
     Then.... second instance.... .... sorry, my brain just stopped
there....  guys, would there be a problem at this point....

Norma Jean Sebastian
ERP Support Administration
IT -  Enterprise Technical Services

-----Original Message-----
From: informix-list-bounces@iiug.org
[mailto:informix-list-bounces@iiug.org] On Behalf Of Keith Simmons
Sent: Thursday, December 28, 2006 10:40 AM
To: Gary Quiring
Cc: informix-list@iiug.org
Subject: Re: Ontape restore to another server

> Sebastian, Norma J. wrote:
> > Don't think that's different than other DB products.
[quoted text clipped - 5 lines]
> Looking forward I don't see using dbexport as a practical backup
> solution for a 150gig DB.  Other DB products may be alike but that
does
> not excuse the issue. I think it's silly they can't make backup data
> compatible between hardware platforms.
[quoted text clipped - 3 lines]
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list

Gary

You were not asking for an archive/backup solution, only data
transfer. Horses for courses. Ontape is designed to archive data and
then restore it to the same or similar server. The two servers you
have probably have different page sizes (2K for Sol, 4K for Linux)
possibly different endedness (big or little), different procesors
(Sparc and Intel). Text files wold probably ftp between them OK but
ontape stores the data in binary page images (for speed of archive and
restore).
I would have thought cpio or tar wold not work between these servers
either, and they would only be transfering 'data'.
Do you have enough space on your Solaris box to create another
instance and then restore to this (using chunk renaming) just to
extract the table you need.
ou could investigate table level restores as well, although I can't
remember off the top of my head whether this is available at v9.4.

Keith
_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
Sebastian, Norma J. - 28 Dec 2006 20:43 GMT
I think the idea will work.  I have to look at some of my systems and
remember some things.

I am glad you said you would try this on your DEV box.  Is the name of
your DEV database different than your PRD database?   And what is the
name of your $INFORMIXDIR?

I believe you pegged the right onconfig params that need to be changed.
Let me put some more thought into it, check my systems,  and post back.

Of course, once we plan this out, you may still want a warm/fuzzy with
IBM Informix tech support.  I have done interesting things with my
systems, but I will only put my neck on the line, not yours ;)

Norma Jean Sebastian
ERP Support Administration
IT -  Enterprise Technical Services

-----Original Message-----
From: informix-list-bounces@iiug.org
[mailto:informix-list-bounces@iiug.org] On Behalf Of Gary Quiring
Sent: Thursday, December 28, 2006 2:20 PM
To: informix-list@iiug.org
Subject: Re: Ontape restore to another server

Sebastian, Norma J. wrote:
> Excellent idea Keith!!
>
> A second informix instance on the same solaris box is a great idea,
> informix has such a small footprint anyway.  And if you PRD db is a
> large memory instance, you can make the second instance much smaller,
> restore take longer, but who cares, you don't want to impact PRD much.

This instance idea with a mounted file system sounds like a solution.
I did use links for my raw devices so that should not be an issue.  My
dev box is also Solaris but has no space for the restore but the
mounted system from Linux can solve that.

Getting back to the tape drive which is unique on the production box.
If I add an instance on my dev box to use the production tape, is it
full proof that when I issue the ontape -r on the dev box that the
restore will be done locally and not on production?  I don't want the
restore stepping on the prod box.

Question for instances.  I have never configured one.  I would copy the
onconfig to another name and change the DBSERVERNAME, DBSERVERALIASES,
MSGPATH, SERVERNUM & ROOTHPATH.  I can keep my current INFORMIXDIR
right? Or do I need to make a complete copy else where?  I should just
need to change ONCONFIG & INFORMIXSERVER?

_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
Art S. Kagel - 29 Dec 2006 16:41 GMT
> I have a need to restore our production DB (9.4) to a junk box to
> salvage a table that recently lost some data.  I am not very familiar
[quoted text clipped - 7 lines]
> hat server restore the data to the local drives?  I obviously don't
> want to restore the data over the production server.

Gary, go with the IDS 10 version of archecker to extract the data from the
tape and recreate the table in a small IDS 10 instance on the Sun box.  Then
you could extract and reload to the production server, or copy directly from
one to the other using dbaccess or my dbcopy utility as long as there are no
special columns (and you could upgrade the dbcopy source to support your
data types as well).

Art S. Kagel
Sebastian, Norma J. - 29 Dec 2006 19:03 GMT
Thanks Art,

That simplifies some of the stuff we've posted on this thread, and I
haven't had time for more digging.  Your way sounds the simplest.

I am not very experienced with archecker (last time I played with it was
years ago)....
I have a couple questions for my own clarification....

IDS 10 archecker would do that for v9.4?
.......if using v10 archecker to extract data from v9.4 ontape backup
into an IDS10 instance....
Would the v10 instance need to take into consideration chunk paths and
other things discussed when thinking of doing the ontape restore to
second instance?  Or can the IDS10 instance be set up pretty much any
old way not in consideration of the v9.4 instance or ontape data......
and still receive the v10 archecker data extract from v9.4 ontape
backup?

Thanks for your thoughts,

Norma Jean Sebastian
ERP Support Administration
IT -  Enterprise Technical Services

-----Original Message-----
From: informix-list-bounces@iiug.org
[mailto:informix-list-bounces@iiug.org] On Behalf Of Art S. Kagel
Sent: Friday, December 29, 2006 10:41 AM
To: informix-list@iiug.org
Subject: Re: Ontape restore to another server

> I have a need to restore our production DB (9.4) to a junk box to
> salvage a table that recently lost some data.  I am not very familiar
[quoted text clipped - 7 lines]
> hat server restore the data to the local drives?  I obviously don't
> want to restore the data over the production server.

Gary, go with the IDS 10 version of archecker to extract the data from
the
tape and recreate the table in a small IDS 10 instance on the Sun box.
Then
you could extract and reload to the production server, or copy directly
from
one to the other using dbaccess or my dbcopy utility as long as there
are no
special columns (and you could upgrade the dbcopy source to support your

data types as well).

Art S. Kagel
_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.