Producing an image copy of a database object based on information within database buffer pools

According to one embodiment of the present invention, a system includes a processor to copy an object of a database system. The system determines one or more portions of the object that are active and reside within a buffer pool of the database system, and copies the determined portions of the object from the buffer pool. Remaining portions of the object that are non-active are copied from database storage. A copy of the object is created from the copied object portions. Embodiments of the present invention further include a method and program product for copying an object of a database system in substantially the same manner described above.

BACKGROUND

1. Technical Field

Present invention embodiments relate to copying database objects, and more specifically, to creating image copies of database objects based on information within database buffer pools.

2. Discussion of the Related Art

Enterprise database systems commonly rely on rapid backup of production level objects to ensure high availability. The backup or copy process can be disruptive since on-line database systems access the disk devices used for the backup or copy processes. In addition, some copy processing may be performed without allowing changes to the object being copied. In order to minimize disruption, the copy process should complete as rapidly as possible. This becomes more acute in a database-as-a-service deployment model since service level agreements (SLAs) for database users need to be satisfied. A disruption caused by copy processing could jeopardize online system performance and ultimately jeopardize the SLAs.

One common approach for creating full image copies of database objects copies the file (or dataset) representing the object from disk. However, this copy may reflect significantly stale data for on-line database systems. Data may be updated in a buffer pool, but not committed to disk for long durations. Although the copy may be rapid with only disruption to the disk device, the recovery process may be severely impacted by the stale copy since more database logs would need to be applied to the stale data. This may result in a failure to meet SLAs should recovery be required.

Another common approach reads the object sequentially into the database buffer pool and uses the data in the buffer pool to create the image copy. This creates a current image copy, but the copy process may be elongated due to inefficient use of the buffer pool. Pages from the object may already reside in the buffer pool when the image copy is started. By navigating sequentially through the object, active pages in the buffer pool may be processed to disk to free space in the buffer pool for earlier pages. When the active page that was removed from the buffer pool needs to be copied, the page is reloaded into the buffer pool before writing the page to the image copy. These extra input/output (I/O) steps may result in longer elapsed times for the image copy. In addition, if the number of active pages in the buffer pool is low relative to the object size, when the image copy process finishes, the buffer pool is filled with unused object pages. This temporarily disrupts database performance since the prior active working set gets reloaded back into the buffer pool.

BRIEF SUMMARY

According to one embodiment of the present invention, a system includes a processor to copy an object of a database system. The system determines one or more portions of the object that are active and reside within a buffer pool of the database system, and copies the determined portions of the object from the buffer pool. Remaining portions of the object that are non-active are copied from database storage. A copy of the object is created from the copied object portions. Embodiments of the present invention further include a method and computer program product for copying an object of a database system in substantially the same manner described above.

DETAILED DESCRIPTION

A database management system controls access to various database objects. The database management system is responsible for ensuring that the database is available for processing queries and updates, and for maintaining object consistency throughout the queries and updates. Image or backup copies of database objects are typically produced for a recovery process that recovers data in the event of a database crash, preferably with as current data as possible.

Database objects are typically divided into portions (e.g., pages) for storage. These pages are loaded from database storage into a buffer pool to enable faster data access. Present invention embodiments produce a current image copy of a database object by using information within the buffer pool (or buffer pool awareness optimization). In particular, a buffer manager of a database management system maintains a list of active pages for each object in the buffer pool. The active pages within the buffer pool that originate from the object being copied are initially determined and copied. This avoids the need to reload those active pages should the pages be flushed from the buffer pool. The copied pages of the object need not be placed sequentially into the image copy. For example, if pages 5, 10, and 15 reside in the buffer pool, the copied object may have the initial three pages as pages 5, 10, and 15 (e.g., as opposed to pages 1, 2, 3 of the object).

After the active pages have been copied from the buffer pool to the image copy, the remaining non-active pages (e.g., remaining pages of the object that do not reside within the buffer pool) are copied from database storage. A portion of the buffer pool may be allocated as a temporary sub-buffer for the image copy process. The temporary sub-buffer is used to receive non-active pages of the object and transfer the received pages to the image copy. In addition, the production of the image copy may employ parallel threads for maximum throughput. A recovery process handles non-sequential ordering of the object pages within the resulting image copy.

Since the remaining portions of the buffer pool that have not been allocated for the sub-buffers remain available for active processing of other requests for access to the database (i.e., the non-active pages of the object are not read into the in-use portion of the database buffer pool), there is no disruption of on-line data processing. Further, due to the rapid nature of the copy process and the inclusion of active pages from the buffer pool, any staleness of a copied page is minimal, and a log application phase of a recovery process is maintained at low overhead.

An example environment for use with present invention embodiments is illustrated inFIG. 1. Specifically, the environment includes one or more server systems140, and one or more client or end-user systems112. Server systems140and client systems112may be remote from each other and communicate over a network120. The network may be implemented by any number of any suitable communications media (e.g., wide area network (WAN), local area network (LAN), Internet, Intranet, etc.). Alternatively, server systems140and client systems112may be local to each other, and communicate via any appropriate local communication medium (e.g., local area network (LAN), hardwire, wireless link, Intranet, etc.). Alternatively, server systems140may reside within the network with distributed processing to provide a cloud computing environment for producing image copies of database objects.

Client systems112enable users to submit requests (e.g., backup or copy requests, queries, etc.) to server systems140to perform various operations (e.g., searches, updates, backup or copies, etc.). The server system may be in the form of, or include, database management system260, and includes image module250(FIG. 2) to produce an image copy of a database object as described below. The image module may be a stand alone module, or be embedded within the database management system. Databases130,132, and134may store various information and database objects, and interact with server systems140. The databases may each be implemented by any conventional or other database or storage unit, may be local to or remote from server systems140and/or client systems112, and may communicate via any appropriate communication medium (e.g., local area network (LAN), wide area network (WAN), Internet, hardwire, wireless link. Intranet, etc.). The client systems may present a graphical user interface (e.g., GUI, etc.) or other interface (e.g., command line prompts, menu screens, etc.) to solicit information from users pertaining to the desired operations, and may provide reports including operation results.

Alternatively, one or more client systems112may produce image copies from an associated database when operating as a stand-alone unit. In a stand-alone mode of operation, the client system stores or has access to the database, and includes image module250(FIG. 2) to produce image copies. The graphical user interface (e.g., GUI, etc.) or other interface (e.g., command line prompts, menu screens, etc.) solicits information from a user pertaining to the desired operations, and may provide reports including operation results. If client system112produces the image copy, then the database management system may provide an interface for image module250to know what pages are currently in buffer pool220. The database management system may further provide an interface to image module250with access methods to load pages in and out of buffer pool220.

Referring toFIG. 2, server systems140may be implemented by any conventional or other computer systems preferably equipped with a display or monitor, a base (e.g., including at least one processor210, one or more memories240and/or internal or external network interfaces or communications devices230(e.g., modem, network cards, etc.)), optional input devices (e.g., a keyboard, mouse or other input device), and any commercially available and custom software (e.g., server/communications software, image module, database management system software, etc.). The server systems may further include a buffer pool220that generally comprises high-speed memory for storing data from databases130,132,134. The buffer pool may be within or external of the database management system, and may be managed by the database management system, is utilized to provide rapid data access to data within the databases and to produce image copies of database objects. The buffer pool may be divided into one or more sub-buffers (e.g., sub-buffers222,224,226, and228as shown in inFIG. 2) in order to enhance the throughput for producing image copies as described below. By way of example, sub-buffers222and224may be utilized for producing an image copy, while remaining sub-buffers226and228may be utilized for normal (e.g., client, etc.) access to database systems130,132,134, thereby enabling the production of the image copy to minimally disrupt database access.

Memory240may include image module250, and may further store the resulting image copy of a requested database object. Image module250may include one or more modules or units to perform the various functions of present invention embodiments described below. The various modules (e.g., image module, etc.) may be implemented by any combination of any quantity of software and/or hardware modules or units, and may reside within the memories of the server and/or client systems for execution by the processor.

