Eu vi muitas maneiras de tentar lidar com isso e, no final, acho que você precisa apenas manter scripts manuais.

Agora, você não precisa necessariamente escrever então você mesmo. No MSSQL, enquanto você está fazendo uma mudança, há um pequeno botão para Gerar Script, que irá gerar um script SQL para a mudança que você está fazendo. Eu sei que você está falando sobre o Oracle, e já faz alguns anos desde que trabalhei com a GUI deles, mas posso imaginar que eles tenham o mesmo recurso.

No entanto, você não pode deixar de trabalhar com scripts manualmente. Você terá muitos problemas com dados pré-existentes, como valores padrão para novas colunas ou como lidar com dados de uma coluna renomeada/excluída/movida. Isso é apenas parte da análise ao trabalhar com um esquema de banco de dados ao longo do tempo do qual você não pode fugir. Se você tentar fazer isso com uma solução totalmente automatizada, seus dados ficarão confusos mais cedo ou mais tarde.

A única coisa que eu recomendaria, apenas para tornar sua vida um pouco mais fácil, é certificar-se de separar as alterações de esquema das alterações de código. A diferença é que as alterações de esquema em tabelas e colunas devem ser executadas exatamente uma vez e nunca mais e, portanto, devem ser versionadas como scripts de alteração individuais. No entanto, alterações de código, como procs armazenados, funções e até visualizações, podem (e devem) ser executadas repetidamente e podem ser versionadas como qualquer outro arquivo de código. A melhor abordagem para isso que eu vi foi quando tínhamos todos os procs/funções/visualizações no VSS, e nosso processo de compilação descartava tudo e os recriava durante cada atualização. Essa é a mesma ideia de fazer uma reconstrução do seu código C#/Java/qualquer que seja, porque garante que tudo esteja sempre atualizado.