Altre classi e metodi AMO

Si applica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Questa sezione contiene classi comuni non specifiche di OLAP o data mining e utili per l'amministrazione o la gestione di oggetti in Analysis Services. Tali classi riguardano caratteristiche quali stored procedure, traccia, eccezioni e backup e ripristino.

Nella figura seguente viene illustrata la relazione delle classi descritte in questo argomento.

Oggetti assembly

Un Assembly oggetto viene creato aggiungendolo all'insieme assembly del server e quindi aggiornando l'oggetto Assembly al server utilizzando il metodo Update.

Per rimuovere un Assembly oggetto, è necessario eliminarlo usando il metodo Drop dell'oggetto Assembly . La rimozione di un Assembly oggetto dalla raccolta di assembly del database non elimina l'assembly, ma impedisce solo di visualizzarlo nell'applicazione fino alla successiva esecuzione dell'applicazione.

Per altre informazioni sui metodi e sulle proprietà disponibili, vedere Assembly in Microsoft.AnalysisServices .

Importante

Gli assembly COM potrebbero comportare un rischio per la sicurezza. A causa di questo rischio e altre considerazioni, gli assembly COM non sono più supportati.

Metodi di backup e ripristino

Backup e ripristino sono metodi che possono essere usati per creare copie di un database e ripristinare il database usando la copia. Il metodo Backup appartiene all'oggetto Database e il metodo Restore appartiene all'oggetto Server .

Il backup di un database può essere eseguito solo dagli amministratori del server e di database. Solo gli amministratori del server possono ripristinare un database in un server diverso da quello da cui è stato eseguito il backup, mentre gli amministratori di database possono ripristinare un database sovrascrivendo il database esistente solo se risultano proprietari del database da sovrascrivere. Dopo un ripristino, l'amministratore di database può perdere l'accesso al database ripristinato se il database è stato ripristinato con le definizioni di sicurezza originali.

I file di backup di database devono avere estensione abf.

Metodo di backup

Per eseguire il backup di un database, utilizzare il metodo Backup dell'oggetto di database con il nome del file di backup come parametro.

Valori predefiniti

AllowOverwrite=false

BackupRemotePartitions=false

Security=CopyAll

ApplyCompression=true

Metodo Restore

Per ripristinare un database in un server, utilizzare il metodo Restore del server con il file di backup come parametro.

Valori predefiniti

AllowOverwrite=false

DataSourceType=Remote

Security=CopyAll

Restrizioni

1. Una partizione locale non può essere ripristinata come partizione remota.

2. Una partizione remota non può essere ripristinata come partizione locale, ma può essere ripristinata in un server diverso da quello da cui è stato eseguito il backup.

Parametri e proprietà comuni per i metodi di backup e ripristino

• Il file è il nome del file di cui eseguire il backup (nome UNC) in/da.

• Percorso specifica le informazioni di backup specifiche del server, ad esempio BackupFile. In questo modo è possibile specificare un file di backup separato per un database remoto.

• DatasourceID specifica l'ID del database subordinato in un server remoto.

• ConnectionString consente di modificare l'origine dati remota nel caso in cui il server remoto sia stato modificato. Quando ConnectionString è presente, è necessario specificare sempre DatasourceID.

• La cartella consente il mapping delle cartelle per le partizioni nel disco rigido locale

• Original è la cartella originale per le partizioni locali.

• New è il nuovo percorso per le partizioni locali che si trovano nella cartella precedente "Originale".

• Password, se non vuota, specifica che il server crittograferà il file di backup.

Oggetti di traccia

Trace è un framework usato per il monitoraggio, la riproduzione e la gestione di un'istanza di Analysis Services. Un'applicazione client, ad esempio SQL Profiler, sottoscrive una traccia e il server invia gli eventi di traccia come specificato nella definizione di traccia.

Ogni evento viene descritto da una classe di evento che illustra il tipo di evento generato. In una classe di evento le sottoclassi di evento descrivono un livello di categorizzazione più dettagliato. Ogni evento viene descritto da un numero di colonne. Le colonne che descrivono un evento di traccia sono coerenti per tutti gli eventi e conformi alla struttura di traccia SQL. Le informazioni registrate in ogni colonna possono differire a seconda della classe di evento. Sebbene per ogni traccia sia specificato un set predefinito di colonne, il significato della colonna può differire a seconda della classe di evento. La colonna TextData ad esempio viene utilizzata per registrare il codice ASSL per tutti gli eventi relativi alle istruzioni.

Una definizione della traccia può includere una o più classi di evento di cui eseguire contemporaneamente la traccia. Per ogni classe di evento, è possibile aggiungere una o più colonne di dati alla definizione della traccia, sebbene non sia necessario utilizzare tutte le colonne di traccia. L'amministratore di database può decidere le colonne disponibili da includere in una traccia. È inoltre possibile eseguire selettivamente la traccia di classi di evento in base a criteri di filtro applicati a qualsiasi colonna nella traccia.

