Re: Data Sourced from mainframe for Oracle application

From: Ron Rogers <RROGERS_at_galottery.org>
Date: Fri, 11 Jun 2004 12:32:05 -0400
Message-Id: <s0c9a655.044@galottery.org>

Robert,
I have used both options mentioned. Each has it's benifits and down falls.

I prefer option 1 because there is less work to perform;loading the duplicate data, backups, etc.
and all of the data is on the same server/instance. Therefore each application is looking at the same data and none of the common files are out of date. The only major draw back that I find is ,one disk fails and every application is in jeopardy. As far as backups go, one RMAN gets them all at the same time. The administration of the network configurations is easier because there is only one connection to the database not a connection per application. The access to the database applications could be controled by the application them selves and the access to the different database tables and data controled by the privileges granted.

If you use option 2 , the common data must be loaded into each application to be effective and isolate the application from a failure on the source database. A DB link would work instead of a data load but not isolate you from a database failure. The backup would be more complicated with mutliple server/instances but restore could be easier is the applications are kept separate.

Ron
>>> FREEMANR_at_tusc.com 06/11/2004 12:07:19 PM >>>
Hey fokls... looking for some feedback.

I've got data sourced from other databases (e.g. DB2, etc..) that is comming
into a central Oracle database. Right now, this data is fairly small, but
the volume will be increasing quickly (amount of data and number of tables
being replicated), and the number of applications that will be using this
data will increase as well. Each of these applications has different data
retention requirements (some, for example, only need the data for 10 days,
other for 180, others for 365, and each only need subsets of the whole).

Each application also has it's own application specific data as well of
course.

So, I'm trying to decide what the best architectural option is here. The
options as I see them are:

Have one big data store for the data, throw all the applications in it being careful to tune each one so they won't step on the other. Benefit: Data is only stored in one place, no physical duplication of data. This is not my prefered course of action, but others prefer this.
Have multipule instances for the more critical applications, and duplicate (replicate) the data to those instances. Less important, and less performance impactive applications could sit on a single database, but those mission critical applications would sit on their own instances/disks/etc... the down side of this is duplication of data, and more disk space is required. Still from an administrative point of view this seems a better course of action.

Any thoughts on this?

Robert

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/ 
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html 
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Fri Jun 11 2004 - 11:29:39 CDT