it-swarm.it

Come si modificano le modifiche al database Oracle?

Sono interessato a sapere quali metodi vengono utilizzati da altre persone per tenere traccia delle modifiche apportate al database, comprese le modifiche alla definizione della tabella, i nuovi oggetti, le modifiche ai pacchetti, ecc. Usi file flat con un sistema di controllo versione esterno? Trigger? Altro software?

32
Leigh Riffel

Nei siti in cui ho lavorato, tutte le modifiche che devono essere apportate alle istanze di produzione devono essere scritte come script di modifica che verranno eseguiti in SQL * Plus; inoltre, gli script necessari per ricreare da zero tutti gli oggetti dello schema devono essere aggiornati. Tutti questi script vengono controllati nel controllo delle modifiche e vengono migrati da lì.

È possibile controllare le modifiche DDL o utilizzare i trigger DDL per rilevare le modifiche o persino utilizzare il software diff per confrontare due istanze, ma questi metodi sono indiscriminati; spesso uno sviluppatore apporta e annulla una serie di modifiche a uno schema (ad es. piccole modifiche ai test, creazione di tabelle fittizie per testare concetti, ecc.) prima di capire esattamente cosa deve essere modificato.

22
Jeffrey Kemp

Ho pensato e letto molto su questo argomento. Questo è un argomento ampio di controllo della configurazione e strategia di gestione delle modifiche. CMMI ha un dominio in questo argomento. Anche nelle aziende che hanno un accreditamento di CMMI 3-5, a volte non controllano la versione dei loro database.

È necessario rispondere a questa domanda tenendo presente i seguenti vincoli .

  1. Hai un custode e ogni DDL viene eseguito da questo custode.
  2. Altre persone hanno la capacità di eseguire istruzioni DDL.
  3. È necessario solo registrare le modifiche apportate, ma non è necessario confrontare grandi differenze.
  4. La progettazione del database viene eseguita tramite uno strumento esterno, quindi viene pubblicata nel database. Questo strumento esterno può essere anche script DDL nel controllo del codice sorgente. Ma il punto chiave è il controllo del codice sorgente, quindi la pubblicazione nel database.
  5. Non è necessario conoscere i cambiamenti istantanei ma di volta in volta: ovvero ogni ora, ogni giorno.
  6. Hai una struttura di server definita: sviluppo, test, produzione. E una buona strategia di test.

