Writable shared database objects

A system may include a provider database, a reader database, and a database management system. The provider database may include a provider data area having a plurality of provider block addresses, and the reader database may include a reader data area having a plurality of reader block addresses, and a mapping of provider-specific identifiers to block addresses of the plurality of provider data pages and of reader-specific identifiers to block addresses of the plurality of reader data pages. The database management system may modify a database object of the reader database, the object being is associated with a provider-specific identifier; and modify the mapping to map the provider-specific identifier to a first block address of one of the plurality of reader data pages.

FIELD

Some embodiments relate to modifying objects stored within a database system. In particular, some embodiments concern modifying database objects imported from a provider database.

BACKGROUND

A conventional database-driven system may include several computing environments, each consisting of one or more applications and a database instance storing data associated with the one or more applications. Such a system may, for example, provide online transaction processing for several different vendors. More specifically, each computing environment may store data specific to a particular vendor and may be responsible for processing online transactions on behalf of the vendor.

A system as described above typically stores a significant amount of identical data across each database instance. This identical data may comprise static data unrelated to any specific vendor, such as payment processing data, shipping data, etc. Duplicative storage of this data is inefficient, particularly if this duplication is not intended for backup or redundancy. Moreover, the entire portion of static data must be recreated each time an additional environment is required (e.g., to support an additional vendor).

Commonly-owned U.S. patent application Ser. No. 11/715,777, entitled “Sharing of Database Objects”, describes a system in which one or more “reader” databases may efficiently import and read shared database objects stored in a common “provider” database. Such a system may reduce a need to duplicate the shared database objects within the reader databases.

It may be desirable to provide write access to a shared database object imported by a reader database. Preferably, the write access is transparent to the applications of the reader database (i.e., the applications need not be aware that the database object was shared by and imported from the provider database), and should not affect the original shared database object of the provider database or other instances of the database object within other reader databases.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a software architecture according to some embodiments. The architecture includes provider database instance100and reader database instances110,120,130and140. In some embodiments, reader database instances110,120,130and140are capable of accessing data of provider database instance100directly. The data may, according to some embodiments, be accessed while database management system101of provider database instance100is not executing.

A database instance, generally, includes at least one operating system process, a physical data storage unit and a block of main memory (e.g., Random Access Memory). These components are represented in the database instances ofFIG. 1by a database management system (DBMS), a data area and an I/O buffer, respectively. The present description will use the terms “database” and “database instance” interchangeably.

Each illustrated DBMS may comprise any system for managing a database instance that is or becomes known. Generally, a DBMS may receive requests for data (e.g., Structured Query Language (SQL) requests from a database application), may retrieve requested data from its local data area, and may return the requested data to the requestor. A DBMS may also perform start-up, logging, recovery, management, optimization, monitoring and other database-related tasks.

A data area may comprise one or more disparate physical systems for storing data. The data of a data area may include database objects and associated index entries (i.e., application data), as well as configuration files, system files, converter pages, database parameters, paths, user information and any other suitable information. The database objects may include tables, indexes, views, users and user groups. A data area may also store a database catalog including metadata associated with the database objects that are stored within the data area.

According to some embodiments, at least one of reader database instances110,120,130and140may access data area102of provider database instance100. This access allows the at least one reader database instance to read the configuration files, file directory, converter pages and other elements of provider database instance100that may be required to read the database objects of provider database instance100. Some embodiments providing such access will be described in detail below.

An I/O buffer cache stores various elements of the data area during execution of its associated database instance. These elements may include recently-accessed pages of application data, current converter pages, database catalog objects and/or a log queue.

Some embodiments may include more or fewer than the four pictured reader database instances. In some embodiments, a single reader database instance may be capable of accessing data of two or more provider database instances.

Any of theFIG. 1database instances may communicate with one or more database applications (not shown) over one or more interfaces provided by its DBMS. The applications may provide business monitoring, inventory control, online shopping, and/or any other suitable functions. The applications may, in turn, support client applications that may be executed by client devices. Such a client application may simply comprise a Web browser to access and display reports generated by a database application.

Database instances100,110,120,130and140may receive data from disparate hardware and software systems, some of which are not interoperational with one another. The systems may comprise a back-end data environment employed in a business or industrial context. The data may be pushed to the database instances and/or provided in response to queries received therefrom.

TheFIG. 1database instances may also include other unshown elements that may be used during operation thereof, such as any suitable program code, scripts, or other functional data that is executable to interface with other elements, other applications, other data files, operating system files, and device drivers. These elements are known to those in the art, and are therefore not described in detail herein.

Two or more of the database instances ofFIG. 1may be located remote from one another and may communicate with one another via a computer network and/or a dedicated connection. Moreover, each displayed element ofFIG. 1may comprise any number of hardware and/or software elements, some of which are located remote from each other.

