Database interno scadente: sostituirlo o mandare in crash l'hardware?

Quindi - abbiamo un database aziendale interno, il solito tipo di cose: gestisce i clienti, le telefonate, le offerte di vendita e gli accordi / schemi dei clienti.

È un front-end di Access 2000 e un back-end standard di SQL Server 2000. Server singolo, doppio Xeon 3.2GHz, 2 GB di RAM, Windows Server 2003, ottiene circa il 40% del carico della CPU tutto il giorno, distribuito sui 4 core visibili al sistema operativo (HT).

Il database di back-end è mal progettato e cresciuto organicamente in oltre 10 anni, gestito da persone poco qualificate. È mal normalizzato e alcuni degli ovvi problemi includono tabelle con decine di migliaia di righe senza chiave primaria o indice, che sono anche usate pesantemente nei join multi-tabella per alcune delle parti del sistema più utilizzate (ad es. applicazione per la gestione delle chiamate che si trova sul secondo monitor di tutti per 8 ore al giorno ed esegue una query inefficiente ogni pochi secondi).

Il front-end non è molto migliore, è il tipico pasticcio di centinaia di moduli, query salvate nidificate, SQL incorporato scarsamente scritto nel codice VBA, dozzine di "stranezze" ecc. E ogni volta che viene apportata una modifica, qualcosa di non correlato sembra rompersi. Abbiamo optato per un MDB che funzioni "abbastanza bene" e ora abbiamo una politica di non cambiamento in quanto non abbiamo pesi massimi di accesso internamente (e non abbiamo nemmeno intenzione di assumerne uno).

La società ora sta lentamente crescendo, aumentando il numero di clienti, chiamate ecc., Nonché un modesto aumento del numero di utenti simultanei e le prestazioni sono peggiorate notevolmente di recente (in attesa di spostarsi tra i moduli, in attesa di compilazione di elenchi, ecc. )

Perfmon dice:

• Trasferimenti del disco al secondo: tra 0 e 30, in media 4.
• Lunghezza corrente della coda del disco: circa 1

Il profiler di SQL Server vede centinaia di migliaia di query ogni minuto. L'utilizzo della CPU sui client è praticamente pari a zero, a indicare che è in attesa di eseguire query sul lato server. Ho trasferito questo carico di lavoro tramite DB Engine Tuning Advisor, ho applicato i suoi suggerimenti a un backup di prova, ma questo non ha fatto molta differenza.

A proposito, abbiamo un mix di 100 MB e Ethernet gigabit, tutto su una sottorete, 40 utenti ish su due piani.

Alla domanda

A mio avviso, abbiamo due opzioni per risolvere / migliorare questa situazione.

• Possiamo eliminarlo e sostituirlo con un sistema CRM completamente nuovo, su misura o in parte su misura
• Siamo in grado di prolungare la durata di questo sistema mandandoci l'hardware.

Siamo in grado di costruire un sistema Intel i7 con numeri di prestazioni folli per un ordine di grandezza in meno costi rispetto alla sostituzione del software.

Quando un nuovo sistema viene infine sviluppato, può essere ospitato su questo box, quindi non c'è spreco di hardware. Un nuovo sistema CRM continua a essere rimandato, spento e spento - non vedo che ciò accada per almeno un anno.

Qualsiasi pensiero su questa situazione, specialmente se sei stato qui da solo, sarebbe molto apprezzato.

Grazie

Non sarò d'accordo con tutti qui. Chuck un po 'di hardware. È economico, veloce, facile e ti farà guadagnare il tempo necessario per implementare una soluzione CRM adeguata. Il motivo per cui sto sostenendo qualcosa che è un anatema per quasi tutti su questo board, ma anche su stackoverflow, è che sono stato un project manager / manager e sono stato dalla parte "Business" per un po '(business è tra virgolette a causa del mio odio per la parola). Sulla base della descrizione del software, ci vorrà circa un anno per ricostruire qualcos'altro. La scoperta / documentazione delle regole / stranezze aziendali richiederà probabilmente 2 mesi. Sarà anche incredibilmente costoso da sviluppare. Soprattutto se confrontato con il costo di un server ingannato.

