Re: General Replication question
Hello Ed We are using replication for one application, Dealing room. This is synchronous replication between 2 computers sitting in the same room connected by dedicated cable. The target is to have up to date second database in case of machine failure. I got lost quickly in the manual and finally did the right thing. Called Oracle support and paid for in site consulting. The guy came over and after 6-7 hours had a script that generate replication for a schema. I put it in production about 1 year ago and no problems since. Yechiel Adar Mehish - Original Message - To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Monday, August 26, 2002 6:58 PM > I'm curious, based on a discussion I had with a DBA here at work, how > many people use the replication features of Oracle. I often see > replication listed as one of the selling points of Oracle, but it's also > very hard to get a class on replication because they are always closing > classes for poor registration. > > How common is replication (basic or advanced)? It makes more sense to > use simple snapshots than DB links for what we are doing, but given that > our support from Oracle has been TERRIBLE with snapshot problems, I now > wonder if anyone uses them. We are switching to db links, but that can > pose potential performance issues with, for example, joins across the db > link. > > Best, > > Ed > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Ed > INET: [EMAIL PROTECTED] > > Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California-- Public Internet access / Mailing Lists > > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Yechiel Adar INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: General Replication question
Well, the flood of responses (not) to this topic probably answers one of the points raised! While endorsing all that Dennis has stated, I would just like to add something. Most crucially, replication is an exercise in logic, which fundamentally depends on getting your database design correct on both (or all) instances. If one site has an indadequately defined model, then sure as fate, replication will uncover the weakness sooner or later in the form of corrupt data or a failed replication transaction. Which provides a useful side benefit, by the way. We have been running replication for 15 years. In-house system. Slowly and incrementally improved over the years. Why replicate? Because we had such a poor wan, that transactions across it were highly problematic. Easier to have a couple of instances, and replicate between them each night. Now we have three big sites, and murmurs between them in the dead of night ensure everything is maintained synchronous... The point about checking that replication has worked in very important. I spent a lot of time building up an ever-increasingly complex array of exception reports. No emails in the morning - all's well. Hey, but replication is great for carrying out major data migrations! peter edinburgh > -Original Message- > From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]] > Sent: 26 August 2002 19:19 > To: Multiple recipients of list ORACLE-L > Subject: RE: General Replication question > > > Ed - We have flirted with the replication thing here for some > time. I have > had the same questions as you, trying to take classes, for > example. I don't > think replication is widely used, but there are plenty of > sites out there. * This e-mail message, and any files transmitted with it, are confidential and intended solely for the use of the addressee. If this message was not addressed to you, you have received it in error and any copying, distribution or other use of any part of it is strictly prohibited. Any views or opinions presented are solely those of the sender and do not necessarily represent those of the British Geological Survey. The security of e-mail communication cannot be guaranteed and the BGS accepts no liability for claims arising as a result of the use of this medium to transmit messages from or to the BGS. The BGS cannot accept any responsibility for viruses, so please scan all attachments.http://www.bgs.ac.uk * -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Robson, Peter INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: General Replication question
We are using advanced replication for three instances. It's labor intensive, fraught with error, and requires continual babysitting. For us, it is doing what we want. Near real time copies of the primary instance, and instant failover capability (well, instant as soon as the tnsnames.ora is changed - but that's another story). --- DENNIS WILLIAMS <[EMAIL PROTECTED]> wrote: > Ed - We have flirted with the replication thing here > for some time. I have > had the same questions as you, trying to take > classes, for example. I don't > think replication is widely used, but there are > plenty of sites out there. >The conclusion I've come to is that the secret to > a successful > replication project is not in the technology. It is > in the preparation. > Success requires a military-like discipline of > getting full cooperation from > all involved people. And there will be many more > people throughout your > organization to be involved than you think. > Replication is a practice rather > than a slap-on Oracle or third-party feature. > Regardless of the technology > you select, you'll still need to resolve the same > issues in order to > succeed. Dull stuff like how you will test > replication (very difficult), how > you will fix the data when the replication > inevitably breaks, how you will > implement changes (massive issue, as Dick points > out). Replication can move > corrupt data just as quickly as good data. Whether > you are using the most > expensive third-party add-on tool (aren't vendors > great at acting like their > product will solve all your problems?) or tossing > magnetic tapes in a semi > to be driven to the site, the big issues don't > change. A friend was just > reliving problems they encountered 15 years ago with > a home-grown COBOL > system. As he discussed their problems, he was > shocked that the underlying > problems haven't really changed much. Maybe more > convenient and faster, but > you still have a lot of human involvement, > regardless. >Replication is easy so set up. Keeping it running > reliably day after day > is the trick. For example a friend of mine who had > quit his previous > employer to get away from their replicated > environment (this was a Sybase > log-based project). Recently someone at one of their > remote sites decided to > reboot a server. It took several days and nights for > them to get the entire > system corrected. >First of all your organization must decide > whether replication is worth > all the time and trouble it will inflict. Most > replication projects are > caused by political rather than technical reasons. > Like two divisions that > both need to be equally important. >I feel most replication projects are eventually > abandoned. If the > organization was smart and started with a small > project, usually their > enthusiasm was simply dulled. If they weren't and > started with a really big > project, the disaster can be spectacular. Usually > the organization starts > with a small project, learns how much trouble > replication is, and never > implements "phase II". The successful replication > projects probably aren't > so visible on because the people who tend them day > in and day out aren't the > shooting stars that go for the latest technology. > Those people may have sold > management on starting the replication project, but > they would have probably > gotten bored with the mundane detail and follow-up > and moved on to a more > exciting project. >Another factor is the application. The best > application is one you are > just now developing in-house where you can build > replication considerations > in from the initial design. The worst is a mature > third-party product that > you don't clearly understand at the data level and > have no hope of modifying > to accommodate replication. >The only two books I've found on replication are: > > Data Replication, Marie Buretta, 1997. Lists > all the issues that > must be considered for a replication project to > succeed. > Oracle Distributed Systems, Charles Dye, > 1999. > As you can tell from the publication dates, this > isn't exactly a hot > technology. > I don't mean to be too negative. I just feel it > is important for an > organization to understand what they are getting in > for before they start. > If the benefits outweigh the costs, then proceed. > But don't think a couple > of DBAs can "turn replication on" and succeed. > Eventually management wakes > up and says "wow, we've gone through about a dozen > DBAs in the last year, do > you think they are overwhelmed by that replication > thing?". > Again, these are my observations from studying > replication from the outside. > Perhaps it will provoke some responses from > replication experts. > > -Original Message- > Sent: Monday, August 26, 2002 11:58 AM > To: Multiple recipients of list ORACLE-L > > > I'm curious, based on a discussion I had with a DBA > here at work, how > many pe
RE: General Replication question
Ed - We have flirted with the replication thing here for some time. I have had the same questions as you, trying to take classes, for example. I don't think replication is widely used, but there are plenty of sites out there. The conclusion I've come to is that the secret to a successful replication project is not in the technology. It is in the preparation. Success requires a military-like discipline of getting full cooperation from all involved people. And there will be many more people throughout your organization to be involved than you think. Replication is a practice rather than a slap-on Oracle or third-party feature. Regardless of the technology you select, you'll still need to resolve the same issues in order to succeed. Dull stuff like how you will test replication (very difficult), how you will fix the data when the replication inevitably breaks, how you will implement changes (massive issue, as Dick points out). Replication can move corrupt data just as quickly as good data. Whether you are using the most expensive third-party add-on tool (aren't vendors great at acting like their product will solve all your problems?) or tossing magnetic tapes in a semi to be driven to the site, the big issues don't change. A friend was just reliving problems they encountered 15 years ago with a home-grown COBOL system. As he discussed their problems, he was shocked that the underlying problems haven't really changed much. Maybe more convenient and faster, but you still have a lot of human involvement, regardless. Replication is easy so set up. Keeping it running reliably day after day is the trick. For example a friend of mine who had quit his previous employer to get away from their replicated environment (this was a Sybase log-based project). Recently someone at one of their remote sites decided to reboot a server. It took several days and nights for them to get the entire system corrected. First of all your organization must decide whether replication is worth all the time and trouble it will inflict. Most replication projects are caused by political rather than technical reasons. Like two divisions that both need to be equally important. I feel most replication projects are eventually abandoned. If the organization was smart and started with a small project, usually their enthusiasm was simply dulled. If they weren't and started with a really big project, the disaster can be spectacular. Usually the organization starts with a small project, learns how much trouble replication is, and never implements "phase II". The successful replication projects probably aren't so visible on because the people who tend them day in and day out aren't the shooting stars that go for the latest technology. Those people may have sold management on starting the replication project, but they would have probably gotten bored with the mundane detail and follow-up and moved on to a more exciting project. Another factor is the application. The best application is one you are just now developing in-house where you can build replication considerations in from the initial design. The worst is a mature third-party product that you don't clearly understand at the data level and have no hope of modifying to accommodate replication. The only two books I've found on replication are: Data Replication, Marie Buretta, 1997. Lists all the issues that must be considered for a replication project to succeed. Oracle Distributed Systems, Charles Dye, 1999. As you can tell from the publication dates, this isn't exactly a hot technology. I don't mean to be too negative. I just feel it is important for an organization to understand what they are getting in for before they start. If the benefits outweigh the costs, then proceed. But don't think a couple of DBAs can "turn replication on" and succeed. Eventually management wakes up and says "wow, we've gone through about a dozen DBAs in the last year, do you think they are overwhelmed by that replication thing?". Again, these are my observations from studying replication from the outside. Perhaps it will provoke some responses from replication experts. -Original Message- Sent: Monday, August 26, 2002 11:58 AM To: Multiple recipients of list ORACLE-L I'm curious, based on a discussion I had with a DBA here at work, how many people use the replication features of Oracle. I often see replication listed as one of the selling points of Oracle, but it's also very hard to get a class on replication because they are always closing classes for poor registration. How common is replication (basic or advanced)? It makes more sense to use simple snapshots than DB links for what we are doing, but given that our support from Oracle has been TERRIBLE with snapshot problems, I now wonder if anyone uses them. We are switching to db links, but that can pose potential performance issues with, for example, joins across the db link. Best, Ed -- Please see t
General Replication question
I'm curious, based on a discussion I had with a DBA here at work, how many people use the replication features of Oracle. I often see replication listed as one of the selling points of Oracle, but it's also very hard to get a class on replication because they are always closing classes for poor registration. How common is replication (basic or advanced)? It makes more sense to use simple snapshots than DB links for what we are doing, but given that our support from Oracle has been TERRIBLE with snapshot problems, I now wonder if anyone uses them. We are switching to db links, but that can pose potential performance issues with, for example, joins across the db link. Best, Ed -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Ed INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
