Building indexes on columns containing large objects

Details Building indexes on columns containing large objects Building indexes on columns containing large objects

1999-09-24

2001-06-05

Alam, Hosain T. (Department: 2172)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C707S793000, C707S793000

Reexamination Certificate

active

06243718

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to database systems, and more specifically, to techniques for handling large objects (LOBs) within a client server database system.
BACKGROUND OF THE INVENTION
Recently a trend has developed to expand database systems to handle non- traditional data types (e.g. images, text, and audio data). In particular, it has become important to provide database systems that handle user-defined “large objects” (LOBs). LOBs may be much larger than traditional data types. For example, a single LOB may include four gigabytes of data.
Because of their size, LOBs cannot be efficiently handled with the same techniques used to handle traditional data types. For example, conventional database systems consist of one or more clients (“database applications”) and a server (a “database server”). When a client requires data, the client submits a query to the server that selects the data. The server retrieves the selected data from a database and returns copies of the selected data to the client that submitted the query. When the selected data items are LOBs, the amount of data that would be returned to the user could be enormous. Consequently, automatically sending an entire LOB would be inefficient and time consuming, particularly when the client is only interested in viewing or updating a relatively small subset of the entire LOB.
The size of LOBs also results in space management difficulties within the database system. In typical database systems, it is important to be able to supply data items as they existed at a particular point in time. To do this, database systems typically time, or store multiple versions of data items. In either case, the amount of data that would have to be stored to support LOBs could be enormous. The storage usage problems thus created can be mitigated by reclaiming space that is no longer required by LOBs. Consequently, it is clearly desirable to provide a mechanism for efficiently maintaining information about storage that can be re-used after the LOB data contained thereon is no longer needed.
LOB data may also be thought of as a file or a stream of characters or bytes. Applications are used to storing and accessing large amounts of data in a file, and the same is expected from LOBs. As in file access, applications require random, sequential piecewise access to LOB data. Also, file operations seldom copy the whole file, and the same behavior is expected of LOB operations.
One approach to handling LOBs may be to deliver to a client only a subset of the LOB. However, conventional retrieval mechanisms are designed to provide fast access to entire sets data items, such as rows, and not sub-portions of individual data items. Thus, even after a LOB is located, the time it would take to scan through the LOB to retrieve a particular subset of interest may be unacceptably long.
Another difficulty presented by the size of LOBs relates to how users are provided consistent views of a database that includes LOBs. Specifically, some database systems provide consistent views of the database to users by generating undo records when data items are updated. When applied to an updated item, the undo record reconstructs the data item as it existed before the update. Consequently, a user can be shown the database as of a particular point in time by applying one or more undo records to data items requested by a user that have been updated since that point in time.
Unfortunately, as a general rule, the larger the updated data item, the larger the undo record that must be generated in order to undo the update. Consequently, generating undo records for LOBs is inefficient and impractical due to the amount of data that would have to be generated and stored in response to every update.
Based on the foregoing, it is clearly desirable to provide a mechanism to efficiently access LOBs and desired portions within LOBs. It is further desirable to provide a mechanism for reconstructing a consistent view of a database that includes LOBs.
SUMMARY OF THE INVENTION
According to one aspect of the invention, a method is provided for accessing data that belongs to a particular snapshot. According to the method, an index is used to locate an index entry associated with the data. One or more undo records are applied to the index entry to reconstruct a non-current version of the index entry. Location information is read from the non-current version of the index entry. Finally, a non-current version of the data stored at a location identified by the location information is accessed, wherein both the non-current version of the index entry and the non-current version of the data belong to the particular snapshot.
According to another aspect of the invention, a method is provided for accessing large objects (LOBs) that belong to a column of a table. According to the method, an index is built on the column, the index including index entries that contain pointers to blocks containing LOB data associated with the LOBs. If a first parameter is set to a first value, then a locator is stored for each LOB in the table, wherein each locator includes a LOB identifier and a version number for a corresponding LOB, and LOB data is stored for each LOB out of the table. If the first parameter is set to a second value, then a locator is stored for each LOB in the table. Finally, LOB data is stored in the table for at least a subset of the LOBs that belong to the column.
According to another aspect of the invention, a method is provided for accessing large objects (LOBs) that belong to a column of a table. The method includes building an index on the column, wherein the index includes index entries that contain pointers to blocks containing LOB data associated with the LOBs. Then, a locator is stored for each LOB in the table, wherein each locator includes a LOB identifier and a version number for a corresponding LOB. Finally, a plurality of pointers is stored within at least one cell in the column, where each pointer of the plurality of pointers points to a LOB chunk of a LOB that belongs to the cell.


REFERENCES:
patent: 5109487 (1992-04-01), Ohgomori et al.
patent: 5347653 (1994-09-01), Flynn et al.
patent: 5566329 (1996-10-01), Gainer et al.
patent: 5678046 (1997-10-01), Cahill et al.
patent: 5732402 (1998-03-01), Lehman
patent: 5742810 (1998-04-01), Ng et al.
patent: 5857203 (1999-01-01), Kauffman et al.
patent: 5864849 (1999-01-01), Bohannon et al.
patent: 5905506 (1999-05-01), Hamburg
patent: 5983229 (1999-11-01), Houchin et al.
patent: 5999943 (1999-12-01), Nori et al.
patent: 6061678 (2000-05-01), Klein et al.
patent: 6125371 (2000-09-01), Bohannon et al.
Lehman, et al., DB2 LOBs: The Teenage Years, IEEE Computer Society Press, pp. 192-199, 1996.
Biliris, An Efficient Database Storage Structure for Large Dynamic Objects, Proceedings of the 1992 International Conference on Data Engineering, USA, IEEE Computer Society Press, pp. 301-308.
Campbell, et al., “The Role of Database Systems in the Management of Multimedia Information”, Multi media Database Management Systems, 1995. Proceedings., International Workshop, pp. 4-11.

Affiliated with

Also associated with

Rating

Building indexes on columns containing large objects does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Building indexes on columns containing large objects, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Building indexes on columns containing large objects will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2516161