Analysis Services non ha un sistema di backup molto sofisticato: esiste una funzionalità di backup e una di restore, disponibile dal tool a linea di comando MSMDARCH.EXE e dall’interfaccia utente di Analysis Manager. La granularità di tale funzionalità è l’intero database: prendere o lasciare, se uno volesse esportare le sole strutture dati… non c’è molto a disposizione.

 

Un’esigenza comune è quella di voler salvare (e ripristinare) la sola struttura dati (quindi la definizione di cubi, dimensioni, misure, ecc.), senza ripristinare anche il contenuto dei dati già elaborati. Il motivo è che i dati spesso non sono così utili, perché tanto possono essere ricostruiti. A maggior ragione, per passare un database dall’ambiente di sviluppo a quello di test, spesso è un po’ scomodo spostare anche i dati di test (che spesso e volentieri sono di qualche centinaio di Mb). Purtroppo non c’è nessuna funzionalità nativa che consenta di ottenere esattamente questa funzionalità. Senza andare a cercare tool di terze parti, vediamo tre diversi sistemi disponibili per ottenere questo tipo di funzionalità.

 

Copia e Incolla da Analysis Manager

 

La prima tecnica, quella direi più “ufficiale”, è di connettersi a due server diversi da una stessa istanza di Analysis Manager; da qui, con i comandi Copia e poi Incolla è possibile copiare e incollare un database da un server a un altro (in realtà si possono copiare anche singole entità come cubi o dimensioni, ma ciò non è interessante ai fini di questo articolo). Questa operazione copia solamente le strutture del database (cubi, dimensioni, misure, membri calcolati, ecc.), senza copiare l’eventuale contenuto.

 

Chi ha provato questa funzione saprà anche che non è particolarmente veloce. Senza entrare nel merito dei motivi per cui è così lenta, esaminiamo però quanto questa funzionalità sia utile in pratica. Se la si usa per copiare entità all’interno di uno stesso database, nessun problema. Copiare un database da un server all’altro, invece, presuppone che lo stesso utente sia nel gruppo Olap Administrator di entrambi i database: non è infatti possibile collegarsi con due utenti diversi, visto che l’operazione va fatta attraverso la medesima istanza di Analysis Manager (e quindi l’utente deve essere necessariamente lo stesso per entrambe le connessioni). Ciò non è esattamente all’ordine del giorno se si ha un minimo di rispetto per una strana cosa chiamata security.

 

Il fatto stesso di doversi fisicamente collegare a due server contemporaneamente può, alle volte, essere poco pratico. Il caso più frequente è quello dello sviluppatore che agisce su una LAN fisicamente disconnessa e priva di VPN rispetto alla LAN su cui risiede il server di produzione.

 

Metadati Scripter

 

Una possibile soluzione al problema è quella di creare uno script che, se eseguito sul server, generi tutte le entità di cui abbiamo bisogno, di fatto ricreando le stesse strutture che avevamo originariamente.

 

La cosa è resa tecnicamente possibile dal fatto che l’interfaccia amministrativa è esposta attraverso un modello a oggetti chiamato DSO (Decision Support Objects), che come molti componenti COM è utilizzabile da un linguaggio di scripting come VBScript. A questo punto basta trovare le funzioni e i parametri giusti e scriversi qualche centinaio di linee in un file VBS…

 

Per fortuna esiste, nel Resource Kit di SQL Server 2000, un piccolo componente chiamato MetaDataScripter: è un sorgente VB6 che può essere compilato (anzi, deve… visto che l’eseguibile non è incluso, se non ricordo male) e installato come estensione di Analysis Manager. Dopo aver fatto questo, compare un menu contestuale “All Tasks \ Create meta data script” che consente di generare il sorgente VBS per ricostruire l’entità selezionata: si può creare uno script per l’intero database o per un’entità più piccola, come un cubo o una dimensione…

 

Il file VBS generato è un file di testo, molto comodo da modificare con un qualsiasi editor. Se volete ricreare un database su un PC diverso da quello da cui avete “estratto” questi metadati è necessario fare qualcuno di questi interventi, perché altrimenti lo script tenta di connettersi sempre al PC originale (il nome della macchina è all’interno del file, per fortuna assegnato a una variabile dichiarata all’inizio, quindi è facile da modificare).

 

MetaDataScripter è molto comodo, anche se talvolta ha qualche bug (in particolare se lo usate con le impostazioni in italiano…) e il file generato è piuttosto ingombrante (anche se, una volta compattato, si può mandare ragionevolmente via mail).

 

Backup nativo dei soli metadati

 

Ma come, non avevamo detto che nativamente non c’è un backup dei soli metadati? Certo, è così, ma il trucco è quello di non far “vedere” i dati ad Analysis Services durante il backup.

 

Per capire il funzionamento di questa tecnica è necessario chiarire alcuni dettagli di funzionamento di Analysis Services. Al momento dell’installazione Analysis Services richiede il nome di una directory su cui far risiedere i dati (successivamente consultabile nelle proprietà del server su Analysis Manager). Ogni database di Analysis Services sarà gestito in una directory omonima all’interno di questa directory di partenza; la directory del database contiene poi altri file e directory, che contengono prevalentemente dati e in parte alcuni metadati delle strutture generate.

 

