Re: Linux LVM snapshot

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@ardenta.com> escreveu: De: Neil Truby <neil.truby@ardenta.com> Assunto: Re: Linux LVM snapshot Para: informix-list@iiug.org Data: Quinta-feira, 4 de Março de 2010, 19:18 "Neil Truby" <neil.truby@ardenta.com> wrote in message news:7vapp7Fkf6U1@mid.individual.net... > > "Cesar Inacio Martins" <cesar_inacio_martins@yahoo.com.br> wrote in > message news:mailman.667.1267739579.6236.informix-list@iiug.org... > 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? Also, are *all* the LVs being snapped within a single invocation of onmode -c block/onmode -c unblock? _______________________________________________ Informix-list mailing list Informix-list@iiug.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@yahoo.com.br> wrote in message news:mailman.671.1267786544.6236.informix-list@iiug.org... 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... Provided all the LVs are snapped *** WITHIN THE SAME ONMODE -C BLOCK ... **** The raw one will be fine. The cooked one will be unpredictable.

> From: neil.truby@ardenta.com > Subject: Re: Linux LVM snapshot > Date: Fri, 5 Mar 2010 12:44:30 +0000 > To: informix-list@iiug.org > > "Cesar Inacio Martins" <cesar_inacio_martins@yahoo.com.br> wrote in message > news:mailman.671.1267786544.6236.informix-list@iiug.org... > 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... > > Provided all the LVs are snapped *** WITHIN THE SAME ONMODE -C BLOCK ... > **** > > The raw one will be fine. > The cooked one will be unpredictable. > > Interesting. How long does a snapshot take? _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/

"Ian Michael Gumby" <im_gumby@hotmail.com> wrote in message news:mailman.674.1267795715.6236.informix-list@iiug.org... > From: neil.truby@ardenta.com > Subject: Re: Linux LVM snapshot > Date: Fri, 5 Mar 2010 12:44:30 +0000 > To: informix-list@iiug.org > > "Cesar Inacio Martins" <cesar_inacio_martins@yahoo.com.br> wrote in > message > news:mailman.671.1267786544.6236.informix-list@iiug.org... > 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... > > Provided all the LVs are snapped *** WITHIN THE SAME ONMODE -C BLOCK ... > **** > > The raw one will be fine. > The cooked one will be unpredictable. > > >> Interesting. How long does a snapshot take? Should just be a few seconds. But if the db is blocked it doesn't really matter how long it takes, save of course the impact on the users of the source system!

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@iiug.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@ardenta.com> wrote: > "Cesar Inacio Martins" <cesar_inacio_martins@yahoo.com.br> wrote in > message > news:mailman.671.1267786544.6236.informix-list@iiug.org... > 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... > > Provided all the LVs are snapped *** WITHIN THE SAME ONMODE -C BLOCK ... > **** > > The raw one will be fine. > The cooked one will be unpredictable. > > > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list >

> From: neil.truby@ardenta.com > Subject: Re: Linux LVM snapshot > Date: Fri, 5 Mar 2010 13:31:20 +0000 > To: informix-list@iiug.org > > > > >> Interesting. How long does a snapshot take? > > Should just be a few seconds. But if the db is blocked it doesn't really > matter how long it takes, save of course the impact on the users of the > source system! > 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 mirrored hot 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/

>> "Art Kagel" <art.kagel@gmail.com> wrote in message >> news:mailman.676.1267797083.6236.informix-list@iiug.org... >> 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. 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?