A manner in which an image copy of a database object is produced (e.g., via image module250and server system140and/or client system112) according to an embodiment of the present invention is illustrated inFIG. 3. Initially, a request for an image copy or backup of a database object is received at step310. The request may originate from a client system, or from within the server system (e.g., user request, request from an application, etc.). The request preferably includes one or more identifiers (e.g., database identification, object identification, etc.) to specify the object to be copied. Each database object (e.g., table, etc.) is partitioned into pages (e.g., blocks or units of storage of a predetermined size) for storage in the database and buffer pools as described above.

Buffer pool220is scanned for active pages that belong to the requested object at step320. In particular, the first page of the buffer pool is scanned at step322. If the scanned page does not belong to the requested object as determined at step324, the next page in the buffer pool is scanned at step322in response to the presence of additional pages in the buffer pool as determined at step330. In another embodiment, a buffer manager may keep a list of active pages in the buffer pool for each object, such that all of the pages in the buffer pool are not necessarily scanned.

When the scanned page does belong to the requested object, the scanned page is examined for validity. A page is considered valid when the data of the page includes the most recent data. For example, a page may be modified several times before any modifications are committed to database storage. When any given page is modified, remaining versions of that page are marked as invalid. If the scanned page is invalid as determined at step326, the next page in the buffer pool is scanned at step322in response to the presence of additional pages in the buffer pool as determined at step330.

When the scanned page is valid as determined at step326, the active, valid page of the requested object is copied from the buffer pool to the image copy at step328. The next page in the buffer pool is scanned at step322in response to the presence of additional pages in the buffer pool as determined at step330. The above process is repeated until all of the pages in the buffer pool are scanned as determined at step330.

Once the pages in the buffer pool belonging to the requested object have been copied, the presence of non-active pages of the requested object (e.g., pages of the object not residing in the buffer pool) is determined. If all of the pages of the requested object resided in the buffer pool as determined at step340, the image copy is complete. However, if non-active pages of the requested object exist as determined at step340, the non-active pages are copied from database storage to the image copy at step350. For example, the non-active pages may be read sequentially from the database storage and stored within the buffer pool for transference to the image copy. Alternatively, a sub-buffer may be allocated within the buffer pool to be used to receive the non-active pages for transference to the image copy as described below.

Once all of the pages (e.g., active and non-active) of the requested object have been copied as determined at steps340,350, the resulting image copy represents a copy of the requested object and the process terminates at step360. The resulting image copy may be stored in the memory of the server and/or client systems, or other locally or remotely accessible storage units (e.g., databases, processing devices, memories, etc.).

A manner in which an image copy of a database object is produced (e.g., via image module250and server system140and/or client system112) utilizing sub-buffers and parallel processing to enhance throughput according to an embodiment of the present invention is illustrated inFIG. 4. By way of example, two sub-buffers (A and B) are allocated within the buffer pool to copy the non-active pages of the requested object from the database storage. Plural sub-buffers may be allocated to accommodate plural threads and/or plural I/O operations. Present invention embodiments may utilize any quantity of sub-buffers and threads for copying non-active pages of requested objects.

Initially, active pages within the buffer pool are scanned to identify and copy the pages belonging to the requested object in substantially the same manner described above (e.g., steps310-340ofFIG. 3). In particular, portions of the buffer pool are allocated for sub-buffers A and B at respective steps410and420. The sub-buffers are generally a subset of the buffer pool and dedicated for receiving non-active pages of requested objects for transference to the image copies. The sub-buffers may already exist if prior image copy processes have already allocated the sub-buffers. By way of example, the size of a sub-buffer may be based on the page size and the amount of information that can be accessed in a single input/output (I/O) operation from database storage, such that the sub-buffer can be read from and written to in parallel. One example, in which the speed of read I/O operations and write I/O operations are the same, may be expressed as:
Sub-Buffer Size=2*MAX(page size, ((amount of data that can be accessed by a singleI/OoperationDIVpage size)*page size));

