home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / bit / listserv / db2l / 263 < prev    next >
Encoding:
Text File  |  1993-01-24  |  1.8 KB  |  57 lines
  1. Newsgroups: bit.listserv.db2-l
  2. Path: sparky!uunet!psinntp!cmcl2!panix!awerman
  3. From: awerman@panix.com (Aaron Werman)
  4. Subject: Re: DB2 Back up procedure
  5. Message-ID: <C1D1rw.J2s@panix.com>
  6. Organization: PANIX Public Access Unix, NYC
  7. References: <930124.091333.SAT.OPRIMS@SAUPM00.BITNET>
  8. Date: Sun, 24 Jan 1993 13:35:55 GMT
  9. Lines: 46
  10.  
  11.  
  12. This is an important thread (DB2 catalog recovery). Consider the
  13. goals of the recovery process. These may not all apply:
  14.  
  15.     1. Restarting DB2 after a failure of DASD containing the
  16.        catalog or directory.
  17.  
  18.     2. Restarting DB2 after DB2 software failure or operator
  19.        error destroys the catalog.
  20.  
  21.     3. "Oops, what do we do now" type procedures, e.g. accidental
  22.        dropping of a production database.
  23.  
  24.     4. Audit concerns, e.g. "who had access to table X last Thursday.
  25.  
  26. Each of these issues has a different recovery strategy. (1) Generally
  27. involves a combination of DB2 backup (COPY) and external DASD dumps.
  28. (2) Is assisted tremendously by external dumps of DB2 data sets. (3)
  29. and (4) can be further assisted by keeping human readable copies of 
  30. catalog information (such as DBID...) either on paper or in the computer.
  31.  
  32. Don't forget that DB2 requires all of:
  33.  
  34.     - DB2 catalog
  35.  
  36.     - DB2 directory
  37.  
  38.     - BSDS
  39.  
  40.     - All ICF catalogs
  41.  
  42.     - Logs
  43.  
  44. Many of these can be recovered from the others (e.g. - recovering the BSDS
  45. from logs and DB2 catalog and directory). In most cases, this is a slow,
  46. complex, and tedious process; not something that you want to try the first
  47. time during a crisis, nor something you would prefer to do at all.
  48.  
  49. In all cases, the recovery strategy is completely dependant on the speed
  50. that you need to be able to recover. For example, stable production 
  51. environments with very fast recovery requirements tend to rely on warm or
  52. hot backup sites or at least DASD dumps of the catalog.
  53.  
  54. -- 
  55.  
  56. Aaron Werman        awerman@panix.com
  57.