"Ian Michael Gumby" <im_gumby@hotmail.com> wrote in message news:mailman.677.1267797150.6236.informix-list@iiug.org... > From: neil.truby@ardenta.com > Subject: Re: Linux LVM snapshot > Date: Fri, 5 Mar 2010 13:31:20 +0000 > To: informix-list@iiug.org > > > > >> Interesting. How long does a snapshot take? > > Should just be a few seconds. But if the db is blocked it doesn't really > matter how long it takes, save of course the impact on the users of the > source system! > >> 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 mirrored hot 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? No, I don't think you missed anything. Well, actually, perhaps you did ;-) If you look closely at El Kagel's description of how it sometimes work under the covers, you can also extrapolate to see that, on all but the most volatile of dbs, the restore speed if you need to do it is also going to be very quick indeed. Most databases have a pretty small delta of data that changes within a day - usually lesss than 5% - so since to restore you need only replay back to the source the prior images of those pages that have changed since the SAN split, this should be FAR quicker than a traditional all-pages restore. I've been advocating SAN backups, or external backups, in customers with decent SANS for 8 years or more. Becuase it is now possible to replicate large database with low volatility across great distances, the necessity of having to keep a stand-by Informix HDR instance on hand and in fast recovery for recovery purposes can be supplanted by the possibilty to have a cold standby looking at a SAN-replicated image, which has an IBM licence saving (more modest than it used to be though, since IBM has reacted by modifying its stand-by pricing).

----- Original Message ----- From: "Neil Truby" <neil.truby@ardenta.com> Newsgroups: comp.databases.informix To: <informix-list@iiug.org> Sent: Friday, March 05, 2010 8:12 AM Subject: Re: Linux LVM snapshot > > "Ian Michael Gumby" <im_gumby@hotmail.com> wrote in message > news:mailman.677.1267797150.6236.informix-list@iiug.org... > > >> From: neil.truby@ardenta.com >> Subject: Re: Linux LVM snapshot >> Date: Fri, 5 Mar 2010 13:31:20 +0000 >> To: informix-list@iiug.org >> > >> > >> >> Interesting. How long does a snapshot take? >> >> Should just be a few seconds. But if the db is blocked it doesn't really >> matter how long it takes, save of course the impact on the users of the >> source system! >> > >>> 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 mirrored > hot > 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? > > No, I don't think you missed anything. Well, actually, perhaps you did > ;-) > If you look closely at El Kagel's description of how it sometimes work > under > the covers, you can also extrapolate to see that, on all but the most > volatile of dbs, the restore speed if you need to do it is also going to > be > very quick indeed. Most databases have a pretty small delta of data that > changes within a day - usually lesss than 5% - so since to restore you > need > only replay back to the source the prior images of those pages that have > changed since the SAN split, this should be FAR quicker than a traditional > all-pages restore. > > I've been advocating SAN backups, or external backups, in customers with > decent SANS for 8 years or more. > > Becuase it is now possible to replicate large database with low volatility > across great distances, the necessity of having to keep a stand-by > Informix > HDR instance on hand and in fast recovery for recovery purposes can be > supplanted by the possibilty to have a cold standby looking at a > SAN-replicated image, which has an IBM licence saving (more modest than it > used to be though, since IBM has reacted by modifying its stand-by > pricing). > I tend to lean the other direction. I would prefer a hot HDR standby and possibly one or more RSS nodes for long distance disaster recovery over a SAN snapshot or a SAN replicated image. Correct me if I am wrong but with a SAN snapshot you can only recover to the point of the last snapshot, but with HDR/RSS you always have a backup system that is in sync with the Primary and can be made Primary in a few seconds with a few simple onmode commands or automatically with oncmsm and the failover arbitrator. Does a SAN replicated image solve this problem and is it just as good as HDR as far as recoverability is concerned? (serious question, I don't know the answer) With HDR/RSS you also get the benefit of a read only secondary (or multiple secondaries) for reporting and can use updateable secondaries if you want to make all of your HDR nodes appear updateable (all updates will be sent to the primary, so this only gives the impression that all nodes are updateable). Add on top of this the benefit of HDR being an Informix feature that works well with the application side (I'm thinking mostly about connection redirection via sqlhost groups or the connection manager). In my experience HDR is pretty hands off once it is up and running, so the administration overhead is pretty low. Also, HDR is something you have control over vs. a SAN based solution where a sysadmin or storage admin may have control. For these reasons the costs of HDR licenses are worth it to me. When we migrated to a new storage solution, the SAN snapshot and replication stuff required an additional license which we did not purchase. Is this standard? If the SAN stuff costs extra you have to consider that when deciding which is better for your situation. Andrew

