SQL Server Home Page

 SQL Server 2000 (64-Bit)

Differences Between 32-bit and 64-bit Releases

SQL Server Books Online (64 - bit)

Technical Support

  • Microsoft Product Support Services (PSS)
  • Microsoft SQL Server Support
  • Knowledge Base (KB) Search
  • Microsoft TechNet
  • Microsoft Windows Hardware Compatibility List

Microsoft Accessibility Web Site

SQL Server Printed Documentation

White Papers

Feedback

Web Links

  • Microsoft SQL Server Product Web Site
  • Microsoft SQL Server Developer Center
  • Professional Association for SQL Server
  • SQL Server Magazine
  • Microsoft Newsgroups
  • MSDN Online
  • Microsoft SQL Server Web Site, English Query Page
  • Microsoft SQL Server Web Site, Analysis Services Page
  • XML Developer Center


Introducing SQL Server 2000 (64-bit)

This topic applies only to SQL Server 2000 (64-bit).

Microsoft® SQL Server™ 2000 (64-bit) provides full native support for the 64-bit version of the Microsoft Windows® operating system. This version of SQL Server 2000 provides many of the features of the 32-bit version, as well as providing support for the extended 64-bit hardware. SQL Server 2000 (64-bit) takes advantage of the large memory capabilities of the 64-bit Windows platform, including support for up to 32 terabytes of physical memory. SQL Server 2000 (64-bit) provides new levels of scalability while providing complete compatibility with the 32-bit version of SQL Server 2000.

Topic | Description
About This Release (64-bit) | Outlines what is new in this release.
Editions of SQL Server 2000 (64-bit) | Describes the different editions of SQL Server 2000 (64-bit).
Differences Between 64-bit and 32-bit Releases (64-bit) | Describes differences you may observe in the 64-bit version of SQL Server 2000.
Sending Feedback (64-bit) | Provides instructions for commenting on this documentation.
Additional Resources (64-bit) | Describes where to go on the Web for help and information.


About This Release (64-bit)

This release of Microsoft® SQL Server™ 2000 (64-bit) includes the SQL Server 2000 (64-bit) Enterprise Edition. To run this release of SQL Server 2000 (64-bit), you must use the 64-bit Microsoft Windows® operating system: the 64-bit versions of the Windows® Server 2003 family.

Documentation for This Release

To see the setup documentation file, open the Setupsql.chm file in the following location: Systemdrive:\Program Files\Microsoft SQL Server\80\SetupBootstrap\Help\1033\.

After Setup completes, you can view the documentation for SQL Server by clicking the Help button, pressing the F1 key in dialog boxes or interface elements, or from the Start menu by selecting Programs, Microsoft SQL Server, and then Books Online.


Editions of SQL Server 2000 (64-bit)

This release of Microsoft® SQL Server™ 2000 (64-bit) is available in these editions:

SQL Server 2000 Enterprise Edition (64-bit)

Used as a production database server with a 64-bit processor. Supports most of the features available in the 32-bit version of SQL Server 2000, and scales to the performance levels required to support the largest Web sites and enterprise online transaction processing (OLTP) and data warehousing systems. It has three installation features, SQL Server, Analysis Server, and Books Online, as well as several subfeatures. The default is for Setup to install all three features and all subfeatures. On the Feature Selection page of the Installation Wizard, you can choose and configure the features to install. For more information, see Features of SQL Server 2000 (64-bit).


Differences Between 64-bit and 32-bit Releases (64-bit)

This section describes differences you need to consider when installing and using the 64-bit version of Microsoft® SQL Server™ 2000.

Setup and Installation

Windows Installer-Based

SQL Server 2000 (64-bit) uses the Windows Installer to completely integrate the installation of SQL Server features in a single feature tree. Minimum and typical installation modes are no longer implemented. Setup initially displays the feature tree with all available features selected. Administrators can customize installations by choosing items on the feature tree and changing installation paths.

Setup Feature Tree Interaction with Parent/Child Features

In this release of SQL Server 2000 (64-bit), child feature selection is more limited than in the 32-bit version of SQL Server 2000. For example, the Tools feature installs all tools; there is no option to select individual tools. Similarly, Server Components are limited to SQL Server and the Full-Text Search Engine. The full selection of child features will be enabled in the next major release.

Connectivity-Only Option Not Supported

The Connectivity-Only option is not implemented during the SQL Server 2000 (64-bit) Setup. The Connectivity-Only option in previous versions installed Microsoft Data Access Components (MDAC) and JET. JET is not available for the 64-bit version of SQL Server 2000. MDAC 64-bit components are installed by the 64-bit versions of the Windows® Server 2003 family as part of its core components.

Remote Installation

SQL Server 2000 (64-bit) does not support remote installation.

Previous Version Upgrades

Previous versions of SQL Server for the 32-bit computer are not supported to run on the 64-bit platform; upgrades of 32-bit instances are not supported in this release.

Data Migration

Data migration from SQL Server 2000 to SQL Server 2000 (64-bit) is supported. Attaching a 32-bit database to a 64-bit instance is possible by using detach/attach or backup/restore in 32-bit Enterprise Manager. You can move databases back and forth between 32-bit and 64-bit versions of SQL Server. Migrating data from SQL Server version 7.0 is also supported using the same methods. Downgrading data to SQL Server 7.0 from SQL Server 2000 (64-bit) is not supported.

Documentation for Both SQL Server 2000 SP3 and SQL Server 2000 (64-bit)

This release of Books Online includes documentation for both SQL Server 2000 Service Pack 3 (SP3) and SQL Server 2000 (64-bit). The Books Online table of contents is organized by platform: 64-bit content is grouped together in a node entitled "SQL Server 2000 (64-bit)," and 32-bit topics are grouped together in a node called "SQL Server 2000."

Content specific to the 64-bit platform is identified below the topic title as follows: "This topic applies only to SQL Server 2000 (64-bit)." All 64-bit topics also include "64-bit" in the topic title. Topics that include content for SP3 changes in behavior include the following tag below the topic title: "New Information – SQL Server 2000 SP3." Not all 32-bit topics have been updated for SP3.

Index entries for 32-bit and 64-bit content have been combined. As a result, keyword searches may return a combined list of 32-bit and 64-bit topics. Topics that apply to the 64-bit SQL Server can be identified by the "64-bit" tag in the topic title, and also by the tag below the topic title that states, "This topic applies only to SQL Server 2000 (64-bit)."

Maintenance

Feature Maintenance

SQL Server 2000 (64-bit) uses Add or Remove Programs in Control Panel to fully support the addition and removal of individual features, as well as to remove instances of SQL Server. You can also use the Setup user interface or command line for installation maintenance. Feature maintenance for clustered installations is not supported.

Instance Maintenance

Maintenance activities on existing installations are supported with Add or Remove Programs in Control Panel as well as by the Setup program. Each installed instance (except for clustered installations) is listed in the Add or Remove Programs dialog box. Any non-cluster instance may be removed or changed with the Add or Remove Programs. Instance maintenance may also be performed on the setup command line by specifying features on the command line or in an .ini file. For information about cluster maintenance, see the section on failover clustering at the end of this topic.

Editions and Components

Supported Editions

For this release, only the Enterprise Edition is available. The SQL Server 2000 (64-bit) Desktop Engine is not available.

Network Libraries

The Network Library configuration page is not included in SQL Server 2000 (64-bit). Setup initially enables Shared Memory, Named Pipes, and TCP/IP. Use the SQL Server Network Utility to change the settings that enable or disable protocols. Configuration of Network Libraries is not supported in Setup, but is still supported by the SQL Server Network Utility. Configure client network libraries using the Client Network Utility (cliconfg.exe) included with the 64-bit versions of the Windows Server 2003 family.

Services

The Service Account dialog supports the SQL Server Service (MSSQLSERVER, MSSQL$<instancename>), the SQL Agent Service (SQLSERVERAGENT, SQLAgent$<instancename>), and the Analysis Services (MSSQLServerOLAPService) account. The Remote Account Information dialog supports the Cluster Setup Admin account for use when installing a virtual server. Command-line support for configuration of these accounts is also provided.

Code Samples

Code samples are not installed by Setup.

English Query

English Query is not supported.

Analysis Services

Analysis Services Integrated into SQL Server Setup

Analysis Services can be installed at the same time as the SQL Server relational database engine and other SQL Server components. It is part of the Windows Installer feature tree, in which you can select the features you want to include in your installation. Analysis Services appears in the feature tree with Data and SQL Repository child features.

Analysis Services Uses the SQL Server Repository

The 64-bit version of Analysis Services uses SQL Server instead of Jet (.MDB) for its meta data repository. If the full SQL Server is not installed with Analysis Services, the SQL Repository child feature installs the core SQL Server files and enables you to specify the location of these files.

Tools and Utilities

Graphical User Interface Management Tools

To administer a 64-bit SQL Server or Analysis Server with management tools like Enterprise Manager or Analysis Manager, you must use the 32-bit tools on a 32-bit server to remotely administer the 64-bit server. The only 64-bit tools included with this release are the Server Network Utility, the Service Manager, and the command line utilities.

Distributed Transaction Coordinator (DTC) Installed with the 64-bit versions of the Windows Server 2003 family

DTC is part of the 64-bit versions of the Windows Server 2003 family operating system and is no longer installed as part of the SQL Server 2000 (64-bit) setup. The DTC service can no longer be managed from the SQL Server Service Manager. To manage this service, use Services in the 64-bit versions of the Windows Server 2003 family Administrative Tools.

Data Transformation Services (DTS) components for 64-bit servers are not available in this release. Note the resulting functionality changes:

  • A DTS package can be saved on the 64-bit server, and a DTS package can be run against a SQL Server 2000 (64-bit) dataset, but the package must run from a 32-bit machine that is set up with SQL Server 2000 tools.

  • The Copy Database Wizard will not be able to run on a 64-bit server or target a 64-bit server. Data migration from SQL Server 2000 to SQL Server 2000 (64-bit) is supported. Attaching a 32-bit database to a 64-bit instance is possible by using either the detach/attach or the backup/restore technique. You can move databases back and forth between 32-bit and 64-bit versions of SQL Server.

  • If you are using Meta Data Services (MDS) to store a DTS package, you must manage and store the DTS package on a 32-bit server.

  • Transformable push subscriptions are not supported. Pull subscriptions from a 32-bit installation of SQL Server 2000 should work with a 64-bit Publisher or Distributor.

SQL Mail

SQL Mail is not supported in this release of SQL Server 2000 (64-bit). The following extended procedures and stored procedures are not supported, as they are part of the SQL Mail functionality:

  • xp_startmail

  • xp_stopmail

  • xp_sendmail

  • xp_readmail

  • xp_deletemail

  • xp_findnextmsg

  • sp_processmail

    However, SQL Agent Mail in SQL Server 2000 (64-bit) can be configured remotely by Enterprise Manager, if your client remotely connects using SQL Server 2000 Service Pack 3.0 or later.

    To configure SQL Agent Mail, you must use Microsoft Outlook® Express to use an existing mail account.

To create a mail account for SQL Agent Mail using Outlook Express

1. From the Start menu, select Outlook Express.

2. From the Tools menu, select Accounts. . .

3. On the Internet Accounts dialog box, click Add, and then click Mail. This will allow you to create a new mail account by launching the Internet Connection Wizard.

4. On the Your Name dialog box in the Display name box, enter the name you would like to be the sender of all SQL Agent e-mail messages.

5. On the Internet E-mail Address dialog box in the E-mail address box, enter the e-mail account to use to send SQL Agent e-mail messages. For example: someone@example.com.

6. On the E-mail Server Names dialog box in the My incoming mail server is a box, select POP3 for the server type.

7. In the Incoming mail (POP3, IMAP, or HTTP) server box, enter the name of the POP3 server. If you are only using this account for SQL Agent Mail, it is not necessary to select a valid POP3 server name, as SQL Agent Mail does not receive mail.

8. In the Outgoing mail (SMTP) server box, enter a valid SMTP server name to be used to send SQL Agent messages.

9. On the Internet Mail Logon dialog box in the Account Name box, enter the account you wish to use for sending SQL Agent Mail notifications.

10. Click Next.

11. Click Finish.

If you are using Outlook Express 6.0 or later, you must configure this application so that it does not send an alert when SQL Agent Mail is accessing your Outlook Express account.

To configure SQL Agent Mail with Outlook Express 6.0

1. From the Outlook Express Tools menu, select Options . . .

2. Select the Security tab, and clear the "Warn me when other applications try to send mail as me" check box.

3. Click OK.

If you already have an SMTP Outlook Express profile created, you can use that profile for SQL Agent Mail by setting it as the default account.

To use an existing SMTP Outlook Express Mail Account for SQL Agent Mail

1. From the Start menu, select Outlook Express.

2. From the Tools menu, select Accounts. . .

3. On the Internet Accounts dialog box, select the mail account to set as the default, and click the Set as Default button. This must be a POP3/SMTP account for SQL Agent Mail to work.

If you would like to change the name of your mail account after you have set it as the default, you can rename it to SQLAgentMail. The same mail account name will be used in configuring SQL Agent Mail in Enterprise Manager.

To change the name of your profile for SQL Agent Mail

1. From the Start menu, select Outlook Express.

2. From the Tools menu, select Accounts. . .

3. On the Internet Accounts dialog box, select the default account and click the Properties button.

4. On the Properties dialog box, type the name for the profile in the Mail Account box.

After you have created a mail account for SQL Agent Mail, you can configure SQL Agent Mail using Enterprise Manager.

To select the mail account in Enterprise Manager for SQL Agent Mail

1. On the Agent Properties dialog box, select the General tab.

2. In the Mail profile box, select the previously configured Outlook Express mail account.

For more information about SQL Agent Mail functionality, see the 32-bit SQL Server 2000 Books Online.

Client Tools Only

Installing only the Tools feature from the feature tree can facilitate a Client Tools Only installation. Note that the SQL Server graphical user interface management tools are not included with this release, except for the SQL Server Network Utility and the Service Manager. The command-line tools are available.

Supported Tools

Tools must be installed from the SQL Server 2000 (64-bit) RTM CD. Tools from any other CD cannot be installed as part of an instance of SQL Server 2000 (64-bit). To utilize management tools like Enterprise Manager, use a 32-bit instance of SQL Server where management tools are installed to remotely administer instances of SQL Server 2000 (64-bit).

Record Unattended File

A Template.ini file is provided and can be modified for unattended installations. SQL Server 2000 (64-bit) does not support the record unattended file functionality.

Development Tools

The Development Tools feature is not included in the feature tree. The SQL Debugging Interface (SDI) is installed by Setup, but is included in the core SQL Server Engine component. The other development tools available in SQL Server 2000 (32-bit) (headers and libraries, MDAC SDKs, and the Backup/Restore API) are not installed by Setup.

For more information on MDAC and the status of its components, see the MDAC Roadmap

DB-Library

The DB-Library programming model is not supported in SQL Server 2000 (64-bit), and it has not been ported to the 64-bit Windows operating system. The DB-Library API has not been enhanced beyond the level of SQL Server version 6.5. All DB-Library applications can work with SQL Server 2000, but only as 6.5-level clients. Features introduced in SQL Server 2000 and SQL Server version 7.0 are not supported for DB-Library applications.

Registry Rebuild and Rebuild Master

Registry Rebuild and Rebuild Master are implemented differently in the 64-bit version of SQL Server 2000 than in the 32-bit version. In the 64-bit version, SQL Server 2000 takes advantage of the self-repairing features provided by Windows Installer. In addition, the REINSTALL and REINSTALLMODE properties on the setup command line are available to explicitly rebuild the registry, reinstall corrupted or missing files, reinstall corrupted or missing shortcuts, and rebuild the master databases. These properties can be specified on the command line or in an .ini file.

Failover Clustering

Cluster Support

Installation of a failover cluster is supported for a single cluster definition. Feature maintenance for clustered installations is not supported. A template .ini file is provided that enables all supported cluster features.

Cluster Maintenance

Because only a single cluster definition is supported, feature maintenance with Add or Remove Programs in Control Panel for clustered installations is not supported. Clustered instances are displayed by Add or Remove Programs, but changes are not allowed. Setup supports adding or removing a node with either the graphical user interface or the command line. Setup also supports changing or adding an IP address. Cluster uninstall is supported by Setup.


Sending Feedback (64-bit)

We welcome your suggestions and comments about the documentation for this release of Microsoft® SQL Server™ 2000 (64-bit). You can send e-mail feedback about the documentation by clicking the mail icon at the top of the screen. General product support and feedback are not available through the documentation feedback process.


Additional Resources (64-bit)

If you have questions about the Microsoft® SQL Server™ 2000 (64-bit) Setup, you can access the microsoft.public.sqlserver.setup newsgroup on the msnews.microsoft.com news server to participate in discussions. You can also find peer-based support through this newsgroup.

Access to special newsgroups for this limited release is described in the agreement and instructions for the release.

The following table provides Web resources for additional information about Microsoft SQL Server.

For information on | Go to
Microsoft SQL Server | The Microsoft SQL Server Web site.
Analysis Services | The Analysis Services Web page on the Microsoft Web site.


Copyright Disclaimer (64-bit)

This document, including sample applications herein, is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including samples, URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user.

The primary purpose of a sample is to illustrate a concept, or a reasonable use of a particular statement or clause. Most samples do not include all of the code that would normally be found in a full production system, as a lot of the usual data validation and error handling is removed to focus the sample on a particular concept or statement. Technical support is not available for these samples or for the provided source code.

Unless otherwise noted, the example companies, organizations, products, people, and events depicted herein are fictitious and no association with any real company, organization, product, person, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

©1988-2002 Microsoft Corporation. All rights reserved.

Active Directory, ActiveX, BackOffice, CodeView, Developer Studio, FoxPro, JScript, Microsoft, Microsoft Press, Microsoft SQL Server, MSDN, MS-DOS, Outlook, PivotChart, PivotTable, PowerPoint, Visual Basic, Visual C++, Visual Studio, Win32, Win64, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Version: 8.00.002


Preparing to Install SQL Server 2000 (64-bit)

The topics in this section provide information that you may need to know during the installation of Microsoft® SQL Server™ 2000 (64-bit).

Topic | Description
Hardware and Software Requirements (64-bit) | Describes hardware and software required to install and run SQL Server 2000 (64-bit).
Product Specifications (64-bit) | Provides feature, capacity, configuration, and memory specifications for SQL Server 2000 (64-bit).
Working with Named and Multiple Instances of SQL Server (64-bit) | Provides background information to install a named instance or multiple instances of SQL Server.
File Paths for SQL Server 2000 (64-bit) | Provides the locations of files copied to the disk by Setup.
Creating Windows Service Accounts (64-bit) | Describes Microsoft Windows® service accounts required to run SQL Server services.
Features of SQL Server 2000 (64-bit) | Describes the features that can be included in a SQL Server 2000 (64-bit) installation.


Hardware and Software Requirements (64-bit)

The minimum hardware and software requirements for running Microsoft® SQL Server™ 2000 (64-bit) are listed in the following tables.

Hardware Requirements

This table shows hardware requirements for installing SQL Server 2000 (64-bit).

Hardware | Minimum requirements
Computer | Intel® Itanium™ and Itanium II processors with 64-bit CPU
Memory (RAM)1 | Enterprise Edition: 1 GB
Hard disk space2 | SQL Server database components: 190 to 320 MB Analysis Services: 230 MB Books Online only: 40 MB
Monitor | VGA or higher resolution 800x600 or higher resolution required for the SQL Server graphical tools
Pointing device | Microsoft Mouse or compatible
CD-ROM drive | Required

1 Additional memory may be required, depending on configuration and operating system requirements.
2 Actual requirements will vary based on your system configuration and the applications and features you choose to install.

Note SQL Server 2000 (64-bit) does not have a hardware compatibility list (HCL). If your computer meets the minimum requirements listed in the preceding table, SQL Server 2000 software should work on the hardware certified for use with the Microsoft Windows® operating system. For more information about hardware certified for use with the Windows operating system, see the Microsoft Windows Hardware Compatibility List at the Microsoft Web site

Operating System Requirements

You must use the 64-bit versions of the Windows® Server 2003 family operating system.

Internet Requirements

This table shows Internet requirements related to using SQL Server 2000 (64-bit).

Component | Requirement
Internet software | Microsoft Internet Explorer 6.0 is required to view the online documentation (HTML Help). This software is included with the 64-bit versions of the Windows Server 2003 family operating system.
Internet Information Services | If writing XML applications, see the System Requirements for IIS Virtual Directory Management topic in the SQL Server 2000 32-bit Books Online.

Network Software Requirements

The 64-bit versions of the Windows Server 2003 family have built-in network software.

Note TCP/IP must be enabled at the operating system level before installing SQL Server 2000 (64-bit). For more information, see Configuring Network Libraries (64-bit).

SQL Server 2000 (64-bit) activates the TCP/IP Sockets, Shared Memory, and Named Pipes libraries by default. To configure the network libraries after you set up SQL Server 2000 (64-bit), use the Server Network Utility (go to the Start menu, point to Programs, and click the Microsoft SQL Server program group).

Supported Clients

SQL Server 2000 (64-bit) supports the following clients: Windows XP Professional, Windows 2000 Professional, Windows NT® Workstation, Windows ME, Windows 98, Windows 95, Apple Macintosh®, OS/2, and UNIX. Macintosh, OS/2, and UNIX do not support the SQL Server graphical tools and require ODBC client software from a third-party vendor.


Product Specifications (64-bit)

Topic | Description
Features Supported by the Editions of SQL Server 2000 (64-bit)_ (64-bit) | The component features supported by different editions of Microsoft® SQL Server™ 2000 (64-bit).
Maximum Capacity Specifications (64-bit) | Maximum capacities supported by Microsoft SQL Server 2000 (64-bit).
Configuration Option Specifications (64-bit) | Minimum and maximum limits for computer resources managed by SQL Server 2000 (64-bit).
Memory Used by SQL Server Objects Specifications (64-bit) | Approximate memory requirements of objects


Features Supported by the Editions of SQL Server 2000 (64-bit)

This topic summarizes the features supported by the different editions of Microsoft® SQL Server™ 2000 (64-bit).

For more information about the amount of physical memory SQL Server 2000 can address, and the number of CPUs each edition supports in symmetric multiprocessor (SMP) computers, see Maximum Capacity Specifications (64-bit).

Database Engine Features Supported by the Editions of SQL Server 2000 (64-bit)

This table shows the database engine features and the editions of SQL Server 2000 (64-bit) that support them.

Database engine feature | Enterprise Edition
Multiple Instance Support | Supported
Failover Clustering | Supported
Failover Support in SQL Server Enterprise Manager | Supported
Log Shipping | Supported
Parallel DBCC | Supported
Parallel CREATE INDEX | Supported
Enhanced Read-ahead and Scan | Supported
Indexed Views | Supported
Federated Database Server | Supported
System Area Network (SAN) Support | Supported
Graphical DBA and Developer Utilities, Wizards | Partial Support
Graphical Utilities Support for Language Settings | Partial Support
Full-Text Search | Supported

Note SQL Mail is not supported in this release of SQL Server 2000 (64-bit). However, SQL Agent Mail in SQL Server 2000 (64-bit) can be configured remotely by Enterprise Manager, if your client remotely connects using SQL Server 2000 Service Pack 3.0 or later. For more information, see Differences Between 64-bit and 32-bit Releases (64-bit).

Replication Features Supported by the Editions of SQL Server 2000 (64-bit)

This table shows replication features and the editions of SQL Server 2000 (64-bit) that support them.

Replication feature | Enterprise Edition
Snapshot Replication | Supported
Transactional Replication | Supported
Merge Replication | Supported
Immediate Updating Subscriptions | Supported
Queued Updating Subscribers | Supported

The 64-bit edition of SQL Server 2000 does not support the following:

  • Microsoft Jet push subscriptions for merge replication, because a 64-bit version of the Microsoft Jet data provider is not available.

  • Transactional or snapshot push subscriptions for ODBC or OLE DB subscribers, unless the subscriber provides a 64-bit ODBC or OLE DB driver. Check with your vendor for availability of a 64-bit driver.

  • Transformable push subscriptions, because the necessary 64-bit Data Transformation Services (DTS) components are currently unavailable. Pull subscriptions from a 32-bit installation of SQL Server 2000 should work with a 64-bit Publisher or Distributor.
Analysis Services Features Supported by the Editions of SQL Server 2000 (64-bit)

This table shows the Analysis Services features and the editions of SQL Server 2000 (64-bit) that support them.

Analysis Services feature | Enterprise Edition
Analysis Services | Supported
User-defined OLAP Partitions | Supported
Linked OLAP Cubes | Supported
ROLAP Dimension Support | Supported
HTTP Internet Support | Supported
Custom Rollups | Supported
Calculated Cells | Supported
Writeback to Dimensions | Supported
Very Large Dimension Support1 | Supported
Actions | Supported
Real-time OLAP | Supported
Distributed Partitioned Cubes | Supported
Data Mining | Supported

1 With the 64-bit version of Analysis Services, it is not necessary to use the Very Large Dimension Manager (VLDM) to configure for very large dimensions. Because of the 64-bit virtual address space, Analysis Services handles very large dimensions automatically.


Maximum Capacity Specifications (64-bit)

The first table specifies maximum capacities that are the same for all editions of Microsoft® SQL Server™ 2000. The second and third tables specify capacities that vary by edition of SQL Server 2000 and the operating system.

This table specifies the maximum sizes and numbers of various objects defined in Microsoft SQL Server databases, or referenced in Transact-SQL statements. The table does not include the SQL Server 2000 Windows® CE Edition.

 | Maximum sizes/numbers
Object | SQL Server 2000 (32-bit) | SQL Server 2000 (64-bit)
Batch size | 65,536 * Network Packet Size1 | 65,536 * Network Packet Size1
Bytes per short string column | 8,000 | 8,000
Bytes per text, ntext, or image column | 2 GB-2 | 2 GB-2
Bytes per GROUP BY, ORDER BY | 8,060 | 8,060
Bytes per index | 900 | 9002
Bytes per foreign key | 900 | 900
Bytes per primary key | 900 | 900
Bytes per row | 8,060 | 8,060
Bytes in source text of a stored procedure | Lesser of batch size or 250 MB | Lesser of batch size or 250 MB
Clustered indexes per table | 1 | 1
Columns in GROUP BY, ORDER BY | Limited only by number of bytes | Limited only by number of bytes
Columns or expressions in a GROUP BY WITH CUBE or WITH ROLLUP statement | 10 | 10
Columns per index | 16 | 16
Columns per foreign key | 16 | 16
Columns per primary key | 16 | 16
Columns per base table | 1,024 | 1,024
Columns per SELECT statement | 4,096 | 4,096
Columns per INSERT statement | 1,024 | 1,024
Connections per client | Maximum value of configured connections | Maximum value of configured connections
Database size | 1,048,516 TB | 1,048,516 TB
Databases per instance of SQL Server | 32,767 | 32,767
Filegroups per database | 256 | 256
Files per database | 32,767 | 32,767
File size (data) | 32 TB | 32 TB
File size (log) | 32 TB | 32 TB
Foreign key table references per table | 253 | 253
Identifier length (in characters) | 128 | 128
Instances per computer | 16 | 16
Length of a string containing SQL statements (batch size) | 65,536 * Network packet size1 | 65,536 * Network packet size1
Locks per connection | Maximum locks per server | Maximum locks per server
Locks per instance of SQL Server | Up to approximately 16,000,000 (limited by memory) | Limited only by memory
Nested stored procedure levels | 32 | 32
Nested subqueries | 32 | 32
Nested trigger levels | 32 | 32
Nonclustered indexes per table | 249 | 249
Objects concurrently open in an instance of SQL Server4 | 2,147,483,647 per database (depending on available memory) | 2,147,483,647 per database (depending on available memory)
Objects in a database | 2,147,483,6473 | 2,147,483,6473
Parameters per stored procedure | 1,024 | 1,024
REFERENCES per table | 253 | 253
Rows per table | Limited by available storage | Limited by available storage
Tables per database | Limited by number of objects in a database3 | Limited by number of objects in a database3
Tables per SELECT statement | 256 | 256
Triggers per table | Limited by number of objects in a database3 | Limited by number of objects in a database3
UNIQUE indexes or constraints per table | 249 nonclustered and 1 clustered | 249 nonclustered and 1 clustered

1 Network Packet Size is the size of the tabular data scheme (TDS) packets used to communicate between applications and the relational database engine. The default packet size is 4 KB, and is controlled by the network packet size configuration option.
2 The maximum number of bytes in any key cannot exceed 900 in SQL Server 2000. You can define a key using variable-length columns whose maximum sizes add up to more than 900, provided no row is ever inserted with more than 900 bytes of data in those columns. For more information, see the Maximum Size of Index Keys topic in SQL Server 2000 32-bit Books Online.
3 Database objects include all tables, views, stored procedures, extended stored procedures, triggers, rules, defaults, and constraints. The sum of the number of all these objects in a database cannot exceed 2,147,483,647.

Maximum Numbers of Processors Supported by the Editions of SQL Server 2000 (64-bit)

SQL Server 2000 (64-bit) Enterprise Edition supports 32 processors on symmetric multiprocessing (SMP) computers.


Configuration Option Specifications (64-bit)

Microsoft® SQL Server™ 2000 contains improved algorithms for controlling computer resources. Many of the options that must be configured manually in earlier versions of SQL Server are managed dynamically in SQL Server 2000. These configuration settings can be viewed with the stored system procedure sp_configure.

Several configuration options are still specified in SQL Server 2000; however, instead of specifying the size of a static allocation, the options now specify the upper limit for the number of objects allocated dynamically as needed. These options are marked with an asterisk (*) in this table. The information in this table does not pertain to the SQL Server 2000 Windows® CE Edition.

 | SQL Server 2000 (32-bit) |  | SQL Server 2000 (64-bit)
Configuration values | Minimum | Maximum | Minimum | Maximum
affinity mask | -2,147,483,648 | 2,147,483,647 | -2,147,483,648 | 2,147,483,647
affinity64 mask |  |  | -2,147,483,648 | 2,147,483,647
allow updates | 0 | 1 | 0 | 1
AWE enabled1 | 0 | 1 | 0 | 1
c2 audit mode | 0 | 1 | 0 | 1
cost threshold for parallelism | 0 | 32,767 | 0 | 32,767
Cross DB Ownership Chaining | 0 | 1 | 0 | 1
cursor threshold | -1 | 2,147,483,647 | -1 | 2,147,483,647
default full-text language | 0 | 2,147,483,647 | 0 | 2,147,483,647
default language | 0 | 9,999 | 0 | 9,999
fill factor (percent) | 0 | 100 | 0 | 100
index create memory (K) | 704 | 2,147,483,647 | 704 | 2,147,483,647
IO_affinity_mask2 | -2,147,483,648 | 2,147,483,648 | -2,147,483,648 | 2,147,483,648
lightweight pooling | 0 | 1 | 0 | 1
locks | 5,000* | 2,147,483,647* | 5,000* | 2,147,483,647*
max degree of parallelism | 0 | 32 | 0 | 32
max server memory (MB) | 4 | 2,147,483,647* | 4* | 2,147,483,647*
max text repl size | 0 | 2,147,483,647 | 0 | 2,147,483,647
max worker threads | 10 | 32,767 | 32 | 32,767
media retention | 0 | 365 | 0 | 365
min memory per query (K) | 512 | 2,147,483,647 | 512 | 2,147,483,647
min server memory (MB) | 0* | 2,147,483,647* | 0* | 2,147,483,647*
nested triggers (bytes) | 0 | 1 | 0 | 1
network packet size | 512 | 65,535 | 512 | 65,536
open objects | 0* | 2,147,483,647* | 0* | 2,147,483,647*
priority boost | 0 | 1 | 0 | 1
query governor cost limit | 0 | 2,147,483,647 | 0 | 2,147,483,647
query wait (sec) | -1 | 2,147,483,647 | -1 | 2,147,483,647
recovery interval (min) | 0 | 32,767 | 0 | 32,767
remote access | 0 | 1 | 0 | 1
remote login timeout (sec) | 0 | 2,147,483,647 | 0 | 2,147,483,647
remote proc trans | 0 | 1 | 0 | 1
remote query timeout (sec) | 0 | 2,147,483,647 | 0 | 2,147,483,647
scan for startup procs | 0 | 1 | 0 | 1
set working set size | 0 | 1 | 0 | 1
show advanced options | 0 | 1 | 0 | 1
two digit year cutoff | 1,752 | 9,999 | 1,753 | 9,999
user connections | 0* | 32,767 (server)* 3 | 0* | 32,767 (instance)* 3
user options | 0 | 32,767 | 0 | 32,767

* Lower or upper limit for objects allocated dynamically.
1 This configuration parameter exists but is ignored by the 64-bit version of SQL Server 2000.
2 The IO affinity can be a hex, octal, or decimal string. On Win64™, the range can be 0 to 0xffffffffffffffff in hex, or 1 to 18446744073709551615 decimal. Invalid representations will be set to 0. Note: The IO_affinity_mask switch should be used in conjunction with the affinity mask configuration option. Users should not enable a CPU for both the IO_affinity_mask switch and affinity_mask options. See Microsoft Knowledge Base article Q298402 on the Microsoft Web site for additional detail.
3 The concurrent workload governor in SQL Server 2000 Personal Edition limits performance when more than 5 batches are executed concurrently.


Memory Used by SQL Server Objects Specifications (64-bit)

This table lists the approximate amount of memory used by different objects in Microsoft® SQL Server™ 2000.

 | Object Size
Object | SQL Server 2000 (32-bit) | SQL Server 2000 (64-bit)
Lock | 64 bytes plus 32 bytes per owner | 88 bytes plus 56 bytes per owner
Open database | 4848 bytes plus 1648 bytes per file and 336 bytes per file group | 4984 bytes plus 1720 bytes per file and 384 bytes per file group
Open object1 | 276 bytes plus 1824 bytes per index opened on the object2 | 376 bytes plus 1872 bytes per index opened on the object2
User connection | 12 KB + (3 * Network Packet Size)3 | 12 KB + (3 * Network Packet Size)3

1 Open objects include all tables, views, stored procedures, extended stored procedures, triggers, rules, defaults, and constraints.
2 Indexes can be opened on tables or views.
3 Network Packet Size is the size of the tabular data scheme (TDS) packets used to communicate between applications and the relational database engine. The default packet size is 4 KB, and is controlled by the network packet size configuration option.


Working with Named and Multiple Instances of SQL Server (64-bit)

With Microsoft® SQL Server™ 2000 (64-bit), you have the option of installing multiple copies, or instances, of SQL Server on one computer. When setting up a new installation of SQL Server 2000 or maintaining an existing installation, you can specify it as:

  • The default instance of SQL Server.

    This is the instance of SQL Server that is accessed by supplying the computer name as the name of the SQL Server. An installation does not have to have a default instance. However, if you install multiple instances on a single computer, only one instance can be the default instance. Applications using client software from earlier versions of SQL Server can connect to a default instance.

  • A named instance of SQL Server.

    A computer can run up to 15 named instances of SQL Server concurrently (16 instances including the default instance), as long as it has sufficient resources to support them. A named instance is identified by the network name of the computer plus an instance name, in the format computername\instancename, where instancename is the name provided for the instance during Setup. Most applications must use SQL Server 2000 client components to connect to a named instance. For naming rules, see Naming Instances (64-bit).

Each instance has its own separate folder for storing the server program files, and the data files for each instance can be placed wherever you choose. Each instance also has its own SQL Server Agent service. The tools for all instances are installed only once.

Multiple Instances

Multiple instances occur when you have more than one instance of SQL Server 2000 (64-bit) installed on one computer. Each instance operates independently from any other instance on the same computer, and applications can connect to any of the instances. The number of instances that can run on a single computer depends on resources available. The maximum number of instances supported in SQL Server 2000 (64-bit) is 16.

A named instance of SQL Server 2000 (64-bit) can be installed at any time: before, after, or instead of installing the default instance of SQL Server 2000 (64-bit). When you install SQL Server 2000 (64-bit) on a computer with no existing installations of SQL Server, Setup specifies the installation of a default instance. You can choose to install SQL Server 2000 (64-bit) as a named instance by choosing the Named Instance option in the Instance Name dialog box.

Each named instance is made up of a distinct set of services and can have completely different settings for collations and other options. The directory structure, registry structure, and service names all reflect the specific instance name you specify.

Service Names for Default and Named Instances

When you install a default instance of SQL Server, the service names are MSSQLServer and SQLServerAgent.

When you install a named instance of SQL Server, the service names are changed to:

  • MSSQL$instancename for the MSSQLServer service.

  • SQLAgent$instancename for the SQLServerAgent service.

The Microsoft Distributed Transaction Coordinator and Microsoft Search services are installed only once, and can be used simultaneously by every installed instance of SQL Server.

See Also

Naming Instances (64-bit)

Network Protocols for Named Instances (64-bit)


Network Protocols for Named Instances (64-bit)

The default network libraries for Microsoft® SQL Server™ 2000 (64-bit) are Named Pipes, Shared Memory, and TCP/IP. Additional protocols can be added, but Multiprotocol, Banyan VINES, and AppleTalk are not supported. When you install a default instance of SQL Server 2000, the standard network addresses are enabled. For example, Named Pipes uses \\.\pipe\sql\query, and TCP/IP sockets connect to port 1433.

When you select a named instance, only the Named Pipes and TCP/IP protocols are supported. Named Pipes defaults to a network address of \\.\pipe\MSSQL$instancename\Sql\Query. The port address used by TCP/IP is chosen dynamically by default the first time the instance is started.

This release of the 64-bit version of SQL Server 2000 does provide for configuring network libraries during Setup. After you install SQL Server 2000, you can use the SQL Server Network Utility to configure the network libraries. Refer to SQL Server 2000 Books Online for additional information about configuring the network libraries.

See Also

Working with Named and Multiple Instances of SQL Server (64-bit)

Configuring Network Libraries (64-bit)


File Paths for SQL Server 2000 (64-bit)

An installation of Microsoft® SQL Server™ 2000 (64-bit) can consist of one or more separate instances. These can consist of the default instance and/or one or more named instance. An instance, default or named, has its own set of program and data files as well as common files. The following illustration shows file locations for SQL Server 2000 (64-bit) installed with the default instance and one named instance, Instance1. Both instances have a full set of data and executable files. Common files used by both the default instance and any named instances are installed in the folder systemdrive\Program Files\Microsoft SQL Server\80.

The following figure shows the default locations for installing SQL Server in systemdrive\Program Files\Microsoft SQL Server, normally on drive C.

The location for both the program and data files for the default instance of SQL Server is systemdrive\Program Files\Microsoft SQL Server\Mssql. The default location for the named instance in this case is systemdrive\Program Files\Microsoft SQL Server\Mssql$Instance1. During setup, you can specify a different file path for both the program and the data files. Setup also installs files in the Microsoft Windows® system folder. The location for these system files cannot be changed.

The remainder of this topic details locations for files installed by Setup for SQL Server 2000 (64-bit).

Program and Data File Locations

The program folder is the root folder where Setup creates folders for program and other files that typically do not change as you use SQL Server. These folders do not contain data, log, or backup files, or replication data, so the space required by these files does not change greatly.

Note Data and program files cannot be installed on a removable disk drive.

This data file is the root folder where Setup creates folders that contain database and log files, as well as directories for the system log, backup, and replication data. Setup creates database and log files for the master, model, tempdb, msdb, pubs, and Northwind databases. The SQL Server data file path should be located on a drive with free space available for these files to grow.

Note Data files cannot be installed on a file system using compression.

Each instance of SQL Server has its own program and data files.

Data and Program File Locations for the Default Instance of SQL Server

For the default instance of SQL Server, the default SQL Server program and data folder name (Mssql) is used as the default instance name in the folder that you specify. If you do not specify a location, this is normally in the systemdrive\Program Files\Microsoft SQL Server\ folder. For the default instance of SQL Server, the default directories are:

  • systemdrive\Program Files\Microsoft SQL Server\Mssql\Binn (for program files)

  • systemdrive\Program Files\Microsoft SQL Server\Mssql\Data (for data files)

During setup, you can change the location for the default instance. For example, if you specify that the default instance be installed at D:\MySqlDir, the file paths are:

  • D:\MySqlDir\Mssql\Binn (for program files)

  • D:\MySqlDir\Mssql\Data (for data files)
Data and Program File Locations for a Named Instance of SQL Server

Each named instance of SQL Server has a specific location for its program files and another for its data files. These file locations are different from those of the default instance of SQL Server.

Note A named instance is not necessarily the same as a multiple instance. You can have a single named instance or you can have multiple named instances. For more information, see Working with Named and Multiple Instances of SQL Server (64-bit).

For each named instance of SQL Server that you install, with the name instancename, the default directories are:

  • systemdrive\Program Files\Microsoft SQL Server\MSSQL$instancename\Binn (for executable files).

  • systemdrive\Program Files\Microsoft SQL Server\MSSQL$instancename\Data (for data files).

You can specify file paths other than the default locations for program and data file for named instances. For example, if you specify that the instance named "AnInstance" be installed at D:\MySqlDir, the paths are:

  • D:\MySqlDir\MSSQL$AnInstance\Binn (for program files)

  • D:\MySqlDir\MSSQL$AnInstance\Data (for data files)
File Locations for Shared Tools

Shared tools are installed by default at systemdrive\Program Files\Microsoft SQL Server\80\Tools. This folder contains files shared by all instances of SQL Server 2000, both the default and any named instances of SQL Server. Tools include this help file (Setupsql.chm), Dev Tools, and other components.

Shared tools that are still in the 32-bit format but used by the 64-bit version of SQL Server are located in systemdrive\Program Files (x86)\Microsoft SQL Server\80\Tools. These files include all of Books Online for SQL Server 2000. This location cannot be changed.

Analysis Services File Locations

Analysis Services includes program files, data files, and the meta data repository. The default location for Analysis Services program files is systemdrive\Program Files\Microsoft Analysis Services\Bin. The default location for the data files is systemdrive\Program Files\Microsoft Analysis Services\Data. The Data folder stores multidimensional data for the objects defined on the Analysis server.

The default locations for both the program and data folders can be changed during setup. However, Analysis Services should not be installed to a folder that uses characters from a double-byte character set (DBCS) in the path or folder name. Install Analysis Services to a folder that uses only single-byte characters in the path and folder name.

In SQL Server 2000 (64-bit), Analysis Services uses SQL Server to host its repository (OLAPRepository.mdf), which stores meta data for objects stored on the Analysis server. The default location for the repository database file is systemdrive\Program Files\Microsoft SQL Server\Mssql$instancename\data, where instancename is the name of the instance with which you install Analysis Services.

Note The Setup program allows installation of only one copy of Analysis Services with a single instance. With the installation of subsequent instances, Analysis Services does not appear on the Feature Selection page of Setup.

When you install Analysis Services, the Setup program also installs the core SQL Server program files to support the Analysis Services repository, even if you do not install the SQL Server components. If you do not want SQL Server and Analysis Services to share the same core SQL Server program files, install Analysis Services in one instance and SQL Server in another instance.

Specifying File Paths

During Setup you can change the installation path for the following features:

Feature | Default path1,2
SQL Server |
Server Components | \Program Files\Microsoft SQL Server
Data Files | \Program Files\Microsoft SQL Server\Mssql\Data
Analysis Services |
Analysis Server | \Program Files\Microsoft Analysis Services
Data Files | \Program Files\Microsoft Analysis Services\Data
SQL Repository3 | \Program Files\Microsoft SQL Server\Mssql\
Data Files4 | \Program Files\Microsoft SQL Server\Mssql\Data

1 The default paths shown here are for the default instance. For a named instance, Mssql changes to Mssql$instancename, where instancename is the name of the instance.
2 The default drive for these locations is systemdrive, normally drive C.
3 Specifies the location of the SQL Server program files (if you do not select to install SQL Server Server Components). For more information, see Analysis Services (64-bit).
4 Specifies the location for the Analysis Services repository database. For more information, see Analysis Services (64-bit).

Note When adding features to an existing installation, you cannot change the location of a previously installed feature, nor can you specify the location for a new feature.

When you specify an installation path during Setup for the server components or data files, the Setup program uses the instance name in addition to specified location for program and data files. Setup does not use the instance name for tools and other shared files. Setup also does not use any instance name for the Analysis Services program and data files, although it does for the Analysis Services repository.

Finding Install Locations

If you are uncertain about instance paths, the following registry key provides the path for any named instance:

HKLM\Software\Microsoft\Microsoft SQL Server\instancename\Setup\SQLPath

The following registry key provides the path for the default instance:

HKLM\Software\Microsoft\MSSQLServer\Setup\SQLPath

You can use the REG QUERY tool available with the 64-bit versions of the Windows® Server 2003 family operating system to query the registry and get the installation path of a particular instance. Run the following at the command prompt, inserting the appropriate instance name:

REG QUERY HKLM\Software\Microsoft\Microsoft SQL Server\instancename\Setup /v SQLPath

Or run the following command for the default instance:

REG QUERY HKLM\Software\Microsoft\MSSQLServer\Setup /v SQLPath

For more information about the REG QUERY tool command syntax, type REG QUERY /? on the command line.


Creating Windows Service Accounts (64-bit)

Microsoft® SQL Server™ 2000 (64-bit) has three service accounts on the 64-bit versions of the Windows® Server 2003 family operating system: Microsoft SQL Server, SQL Server Agent, and Analysis Services. These services appear in the list of installed services in Services, in Administrative Tools, which you can find in Control Panel. The following table shows each service name and the term used to refer to the default and named instances of SQL Server, as displayed in Services.

Service | Default Instance | Named Instance
Microsoft SQL Server | MSQLSERVER | MSSQL$instancename
SQL Server Agent | SQLSERVERAGENT | SQLAgent$instancename
Analysis Services | MSSQLServerOlapService |

Typically, these services are assigned the same user account, either the local system account or a domain user account. However, during Setup you can customize the settings for each service.

Using the Local System Account

The local system account does not require a password, does not have network access rights, and restricts your SQL Server installation from interacting with other servers.

Using a Domain User Account

A domain user account uses Windows Authentication so that the same login used for connecting to the network is also used for connecting to SQL Server. A domain user account is typically used because many server-to-server activities can be performed only with a domain user account. For example:

  • Remote procedure calls.

  • Replication.

  • Backing up to network drives.

  • Heterogeneous joins that involve remote data sources.

  • Analysis Services linked cubes.
Requirements for Domain User Account

All domain user accounts must have permission to:

  • Access and change the SQL Server folder (\Programs Files\Microsoft SQL Server\Mssql).

  • Access and change the .mdf, .ndf, and .ldf database files.

  • Log on as a service.

  • Read and write registry keys at and under:
    • HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer (default instance)

    • HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server (any named instance)

    • HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\MSSQLServer (default instance)

    • HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\MSSQL$Instance (any named instance)

    • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Peflib

Analysis Services domain accounts should have the following permissions:

  • Access and change the Analysis Services folder (Program Files\Microsoft Analysis Services\).

  • Log on as a service.

  • Read and write registry keys at and under:
    • HKEY_LOCAL_MACHINE\Software\Microsoft\OLAP Server

    • HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\MSSQLServerOLAPService

In addition, a domain user account must be able to read and write corresponding registry keys for these services: SQLAgent$instancename, MSSEARCH, and MSDTC.

This table shows additional permissions required for specified functionalities.

Service | Permission | Functionality
SQL Server | Network write privileges | Write to a mail slot using xp_sendmail.
SQL Server | Act as part of operating system and replace a process level token | Run xp_cmdshell for a user other than a SQL Server administrator.
SQL Server | Member of local Power Users or local Administrators group | Add and delete SQL Server objects in Active Directory.
SQL Server Agent | Member of the local Administrators group | Create CmdExec and ActiveScript jobs belonging to someone other than a SQL Server administrator. Use the auto restart feature. Use run-when-idle jobs.
MSSQLServerOLAPService | Member of the OLAP Administrators group | To use the Analysis Manager 2000 administration tool.

Changing User Accounts

To change the password or other properties of any SQL Server related service after installing SQL Server, go to Control Panel, click Administrative Tools, and then click Services. If you are administering the 64-bit Server remotely from a 32-bit SQL Server, you can also use SQL Server Enterprise Manager. If you change the Windows password for any service account, be sure to also change the password setting for the service. A service that logs on to a user account cannot start without the current password setting for the account.


Features of SQL Server 2000 (64-bit)

During setup of Microsoft® SQL Server™ 2000 (64-bit), you can choose features and subfeatures to install, to remove, or to add if not included in an initial installation of SQL Server. Before you begin the Setup Wizard, familiarize yourself with the different features and decide which ones are appropriate for your installation.

  • SQL Server Management Tools (64-bit)

  • Server Components (64-bit)

  • Analysis Services (64-bit)

  • Books Online (64-bit)
Choosing Features and Options to Install

SQL Server can be used in a number of different contexts; not all features and options of SQL Server are needed for every installation. You may have a database server, an Internet server, or require a database on a client computer. If you are running database client/server applications you may or may not require a database on your computer. You may need tools to administer a database server, or you may want to run applications that access an instance of SQL Server. You may want an Analysis server for online analytical processing (OLAP) and data mining. Installation choices for these and other SQL Server configurations are described in the following paragraphs.

Installing SQL Server on a Database Server

If you are creating a database server, install SQL Server 2000 (64-bit) Enterprise Edition. On a 64-bit database server, you can install a default instance of the SQL Server 2000 (64-bit) relational database engine. You can also install one or more named instances of the SQL Server 2000 (64-bit) relational database engine. Other than specifying an instance name, the setup choices for installing a named instance are similar to those for installing a default instance.

Using SQL Server with an Internet Server

On an Internet server, such as a server running Microsoft Internet Information Services (IIS), you typically install the SQL Server 2000 Management Tools. SQL Server 2000 (64-bit) does not include graphical tools (other than the Server Network Utility and the Service Manager), but it does support the same command-line tools that are supported by the 32-bit version of SQL Server 2000. These include the client connectivity features used by an application connecting to an instance of SQL Server. In addition, the client tools include the utility for configuring the virtual roots needed for applications to access SQL Server through URLs.

After installing the SQL Server tools, configure the virtual roots that support accessing an instance of SQL Server through a URL. For more information about configuring the virtual roots, see the "Using IIS Virtual Directory Management for SQL Server Utility" topic (64-bit) in the SQL Server 2000 32-bit Books Online.

