I processi di consolidamento consentono di ottenere costi di gestione meno elevati, apportare una maggiore semplicità nella gestione dei database e possono inoltre migliorare sensibilmente la qualità dei livelli di servizio.
Un recente sondaggio indipendente ha messo in luce che il consolidamento di database è molto più di un semplice fenomeno passeggero.
L’indagine ha evidenziato che già il 6 % delle imprese ha portato a termine un progetto di consolidamento, mentre quasi la metà ne sta valutando la fattibilità o si trova
nelle fasi iniziali dello stesso.
Di seguito i punti di maggior interesse emersi dall’indagine:
• Oltre il 70 % delle aziende sono coinvolte in progetti di consolidamento di database di un certo livello, ma almeno la metà di queste sono soltanto all’inizio
• Eliminare fornitori specifici non è l’obiettivo finale, ma il passaggio obbligato attraverso il quale si realizza il consolidamento. Le aziende sono intenzionate a ridurre il numero di database, ma lo fanno puntando su alcuni vendor ben precisi
• Il consolidamento dei database si prefigura come una contesa tra due fattori: il raggiungimento di una fondamentale maturità tecnologica da un lato, e gli oneri relativi
alla gestione e i costi dell’IT dall’altro
• Tra le tre grandi aziende fornitrici di database, Oracle è quella che più delle altre si sta imponendo nel mercato del consolidamento
• Alcune aziende sono disposte ad avviare un processo di consolidamento così radicale da rivalutare a fondo la scelta del loro principale fornitore di database, questo è il motivo per cui IBM DB2 sta incontrando più difficoltà a mantenere la propria quota di mercato
I motivi principali per intraprendere un processo di consolidamento:
o Ridurre il TCO (Total Cost of Ownership) – numero di licenze, personale interno, consulenze esterne;
o Migliorare il livello di affidabilità con effetti positivi a livello di SLA;
o Innalzare il livello di sicurezza;
o Migliorare la condivisione dei dati e la fruibilità degli stessi;
o Offrire un miglior supporto per la globalizzazione dei servizi;
o Determinare un miglioramento prestazionale per le applicazioni in uso;
o Offrire la possibilità di centralizzare backup e archiviazioni;
o Incrementare il ROI (Return Of Investments) per una maggior redditività
o In conclusione = ridurre il TCO di oltre il 20 %
Le aziende che hanno intrapreso questo cammino hanno posto in essere un progetto di consolidamento che si basa su un procedimento ben noto e testato suddiviso nelle tre fasi di ricerca informazioni/raccolta dati/ disegno progettuale. Tale procedimento permette di ottenere una chiara tabella di marcia contenente i passi necessari per attuare la migliore strategia di consolidamento con la scelta delle architetture hardware e software più indicate e che preveda i costi realizzativi e i benefici in termini di incremento della redditività.
Autore: Stefano Quercia
arà capitato molto ma molto spesso. Ogni volta che le sento penso, il database non può andare lento, non si muove, casomai sarà qualche processo/flusso che risponde lentamente, ma di sicuro non il database che va lento. Altrettanto spesso chi pronuncia quelle parole crede che ci sia un parametro FAST=TRUE con il quale risolvere tutti i problemi. Ovviamente quel parametro, per fortuna, non esiste altrimenti lo metterebbe direttamente a TRUE senza chiedere e non esisterebbero i DBA. Detto questo però, rimane il problema vero o percepito che sia, del quale sappiamo poco o niente e ci viene dato pochissimo tempo per risolvere. In fondo per mettere un parametro a TRUE quanto tempo ci volete mettere? Che fare a questo punto?
oblema di capacità di calcolo. Se è molto piccolo il database o non fa nulla oppure ha attese elevate per qualche causa specifica. Se la percentuale di WaitTime è molto più alta di quella del ServiceTime, c’è un problema di risorse. Se invece il ServiceTime è piu alto del WaitTime e il ResponseTime è minore del periodo di tempo preso in analisi, il database va bene e se c’è un problema è molto specifico o relativo ad una frazione di tempo inferiore a quella presa in esame. Di solito si usano tempi di raccolta dei dati di circa un’ora, ma mi sono capitati casi in cui sono dovuto scendere fino a 5 minuti per trovare il problema. Si potrebbe continuare con esempi all’infinito, ma va oltre lo scopo di questa discussione. Basta mettere la formula su google per trovare infiniti documenti, quando lo farete valutate sempre bene chi scrive, non tutti dovrebbero poterlo fare, metalink e ask tom sono ottimi punti di partenza.