Gestire i metadati quando si rende disponibile un database in un altro server

  • Articolo

Si applica a:SQL Server

Le informazioni contenute in questo articolo sono relative alle situazioni seguenti:

  • Configurazione delle repliche di disponibilità di un gruppo di disponibilità dei gruppi di disponibilità AlwaysOn.

  • 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.

  • Esecuzione dell'aggiornamento del motore di database usando il metodo: eseguire la migrazione a una nuova installazione.

  • Migrazione di database ad Azure SQL (macchina virtuale o Istanza gestita).

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 archiviatimaster.

Quando il database per un'applicazione viene spostato in un'altra istanza del server, è necessario creare di nuovo 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 di 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'articolo 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, selezionare il collegamento per l'elemento.

Impostazioni di configurazione del server

In SQL Server 2005 (9.x) 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 altre informazioni su queste impostazioni e sulla relativa abilitazione o disabilitazione, vedere Opzioni di configurazione del server (SQL Server).

Titolo

Una credenziale è un record contenente le informazioni di autenticazione necessarie per connettersi 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 altre informazioni su questa funzionalità, vedere Credenziali (Motore di database).

Nota

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

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 altre informazioni, vedere ALTER DATABASE (Transact-SQL).

Le operazioni di collegamento e scollegamento consentono la disabilitazione del concatenamento della proprietà tra database per il database. Per informazioni su come abilitare il concatenamento, vedere Opzione di configurazione del server cross db ownership chaining.

Per altre informazioni, vedere anche Configurare un database mirror per l'uso della proprietà Trustworthy (Transact-SQL)

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 ha iniziato 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 altre informazioni su queste funzionalità, vedere Server collegati (Motore di database).

Dati crittografati

Se nel database che si sta rendendo disponibile in un'altra istanza del server sono contenuti 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 master. In genere, la copia archiviata in master viene aggiornata in modo automatico ogni volta che la chiave master viene modificata. SQL Server tenta innanzitutto di decrittografare la chiave master del database con la chiave master del servizio dell'istanza. Se il tentativo non riesce, in SQL Server si esegue una ricerca nell'archivio delle credenziali per individuare le credenziali di chiave master con lo stesso GUID del database per cui è richiesta la chiave master. SQL Server tenta quindi di decrittografare la chiave master del database con ogni credenziale corrispondente fino a quando non si 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 usare 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 in 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 altre informazioni, vedere OPEN MASTER KEY (Transact-SQL) e ALTER MASTER KEY (Transact-SQL).

Per informazioni sull'abilitazione della decrittografia automatica della chiave master del database di un database mirror, vedere Impostare un database mirror crittografato.

Per ulteriori informazioni, vedere anche:

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 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, usare sp_addmessage per aggiungere tali messaggi definiti dall'utente nell'istanza del server di destinazione.

