Tre approcci alla gestione della crescita dei database

Transcript

1 White paper Tre approcci alla gestione della crescita dei database Si può sceglire se ridurre le dimensioni dei dati, eliminare tutti i dati insieme o dismettere le applicazioni e archiviare i relativi dati: in ogni caso, la crescita del database è una questione che può essere ignorata. Questa guida offre dei consigli per aiutarvi a scegliere la soluzione giusta.

2 Questo documento contiene informazioni riservate, proprietarie e coperte da segreto commerciale ("Informazioni confidenziali") di Informatica Corporation che non possono essere copiate, distribuite, duplicate o altrimenti riprodotte in alcun modo senza previa autorizzazione scritta di Informatica. Nonostante siano state adottate tutte le precauzioni necessarie per garantire la precisione e la completezza delle informazioni contenute nel presente documento, non si può escludere la presenza di errori tipografici o imprecisioni tecniche. Informatica declina qualsiasi responsabilità in relazione a perdite di qualsiasi natura derivanti dall'utilizzo delle informazioni contenute in questo documento. Le informazioni contenute in questo documento sono soggette a modifica senza preavviso. L'integrazione delle caratteristiche di prodotto descritte nel presente materiale in qualsiasi versione o upgrade dei prodotti software Informatica (oltre ai tempi di rilascio di tali versioni o upgrade) è interamente a discrezione di Informatica. Protetto da uno o più dei seguenti brevetti USA: 6,032,158; 5,794,246; 6,014,670; 6,339,775; 6,044,374; 6,208,990; 6,208,990; 6,850,947; 6,895,471; o dai seguenti brevetti USA in attesa di registrazione: 09/644,280; 10/966,046; 10/727,700. Questa edizione è stata pubblicata ad aprile 2014

3 White paper Indice Introduzione... 2 Partizionamento e compressione per ridurre le esigenze di storage.. 3 Archiviazione e tiering per ridurre i dati Soluzioni di tiering del database terze parti....6 Soluzioni di dismissione delle applicazioni... 7 Soluzioni di test data management...8 Un investimento studiato... 8 Tre approcci alla gestione della crescita dei database 1

4 Introduzione Non è certo un segreto che i dati siano in rapida crescita. Gli esperti prevedono un incremento del 4300% nella generazione annua di dati entro il Alla fine del 2011, risultava che la quantità di informazioni digitali create e condivise nel mondo era aumentata di nove volte in soli cinque anni, fino a raggiungere quasi due zettabyte. Entro il 2015, si prevede che creazione e condivisione di dati arriveranno almeno a quadruplicarsi. 2 Numeri sbalorditivi, ma che non dicono tutto. La richiesta di dati all'interno delle aziende sta crescendo. Ad accelerare ulteriormente tale incremento,interviene un fattore: all'interno delle aziende esistono almeno tre copie di ogni dato. 3 Inoltre, sta diventando molto più difficile liberarsi dei dati: il 40% dei partecipanti a un sondaggio rivolto a un gruppo di utenti di Oracle ha dichiarato che sceglie di conservare i dati oltre i sette anni stabiliti dalle normative, per rispettare i requisiti di compliance e avere a disposizione i dati in caso di controversie legali. 4 Con questa esplosione di dati, non c'è da sorprendersi se gli archivi si stanno espandendo a una velocità superiore al 20% ogni anno. 5 Una crescita incontrollata del database compromette le prestazioni e limita la disponibilità di applicazioni e dati mission-critical. Le applicazioni per database, diversamente da quelle per posta elettronica o sistemi di condivisione dei file, richiedono più copie dei database di produzione per supportare attività come ad esempio testing, sviluppo e creazione di report. Ogni volta che i dati si moltiplicano in un sistema di produzione, aumentano proporzionalmente anche i costi. Con il progressivo aumento dei dati, le strategie per gestire la crescita del database diventano sempre più determinanti. Occorre mantenere le prestazioni delle applicazioni nei database di produzione e in tutte le copie associate, per non far si che non si allunghino i tempi di risposta delle query sul database. Non solo, senza un piano ragionevole per gestire la crescita del database, i tempi per la manutenzione del database (clonazione, backup e applicazione di patch) aumenteranno, così come i cicli di test durante gli upgrade delle applicazioni. Acquistare a casaccio ulteriori componenti hardware per tenere il passo con la crescita dei dati non è una strategia sostenibile a lungo termine: si investe più denaro per una soluzione meno efficiente senza risolvere la causa alla radice del problema. È come costruire una casa nuova perché in quella vecchia non c'è più spazio per conservare oggetti che sono stati dimenticati e giacciono inutilizzati da anni. Invece di implementare altri componenti hardware per gestire l'esplosione dei dati, è molto più intelligente investire in soluzioni che riducano lo spazio occupato dai dati stessi e i relativi requisiti di storage, che eliminino o archivino i dati o che dismettano o consolidino le applicazioni. La presente guida analizza e valuta i pro e i contro delle opzioni per gestire la crescita dei dati dei database, per aiutare i lettori a scegliere l'approccio più adatto alla propria azienda. Zettabyte Un'esplosione digitale Informazioni digitali globali create e condivise E 2015E techandinnovationdaily.com Fonte: KPCB, IDC ibid 5 2

