Patent Publication Number: US-9836360-B2

Title: Recovery strategy with dynamic number of volumes

Description:
BACKGROUND 
     During operation, database systems generate backup files which may be used to recover from database crashes. The backup files include data backups, which consist of all the data of the database system at a given point in time, and log backups, which describe changes made to the data during a particular time period. In order to perform a recovery, a database administrator specifies a point in time to which the database should be recovered. The point in time may be specified by providing a timestamp or a log position and volume number. Based on the specified point in time, a data backup and a set of log backups are selected. Recovery then consists of restoring the database to the state of the data backup, followed by replaying the log backups in sequence. 
     Proper selection of the log backups may be difficult if a particular database backup was used for a prior recovery. Specifically, the log backups used for the prior recovery are members of a first log sequence which may include even more recent log backups, while log backups generated after the prior recovery are members of a second independent log sequence. 
     Moreover, some database systems associate database services with particular volumes, and generate data backups and log backups for each volume independently. Accordingly, a data backup and log backups must be selected for each volume, in a manner that results in a consistent overall database state. This problem is exacerbated by the capability of some database systems to remove and add volumes during operation. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of a system according to some embodiments. 
         FIG. 2  is a tabular representation of a portion of a backup catalog according to some embodiments. 
         FIG. 3  is a flow diagram of a process according to some embodiments. 
         FIG. 4  is a flow diagram of a process according to some embodiments. 
         FIG. 5  is a tabular representation of a portion of a backup catalog according to some embodiments. 
         FIG. 6  is a tabular representation of a portion of a backup catalog according to some embodiments. 
         FIG. 7  is a tabular representation of a portion of a backup catalog according to some embodiments. 
         FIG. 8  is a block diagram of an apparatus according to some embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     The following description is provided to enable any person in the art to make and use the described embodiments and sets forth the best mode contemplated for carrying out some embodiments. Various modifications, however, will remain readily apparent to those in the art. 
       FIG. 1  is a block diagram of system  100  according to some embodiments. System  100  includes database  110 , client  120  and administrator  130 . Generally, client  120  requests and receives data from database system  110 . More particularly, database engine  112  of database system  110  manages data  114 , and provides data of data  114  to client  120  in response to requests received therefrom. 
     Database system  110  may comprise any query-responsive data source or sources that are or become known, including but not limited to a structured-query language (SQL) relational database management system. Data  114  may comprise a relational database, a multi-dimensional database, an eXtendable Markup Language (XML) document, or any other data storage system storing structured and/or unstructured data. Data  114  may be distributed among several relational databases, multi-dimensional databases, and/or other data sources. Embodiments are not limited to any number or types of data sources. 
     Database system  110  may implement an “in-memory” database, in which volatile (e.g., non-disk-based) storage (e.g., Random Access Memory) is used both for cache memory and for storing the full database during operation, and persistent storage (e.g., one or more fixed disks) is used for offline persistency and maintenance of database snapshots. Alternatively, volatile storage may be used as cache memory for storing recently-used data, while persistent storage stores the full database. In some embodiments, data  114  comprises one or more of conventional tabular data, row-based data stored in row format, column-based data stored in columnar format, and object-based data. Database system  110  may also or alternatively support multi-tenancy by providing multiple logical database systems which are programmatically isolated from one another. Moreover, data  114  may be indexed and/or selectively replicated in an index to allow fast searching and retrieval thereof. 
     Administrator  130  provides management of database system  110 . For example, administrator  130  may define the structure of tables within data  114 , configure hosts within database  110 , initiate backup operations, and may instruct database engine  112  to recover data  114  based on a specified point in time, as described below. 
     Administrator  130  and client  120  of system  100  may comprise one or more devices executing program code of a software application for presenting user interfaces to allow interaction with its respective database system. Presentation of a user interface may comprise any degree or type of rendering. For example, administrator  130  may execute a Web Browser to receive a Web page (e.g., in HTML format) from database system  110 , and may render and present the Web page according to known protocols. Each administrator or client may also or alternatively present user interfaces by executing a standalone executable file (e.g., an .exe file) or code (e.g., a JAVA applet) within a virtual machine. 
     System  100  also includes backup file storage  140 . Backup file storage  140  may store data backups and log backups created by system  110 . Storage  140 , as well as the backup processes, may be managed by a third-party backup tool which receives instructions from database engine  112 . 
     Each log backup of backup file storage  140  is associated with one data backup. As described above, one or more log backups may be associated with a data backup and a first sequence of operations, while a second one or more log backups may be associated with the same data backup and a second sequence of operations. According to some embodiments, each data backup and log backup is associated with a particular volume, which in turn is associated with a particular service. Accordingly, backup and recovery of service-associated volumes may be managed independently. 
     Backup catalog  115  stores information about all data backups and log backups of data  114 .  FIG. 2  is a tabular representation of a portion of backup catalog  200  according to some embodiments. Each record of backup catalog  200  specifies a backup identifier, a backup type, a volume, a timestamp, a globally-unique identifier (GUID), and log positions associated with a single data backup or log backup. Embodiments are not limited to the structure and contents of backup catalog  200 . 
     The volume field, according to the illustrated embodiment, indicates the server service which is associated with the backup. According to some embodiments, data backups and log backups of each service&#39;s volumes are stored independently. This may facilitate recovery of the full database to a particular point in time in cases where a service volume is added or deleted during database operation. For example, if a volume has been deleted and would not be active after a point in time specified by a recovery, the data and log backups of the volume are ignored during the recovery. 
     According to some embodiments, a command to perform a database backup results in creation of a separate data backup for each currently-existing volume of the database. Records  202 - 206  of catalog  200  represent three such separate data backups. 
       FIG. 3  comprises a flow diagram of process  300  according to some embodiments. In some embodiments, various hardware elements of database system  110  execute program code of database engine  120  to perform process  300 . Process  300  and all other processes mentioned herein may be embodied in processor-executable program code read from one or more of non-transitory computer-readable media, such as a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, and a magnetic tape, 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 system is operated at S 310 . As described above, operation of the database system at S 310  may comprise receiving a query from a database client, and providing data of data  114  to the database client in response to the query. Operation of the database system may also comprise receiving commands to add, delete or modify data of data  114 . 
     During such operation, it is determined at S 320  whether a data backup should be performed. The database system may be configured to perform data backups at predetermined intervals, in response to certain parameters (e.g., number of modifications, etc.), or in response to a command received from a database administrator. According to the present example, one instantiation of process  300  executes for each running service, with all instantiations executing in parallel. Accordingly, the determination at S 320  relates to a data backup of a particular volume. Flow proceeds to S 340  if a data backup is not desired at this time. 
     At S 340 , it is determined whether a log backup should be performed. Although the determinations of S 320  and S 340  are illustrated as sequential, they may be performed independently and/or in parallel. Similarly to S 320 , the database system may be configured to perform log backups at predetermined intervals, in response to certain parameters or in response to a command received from a database administrator. A log backup describes changes made to the database since a last log backup in a sequence which begins at a particular data backup. Flow returns to S 310  if the determination at S 340  is negative. Accordingly, flow cycles between S 310 , S 320  and S 340  to operate the database system until it is determined that a backup operation should be performed. 
     If it is determined at S 320  that a data backup should be performed, a data backup is generated at S 330 . The data backup may be generated using any system for creating a data backup that is or becomes known. According to some embodiments, database engine  112  generates data backup  142  at S 330 , including all of the data of data  114  at the current time. 
     Also at S 330 , a record corresponding to the data backup is created in the backup catalog. The record includes a new identifier which has not yet been associated with a record in the backup catalog. Flow then returns to S 310  to continue operation of the database system. If, during such operation, it is then determined at S 340  that a log backup should be performed, a log backup is generated at S 350 , along with a new record of the backup catalog including the current identifier. 
     Backup catalog  200  of  FIG. 2  illustrates the results of several iterations of process  300  according to some embodiments. Specifically, records  202 ,  206  and  208  were created in response to a data backup. Next, in response to three subsequent affirmative determinations at S 340 , log backups and corresponding records  208 - 212  were created. 
       FIG. 4  is a flow diagram of process  400  to recover a database according to some embodiments. As described with respect to process  300 , process  400  may be executed with respect to a specific data volume. 
     Initially, at S 410 , a command is received to recover a database to a point in time. The point in time may be an actual time or represented as a log position and volume number. The command may be provided by a database administrator, via a graphical user interface or command-line interface. 
     If the particular volume of interest was active at the point in time, a log backup which covers the point in time is determined at S 420 . Also determined at S 420  is an identifier associated with the determined log backup in the backup catalog. The log backup may be determined by locating records of the backup catalog which concern the volume of interest, and by comparing the recovery point in time with the timestamps or log positions associated with those records. The identifier (e.g., the GUID) is then determined from the backup catalog record of the determined log backup. 
     According to some embodiments, the backup catalog includes records indicating when a volume is removed or added, and when a recovery occurs. Backup catalog  200  of  FIG. 5  shows record  214  indicating that the IndxServr volume was removed, and includes a timestamp indicating a time at which the removal occurred. 
       FIG. 6  shows catalog  200  at a later time, at which record  224  has been added to show that the IndxServr volume has been added. Accordingly, if process  400  is executed with respect to the IndxServr volume and the point in time is between records  214  and  224 , process  400  terminates without performing a recovery of the IndxServr volume, because the volume was not active at the recovery point in time. 
     Next, at S 430 , all other log backups of the volume prior to the determined log backup and later than a last recovery indicated in the backup catalog are collected, along with a last data backup of the volume. In this regard, and as illustrated by record  226  of catalog  200  of  FIG. 7 , backup catalog  200  stores a record indicating the occurrence of a recovery, along with a timestamp of the recovery. 
     For example, if the log backup determined at S 420  is the backup associated with record  230  of backup catalog  200 , then no other log records associated with the NameServr volume are collected, because none later than the last recovery exist. The last data backup, represented by record  216 , is collected. 
     At S 440 , a recovery is executed based on the log backup determined at S 420  and on the backups collected at S 430 . First, the data of the data backup is restored, and then each log backup is replayed, in order of age, up to the specified point in time. Next, at S 450 , a record is appended to the backup catalog indicating the recovery and including a timestamp, as shown with respect to record  226 . 
       FIG. 8  is a block diagram of system  800  according to some embodiments. System  800  may comprise a general-purpose computing system and may execute program code to perform any of the processes described herein. System  800  may comprise an implementation of database system  110  according to some embodiments. System  800  may include other unshown elements according to some embodiments. 
     System  800  includes processor  810  operatively coupled to communication device  820 , data storage device  830 , one or more input devices  840 , one or more output devices  850  and memory  860 . Communication device  820  may facilitate communication with external devices, such as a reporting client, or a data storage device. Input device(s)  840  may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s)  840  may be used, for example, to enter information into apparatus  800 . Output device(s)  850  may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer. 
     Data storage device  830  may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory  860  may comprise Random Access Memory (RAM). 
     Database engine  832  may comprise program code executed by processor  810  to cause apparatus  800  to perform any one or more of the processes described herein. Embodiments are not limited to execution of these processes by a single apparatus. Backup catalog  832  may comprise an implementation of backup catalog  115  and/or backup catalog  200 , and data  834  may include data  114  as described above. As also described above, data  114  may be implemented using volatile memory such as memory  860 . Data storage device  830  may also store data and other program code for providing additional functionality and/or which are necessary for operation of system  800 , such as device drivers, operating system files, etc. 
     The foregoing diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other manners. Other topologies may be used in conjunction with other embodiments. Moreover, each system described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Each device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. For example, any computing device used in an implementation of system  100  may include a processor to execute program code such that the computing device operates as described herein. 
     All systems and processes discussed herein may be embodied in program code stored on one or more non-transitory computer-readable media. Such media may include, for example, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units. Embodiments are therefore not limited to any specific combination of hardware and software. 
     Embodiments described herein are solely for the purpose of illustration. Those skilled in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.