home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / informix / 2760 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.1 KB

  1. Path: sparky!uunet!haven.umd.edu!mimsy!prometheus!media!irscscm!bogart!mfaurot
  2. From: mfaurot@bogart.uucp (Michael Faurot)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: Help, tbtape is trashing my rootdbs!
  5. Message-ID: <1992Dec17.125812.117@bogart.uucp>
  6. Date: 17 Dec 92 12:58:12 GMT
  7. References: <1992Dec14.171459.21988@informix.com>
  8. Organization: ism:c:m/xo
  9. Lines: 35
  10. X-Newsreader: Tin 1.1 PL4
  11.  
  12. davek@informix.com (David Kosenko) writes:
  13.  
  14. : I will speculate that the reason the second database seems to "cause" the 
  15. : problem is that the space allocated for the tables in that database contain
  16. : the problem area.  Since tbtape will only try to read allocated space, it
  17. : does not encounter the problem until the second database is created. I am 
  18. : not sure why the bad block was not encountered at the create time - it must
  19. : be that the space allocated is not all read at the create time.
  20. : What you should do is run a low-level disk surface check on the devices you
  21. : are using for your chunks.  Typically, this problem is caused by bad blocks 
  22. : present on the device.
  23.  
  24. I suspected bad blocks on the device as well.  I haven't low leveled
  25. the device just yet, but I figured I could easily find out if in fact
  26. there were bad blocks by using dd.  Using dd I had it read the entire
  27. surface area and never got a hick-up.  Since OnLine consistently has
  28. this problem during back-up I would assume that dd should have a
  29. problem reading the device as well--but that wasn't the case.
  30.  
  31. Is my logic flawed in assuming dd would report some sort of error
  32. condition if it couldn't read some blocks on the partition?
  33.  
  34. : As per bringing your system back up after a "bad block experience": if you
  35. : edit your tbconfig file and set MIRROR to 1, you will be able to restart
  36. : your system even though the chunk is marked as down.
  37.  
  38. Thanks for the tip!
  39.  
  40. -- 
  41.  
  42. +--------------------+-------------------------------------------------------+
  43. |   Michael Faurot   | Domain: mfaurot@bogart.UUCP                     |
  44. |   ------- ------   | UUCP:   ...{irscscm|mimsy}!bogart!mfaurot             |
  45. +--------------------+-------------------------------------------------------+
  46.