J
James Palmer
Guest
Thanks Rob. Appreciate the thoughts. I've moved on from the dev db to uat now. It is on a much better machine. 
James Palmer | Application Developer Tel: 01253 785103 From: Rob Fitzpatrick Sent: 04/06/2014 01:10 To: TU.OE.RDBMS@community.progress.com Subject: RE: [Technical Users - OE RDBMS] Remove a storage area James, I think trying to do maintenance within a single DB is making your life more challenging. As Tom pointed out it also makes a back-out plan more challenging. Also, starting fresh gives you the opportunity to revisit DB design decisions about area RPB and BPC that are perhaps years old and no longer fit the data. I'd just design a new structure, taking into account what you've learned from the present application environment's static analysis and run-time data, and build a new DB. You can do the new area assignments in your .df and load data, or you can load your existing schema without area assignments and run a tablemove script to put tables and indexes in their new homes. This runs very quickly when there's no data. Then: - binary dump from your source - binary load to your target - load _user, seqvals, and SQL permissions if necessary - back up - idxbuild (with all the new performance goodies) - back up and you're good to go. That way you don't have to mess with extent removal, area truncation, etc. Then once you validate your load (analysis of log files, comparison of tabanlys output, etc.), blow away your old DB if you like. P.S. This isn't the dev DB in the external USB2 enclosure, is it? :-/
Continue reading...
James Palmer | Application Developer Tel: 01253 785103 From: Rob Fitzpatrick Sent: 04/06/2014 01:10 To: TU.OE.RDBMS@community.progress.com Subject: RE: [Technical Users - OE RDBMS] Remove a storage area James, I think trying to do maintenance within a single DB is making your life more challenging. As Tom pointed out it also makes a back-out plan more challenging. Also, starting fresh gives you the opportunity to revisit DB design decisions about area RPB and BPC that are perhaps years old and no longer fit the data. I'd just design a new structure, taking into account what you've learned from the present application environment's static analysis and run-time data, and build a new DB. You can do the new area assignments in your .df and load data, or you can load your existing schema without area assignments and run a tablemove script to put tables and indexes in their new homes. This runs very quickly when there's no data. Then: - binary dump from your source - binary load to your target - load _user, seqvals, and SQL permissions if necessary - back up - idxbuild (with all the new performance goodies) - back up and you're good to go. That way you don't have to mess with extent removal, area truncation, etc. Then once you validate your load (analysis of log files, comparison of tabanlys output, etc.), blow away your old DB if you like. P.S. This isn't the dev DB in the external USB2 enclosure, is it? :-/Continue reading...