Re: Data Sourced from mainframe for Oracle application
- From: "Ron Rogers" <RROGERS@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 11 Jun 2004 12:32:05 -0400
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@xxxxxxxx 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:
1. 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.
2. 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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
