How to bind Oracle database (packages, triggers, indexes, table structure, etc.) with a version control system (GIT, SVN)?


Warning: count(): Parameter must be an array or an object that implements Countable in /home/styllloz/public_html/qa-theme/donut-theme/qa-donut-layer.php on line 274
0 like 0 dislike
14 views
All kind time of day.
Long overdue question and now it's time:
How to bind Oracle database (packages, triggers, indexes, table structure, etc.) with a version control system (GIT, SVN)?

I know there are several software solutions (Liquibase and RedGate). So comes the decision in a forehead - all the objects written in sql files and have them stored in version control.

I would like to know how You are going to work with the database team? How is what and who changed.

The main problem is to find out who changed a specific object (was sad precedents). In addition of course to move data to develop production.
by | 14 views

3 Answers

0 like 0 dislike
If we are talking about a production database, the most reliable and time-tested algorithm, perhaps-as follows:
1. The changes to the database are issued in the form of the so-called migrations. Engines to implement SQL migrations-complete. In the simplest case, migration is simply a set of DDL/DML issued in the form of, for example, SQL script.
2. Migration is stored in a VCS. Anyone seen what changes are made.
3. In production migrations are applied automatically under control of the DBA or the DBA. The DBA role can perform any responsible person if you do not have a dedicated person.
4. (bonus) the database Schema in production after each application migration is unloaded in the same VCS as a separate script contains only DDL and reference data (example: data for filling the table of car brands, the data for filling the table of countries, etc.). It is convenient for rapid deployment of development environments in sync with the current production database schema.
Something like that.
by
0 like 0 dislike
To say @mrstrictly I want to add:

Have the rights to change the DB structure on production is a very limited number of workers (or even one). They should have a very simple algorithm works: take the latest version of the migration script from the branch "xxx" and run it after the go-ahead from the project Manager.
Game push changes to the branch "xxx" from waitoki which is made after checking on the development database. That is, they seem to make the release of the migration script.

Thus, if the only source DDL is a version control system, this will push the developers to make changes to the structure of the database through it. And you will be able to keep track of who changed what and when.

I see it, the problem is more organizational work.
by
0 like 0 dislike
If "the Main problem is to find out who changed a specific object (was sad precedents). "you can put a trigger on the schema and log DDL changes

CREATE OR REPLACE TRIGGER ddl_log_and_lock_trigger
AFTER
CREATE OR ALTER OR DROP
ON SCHEMA
BEGIN
.....
END;
by

Related questions

0 like 0 dislike
7 answers
asked Mar 26, 2019 by budyakov
0 like 0 dislike
1 answer
0 like 0 dislike
1 answer
110,608 questions
257,186 answers
0 comments
27,917 users