In realtà, però, le strutture di un database (cioè la definizione di cubi, dimensioni, misure, ecc.) sono memorizzate nel repository di Analysis Services, che per default è un file MDB (sì, è in Access) contenuto nella directory Bin di Analysis Services, in compagnia di file eseguibili e DLL che compongono questo prodotto. Tale repository può essere migrato su SQL Server, ma in questo articolo la locazione fisica del repository non è un aspetto rilevante. Ciò che conta è che il repository contiene i metadati di un database, cioè tutte le strutture senza i dati. Peccato però che il repository contenga la definizione di tutti i database: sarebbe bello poter estrarre solo la parte di repository contenente i dati di un particolare database e copiare tale informazioni sul repository di un altro server… in questo modo potremmo copiare la struttura del database senza i dati!

 

In effetti è possibile ottenere proprio questo comportamento utilizzando la funzionalità di backup di Analysis Services (sia con MSMDARCH.EXE che con l’interfaccia utente di Analysis Manager). Un backup non è altro che un file .CAB che contiene tutti i file disponibili nella directory corrispondente al database salvato più due file: olapdb.inf e olapdb.rep. Il file olapdb.rep contiene un’estrazione delle informazioni presenti nel repository in formato testuale; il file olapdb.inf contiene invece un elenco dei file contenuti nel .CAB. Dunque, il backup contiene le informazioni estratte dal repository, in modo che la successiva operazione di restore possa rigenerare le stesse informazioni nel repository del server su cui si fa il ripristino.

 

A questo punto si potrebbe pensare: bene, allora creo un file .CAB, cancello tutti i file tranne olapdb.rep e olapdb.inf e così ottengo un .CAB con le sole strutture ma senza i dati? Purtroppo ciò non è sufficiente, perché bisognerebbe anche editare a mano il file olapdb.inf per ricreare una situazione consistente con il nuovo contenuto del file. Fare tutto ciò a mano è possibile ma anche molto noioso, però funzionerebbe.

 

Una soluzione più ragionevole è quella di generare da subito un file .CAB senza i dati. Sarebbe stato bello (e ragionevole) avere un parametro su MSMDARCH.EXE per ottenere questa funzionalità… ma purtroppo non è così. Però si può usare un piccolo stratagemma: se Analysis Services non trova nulla nella directory corrispondente al database di cui vogliamo fare il backup… non metterà nulla neanche nel file .CAB, lasciando solo i due file che ci interessano (o poco più). In effetti ciò corrisponde esattamente a quanto avviene quando si crea un database con delle entità e, senza processare nulla, si fa un backup del database.

 

Per ottenere il risultato desiderato, però, bisogna eliminare (o rinominare) la directory contenente il database di cui vogliamo fare il backup, e ciò non può avvenire mentre il servizio di Analysis Services è attivo.

 

 

 

Dunque, riassumendo, la procedura da seguire per fare il backup di un ipotetico database MyOlapDb è questa (per alcuni passi segue una possibile linea di comando):

 

• Fermare il servizio di Analysis Services. Da linea di comando:

> NET STOP MSSQLServerOLAPService

• Rinominare la directory MyOlapDb, magari aggiungendo un suffisso (posizionarsi sulla directory Data Folder di Analysis Services):

   

> CD "c:\Program Files\Microsoft Analysis Services\Data"

> RENAME MyOlapDb MyOlapDb_disabled

• Riavviare il servizio di Analysis Services

   

> NET START MSSQLServerOLAPService

• Eseguire il backup del database, che conterrà i metadati ma sarà privo di dati – il file così ottenuto è piccolo e facilmente trasportabile

   

• Fermare il servizio di Analysis Services. Da linea di comando:

> NET STOP MSSQLServerOLAPService

• Ripristinare la directory MyOlapDb originale (posizionarsi sulla directory Data Folder di Analysis Services):

   

> CD "c:\Program Files\Microsoft Analysis Services\Data"

> RD MyOlapDb /S /Q

> RENAME MyOlapDb_disabled MyOlapDb

• Riavviare il servizio di Analysis Services

   

> NET START MSSQLServerOLAPService

 

La procedura descritta illustra anche un’altra possibilità: quella di mettere un database “off-line”. Tale funzionalità, disponibile su SQL Server, non è prevista per Analysis Services, ma può essere molto comoda, se non altro per velocizzare i tempi di avviamento del servizio di Analysis Services (legati alla presenza di database con particolari caratteristiche, come dimensioni con occupazioni di spazio elevate). Il backup viene effettuato in una condizione in cui il database è come se non fosse mai stato processato. Non è esattamente come se fosse off-line, anzi alla partenza Analysis Services crea le directory per i database eventualmente non trovati (per questo motivo il ripristino della directory originale nella procedura descritta è accompagnato da una cancellazione della directory rigenerata), però è la cosa più vicina che abbiamo.

 

La procedura descritta non è ufficialmente supportata da Microsoft, però funziona ed è efficace, soprattutto quando si vogliono ottenere dei backup facilmente trasportabili delle strutture dati. Ha il vantaggio di non richiedere nessuna installazione particolare (MetaDataScripter è un AddIn di Analysis Manager che richiede un apposito setup) ma ha il grande svantaggio di richiedere il riavvio del servizio di Analysis Manager, che non sempre è possibile.

 

 Purtroppo non c’è una soluzione ideale e proprio per questo ho pensato che scrivere questo articolo sarebbe stato molto utile per chi deve affrontare queste problematiche e vuole avere un po’ di supporto…