Scegliere un metodo di aggiornamento del motore di database

Sono disponibili diversi approcci da considerare quando si intende eseguire l'aggiornamento di Motore di databaseDatabase Engine da una versione precedente di SQL Server a SQL Server 2017SQL Server 2017 per ridurre al minimo i tempi di inattività e il rischio. È possibile eseguire un aggiornamento sul posto, la migrazione a una nuova installazione o un aggiornamento in sequenza. Il diagramma seguente consentirà di scegliere tra questi approcci. Ogni approccio del diagramma viene anche illustrato in basso. Per assistenza nei punti decisionali all'interno del diagramma, consultare anche Plan and Test the Database Engine Upgrade Plan.

Database Engine Upgrade Method Decision Tree

Scarica

  • Scaricare SQL Server 2016SQL Server 2016dalla pagina Evaluation Center.

  • Se si ha un account di Azure, fare clic qui per selezionare una macchina virtuale in cui è già installato SQL Server 2017SQL Server 2017 .

Nota

Nell'ambito del piano di aggiornamento, è anche possibile considerare l'aggiornamento del database SQL di Azure o la virtualizzazione dell'ambiente SQL Server. Questi approcci non rientrano nell'ambito di questo argomento, ma di seguito sono riportati alcuni collegamenti: Introduzione al cloud ibrido di SQL Server 2016, Introduzione a SQL Server in Macchine virtuali di Azure, Database SQL di Azure e Selecting a SQL Server option in Azure (Scelta di un'opzione di SQL Server in Azure).

Aggiornamento sul posto

Con questo approccio, il programma di installazione di SQL Server aggiorna l'installazione SQL ServerSQL Server esistente sostituendo i bit di SQL ServerSQL Server esistenti con i bit di SQL Server 2017SQL Server 2017 e quindi aggiorna tutti i database utente e di sistema. Il metodo di aggiornamento sul posto è più semplice, implica tempo di inattività, richiede più tempo per il fallback, se necessario, e non è supportato in tutti gli scenari. Per altre informazioni sugli scenari di aggiornamento sul posto supportati e non supportati, vedere Aggiornamenti di versione ed edizione supportati.

Questo approccio viene spesso usato negli scenari seguenti:

  • Un ambiente di sviluppo senza una configurazione a disponibilità elevata.

  • Un ambiente di produzione non mission-critical in grado di tollerare i tempi di inattività e in esecuzione su hardware e software recenti. La quantità di tempo di inattività dipende dalle dimensioni del database e dalla velocità del sottosistema di I/O. L'aggiornamento di SQL Server 2014 quando le tabelle con ottimizzazione per la memoria sono in uso comporta maggiore tempo. Per altre informazioni, vedere Plan and Test the Database Engine Upgrade Plan.

Avviso

Quando si esegue il programma di installazione di SQL Server 2017SQL Server 2017, l'istanza di SQL ServerSQL Server viene arrestata e riavviata quando si eseguono i controlli di pre-aggiornamento.

Attenzione

Quando si aggiorna SQL ServerSQL Server, l'istanza precedente di SQL ServerSQL Server viene sovrascritta e non sarà più disponibile nel computer. Prima dell'aggiornamento, eseguire il backup dei database di SQL ServerSQL Server e degli altri oggetti associati all'istanza precedente di SQL ServerSQL Server.

Il diagramma seguente illustra una panoramica generale dei passaggi necessari per un aggiornamento sul posto di Motore di databaseDatabase Engine.

Database Engine Upgrade Non-HA In-Place Upgrade

Per i passaggi dettagliati, vedere Eseguire l'aggiornamento a SQL Server 2016 usando l'Installazione guidata (programma di installazione).

Migrazione verso una nuova installazione

Con questo approccio è possibile mantenere l'ambiente corrente mentre si crea un nuovo ambiente SQL Server 2017SQL Server 2017 , spesso su hardware nuovo e con una nuova versione del sistema operativo. Dopo l'installazione di SQL Server 2017SQL Server 2017 nel nuovo ambiente, è necessario eseguire una procedura per preparare il nuovo ambiente alla migrazione dei database utente esistenti dall'ambiente esistente al nuovo ambiente, riducendo al minimo i tempi di inattività. Questa procedura comprende la migrazione degli elementi seguenti:

  • Oggetti di sistema: 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. Per informazioni dettagliate, vedere Gestire i metadati quando si rende disponibile un database in un'altra istanza del server (SQL Server)

  • Pacchetti di Integration Services archiviati in MSDB: se i pacchetti vengono archiviati nel database MSDB, è necessario inserire i pacchetti nello script usando dtutil Utility o ridistribuendoli sul nuovo server. Prima di usare i pacchetti nel nuovo server, è necessario aggiornarli a SQL Server 2017SQL Server 2017. Per altre informazioni, vedere Upgrade Integration Services Packages.

  • **Chiavi di crittografia di Reporting Services: **un aspetto importante della configurazione del server di report riguarda la creazione di una copia di backup della chiave simmetrica usata per crittografare le informazioni riservate. La copia di backup della chiave è obbligatoria per molte operazioni di routine e consente di riutilizzare un database del server di report esistente in una nuova installazione. Per altre informazioni, vedere Eseguire il backup e il ripristino delle chiavi di crittografia di Reporting Services ed Eseguire l'aggiornamento e la migrazione di Reporting Services

    Quando il nuovo SQL Server 2017SQL Server 2017 ambiente dispone degli stessi oggetti di sistema dell'ambiente esistente, procedere quindi alla migrazione dei database utente dal sistema esistente verso l'istanza di SQL Server 2017SQL Server 2017 in modo da ridurre al minimo i tempi di inattività del sistema esistente. Eseguire la migrazione del database tramite backup e ripristino oppure tramite un nuovo puntamento dei numeri di unità logica (LUN) se si dispone di un ambiente SAN. Nel diagramma seguente vengono descritte le procedure per entrambi i metodi.

Attenzione

La quantità di tempo di inattività dipende dalle dimensioni del database e dalla velocità del sottosistema di I/O. L'aggiornamento di SQL Server 2014 quando le tabelle con ottimizzazione per la memoria sono in uso comporta maggiore tempo. Per altre informazioni, vedere Plan and Test the Database Engine Upgrade Plan.

Dopo la migrazione dei database utente, puntare i nuovi utenti verso la nuova istanza di SQL ServerSQL Server usando uno dei diversi metodi, ad esempio rinominando il server, usando una voce DNS, modificando le stringhe di connessione. Il nuovo approccio di installazione riduce rischi e tempi di inattività rispetto all'aggiornamento sul posto e agevola gli aggiornamenti hardware e del sistema operativo in combinazione con l'aggiornamento a SQL Server 2017SQL Server 2017.

Nota

Se si ha già una soluzione a disponibilità elevata o altri numerosi ambienti dell'istanza di SQL ServerSQL Server, vedere Aggiornamenti in sequenza. Se non si ha una soluzione a disponibilità elevata, è possibile configurare temporaneamente il mirroring del databaseper ridurre maggiormente i tempi di inattività e semplificare l'aggiornamento oppure configurare un gruppo di disponibilità Always On come soluzione a disponibilità elevata permanente.

Ad esempio, è possibile usare questo approccio per aggiornare gli elementi seguenti:

  • Un'installazione di SQL ServerSQL Server su un sistema operativo non supportato.

  • Un'installazione x86 di SQL Server dal momento che SQL Server 2017SQL Server 2017 non supporta le installazioni x86.

  • SQL ServerSQL Server su un nuovo hardware e/o su una nuova versione del sistema operativo.

  • SQL ServerSQL Server in combinazione con il consolidamento dei server.

  • SQL Server 2005 come SQL Server 2017SQL Server 2017 non supporta l'aggiornamento sul posto di SQL Server 2005 a SQL Server 2017SQL Server 2017. Per altre informazioni, vedere Are you upgrading from SQL Server 2005?.

    I passaggi necessari per un nuovo aggiornamento di installazione variano leggermente a seconda che si usi l'archiviazione associata o l'archiviazione SAN.

  • Ambiente di archiviazione associata: se si dispone di un ambiente SQL ServerSQL Server che usa l'archiviazione associata, il diagramma seguente e i collegamenti all'interno del diagramma guidano nella procedura necessaria per un nuovo aggiornamento dell'installazione del Motore di databaseDatabase Engine.

    New installation upgrade method using backup and restore for attached storage

  • Ambiente di archiviazione SAN: se si dispone di un ambiente SQL ServerSQL Server che usa l'archiviazione SAN, il diagramma seguente e i collegamenti all'interno del diagramma guidano nella procedura necessaria per un nuovo aggiornamento dell'installazione del Motore di databaseDatabase Engine.

    New installation upgrade method using detach and attach for SAN storage

Aggiornamenti in sequenza

È necessario un aggiornamento in sequenza in ambienti di soluzioni SQL Server che includono più istanze di SQL ServerSQL Server da aggiornare in un determinato ordine al fine di ottimizzare i tempi di attività, ridurre i rischi e mantenere la funzionalità. Un aggiornamento in sequenza è essenzialmente l'aggiornamento di più istanze di SQL ServerSQL Server in un ordine specifico, ovvero l'aggiornamento sul posto in ogni istanza di SQL ServerSQL Server esistente o l'esecuzione di un nuovo aggiornamento dell'installazione per facilitare l'aggiornamento di hardware e/o sistema operativo come parte del progetto di aggiornamento. Esistono diversi scenari in cui è necessario usare il metodo di aggiornamento in sequenza. Questi scenari sono documentati negli argomenti seguenti:

Questo articolo è stato utile? Commenti e suggerimenti

Quali informazioni si stanno cercando? La ricerca ha restituito i risultati desiderati? Microsoft incoraggia gli utenti a inviare i propri commenti per migliorare i contenuti Inviare i commenti all'indirizzo sqlfeedback@microsoft.com

Vedere anche

Pianificare e testare il piano di aggiornamento del motore di database
Completare l'aggiornamento al motore di database