Re: Reorganizing the DB.. the tricky way

Anton Buijs wrote:

> DA Morgan <damorgan_at_exxesolutions.com> schreef in berichtnieuws
> 3E909DD0.F6E37025_at_exxesolutions.com...
> | Anton Buijs wrote:
> |
> | I would argue that in a production database there is no place for ALTER
> TABLE
> | ADD column as is being assumed here. That to do so is irresponsible. The
> | existing data should be dumped to a temp table, the table truncated, then
> | modified, and the data returned to the table in combination with whatever
> values
> | are required by the modification.
> |
> | Daniel Morgan
> |
>
> Don't agree it is irresponsible, it is the real world! The production DBA is
> always the last to know that a column has to be added, no time to wait for
> the proper moment to take the application down for a while so you must add
> the column NOW. And do the reorg later. Your or mine scenario: table is
> unavailable for some time. And in 9i I'am in favour of adding the column and
> reorg later: we can really do alter table move online, without downtime, if
> I recall it well from the New features course (unfortunately we only have a
> small 9i playground at this moment, but real 9i db's are coming soon)

I stand on irresponsible. 'Real-world' should not be a convenient euphimism for bad practices.

DBAs are responsible for the integrity of the production environment. Developers can make as big a mess of development as they wish but ultimately the DBA must control production. If it is otherwise the DBA should head for the door and a new job or suffer silently every evening and weekend they are working for free.

Creating objects and altering objects should always be owned by the DBA when things move from testing to production. DBAs should stay out of development and developers should stay out of production. The result of blurring of these lines can be found in far too many places.

But yes the table will be unavailable. And that is something that should be factored into the mix by development when they decide to modify the object. Which makes this an excellent place to add that development teams that don't include a DBA capable of thinking this far in advance are doomed to create messes.

Daniel Morgan Received on Sun Apr 06 2003 - 17:59:54 CDT