Home » RDBMS Server » Server Administration » Central Server Architecture
Central Server Architecture [message #109212] Tue, 22 February 2005 22:26 Go to next message
kamalc
Messages: 3
Registered: February 2005
Junior Member
Hi Friends,

This is a request for suggestions & inputs required by us. I was searching for a proper forum, and finally, decided to put it here. I might have put it in the wrong forum and I am sorry for that. Well, we are actually trying to setup a remote access architecture for our application. Our scenerio, as decided, is like this :

we have an application running on central 9iAS, at a central location (called HO). We have 34 Regions in different locations and different users are going to access our application in HO through VSAT. We have also planned for a set of HO user where all the Global Data (Common to all the 34 regions) will be maintained in the 9i Database. 34 regions are differentiated by their specific ID's. We are planning to setup an architecture where all of these 34 Regions are going to access our central 9i database, remotely, through VSAT connection. Our application server, where the Oracle Application resides, will also be kept at the Central location at HO. We have thought of having 34 Different database schemas for the 34 different regions to be setup in the Central Server with a set of users of each of the region. The Database Backup & recovery process has also been planned accordingly to initiate a backup & recovery process for all the 34 regions from the central location, schema wise.

my question to the forum is whether this architecture (Having 34 different schemas for 34 regions) is a feasible and possible architecture to implement or are there any other options that can be suggested to have better performance as all of these 34 regions will have a huge volume of data on a periodic basis and all of these 34 regions are also to initiate a number of periodic as well as adhoc report requests to the 9iAS server as we have planned the Report Server to be running on the central location.

Do you all think that this solution is workable enough ?

Rgds.
Kamal
Re: Central Server Architecture [message #109229 is a reply to message #109212] Wed, 23 February 2005 01:47 Go to previous messageGo to next message
Frank
Messages: 7901
Registered: March 2000
Senior Member
If I understand you well, these 34 schemas will all contain a copy of the same application.
If so, have you considered Fine Grained Access Control (FGAC, or as it was known before Virtual Private Database)? With FGAC you put all data into 1 schema and add predicates.
See this discussion for more info.

hth
Re: Central Server Architecture [message #109236 is a reply to message #109229] Wed, 23 February 2005 02:43 Go to previous message
kamalc
Messages: 3
Registered: February 2005
Junior Member
Hi Frank,

Thanx a lot for your suggestion. I did get your suggestion and the point ! Let me tell you the reason why we have thought of having 34 schemas :

1. Suppose, due to some reason, we are having some problem in one location so, we don't need to shutdown the entire operation, rather, the other sites can continue normal operation till we repair the problemetic location. As per your suggested option, we might have to face the situation of closing the entire operation of all the locations as we have a single database with single schema. (Your comments Pls.)

2. In case of the Central server architecture, as per you suggestion, the data for all the 34 regions will go into single table ( we have around 835 Database Tables). So, the query and other transaction fetch time (Involves complicated processing for some functional areas) will increase (i suppose).

3. Pls. note that 34 locations will fire report requests (involving simple To very complex queries). we have one report server running on 9iAS.

4. For your information, we already have the application running on 9iAS but have different Databases created in different locations individually (having the same structures in a single schema etc.). We do have catered something like COMPANY_ID and the same exists in almost all the tables. As we were not very confident on this creation and we didn't want/ Don't want to touch our application, we have decided to go for the 34 SCHEMA method.

Overall, pls. give some more suggestions or better ideas for the requirement so that we don't have to really do anything on the application side and go for the central server architecture.

Thanx
Kamal
Previous Topic: Unable to start Oracle database service in Windows XP
Next Topic: change in table space
Goto Forum:
  


Current Time: Fri Sep 27 04:22:54 CDT 2024