Bagaimana cara Anda mengubah perubahan basis data Oracle?

Saya tertarik untuk mengetahui metode apa yang digunakan orang lain untuk melacak perubahan yang dilakukan pada database termasuk perubahan definisi tabel, objek baru, perubahan paket, dll. Apakah Anda menggunakan file datar dengan sistem kontrol versi eksternal? Pemicu? Perangkat lunak lain?

Di situs tempat saya bekerja, setiap perubahan yang perlu dibuat pada instance produksi harus dituliskan sebagai skrip perubahan yang akan dijalankan dalam SQL * Plus; selain itu, skrip yang diperlukan untuk membuat ulang semua objek skema dari awal harus tetap terbaru. Semua skrip ini diperiksa ke kontrol perubahan, dan dimigrasikan dari sana.

Anda dapat mengaudit perubahan DDL atau menggunakan pemicu DDL untuk mengambil perubahan, atau bahkan menggunakan perangkat lunak berbeda untuk membandingkan dua contoh, tetapi metode ini tidak pandang bulu; seringkali pengembang akan membuat dan membatalkan sejumlah perubahan pada skema (mis., sedikit perubahan tes, membuat tabel dummy untuk menguji konsep, dll.) sebelum mengerjakan apa yang sebenarnya perlu diubah.

Saya sudah banyak berpikir dan membaca tentang topik ini. Ini adalah topik luas dari kontrol konfigurasi dan perubahan strategi manajemen. CMMI memiliki domain dalam topik ini. Bahkan di perusahaan yang memiliki akreditasi CMMI 3-5, mereka terkadang tidak mengontrol versi database mereka.

Pertanyaan ini harus dijawab dengan tetap memperhatikan kendala - kendala berikut .

1. Anda memiliki penjaga dan setiap DDL dieksekusi oleh penjaga ini.
2. Orang Lain memiliki kemampuan untuk menjalankan pernyataan DDL.
3. Anda hanya perlu mencatat perubahan apa yang telah dilakukan tetapi Anda tidak perlu membandingkan perbedaan besar.
4. Desain basis data Anda dilakukan melalui alat eksternal kemudian dipublikasikan ke basis data. Alat eksternal ini dapat berupa skrip DDL dalam kontrol sumber. Tetapi poin kuncinya adalah Anda mengendalikan sumber ini lalu menerbitkannya ke basis data.
5. Anda tidak perlu mengetahui perubahan instan tetapi dari waktu ke waktu: yaitu setiap jam, setiap hari.
6. Anda memiliki struktur server yang ditentukan: Pengembangan, Tes, Produksi. Dan strategi pengujian yang bagus.

jawaban 1

• jika 1, 4,6 benar maka Anda dapat menggunakan kontrol sumber eksternal. Sebagai contoh
  • Embercadero memiliki alat manajemen perubahan basis data ( http://www.embarcadero.com/products/db-change-manager-xe ). Yang memiliki kemampuan untuk merekayasa balik database (Oracle) dan memasukkannya ke dalam kendali sumber mereka. Kemudian sejumlah pengembang, dba dapat mencapai skema ini dan melakukan perubahan padanya.
  • Oracle SQL Designer mirip dengan pendekatan ini.
  • Menempatkan Anda membuat skrip tabel ke kontrol sumber (svn, mercurial dll) dan mempertahankannya juga hal yang sama.
  • http://www.liquibase.org adalah pendekatan otomatis di atas.
  • Saya menulis pembuat kode yang menghasilkan pernyataan DAL (Lapisan Akses Data), DDL (Buat Tabel). Kami menempatkan mereka kontrol sumber dan dipelihara di sana. Saya pikir solusi khusus seperti liquibase dapat bekerja lebih baik.

Pendekatan ini bekerja dengan baik jika ada 6. Anda meletakkan pernyataan DDL, yang juga merupakan kode, dalam kontrol sumber dan memeliharanya. Tidak ada yang akan mengubah Server Uji dan Produksi tanpa pertimbangan.

Kerugiannya adalah jika Anda membuat perubahan apa pun pada server produksi atau pengujian dengan alasan apa pun, perbaikan bug cepat, perubahan kunci primer, dll. Anda harus memutar perubahan itu ke server pengembangan juga. Karena sebenarnya server Pengembangan adalah KEBENARAN GROUND Anda. Tidak sebaliknya.

Ini adalah pendekatan yang sangat berorientasi pada pengembang. Tetapi ketika Anda pertama kali mengembangkan modul baru itu berfungsi dengan baik.

Jawaban 2 - jika 1 dan 6 benar:

Pendekatan serupa untuk jawaban 1 adalah memelihara server pengembangan. Semua orang menggunakannya mengubahnya. Daripada ketika tiba saatnya untuk memperbarui. Anda menggunakan alat perbandingan database. Dapatkan ini sebagai skrip, letakkan di bawah kendali sumber.

- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)

