Upgrade Tutorial SQL 2012
Upgrade Tutorial SQL 2012
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.
o Disadvantages:
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.
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.