home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / informix / 1623 < prev    next >
Encoding:
Text File  |  1992-07-28  |  2.7 KB  |  55 lines
  1. Newsgroups: comp.databases.informix
  2. Path: sparky!uunet!caen!hellgate.utah.edu!perle.utah.edu!cdoe
  3. From: cdoe%perle.utah.edu@cs.utah.edu (Carlton Doe)
  4. Subject: OnLine 5.0 BUG -- create index problems
  5. Date: 28 Jul 92 16:05:45 MDT
  6. Message-ID: <1992Jul28.160546.13164@hellgate.utah.edu>
  7. Organization: University of Utah CS Dept
  8. Lines: 45
  9.  
  10.  
  11. 7.27.92
  12.  
  13.     MAJOR BUG IN 5.0 -- tables MUST be locked in exclusive mode
  14.        before creating indexes or risk trashing the systables
  15.        rowid pointers into the indexes.  This trashes the data-
  16.        base requiring a dbexport/dbimport or restore from archive.
  17.  
  18. Just a warning to OnLine 5.0 DBA's.  The other day I needed to drop and recreate some
  19. indexes on most of the tables in one of my databases.  I had done some table
  20. shuffling within extents and some of the tables had grown significantly since their
  21. original creation.  
  22.  
  23. I started a transaction, dropped the indexes and recreated them.  I checked the
  24. sql script when finished as well as the engine log -- no errors recorded.  I committed 
  25. the transaction and went home.  NOTE: Locks are tuned to 3000 and I was running a 
  26. "tbstat -u -r 60" during the entire process and the greatest number of locks used was 685.
  27.  
  28. The next morning, no one could access the database.  I know, I know, I shouldn't have
  29. believed the log or the result code from the script and should have tried to run 
  30. some applications but I figured the engine had better be able to create indexes
  31. correctly.  After much research on my part as well as tech support, we were able to 
  32. reproduce AND AVOID the problem with a test table.  By not locking the table in exclusive
  33. mode, the index would be created but the rowid pointers would get screwed up.  A
  34. tbcheck -ci showed the index as ok but a tbcheck -cI (which hits the rowids) would
  35. fail all over the place.  Worse, it (tbcheck -cI) couldn't correct the problem
  36. because it couldn't drop the index to recreate it.  I also couldn't manually drop the index
  37. and recreate it either; I got unknown rowid errors all over the place.  The tech support 
  38. engineer later found notes to support this.
  39.  
  40. The only solution to the problem is to recreate the database either through a 
  41. dbexport/dbimport or through restoration from archive.  I chose the later as
  42. I always make it a practice to archive the system before and after I make any 
  43. major changes to any of the databases.  
  44.  
  45. I must say I was pleased with the restoration process.  I had never done a restore
  46. in the OnLine environment just Turbo.  The restore ran very smoothly and most
  47. important of all, quickly!
  48.  
  49. Anyway, I pass this on to perhaps help someone avoid the same trap we ran into.
  50.  
  51. -------------------------------------------------------------
  52. Carlton Doe 
  53. cdoe@sunset.utah.edu    
  54. attmail: attmail!alexis!carlton
  55.