ifxclone

Never used this, but one of my boys suggested it for the establishment of a long-distance RSS where we knew it would take many, many hours, but needed to keep onbar logical log backups running on the Primary. IDS 11.70FC7 and FC8 on SuSE Linux. What are your experiences? What we found was, having BAR_MAX_BACKUP set to anything but 1, it would crap out after 15-120 minutes. But - suggestion from Ron Privett, IBM US support - it is *absolutely rock solid* with BAR_MAX_BACKUP=1. Fails with anything else. This has run for 3 days and worked! But it’s a pretty crap solution. We could have cloned within a day if the function had supported multiple threads. Raised IBM PMR 35085,019,866. IBM comment is: >> It seems the problem is related to a network problem I don’t buy this. I think it’s an Informix problem. The clones have been absolutely rock-solid with Ron’s BAR_MAX_BACKUP workaround. Any thoughts? Thanks Neil

Neil, You would need to use the same technique that I discussed last week with you to create multiple network threading. From: "NEIL TRUBY" <neil.truby@ardenta.com> To: ids@iiug.org Date: 12/22/2014 01:04 PM Subject: ifxclone [34378] Sent by: ids-bounces@iiug.org Never used this, but one of my boys suggested it for the establishment of a long-distance RSS where we knew it would take many, many hours, but needed to keep onbar logical log backups running on the Primary. IDS 11.70FC7 and FC8 on SuSE Linux. What are your experiences? What we found was, having BAR_MAX_BACKUP set to anything but 1, it would crap out after 15-120 minutes. But - suggestion from Ron Privett, IBM US support - it is *absolutely rock solid* with BAR_MAX_BACKUP=1. Fails with anything else. This has run for 3 days and worked! But it’s a pretty crap solution. We could have cloned within a day if the function had supported multiple threads. Raised IBM PMR 35085,019,866. IBM comment is: >> It seems the problem is related to a network problem I don’t buy this. I think it’s an Informix problem. The clones have been absolutely rock-solid with Ron’s BAR_MAX_BACKUP workaround. Any thoughts? Thanks Neil ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Oh dear. Madison has gone all Klingon on us again. yImev Har 'oH > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Madison Pruet > Sent: Monday, December 22, 2014 1:25 PM > To: ids@iiug.org > Subject: Re: ifxclone [34381] > > Neil, > > You would need to use the same technique that I discussed last week with > you to create multiple network threading. > > > > From: "NEIL TRUBY" <neil.truby@ardenta.com> > To: ids@iiug.org > Date: 12/22/2014 01:04 PM > Subject: ifxclone [34378] > Sent by: ids-bounces@iiug.org > > > > Never used this, but one of my boys suggested it for the establishment of a > > long-distance RSS where we knew it would take many, many hours, but needed > to > keep onbar logical log backups running on the Primary. > > IDS 11.70FC7 and FC8 on SuSE Linux. > > What are your experiences? > > What we found was, having BAR_MAX_BACKUP set to anything but 1, it would > crap > out after 15-120 minutes. > > But - suggestion from Ron Privett, IBM US support - it is *absolutely rock > solid* with BAR_MAX_BACKUP=1. Fails with anything else. > > This has run for 3 days and worked! But it’s a pretty crap solution. We > could > have cloned within a day if the function had supported multiple threads. > > Raised IBM PMR 35085,019,866. IBM comment is: > >> It seems the problem is related to a network problem > > I don’t buy this. I think it’s an Informix problem. The clones have been > absolutely rock-solid with Ron’s BAR_MAX_BACKUP workaround. > > Any thoughts? > > Thanks > Neil > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > *********************************************************************** > ******** > Forum Note: Use "Reply" to post a response in the discussion forum.