Hi,

Acording to other guys it should work, but I am a bit uncertain
now .... Which other option do I have to be able to make a backup on
one instance and in a situation be able to import this backup on
another host and IDS instrance? I know dbexport would be a
possebility, but not if the db is huge ... several 100 GB's ....

-POW

On 2 Mar, 16:28, theBP <th... (AT) Usenet-News (DOT) Net> wrote:

pow43 wrote:
dbspace restores between instances don't work.
For a dbspace to be recovered, you have to roll forward the logical logs
since the start of the backup of that dbspace. This is assumed to
guarantee the integrity of the data. If the instance is different, the
logical log rollforward would obviously fail.

I personally understand the requirement of being able to "move" dbspaces
from one instance to another since we can imagine scenarios where this
could be acceptable (if the dbspace only contains objects of a specific
database and if that database has no more objects except those included
in that dbspace). But this is not supported. Basically the idea is that
we don't let customers shoot themselves in the foot (even if they're
just pointing down and away from the feet).

Regards.

You take an archive on the source. Then you can use the Archecker utility
to extract the tables from the archive and restore the data to another
server! I thought I said that several days ago.

Another option is to get my dbimport/dbexport replacement utility package
myexport which can use the hploader to unload and load the data VERY fast
to/from disk and it can process all or many tables in parallel and it does
not lock the data base while it's working.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art (AT) iiug (DOT) org)

See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf

Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.



On Tue, Mar 2, 2010 at 5:47 PM, pow43 <faber_38 (AT) yahoo (DOT) no> wrote:

Hi,

Ok ... I think we maybe misunderstand eachother a little. I work
mostly with Sybase and Oracle and in Sybase ASE I restore db's accross
hosts and instances even. importing into different versions on a
regular basis and it works perfectly. Dbexport/import ... HPL or
similar approches (""aka"" bcp/sybmigrate in Sybase and exp/imp or
datapump in Oracle) are not at all an option when we are planning
Disaster plan for Informix databases. Then we must look at mirror/snap
solutions on the SAN (we are using Solaris zfs btw) and not useing
Informix tools.

Thanks!

Per Otto

On 3 Mar, 00:43, Art Kagel <art.ka... (AT) gmail (DOT) com> wrote:

By "disaster" you mean something that affects what?!
If it affects only a dbspace, you need to recover it in the original
instance.
If it affects a complete machine/instance you need to recover the whole
instance and not a dbspace (in the same machine or another).
Also, if you're planning for disaster/recovery take a look at MACH 11
technology (HDR/RSS/SDS/ER).
That should give you plenty of options for whatever you need to do.

The option of moving a dbspace can have several usage scenarios, but I can't
see how disaster recovery is one of them?

Regards.

On Wed, Mar 3, 2010 at 12:27 AM, pow43 <faber_38 (AT) yahoo (DOT) no> wrote:



--
Fernando Nunes
Portugal

http://informix-technology.blogspot.com
My email works... but I don't check it frequently...

This one bites me every time. PLEASE!!! Don't ask us how to make it work
when some solution you've dreamed up doesn't work. Insead, lay out what it
is that you are trying to accomplish and ask us how we would solve the
issue.

For disaster recovery, Informix has ontape and onbar which archive and
restore the entire server onto the same machine or a different one as long
as the machines are binary compatible and run the same OS. That's simple
and fast. That's disaster recovery. In addition, Informix has HDR, SDS,
and RSS secondary servers so that you can continue servicing client
applications immediately after a server crashes, that's disaster avoidance.
But that does not seem to be what you were asking about.

If all you are trying to do is to restore the archived server onto a
different machine, then it is trivial:

- Create the links for each chunk to some existing storage on the machine
that is at least as big as the original chunk
- To determine what the chunks are in case you have not saved a copy
of the onstat -d report from the server before it crashed, you
can start the
restore and it will print out the list of chunk paths and their sizesand
offsets (offset + size equals how much storage you'll need on the
replacement chunk device or file unless you use the remapping option of
ontape to relocate the chunks elsewhere).
- Make sure the ownerships and permissions are correct on the chunks
(informix:informix 0660)
- run "ontape -r" and stand back

It's that simple, I've restored many hundred servers over the years between
using ontape and onbar to migrate servers to new machines, test restores,
post-disaster crash recovery, and post fumble-finger restores (before
archecker) to recover deleted rows and dropped tables and there is nothing
easier. If you are having trouble with the mechanics of restoring an
archive, you need training not a different tool. Call us at ADTC, we can
help.

However, you keep asking about restoring a single dbspace to a different
already running server instance. You cannot do that, correct. What has
that to do with SNAPping SAN storage. What does that have to do with
disaster recovery? Disaster recovery is about restoring an entire database
server instance, not restoring a single dbspace or a single database.
Usually that kind of partial restoration is about recovering from fumble
fingers and that's a different animal. Other applications for this that
I've seen is copying production data to a QA or Dev. environment. If these
are your scenarios, which are not disaster recovery at all, then, yes ontape
and onbar are not the correct tools for you. Actually, dbexport and
dbimport (or myexport and myimport) and other scripted solutions are what
most of us use and they work well. For large to massive databases hploader
reading from one instance and piping its output to another hploader copy
which is inserting the data into the remote server works VERY well. Beyond
that, now with 11.50.xC6's EXTERNAL TABLES

So, what is the recovery scenario that you are that you are trying to plan
recovery from?

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art (AT) iiug (DOT) org)

See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf

Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.



On Tue, Mar 2, 2010 at 7:27 PM, pow43 <faber_38 (AT) yahoo (DOT) no> wrote: