Microsoft SQL Server 2000 High Availability

Upgrading an SQL Server version is something most DBAs have encountered or will encounter at some time in their careers. Whether you are upgrading the legacy Enterprise Resource Planning (ERP) system that was on SQL Server 6.5 and is finally being retired or migrating to a new SQL Server 2000 instance on new hardware because you outgrew capacity on your current server, you have to take into account the amount of downtime that will be caused and what effect it will have on your end users and the SLA.

Tip

Much of the information in an earlier section, Upgrading, Consolidating, and Migrating to SQL Server 2000, is applicable to any upgrade or migration process, including version upgrades for SQL Server. Use that in conjunction with the information in this section to help you plan your upgrades or migrations from another SQL Server version or instance to your target instance of SQL Server 2000.

Depending on which version you are starting from, you will have different options. Regardless of the version, you should have a dedicated testing environment as well as new hardware for the new SQL Server 2000 instances. When you are trying to upgrade on the same server, you increase your risk greatly for a few reasons. The most important reason is that should something go wrong, you might not only ruin the new environment, but also damage the old environment to the point that it can never be a fallback plan. Another reason is that while the upgrade is happening, you might not be able to use the server at all, whereas on different hardware, you might be able to keep things running while you are doing some, if not all, of the upgrade. From an availability perspective, that is crucial.

Another reason to keep the original hardware available is troubleshooting against the perceptions of the occasional change-fearing user . Consider a case in which you performed a flawless migration, only to have users complain about the performance of a particular task a few days, or even a week or two later. Keep in mind that this might be noise, as sometimes hearing that the system changed at all makes users think there actually will be a performance difference, causing perceived problems. Having the ability to run the query on the existing old system and prove that it is just as fast or even faster can save you much time and effort. It can also save your reputation and your performance review.

Depending on which version of SQL Server you are starting from, different native SQL-based tools are available to assist during an upgrade, consolidation, or migration effort. Other requirements also drive the decision process of what to use, such as the window of time that is open to perform the migration. Whatever tool you decide to use, realize that each has its strengths and weaknesses, and you might need to combine tools.

Warning

If you are using replication, it must be disabled or unconfigured prior to the upgrade. It would be necessary to have the replication configuration documented, as well as scripted, so that it can be set up after the upgrade. For more upgrade information with replication, see the topics Backing Up and Restoring Replication Databases, Scripting Replication, and Replication and Upgrading in SQL Server Books Online.

Caution

Do not assume your application running on a previous version of SQL Server will work or perform better than it did before the upgrade to SQL Server 2000. First, if it is from a third-party manufacturer, make sure the software is supported on SQL Server 2000. Second, make sure that syntax that is used by any application is still valid and that some variables or things like column names that you are using are not now reserved keywords in SQL Server 2000 (see Reserved Keywords in SQL Server Books Online under the topic Transact -SQL Reference) or are not being deprecated. The same goes for any applications, as Open Database Connectivity (ODBC) keywords are also listed.

More Info

For more information on upgrading your SQL Server version, some key topics in SQL Server Books Online you can reference (there are more that are not listed here) are Upgrading an Existing Installation of SQL Server, Upgrading from SQL Server 7.0 to SQL Server 2000, Preparing to Upgrade from SQL Server 6.5, and How to Upgrade from SQL Server 6.5.

Tools for Upgrading from SQL Server 6.5

The database formats of SQL Server 6.5 and SQL Server 2000 are incompatible, so it is not possible to use the backup and restore process to create the database on the target SQL Server 2000 instance, which can also jump start the process. You also cannot apply transaction logs of a SQL Server 6.5 database to a SQL Server 2000 database. There are a few options to consider when planning your upgrade or migration to SQL Server 2000:

Tools for Upgrading from SQL Server 7.0

If you are migrating from SQL Server 7.0 to SQL Server 2000, you have some different options than you would if you started with SQL Server 6.5.

Upgrading Between Different Versions of SQL Server 2000

The same options for SQL Server 7.0 are valid for SQL Server 2000 to SQL Server 2000 migrations, and because all databases are at the same version level (sans service pack differences), there is less work that needs to be done because the databases do not need to be upgraded. Concerns about collations and service packs are still valid, but you do not need to worry as much about things like behavior differences and syntax changes.

Upgrading from Previous Versions of SQL Server Clustering

If you are looking to upgrade from previous versions of SQL Server clustering to SQL Server 2000 failover clustering, or even from a stand-alone SQL Server to a failover cluster, this section will help you. The same rules for a standard upgrade apply (such as having to unconfigure replication), but there are other considerations to take into account:

Категории