Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Externalizing updated pages for a DB2 object prior to serializing on the DB2 object to minimize the unavailability of the object

IP.com Disclosure Number: IPCOM000013737D
Original Publication Date: 2001-Jul-21
Included in the Prior Art Database: 2003-Jun-18
Document File: 1 page(s) / 40K

Publishing Venue

IBM

Abstract

Today customers back up their data and many require that a consistent copy needs to be made, which means no users can be updating the data while the backup is being made. When external means are used to perform the backup process (e.g. , the DB2 COPY utility can invoke DFSMSdss DUMP or COPY functions), then while the DBMS disallows updates to the data and before the backup copy process can actually start, all data pages that contain recent updates of the data being copied must first be externalized from within DB2 to the physical object being backed up. Currently this process is performed just prior to invoking DFSMSdss. If the number of updated pages to be externalized is significant, it lengthens the time the data is unavailable for updating. To minimize this time, we will first externalize all updates before serializing on the DB2 object. Then, after we have placed the object into "read only' status, we will once again externalize any recent updates. There should be very few, since the process was just performed prior to placing the object into "read only" status. Users are looking for ways to minimize the outages of their data caused by utilities placing the data into "read only" status while executing. By performing the externalization of updates prior to placing an object into "read only" status, we will be minimizing the unavailbility of their data. 1

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 99% of the total text.

Page 1 of 1

  Externalizing updated pages for a DB2 object prior to serializing on the DB2 object to minimize the unavailability of the object

    Today customers back up their data and many require that a consistent copy needs to be made, which means no users can be updating the data while the backup is being made. When external means are used to perform the backup process (e.g. , the DB2 COPY utility can invoke DFSMSdss DUMP or COPY functions), then while the DBMS disallows updates to the data and before the backup copy process can actually start, all data pages that contain recent updates of the data being copied must first be externalized from within DB2 to the physical object being backed up. Currently this process is performed just prior to invoking DFSMSdss. If the number of updated pages to be externalized is significant, it lengthens the time the data is unavailable for updating. To minimize this time, we will first externalize all updates before serializing on the DB2 object. Then, after we have placed the object into "read only' status, we will once again externalize any recent updates. There should be very few, since the process was just performed prior to placing the object into "read only" status.

    Users are looking for ways to minimize the outages of their data caused by utilities placing the data into "read only" status while executing. By performing the externalization of updates prior to placing an object into "read only" status, we will be minimizing the unavailb...