In realtà sto per ospitare un set di app Web per un'azienda proprio per questo motivo. Il reparto IT interno non lo sposterà su un hardware migliore perché vogliono riqualificarli su una nuova piattaforma. Tale costo è circa il triplo di quanto sarebbe necessario per spostarlo su un nuovo hardware. Non troppo menzione del fatto che la società potrebbe non rinnovare il contratto tra un anno.

Potrebbe non essere necessario farlo neanche. Il mio suggerimento è semplicemente aggiungere alcuni indici / chiavi alla tabella.

tabelle con decine di migliaia di righe senza chiave primaria o indice, anch'esse utilizzate pesantemente nei join multi-tabella

Prima di spendere molto tempo o denaro, prenditi un paio d'ore e aggiungi indici (o chiavi primarie se puoi) a qualsiasi tabella coinvolta in quei join ... in particolare per le colonne utilizzate in una clausola where. Potresti facilmente migliorare le prestazioni di un fattore 10 in poche ore.

La mancanza di I / O su disco implica che le query siano alimentate principalmente dalla RAM. Se 'improvvisamente' i tuoi hot table non si adattano più alla RAM e il server inizia a lavorare sui dischi, potresti essere in una brutta corsa. 2GB o RAM non sono molto al giorno d'oggi, ma nell'era di SQL2000 sarebbe stata considerevole. Immagino che la quantità di dati che l'applicazione normalmente manipola sia inferiore alla RAM che hai. Potresti voler esaminare la quantità di spazio "usato" nei file di dati. Questo ti darà un'idea di quanta RAM potrebbe consumare il database, nel peggiore dei casi. SQL Server non conserva i dati di cui non ha bisogno nella RAM, ma può essere difficile sapere quali tabelle vengono utilizzate e quando.

L'hyperthreading non è sempre utile con SQL Server. Potresti ottenere prestazioni migliori spegnendolo. È difficile da testare perché spegnerlo e riaccenderlo richiede un riavvio, e questo è un grosso problema su un server di produzione.

"Centinaia di migliaia di query al minuto" si traduce in migliaia di query al secondo. Sembra piuttosto affollato, ma gran parte di quel traffico potrebbe essere semplicemente recuperato dal cursore da Access. L'accesso è particolarmente dannoso per il recupero efficiente dei set di risultati da SQL. È possibile ottenere prestazioni migliori disattivando l'impostazione di parallelizzazione di SQL Server.

Vuoi anche cercare il blocco. Lanciare hardware a un problema di blocco non sempre produce il sperato miglioramento drammatico. Se non ci sono molti blocchi e le richieste sono soddisfatte dalla RAM, piuttosto che dal disco, in pratica fai affidamento sul grugnito del processore e sulla sua capacità di estrarre i dati attraverso i canali di memoria. In tal caso, un hardware più veloce dovrebbe fornire un buon miglioramento. Se hai fretta (per superare questo problema) e stai crescendo lentamente, potrebbe essere abbastanza buono.

Come soluzione, l'aggiunta di hardware non si ridimensiona così come i miglioramenti del database. Se si verifica un aumento della crescita, è possibile che il nuovo hardware stia faticando. Un altro pensiero è che le applicazioni di successo attirano gli utenti. Se l'applicazione diventa più reattiva, gli utenti potrebbero avere maggiori probabilità di eseguire più report e simili rispetto a quanto farebbero se avessero bisogno di andare a prendere un caffè mentre aspettavano che il report finisse.

Se lo schema del database è davvero negativo, potresti essere in grado di ottenere alcune vittorie delle prestazioni semplicemente osservando l'indicizzazione nelle tabelle. Concentrati sui tavoli che conosci vengono interrogati spesso. È possibile utilizzare Profiler per guardare le query in esecuzione sul server, basta dirgli di cercare query che leggono molti dati (come 100.000 pagine) e quindi procedere verso query che non leggono molto. Hai detto che alcuni dei tavoli non hanno chiavi. Esistono chiavi naturali nei dati, semplicemente non imposte da vincoli o indici univoci?

