Hi,
Please advise me.
I have site USA having production server of EBS 11.5.10 on Redhat AS4. Currently users from site UK are remotely connected to site USA.
Now network between two sites breaks, how we can prepare any solution if network is not available. Users of USA site can continue work on system and same time users of UK site can also continue work on production system and when network restored there transactions from both sites can be synchronized.
Best Regards
EBS server on two locations
-
kashifkamyana
- Posts: 3
- Joined: Mon Apr 16, 2007 1:10 am
- Location: Pakistan
http://www.oracle.com/technology/produc ... apr04.html
Materialized views, known as snapshots in prior releases, are used to replicate data to non-master sites in a replication environment. Updatable materialized views enable users to maintain data at their local site (even a mobile user with a laptop) and later resynchronize with main site by applying the local changes to the master site and retrieving the any changed data for the materialized view site from the master site.
With Oracle9i Replication, you can create multiple tiers, or levels, of materialized views. This multitier capability offers greater flexibility in the design of a replication environment. Multitier materialized views are useful in a variety of situations, including:
* Branch Office configurations
* Sales Force Automation applications
* Indirect connectivity situations
Multitier materialized views are ideal for organizations structured on three or more levels or in situations constrained by network resources. As an example, in the Corporate Headquarters(HQ), Regional Office, Branch Office configuration in the picture above, the Branch office has no direct network connectivity requirement to the Headquarters site. Alternatively, mutlitier materialized views can be configured to restrict the data available at each site. For example, the replication environment can be configured so that the Headquarters office maintains all of the data, the Regional office maintains the data necessary to support the customers in the particular region, and the Branch office receives a further subset of the data from the Regional office - only the information necessary to support the Branch office. Similarly, another materialized view can be created from the Branch Office to facilitate a salesperson's ability to view and maintain information on individual customers even when disconnected from the company network.
In a multiter updatable materialized view configuration, you can create an updatable materialized view based on another updatable materialized view. Each middle tier updatable materialized view performs as a replication master site for any subsequent updatable materialized views and can refresh the data incrementally, ie, retrieve only the changes since the last resynchronization with the master site. Each materialized view that acts as a master is known as a master materialized view, performing conflict detection and resolution for any updates that come from the subsequent materialized view sites. If a change that originated from a lower level site (for example, the Branch office) is rejected, the data values of the parent master materialized view (the Regional Office) are refreshed to the lower-level site (Branch Office) via the normal refresh mechanism. Changes percolate up to the top-level sites by successive refreshes of the intermediate level sites.
It's a bit tricky job for Oracle Application database but it's possible though. The one who is at expert level in replication can do this task easily.
Thanks
Amir
Materialized views, known as snapshots in prior releases, are used to replicate data to non-master sites in a replication environment. Updatable materialized views enable users to maintain data at their local site (even a mobile user with a laptop) and later resynchronize with main site by applying the local changes to the master site and retrieving the any changed data for the materialized view site from the master site.
With Oracle9i Replication, you can create multiple tiers, or levels, of materialized views. This multitier capability offers greater flexibility in the design of a replication environment. Multitier materialized views are useful in a variety of situations, including:
* Branch Office configurations
* Sales Force Automation applications
* Indirect connectivity situations
Multitier materialized views are ideal for organizations structured on three or more levels or in situations constrained by network resources. As an example, in the Corporate Headquarters(HQ), Regional Office, Branch Office configuration in the picture above, the Branch office has no direct network connectivity requirement to the Headquarters site. Alternatively, mutlitier materialized views can be configured to restrict the data available at each site. For example, the replication environment can be configured so that the Headquarters office maintains all of the data, the Regional office maintains the data necessary to support the customers in the particular region, and the Branch office receives a further subset of the data from the Regional office - only the information necessary to support the Branch office. Similarly, another materialized view can be created from the Branch Office to facilitate a salesperson's ability to view and maintain information on individual customers even when disconnected from the company network.
In a multiter updatable materialized view configuration, you can create an updatable materialized view based on another updatable materialized view. Each middle tier updatable materialized view performs as a replication master site for any subsequent updatable materialized views and can refresh the data incrementally, ie, retrieve only the changes since the last resynchronization with the master site. Each materialized view that acts as a master is known as a master materialized view, performing conflict detection and resolution for any updates that come from the subsequent materialized view sites. If a change that originated from a lower level site (for example, the Branch office) is rejected, the data values of the parent master materialized view (the Regional Office) are refreshed to the lower-level site (Branch Office) via the normal refresh mechanism. Changes percolate up to the top-level sites by successive refreshes of the intermediate level sites.
It's a bit tricky job for Oracle Application database but it's possible though. The one who is at expert level in replication can do this task easily.
Thanks
Amir
Who is online
Users browsing this forum: No registered users and 0 guests