Le tracce possono essere avviate ed eliminate. È inoltre possibile eseguire più tracce contemporaneamente. Gli eventi di traccia possono essere acquisiti in tempo reale o indirizzati a un file per un'analisi o una riproduzione successiva. SQL Profiler è lo strumento usato per analizzare e riprodurre eventi di traccia. Gli eventi di una stessa traccia possono essere ricevuti da più connessioni.

Le tracce possono essere divise in due gruppi, ovvero tracce del server e tracce della sessione. Nelle tracce del server saranno disponibili le informazioni relative a tutti gli eventi del server, mentre nelle tracce della sessione saranno disponibili le informazioni relative solo agli eventi della sessione corrente.

Per definire le tracce dalla raccolta di tracce del server, effettuare le operazioni seguenti:

1. Creare un Trace oggetto e popolare i dati di base, inclusi ID traccia, nome, nome file di log, accodamento|sovrascrivi e altri.

2. Aggiungere gli eventi da monitorare alla raccolta di eventi dell'oggetto traccia. Per ogni evento vengono aggiunte colonne di dati.

3. Impostare i filtri per escludere le righe non necessarie di dati aggiungendoli alla raccolta di filtri.

4. Avviare la traccia. La creazione della traccia non avvia la raccolta dei dati.

5. Fermare il tracciamento.

6. Esaminare il file di traccia con SQL Profiler.

Per ottenere le tracce dall'oggetto sessione, effettuare le operazioni seguenti:

1. Definire le funzioni per gestire gli eventi di traccia generati nell'applicazione da SessionTrace. I possibili eventi sono OnEvent e Stopped.

2. Aggiungere le funzioni definite al gestore dell'evento.

3. Avviare la traccia della sessione.

4. Eseguire il processo e consentire ai gestori di funzione di acquisire gli eventi.

5. Arrestare la traccia della sessione.

6. Continuare l'applicazione.

Attributi CaptureLog e CaptureXML

Tutte le azioni che devono essere eseguite da AMO vengono inviate al server come messaggi XMLA. In AMO sono disponibili gli strumenti per acquisire tutti i messaggi di questo tipo senza le intestazioni SOAP. Per altre informazioni, vedere Introduzione alle classi AMO. La classe CaptureLog è il meccanismo disponibile in AMO per inserire nello script oggetti e operazioni. Per gli oggetti e le operazioni gli script verranno generati in XMLA.

Per avviare l'acquisizione del codice XML, la proprietà dell'oggetto server CaptureXML deve essere impostata su true. In questo modo verrà avviata l'acquisizione di tutte le azioni che devono essere inviate al server nella classe CaptureLog, senza che sia necessario inviare le azioni stesse al server. CaptureLog è considerata una classe poiché dispone del metodo Clear che consente di cancellare il log relativo all'acquisizione.

Per leggere il log, individuare la raccolta di stringhe e avviare l'iterazione sulle stringhe stesse. È possibile inoltre concatenare tutti i log in una stringa tramite il metodo dell'oggetto server ConcatenateCaptureLog cui sono associati tre parametri, due dei quali sono obbligatori. I parametri obbligatori sono transazionali, di tipo booleano e paralleli, di tipo booleano. Se la transazione è impostata su true, indica che il file batch XML verrà creato come singola transazione anziché ogni comando considerato come transazione separata. Se parallel è impostato su true, indica che tutti i comandi nel file batch verranno registrati per l'esecuzione simultanea anziché in sequenza durante la registrazione.

Classe di eccezione AMOException

È possibile utilizzare la classe eccezione AMOException per rilevare facilmente nell'applicazione eccezioni generate da AMO.

In caso di rilevamento di problemi, in AMO verrà generata un'eccezione. Nella tabella seguente vengono elencati i tipi di eccezioni gestite da AMO. Le eccezioni sono derivate dalla AmoException classe .

Eccezione	Origine	Descrizione
AmoException	Classe di base	L'applicazione riceve questa eccezione quando un oggetto padre obbligatorio è mancante o quando un elemento necessario non è presente in una raccolta.
OutOfSyncException	Derivata da AMOException	L'applicazione riceve questa eccezione quando AMO non è sincronizzato con il motore e quest'ultimo restituisce un riferimento a un oggetto sconosciuto in AMO.
OperationException	Derivata da AMOException	Importante eccezione ricevuta di frequente dalle applicazioni che contiene i dettagli relativi a un errore proveniente dal server probabilmente a causa di un'operazione AMO non corretta, ad esempio Update, Process o Drop.
ResponseFormatException	Derivata da AMOException	Questa eccezione si verifica quando il motore restituisce un messaggio in un formato sconosciuto in AMO.
ConnectionException	Derivata da AMOException	Questa eccezione si verifica quando non è possibile stabilire una connessione (tramite Server.Connect) o quando la connessione viene persa durante la comunicazione tra AMO e il motore, ad esempio durante un'operazione Update, Process o Drop.