I think the issue you have with Agile development is due to a lack of understanding of Agile practices, based on the statement "... allow and encourage the changing of code freely and often." If you just take a brief look at Agile practices, that's what you see and hear. But these changes are not supposed to happen randomly (if they do, then the rest of the team is using "Agile practice" as an excuse to not do any design work). The goals of Agile practices are to be able to embrace changing business requirements. This does not mean that "we'll design on the fly" is acceptable (what I might be saying here as a corollary is that it's just as easy to create a bad system using Agile methods as it is using any process). It does not mean "we don't plan".

Many of these changes occur as the application/system develops and users see what it is they are getting. Two common reactions during this phase are "I didn't know the application would act that way" or "I know that's what I said, but that's not what I meant." Developers (and DBAs) need to be able to react to this type of situation if the business is to be successful. Sometimes that means adding columns to a table, for example. But the implications of doing that to a production table with millions of rows have to be taken into account when planning this change into an iteration. And if a DBA is not part of the development team planning these iterations, than s/he should get in there pronto.