Note Although you can install an instance of SQL Server on a computer running IIS, this is typically not recommended and may be done only for small Web sites that have a single server computer. Most Web sites have their middle-tier IIS system on one server or cluster of servers, and their databases on a separate server or federation of servers. For more information about federations, see the "Federated SQL Server 2000 Servers" topic in SQL Server 2000 32-bit Books Online.

Installing Analysis Services

If you require an Analysis server for online analytical processing (OLAP) and data mining, install Analysis Services. You can choose to install Analysis Server, which comes with SQL Server. The SQL Server 2000 (64-bit) Analysis Services uses a SQL Server repository, so Setup always installs Analysis Services with an instance of SQL Server including the core SQL Server program files, even if you choose not to install the SQL Server database components. If you want SQL Server and Analysis server on the same computer, but sharing different core database server files, then install them separately in separate instances.


SQL Server Management Tools (64-bit)

These features can be installed from the Management Tools category on the Select Features page of the Installation Wizard. Management tools are included when the option for Client Tools Only is selected as an initial installation choice.

Server Network Utility

Used to manage the server Net-Libraries.

Service Manager

Used to start, stop, and pause the Microsoft® SQL Server™ components on the server.

Command Prompt Utilities

Used to manage the SQL Server components and databases on the server from the command line.

Location1 | Utilities
\Program Files\Microsoft SQL Server\80\Tools\Binn | Bcp osql scm
\Program Files\Microsoft SQL Server\80\COM | distrib logread qrdrsvc replmerg snapshot
\Program Files\Microsoft SQL Server\MSSQL\Binn also \Program Files\Microsoft SQL Server\MSSQL$instancename\Binn | sqlagent sqlmaint sqlsrvr

1 The default drive for these locations is systemdrive, normally drive C.

Unsupported Tools

Other server management tools available with the 32-bit versions of SQL Server (such as SQL Server Enterprise Manager, SQL Server Profiler, SQL Query Analyzer, MS DTC Client Support, and Conflict Viewer) are not supported in this release of SQL Server 2000 (64-bit). You can use them with a 32-bit installation of SQL Server 2000 on a 32-bit machine in order to remotely manage a SQL Server 2000 (64-bit) installation. For additional information, see Configuring SQL Server 2000 (64-bit).

See Also

Specifying SQL Server Features (64-bit)


Server Components (64-bit)

Choosing to install the Server Components installs the Microsoft® SQL Server™ relational database engine and other core tools. If any SQL Server program files are installed, the SQL Server component must be installed.

Note When installing the SQL Server component, the Setup program also installs the bcp, isql, and osql utilities, ODBC, OLE DB, and DB-Library.

Data Files

Specifies the location for the SQL Server catalog files. This specifies the root location where Setup creates the folders that contain database and log files, as well as directories for the system log, backup, and replication data. Setup creates database and log files for the master, model, tempdb, msdb, pubs, and Northwind databases. For an instance installed with Analysis Services, it can also contain the OLAPRepository and Foodmart 2000 databases as well as the Analysis Services query log OLAPQueryLog (see the Analysis Services (64-bit) component for more information).

Full-Text Search

Installs the Microsoft full-text search engine (Microsoft Search service), which extends the ability to search on character columns beyond the basic equality and LIKE operators.

See Also

Specifying SQL Server Features (64-bit)


Analysis Services (64-bit)

Microsoft® SQL Server™ 2000 Analysis Services is a server for online analytical processing (OLAP) and data mining. Analysis Services manages multidimensional cubes of data for analysis and provides rapid client access to cube information.

Setup installs only one copy of Analysis Services with a single instance of SQL Server 2000. If you run Setup again to install an additional instance of SQL Server 2000, Setup does not display Analysis Services in the feature tree. Analysis Services uses that instance of SQL Server 2000 to support its meta data repository. Analysis Services is not otherwise limited to a single instance of SQL Server 2000, and it can connect to not only any instance of SQL Server but to any ODBC or OLE DB data source.

In this release of SQL Server 2000 (64-bit), the Analysis Services management tools are not included. To administer Analysis Services remotely, use a 32-bit version of SQL Server 2000 Analysis Services installed on a 32-bit computer.

Data Files

This is a required option for the path to the Analysis server data files.

SQL Repository

Analysis Services uses SQL Server for a repository to store its object meta data (cubes, dimensions, and so on). By default, this database is located as follows:

systemdrive\Program Files\Microsoft SQL Server\MSSQL$instancename\Data\OLAPRepository.mdf

$InstanceName specifies the instance name for a named instance of SQL Server 2000 (omitted for the default instance). The SQL Repository option in Setup allows you to change the location for these data files.

When you choose to install Analysis Services, Setup installs the Analysis Services program files and the SQL Server Desktop Engine. If you choose to install both the Server Components and Analysis Server, Analysis server will use the database server program files installed with that instance of SQL Server to support its repository. If you do not wish to have the SQL Server database server and Analysis Services share the same SQL Server program files, you can install separate copies of the SQL Server program files by performing two installations, one with SQL Server only and one with Analysis Services only.

SQL Server 2000 (64-bit) Analysis Services does not include Analysis Manager. You can manage the 64-bit version of Analysis Services remotely from a 32-bit version of Analysis Manager 2000 installed on a 32-bit computer. However, to administer Analysis Server remotely, your user name must be in the Administrators group or the OLAP Administrators group on the 64-bit Windows® operating system.

Data Files

Data Files under the SQL Repository option in Setup specifies the location for the repository. Note that when installed in the same instance, the Server Components Data Files and the Analysis Services SQL Repository Data Files also use the same Installation path setting; so changing one of these settings changes the other.

Client Components

Installs the client components for Analysis Services. These are binary executables and related files for the Analysis Services client.

See Also

Locating Folders and Files (64-bit)

Specifying SQL Server Features (64-bit)


Books Online (64-bit)

The SQL Server Books Online feature of the Microsoft® SQL Server™ 2000 (64-bit) installation includes both the full SQL Server Books Online for SQL Server 2000 and online Help. Online Help is available by clicking the Help button or pressing the F1 key in dialog boxes and interface elements. Another way of obtaining the full SQL Server Books Online for SQL Server 2000 is to download it from the SQL Server Product Documentation page at the Microsoft Web site.

Selecting to install this feature installs the complete documentation set on your local drive in the default shared tools locations: systemdrive\Program Files (X80)\Microsoft SQL Server\80\Tools\Books\1033. To view Books Online, click Start, point to Programs, point to Microsoft SQL Server, and then click Books Online.

How to access SQL Server Books Online

SQL Setup

How to access SQL Server Books Online for SQL Server (64-bit)

Note In this release of Microsoft SQL Server 2000 (64-bit), the Books Online available on the Start menu is from the 32-bit SQL Server 2000 product. Most of the documentation applies for both the 32-bit and 64-bit products. Documentation specific to the 64-bit product is contained in the Setupsql.chm file (located in systemdrive\Program Files\Microsoft SQL Server\80\SetupBootstrap\Help\1033\).

See Also

Specifying SQL Server Features (64-bit)


Installing SQL Server 2000 (64-bit)

Read this | To
Overview | Read a quick summary of the steps involved in the Microsoft® SQL Server™ 2000 (64-bit) Setup, and how long the process takes. The remaining topics are ordered in the setup sequence.
Starting Setup (64-bit) | Start the installation of SQL Server or any of its features.
Specifying SQL Server Features (64-bit) | Specify the SQL Server features to install.
Naming Instances (64-bit) | Specify whether to install the default instance or a named instance, and the name for a named instance.
Specifying Service Accounts (64-bit) | Specify accounts used to run the services corresponding to the features that you are installing.
Defining the Authentication Mode (64-bit) | Specify whether to use Windows Authentication only or to allow both Windows and SQL Server Authentication to verify users.
Specifying the Collation Setting (64-bit) | Modify the collation settings for your SQL Server installation.
Choosing the Licensing Mode (64-bit) | Choose whether to use per-seat or per-processor licensing.


Overview (64-bit)

To install any or all of the features of Microsoft® SQL Server™ 2000 (64-bit), use the Windows Installer service, which is common to many Microsoft products. Windows Installer enables you to use the Add or Remove Programs option in Control Panel to add or remove features in an existing installation. You can also run Setup.exe on the SQL Server 2000 (64-bit) compact disc to install SQL Server 2000 (64-bit) or to modify an existing installation. Users should run Setup.exe for an initial installation so that bootstrap files get installed on the destination machine.

If you wish to install a new instance of SQL Server 2000 (64-bit), specify in the Installation Wizard that you are installing a new instance of SQL Server rather than working with an existing instance, enter registration information, and review the End User License Agreement (EULA). You then select the server features that you want to install. Then, depending on your previous selections, you may provide an instance name, specify service accounts, specify the authentication mode, make any changes to the collation settings, choose the appropriate licensing model, and confirm your setup.

The entire process for setup on a nonclustered server takes about 15 to 20 minutes. The lengthiest part of installation, along with the copying of files, is building and configuring the SQL Server master database, which stores configuration information and information about all other databases, as well as many system stored procedures.

Copying the master database occurs automatically, so if you accept the default collation, the Installation Wizard simply copies a mostly prebuilt master database from the Master.mdf and Mastlog.ldf files on the CD-ROM. The Installation Wizard completes this task with some additional configuration for your particular setup. Setup can take longer if you do not accept the default collation. If you change the default collation setting, the Installation Wizard will reindex the master database.


Starting Setup (64-bit)

This topic describes how to start installing Microsoft® SQL Server™ 2000 (64-bit) or its features on a single server. For installing SQL Server on a clustered server, see Failover Clustering (64-bit).

To start Setup using the SQL Server 2000 (64-bit) CD-ROM, insert the disk in the CD-ROM drive. You can launch the Installation Wizard by running Setup.exe in the root folder of the product CD. To run Setup from a network drive, navigate to the installation location on the shared drive, and then run Setup.exe.

If this is the first installation of SQL Server on the local server, Setup displays the Welcome page. If Setup detects that SQL Server has already been installed on the local server, the first page of the wizard provides the following two options for the installation.

Choose this | To
Start a new installation | Install a local instance of SQL Server or, if a cluster is detected, a failover cluster. This release of SQL Server 2000 (64-bit) supports installation only on the local machine.
Work with an existing installation | Change or remove an existing instance of SQL Server 2000 (64-bit).

For more information about working with an existing installation, see Maintaining a SQL Server Installation (64-bit).

For a new or additional instance of SQL Server or any of its features, select the option to Start a new installation. To install an instance on the local computer, choose Local Instance in the box, and click Next to display the Welcome page.

On the Welcome page, click Next to display the Registration Information page of the wizard. On the Registration Information page, enter your name. When installing on a network server, you can provide the name of a user responsible for using or administering the server. You can also enter your company name, although it is not required.

To complete the Registration Information page, you must enter the 25-character product key. (You can find the product key on the yellow sticker in the CD liner notes or the CD sleeve). For a network installation, request the product key from the network or SQL Server administrator. This option is displayed only for the first installation on a server.

The next page of the wizard displays a standard Microsoft Software License Agreement. Read the agreement and click Yes to accept it and continue Setup. If you choose not to accept the terms of the agreement, click No and the Installation Wizard will close.

After you accept the terms of the Software License Agreement, the Installation Wizard displays the Feature Selection page, on which you choose the program features to install. For details about your choices, see Specifying SQL Server Features (64-bit).

See Also

Working with Named and Multiple Instances of SQL Server (64-bit)

Setup Mode (64-bit)

Registration Information (64-bit)


Specifying SQL Server Features (64-bit)

Use the Feature Selection page of the Installation Wizard to select the features to include in an installation of SQL Server 2000 (64-bit). The features are displayed in a tree showing features and subfeatures. Expand any feature with a plus sign (+) next to it to view subfeatures. When you select a feature, the feature description pane displays more information about the feature, including the disk space it requires. It also shows the disk space required by any subfeatures that you have selected to install with the parent feature.

To change whether to install a feature during setup, click the icon for the feature and then select one of the following options:

Will be installed on local hard drive

Installs the selected feature, but permits you to choose not to install optional subfeatures under it.

Entire feature will be installed on local hard drive

Installs the selected feature and any subfeatures under it.

Entire feature will be unavailable

Removes the selected feature and all subfeatures under it from the installation. This option does not appear on the menu when a subfeature is required by its parent feature.

To assess the space required by a feature and the available disk space on different drives, first select the feature and then click Disk Cost. When you select a feature associated with an installation path, the path appears under Installation path. To change where Setup puts the files for the feature, click Browse and specify a different location.

The following features are available for installation by the Installation Wizard. By default, all these features are initially selected for installation.

SQL Server Management Tools

Select this feature to install server tools to create a relational database server with administrative capabilities.

Server Components

Select this feature to install the SQL Server relational database engine and other core tools. If you select either the Data Files or Full-Text Search Engine subfeatures, you will also automatically install the SQL Server feature as well.

Analysis Services

Select this feature to install SQL Server 2000 Analysis Services, which includes online analytical processing (OLAP) and data mining. The Analysis Server will install its own process, MSSQLServerOLAPService, separate from the 64-bit SQL Server process. Although Analysis Services can connect to multiple instances of SQL Server running on a single computer, you cannot install multiple instances of Analysis Services on a single computer. Analysis Services will appear in the feature tree until it is installed on the server. Analysis Services uses the SQL Server program files associated with the instance with which it was installed to support its repository.

Books Online

Select this feature to install the online documentation for SQL Server 2000. This documentation can be opened from the Start menu by choosing Books Online in the Microsoft SQL Server program group.

See Also

Feature Selection (64-bit)

File Paths for SQL Server 2000 (64-bit)


Naming Instances (64-bit)

Client applications must connect to an instance of Microsoft® SQL Server™ 2000 (64-bit) to work with a database. Each instance is made up of a distinct set of services and can have completely different settings for collations and other options. The directory structure, registry structure, and service names all reflect the specific instance name you identify during setup. An instance can be either the default instance or a named instance.

Use the Setup Mode page of the Installation Wizard to specify whether to install the default instance or a named instance. The default instance is identified by the network name of the computer on which it is running and does not require a client to specify the name of the instance to make a connection. A named instance is identified by the network name of the computer plus the instance name, in the format computername\instancename.

Multiple Instances

SQL Server 2000 (64-bit) supports multiple instances on a single server or processor. A computer can run multiple instances of SQL Server concurrently, and each instance runs independently of other instances. A server can have only one default instance of SQL Server, but multiple named instances up to the resources available on the computer. The maximum number of instances supported in SQL Server 2000 (64-bit) is 16.

Note SQL Server 2000 (64-bit) Enterprise Edition licenses permit multiple instances of SQL Server without additional licenses. Other editions may technically support multiple instances but require a separate license for each instance installed on a server. For complete details, refer to the licensing agreement packaged with your product.

A named instance can be installed either as the first or only instance, or in a subsequent installation of SQL Server. The first time you install SQL Server 2000 (64-bit) on a computer with no existing installations of SQL Server, Setup specifies the installation of the default instance, although you can choose to install SQL Server as a named instance without installing the default instance first.

Creating a Named Instance

To create a named instance, choose Named instance on the Instance Name page of the Installation Wizard and type an instance name. An instance name must begin with a letter or an underscore (_), and can contain numbers, letters, or other characters. SQL Server sysnames and reserved keywords should not be used as instance names. For example, the term "default" should not be used as an instance name because it is a reserved keyword used by Setup.

Instance Naming Rules

