Condividi tramite

Scegliere un metodo di aggiornamento del motore di database

  • Articolo

Si applica a: SQL Server - solo Windows

Sono diversi gli approcci da valutare quando si intende eseguire l'aggiornamento del motore di database da una versione precedente di SQL Server 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 consente di scegliere tra questi approcci. Ogni approccio nel diagramma è illustrato anche nell'articolo. Per assistenza nei punti decisionali all'interno del diagramma, consultare anche pianificare e testare il Database Engine Upgrade Plan.

Diagramma che mostra un albero delle decisioni per il metodo di aggiornamento del motore di database.

Scarica

  • Per scaricare SQL Server, andare su Evaluation Center.

  • Si ha un account di Azure? Passare quindi ad Azure Marketplace per avviare una macchina virtuale con SQL Server Developer Edition già installato.

Opzioni di aggiornamento di Azure SQL

Nell'ambito del piano di aggiornamento, è anche possibile considerare l'aggiornamento del database SQL di Azure e dell'istanza gestita di SQL di Azure, o la virtualizzazione dell'ambiente SQL Server. Per ulteriori informazioni su tali opzioni, vedere i collegamenti seguenti:

Aggiornamento sul posto

Con questo approccio, il programma di installazione di SQL Server aggiorna l'installazione di SQL Server esistente sostituendo i bit di SQL Server esistenti con i bit nuovi di SQL Server 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 (12.x) quando le tabelle ottimizzate per la memoria sono in uso comporta maggiore tempo. Per altre informazioni, vedere pianificare e testare il Database Engine Upgrade Plan.

A livello generale, i passaggi necessari per un aggiornamento sul posto della motore di database sono i seguenti:

Diagramma che mostra un aggiornamento sul posto non a disponibilità elevata del motore di database.

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

Considerazioni

Il programma di installazione SQL Server arresta e riavvia l'istanza di SQL Server durante i controlli di pre-aggiornamento.

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

Migrazione verso una nuova installazione

Con questo approccio è possibile mantenere l'ambiente corrente mentre si crea un nuovo ambiente SQL Server, spesso su hardware nuovo e con una nuova versione del sistema operativo. Dopo l'installazione di SQL Server 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 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 del database utilizza trigger a livello di server, non è sufficiente collegare o ripristinare il database nel nuovo sistema. Il database non funziona 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 l'utilità dtutil o ridistribuendoli sul nuovo server. Prima di usare i pacchetti nel nuovo server, è necessario aggiornarli a SQL Server. 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 ambiente SQL Server 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 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. I passaggi per entrambi i metodi sono indicati nei diagrammi seguenti.

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 (12.x) quando le tabelle ottimizzate per la memoria sono in uso comporta maggiore tempo. Per altre informazioni, vedere pianificare e testare il Database Engine Upgrade Plan.

Dopo la migrazione dei database utente, i nuovi utenti vengono indirizzati verso la nuova istanza di SQL Server usando uno dei vari metodi possibili, ad esempio rinominando il server, usando una voce DNS e 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 con l'aggiornamento a SQL Server.

Nota

Se si ha già una soluzione a disponibilità elevata o altri numerosi ambienti dell'istanza di SQL Server, vedere Aggiornamenti in sequenza. Se non si ha una soluzione a disponibilità elevata, è possibile configurare temporaneamente il mirroring del database per 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 Server in un sistema operativo non supportato.
  • Un'installazione x86 (32-bit) di SQL Server, dal momento che SQL Server 2016 (13.x) e versioni successive non supportano le installazioni x86.
  • SQL Server in un nuovo hardware e/o in una nuova versione del sistema operativo.
  • SQL Server con il consolidamento dei server.
  • SQL Server 2005 (9.x), dal momento che SQL Server 2016 (13.x) e versioni successive non supportano l'aggiornamento sul posto di SQL Server 2005 (9.x). Per altre informazioni, vedere Si sta eseguendo l'aggiornamento da una versione precedente di SQL Server.

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 collegata: se si ha un ambiente SQL Server che usa l'archiviazione collegata, il diagramma seguente e i collegamenti all'interno del diagramma guideranno attraverso i passaggi necessari per un nuovo aggiornamento dell'installazione del motore di database.

    Diagramma che mostra un nuovo metodo di aggiornamento dell'installazione mediante backup e ripristino per l'archiviazione collegata.

  • Ambiente di archiviazione SAN: se si ha un ambiente SQL Server che usa l'archiviazione SAN, il diagramma seguente e i collegamenti all'interno del diagramma guideranno attraverso i passaggi necessari per un nuovo aggiornamento dell'installazione del motore di database.

    Diagramma che mostra un nuovo metodo di aggiornamento dell'installazione mediante collegamento e scollegamento per l'archiviazione SAN.

Aggiornamenti in sequenza

È necessario un aggiornamento in sequenza in ambienti di soluzioni SQL Server che includono più istanze di SQL 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 Server in un ordine specifico. Si esegue un aggiornamento sul posto in ogni istanza di SQL Server esistente oppure si esegue un nuovo aggiornamento dell'installazione per facilitare l'aggiornamento di hardware e/o sistema operativo come parte del progetto di aggiornamento. Esistono molti scenari in cui è necessario usare il metodo di aggiornamento in sequenza. Questi scenari sono documentati negli articoli seguenti: