Condividi tramite

  • Articolo

Gestione dei metadati quando si rende disponibile un database in un'altra istanza del server

Le informazioni presentate in questo argomento sono rilevanti per l'utilizzo di MicrosoftSQL Server 2005 e versioni successive nelle situazioni seguenti:

  • Impostazione del mirroring per un database.

  • Preparazione per il cambio di ruoli tra server primario e server secondario in una configurazione per il log shipping.

  • Ripristino di un database in un'altra istanza del server.

  • Collegamento di una copia di un database in un'altra istanza del server.

Alcune applicazioni dipendono da informazioni, entità e/o oggetti esterni all'ambito di un database in modalità a utente singolo. Un'applicazione include in genere dipendenze nei database master e msdb, nonché nel database utente. Qualsiasi elemento archiviato all'esterno di un database utente necessario per il corretto funzionamento di tale database deve essere reso disponibile nell'istanza del server di destinazione. Ad esempio, gli account di accesso per un'applicazione vengono archiviati come metadati nel database master e devono essere ricreati nel server di destinazione. Se il piano di manutenzione di un'applicazione o un database dipende da processi di SQL Server Agent i cui metadati sono archiviati nel database msdb, è necessario ricreare tali processi nell'istanza del server di destinazione. Analogamente, i metadati per un trigger a livello di server vengono archiviati nel database master.

Quando il database per un'applicazione viene spostato in un'altra istanza del server, è necessario ricreare tutti i metadati delle entità e degli oggetti dipendenti nei database master e msdb dell'istanza del server di destinazione. Ad esempio, se un'applicazione del database utilizza trigger a livello di server, non è sufficiente collegare o ripristinare il database nel nuovo sistema. Il database non funzionerà come previsto a meno che non si ricreino manualmente i metadati per tali trigger nel database master.

Informazioni, entità e oggetti archiviati all'esterno dei database utente

Nel resto dell'argomento vengono riepilogate le potenziali problematiche che possono influenzare un database reso disponibile in un'altra istanza del server. Potrebbe essere necessario ricreare uno o più tipi di informazioni, entità o oggetti indicati nell'elenco seguente. Per visualizzare un riepilogo, fare clic sul collegamento per l'elemento.

  • Impostazioni di configurazione del server

  • Credenziali

  • Query tra database

  • Proprietà dei database

  • Query distribuite o server collegati

  • Dati crittografati

  • Messaggi di errore definiti dall'utente

  • Notifiche degli eventi ed eventi WMI (a livello del server)

  • Stored procedure estese

  • Proprietà del motore di ricerca full-text per SQL Server

  • Processi

  • Account di accesso

  • Autorizzazioni

  • Impostazioni di replica

  • Applicazioni Service Broker

  • Procedure di avvio

  • Trigger (a livello del server)

Impostazioni di configurazione del server

In SQL Server 2005 e versioni successive i servizi e le funzionalità chiave vengono installati e avviati in modo selettivo. In questo modo, è possibile ridurre la superficie di attacco del sistema. Nella configurazione predefinita di nuove installazioni, molte funzionalità non sono abilitate. Se il database si basa su qualsiasi funzionalità o servizio disabilitato per impostazione predefinita, tale funzionalità o servizio dovrà essere abilitato nell'istanza del server di destinazione.

Per ulteriori informazioni su queste impostazioni e sulla relativa abilitazione o disabilitazione, vedere Informazioni su Configurazione superficie di attacco e Impostazione delle opzioni di configurazione del server.

