Aggiunta di un indice cluster a una tabella SQL: quali pericoli esistono per un sistema di produzione dal vivo?

Question

Sono stato messo a capo di un sistema transazionale di 10 anni in cui la maggior parte della logica aziendale è implementata a livello di database (trigger, stored procedure, ecc.). Server Win2000, MSSQL 2000 Enterprise. Non sono in programma piani immediati per la sostituzione o l'aggiornamento del sistema.

Il processo principale è un programma che esegue le transazioni, in particolare esegue una stored procedure con vari parametri; chiamiamolo sp_ProcessTrans. Il programma esegue la stored procedure ad intervalli asincroni.

Da solo, le cose funzionano bene, ma ci sono 30 istanze di questo programma su workstation in remoto, tutte in esecuzione asincrona sp_ProcessTrans e quindi il recupero dei dati dal server SQL. L'esecuzione è abbastanza regolare, da 0 a 60 volte al minuto, a seconda di quali articoli è responsabile l'istanza del programma.

Le prestazioni del sistema sono diminuite considerevolmente con 10 anni di crescita dei dati: il motivo sono i deadlock, in particolare i deadlock wait, sulla tabella Employee.

ho scoperto:

• In esecuzione sp_ProcessTrans s', si seleziona da una tabella Employee 7 volte
• La select è fatto su un campo che non è la chiave primaria
• Non esiste alcun indice su questo campo. Così una scansione di tabella viene eseguita 7 volte per transazione

Quindi la ragione di situazioni di stallo è chiaro. Ho creato un indice cluster non univoco ordinato sul campo (quasi univoco, NUM(7), molto raramente variazioni). C'è stato un miglioramento immediato nell'ambiente di test. Il problema è che non riesco a simulare i deadlock in un ambiente di test. Avrei bisogno di 30 postazioni di lavoro e avrei dovuto simulare un'attività "realistica" su quelle stazioni, quindi la visualizzazione non è disponibile.

Ho bisogno di sapere se devo pianificare i tempi di inattività. La creazione di un indice non dovrebbe essere un'operazione rischiosa per MSSQL, ma c'è qualche pericolo (corruzione dei dati, tempo di attesa extra, ecc.) Nella creazione di questo indice di campo nel database di produzione mentre le transazioni sono ancora in corso? Posso selezionare un orario in cui le transazioni sono abbastanza silenziose attraverso le 30 stazioni.

Ci sono pericoli nascosti che non vedo? (Non vedo l'ora di ripristinare il DB se qualcosa va storto. Ci vorrebbe molto tempo con 10 anni di dati.)

Answer 1

La corruzione dei dati non dovrebbe essere un problema, ma se si tenta di aggiungere un indice in una tabella di produzione dal vivo è probabile che si verifichino problemi poiché la tabella non risponderà alle query durante la creazione dell'indice. La creazione di un indice applicherà un blocco di tabella esclusivo fino al completamento e il tempo richiesto dipenderà da numerosi fattori (in particolare il numero di righe).

tempi di inattività programmati sono fortemente raccomandati e anche una buona abitudine per entrare. E ovviamente il backup è stato preso, e un piano nel caso tu debba annullare ciò che intendi.