Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-05-28
2003-03-11
Robinson, Greta (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06532479
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to distributed database systems and more particularly to replication of data at distributed sites.
BACKGROUND OF THE INVENTION
Modern data processing systems have evolved from a single, centralized mainframe to a network of independent processing systems. The efficiency of such distributed systems depends not only on the processing power of each computer site but on the ability of the system to efficiently access the information required by a user. Generally, a site can access data that resides on local storage much faster than it can access data at another site over a network connection. To take advantage of the efficiency of local access operations, some systems allow the same set of data to be maintained on multiple nodes. The mechanism for maintaining multiple copies of the same body of data at multiple sites is generally referred to as “data replication.” In a distributed database system using data replication, multiple replicas of data exist in more than one database in the distributed database system.
One kind of data replication employs snapshots. A snapshot is a body of data constructed of data from one or more “master” tables, views, or even other snapshots, any of which can be stored locally or remotely relative to the snapshot. The data contained within the snapshot is defined by a query that references one or more master tables (and/or other database objects) and reflects the state of its master tables at a particular point in time. To bring the snapshot up-to-date with respect to the master tables, the snapshot is refreshed upon request, e.g. at a user's command or automatically on a periodic, scheduled basis.
There are two basic approaches for refreshing a snapshot. “Complete refreshing” involves reissuing the defining query for the snapshot and replacing the previous snapshot with the results of the reissued query. “Incremental refresh” or “fast refresh” refers to identifying the changes that have happened to the master tables since the previous refresh (typically, by examining a log file of the changes) and transferring only the data for the rows in the snapshot that have been affected by the master table changes. An “updatable snapshot” is a snapshot to which updates may be directly made at the snapshot site. These updates are propagated from the snapshot back to the master table before refreshing.
High-End Snapshot Replication
Traditionally, snapshots have been implemented for high-end computer systems, which are characterized by the use of high performance computers that are interconnected to one another by highly reliable and high bandwidth network links. Typically, highly experienced database administrators manage these high-end systems. Due to the expense of these high-end computers, high-end distributed systems tend to involve a small number of networked sites, whose users can be trusted at least in part because of the physical security of the computers.
FIG. 12
depicts an exemplary high-end distributed database system for a company's sales department consisting of three sites, master site
1200
, client site
1220
, and client site
1240
. Master site
1200
, which may be located, for example, at the company's headquarters, includes a full relational database server
1202
that is responsible for storing and retrieving data from a relational database
1204
. In this example, relational database
1204
contains a customers master table
1212
and an orders master table
1214
. The customers master table
1212
is illustrative of the data stored in rows for each customer of the company and includes columns for the customer number CUSTNO and the sales representative REP to whom the customer is assigned. For example, customer
13
is assigned to sales representative Smith, and customer
18
is assigned to sales representative Jones. As illustrated, orders master table
1214
holds the data stored in rows for each order that a customer has placed and includes a column ORDER that indicates the number of the order and a CUSTNO column that is correlated to a customer in the customer masters table
1212
. For example, order
25
was placed by customer
13
, and orders
40
and
41
were placed by customer
18
.
In this high-end distributed database system, the client site
1220
is located at one sales office and client site
1240
is located at another sales office, for example in another city. Accordingly, it is desirable to have a copy of the customer and order information at the local site for the sales representatives who are located at the corresponding sales office. For example, if sales representative Smith is located at the sales office for client site
1220
or if sales representative Jones is located at the sales office for client site
1240
, then it would be desirable to store the customer and order information for Smith (and other sales representatives at the same sales office) at client site
1220
and the information for Jones (and coworkers) at client site
1240
.
Therefore, client site
1220
, which also has a full relational database server
1222
, stores snapshots of the customer master table
1212
and the order master table
1214
in local relational database
1224
as customer snapshot
1232
and order snapshot
1234
, respectively. Since only some of the sales representatives are located at the sales office for the client site
1220
, the customer snapshot
1232
and order snapshot
1234
only hold a subset of the data in the customer master table
1212
and the order master table
1214
, respectively. In this example, the customer snapshot
1232
is shown to contain the rows for Smith's customers and the order snapshot
1234
for the corresponding order information. All the information required to maintain and drive the refreshes for the local snapshots
1232
,
1234
, such as the defining queries for the snapshots
1232
,
1234
and the latest refresh times, is kept in snapshot metadata
1226
.
Similarly, client site
1240
also has a full relational database server
1242
and stores snapshots of the customer master table
1212
and the order master table
1214
in local relational database
1244
as customer snapshot
1252
and order snapshot
1254
, respectively. Since different sales representatives are located at the sales office for the client site
1240
, the customer snapshot
1252
and order snapshot
1254
maintain a different subset of the data in customer master table
1212
and order master table
1214
, respectively. Shown in this example, customer snapshot
1252
contains the rows for Jones's customers and order snapshot
1254
contains the corresponding order information. All the information required to maintain and drive the refreshes for the local snapshots
1252
,
1254
, such as the defining queries for the snapshots
1252
,
1254
and the latest refresh times, is kept in snapshot metadata
1256
.
For a more detailed description of how a snapshot is refreshed in one high-end snapshot replication environment, the reader is referred to the commonly assigned U.S. patent application Ser. No. 08/865,645, entitled “Fast Refresh of Snapshots” filed on May 30, 1997 by Harry Sun, Alan Downing, and Benny Souder, now U.S. Pat. No. 5,963,959 issued Oct. 4, 1999, the contents of which are incorporated by reference in their entirety herein.
FIG. 13
, however, is provided to briefly illustrate some of the operations involved in refreshing a snapshot in an exemplary high-end environment.
In response to one or more refresh requests, the client database server
1222
iterates through a series of doubly nested loops, first for each snapshot for which the requests were made and then for each base or master table used by the snapshot. In the doubly nested loop controlled by step
1300
, the client database server
1222
sends a “Set Up” remote procedure call (RPC) to the master site
1200
(step
1302
). When the master site
1200
receives the Set Up RPC call, the master database server
1202
performs the remotely called set up operation (step
1304
). The
Demers Alan J.
Downing Alan Robert
Elsbernd Curtis
Graham John C.
Smith Wayne E.
Black Linh
Ditthavong & Carlson P.C.
Oracle Corp.
Robinson Greta
LandOfFree
Data replication for front office automation does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Data replication for front office automation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Data replication for front office automation will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3051036