> Correct me if I am wrong but with a SAN snapshot you can only recover to > the point of the last snapshot, but with HDR/RSS you always have a backup > system that is in sync with the Primary and can be made Primary in a few > seconds with a few simple onmode commands or automatically with oncmsm and > the failover arbitrator. Does a SAN replicated image solve this problem > and is it just as good as HDR as far as recoverability is concerned? > (serious question, I don't know the answer) 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). > With HDR/RSS you also get the benefit of a read only secondary (or > multiple secondaries) for reporting and can use updateable secondaries if > you want to make all of your HDR nodes appear updateable (all updates will > be sent to the primary, so this only gives the impression that all nodes > are updateable). 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. > Add on top of this the benefit of HDR being an Informix feature that works > well with the application side (I'm thinking mostly about connection > redirection via sqlhost groups or the connection manager). In my > experience HDR is pretty hands off once it is up and running, so the > administration overhead is pretty low. Also, HDR is something you have > control over vs. a SAN based solution where a sysadmin or storage admin > may have control. 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. > When we migrated to a new storage solution, the SAN snapshot and > replication stuff required an additional license which we did not > purchase. 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.

On Mar 5, 6:50 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote: > > Correct me if I am wrong but with a SAN snapshot you can only recover to > > the point of the last snapshot, but with HDR/RSS you always have a backup > > system that is in sync with the Primary and can be made Primary in a few > > seconds with a few simple onmode commands or automatically with oncmsm and > > the failover arbitrator.  Does a SAN replicated image solve this problem > > and is it just as good as HDR as far as recoverability is concerned? > > (serious question, I don't know the answer) > > 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). > > > With HDR/RSS you also get the benefit of a read only secondary (or > > multiple secondaries) for reporting and can use updateable secondaries if > > you want to make all of your HDR nodes appear updateable (all updates will > > be sent to the primary, so this only gives the impression that all nodes > > are updateable). > > 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. > > > Add on top of this the benefit of HDR being an Informix feature that works > > well with the application side (I'm thinking mostly about connection > > redirection via sqlhost groups or the connection manager).  In my > > experience HDR is pretty hands off once it is up and running, so the > > administration overhead is pretty low. Also, HDR is something you have > > control over vs. a SAN based solution where a sysadmin or storage admin > > may have control. > > 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. > > > When we migrated to a new storage solution, the SAN snapshot and > > replication stuff required an additional license which we did not > > purchase. > > 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. Exactly as Neil says, in an environment that contains other RDBMSes also, it may be overall simpler to use Recover Point as universal solution that may provide CDP/ point-in-time restore for all databases (and file systems also) of interest. At least, we in this news group know that not all RDBMSes have replication mechanisms as good as HDR is. For some apps, like Oracle, SQL Server or MS Exchange there are readily available scripts; for others there is an API available to access Recover Point for the purpose of marking points of consistency etc. BTW, being a SAN admin/UNIX sysadmin/RDBMSes DBA all at once, I wonder what's it like to be a DBA unaware of how are your database chunks stored. Is it easier not to worry about underlying server/SAN stuff or one worries even more since he/she has no control of that? Darko Krstic

> BTW, being a SAN admin/UNIX sysadmin/RDBMSes DBA all at once, I wonder > what's it like to be a DBA unaware of how are your database chunks > stored. Is it easier not to worry about underlying server/SAN stuff or > one worries even more since he/she has no control of that? What's the big deal? You just let the SAN admin give you a slice of that giant RAID5 array that is shared by everyone and let the storage firmware handle everything. I mean, that thing has a 16 GB cache so how could there ever be a problem? :) Andrew

Andrew Ford schrieb: >> BTW, being a SAN admin/UNIX sysadmin/RDBMSes DBA all at once, I wonder >> what's it like to be a DBA unaware of how are your database chunks >> stored. Is it easier not to worry about underlying server/SAN stuff or >> one worries even more since he/she has no control of that? > > What's the big deal? You just let the SAN admin give you a slice of > that giant RAID5 array that is shared by everyone and let the storage > firmware handle everything. I mean, that thing has a 16 GB cache so how > could there ever be a problem? :) > > Andrew LOL This was a good one. Andrew, you made my day! The bitter truth is: .... the thingy could have 16 GB cache, but as the greedy storage company changes 16-32 times for 2x 4 GB of what you or me 'd pay in mail ordering it from 'Kaiser'-ston [ to not name a memory seller ] .... it only has 8 GB installed. dic_k *--- NO RAID 5 or 6 NEVER EVER ---* -- Richard Kofler SOLID STATE EDV Dienstleistungen GmbH Vienna/Austria/Europe