Le tabelle hanno indici cluster? La mancanza di indicizzazione in cluster può causare effetti secondari di ogni genere.

Ci sono molti indici non cluster, con molte colonne? Questo è spesso un tentativo di costruire molti indici di copertura, piuttosto che implementare una strategia di indicizzazione più efficace. SQL Server è in grado di creare in modo efficace indici di copertura al volo durante una query, se ha senso farlo e sono supportati indici non cluster e cluster.

Infine, vale la pena chiedere: la manutenzione (reindicizzazione e / o aggiornamento delle statistiche) viene eseguita sui tavoli?

questa è una domanda commerciale, non una domanda tecnica.

Come imprenditore: quanto è strategico il sistema per l'azienda? tanto meno strategico, tanto meno mi preoccupo e lo aggiusto e tutti i soldi spesi, sono i soldi che potrei usare altrove per far crescere la mia attività.

La gente del computer mi spaventa mentre entrano in una grande stanza e discutono sul design e mi costano una fortuna. Mantieni il sistema in funzione! indipendentemente dal fatto che ciò significhi il tuning delle prestazioni (senza riprogettazione) o il lancio di altro hardware, è solo una priorità se smette di funzionare.

Come consulente IT: il tuo sistema è legacy e ha costi operativi nascosti. Siamo in grado di progettare un sistema adatto a te, che scalerà e fornirà una piattaforma per la crescita futura e il vantaggio strategico. Firma qui e tutti i tuoi sogni diventeranno realtà.

Come dipendente IT: posso essere il supereroe qui e salvare la società evitando un disastro imminente ottimizzando al massimo questa cosa! il mio manager mi colmerà di doni e di elogi poiché avrò salvato migliaia di persone.

Dico di fare entrambe le cose.

In questo momento hai il 40% circa di CPU che hai detto? Ti stai ancora lamentando (molto) per l'utente? Altrimenti hai ancora spazio per respirare. Più memoria potrebbe essere sufficiente per farlo per un po '.

Domanda per la strada da percorrere, hai sviluppatori di software interni? Se la risposta è NO, non tentare nemmeno di rifarla. Finirai esattamente dove sei ora.

Supponendo che tu abbia sviluppatori interni, i tuoi sviluppatori interni hanno la capacità di realizzare correttamente un progetto? Sto parlando di una linea temporale completamente corretta (relistica), sostanzialmente come se fosse un progetto di un cliente. Altrimenti, non preoccuparti o finirà per tornare dove sei ora.

Fino a quando le aziende si renderanno conto di essere anche clienti di se stessi e devono fornire le stesse risorse ai progetti interni, finirai esattamente dove sei ora. Sono stato lì, fatto quello, ho avuto un intero comò di magliette.

Quindi, se non riesci a farlo correttamente, due opzioni sono pronte all'uso, che il tuo personale odierà perché ora devono adattarsi allo stampo del sistema che acquisti. Oppure sarà personalizzabile e dovrai comunque passare il tempo a PROJECT a personalizzarlo.

OPPURE Rifattorizza ciò che hai. Ricorda che le persone si aspetteranno la stessa completa funzionalità quando entrerà quella nuova, quindi è per questo che in qualsiasi altro modo devi fare tutto in una volta. Se lo ri-fattorizzi, hai la possibilità di capire come funziona e quindi, piuttosto che i cambiamenti ad hoc, lo pianifichi in molti piccoli progetti secondari.

Senza vedere il sistema, probabilmente vedrei come normalizzare il più possibile nel back-end, spostare la maggior parte dell'SQL in Proc memorizzati. Quindi crea un nuovo front-end da C # Forms o da una webapp. Se riesci a ottenere la tua logica di business e SQL dal front-end, sarà più facile rifarlo in un secondo momento. Mantenendo ciò che fai ai piccoli progetti, se viene messo da parte in qualsiasi momento o interrotto, avrai fatto progressi che verranno utilizzati.

