patternMinor
Best method to give two Oracle databases on the same server access to common data
Viewed 0 times
samethedatabasesmethodgivetwoserveroracledatacommon
Problem
With a production and a test database on the same server, how should access be provided to some common quarterly update tables for both databases?
It is possible to put these tables into a third database, let us call it catalogs, but then the tables within catalogs can't be accessed as efficiently as if the tables where directly in production or test. On the other hand, space is saved, as there is only one copy of the data.
I see the following two options
both database instances. That gives efficient access, but
duplicates space requirements and work to maintain the catalogs
catalogs and access this via database
links. This saves space, but what about performance.
Which of these solution is better?
Edit:
Some further information:
Catalog has about 60 tables using less than 1GB tablespace.
There are functions to be defined in the katalog schema and indexing is important.
It is possible to put these tables into a third database, let us call it catalogs, but then the tables within catalogs can't be accessed as efficiently as if the tables where directly in production or test. On the other hand, space is saved, as there is only one copy of the data.
I see the following two options
- add a user and schema for catalog to
both database instances. That gives efficient access, but
duplicates space requirements and work to maintain the catalogs
- add a third database instance for
catalogs and access this via database
links. This saves space, but what about performance.
Which of these solution is better?
Edit:
Some further information:
Catalog has about 60 tables using less than 1GB tablespace.
There are functions to be defined in the katalog schema and indexing is important.
Solution
You could store the catalogs tables in a separate schema on production. test could then have a schema with the same name that uses views that select from the production tables using a database link. This would make production fast because the data is local without requiring extra space.
If you decided that a particular table was too slow to access over the database link or having too great of an impact on production, then you could create a materialized view on test instead of a view. You could create as many or as few of these as necessary to give the best balance of space and performance.
On the other hand, 1GB isn't that much space, so you might be better off importing into both databases even though it would double the space requirements. It would have a speed advantage and would make test more like production.
If you decided that a particular table was too slow to access over the database link or having too great of an impact on production, then you could create a materialized view on test instead of a view. You could create as many or as few of these as necessary to give the best balance of space and performance.
On the other hand, 1GB isn't that much space, so you might be better off importing into both databases even though it would double the space requirements. It would have a speed advantage and would make test more like production.
Context
StackExchange Database Administrators Q#1243, answer score: 4
Revisions (0)
No revisions yet.