Re: information integrator & informix
How about the "hosting" or replication piece of Integrator? Sorry I do not know much about the product so I am getting information kind of piecemeal. The thought is for some DB2 Data Warehousing folks to host or replicate our Informix data but we cannot afford to have it hit our production, so their thought was to use our HDR instance of Informix. If you have any good articles, sites to check out, that would be great also.. Thanks Madison! "Madison Pruet" <mpruet@comcast.net> wrote in message news:<X1jlb.836174$YN5.927005@sccrnsc01>... > I don't think that II to a HDR secondary would be too successful. > > Basically II is a combination of synonyms and gateway. The query is made on > the II server against a 'nickname' which is fundamentally an expansion of > the IDS synonym. > > When queries are made on the nickname, depending on the query, the II server > might need to push data to the remote server (temp table) and then join > against that table. So there might be some logging occuring. > > As far as impact - the backend server treats the II query much as any remote > query. So there isn't really any impact on the BE - or at least any more > than a normal distributed query. > > M.P. > > > "tomL" <tomcaml@yahoo.com> wrote in message > news:3158a6a2.0310211335.74b999cf@posting.google.com... > > hello all! > > has anyone tried connecting Info integrator to Informix 9.x? > > if so, here are my questions....how much of the server's resources > > does it use? > > does it matter if using Info integrator pointing to a replicated > > instance versus the production instance? We use HDR on Informix and > > want the Info integrator to point to the HDR instance, not the main > > production instance.. > > > > > > > > Thanks > > Tom
DB2 replicates from IDS by using triggers which populate staging tables. So that approch would not work on an HDR secondary. Also, the DPROP apply program has to update control tables which is used to keep track of how far the apply got with the last apply cycle. I would like to see an interface developed which would allow IDS logs to be snooped and fed directly into the DPROP replication stream. That should reduce the replication impact from an IDS source to the level of ER or HDR. Perhaps you could make a feature request for this functionality? M.P. "tomL" <tomcaml@yahoo.com> wrote in message news:3158a6a2.0310220615.65a6e263@posting.google.com... > How about the "hosting" or replication piece of Integrator? Sorry I do > not know much about the product so I am getting information kind of > piecemeal. The thought is for some DB2 Data Warehousing folks to host > or replicate our Informix data but we cannot afford to have it hit our > production, so their thought was to use our HDR instance of Informix. > If you have any good articles, sites to check out, that would be great > also.. > > Thanks Madison! > > > > > "Madison Pruet" <mpruet@comcast.net> wrote in message news:<X1jlb.836174$YN5.927005@sccrnsc01>... > > I don't think that II to a HDR secondary would be too successful. > > > > Basically II is a combination of synonyms and gateway. The query is made on > > the II server against a 'nickname' which is fundamentally an expansion of > > the IDS synonym. > > > > When queries are made on the nickname, depending on the query, the II server > > might need to push data to the remote server (temp table) and then join > > against that table. So there might be some logging occuring. > > > > As far as impact - the backend server treats the II query much as any remote > > query. So there isn't really any impact on the BE - or at least any more > > than a normal distributed query. > > > > M.P. > > > > > > "tomL" <tomcaml@yahoo.com> wrote in message > > news:3158a6a2.0310211335.74b999cf@posting.google.com... > > > hello all! > > > has anyone tried connecting Info integrator to Informix 9.x? > > > if so, here are my questions....how much of the server's resources > > > does it use? > > > does it matter if using Info integrator pointing to a replicated > > > instance versus the production instance? We use HDR on Informix and > > > want the Info integrator to point to the HDR instance, not the main > > > production instance.. > > > > > > > > > > > > Thanks > > > Tom
Madison, That's too bad. I would have guessed that the way it was set-up already was to hit the logs. Thank you very much for the insight! Tom "Madison Pruet" <mpruet@comcast.net> wrote in message news:<2kxlb.329813$mp.271498@rwcrnsc51.ops.asp.att.net>... > DB2 replicates from IDS by using triggers which populate staging tables. So > that approch would not work on an HDR secondary. Also, the DPROP apply > program has to update control tables which is used to keep track of how far > the apply got with the last apply cycle. > > I would like to see an interface developed which would allow IDS logs to be > snooped and fed directly into the DPROP replication stream. That should > reduce the replication impact from an IDS source to the level of ER or HDR. > Perhaps you could make a feature request for this functionality? > > M.P.
Madison, Can you explain a little more about that? Why exactly would this not work on a HDR secondary? Does it have to do with the Read-Only aspect? Does DB2 use triggers to populate staging tables on the DB2 box? Are they Temp Tables? Sorry to hit you with so many questions but no one seems to know any of these details...Thanks again!! Tom > DB2 replicates from IDS by using triggers which populate staging tables. So > that approch would not work on an HDR secondary. Also, the DPROP apply > program has to update control tables which is used to keep track of how far > the apply got with the last apply cycle. > > I would like to see an interface developed which would allow IDS logs to be > snooped and fed directly into the DPROP replication stream. That should > reduce the replication impact from an IDS source to the level of ER or HDR. > Perhaps you could make a feature request for this functionality? > > M.P. >
Tom, DPROP creates insert/delete/update triggers on the replicated table to populate what are called CCD tables. There is a CCD table for each base table. The CCD table contains the row, and when it was last updated. There is a seperate program which periodically scans the CCD tables, picks up the changes, and applies them to the target table. The updates to the CCD tables are done as part of the user transaction. (FYI - this is pretty much what happens on all trigger based capture from all vendors with hetrogenous replication support.) Since the HDR secondary is a mirror copy of the HDR primary, then that would mean that the triggers would need to be created on the primary server, not the secondary. (FYI - triggers are not fired on the HDR secondary - the action of the trigger is replicated.) FYI - ER should be able to support this, but would require that the replicates be set to fire triggers. No - the triggers are not directly copied to the DB2 box, the CCD tables would exist on the source box. I really would like to get the IDS logs opened to snooping so that DPROP can snoop the logs directly, and thus eliminate the cost of the triggers. That would allow IDS to work directly with DPROP and would also enable IDS to integrate with the existing II functionality as well as planned II development. However, I need the customers to 'raise a ruckus on this so that priorities on this can be raised enough to get it scheduled. So - if you want to help me out - please contact your sales force and ask/demand/bribe/or whatever - that this become a feature. Thanks M.P. "tomL" <tomcaml@yahoo.com> wrote in message news:3158a6a2.0310230726.41e16164@posting.google.com... > Madison, > > Can you explain a little more about that? Why exactly would this not > work on a HDR secondary? Does it have to do with the Read-Only aspect? > Does DB2 use triggers to populate staging tables on the DB2 box? Are > they Temp Tables? > Sorry to hit you with so many questions but no one seems to know any > of these details...Thanks again!! > Tom > > > DB2 replicates from IDS by using triggers which populate staging tables. So > > that approch would not work on an HDR secondary. Also, the DPROP apply > > program has to update control tables which is used to keep track of how far > > the apply got with the last apply cycle. > > > > I would like to see an interface developed which would allow IDS logs to be > > snooped and fed directly into the DPROP replication stream. That should > > reduce the replication impact from an IDS source to the level of ER or HDR. > > Perhaps you could make a feature request for this functionality? > > > > M.P. > >