|< Day Day Up >|| |
As we've tried to make clear, Streams is not inherently a high-availability technology. The reason for its existence is more about event management systems than anything else. Downhill from event management comes the ability to replicate data very effectively using Streams. This data replication can occur locally-the source and destination database are the same. More likely, the replication takes place between a local source and a remote destination. This type of replication allows for a distributed database environment that allows local copies of centralized data, coupled with the power of data duplication for protection, and user load balancing across multiple databases.
The distributed nature of Streams replication provides us with a unique availability solution. With Streams, a complete copy of a database can be created at a remote site. In this way, it will look very similar to a logical standby database, and that is a fair assessment. However, Streams replication provides more flexibility than the logical standby database. Streams can be set up to exclude certain objects from replicating at the destination, so you are provided performance and space gains.
Streams replication also provides for the possibility of updating production databases at the destination site, and having the changes propagated back to the source. In this way, the disaster failover system also doubles as a secondary load-balancing system, where you can offload certain activities that might interfere with production systems.
When you use Streams to maintain a copy of a database, the destination database is referred to as a replica database, as opposed to a standby database. The replica database differs significantly from the standby in its open and usable nature, and in that the database structure can be significantly different than the source database-even to the point that the database objects are different. With Streams, you can manipulate the incoming LCRs from the source database such that they are inserted into tables with different physical structures. In this way, you can have the same data living in two different formats and used in different ways.
In the case of a disaster at the source database, you can redirect users to the replica database in much the same way you would a standby database. The primary difference between a replica and a standby is that a replica does not contain an exact copy of the system or sysaux tablespaces. The data dictionary of the replica is unique to itself, and the objects that you replicate are unique as well. Only the rows moving from the source are the same.
|< Day Day Up >|| |