Per prima cosa devi identificare i blocchi di prestazioni prima di poter stimare il tempo di correzione. Se il blocco è causato dalla necessità di un server più recente con più memoria e potenza di elaborazione che non richiede molto tempo per risolvere. Se hanno una buona attrezzatura, ma il problema è la struttura di base del database, potrebbe essere necessario un anno o più per la correzione. O forse hanno bisogno del partizionamento del database per poter accedere più rapidamente alle cose.
In un prodotto maturo, dovresti trovare in dba le query di lunga durata e correggerle regolarmente. La regolazione delle prestazioni dovrebbe essere continua. Inoltre i tuoi sviluppatori probabilmente hanno una buona idea di dove si trova il debito tecnico e che è un buon punto per iniziare a cercare problemi di prestazioni.
Vorrei stimare il tempo necessario per identificare i blocchi di prestazioni e dire loro che preparerai un preventivo per risolvere i problemi una volta che i problemi saranno noti. Vorrei iniziare anche adesso per esaminare le tue query a lungo termine e correggerle. Ogni miglioramento incrementale aiuterà a mantenere il cliente dalla tua parte. Potresti anche dargli un elenco prioritario delle aree in cui hanno le prestazioni più lente per darti un'idea di cosa iniziare. Potresti anche considerare di proporre un processo di interazione quando trascorri una settimana o due identificando i problemi in una parte specifica dell'applicazione e poi un'altra settimana o due risolvendo questi problemi, quindi passa alla sezione successiva, ecc. In questo modo, puoi iniziare a migliorare prima di identificare tutti gli articoli che causano le scarse prestazioni.
Esistono noti problemi di prestazioni con determinati tipi di strutture SQL (varia a seconda del back-end del database), ma per SQL server, se si utilizzano spesso cose come sottoquery, cursori, funzioni in join e clausole where, UDF scalari, viste che chiamano viste che chiamano visualizzazioni, allora è probabile che il tuo database abbia bisogno di una revisione completa. Se tutte le tue chiavi esterne non sono indicizzate è una vittoria facile, economica (in termini di tempo). Se i tuoi sviluppatori non sanno cosa significa sargable, allora probabilmente hai delle query scritte male e quasi tutte le query dovranno essere esaminate per le cattive pratiche.
Francamente, è bello che il tuo cliente sia disposto a pagare un po 'di soldi per questo, ma hai fatto il design scadente, la tua azienda dovrebbe pagare la maggior parte delle correzioni.
Infine, assicurati di imparare da questo. Se il problema è una cattiva progettazione di database o query poco performanti, istruisci i tuoi sviluppatori a scrivere query performanti e / o assumere uno specialista di dati. Chiunque progetta un sistema Enterprise senza specialisti di dati nella fase di progettazione probabilmente avrà un sistema che fallisce quando il carico diventa alto. Le prestazioni dovrebbero essere considerate nella fase di progettazione del database. Questa NON è ottimizzazione prematura, questo evita problemi noti di prestazioni. È molto più difficile risolvere un sistema Enterprise maturo in produzione che per correggere un cattivo progetto.
Non sto dicendo che il database sia l'unica fonte dei tuoi problemi di prestazioni, solo che è uno dei posti più probabili. Hai bisogno di profilo per vedere cosa sta succedendo. Ricordo una volta in cui stavamo riscontrando un problema di prestazioni e si è scoperto che l'applicazione chiamava lo stesso proc migliaia di volte per ogni pagina quando era necessario chiamarla una sola volta. Ma come specialista di dati, la mia esperienza è stata che ci sono molti database mal progettati e poco performanti là fuori.