Alcune buone risposte qui già - ma potrei solo sottolineare che (supponendo che ci siano sviluppatori interni) una quantità relativamente piccola di lavoro avrà un grande impatto - aggiungi le chiavi primarie (non dovresti nemmeno cambiare tutte le tue query in usali), aggiungi indici ai campi che usi e ottimizza un po 'le tue domande e potresti vedere un aumento assolutamente enorme. Comprati subito un po 'di RAM per acquistarlo con il tempo e la testata necessari per ripararlo, quindi mettiti al lavoro.

A proposito di "riparalo o eliminalo", se le funzionalità del sistema funzionano sostanzialmente per te e fanno quello che ti serve, non riscrivere la ruota. Se i tuoi utenti devono fare ginnastica per usare la cosa perché non si adatta alle tue esigenze, allora non c'è motivo di sforzarti.

Bene ... questo è passato un po 'di tempo fa, ma ho pensato di registrare il risultato qui.

Alla fine, ho attraversato la VBA riga per riga per affrontare un altro problema. Fu allora che mi resi conto che alcune chiamate per recuperare i set di righe venivano bloccate per 20-30 + secondi.

Quando ho scavato dentro di loro, ho scoperto che il set di righe era basato su una query di MS Access.

Quello stava selezionando i dati da un'altra query di accesso.

Quello stava selezionando i dati da ancora un'altra query di accesso.

Tutto ciò sembrava che fossero stati trascinati e rilasciati insieme utilizzando il Query Designer.

Ho esaminato la mezza dozzina di punti critici per l'utente e ho scoperto che erano tutti esattamente uguali a questo.

Quindi ho rimosso completamente le pile di query concatenate e le ho sostituite con una singola query pass-through che poteva essere scritta in T-SQL ed eseguita direttamente sul server.

Il miglioramento è stato assolutamente immenso in ogni caso a colpo sicuro e non c'erano più attese di domande per nessuno.

E poi ho lasciato la compagnia. Non ho idea se sia ancora lì ... ma non mi manca.

Sto postando una risposta separata invece di aggiungere semplicemente la risposta di Dayton perché c'è un costo che non viene preso in considerazione dalle prime persone a pubblicare una risposta: il costo della riqualificazione degli utenti e il costo della modifica delle procedure aziendali per adattarsi un nuovo programma software. Altrimenti, quello che ha detto.

Uno dei motivi principali per cui le aziende sviluppano il proprio software è che dispongono di procedure aziendali che non corrispondono a quelle presenti sul mercato. Il che è fantastico: le procedure aziendali individuali di un'azienda sono una parte significativa del valore che un'azienda mette in campo e SONO il vantaggio competitivo che un'azienda ha sul resto del suo mercato. Sostituire il software con qualcosa di generico richiederebbe di riqualificare il personale e sacrificare il vantaggio competitivo, oppure dovresti personalizzare la soluzione per adattarla ai tuoi processi aziendali. Entrambi sono costosi e richiedono molto tempo. Come consulente aziendale e amministratore di sistema, ho visto questi costi uccidere da soli le piccole aziende.

Dalle tue dichiarazioni, sembra che tu sia praticamente legato a processore / software. Farei due cose: aggiungere indici (entro i limiti), in particolare alle colonne che attualmente non li usano. E vorrei lanciare il set di processori più veloce che puoi, perché sembra che sia lì che sei vincolante se non hai molte unità che leggono 'al picco.