Complete rules for naming an instance are as follows:

  • An instance name is not case-sensitive.

  • Instance names must follow the rules for SQL Server identifiers and cannot be reserved keywords (for example, an instance name cannot be the terms "default" or "MSSQLServer").

  • Acceptable letters are those defined by Unicode Standard 2.0, which includes Latin characters a-z and A-Z, in addition to letter characters from other languages. For details, see The Unicode Standard page at the Unicode Web site.

  • The first character of an instance name must be a Unicode Standard letter, an underscore (_), or a number sign (#).

  • Subsequent characters in an instance name can be Unicode Standard letters, decimal numbers from Basic Latin or other national scripts, the dollar sign ($), a number sign (#), or an underscore (_).

  • The following characters are not allowed in instance names: embedded spaces, special characters, the backslash (\), the comma (,), the colon (:), or the "at" sign (@).

See Also

Instance Name (64-bit)

Working with Named and Multiple Instances of SQL Server (64-bit)


Specifying Service Accounts (64-bit)

Use the Service Account page of the Installation Wizard to specify Setup login accounts to the following Microsoft® SQL Server 2000™ services.

Service | Description
SQL Server (MSSQLSERVER, or MSSQL$instancename for a named instance) | Provides the core relational database functionality of SQL Server.
SQL Server Agent (SQLSERVERAGENT, or SQLAgent$instancename for a named instance) | Provides the capability to schedule regular commands, schedule replication, supply a method for dealing with errors, contact SQL Server operators when errors occur, as well as other support functions.
Analysis Services (MSSQLServerOLAPService) | Provides the Analysis Services engine for OLAP and data mining functionality. Although Analysis Services is installed with an instance and uses the core relational functionality provided by that instance, it is installed in a separate location and is not identified using the instance name. Analysis Services can be installed with only one instance of SQL Server 2000 (64-bit) on a server.

During Setup, you can configure these services to use one of the following Microsoft Windows® accounts:

  • Local system account

  • Local user account

  • Domain user account

You can specify the same account for all the services or a different account for each of the services. The selection you use depends on the functionality required of your SQL Server 2000 (64-bit) installation.

Local System Account

SQL Server 2000 (64-bit) can be run using the local system account if SQL Server does not require access to network resources and is not configured for replication. The following permissions must be set for the local system account for SQL Server 2000 (64-bit) to perform its tasks correctly:

For the default instance

  • Full control on the Microsoft SQL Server folder, by default:
    • systemdrive\Program Files\Microsoft SQL Server\MSSQL
  • Full control of all .mdf, .ndf, and .ldf database files.

  • Full control on the registry keys at and under:
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server

    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER

For a named instance

  • Full control on the Microsoft SQL Server folder, by default:
    • systemdrive\Program Files\Microsoft SQL Server\MSSQL$instancename
  • Full control of all .mdf, .ndf, and .ldf database files.

  • Full control on the registry keys at and under the following:
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server

    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQL$instancename

For the Analysis Services service

  • Full control on the Microsoft Analysis Services folder, by default:
    • systemdrive\Program Files\Microsoft Analysis Services
  • Full control on the registry keys at and under the following:
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server

    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLServerOLAPService
Local User Account

If SQL Server 2000 (64-bit) is configured to use a Windows local user account, the account must fulfill the same restrictions as apply for a local system account, with the addition that it must be granted Log on as a service permission.

To create or maintain a SQL Server 2000 (64-bit) failover cluster, you must be logged on to the computer with administrator privileges; that is, you must be a member of the Administrators local group of the computer or the domain. For clustering, this means that you must be an administrator of all nodes of the cluster.

Domain User Account

Configuring SQL Server 2000 (64-bit) with a domain user account provides the greatest flexibility. Some examples of functionality provided by a domain user include:

  • Replication

  • Backing up to and restoring from network drives

  • Performing heterogeneous joins that involve remote data sources

  • Ability to define remote partitions on an Analysis server

  • Ability to process linked cubes with an Analysis server

For SQL Server 2000 (64-bit) to perform its tasks, the domain user account must be configured like the local user account discussed earlier. In addition, extended functionality is available by adding further permissions described in the following table.

Service | Permission | Functionality
SQL Server | Network write permissions | Read/Write to remote backups, data loads, and so on
SQL Server | Act as part of the operating system and replace process level token | Run xp_cmdshell for a user other than a SQL Server administrator
SQL Server Agent | Member of the Administrators local group | Create CmdExec and ActiveScript jobs belonging to someone other than a SQL Server administrator
SQL Server Agent | Member of the Administrators local group | Use the autorestart feature
SQL Server Agent | Member of the Administrators local group | Use run-when-idle jobs
Analysis Services | Member of OLAP Administrators group on remote server | Link to source cube on remote Analysis server
Analysis Services | Permissions to data sources accessed by Analysis Services | Required for processing objects

To take advantage of maximum functionality in SQL Server 2000 (64-bit), the domain user account should be a member of the Administrators local group.

If you specify a remote data storage location for Analysis Services, you must use a domain account with access to that location.

See Also

Creating Windows Service Accounts (64-bit)

Service Account (64-bit)


Defining the Authentication Mode (64-bit)

Microsoft® SQL Server™ uses an authentication process to validate users against SQL Server or Microsoft Windows® account credentials. On the Authentication Mode page of the Installation Wizard, you can choose one of the following.

Windows Authentication Mode

When a user connects through a Windows user account, SQL Server validates the account name and password using information in the Windows operating system. This mode provides the highest level of security, and is recommended when backward compatibility is not an issue.

With Windows Authentication, SQL Server achieves login security integration with Windows by using the security attributes of a network user to control login access. A user's network security attributes are established at the time the network login and password are validated by a Windows domain controller. When a network user tries to connect, SQL Server uses Windows to determine the validated network user name, verifies the identity of the user, and then permits or denies access based on the network user name. In this security mode, only trusted connections are allowed.

Administrators of SQL Server can be granted access to SQL Server through the Windows group membership, and this group can be assigned the sysadmin server role. However, Windows administrators can give anyone sysadmin permissions on SQL Server 2000 (64-bit), as they are able to add any user to the appropriate Windows group. If Windows administrators should not have the ability to give themselves or others sysadmin access to SQL Server, then only individual Windows accounts should be assigned to the role of sysadmin.

Note For added security when you choose Windows Authentication mode, you can use the sp_password stored procedure to set up a password for the system administrator (sa) account. This guards against the risk of the installation being switched to Mixed Mode at a later time without a password for the sa account.

Security Note When possible, use Windows Authentication.

Mixed Mode

Allows users to connect using Windows Authentication or SQL Server Authentication. Users who connect through a Windows user account can make use of trusted connections (connections validated by Windows) in either Windows Authentication Mode or Mixed Mode.

SQL Server Authentication is provided for backward compatibility, because applications written for SQL Server version 7.0 or earlier may require the use of SQL Server logins and passwords. Some application developers may prefer SQL Server Authentication because of familiarity. SQL Server Authentication may also be required for connections with client devices that are not running the Windows NT® 4.0, Windows 2000, or Windows XP operating systems.

If you choose Mixed Mode, it is strongly recommended that you assign a strong password for the sa login. In this case, it is recommended that the sa login not be used for day-to-day administration and the password be locked in a safe for emergency access only.

For additional information about authentication, see the "Managing Security" section of "Administering SQL Server" in SQL Server 2000 Books Online.

See Also

Authentication Mode (64-bit)


Specifying the Collation Setting (64-bit)

Use the Collation Settings page of the Installation Wizard to modify default collation settings. Use the Collation designator option to match collation settings in instances of Microsoft® SQL Server™ 2000 (64-bit). Use the SQL Collations option to match settings that are compatible with the sort orders in earlier versions of SQL Server.

Collation Designator

Change the default settings for the Collation designator (Microsoft Windows® collation) and sort order options only if your installation of SQL Server must match the collation settings used by another instance of SQL Server 2000, or if it must match the Windows locale of another computer.

Collation designator

Select the name of a specific Windows collation from the list. For example:

  • Use Latin1_General for the U.S. English character set (code page 1252).

  • Use Modern_Spanish for all variations of Spanish, which also use the same character set as U.S. English (code page 1252).

  • Use Arabic for all variations of Arabic, which use the Arabic character set (code page 1256).

  • Use Japanese_Unicode for the Unicode version of Japanese (code page 932), which has a different sort order from Japanese, but the same code page (932).

For more information, see the "Windows Collation Sorting Styles" topic in SQL Server 2000 32-bit Books Online. (64-bit)

Sort order

Select Sort order options to use with the selected Collation designator. Binary is the fastest sorting order, and is case-sensitive. If Binary is selected, the Case-sensitive, Accent-sensitive, Kana-sensitive, and Width-sensitive options are not available. For more information, see the "Windows Collation Sorting Styles" topic in SQL Server 2000 32-bit Books Online. (64-bit)

SQL Collations

The SQL Collations option is used for compatibility with earlier versions of SQL Server. Select this option to match settings compatible with SQL Server version 7.0, SQL Server version 6.5, or earlier. For more information, see the "Using SQL Collations" topic in SQL Server 2000 32-bit Books Online. (64-bit)

For more information, see the "Specifying the Collation Setting" topic in SQL Server 2000 32-bit Books Online.


Choosing the Licensing Mode (64-bit)

Microsoft® SQL Server™ 2000 (64-bit) supports two client access licensing modes, one based on devices and one based on processors.

  • A device in this context can be a workstation, terminal, or any other device running a SQL Server application connected to an instance of SQL Server.

  • A processor refers to a central processing unit (CPU) installed on a computer running an instance of SQL Server 2000. One computer may have multiple processors installed, requiring multiple processor licenses.

Once a licensing mode is set, you cannot change modes without uninstalling and reinstalling the product. After you install SQL Server, you can use SQL Server 2000 Licensing in Control Panel to add device or processor licenses.

Note Do not confuse the SQL Server licensing utility with the Windows licensing utility, also found in Control Panel.

Examine the licensing agreement packaged with SQL Server 2000 to find the type and quantity of licenses that were purchased with the product. Then on the Licensing Mode page of the Installation Wizard, choose one of the following two options:

Per Seat

This licensing mode requires a license for the computer running SQL Server 2000 (64-bit) as well as Client Access Licenses (CALs) for each client device that connects to the server. An example of a device is a personal computer, workstation, terminal, personal digital assistant, or mobile phone. A specified number of CALs is included with the server license and the server software. If you choose this option, next to devices, type the number of CALs purchased for SQL Server 2000 (64-bit).

Processor License

This licensing mode requires a single license for each CPU in the computer running SQL Server. A processor license includes access for an unlimited number of users to connect from the corporate local area network (LAN), a wide area network (WAN), or the Internet. If you choose this option, next to processors, type the number of Processor licenses purchased for SQL Server 2000 (64-bit).

Per Seat licensing is often more economical for networks in which relatively few clients connect to SQL Server on your network (for example, 75 or fewer devices for the Enterprise Edition). Processor licensing is usually more economical for an installation that provides access to SQL Server databases over the Internet or that supports a large number of users within a LAN or WAN. With Processor licensing, SQL Server can take advantage of each installed processor on the computer and support an unlimited number of client devices.

For additional information about current pricing and licensing rules, see the Microsoft SQL Server Web page.

Important Licensing for Microsoft SQL Server 2000 (64-bit) is governed by the End User Licensing Agreement (EULA) that accompanies the product. This agreement governs all uses and the explanations provided here are not intended to replace the terms of the EULA.

See Also

Licensing Mode (64-bit)


Failover Clustering (64-bit)

In Microsoft® SQL Server™ 2000 Enterprise Edition (64-bit), failover clustering provides high availability support. For example, during an operating system failure or a planned upgrade, you can configure one node of a failover cluster to fail over to any other node in the failover cluster configuration.

To install, configure, and maintain a failover cluster, use SQL Server Setup. As there are no previous 64-bit versions of SQL Server, you cannot upgrade an existing failover cluster to a SQL Server 2000 (64-bit) failover cluster. Also be aware that support for multiple instances of SQL Server differs in the failover clustering scenario: you can create multiple virtual servers in a cluster, but each virtual server can have only one instance of SQL Server installed.

Use failover clustering to:

  • Install SQL Server on multiple nodes in a failover cluster. You are limited only by the number of nodes supported by the operating system.

    Before installing failover clustering, you must install the Microsoft Cluster Service (MSCS) and the 64-bit versions of the Windows® Server 2003 family (additional 64-bit versions of the Windows operating system for servers will be available for later releases of SQL Server 2000 [64-bit]). Because there is no 64-bit version of Windows NT® 4.0 or Windows 2000, you cannot install SQL Server 2000 (64-bit) with Windows NT 4.0 or Windows 2000.

    To use failover clustering, you must follow specific installation steps. For more information, see Handling a Failover Cluster Installation (64-bit).

  • Specify multiple IP addresses for each virtual server.

    With SQL Server 2000 (64-bit), you can specify multiple IP addresses for each server, which allows you to use all available network IP subnets. This provides alternate ways to connect if one subnet fails, and increasing network scalability. For example, with a single network adaptor, a network failure can disrupt communications. But with multiple network cards in the server, each network can be on a different IP subnet. If one subnet fails, at least one connection can continue to function. If a router fails, MSCS continues to function, and all IP addresses still work. However, if the network card on the local computer fails, communication still may be disrupted. For more information, see Creating a Failover Cluster (64-bit).

  • Administer a failover cluster from any node in the clustered SQL Server configuration. For more information, see Creating a Failover Cluster (64-bit).

  • Allow one virtual server to fail over to any other node in the virtual server failover cluster configuration. For more information, see Creating a Failover Cluster (64-bit).

  • Add or remove nodes from the failover cluster configuration using the Setup program. For more information, see Maintaining a Failover Cluster (64-bit).

  • Reinstall or rebuild a virtual server on any node in the failover cluster without affecting the other nodes. For more information, see Maintaining a Failover Cluster (64-bit).

  • Perform full-text queries by using Microsoft Search service with failover clustering. For more information, see Using SQL Server Tools with Failover Clustering (64-bit).


Failover Clustering Support (64-bit)

In Microsoft® SQL Server™ 2000 Enterprise Edition (64-bit), the number of nodes supported for failover clustering depends on the operating system. Some operating systems may require fibre channels for clustering. Because there is no 64-bit version of Windows NT® 4.0 or Windows 2000, you cannot install SQL Server 2000 (64-bit) on Windows NT 4.0 or Windows 2000.

The following tools, features, and services are supported with SQL Server 2000 (64-bit) failover clustering:

  • Microsoft Search service. For more information, see Using SQL Server Tools with Failover Clustering (64-bit).

  • Replication. For more information, see Creating a Failover Cluster (64-bit).

  • Service Control Manager. For more information, see Using SQL Server Tools with Failover Clustering (64-bit).

In addition, the following tools can be used for failover clustering with SQL Server 2000 (64-bit), but only if they are administered remotely from a 32-bit computer. You cannot run these tools directly on a SQL Server 2000 (64-bit) computer. To get the SQL Server 2000 tools, you must install them on a 32-bit computer. For more information, see Configuring SQL Server 2000 (64-bit).

  • SQL Server Enterprise Manager. For more information, see Using SQL Server Tools with Failover Clustering (64-bit).

  • SQL Profiler. For more information, see Using SQL Server Tools with Failover Clustering (64-bit).

  • SQL Query Analyzer. For more information, see Using SQL Server Tools with Failover Clustering (64-bit).

The following feature is not supported for failover clustering:

  • SQL Server 2000 Analysis Services


Handling a Failover Cluster Installation (64-bit)

When you install a Microsoft® SQL Server™ 2000 (64-bit) failover cluster, you must:

  • Ensure that the operating system is installed properly and designed to support failover clustering. For more information about what to do before installing a failover cluster, see Before Installing Failover Clustering (64-bit).

  • Consider whether the SQL Server tools, features, and components you want to use are supported with failover clustering. For more information, see Failover Clustering Support (64-bit).

  • Consider whether failover clustering is dependent on the products you want to use. For more information, see Failover Clustering Dependencies (64-bit).

  • Consider how to create a new failover cluster. For more information about creating a new failover cluster configuration, see Creating a Failover Cluster (64-bit).


Before Installing Failover Clustering (64-bit)

Before you install a Microsoft® SQL Server™ 2000 (64-bit) failover cluster, you must select the operating system on which your computer will run. Note that for the present release, only one operating system is available: the 64-bit versions of the Windows® Server 2003 family. For future releases of SQL Server 2000 (64-bit), additional 64-bit Windows operating systems will be available. You also must install Microsoft Cluster Service (MSCS).

Preinstallation Checklist

Before you begin the installation process, verify that:

  • Your hardware is listed on the Hardware Compatibility List for the 64-bit versions of the Windows Server 2003 family.

    The hardware system must appear under the category of cluster. Individual cluster components added together do not constitute an approved system. Only systems purchased as a cluster solution and listed in the cluster group are approved. When checking the list, specify cluster as the category. All other categories are for OEM use.

    Special hardware compatibility testing is necessary when implementing a failover server cluster on a Storage Area Network (SAN). The entire solution must be on the Multi-Cluster Device Hardware Compatibility List. This is also true when implementing failover cluster nodes in different geographic locations. The entire solution must be on the Geographic Cluster Hardware Compatibility List.

  • MSCS has been installed completely on at least one node before you run the 64-bit versions of the Windows Server 2003 family simultaneously on all nodes.

  • WINS is properly installed. For guidelines, go to this Microsoft Web site, and search for the following article:

    Q258750 Recommended Private "Heartbeat" Configuration on Cluster Server

  • The disk drive letters for the cluster-capable disks are the same on both servers.

  • You have disabled NetBIOS for all private network cards before beginning SQL Server Setup.

  • You have cleared the system logs in all nodes and viewed the system logs again. Ensure that the logs are free of any error messages before continuing.

Also be sure to review the tutorial for Windows Cluster Installation at this Microsoft Web site. For more information about any of these steps, please see your Windows documentation.

For information about installing SQL Server 2000 (64-bit) failover clustering, see Creating a Failover Cluster (64-bit).


Creating a Failover Cluster (64-bit)

To create a Microsoft® SQL Server™ 2000 failover cluster, you must create and configure a virtual server. Running SQL Server Setup does this. This topic explains the elements of a virtual server, as well as important information about naming a virtual server. It also lists basic steps for creating a failover cluster.

Elements of a Virtual Server

A virtual server contains:

  • A combination of one or more disks in a Microsoft Cluster Service (MSCS) cluster group.

    Each MSCS cluster group can contain at most one virtual SQL Server.

  • A network name for each virtual server. This network name is the virtual server name.

  • One or more IP addresses that are used to connect to each virtual server.

  • One instance of SQL Server 2000 (64-bit), including a SQL Server resource, a SQL Server Agent resource, and a full-text resource.

    If an administrator uninstalls the instance of SQL Server 2000 (64-bit), the virtual server, including all IP addresses and the network name, is also removed from the MSCS SQL Server cluster group.

A failover cluster can run across one or more actual computers that are participating nodes of the cluster and that are using the 64-bit versions of the Windows® Server 2003 family operating system. However, a SQL Server virtual server always appears on the network as a single computer.

Naming a Virtual Server

SQL Server 2000 (64-bit) depends on distinct registry keys and service names within the failover cluster so that operations will continue correctly after a failover. Therefore, the name you provide for the instance of SQL Server 2000 (64-bit), including the default instance, must be unique across all nodes in the failover cluster, as well as across all virtual servers within the failover cluster. For example, if all instances failed over to a single server, their service names and registry keys should each be distinct from one another.

Additionally, you must use the virtual server name to connect to a SQL Server 2000 (64-bit) virtual server. You cannot use the node name of the computer it happens to be running on at the time. This ensures that you will always be able to connect to the virtual server using the same name. SQL Server 2000 (64-bit) does not listen on the IP address of the local servers. SQL Server listens only on the clustered IP addresses created during the setup of a virtual server for SQL Server 2000 (64-bit).

Usage Considerations

Before you create a failover cluster, consider the following:

  • In a failover cluster configuration, the network name and IP address of your SQL Server virtual server should not be used for any other purposes, such as file sharing. If you want to create a file share resource, you should use a different network name and IP address.

    Important SQL Server 2000 (64-bit) supports both Named Pipes and TCP/IP Sockets over TCP/IP within a failover cluster. However, it is strongly recommended that you use TCP/IP Sockets in a clustered configuration.

  • If you need high-availability servers in replication, use an MSCS cluster file share as your snapshot folder when configuring a Distributor on a failover cluster. In the case of server failure, the distribution database will be available and replication will continue to be configured at the Distributor.

Also, when creating publications, specify the MSCS cluster file share for the additional storage of snapshot files or as the location from which Subscribers apply the snapshot. This way, the snapshot files are available to all nodes of the cluster and to all Subscribers that must access it. For more information, see the "Alternate Snapshot Locations" and "Publishers, Distributors, and Subscribers" topics in the SQL Server 2000 32-bit Books Online.

  • To use encryption with a failover cluster, install the server certificate with the fully qualified DNS name of the virtual server on all nodes in the failover cluster. For example, if you have a two-node cluster, with nodes named "test1.redmond.corp.microsoft.com" and "test2.redmond.corp.microsoft.com" and a virtual SQL Server "Virtsql", you need to get a certificate for "virtsql.redmond.corp.microsoft.com" and install the certificate on both nodes. You can then check the Force protocol encryption check box on the Server Network Utility to configure your failover cluster for encryption. Do not enable the Force protocol encryption check box until you have certificates installed on all participating nodes in your virtual server.

  • The cluster service must check whether the virtual SQL Server is running by using the IsAlive thread. This requires connecting to the server using a trusted connection. You should ensure that the account the cluster services is configured to run as is an administrator on all nodes in the cluster, and that the BUILTIN\Administrators group has permission to log into SQL Server. These permissions are set by default, so this only applies if you change permissions on the cluster nodes.
Creating a Failover Cluster

To create a failover cluster, you must be a local administrator with permission to log on as a service and to act as part of the operating system on all computers in the failover cluster.

Here are the basic steps for creating a failover cluster using the Setup program:

  1. Identify the information you need to create your virtual server (for example, cluster disk resource, IP addresses, and network name) and the nodes available for failover.

    This configuration must take place before you run the Setup program. You configure this through Cluster Administrator in the 64-bit versions of the Windows Server 2003 family. You need one MSCS group for each virtual server you want to set up.

  2. Start the Setup program to begin your installation. After you enter all necessary information, the Setup program installs a new instance of SQL Server binaries on the local disk of each computer in the virtual server and installs the system databases on the specified cluster disk. The binaries are installed in exactly the same path on each cluster node, so you must ensure that each node has a local drive letter in common with all the other nodes in the cluster.

    If any resource (including SQL Server) fails for any reason, the resources will either be re-started on the same node or the group will move to an available failover cluster node (depending on the failover cluster threshold configuration). The available failover cluster node will be one of the nodes defined as available nodes for the virtual server during SLQ Server setup.

  3. Install one instance of SQL Server 2000 (64-bit), creating a new virtual server and all resources.

How to create a new failover cluster

SQL Setup

SQL Setup (64-bit)

How to install a one-node failover cluster

SQL Setup

SQL Setup (64-bit)

You can also create a failover cluster using the .ini file provided with SQL Server Setup. For more information about installing using the .ini file, see SQL Server 2000 (64-bit) Setup Command.


Failover Clustering Example (64-bit)

The following example illustrates how to configure Microsoft® SQL Server™ 2000 (64-bit) failover clustering.

CLUSTERNODEA and CLUSTERNODEB are two computers in a failover cluster. Run SQL Server Setup on CLUSTERNODEA to create a default instance of SQL Server on a virtual server named "SQLCLUSTA." This virtual server can run on either CLUSTERNODEA or CLUSTERNODEB. From this point forward, connect to the server by specifying "SQLCLUSTA" as the server name in the connection string.

Run the Setup program again on CLUSTERNODEB. Create a named instance "Inst1" on a new virtual server named "SQLCLUSTB" (this must be installed in a different Microsoft Cluster Service [MSCS] cluster group). This virtual server can run on either CLUSTERNODEA or CLUSTERNODEB. From this point forward, connect to the server by specifying "SQLCLUSTB\Inst1" as the connection string.

The two virtual servers are running in the MSCS cluster consisting of CLUSTERNODEA and CLUSTERNODEB. Other than that, they are completely separate from each other. Each virtual server resides in a different MSCS cluster group, and each has a different set of IP addresses, a distinct network name, and data files that reside on a separate set of shared cluster disks.

When a failover occurs for any resource in an MSCS cluster group, all resources that are members of that group also fail over. For SQLCLUSTA, any failure (from the disk resources, IP address, the network name, or the installations of SQL Server 2000 [64-bit] within the virtual server) causes all members of the cluster group to fail over when the failover threshold is reached.

The following illustration is a two-node cluster with binaries and data. Each virtual server in this illustration must have exclusive ownership of the disk on which the data and log files are located.


Failover Clustering Dependencies (64-bit)

There are several products that interact with Microsoft® SQL Server™ 2000 (64-bit) failover clustering. To ensure that your failover cluster functions properly, you need to understand the underlying dependencies that failover clustering has on other products.

Microsoft Distributed Transaction Coordinator (MS DTC)

SQL Server 2000 (64-bit) requires Microsoft Distributed Transaction Coordinator (MS DTC) in the cluster for distributed queries and two-phase commit transactions, as well as for some replication functionality. After you install the 64-bit versions of the Windows® Server 2003 family, and configure your cluster, you must configure MS DTC to work in a cluster by using the Cluster Administrator. Using the Cluster Administrator, go to New/Resource, and create the MS DTC resource. It is recommended that the MS DTC resource not be in the cluster group.

Running MS DTC in Clustered Mode

When MS DTC is running in clustered mode, you can create only one MS DTC resource on the entire cluster.

Any process running on any node in the cluster can use MS DTC. These processes simply call the MS DTC Proxy and the MS DTC Proxy automatically forwards MS DTC calls to the MS DTC transaction manager that is controlling the entire cluster.

If the node running the MS DTC transaction manager fails, the MS DTC transaction manager is automatically restarted on another node in the cluster. The newly restarted MS DTC transaction manager reads the MS DTC log file on the shared cluster disk to determine the outcome of pending and recently completed transactions. Resource managers reconnect to the MS DTC transaction manager and perform recovery to determine the outcome of pending transactions. Applications reconnect to MS DTC so they can initiate new transactions.

For example, suppose the MS DTC transaction manager is active on system B. The application program and resource manager on system A call the MS DTC proxy. The MS DTC proxy on system A forwards all MS DTC calls to the MS DTC transaction manager on system B.

If system B fails, the MS DTC transaction manager on system A will take over. It will read the entire MS DTC log file on the shared cluster disk, perform recovery, and then serve as the transaction manager for the entire cluster.

Note The MS DTC transaction manager, MS DTC Proxy, and Component Services administrative tools are installed on each node of a the 64-bit versions of the Windows Server 2003 family cluster. The cluster uses Microsoft Cluster Services (MSCS) as part of the setup of the 64-bit versions of the Windows Server 2003 family.

To manually install MS DTC on the 64-bit versions of the Windows Server 2003 family (running MSCS)

  1. Install the 64-bit versions of the Windows Server 2003 family on each node in the cluster.

  2. Select Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

  3. In the left pane, select the name of the cluster.

  4. Right-click, and then click the Create Group menu item. This creates a new group in the cluster.

For more information about using MS DTC in a cluster configuration, see your Windows documentation.


Maintaining a Failover Cluster (64-bit)

After you have installed a Microsoft® SQL Server™ 2000 (64-bit) failover cluster, you can change or repair your existing setup. For example, you can add additional nodes to a virtual server in a failover cluster, run a clustered instance as a stand-alone instance, remove a node from a clustered instance, or recover from failover cluster failure.

Adding a Node to an Existing Virtual Server

During SQL Server Setup, you are given the option of maintaining an existing virtual server. If you choose this option, you can add other nodes to your failover cluster configuration at a later time. You can add up to three additional nodes to an existing virtual server configured to run on one node.

To add a node to an existing virtual server

SQL Setup

SQL Setup (64-bit)

Removing a Node from an Existing Failover Cluster

You can remove a node from a virtual server (for example, if a node is damaged). Each node in a virtual SQL Server is considered a peer, and you can remove any node.

A removed node can be added back to a failover cluster at any time. For example, a removed node can be rebuilt after a failure and added back to the failover cluster. Alternatively, if a node is temporarily unavailable and later comes back online, and an instance of SQL Server 2000 (64-bit) from the affected virtual server is still in place, the Setup program removes this instance from the computer before installing the binaries on the node again.

Note A damaged node does not have to be available to be removed, but the removal process will not uninstall any of the binaries from the unavailable node.

To remove a node from an existing failover cluster

SQL Setup

SQL Setup (64-bit)

Running a Clustered Instance of SQL Server as a Stand-Alone Instance

Usually, you run a clustered instance of SQL Server under the control of Microsoft Cluster Service (MSCS). However, it may be necessary to run a clustered instance of SQL Server as a stand-alone instance (for example, when you want to perform administrative operations like running an instance of SQL Server in single-user mode). To connect to a clustered instance of SQL Server 2000 in stand-alone mode using sockets, both the IP address and network name resources must be online for the virtual server on which the instance was installed.

If these resources cannot be online, connect using Named Pipes. However, you must create an alias on the client side to talk to the pipe name on which the instance of SQL Server is listening. Use SQL Server Network Utility to find out the pipe name. For more information, see the "SQL Server Network Utility" topic in the SQL Server 2000 32-bit Books Online. For more information, see Failover Cluster Troubleshooting (64-bit).

Recovering from Failover Cluster Failure

Usually, failover cluster failure is due to one of these causes:

  • Hardware failure in Node 1 of a two-node cluster. This hardware failure could be caused by a failure in the SCSI card or the operating system.

    To recover from this failure, first remove the failover cluster using the Setup program.

To remove a failover clustered instance

SQL Setup

SQL Setup (64-bit)

To recover from failover cluster failure in Scenario 1

SQL Setup

SQL Setup (64-bit)
  • Node 1 is down or offline, but not irretrievably broken. This could be caused by an operating system failure. However, recovering from operating system failure using the steps below can take time. If the operating system failure can be recovered easily, avoid using this technique.

    To recover from this failure, first remove the failover cluster using the Setup program.

To remove a failover clustered instance

SQL Setup

SQL Setup (64-bit)

To recover from failover cluster failure in Scenario 2

SQL Setup

SQL Setup (64-bit)

Changing Service Accounts

You should not change the passwords for any of the SQL Server service accounts when a failover cluster node is down or offline. If you have to do this, you will need to reset the password again using SQL Server Enterprise Manager when all nodes are back online. To use SQL Server Enterprise Manager on your SQL Server 2000 (64-bit) installations, you must administer the tool remotely from a 32-bit computer.

If the service account for SQL Server is not an administrator in a cluster, the administrative shares cannot be deleted on any nodes of the cluster. The administrative shares must be available in a cluster for SQL Server to function.

Do not use the same account for the SQL Server service account and the Cluster service account. If the password changes for the Cluster service account, your SQL Server installation will fail.

See Also

Handling a Failover Cluster Installation (64-bit)


Using SQL Server Tools with Failover Clustering (64-bit)

You can use Microsoft® SQL Server™ 2000 (64-bit) failover clustering with a variety of SQL Server tools and services. However, to get some of the SQL Server 2000 tools and services, you must install them on a 32-bit computer and administer them remotely. Review the following usage considerations.

Full-Text Queries: Available on SQL Server 2000 (64-bit)

To use the Microsoft Search service to perform full-text queries with failover clustering, consider the following:

  • An instance of SQL Server 2000 (64-bit) must run on the same system account on all failover cluster nodes in order for full-text queries to work on failover clusters. Note that this is a general requirement of failover clustering, and is not specific to Microsoft Search service.

  • You must change the start-up account for SQL Server 2000 (64-bit) in the failover cluster using SQL Server Enterprise Manager. If you use Control Panel or the Services Application in the 64-bit versions of the Windows® Server 2003 family, you will break the full-text configuration for SQL Server.
SQL Server Enterprise Manager: Only Available on SQL Server 2000 (32-bit)

To use SQL Server Enterprise Manager with failover clustering, consider the following:

  • You must change the start-up account for SQL Server 2000 (64-bit) in the failover cluster by using SQL Server Enterprise Manager. If you use Control Panel or the Services Application in the 64-bit versions of the Windows Server 2003 family, you could break your server configuration.

  • When creating or altering databases, you will only be able to view the cluster disks for the local virtual server.

  • If you are browsing a table through SQL Server Enterprise Manager and lose the connection to SQL Server during a failover, you will see the error message, "Communication Link Failure." You must press the ESCAPE key and undo the changes to exit out of the SQL Server Enterprise Manager window. You cannot click Run Query, save any changes, or edit the grid.

  • If you use SQL Server Enterprise Manager to reset the properties of the SQL Server service account, you will be prompted to restart SQL Server. When SQL Server is running in a failover cluster configuration, this will bring the full text and SQL Agent resources offline, as well as SQL Server. However, when SQL Server is restarted, it will not bring the full text or SQL Agent resources back online. You must start those resources manually using the Windows Cluster Administrator utility.
Service Control Manager: Available on SQL Server 2000 (64-bit)

Use the Service Control Manager to start or stop a clustered instance of SQL Server. You cannot pause a clustered instance of SQL Server.

SQL Profiler: Only Available on SQL Server 2000 (32-bit)

You can use SQL Profiler with failover clustering. However, if you experience a failover on a server where you are running a SQL Profiler trace, you must restart the trace when the server is back online to continue tracing.

SQL Query Analyzer: Only Available on SQL Server 2000 (32-bit)

You can use SQL Query Analyzer with failover clustering. However, if you experience a failover on a server where you are executing a query, you must restart the query when the server is back online to continue execution.

SQL Mail: Not Available on SQL Server 2000 (64-bit)

You cannot use SQL Mail with SQL Server 2000 (64-bit). However, SQL Agent Mail in SQL Server 2000 (64-bit) can be configured remotely by Enterprise Manager, if your client remotely connects using SQL Server 2000 Service Pack 3.0 or later. For more information, see Differences Between 64-bit and 32-bit Releases (64-bit).


Failover Cluster Troubleshooting (64-bit)

This topic provides information about:

  • Resolving the most common Microsoft® SQL Server™ 2000 (64-bit) failover clustering usage issues.

  • Optimizing failover cluster performance.

  • Using failover clustering with extended stored procedures that use COM objects.
Resolving Common Usage Issues

The following list describes common usage issues and explains how to resolve them:

  • SQL Server 2000 (64-bit) cannot log on to the network after it migrates to another node.

    SQL Server service account passwords must be identical on all nodes, or else the node cannot restart a SQL Server service that has migrated from a failed node.

    It is recommended that you change the SQL Server service account passwords using SQL Server Enterprise Manager (administered remotely from a 32-bit computer). If you do not, and you change the SQL Server service account passwords on one node, you must also change the passwords on all other nodes. SQL Server Enterprise Manager does this automatically.

  • SQL Server cannot access the cluster disks.

    A node cannot recover cluster disks that have migrated from a failed node if the shared cluster disks use a different letter drive. The disk drive letters for the cluster disks must be the same on both servers. If they are not, review your original installation of the operating system and Microsoft Cluster Service (MSCS). For more information, see the 64-bit versions of the Windows® Server 2003 family.

  • Failover is caused by the failure of one particular service, such as full-text search or SQL Server Agent.

    To prevent the failure of specific services from causing the SQL Server group to fail over, configure those services using Cluster Administrator in the 64-bit versions of the Windows Server 2003 family. For example, to prevent the failure of the full-text search service from causing a failover of SQL Server, clear the Affect the Group check box on the Advanced tab of the Full Text Properties dialog box. However, if SQL Server causes a failover, the full-text search service will restart.

  • SQL Server will not start automatically.

    You cannot start a failover cluster automatically using SQL Server. You must use Cluster Administrator in MSCS to automatically start a failover cluster.

  • If the Network Name is offline and you cannot connect using TCP/IP, you must use Named Pipes.

    To connect using Named Pipes, create an alias using the Client Network Utility to connect to the appropriate computer. For example, if you have a cluster with two nodes (Node A and Node B), and a virtual server (Virtsql) with a default instance, you can connect to the server that has the Network Name resource offline by doing the following:

    1. Determine on which node the group containing the instance of SQL Server is running by using the Cluster Administrator. For this example, it will be Node A.

    2. Start the SQL Server service on that computer using net start. For more information about using net start, see Starting SQL Server Manually.

    3. Start the SQL Server Network Utility on Node A. View the pipe name on which the server is listening. It should be similar to \\.\$$\VIRTSQL\pipe\sql\query.

    4. On the client computer, start the Client Network Utility.

    5. Create an alias SQLTEST1 to connect through Named Pipes to this pipe name. To do this, enter Node A as the server name and edit the pipe name to be \\.\pipe\$$\VIRTSQL\sql\query. Connect to this instance using the alias SQLTEST1 as the server name.

      For more information, see Client Net-Libraries and Network Protocols.

Optimizing Failover Clustering Performance

To optimize performance when using failover clustering, consider the following:

  • If your disk controller is not external to your clustered computer, you must turn off write-caching within the controller to prevent data loss during a failover.

  • Write-back caching cannot be used on host controllers in a cluster without hindering performance. However, if you use external controllers, you continue to provide performance benefits. External disk arrays are not affected by failover clustering and can sync the cache correctly, even across a SCSI bus.

  • It is recommended that you do not use the cluster drive for file shares. Using these drives impacts recovery times and can cause a failover of the cluster group due to resource failures.

  • Determine and set your maximum memory size (MAX Memory). MAX Memory is equal to the total memory available, less memory for the operating system, and less memory for other cluster resources. Divide the remaining memory between the SQL Servers installed to find your MAX memory for SQL Server.
Using Extended Stored Procedures and COM Objects

When you use extended stored procedures with a failover clustering configuration, all extended stored procedures need to be installed on the shared cluster disk. This is to ensure that when a node fails over, the extended stored procedures can still be used.

If the extended stored procedures use COM components, the administrator needs to register the COM components on each node of the cluster. The information for loading and executing COM components must be in the registry of the active node in order for the components to be created. Otherwise, the information will remain in the registry of the computer on which the COM components were first registered. For more information, see the "Extended Stored Procedure Architecture" topic in the SQL Server 2000 32-bit Books Online.


Upgrading to a SQL Server 2000 Failover Cluster (64-bit)

 SQL Server 2000 (64-Bit)

Upgrading to a SQL Server 2000 (64-bit) Failover Cluster

This topic applies only to SQL Server 2000 (64-bit).

Because there are no previous 64-bit versions of SQL Server, you cannot upgrade an existing failover cluster to a SQL Server 2000 (64-bit) failover cluster.


Installing SQL Server from the Command Line (64-bit)

The Microsoft® SQL Server™ 2000 (64-bit) Setup.exe program can be run from the command line.

If the user chooses to run Setup.exe from the command line rather than by double-clicking on Setup.exe, there are several command line switches that can be specified. Note that in order to perform an unattended installation, either /qn or /qb must be specified; otherwise the complete graphical user interface will be displayed. For unattended virtual server installation /qn must be specified.

  • SQL Server 2000 (64-bit) Setup Command

  • Running Setup to Install SQL Server 2000 (64-bit)

  • Reinstalling SQL Server 2000 (64-bit)

  • Cluster Command-Line Support (64-bit)


SQL Server 2000 (64-bit) Setup Command

The Microsoft® SQL Server™ 2000 (64-bit) Setup.exe program provides a command line interface in addition to the graphical user interface provided when Setup is run from My Computer or Windows Explorer. Use the properties described in this topic to define settings for customizing the way Setup.exe installs SQL Server 2000. These property settings can be specified either on the command line or in an .ini file specified by the /settings argument.

Important For all path-related parameters in setup, use of a trailing backslash (\) is required.

The following syntax shows the three different command lines to show help, to install an instance, or to remove an instance.

Syntax

setup /?

setup

[/i package_file]
{/settings ini_file | property1=setting1 property2=setting2 ...}
[{/qn|/qb}]

[/l*v log_file]

setup /x package_file
[/qn

[/l*v log_file]

Arguments

/?

Displays a syntax summary of the setup switches.

/i package_file

This argument is not required to install a new instance. It specifies the name of the Microsoft Windows® installation package file (an .msi file) to be used to install an instance of SQL Server 2000 or any of its features. You should specify the complete path to the file following the /i or /x switch. Place the .msi file in the same folder as Setup.exe. Msi files are located in the setup subdirectory from the root directory of the CD. If this parameter is omitted, Setup automatically chooses the next unused .msi file for the installation. For maintaining an existing installation you can instead specify the product code from the ProductCode registry key. For the default instance, use HKEY_Local_Machine\Software\Microsoft\MSSQLServer\Setup:ProductCode. For a named instance, use HKEY_Local_Machine\Software\Microsoft SQL Server\instancename\Setup:ProductCode.

To uninstall a failover cluster, do not use this argument. Use the NODELIST property with an empty list.

/settings ini_file

Specifies the name of an .ini file containing settings for the Setup Properties (listed later in this topic). Place the .ini file in the same folder as Setup.exe. If you use this argument, properties should be set in the .ini file, not in the setup command line. For more information, see Specifying Setup Properties with an .ini File (64-bit).

property1=setting1 property2=setting2 ...

Sets a value for a setup property, which may have a string or a value setting. You only need to include the property settings that are required for an installation. The properties and their settings are described later in this topic. Spaces are permitted in a character string setting but the string must then be enclosed between double quotation marks: "string". For any double quotation character included within the string setting, you must place an additional double-quotation character ("") as an escape code. End paths for folder locations with a backward slash:

INSTALLSQLDIR="C:\Program Files\Microsoft SQL Server\"

If the /settings argument is used to specify an .ini file, properties should be set in the .ini file, not on the setup command line.

/x package_file

Specifies the Windows Installer installation package file (an .msi file) to use when uninstalling an instance of SQL Server 2000. You must specify the name of the same installation package file that was used to install the instance of SQL Server. Specify the complete path to the file following the /x switch.

/qn

In order to perform an unattended installation, you must specify either /qn or /qb. The /qn switch specifies that Setup run with no user interface. This argument is required for unattended failover cluster installations.

/qb

In order to perform an unattended installation, you must specify either /qn or /qb. This argument specifies that Setup show only the basic user interface. Only dialog boxes displaying progress information are displayed.

This argument cannot be used for failover cluster installations.

/l*v log_file

Specifies that the verbose log be created. If this argument is omitted, a non-verbose log is created and saved in the %TEMP% location as Sqlrunn.log (where n represents an enumeration for the installation). Another log, Sqlstpn.log is always created for every installation in the %TEMP% location.

Properties

ADDLOCAL="feature_selection"

Specifies the features to be installed with the current instance either for a new instance or for maintaining an existing instance. The feature_selection list is a comma-delimited list composed of the following features:

Feature | Description
SQL_Server, SQL_Tools, SQL_Headers_Libs, SQL_Engine, SQL_Replication, SQL_Data_Files, SQL_DevTools | SQL Server features that are all required when you install SQL Server.
SQL_FullText | Full-text search engine.
AnalysisServices, Analysis_Server, AnalysisDataFiles, AnalysisSQL, AnalysisSQLData, AnalysisClient | Analysis Services features that are all required when you install Analysis Services.
Books_Online | Books Online.

If ADDLOCAL is omitted, Setup performs a complete installation of all features. If adding features to an existing installation, specify only those features that you are adding. For example, to add Analysis Services to an existing installation, specify the following property setting:

ADDLOCAL=SqlRun,AnalysisServices,Analysis_Server,AnalysisDataFiles,AnalysisSQL,AnalysisSQLData,AnalysisClient

This property is not used to install the SQL Server 2000 Desktop Engine.

This property cannot be used for failover cluster installations.

AGTACCOUNT="domain\logon_name"

Specifies the SQL Server Agent service account domain and logon name. Use AGTPASSWORD to specify the password that corresponds to the logon name. The default if this property is omitted is the local system account.

This property is required for failover cluster installations.

AGTPASSWORD="password"

Specifies the SQL Server Agent service account password that corresponds to the logon name specified by AGTACCOUNT.

This property is required for failover cluster installations.

Caution If this property is omitted, the sa password will be set to NULL. Microsoft recommends that you use Windows Authentication security mode (integrated security). If you must use SQL Server Authentication, you should immediately change the password.

AGTAUTOSTART={1|0}

Specifies whether the SQL Server Agent service is started automatically when the Microsoft Windows® operating system is restarted. Specify 1 to enable or 0 to disable automatic restart. The default if this property is omitted is 1. The SQL Server Agent service requires the SQL Server service to start, so if you specify 1 for this property then the SQLAUTOSTART property setting is also set to 1 (even if you specify SQLAUTOSTART=0).

BLANKSAPWD=1

Specifies that the sa password should be set to NULL. The password string specified by this property is hidden and not written to the log file.

CALLBACK=Dllname!CallbackFunctionName

Specifies the name of the DLL containing the Windows Installer callback function, as well as the name of the callback function.

COLLATION="collation_designator"

Specifies the SQL Server collation that will be used as the default collation for this instance of SQL Server. The default collation depends on the Windows locale setting. For a list of Windows locales and their corresponding collation designators, see the "Windows Collation Designators" topic in SQL Server 2000 32-bit Books Online. (64-bit)

COMPANYNAME="company_name"

Specifies the name for the company registering this product. If this property is omitted, the company name for the operating system is used. If the name contains any spaces, enclose it between double quotation marks.

INSTALLOLAPDIR="OLAP_executable_folder_path"

Specifies the folder where the Analysis Services executable files are installed. The default path is systemdrive\Program Files\Microsoft Analysis Services\. For all path-related parameters, use of a trailing backslash (\) is required. Install Analysis Services to a folder that uses only single-byte characters in the path and name.

This property cannot be used for failover cluster or MSDE installations.

INSTALLOLAPDATADIR="OLAP_data_folder_path"

Specifies the folder where the Analysis Services cubes are built. The default path is systemdrive\Program Files\Microsoft Analysis Services\Data\.

This property cannot be used for failover cluster or MSDE installations.

INSTALLSQLDIR="SQL_executable_folder_path"

Specifies the folder where the SQL Server executable files are installed. The default path is systemdrive\Program Files\Microsoft SQL Server\. SQL Server then locates program files for the default instance in systemdrive\Program Files\Microsoft SQL Server\MSSQL. For a named instance, it locates program files in systemdrive\Program Files\Microsoft SQL Server\MSSQL$instancename.

For installation of a failover cluster, this property is required, and SQL_executable_folder_path must be located on a local drive with a drive letter that exists on all nodes in the cluster definition.

INSTALLSQLDATADIR="data_folder_path"

Specifies the folder where the SQL Server system databases are built. The default path is systemdrive\Program Files\Microsoft SQL Server\. SQL Server then locates database files for the default instance in systemdrive\Program Files\Microsoft SQL Server\MSSQL\Data. For a named instance, it locates program files in systemdrive\Program Files\Microsoft SQL Server\MSSQL$instancename\Data.

For installation of a failover cluster, this property is required, and data_folder_path must be located on shared drive that is a member of the cluster group specified for installation (see the GROUP property).

INSTANCENAME="instance_name"

Specifies the name of the instance. If this property is omitted, the instance is installed as a default instance. See Naming Instances (64-bit) for complete rules to name an instance.

This property is optional for failover cluster installations. If you want to assign an instance name to your cluster installation, then include this property setting.

PIDKEY=cd_key

Specifies the 25-character product identification key required for installation of SQL Server 2000. You can find this number on the yellow sticker in the installation CD liner notes or on the CD case. This property is required.

This property is not used to install the SQL Server 2000 Desktop Engine.

OLAPACCOUNT="domain\logon_name"

Specifies the MSSQLServerOLAPService service account domain and logon name. Use OLAPPASSWORD to specify the password that corresponds to the logon name. The default if this property is omitted is the local system account.

This property is not used to install the SQL Server 2000 Desktop Engine.

This property cannot be used for failover cluster installations.

OLAPAUTOSTART={1|0}

Specifies whether the MSSQLServerOLAPService service is started automatically when the Windows operating system is restarted. Specify 1 to enable or 0 to disable automatic restart. The default if this property is omitted is 1.

This property is not used to install the SQL Server 2000 Desktop Engine.

This property cannot be used for failover cluster installations.

OLAPPASSWORD="password"

Specifies the MSSQLServerOLAPService service account password that corresponds to the logon name specified by OLAPACCOUNT.

This property is not used to install the SQL Server 2000 Desktop Engine.

This property cannot be used for failover cluster installations.

Caution If this property is omitted, the sa password will be set to NULL. Microsoft recommends that you use Windows Authentication security mode (integrated security). If you must use SQL Server Authentication, you should immediately change the password.

PERPROCESSOR="per_processor_license"

Specifies the number of per processor licenses purchased. If you use the PERPROCESSOR property, do not use the PERSEAT property.

This property is not used to install the SQL Server 2000 Desktop Engine.

PERSEAT="per_seat_license"

Specifies the number of per seat licenses purchased. If you use the PERSEAT property, do not use the PERPROCESSOR property.

This property is not used to install the SQL Server 2000 Desktop Engine.

REINSTALL=All

Specifies that Setup install all previously installed SQL Server 2000 (64-bit) features. The only value supported is All. This property must always be used with REINSTALLMODE.

REINSTALLMODE={omus|amus}

Specifies the level of processing performed by Setup. Use REINSTALLMODE=omus when resuming a failed setup. With this option, the entire installation is verified and completed. REINSTALLMODE=omus also rebuilds the registry for a corrupted Microsoft SQL Server installation. Use REINSTALLMODE=amus to rebuild the system databases (for example, to change the server collation or to rebuild the master database after a hard drive failure). When you use REINSTALLMODE=amus, you can modify the security settings (SECURITY and SAPWD) and the collation (COLLATION).

REMOVE="feature_selection"

Specifies the features that will be removed from an existing installation. The feature_selection list is a comma-delimited list containing features listed under ADDLOCAL. To completely remove an instance, use the /x argument on the setup command line.

This property cannot be used for failover cluster installations.

SAPWD="sa_password"

Specifies the sa password when you use the SECURITYMODE=SQL property. The password string specified by this property is hidden and not written to the log file.

Caution If this property is omitted, the sa password will be set to NULL. Microsoft recommends that you use Windows Authentication security mode (integrated security). If you must use SQL Server Authentication, you should immediately change the password.

SECURITYMODE=SQL

Configures the installed instance to use SQL Server (Mixed Mode) Authentication. The default if you omit this property is to use Windows Authentication and place the Windows local Administrators group in the SQL Server sysadmin fixed server roll. When you use this property, you can use SAPWD to specify the sa password for SQL Server Authentication.

Note Microsoft recommends that you use Windows Authentication security mode (integrated security). If you must use SQL Server Authentication, you should immediately change the password

SQLACCOUNT="domain\logon_name"

Specifies the SQL Server service account domain and logon name. Use SQLPASSWORD to specify the password that corresponds to the logon name. The default if this property is omitted is the local system account.

This property is required for failover cluster installations.

SQLAUTOSTART={0|1}

Specifies whether the SQL Server service is started automatically when the Windows operating system is restarted. Specify 1 to enable or 0 to disable automatic restart. The default if this property is omitted is 1.

SQLPASSWORD="password"

Specifies the SQL Server service account password that corresponds to the logon name specified by SQLACCOUNT.

This property is required for failover cluster installations.

Caution If this property is omitted, the sa password will be set to NULL. Microsoft recommends that you use Windows Authentication security mode (integrated security). If you must use SQL Server Authentication, you should immediately change the password.

UPGRADE=1

Specifies that Windows Installer is upgrading the instance specified by INSTANCENAME. If INSTANCENAME is not specified, then the default instance is upgraded. The only supported value is 1.

Note Upgrades are not supported for this release of SQL Server 2000 (64-bit).

UPGRADEPWD="password"

Specifies the password for the login account specified by the UPGRADEUSER property setting. This can be omitted if the login account has a blank password.

Security Note It is recommended that you not use blank passwords; instead, use strong passwords.

This property is not used to install the SQL Server 2000 Desktop Engine.

UPGRADEUSER="login_account"

Specifies that Setup connect to the instance using SQL Server Authentication using the specified login account. The login account must be a member of the sysadmin fixed server role.

It is recommended that you not use this property, so that Setup uses Windows Authentication to connect to the instance. Omitting this property requires Setup to run under a Windows domain or computer account that has been included in the SQL Server sysadmin fixed server role.

This property is not used to install the SQL Server 2000 Desktop Engine.

USERNAME="user_name"

Specifies the name for the user registering this product. If this property is omitted, the user name for the operating system is used. If the name contains any spaces, enclose it between double quotation marks.

Cluster Specific Properties

ADMINACCOUNT="domain\login_name"

Specifies the domain and the administrator account name that is used to spawn processes to remote nodes during Setup only. This account must be a valid administrator on all nodes in the cluster. This property is optional only if the only node affected is the node on which Setup is being run.

ADMINPASSWORD="admin_password"

Specifies the cluster administrator password that corresponds to the account name specified by ADMINACCOUNT.

GROUP="cluster_group_name"

Specifies the cluster group name. This is the group that contains the disk to which the shared data files are written and that contains SQL Server resources. The node that owns the cluster group must be specified by the NODELIST property.

IP="ip_address1,network_name1"

IP="ip_address2,network_name2"

Specify one or more IP addresses that are used to connect to each virtual server. Only one address per network adaptor is permitted, although this property can be used multiple times, once for each network adaptor.

NODELIST="node1_name,node2_name"

Specifies the cluster nodes that are part of the virtual server definition. This list is comma-delimited. To add a node to an existing virtual server definition, execute the original command line or .ini file with the new node added to the NODELIST property setting. To remove a node from an existing virtual server definition, execute the original command line or .ini file with the node removed from the NODELIST property setting. To uninstall a cluster, simply provide an empty NODELIST or omit the NODELIST property completely.

VS="virtual_server_name"

Specifies the name of the virtual server. This is the name that users see when they connect to the virtual server. For more information, see Creating a Failover Cluster (64-bit). This name must be 15 characters or less and follow the naming rules for a computer name.

See Also

Running Setup to Install SQL Server 2000 (64-bit)

Reinstalling SQL Server 2000 (64-bit)


Running Setup to Install SQL Server 2000 (64-bit)

Run the Setup command to install Microsoft® SQL Server™ 2000 (64-bit) or any of its features. Run Setup in either of the following ways:

  • Execute Setup.exe from a batch command file or from the command prompt. When using this method, setup switches are specified in the same way they would be specified for any other command prompt utility.

  • Execute Setup.exe from within an application setup executable file, using a method similar to the Microsoft Win32® CreateProcess() function. In this case, setup switches are specified in a character string passed in using the lpCommandLine parameter. For information about using CreateProcess() to execute Setup.exe, see the "Desktop Engine Installation Samples" topic in the SQL Server 2000 32-bit Books Online (64-bit).

To perform an unattended installation use the /qn or /qb argument. The /qn argument provides for a silent installation, displaying no user interface dialog boxes. The /qb argument displays only dialog boxes showing progress information, such as the dialog box that prompts users to restart after setting up SQL Server. For an unattended installation of a failover cluster, you must use /qn.

The preferred method for removing an instance of SQL Server 2000 is to use Add or Remove Programs in Control Panel, or to run Setup.exe from the desktop or Windows Explorer. However, you can use the setup command line to uninstall SQL Server for an unattended operation or from another application. To uninstall an instance of SQL Server 2000 using the setup command line, call Setup.exe using the /x switch to specify the same .msi file that was used to install that instance. For example, to uninstall a named instance installed with a custom installation package file named MyCustom.msi, execute:

Setup /x MyCustom.msi

Instead of an .msi file, you can specify the product code from the ProductCode registry key. For the default instance use HKEY_Local_Machine\Software\Microsoft\MSSQLServer\Setup:ProductCode. For a named instance use HKEY_Local_Machine\Software\Microsoft SQL Server\instancename\Setup:ProductCode.


Specifying Setup Properties with an .ini File (64-bit)

Optionally, the setup command line properties can be specified using an .ini file. On the setup command line, use the /settings ini_file argument to specify the .ini file. The first line in the .ini file must contain the string [Options].

The \Template.ini file on the SQL Server 2000 (64-bit) installation compact disc provides detailed instructions for creating an ini file. The format of the .ini file is illustrated in this example:

[Options]
USERNAME=MyName
COMPANYNAME=MyCompany
PIDKEY=ABCDE12345FGHIJ67890KLMNO
INSTALLSQLDIR="C:\Program Files\Microsoft SQL Server\"
INSTALLSQLDATADIR="C:\Program Files\Microsoft SQL Server\"
INSTANCENAME=MyInstance
SQLACCOUNT=MyDomain/MyAccount
SQLPASSWORD=MyPassword
...

Important Property settings that contain spaces must be enclosed between double quotation marks, and paths must always end with a backslash (\) character.

You can also use an .ini file to specify property settings for an existing installation of SQL Server 2000. To maintain an existing instance using an .ini file, you must also include the /i package_file argument on the command line to specify the package file for the instance. Include the /i on the command line with the /settings argument. For example:

setup /i sqlrun01.msi /settings myinstance.ini /l*v c:\myinstance.log

Alternatively, you can specify the product code from the ProductCode registry key. For the default instance use HKEY_Local_Machine\Software\Microsoft\MSSQLServer\Setup:ProductCode. For a named instance use HKEY_Local_Machine\Software\Microsoft SQL Server\instancename\Setup:ProductCode.

See Also

SQL Server 2000 (64-bit) Setup Command


Reinstalling SQL Server 2000 (64-bit)

If an attempt to install an instance of Microsoft® SQL Server™ 2000 (64-bit) fails (for reasons such as specifying an incorrect login account or using a Microsoft Windows® account that does not have sufficient file permissions), you may want to resume Setup after correcting the error condition. This includes installations using either SQL Server 2000 (64-bit) Setup or the merge modules in a Windows Installer installation process.

When resuming the installation process, you must specify two installation options in addition to the options that were specified in the original installation attempt:

REINSTALL=All

Specifies that SQL Server 2000 Setup install all SQL Server 2000 features. The only value supported is All.

REINSTALLMODE={omus|amus}

Specifies the level of processing performed by SQL Server 2000 Setup. Specify REINSTALLMODE=omus when resuming a failed setup. With this option, the entire installation process is verified and completed. Specify REINSTALLMODE=amus when you have to rebuild only the master database, such as after a failure of the disk drive holding the master database.

See Also

SQL Server 2000 (64-bit) Setup Command

Repairing a SQL Server Installation (64-bit)


Cluster Command-Line Support (64-bit)

The following syntax shows the arguments and properties used by the setup command line for a failover cluster. For complete documentation of the arguments and properties, see SQL Server 2000 (64-bit) Setup Command.

Syntax

setup /? |

[
{[/i package_file]
{[/settings ini_file]
|[USERNAME="user_name"]
[COMPANYNAME="company_name"]
PIDKEY=cd_key
INSTALLSQLDIR="SQL_executable_folder_path"
INSTALLSQLDATADIR="data_folder_path"
[REMOVE="feature_selection"]
[INSTANCENAME="instance_name"]
SQLACCOUNT="domain\logon_name"
SQLPASSWORD="password"]]
AGTACCOUNT="domain\logon_name"
AGTPASSWORD="password"]]
[SQLAUTOSTART={0|1}]
[AGTAUTOSTART={1|0}]
[SECURITYMODE=SQL]
[SAPWD="sa_password"]
[COLLATION="collation_designator"]
[PERPROCESSOR="per_processor_license"
|PERSEAT="per_seat_license"]
[UPGRADE=1
[UPGRADEUSER="login_account"
[UPGRADEPWD="password"]]
[CALLBACK=Dllname!CallbackFunctionName]
[REINSTALL=All

REINSTALLMODE={omus|amus}]
VS="virtual_server_name"
IP="ip_address1network_name1"
[IP="ip_address1network_name2" ...]
NODELIST="node1_name,node2_name"
GROUP="cluster_group_name"
ADMINACCOUNT="domain\login_name"
ADMINPASSWORD="admin_password"]}]
/qn
[/l*v log_file]
]

