Fernando Nunes wrote:
ISM won't go away until there is an alternative available - one that
should be easier for you to use and us to maintain, that has been around
for a couple of releases, and that has proven reliable. These criteria
mean that ISM will be around for a good few years yet. OTOH, you might
want to look at other storage managers - or wait until after you've seen
the replacement and then decide whether to look for an alternative to
the storage manager provided with IDS. ON-Tape in Cheetah has some nice
stuff in it, too.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler (AT) earthlink (DOT) net, jleffler (AT) us (DOT) ibm.com
Guardian of DBD::Informix v2007.0226 -- http://dbi.perl.org/

On 12 Jun, 05:12, Jonathan Leffler <jleff... (AT) earthlink (DOT) net> wrote:
All I really need is a version of ontape that can backup dbspace in
parallel.

Sybase can use multiple stripes.
I believe DB2 can backup in parallel

Why can't Informix without the complexity of a Storage Manager?

ontape's advantage is that it backsup the whole instance in one go
without having to list tablespace (Oracle) or databases (Sybase)
where these lists can get out of date.

[ Either yes I know we added a new database to your Sybase server but
we forgot to amend the list of backup job or
each customer has to create their own script to discover the list
of databases and back them up].

Parallel ontape where you specify N files and it backsup in parallel
to all N (parallelism internal at dbspace level if needed.

As mentioned in the great book "Unix Backup and Recovery" better if
with M reader x N writers (you know the famous xchg stuff used
by parallel everything queries) but I'll settle for backups running
in parallel at the dbspace level.

FYI, using ISM to mount 3 volume on 3 disk devices with plenty of
space results in each volume reporting full after a while.

WTF? How can it be full when all 3 devices are links to a directories
on a network share that has 600GB free?

David.

[snip]
complexity of a storage manager - although it might be adding complexity of
its own ;-))
--
Ciao,
Marco
__________________________________________________ ____________________________
Marco Greco /UK /IBM Standard disclaimers apply!

Structured Query Scripting Language http://www.4glworks.com/sqsl.htm
4glworks http://www.4glworks.com
Informix on Linux http://www.4glworks.com/ifmxlinux.htm

Hi,

maybe you want to look into external backup (and restore).
This can easily be done to a file system and you can add
as much parallelism as you want (or are capable of).
If you do it right, you can accomplish the critical part of the
external backup in less than a minute even for some terrabytes
of data (e.g. by splitting a mirror). After this you can let the
database users continue with their work while the actual backup to
tape, files or whatever destination is done ...

ontape can do backup to files, but also (if not chiefly) it is
intended as a tool to backup to tape. And for doing backup
to tapes in parallel, a storage manager (SM) is enormously helpful.

BTW: as already mentioned by someone, onarchive was an attempt
to do parallel backup without an SM. It became so complex to use
that in the end people didn't use it anymore.

TIA,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

IBM Deutschland GmbH
Chairman of the Supervisory Board: Hans Ulrich Märki
Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
Diemer
Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940

informix-list-bounces (AT) iiug (DOT) org wrote on 12.06.2007 23:16:18:

On 13 Jun, 12:18, Martin Fuerderer <MARTI... (AT) de (DOT) ibm.com> wrote:
1. If you resync mirror the wrong way you break the database.
2. If you add a device you have to a) add a mirror) b) add the
mirror to the backup script.



In what way it is helpful? It just means I need to piss about
- parsing /nsr/logs/daemon.log for messages
- creating volumes,
- labeling volumes,
- find a free device
- mounting volumes on devices
- not mounting the same volume on >1 device.
- unmounting volumes
- wondering why it all went tits up and i unmounted something that
was in use and having to waiting until ISM issues a media critical
event
and the volume required for a restore gets mounted a second
time.

WHAT BENEFIT DO I GET HAVING TO DO ALL THIS CRAP?

NOTE: Does anyone know how to configure the timeout in ISM during a
restore between "media waiting for volume X" and
"media critical waiting for volume X" messages? At the moment we
unmount when a message appears in /nsr/logs/daemon.log that the
dbspace restore is complete (" ...done reading") but if a volume
contains >1 dbspace we unmount the volume between one dbspace
finishing and the restore for the next one starting. We have to
wait for the "media critical" message before ISM prompts for the
volume
to be remounted.


I DON'T HAVE TO DO ALL THIS CRAP WITH DB2 OR SYBASE. How come they can
do it without getting as complex as onarchive?

David.