Re: Distributed Vs. Centralized Database Approach

Jim Kennedy wrote:

>I find it hard to believe with such a small system that you need
>replication. I think you would do much better to make sure that you have
>the proper procedures in place to backup and restore if something happens.
>In all likelihood you don't have those in place, you probably have never
>tested your recovery scenarios and probably never documented them. Now you
>want to add replication to the mix and make the whole thing more difficult
>to manage.
>
>If you have scalability problems now adding another database is not going to
>solve your problem, just complicate it. To solve performance and
>scalability problems you need to find the root cause of the problem and fix
>that.(probably poor queries, bad application design and no use of bind
>variables)
>
>Jim
>
>"coldfusion" <coldfusion1998_at_yahoo.com> wrote in message
>news:c6bc3b02.0310291924.719b5be9_at_posting.google.com...
>
>
>>How intricate is real time database replication and what type of
>>overhead would that add to a system? I have been on projects in the
>>past where we tried replicating data between databases globally, but
>>we have always run into errors, is Oracle 9i better at replication
>>than its predecessors?
>>
>>The other question I have is with a single instance how do you
>>maintain a state of high availabilty to your users?
>>
>>
>>
>>
>>Daniel Morgan <damorgan_at_x.washington.edu> wrote in message
>>
>>
>news:<1067458103.447099_at_yasure>...
>
>
>>>coldfusion wrote:
>>>
>>>
>>>
>>>>Hi,
>>>>I am trying to make a reccomendation for our database arch. We are
>>>>currently debating on using a centralized database on one machine
>>>>possibly having multiple instances or to use a distributed model have
>>>>multiple servers and instances.
>>>>
>>>>Background:
>>>>the application is a global application with a couple of hundred
>>>>users. In the past couple of months the database grew to about 70,000
>>>>records. Going forward as we add more modules to the application we
>>>>want to try and figure out a strategy so that we can scale, and
>>>>minimize performace problems down the road.
>>>>Any opinions or ideas?
>>>>Thanks
>>>>
>>>>
>>>>
>>>>
>>>Unless you accidentally posted to Oracle and are really working in MS
>>>Access (or dBASE II)
>>>70,000 records barely qualifies for building an index. I wouldn't sweat
>>>a database with
>>>70,000,000 records much less a single table with 70,000,000 records.
>>>
>>>What you need is one database with one instance. And if you do anything
>>>else it should be
>>>a separate database, separate instance, on a separate machine involving
>>>some strategy for
>>>replication for data security.
>>>
>>>Just so you know ... I routinely build tables with 50,000 - 100,000
>>>records on my personal
>>>notebook computer just to run demos in class for my students. When you
>>>get into the billions
>>>or trillions ... then start thinking about splitting things up ... but
>>>into partitions ... not separate
>>>databases.
>>>
>>>

Timeout.

The OP said nothing, as I recall, about replication.

I said put it all together and don't even think of a second database/instance except if the purpose is replication for fail-over purposes. If my recollection is good lets not get side-tracked.

Well unless you want to. ;-)

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)