To install Microsoft® SQL Server™ 2000 (64-bit) on a failover cluster, you must run the setup command line on the cluster. The following property settings (except for INSTANCENAME, which is optional) are required.

Property | Comment
VS | Specifies the name of the virtual server. The name can have up to 15 characters and must adhere the same rules as any computer name.
IP | Specifies the IP addresses. Use one entry for each network adapter. The format is "IP address,network", for example IP="172.26.16.77, Local Area Connector 2".
NODELIST | Specifies the nodes for your virtual server. The nodes must exist in the cluster. To add a node to the virtual server definition, execute the original command line with the new node added to the NODELIST property setting. To remove a node, execute the original command line with the node removed from the property setting. To uninstall a cluster, run the command line with an empty NODELIST (or omit it completely).
ADMINACCOUNT ADMINPASSWORD | Specifies an account used to spawn processes to remote nodes during setup only. This user account must be in the administrators group on all nodes that are to be included in the virtual server. This account must be defined.
INSTALLSQLDIR | The drive letter in the path must exist on all nodes in the cluster.
INSTALLSQLDATADIR | Specifies a location on a shared disk that is a member of the cluster group.
SQLACCOUNT | Required
SQLPASSWORD | Required
AGTACCOUNT | Required
AGTPASSWORD | Required
INSTANCENAME | Optional. If you would like to have an instance name for the virtual server, then include this property setting.


Maintaining a SQL Server Installation (64-bit)

The preferred methods of maintaining an installation of Microsoft® SQL Server™ 2000 (64-bit) are either to use Add or Remove Programs in Control Panel or to run the SQL Server 2000 Setup program. These applications support adding and removing features of an installed instance of SQL Server 2000 (64-bit) or completely removing an instance. You can also specify property settings on the setup command line. Using the command line, you can also verify and repair an existing installation, repair the master database, and repair registry entries. Maintenance options are described in the following topics.

Read this | To
Adding or Removing SQL Server Features (64-bit) | Add or remove SQL Server features in an installed instance of SQL Server 2000 (64-bit).
Removing a SQL Server Installation (64-bit) | Remove an instance of SQL Server 2000 (64-bit).
Repairing a SQL Server Installation (64-bit) | Repair a broken installation and rebuild the master database or the registry keys for an instance of SQL Server 2000 (64-bit).
Viewing Setup Log Files (64-bit) | Find descriptions and directory locations of Setup log files.
Upgrading to SQL Server 2000 (64-bit) | Find out about support for upgrading existing installations on the 64-bit platform.


Adding or Removing SQL Server Features (64-bit)

You can add or remove individual features in an instance of Microsoft® SQL Server™ 2000 (64-bit). To add or remove a feature, run Add or Remove Programs in Control Panel and choose to change an instance of SQL Server. This starts the Installation Wizard and lets you choose whether to change the installed features or completely remove all features. After you choose to change the installed features, the wizard displays the Feature Selection page described in Specifying SQL Server Features (64-bit). The remaining steps in the wizard depend on which features you choose to install or remove.

Note For a failover cluster installation, you cannot use Add or Remove Programs to add or remove features in an instance. You must use the Setup.exe graphical interface or the command line.

You can also add or remove features by running the SQL Server 2000 Setup program from the desktop or from Windows Explorer. When Setup starts, you can choose to work with an existing instance rather than installing a new instance. This displays the Feature Selection page and additional pages to complete the task. In this setup mode, you cannot change the location of a previously installed feature, nor can you specify the location for a new feature.

How to add or remove features in an instance of SQL Server 2000

SQL Setup

SQL Setup (64-bit)

You can also add or remove features on the setup command line for SQL Server 2000 (64-bit). The command line is useful for a silent operation or to maintain SQL Server using another application, although the preferred methods to add or remove features are through Add or Remove Programs or Setup run from the desktop. On the setup command line, use the ADDLOCAL property to specify features to add to an instance of SQL Server 2000. Use the REMOVE property to specify features to remove. For more information, see SQL Server 2000 (64-bit) Setup Command.

See Also

Running Setup to Install SQL Server 2000 (64-bit)

Removing a SQL Server Installation (64-bit)

Repairing a SQL Server Installation (64-bit)


Removing a SQL Server Installation (64-bit)

Use Add or Remove Programs in Control Panel to change or remove an instance of Microsoft® SQL Server™ 2000 (64-bit). When you remove the default or a named instance of SQL Server 2000, the data files and registry keys for the instance are deleted. To remove all instances of SQL Server 2000, each instance must be removed separately.

Note For a failover cluster installation, you cannot use Add or Remove Programs to remove an instance. You must use the Setup.exe graphical interface or the command line.

Tools and other shared files cannot be removed until all instances of SQL Server 2000 have been removed from a computer because these files are shared among all the installed instances. After SQL Server 2000 is uninstalled, some files may remain.

You can remove SQL Server from an instance without removing Analysis Services. However, because Analysis Services uses SQL Server core program files for its repository, Add or Remove Programs does not remove the SQL Server core program files from the instance unless you also remove Analysis Services. For more information, see Analysis Services (64-bit).

How to remove SQL Server 2000

SQL Setup

How to remove SQL Server 2000 (64-bit)

Add or Remove Programs or Setup run from the desktop are the preferred methods to remove features, but the command line is useful for a silent operation or to maintain SQL Server using another application. You can use the /x="packagefile" argument on the setup command line to remove an instance of SQL Server 2000. Specify the name of the same installation package (.msi) file that was used to install the instance of SQL Server. Place the file in the same folder as Setup.exe. For more information, see SQL Server 2000 (64-bit) Setup Command.

If you do not know which .msi file was used to install the instance, then use the product code for the instance. The product code for the default instance can be gathered from the following registry key:

HKEY_Local_Machine\Software\Microsoft\MSSQLServer\Setup:ProductCode

The product code for any named instance can be gathered from the following registry key:

HKEY_Local_Machine\Software\Microsoft SQL Server\instancename\Setup:ProductCode

See Also

Running Setup to Install SQL Server 2000 (64-bit)

Adding or Removing SQL Server Features (64-bit)


Repairing a SQL Server Installation (64-bit)

You can use the setup command line with the REINSTALL and REINSTALLMODE properties to repair an instance of Microsoft® SQL Server™ 2000 (64-bit). The REINSTALL property triggers the reinstallation of program files and the REINSTALLMODE property specifies the type of reinstall. Its two different settings, amus and omus, both repair and verify an instance of SQL Server. Additionally, the amus setting repairs a corrupted master database and the omus setting rebuilds the registry. These properties can be specified on the command line or in an .ini file.

Rebuilding the Registry

Use the setup command line with the REINSTALL=ALL and REINSTALLMODE=omus property settings to rebuild the registry for a corrupted installation of SQL Server 2000 (64-bit). Running Setup.exe with these property settings rebuilds, verifies, and repairs the installation of an instance in addition to rebuilding the registry.

Important To rebuild the registry, you must use the same package file and choices that you entered during the initial installation. If you do not know this information, first uninstall and then reinstall SQL Server rather than using the command line.

Rebuilding the Master Database

Use the setup command line with the REINSTALL=ALL and REINSTALLMODE=amus property settings to rebuild the master database for a corrupted installation of SQL Server 2000 (64-bit). Running Setup.exe with these property settings rebuilds, verifies, and repairs the installation of an instance in addition to rebuilding the system databases. When you use REINSTALLMODE=amus, you can modify the security settings (SECURITYMODE and SAPWD) and the collation setting (COLLATION).

Security Note When possible, use Windows Authentication. Do not leave the sa password blank; always use strong passwords.

See Also

SQL Server 2000 (64-bit) Setup Command

Running Setup to Install SQL Server 2000 (64-bit)


Viewing Setup Log Files (64-bit)

The following table describes log files created by SQL Server setup processes.

File Name | Description | Location
SqlstpX.log | Each installation creates sqlstpX.log files, where X is a sequence number. This log file contains output from the Windows Installer and other information about setup. | %Temp%
SqlrunX.log (Standalone installation) | A non-verbose1 log is created as SqlrunX.log, where X represents an enumeration for the installation. This log files contains setup procedure information. | %Temp%
SqlrunX.log (Failover installation) | Setup always creates a SqlrunX.log verbose log file on all failover nodes, where X represents an enumeration for the installation. This log file contains setup procedure information. | %Temp% (On the node where Setup is launched) %Windir% (On the remote nodes)
Dasetup.log | This is the Microsoft Data Access Components (MDAC) setup log file. | %Windir%
Errorlog.log | This is the SQL Server error log file. | The default location for this error log is C:\Program Files\Microsoft SQL Server\Mssql\Log\Errorlog. For a named instance, the error log would be in \Microsoft SQL Server\Mssql$<instancename>\Log\Errorlog.

1 Setup can be run using the command line option '/L*v' to create a verbose log file (for example, setup.exe /L*v c:\SQL_Server_verbose.log). Verbose log files are useful when you are investigating setup problems.


Upgrading to SQL Server 2000 (64-bit)

Upgrades are not supported for this release of SQL Server 2000 (64-bit). The 32-bit versions of SQL Server are not supported on the 64-bit Microsoft Windows® operating system, so you cannot upgrade from a previous 32-bit release of SQL Server (including SQL Server 2000 [32-bit], SQL Server version 7.0, or SQL Server version 6.5) to SQL Server 2000 (64-bit).


Configuring SQL Server 2000 (64-bit)

After Setup completes the installation of Microsoft® SQL Server™ 2000 (64-bit), you can further configure SQL Server using graphical and command prompt utilities. All the command prompt utilities available for the 32-bit version of SQL Server 2000 are also provided with SQL Server 2000 (64-bit). Of the graphical tools, only the Server Network Utility and the SQL Server Service Manager are provided with this release of SQL Server 2000 (64-bit). The Client Network Utility is provided by the operating system, as part of Microsoft Data Access Components (MDAC). The other graphical tools can only be installed with the 32-bit version of SQL Server 2000 on the 32-bit Microsoft Windows® operating system, and are not supported on the 64-bit Windows operating system. However, you can use the graphical tools installed with the 32-bit version of SQL Server 2000 to remotely manage 64-bit SQL Server features.

Icon | Tool or utility | Support
 | SQL Server Enterprise Manager SQL Server groups, server registration, server options (databases, objects, logins, users, and permissions), administrative tasks for servers, management wizards | Remote administration from the 32-bit SQL Server 2000. See "SQL Server Enterprise Manager" in SQL Server Books Online.
 | Analysis Manager Analysis servers, data sources, cubes, data mining models, storage, security, dimensions, and security roles | Remote administration from the 32-bit SQL Server 2000. See "Analysis Manager" in SQL Server Books Online.
 | SQL Query Analyzer SQL statements, batches, and scripts | Remote administration from the 32-bit SQL Server 2000. See the "SQL Query Analyzer Help" section in SQL Server Books Online.
 | SQL Profiler Events for SQL services | Remote administration from the 32-bit SQL Server 2000. See "Monitoring with SQL Profiler" in SQL Server Books Online.
 | Client Network Utility Net-Libraries and server alias names From a command prompt or the Run command, run Cliconfg.exe. | MDAC tool on the 64-bit versions of the Windows® Server 2003 family operating system. See "Client Network Utility" in SQL Server Books Online.
 | Server Network Utility Server Net-Libraries | Supported for SQL Server 2000 (64-bit). Note that Net-Library configuration is not made during Setup and, if necessary, must be made with this utility. See "Server Network Utility" in SQL Server Books Online.
 | Import and Export Data Data transformation | Command line support only. See "dtsrun Utility" in SQL Server Books Online.
 | SQL Server Service Manager SQL Server log on services (Microsoft Search, MSSQLServerOLAPService, SQL Server, SQL Server Agent) | Supported for SQL Server 2000 (64-bit). See "SQL Server Service Manager" in SQL Server Books Online.
 | SQL Server 2000 Licensing Per Seat or Per Processor licenses | In Control Panel. See Licensing Mode (64-bit) and Choosing the Licensing Mode (64-bit).
 | Setup SQL Server instances and features | Supported by Windows Installer in SQL Server 2000 (64-bit).


Using the Start Menu (64-bit)

Some graphical interface tools are accessible through the Microsoft® SQL Server™ program group in the Programs group on the Start menu. These tools are:

  • Books Online

  • Server Network Utility

  • Service Manager

Additionally, you can open Control Panel to start the following:

  • SQL Server 2000 Licensing

The command line tools may also be started with the Run command on the Start menu, or from a command prompt. For more information, see SQL Server Management Tools (64-bit).


System and Sample Databases (64-bit)

When Microsoft® SQL Server™ 2000 (64-bit) is installed, Setup creates the databases and log files shown in this table.

Database | Database file | Log file
master | Master.mdf | Mastlog.mdf
distmdl | Distmdl.mdf | Distmdl.ldf
model | Model.mdf | Modellog.ldf
msdb | Msdbdata.mdf | Msdblog.ldf
tempdb | Tempdb.mdf | Templog.ldf
pubs | Pubs.mdf | Pubs_log.ldf
Northwind | Northwnd.mdf | Northwnd.ldf

The following Analysis Services database files appear only in the instance with which Analysis Services is installed.

Database | Database file | Log file
olapquerylog | OLAPQueryLog.mdf | OLAPQueryLog.ldf
olaprepository | OLAPRepository.mdf | OLAPRepository.ldf
Foodmart 2000 | Foodmart 2000.mdf | Foodmart 2000.ldf

The default location of the database and log files is systemdrive\Program Files\Microsoft SQL Server\Mssq\Data for the default instance, and systemdrive\Program Files\Microsoft SQL Server\Mssq$instancename\Data for a named instance. The databases installed with an instance may not include all those shown above, depending on the features installed with the instance.

The system databases are master, distmdl, model, msdb, and tempdb. The sample databases, pubs, Northwind, and Foodmart 2000 are provided as learning tools. (Names of these databases are case sensitive.) Many of the examples in SQL Server Books Online are based on the sample databases.


Locating Folders and Files (64-bit)

The following tables and illustration show the default locations of folders and files for Microsoft® SQL Server™ 2000 (64-bit). Depending on the options you install, some of the files listed in the tables may not appear on your computer, and others not listed may be included.

Paths listed here are default paths, and may vary if locations were changed during installation. Both program and data file locations can be changed, but the location of shared tools cannot be changed.

Shared Files for All Instances of SQL Server 2000

This table shows the locations for the shared files for both default and named instances of SQL Server 2000.

Location1 | Description
\Program Files\Microsoft SQL Server\80\Com | Dynamic-link libraries (DLLs) for Component Object Model (COM) objects
\Program Files\Microsoft SQL Server\80\Com\Binn\Resources\1033 | Resource files (RLLs) used by the DLLs in this COM folder (Note: 1033 is for U.S. English; localized versions use different numbers for the folder name.)
\Program Files\Microsoft SQL Server\80\Setup Bootstrap | Files installed by Setup to support the setup operation
\Program Files\Microsoft SQL Server\80\Tools\Binn | The 64-bit versions of the Windows® Server 2003 family client executable files
\Program Files\Microsoft SQL Server\80\Tools\Binn\Resources\1033 | Resource files used by the DLLs in the Tools\Binn folder
\Program Files\Microsoft SQL Server\80\Tools\DevTools\ | Header files, library files, and sample programs for use by developers

1 The default drive for these locations is systemdrive, normally drive C.

Program and Data Files for the Default Instance of SQL Server 2000

This table shows the locations of the program and data files for the default instance of SQL Server 2000. These are the default file locations, which can be changed during installation. For a named instance, these folders are located similarly in systemdrive\Program Files\Microsoft SQL Server\Mssql$instancename, where instancename is the name of the instance.

Location1 | Description
\Program Files\Microsoft SQL Server\Mssql\Backup | Default location for backup files
\Program Files\Microsoft SQL Server\Mssql\Binn | The 64-bit versions of the Windows Server 2003 family server executable files and DLL files for extended stored procedures
\Program Files\Microsoft SQL Server\Mssql\Binn\Resources\1033 | Resource files used by the DLLs in this Binn folder
Program Files\Microsoft SQL Server\Mssql\Data | System and sample database files, including the repository and sample database files for Analysis Services (for the default or named instance of SQL Server with which you install Analysis Services)
\Program Files\Microsoft SQL Server\Mssql\Ftdata | Full-text catalog files
\Program Files\Microsoft SQL Server\Mssql\Install | Scripts run during Setup and resulting output files
\Program Files\Microsoft SQL Server\Mssql\Log | Error log files
\Program Files\Microsoft SQL Server\Mssql\Repldata | Working folder for replication tasks

1 The default drive for these locations is systemdrive, normally drive C.

Program and Data Files for Analysis Services

This table shows the locations of the program and data files for Analysis Services. These are the default file locations, which can be changed during installation.

Location1 | Description
\Program Files\Analysis Services\Bin | The 64-bit versions of the Windows Server 2003 family server executable files and DLL files
\Program Files\Analysis Services\Data | Analysis server databases

1 The default drive for these locations is systemdrive, normally drive C.

Note that the Analysis Services repository and sample data files are installed in the SQL Data folder for the default or named instance of SQL Server with which you install Analysis Services. See the previous table, under "Program and Data Files for the Default Instance of SQL Server 2000."

File Locations for 32-bit SQL Server Files

Some shared SQL Server 2000 program files have been transferred directly to the 64-bit platform. These files include SQL Server Books Online.

This table shows the locations for the shared files for both default and named instances of SQL Server 2000.

Location1 | Description
\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn | Executable and DLL files
\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn\Resources\1033 | RLL files
\Program Files (x86)\Microsoft SQL Server\80\Tools\Books\ | SQL Server 2000 Books Online

1 The default drive for these locations is systemdrive, normally drive C.

File Locations for the Default Instance of SQL Server 2000

This illustration shows the file locations for the default instance of SQL Server 2000 (64-bit).


Changing Passwords and User Accounts (64-bit)

Microsoft® SQL Server™ 2000 (64-bit) services accounts and passwords are linked to Microsoft Windows® user accounts and passwords. Changes in one location may require changes in the other.

Changing SQL Server Services Accounts After Installation

After you have installed SQL Server 2000 (64-bit), use Services in the Administrative Tools of the 64-bit versions of the Windows® Server 2003 family to change the assigned password or other properties of any service related to SQL Server. Each service must be changed individually. The new user account takes effect when the service is restarted. You should not change the passwords for any of the SQL Server service accounts when a failover cluster node is down or offline. If you have to do this, you will need to reset the password again when all nodes are back online.

Note You can also manage services related to an instance of SQL Server 2000 (64-bit) from SQL Server Enterprise Manager on a 32-bit installation of SQL Server 2000.

If you select to change the current service account for SQL Server to a non-administrator account (and the current service account for SQL Server is not an administrator account), the Valid Administrator Login dialog box is displayed. SQL Server must have administrator privileges to change security entries, so you must enter the user name, password, and domain to impersonate the non-administrator service account you have selected.

Once you have specified this information, all objects are granted full-control permission. The location of the objects is determined by the following:

  • Permissions are set for all files in the binary and data installation locations for the specific instances.

  • Registry permissions depend on whether the instance is default or named:

    For a default instance, permissions are applied only to the entries listed below the HKLM\Software\Microsoft\MSSQLServer entry:

    • Client

    • MSSQLServer

    • Providers

    • Replication

    • Setup

    • SQLServerAgent

    • SQLServerSCP

    • Tracking

    For a named instance, permissions are applied to the entire HKLM\Software\Microsoft\Microsoft SQL Server\instancename entry.

The following rights are granted to the accounts:

  • SeServiceLogonRight, which allows the account to run as a service.

  • SeLockMemoryPrivilege, which allows the account to use the AWE memory feature of SQL Server.

  • SeTcbPrivilege, which allows the account to impersonate other accounts.

If you are running SQL Server in a failover cluster configuration, permissions are also set for all files in the binary and data installation locations for all nodes in the cluster. Permission is also granted for the service account on the Cluster Object.

Changing the current service account for SQL Server to a non-administrator account causes existing full-text catalogs to become inaccessible. Either rebuild and perform a full population of all catalogs belonging to this instance of SQL Server, or switch back to an account with administrator permissions.

To change the MSSQLServer services login account information

SQL Setup

Services (64-bit)

If your Windows password changes after SQL Server 2000 is installed (for example, your password expires), you must also revise the user account information for SQL Server services in Windows.

For more information about creating the 64-bit versions of the Windows Server 2003 family user accounts, granting advanced user rights, setting password expiration, and managing group memberships, see the the 64-bit versions of the Windows Server 2003 family documentation. For additional information, see the topics "Creating Security Accounts" and "Security Architecture" in SQL Server Books Online.


Renaming a Server (64-bit)

When you change the name of the computer that is running Microsoft® SQL Server™ 2000 (64-bit), the new name is recognized during SQL Server startup. You do not have to run Setup again to reset the computer name.

You can connect to SQL Server using the new computer name after you have restarted the server. However, to correct the sysservers system table, you should run these procedures manually:

sp_dropserver old_name
GO
sp_addserver new_name, local
GO

When you have more than one instance of SQL Server on the computer, change the sysservers system table information by running the stored procedures this way:

sp_dropserver old_servername\instancename
GO
sp_addserver new_servername\instancename, local
GO
Issues with Remote Logins and Replication

If the computer has any remote logins (for example, if it is a replication Publisher or Distributor), sp_dropserver may generate an error similar to this:

Server: Msg 15190, Level 16, State 1, Procedure sp_dropserver, Line 44
There are still remote logins for the server 'SERVER1'.

To resolve the error, you may need to drop remote logins for this server. If replication is installed, disable replication using SQL Server Enterprise Manager from a 32-bit installation on the 64-bit server. Then run the sp_dropserver stored procedure.

To disable replication using the SQL Server Enterprise Manager

  1. Expand a server group, and then expand the Distributor (the server that contains the distribution database).

  2. Right-click the replication folder and then select Disable Publishing.

  3. Complete the steps in the Disable Publishing and Distribution Wizard.


Distributing Disk Images of an Installation (64-bit)

Microsoft® SQL Server™ 2000 (64-bit) includes the same method as the 32-bit version of SQL Server 2000 for distributing a disk image of an installation. When an installation is first created, it is marked as a new installation. When the server is restarted after installation, SQL Server 2000 verifies that the server name has not changed. If the server name has changed, an automatic correction is made.

This functionality allows Independent Service Vendors to install SQL Server 2000, stop the server, clone the disk image, and then distribute it as required. On the first startup of the distributed server, the name correction is made.

This process can be done only one time. If the server is restarted and then stopped, you must create a new SQL Server installation to be distributed as an image during deployment.


Configuring Network Libraries (64-bit)

Unlike the 32-bit version, Microsoft® SQL Server™ 2000 (64-bit) does not provide for configuring Network Libraries during Setup. Shared Memory, Named Pipes, and TCP/IP are enabled by default during Setup. To make any changes to these settings, such as enabling or disabling protocols, use the SQL Server Network Utility, which is in the Microsoft SQL Server program group on the Start menu.


Setting Configuration Options for the Affinity Mask (64-bit)

This section introduces two affinity mask options that you can use with Microsoft® SQL Server™ 2000 (64-bit) to control CPU affinity. SQL Server 2000 (64-bit) supports processor affinity with two different affinity mask options: affinity mask Option (64-bit) and affinity64 mask Option (64-bit).


affinity mask Option (64-bit)

An association between a thread and a processor is called processor affinity, and such an association is generally beneficial for the performance of Microsoft® SQL Server™. At the operating system level, however, Microsoft Windows® sometimes moves process threads among different processors in order to handle multitasking. While the operating system performs more efficiently because of this technique, SQL Server performance can actually be reduced under heavy system loads, as each processor cache is repeatedly reloaded with data.

SQL Server 2000 (64-bit) supports processor affinity by means of two affinity mask options: affinity mask and affinity64 mask. For more information about the affinity64 mask option, see affinity64 mask Option (64-bit).

Note The affinity64 mask option is only available for SQL Server 2000 (64-bit).

The affinity mask option, also available in previous releases of SQL Server, dynamically controls CPU affinity. Use the affinity mask option to increase performance on multiprocessor (SMP) systems with more than four microprocessors operating under heavy load. You can associate a thread with a specific processor and specify which processors SQL Server will use. You can also exclude SQL Server activity from processors given specific workload assignments by the Windows 2000 or Windows Server 2003 operating system.

If you set affinity mask to 1 (that is, you set a bit representing a processor to 1), that processor is selected for thread assignment. When you set affinity mask to 0 (the default), the 64-bit versions of the Windows® Server 2003 family scheduling algorithms set the thread's affinity. When you set affinity mask to any nonzero value, SQL Server affinity interprets the value as a bit mask that specifies those processors eligible for selection.

By segregating SQL Server threads from running on particular processors, the 64-bit versions of the Windows Server 2003 family can better evaluate the system's handling of processes specific to Windows. For example, you can use the affinity mask option to evaluate whether an additional network interface card (NIC) increases performance or assess NIC performance with increasing loads.

The values for affinity mask are as follows:

  • A one-byte affinity mask covers up to 8 CPUs in a multiprocessor computer.

  • A two-byte affinity mask covers up to 16 CPUs in a multiprocessor computer.

  • A three-byte affinity mask covers up to 24 CPUs in a multiprocessor computer.

  • A four-byte affinity mask covers up to 32 CPUs in a multiprocessor computer.

