Se ti venisse chiesto se un sistema potesse sostenere una doppia crescita, a quali 3 cose faresti per rispondere?

Question

Diciamo che al tuo posto di lavoro dice il tuo capo

  

Quel sistema laggiù, che ha perso tutta la conoscenza istituzionale ma sembra funzionare abbastanza bene in questo momento, potremmo scaricare il doppio dei dati in esso e sopravvivere?

Non hai familiarità con il sistema.

È in SQL Server 2000 (principalmente un'app di database).

Non esiste un ambiente di test.

Potresti essere in grado di dirottarlo nei fine settimana se hai bisogno di eseguire un benchmark.

Quali sarebbero le 3 cose che faresti per convincere te stesso e poi il tuo manager che potresti assumere quel carico extra. E se non potessi farlo, sullo stesso hardware ... l'hardware aggiuntivo (misurato in dollari) sarebbe necessario per soddisfare quella richiesta.

Per rispondere alla risposta di doofledorfer, i tuoi presupposti sono quasi tutti a 180 gradi. Ma è colpa mia per una domanda ambigua.

1. Uno dei server principali esegue 7x24 con una base del 70% e picchi da lì e nessuno sa cosa sta facendo.

2. Questo non è un problema di buy-in o piagnistei ... La nostra azienda potrebbe non avere molta scelta in materia.

3. Poiché questo è affidato esternamente, ritardi nell'attuazione potrebbero comportare multe enormi. Riunioni così ampie per valutare il rischio sono quasi impossibili. Esiste il rischio che il doppio dei dati scarichi il sistema per i clienti esistenti.

Speravo che qualcuno potesse dire qualcosa del genere, vedere se togli il sistema dalla linea domenica sera a mezzanotte ed esegui i test SQLIO per vedere quanto è vicino il sottosistema di archiviazione alla saturazione. Cose del genere.

Answer 1

1. Imposta un ambiente di test, anche se devo farlo sul mio laptop.

2. Abilita un qualche tipo di registrazione sul sistema di produzione per avere un'idea del volume delle transazioni oltre al volume dei dati.

3. Leggi il codice sorgente mentre eseguo gli stress test sul mio laptop con quantità crescenti di dati.

Detto questo, sono d'accordo con questo incarico, perché è ingiusto. È come chiedere a qualcuno in una barca se la barca può galleggiare con il doppio del carico - ma non puoi uscire dalla barca o toglierlo dal suo servizio regolare.

Answer 2

Hai appena descritto un tipico progetto Agile. La tua risposta dovrebbe essere:

1. Non lo so e non sarò in grado di dirlo senza test.
2. Oltre al volume di dati, potrebbero esserci problemi con schemi di utilizzo, interazioni tra applicazioni, ottimizzazione di database e server, ecc.
3. Quindi esaminiamo un elenco di base di fattori di rischio e come risolverli.
4. Una volta fatto ciò, esaminiamoli in ordine inverso di rischio; e prendere una decisione stop / continue mentre sviluppiamo i risultati.
5. ecc.

Senza buy-in della gestione e partecipazione almeno a quel livello, qualsiasi altra risposta che potresti dare è un desiderio ad alto rischio e "3 i più importanti" è un non sequitur.

Sarei ottimista a meno che il tuo sistema attuale non sia già sostanzialmente caricato. La maggior parte dei server dovrebbe funzionare con una capacità inferiore al 50% su tutte le risorse, oppure essere in supporto vitale. E mi aspetto che non avresti la conversazione se il server esistente avesse già a che fare con problemi di caricamento; sebbene "sembra funzionare abbastanza bene in questo momento" è abbastanza impreciso da essere preoccupante.

Answer 3

dipende principalmente dal suo livello attuale. Se il raddoppio va da 2 GB a 4 GB, basta farlo. Se va da 1 TB a 2 TB, hai in programma di fare qualcosa.

Raccoglierei alcune informazioni utilizzando Performance Monitor e le fornirei per aiutare a prendere una decisione consapevole.

Answer 4

Dipende da cosa intendi per "raddoppiare i dati".

Se ciò influirà solo su una tabella (ad esempio tabella dei prodotti), allora probabilmente sei al sicuro, poiché la maggior parte delle query che fanno riferimento a quella tabella hanno più probabilità di raddoppiare il tempo di esecuzione (presupponendo che non si faccia riferimento al contemporaneamente due volte in una query).

Il problema sorgerà se si raddoppia la quantità di dati in tutte le tabelle poiché il tempo di esecuzione può aumentare in modo esponenziale e può portare ad alcuni gravi problemi.

Ma in generale sosterrei risposta di doofledorfer