|
|
|||||
|
|||||
STEP 6: The RTA Fault-Tolerant ArchitectureLet's say you have numerous real-time frontends that are either configured as blind nodes and/or operator consoles and you want to connect these frontends directly to your central database system via the enterprise network. The frontends need to be up and running 24/7, even if the network connection or the central server goes down. And of course you don't want to loose any of the information collected by the frontends, even if the server or networks is down. How would you do that? RTA has a solution for this. RTA can be configured to run against an ORACLE database via SQL*NET in a 'fault-tolerant' mode. In this mode RTA will operate normal as long as the SQL*NET connection to ORACLE is up and running. This means it will load all data from ORACLE during startup and once up and running synchronize all changes between RtDB and the ORACLE database in real-time. If the connection to the ORACLE database gets lost, RTA will continue normal operation and simply defer all 'direct' DML operations to ORACLE. Direct SELECT statements are of course not possible during this time. All applications that use only RtDB and not the direct ORACLE interface (which is the better approach but not always feasible) are not affected at all. They will continue normal operations without any limitations because RtDB runs locally and is still available, even if the SQL*NET connection goes down. As soon as the connection comes back online all data is automatically resynchronized. The whole procedure is transparent for the application programmer. RTA achieves this functionality by constantly replicating all RtDB tables on files on the local harddrive in addition to the ORACLE synchronization. If SQL*NET goes down RtDB operates only on these files until the connection is up again. This architecture allows for a loose coupling of the RTA nodes and the ORACLE server thus improving the overall system reliability and production up time in 24/7 environments.
|