ALTER TABLE stickiness

Well, it's about that time again. Once or maybe twice a year, we upgrade our database applications to support greater functionality, which undoubtedly entails altering the structure of some tables. The last time we did this on our largest table (~1.8 Million WIDE rows of historical transaction data), it took 17 hours to perform the ALTER. This was using OnLine v5 on a Sparc-10. We now have about 2.5 million rows, and are going to repeat the process. Since tha last time, we have upgraded to OnLine v7.11, on a Sparc-20, which should help, but we are still faced with hours of database downtime for this upgrade. (Not completely down, since we can reconnect users to a read-only copy, but our customer service operates 24x7, so any updating has to get deferred). I know that we can take steps to decrease the amount of time that the tables will be unavailable, like using narrower rows, but due to the sheer number of rows, it seems like any ALTER will still be on the order of several hours, including turning logging off & on (what fun). I'd like to hear stories about how anyone else has handled this type of scenario, where it is not acceptable to take the entire database away from users to run ALTER TABLE statements for a day or two. Paul Kapp ----> PLKapp@aol.com -OR- plk@interactive.visa.com