Best practice per la gestione del cambiamento con gli indici

Question

negozio

La nostra è prima di iniziare a costruire un gruppo di DBA. Tutti noi (me compreso) sono venuti su dal mondo lo sviluppo di applicazioni / architettura, in modo che il mondo DBA è ancora abbastanza nuovo per noi.

Con la costruzione di un gruppo DBA, stiamo cercando di costruire il cambiamento gestire le procedure ei processi (si spera basate sulle migliori pratiche) per quando abbiamo bisogno di spostare le modifiche.

Ho trovato il seguente post che è utile per la maggior parte di trigger, stored procedure, e / o DDL cambia. Ma non è così necessariamente indici di indirizzo o database vendor.

Abbiamo un mix di entrambe le nostre banche dati proprie e fornitori. Nel nostro caso alcuni dei fornitori (anche se non tutti) stanno lavorando con la nostra società per creare il database (s) e le applicazioni. Siamo in fase di test di performance nostre applicazioni ora prima di "andare a vivere". Così stiamo analizzando gli indici (o la sua mancanza) piuttosto pesantemente.

Come ci si imbatte indici che riteniamo dovrebbe essere fatto, come possiamo meglio affrontare la gestione del cambiamento per quanto riguarda questi, sia per le nostre banche dati, nonché per eventuali fornitori?

Cosa fai nel tuo negozio? Sono preoccupato di meno sugli strumenti quindi circa il processo.

Modifica Finora, sto apprezzando le valutazioni, i commenti e le risposte a questa domanda. Ho notato che alcune delle risposte sono un po ' strumento specifico. Sto cercando altre pratiche "agnostici", se questo può essere avuto.

Tuttavia, se agnostico non è possibile, quindi per i set di utensili, usiamo IBM DB2 LUW (e che in realtà su AIX) per lo più. Abbiamo un po 'di DB2 su Windows e DB2 for i (IBM i5 / OS), ma sono per lo più AIX DB2. Facciamo uso controllo del codice sorgente, specificamente Subversion.

Anche in questo caso, alla ricerca di migliori pratiche generali, ma soprattutto è quello che usiamo che sarebbe fornitore specifico.

Modifica Decisione corrente: intende seguire il nostro ragionamento, così come i nostri cambiamenti. Quindi stiamo per aprire un problema nel nostro issue-tracking software (che nel nostro caso è JIRA). Ora possiamo aggiungere nella documentazione da quale priorità la modifica ha, i dati che esegue il backup ciò che il cambiamento dovrebbe essere, il cambiamento, ed i risultati del cambiamento di un altro ambiente in cui è stato testato il cambiamento.

Abbiamo poi anche intenzione di tenere traccia dei nostri cambiamenti negli script in SVN (Molto simile è stato suggerito di seguito). In questo modo siamo in grado di tenere traccia di quale versione di ciò che esiste dove. Questo può essere registrato nel nostro numero JIRA (e in ogni altri usiamo il software di controllo, vale a dire. collegamenti incollati). Siamo in grado di conoscere con maggiore certezza quale cambiamento è andato a quale ambiente e perché. Noi possiamo poi tracciare anche se l'indice era qualcosa che abbiamo aggiunto al di là dei fornitori realizzazione o in vista della loro attuazione, ecc.)

Answer 1

vi consiglio vivamente di trattare il vostro database di fondamentalmente lo stesso modo in cui si trattano il codice dell'applicazione. È possibile creare script il database fuori per le sue parti componenti e controllare quelli in controllo del codice sorgente e quindi utilizzare le stesse etichette & Versioni là che si utilizza per le tue applicazioni.

Per ottenere gli oggetti in controllo del codice sorgente ci sono una serie di strumenti che è possibile utilizzare. Microsoft dispone di uno strumento che è soprannominato dati Amico. Funziona con Visual Studio. Stanno anche preparando a rilasciare un nuovo strumento chiamato SQL Server Database Tools (SSDT), ancora una volta, si lavora con Visual Studio. La mia azienda, Red Gate Software, fa uno strumento che funziona con SSMS chiamati controllo del codice sorgente SQL.

In termini di processo, ho scritto diversi capitoli per il libro Red gate Guida al team di sviluppo . E 'disponibile per il download gratuito (o se si vuole uccidere un albero è possibile purcahse uno da Amazon). Vado in dettagli molto di più su come lavorare con i database nel team di sviluppo là.

Answer 2

1. mantenere script di database come parte della nostra base di codice dell'applicazione che viene mantenuta sotto controllo di versione. Tuttavia usiamo diversi "processi" per lo sviluppo e il codice di produzione

2. Sviluppo manteniamo i seguenti script:

   • base.sql - crea le tabelle dello schema e dati di esempio
   • stagingchanges.sql - apporta modifiche al base.sql per la stadiazione ambiente, e-mail soprattutto gli indirizzi, i percorsi e le altre attività che potrebbero cambiare
   • prodchanges.sql - apporta modifiche al base.sql per una distribuzione di produzione. Per i nuovi progetti che di solito arriva a provare questi fuori in ambienti di produzione effettivi

3. Manutenzione

   • base.sql - una versione sterilizzata del database di produzione
   • stagingchanges.sql e prodchanges.sql - come sopra
   • changerequest.sql (di solito ha l'id della richiesta di modifica), che si applica eventuali modifiche allo schema per la richiesta di modifica corrente su cui stiamo lavorando
   • changerequest-rollback.sql - inverte le modifiche apportate per la richiesta di modifica e reimposta la parte posteriore del database di produzione
   • archivio (cartella) per gli script di richiesta di modifica precedente

Quindi, in modalità di manutenzione tutto quello che dobbiamo fare è applicare lo script changerequest.sql durante la distribuzione alla produzione

Answer 3

Essere nello spazio versione del database di controllo per 5 anni (in qualità di direttore del product management di DBmaestro ) e dopo aver lavorato come DBA per oltre due decenni, vi posso dire il semplice fatto che non è possibile trattare gli oggetti di database come trattare il vostro Java, C # o altri file.

Ci sono molte ragioni e io citarne alcuni:

• I file vengono memorizzati localmente sul PC dello sviluppatore e il cambio s / he
  marche non influenzano altri sviluppatori. Allo stesso modo, lo sviluppatore non è colpiti da modifiche apportate da suo collega. In base di dati questo è
  (Di solito) non è il caso e gli sviluppatori condividono lo stesso database
  ambiente, in modo che qualsiasi cambiamento che sono stati commessi al database influenza altri.
• modifiche al codice Editoria viene fatto usando il check-in / Invia modifiche / ecc (a seconda di quale strumento di controllo del codice sorgente si usa). A quel punto, il codice dalla directory locale dello sviluppatore è inserito
  nel repository controllo di origine. Sviluppatore che vuole ottenere il
  ultimo codice necessità di richiedere dall'utensile controllo del codice sorgente. in
  banca dati il ??cambiamento esiste già e impatti altri dati, anche se non è stato il check-in nel repository.
• Durante il file del check-in, le esegue strumento di controllo di origine di un conflitto controllare per vedere se lo stesso file è stato modificato e il check-in da un altro sviluppatore durante il tempo che ha modificato la copia locale. Anche in questo caso ci è alcun controllo per questo nel database. Se si modifica una procedura da il PC locale e allo stesso tempo modifico la stessa procedura con Codice del modulo di mio PC locale, allora ridefiniamo le rispettive modifiche.
• Il processo di generazione di codice è fatto da ottenere l'etichetta / ultime versione del codice in una directory vuota e poi eseguire una generazione - compilare. L'uscita sono binari in cui copiare e sostituire il esistente. Non ci interessa quello che era prima. Nel database non possiamo ricreare il database come abbiamo bisogno di mantenere i dati! Anche il script esegue SQL distribuzione che sono stati generati nella build processo.
• Quando si esegue gli script SQL (con il DDL, DCL, DML (statica contenuto) comanda) si assume l'attuale struttura del ambiente corrisponde alla struttura quando si creano gli script. Altrimenti, quindi i vostri script possono fallire come si sta tentando di aggiungere nuova colonna che esiste già.
• Trattamento script SQL come codice e generare manualmente causerebbe errori di sintassi, di database dipendenze errori, gli script che non sono riutilizzabile che complicano il compito di sviluppare, mantenere, test quegli script. Inoltre, questi script possono essere eseguiti su un ambiente, che è diversa da quella che anche se sarebbe correre on.
• A volte lo script nel repository di controllo della versione non corrisponde la struttura dell'oggetto che è stato testato ed errori poi sarà accadere in produzione!

Ci sono molti di più, ma penso che hai l'immagine.

Quello che ho trovato che funziona è il seguente:

1. Utilizzare un sistema di controllo versione forzata che impone check-out / check-in operazioni sugli oggetti di database. Questo sarà assicurarsi che il repository di controllo della versione corrisponde il codice che è stato il check-in come si legge i metadati dell'oggetto nel check-in funzionamento e non come una fase separata fatto manualmente
2. Utilizzare un'analisi di impatto che utilizzano linee di base come parte del confronto per identificare i conflitti e di identificare se un cambiamento (quando confrontando struttura dell'oggetto tra il controllo di origine repository e il database) è un vero e proprio cambiamento che da origine di sviluppo o un cambiamento che era all'origine da un percorso diverso e allora dovrebbe essere ignorata, come ramo diverso o di emergenza fix.

Un articolo che ho scritto su questo è stato pubblicato qui , siete invitati a leggerlo.