On 5 Mar, 17:50, "Neil Truby" <neil.tr...@ardenta.com> wrote: > > Correct me if I am wrong but with a SAN snapshot you can only recover to > > the point of the last snapshot, but with HDR/RSS you always have a backup > > system that is in sync with the Primary and can be made Primary in a few > > seconds with a few simple onmode commands or automatically with oncmsm and > > the failover arbitrator.  Does a SAN replicated image solve this problem > > and is it just as good as HDR as far as recoverability is concerned? > > (serious question, I don't know the answer) > > 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). > Honestly these amateurs who give advice... If the SAN is behind then when you flip over you will be missing disk writes hence how on earth can you rollforward the logs? "Oh that insert did not make it so the subsequent log record to update it fails and oops my other copy will not come online". You need to do an external backup and restore as per http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.bar.doc/ids_bar_263.htm and follow the rules at http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.bar.doc/ids_bar_420.htm including "Suspend continuous logical-log backups before you block the database server for an external backup. After the external backup is complete, resume the continuous logical-log backup". You ALWAYS need to ensure that IDS can sync the logs with the data otherwise log roll-forwards will fail. > > With HDR/RSS you also get the benefit of a read only secondary (or > > multiple secondaries) for reporting and can use updateable secondaries if > > you want to make all of your HDR nodes appear updateable (all updates will > > be sent to the primary, so this only gives the impression that all nodes > > are updateable). > > 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. > > > Add on top of this the benefit of HDR being an Informix feature that works > > well with the application side (I'm thinking mostly about connection > > redirection via sqlhost groups or the connection manager).  In my > > experience HDR is pretty hands off once it is up and running, so the > > administration overhead is pretty low. Also, HDR is something you have > > control over vs. a SAN based solution where a sysadmin or storage admin > > may have control. > > 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. > > > When we migrated to a new storage solution, the SAN snapshot and > > replication stuff required an additional license which we did not > > purchase. > > 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.

<david@smooth1.co.uk> wrote in message news:45c07d4d-4c53-438e-a473-852194020cfe@33g2000yqj.googlegroups.com... > > 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). > >> Honestly these amateurs who give advice... Well obviously I'm not a true professional like you, David. I'm just doing my humble amateur best ... ;-) >> If the SAN is behind then when you flip over you will be missing disk writes hence how on earth can you rollforward the logs? "Oh that insert did not make it so the subsequent log record to update >> it fails and oops my other copy will not come online". Who said anything about rolling forward logs? >> You need to do an external backup and restore as per http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.bar.doc/ids_bar_263.htm and follow the rules at http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.bar.doc/ids_bar_420.htm >> including Why are you referring to backups and restores?

Thanks to Neil and Art for the answers and everyone else for this discussion... So, anybody use Linux  LVM Snapshot with Informix on production ? Over primary or secondary (using the new resource of external backups). Any comment? --- Em sex, 5/3/10, Neil Truby <neil.truby@ardenta.com> escreveu: De: Neil Truby <neil.truby@ardenta.com> Assunto: Re: Linux LVM snapshot Para: informix-list@iiug.org Data: Sexta-feira, 5 de Março de 2010, 21:40 <david@smooth1.co.uk> wrote in message news:45c07d4d-4c53-438e-a473-852194020cfe@33g2000yqj.googlegroups.com... > > 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). > >> Honestly these amateurs who give advice... Well obviously I'm not a true professional like you, David.  I'm just doing my humble amateur best ... ;-) >> If the SAN is behind then when you flip over you will be missing disk writes hence how on earth can you rollforward the logs? "Oh that insert did not make it so the subsequent log record to update >> it fails and oops my other copy will not come online". Who said anything about rolling forward logs? >> You need to do an external backup and restore as per http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.bar.doc/ids_bar_263.htm and follow the rules at http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.bar.doc/ids_bar_420.htm >> including Why are you referring to backups and restores? _______________________________________________ Informix-list mailing list Informix-list@iiug.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

On 05/03/2010 17:50, Neil Truby wrote: > > 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). I was going to ignore this, but on balance I won't Neil - unless your rate of data change is VERY bursty then the above is just wrong The bandwidth requirement is the average rate of data change - no more - no less If your data is bursty then if you stick with the average bandwidth requirement then yes your remote san will sometimes lag In the real world (tm) use the 95 percentile and set your bandwidth there as a minimum Please don't confuse bandwidth and latency (offers grandmother an egg) -- Clive -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

On 6 Mar, 00:40, "Neil Truby" <neil.tr...@ardenta.com> wrote: > <da...@smooth1.co.uk> wrote in message > > news:45c07d4d-4c53-438e-a473-852194020cfe@33g2000yqj.googlegroups.com... > > > > > 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). > > >> Honestly these amateurs who give advice... > > Well obviously I'm not a true professional like you, David.  I'm just doing > my humble amateur best ... ;-) > Hee Hee! > >> If the SAN is behind then when you flip over you will be missing disk > > writes hence how on earth can you rollforward the logs? > "Oh that insert did not make it so the subsequent log record to update > > >> it fails and oops my other copy will not come online". > > Who said anything about rolling forward logs? If x minutes after you snapshot you lose the building then you need to rollforward x minutes of logs to get to up to the minute recovery. Depending how often you snapshot the set of volumes 'x' minutes could be several hours. > > >> You need to do an external backup and restore as per > > http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic... > and follow the rules athttp://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic... > > >> including > > Why are you referring to backups and restores?

"Clive Eisen" <clive@serendipita.com> wrote in message news:mailman.1.1267991246.1071.informix-list@iiug.org... > On 05/03/2010 17:50, Neil Truby wrote: > >> >> 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). > > I was going to ignore this, but on balance I won't > > Neil - unless your rate of data change is VERY bursty then the above is > just wrong I don't think so. But you might be right I suppose. However, I didn't understand your explanation.

<david@smooth1.co.uk> wrote in message news:bb2e9c21-1937-4f0c-9f6a-eff08037686c@z4g2000yqa.googlegroups.com... On 6 Mar, 00:40, "Neil Truby" <neil.tr...@ardenta.com> wrote: > <da...@smooth1.co.uk> wrote in message > > news:45c07d4d-4c53-438e-a473-852194020cfe@33g2000yqj.googlegroups.com... > > >> If the SAN is behind then when you flip over you will be missing disk > > writes hence how on earth can you rollforward the logs? > "Oh that insert did not make it so the subsequent log record to update > > >> it fails and oops my other copy will not come online". > > Who said anything about rolling forward logs? >> If x minutes after you snapshot you lose the building then you need to rollforward x minutes of logs to get to up to the minute recovery. Recoverpoint is a continuous remote replication product, not a snapshot technology. So although you can use it for external backups, being careful to block the primary first, it can be used just to replicate to a remote site, preserving write order. So the db at the remote site can just be restarted, and rely upon Fast Recovery to fire up. Furtehrmore it can be used to do point-in-time recovery, argubaly much more quickly and easily that onbar. It's certified for all the usual dbs: Oracle, SQL Server, DB2 ... but not, unfortunately, Informix. It does work with IDS though (although I've not been able to try the point-in-time functionality for myself).

On 08/03/2010 01:56, Neil Truby wrote: > "Clive Eisen"<clive@serendipita.com> wrote in message > news:mailman.1.1267991246.1071.informix-list@iiug.org... >> On 05/03/2010 17:50, Neil Truby wrote: >> >>> >>> 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). >> >> I was going to ignore this, but on balance I won't >> >> Neil - unless your rate of data change is VERY bursty then the above is >> just wrong > > I don't think so. > But you might be right I suppose. > However, I didn't understand your explanation. > > Let's say your data is changing on average at 1 mbyte per second If your bandwidth is < 1 mbyte/sec you will start to fall behind immediately and never catch up Is that simple enough? -- Clive -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