Elements described herein as communicating with one another are directly or indirectly capable of communicating over any number of different systems for transferring data, including but not limited to shared memory communication, a local area network, a wide area network, a telephone network, a cellular network, a fiber-optic network, a satellite network, an infrared network, a radio frequency network, and any other type of network that may be used to transmit information between devices. Moreover, communication between systems may proceed over any one or more transmission protocols that are or become known, such as Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP) and Wireless Application Protocol (WAP).

FIG. 2is a detailed block diagram of provider database instance100and reader database instance110according to some embodiments. I/O buffer cache103is omitted fromFIG. 2because the foregoing explanation presumes that DBMS101of provider database instance100is not executing.

As described above, data volumes1024may comprise not only database objects but also converter pages and a database catalog including metadata associated with tables, indexes, views, users and user groups that are stored within the data area. A data volume may comprise a portion of a physical hard disk, an entire physical hard disk, or a storage system composed of several physical hard disks.

Data volumes1024are subdivided into storage areas known as blocks. Also, the data stored in data volumes1024is stored in logical pages having the same size as a block. Accordingly, a page of data volumes1024may be accessed by referencing a data volume and a block address of the data volume.

Data area102may include more or fewer data volumes than illustrated inFIG. 2. Database instance100may also store log volumes in a log area (not shown). Such log volumes store information indicating changes made to stored data. The information may be used for returning database instance100to a consistent state after a system crash.

DBMS111and data area112of reader database instance110may be configured similarly to DBMS101and data area102of provider database instance100. In some embodiments, DBMS111includes an SQL manager to process received SQL statements and a data access manager to manage access to stored data. Since reader database instance110will be executing in the forthcoming operational example,FIG. 2also includes I/O buffer cache113of database instance110.

I/O buffer cache113is used to manage memory that is available for I/O operations. I/O buffer cache113includes data cache1132and converter1134. Generally, data cache1132stores pages from data area112that have been recently read or write-accessed. If a transaction changes a page, the changed page is initially saved in data cache1132while the previous version of the page remains in data area112. At various intervals (e.g., if data cache1132reaches a threshold fullness or if a savepoint is scheduled), the changed data page is written to a location of one of data volumes1124.

The aforementioned database catalog may map a name of each database object to a unique file identifier (ID). Data volumes1124may also include a file directory which maps file IDs to logical page numbers. The information of the database catalog and the file directory may therefore be used to determine a logical page number from a name of a database object. Once the page number is known, converter1134may be used to determine a block address at which the database object is stored.

In this regard, converter1134associates logical page numbers of data area112with physical block addresses of data volumes1124. For a given page number, converter1134indicates a block address (e.g., a data volume number and an offset) at which an associated page is stored in data volumes1124. In a case that DBMS111cannot find a page in data cache1132, converter1134is accessed to determine a location of the page in data volumes1124based on the page's number.

Converter1134according to some embodiments includes converter map table0, converter map table1, converter pages0and converter pages1. Converter map table0and converter pages0are used to determine block addresses for each logical page number associated with database110, while converter map table1and converter pages1are used to determine block addresses for each logical page number associated with database100. As will be described below, a database object having a logical page number associated with database100may be stored at a block address of database110.

For example, converter map table0maps a logical page number associated with database110to a memory address of I/O buffer cache113at which a converter page associated with the page number is located. The associated converter page, in turn, indicates a data volume and a block address for the logical page number. Each of converter pages0also indicates a data volume and a block address at which the converter page is stored in data volumes1124. One or more of converter pages1may be stored in data volumes1024and/or data volumes1124according to some embodiments, as will be described below.

Data cache1132and converter1134are illustrated separately inFIG. 2for the sake of clarity. According to some embodiments, data cache1132and converter1134might not comprise separate, contiguous memory addresses of I/O buffer cache113. For example, converter pages0may be interspersed among the data pages throughout I/O buffer cache113.

Detailed examples of the foregoing elements according to some embodiments will be provided with respect toFIGS. 4A through 7. Usage of the elements to read a database object will also be described. Moreover, some embodiments will be described which provide efficient write access to a database object having an identifier associated with a provider database.

FIG. 3is a flow diagram of process300according to some embodiments. Some embodiments of process300may provide a reader database instance with write access to database objects read from a provider database instance. In some embodiments, a hardware environment of database instance110executes program code of DBMS111to perform process300. Process300may be performed in response to a command received from a database client (not shown), or may be initiated by a thread of DBMS111.

Process300and all other processes mentioned herein may be embodied in processor-executable program code read from one or more of a computer-readable medium, such as a floppy disk, a CD-ROM, a DVD-ROM, a Zip™ disk, a magnetic tape, and a signal encoding the process, and then stored in a compressed, uncompiled and/or encrypted format. In some embodiments, hard-wired circuitry may be used in place of, or in combination with, program code for implementation of processes according to some embodiments. Embodiments are therefore not limited to any specific combination of hardware and software.