Perbedaan antara Jawaban 1 dan Jawaban 2 adalah, dalam jawaban 1 Anda mengumpulkan pernyataan DDL untuk seluruh basis data dan Anda menyimpannya. Di jawaban 2 Anda perlu menyimpan setiap versi perubahan.

1. Mulai
2. V1
3. V2
4. V3
5. ...

Jika Anda meletakkan kolom ke tabel dan kemudian memutuskan untuk menghapusnya. Skrip Anda akan menampilkan ini di answer2 sementara di answer1 Anda hanya akan melihat versi terakhir. Dan Anda perlu membandingkan V2 dan V1 untuk melihat perbedaan. Secara pribadi saya suka jawaban 1 lebih baik karena saya dapat dengan mudah membandingkan Mulai dan V3, V1 dan V3. Di answer2, saya perlu mencari semua perubahan. Juga dalam jawaban 2 skrip dalam kontrol sumber cenderung menjadi big bang, skrip yang kompleks. Sulit mencari informasi.

Jawaban 3 Jika 3 benar. Perhatikan bahwa dalam situasi ini Anda tidak memiliki kendala 6, yaitu: Anda tidak memiliki Pengembangan, Uji, Server produk. Hanya server produksi. Anda dapat menggunakan pemicu DDL untuk mencatat perubahan apa yang telah dilakukan. Ini sebagian besar digunakan untuk mencegah orang menyalahgunakan hibah DDL mereka. Jika ada masalah, Anda dapat bertanggung jawab. Agar ini berfungsi, setiap orang harus terhubung dengan akun pengguna mereka dan akun Aplikasi tidak boleh memiliki hibah DDL. Karena setiap pengembang mengetahui akun Aplikasi dan dapat menggunakannya.

Jawaban 4 Jika Anda memiliki 3 dan 5. Perhatikan bahwa dalam situasi ini Anda tidak memiliki kendala 6, yaitu: Anda tidak memiliki Pengembangan, Uji, Server produk. Hanya server produksi. Alih-alih memicu untuk menyimpan perubahan. Anda menggunakan alat eksternal untuk menemukan perubahan dan menyimpan skrip DDL dalam kontrol sumber.

Jika alat ini memiliki kemampuan untuk merekam siapa yang telah melakukan perubahan, itu akan berguna. Perhatikan bahwa dalam solusi ini Anda kehilangan DDL tambahan yang dilakukan secara berkala.

Baru saja menemukan tutorial yang menarik tentang penggunaan Liquibase ke versi Oracle.

Pada beberapa basis data kami, kami menggunakan pemicu DDL untuk menangkap perubahan dan menyimpannya ke tabel. Kami kemudian memiliki antarmuka web untuk menarik versi sebelumnya. Ini memiliki kelemahan parah, itulah sebabnya saya mencari alternatif, tetapi mudah dan lebih baik daripada tidak ada kontrol versi.

Kami telah menggunakan Kontrol Versi Skema untuk basis data 11g kami, tetapi telah mengalami beberapa masalah dengan perangkat lunak pada 11.2. Jika bukan karena masalah-masalah yang masih kami tangani, itu akan menjadi produk yang hebat.

Kami dulu bekerja dengan Oracle SQL Designer, yang (saya kira) telah diganti dengan SQL Developer Data Modeler sekarang. http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html

Itu cukup bagus, esp. kemampuan untuk mengatur DOMAINs untuk kolom dan menghemat banyak waktu membuat kolom umum (mtime, ctime dll).

Kami menggunakan seperangkat alat oracle-ddl2svn (yang saya penulis) untuk penyimpanan otomatisasi skema DDL oracle di SVN.

Lihatlah DBmaestro TeamWork yang databasenya menerapkan pendekatan manajemen perubahan .

_{pengungkapan: Saya bekerja untuk dbMaestro}

Saya tidak pernah menggunakannya, tetapi http://blog.gitora.com/ adalah pilihan lain.