Re: General Replication question

2002-09-05 Thread Yechiel Adar

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

2002-09-03 Thread Robson, Peter

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. 

snip


*
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

2002-08-27 Thread Peter Barnett

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 people use the replication features of Oracle. 
 I often see
 replication listed as one of the selling points of
 Oracle, but it's also

RE: General Replication question

2002-08-26 Thread DENNIS WILLIAMS

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 the