Some organizations may install database servers in several locations that are geographically diverse from each other. For example, a corporation may set up two database servers in two locations (such as New York City and Los Angeles) so that they operate in an autonomous and load-balanced way in a normal situation, but, in case a disaster (such as earthquakes, hurricanes, or terrorist attacks) causes one server to fail, the other server can quickly take over and keep critical functions and services, some of which might have been previously supported by the failed server, uninterrupted. Typically, under such a multi-location scheme, a database server at a location has its own storage subsystem; direct access to such a storage subsystem is not shared with database servers at other locations; and only logical access to data stored in the storage subsystem is allowed to the database servers at the other locations. To provide logical access to data stored in the storage subsystem, copies of files or tables may be provided by the database server that owns the storage subsystem to the database servers in the other locations using file transfer protocols.
In addition to being highly inefficient, these techniques dictate uses of disparate methods to access local and remote data, respectively. As a result, a database server must use disparate calls, APIs and logic flows in handling accesses to the local data and remote data, thereby resulting in much programmatic complexity.
Under some other techniques, a local data storage device may be explicitly exported by its hosting operating system to a remote node that hosts a remote database server. For example, a hard disk that is directly attached to a hosting UNIX system may be explicitly exported by the hosting UNIX system. A remote node that has an appropriate communication link with the hosting UNIX system may mount the exported hard disk on the remote node, using an NFS protocol, thereby enabling remote access to the exported hard disk. However, there may be no direct link between a system that hosts local data storage devices and a remote node. For example, where a Network Attached Storage (NAS) system is used, a local database server that controls direct access to the NAS system may not be the same system as the NAS system itself. The NAS system that hosts the data storage devices may not have any communication link with the remote database server that enables the NFS protocol. Or, for any such reasons as site security, the NAS system may not be configured for exporting through external protocols such as the NFS protocol to any other database servers except the one directly attached.
Therefore, a better mechanism, which would better support network data transfer in distributed database systems, is needed.