On Thu, Jan 20, 2011 at 10:42 AM, Bradley Holbrook
<operations_brad...@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.