where MAX is a function that returns a maximum value, page size is the size (or storage capacity) of a page, and DIV is a function that performs integer division (e.g., returns a truncated integer result). The page size is preferably defined to be less than or equal to the amount of data that can be accessed in a single input/output (I/O) operation. For example, if the database storage can access 130 kilobytes in one I/O operation, and each page is 4 kilobytes, the sub-buffer is sized to 256 kilobytes (e.g., 2*MAX(4 KB, ((130 KB DIV 4 KB)*4 KB)=2*MAX(4 KB, (32*4 KB)=2*128 KB=256 KB).

The non-active pages of a requested object are read and placed in sub-buffer A at step412. Once pages are placed in sub-buffer A, the pages are transferred from sub-buffer A to the image copy at step414. The non-active pages of the requested object are read and placed in sub-buffer B at step422. Once pages are placed in sub-buffer B, the pages are transferred from sub-buffer B to the image copy at step424.

The pages for sub-buffers A and B are synchronously read to avoid conflicting access to the same page and ensure that different pages of the requested object are stored in the sub-buffers. In other words, the synchronous reading of requested object pages prevents a page from appearing in more than one sub-buffer. By synchronously writing the requested object pages to sub-buffers A and B, the database management system ensures page consistency and knows when the entire block of pages is completely in the proper sub-buffer. If the pages are of sufficient size where plural input/output (I/O) operations are required to read/write a single page of the requested object, the pages are read into a sub-buffer asynchronously, and a synchronization is performed to ensure that the input/output (I/O) operations are complete and the entire page is present in the sub-buffer.

Pages are written or transferred from sub-buffers A and B to the image copy asynchronously since the pages are being retrieved from independent buffers, thereby avoiding conflicting access.

The process waits for one of the asynchronous write operations414or424to complete at step430, thereby providing storage in the respective sub-buffer for another page from the requested object. In response to completion of the asynchronous write operation from sub-buffer A as determined at step440, a subsequent page is retrieved from the requested object for placement in that sub-buffer at step412in response to the presence of additional pages as determined at step450. Similarly, in response to completion of the asynchronous write operation from sub-buffer B as determined at step440, a subsequent page is retrieved from the requested object for placement in that sub-buffer at step422in response to the presence of additional pages as determined at step452.

Once the non-active pages of the requested object have been read into the sub-buffers as determined at steps450,452, the process waits for completion of all asynchronous writes from the sub-buffers at step460. When the asynchronous writes have completed, a resulting image copy is produced at step470.

A single thread may be employed with one or more sub-buffers to perform the above process. The input/output (I/O) operations may be queued in the case of plural sub-buffers to enable an available sub-buffer to receive and/or transfer information to the image copy. Further, plural threads may be employed to perform the above process with plural sub-buffers in parallel to enhance throughput. In this case, each thread transfers data with a corresponding sub-buffer concurrently. A serialized central control block communicates the pages that have been handled to coordinate processing of the object pages by the threads.

Since the non-active pages of a requested object are not read into the database buffer pools in use, present invention embodiments provide no disruption to on-line database processing for image copies. Although a non-active page of a requested object may become active during processing, the staleness of the copied page is minimal and the log application phase of the recovery process should be maintained at low overhead due to the rapid nature of the copy process. The techniques of present invention embodiments may be applied to image copy utilities that are integrated into a database management system in order to produce rapid, minimally disruptive image copies.

It will be appreciated that the embodiments described above and illustrated in the drawings represent only a few of the many ways of implementing embodiments for producing an image copy of a database object based on information within database buffer pools.

The software of the present invention embodiments (e.g., image module, etc.) may be available on a recordable or computer useable medium (e.g., magnetic or optical mediums, magneto-optic mediums, floppy diskettes, CD-ROM, DVD, memory devices, etc.) for use on stand-alone systems or systems connected by a network or other communications medium.

Alternative embodiments of the present invention may include copying the non-active pages before or concurrently with the active pages, such that the active pages are not removed from the buffer pool before being written to the image copy. Additional alternative embodiments include sub-buffers that are separate from the buffer pool (i.e., not a subset of the buffer pool), and/or sub-buffers that are permanently allocated to image copy processing. Further, alternative embodiments may include unequally sized sub-buffers. Still further, in some alternative embodiments, read operations may be performed asynchronously and/or write operations may be performed synchronously.