(Inoltre, aggiornerei l'edizione del server per quanto possibile - quando lo metterai in atto, Access 2000 e SQL Server 2000 avranno dieci anni. Questo è VECCHIO in anni di computer!)

Ciò richiede una totale ristrutturazione (nuova architettura). Ricostruisci il sistema da zero. Questo ti farà risparmiare molto nel lungo periodo (costi generali di manutenzione). Per il momento, chuck hardware. Penso che questa domanda sia più un "caso aziendale" che un'indagine tecnica. Dal punto di vista tecnico, la risposta è un vero e proprio "potere più potente". Per quanto riguarda il business, costruisci un nuovo sistema!

Risposta tecnica:

Hai un gran numero di suggerimenti che affermano che le chiavi primarie e l'indicizzazione dovrebbero essere esaminate a fondo. Ad Access piace anche usare una colonna TimeVamp di SQL Server, nota anche come RowVersion su ogni tabella, in quanto ciò riduce molto il tempo che Access spende a decidere se un record è stato modificato quando si tratta di aggiornare i record.

Risposta aziendale:

Una nuova soluzione CRM è molto impegnativa nella formazione delle persone e non finirai mai con un sistema che soddisfa esattamente le tue esigenze aziendali.

Troverei una buona persona di Access che è anche molto ben informata su SQL Server e li farei passare 3 o 6 mesi a normalizzare i tavoli e sistemare i punti deboli degli utenti. Assicurati che la persona lavori ai piani di sicurezza come utenti, anche se in uno spazio silenzioso, e sia accessibile. Anche se non troppo accessibile. Agli sviluppatori non piacciono le interruzioni. S

Sulla base delle informazioni fornite, vorrei sostituire il sistema. Preferibilmente con un altro CRM che consente l'integrazione flessibile con altri sistemi (che comprometterebbe il tuo ISP ERP ).

La parte più difficile sarà convincere il management e gli utenti a richiedere un aggiornamento.

Gestione

Esprimi le tue preoccupazioni su problemi tecnici, basse prestazioni, paura di fallimenti bizantini, ecc. Quindi presenta 2 CRM alternativi. Parla dell'integrazione aziendale, della strategia ERP complessiva per l'azienda e, soprattutto, di come questo renderà i dipendenti più produttivi e redditizi. Usa casi studio. Fai questo non più di 15 minuti (a meno che non vogliano maggiori informazioni). Quindi devi convincere gli utenti.

utenti

Piani di formazione (che un fornitore può fornire [e la gestione dovrebbe approvare]), comunicazione continua al 20% superiore dei tuoi utenti (utenti esperti, quelli che causano problemi) e un solido impegno a mantenere il sistema operativo al 100% per il primo mese (il primo mese creerà o distruggerà qualsiasi nuovo IS).

Esistono molti prodotti CRM, scegli quello più adatto alle tue esigenze aziendali.

Il lancio dell'hardware incoraggia solo una progettazione e una gestione più scadenti, fino a quando il sistema non è così patetico da non funzionare bene anche con l'hardware più recente e più potente. È tempo di guardare a una migliore implementazione. Prima analizza ciò che è richiesto. Solo quando comprendi appieno i requisiti puoi iniziare a cercare il modo migliore per implementarli. Una volta che sei sicuro di aver compreso i requisiti, inizia a vedere se è meglio / più conveniente modificare ciò che hai o iniziare da zero, possibilmente con qualcosa di completamente diverso.

A lungo termine probabilmente sarebbe meglio rifare il database. Lanciare più hardware risolverà il problema per un po ', ma se continui a usarlo finirai per lanciarti più hardware dopo un po'.

In genere quando ci sono problemi di prestazioni si osservano cose come i / o colli di bottiglia su dischi rigidi / RAID, condivisione del database, ecc ... ma per cose come la condivisione è necessario che il database sia progettato correttamente per sfruttarlo. Dai suoni di esso, l'applicazione non sarà mai in grado di ridimensionare.

A lungo termine, la ripetizione del database e del software front-end per riflettere meglio le vostre attuali esigenze aziendali vi servirà meglio a lungo termine. I tuoi utenti ti ringrazieranno, il tuo hardware durerà più a lungo e, nel lungo periodo, risparmierà molto più denaro che lanciare hardware gigantesco al problema.

Data la tua descrizione, la creazione di un sistema completamente nuovo su misura è inutile: finirai proprio dove hai iniziato, o forse anche peggio di come sei ora. Quindi, a meno che tu non riesca a convincere qualcuno ad acquistare una soluzione di terze parti, la tua scommessa migliore è quella di refactoring il meglio che puoi e lanciarci l'hardware.

Direi che dovresti fare due cose: 1) Analisi delle prestazioni sul server SQL. Sembra che tu abbia identificato il lato server come l'origine dei ritardi, quindi ora devi sapere quali query sono in ritardo e perché. Con ogni probabilità, puoi trovare alcune query hot-spot da ottimizzare che ti darebbero grandi benefici. Diamine, se hai client che si aggiornano ogni pochi secondi, vedi se riesci a ridurre la loro frequenza di aggiornamento (L'elenco sullo schermo DEVE REALMENTE aggiornare ogni 5 secondi? 30 sarebbero OK? In caso contrario, che ne dici di 15? ). Cose stupide come aumentare i timer di aggiornamento potrebbero farti risparmiare un sacco di costi, se riesci a cavartela.

2) Lancia più hardware. PARTICOLARMENTE lanciando enormi quantità di ariete. Volete così tanta memoria che il database si adatti interamente alla RAM. Tieni d'occhio il tuo sistema operativo e le versioni del software ( apparentemente ci sono molte regole con le versioni di Windows e quale hardware effettivamente supportano). Se riesci a convincerti che un maggior numero di core potrebbe essere d'aiuto, lancia anche quante più CPU e core riesci a ottenere.

Hai menzionato RAM e processori, ma non dischi. Devo ammettere che è passato quasi un decennio da quando ho avuto a che fare con SQL Server di MS, ma è legato ai dischi tanto quanto qualsiasi altro database, se non può contenere tutto in memoria.

Probabilmente proverei prima a riempire la macchina con tutta la RAM che può richiedere, quindi mi assicurerò che i log vengano scritti su dischi che non vengono utilizzati per tabelle o indici. Proverei quindi ad assicurarmi che nessuna tabella abbia i propri indici sullo stesso mandrino.

Dopodiché, mi preoccuperei dell'ottimizzazione a livello di database, ma con ciò, dovrai definire i tuoi test e un obiettivo di ottimizzazione in modo da non interrompere le cose o peggiorare le query. Anche se hai detto che le chiavi primarie non hanno mostrato molto vantaggio nel tuo database di test, dovresti esaminare la tua metodologia di test - le chiavi primarie possono consentire ad alcuni database (non sono sicuro se MS SQL sia uno di questi) di usare il blocco a livello di record , piuttosto che i blocchi a livello di tabella, che possono ridurre la contesa che potrebbe non essere mostrata nei test con solo pochi utenti.

Innanzitutto, sono d'accordo con Kyle Hodgson e aggiungo PK. È economico (solo tempo) e potresti vedere una spinta alle tue domande. Che dire degli indici sulle colonne di join nelle prime 10 query più brutte? Dove sono le scansioni del tavolo?

Secondo, che dire del taglio dei dati nel database? Nelle query vengono restituite più righe di quelle necessarie? Concordo anche con il suggerimento di Kyle di RAM (altri due GB).

Inserisci tutto questo nel tuo commento (Joseph Kern) su ciò che proponi per l'interim mentre traccia il futuro. Chiedi alla direzione e agli utenti cosa succede all'organizzazione se l'attuale app CRM craterizza e non è disponibile. Forse questo li aiuterà a pensare al futuro.

Ottieni l'hardware!

Non solo è molto economico al momento se scegli un chip serie Xeon 55xx ma urlerà per tutto ciò che puoi lanciare.

È solo una questione di rischio / ricompensa: puoi spendere soldi e un sacco di tempo per migliorare il DB o acquistarlo in modo più rapido ed economico.

Considera di girare l' interruttore di memoria da 3 GB e aggiungere altri 2 GB di memoria.