Jak oceniasz wersję zmian w bazie danych Oracle?

Chcę wiedzieć, jakich metod używają inni ludzie, aby śledzić zmiany wprowadzone w bazie danych, w tym zmiany definicji tabeli, nowe obiekty, zmiany pakietów itp. Czy używasz płaskich plików z zewnętrznym systemem kontroli wersji? Wyzwalacze? Inne oprogramowanie?

W witrynach, w których pracowałem, wszelkie zmiany, które należy wprowadzić w instancjach produkcyjnych, muszą być skryptowane jako skrypty zmian, które będą działać w SQL * Plus; ponadto skrypty potrzebne do odtworzenia od podstaw wszystkich obiektów schematu muszą być aktualizowane. Wszystkie te skrypty są sprawdzane pod kątem kontroli zmian i stamtąd migrowane.

Możesz kontrolować zmiany DDL lub użyć wyzwalaczy DDL, aby wykryć zmiany, a nawet użyć oprogramowania różnicowego do porównania dwóch instancji, ale metody te są niedyskryminujące; często programista wprowadza i usuwa wiele zmian w schemacie (np. małe zmiany testowe, tworzenie fałszywych tabel do testowania koncepcji itp.) przed ustaleniem, co dokładnie należy zmienić.

Wiele myślałem i czytałem na ten temat. Jest to szeroki temat kontroli konfiguracji i strategii zarządzania zmianami. CMMI ma domenę w tym temacie. Nawet w firmach, które mają akredytację CMMI 3-5, czasami nie kontrolują wersji swoich baz danych.

Na to pytanie należy odpowiedzieć, mając na uwadze następujące ograniczenia .

1. Masz opiekuna i każdy DDL jest wykonywany przez tego opiekuna.
2. Inne osoby mają możliwość wykonywania instrukcji DDL.
3. Musisz tylko zarejestrować, jakie zmiany zostały wprowadzone, ale nie musisz porównywać ogromnych różnic.
4. Projektowanie bazy danych odbywa się za pomocą zewnętrznego narzędzia, a następnie jest publikowane w bazie danych. Tym zewnętrznym narzędziem mogą być nawet skrypty DDL pod kontrolą źródła. Ale kluczową kwestią jest kontrola źródła, a następnie publikowanie w bazie danych.
5. Nie musisz znać natychmiastowych zmian, ale od czasu do czasu: tj. Co godzinę, codziennie.
6. Masz zdefiniowaną strukturę serwera: Rozwój, Test, Produkcja. I dobra strategia testowania.

odpowiedź 1

• jeśli 1, 4,6 jest prawdą, możesz użyć zewnętrznego źródła kontroli. Na przykład
  • Embercadero ma narzędzie do zarządzania zmianą bazy danych ( http://www.embarcadero.com/products/db-change-manager-xe ). Który ma zdolność do inżynierii wstecznej bazy danych (Oracle) i oddania jej pod kontrolę źródła. Następnie dowolna liczba programistów, dba może osiągnąć ten schemat i wprowadzić w nim zmiany.
  • Oracle SQL Designer jest podobny do tego podejścia.
  • Oddawanie skryptów tabel do kontroli źródła (svn, mercurial itp.) I utrzymywanie ich również w tym samym porządku.
  • http://www.liquibase.org jest zautomatyzowanym podejściem powyżej.
  • Napisałem generator kodu, który wygenerował instrukcje DAL (Data Access Layer), DDL (Create Table). Przekazujemy im kontrolę źródła i tam utrzymujemy. Myślę, że dedykowane rozwiązanie, takie jak likibaza, może działać lepiej.

To podejście działa dobrze, jeśli masz 6. Umieszczasz instrukcje DDL, które są także kodem, w kontroli źródła i utrzymujesz je. Nikt nie zmieni serwerów testowych i produkcyjnych bez należytego rozważenia.

Wady polegają na wprowadzeniu jakichkolwiek zmian w serwerach produkcyjnych lub testowych z dowolnego powodu, szybkiej korekcie błędów, zmianie klucza podstawowego itp. Trzeba te zmiany wprowadzić także na serwerze programistycznym. Ponieważ tak naprawdę serwer programistyczny jest waszą PRAWDĄ. Nie na odwrót.

Jest to podejście bardzo zorientowane na programistów. Ale kiedy tworzysz nowy moduł, działa całkiem dobrze.

Odpowiedź 2 - jeśli 1 i 6 są prawdziwe:

Podobne podejście do odpowiedzi 1 to utrzymanie serwera programistycznego. Każdy używa go zmienia to. Niż czas na aktualizację. Korzystasz z narzędzia do porównywania baz danych. Pobierz je jako skrypty, poddaj je kontroli źródła.

- 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)