On Mar 8, 9:09 am, Clive Eisen <cl...@serendipita.com> wrote: > On 08/03/2010 01:56, Neil Truby wrote: > > > > > "Clive Eisen"<cl...@serendipita.com>  wrote in message > >news:mailman.1.1267991246.1071.informix-list@iiug.org... > >> On 05/03/2010 17:50, Neil Truby wrote: > > >>> 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). > > >> I was going to ignore this, but on balance I won't > > >> Neil - unless your rate of data change is VERY bursty then the above is > >> just wrong > > > I don't think so. > > But you might be right I suppose. > > However, I didn't understand your explanation. > > Let's say your data is changing on average at 1 mbyte per second > > If your bandwidth is < 1 mbyte/sec you will start to fall behind > immediately and never catch up > > Is that simple enough? > > -- > Clive > > -- > This message has been scanned for viruses and > dangerous content by OpenProtect(http://www.openprotect.com), and is > believed to be clean. Clive, Recover Point is doing compression at a level that positively surprised me when I first saw it. So, actually, your bandwidth for Recover Point's remote replication doesn't have to be exactly the same as your average of data change. Of course, those two measures are proportionate. Out-of-box, Recover Point provides at least crash recovery consistency for perhaps any application. I've tested it with Informix and it is functioning. For those that EMC considers most important (Oracle, MS SQL Server and Exchange, I think DB2 also,...), there are automated mechanisms provided for application level consistency. One can make such a mechanism himself/herself, using the API that is available. It would be in a way similar to the mechanism that is described by OP of this thread with LVM snapshots, but instead of creating LVM snapshots, one should notify Recover Point that it is the point of consistency. What is important is that Recover Point provides write order preservation over a group of LUNs. The question if some acceptable lag may implicate lower bandwidth needed is very interesting one. Since Recover Point is relying on strong compression, there may be dependence between lag and bandwidth. Some compression algorithms can get higher compression rates if they have larger sample before doing the compression. When I started initial synchronization (file systems, databases), achieved compression rates were in the range of up to 6 times. Such rates were never achieved in later stages, when data is compressed and transfered due to changes on a live system. Darko Krstic

"Clive Eisen" <clive@serendipita.com> wrote in message news:mailman.2.1268035792.1071.informix-list@iiug.org... > On 08/03/2010 01:56, Neil Truby wrote: >> "Clive Eisen"<clive@serendipita.com> wrote in message >> news:mailman.1.1267991246.1071.informix-list@iiug.org... >>> On 05/03/2010 17:50, Neil Truby wrote: >>> >>>> >>>> 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). >>> >>> I was going to ignore this, but on balance I won't >>> >>> Neil - unless your rate of data change is VERY bursty then the above is >>> just wrong >> >> I don't think so. >> But you might be right I suppose. >> However, I didn't understand your explanation. >> >> > Let's say your data is changing on average at 1 mbyte per second > > If your bandwidth is < 1 mbyte/sec you will start to fall behind > immediately and never catch up > > Is that simple enough? Well, it's simple enough. But it's bollocks ... ;-) If your Recovery Point Objective is, say, a strict 5 seconds then each time the replicate would threaten to lag by more than this, operation of the primary would be affected. To avoid that lag your bandwidth would have to be sufficient always to handle any peak that would take more than 5s to clear. If your RPO is 5 minutes, the bandwidth requirement must be sufficient always to handle any peak that would take more than 5 mins to clear. Hence my original comment: " ....the more seconds you allow the remote SAN to lag, the lower the bandwidth requirement of course".

"darko" <darko.krstic@gmail.com> wrote in message news:4c87dc48-9d77-41fe-b2a9-a3f8da6c5d49@y17g2000yqd.googlegroups.com... On Mar 8, 9:09 am, Clive Eisen <cl...@serendipita.com> wrote: >> For those that EMC considers most important (Oracle, MS SQL Server and Exchange, I think DB2 also,...), there are automated mechanisms provided for application level consistency. One can make such a mechanism himself/herself, using the API that is available. It would be in a way similar to the mechanism that is described by OP of this thread with LVM snapshots, but instead of creating LVM snapshots, >> one should notify Recover Point that it is the point of consistency. Indeed, the absence of Informix integration for Informix is very regrettable, and another indication of the way Informix is viewed by the big players.