home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / sybase / 519 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.7 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!ucbvax!mtxinu!sybase!elton
  2. From: elton@sybase.com (Elton Wildermuth)
  3. Newsgroups: comp.databases.sybase
  4. Subject: Re: DD vs DUMP DATABASE
  5. Message-ID: <27301@sybase.sybase.com>
  6. Date: 17 Dec 92 21:16:39 GMT
  7. References: <1992Dec8.163842.13610@netcom.com>
  8. Sender: news@Sybase.COM
  9. Organization: Sybase, Inc.
  10. Lines: 84
  11.  
  12. Regarding using dd to dump a database:
  13. >
  14. >    A short time ago, someone posted about a customer who had saved their
  15. >database using 'dd' instead of 'dump database.'  I am currently trying to
  16. >help a customer who has decided that this is a good idea.
  17.  
  18. Ahem.  Two things about this.
  19.  
  20. First:  Sybase DOES NOT recommend this practice.  As a support engineer,
  21. I "helped" far too many customers who thought that would be the way to go.
  22. The nature of my "help" was to identify the corrupted databases so that
  23. they could set about recreating them from the ground up.  Worse, the
  24. corruption is not limited to the single database that was backed up; it
  25. extends to every database that shares an OS file with that database.
  26.  
  27. Second:  Okay, you're going to do it anyway.  Follow these steps, or you
  28. WILL have corruption in your system after you restore, and Sybase CAN NOT
  29. help you recover from it.  DO NOT take this advice as a recommendation
  30. from Sybase; see the preceding paragraph.  Sybase's recommendation is,
  31. "Don't do it!"
  32.  
  33.     1.    Determine which OS files your database resides on.  You will
  34.     need to copy the lot in order to get a good dump.  Say:
  35.  
  36.         use master
  37.  
  38.         select distinct d.phyname
  39.         from sysusages u, sysdevices d, sysdatabases b
  40.         where b.name = <database-name>
  41.           and b.dbid = u.dbid
  42.           and u.vstart between d.low and d.high
  43.           and d.status & 2 = 2
  44.  
  45.     Write the physical names down.  This is the list of devices you
  46.     will have to copy.
  47.  
  48.     2.    Determine if any other databases use those devices.  If they do,
  49.     you must repeat step 1 for every other database residing on those
  50.     same devices.  Repeat steps 1 and 2 until you have determined ALL
  51.     devices containing ANY portion of a database residing on a device
  52.     found in ANY REPETITION of step 1.  (In fact, while you're at it,
  53.     why not just "select phyname from sysdatabases where status & 2 = 2",
  54.     and have done with it?)  To do this:
  55.  
  56.         select b.name
  57.         from sysusages u, sysdevices d, sysdatabases b
  58.         where b.dbid = u.dbid
  59.           and u.vstart between d.low and d.high
  60.           and d.phyname in ( <repeat the select from step 1> )
  61.         order by 1
  62.  
  63.     REMEMBER:  Any device that wasn't in the original list must also
  64.     get copied, along with the devices for all databases on those
  65.     devices.  Repeat until thoroughly sick and tired of the search.
  66.  
  67.     3.    (OPTIONAL) Checkpoint your databases.  This saves recovery time
  68.     when you restart the server.
  69.  
  70.     4.    SHUT DOWN THE SQL SERVER.  If you don't do this, I personally
  71.     guarantee data corruption upon recovery.
  72.  
  73.     5.    Use dd, or tar, or whatever command you like to save the files
  74.     you noted in step 1 above.
  75.  
  76.     6.    Restart SQL Server.
  77.  
  78. This should ensure that you copy all the correct devices to save all the
  79. data for every database touched by this procedure.
  80.  
  81. Why bother?  Because if you don't, after you restore your dump, some
  82. portion of some database will be out of sync with the rest of that
  83. database.
  84.  
  85. Oh, I forgot:  don't restore the files you dumped if you have subsequently
  86. done an ALTER DATABASE on any of the affected devices, OR on any of the
  87. affected databases.  Otherwise, you will have to go in by hand and revise
  88. master.dbo.sysusages to correct its idea of where the databases are, or it
  89. will report corruption.  Not fun.
  90.  
  91. Like I said:  why not just select phyname from sysdevices and have done
  92. with it?  Better yet, why not just do it the slow way, through DUMP DATABASE?
  93.  
  94. Best of luck,
  95.             -- Elton
  96.