Because setting the SQL Server processor affinity option is an advanced operation, it is recommended that it be used only when necessary. In most cases, the the 64-bit versions of the Windows Server 2003 family default affinity provides the best performance.

Note You can use the Windows System Monitor to view and analyze individual processor usage.

Consider the following as an example of setting the affinity mask option: if processors 1, 2, and 5 are selected as available with bits 1, 2, and 5 set to 1 and bits 0, 3, 4, 6, and 7 set to 0, a hexadecimal value of 0x26 or the decimal equivalent of 38 is specified. Number the bits from right to left. The rightmost bit is bit 0. Set bits 1, 2, and 5 (the third, fifth, and sixth bits) to 1. The number calculated from setting the specified bits is binary 00100110, which is decimal 38 or hexadecimal 0x26.

These are affinity mask values for an eight-processor system.

Decimal value | Binary bit mask | Allow SQL Server threads on processors
1 | 00000001 | 0
3 | 00000011 | 0 and 1
7 | 00000111 | 0, 1, and 2
15 | 00001111 | 0, 1, 2, and 3
31 | 00011111 | 0, 1, 2, 3, and 4
63 | 00111111 | 0, 1, 2, 3, 4, and 5
127 | 01111111 | 0, 1, 2, 3, 4, 5, and 6 (isolates SQL Server activity from DPC processor only)

affinity mask is an advanced option. If you are using the sp_configure system stored procedure to change the setting, you can change affinity mask only when show advanced options is set to 1. This setting takes effect immediately.

For more information, see the following topics in SQL Server 2000 32-bit Books Online:

  • Monitoring with System Monitor

  • RECONFIGURE

  • Setting Configuration Options

  • sp_configure

  • SQL-DMO Objects and SQL Server Administration


affinity64 mask Option (64-bit)

An association between a thread and a processor is called processor affinity, and such an association is generally beneficial for the performance of Microsoft® SQL Server™. At the operating system level, however, Microsoft Windows® sometimes moves process threads among different processors in order to handle multitasking. While the operating system performs more efficiently because of this technique, SQL Server performance can actually be reduced under heavy system loads, as each processor cache is repeatedly reloaded with data.

Microsoft SQL Server 2000 (64-bit) supports processor affinity by means of two affinity mask options: affinity mask and affinity64 mask. For more information about the affinity mask option, see affinity mask Option (64-bit)

Note The affinity64 mask option is only available for SQL Server 2000 (64-bit).

The affinity64 mask option, new in SQL Server 2000 (64-bit), dynamically controls CPU affinity on 64-bit systems. Use the affinity64 mask option to increase performance on 64-bit symmetric multiprocessor (SMP) systems with more than 32 microprocessors operating under heavy load.

Because affinity64 mask is a 32-bit value, this option controls a maximum of 32 processors. The 32-bit mask that affinity64 mask option holds supports the upper 32 bits of a 64-bit mask, if there are 64 processors. Thus, to set affinity on either a 32- or 64-bit system with fewer than 33 processors, you only need to manipulate the affinity mask option. To set affinity on a system with 33 to 64 processors, you must manipulate both the affinity mask option and the affinity64 mask option, treating the two 32-bit values as if they were one 64-bit value for the purpose of identifying your affinity to the system. For more information on setting affinity for the first 32 processors, see affinity mask Option (64-bit).

If you set affinity64 mask to 1 (that is, you set a bit representing a processor to 1), that processor is selected for thread assignment. When you set affinity64 mask to 0 (the default), the the 64-bit versions of the Windows® Server 2003 family scheduling algorithms set the thread's affinity. When you set affinity64 mask to any nonzero value, SQL Server affinity interprets the value as a bit mask that specifies those processors eligible for selection. Excluding SQL Server threads from running on particular processors helps evaluate the system's handling of processes specific to the 64-bit versions of the Windows Server 2003 family. For example, you can use affinity64 mask to evaluate whether an additional network interface card (NIC) increases performance or assess NIC performance with increasing loads.

Because setting the SQL Server processor affinity option is a specialized operation, it is recommended that it be used only when necessary. In most cases, the the 64-bit versions of the Windows Server 2003 family default affinity provides the best performance.

Note You can use the Windows System Monitor to view and analyze individual processor usage.

affinity64 mask is an advanced option. If you are using the sp_configure system stored procedure to change the setting, you can change affinity64 mask only when show advanced options is set to 1. This setting takes effect immediately.


How To (64-bit)

This set of How To topics includes common procedures used in installing Microsoft® SQL Server™ 2000 (64-bit).

  • How to install SQL Server 2000 (64-bit)

  • How to change SQL Server services login account information (64-bit)

  • How to change SQL Server services login account information remotely (64-bit)

  • How to set up SQL Server from a command prompt (64-bit)

  • How to add or remove features in an instance of SQL Server 2000 (64-bit)

  • How to access SQL Server Books Online (64-bit)

  • How to create a case-sensitive instance of SQL Server 2000 (64-bit)

  • How to remove SQL Server 2000 (64-bit)


How to install SQL Server 2000 (non-clustered installations only) (64-bit)

To install SQL Server 2000

  1. Insert the Microsoft® SQL Server™ 2000 (64-bit) compact disc in your CD-ROM drive.

    If you are installing from a network location, share the installation files and connect to the location from the computer where you want to install the program.

  2. In the root folder of the compact disc or installation location on the network, double-click Setup.exe.

  3. Click Start a new installation.

    Local Instance is the only selection for this release of SQL Server 2000 (64-bit).

    Important For installation of a failover cluster, do not continue this procedure. See How to create a new failover cluster (Setup) (64-bit).

  4. On the Welcome page, click Next.

  5. On the Registration Information page, enter the user name, company, and product key.

  6. On the Software License Agreement page, read the license agreement and click Yes to accept the license agreement. Clicking No ends Setup.

  7. On the Feature Selection page, you can select or remove features installed with SQL Server 2000, and you can change installation locations of features.

    For additional information about the features of SQL Server 2000, see Feature Selection (64-bit).

    Note To install all of the features of SQL Server 2000 in their default locations, make no changes and accept the default settings.

  8. On the Instance Name page, if the Default instance option is available, you can install either the default or a named instance. If the Default instance option is not available, a default instance has already been installed, and you can install only a named instance.
    • To install the default instance, click the Default instance check box.

    • To install a named instance, click the Named instance check box, and type a name for the instance. For more information, see Naming Instances (64-bit).
  9. On the Service Account page, configure the logon account information for SQL Server 2000 service accounts.

    Select the Advanced check box to configure the different service accounts separately.

  10. On the Authentication Mode page, accept the default setting.

    Security Note When possible, use Windows Authentication.

    To use Mixed Mode, see Defining the Authentication Mode (64-bit).

  11. On the Collation Settings page, change the default settings for collation and sort order only if your installation of SQL Server must match the collation settings used by another instance of SQL Server, or if it must match the Windows locale of another computer.

    If you need to match collation settings in instances of SQL Server or match the Microsoft Windows® locale of another computer, see Specifying the Collation Setting (64-bit).

  12. On the Licensing Mode page, make selections according to your license agreement.

    Click Help for information about licensing or see your system administrator.

  13. On the Ready to Install page, click Install.

See Also

Installing SQL Server 2000 (64-bit)

How to add or remove features in an instance of SQL Server 2000 (Setup) (64-bit)


How to change SQL Server services login account information (64-bit)

To change SQL Server services login account information

  1. In Administrative Tools in Control Panel, double-click the Services icon.

  2. In the Services right pane, double-click the service you want to configure.
    Service | For
    MSSQLSERVER | The default instance of Microsoft SQL Server™.
    MSSQL$instancename | A named instance of SQL Server, where instancename is the name of the instance.
    SQLSERVERAGENT | SQL Server Agent for the default instance.
    SQLAgent$instancename | SQL Server Agent for a named instance, where instancename is the name of the instance.
    MSSQLServerOLAPService | SQL Server 2000 Analysis Services.

  3. On the Log On tab, click This account, and change the password or account information.

    Note For SQL Server to start successfully, the account must be a member of the local Administrators group. To provide network access, it must also be a domain account.

See Also

How to change SQL Server services login account information remotely (64-bit)

Creating Windows Service Accounts (64-bit)


How to change SQL Server services login account information remotely (64-bit)

Note This version of Microsoft® SQL Server™ 2000 (64-bit) does not install SQL Server Enterprise Manager. This procedure describes how to use SQL Server Enterprise Manager on the Microsoft Windows® 2000 operating system to remotely manage the 64-bit version of SQL Server 2000.

Note If Microsoft SQL Server files are encrypted, you must decrypt the files before you can change the SQL Server service accounts. If you do not decrypt the files and then reset the SQL Server service accounts, you cannot decrypt the files.

To change the MSSQLServer service login (Enterprise Manager)

  1. Expand a server group.

  2. Right-click a server, and then click Properties.

  3. In the SQL Server Properties dialog box, click the Security tab.

  4. In the Startup service account box, the option for This Account is selected, indicating that the SQL Server service account is a Windows domain account. Enter changes as necessary for the account and password.

    Note For SQL Server to start successfully, the account must be a member of the local Administrators group on the remote computer where SQL Server is installed. To provide network access, it must also be a domain account.

To change the SQLServerAgent service login (Enterprise Manager)

Note The Windows account must be a member of the sysadmin fixed server role to run SQL Server Agent.

  1. Expand a server group, and then expand a server.

  2. Expand Management.

  3. Right-click SQL Server Agent, and then click Properties.

  4. In the SQL Server Agent Properties dialog box, click the General tab.

  5. In the Service startup account box, enter the appropriate account and password.

See Also

How to change SQL Server services login account information (64-bit)

Creating Windows Service Accounts (64-bit)

Changing Passwords and User Accounts (64-bit)

Creating Windows Service Accounts (64-bit)


How to set up SQL Server from a command prompt (64-bit)

You can run the SQL Server 2000 (64-bit) Setup program directly from a command prompt or in a batch file.

To run an unattended installation directly from a command prompt

  1. On a command prompt or in a batch file, use Setup.exe from the root folder of the SQL Server edition you want to install.

  2. Use arguments and properties as needed.

    For the Setup command syntax, arguments, and properties, see SQL Server 2000 (64-bit) Setup Command.

    To create an .ini file in which to specify properties, use the Template.ini file in the root folder of your compact disc.

See Also

Running Setup to Install SQL Server 2000 (64-bit)


How to add or remove features in an instance of SQL Server 2000 (64-bit)

To add features to an instance using Add or Remove Programs

  1. In Control Panel, double-click the Add or Remove Programs icon.

  2. Under Currently installed programs, click the instance of Microsoft® SQL Server™ to configure, and then click Change.

  3. On the Change or Remove page, click Change Installed Features.

  4. On the Feature Selection page, you can select or remove features installed with SQL Server 2000.

  5. Click Next, and then follow the instructions on subsequent wizard pages.

To add features to an instance using Setup

  1. From the desktop or Windows Explorer, start Setup.exe on the SQL Server 2000 (64-bit) compact disc.

  2. On the Setup Mode page of the Installation Wizard, click Work with an existing installation.

  3. In the drop-down list, select the instance that you want to maintain.

  4. Click Next, and then on the Change or Remove page, click Change Installed Features.

  5. On the Feature Selection page, you can select or remove features installed with SQL Server 2000.

  6. Click Next, and then follow the instructions on subsequent wizard pages.

See Also

How to remove SQL Server 2000 (64-bit)

How to install SQL Server 2000 (Setup) (64-bit)


How to access SQL Server Books Online (64-bit)

Note This version of Microsoft® SQL Server™ 2000 (64-bit) includes the SQL Server 2000 (32-bit) Books Online. For setup and documentation differences between the two versions, refer to the Readme.txt file on the installation disk and to this SQL Server Setup Help file (Setupsql.chm) in the SQL Server 2000 (64-bit) installation folder.

To access SQL Server Books Online for SQL Server from the Start menu

  • On the Start menu, point to Programs and Microsoft SQL Server, and then click Books Online.

    This opens the Microsoft SQL Server 2000 (32-bit) Books Online.

To create a shortcut to the 64-bit SQL Server Setup Help file

  1. Locate the Setup Bootstrap Setupsql.chm file on your computer. (The default location is systemdrive\Program Files\Microsoft SQL Server\80\SetupBootstrap\Help\1033.)

  2. Right-click Setupsql.chm, and then click Create Shortcut.

  3. Copy the shortcut to the desktop, where you can use it to access the 64-bit SQL Server Setup help.


How to create a case-sensitive instance of SQL Server 2000 (64-bit)

Important Change the default settings for this and the sort order only if your installation of SQL Server must match the collation settings used by another instance of SQL Server 2000, or if it must match the Windows locale of another computer.

To create a case-sensitive instance of SQL Server 2000

  1. Run Microsoft® SQL Server™ Setup.

  2. Click Start a new installation.

  3. Follow instructions on the Welcome, Registration Information, and Software License Agreement pages.

  4. On the Feature Selection page, choose to install Server Components (this is the default setting). You can change or leave other default settings.

  5. On the Instance Name page:
    • To create a case-sensitive default instance, click the Default instance (this is available only if there is no default instance already installed).

    • To create a case-sensitive named instance, click Named instance, and type an instance name.
  6. On the Service Account and Authentication Mode pages, change or accept the default settings.

    Security Note When possible, use Windows Authentication.

  7. On the Collation Settings page, you have two options:
    • To make a Windows Locale collation case-sensitive, select Collation designator and then select the correct collation designator from the list. Select the Case-sensitive check box. If the Binary check box is selected, clear it.

    • To make a SQL collation case-sensitive, select SQL Collations, and then select the correct collation name.

    For more information about collation options, click Help. When you finish setting the options, click Next.

  8. On the Licensing Mode page, make selections according to your license agreement.

  9. On the Ready to Install page, click Install.

See Also

Specifying the Collation Setting (64-bit)


How to remove SQL Server 2000 (64-bit)

To remove an instance of SQL Server 2000

  1. In Control Panel, double-click the Add or Remove Programs icon.

  2. Select the named or default instance of Microsoft® SQL Server™ 2000, and click Remove.

To remove all instances of SQL Server 2000

  1. In Control Panel, click Add or Remove Programs.

  2. Repeat the removal process for each instance of SQL Server 2000 that is installed.

To remove an instance using Setup

  1. In My Computer or Windows Explorer, start Setup.exe on the SQL Server 2000 (64-bit) compact disc.

  2. On the Setup Mode page of the Installation Wizard, click Work with an existing installation.

  3. In the drop-down list, select the instance that you want to remove.

  4. Click Next, and then on the Change or Remove page, click Remove Microsoft SQL Server.

  5. Follow the instructions on subsequent wizard pages.


How To Create or Maintain a Failover Cluster (64-bit)

The How To topics in this section contain information on creating or maintaining a failover cluster. Before you create a Microsoft® SQL Server™ 2000 (64-bit) failover cluster, you must configure Microsoft Cluster Services (MSCS) by using the Cluster Administrator.


How to create a new failover cluster (Setup) (64-bit)

 SQL Server 2000 (64-Bit)

How to create a new failover cluster (64-bit)

This topic applies only to SQL Server 2000 (64-bit).

Important Before you create a Microsoft® SQL Server™ 2000 (64-bit) failover cluster, you must configure Microsoft Cluster Service (MSCS) by using the Cluster Administrator in the 64-bit versions of the Windows® Server 2003 family (additional 64-bit Windows operating systems will be available for future releases of SQL Server 2000 [64-bit]). Note the group that contains the cluster drive you want SQL Server to use by using Cluster Administrator before you run SQL Server Setup. You need this information to create a new failover cluster.

To create a new failover cluster

  1. On the Setup Mode page, select Start a new installation. In the drop down box, select Virtual Server. Click Next.

  2. On the Welcome page of the Microsoft SQL Server Installation Wizard, click Next.

  3. On the Registration Information page, enter the user name and company. Click Next.

  4. On the Software License Agreement page, read the license agreement. If you agree, click Yes.

  5. On the Virtual Server Name page, enter a virtual server name. This is the name of the new virtual server you are creating, so it should be unique across the network. Click Next.

  6. On the Cluster Group Selection page, select the group that contains the drive you want to use for SQL Server from the Available Cluster Groups. The selected cluster group is where the SQL Server virtual server resources will be placed. If you select the group containing the cluster quorum resource, a warning will be displayed recommending you do not install to the cluster quorum resource. Click Next.

  7. On the Failover Clustering page, enter one IP address for each network you wish to configure for client access. That is, enter one IP address for each network on which the virtual server will be available to clients on a public (or mixed) network. Select the network for which you want to enter an IP address, and then enter the IP address. Click Add.

    The network address and the subnet are displayed. The subnet is supplied by MSCS. Continue to enter IP addresses for each installed network until you have populated all desired networks with an IP address. Click Next.

  8. On the Instance Name page, choose a default instance or specify a named instance. To specify a named instance, select Named Instance, and then enter the name for the named instance. Click Next.

    Important You cannot name an instance DEFAULT or MSSQLSERVER. For more information, see the "Working with Named and Multiple Instances of SQL Server 2000" topic in the SQL Server 2000 32-bit Books Online. Names must follow rules for SQL Server identifiers. For more information, see the "Using Identifiers" topic in the SQL Server 2000 32-bit Books Online.

  9. On the Configure Nodes page, select the nodes to include in the virtual server cluster definition. All available nodes (by default) are included in the Selected Nodes list. You can remove any nodes you do not wish to include by clicking Remove until only the desired nodes appear in the Selected Nodes list. Any nodes that are unavailable are displayed in the Unavailable Nodes list, as well as the reason the node is unavailable. Click Next.

    Note In Microsoft® SQL Server™ 2000 Enterprise Edition (64-bit), the number of nodes supported for failover clustering depends on the operating system.

  10. On the Remote Account Information page, enter the login credentials for the remote cluster node, including the Username, Password, and Domain. The login credentials must have local administrator privileges on all node(s) of the cluster and its resources. This dialog will only appear if you are installing a remote node(s). Click Next.

  11. On the Installation Folder page, choose the destination drive and directory name for the SQL Server program files. By default, all available drives will be in the Program Files and Data Files drop down lists. You must select a drive that is available on every node of the cluster. Then choose the destination drive and directory name for the SQL Server data files. You will be required to select a clustered drive resource that is contained within the cluster group you chose earlier. Click Next.

  12. On the Service Account page, select the login credentials for the service accounts. Enter the Username, Password, and Domain of the Domain User account for the virtual server. All service accounts for a virtual server must be domain accounts. Check the Advanced box to specify the Username, Password, and Domain for specific services. Select the service from the Service list. The account for the SQL Server Agent service must be an administrator on all nodes of the cluster. Do not use the same account that was assigned to the Cluster service. Click Next.

  13. On the Authentication Mode page, choose the authentication mode to use. If you change the selection from Windows Authentication Mode to Mixed Mode (Windows Authentication and SQL Server Authentication), you need to enter and confirm a password for the sa login, or choose to set a blank password. Setting a blank password is not recommended. Click Next.

    Security Note When possible, use Windows Authentication.

    Security Note Do not use a blank password. Use a strong password.

  14. On the Collation Settings page, choose the sorting behavior for your server. Click Next.

  15. On the Licensing Mode page, select Per Seat or Processor License for SQL Server. Enter the appropriate number of licenses. Click Next.

  16. On the Ready to Install page, click Install to proceed with the installation.

  17. On the Completing the Microsoft SQL Server Installation Wizard page, click Finish.

    If you are instructed to restart the computer, do so now. It is important to read the message from the Setup program when you are done with installation. Failure to restart any of the specified nodes may cause failures when you run the Setup program in the future on any node in the failover cluster.


How to create a one-node failover cluster (Setup) (64-bit)

 SQL Server 2000 (64-Bit)

How to create a one-node failover cluster (64-bit)

This topic applies only to SQL Server 2000 (64-bit).

  1. On the Setup Mode page, select Start a new installation. In the drop down box, select Virtual Server. Click Next.

  2. On the Welcome page of the Microsoft SQL Server Installation Wizard, click Next.

  3. On the Registration Information page, enter the user name and company. Click Next.

  4. On the Software License Agreement page, read the license agreement. If you agree, click Yes.

  5. On the Virtual Server Name page, enter a virtual server name. This is the name of the new virtual server you are creating, so it should be unique across the network. Click Next.

  6. On the Cluster Group Selection page, select the group that contains the drive you want to use for SQL Server from the Available Cluster Groups. The selected cluster group is where the SQL Server virtual server resources will be placed. If you select the group containing the cluster quorum resource, a warning will be displayed recommending you do not install to the cluster quorum resource. Click Next.

  7. On the Failover Clustering page, enter one IP address for each network you wish to configure for client access. That is, enter one IP address for each network on which the virtual server will be available to clients on a public (or mixed) network. Select the network for which you want to enter an IP address, and then enter the IP address. Click Add.

    The network address and the subnet are displayed. The subnet is supplied by MSCS. Continue to enter IP addresses for each installed network until you have populated all desired networks with an IP address. Click Next.

  8. On the Instance Name page, choose a default instance or specify a named instance. To specify a named instance, select Named Instance, and then enter the name for the named instance. Click Next.

    Important You cannot name an instance DEFAULT or MSSQLSERVER. For more information about naming instances of SQL Server 2000, see Working with Named and Multiple Instances of SQL Server 2000. Names must follow rules for SQL Server identifiers. For more information about naming conventions for identifiers, see Using Identifiers.

  9. On the Configure Nodes page, remove all nodes from the Selected Nodes list by clicking Remove. The only node that will be installed with the virtual server should be listed in the Required Node list. Any nodes that are unavailable are displayed in the Unavailable Nodes list, as well as the reason the node is unavailable. Click Next.

  10. On the Remote Account Information page, enter the login credentials for the remote cluster node, including the Username, Password, and Domain. The login credentials must have local administrator privileges. This dialog will only appear if you are installing to a remote node. Click Next.

  11. On the Installation Folders page, choose the destination drive and directory name for the SQL Server program files. By default, all available drives will be in the Program Files and Data Files drop down lists. You must select a drive that is available on every node of the cluster. Then choose the destination drive and directory name for the SQL Server data files. You will be required to select a clustered drive resource that is contained within the cluster group you chose earlier. Click Next.

  12. On the Service Account page, select the login credentials for the service accounts. Enter the Username, Password, and Domain of the Domain User account for the virtual server. All service accounts for a virtual server must be domain accounts. Check the Advanced box to specify the Username, Password, and Domain for specific services. Select the service from the Service list. The account for the SQL Server Agent service must be an administrator for the cluster node. Do not use the same account that was assigned to the Cluster service.

  13. On the Authentication Mode page, choose the authentication mode to use. If you change the selection from Windows Authentication Mode to Mixed Mode (Windows Authentication and SQL Server Authentication), you need to enter and confirm a password for the sa login, or choose to set a blank password. Setting a blank password is not recommended. Click Next.

    Security Note When possible, use Windows Authentication.

  14. On the Collation Settings page, choose the sorting behavior for your server. Click Next.

  15. On the Licensing Mode page, select Per Seat or Processor License for SQL Server. Enter the appropriate number of licenses. Click Next.

  16. On the Ready to Install page, click Install to proceed with the installation.

  17. On the Completing the Microsoft SQL Server Installation Wizard page, click Finish.

    If you are instructed to restart the computer, do so now. It is important to read the message from the Setup program when you are done with installation. Failure to restart any of the specified nodes may cause failures when you run the Setup program in the future on any node in the failover cluster.


How to add a node to an existing virtual server (Setup) (64-bit)

 SQL Server 2000 (64-Bit)

How to add a node to an existing virtual server (64-bit)

This topic applies only to SQL Server 2000 (64-bit).

  1. On the Setup Mode page, select Work with an existing installation. In the drop down box, select the virtual server to add nodes to. Click Next.

  2. On the Change or Remove page, click Maintain the Virtual Server.

  3. On the Failover Clustering page, click Next.

    You do not need to enter an IP address, unless you wish to add a new one, or modify an existing address.

  4. On the Configure Nodes page, ensure that all nodes to add to the virtual server are in the Selected Nodes list. Click Next.

  5. On the Remote Account Information page, enter the login credentials for the remote cluster node, including the Username, Password, and Domain. The login credentials must have local administrator privileges on all nodes of the cluster and the cluster resources. This dialog will only appear if you are installing remote nodes. Click Next.

  6. On the Service Account page, select the login credentials for the service accounts. Enter the Username, Password, and Domain of the Domain User account for the virtual server. All service accounts for a virtual server must be domain accounts. Check the Advanced box to specify the Username, Password, and Domain for specific services. Select the service from the Service list. The account for the SQL Server Agent service must be a local administrator on all nodes of the cluster. Do not use the same account that was assigned to the Cluster service.

  7. On the Ready to Update page, click Install to begin updating your virtual server.

  8. On the Completing the Microsoft SQL Server Installation Wizard page, click Finish.

    If you are instructed to restart the computer, do so now. It is important to read the message from the Setup program when you are done with installation. Failure to restart any of the specified nodes may cause failures when you run the Setup program in the future on any node in the failover cluster.


How to remove a node from an existing failover cluster (Setup) (64-bit)

 SQL Server 2000 (64-Bit)

How to remove a node from an existing failover cluster (64-bit)

