it-swarm.dev

Jak oceniasz wersję zmian w bazie danych Oracle?

Chcę wiedzieć, jakich metod używają inni ludzie, aby śledzić zmiany 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?

32
Leigh Riffel

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żywać wyzwalaczy DDL, aby wykrywać zmiany, a nawet używać oprogramowania różnicowego do porównywania dwóch wystąpień, ale metody te są niedyskryminujące; często programista wprowadza i cofa 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ć.

22
Jeffrey Kemp

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 posiadają 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 to, że kontrolujesz to źródło, a następnie publikujesz 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ż tak samo.
    • http://www.liquibase.org to automatyczne podejście do powyższego.
    • Napisałem generator kodu, który wygenerował instrukcje DAL (Data Access Layer), DDL (Create Table). Dajemy im kontrolę źródła i tam utrzymujemy. Myślę, że dedykowane rozwiązanie, takie jak Liquibase, 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 twoją PRAWDZIWĄ 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 jakiś 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 programowania, testowania, Serwery produktów. 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.

10
Atilla Ozgur

Właśnie znalazłem interesujący samouczek korzystania z Liquibase do wersji Oracle.

6
Leigh Riffel

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.

4
Leigh Riffel

Użyliśmy Kontrola wersji schemat dla 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.

4
Leigh Riffel

Pracowaliśmy z Oracle SQL Designer, który (jak sądzę) został teraz zastąpiony programem 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.).

2
Sebastian Roth

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

2
popalka

Spójrz na DBmaestro TeamWork, którego jego podejście zarządzanie zmianami wymuszone przez bazę danych .


ujawnienie: Pracuję dla dbMaestro

0
Uri

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

0
Leigh Riffel