Notifiche degli eventi ed eventi di Strumentazione gestione Windows (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 una notifica degli eventi a livello di server, tale notifica deve essere nuovamente creata nell'istanza del server di destinazione. Per visualizzare le notifiche degli eventi in un'istanza del server, usare la vista del catalogo sys.server_event_notifications . Per altre informazioni, vedere Event Notifications.

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 consente di usare una route esplicita nel database msdb per eseguire il routing dei messaggi in arrivo al servizio, quando si collega un database in un'istanza diversa è necessario ricreare questa route.

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 msdb.

Nota

Per altre 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 una route regolare verso la destinazione.

Stored procedure estese

Importante

Questa funzionalità verrà rimossa nelle versioni future di SQL Server. Evitare di usare questa funzionalità in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata. Usare invece la funzionalità Integrazione CLR.

Le stored procedure estese sono programmate utilizzando l'API per stored procedure estese di SQL Server. Un membro del ruolo predefinito del server amministratore di sistema 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.

Importante

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 altre informazioni, vedere GRANT - autorizzazioni per oggetti (Transact-SQL), DENY - autorizzazioni per oggetti (Transact-SQL) e REVOKE - autorizzazioni per oggetti (Transact-SQL).

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 altre informazioni su queste proprietà, vedere FULLTEXTSERVICEPROPERTY (Transact-SQL).

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 colleghi un database di SQL Server 2005 (9.x) contenente file di cataloghi full-text in un'istanza del server di SQL Server, i file di catalogo vengono collegati dal percorso precedente insieme agli altri file del database, come in SQL Server 2005 (9.x). Per altre informazioni, vedere Aggiornamento della ricerca full-text.

Per ulteriori informazioni, vedere anche:

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 SQL Server di richiesti dal processo all'istanza del server di destinazione. Per altre informazioni, vedere Configurare un utente per la creazione e la gestione di processi di SQL Server Agent.

  • Account di avvio del servizio SQL Server Agent

    L'account di avvio del servizio definisce l'account di Microsoft Windows in cui viene eseguito SQL Server Agent e 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 Selezionare 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 Configurare account di servizio e autorizzazioni di Windows.

  • 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.

    Attenzione

    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 altre informazioni, vedere Creare un proxy di SQL Server Agent e Risolvere i problemi relativi a processi multiserver che usano proxy.

Per ulteriori informazioni, vedere anche:

Per visualizzare processi esistenti e relative proprietà

Per creare un processo

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.

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. Questo utente viene definito utente orfano del database nell'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.

Nota

per informazioni su come configurare gli account di accesso per un database con mirroring, vedere Configurare gli account di accesso per il mirroring del database o i gruppi di disponibilità Always On (SQL Server) e Gestione di account di accesso e di processi dopo un cambio di ruolo (SQL Server).

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

  • 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 alcuni o tutti gli oggetti nella copia originale del database è possibile usare la procedura guidata di generazione script e, nella finestra di dialogo Selezione opzioni generazione script impostare l'opzione Script per autorizzazioni a livello oggetto su True.

Importante

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 altre 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 altre 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 con mapping creato esclusivamente per un certificato o una chiave asimmetrica specifica. Ogni certificato o chiave asimmetrica che richiede autorizzazioni a livello del server richiede quindi un proprio account di accesso con mapping al certificato o un account di accesso con mapping 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 con mapping.

Nota

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

L'account di accesso con mapping e le relative autorizzazioni risiedono nel master. Se un certificato o una chiave asimmetrica risiede in un database diverso da master, è necessario ricreare tale certificato o chiave asimmetrica nel 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 eseguire il mapping di un certificato o una chiave asimmetrica a un account di accesso

Per assegnare autorizzazioni all'account di accesso con mapping

Per ulteriori informazioni su certificati e chiavi asimmetriche, vedere Encryption Hierarchy.

Proprietà TRUSTWORHTY

La proprietà di database TRUSTWORTHY consente di indicare se l'istanza di SQL Server considera attendibile il database e il relativo contenuto. Quando viene collegato un database, per impostazione predefinita e per questioni di sicurezza, questa opzione è impostata su OFF, anche se era impostata su ON nel server originale. Per alte informazioni su questa proprietà, vedere Proprietà di database TRUSTWORTHY. Per informazioni su come impostare questa opzione su ON, vedere ALTER DATABASE (Transact-SQL).

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 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 altre informazioni, vedere Backup e ripristino di database replicati, Mirroring e replica del database (SQL Server) e Log shipping e replica (SQL Server).

Applicazioni 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. Quando un database viene collegato da un altro server, per impostazione predefinita e per questioni di sicurezza, le opzioni is_broker_enabled e is_honoor_broker_priority_on sono impostate su OFF. Per informazioni su come impostare queste opzioni su ON, vedere ALTER DATABASE (Transact-SQL).

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.

Trigger (a livello del server)

I trigger DDL attivano stored procedure in risposta a diversi 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 DDL Triggers.

Vedi anche

Database indipendenti
Copiare database in altri server
Collegamento e scollegamento di un database (SQL Server)
Failover su un database secondario per il log shipping (SQL Server)
Cambio di ruolo durante una sessione di mirroring del database (SQL Server)
Impostazione di un database mirror crittografato
Gestione configurazione SQL Server
Risolvere i problemi relativi agli utenti isolati (SQL Server)
Migrare a una nuova installazionePanoramica della migrazione: da SQL Server a SQL Server in VM di Azure