This topic applies only to SQL Server 2000 (64-bit).

  1. On the Setup Mode page, select Work with an existing installation. In the drop down box, select the installation to remove a node from. Click Next.

  2. On the Change or Remove page, click Maintain the Virtual Server.

  3. On the Failover Clustering page, click Next. You do not need to enter an IP address.

  4. On the Configure Nodes page, select the node to remove from the Selected Nodes list. Click Remove, and then click Next.

  5. On the Remote Account Information page, enter the login credentials for the remote cluster node, including the Username, Password, and Domain. The login credentials must have administrator privileges on all nodes of the cluster. This dialog will only appear if you are removing remote nodes. Click Next.

  6. On the Ready to Update page, click Install to begin updating your virtual server and remove the selected node from your failover cluster.

  7. On the Completing the Microsoft SQL Server Installation Wizard page, click Finish.

    If you are instructed to restart the computer, do so now. It is important to read the message from the Setup program when you are done with installation. Failure to restart any of the specified nodes may cause failures when you run the Setup program in the future on any node in the failover cluster.


How to remove a failover clustered instance (Setup) (64-bit)

 SQL Server 2000 (64-Bit)

How to remove a failover clustered instance (64-bit)

This topic applies only to SQL Server 2000 (64-bit).

  1. On the Setup Mode page, select Work with an existing installation. In the drop down box, select the installation to remove. Click Next.

  2. On the Change or Remove page, click Remove Microsoft SQL Server.

  3. On the Remove Microsoft SQL Server page, click Remove.


How to recover from failover cluster failure in Scenario 1 (64-bit)

In this scenario, failure is caused by hardware failure in Node 1 of a two-node cluster. This hardware failure could be caused, for example, by the failure of a disk controller or the operating system.

  1. After Node 1 fails, the Microsoft® SQL Server™ 2000 (64-bit) failover cluster fails over to Node 2.

  2. Run SQL Server Setup and remove Node 1. For more information, see How to remove a failover clustered instance (Setup) (64-bit).

  3. Evict Node 1 from Microsoft Cluster Service (MSCS). To evict a node from MSCS, from Node 2, open Cluster Administrator, and right-click the node to remove, and then click Evict Node.

  4. Install new hardware to replace the failed hardware in Node 1.

  5. Install the operating system. For more information about which operating system to install and specific instructions on how to do this, see Before Installing Failover Clustering (64-bit).

  6. Install MSCS and join the existing cluster using the Cluster Administrator. For more information, see Before Installing Failover Clustering (64-bit).

  7. Run the Setup program on Node 2 and add Node 1 back to the failover cluster. For more information, see How to add nodes to an existing virtual server (Setup) (64-bit).


How to recover from failover cluster failure in Scenario 2 (64-bit)

In Scenario 2, failure is caused by Node 1 being down or offline but not irretrievably broken. This could be caused, for example, by an operating system failure.

  1. After Node 1 fails, the Microsoft® SQL Server™ 2000 (64-bit) failover cluster fails over to Node 2.

  2. Run SQL Server Setup and remove Node 1. For more information, see How to remove a failover clustered instance (Setup) (64-bit).

  3. Resolve the problem with Node 1.

  4. Ensure that the Microsoft Cluster Service (MSCS) cluster is working and all nodes are online.

  5. Run the Setup program on Node 2 and add Node 1 back to the failover cluster. For more information, see How to add nodes to an existing virtual server (Setup) (64-bit). If you need to change domains for a SQL Server failover cluster, search on KB Article Q319016 in the Microsoft Knowledge Base at the Microsoft Web site.


User Interface Reference (64-bit)

This section describes the installation options of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard. Options include installing the SQL Server relational database engine, Analysis Services, installing a failover cluster, or changing or removing a current installation. The Installation Wizard has the following pages.

Topic | Description
Setup Mode (64-bit) | Describes choosing between a new installation and working with an existing one
Registration Information (64-bit) | Covers the product registration options for SQL Server
Feature Selection (64-bit) | Describes how to add and remove SQL Server features
Instance Name (64-bit) | Outlines guidelines for naming instances
Service Account (64-bit) | Describes how to assign login accounts to SQL Server services
Authentication Mode (64-bit) | Discusses security options for your installation
Collation Settings (64-bit) | Covers options for controlling language and sort order in SQL Server
Licensing Mode (64-bit) | Describes licensing mode options
Backward Compatibility (64-bit) | Describes backward compatibility considerations for cross-database ownership chaining
Error Reporting (64-bit) | Describes error reporting options for SQL Server components
Virtual Server Name (64-bit) | Describes how to name a failover cluster
Cluster Group Selection (64-bit) | Covers selecting cluster group options
Failover Clustering (64-bit) | Discusses failover clustering options
Configure Nodes (64-bit) | Defines options for configuring cluster nodes
Remote Account Information (64-bit) | Outlines options for setting up a remote account for the virtual server in a failover cluster
Installation Folders (64-bit) | Discusses options for specifying where SQL Server program files and data files will be installed


Setup Mode (64-bit)

Use the Setup Mode page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to choose whether to create a new installation or work with an existing instance of SQL Server.

Options

Start a new installation

Creates a new installation of SQL Server 2000. Choose this option to create either a default or a named instance of SQL Server, or a SQL Server failover cluster. You can use this option to install any or all of the following features: the SQL Server relational database engine, Analysis Services, or Books Online. If a cluster is detected, Virtual server is selected by default. If no cluster is detected, Local Instance is the only selection for this release of SQL Server 2000 (64-bit).

Work with an existing installation

Enables you to add or remove SQL Server features. If you currently have an instance of the beta release of SQL Server 2000 (64-bit) installed on your computer, your options for working with an existing database will be to utilize the backup/restore or detach/attach processes to preserve your current databases

See Also

Starting Setup (64-bit)


Registration Information (64-bit)

Use the Registration Information page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to enter identification information used to register your copy of SQL Server (64-bit).

Options

Name

Type your name. When installing SQL Server on a network server, provide the name of a user responsible for administering the server. A user name is required to continue Setup.

Company

Enter the name of your company. For a personal copy of the product, you can provide your name again. This information is optional.

Product Key

If the Product Key fields do not auto-populate, enter the 25-character Product Key for the installation copy of SQL Server 2000 (64-bit). You can find the Product Key on the yellow sticker in the CD liner notes or on the CD case. If you are installing from a network location, request the Product Key from the network or SQL Server administrator. The Product Key is required to continue Setup.

See Also

Starting Setup (64-bit)


Feature Selection (64-bit)

Use the Feature Selection page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to choose which SQL Server features to install. This dialog is displayed both when you run the SQL Server Setup program and after you choose Add or Remove Programs in Control Panel. For an existing installation, you can use this page to add or remove features.

Options

The Feature Selection page consists of two panes. The left pane shows in a tree view the features that you can install. Expand a feature to view its subfeatures. When you click a feature or subfeature, the Feature Description box in the right pane describes the selection and displays its disk space requirements.

To add or remove a feature, click the icon representing the feature and choose one of the following options from the drop-down list:

Will be installed on local hard drive
Installs the selected feature in the location shown under Installation Path.
Entire feature will be installed on local hard drive
Installs the selected feature and all subfeatures. Expand the feature to view subfeatures.
Entire feature will be unavailable
For a new installation of SQL Server, choose this option if you do not want to install the selected feature. For an existing installation, choose this option to remove the feature from the installation. After you select this option, a red X will appear on the menu icon for the feature, and the icon on any parent features in the tree view will appear shaded.

The Feature Selection page also offers the following options:

Installation path

Shows the folder where files for the selected feature will be installed. This option is displayed only for features with an installation path that users can configure.

Browse

Click this to change the location where the selected feature will be installed.

Disk Cost

Click this to examine the available space for installing to different disks on the computer. After examining the disk space on your computer in the Disk Cost dialog box, you can click Resume to continue installing SQL Server or Exit to quit Setup.

See Also

Specifying SQL Server Features (64-bit)


Instance Name (64-bit)

Use the Instance Name page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to specify whether to create a default instance or a named instance of SQL Server. A default instance name will be used unless you choose a named instance.

Options

Default instance

Choose this option to install a default instance of SQL Server 2000. If this option is disabled, it is because Setup has detected a default instance of SQL Server already installed on this computer. A computer can host only one default instance; all other instances must be named.

Named instance

Choose this option to enter a new instance name. Note the following when naming an instance of SQL Server:

  • Instance names are not case-sensitive.

  • Instance names cannot contain "Default" or "MSSQLServer."

  • The first character in the instance name must be a letter, an underscore (_), or a number sign (#). Acceptable letters are those defined by Unicode Standard 2.0, including Latin characters a-z, A-Z, and letter characters from other languages. Numbers and the ampersand sign (&) are not allowed.

  • Subsequent characters can be letters defined by Unicode Standard 2.0, decimal numbers from Basic Latin or other national scripts, the dollar sign ($), number sign (#), or an underscore (_).

  • Embedded spaces or other special characters are not allowed in instance names; nor are the backslash (\), comma (,), colon (:), or at sign (@).

  • The identifier may not be a reserved keyword. If you enter a reserved keyword as part of the instance name, an error occurs with the message: "The instance name specified is invalid."

    Note Only characters that are valid in the current Microsoft Windows® code page can be used in SQL Server instance names. If an unsupported Unicode character is used, an error occurs.


Service Account (64-bit)

Use the Service Account page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to assign a login account to these SQL Server services: SQL Server, SQL Server Agent, and Analysis Services. The actual services configured on this page depend on the features you have selected to install.

You can assign either the local system account or a domain user account to all SQL Server services. You can also configure each service account individually, and specify whether the services start automatically. The default is to use the same account for each service and to start each service automatically. To use the default setting, enter the domain name, username, and password, and then click Next.

If you want to customize settings for individual services, select the Advanced check box, and then change the settings for each service in the Service list.

Note To change options that you set on the Service Account page at a later time, run the Services application in Control Panel.

Options

Advanced

Select this check box to assign specific login accounts to different services.

If this check box is not selected, the same account and settings are used for all SQL Server 2000 services.

Service

Select any of the following services to customize their settings.

Select this | To configure
SQL Server | Service settings for the Microsoft SQL Server relational database engine
SQL Server Agent | Service settings for Microsoft SQL Server Agent
Analysis Services | Service settings for Microsoft SQL Server Analysis Services

Service Settings

Select service settings as required.

Use the Local System account
The local system account does not require a password to connect to SQL Server on the same computer. However, the local system account may restrict the SQL Server installation from interacting with other servers.
Use a Domain User account
A domain user account uses Windows Authentication to set up and connect to SQL Server. By default, account information appears for the domain user account currently logged on to the computer.
Username
Accept or change the domain username.
Password
Enter the domain password.
Domain
Accept or change the domain name assigned to the account.
Auto-start service
Select this check box to automatically start the services when your operating system is started. If the Advanced check box is cleared, this option applies to all the services; if the Advanced check box is selected, this option applies only to the service shown in the Service field.

Note The SQL Server Agent service is dependent on SQL Server. If you select this check box separately for the SQL Server Agent, it will also be selected and dimmed for SQL Server.

See Also

Specifying Service Accounts (64-bit)


Authentication Mode (64-bit)

Use the Authentication Mode page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to choose the security (authentication) mode for this installation. If you select Mixed Mode, you can enter and confirm the SQL Server system administrator (sa) password. After a device completes a successful connection to SQL Server, the security mechanism is the same for both modes.

Options

Windows Authentication Mode

When a user connects through a Microsoft Windows® user account, SQL Server validates the account name and password using information in the Windows operating system. This is the recommended authentication mode.

Security Note When possible, use Windows Authentication.

Mixed Mode (Windows Authentication or SQL Server Authentication)

Allows users to connect using Windows Authentication or SQL Server Authentication. Users who connect through a Windows user account can make use of trusted connections (connections validated by Windows) in either Windows Authentication Mode or Mixed Mode.

Note SQL Server Authentication is used for validating SQL Server login accounts. SQL Server Authentication is provided for backward compatibility only. Microsoft recommends use of Windows Authentication mode.

Enter Password

Enter and confirm the system administrator (sa) login for SQL Server Authentication. SQL Server passwords can contain from 1 to 128 characters, including any combination of letters, symbols, and numbers. If you choose Mixed Mode authentication, you must enter a password before you can continue to the next page of the Installation Wizard.

If you leave the sa password field blank, the Installation Wizard launches a confirmation dialog box when you continue Setup. This dialog box recommends that you set a strong password to secure your database server, even if you are using Windows Authentication. To set a non-blank password, click No on the confirmation dialog box. You will return to the Authentication Mode page where you can set your sa password. To leave your sa password blank and proceed with Setup, click Yes on the confirmation dialog box to confirm your choice to set a blank sa password. The Installation Wizard will then proceed with Setup.

Caution Leaving the sa login password blank is strongly discouraged, because users can then connect to SQL Server as administrators, risking inadvertent or malicious data corruption or loss.

See Also

Defining the Authentication Mode (64-bit)


Collation Settings (64-bit)

Use the Collation Settings page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to modify default collation settings that SQL Server uses for language and sorting purposes. Change the Collation designator option only if your installation of SQL Server must match the collation settings used by another instance of SQL Server 2000, or must match the Windows locale of another computer. Use the SQL Collations option to match settings that are compatible with the sort orders in earlier versions of SQL Server.

Options

Collation designator

Designates the collation to be used by this instance of SQL Server 2000. The default setting for this is the Microsoft Windows® locale setting for your computer (the Language for non-Unicode programs setting or the closest equivalent from the Regional and Language Options in Control Panel). Change the default settings for this and the sort order only if your installation of SQL Server must match the collation settings used by another instance of SQL Server 2000, or if it must match the Windows locale of another computer.

In the list, select the name of a specific Windows collation. For example:

  • Use Latin1_General for the U.S. English character set (code page 1252).

  • Use Modern_Spanish for all variations of Spanish, which also use the same character set as U.S. English (code page 1252).

  • Use Arabic for all variations of Arabic, which use the Arabic character set (code page 1256).

  • Use Japanese_Unicode for the Unicode version of Japanese (code page 932), which has a different sort order from Japanese, but the same code page (932).

    For more information, see the "Windows Collation Sorting Styles" topic in the SQL Server 2000 32-bit Books Online.

Sort order

Specifies the sort order to use with the Collation designator selected. Binary is the fastest sorting order and is case-sensitive. If Binary is selected, the Case-sensitive, Accent-sensitive, Kana-sensitive, and Width-sensitive options are not available. For more information, see the "Windows Collation Sorting Styles" topic in the SQL Server 2000 32-bit Books Online.

SQL Collations

The SQL Collations option is used for compatibility with earlier versions of SQL Server. Select this option to match settings compatible with SQL Server version 7.0, SQL Server version 6.5, or earlier. For more information, see the "Using SQL Collations" topic in the SQL Server 2000 32-bit Books Online.

For more information, see the "Specifying the Collation Setting" topic in the SQL Server 2000 32-bit Books Online.


Licensing Mode (64-bit)

Use the Licensing Mode page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to set the licensing mode that enables your clients to access SQL Server.

Options

Examine the licensing agreement packaged with SQL Server 2000 to find the type and quantity of licenses that were purchased with the product. Then on the Licensing Mode page of the Installation Wizard, choose one of the following two options:

Per Seat

This licensing mode requires a license for the computer running SQL Server as well as a Client Access License (CAL) for each client device that connects to the server. An example of a client device is a personal computer, workstation, terminal, personal digital assistant, or mobile phone. A specified number of CALs are included with the server license and the server software. If you choose this option, next to Devices, type the number of CALs purchased for SQL Server.

Processor License

This licensing mode requires a single license for each CPU in the computer running SQL Server. A processor license includes access for an unlimited number of users to connect from a corporate local area network, a wide area network, or the Internet. If you choose this option, next to Processors, type the number of processor licenses purchased for SQL Server.

See Also

Choosing the Licensing Mode (64-bit)


Backward Compatibility (64-bit)

Microsoft® SQL Server™ 2000 (64-bit) provides options for configuring cross-database ownership chaining. The following information will help you determine whether to apply the default cross-database ownership chaining behavior during Setup, or override the changes and allow cross-database ownership chaining for all user databases. In addition, this topic provides information about configuring support for cross-database ownership chaining after installation.

Ownership Chaining

All database objects have owners. When an object--such as a stored procedure, view, or user-defined function--references other objects, an "ownership chain" is established. SQL Server uses the ownership chain to determine how to check permissions.

When the same user owns the source object (the view, stored procedure, or user-defined function) and all target objects (underlying tables, views, or other objects), the ownership chain is said to be "unbroken." When the ownership chain is unbroken, SQL Server checks permissions on the source object but not on the target objects.

Ownership chaining simplifies security management by allowing users to grant permissions on views, stored procedures, and user-defined functions instead of on individual objects in the database. For example, a user who owns several tables can create a view that includes data from the tables. The user can then grant permissions on the view instead of on the individual tables.

Cross-Database Ownership Chaining

Cross-database ownership chaining occurs when a source object depends on objects in other databases.

A cross-database ownership chain works in the same way as ownership chaining within a database, except that an unbroken ownership chain is based on all the object owners being mapped to the same login account.

Therefore, in a cross-database ownership chain, if the source object in the source database and the target objects in the target databases are owned by the same login account, SQL Server does not check permissions on the target objects.

For example, if two databases are owned by the same login account, the dbo users in these databases are mapped to the same login account. If cross-database ownership chaining is enabled for these databases, source objects in the dbo schema can access target objects in the dbo schema of both databases.

Risks Associated with Cross-Database Ownership Chaining

Ownership chaining within a database is a useful application design technique; however, Microsoft does not recommend cross-database ownership chaining because of security risks. These risks are due to the actions that users with high-level privileges can perform:

  • Database owners and members of the db_ddladmin or db_owners database roles can create objects owned by other users. These objects can potentially target objects in other databases. This means that if you enable cross-database ownership chaining, you must fully trust these users with data in all databases.

  • Users with the CREATE DATABASE permission can create new databases and attach existing databases. If cross-database ownership chaining is enabled, these users can access objects in other databases from newly created or attached databases.

Even though Microsoft recommends turning off cross-database ownership chaining for maximum security, there are some environments where you can fully trust your highly-privileged users; for applications in those environments, you can enable cross-database ownership chaining at the database or instance level.

Setup Dialog Box Options

Use the following information to determine whether to select or clear the Enable cross-database ownership chaining for all databases check box:

  • When the box is cleared, Setup applies a change that, by default, turns off cross-database ownership chaining for all user databases. After installation, you can turn on cross-database ownership chaining for individual user databases using the db_option system stored procedure. This cross-database security enhancement enables you to configure which databases can be accessed from within other databases.

  • If you select the check box, you are overriding the security enhancement and choosing to allow cross-database ownership chaining for all databases. Selecting the check box therefore exposes your system to the security risks described above.

Regardless of which option you choose during Setup, you can later modify server and database support for cross-database ownership chaining.

Configuring Cross-Database Ownership Chaining After Installation

If, after running Setup, you need to change the cross-database ownership chaining configuration, use the new options in the sp_configure and sp_dboption stored procedures:

  • Configure cross-database ownership chaining support for the instance of SQL Server with the new Cross DB Ownership Chaining option of sp_configure. When this option is set to 0, you can control cross-database ownership chaining at the database level using sp_dboption. When this option is set to 1, cross-database ownership chaining is on in all user databases.

    If you change this option, include the RECONFIGURE option to reconfigure the instance without having to restart it. For example, use the following command to allow cross-database ownership chaining in all databases:

    EXEC sp_configure 'Cross DB Ownership Chaining', '1'; RECONFIGURE
  • Configure cross-database ownership chaining at the database level with the new db chaining option of sp_dboption. When this option is set to false, the database cannot participate in cross-database ownership chaining as either the source or target database. When this option is set to true, the database can participate in a cross-database ownership chain. By default, this option is false for all user databases after installation.

    The following command turns on cross-database ownership chaining for the Northwind database:

    EXEC sp_dboption 'Northwind', 'db chaining', 'true'

    You cannot turn off cross-database ownership chaining for the master, tempdb, and msdb databases. You cannot turn on cross-database ownership chaining for the model database, which is used as a template for user databases.

    The effects of sp_dboption are manifested only when the Cross DB Ownership Chaining option of sp_configure is set to 0.

For more information, see the following topics in the SQL Server 2000 32-bit Books Online:

  • "Using Ownership Chains"

  • "sp_configure"

  • "Setting Configuration Options"

  • "sp_dboption"


Error Reporting (64-bit)

Use the Error Reporting page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to enable error reporting.

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 SQL Server Enterprise Manager Server Properties dialog box or the Analysis Manager Server Properties dialog box (from a remote client running SQL Server 2000 SP3).

Enabling error reporting while running SQL Server Setup or Analysis Services Setup allows SQL Server error reporting for the SQL Server database engine, SQL Server Agent, and SQL Server Analysis Services. If you run SQL Server Setup and enable error reporting, and later run Analysis Services Setup, error reporting will automatically be enabled for the Analysis Services, as well as the SQL Server database engine and SQL Server Agent.

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:

  • The condition of SQL Server when the problem occurred.

  • The operating system version and computer hardware information.

  • Your Digital Product ID, which can be used to identify your license.

  • The network IP address of your computer.

  • Information from memory or file(s) of the process that caused the error.

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 file(s) 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 on 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=

To disable error reporting for the SQL Server database engine and SQL Server Agent, go to SQL Server Properties (General Tab) in Enterprise Manager (from a remote client running SQL Server 2000 SP3) and clear the Enable the error reporting feature check box. To disable error reporting for Analysis Services, go to Server Properties in Analysis Manager (from a remote client running SQL Server 2000 SP3) and clear the Enable the error reporting feature 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.


Virtual Server Name (64-bit)

Use the Virtual Server Name page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to specify the virtual server name.

Options

Virtual Server Name

Enter the name of a virtual server. The virtual server name must be a unique name in your network's domain.

See Also

Creating a Failover Cluster (64-bit)


Cluster Group Selection (64-bit)

Use the Cluster Group Selection page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to select the Microsoft Cluster Service (MSCS) cluster group. The selected cluster group is where the SQL Server virtual server resources will be placed.

Options

Available Cluster Groups

Select the MSCS cluster group where the SQL Server virtual server resources will be placed. If you select the group containing the cluster quorum resource, a warning will be displayed. It is recommended that you do not install to the cluster quorum resource.

Unavailable Cluster Groups

Any MSCS cluster groups that are unavailable are listed with the reason they are unavailable.

See Also

Creating a Failover Cluster (64-bit)


Failover Clustering (64-bit)

Use the Failover Clustering page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to define the IP address configuration for the virtual server.

Options

Virtual Server Name

Displays the name of the virtual server for which you are defining an IP address.

Network to use

Select the network for which you want to enter an IP address.

IP Address

Enter the IP address for each network you want to configure for client access. That is, enter one IP address for each network on which the virtual server will be available to clients on a public (or mixed) network.

Network Address

Displays the network address supplied by the Microsoft Cluster Service.

Network Subnet

Displays the network subnet supplied by the Microsoft Cluster Service.

Add

Click to add a network and IP address for each installed network, until you have populated all desired networks with an IP address.

Remove

Click to remove the selected network and IP address from the Selected Networks and IP Addresses box for an installed network.

Selected Networks and IP Addresses

Displays any selected networks and IP addresses configured for the virtual server.

See Also

Creating a Failover Cluster (64-bit)


Configure Nodes (64-bit)

Use the Configure Nodes page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to select the cluster nodes to include in the virtual server's cluster definition.

Options

Available Nodes

Displays the node(s) available to be included in the virtual server definition. Click Add to move an available node to the Selected Nodes list.

Selected Nodes

Displays the node(s) selected to be included in the virtual server definition.

Add

Click to move the selected node from the Available Nodes list to the Selected Nodes list, thereby adding the node to the virtual server definition.

Remove

Click to remove a selected node from the Selected Nodes list. This will remove the node from the virtual server.

Required Node

Displays the required node. The required node owns the cluster group where the SQL Server data files are installed.

Unavailable Nodes

Displays a list of unavailable nodes, and the reason each node is unavailable.

See Also

Creating a Failover Cluster (64-bit)


Remote Account Information (64-bit)

Use the Remote Account Information page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to enter remote account information for the virtual server.

Options

Username

Enter a username that is a valid local administrator account for all node(s) of the cluster.

Password

Enter a password for the selected valid local administrator account for all node(s) of the cluster.

Domain

Enter the domain for the selected domain user account, which is a valid local administrator account for all node(s) of the cluster.

See Also

Creating a Failover Cluster (64-bit)


Installation Folders (64-bit)

Use the Installation Folders page of the Microsoft® SQL Server™ 2000 (64-bit) Installation Wizard to specify the folders to which the SQL Server program files and data files will be installed.

Options

Program Files

Select the destination drive and folder name for the SQL Server program files. For clustered configurations, you must select a local drive that is available on every node of the cluster.

Available Space

Displays the available space for the selected drive.

Required Space

Displays the required space for the SQL Server program files.

Data Files

Select the destination drive and folder name for the SQL Server data files. For clustered configurations, you must select a cluster drive in the group you selected earlier.

Available Space

Displays the available space for the selected drive.

Required Space

Displays the required space for the SQL Server data files.

See Also

Creating a Failover Cluster (64-bit)