0% found this document useful (0 votes)
15 views

Upgrade Tutorial SQL 2012

Uploaded by

khalandar463
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views

Upgrade Tutorial SQL 2012

Uploaded by

khalandar463
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

*MOST IMPORTANT*

Perform a test upgrade


Before you attempt to upgrade a production database server, try the upgrade in a lab environment.
Make a full backup of a domain controller, a DNS server, your SQL server, and any other required
infrastructure servers and then restore those backups to isolated lab servers. Once SQL is up and
running, try out your upgrade plan in the lab. That way, you can handle any issues that come up before
you have to perform a real upgrade.

1: Be aware of the supported upgrade paths


Before you begin planning an upgrade, you need to be aware of Microsoft's supported upgrade paths.
Please refer the below link:
http://technet.microsoft.com/en-us/library/ms143393.aspx

2: Run the Upgrade Advisor


The Upgrade Advisor, which is a free utility that is designed to assist you with your upgrade. The tool
analyzes your existing SQL Server deployment and informs you of issues that need to be addressed prior
to performing an upgrade.

3: Don't panic over Other Issues


The report generated by the SQL Server Upgrade Advisor often contains a section called Other Issues.
This section exists as a way of informing you of possible issues that may exist, but that the tool is
incapable of testing. Therefore, the issues that appear in the ‘Other Issues’ section may not necessarily
be present on your network.

4: Verify the hardware and software requirements


If you're considering an in-place upgrade (rather than a migration), it is critically important to verify that
your existing SQL Server meets all the hardware requirements for running SQL Server 2012 and that all
the necessary software prerequisites are in place. Check out this full list of the hardware and software
requirements.

5: Perform a full backup


Although it should go without saying, you should always perform a full server backup prior to
performing a upgrade. The upgrade process usually goes smoothly, but things can and sometimes do go
wrong. It's important to have a way to revert your SQL Server to its previous state if the upgrade does
not go as planned.

6: Don't forget to clean up when you're finished


When the upgrade is complete, run DBCC UPDATEUSAGE on all of your databases to ensure database
integrity. You will also need to reregister your servers and repopulate full text catalogs. If you have
disabled replication or disabled stored procedures for the upgrade, you will need to put things back to
normal.
Upgrade Options

There are two methods to upgrade from SQL Server 2008 to SQL Server 2012.

In-place Upgrade

Organizations that do not have resources available to host multiple database environments
commonly use an in-place upgrade. An in-place upgrade overwrites a previous installation of SQL
Server 2008 with an installation of SQL Server 2012. The reason it is called in-place upgrade is
because a target instance of SQL Server 2008 is actually replaced with a SQL Server 2012 instance.
We do not have to worry about coping data from the old instance to new instance as the old data
files are automatically converted to new format. This upgrade method is the easiest way to upgrade
the database to newer version. It's because the files are automatically upgraded without any manual
intervention. The number of instances and server involved in this type of upgrade is always one.
Before we perform an in-place upgrade, we must back up all SQL Server databases and other objects
associated with our previous SQL Server instances. In addition, we should be aware that the previous
version of SQL Server Books Online will remain intact on the machine after the upgrade.

In-place Upgrade Advantages:

 It's easier and faster, especially in small systems.


 It's mostly an automated process.
 The instance will be offline for a minimum amount of time.
 The resulting instance after upgrade will have the same name as the original, as the new setup will
replace the older version.
 No additional hardware is required in many cases.

o Disadvantages:

 It's very complex to rollback.


 Not applicable in scenarios where we want to upgrade a part of system like upgrading just one single
databases.
 We cannot run an upgrade comparison after doing the upgrade.

Side by Side Upgrade

Database environments that have additional server resources can perform a side-by-side migration of
their SQL Server 2008 or 2008R2 installations to SQL Server 2012. In this upgrade method, a new
instance is created on the same server or in a new server. In this upgrade method the old database
instance runs in parallel to the old legacy database. So as the old instance is untouched during this type
of upgrade, the old legacy database is still available and online for the application. Having the old
environment still active during the upgrade process allows for the continuous operation of the original
database environment while we can install and test the upgraded environment. Side-by-side migrations
can often minimize the amount of downtime for the SQL Server.
A side-by-side migration does not overwrite the SQL Server files on our current installation, nor does it
move the databases to new SQL Server 2012 installation. We/DBAs need to manually move databases to
the new SQL Server 2008 R2 installation and other supporting objects (Jobs, DTS/SSIS packages etc.)
after a side-by-side installation by using one of the upgrade methods discussed below.

o Detach/Attach – When disk storage and source database availability are not a consideration, one
common method of moving a database from one server to another is to detach and then attach the
database. This process requires that users not be accessing the database, but it has the safety
advantage that if an unforeseen problem arises, the DBA can always reattach a copy of the database
file to the original SQL Server instance. We can move a large database from one instance to another
on the same server, which requires less disk space than some other methods because it reduces the
number of database files that we must create for the upgrade process. However, this method can be
unsafe because it doesn't follow the recommendation of creating a copy of the database files.
o Backup/Restore – To avoid possible loss of the database files, making a database backup to use in
the upgrade is a secure alternative method for moving a database from one SQL Server instance to
another. This process does not interfere with the continuation of activity on the original database
environment, nor does it jeopardize the usefulness of the source database files to the original SQL
Server version.

Another advantage of using backup and restore is that the backup files are usually smaller than the
original database files because the backup process captures only database data, not reserved, unused
database space. The decrease in file size usually makes any file transfer faster than transferring the
original database file. However, we must take into account the disk space needed for the original
database files, the backup files, and the new database files during the upgrade.

 Copy Database Wizard – If we want to automate the task of moving a database from one server to
another during the upgrade process, we can use SQL Server's Copy Database Wizard. This direct copy
makes efficient use of disk space while preserving database uptime.
 Manual Schema Rebuild and Data Export/Import – A method not commonly used for database
upgrades is the manual method of scripting out the database, scripting the logins associated with
that database, scripting all objects associated with that database, and scripting out any other
supporting SQL Server objects associated with that database. After executing the script or scripts in
the new instance, then we must manually move the data from the original database to the new
database using Transact-SQL scripts, SQL Server Integration Services (SSIS), BCP, or other methods
available for moving data from one database to another.
Note: Make a copy of the files : It is a best practice to create a copy of the database file for recovery
purposes before attaching it to a new instance. After we attach a database file to SQL Server 2012,
we can no longer use that file in an earlier version of SQL Server.

Advantages:

 More control over the upgrade, as we can upgrade the components, which we want to.
 We can keep our application running even when we are installing SQL 2012 as the old instance or
server will be available.
 Easy to do a rollback as the original database server is untouched.

Disadvantages:
 We might need additional hardware resources in terms of disk space, CPU and RAM.
 Manual intervention is required to migrate databases, Jobs, logins etc.
 There will be change in configuration settings, which are used by the application to connect to the
database.
 More time is required while moving VLDB to the new version of database.

Also please the Upgrade Technical Reference Guide attached.

I hope you find the information and the documents helpful. Please get back to me for further assistance
or if you have any other query around this and I’ll be more than happy to assist you further.

You might also like