A database object of a reader database is modified at S310. An identifier of the database object is associated with a provider database. The identifier may comprise a file ID, a page number, or any other identifier that may be associated with a database object. The identifier may be associated with the provider database (e.g., database100) using any suitable convention, including but not limited to those described below.

According to some embodiments of S310, DBMS111locates a data page associated with the database object in data cache1132. If the data page is not located in data cache1132, DBMS111may use converter map table1and converter pages1to locate the data page within data volumes1024of provider database100, and may subsequently read the database object into data cache1132. As described above, DBMS111uses converter map table1and converter pages1because the identifier of the database object is associated with provider database100. DBMS111then performs a write operation to modify the database object within data cache1132.

Next, at S320, the identifier is mapped to a block address of the reader database. In some embodiments, this mapping comprises re-mapping the identifier from a block address of data volumes1024to a block address of data volumes1124. The identifier may remain unchanged (i.e., associated with the provider database100) according to some embodiments, but will thereafter refer to a block address of data volumes1124instead of a block address of data volumes1024.

Some embodiments of the foregoing provide reader database110with efficient write and/or read access to the modified database object. Although the identifier of the database object continues to reference provider database100, the modified database object will be stored in reader database110and may be accessed by standard mechanisms thereof. Moreover, in some embodiments, the modification will not be visible to other reader databases (e.g.120,130,140) and will not affect their access to the original version of the database object stored in data volumes1024of provider database100.

FIGS. 4A through 7provide particular examples of elements of theFIG. 2embodiment. The examples may be used in conjunction with embodiments different from that illustrated inFIG. 2. In this regard,FIG. 4Aillustrates portion of converter pages0according to some embodiments. Converter pages0may comprise many more pages and each page may include many more entries than illustrated.

Each of converter pages0provides a mapping of logical page numbers to respective block addresses of data area112. As described above, each data object is associated with a file identifier, which in turn is associated with a logical page number. Accordingly, once the page number of a data object is known, converter pages0may be used to determine a block address at which the data object is stored.

The block addresses are represented as a volume number/offset, with the volume number referring to one of volumes1124. Each converter page also specifies a block address at which it is stored within data volumes1124. Each page number and block address ofFIG. 4Ais prefaced with an index “0:”. The index associates the page numbers and block addresses with reader database110. More specifically, the index indicates that the volume specified by each block address is a volume of data area112, and not a volume of data area102or another data area. The index associated with a particular page number indicates whether to use converter map table0or converter map table1to locate the associated data object.

Converter pages1ofFIG. 4Bassociate logical page numbers with respective block addresses of data area102. The index “1:” of each block address indicates that the specified volume is a volume of data area102, and the index “1:” of each page number indicates that converter map table1should be used to locate the associated data object.

Generally, page numbers and block addresses beginning with “0:” may be referred to as reader-specific, while those beginning with “1:” may be referred to as provider-specific. As described in aforementioned U.S. patent application Ser. No. 11/715,777, the indicies may assist in preventing confusion between otherwise identically-numbered logical pages or data volumes of provider database100and reader database110.

The indicies may be added to the page numbers and block addresses as described in application Ser. No. 11/715,777, the contents of which are incorporated by reference for all purposes. Embodiments are not limited to the methods described therein.

FIG. 5illustrates tabular representations of converter map table1and converter pages1to provide background for the forthcoming description. As shown, converter map table1specifies several ranges of provider-specific logical page numbers. Converter map table1associates a memory address of I/O buffer cache113with each specified range. As also shown, stored at each memory address is one of converter pages1that lists page numbers in the range associated with each address.

FIG. 6illustrates a mapping of file identifiers to logical page numbers. The mapping associates identifiers of provider database100with logical page numbers of provider database100, and identifiers of reader database110with logical page numbers of reader database110. As shown, provider database100and reader database110may use one or more identical file identifiers and page numbers.

The mapping may comprise a file directory of database instance110. Data volumes1124of database instance110may include a system table FILES which provides, for each internal database object, a file identifier and a logical page number of the file root. The file identifiers and the page numbers prefaced with the index “1:” are associated with provider database100. As will be described below, a database object associated with such file identifiers or page numbers may be stored at a block address of data volumes1124of reader database110.

FIG. 7is a tabular representation of a portion of a database catalog of reader database110according to some embodiments. The database catalog associates each of the file identifiers ofFIG. 6with an object name and other metadata. The database catalog may be stored in data volumes1124and may include all or any subset of object metadata associated with the provider-specific file identifiers.

