home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / misc / 659 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.0 KB
  1. Xref: sparky vmsnet.misc:659 comp.os.vms:12794
  2. Path: sparky!uunet!gatech!bloom-beacon!eru.mt.luth.se!lunic!sunic!seunet!enea!sommar
  3. From: sommar@enea.se (Erland Sommarskog)
  4. Newsgroups: vmsnet.misc,comp.os.vms
  5. Subject: Re: How to resize an Rdb Database
  6. Message-ID: <1992Jul26.091514.21517@enea.se>
  7. Date: 26 Jul 92 09:15:14 GMT
  8. References: <1992Jul15.162637@mccall.com>
  9. Organization: Enea Data AB
  10. Lines: 37
  11.  
  12. Terry Poot (tp@mccall.com) writes:
  13. >I have an Rdb database that has grown too large. The data in it has been
  14. >trimmed down, but I need to shrink the actual files. I don't need explicit
  15. >directions, just for someone to point me in the proper direction. Things
  16. >I've thought off are:
  17. >
  18. >1) backup/restore. Does this resize the files?
  19.  
  20. Don't remember offhand, but I don't think so.
  21.  
  22. >2) Import/export. Sounds like a slow process.
  23.  
  24. Well, you have a large file with a lot of holes in which you want to
  25. remove. Does that sound like a fast process to you. IMPORT/EXPORT
  26. is the standard method to handle this problem, as far as I know.
  27.  
  28. >3) rmu/copy. Does this resize the files? Can I copy one area at a time so
  29. >that I don't need as much free space at once? Can it be done while the
  30. >database is in use?
  31.  
  32. I don't think you can expect to resize the files with users in the
  33. database. I don't think RMU/COPY does much resizing anyway.
  34.  
  35. >3) Create new areas and use change storage map to move the data,
  36. >then delete the old files. Same questions as above.
  37.  
  38. Yes, this would probably work, but that is not what you have storage
  39. areas for. I don't recall offhand if you have to do an IMPORT/EXPORT
  40. here or not, but in any case, this is a more complex operation so guess
  41. which one which take the longest time. This could be an option, however, 
  42. if your database is huge and only one storage area is in need of compression.
  43.   By the way, don't just delete the files, drop the storage areas first,
  44. unless you want a corrupt data base.
  45.  
  46. -- 
  47. Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
  48. Dabras Laiks!
  49.