easy IDS Enterprise replication question
Hello, I'm new to managing a group using IDS, and am familiar with other RDMS platforms, but just not up to speed yet on this particular one. We have a two-fold problem getting data out for use in a reporting/ data warehouse from our OLTP environment. The issue is that we do not have last update date and time columns on our tables, so picking up the data deltas from the last time the ETL process ran isn't an option. The other is that we're using a trigger-based replication package (Replicate1), but we're experiencing locking issues after applying the replication triggers (we're using this third-party application because we're pushing to DB2). So, while we're trying to figure out if the locking can be remedied, I want to have a viable Plan B by having an additional instance of IDS and using ER to replicate to it. Can I have the destination tables be slightly different (having an extended column set to indicate the date and time the row changed) than the source data? This would be ideal for some intra-day reporting needs and as the sourced database for the ETL process to push to DB2. Thanks for any advice.
Luke.Schollmeyer@gmail.com wrote: > Hello, > > I'm new to managing a group using IDS, and am familiar with other RDMS > platforms, but just not up to speed yet on this particular one. > > We have a two-fold problem getting data out for use in a reporting/ > data warehouse from our OLTP environment. The issue is that we do not > have last update date and time columns on our tables, so picking up > the data deltas from the last time the ETL process ran isn't an > option. The other is that we're using a trigger-based replication > package (Replicate1), but we're experiencing locking issues after > applying the replication triggers (we're using this third-party > application because we're pushing to DB2). > > So, while we're trying to figure out if the locking can be remedied, I > want to have a viable Plan B by having an additional instance of IDS > and using ER to replicate to it. Can I have the destination tables be > slightly different (having an extended column set to indicate the date > and time the row changed) than the source data? This would be ideal > for some intra-day reporting needs and as the sourced database for the > ETL process to push to DB2. > No problem. The schema of the target table(s) just have to be compatible for the replicated columns, not identical. The target tables can contain additional columns like a DATETIME YEAR TO FRACTION(3) column for the update time and even a source server column if you were gathering data from multiple sources. Art S. Kagel Oninit > Thanks for any advice. > > =========================================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ===========================================================================================