[Torna all'inizio]

Credenziali

Una credenziale è un record contenente le informazioni di autenticazione necessarie per la connessione a una risorsa all'esterno di SQL Server. La maggior parte delle credenziali è costituita da un account di accesso e da una password di Windows.

Per ulteriori informazioni su questa funzionalità, vedere Credenziali (Motore di database).

[!NOTA]

Gli account proxy di SQL Server Agent utilizzano credenziali. Per conoscere l'ID delle credenziali di un account proxy, utilizzare la tabella di sistema sysproxies.

[Torna all'inizio]

Query tra database

Il valore predefinito delle opzioni DB_CHAINING e TRUSTWORTHY è OFF. Se una di queste opzioni è impostata su ON per il database originale, può essere necessario abilitarla nel database nell'istanza del server di destinazione. Per ulteriori informazioni, vedere ALTER DATABASE (Transact-SQL).

In SQL Server 2000 Service Pack 3 (SP3) e nelle versioni successive di SQL Server le operazioni di collegamento e scollegamento comportano la disabilitazione del concatenamento della proprietà tra database relativo al database in oggetto. Per informazioni su come abilitare il concatenamento, vedere Opzione cross db ownership chaining.

Per ulteriori informazioni, vedere anche:

[Torna all'inizio]

Proprietà dei database

Quando un database viene ripristinato in un altro computer, l'account di accesso di SQL Server o l'utente di Windows che inizia l'operazione di ripristino diventa automaticamente il proprietario del nuovo database. Al momento del ripristino, l'amministratore di sistema o il nuovo proprietario del database possono modificare il proprietario del database.

Query distribuite e server collegati

Le query distribuite e i server collegati sono supportati per le applicazioni OLE DB. Le query distribuite consentono di accedere ai dati da più origini di dati eterogenee nello stesso computer o in computer diversi. Una configurazione con server collegati consente a SQL Server di eseguire comandi su origini dei dati OLE DB in server remoti. Per ulteriori informazioni su queste funzionalità, vedere Query distribuite, Collegamento di server e Recupero di metadati da server collegati.

[Torna all'inizio]

Dati crittografati

Se il database che si sta rendendo disponibile in un'altra istanza del server contiene dati crittografati e se la chiave master del database è protetta dalla chiave master del servizio nel server originale, potrebbe essere necessario ricreare la crittografia della chiave master del servizio. La chiave master del database è una chiave simmetrica che viene utilizzata per proteggere le chiavi private di certificati e chiavi asimmetriche in un database crittografato. Al momento della creazione, la chiave master del database viene crittografata con l'algoritmo Triple DES e una password specificata dall'utente.

Per abilitare la decrittografia automatica della chiave master del database in un'istanza del server, viene crittografata una copia di questa chiave utilizzando la chiave master del servizio. Questa copia crittografata viene archiviata sia nel database che nel database master. La copia archiviata nel database master viene in genere aggiornata automaticamente a ogni modifica della chiave master. SQL Server tenta innanzitutto di decrittografare la chiave master del database con la chiave master del servizio dell'istanza. Se il tentativo non riesce, SQL Server cerca nell'archivio credenziali le credenziali di chiave master aventi lo stesso GUID del database per cui è necessaria la chiave master. SQL Server tenta quindi di decrittografare la chiave master del database con ogni credenziale corrispondente fino a quando non riesce a completare l'operazione o non sono disponibili altre credenziali da provare. Per aprire una chiave master non crittografata con la chiave master del servizio, è necessario utilizzare l'istruzione OPEN MASTER KEY e una password.

Quando viene copiato, ripristinato o collegato un database crittografato in una nuova istanza di SQL Server, una copia della chiave master del database crittografata dalla chiave master del servizio non viene archiviata nel database master nell'istanza del server di destinazione. Nell'istanza del server di destinazione, è necessario aprire la chiave master del database. Per aprire la chiave master, eseguire l'istruzione OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'. È quindi consigliabile abilitare la decrittografia automatica della chiave master del database eseguendo l'istruzione ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. L'istruzione ALTER MASTER KEY fornisce all'istanza del server una copia della chiave master del database crittografata con la chiave master del servizio. Per ulteriori informazioni, vedere OPEN MASTER KEY (Transact-SQL) e ALTER MASTER KEY (Transact-SQL).

Per informazioni su come abilitare la decrittografia automatica della chiave master del database di un database mirror, vedere Impostazione di un database mirror crittografato.

Per ulteriori informazioni, vedere anche:

[Torna all'inizio]

Messaggi di errore definiti dall'utente

I messaggi di errore definiti dall'utente sono contenuti nella vista del catalogo sys.messages. Questa vista del catalogo è archiviata nel database master. Se un'applicazione del database dipende da messaggi di errore definiti dall'utente e il database è reso disponibile in un'altra istanza del server, utilizzare sp_addmessage per aggiungere tali messaggi definiti dall'utente nell'istanza del server di destinazione.

[Torna all'inizio]

Notifiche degli eventi ed eventi WMI (a livello del server)

Notifiche degli eventi a livello di server

Le notifiche degli eventi a livello di server sono archiviate nel database msdb. Se un'applicazione del database si basa su notifiche degli eventi a livello di server, tali notifiche devono pertanto essere ricreate nell'istanza del server di destinazione. Per visualizzare le notifiche degli eventi in un'istanza del server, utilizzare la vista del catalogo sys.server_event_notifications. Per ulteriori informazioni, vedere Notifiche degli eventi (Motore di database).

Le notifiche degli eventi vengono inoltre recapitate utilizzando Service Broker. I route per i messaggi in ingresso non sono inclusi nel database che contiene un servizio. I route espliciti sono invece archiviati nel database msdb. Se il servizio utilizza un route esplicito nel database msdb per eseguire il routing dei messaggi in ingresso al servizio, quando si collega un database in una diversa istanza, è necessario ricreare questo route. Per ulteriori informazioni, vedere Routing di Service Broker.

Per impostare un database per il recapito dei messaggi remoti

Eventi di Strumentazione gestione Windows (WMI)

Il provider WMI per eventi del server consente di utilizzare il servizio Strumentazione gestione Windows (WMI) per monitorare eventi in SQL Server. Qualsiasi applicazione che si basi su eventi a livello di server esposti tramite il provider WMI utilizzato da un database deve essere definita nel computer dell'istanza del server di destinazione. Il provider di eventi WMI crea le notifiche degli eventi con un servizio di destinazione definito nel database msdb.

[!NOTA]

Per ulteriori informazioni, vedere Concetti relativi al provider WMI per eventi del server.

Per creare un avviso di WMI utilizzando SQL Server Management Studio

Funzionamento delle notifiche degli eventi per un database con mirroring

Il recapito tra database delle notifiche degli eventi che richiede un database con mirroring è remoto, per definizione, in quanto per il database con mirroring è possibile eseguire il failover. Service Broker offre uno speciale supporto per i database con mirroring, sotto forma di route con mirroring. Un route con mirroring dispone di due indirizzi, uno per l'istanza del server principale e uno per l'istanza del server mirror.

Impostando i route con mirroring, si rende il routing di Service Broker compatibile con il mirroring del database. I route con mirroring consentono a Service Broker di reindirizzare in modo trasparente le conversazioni all'istanza del server principale corrente. Prendere, ad esempio, in considerazione un servizio, Service_A, ospitato da un database con mirroring, Database_A. Si supponga che sia necessario un altro servizio, Service_B ospitato da Database_B, che comunichi con Service_A. Affinché tale comunicazione sia possibile, Database_B deve contenere una route con mirroring per Service_A. Inoltre, Database_A deve contenere una route di trasporto TCP senza mirroring a Service_B che, diversamente da una route locale, rimane valido dopo il failover. Questi route consentono il ritorno degli ACK dopo un failover. Dato che il servizio del mittente è sempre denominato nello stesso modo, il route deve specificare l'istanza del broker.

Il requisito per i route con mirroring si applica indipendentemente dal fatto che il servizio nel database con mirroring sia il servizio Initiator o il servizio di destinazione:

  • Se il servizio di destinazione si trova nel database con mirroring, il servizio Initiator deve disporre di un route con mirroring verso la destinazione. Tuttavia, la destinazione può disporre di un route regolare verso l'Initiator.

  • Se il servizio Initiator si trova nel database con mirroring , il servizio di destinazione deve disporre di un route con mirroring verso l'Initiator per recapitare acknowledgement e risposte. Tuttavia, l'Initiator può disporre di un route regolare verso la destinazione.

Per ulteriori informazioni, vedere anche:

[Torna all'inizio]

Stored procedure estese

Nota importanteImportante

Questa caratteristica verrà rimossa a partire da una delle prossime versioni di Microsoft SQL Server. Evitare di utilizzare questa funzionalità in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata. Utilizzare in alternativa l'integrazione con CLR.

Le stored procedure estese sono programmate utilizzando l'API per stored procedure estese di SQL Server. Un membro del ruolo predefinito del server sysadmin può registrare una stored procedure estesa con un'istanza di SQL Server e concedere agli utenti l'autorizzazione a eseguire la procedura. Le stored procedure estese possono essere aggiunte soltanto al database master.

Le stored procedure estese vengono eseguite direttamente nello spazio degli indirizzi di un'istanza di SQL Server e possono produrre perdite di memoria o altri problemi che riducono le prestazioni e l'affidabilità del server. È consigliabile valutare l'opportunità di archiviare le stored procedure estese in un'istanza di SQL Server distinta dall'istanza contenente i dati di riferimento. Valutare inoltre l'opportunità di utilizzare query distribuite per accedere al database. Per ulteriori informazioni, vedere Query distribuite.

Nota importanteImportante

Prima di aggiungere stored procedure estese al server e concedere le autorizzazioni EXECUTE ad altri utenti, è necessario che l'amministratore di sistema esamini con attenzione ogni stored procedure estesa per verificare che non contenga codice dannoso o malware. Per ulteriori informazioni, vedere Stored procedure estese.

Per ulteriori informazioni, vedere GRANT - autorizzazioni per oggetti (Transact-SQL), DENY - autorizzazioni per oggetti (Transact-SQL) e REVOKE - autorizzazioni per oggetti (Transact-SQL).

[Torna all'inizio]

Proprietà del motore di ricerca full-text per SQL Server

Le proprietà per il motore di ricerca full-text vengono impostate da sp_fulltext_service. Verificare che l'istanza del server di destinazione disponga delle impostazioni necessarie per queste proprietà. Per ulteriori informazioni su queste proprietà, vedere FULLTEXTSERVICEPROPERTY (Transact-SQL).

Inoltre, se le versioni del componente word breaker e stemmer o del componente filtri di ricerca full-text sono diverse nelle istanze del server originale e del server di destinazione, l'indice e le query full-text possono comportarsi in modo diverso. Anche il thesaurus viene archiviato in file specifici dell'istanza. È necessario trasferire una copia di questi file in un percorso equivalente nell'istanza del server di destinazione oppure ricrearli nella nuova istanza.

[!NOTA]

Quando si collega un database SQL Server 2005 contenente file di cataloghi full-text in un'istanza di server SQL Server 2008, i file di catalogo vengono collegati dal percorso precedente insieme agli altri file del database, come in SQL Server 2005. Per ulteriori informazioni, vedere Aggiornamento della ricerca full-text.

Per ulteriori informazioni, vedere anche:

[Torna all'inizio]

Processi

Se il database si basa su processi di SQL Server Agent, sarà necessario ricrearli nell'istanza del server di destinazione. I processi dipendono dai relativi ambienti. Se si pianifica di ricreare un processo esistente nell'istanza del server di destinazione, può essere necessario modificare l'istanza del server di destinazione in modo che corrisponda all'ambiente di tale processo nell'istanza del server originale. I fattori ambientali seguenti sono significativi:

  • Account di accesso utilizzato dal processo

    Per creare o eseguire i processi di SQL Server Agent, è innanzitutto necessario aggiungere tutti gli account di accesso di SQL Server richiesti dal processo all'istanza del server di destinazione. Per ulteriori informazioni, vedere Procedura: Configurazione di un utente per la creazione e la gestione di processi di SQL Server Agent (SQL Server Management Studio).

  • Account di avvio del servizio SQL Server Agent

    L'account di avvio del servizio definisce l'account di Microsoft Windows utilizzato per l'esecuzione di SQL Server Agent, nonché le relative autorizzazioni di rete. SQL Server Agent viene eseguito con un account utente specificato. Il contesto del servizio SQL Server Agent influisce sulle impostazioni per il processo e per il relativo ambiente di esecuzione. È necessario che l'account abbia accesso alle risorse, ad esempio alle condivisioni di rete, richieste dal processo. Per informazioni su come selezionare e modificare l'account di avvio del servizio, vedere Selezione di un account per il servizio SQL Server Agent.

    Per un corretto funzionamento, è necessario che l'account di avvio del servizio sia configurato con dominio, file system e autorizzazioni per il Registro di sistema appropriati. Inoltre, un processo potrebbe richiedere una risorsa di rete condivisa che deve essere configurata per l'account del servizio. Per informazioni, vedere Impostazione di account di servizio Windows.

  • Il servizio SQL Server Agent, associato a un'istanza specifica di SQL Server, dispone di un proprio hive del Registro di sistema e i relativi processi presentano in genere dipendenze da una o più delle impostazioni in questo hive del Registro di sistema. Per funzionare come previsto, un processo richiede queste impostazioni del Registro di sistema. Se si utilizza uno script per ricreare un processo in un altro servizio SQL Server Agent, è possibile che nel Registro di sistema relativo non siano disponibili le impostazioni corrette per tale processo. Affinché i processi ricreati funzionino correttamente in un'istanza del server di destinazione, è necessario che i servizi SQL Server Agent originale e di destinazione presentino le stesse impostazioni del Registro di sistema.

    Nota di attenzioneAttenzione

    La modifica delle impostazioni del Registro di sistema nel servizio SQL Server Agent di destinazione per gestire un processo ricreato può essere problematica se le impostazioni correnti sono necessarie per altri processi. Se, inoltre, il Registro di sistema viene modificato in modo non appropriato, il sistema potrebbe venire gravemente danneggiato. Prima di modificare il Registro di sistema, è consigliabile eseguire il backup di tutti i dati importanti disponibili nel computer.

  • Proxy di SQL Server Agent

    Un proxy di SQL Server Agent definisce il contesto di protezione per il passaggio di processo specificato. Affinché un processo venga eseguito nell'istanza del server di destinazione, è necessario ricreare in tale istanza tutti i proxy di cui necessita il processo. Per ulteriori informazioni, vedere Creazione di proxy di SQL Server Agent e Risoluzione dei problemi relativi a processi multiserver che utilizzano proxy.

Per ulteriori informazioni, vedere anche:

Per visualizzare processi esistenti e relative proprietà

Per creare un processo

Per creare script per un processo esistente

Procedure consigliate per l'utilizzo di uno script per ricreare un processo

Per iniziare, è consigliabile creare lo script di un processo semplice, ricreare il processo nell'altro servizio SQL Server Agent ed eseguire il processo per verificare se funziona come previsto. In questo modo, è possibile identificare eventuali incompatibilità e tentare di risolverle. Se un processo per cui è stato creato uno script non funziona come previsto nel nuovo ambiente, è consigliabile creare un processo equivalente che funzioni correttamente in tale ambiente.

[Torna all'inizio]

Account di accesso

L'accesso a un'istanza di SQL Server richiede un account di accesso di SQL Server valido. Questo account di accesso viene utilizzato nel processo di autenticazione che verifica se l'entità può connettersi all'istanza di SQL Server. Un utente del database il cui account di accesso di SQL Server corrispondente non è definito o è definito in modo errato in un'istanza del server non potrà accedere a tale istanza. Tale utente viene definito utente isolato (orfano) del database in tale istanza del server. Un utente del database può divenire isolato (orfano) dopo il ripristino, il collegamento o la copia di un database in un'altra istanza di SQL Server.

Per generare uno script per tutti gli oggetti nella copia originale del database o per alcuni di essi, è possibile utilizzare Generazione guidata script e, nella finestra di dialogo Selezione opzioni generazione script, impostare l'opzione Script per account di accesso su True. Per ulteriori informazioni, vedere Procedura: Generazione di uno script (SQL Server Management Studio).

Per informazioni su come visualizzare gli account di accesso di SQL Server e su come rilevare e risolvere gli utenti isolati (orfani) in un'istanza del server, vedere Risoluzione dei problemi relativi agli utenti isolati.

[!NOTA]

Per informazioni su come impostare account di accesso per un database con mirroring, vedere Configurazione degli account di accesso per il mirroring del database e Gestione di account di accesso e di processi dopo un cambio di ruolo.

[Torna all'inizio]

Autorizzazioni

I tipi seguenti di autorizzazioni possono essere influenzati quando un database viene reso disponibile in un'altra istanza del server.

  • Autorizzazioni GRANT, REVOKE o DENY per gli oggetti di sistema

  • Le autorizzazioni GRANT, REVOKE o DENY nell'istanza del server (autorizzazioni a livello di server)

Autorizzazioni GRANT, REVOKE o DENY per gli oggetti di sistema

Le autorizzazioni per gli oggetti di sistema, ad esempio stored procedure, stored procedure estese, funzioni e viste, sono archiviate nel database master e devono essere configurate nell'istanza del server di destinazione.

Per generare uno script per tutti gli oggetti nella copia originale del database o per alcuni di essi, è possibile utilizzare Generazione guidata script e, nella finestra di dialogo Selezione opzioni generazione script, impostare l'opzione Script per autorizzazioni a livello oggetto su True. Per ulteriori informazioni, vedere Procedura: Generazione di uno script (SQL Server Management Studio).

Nota importanteImportante

Se si creano script per account di accesso, le password non vengono incluse negli script. Se sono presenti account di accesso che utilizzano l'autenticazione di SQL Server, è necessario modificare lo script nella destinazione.

Gli oggetti di sistema sono visibili nella vista del catalogo sys.system_objects. Le autorizzazioni per gli oggetti di sistema sono visibili nella vista del catalogo sys.database_permissions nel database master. Per informazioni su come eseguire query in queste viste del catalogo e su come concedere autorizzazioni per gli oggetti di sistema, vedere GRANT - autorizzazioni per oggetti di sistema (Transact-SQL). Per ulteriori informazioni, vedere REVOKE - autorizzazioni per oggetti di sistema (Transact-SQL) e DENY - autorizzazioni per oggetti di sistema (Transact-SQL).

Autorizzazioni GRANT, REVOKE o DENY per un'istanza del server

Le autorizzazioni nell'ambito del server vengono archiviate nel database master e devono essere configurate nell'istanza del server di destinazione. Per informazioni sulle autorizzazioni del server di un'istanza del server, eseguire una query nella vista del catalogo sys.server_permissions. Per informazioni sulle entità del server, eseguire una query nella vista del catalogo sys.server_principals e per informazioni sull'appartenenza ai ruoli del server, eseguire una query nella vista del catalogo sys.server_role_members.

Per ulteriori informazioni, vedere GRANT - autorizzazioni per server (Transact-SQL), REVOKE - autorizzazioni per server (Transact-SQL) e DENY - autorizzazioni per server (Transact-SQL).

Autorizzazioni a livello del server per un certificato o una chiave asimmetrica

Non è possibile concedere autorizzazioni a livello del server direttamente a un certificato o a una chiave asimmetrica. Le autorizzazioni a livello del server vengono viceversa concesse a un account di accesso mappato creato esclusivamente per un certificato o una chiave asimmetrica specifica. Pertanto, ogni certificato o chiave asimmetrica che richiede autorizzazioni a livello del server richiede un proprio account di accesso mappato al certificato o un account di accesso mappato alla chiave asimmetrica. Per concedere autorizzazioni a livello del server per un certificato o una chiave asimmetrica, concedere le autorizzazioni al relativo account di accesso mappato.

[!NOTA]

Un account di accesso mappato viene utilizzato solo per l'autorizzazione del codice firmato con il certificato o la chiave asimmetrica corrispondente. Gli account di accesso mappati non possono essere utilizzati per l'autenticazione.

L'account di accesso mappato e le relative autorizzazioni risiedono nel database master. Se un certificato o una chiave asimmetrica risiede in un database diverso da master, è necessario ricreare tale certificato o chiave asimmetrica nel database master ed eseguirne il mapping a un account di accesso. Se si sposta, copia o ripristina il database in un'altra istanza del server, è necessario ricreare tale certificato o chiave asimmetrica nel database master dell'istanza del server di destinazione, eseguirne il mapping a un account di accesso e concedere le autorizzazioni a livello del server richieste all'account di accesso.

Per creare un certificato o una chiave asimmetrica

Per mappare un certificato o una chiave asimmetrica a un account di accesso

Per assegnare autorizzazioni all'account di accesso mappato

Per ulteriori informazioni su certificati e chiavi asimmetriche, vedere Gerarchia di crittografia.

[Torna all'inizio]

Impostazioni di replica

Se si ripristina un backup di un database replicato in un altro server o database, le impostazioni di replica non potranno essere mantenute. In questo caso, è necessario ricreare tutte le pubblicazioni e le sottoscrizioni dopo il ripristino dei backup. Per semplificare questo processo, creare script per le impostazioni di replica correnti e per l'abilitazione e la disabilitazione della replica. Per ulteriori informazioni, vedere Procedura: Creazione di script per gli oggetti di replica (SQL Server Management Studio). Per ricreare più agevolmente le impostazioni di replica, copiare questi script e modificare i riferimenti al nome del server in base all'istanza del server di destinazione.

Per ulteriori informazioni, vedere Backup e ripristino dei database replicati, Replica e mirroring del database e Replica e log shipping.

[Torna all'inizio]

Applicazioni di Service Broker

Insieme al database vengono spostati molti aspetti di un'applicazione di Service Broker. Tuttavia, alcuni aspetti dell'applicazione dovranno essere ricreati o riconfigurati nella nuova posizione. Per ulteriori informazioni, vedere Migrazione (Service Broker).

[Torna all'inizio]

Procedure di avvio

Una procedura di avvio è una stored procedure contrassegnata per l'esecuzione automatica che viene eseguita a ogni avvio di SQL Server. Se il database dipende da procedure di avvio, è necessario definire tali procedure nell'istanza del server di destinazione e configurarle per l'esecuzione automatica all'avvio.

Per ulteriori informazioni, vedere Esecuzione automatica di stored procedure.

[Torna all'inizio]

Trigger (a livello del server)

I trigger DDL attivano stored procedure in risposta a vari eventi DDL (Data Definition Language). Questi eventi corrispondono principalmente a istruzioni Transact-SQL che iniziano con le parole chiave CREATE, ALTER e DROP. Alcune stored procedure di sistema che eseguono operazioni di tipo DDL possono inoltre attivare trigger DDL.

Per ulteriori informazioni su questa funzionalità, vedere Trigger DDL.

[Torna all'inizio]