5 Partizionamento e compressione per ridurre le esigenze di storage I fornitori di database offrono funzionalità comuni, come ad esempio il partizionamento e la compressione, che aiutano i database administrator (DBA) a mantenere le prestazioni delle applicazioni e controllare quanto spazio dello storage totale viene occupato dai volumi di dati. Implementare queste soluzioni a livello di database richiede una conoscenza approfondita dell'applicazione e pertanto i DBA devono lavorare a stretto contatto con il team di sviluppo delle applicazioni per garantire l'implementazione della corretta strategia senza influire negativamente sulle prestazioni o sulle funzionalità dell'applicazione in produzione. Il partizionamento del database permette di utilizzare una logica di business per separare fisicamente i dati contenuti nelle tabelle del database in partizioni. L'applicazione rileverà i dati come in una singola tabella logica. Il file system vedrà invece i dati memorizzati in singoli file in base alla logica di partizione. Separando fisicamente i segmenti di dati, è possibile ottimizzare le query in modo che si possa accedere solo a una parte dei dati sul disco in base a quanto richiesto nella query (anziché effettuare la scansione dell'intera tabella del database per trovare un piccolo intervallo di dati richiesti). Pro: se la logica è allineata ai requisiti di conservazione, si possono gestire e spostare con precisione le partizioni del database senza influire sull'intera applicazione. Questa soluzione permette di spostare le partizioni su supporti di storage meno costosi oppure di comprimerle, eliminarle o metterle offline. Contro: tuttavia, quando si applica una logica di partizione per questioni di prestazioni senza allinearla con precisione alla logica delle policy di conservazione, il partizionamento del database può avere un impatto negativo sulle prestazioni. Peggio ancora, qualora fosse impossibile rendere la logica di partizione coerente rispetto a un oggetto di business completo (ad esempio, una transazione di business suddivisa su più tabelle con applicata una logica di partizionamento diversa), l'integrità relazionale dei dati potrebbe venire irreparabilmente danneggiata se una partizione venisse messa offline senza considerare le dipendenze tra le tabelle. Le funzionalità di compressione del database permettono di ridurre lo spazio occupato dai dati (e le esigenze di capacità dello storage) eseguendo diversi algoritmi sui dati contenuti in una tabella. I rapporti di compressione variano a seconda della composizione dei dati e in base a quanto il fornitore del database supporti i diversi algoritmi di compressione. Analogamente a quanto accade con il partizionamento, se si implementa la compressione senza considerare il modello dei dati dell'applicazione, le prestazioni dell'applicazione possono risultare significativamente compromesse. Pro: si riduce lo spazio occupato dai dati e quindi le esigenze di storage e si garantisce al tempo stesso accesso completo a tutti i dati del database. La compressione è vivamente consigliata quando le prestazioni del tool si sono dimostrate non incisive sulle prestazioni della produzione o sull'utilizzo di CPU. Contro: le prestazioni possono peggiorare sensibilmente a seconda delle modalità di implementazione della compressione. Le funzionalità di compressione potrebbero implicare spese per la licenza relativa ai componenti aggiuntivi. Tre approcci alla gestione della crescita dei database 3

6 Archiviazione e tiering per ridurre i dati La riduzione dei volumi di dati richiede la rimozione o l'eliminazione dei dati dal database di produzione o dalle copie di non produzione. Con questo approccio, bisogna comprendere il modello di dati applicativo per fare in modo che, quando si rimuovono i dati, ne venga mantenuta l'integrità relazionale e l'applicazione continui a funzionare correttamente. Tuttavia, l'eliminazione dei dati potrebbe non essere un'opzione percorribile per le aziende che devono mantenere i dati disponibili per lunghi periodi. Quando il modello di dati è complesso o se proviene da fornitori ISV terzi di applicazioni pacchettizzate, la gestione manuale del processo diventa costosa, difficile e rischiosa. In questo caso, è meglio sfruttare una soluzione di terze parti che permetta di separare i dati in base a policy, permettendo al tempo stesso l'accesso all'utente finale e mantenendo il supporto da parte di fornitori ISV e terzi. Le due soluzioni che discuteremo in questa guida includono l'archiviazione e il tiering del database. Le soluzioni di terze parti per l'archiviazione del database sono nate in risposta all'esigenza di gestire la crescita dei dati del database nonostante le limitazioni delle offerte dei fornitori di database e applicazioni. Queste soluzioni permettono di identificare in modo selettivo, di suddividere in livelli (tier), di archiviare o di eliminare i dati del database nel contesto dell'applicazione aziendale. Si possono ricollocare o archiviare i dati idonei su uno schema di database a parte, archiviare il database o il repository, mantenendo al tempo stesso l'accesso ai dati per l'utente finale tramite l'applicazione nativa o un'interfaccia utente separata simile. Pro: poiché queste soluzioni rimuovono i dati dal database di produzione, le prestazioni rimangono le stesse e in molti casi migliorano. I dati sono messi a disposizione dell'utente finale attraverso interfacce native richiedendo piccole modifiche all'applicazione. Contro: il processo di selezione di dati idonei e lo spostamento degli stessi su un altro repository possono creare problemi alle prestazioni durante la produzione, problemi di cui tenere conto quando si sceglie un'architettura di archiviazione del database. In base all'applicazione e alla configurazione dell'implementazione, la gestione e l'accesso ai dati in un repository separato potrebbe richiedere attività e processi di manutenzione supplementari. Figura 1. Tipica configurazione di archiviazione su database con accesso all'archivio tramite un collegamento al database Accesso in produzione Accesso all'archivio Livello di accesso dati DBLink Hot data Cold data Dati eliminati Database di produzione Repository archivio y Un approccio comune consiste nell'archiviare i dati obsoleti e inattivi del database di produzione in un database online separato o in un file di archivio, continuando a offrire accesso al repository di archivio mediante un collegamento al database. 4

7 Una soluzione di archiviazione del database generalmente prevede quattro componenti chiave: i metadati dell'applicazione, un policy engine, un repository di archiviazione e un livello di accesso ai dati. Metadati dell'applicazione: contengono informazioni per definire le tabelle che partecipano alle attività di partizione, trasferimento o archiviazione di un database. Memorizzano le relazioni tra queste tabelle, inclusi i vincoli a livello di database e applicazione e ogni criterio da considerare nella scelta dei dati da archiviare. I metadati per applicazioni pacchettizzate, come Oracle E-Business Suite, PeopleSoft o SAP, solitamente possono essere acquistati in repository pre-popolati per velocizzare i tempi di implementazione. I metadati applicativi sono fondamentali per assicurarsi che, nel momento in cui si applica una policy di archiviazione, venga mantenuta l'integrità referenziale dei dati e che venga rispettata la logica di business. Policy engine: in questo componente gli utenti definiscono le policy di conservazione in termini di durata e altre regole aziendali. Il policy engine è anche responsabile dell'esecuzione della policy all'interno del database e del trasferimento dei dati in un'area di destinazione. Questo comporta la conversione della policy e dei metadati in linguaggio SQL (Structured Query Language) che possa essere compreso dal database (ad esempio SELECT * da TABELLA A dove COLONNA 1 > 2 anni e COLONNA 2 = "Chiuso" / swap partition, e così via). In base all'insieme di competenze di cui dispone l'azienda e all'interesse nel controllare il processo durante l'esecuzione, questo risulta un componente la cui importanza va compresa a fondo, oltre ad essere un ottimo argomento da utilizzare durante discussioni e dimostrazioni tecniche. Repository di destinazione: memorizza i dati del database partizionati, migrati o archiviati. Le opzioni per il repository variano e sono stabilite in base a numerosi fattori, normalmente determinati dai requisiti di accesso all'archivio dell'utente finale. Alcune di queste opzioni includono partizioni dedicate all'interno dello stesso database, un altro database dedicato o archivi altamente compressi interrogabili tramite query. Esiste sempre la possibilità di esportare i dati in un formato open, come ad esempio CSV o XML. Si tratta di una decisione architetturale critica. Le principali considerazioni per ogni tipo di destinazione sono prese in esame nella Tabella 1. OPZIONE REPOSITORY DI DESTINAZIONE Partizione separata nella stessa tabella Schema separato nello stesso DB DB separato Archivio altamente compresso interrogabile con query File XML/CSV PRO Separa i dati per massimizzare le prestazioni di quelli cui si accede con maggiore frequenza Gli amministratori devono gestire solo un database Il database di produzione è ridotto in termini di dimensioni I dati sono rimossi dal database di produzione e i dati dell'archivio sono ridotti in termini di dimensioni e memorizzati in un file di archivio protetto I dati sono rimossi dal database di produzione e memorizzati in formato standard open per garantirne la leggibilità a lungo termine CONTRO Tutti i dati restano nel database di produzione finché le partizioni non sono spostate o eliminate Tutti i dati restano nel database di produzione finché non sono spostati o eliminati Gli amministratori devono gestire un database di archivio separato e le prestazioni di accesso potrebbero richiedere un più alto livello di monitoraggio Le prestazioni di accesso potrebbero richiedere un monitoraggio maggiore e gli amministratori devono garantire che le policy di sicurezza siano estese all'archivio. Le prestazioni di accesso potrebbero risultare significativamente peggiori, è necessaria un'applicazione di reporting separata per accedere ai dati e gli amministratori devono estendere le policy di sicurezza ai dati presenti in un file. Tabella 1. Pro e contro delle diverse opzioni per il repository di destinazione Tre approcci alla gestione della crescita dei database 5

8 Livello di accesso ai dati: meccanismo che rende i dati del database partizionato, migrato o archiviato accessibili a un'applicazione nativa, a un tool di reporting aziendale standard o a un portale di discovery dei dati. Di nuovo, queste opzioni variano e sono determinate dai requisiti di accesso dell'utente finale e dagli standard tecnologici implementati nel data center. Fornire un livello di accesso ai dati è fondamentale per gli utenti finali che devono accedere ai dati tramite applicazioni native o simili. Quando gli utenti accedono ai dati dell'archivio utilizzando una vista implementata con un collegamento al database, le prestazioni di risposta alle query potrebbero essere più lente. Soluzioni di tiering del database di terze parti Le soluzioni di tiering per database sono un complemento alle funzionalità di partizionamento per database esistenti, in cui i dati possono essere isolati automaticamente, che siano attivi o meno, all'interno del database, in base a policy aziendali specifiche. La classificazione comporta il posizionamento dei dati all'interno dello stesso database, sfruttando quella che viene chiamata "segmentazione application-aware". La segmentazione o il partizionamento di dati del database all'interno della stessa istanza di database separa fisicamente i dati senza alcun impatto sulla rappresentazione logica per l'applicazione nativa. Figura 2. Alternativa di tiering all'archiviazione su database Accesso in produzione Modello dati relazionale USA Canada... 2Q14 2Q14 2Q14 1Q14 1Q14 1Q14 4Q13 4Q13 4Q13 3Q13 3Q13 1Q13 Tier 0 (alte prestazioni) Tier 1 (alta capacità) 2Q14 2Q14 2Q14 1Q14 1Q14 1Q14 Tier N (compresso) Database di produzione Sfruttando un approccio di segmentazione, i dati possono essere compressi, messi offline o eliminati con un impatto minimo sulle prestazioni dell'applicazione in produzione. Inoltre, le aziende possono ottimizzare il posizionamento delle partizioni nella giusta categoria di supporti di storage, allineandole ai requisiti prestazionali necessari per soddisfare le esigenze aziendali. 6

9 Soluzioni di dismissione delle applicazioni Molte aziende lamentano una proliferazione di applicazioni legacy che consumano preziose risorse dal data center e stanno ragionando per capire se hanno davvero l'esigenza di tenere queste applicazioni online. Se i dati nei repository inattivi devono essere conservati per questioni di compliance o normative, le soluzioni di dismissione delle applicazioni offrono la possibilità di conservare i set di dati richiesti per lunghi periodi di tempo, mantenendo al tempo stesso il contesto aziendale e permettendo all'it di arrestare il sistema sorgente una volta per tutte. È possibile leggere le "10 cose da sapere prima di modernizzare le applicazioni" per ulteriori informazioni sulla dismissione delle applicazioni. Nel caso in cui un'intera applicazione del database non venga più utilizzata per supportare processi aziendali o esigenze operative del momento, ma continui a contenere dati coperti da obblighi di conservazione legali o normativi, la dismissione delle applicazioni è una soluzione economica che permette di migrare i dati da formati obsoleti o non supportati in un formato supportato, mantenendo inalterato il contesto aziendale e il livello di accesso per l'utente finale. Queste soluzioni sono simili all'archiviazione del database in quanto dotate di opzioni di memorizzazione dei dati del database in un archivio, ma differiscono per via del fatto che l'applicazione originale è sostituita da un'interfaccia utente simile separata e può essere completamente dismessa. La Figura 3 illustra un esempio di migrazione dei dati legacy in un repository di dismissione delle applicazioni, accessibile dalle moderne interfacce open, eliminando l'esigenza di stack tecnologici arcaici e obsoleti. Figura 3: Le soluzioni di dismissione delle applicazioni eliminano l'obsoleta tecnologia legacy Interfacce arcaiche per i dati legacy Accesso legacy Interfaccia standardizzata per i dati legacy Modello dati relazionale Database applicazione legacy Repository dei dati per la dismissione delle applicazioni I dati sono memorizzati in un file di archivio accessibile, online e protetto che potrebbe offrire una significativa riduzione dello storage grazie alle elevate percentuali di compressione dei dati. Tre approcci alla gestione della crescita dei database 7

10 Soluzioni di test data management Il Test Data Management (TDM) è il processo di creazione e utilizzo di un set di dati rappresentativo di quelli utilizzati dalle applicazioni aziendali. Una soluzione TDM permette di risparmiare ore nella creazione dei dati di test, rendere più efficiente il processo di test, evitare il rischio di esposizione dei dati sensibili e, infine, ridurre i costi associati alle operazioni di testing. Le soluzioni di test data management possono ridurre i requisiti di storage diminuendo la dimensione dei set di dati di test. Per ulteriori informazioni, leggere "Why You Need Test Data Management". OPZIONE DI TEST DATA MANAGEMENT Copia di sottoinsiemi dei dati dall'ambiente di produzione in un ambiente di destinazione Eliminazione dei dati in eccesso dalle copie complete di produzione Copie del database virtuali PRO Vengono copiati solo i dati necessari per l'ambiente di test e sviluppo. Visto che i set di dati sono ridotti, i cicli di test sono più brevi. Se il processo richiede di copiare solo le partizioni, il tempo per la copia è ridotto al minimo. Sono conservati solo i dati necessari per l'ambiente di test e sviluppo. Se il processo richiede di eliminare solo le partizioni di dati, il tempo per l'eliminazione dei dati è ridotto al minimo. I database di test possono essere creati quasi istantaneamente, richiedendo solo una minima parte dello storage. Anche gli ambienti di test possono essere ripristinati quasi istantaneamente. Le finestre di aggiornamento sono completate quasi istantaneamente. CONTRO Il processo di copia dei dati e il loro inserimento in un database vuoto potrebbe influire sulle prestazioni della sorgente e richiedere una quantità di tempo significativa in base al volume dei dati da copiare. Il processo deve essere ripetuto per l'aggiornamento. Inizialmente è richiesta una copia completa di produzione. Il processo per la rimozione di grandi set di dati potrebbe richiedere una quantità di tempo significativa. Il processo deve essere ripetuto per l'aggiornamento. I set di dati completi sono virtuali: i piani di test che accedono a set di dati completi non funzionano più velocemente quando il clone è disponibile. Le prestazioni in lettura/ scrittura dei database virtuali dipendono dal numero di database virtuali creati e ai quali si accede contemporaneamente. Tabella 2. Pro e contro delle opzioni per la soluzione di test data management Un investimento studiato Valutando le esigenze aziendali di accesso ai dati di un'applicazione e in che modo tali requisiti cambiano con l'invecchiamento dei dati, è possibile implementare una strategia per gestire la crescita dei dati che aiuti a decidere più razionalmente quali investimenti fare. Per i dati ai quali è necessario accedere regolarmente, sono implementati servizi IT di prima qualità (alte prestazioni, alta disponibilità). Per la maggior parte dei dati, tuttavia, la necessità di accedervi viene meno man mano che questi diventano obsoleti. Mappando i requisiti per le esigenze di accesso degli utenti aziendali nel tempo, per le pianificazioni di conservazione legale o per la gestione documentale e le esigenze di supporto operativo, è possibile pianificare meglio e in modo proattivo acquisti infrastrutturali e tecnologici nel contesto del controllo dell'aumento dei dati. Ottenendo risposte ad alcune delle domande chiave sulle esigenze di accesso dell'utente finale e soppesando l'impatto economico delle opzioni tecnologiche, si può progettare una soluzione in grado di ottimizzare gli investimenti. Per quanto tempo devono essere conservati i dati del database e perché (per supportare il processo di business, soddisfare requisiti legali e sostenere i processi operativi)? Più esteso è il periodo di conservazione, maggiore sarà la misura in cui l'architettura della soluzione dovrà tenere in considerazione volumi di dati potenzialmente significativi, upgrade tecnologici o obsolescenza. Questo determina fattori di costo legati al mantenimento dei dati online in un database o in un archivio e opzioni di supporto, come ad esempio online, nearline o offline. 8

11 È necessario l'accesso ai dati nel contesto dell'applicazione aziendale originale? Se i dati devono essere mantenuti per un periodo di tempo prolungato, bisogna accedervi nel contesto dell'applicazione originale? Qualora l'applicazione venga dismessa o aggiornata, i dati dovranno ancora essere visualizzati? In tal caso, questo potrebbe influire sulla scelta di archiviare i dati in un formato diverso dal database. Con che frequenza si accede ai dati e quali sono le aspettative prestazionali? La migrazione o l'archiviazione dei dati di database a bassa frequenza di accesso in un'infrastruttura con costi inferiori di storage è un'opzione eccellente per ridurre il costo complessivo della gestione dei dati. Se il numero di utenti e la frequenza di accesso ai dati dell'archivio sono relativamente alti, occorre tenere in conto l'i/o quando si sceglie l'architettura di destinazione per i dati archiviati. Tipicamente si limita l'accesso ai dati dell'archivio a un set ridotto di super-utenti o amministratori. Se ai dati accederanno pochi utenti e la frequenza di accesso ai dati è limitata, è ragionevole considerare uno storage a basso costo con caratteristiche prestazionali inferiori. Anche se l'accesso previsto va da minimo a nessuno, praticamente senza utenti, i dati potrebbero dover tuttavia essere accessibili a revisori o legali durante l'ediscovery: l'accesso online o la ricercabilità potenzialmente conducono all'architettura di destinazione. Oltre a progettare una soluzione software che elimini i costi pergestire la crescita del database, le opzioni server e storage possono offrire vantaggi significativi. Le risposte alle domande precedenti rappresentano una buona base per i responsabili dell'architettura di sistema che si stanno occupando di progetti economici. La classificazione e la categorizzazione dei dati del database in base ai requisiti di conservazione e agli schemi di accesso dell'utente finale permette alle organizzazioni IT di implementare una strategia che introduca risparmi sui costi significativi grazie a requisiti di elaborazione per storage e server inferiori. Agire intelligentemente sapendo dove sono archiviati i dati ed eliminando le copie ridondanti dei dati permette all'it di fare di più con meno risorse. Le "pulizie di primavera" liberano grandi spazi per le future esigenze Informazioni su Informatica Informatica Corporation (Nasdaq:INFA) è il principale fornitore indipendente di software per l'integrazione dei dati. Aziende in tutto il mondo si affidano a Informatica per valorizzare il potenziale racchiuso nelle informazioni - information potential - ottenendo un evidente vantaggio competitivo. Informatica Vibe, la prima e unica virtual data machine (VDM) integrabile, offre l'innovativa ed esclusiva funzionalità "Map Once. Deploy Anywhere." di Informatica Platform. Oltre aziende a livello mondiale utilizzano Informatica per sfruttare appieno il proprio patrimonio informativo, da dati nei dispositivi, dati mobile, social e Big Data, siano essi on premise, nel Cloud o sui social network. Per ulteriori informazioni: Lo sfruttamento delle funzionalità presenti all'interno del database o messe a disposizione dal fornitore dell'applicazione potrebbe essere sufficiente se il modello di dati del database è chiaro e il processo è una procedura di pulizia una tantum. Se il modello di dati è complesso, esteso su diverse tabelle e con una complessa logica di business, è consigliabile prendere in considerazione Informatica Data Archive, il software di smart partitioning e data archiving altamente scalabile e completo. Consente alle organizzazioni IT di migliorare significativamente le prestazioni dell'applicazione e gestire in modo economicamente conveniente la crescita dei dati su una serie di applicazioni aziendali enterprise, riducendo al tempo stesso costi e rischi. Con Informatica Data Archive, si possono segmentare i dati in base al valore di business, archiviare in sicurezza i dati delle applicazioni inattive e fornire un accesso costante ai dati archiviati per il business. Tre approcci alla gestione della crescita dei database 9

12 Informatica, Via Santa Maria Valle, Milano telefono: fax: Via Luca Gaurico 9/ Roma telefono: fax: Informatica Corporation. Tutti i diritti riservati. Informatica e Put potential to work sono marchi o marchi registrati di Informatica Corporation negli Stati Uniti e in giurisdizioni a livello mondiale. Tutti gli altri nomi di aziende e di prodotti possono essere nomi commerciali o marchi. IN09_0414_02640