Różnica między odpowiedzią 1 a odpowiedzią 2 polega na tym, że w odpowiedzi 1 gromadzisz instrukcje DDL dla całej bazy danych i je przechowujesz. W odpowiedzi 2 musisz zapisać każdą wersję zmiany.

1. Początek
2. V1
3. V2
4. V3
5. ...

Jeśli umieścisz kolumnę w tabeli, a później zdecydujesz się ją usunąć. Skrypty pokażą to w odpowiedzi 2, natomiast w odpowiedzi 1 zobaczysz tylko ostatnią wersję. I musisz porównać V2 i V1, aby zobaczyć różnice. Osobiście bardziej lubię odpowiedź 1, ponieważ mogę łatwo porównać Start i V3, V1 i V3. W odpowiedzi 2 muszę szukać wszystkich zmian. Również w odpowiedzi 2 skrypt w kontroli źródła jest z reguły wielkim, złożonym skryptem. Trudno znaleźć informacje.

Odpowiedź 3 Jeśli 3 jest prawdą. Zauważ, że w tej sytuacji nie masz ograniczenia 6, to znaczy: nie masz serwerów programistycznych, testowych i produktowych. Tylko serwer produkcyjny. Za pomocą wyzwalaczy DDL można rejestrować dokonane zmiany. Jest to najczęściej stosowane w celu zniechęcenia ludzi do nadużywania dotacji DDL. Jeśli wystąpi jakikolwiek problem, możesz znaleźć odpowiedzialnego. Aby to zadziałało, każda osoba powinna połączyć się ze swoim kontem użytkownika, a konto aplikacji nie powinno mieć żadnych dotacji DDL. Ponieważ każdy programista zna konto aplikacji i może z niego korzystać.

Odpowiedź 4 Jeśli masz 3 i 5. Zauważ, że w tej sytuacji nie masz ograniczenia 6, to znaczy: nie masz serwerów programistycznych, testowych i produktowych. Tylko serwer produkcyjny. Zamiast wyzwalacza do zapisywania zmian. Korzystasz z zewnętrznego narzędzia znajdowania zmian i przechowujesz skrypty DDL w kontroli źródła.

Jeśli narzędzie to ma możliwość rejestrowania, kto dokonał zmian, przydałoby się. Zauważ, że w tym rozwiązaniu tracisz dodatkowe DDL, które są wykonywane w odstępach czasu.

Właśnie znalazłem interesujący samouczek na temat używania Liquibase do wersji Oracle.

W niektórych naszych bazach danych używamy wyzwalaczy DDL do przechwytywania zmian i zapisywania ich w tabeli. Następnie mamy interfejs sieciowy do pobrania poprzednich wersji. Ma poważne wady, dlatego szukam alternatyw, ale jest to łatwe i lepsze niż brak kontroli wersji.

Użyliśmy kontroli wersji schematu do naszych baz danych 11g, ale mieliśmy problemy z oprogramowaniem w wersji 11.2. Gdyby nie te problemy, nad którymi wciąż pracujemy, byłby to świetny produkt.

Pracowaliśmy z Oracle SQL Designer, który (jak sądzę) został teraz zastąpiony przez SQL Developer Data Modeler. http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html

To było całkiem miłe, szczególnie. możliwość ustawienia DOMAIN dla kolumn i zaoszczędzenia czasu na tworzeniu wspólnych kolumn (mtime, ctime itp.).

Używamy zestawu narzędzi oracle-ddl2svn (którego jestem autorem) do automatyzacji przechowywania schematu DDL Oracle w SVN.

Spójrz na DBmaestro TeamWork, która w swojej bazie danych wymusiła podejście do zarządzania zmianami .

_{ujawnienie: Pracuję dla dbMaestro}

Nigdy go nie używałem, ale http://blog.gitora.com/ to kolejna opcja.