Hi,

Someone use LVM snapshot on linux with Informix (using onmode -c block)?
There some issues with it? or is simple like Informix, just works...

Cesar



__________________________________________________ __________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

"Cesar Inacio Martins" <cesar_inacio_martins (AT) yahoo (DOT) com.br> wrote

Hi,
Someone use LVM snapshot on linux with Informix (using onmode -c block)?
There some issues with it? or is simple like Informix, just works...

Do you, or your friend, have the Informix chunks as raw devices, or as
regular files on a file system?

"Neil Truby" <neil.truby (AT) ardenta (DOT) com> wrote

Also, are *all* the LVs being snapped within a single invocation of
onmode -c block/onmode -c unblock?

Hi Neil,

We have the 2 situations, one instance running with
RAW (configured with raw module) and other instance (differ machine) as
cooked.

And yes, ALL LVs (used by the database) will be snaped...


--- Em qui, 4/3/10, Neil Truby <neil.truby (AT) ardenta (DOT) com> escreveu:

De: Neil Truby <neil.truby (AT) ardenta (DOT) com>
Assunto: Re: Linux LVM snapshot
Para: informix-list (AT) iiug (DOT) org
Data: Quinta-feira, 4 de Março de 2010, 19:18


"Neil Truby" <neil.truby (AT) ardenta (DOT) com> wrote

Also, are *all* the LVs being snapped within a single invocation of
onmode -c block/onmode -c unblock?

_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list



__________________________________________________ __________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

"Cesar Inacio Martins" <cesar_inacio_martins (AT) yahoo (DOT) com.br> wrote

Hi Neil,

Provided all the LVs are snapped *** WITHIN THE SAME ONMODE -C BLOCK ...
****

The raw one will be fine.
The cooked one will be unpredictable.

__________________________________________________ _______________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/

Cooked should be OK also. IDS always opens COOKED chunks with either the
O_DIRECT or O_SYNC flags so everything is sync'd to disk immediately and the
IO doesn't return until the write is complete. So, once the onmode -c BLOCK
returns and IDS reports that the engine is blocked even COOKED chunks should
be safe to snap-copy.

Snap copies are almost instantaneous. You are snapping to another SAN
that's being kept in sync. The snap mainly detaches the LUN's logical log
equivalent of any updates that haven't been copied yet, discontinues the
live updates to the copy, copies the residual logs over, and then releases
the source LUN for new updates. Very fast. The copy is updated in the
background but since it's just the last update log or two even that's almost
instantaneous.

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 Fri, Mar 5, 2010 at 7:44 AM, Neil Truby <neil.truby (AT) ardenta (DOT) com> wrote:

Well that's what I mean.

So you can take a snapshot, unblock and then take your time moving the snapshot to more persisted space.

The idea is if you're running a 24x7 shop, you use HA/HDR where you take your snapshot off your secondary, move it to other disk and either flash a disk or make a tape for off premise storage.
(Ok so you could also push the image to a second facility too.)

Even if you're not a large shop, you could take your system, put out a NAS or even a second box filled with cheap SATA, and then use that as your primary archive. If you need to take stuff off site, you use a mirroredhot swap and pull the drive.

Pretty cheap way to manage backups and avoid tape libraries.

Ok, how much does 2TB of tape cost, vs a 2TB SATA?

If IBM doesn't really charge you extra for the hot secondary, you can build a cheap back up solution. Or did I miss something?



__________________________________________________ _______________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/

Without knowing what the underlying file system type is, and what weird and
wonderful "cacheing", jouraling or other performance functionality it might
have, now can you be certain that everything really has been written back to
disk?

Well, yes, with something like EMC Recoverpoint you can keep a remote SAN
copy in step with the original primary (the more seconds you allow the
remote SAN to lag, the lower the bandwidth requirement of course).

Yes, that is true, and a good point. But a subtle point here is that, if the
remote site is to be true DR from which you are likely to want to a remote
server which has lots of grunt. And any remote server you want to query
needs to be fully licensed rom an IBM software perspective. Sure, you can
alleviate this impact through virtualisation, but there's one more thing you
have to reverse if you *do* fail over.

Well, speak for yourself of course - our business model is wherever possible
to contrll all the infrastructure! But, in an environment where
resposnibilities is tightly siloed, you certainly have a point.

Yes, usually. So indeed it's an extra cost to consider. The general point
about SAN replication is though that few of our customer sites are all
Informix these days, and SAN replication techniques can be used for
non-Informix databases and apps as well, which would tend to make it a lower
TCO option for multi-app sites.