© Copyright Microsoft Corporation, 2004. All rights reserved.
The SQL Server documentation team cannot answer technical support questions, but welcomes your suggestions and comments about this Readme documentation. You can quickly and directly send e-mail feedback using the link below. Please send your feedback in English.
To submit written feedback about this document, click here: Submit feedback.
1.0 Introduction
1.2 Before You Upgrade to Database Components SP4
1.3 Verify the Version of Microsoft Data Access Components
1.4 Identify the Current Version of SQL Server 2000
1.5 Additional Information About SP4
1.6 Updates to SQL Server 2000 Books Online Are Available
2.0 Where to Find and Download Database Components SP4
2.1 Choosing the Correct Language
2.2 Downloading Database Components SP4
2.3 Extracting the Database Components SP4 Files
2.4 Download and Extraction Phase Guidelines
2.5 Database Components SP4 Setup Documentation
3.1 Prepare for Database Components SP4 Installation
3.2 Install Database Components SP4
3.3 Restart Services and Applications
3.4 Install on a Failover Cluster
3.5 Install Database Components on Replicated Servers
3.6 Apply SP4 to Read-Only Databases or Filegroups in a Replication Topology
3.7 Upgrade the Catalog of Linked Servers
3.8 Uninstall Database Components SP4
3.9 Reapply Database Components SP4
4.0 Additional Installation Information
4.2 Redistributing SP4 Database Components
4.3 Systems Management Server Distributed Installation
5.3 SQL Server Agent and Shared Tools Enhancements
5.4 SQL Server Connectivity Component Enhancements
5.5 Meta Data Services Enhancements
5.6 Data Transformation Services Enhancements
5.7 XML Enhancements
5.8 Virtual Backup Device API Enhancements
5.9 Error Reporting
5.10 Serviceability Enhancements
5.11 English Query Enhancements
5.12 DB-Library and Embedded SQL for C
This Readme file describes how to use the Database Components part of Microsoft® SQL Server™ 2000 Service Pack 4 (SP4) to upgrade existing instances of the SQL Server 2000 database engine to SQL Server 2000 SP4.
The general process for installing SP4 is as follows:
SQL Server 2000 SP4 has four parts:
All SQL Server service packs are cumulative. SQL Server SP4 includes the fixes delivered in SP1, SP2, SP3, and SP3a.
Database Components SP4 can only be used on instances of the SQL Server 2000 database engine from Enterprise Edition, Standard Edition, Developer Edition, or Personal Edition. The other parts of SQL Server 2000 SP4 apply to the other SQL Server 2000 components, such as Analysis Services, MSDE 2000, or SQL Server 2000 (64-bit). Separate Readme files describe use of the Analysis Services SP4, MSDE 2000 SP4, and SQL Server 2000 SP4 (64-bit). The other Readme files are available at this Microsoft Web site.
This section describes changes to system requirements and system related issues that affect the installation of Database Engine SP4. General information on system requirements for SQL Server 2000 can be found at this Microsoft Web site.
A Database Components SP4 installation will fail if either of the following security policies has been set to Do not allow installation.
If you use the Do not allow installation setting, you must change it to Silently succeed before you install Database Components SP4. If necessary, you can return the policy to its previous setting after the installation is complete.
Note Do not allow installation is not the default setting for these security policies.
To set security policies
If your instance of SQL Server 2000 is being used by an application, before you upgrade to Database Components SP4 ask the provider of the application whether are any SQL Server 2000 upgrade considerations apply to that application.
This section describes issues that you must address and tasks you must perform before using Database Components SP4 to upgrade an existing instance of the database engine for SQL Server 2000.
Databases or database backups created on an instance of Database Components SP4 can be attached or restored on an earlier version of SQL Server 2000. However, there are restrictions for databases in a replication topology. For more information, see Section 1.2.2 Considerations for an Instance in a Replication or Log Shipping Topology.
The Database Components SP4 Setup program automatically detects which edition of SQL Server 2000 is present on the instance of SQL Server 2000 that is to be upgraded. Setup upgrades only the components that are installed for that instance. For example, if you apply the service pack to a computer on which SQL Server 2000 Standard Edition is running, the service pack does not attempt to upgrade components that are included only with SQL Server 2000 Enterprise Edition.
You can apply Database Components SP4 to a single default instance or a named instance of SQL Server. If you upgrade multiple instances of SQL Server 2000 to SP4, you must apply SP4 to each instance. When one instance on a computer with one or more instances of SQL Server 2000 is upgraded to SP4, all of the tools are upgraded to SP4. There are not separate copies of the tools for each instance.
If your instance of SQL Server 2000 is being used by an application, first check with the provider of the application whether there are any SQL Server 2000 upgrade considerations specific to that application.
Before you use Database Components SP4 to upgrade an existing instance of the database engine, it is advisable to plan how to return the instance to its previous state in case that becomes necessary later. When SQL Server 2000 Database Components SP4 is installed, it makes changes to the system tables for maintenance purposes. It also upgrades user and distribution databases that are members of a replication topology. Because of the nature of these changes, Database Components SP4 cannot be removed easily. To revert to the build that you were running before you installed Database Components SP4, you first must uninstall the instance of the SQL Server 2000 database engine and then reinstall that instance. Second, if you ran a previous SQL Server 2000 service pack or applied any hotfixes, you must reapply that service pack and any hotfixes to the instance.
Note To remove SP4, you must have backups of the master, model, and msdb databases that were taken immediately prior to applying SP4. For more information, see Section 3.1.1 Back Up Your SQL Server Databases.
For more information, see Section 3.8 Uninstalling SP4.
SQL Server 2000 SP4 Setup upgrades user databases that are members of a replication topology. This upgrade factor can affect backup-and-restore functionality for replicated user databases. Before you install SP4, ensure that replication databases and filegroups are writable. For more information about applying SP4 to databases that are included in replication topologies, see Section 3.5 Install Database Components on Replicated Servers. Additional backup and restore considerations for replication are detailed in section 5.2.6 Backup and Restore Issues for Merge Replication.
Note If an instance of SQL Server is not part of a replication topology, you can back up a user database and restore it on any other release of SQL Server 2000.
If SP4 Setup detects user databases or filegroups that are not writable, it does the following:
Setup has detected one or more databases and filegroups which are not writable.Note This message does not affect unattended installations of Database Components. For more information about unattended installations, see Section 4.1 Unattended Installations.
You can ignore this warning unless some of the databases listed in the Setup log are members of a replication topology. If any of the non-writable databases listed in the Setup log are members of a replication topology, you must make those databases writable and reapply SP4 Setup to that instance of SQL Server 2000.
For information about making a database writable, see Section 3.6 Apply SP4 to Read-Only Databases or Filegroups in a Replication Topology. For more information about reapplying SP4, see Section 3.9 Reapply Database Components SP4.
Because non-writable databases do not cause Setup to fail, you need not remove log shipping before upgrading to Database Components SP4. However, if the database is shipping logs to a database that is a replication publisher, you must do the following:
USE master
GO
EXEC sp_vpupgrade_replication
GOIf you apply SP4 without having taken offline all non-writable databases that ship logs to publication databases, you receive this error:
Error Running Script sp_vpupgrade_replication (1)
If you receive this error, follow the preceding procedure.
Note During installation, Setup makes no distinction between read-only databases and databases that are offline or in a suspect state. If a replication database or filegroup is offline or in a suspect state during setup and is involved in a replication topology, you must reapply the service pack after making the database writable.
Database Components SP4 setup determines whether to upgrade an installed version of Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1.
Note If a computer on which Database Components SP4 is later upgraded to a newer operating system platform, the version of MDAC installed by SP4 is no longer present.
Note See Knowledge Base article 301202 for instructions on determining the version of MDAC on your computer.
When Database Components SP4 installs MDAC 2.8 SP1, the MDAC language version is the same as the language version of Database Components SP4. If you want to maintain a language version of MDAC that is different from that of Database Components SP4, you must download and install the intended language version of MDAC 2.8 SP1 before you run Database Components SP4 Setup. You can download language-specific versions of MDAC 2.8 SP1 from this Microsoft Web site.
MDAC 2.8 SP1 includes an upgrade to MSXML 3.0 SP7. MDAC 2.81 also updates SQLXML 1.0, which shipped with Microsoft SQL Server 2000. This service pack does not install or update SQLXML 3.0. If your application requires SQLXML 3.0, you must download and install it from this Microsoft Web site. For more information about MDAC 2.8 SP1, see this Microsoft Web site. For more information about MDAC versions, see Knowledge Base article 822758. Fixes included in MDAC 2.8 SP1 are documented in Knowledge Base article 884930.
Note Prerelease versions of SQL Server 2000 SP4 installed a prerelease version of MSXML 3.0 SP7. If you installed a prerelease version of SQL Server 2000 SP4, it is recommended that you download and install the final release version of MSXML 3.0 SP7 from this Microsoft Web site.
Before running Setup, you must identify the version of the Database Components instance that is being upgraded.
To identify the installed version of SQL Server 2000 Database Components
SELECT SERVERPROPERTY('ProductLevel')SELECT @@VERSION SELECT SERVERPROPERTY('ProductVersion')| SQL Server 2000 Version and Level | @@VERSION | Product Level |
| SQL Server 2000 Original Release | 8.00.194 | RTM |
| Database Components SP1 | 8.00.384 | SP1 |
| Database Components SP2 | 8.00.534 | SP2 |
| Database Components SP3, SP3a or MSDE 2000 Release A. | 8.00.760 | SP3 |
| Database Components SP4 | 8.00.2039 | SP4 |
Note Your product version may be different than these values if you applied a hotfix after installing the product or after installing a previous service pack. For example, @@VERSION returns a value of 8.00.818 after you apply the security fix MS03-031 to SQL Server 2000 SP3a.
SELECT SERVERPROPERTY('Edition')If this query returns "desktop engine," you are running an instance of MSDE 2000; otherwise, you are running an instance of SQL Server 2000 database engine.
A list of the fixes contained in this service pack will be provided in Microsoft Knowledge Base article 888799. Each fix listed in 888799 has a link to a Knowledge Base article about the problem that the fix addresses. Follow the links to the individual Knowledge Base articles to see information about each fix.
Any information relevant to SQL Server 2000 Service Pack 4 that was not available in time to be included in this Readme file will be published in Microsoft Knowledge Base article 884525.
The Knowledge Base articles mentioned in this Readme are available in the Microsoft Support Knowledge Base.
To find an article in the Knowledge Base
All publicly issued SQL Server 2000 SP3a and SQL Server 2000 (64-bit) security bulletins have been addressed in SP4.
If you received a SQL Server 2000 hotfix after December 2, 2004, that hotfix is unlikely to be included in SP4. Contact your primary support provider about obtaining the same hotfix for SQL Server 2000 SP4.
SQL Server 2000 SP4 includes serviceability enhancements that enable you to uninstall future hotfixes. For more information, see Section 5.10 Serviceability Enhancements.
Microsoft SQL Server 2000 (SP4 incorporates changes to the SQL Server 2000 components that address issues raised by the Slammer worm:
Users of Microsoft SQL Server 2000 Windows® CE Edition (SQL Server CE) and SQL Server 2005 Mobile Edition (SQL Mobile) who have upgraded or plan to upgrade SQL Server 2000 database and publisher servers to SP4 should also update the server replication components on Microsoft Internet Information Services (IIS) servers. Updated server tools installers are available for SQL Server CE and for SQL Mobile.
Note Even if you updated your server replication components after you upgraded to SQL Server 2000 SP3 or SP3a, you must install the latest SP4-specific updates to server tools components.
SQL Server 2000 SP4 removes the OPENXML dependency on the version of MSXML installed by the operating system. Database Components SP4 installs an internal version of the MSXML technology that is backward compatible with MSXML 2.6.
SQL Server 2000 Books Online is the primary user documentation set for Database Components 2000. Books Online is periodically updated with fixes and new information.
Samples for the SQL Server 2000 database engine and Analysis Services that were updated for SP3 and SP3a are available. You can download these updated samples from this Microsoft Web site.
SQL Server 2000 SP4 is distributed in the following ways:
If you have an SP4 CD, you can upgrade an instance of SQL Server 2000 to SP4 by using the Database Components SP4 files directly from the CD.
Note LLL represents a designator that varies by language.
If you do not have an SP4 CD, you can download SQL2000-KB884525-SP4-x86-LLL.exe and then run it to extract the Database Components SP4 files onto your computer. SQL2000-KB884525-SP4-x86-LLL.exe creates a set of folders and files on your disk that have the same organization as the Database Components folders and files on the SP4 CD. After this file extraction phase is complete, you can install Database Components SP4 from the folders on your disk.
SQL Server 2000 Database Components service packs are language-specific. To upgrade an instance of SQL Server 2000, you must obtain the service pack that has the same language as your instance. You get the service pack either on a SQL Server 2000 SP4 CD or by downloading the Database Components SP4 files. For example, if you upgrade an instance of SQL Server 2000 that uses Japanese, you must get the Japanese version of Database Components SP4.
If you are unsure of the language of an instance of SQL Server 2000:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\CurrentVersion
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\InstanceName\CurrentVersion
where InstanceName is the name of the instance.
| Language Registry Value (in Hexadecimal) | Language Registry Value (in Decimal) | Language of That Instance |
| 0x00000404 | 1028 | Traditional Chinese |
| 0x00000407 | 1031 | German |
| 0x00000409 | 1033 | English |
| 0x0000040a | 1034 | Spanish |
| 0x0000040c | 1036 | French |
| 0x00000410 | 1040 | Italian |
| 0x00000411 | 1041 | Japanese |
| 0x00000412 | 1042 | Korean |
| 0x00000804 | 2052 | Simplified Chinese |
To download the self-extracting installation package for Database Components SP4:
After you download the self-extracting file that contains the installation package, you must extract the Database Components SP4 files:
When you download and extract Database Components SP4 installation files from the Internet, use the following guidelines:
Note When you extract the service pack to a network shared directory, the path to the folder that you specify is relative to the folder from which you ran SQL2000-KB884525-SP4-x86-LLL.exe.
Database Components SP4 installation files contain updated setup documentation that you can access by clicking Help during Database Components SP4 setup. This setup documentation does not update the version of SQL Server 2000 Books Online that is already installed on your computer. For information about how to get an updated version of SQL Server 2000 Books Online, see Section 1.6 Updates to SQL Server 2000 Books Online Are Available. If you want to access just the updated SQL Server 2000 SP4 setup documentation without updating SQL Server 2000 Books Online, run the Setupsql.chm file. Setupsql.chm is located in the \Books subfolder of the folder on the SP4 CD-ROM, the local folder, or the network share that contains the extracted service pack files.
To install Database Components SP4, use the installation instructions in the following sections. Review the material in Section 1.0 Introduction before you install Database Components SP4. The steps to install Database Components SP4 are as follows:
You must do the following before you install Database Components SP4:
Before installing Database Components SP4, back up the master, msdb, and model databases. Installation of SP4 modifies the master, msdb, and model databases, making them incompatible with pre-SP4 versions of SQL Server. Backups of these databases are required if you decide to reinstall SQL Server 2000 without SP4.
It is also prudent to back up your user databases, although SP4 updates only those user databases that are members of replication topologies.
An existing backup scheme that accounts for replication allows you to restore a database to a known point after the SP4 upgrade in case of a failure. After applying SP4, a log or full database backup is recommended for any user database that is included in a replication topology. This way, if a replication database fails, you do not have to reapply SP4 after the database is restored.
If the autogrow option is not selected for the master and msdb databases, the databases must have at least 500 kilobytes (KB) of free space. To verify that they have this space, run the sp_spaceused system stored procedure for the master or msdb database. If the unallocated space in either database is less than 500 KB, increase the size of the database. For more information, see "Expanding a Database" in SQL Server 2000 Books Online.
If the autogrow option is selected for the master and msdb databases, and there is sufficient room on the drives, you can skip the preceding space-verification step.
To verify that the autogrow option is selected in SQL Server 2000, open SQL Server Enterprise Manager, right-click the icon for the database, and then click Properties. Verify that the Automatically grow file check box is selected.
You should stop all applications and services, including Control Panel, Add and Remove Programs, SQL Server 2000 Reporting Services, SQL Server 2000 Notification Services, and all applications that make connections to the instance of the database engine being upgraded, before installing Database Engine SP4.
You can apply Database Components SP4 without first shutting down services, but then some services will not start again unless you restart the system. If you do not shut down services, you are prompted to restart the computer when Setup is complete. If you do not restart the system, the following services may fail to start:
You can reduce the likelihood that you will need to restart your computer after you install Database Components SP4. To reduce this likelihood, stop the services and applications in the preceding list before you run Setup.
You cannot stop the services in a clustered environment. For more information, see Section 3.4 Install on a Failover Cluster.
The following information applies only to the Database Components part of SQL Server 2000.
Run the Setup.bat script from one of the following locations:
Note In order to install database components from a network share, you must first do one of the following:
Setup displays a dialog box that prompts you for information, such as whether you want to use SQL Server Authentication or Windows Authentication. If you choose SQL Server Authentication, you must supply the Setup program with the password for the sa login. If you choose Windows Authentication, you must run the Setup program while logged on to Windows with a Windows login account that is a member of the sysadmin fixed server role for the instance of SQL Server 2000 you are upgrading.
The Setup program then performs the following tasks:
Note This password change is made immediately; even if Setup fails, the password is nonetheless changed.
Note The previous steps are necessary only when you apply SP4 to non-writable databases or filegroups that are part of a replication topology. For more information, see Section 3.6 Apply SP4 to Read-Only Databases or Filegroups in a Replication Topology.
The Authentication Mode dialog box does not select the current settings by default for the installation. The dialog box default setting is Windows Authentication. Use the dialog box to switch Windows Authentication or Mixed Mode Authentication by means of an sa login password that is not blank.
Note Before you change the authentication mode or the password for the sa login, make sure that this change does not affect existing applications. For example, if you change an instance of SQL Server from selection for Mixed Mode Authentication to only Windows Authentication, existing applications that attempt to connect by using SQL Server Authentication cannot connect until the authentication mode is set to Windows Authentication. Also, if you change the sa login password, applications or administrative processes that use the old password cannot connect until they are configured to use the new password.
Important For security reasons, you should never have a blank password on the sa login.
The Setup program places a record of the actions it performs in the Sqlsp.log file. This log file is stored in the Windows folder of the computer on which Setup is run. If you upgrade multiple instances, only the most recent upgrade is recorded in this log.
The Backward Compatibility Checklist dialog box lists issues that you may encounter when you apply the service pack to versions of SQL Server earlier than SP3. The compatibility issues that appear in the checklist vary depending on the configuration of the instance of SQL Server 2000 that is being upgraded.
The following backward compatibility issues may be addressed in this dialog box:
Security Note Enabling cross-database ownership chaining for all databases is not recommended.
When Setup completes, it may prompt you to restart the system. Section 3.1.3 Stop Services and Applications Before You Run Database Components SP4 Setup provides guidelines on when a restart is required. After the system restarts (or after Setup completes without requesting a restart), use the Services application in Control Panel to make sure that any services you stopped before you applied the service pack are now running. Services you might have stopped before you applied the service pack include DTC and the Microsoft Search, MSSQLServer, MSSQLServerOLAPService, and SQLServerAgent services or their instance-specific equivalents.
Restart the applications you closed before running the service pack Setup program.
Also, it is advisable to back up the upgraded master and msdb databases at this time.
The following information applies only to SQL Server 2000 components that are part of a failover cluster.
To install the service pack on a failover cluster
Note When a clustered resource is taken offline, all dependent resources are also taken offline by the cluster service.
Note Setup might require restarting of the failover cluster nodes. This restart replaces the files that were in use during setup with the updated files.
If you are upgrading a default (non-clustered) instance of SQL Server to a virtual server, you must upgrade the default (non-clustered) instance to a virtual instance, and then apply SP4. For more information about upgrading, see "How to upgrade from a default instance to a default clustered instance of SQL Server 2000 (Setup)" in SQL Server 2000 Books Online.
For additional information about how to install SP4 on a failover cluster, see Knowledge Base article 811168.
If you need to rebuild a node in the failover cluster
Note If you run Setup from the node where the virtual server is running, you must reapply SP4 to all the nodes. You must also run the database upgrade scripts again.
The following information applies only to existing instances of SQL Server 2000 that are part of a replication topology:
Note In many cases, especially in merge replication, the Distributor and Publisher are on the same server and are upgraded at the same time.
You might need to quiesce the system (stop all updates) and upgrade all servers simultaneously in the following cases.
The following table includes servers that both publish and subscribe to publications that allow updates at the Subscriber. As noted earlier, you must follow the upgrade order Distributor, Publisher, Subscriber for topologies that allow updates at the Subscriber. This order requires that you upgrade Server A first for the merge publication and Server B first for the transactional publication with updating Subscribers. In this case, you must quiesce the system and upgrade the servers simultaneously.
| Server A | Server B |
|---|---|
| Publisher/Distributor for merge replication | Subscriber for merge replication |
| Subscriber for transactional replication with updating | Publisher/Distributor for transactional replication with updating |
In this example, you can upgrade Server A first because the read-only transactional publication allows a Subscriber to be upgraded before the Publisher/Distributor.
| Server A | Server B |
|---|---|
| Publisher/Distributor for merge replication | Subscriber for merge replication |
| Subscriber for read-only transactional replication | Publisher/Distributor for read-only transactional replication |
The following information applies only to SQL Server 2000 components that are part of a replication topology.
When non-writable databases or filegroups exist, Setup displays the following message:
Setup has detected one or more databases and filegroups which are not writable.In general, you can ignore this warning and setup will continue. However, if any of the non-writable databases listed in the Setup log are members of a replication topology, you must make those databases writable and reapply SP4 Setup to that instance of SQL Server 2000.
Note This message does not affect unattended installations. For more information about unattended installations, see Section 4.1 Unattended Installations.
During installation, Setup makes no distinction between non-writable databases and databases that are offline or in a suspect state. If a database or filegroup in a replication topology is non-writable during setup, you must reapply the service pack to upgrade this database. For more information about how to bring a database online, see the topic "Attaching and Detaching a Database" in SQL Server 2000 Books Online. For more information about diagnosing suspect databases, see the topic "Server and Database Troubleshooting" in SQL Server Books Online.
To apply Database Components SP4 to a read-only database
ALTER DATABASE statement, as follows:
ALTER DATABASE database SET READ_WRITEALTER DATABASE, as follows:
ALTER DATABASE database SET READ_ONLYTo apply SP4 to a read-only filegroup
ALTER DATABASE, as follows:
ALTER DATABASE Database
MODIFY FILEGROUP filegroup_name READWRITE ALTER DATABASE, as follows:
ALTER DATABASE Database
MODIFY FILEGROUP filegroup_name READONLYFor more information about ALTER DATABASE, see the "ALTER DATABASE" reference topic in SQL Server 2000 Books Online. For more information about reapplying SP4, see Section 3.9 Reapply Database Components SP4.
When you upgrade an instance of the SQL Server 2000 database engine to Database Components SP4, you might need to ensure that some of the system stored procedures are updated in other instances of SQL Server or MSDE.
Database Components SP4 includes an upgrade of the Microsoft Data Access Components (MDAC) to MDAC version 2.8 SP1. MDAC 2.8 SP1 includes updates to the SQLOLEDB provider and the SQL Server ODBC driver. For more information, see Section 1.3 Verify the Version of Microsoft Data Access Components. When either the provider or driver connects to an instance of SQL Server or MSDE, the provider or driver uses a set of system stored procedures known as the catalog stored procedures. The versions of the catalog stored procedures on the instance must be the same version or later than the versions that the provider and driver use. If you attempt to connect to an instance of SQL Server or MSDE that have earlier versions of the catalog stored procedures you will receive the following error:
The ODBC catalog stored procedures installed on server <ServerName>
are version <OldVersionNumber>; version <NewVersionNumber> or later
is required to ensure proper operation. Please contact your system
administrator.
Each version of the provider and driver is shipped with a script named Instcat.sql. Instcat.upgrades the catalog stored procedures in any instance of SQL Server or MSDE that has an earlier version of the catalog.
After installing Database Components SP4, you must run the Instcat.sql script from Database Components SP4 against any instance of SQL Server or MSDE that is an earlier version than SQL Server 2000 SP4 and has the following characteristics:
To upgrade the catalog stored procedures on an instance using Windows Authentication Mode:
osql -E -SComputerName -ilocation\instcat.sqlosql -E -SComputerName\InstanceName -ilocation\instcat.sqlTo upgrade the catalog stored procedures on an instance using Mixed Mode:
osql -UAnAdminLogin -PAdminPassword -SComputerName
-ilocation\instcat.sqlosql -UAnAdminLogin -PAdminPassword
-SComputerName\InstanceName -ilocation\instcat.sqlwhere:
The Instcat.sql script generates many messages. Typically the messages do not indicate any errors; they just inform you how many rows were affected by each Transact-SQL statement in the script. The last message should indicate whether the script ran successfully.
To remove Database Components SP4, follow the steps in this section.
Note MDAC updates are not uninstalled. For more information, see Section 1.3 Verify the Version of Microsoft Data Access Components.
To be able to return to pre-SP4 versions of SQL Server 2000 components, you must back up the master, msdb, and model databases before you install SP4. For more information, see Section 3.1.1 Back Up Your SQL Server Databases.
If any of the databases are involved in replication, you must disable publishing.
To disable publishing:
To revert to a pre-SP4 version of SQL Server
Warning When you revert to the pre-SP4 version of SQL Server 2000, all changes made to the databases master, msdb, and model since applying SP4 are lost.
The following information applies to all components.
In the following cases, you must reapply SP4:
To reapply SP4, follow the steps in Section 3.0 Service Pack Installation.
This section documents additional service pack installation considerations that apply only in special cases.
Database Components SP4 no longer includes pre-defined setup initialization (.iss) files. However, each time you run an attended installation of Database Components SP4, the setup options are written to the setup.iss file, which is located in the system folder. This .iss file can be used later to run an unattended installation of Database Components SP4. For more information about performing unattended installations, see the topic "Performing an Unattended Installation" in SQL Server 2000 Books Online.
The following considerations relate to unattended installations:
start /wait setupsql.exe -s -sms -f1 C:\Windows\setup.iss -sapwd password Security Note When possible, supply security credentials at run time. If you store credentials in a script file, you must secure the file to prevent unauthorized access.
Security Note The use of blank passwords is strongly discouraged because blank passwords add a significant vulnerability to security breaches.
| Unattended setup switch | Description |
|---|---|
| UpgradeMSSearch | This switch is required to address the required rebuild of full-text catalogs. If Full Text Search is enabled, you must set this switch to 1. For more information, see Section 5.1.4 Full-Text Catalogs are Rebuilt After Setup Completes. |
| MSXTSXUpgraded | This switch is required to address the issue of upgrading master/target server configurations. If you are applying SP4 to a master or target server, you must set this switch to 1. For more information, see Section 5.3.2 Changes to Master/Target Server Configurations. |
| EnableCrossDBChaining | (Optional) This switch is used to enable cross-database ownership chaining. To enable cross-database ownership chaining, set this switch to 1. For more information, see Section 5.1.10 Cross-Database Ownership Chaining. |
| EnableErrorReporting | (Optional) This switch is used to enable Error Reporting. To enable error reporting, set this switch to 1. For more information, see Section 5.9 Error Reporting. |
Database Components SP4 includes the self-extracting file Sqlredis.exe. When Sqlredis.exe runs, it:
You can redistribute the Sqlredis.exe file under the terms and conditions noted in the Redist.txt file that accompanies SP4.
You cannot install Database Components SP4 from a remote location. However, you can use Microsoft Systems Management Server to install SP4 automatically on multiple computers that are running on Windows Server 2003, Windows XP, or Windows 2000. To do so, you must use a package definition file (Smssql2ksp4.pdf) that automates the creation of a SQL Server package in Systems Management Server. The SQL Server package can then be distributed and installed on computers that are running Systems Management Server. Sms2kdef.bat is a batch file that starts an unattended setup by using Systems Management Server. In this type of installation, the Setup program automatically detects relevant system information that it needs. No user input is required.
This section covers issues that can occur after applying Database Components SP4 and new features that are available when you run SP4. These issues apply when running the service pack to upgrade from any earlier version of SQL Server 2000. This section does not describe all of the fixes provided in SP4. For a complete list of these fixes, see Microsoft Knowledge Base article 888799.
Any information relevant to SQL Server 2000 Service Pack 4 that was not available in time to be included in this Readme file will be published in Microsoft Knowledge Base article 884525.
The following enhancements apply to instances of SQL Server 2000 on which Database Components SP4 is installed.
Introduced in SP1
Hash teams have been removed. Because of certain enhancements to SQL Server 2000, hash teams no longer produce the performance benefits they offered in SQL Server 7.0. In addition, removing hash teams makes SQL Server 2000 more stable.
Therefore, the query optimizer no longer generates query plans using hash teams.
In rare cases, the removal of hash teams can cause a query to be processed more slowly. Analyze such queries to see whether creating more suitable indexes will return query performance to its previous level.
Introduced in SP1
Two affinity mask switches have been added to this service pack.
With this service pack, you can specify which CPUs are used to run threads for disk I/O operations. This switch must be used in conjunction with the affinity mask option. For more information, see article 298402.
With this service pack, you can configure systems that are enabled for Virtual Interface Architecture (VIA) to bind the SQL Server connections from certain network cards to a processor or a set of processors. This switch must be used in conjunction with the affinity mask option. For more information, see article 299641.
Introduced in SP2
If you have encountered SQL Server 2000 bug 355069 as documented in Microsoft Knowledge Base Article 306467, this service pack will only prevent future occurrences of unexpected results because of data modifications. In addition to applying this fix, all indexes that are based on views with filter conditions must be re-created.
Introduced in SP3
All full-text catalogs are rebuilt as part of the installation of SP4 when upgrading from SP2 or earlier. The rebuild is automatic and resource-intensive. Queries against full-text catalogs may return partial results or no results until the rebuild process is complete. After SP4 is installed, the system event logs contain messages stating that the catalogs were corrupt, of an older version, and had to be rebuilt.
For information , see the Knowledge Base article 327217, which also discusses possible workarounds for keeping full-text search available during the rebuild process and to avoid an automatic rebuild.
Introduced in SP3
When you run sp_change_users_login with the @Action=Auto_Fix argument, you must now specify a password. sp_change_users_login assigns the password to any new login it creates for the user. The following example shows the new @Password argument:
sp_change_users_login [ @Action = ] 'action'
[ , [ @UserNamePattern = ] 'user' ]
[ , [ @LoginName = ] 'login' ]
[ , [ @Password = ] 'password' ]Use the @Password argument only with @Action=Auto_Fix. The following example shows the new syntax for the sp_change_users_login command when using Auto_Fix. Other examples in SQL Server Books Online remain unchanged.
USE pubs
go
EXEC sp_change_users_login 'Auto_Fix', 'Mary', NULL, 'B3r12-36'
GoIntroduced in SP3
If the DisallowAdhocAccess registry option is not explicitly set, by default, ad hoc access to OLE DB providers is not allowed. This means ad hoc query syntax, such as OPENDATASOURCE and OPENROWSET, will not work against remote servers. To allow ad hoc access, you must explicitly set the DisallowAdhocAccess option to 0.
Introduced in SP3
To enable more efficient processing of remote queries that include LIKE predicates, the SqlServerLike option was added in SP3. SQL Server 2000 SP3 or later now has two options for sending LIKE operations to linked servers. If the OLE DB provider for a linked server supports the SQL Server syntax for the LIKE operator and wildcards, you can specify the SqlServerLIKE option to have SQL Server send LIKE operations using SQL Server syntax. If the OLE DB provider for a linked server reports that it supports the Entry Level ANSI/ISO SQL-92 syntax or returns the SQLPROP_ANSILIKE property, SQL Server will send LIKE operations to the linked server using SQL-92 syntax. For more information on SQLPROP_ANSILIKE, see the topic "Programming the SQLPROPSET_OPTHINTS Property Set" in SQL Server 2000 Books Online.
You must add a registry key value to enable the SqlServerLIKE option for an OLE DB provider.
Security Note Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from editing the registry incorrectly can be resolved. Before editing the registry, back up any valuable data.
HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\<Instance Name>\Providers\<Provider Name>
HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer\Providers\<Provider Name>
Introduced in SP3
For distributed queries, SQL Server returns provider error information in addition to server error information. When a query between linked servers results in an error, SQL Server checks to see if the provider supports the IErrorRecords OLE DB interface. If this interface is supported, SQL Server calls the GetErrorInfo function to get additional error information from the provider and returns this information to the user as part of the error message. If the IErrorRecords interface is not supported, there is no change in SQL Server behavior: SQL Server returns a generic error.
For example, run the following query against a server that uses MSDASQL, which does not support sql_variant:
SELECT * FROM remote2k.dqtable.dbo.sqlvariantnotnull
--Remote2k is a loopback server.Prior to SP3, SQL Server returned the following error message:
Server: Msg 7356, Level 16, State 1, Line 1
OLE DB provider 'msdasql' supplied inconsistent metadata for a column.
Metadata information was changed at execution time.
After you apply SP3 or later, SQL Server returns the following error message:
Server: Msg 7356, Level 16, State 1, Line 1
OLE DB provider 'msdasql' supplied inconsistent metadata for a column.
Metadata information was changed at execution time.
OLE DB error trace [Non-interface error: Column 'sql_variant' (compile-time
ordinal 3) of object '"dqtable"."dbo"."sqlvariantnotnull"' was reported
to have a DBCOLUMNFLAGS_ISFIXEDLENGTH of 16 at compile time and 0 at run time].
Introduced in SP3
SP3 and later includes the new function fn_get_sql that returns the text of the SQL statement for the specified SQL handle. In addition, to support this function, three new columns have been added to the sysprocesses system table: sql_handle, stmt_start, and stmt_end.
fn_get_sql is documented in the latest copy of the SQL Server 2000 Books Online. For information about installing the latest version of the SQL Server 2000 Books Online, see section 1.6 Updates to SQL Server 2000 Books Online Are Available. This is an English-language copy of the reference topic for fn_get_sql.
Introduced in SP3
This service pack provides new options for turning cross-database ownership chaining on and off.
When installing Database Components SP4, the Setup Backward Compatibility Checklist dialog displays an option for configuring cross-database ownership chaining. By default, Setup turns off cross-database ownership chaining for all user databases. You can enable cross-database ownership chaining for all databases. For more information, see Backward Compatibility Checklist dialog box
Note Enabling cross-database ownership chaining for all databases is not recommended.
After installation, you can use the following methods to turn cross-database ownership chaining on and off for all databases in the instance:
If cross-database ownership chaining is turned off for the instance, you can configure it for individual databases. Use the following methods to turn cross-database ownership chaining on and off for a database:
For more information, click the Help button on the Backwards Compatibility Checklist page when you run Setup, download the updated edition of SQL Server 2000 Books Online, or see Knowledge Base article 810474.
Introduced in SP3
Trace flag 1204 returns the type of locks participating in the deadlock and the current command affected. In SP3 and later, when this trace flag is on, the deadlock information is automatically written to the error log.
Introduced in SP3
Only members of the sysadmin fixed server role can run the sp_changedbowner system stored procedure.
Introduced in SP3
The functionality for debugging stored procedures with Microsoft Visual Studio® 6.0 and older or with SQL Server Query Analyzer prior to SP3 is turned off by default. Application debugging (stopping at a SQL Server Transact-SQL breakpoint while debugging a client application) is also turned off by default. To enable debugging functionality, run sp_sdidebug, passing the parameter legacy_on. To disable debugging, pass legacy_off to this procedure.
Note Running the sp_sdidebug stored procedure on production servers is not recommended.
For more information, see Microsoft Knowledge Base article 328151.
Note Books Online refers to the client-side debugging component sqldbreg.exe. In SP3, this component file was renamed to sqldbreg2.exe.
Introduced in SP3
After applying the service pack, you are no longer able to disable the Named Pipes protocol on instances of the database engine participating in a failover cluster.
Introduced in SP3a
Starting with SQL Server 2000 SP3a, instances of the SQL Server 2000 database engine and MSDE 2000 that are not configured to support network communications will stop using User Datagram Protocol (UDP) port 1434. Instances that are configured to support network communications will use UDP 1434.
An instance upgraded to SP3a or later will stop using UDP 1434 whenever all of the server Net-Libraries for the instance, except the shared memory Net-Library, are disabled. The instance will start using port 1434 whenever you enable any of the server Net-Libraries. For information on disabling or enabling server Net-Libraries, see the topic "SQL Server Network Utility" in SQL Server 2000 Books Online.
The use of UDP port 1434 by a computer will not stop until all instances of SQL Server 2000 and MSDE 2000 on the computer have been upgraded to SP3a or later and configured to not support network communications.
Whether UDP port 1434 is open or closed does not depend on the state of the shared memory Net-Library. The shared memory Net-Library is used only for local connections, and does not use a network. The shared memory Net-Library is always active; it cannot be enabled or disabled.
You cannot disable all of the server Net-Libraries when installing or upgrading instances of the SQL Server 2000 database engine.
Introduced in SP4
In SP4, the maximum value for the network packet size option (set using sp_configure) is 32767. This is slightly less than half the previous maximum of 65536. During upgrade, existing values larger than 32767 will automatically be adjusted to 32767. If a script attempts to use sp_configure to set a value larger than 32767 but less than or equal to 65536, the value will also be set to 32767. Setting the network packet size to a value larger than 65536 results in an error.
Introduced in SP4
SP4 includes a change in the behavior of the SQL Server optimizer that affects queries containing predicates with large IN lists or many OR clauses. More specifically, this change (introduced in SQL Server 2000 hotfix 789) affects queries that contain (or that can be rewritten using an equivalent expression that contains) the following:
Because of this change, SQL Server uses less memory when compiling these types of statements and thereby avoids out-of-memory errors. In rare cases when these types of queries are run on systems that have very large memory and a low degree of parallelism, a query plan with inferior performance may be chosen by the optimizer. To override the change in optimizer behavior, trace flag 9060 is provided in this service pack. By default, trace flag 9060 is OFF. When the trace flag is ON, SP3 behavior prior to hotfix 789 is enabled. If error 701 (insufficient system memory) is encountered when the trace flag is ON, consider rewriting the queries using temporary tables or table variables for the values in the IN lists. For numerical ranges, use BETWEEN clauses or greater than (>) or less than (<) operators. For information on using trace flags, see "Trace Flags" in SQL Server Books Online.
Introduced in SP4
Banyan VINES, Multiprotocol, AppleTalk, and NWLink IPX/SPX network protocols are supported in SP4. However, these protocols will not be supported in SQL Server 2005 and later releases. Please plan accordingly.
Introduced in SP4
When you run in Windows-on-Windows 64 (WOW) mode on Windows Server 2003 x64 SP1 or later, the default 64-bit version of Windows Performance Monitor cannot be used to access the SQL Server Performance Counters that are used to monitor an instance of SQL Server 2000 SP4. Instead, you must use the 32-bit version of Windows Performance Monitor. The 32-bit version is located at:
%systemdrive%\WINDOWS\SysWOW64\perfmon.exe
In WOW mode, SQL Server Performance Counters can be viewed only when the 32-bit version of Performance Monitor is running on the same computer as the instance of SQL Server 2000 SP4.
This restriction does not apply to Windows Server 2003 for 64-Bit Itanium-based Systems.
This section discusses enhancements to SQL Server 2000 replication that are included with SP4.
Introduced in SP1
During transactional replication setup, custom stored procedures for insert, delete, and update actions are created in the subscription database. Regardless of how many columns are affected by an UPDATE statement, the update custom stored procedure updates all of the columns in the subscription table. Any column that has not changed is reset to the same values that existed before the update. Typically, this action causes no problems. However, if any of these columns are indexed, this resetting can become expensive.
If you use transactional replication and have several indexes on the subscription table, and only a few column values change because of updates, the overhead of maintaining the index can limit performance when changes are applied at the Subscriber. For example, a subscription database that is used for reporting purposes may have many more indexes than the publication database. Dynamically building the UPDATE statement at run time can improve performance. The update includes only the columns that have changed, creating an optimal UPDATE string.
This service pack includes a new stored procedure, sp_scriptdynamicupdproc, which generates a custom stored procedure that you can use at the Subscriber to dynamically build the UPDATE statement at run time. However, building the dynamic UPDATE statement at run time requires extra processing.
sp_scriptdynamicupdproc is documented in the latest copy of the SQL Server 2000 Books Online. For information about installing the latest version of the SQL Server 2000 Books Online, see section 1.6 Updates to SQL Server 2000 Books Online Are Available. This is an English-language copy of the reference topic for sp_scriptdynamicupdproc.
Introduced in SP1
In transactional replication, UPDATE statements usually are replicated as updates. But if the update changes any column that is part of a unique index, a clustered index, or an expression that is used as a unique constraint, the update is performed as a DELETE statement followed by an INSERT statement at the Subscriber. This is done because this type of update can affect multiple rows and a uniqueness violation can occur if updates are delivered row by row.
If the update affects only one row, there is no chance for a uniqueness violation. Therefore, trace flag 8207 has been added to this service pack to allow updates to any unique column that affect only one row to be replicated as UPDATE statements. This optimization has been added specifically for applications that install user-defined UPDATE triggers at the Subscriber and require these triggers to fire for updates that affect only one row on a unique column.
To use trace flag 8207, turn it on from the command prompt (sqlservr.exe -T8207) or at run time using DBCC TRACEON(8207, -1) before the Log Reader Agent is started.
Important Typically, trace flag 8207 is used with read-only transactional replication. Do not use this trace flag with updatable subscriptions if the primary key UPDATE can occur at the Subscriber.
[Top]Introduced in SP1
In SQL Server 2000, concurrent snapshot processing was not recommended if the publishing table had a unique index that was not the primary key or the clustering key. If data modifications were made to the clustering key while a concurrent snapshot was being generated, replication could fail with a duplicate key error when applying the concurrent snapshot to a Subscriber. With this service pack, restrictions on using concurrent snapshot processing are removed.
Introduced in SP1
When setting up nosync subscriptions (that is, subscriptions that do not receive the initial snapshot), the custom stored procedures for INSERT, UPDATE, and DELETE statements must be created manually. Typically, these statements are created at the Subscriber when the initial snapshot is delivered. A new stored procedure, sp_scriptpublicationcustomprocs, has been added to generate scripts for the custom stored procedures at the publication level. This new functionality may make it easier to set up nosync subscriptions.
sp_scriptpublicationcustomprocs is documented in the latest copy of the SQL Server 2000 Books Online. For information about installing the latest version of the SQL Server 2000 Books Online, see section 1.6 Updates to SQL Server 2000 Books Online Are Available. This is an English-language copy of the reference topic for sp_scriptpublicationcustomprocs.
Introduced in SP1
When merge replication system tables contain large amounts of meta data, cleaning up the meta data improves performance. Prior to SQL Server 2000 SP1, meta data could be cleaned up only by running sp_mergecleanupmetadata. However, SQL Server 2000 SP1 and later versions include retention-based meta data clean up, which means that meta data can be automatically deleted from the following system tables:
Note Before image tables are present if the @keep_partition_changes synchronization optimization option is enabled on the publication.
Retention-based meta data clean up occurs as follows:
Note -MetadataRetentionCleanup parameter is set to 1 for all Merge Agent profiles that are included with SQL Server 2000 SP1 and later versions. If you upgrade a server to SP1 or later and then add merge replication, the Merge Agent profile is automatically updated to include this parameter. If you upgrade a server that already has merge replication enabled to SP1 or later, the Merge Agent profile is not automatically updated; update the profile by running sp_add_agent_parameter (see Additional Parameter for sp_add_agent_parameter later in this section).
Important The default retention period for publications is 14 days. If an article belongs to several publications, there might be different retention periods. In that situation, the longest retention period is used to determine the earliest possible time that clean up can occur. If there are multiple publications on a database, and if any one of those publications uses an infinite publication retention period (@retention=0), merge meta data for the database is not automatically cleaned up. For this reason, use infinite publication retention with caution.
The system stored procedure sp_add_agent_parameter now has a MetadataRetentionCleanup parameter, which allows you to add or remove meta data retention clean up from Merge Agent profiles. A value of 1 indicates that the profile should include clean up; a value of 0 indicates that it should not include clean up. For example, to add meta data retention clean up to a profile, execute the following code:
EXEC sp_add_agent_parameter @profile_id=<my_profile_id>,
@parameter_name='MetadataRetentionCleanup', @parameter_value=1For automatic retention-based clean up to occur in a database involved in merge replication, the database and the Merge Agent must both be on servers running SQL Server 2000 SP1 or later. For example:
Automatic clean up on some servers and not on others will at most cause false conflicts, and those should be rare. For topologies that include versions of SQL Server prior to SQL Server 2000 SP1, you may see performance benefits by running sp_mergemetadatacleanup on all servers that are not cleaned up automatically.
Retention-based meta data clean up prevents non-convergence and silent overwrites of changes at other nodes. However, false conflicts can occur if the following conditions are met:
For example, if meta data is cleaned up at the Publisher but not at the Subscriber, and an update is made at the Publisher, a conflict occurs even though the data appears to be synchronized.
To prevent this conflict, make sure that meta data is cleaned up at related nodes at about the same time. If -MetadataRetentionCleanup is set to 1, both the Publisher and Subscriber are cleaned up automatically before the merge starts, thereby ensuring that the nodes are cleaned up at the same time. If a conflict occurs, use the merge replication conflict viewer to review the conflict and change the outcome if necessary.
If an article belongs to several publications or is in a republishing scenario, it is possible that the retention periods for a given row at the Publisher and Subscriber are different. To reduce the chance of cleaning up meta data on one side but not the other, it is recommended that those different publications have similar retention periods.
Note If the system tables contain large amounts of meta data that must be cleaned up, the merge process may take longer to run. Clean up the meta data on a regular basis to prevent this issue.
Introduced in SP1
A publication database that is restored from a backup should first synchronize with a subscription database that has a global subscription (that is, a subscription having an assigned priority value) to guarantee correct convergence behavior. Synchronization ensures that the changes that were lost at the publication database because of the restore operation are reapplied accurately.
Do not synchronize the publication database with a subscription database that has an anonymous subscription. Because anonymous subscriptions do not have enough meta data to apply changes to the publication database, such synchronization can lead to the non-convergence of data.
When you are planning back up and restore operations for merge replication, consider the following additional issues:
Restore a subscription database from a backup only if the backup is no older than the shortest retention period of all publications to which the Subscriber subscribes. For example, if a Subscriber subscribes to three publications with retention periods of 10, 20, and 30 days, respectively, the backup used to restore the database should not be more than 10 days old.
It is strongly recommended that a Subscriber synchronize with the Publisher before you perform a backup. Otherwise, the system might not converge correctly if the Subscriber is restored from this backup. Although the backup file itself might be new, the last synchronization with a Publisher could be almost as old as the retention period. For example, consider a publication with a retention period of 10 days. The last synchronization was 8 days ago, and now the backup is performed. If the backup is applied 4 days later, the last synchronization will have occurred 12 days ago, which is past the retention period. If the Subscriber had synchronized right before the backup, the subscription database would be within the retention period.
If you need to change the publication retention value, manually reinitialize the Subscriber to avoid the non-convergence of data. The retention-based meta data clean up feature deletes outdated meta data from merge system tables when the publication retention period is reached.
The publication retention value is used to determine when subscriptions that have not synchronized within the retention period should expire. If, after a clean up, the publication retention period is increased and a subscription attempts to merge with the Publisher (which has already deleted the meta data), the subscription will not expire because of the increased retention value. Furthermore, the Publisher does not have enough meta data to download changes to the Subscriber, which leads to non-convergence.
Introduced in SP1
Restoring a backup to the same server and database—running the same version as the server from which the backup was created—preserves your replication settings. If you are restoring a replicated database to a version of SQL Server that is different from the version used to back up the database, consider the following issues:
Introduced in SP1
Starting with SP1, a new command prompt parameter, -MaxCmdsInTran, has been added for the Log Reader Agent. For transactions affecting a large number of commands (typically mass updates or deletes), the Distribution Agent must wait for the Log Reader Agent to write the entire transaction to the distribution database before it can start propagating the transaction to the Subscriber. This delay blocks the Distribution Agent and reduces the parallelism between the two agents.
By using –MaxCmdsInTran, the Log Reader Agent breaks large transactions into smaller chunks, and each chunk contains the same or fewer commands as the -MaxCmdsInTran input. Therefore, the Distribution Agent can start processing earlier chunks of a transaction while the Log Reader Agent is still working through later chunks of the same transaction.
This improvement in parallelism between the Log Reader Agent and the Distribution Agent contributes to better overall replication throughput. Note, however, that the transaction chunks are committed at the Subscriber as individual transactions, which breaks the property of atomicity, one of the ACID (Atomicity, Consistency, Isolation, and Durability) properties. This outcome is not a problem in most circumstances, though it is recommended that you test this to make sure.
Specify a positive integer (1 or above) for the -MaxCmdsInTran parameter value. Specifying a value of 0 is equivalent to not using the parameter. Because this parameter improves performance only when the transaction is very large, a value of 5000 or greater for this parameter is typical. For example:
logread.exe -MaxCmdsInTran 10000. To use this parameter, the Publisher must be running SQL Server 2000 SP1 or a later version, and the Log Reader Agent and distribution database must be upgraded to SP3 or later. Otherwise, -MaxCmdsInTran is ignored.
Introduced in SP2 (applies to Transactional Replication only).
You cannot create a non-unique clustered index on a table after it is published for transactional replication. Before creating the index you must first drop any publication that includes the table.
Introduced in SP2.
During normal processing, merge replication can send DELETE commands to Subscribers for rows that do not belong to the Subscriber's partition. DELETE commands of this type are referred to as irrelevant deletes. Irrelevant deletes do not affect data integrity or convergence, but they can result in unnecessary network traffic.
To reduce network traffic caused by irrelevant deletes, you can use the new Snapshot Agent parameter
-MaxNetworkOptimization with merge replication publications. Setting the parameter to 1 minimizes the chances of irrelevant deletes, which maximizes network optimization.
Note Setting this parameter to 1 is useful only when the synchronization optimization option of the merge publication is set to true (the @keep_partition_changes parameter of sp_addmergepublication).
The default is 0 because setting the parameter to 1 can increase the storage of meta data and cause performance to degrade at the Publisher if multiple levels of join filters and complex subset filters are present. You should carefully assess your replication topology and set -MaxNetworkOptimization to 1 only if network traffic from irrelevant deletes is unacceptably high.
You can add this parameter to the Snapshot Agent profile by executing the system procedure sp_add_agent_parameter as follows:
EXEC sp_add_agent_parameter 1, 'MaxNetworkOptimization', 1Introduced in SP3
SP3 and later automatically creates a new role for use by merge replication. The name of the new role is in the form MSmerge-<publication ID>. The role is created on the Publisher for each merge replication publication and acts as the publication access list (PAL) to control access to merge publications on the Publisher. If this role is dropped, you can run a new stored procedure included with SP3 or later, sp_createmergepalrole, to re-create the role. This stored procedure is executed at the Publisher on the publication database to re-create the role.
sp_createmergepalrole is documented in the latest copy of the SQL Server 2000 Books Online. For information about installing the latest version of the SQL Server 2000 Books Online, see section 1.9 Updates to SQL Server 2000 Books Online Are Available. This is an English-language copy of the reference topic for sp_createmergepalrole.
Introduced in SP3
If a subscription is created by a user who is not a member of the sysadmin fixed server role, you must do one of the following:
Note The remote agent activation feature always requires the job step to run in the context of a user account in the sysadmin fixed server role.
Introduced in SP3
Permissions have been changed on a number of the stored procedures used to implement, administer, and monitor a replication topology. Most of these changes involve a tightening of the permissions that are required to run the stored procedures. For more information about the new permissions, review the Transact-SQL reference documentation for the replication stored procedures in the updated version of SQL Server Books Online. For more information about the updated SQL Server Books Online, see Section 1.6 Updates to SQL Server 2000 Books Online Are Available.
Introduced in SP3
A new parameter, @published_in_tran_pub, has been added to both sp_addmergearticle and sp_changemergearticle. This parameter is used to indicate that an article in a merge publication is also published in a transactional publication. @published_in_tran_pub is nvarchar(5), with a default of FALSE. TRUE specifies that the article is also published in a transactional publication.
Note When you change this parameter in sp_changemergearticle, the snapshot must be invalidated and subscribers must be reinitialized.
Introduced in SP3
The Configure Publishing and Distribution Wizard now includes a new page: Distributor Password. You must type a password on this page if you select one or more Publishers to use the server as a remote Distributor and one or more of those Publishers require a password. The connection between a Publisher and a remote Distributor is a hybrid of a linked server and a remote server. The connection uses the login distributor_admin. By default, the Publisher is configured as non-trusted at the remote Distributor, so a password is required.
Note If you have downloaded and installed the latest version of the SQL Server 2000 Books Online, this information is available when you click the Help button for the new page.
Introduced in SP3
SQL Server allows you to enable existing subscriptions (created using SQL Server Enterprise Manager, SQL-DMO, and replication stored procedures) for use with Windows Synchronization Manager. You can also create new subscriptions using Windows Synchronization Manager. After you apply the service pack, when synchronizing a subscription, Windows Synchronization Manager will prompt you to enter the password or passwords required to connect to the servers involved in the synchronization.
Introduced in SP3
Under a certain set of conditions, replication could malfunction in the process of attaching or restoring a published database. These conditions are:
If all of these conditions are true, you should execute the sp_changedbowner stored procedure on the attached or restored database. Assign ownership to the sa built-in administrator login. This will ensure that replication functions correctly.
Note You must be a member of the sysadmin fixed server role to execute sp_changedbowner .
For more information about cross-database ownership chaining, see Section 5.1.10 Cross-Database Ownership Chaining.
Introduced in SP4
Replication ActiveX® controls (sqlinitx.dll, sqldistx.dll, sqlmergx.dll, and replerrx.dll) are no longer designated as "safe for scripting" and "safe for initialization." The security and functional behaviors of the controls have not changed since SP3; however, the security designations have been changed to meet security standards. These changes may affect applications that invoke embedded replication ActiveX controls in a Web page.
Introduced in SP4
A new parameter, @compensate_for_errors, can be specified when calling sp_addmergearticle. The parameter specifies whether compensating actions are taken if errors (such as a constraint violation) are encountered during synchronization. When set to TRUE (the default), a change that cannot be applied at a node during synchronization leads to compensating actions that undo the change at all other nodes. In some cases this behavior is desirable, but in some cases it can be problematic; for example, one incorrectly configured Subscriber that generates an error can cause changes to be undone at the Publisher and all other Subscribers.
Specifying a value of FALSE disables these compensating actions; however, the errors are still logged and subsequent merges will continue to attempt to apply the changes. Although data in the affected rows might appear to be out of convergence, as soon as you address the error the change can be applied, and data will converge.
Note If the source table for an article is already published in another publication, then the value of @compensate_for_errors must be the same for both articles.
Introduced in SP4
In previous releases, identity columns in transactional publications were replicated as the base data type, such as int, without the identity property set. This approach is appropriate for applications that do not allow inserts at the Subscriber. SQL Server 2000 SP4 introduces a new schema option (0x4) for transactional publications, which is used to replicate the identity column as an identity column. This is useful in a number of cases, including bidirectional replication and using the Subscriber as a warm standby server. In these cases, inserts can occur at the Subscriber, and the inserts result in the identity column being incremented.
To specify that an identity column should be replicated as an identity column:
USE Northwind
GO
DBCC CHECKIDENT ('Employees', RESEED, 1000000)
GOFor more information, see DBCC CHECKIDENT in SQL Server Books Online.
Introduced in SP4
Distributor instances of SQL Server 2000 (32-bit) running in Windows-on-Windows 64 mode on Windows 2003 SP1 systems running on X64 or compatible processors cannot have non-SQL Server Subscribers. Although running Windows-on-Windows 64 mode is now supported for SQL Server 2000 SP4, this mode is not supported by drivers or providers used to connect from the Distributor to the non-SQL Server Subscriber.
This section discusses enhancements to SQL Server Agent and shared tools that are included in SP4.
Introduced in SP2
The SQL Server Agent Job History now records the Windows account under which each job step runs. This information helps administrators diagnose security issues with scheduled jobs, including scheduled jobs that are defined for replication and Data Transformation Services (DTS) tasks.
Introduced in SP3
Multiserver administration is the process of automating administration tasks across multiple instances of SQL Server. Use multiserver administration if you manage two or more servers and you want to centralize maintenance tasks.
In SP3 or later, the SQL Server Agent service account does not have to be a Windows administrator unless you need to use the SQL Server Agent Proxy Account. For more information about the SQL Server Agent Proxy Account, see Section 5.6.3 SQL Server Agent Proxy Account Improvements. The SQL Server Agent service account must be a member of the sysadmin fixed server role.
With multiserver administration, you must have at least one master server and at least one target server. A master server distributes jobs to and receives events from target servers. A master server stores the central copy of job definitions for jobs that run on target servers. Target servers connect periodically to their master server to update their list of jobs to perform. If a new job exists, the target server downloads the job and disconnects from the master server. After the target server completes the job, it reconnects to the master server and reports the status of the job.
Before you apply SP4, you must complete several steps to upgrade your SQL Server 2000 master/target server configuration. The changes that are introduced with SP4 are not compatible with SQL Server 7.0 target servers, or with any servers not running SP3 or later. This is a change from the original SQL Server 2000 functionality.
To upgrade your master/target server configuration
--Option A: Windows authentication
EXEC sp_grantlogin 'DOMAIN\user'
GO
USE msdb
GO
EXEC sp_adduser 'DOMAIN\user', 'DOMAIN\user', 'TargetServersRole'
GO
--Option B: SQL Server authentication – see explanation below for
--details.
EXEC sp_addlogin <MSXAccount>, <MSXAccountPassword>, 'msdb'
GO
USE msdb
GO
EXEC sp_adduser <MSXAccount>, <MSXAccount>, 'TargetServersRole'
GOWhere <MSXAccount> represents the SQL Login name you choose and <MSXAccountPassword> represents the associated password.
Note These values must be enclosed in single quotation marks.
You have the following options when choosing an MSX account:
Do not specify a SQL Server Agent probe account (<computer_name>_msx_probe_login). As part of the upgrade to SP3 or later, SQL Server removes the old probe accounts because the TSX servers no longer use them.
Note After running xp_sqlagent_msx_account, SQL Agent must be stopped and restarted on each server.
For more information about xp_sqlagent_msx_account, see Section 5.3.3 New SQL Server Agent Extended Stored Procedure.
Introduced in SP3
SP3a includes a new extended stored procedure (xp_sqlagent_msx_account) that allows you to configure the account that the SQL Server Agent TSX server uses to download instructions from an MSX server. This account is also known as the MSX account, or master server account.
xp_sqlagent_msx_account is documented in the latest copy of the SQL Server 2000 Books Online. For information about installing the latest version of the SQL Server 2000 Books Online, see section 1.6 Updates to SQL Server 2000 Books Online Are Available. This is an English-language copy of the reference topic for xp_sqlagent_msx_account .
Introduced in SP3
SQL Server now checks to ensure that the Agent job owner has permission to append or overwrite the output log file from each job. This happens in three ways:
In all cases, jobs are written with SQL Server Agent credentials, but SQL Server now tests to ensure the user has permission to write to the selected job output log file location on the server. Errors appear in the job history, but the job steps do not fail if the log file cannot be written.
Introduced in SP3
In the 32-bit version of SQL Server 2000, SQL Agent Mail can be configured to use an Extended MAPI e-mail profile for sending e-mail alerts. You can use an Extended MAPI e-mail application, such as Microsoft Outlook, to create an Extended MAPI profile. In the 64-bit version of SQL Server 2000, SQL Agent Mail can only use a Simple MAPI profile for sending e-mail alerts. Do not use Simple MAPI profiles in the 32-bit version of SQL Server 2000.
Introduced in SP4
In SQL Server Enterprise Manager, the Help topic "View Properties" is not available from Design View and Create View. The updated topic is available at this Microsoft Web site.
This section discusses enhancements to connectivity components of SQL Sever 2000 that are included with SP4.
Introduced in SP3
SQL Server now supports QLogic Virtual Interface Architecture (VIA) System Area Network (SAN) implementations. To enable SQL Server support for connections over QLogic VIA, both the client and server computers must provide IP address resolution in a file named Vihosts in the appropriate Windows system32\drivers\etc folder.
The Vihosts file should be formatted as follows:
<VI IP Address of server computer> <SERVER_COMPUTERNAME>
<VI IP Address of client computer> <CLIENT_COMPUTERNAME>
For example:
139.4.130.1 SQLCOMPUTER
139.4.130.2 SQLCLIENT
Use IP addresses from the respective QLogic VIA network cards and actual computer names. Otherwise, connections cannot be made to named instances or with other IP protocols such as TCP or Named Pipes. The Vihosts file is not necessary for Giganet VIA connectivity.
Note You must identify the correct VIA vendor on client computers by using Client Network Utility. Select the appropriate value in the Vendor drop-down box. The corresponding action should also be completed on server computers through Server Network Utility.
This section discusses enhancements to SQL Server 2000 Meta Data Services that are included with Database Components SP4.
Introduced in SP1
Meta Data Browser now exports XML-based meta data in Unicode. Before SQL Server 2000 SP1, the browser exported ANSI code, which does not support non-English characters. This functional change is invisible to the user. As of this SP4 release, exported data is always expressed as Unicode. You can still export in ANSI code by setting the value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Repository\Engine\XMLExport to 0. The following list represents the values that you can set for this registry key:
For more information about each flag, see "IExport::Export Method" in SQL Server Books Online.
Introduced in SP3
Script support in information models has been disabled. After installing SP3a or later, you receive the following error if your application accesses a property or method for which a script is defined:
EREP_SCRIPTS_NOTENABLEDTo enable script support
If you need to continue executing scripts, you can use the following procedure to create a registry setting that enables script support.
If you want to disable scripting later, set the value of this new registry key to 0.
Important For security reasons, you should never have a blank password on the sa login.
Introduced in SP3
SQL Server includes in the msdb database a set of tables, stored procedures, and views that store information used by the Meta Data Services repository engine. In SP3, a new dedicated role named RepositoryUser was added and must be used to access and update repository information. This role has been granted create, read, update, delete, and execute permissions on these objects. The public role no longer has permissions on these objects.
This change affects existing repository objects in addition to any additional objects created by the repository engine in the future. Users and applications that access the repository through the public role must be added to the RepositoryUser role.
This section discusses enhancements to SQL Server 2000 Data Transformation Services that are included with SP4.
Introduced in SP2
When you export data to a text file, the DTS Import/Export Wizard now configures the package to write up to 8000 characters of any column containing string-type data.
Introduced in SP2
SQL Server Agent records the security context under which each step in a job runs. In SP3 or later, the security context appears in the Job History dialog box. When you run a DTS package from a step in a job, the SQL Server Agent logs the user account under which the package runs. This information helps administrators diagnose permission and authentication issues that occur when DTS packages are scheduled to run on a server.
Introduced in SP2
Prior to SP2, DTS packages stored on the server could not be run under the credentials of the SQL Server Agent Proxy Account unless the proxy account had access to the user Temp folder for the account under which either the server (in the case of jobs run from xp_cmdshell), or the agent (in the case of agent jobs) was running. Because of this, users often had to adjust the TEMP environment variable for the SQL Server or SQL Agent startup account to point to a folder that was accessible to both the startup and the proxy accounts, such as C:\Temp. For SP2 and later, DTS has been enhanced to use the system Temp folder if the user Temp folder is unavailable, greatly reducing the need for these adjustments.
Introduced in SP3
By default, SP3 and later disables the option to store DTS packages in Meta Data Services. This means that the Meta Data Services option does not appear in the Location drop-down list in the Save DTS Packages dialog box. In addition, this option is disabled on the Save, schedule, and replicate package page in the DTS Import/Export Wizard.
To allow packages to be saved in Meta Data Services
Note You must be logged on with administrator privileges to modify this property.
When the option to store packages in Meta Data Service is disabled, you can load existing packages from Meta Data Services, edit them, and save them to Meta Data Services using the Save option. However, Meta Data Services is not available from the Save As option. For example, you cannot re-save a package to Meta Data Services using a different name.
The following topic discusses an enhancement for XML and SQLXML in SP4.
Introduced in SP3, updated in SP4
When you apply SP4, OPENXML is updated to use a custom-built XML parsing technology designed to be backward compatible with MSXML 2.6.
Prior to SP3, the version of the XML parser used by OPENXML permitted a predicate in an XPath expression to follow the special character abbreviation that identifies the current context node, which is denoted by a period (.) in XPath syntax. This violates the XPath syntax specification, which requires that this character be followed by a location path expression.
With the new OPENXML behavior, a predicate cannot immediately follow the current context node abbreviation special character. XPath expressions in SQLXML queries (XPath queries against annotated mapping schemas and in XSLT style sheets written to transform the results of SQLXML queries) that use the faulty syntax will fail after you upgrade to SP3 or later.
To prevent these failures, identify and fix any expressions that use the incorrect syntax. For example, the syntax of the XPath expression that is specified as the value of the test attribute in the following xsl:if element is not valid because the predicate, [@ResourceTypeID='2'], immediately follows the special character abbreviation that identifies the current context node.
The following statement, which previously did not generate an error, will fail after SP3 or later is installed.
<xsl:if test=".[@ResourceTypeID='2']">To prevent a failure, the XPath expression must be amended as follows:
<xsl:if test="@ResourceTypeID='2'">The following item applies to the SQL Server 2000 Virtual Backup Device API.
Introduced in SP2
The Virtual Backup Device API allows ISVs to integrate SQL Server 2000 into their products. This API is engineered to provide maximum reliability and performance. It fully supports the backup and restore functionality of SQL Server 2000, including the complete range of hot and snapshot backup capabilities.
In SP1 and earlier, there was no way to freeze and back up more than a single database at one time. SP2 or later now provides server-side support for freezing and capturing multiple databases in a single snapshot through the VDC_PrepareToFreeze command.
The Virtual Backup Device Interface Specification in SP4 contains updated information about the VDC_PrepareTo Freeze command. An updated version of the Virtual Device Interface header file (Vdi.h) can be found at \Devtools\Include in the SP4 setup folder.
You can download the updated specification from the Microsoft Download center at the Microsoft SQL Server Downloads Web site.
Introduced in SP3
Microsoft SQL Server error reporting is disabled by default. You can enable it during installation through SQL Server Setup or Analysis Services Setup, or after installation through the Server Properties dialog box in Enterprise Manager or the Server Properties dialog box in Analysis Manager. Enabling error reporting while you are running SQL Server Setup allows error reporting for the SQL Server database engine and SQL Server Agent. Enabling error reporting while you are running Analysis Services Setup allows error reporting for Analysis Services. If you want to enable error reporting for both SQL Server and Analysis Services, you must enable error reporting for SQL Server while running SQL Server Setup and Analysis Services while running Analysis Services Setup.
If you enable this feature, SQL Server is configured to send a report to Microsoft automatically if a fatal error occurs in the SQL Server database engine, in SQL Server Agent, or in SQL Server Analysis Services. Microsoft uses error reports to improve SQL Server functionality and treats all information as confidential.
Information about errors is sent over a secure (HTTPS) connection to Microsoft, where it is stored with limited access. Alternatively, this information can be sent to your own Corporate Error Reporting server. See this Microsoft Web site for more information about setting up a Corporate Error Reporting server.
The error report contains the following information:
Microsoft does not intentionally collect your files, name, address, e-mail address, or any other form of personal information. The error report can, however, contain customer-specific information from the memory or files of the process that caused the error. Although this information can potentially be used to determine your identity, Microsoft does not use this information for that purpose.
For the Microsoft error reporting data collection policy, see this Microsoft Web site.
If you enable error reporting and a fatal error occurs, you may see a response from Microsoft in the Windows Event log that points to a Microsoft Knowledge Base article about a particular error. A response may look similar to the following example:
Source = MSSQLServerOlapServicesDW
EventID = 1010
data = http://support.microsoft.com/support/misc/kblookup.asp?id=Q123456
&iBucketTable=1&iBucket=39980&Cab=21474432.cab&LCID=1033
&OS=5.1.2600.2.00010100.0.0To disable error reporting for the SQL Server database engine and SQL Server Agent, go to SQL Server Properties (General Tab) in Enterprise Manager and clear the Enable the error reporting check box. To disable error reporting for Analysis Services, go to Server Properties in Analysis Manager and clear the Enable Error Reporting check box. If error reporting is enabled for both SQL Server (database engine and SQL Server Agent) and Analysis Services, you must disable error reporting for SQL Server and Analysis Services individually.
Introduced in SP4
SQL Server 2000 SP4 introduces new serviceability functionality that enables you to uninstall hotfixes applied to SP4 and later versions of SQL Server 2000 running on Windows XP and Windows Server 2003. (This same functionality was available with SQL Server 2000 SP3, but only after the application of an additional hotfix).
Introduced in SP1
Microsoft has released a security enhancement for English Query applications. This enhancement is not installed as a part of the service pack. However, it is recommended that you apply it if you use English Query. The security enhancement is located on the SP4 CD-ROM in the folder \EQHotfix. Details about the English Query enhancement are available in Knowledge Base article 297105.
Introduced in SP1, updated for SP4
While the DB-Library and Embedded SQL for C APIs are still supported in SQL Server 2000, no future versions of SQL Server will include the files or documentation that are necessary to program applications that use these APIs. Connections from existing applications written using DB-Library and Embedded SQL for C will still be supported in the next version of SQL Server, but this support will be dropped in a future release. Do not use DB-Library or Embedded SQL when writing new applications. Remove dependencies on these technologies when modifying existing applications. Instead of DB-Library or Embedded SQL for C, use the System.Data.SQLClient namespace from the .NET Framework or an API such as ADO, OLE DB, or ODBC to access data in SQL Server. For more information about these technologies, see SQL Server Books Online or the .NET Framework SDK.