Delen via

Een upgrademethode voor database-engine kiezen

  • Artikel

van toepassing op:SQL Server- - alleen Windows

Er zijn verschillende benaderingen om rekening mee te houden wanneer u van plan bent om de database-engine bij te werken vanaf een eerdere versie van SQL Server, om downtime en risico's te minimaliseren. U kunt een in-place upgrade uitvoeren, migreren naar een nieuwe installatie of een rolling upgrade uitvoeren. In het volgende diagram kunt u kiezen tussen deze benaderingen. Elke benadering in het diagram wordt ook besproken in het artikel. Bekijk ook plan en test het upgradeplan voor de database-engineom u te helpen bij de beslissingspunten in het diagram.

diagram met een beslissingsstructuur van de database-engine-upgrademethode.

Downloaden

  • Als u SQL Server wilt downloaden, gaat u naar het Evaluation Center.

  • Hebt u een Azure-account? Ga vervolgens naar de Azure Marketplace- om een virtuele machine te maken waarop SQL Server Developer Edition al is geïnstalleerd.

Upgradeopties voor Azure SQL

U kunt ook overwegen om uw Azure SQL-database, azure SQL managed instance te upgraden of uw SQL Server-omgeving te virtualiseren als onderdeel van uw upgradeplan. Zie de volgende koppelingen voor meer informatie over deze opties:

In-place upgrade uitvoeren

Met deze methode werkt het INSTALLATIEprogramma van SQL Server de bestaande SQL Server-installatie bij door de bestaande SQL Server-bits te vervangen door de nieuwe SQL Server-bits en vervolgens worden alle systeem- en gebruikersdatabases bijgewerkt.

De in-place upgrade-benadering is het eenvoudigst, vereist enige downtime, duurt langer om terug te vallen als een terugval nodig is en wordt niet ondersteund voor alle scenario's. Zie Ondersteunde versie- en editie-upgradesvoor meer informatie over ondersteunde en niet-ondersteunde upgradescenario's.

Deze benadering wordt vaak gebruikt in de volgende scenario's:

  • Een ontwikkelomgeving zonder hoge beschikbaarheid (HA)-configuratie.

  • Een niet-bedrijfskritieke productieomgeving die downtime kan verdragen en die wordt uitgevoerd op een recente hardware en software. De hoeveelheid downtime is afhankelijk van de grootte van uw database en de snelheid van uw I/O-subsysteem. Het upgraden van SQL Server 2014 (12.x) wanneer voor geheugen geoptimaliseerde tabellen in gebruik zijn, duurt enige extra tijd. Zie Plan en test het upgradeplan voor de Database Enginevoor meer informatie.

Op hoog niveau zijn de stappen die nodig zijn voor een in-place upgrade van de database-engine als volgt:

diagram met een upgrade van een database-engine zonder hoge beschikbaarheid In-Place upgrade.

Zie SQL Server upgraden met behulp van de installatiewizard (Setup)voor gedetailleerde stappen.

Overwegingen

Het installatieprogramma van SQL Server stopt en start het SQL Server-exemplaar opnieuw op als onderdeel van de controles vóór de upgrade.

Wanneer u SQL Server bijwerken, wordt het vorige SQL Server-exemplaar overschreven en bestaat deze niet meer op uw computer. Maak voordat u een upgrade uitvoert een back-up van SQL Server-databases en andere objecten die zijn gekoppeld aan het vorige SQL Server-exemplaar.

Migreren naar een nieuwe installatie

Met deze aanpak onderhoudt u de huidige omgeving terwijl u een nieuwe SQL Server-omgeving bouwt, vaak op nieuwe hardware en met een nieuwe versie van het besturingssysteem. Nadat u SQL Server in de nieuwe omgeving hebt geïnstalleerd, voert u verschillende stappen uit om de nieuwe omgeving voor te bereiden, zodat u de bestaande gebruikersdatabases van de bestaande omgeving naar de nieuwe omgeving kunt migreren en downtime kunt minimaliseren. Deze stappen omvatten het migreren van het volgende:

  • Systeemobjecten: Sommige toepassingen zijn afhankelijk van informatie, entiteiten en/of objecten die buiten het bereik van één gebruikersdatabase vallen. Een toepassing heeft doorgaans afhankelijkheden van de master- en msdb-databases, en ook van de gebruikersdatabase. Alles wat buiten een gebruikersdatabase is opgeslagen dat vereist is voor de juiste werking van die database, moet beschikbaar worden gesteld op het doelserverexemplaar. De aanmeldingen voor een toepassing worden bijvoorbeeld opgeslagen als metagegevens in de master-database en moeten opnieuw worden gemaakt op de doelserver. Als een onderhoudsplan voor toepassingen of databases afhankelijk is van SQL Server Agent-taken waarvan de metagegevens zijn opgeslagen in de msdb-database, moet u deze taken opnieuw maken op het doelserverexemplaren. Op dezelfde manier worden de metagegevens voor een trigger op serverniveau opgeslagen in master.

    Wanneer u de database voor een toepassing naar een ander serverexemplaren verplaatst, moet u alle metagegevens van de afhankelijke entiteiten en objecten in master en msdb opnieuw maken op het doelserverexemplaren. Als een databasetoepassing bijvoorbeeld triggers op serverniveau gebruikt, is alleen het koppelen of herstellen van de database op het nieuwe systeem niet genoeg. De database werkt niet zoals verwacht, tenzij u de metagegevens voor deze triggers handmatig opnieuw maakt in de master-database. Zie voor gedetailleerde informatie Metagegevens beheren wanneer een database beschikbaar wordt gemaakt op een ander serverexemplaar (SQL Server).

  • Integration Services-pakketten die zijn opgeslagen in msdb: Als u pakketten opslaat in msdb, moet u deze pakketten scripten met behulp van de dtutil Utility of opnieuw implementeren op de nieuwe server. Voordat u de pakketten op de nieuwe server gebruikt, moet u de pakketten upgraden naar SQL Server. Zie Integration Services-pakketten upgradenvoor meer informatie.

  • Reporting Services-versleutelingssleutels: Een belangrijk onderdeel van de configuratie van de rapportserver is het maken van een back-up van de symmetrische sleutel die wordt gebruikt voor het versleutelen van gevoelige informatie. Voor veel routinebewerkingen is een back-up van de sleutel vereist en kunt u een bestaande rapportserverdatabase opnieuw gebruiken in een nieuwe installatie. Zie voor meer informatie Back-up maken en herstellen van Reporting Services-versleutelingssleutels en Reporting Services upgraden en migreren

Zodra de nieuwe SQL Server-omgeving dezelfde systeemobjecten heeft als de bestaande omgeving, migreert u de gebruikersdatabases van het bestaande systeem naar het SQL Server-exemplaar op een manier die de downtime op het bestaande systeem minimaliseert. U kunt de databasemigratie uitvoeren met behulp van back-up en herstel, of door LUN's opnieuw aan tewijzen als u zich in een SAN-omgeving bevindt. De stappen voor beide methoden worden aangegeven in de volgende diagrammen.

Voorzichtigheid

De hoeveelheid downtime is afhankelijk van de grootte van uw database en de snelheid van uw I/O-subsysteem. Het upgraden van SQL Server 2014 (12.x) wanneer voor geheugen geoptimaliseerde tabellen in gebruik zijn, duurt enige extra tijd. Voor meer informatie, zie Plan en Test het Upgradeplan voor de Database Engine.

Nadat u gebruikersdatabases hebt gemigreerd, wijst u nieuwe gebruikers naar het nieuwe SQL Server-exemplaar met behulp van een van de verschillende methoden (bijvoorbeeld het wijzigen van de naam van de server, het gebruik van een DNS-vermelding en het wijzigen van verbindingsreeksen). De nieuwe installatiebenadering vermindert risico's en downtime in vergelijking met een in-place upgrade en faciliteert hardware- en besturingssysteemupgrades met de upgrade naar SQL Server.

Notitie

Als u al een hoge beschikbaarheidsoplossing (HA) of een andere omgeving met meerdere SQL Serverinstance-omgevingen hebt, gaat u Rolling upgrade. Als u geen oplossing voor hoge beschikbaarheid hebt, kunt u overwegen om databasespiegelings- tijdelijk te configureren om downtime verder te minimaliseren om deze upgrade te vergemakkelijken of deze mogelijkheid te nemen om een AlwaysOn-beschikbaarheidsgroep te configureren als permanente ha-oplossing.

U kunt bijvoorbeeld deze methode gebruiken om een upgrade uit te voeren:

  • Een installatie van SQL Server op een niet-ondersteund besturingssysteem.
  • Een x86-installatie (32-bits) van SQL Server, omdat SQL Server 2016 (13.x) en latere versies geen ondersteuning bieden voor x86-installaties.
  • SQL Server naar nieuwe hardware en/of een nieuwe versie van het besturingssysteem.
  • SQL Server in combinatie met serverconsolidatie.
  • SQL Server 2005 (9.x), omdat SQL Server 2016 (13.x) en latere versies geen ondersteuning bieden voor de in-place upgrade van SQL Server 2005 (9.x). Zie Upgraden van een oudere versie van SQL Servervoor meer informatie.

De stappen die nodig zijn voor een nieuwe installatie-upgrade variëren enigszins, afhankelijk van of u gekoppelde opslag of SAN-opslag gebruikt.

  • Gekoppelde opslagomgeving: Als u een SQL Server-omgeving hebt met behulp van gekoppelde opslag, volgt het volgende diagram en de koppelingen in het diagram om u te begeleiden bij de stappen die nodig zijn voor een nieuwe installatie-upgrade van de Database Engine.

    diagram met een nieuwe installatie-upgrademethode met behulp van back-up en herstel voor gekoppelde opslag.

  • SAN-opslagomgeving: Als u een SQL Server-omgeving hebt met SAN-opslag, volgt het volgende diagram en de koppelingen in het diagram om u te begeleiden bij de stappen die nodig zijn voor een nieuwe installatie-upgrade van de database-engine.

    diagram met een nieuwe installatie-upgrademethode met behulp van loskoppelen en koppelen voor SAN-opslag.

Geleidelijke upgrade

Een rolling upgrade is vereist in sql Server-oplossingsomgevingen met meerdere SQL Server-exemplaren die in een bepaalde volgorde moeten worden bijgewerkt om de uptime te maximaliseren, risico's te minimaliseren en functionaliteit te behouden. Een rolling upgrade is in feite de upgrade van meerdere SQL Server-exemplaren in een bepaalde volgorde. U voert een in-place upgrade uit op elk bestaand SQL Server-exemplaar of een nieuwe installatie-upgrade om het upgraden van hardware en/of het besturingssysteem als onderdeel van het upgradeproject te vergemakkelijken. Er zijn verschillende scenario's waarin u de rolling upgrade-benadering moet gebruiken. Deze worden beschreven in de volgende artikelen: