Database source control with Oracle

Question

I have been looking during hours for a way to check in a database into source control. My first idea was a program for calculating database diffs and ask all the developers to imlement their changes as new diff scripts. Now, I find that if I can dump a database into a file I cound check it in and use it as just antother type of file.

The main conditions are:

• Works for Oracle 9R2
• Human readable so we can use diff to see the diferences. (.dmp files doesn't seem readable)
• All tables in a batch. We have more than 200 tables.
• It stores BOTH STRUCTURE AND DATA
• It supports CLOB and RAW Types.
• It stores Procedures, Packages and its bodies, functions, tables, views, indexes, contraints, Secuences and synonims.
• It can be turned into an executable script to rebuild the database into a clean machine.
• Not limitated to really small databases (Supports least 200.000 rows)

It is not easy. I have downloaded a lot of demos that does fail in one way or another.

EDIT: I wouldn't mind alternatives aproaches provided that they allows us to check a working system against our release DATABASE STRUCTURE AND OBJECTS + DATA in a batch mode.

By the way. Our project has been developed for years. Some aproaches can be easily implemented when you make a fresh start but seem hard at this point.

EDIT: To understand better the problem let's say that some users can sometimes do changes to the config data in the production eviroment. Or developers might create a new field or alter a view without notice in the realease branch. I need to be aware of this changes or it will be complicated to merge the changes into production.

Answer 1

So many people try to do this sort of thing (diff schemas). My opinion is

• Source code goes into a version control tool (Subversion, CSV, GIT, Perforce ...). Treat it as if it was Java or C code, its really no different. You should have an install process that checks it out and applies it to the database.
• DDL IS SOURCE CODE. It goes into the version control tool too.
• Data is a grey area - lookup tables maybe should be in a version control tool. Application generated data certainly should not.

The way I do things these days is to create migration scripts similar to Ruby on Rails migrations. Put your DDL into scripts and run them to move the database between versions. Group changes for a release into a single file or set of files. Then you have a script that moves your application from version x to version y.

One thing I never ever do anymore (and I used to do it until I learned better) is use any GUI tools to create database objects in my development environment. Write the DDL scripts from day 1 - you will need them anyway to promote the code to test, production etc. I have seen so many people who use the GUIs to create all the objects and come release time there is a scrabble to attempt to produce scripts to create/migrate the schema correctly that are often not tested and fail!

Everyone will have their own preference to how to do this, but I have seen a lot of it done badly over the years which formed my opinions above.

Answer 2

Oracle SQL Developer has a "Database Export" function. It can produce a single file which contains all DDL and data.