Duplicating/Replicating Data? *Urgent please help*
7.x, Unix Hi gurus, I really need you help. We have a number of production tables that we want to "mirror" on another server on a daily basis (not continually, if at all possible). We dont want to risk anything that might impact production performance. We want the simplest and most robust approach. The source tables don't have primary keys defined, nor will it be possible for us to do so (for reasons to lengthy to explain here). So that may rule out replication(?) The tables are large and time is an issue here. I'd be very interested to hear your comments on this and also from people who are doing something similar already. We've considered HPL loads/unloads (too slow?) Informix Replication (primary key problem) Informix Mirroring (is this a bit copy thing?, can it be done as a once off basis?) Hardware disk mirroring (run the mirror at a specified time and then break the mirror link to use the mirror stand alone) Applying backups/logical logs to the target. Any other suggestions welcome. What is the best way? Thanks very much in anticipation. Sent via Deja.com http://www.deja.com/ Before you buy.
Have you actually tried HPL unload/reload? Is it really too slow? I've seen customers in this type of situation restore their backups to a secondary system system. I don't know what percentage of your total database that you want to replicate, so I don't know if this is really feasable or not. You could use triggers to record any inserts/updates/deletes into a seperate table and then apply those changes to the secondary system. However triggers will affect the performance of the production server just a bit. Also, this would require some way of knowing exactly which row to apply any updates to. I don't know if you can do this or not sonce you do not have primary keys. (This is the reason for the PK requirement in most replication schemes.) Generally if you can not uniquely identify the row then you are forced to do snapshot replication. That means simply copying a fresh copy of the data. How are you wanting to use the replicated data? If it is simply to read and create reports from, have you considered HDR? strangiato@my-deja.com wrote: > 7.x, Unix > > Hi gurus, I really need you help. > > We have a number of production tables that we want to "mirror" on > another server on a daily basis (not continually, if at all possible). > We dont want to risk anything that might impact production > performance. > > We want the simplest and most robust approach. > > The source tables don't have primary keys defined, nor will it be > possible for us to do so (for reasons to lengthy to explain here). So > that may rule out replication(?) > > The tables are large and time is an issue here. > > I'd be very interested to hear your comments on this and also from > people who are doing something similar already. > > We've considered > > HPL loads/unloads (too slow?) > > Informix Replication (primary key problem) > > Informix Mirroring (is this a bit copy thing?, can it be done as a once > off basis?) > > Hardware disk mirroring (run the mirror at a specified time and then > break the mirror link to use the mirror stand alone) > > Applying backups/logical logs to the target. > > Any other suggestions welcome. > > What is the best way? > > Thanks very much in anticipation. > > Sent via Deja.com http://www.deja.com/ > Before you buy.
Hi Madison. We aready do triggers/etc and the code gets too complicated. We would consider snapshot replication if we knew what was best(?) What is HDR? Thank you :) In article <391AC778.ACE33AB6@informix.com>, Madison.Pruet@informix.com wrote: > Have you actually tried HPL unload/reload? Is it really too slow? > > I've seen customers in this type of situation restore their backups to a > secondary system system. I don't know what percentage of your total > database that you want to replicate, so I don't know if this is really > feasable or not. > > You could use triggers to record any inserts/updates/deletes into a > seperate table and then apply those changes to the secondary system. > However triggers will affect the performance of the production server just > a bit. Also, this would require some way of knowing exactly which row to > apply any updates to. I don't know if you can do this or not sonce you do > not have primary keys. (This is the reason for the PK requirement in most > replication schemes.) Generally if you can not uniquely identify the row > then you are forced to do snapshot replication. That means simply copying > a fresh copy of the data. > > How are you wanting to use the replicated data? If it is simply to read > and create reports from, have you considered HDR? > > strangiato@my-deja.com wrote: > > > 7.x, Unix > > > > Hi gurus, I really need you help. > > > > We have a number of production tables that we want to "mirror" on > > another server on a daily basis (not continually, if at all possible). > > We dont want to risk anything that might impact production > > performance. > > > > We want the simplest and most robust approach. > > > > The source tables don't have primary keys defined, nor will it be > > possible for us to do so (for reasons to lengthy to explain here). So > > that may rule out replication(?) > > > > The tables are large and time is an issue here. > > > > I'd be very interested to hear your comments on this and also from > > people who are doing something similar already. > > > > We've considered > > > > HPL loads/unloads (too slow?) > > > > Informix Replication (primary key problem) > > > > Informix Mirroring (is this a bit copy thing?, can it be done as a once > > off basis?) > > > > Hardware disk mirroring (run the mirror at a specified time and then > > break the mirror link to use the mirror stand alone) > > > > Applying backups/logical logs to the target. > > > > Any other suggestions welcome. > > > > What is the best way? > > > > Thanks very much in anticipation. > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > Sent via Deja.com http://www.deja.com/ Before you buy.
HDR (High Availability Data Replication) is included as part of the engine. With it the logs from the source system are sent directly to the target system. The target system is always in recovery mode as it is applying the logs from the source instance. I understand the issue with triggers. Not only does it get messy, but it also adds quite a bit of overhead to the user transaction. strangiato@my-deja.com wrote: > Hi Madison. > > We aready do triggers/etc and the code gets too complicated. We would > consider snapshot replication if we knew what was best(?) What is HDR? > > Thank you :) > > In article <391AC778.ACE33AB6@informix.com>, > Madison.Pruet@informix.com wrote: > > Have you actually tried HPL unload/reload? Is it really too slow? > > > > I've seen customers in this type of situation restore their backups to > a > > secondary system system. I don't know what percentage of your total > > database that you want to replicate, so I don't know if this is really > > feasable or not. > > > > You could use triggers to record any inserts/updates/deletes into a > > seperate table and then apply those changes to the secondary system. > > However triggers will affect the performance of the production server > just > > a bit. Also, this would require some way of knowing exactly which row > to > > apply any updates to. I don't know if you can do this or not sonce > you do > > not have primary keys. (This is the reason for the PK requirement in > most > > replication schemes.) Generally if you can not uniquely identify the > row > > then you are forced to do snapshot replication. That means simply > copying > > a fresh copy of the data. > > > > How are you wanting to use the replicated data? If it is simply to > read > > and create reports from, have you considered HDR? > > > > strangiato@my-deja.com wrote: > > > > > 7.x, Unix > > > > > > Hi gurus, I really need you help. > > > > > > We have a number of production tables that we want to "mirror" on > > > another server on a daily basis (not continually, if at all > possible). > > > We dont want to risk anything that might impact production > > > performance. > > > > > > We want the simplest and most robust approach. > > > > > > The source tables don't have primary keys defined, nor will it be > > > possible for us to do so (for reasons to lengthy to explain here). > So > > > that may rule out replication(?) > > > > > > The tables are large and time is an issue here. > > > > > > I'd be very interested to hear your comments on this and also from > > > people who are doing something similar already. > > > > > > We've considered > > > > > > HPL loads/unloads (too slow?) > > > > > > Informix Replication (primary key problem) > > > > > > Informix Mirroring (is this a bit copy thing?, can it be done as a > once > > > off basis?) > > > > > > Hardware disk mirroring (run the mirror at a specified time and then > > > break the mirror link to use the mirror stand alone) > > > > > > Applying backups/logical logs to the target. > > > > > > Any other suggestions welcome. > > > > > > What is the best way? > > > > > > Thanks very much in anticipation. > > > > > > Sent via Deja.com http://www.deja.com/ > > > Before you buy. > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.
Thanks Madison. In article <391B1389.8B1D9E0E@informix.com>, Madison.Pruet@informix.com wrote: > HDR (High Availability Data Replication) is included as part of the engine. > With it the logs from the source system are sent directly to the target > system. The target system is always in recovery mode as it is applying the > logs from the source instance. > > I understand the issue with triggers. Not only does it get messy, but it > also adds quite a bit of overhead to the user transaction. > > strangiato@my-deja.com wrote: > > > Hi Madison. > > > > We aready do triggers/etc and the code gets too complicated. We would > > consider snapshot replication if we knew what was best(?) What is HDR? > > > > Thank you :) > > > > In article <391AC778.ACE33AB6@informix.com>, > > Madison.Pruet@informix.com wrote: > > > Have you actually tried HPL unload/reload? Is it really too slow? > > > > > > I've seen customers in this type of situation restore their backups to > > a > > > secondary system system. I don't know what percentage of your total > > > database that you want to replicate, so I don't know if this is really > > > feasable or not. > > > > > > You could use triggers to record any inserts/updates/deletes into a > > > seperate table and then apply those changes to the secondary system. > > > However triggers will affect the performance of the production server > > just > > > a bit. Also, this would require some way of knowing exactly which row > > to > > > apply any updates to. I don't know if you can do this or not sonce > > you do > > > not have primary keys. (This is the reason for the PK requirement in > > most > > > replication schemes.) Generally if you can not uniquely identify the > > row > > > then you are forced to do snapshot replication. That means simply > > copying > > > a fresh copy of the data. > > > > > > How are you wanting to use the replicated data? If it is simply to > > read > > > and create reports from, have you considered HDR? > > > > > > strangiato@my-deja.com wrote: > > > > > > > 7.x, Unix > > > > > > > > Hi gurus, I really need you help. > > > > > > > > We have a number of production tables that we want to "mirror" on > > > > another server on a daily basis (not continually, if at all > > possible). > > > > We dont want to risk anything that might impact production > > > > performance. > > > > > > > > We want the simplest and most robust approach. > > > > > > > > The source tables don't have primary keys defined, nor will it be > > > > possible for us to do so (for reasons to lengthy to explain here). > > So > > > > that may rule out replication(?) > > > > > > > > The tables are large and time is an issue here. > > > > > > > > I'd be very interested to hear your comments on this and also from > > > > people who are doing something similar already. > > > > > > > > We've considered > > > > > > > > HPL loads/unloads (too slow?) > > > > > > > > Informix Replication (primary key problem) > > > > > > > > Informix Mirroring (is this a bit copy thing?, can it be done as a > > once > > > > off basis?) > > > > > > > > Hardware disk mirroring (run the mirror at a specified time and then > > > > break the mirror link to use the mirror stand alone) > > > > > > > > Applying backups/logical logs to the target. > > > > > > > > Any other suggestions welcome. > > > > > > > > What is the best way? > > > > > > > > Thanks very much in anticipation. > > > > > > > > Sent via Deja.com http://www.deja.com/ > > > > Before you buy. > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > Sent via Deja.com http://www.deja.com/ Before you buy.