Condividi tramite

Gestione dei metadati quando si rende disponibile un database in un'altra istanza del server (SQL Server)

  • Articolo

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

  • Configurazione delle repliche di disponibilità di un gruppo di disponibilità Always On gruppi di disponibilità.

  • 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 creati nuovamente nel server di destinazione. Se un piano di manutenzione dell'applicazione o del database dipende da SQL Server Agent processi, i cui metadati vengono 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 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 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

SQL Server 2005 e versioni successive installano e avviano in modo selettivo servizi e funzionalità chiave. 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 sull'abilitazione o la disabilitazione, vedere Opzioni di configurazione del server (SQL Server).For more information about these settings and enabling or disabling them, see Server Configuration Options (SQL Server).

[Top]

Credenziali

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

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

[Top]

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)

[Top]

Proprietà dei database

Quando un database viene ripristinato in un altro computer, l'account di accesso SQL Server o l'utente di Windows che ha avviato 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 del server collegato consente SQL Server di eseguire comandi sulle origini dati OLE DB nei server remoti. Per altre informazioni su queste funzionalità, vedere Server collegati (motore di database).

[Top]

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 database master. La copia archiviata nel database master viene generalmente aggiornata in modo automatico in seguito a ogni modifica della chiave master. SQL Server tenta prima di tutto di decrittografare la chiave master del database con la chiave master del servizio dell'istanza. Se la decrittografia ha esito negativo, SQL Server cerca le credenziali della chiave master dell'archivio credenziali con lo stesso GUID della famiglia del database per cui richiede la chiave master. SQL Server quindi tenta di decrittografare la chiave master del database con ogni credenziale corrispondente finché la decrittografia non riesce o non sono presenti altre credenziali. Per aprire una chiave master non crittografata con la chiave master del servizio, è necessario utilizzare l'istruzione OPEN MASTER KEY e una password.

Quando un database crittografato viene copiato, ripristinato o collegato a una nuova istanza di SQL Server, una copia della chiave master del database crittografata dalla chiave master del servizio non viene archiviata nel 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 seguente: 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:

[Top]

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

[Top]

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 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, usare la vista del catalogo sys.server_event_notifications . Per altre informazioni, vedere Event Notifications.

Inoltre, le notifiche degli eventi vengono recapitate tramite 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 gli eventi server consente di usare Strumentazione gestione Windows (WMI) per monitorare gli 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 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 supporto speciale 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.

Configurando route con mirroring, il routing di Service Broker è consapevole del mirroring del database. Le 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.

[Top]

Stored procedure estese

Importante

Questa funzionalità verrà rimossa a partire da una delle prossime versioni di Microsoft 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 l'integrazione CLR .

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

Le stored procedure estese vengono eseguite direttamente nello spazio 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 considerare l'archiviazione di stored procedure estese in un'istanza di SQL Server separata dall'istanza che contiene i dati a cui si fa 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 Object Permissions (Transact-SQL),DENY Object Permissions (Transact-SQL) e REVOKE Object Permissions (Transact-SQL).

[Top]

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 si collega un database SQL Server 2005 che contiene file di catalogo full-text in un'istanza del server SQL Server 2014, i file di catalogo vengono collegati dal percorso precedente insieme agli altri file di database, uguali a in SQL Server 2005. Per altre informazioni, vedere Aggiornamento della ricerca full-text.

Per ulteriori informazioni, vedere anche:

[Top]

Processi

Se il database si basa sui processi di SQL Server Agent, è 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 processi di SQL Server Agent, è prima necessario aggiungere eventuali account di accesso SQL Server 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.

  • SQL Server Agent account di avvio del servizio

    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 servizio, associato a un'istanza specifica di SQL Server, ha un proprio hive del Registro di sistema e i relativi processi in genere hanno 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 usa uno script per ricreare un processo in un altro servizio SQL Server Agent, il registro potrebbe non avere le impostazioni corrette per tale processo. Per eseguire nuovamente il comportamento dei processi in un'istanza del server di destinazione, i servizi originali e di destinazione SQL Server Agent devono avere le stesse impostazioni del Registro di sistema.

    Attenzione

    La modifica delle impostazioni del Registro di sistema nel servizio di SQL Server Agent di destinazione per gestire un processo ricreato potrebbe essere problematica se le impostazioni correnti sono richieste da 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.

  • SQL Server Agent proxy

    Un proxy SQL Server Agent definisce il contesto di sicurezza per un 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

È consigliabile iniziare eseguendo lo script di un processo semplice, ricreando il processo nell'altro servizio SQL Server Agent ed eseguendo 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.

[Top]

Logins

L'accesso a un'istanza di SQL Server richiede un account di accesso valido SQL Server. Questo account di accesso viene usato nel processo di autenticazione che verifica se l'entità può connettersi all'istanza di SQL Server. Un utente del database per il quale l'account di accesso SQL Server corrispondente non è definito o viene definito in modo errato in un'istanza del server non può accedere all'istanza. Questo utente viene definito utente orfano del database nell'istanza del server. Un utente del database può diventare orfano se dopo che un database viene ripristinato, collegato o copiato in un'istanza diversa 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à AlwaysOn (SQL Server)e gestione degli account di accesso e dei processi dopo il passaggio al ruolo (SQL Server).

[Top]

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 si dispone di account di accesso che usano SQL Server Autenticazione, è 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 sull'esecuzione di query su queste visualizzazioni del catalogo e sulla concessione delle autorizzazioni a oggetti di sistema, vedere GRANT System Object Permissions (Transact-SQL). Per altre informazioni, vedere REVOKE System Object Permissions (Transact-SQL) e DENY System Object Permissions (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_principalse per informazioni sull'appartenenza ai ruoli del server, eseguire una query nella vista del catalogo sys.server_role_members .

Per altre informazioni, vedere GRANT Server Permissions (Transact-SQL), REVOKE Server Permissions (Transact-SQL) e DENY Server Permissions (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 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 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.

[Top]

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 del database e replica (SQL Server) e log shipping e replica (SQL Server).

[Top]

Applicazioni di Service Broker

Molti aspetti di un'applicazione Service Broker spostano con il database. Tuttavia, alcuni aspetti dell'applicazione dovranno essere ricreati o riconfigurati nella nuova posizione.

[Top]

Procedure di avvio

Una stored procedure è una stored procedure contrassegnata per l'esecuzione automatica e viene eseguita ogni volta che viene avviata 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.

[Top]

Trigger (a livello del server)

I trigger DDL attivano stored procedure in risposta a vari eventi DDL (Data Definition Language). Questi eventi corrispondono principalmente alle 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.

[Top]

Vedere 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)