The logical page numbers, block addresses, file identifiers, database object names, and object metadata of provider database100may be indexed and incorporated into converter1134, a file directory and a database catalog of database110as described in application Ser. No. 11/715,777, the contents of which are incorporated by reference for all purposes. The index “0:” may also be added to the logical page numbers, block addresses, and file identifiers of reader database110as described in application Ser. No. 11/715,777. Embodiments are not, however, limited to the methods described therein.

FIG. 8comprises a flow diagram of process800according to some embodiments. Process800will be described with respect to the above-described elements ofFIGS. 4A through 7, but embodiments are not limited thereto.

Prior to process800, and as described in detail in application Ser. No. 11/715,777, DBMS111may read configuration files1022of data area102. In order to facilitate reading of configuration files1022, DBMS111is provided with a path to configuration files1022. DBMS111is also provided with access to the physical storage unit which stores configuration files1022. In some embodiments, configuration files1022are stored in an <independent_data_path>/config directory of the physical storage unit.

Configuration files1022include the names of each of data volumes1024as well as their respective data paths. DBMS111uses this information to read the converter pages of provider database100stored in data volumes1024. The converter pages provide a mapping of logical page numbers of provider database100to block addresses within data volumes1024. DBMS111generates converter map table1and converter pages1as shown inFIG. 4Bbased on the read converter pages of provider database100. DBMS111may also generate converter map table0and converter pages0as shown inFIG. 4A.

Next, DBMS111reads a file directory of database instance100to acquire a mapping of provider-specific file identifiers to provider-specific page numbers. The provider-specific file identifiers and provider-specific page numbers may be indexed with “1:” and added to a file directory of reader database110as shown inFIG. 6. The reader-specific file identifiers and page numbers of the file directory may also be indexed with “0:” as shown.

DBMS may then use the file directory of database110to scan the database catalog of provider database100for shared database objects. In this regard, the database catalog of provider database100may flag one or more database objects as sharable. The shared database objects are then included in a local database catalog of reader database110as shown inFIG. 7.

Process800may commence in response to an instruction to modify a database object stored in a reader database cache. Although the database object is stored in the reader database, an identifier of the database object is associated with a block address of a provider database data area. The database object is modified at S810.

According to some embodiments of S810, DBMS111receives an instruction to modify a database object having a particular object name. DBMS111consults the database catalog of reader database110to determine a file identifier associated with the object name. Next, DBMS111accesses its file directory to determine a page number associated with the file identifier. Referring to theFIG. 6example, the logical page number and the file identifier are prefaced with “1:”.

DBMS111uses the logical page number to attempt to locate a data page associated with the database object in data cache1132. If the data page is not located in data cache1132, DBMS111uses converter map table1and converter pages1to locate the data page within data volumes1024of provider database100, and subsequently reads the database object into data cache1132. DBMS111uses converter map table1and converter pages1because the page number is prefaced by “1:” and is therefore associated with a block address of data are102. DBMS111then performs a write operation to modify the database object within data cache1132.

The modified database object is written to a block address of data area112at S820. In this regard, and in accordance with a “shadow memory” feature, DBMS111may write all modified pages in cache113to data area112once a number of modified pages reaches a threshold amount, or after passage of a designated time interval. The modified pages are not written to the block addresses of the data volumes from which they were read. Rather, each original unmodified page remains at its respective block address and the modified page is written to a new block address of data112.

A converter page is modified at S830to associate the database object with the block address to which the modified database object was written at S820. For example, DBMS111initially locates a converter page associated with the modified database object. As described above, converter map table1is consulted to determine a location of a converter page which is associated with the database object.

FIG. 9illustrates converter page900which is associated with logical page numbers 1:6,000 through 1:7,999. It will be assumed that the logical page number associated with the modified database object is 1:6111. Accordingly, at S830, block address910is changed from the block address shown inFIG. 4B(i.e., 1:1/300) to a block address of reader database data area110(i.e., 0:2/1255) to which the modified database object was written. Neither the file identifier nor the logical page number of the database object is changed, and therefore both remain associated with provider database100(i.e., prefaced with “1:”).

The modified converter page is written to a second block address of the reader database area at S840. Again, the modified converter page may be written to a block address of data area112once a number of modified pages in cache113reaches a threshold amount, or after passage of a designated time interval. For example, converter page900may be written to a block address of data volumes1124at S840.

The converter page is associated with the second block address at S850.FIG. 10illustrates changing block address920of converter page900in order to associate converter page900with the block address to which converter page900was written at S840. The changed converter page may reside in a new address of cache113after S850. Accordingly, converter map table1may be modified to point to the new address (e.g., address T) as shown inFIG. 11.

As a result of the foregoing, the modified database object will be stored in reader database110and may be accessed by standard mechanisms thereof, even though the file identifier and/or logical page number of the database object is associated with provider database100. The modification also does not affect the original version of the database object stored in data volumes1024of provider database100.

The embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations limited only by the claims.