home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / sybase / 513 < prev    next >
Encoding:
Text File  |  1992-12-21  |  5.1 KB  |  103 lines
  1. Newsgroups: comp.databases.sybase
  2. Path: sparky!uunet!caen!spencer
  3. From: spencer@med.umich.edu (Spencer W. Thomas)
  4. Subject: 4.2 to 4.8 upgrade experiences
  5. Message-ID: <SPENCER.92Dec18120417@guraldi.med.umich.edu>
  6. Date: Fri, 18 Dec 92 12:04:17 EST
  7. Organization: University of Michigan
  8. Distribution: comp
  9. Nntp-Posting-Host: guraldi.itn.med.umich.edu
  10. Lines: 91
  11.  
  12. This week, we finally decided to do the 4.8 upgrade thing.  After
  13. hearing from the net how easy it was, we (first mistake) started early
  14. in the afternoon.  We've got a pretty small database, so figured it
  15. shouldn't take too long.
  16.  
  17. 1. Dump current databases to DAT tape.
  18. 2. Move old software out of the way.
  19. 3. Install new software from tape.  OOPS, it's bigger than the
  20.    partition that the old software fit in.  Reinstall without DWB.
  21. 4. (Mistake 2) Run sybconfig and ask it to upgrade. 
  22. 5. Upgrade fails because we forgot to increase the SHMEM size in the
  23.    SunOS kernel.  Takes a while to figure this out because we're
  24.    working from the wrong copy of the installation manual (we've got
  25.    one with full instructions, one with just instructions for the
  26.    toolset (APT)).
  27. 6. After finding the right manual, reload SunOS and reboot.
  28. 7. Run buildmaster, installmaster, and load database master from tape.
  29. 8. Now dbcc fails on all the user databases (overlap of something
  30.    with object "sysgams").  Restore them.
  31. 9. Run upgrade again.  dataserver goes into an infinite loop during
  32.    upgrade.
  33. 10. Buildmaster, installmaster load database master, load database
  34.    (user databases).
  35. 11. Dbcc checkalloc shows an inconsistency in one of the user
  36.    databases that apparently is present in the dump file.  Offending
  37.    table is not used any more (this is the "test" db, so has some junk
  38.    in it).  Drop table fails miserably because of allocation problems.
  39. 12. Restore test database again, set up directories for 4.2 server,
  40.    and go home (almost 8pm at this point).
  41. 13. (Next morning) Using useful script from comp.databases.sybase,
  42.    dump out the schema of the "broken" db. Use bcp -n to dump all
  43.    tables into flat files.  Drop database, recreate, rebuild schema,
  44.    bcp data back in.
  45. 14. Dump all databases to DAT again.
  46. 15. Tryupgrade succeeds.  All right!
  47. 16. Run sybconfig.  Upgrade fails with a memory allocation failure
  48.    (suggestion: physical memory fragmented), it wanted 2million of
  49.    some unknown unit of memory (if bytes, I don't understand why it
  50.    failed, if some larger unit, why was it asking for that much??).
  51.    This problem was repeatable at this point, but disappears later.
  52.    Not sure why.
  53. 17. buildmaster, installmaster, load database master from dat, load
  54.    user databases from dat.  The last load fails with a bogus logical
  55.    page number.  Very mysterious.
  56. 18. dbcc checkalloc shows serious problems in that user database, but,
  57.    more seriously, also in model and tempdb.  buildmaster,
  58.    installmaster does not fix these, and they can't be dropped.
  59. 19. Rerun 4.2 sybinstall to get a totally clean db.  Load old master
  60.    from tape.  Server now marks old user dbs as unrecoverable, so drop
  61.    them with dbcc dbrepair and reload (except for the one that won't
  62.    load) from tape.
  63. 20. Investigate load problem, and discover that there is a bad spot on
  64.    the tape in the middle of the last dump.  This is why it won't load
  65.    (see my other message where I flame on this).
  66. 21. Rebuild offending database from schema and bcp files.
  67. 22. Run tryupgrade.  It works.
  68. 23. Run real upgrade with fingers crossed.  It works, too.
  69. 24. Start 4.8 dataserver.  Runs fine.
  70.    
  71. Moral(s) (All obvious to the experienced practitioner, I'm sure, so I
  72.    don't need any "I told you so" responses -- I'm already kicking
  73.    myself enough, and I should know better after 20 years in this
  74.    field):
  75.  
  76. A. Make sure (doubly) that your DB is absolutely clean before you
  77.    upgrade.  Any inconsistencies will totally screw up the upgrade.
  78. B. Make sure the 4.8 server will run before applying it to a real
  79.    database.  We could have avoided the first round of failure if we
  80.    had done this.  Just try to create a toy DB with it.
  81. C. Make sure your dumps are clean and readable.  We had both
  82.    problems: our readable dump wasn't clean, and our clean dump wasn't
  83.    readable.
  84. D. Consider doing an unload/reload instead of dump/load.  This is
  85.    significantly more painful, but has less that can go wrong with it.
  86.    Be sure to dump tables like sysusers, and be sure to get all your
  87.    types, triggers, rules, and stored procedures in addition to the
  88.    data.
  89. E. Make sure you know the exact segment configuration of each
  90.    database, because if you don't, you may not be able to load it from
  91.    a dump if you had to drop it or dbcc dbrepair(x,dropdb) it.  (The
  92.    installation manual tells you to do this.  In my experience, it's
  93.    really important!)
  94. F. Start early in the morning on a day when you have nothing else to
  95.    do.  If all goes well, then you can regard the rest of the day as
  96.    "won time".  If it doesn't, you reduce the amount of overtime
  97.    you'll have to put in.
  98.  
  99. --
  100. =Spencer W. Thomas         |  Info Tech and Networking, B1911 CFOB, 0704
  101.    "Genome Informatician"    |  Univ of Michigan, Ann Arbor, MI 48109
  102. Spencer.W.Thomas@med.umich.edu    |  313-747-2778, FAX 313-764-4133
  103.