Risposta 1

  • se 1, 4,6 è vero, è possibile utilizzare un controllo sorgente esterno. Per esempio
    • Embercadero ha uno strumento di gestione delle modifiche al database ( http://www.embarcadero.com/products/db-change-manager-xe ). Che ha la capacità di decodificare un database (Oracle) e metterlo nel loro controllo del codice sorgente. Quindi qualsiasi numero di sviluppatori, dba può raggiungere questo schema e apportare modifiche ad esso.
    • Oracle SQL Designer è simile a questo approccio.
    • Metterti a creare script di tabella per il controllo del codice sorgente (svn, Mercurial ecc.) E mantenerli anche nella stessa cosa.
    • http://www.liquibase.org è un approccio automatizzato di cui sopra.
    • Ho scritto un generatore di codice che ha generato istruzioni DAL (Data Access Layer), DDL (Create Table). Abbiamo messo loro il controllo del codice sorgente e mantenuto lì. Penso che una soluzione dedicata come la liquibase possa funzionare meglio.

Questo approccio funziona bene se hai 6. Metti le istruzioni DDL, che è anche un codice, nel controllo del codice sorgente e lo mantieni. Nessuno cambierà i server di test e produzione senza la dovuta considerazione.

Gli svantaggi sono se si apportano modifiche alla produzione o ai server di prova per qualsiasi motivo, una correzione rapida dei bug, una modifica della chiave primaria ecc. È necessario eseguire il rollback di tali modifiche anche al server di sviluppo. Dal momento che in realtà il server di sviluppo è la tua VERITÀ TERRA. Non diversamente.

Questo è un approccio molto orientato agli sviluppatori. Ma quando si sviluppa per la prima volta un nuovo modulo funziona abbastanza bene.

Risposta 2 - se 1 e 6 sono veri:

Un approccio simile alla risposta 1 è mantenere un server di sviluppo. Tutti lo usano lo cambiano. Di quando arriva il momento di aggiornare. Si utilizza uno strumento di confronto dei database. Prendi questi come script, mettilo sotto il controllo del codice sorgente.

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

La differenza tra la risposta 1 e la risposta 2 è che nella risposta 1 raccogli le istruzioni DDL per l'intero database e le memorizzi. Nella risposta 2 è necessario memorizzare ogni versione di modifica.

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

Se si inserisce una colonna in una tabella e successivamente si decide di rimuoverla. Gli script lo mostreranno in answer2 mentre in answer1 vedrai solo l'ultima versione. E devi confrontare V2 e V1 per vedere le differenze. Personalmente mi piace rispondere meglio 1 poiché posso facilmente confrontare Start e V3, V1 e V3. In answer2, devo cercare tutte le modifiche. Anche nella risposta 2 la sceneggiatura nel controllo del codice sorgente tende ad essere una sceneggiatura complessa e big bang. Informazioni difficili da trovare.

Rispondi 3 Se 3 è vero. Si noti che in questa situazione non si ha il vincolo 6, ovvero: non si dispone di server di sviluppo, test e prodotto. Solo server di produzione. È possibile utilizzare i trigger DDL per registrare le modifiche apportate. Questo è principalmente usato per scoraggiare le persone dall'abusare delle loro sovvenzioni DDL. In caso di problemi, è possibile trovarne la responsabilità. Affinché ciò funzioni, ogni persona dovrebbe connettersi con il proprio account utente e l'account Applicazione non dovrebbe avere alcuna sovvenzione DDL. Poiché ogni sviluppatore conosce l'account dell'applicazione e può utilizzarlo.

Risposta 4 Se hai 3 e 5. Tieni presente che in questa situazione non hai il vincolo 6, ovvero: non hai Sviluppo, Test, Server del prodotto. Solo server di produzione. Invece di innescare per memorizzare le modifiche. Si utilizza uno strumento esterno per trovare le modifiche e archiviare gli script DDL nel controllo del codice sorgente.

Se questo strumento ha la capacità di registrare chi ha apportato le modifiche, sarebbe utile. Si noti che in questa soluzione si perde ulteriore DDL che viene eseguito a intervalli.

10
Atilla Ozgur

Ho appena trovato un tutorial interessante sull'uso di Liquibase alla versione Oracle.

6
Leigh Riffel

Su alcuni dei nostri database utilizziamo i trigger DDL per rilevare le modifiche e salvarle in una tabella. Abbiamo quindi un'interfaccia web per visualizzare queste versioni precedenti. Ha gravi inconvenienti, motivo per cui sto cercando alternative, ma è facile ed è meglio di nessun controllo di versione.

4
Leigh Riffel

Abbiamo usato Schema Version Control per i nostri database 11g, ma abbiamo riscontrato alcuni problemi con il software su 11.2. Se non fosse per quei problemi che stiamo ancora affrontando, sarebbe un ottimo prodotto.

4
Leigh Riffel

Lavoravamo con Oracle SQL Designer, che (suppongo) ora è stato sostituito con SQL Developer Data Modeler. http://www.Oracle.com/technetwork/developer-tools/datamodeler/overview/index.html

È stato abbastanza bello, esp. la possibilità di impostare DOMAIN per colonne e risparmiare molto tempo creando colonne comuni (mtime, ctime ecc.).

2
Sebastian Roth

Utilizziamo Oracle-ddl2svn set di strumenti (di cui sono l'autore) per l'archiviazione automatizzata dello schema DDL Oracle in SVN.

2
popalka

Dai un'occhiata a DBmaestro TeamWork con il suo approccio gestione forzata delle modifiche del database .


divulgazione: lavoro per dbMaestro

0
Uri

Non l'ho mai usato, ma http://blog.gitora.com/ è un'altra opzione.

0
Leigh Riffel