On Thu, Jan 20, 2011 at 10:42 AM, Bradley Holbrook
<operations_bradley@servillian.ca> wrote:
> Thanks Scott... a couple comments.
>
> Our developers never decide what goes to where... they just happily plumb
> away on the development db until we're ready to take our product to testing
> (at regular intervals), once QA is passed, we wish to apply these to live.
> We have several diff tools and sync tools, but they take forever (especially
> the ones that only go one schema at a time).
>
> The DDL Logging sounds like a sufficient solution, can it be configured to
> only record create and alter commands (or create or replace commands on
> functions or updates on sequences, etc)? I'd likely write a script to have
> this emailed to me at the end of every day. I'm going to google DDL logging
> (never heard of it), but any good resources off the top of your head?
It's basically logging anything that changes the structure of the
database. It would be easy enough to grep out what you do and don't
want later.
> Martin French is right though, ask your developers to write down all their
> SQL struct changes and they look at you funny... and being a developer
> myself I'd look at me funny. If you forget just once you're screwed into a
> day sifting through tables and code.
I've worked in three different shops now as a dev-dba and sysadmin,
and in all three, all DDL changes had to be committed and / or handed
over to the DBAs. period. Look funny all they want, they either give
up the DDL or their code doesn't get pushed off dev servers onto
anything else. At the very least they should be able to tell you
which tables changed to go with which code changes, or you're not sure
what code you can and can't push. I get both of your point on this,
but it's a discipline issue that needs sorting out with the developers
if you want to have reproduceable ddl changes in all your systems that
match the code changes.