Abstract:
Described is a computerized system for continuous data protection. The system includes a host executing a user application and a storage subsystem coupled to the host via a network interconnect. The storage subsystem comprises a storage controller and a storage disc coupled to the storage controller. The storage disc is apportioned into logical partitions. The storage subsystem additionally includes a primary volume storing current data associated with the user application; a base volume storing a point-in-time copy of the data associated with the user application; a journal volume storing data associated with the user application; and a journal manager configured to intercept a data write request sent by the host to the storage subsystem and to write data associated with the intercepted request to the primary volume and the base volume and to write the second data associated with the user application into the journal volume. Using the described technology, an application, like an RDBMS (DB), can control storage subsystem based on application specified marker operation. As one of examples, DBMS keeps roll back data records on a storage medium, even if the application executes in the online backup mode which prescribes keeping only roll forward information on the pending transactions.

Description:
FIELD OF THE INVENTION  
       [0001]     This invention generally relates to data storage systems and, more specifically, to continuous data protection using storage subsystem.  
       DESCRIPTION OF THE RELATED ART  
       [0002]     Continuous Data Protection (CDP) technology provides a continuous protection for user data by journaling every write input-output (IO) operation performed by a user application. The log is stored on a storage device, which is independent from the primary system storage. The modern CDP systems detect various activities of the target software application, such as timing checkpoint in events or the installation of the application. The CDP systems then store information on the activities of the target, writing the marker information in the header of the respective log records.  
         [0003]     An exemplary storage based CDP system is described in a published U.S. Patent Application No. US20040268067 A1, titled “Method and apparatus for backup and recovery system using storage based journaling as a reference,” which is incorporated herein by reference. The described system provides copy on write journaling capabilities and keeps unique sequence number for journal log and snapshot images of application data.  
         [0004]     In addition, there are several available commercial CDP products. One major enterprise product is REVIVO CPS 1200i. The description of this product can be found at http://www.revivio.com/index.asp?p=prod_CPS — 1200i, and is incorporated herein by reference. The aforesaid product operates to mirror input-output (IO) operations performed by a host system. The data mirroring is performed by an appliance, which receives mirrored  10  data and stores the received data in the journal format, additionally providing indexing information for subsequent restore operation.  
         [0005]     Another CDP product, which is capable of studying the behavior of a software application, is XOSoft&#39;s Enterprise Rewinder User Guide product, a description of which may be downloaded from http://www.xosoft.com/documentation/EnterpriseRewinder_User_Guide.pdf and is incorporated by reference herein. This product, designed specifically for Microsoft® Exchange®, adjusts its own operation based on the behavior of the user application.  
         [0006]     Despite the above advances, a new technology is required to provide further efficiency of the CDP behavior as well as additional intelligence within the storage subsystem, which would involve better understanding of the behavior of the target application.  
       SUMMARY OF THE INVENTION  
       [0007]     The inventive methodology is directed to methods and systems that substantially obviate one or more of the above and other problems associated with conventional techniques for continuous data protection.  
         [0008]     In accordance with one aspect of the inventive technique, there is provided a computerized system and an associate method and computer programming product for continuous data protection. The inventive system includes a host executing a user application and a storage subsystem coupled to the host via a network interconnect. The storage subsystem includes a storage controller and at least one storage disc connected to the storage controller. The storage disc(s) is apportioned into logical partition(s). The inventive storage system further includes a primary volume operable to store current data associated with the user application; a base volume storing first data associated with the user application; a journal volume storing second data associated with the user application; journal manager operable to intercept a data write request sent by the host to the storage subsystem and to write data associated with the intercepted request to the primary volume and the base volume and to write the second data associated with the user application into the journal volume and a command device operable to receive from the host a command attribute, and to configure the journal manager based on the received command attribute.  
         [0009]     In accordance with another aspect of the inventive technique, there is provided a computer-implemented method and an associate system and computer programming product. The inventive method involves receiving at a storage subsystem a command attribute specifying a after journaling mode; intercepting at a storage subsystem a storage access command issued by a user application; determining whether the intercepted storage access command includes a write operation; if the intercepted storage access command does not include the write operation, processing the intercepted storage access command at primary storage volume and terminating the operation; if the intercepted storage access command includes the write operation, writing data associated with the storage access command to the primary volume; and writing incremental change data associated with the storage access command to a journal volume.  
         [0010]     In accordance with yet another aspect of the inventive technique, there is provided a computer-implemented method and an associate system and computer programming product. The inventive method involves receiving at a storage subsystem a command attribute specifying a before journaling mode; intercepting at a storage subsystem a storage access command issued by a user application; determining whether the intercepted storage access command includes a write operation; if the intercepted storage access command does not include the write operation, processing the intercepted storage access command at primary storage volume and terminating the operation; if the intercepted storage access command includes the write operation, writing data associated with the storage access command to the primary volume; copying old data from a base volume to a journal volume; and writing data associated with the storage access command to the base volume.  
         [0011]     Additional aspects related to the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Aspects of the invention may be realized and attained by means of the elements and combinations of various elements and aspects particularly pointed out in the following detailed description and the appended claims.  
         [0012]     It is to be understood that both the foregoing and the following descriptions are exemplary and explanatory only and are not intended to limit the claimed invention or application thereof in any manner whatsoever. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0013]     The accompanying drawings, which are incorporated in and constitute a part of this specification exemplify the embodiments of the present invention and, together with the description, serve to explain and illustrate principles of the inventive technique. Specifically:  
         [0014]      FIG. 1  depicts an exemplary system architecture in accordance with an embodiment of the invention;  
         [0015]      FIG. 2  is a diagram illustrating exemplary logical organization of various software components of the inventive system and interoperations among them;  
         [0016]      FIG. 3  illustrates exemplary application programming interfaces of the agent application;  
         [0017]      FIG. 4  illustrates an exemplary logical device manager table;  
         [0018]      FIG. 5  illustrates exemplary configuration of the inventive CDP system;  
         [0019]      FIG. 6  illustrates pool of logical devices within the inventive system;  
         [0020]      FIG. 7  illustrates exemplary behavior of after journal monitor;  
         [0021]      FIG. 8  illustrates a procedure for handling the write command directed to a target logical device;  
         [0022]      FIG. 9  illustrates exemplary behavior of before journal monitor;  
         [0023]      FIG. 10  illustrates exemplary procedure for handling the write command for target logical devices;  
         [0024]      FIG. 11  illustrates the operation of the inventive journal manager;  
         [0025]      FIG. 12  depicts exemplary application attribute and action table illustrating actions corresponding to specific attributes;  
         [0026]      FIG. 13  provides a list of actions of the inventive CDP system;  
         [0027]      FIG. 14  illustrates exemplary operating sequence of a restore procedure using before and after journals;  
         [0028]      FIG. 15  illustrates exemplary embodiment of logical unit to logical device mapping table;  
         [0029]      FIG. 16  illustrates an exemplary graphical user interface of the inventive CDP system;  
         [0030]      FIG. 17  and  FIG. 18  illustrate operation of the inventive CDP system interacting with an application by means of inventive attribute function;  
         [0031]      FIG. 19  illustrates an exemplary embodiment of a table storing information on a virtual logical unit group;  
         [0032]      FIG. 20  provides mapping between internal events of a database application and the corresponding attributes of the inventive CDP system; and  
         [0033]      FIG. 21  shows exemplary configuration of storage system in accordance with an embodiment of the invention. 
     
    
     DETAILED DESCRIPTION  
       [0034]     In the following detailed description, reference will be made to the accompanying drawing(s), in which identical functional elements are designated with like numerals. The aforementioned accompanying drawings show by way of illustration and not by way of limitation, specific embodiments and implementations consistent with principles of the present invention. These implementations are described in sufficient detail to enable those skilled in the art to practice the invention and it is to be understood that other implementations may be utilized and that structural changes and/or substitutions of various elements may be made without departing from the scope and spirit of present invention. The following detailed description is, therefore, not to be construed in a limited sense. Additionally, the various embodiments of the invention as described may be implemented in the form of a software running on a general purpose computer, in the form of a specialized hardware, or combination of software and hardware.  
         [0035]     Initially, before the following detailed description, certain special terminology used within the aforesaid description will be explained. Specifically, as used herein, Logical Unit (LU) is a unit which is used to access data from host using SCSI command(s) on storage subsystem. The LU needs to be mapped to at least one logical device (LDEV). Logical Unit Number (LUN) is an identification number for each LU, which is used to specify the logical unit using SCSI command. Each LU has an associated set of World Wide Names (WWN) as well as LUN.  
         [0036]     Logical Device (LDEV) is a storage area configured to store data within a storage subsystem. It may consist of at least one physical disc. Image is an LDEV to which journal data is applied. Virtual LU is an LU which is accessible from a host regardless of the existence of an LDEV associated with that LU. Marker is sent from host&#39;s agent to storage subsystem. Finally, Header/Footer information may include metadata for journal provided to keep data and marker, which is sent from host.  
       First Embodiment  
       [0037]     The first embodiment of the invention illustrates the manner in which CDP deployed on a storage subsystem provides a capability to select application&#39;s action based on attribute using table of attributes and actions. The CDP of the inventive system may operate in both before and after journaling modes. One of the benefits that may be achieved through the use of the inventive concept is that the application can control the CDP operating modes when the state of the application changes, thereby the length of the journal data on storage subsystem&#39;s CDP can be reduced when application is initiated. In addition, the application can keep the “before” image even if the application, such as a database application, enters an online backup mode or rolls forward an operation on recovery.  
         [0000]     Physical Configuration  
         [0038]      FIG. 1  shows a diagram illustrating various hardware components of the first exemplary embodiment of the present invention, as well as the interconnections among these components. The embodiment of the invention shown in  FIG. 1  includes at least one host  10  operatively coupled to at least one storage subsystem  30 . The host  10  may include an operating system (OS) executing on a hardware platform of the host  10 . The hardware of the host  10  may be implemented in a form of a standard workstation or a personal computer. The host may include a central processing unit (CPU)  11 , memory  12 , and internal storage disc drive  13 . The host may also include a host bus adapter (HBA)  14  operable to connect the host  10  to fibre channel (FC) or Ethernet switch  400 . Each host  10  may store its data on one or more logical units (LU) provided by the storage subsystem  30 .  
         [0039]     The storage subsystem  30  may have the following capabilities. Specifically, the storage subsystem  30  may be configured to store data using SCSI-2, 3 commands through fibre channel protocol (FCP) on the logical storage units (LU) allocated within the storage resources of the storage subsystem  30 . The storage subsystem  30  may additionally incorporate one or more RAID controllers (CTL)  20  and one or more storage disc drives  32 . The controller  20  may include one or more central processing units, one or more memory units, as well as one or more network interfaces (NIC), which may include Ethernet and/or FC ports  21  and  22 . The aforesaid ports may be provided to connect the system to a storage area network (SAN) or to the discs  32  in order to enable the processing of the SCSI I/O operations. The RAID configuration of the storage subsystem  30  may use several discs  32  residing within the storage subsystem. The controller  20  preferably includes a non-volatile random access memory (NVRAM) and is configured to utilize the aforesaid NVRAM as a data cache device or a device for protecting data, for example, from a power failure.  
         [0040]     The controller  20  provides the storage subsystem with ports which have associated WWNs (World Wide Names), specifying the target ID within the SCSI world, and consisting of a logical unit number (LUN) on a fibre channel (FC) port. The storage subsystem may additionally include a management console  23 , which may be connected to the storage subsystem  30  via an internal interconnect. The storage system  30  may be additionally accessed through console  402  connected to the system  30  via a switch/hub  401 . The console  402  may be implemented using a general-purpose web-based PC or a similar workstation system arranged to manage the storage subsystem  30 . The console  23  is configured to be utilized by a maintainer of the storage system  30 . The console  402  is provided for use by a storage system administrator and may be located outside of the storage system enclosure and can be accessible by beans of the aforesaid switch/hub  401 .  
         [0000]     Logical Configuration  
         [0041]      FIG. 2  shows a schematic diagram illustrating the logical organization of various software components of the described embodiment of the inventive system as well as the interoperations among those components.  
         [0000]     SAN  400   
         [0042]     The storage area network (SAN)  400  provides a logical data connection between the host  10  and the storage subsystem  30 . The SAN  400  may be implemented using, for example, a switch or a hub, operating according, for example, to the fibre channel (FC) and/or Ethernet protocols, well known to persons of skill in the art. As would be appreciated by those of skill in the art, the present invention is not limited to any specific protocol and other suitable protocols may be used in implementing the SAN  400 . The SAN functionality may be provided by, for example, an appropriate fibre channel (FC) switch or hub, or an Ethernet switch or hub.  
         [0000]     LAN/WAN  401   
         [0043]     The LAN/WAN  401  provides a logical connection between the Console  402  and the Storage Subsystem  30  using, for example, various network switches, such as Ethernet, FDDI or Token Ring switches, or the like. The storage subsystem  30  is connected to LAN/WAN  401  to enable the access thereto from other hosts for purposes of managing the storage subsystem  30 .  
         [0000]     Host  10   
         [0044]     The host  10  may include an operating system (OS) (not shown in the figure), an application  16 , such as a database application (DB), and an agent  15 . The OS may be any suitable operation system including, without limitation, UNIX®, Microsoft Windows®, Sun™ Solaris™, IBM®&#39;s ZIOS® or AIX®. As would be appreciated by those of skill in the art, may other types of operating systems, known to persons of skill in the art, may be used. The application may be a transaction type application, such as a database (DB) or any other kind of office-type application.  
         [0045]     The agent  15  communicates with the storage subsystem  30 . With respect to the communication method utilized for communications between the agent and the storage subsystem, one embodiment of the invention uses a technology which controls the storage device(s) using SCSI command sets. This technology is well known to persons of skill in the art, and is described, for example, in European patent No. EP1246050, which is incorporated herein by reference. It should be noted that the agent  15  generally corresponds to the operation API (RMLIB) on the host computer of the system described in EP1246050. On the other hand, the command device (CMD DEV)  36  of the present invention is generally equivalent to command device (CM) described in the EP1246050.  
         [0046]     The agent  15  may have several application programming interfaces (APIs) configured to control the CDP deployed within the storage subsystem  30 . Specifically,  FIG. 3  shows an exemplary list of the respective APIs. Each function call in the API set of the agent  15  has an instance number. This instance is created after the communication path is established between the agent  15  and the CMD DEV  36 . Each function call uses the created instance to enable the storage subsystem to identify communications between the application and storage subsystem. The following description provides detailed information on the role of the specific functions.  
         [0047]     CreateCTG function creates a consistency group, such as group  39  shown in  FIG. 2  using the CTGGroupName&#39;s name within the storage subsystem  30 . The consistency group provides the serialization of input and output (IO) among logical units (LUs), which include target logical devices (LDEVs) and CMD DEV  36  within the consistency group in the storage subsystem  30 . Within a consistency group, the after journal (JNL) and the before JNL mechanisms (discussed in detail below) can be used together. When a new consistency group is created, a new row is added to the list  33  shown in  FIG. 5 .  
         [0048]     AddLDEVtoCTG function requests to add a logical unit (LU) mapped logical device (LDEV) including target LUs and CMD DEV into the defined consistency group. Storage subsystem stores the added LDEV in the LDEV column  62  of table  33  shown in  FIG. 5 , in a row, which corresponds to the proper consistency group.  
         [0049]     DeILDEVtoCTG function deletes the LDEV, which has been previously added into the consistency group from the defined consistency group. Upon the receipt of this command, the storage subsystem deletes the specified LDEV from a list of LDEV in column  62  of the table  33  of  FIG. 5 .  
         [0050]     InsertMarker function issues a maker corresponding to the consistency group with an application attribute. The aforesaid application attribute controls the operation of the storage system based on the behavior of the application. The mapping between the application attribute and a CDP action is defined and stored within the storage subsystem  30 . The aforesaid definition is loaded from the agent or a console to the controller. The application attributes as well as the CDP actions are based on CDP architecture and will be discussed in detail below.  
         [0051]     ListMarker function shows a list of JNL markers specified by the API. When the function is executed on storage subsystem, JNL manager reads the markers. To optimize the performance of the journaling function, the markers may be stored using a cache. The result of the execution of this function includes the marked time as well as an attribute corresponding to the marker.  
         [0052]     SerachMarker function requests the inventive system to search markers based on one or more keys within user-specified field of the JNL&#39;s header. The storage subsystem returns a result of the search, which includes sequence number #, the searched field name, and the values of the JNL markers.  
         [0053]     CreateVirtualLU function requests to create a virtual LU which will be discussed in detail below. DeleteVirtualLU function requests to delete the created virtual LU from a specific port. After the deletion of the virtual LU, storage subsystem  30  deletes an entry corresponding to that virtual LU from DEV column  84  shown in  FIG. 15 , in the row corresponding to the selected port.  
         [0054]     CreateVLUG function requests to create a group of virtual LUs. Storage subsystem  30  creates a new virtual LU group and inserts a new row within the table  330  shown in  FIG. 19 . The inserted row includes virtual LU group identifier  331  as well as a nick name  332  of the created virtual LU group. The nick name  332  is entered from the corresponding function call. Virtual LUN numbers  333  in table  330  of  FIG. 19  are generated using CreateVirtualLU function executed recursively using the LUNs specified by the function call.  
         [0055]     MapCTGtoVLUG function requests to create a set of consistency group&#39;s images from JNLs specified by time and sequence # and maps the set to the created named virtual LU group. When the storage subsystem maps a set of images on consistency group, the storage subsystem executes the MapImageToVLU function. The order of selecting target VLU on each MapImageToVLU operation is the increment of source LUN on consistency group. For example, there are LUN  1 ,  2 ,  3 , and  4  on consistency group and there are Virtual LUN  20 ,  21 ,  22 ,  23  on virtual LU consistency group. At first, image for LUN  1  is mapped to Virtual LUN  20  and incrementally image for LUN  2  is mapped to Virtual LUN  21 . It continues to LUN  4 .  
         [0056]     UnMapCTGfromVLUG function requests to un-map the set from the created named virtual LU group. Storage subsystem un-maps a set of images which is described in Virtual LUN numbers  333  in a Virtual LU group on  FIG. 19  using UnMapImageFromVLU recursively for each image.  
         [0057]     MapImageToVLU function requests to create an image which represents the journal records applied to a specific LDEV. The portion of the journal to be applied are specified by time and sequence #. The system then maps the created image to a Virtual LU, accessible to the user applications. Storage subsystem selects records from JNL having header information matching the specified time and sequence # and creates a volume. This feature of the inventive system will discussed hereinbelow in connection with the description of the Before/After JNL mechanism. After the image is created, this image is mapped to an LU using DEV column  84  of the table  25  shown in  FIG. 15 .  
         [0058]     UnMapImageFromVLU function requests to un-map the image from the created group of virtual LU. The storage subsystem deletes an entry corresponding to the selected image from DEV column  84  in  FIG. 15 .  
         [0059]     LoadApplicationAttributesTable function loads a configuration file, which describes application and action table  60  information to host. The format may use CSV format which is that each column is separated by comma and the row is separated by return, to controller  20 . The controller  20  converts format to their memory format like  60 .  
         [0060]     The ActivateTable function activates the Application attribute and action table  60  for subsequent use in the marker operation. The DeactivateTable function deactivates the Application attribute and action table  60  to un-use marker operation. In an embodiment of the invention, a command line interface for the aforesaid API operations is provided, with the parameters will be as above function call as well.  
         [0061]     The behavior of the API is based on the CDP architecture, and will be discussed in detail below. The host also maintains a configuration file  17 , which is described with reference to the LoadApplicationAttributesTable function.  
         [0000]     Storage Subsystem  30   
         [0062]     In one embodiment of the invention, the modules of storage subsystem  30  are enabled in microcode which is executed on the controller (CTL) and is provided as a program code installing form optical media, FD, and/or other removable devices. The microcode consists of parity group manager, logical device manager (LDEV Manager)  23  that creates a logical device to provide a logical storage from physical discs to IO process, Port  22  and Journal (JNL) Manager  24 . The description below provides additional details on the aforesaid modules.  
         [0000]     Parity Group Manager (this Module is not Depicted in  FIG. 2 )  
         [0063]     This module is a part of microcode and consists of a parity group from discs using RAID0/1/2/3/4/5/6 technology. RAID 6 is based on RAID 5 technology and includes dual parity protection of stored data. The created parity group is listed in LDEV Configuration table  29  shown in  FIG. 4  and has parity group number column  51  to identify the parity group within the storage subsystem  30 , usable capacity size column  52  created from RAID resources, RAID configuration column  53 , as well as the discs column  54 .  
         [0000]     LDEV Manager  23   
         [0064]     LDEV manager  23  manages LDEV&#39;s structure and the behavior from LU&#39;s IOs. LDEV presents a logical storage area for LU to store and present data from/to host. LDEV is a portion of parity group and administrator defines and initially formats the region of the LDEV adding the number of LDEV. The mapping between LDEV and parity group is stored in LDEV Config  29  ( FIG. 4 ). On a parity group number  51 , a record in LDEV Config has LDEV number  55  to identify the logical device within the storage subsystem, start Logical Block Address (LBA)  56  to represent LDEV&#39;s start address on the parity group, end LBA  57  to present LDEV&#39;s end address on the parity group and size 58 to present a size of LDEV. The initial format is requested by administrator. The default of format data is 0. The format data can be reconfigured by administrator like NULL or other character via console  402 .  
         [0000]     Port  22   
         [0065]     Port  22  provides LDEV via logical unit (LU) on a WWN to SAN  400 .  FIG. 15  shows a mapping table between LU and LDEV LUN (Logical Unit Number)  83  and LDEV  84 . Each value that is in the hardware port  81  column corresponds to one of the ports  22  in  FIG. 1 . Each port  22  has its own WWN  82  to be specified from host. A plurality of LUs can be assigned on the port  22 . An LU is specified by a set of WWN  82  and LUN  83 . The maximum number of LU on a port is 256 based FC-SCSI specifications. Further, each LU is mapped to an LDEV to store data from hosts  10 . Based on this mapping information, the CTL  20  receives SCSI commands from the port  22  and converts the set of WWN  82  and LUN  83  into the LDEV  84  to access the appropriate LDEV.  
         [0066]     Some LUs can be configured as CMD DEV. When an LU is defined as CMD DEV by console  402 , the row of CMD DEV  85  in  FIG. 15  will be checked. Storage Administrator creates LU and sets CMD DEV to LU using console  402 . In each LU, administrator can configure LU as Virtual LU to represent LU for host even if LU doesn&#39;t have the LDEV or the image. When administrator sets LU as Virtual LU, the storage subsystem turns VLU bit  86  on. In this mode, storage subsystem always provides LU to host regardless of assignment of LDEV on LU.  
         [0000]     Virtual LU &amp; Virtual LU Group (Not Shown in Pictures)  
         [0067]     Virtual LU is initially unmapped to an LDEV associated with a port; in case of virtual LU on Storage subsystem, the LU for virtual LU has logical unit number which is one of parameters in the function call. Therefore, a host can access the LU using normal SCSI command. For example, in response to a SCSI inquiry from the host, the virtual LU responds with a normal response, taking into account the fact that the LDEV is unmapped. As the result of the SCSI inquiry, the size of LU is the maximum available storage capacity or any storage subsystem-specific size, for example 2 GB. However the virtual LU does not have any associated LDEVs. Therefore, when SCSI Read/Write operation that comes from the initiator is executed on the virtual LU, the virtual LU responds with an error or other type of response like size 0 to initiator.  
         [0068]     On CreateVLU function, JNL Manager marks an entry of the VLU  86  in  FIG. 5  corresponding to a LUN on a port. If an image which a LDEV and is applied journal (discuss in later) is mapped to Virtual LU, the inquiry returns the size which is the mapped LDEV&#39;s size. When SCSI Read/Write operation is executed, the volume can be read. As additional information, this virtual LU helps to fix the order of device name&#39;s number because some operating systems shuffle device names after attached new LU. Virtual LU Group helps to restore a set of images on consistency group to a set of Virtual LUs.  
         [0069]      FIG. 19  illustrates the table  330  of Virtual LU Group. The table  330  consists of Virtual LU Group (VLUG) Number  331 , Nick Name  332 , and Virtual LUN (Logical Unit Number) # 1   333  and is located on controller&#39;s memory. The table is maintained by the API of the agent  15  and specifically the MapImageToVLU and UnMapImageFromVLU calls, which have been described in detail hereinabove. The console  402  may set the value of the Virtual LU Group.  
         [0000]     Journal Manager  24   
         [0070]     Journal Manager manages After Journal (JNL) and Before Journal mechanism for target LDEV&#39;s including application marker operation. Before the Before and After Journal mechanisms will be discussed in detail, the volume configuration will first be explained.  
         [0000]     [Configuration] 
         [0071]     The mapping between target LDEV and After JNL/Before JNL mechanism&#39;s volumes is depicted in  FIG. 5  as records in the CDP Configuration table  33 . Each record in the table consists of the consistency group number (C.G. #)  61 , a set of CDP protected target LDEV numbers  62 , the command device&#39;s (CMD DEV) LDEV number  63  and the CDP protection mode which includes After JNL LDEV  64  and Before JNL LDEV  65 . If the protection mode is enabled, the related volume information is also stored in the records  66  through  69 . In case that After JNL mechanism is enabled, the base LDEV  66  and JNL LDEV  67  are specified. Also, in case that Before JNL mechanism is enabled, the base LDEV  68  and JNL LDEV  69  are specified. The setting of consistency group may be done by Server Administrator or DBA via host agent  15  thought their API or console. The setting from 64 to 69 is done by Storage administrator via console  402 .  
         [0072]     On allocation of LDEV, LDEV manager provides LDEV from LDEV pool ( FIG. 6 ). So storage administrator gets a LDEV from Free LDEV  68  in LDEV pool. If the LDEV is allocated to base LDEV or JNL LDEV, the LDEV is treated as “used” LDEV  69  in LDEV pool.  
         [0000]     [After JNL Mechanism] 
         [0073]      FIG. 7  shows a diagram of the After JNL mechanism. After JNL mechanism makes a history of Write  10  from hosts. In this configuration, there is Primary LDEV (Primary VOL)  35 , Base LDEV (Base VOL)  37 , JNL LDEV (JNL VOL)  38  and Command Device (CMD DEV)  36 . Primary LDEV is target volume for CDP. The Base LDEV has a point in time of copy data at starting journaling on JNL LDEV  38  and a sequence number which is counted on each journal operations and leave the number after creation of PIT copy. JNL LDEV has 10 journal and related CDP information like marker and the information of the 10 operations. CMD DEV provides a communication method between host and storage subsystem using SCSI in-band communication. The operation is done by SCSI read/write command for a region of logical device on LDEV for CMD DEV.  
         [0074]     JNL Manager has a JNL pointer  50  to find current write position on JNL LDEV. JNL Pointer start from 0 and it manages by logical block address (LBA). If the JNL volume has their management area like VTOC or MBR area, the start address is shifted by the size of their management area.  
         [0075]      FIG. 8  illustrates a procedure for handling the write command directed to the target LDEV, which is handled by the system illustrated in  FIG. 7 . Follows is the detailed description of the specific steps of the aforesaid procedure.  
         [0000]     Begin of Procedure  
         [0076]     Step  111 : JNL Manager receives SCSI CMD which is sent from the host (Procedure  1  in  FIG. 7 ).  
         [0077]     Step  112 : JNL Manager checks if the command is SCSI WRITE commands like WRITE  6 , WRITE  10 , and etc. or not. If the command is WRITE command, the procedure goes to Step  113 . If it is not, the procedure is goes to Step  117 .  
         [0078]     Step  113 : JNL Manager writes data which is for target Primary LDEV to Primary LDEV based on initiator&#39;s SCSI command. (Procedure  2  in  FIG. 7 )  
         [0079]     Step  114 : JNL Manager writes header (HD) information (detail in later), data, footer (FT) information for the journal starting from JNL Pointer&#39;s LBA on JNL LDEV  38 . (Procedure  3  in  FIG. 7 )  
         [0080]     Step  115 : JNL manager increases by total size of header, data, and footer to the pointer.  
         [0081]     Step  116 : JNL Manager returns the result of write to host using SCSI condition state.  
         [0082]     Step  117 : JNL manager executes other SCSI command like READ  6  operation on Primary LDEV.  
         [0000]     End of Procedure  
         [0083]     The header/footer information includes header/footer bit, sequence # to identify IO within system, CMD Type for header/footer to show what type of header/footer like journal data, marker and etc, CMD if the CMD Type is journal data, CDP action if the CMD type is marker and etc., attribute for CDP action and comment for the attribute, Time when JNL Manager receives IO in JNL manager, SCSI command which is received from host, Start Address and size for journal data, header sequence number if the information is footer.  
         [0084]     The sequence # is incremented by each header/footer insertion. If the sequence number is above their maximum number, the number may return to 0. CDP action, attribute, and comment keeps as the text or binary encoded data. CDP action keeps a name of CDP action based on list of  FIG. 13 , attribute keeps a name of attribute on marker based a list of attribute  61 , and the comment keeps an application and Journal Manager inputted comment.  
         [0085]     The size of header/footer information is 2 KB which is 4 by LBA in this invention. The size of header/footer may extent in order to be more capacity.  
         [0086]     Regarding restore operation based on MapImageToVLU from host, the storage subsystem creates an image specified by time in MapImageToVLU or time and sequence number in “Create an image” attribute.  
         [0087]     Before the operation, JNL Manager checks if the Virtual LU maps an image which journal applied LDEV using MapImageToVLU function working in Storage Subsystem or not because this operation uses Virtual LU. If another image has been mapped on Virtual LU and Read/Write access has been executed within last 1 minute, this operation is skipped as the Virtual LU is used. If not, the image is unmapped using UnMapImagefromVLU function working and returns to free. Following is the detailed description of the steps of the procedure illustrated in  FIG. 14 ( a ).  
         [0000]     Begin of Procedure  
         [0088]     Step  140 : JNL Manager looks for the header which is requested on time or sequence number and time. If there is header, the process continues to Step  141 . If there is no header, the process goes to end of procedure.  
         [0089]     Step  141 : JNL Manager allocates a LDEV of which is same size from LDEV pool. To find same size of volume, JNL Manager looks up in size column  58  on LDEV Manager Table  29 .  
         [0090]     Step  142 : JNL Manager creates a copy of base LDEV to new LDEV.  
         [0091]     Step  143 : JNL Manager applies journal data from the first journal data for base LDEV to the found header.  
         [0092]     Step  144 : JNL Manager exports LDEV through the virtual LU.  
         [0000]     End of Procedure.  
         [0000]     [Before JNL Mechanism] 
         [0093]      FIG. 9  shows a diagram of Before JNL mechanism. Before JNL mechanism creates a history of JNL for base volume where the same data is stored in primary LDEV. This configuration includes primary LDEV (primary LDEV)  35 , base LDEV (Base VOL)  357 , JNL LDEV (JNL VOL)  358  and command device (CMD DEV)  36 . The primary LDEV is a target volume for CDP. The base LDEV  357  stores the same data written to primary LDEV by the host&#39;s write operation and has a sequence number which is counted on each journal operations.  
         [0094]     JNL volume has copy-on-write journal for the base LDEV and related CDP information such as the marker and the input-output (IO) information. CMD DEV is also provided as same as the After JNL mechanism.  
         [0095]     JNL Manager also has a JNL pointer  359  identifying the current write position within the JNL LDEV.  
         [0096]     In this disclosure, it is assumed that the primary LDEV and base LDEV are duplicated for backup purposes. However, it is also possible to use only the target LDEV without the base volume. Therefore one may eliminate the Base LDEV. In this case, the JNL manager maintains the copy on write journal on the target Primary LDEV instead of the base LDEV  357  and stores the journal data on the JNL DEV  358 . Therefore, the procedure in  FIG. 9  executes Steps  1 ,  3  and  4 , but not step  2 .  
         [0097]      FIG. 10  shows procedures of the write command for target LDEV corresponding to the configuration shown in  FIG. 9 . The specific steps of the illustrated procedure are described below.  
         [0000]     Begin of Procedure  
         [0098]     Step  121 : JNL Manager receives SCSI CMD which is sent from the host (Procedure  1  in  FIG. 9 )  
         [0099]     Step  122 : JNL Manager checks if the command is SCSI WRITE commands like WRITE  6 , WRITE  10 , or not. If the command is WRITE command, the procedure goes to Step  123 . If it is not, the procedure is goes to Step  128 .  
         [0100]     Step  123 : JNL Manager writes data, which the SCSI command was sent, to target Primary LDEV based on SCSI command. (Procedure  2  in  FIG. 9 )  
         [0101]     Step  124 : JNL Manager reads old data which is indicated by LBA and size in WRITE operation from Base LDEV  357  and writes header (HD) information (detail in later), the old data, footer (FT) information for the journal starting from JNL Pointer&#39;s  
         [0000]     LBA to the JNL LDEV  358 . (Procedure  3  in  FIG. 9 )  
         [0102]     Step  125 : JNL Manager writes data, which the SCSI command was sent, to Base LDEV  5  based on sent SCSI command. (Procedure  4  in  FIG. 9 )  
         [0103]     Step  126 : JNL manager adds size of header, data, and footer to the pointer.  
         [0104]     Step  127 : JNL Manager returns the result of write to host using SCSI condition state.  
         [0105]     Step  128 : JNL manager executes other SCSI command like READ  6  operation on Primary LDEV.  
         [0000]     End of Procedure  
         [0106]     In case of eliminating Base LDEV, the procedure skips the Step  123  and writes data on primary volume instead of the Base LDEV in Step  125   
         [0107]     Regarding the restore operation based on the MapImageToVLU from the host, the storage subsystem creates an image specified by time in MapImagToVLU or time and sequence number in “Create an image” attribute. Following is the description of the specific steps of the procedure illustrated in  FIG. 14 ( b ).  
         [0000]     Begin of Procedure  
         [0108]     Step  145 : JNL Manager looks for the header which based on time or sequence number and time on JNL VOL. If there is header, the process continues to Step  146 . If there is no header, the process goes to end of procedure.  
         [0109]     Step  146 : JNL Manager allocates a LDEV of which is same size from LDEV pool. To find same size of volume, JNL Manager looks a volume which is as same size as Primary LDEV up in size column  58  on LDEV Manager Table  29  based on free LDEV pool  68  on  FIG. 6 .  
         [0110]     Step  147 : JNL Manager creates a point in time of data for Base LDEV to new LDEV and leaves the current sequence number of journal on LDEV&#39;s sequence number.  
         [0111]     Step  148 : JNL Manager applies journal data from the requested sequence number to the sequence number on new LDEV.  
         [0112]     Step  149 : JNL Manager exports LDEV through Virtual LU. End of Procedure.  
         [0000]     [Marker] 
         [0113]     Before After/Before JNL mechanism, the JNL Manager  24  monitors SCSI operation for CMD DEV which is within consistency group. The consistency group makes IO serialize among LUs including CMD DEV within the group which is defined in CDP Config  33 .  FIG. 11  shows work of JNL manager.  
         [0000]     Begin of Procedure  
         [0114]     Step  131 : JNL Manager receives SCSI CMD from port  22 .  
         [0115]     Step  132 : JNL Manager checks if the SCSI CMD is for CMD DEV based on LUN which is found FCP_LUN in Fibre Channel Frame. The definition of relation between LU and CMD DEV is listed on CMD DEV  85  in table  25 . If the target LUN of SCSI CMD is for CMD DEV, the procedure goes to Step  134 . If the target LUN of SCSI CMD is not for it, the procedure goes to Step  133 .  
         [0116]     Step  133 : JNL Manager processes SCSI command for Primary LDEV. The procedure will continue to Step  110  in  FIG. 8  and Step  120  in  FIG. 10  checking each protection mode  64 ,  65  in  FIG. 5 .  
         [0117]     Step  134 : JNL Manager checks if the SCSI CMD is for CDP based on above described API operations or not. If the CMD is for CDP, the procedure goes to Step  136 . If the CMD is not for it, the procedure goes to Step  135 .  
         [0118]     Step  135 : JNL Manager processes other command for CMD DEV including local mirror like ShadowImage® and remote mirror operation like TrueCopy®.  
         [0119]     Step  136 : JNL Manager checks if the CMD is for InsertMarker operation from Host. If the operation is InsertMarker, the procedure goes to Step  137 . If the operation is not for InsertMarker, the procedure goes to Step  138 .  
         [0120]     Step  137 : JNL Manager selects CDP action from application attribute and action table on marker based on marker&#39;s attribute. We will discuss about relations for application attribute and action in later. And JNL Manager executes the selected action.  
         [0121]     Step  138 : JNL Manager selects operations on CDP and executes the operations.  
         [0000]     End of Procedure  
         [0122]     Regarding Step  137 , JNL Manager selects a CDP action from application attribute and action table. The table is showed in  FIG. 12 . The table is defined by console  402  or application agent. The table may be loaded from console application agent as a file or other kind of distribution method. The table consists of attribute which is indicated operations in storage subsystem. Example of CDP action,  FIG. 13  shows a list of actions. Following are detail of actions.  
         [0123]     (a) “Start Before JNL” Action ( 601 )  
         [0124]     In case of “Start Before JNL” action, JNL manager makes a point in time copy (PIT) data of Primary LDEV to Base LDEV. After PIT, JNL manager suspends  10  from host, turns on the protection mode  65  in  FIG. 5  and writes header and footer information as the marker including “Start Before JNL” as CDP action, attribute, comment from application. JNL manager also writes with incremented sequence number, CMD type, CDP action, attribute and comment if there is in the header and footer information to JNL LDEV. And then, JNL manager starts copy on write journal from Base LDEV to JNL LDEV and restart the IO processing. If Primary LDEV and Base LDEV is same volume, the PIT operation doesn&#39;t need.  
         [0125]     (b) “End Before JNL” ( 602 )  
         [0126]     In case of “End Before JNL” action, JNL manager suspended  10  journaling and duplicated writes between Primary LDEV and Base LDEV. JNL manager turns off the protection mode  65  in  FIG. 5  and writes header and footer information as the marker including “End Before JNL”, attribute and comment from application on the JNL LDEV. JNL manager also writes with incremented sequence number, CMD type, CDP action, attribute, and command if there is in header and footer information to JNL LDEV. If Primary LDEV and Base LDEV is same volume, the suspended of duplicated  10  operation between Primary DEV and Base DEV doesn&#39;t need.  
         [0127]     (c) Start After JNL ( 603 )  
         [0128]     In case of “Start After JNL” action, JNL manager makes a PIT volume between Primary LDEV and Base LDEV. After PIT operation, JNL manager turns on the protection mode  64  in  FIG. 5  and writes header and footer information as the marker including “Start After JNL”, and then starts  10  write journal, attribute and comment from application to JNL LDEV. JNL manager also writes with incremented sequence number, CMD type, CDP action, attribute and comment if there is in header and footer information.  
         [0129]     (d) End After JNL ( 604 )  
         [0130]     In case of “End After JNL” action, JNL manager suspends  10  journaling. JNL manager turns off the protection mode  64  in  FIG. 5  and writes header and footer information as the marker which is “End After JNL” on the JNL LDEV. JNL manager also writes with incremented sequence number, CMD type, CDP action, attribute and comment if there is in header and footer information to JNL LDEV.  
         [0131]     (e) Create an Image ( 605 )  
         [0132]     The operation creates an image of volume after inserting marker at the same time. Regarding the working, JNL Manager writes a header and footer information which indicates application provided attribute which is “Create an image” to JNL LDEV at first. JNL Manager creates an image based on each JNL mechanism which have already been discussed above.  
         [0133]     (f) Application Marker ( 606 )  
         [0134]     Application uses the application marker that is left application&#39;s attribute including transaction ID on comment on JNL LDEV. JNL Manager writes a header and footer information which indicates application provided attribute which is “Application maker” to JNL LDEV  
         [0135]     JNL manager also writes with incremented sequence number, CMD type, CDP action, attribute and comment if there is in header and footer information to JNL LDEV  
         [0136]     (f) System Marker ( 607 )  
         [0137]     JNL Manager will use System marker to leave JNL manager&#39;s event like PIT event in comment on JNL LDEV.  
         [0138]     JNL manager also writes with incremented sequence number, CMD type, CDP action, attribute and comment if there is in header and footer information to JNL LDEV.  
         [0000]     Working with After and Before JNL Mechanism at the Same Time  
         [0139]     After and Before JNL can be work at the same time independently. However the marker may be filter to each mechanism. In this patent, the Action&#39;s  63  in  FIG. 12  helps to distinguish JNL mechanism. If an entry in JNL mechanism  63  corresponding to each attribute is Before, JNL manager writes header/footer information to Before JNL LDEV based on a marker from host. Also if After is, then JNL manager write header/footer information to After JNL LDEV based on a marker from host, If After &amp; Before is, then JNL Manager write header/footer information to both After JNL and Before JNL LDEVs based on a marker from host.  
         [0140]     Upon the creation of the image, the storage subsystem  30  may select the source JNL mechanism. For example, if the DB requests JNL Manager to create an image by the time or the time and the sequence, the JNL manager chooses After JNL mechanism&#39;s image creation. If DB requests Storage Subsystem to create an image between HB S to HB E attribute, then Storage Subsystem chooses Before JNL mechanism&#39;s image creation. The controller has this setting.  
         [0000]     Console  402   
         [0141]     The Console  402  provides a capability for administrator to manage storage subsystem via LAN/WAN  401 . The console provides GUIs for the creation of LDEV, the mapping of LDEV to Logical Unit (LU), a creation of LDEV pool, the mapping of LDEV to LU and etc.  
         [0142]     Specially, to make a link between application attribute and action, the console provides a GUI.  FIG. 16  shows an example of GUI. There are two columns. One is Application Attribute  221 . The Application Attribute is defined and used in API. Another is CDP action. Each attribute has a CDP action. Storage Administrator or DBA selects an action from a list of actions. If Administrator or DBA want to add another or delete row, the button  223  can increase a row to last row or the button  224  can decrease a row from last row.  
         [0143]     After the setting, the Administrator or DBA pushes the apply button  225 . The table information is loaded on application attribute-action table  60  in the storage subsystem  30  using the LoadApplicationAttributesTable function, and then activates the table on controller using the ActivateTable function.  
         [0000]     Configuration for Using the Inventive System with an Application  
         [0144]     Before the application attribute and action table can be used, the system setup must be completed. In this configuration, it is assumed that both Before and After JNL mechanisms are used for a target primary LDEV. The configuration is the following.  
         [0145]      FIG. 21  shows configuration for the storage. Storage administrator allocates the target primary LDEV  35 , CMD DEV  36 , two base LDEVs  37  for After JNL,  357  for Before JNL, After JNL LDEV  38 , and Before JNL LDEV  358 , and maps the target Primary LDEV and the CMD Device to LU on host attached port  22  and make a relation among target Primary LDEV, Base LDEVs and JNL LDEVs configuring CDP config  33  via console  402  in  FIG. 5 . Server Administrator creates a consistency group.  
         [0146]     Storage Administrator also creates virtual LUs and virtual LU group for the consistency group via console  50  or agent  16  and prepares free LDEVs which have the same size as the primary LDEV on LDEV pool  68  to restore data.  
         [0147]     Server system administrator installs OS on the host  10  and discovers the LUs including target LDEV and CMD DEV. Subsequently, DBA or Server Administrator installs the agent  15  on host and establishes a connection with the CMD device.  
         [0148]     After that, DBA installs an application within the host  15 , such as a database (DB) application, which can issue calls to the API of the agent  15  based on the application&#39;s events.  
         [0149]     The application attribute-action table  60  may be defined using two methods. In accordance with one such method, administrator defines this table based on database (DB)-provided configuration file  17 . DBA or storage administrator creates the application attribute-action table  60  using the GUI of the console  402  or the command line interface of the agent  15  of the host  10  based on the configuration file  17  provided by the database. If the host  10  is used, the table information is loaded to the controller  20  using the LoadApplicationAttributeTable function based command, and then the table is activated using the ActivateTable function based command. Another method involves loading the configuration table using the LoadApplicationAttirbuteTable function and then activating it using the ActivateTable function.  
         [0150]     Regarding the attributes, in this description, it is assumed that the attributes are internal commands of the DB. If there are other internal commands, one can create the appropriate command-to-attribute mapping. The corresponding mapping table is shown in  FIG. 20 .  
         [0000]     System Behavior  
         [0151]      FIG. 17  and  FIG. 18  illustrate use cases when an application uses attribute function for CDP.  
         [0152]     Specifically,  FIG. 17  shows an example of Backup behavior which is that Application runs following operations during normal operation.  
         [0000]     Begin of Behavior  
         [0153]     Step  301 : DBA issues mount tablespace operation which is stored on target Primary LDEV to DB.  
         [0154]     Step  302 : DB issues mount&#39;s attribute (MT) via maker.  
         [0155]     Step  303 : Storage Subsystem executes Start After_JNL action ( 603 ) based on application attribute and action table.  
         [0156]     Step  304 : After Storage Subsystem&#39;s ACK, DB mounts tablespace. DB&#39;s client application executes SQL command sets after the mount operation.  
         [0157]     Step  305 : DB executes checkpoints, which DB indicates consistency state for database tables and suspends their operation, DB issues CP&#39;s attribute via maker based on the table  335 .  
         [0158]     Step  306 : Storage subsystem executes Create an image operation based on the table.  
         [0159]     Step  307 : After Storage Subsystem&#39;s ACK, DB continues to execute SQL command sets.  
         [0160]     Step  308 : DBA starts hot backup mode to DB.  
         [0161]     Step  309 : DB issues HB S attribute via maker after the starting hot backup mode.  
         [0162]     Step  310 : Storage Subsystem executes Start Before-JNL action ( 601 ) based on the table  60 .  
         [0163]     Step  311  After Storage Subsystem&#39;s ACK, DB becomes hot backup mode.  
         [0164]     Step  312 : DB returns the prompt to DBA.  
         [0165]     Step  313 : DB requests to insert application maker with transaction number like System Commit Number after each commit of transaction via agent InsertMarker API. The transaction number is stored on comment field in marker.  
         [0166]     Step  314 : Storage subsystem executes application marker operation.  
         [0167]     Step  315 : After Storage subsystem&#39;s ACK, DB continues to process their transaction.  
         [0168]     Step  316 : DBA requests end of hot backup mode.  
         [0169]     Step  317 : DB issues HB E attribute via maker after the hot backup mode based on the table  335 .  
         [0170]     Step  318 : Storage Subsystem executes End of Before JNL action ( 602 ) based on the table  60 .  
         [0171]     Step  319 : After Storage Subsystem&#39;s ACK, DB finishes hot backup mode continue to execute SQL command sets.  
         [0172]     Step  320 : DBA receives their prompt.  
         [0173]     Step  321 : DBA un-mounts table space.  
         [0174]     Step  322 : DB unmounts the tablespace and issues MT E attribute via maker based on the table  335 .  
         [0175]     Step  323 : Storage Subsystem executes End of After JNL action ( 604 ) based on the table  60 .  
         [0176]     Step  324 : After Storage Subsystem&#39;s ACK, DB returns result to DBA.  
         [0177]     Step  325  DBA receives their prompt.  
         [0000]     End of Behavior  
         [0178]     Regarding restore operation, the DBA requests an image which is taken on hot backup mode to storage subsystem via agent&#39;s API. The requests from DBA via DB are to search for HB S attribute using SearchMarker API, to receive of a list of HB S marker, to request a image specifying by sequence and time which is select from the list of HB S marker using MapImageToVLU or MapCTGtoVLUG API. DBA can use backup data from VLUs. To recovery data on DB, DBA applies the DB&#39;s log to the DB&#39;s tablespace using DB&#39;s roll forward process because CDP take the DB log and tablespace by atomic break.  
         [0179]     If DBA needs to rollback and rollforward to a transaction number, the DB&#39;s log and table space doesn&#39;t have rollback information. In this situation, the present invention helps to recover the rollback. If the image is not modified, Storage applies journal data from a header which has user requested attribute&#39;s sequence until image&#39;s sequence number. To select before or after journal, the JNL manager selects a before JNL if the requested number is below image&#39;s sequence number. Also the JNL manager selects after JNL if the requested sequence number is above it.  
         [0180]     For example ( FIG. 21 ), there is an image  341  which is mapped to VLU has 26 as sequence number. If DBA wants to restore  40  as sequence number in SCN  11 , JNL Manager selects the After JNL. On the other hand, if DBA wants to restore  23  as sequence number in SCN  9 , JNL Manager selects the Before JNL.  
         [0181]     The benefits considering application behavior are the following.  
         [0182]     Regarding mounting/un-mounting operation which use Step  301  and  315 , the length of journal can be eliminated during un-active of DB.  
         [0183]     Regarding checkpoint operation which is Step  306 , administrator can use pre-created volume image.  
         [0184]     Regarding start/end backup operation which is Step  309  and  312 , DB can create rollback image using After JNL mechanism.  
         [0185]     Regarding recovery, DBA can rollback data on restore even if the DB enters backup mode.  
         [0186]      FIG. 18  illustrates another example, which involves an application executing the followings operations during the recovery procedure. In this example, the DBA takes charge when a database table or related information is lost.  
         [0000]     Begin of Behavior  
         [0187]     Step  341 : The DBA indicates to database to recover table space like RECOVER TABLESPACE.  
         [0188]     Step  342 : After the operation, the DB inserts a marker which includes RT S attribute based on the table  335  via the agent InsertMarker API.  
         [0189]     Step  343 : Storage Subsystem executes Start Before JNL action ( 601 ) based on request RT S attribute based the table  60 .  
         [0190]     Step  344 : After Storage subsystem&#39;s ACK, DB starts to process recovery operation for a transaction from their logs.  
         [0191]     Step  345 : DB inserts a maker with transaction number like System Change Number (SCN) after each commit of transaction which is written on journal via agent InsertMarker API. The transaction number is stored on comment field in marker.  
         [0192]     Step  346 : Storage subsystem executes application marker operation.  
         [0193]     Step  347 : After Storage subsystem&#39;s ACK, the DB continues to process recovery operation for a transaction from their logs.  
         [0194]     Step  348 : The DBA receives current executed transaction number on recovery from the DB.  
         [0195]     Step  349 : After the DB applied all of the logs, DB issues marker RT E which signals the end of the recovery tablespace.  
         [0196]     Step  350 : Storage subsystem executes End Before-JNL action ( 602 ) based the table  60 .  
         [0197]     Step  351 : After Storage Subsystem&#39;s ACK, the DB returns result to the DBA.  
         [0198]     Step  352 : DB returns the prompt for the DBA.  
         [0000]     End of Behavior  
         [0199]     When DBA finishes restoring data after roll forward operation, if the DBA requests DB to search a marker by SCN number in the comment field of the JNL by the SearchMarker function call, the storage subsystem provides a list of markers which are written as a portion of the header. From the list of markers, DBA selects sequence # and time to retrieve the image corresponding to the SCN appearing in the comment. Then the DBA requests the DB to get volumes specified by sequence # using MapCTGtoVLUG function call. Storage Subsystem provides a set of images on Virtual LUs which is specified on Virtual LU Group. The DB may mount table space after the mapping of Virtual LU.  
         [0200]     Finally, it should be understood that processes and techniques described herein are not inherently related to any particular apparatus and may be implemented by any suitable combination of components. Further, various types of general purpose devices may be used in accordance with the teachings described herein. It may also prove advantageous to construct specialized apparatus to perform the method steps described herein. The present invention has been described in relation to particular examples, which are intended in all respects to be illustrative rather than restrictive. Those skilled in the art will appreciate that many different combinations of hardware, software, and firmware will be suitable for practicing the present invention. For example, the described software may be implemented in a wide variety of programming or scripting languages, such as Assembler, C/C++, perl, shell, PHP, Java, etc.  
         [0201]     Moreover, other implementations of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. Various aspects and/or components of the described embodiments may be used singly or in any combination in the computerized storage system with data replication functionality. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.