Service Pack 3a für Microsoft SQL Server 2000

09.04.03

© Copyright Microsoft Corporation, 2003. Alle Rechte vorbehalten.

 
Das Dokumentationsteam von SQL Server stellt keinen technischen Support bereit und kann daher keine Fragen beantworten. Ihre Vorschläge und Anmerkungen zu dieser Infodatei (Readme) sind jedoch willkommen. Mit der folgenden Verknüpfung können Sie Feedback schnell und direkt per E-Mail senden. Sämtliches Feedback muss auf Englisch sein.

Klicken Sie hier, um schriftliches Feedback zu diesem Dokument zu senden:  Feedback schreiben.
 

Inhalt

1.0 Einführung

    1.1 Übersicht über die Installation von Database Components SP3a

    1.2 Übersicht über die Installation von Desktop Engine (MSDE 2000) SP3a

    1.3 Entfernen von SP3a

    1.4 Identifizieren der aktuellen Version von SQL Server oder Analysis Services

    1.5 Zusätzliche Informationen zu SP3a

    1.6 Verfügbare aktualisierte Onlinedokumentation

    1.7 Verfügbare aktualisierte Beispiele zu SQL Server und Analysis Services

2.0 Downloaden und Extrahieren von SP3a

    2.1 Downloaden und Extrahieren von Desktop Engine (MSDE 2000) SP3a

3.0 Installieren des Service Packs

    3.1 Sichern der SQL Server-Datenbanken

    3.2 Sichern der Datenbanken und des Repository von Analysis Services

    3.3 Sicherstellen von genügendem freiem Speicherplatz für die Systemdatenbanken

    3.4 Beenden von Diensten und Anwendungen vor dem Installieren von SP3a

    3.5 Installieren von Database Components SP3a

    3.6 Installieren von Analysis Services SP3a

    3.7 Installieren von Desktop Engine SP3a

        3.7.1 Voraussetzungen für MSDE 2000 SP3a

        3.7.2 Überlegungen zur Sicherheit für MSDE 2000 SP3a

        3.7.3 Setup-Parameter für MSDE 2000

        3.7.4 Aktualisieren vorhandener MSDE 2000-Instanzen auf SP3a

        3.7.5 Installieren einer neuen Instanz von MSDE 2000 SP3a

        3.7.6 Aktualisieren von MSDE 1.0 auf MSDE 2000 SP3a

        3.7.7 Weitervertreiben von MSDE 2000 SP3a

        3.7.8 Dateispeicherorte für MSDE 2000 SP3a

    3.8 Neustarten der Dienste

    3.9 Neustarten der Anwendungen

    3.10 Installieren von SP3a in einem Failovercluster

    3.11 Installieren von SP3a auf Replikationsservern

    3.12 Anwenden von SP3a auf schreibgeschützte Datenbanken oder Dateigruppen

    3.13 Deinstallieren von SP3a

    3.14 Erneutes Anwenden von SP3a

4.0 Weitere Überlegungen zur Installation

    4.1 Unbeaufsichtigte Installationen

    4.2 Weitervertreiben der Datenzugriffskomponenten von SP3a

5.0 Anmerkungen zur Dokumentation

    5.1 Erweiterungen für die Datenbankkomponenten und Desktop Engine

        5.1.1 Verwenden von chinesischen, japanischen oder koreanischen Zeichen mit Database Components SP3a

        5.1.2 Nicht mehr verfügbare Hashteams

        5.1.3 Hinzugefügte Schalter für Affinitätsmaske

        5.1.4 Gefilterte indizierte Sicht

        5.1.5 Erneutes Erstellen der Volltextkataloge nach Abschluss der Installation

        5.1.6 Syntaxänderungen für "sp_change_users_login"

        5.1.7 Standardmäßig deaktivierter Ad-hoc-Zugriff auf OLE DB-Provider

        5.1.8 Neue Provideroption "SqlServerLike"

        5.1.9 Erweiterte Fehlermeldungen für verteilte Abfragen

        5.1.10 Zurückgeben einer SQL-Anweisung mit der neuen fn_get_sql-Funktion

        5.1.11 Datenbankübergreifende Besitzverkettung

        5.1.12 Erweiterung für Ablaufverfolgungsflag 1204

        5.1.13 Berechtigungsänderung für "sp_changedbowner"

        5.1.14 Änderungen bei der Funktionalität zum Debuggen

        5.1.15 Vorgänge für UDP-Port 1434

    5.2 Erweiterungen bei Analysis Services

        5.2.1 Remotepartitionen

        5.2.2 Aktualisierte weitervertreibbare Setup-Programme für Analysis Services-Clients

        5.2.3 Aktivierte Unterstützung für Datamining-Algorithmenanbieter von Drittanbietern

        5.2.4 Installieren von Analysis Services auf einem Computer mit aktualisierten Clientdateien

        5.2.5 Erhöhter Grenzwert für OLAP-Cubes, auf die ein virtueller Cube verweist

        5.2.6 Neues DESCRIPTION-Schlüsselwort

        5.2.7 Neue Restricted Client-Eigenschaft für PivotTable Service

        5.2.8 Änderung der Safety Options-Eigenschaft

        5.2.9 Standardmäßig deaktiviertes Migrieren des Repository zu Meta Data Services

        5.2.10 Notwendige Berechtigungsänderung bei einem Remotedatenordner

    5.3 Erweiterungen bei der Replikation

        5.3.1 Benutzerdefinierte gespeicherte Prozedur für UPDATE bei der Transaktionsreplikation

        5.3.2 UPDATE-Anweisungen für eindeutige Spalten bei der Transaktionsreplikation

        5.3.3 Wegfallende Einschränkungen bei der gleichzeitigen Snapshotverarbeitung

        5.3.4 Benutzerdefinierte gespeicherte Skripterstellungsprozeduren bei der Transaktionsreplikation

        5.3.5 Beibehaltungsbasierter Metadatencleanup bei der Mergereplikation

        5.3.6 Aspekte zum Sichern und Wiederherstellen bei der Mergereplikation

        5.3.7 Wiederherstellen replizierter Datenbanken von verschiedenen SQL Server-Versionen

        5.3.8 Neuer -MaxCmdsInTran-Parameter für den Protokolllese-Agent

        5.3.9 Einschränkung bei nicht eindeutigen gruppierten Indizes

        5.3.10 Neues –MaxNetworkOptimization-Befehlszeilenargument für den Snapshot-Agent

        5.3.11 Verwendung einer neuen Rolle bei der Mergereplikation

        5.3.12 Neue Anforderungen für Abonnements, die nicht von Systemadministratoren erstellt wurden

        5.3.13 Berechtigungsänderungen für gespeicherte Prozeduren

        5.3.14 Neuer Parameter für "sp_addmergearticle" und "sp_changemergearticle"

        5.3.15 Neue Seite des Publizierungs- und Verteilungskonfigurations-Assistenten

        5.3.16 Änderungen bei der Unterstützung der Synchronisierungsverwaltung von Windows

        5.3.17 Anforderungsänderungen für das Anfügen oder Wiederherstellen einer Replikationsdatenbank

    5.4 Erweiterungen beim SQL Server-Agent

        5.4.1 Protokollierung von Kontoinformationen durch den SQL Server-Agent

        5.4.2 Änderungen an der Konfiguration von Master-/Zielservern

        5.4.3 Neue erweiterte gespeicherte Prozedur für den SQL Server-Agent

        5.4.4 Berechtigungsüberprüfungen beim SQL Server-Agent

        5.4.5 MAPI-Profile für SQL Agent Mail

    5.5 Verbesserungen bei der Konnektivitätskomponente von SQL Server

        5.5.1 Aktualisierungen von Microsoft Data Access Components

        5.5.2 Unterstützung für QLogic Virtual Interface Architecture

    5.6 Verbesserungen bei Meta Data Services

        5.6.1 Exportieren in Unicode mit Meta Data-Browser

        5.6.2 Deaktivierte Skripterstellungsunterstützung

        5.6.3 Neue RepositoryUser-Rolle zum Zugreifen auf Repository-Informationen

    5.7 Verbesserungen bei Data Transformation Services

        5.7.1 Wegfallende Einschränkung von Zeichenfolgenspalten auf 255 Zeichen beim DTS-Assistenten

        5.7.2 Protokollierung des Sicherheitskontextes bei DTS-Paketausführung durch den SQL Server-Agent

        5.7.3 Verbesserungen beim SQL Server-Agent-Proxykonto

        5.7.4 Standardmäßig deaktiviertes Speichern in Meta Data Services

    5.8 XML-Erweiterungen

        5.8.1 Verbesserte Überprüfung von Xpath-Ausdrücken

    5.9 Erweiterungen der API für das virtuelle Sicherungsmedium

        5.9.1 Aufzeichnen mehrerer Datenbanken in einem einzelnen Snapshot

    5.10 Fehlerberichte

    5.11 Erweiterungen bei English Query

    5.12 DB-Library und Embedded SQL für C

1.0 Einführung

Microsoft SQL Server 2000 Service Pack 3a (SP3a) enthält Änderungen an SQL Server 2000 SP3, die sich auf Probleme im Zusammenhang mit dem Slammer-Wurm beziehen:

Da die meisten in SP3a eingeführten Änderungen sich auf das Setup-Programm beziehen, müssen Sie SP3a nicht auf Instanzen von SQL Server 2000 oder MSDE 2000 anwenden, die bereits auf SP3 aktualisiert wurden. Instanzen, die noch nicht auf SP3 aktualisiert wurden, sollten jedoch immer direkt auf SP3a und nicht auf SP3 aktualisiert werden. Wenn Sie über Exemplare der SP3-Downloaddateien verfügen, die Sie für zukünftige Aktualisierungen vorgesehen hatten, sollten Sie diese löschen und stattdessen entweder die SP3a-Downloaddateien oder die SP3a-CD-ROM verwenden. Mit Anwendungen, mit denen MSDE 2000 verteilt und installiert wird, sollte SP3a und nicht SP3 installiert werden. Sie können SP3a zwar auf Instanzen von SQL Server 2000 SP3 oder MSDE 2000 SP3 anwenden, dies hat jedoch nur geringe Auswirkungen.

Diese Version von Service Pack 3a (SP3a) für Microsoft® SQL Server™ 2000 wird in drei Teilen bereitgestellt:

Diese drei Teile von SP3a können wie folgt einzeln angewendet werden:

Anmerkung  Wenn auf einem Computer separate Instanzen von MSDE 2000 und anderen Editionen des SQL Server 2000-Datenbankmoduls installiert sind, müssen Sie Desktop Engine SP3a auf Instanzen von MSDE 2000 anwenden und Database Components SP3a auf andere Instanzen des SQL Server 2000-Datenbankmoduls, wie Personal Edition, Standard Edition oder Enterprise Edition.

Anmerkung  Für die Sprachen Portugiesisch (Brasilien), Schwedisch und Niederländisch wird nur der Service Pack-Teil Desktop Engine SP3a zur Verfügung gestellt, da SQL Server 2000 Desktop Engine (MSDE 2000) die einzige für diese Sprachen produzierte SQL Server 2000-Version ist. Die SQL Server 2000-Komponenten, deren Aktualisierung mit Database Components SP3a oder Analysis Services SP3a erfolgt, stehen in diesen Sprachen nicht zur Verfügung. Benutzer der Sprachversionen Portugiesisch (Brasilien), Schwedisch und Niederländisch, die SP3a auf eine andere SQL Server-Version als auf Desktop Engine anwenden möchten, müssen SP3a-Dateien downloaden, die zur Sprache der zu aktualisierenden Edition passen. Um beispielsweise die englische Sprachversion des SQL Server 2000-Datenbankmoduls zu aktualisieren, müssen Sie die englischen Versionen der SP3a-Dateien downloaden. Informationen zum Downloaden des Service Packs finden Sie in Abschnitt 2.0, Downloaden und Extrahieren von SP3a.

1.1 Übersicht über die Installation von Database Components SP3a

Mit dem Setup-Programm von Database Components SP3a wird automatisch erkannt, welche Edition von SQL Server 2000 bei der zu aktualisierenden SQL Server 2000-Instanz vorliegt. Mit dem Setup-Programm werden nur die für diese Instanz installierten Komponenten aktualisiert. Wenn Sie das Service Pack beispielsweise auf einen Computer mit SQL Server 2000 Standard Edition anwenden, wird nicht versucht, nur in SQL Server 2000 Enterprise Edition enthaltene Komponenten zu aktualisieren.

Sie können Database Components SP3a auf eine einzelne Standardinstanz oder auf eine benannte Instanz von SQL Server anwenden. Wenn Sie mehrere Instanzen von SQL Server 2000 auf SP3a aktualisieren, müssen Sie SP3a auf jede Instanz anwenden. Wenn auf einem Computer mit mindestens einer SQL Server 2000-Instanz eine Instanz auf SP3a aktualisiert wird, werden alle Tools auf SP3a aktualisiert. Es gibt keine separaten Kopien der Tools für die einzelnen Instanzen.

1.2 Übersicht über die Installation von Desktop Engine (MSDE 2000) SP3a

Desktop Engine SP3a kann für folgende Zwecke verwendet werden:

Weitere Informationen zur Lizenzierung für MSDE 2000 finden Sie unter Appropriate Uses of MSDE 2000.

Die Prozeduren zum Anwenden von SQL Server 2000 Service Pack 3a auf eine vorhandene MSDE 2000-Instanz hängen davon ab, wie die Instanz installiert wurde. Die Desktop Engine SP3a-Dateien von Microsoft können nur zum Anwenden von SP3a auf MSDE 2000-Instanzen verwendet werden, die mithilfe des Setup-Dienstprogramms für MSDE 2000 installiert wurden. Mit den meisten Anwendungen wird MSDE 2000 auf eine der beiden folgenden Weisen installiert:

Anweisungen dazu, wie Sie bestimmen können, ob eine MSDE 2000-Instanz mit Desktop Engine SP3a auf SP3a aktualisiert werden kann, finden Sie in Abschnitt 2.1, Downloaden und Extrahieren von Desktop Engine (MSDE 2000) SP3a. Auch wenn Sie Desktop Engine SP3a von der SQL Server 2000 SP3a-CD aus anwenden, sollten Sie die Anweisungen in Abschnitt 2.1 lesen, um zu bestimmen, ob Sie Desktop Engine SP3a anwenden können oder eine Patchdatei von einem Anwendungsanbieter beziehen müssen.

Wenn auf einem Computer mehrere MSDE 2000-Instanzen vorhanden sind, müssen Sie jede Instanz einzeln daraufhin überprüfen, ob Sie Desktop Engine SP3a anwenden können. Sie müssen SP3a außerdem auf jede Instanz separat anwenden.

Lesen Sie die Informationen in den Abschnitten 1 und 2 dieser Infodatei (Readme), und befolgen Sie dann in den folgenden Fällen die Anweisungen in Abschnitt 3:

Die folgenden Abschnitte enthalten Beispiele für die häufigsten Szenarios zum Aktualisieren einer vorhandenen MSDE-Instanz auf SP3a oder zum Installieren einer neuen Instanz von MSDE 2000 SP3a:

1.3 Entfernen von SP3a

Auf welche Weise Sie SQL Server 2000 SP3a entfernen, hängt von den zu entfernenden SQL Server 2000 SP3a-Komponenten ab.

Entfernen von Database Components SP3a oder Desktop Engine SP3a für SQL Server

Beim Installieren von Database Components SP3a oder Desktop Engine SP3a für SQL Server werden aus Wartungsgründen Änderungen an den Systemtabellen vorgenommen. Außerdem werden Benutzer- und Verteilungsdatenbanken aktualisiert, die zu einer Replikationstopologie gehören. Daher kann SP3a nicht auf einfache Weise entfernt werden. Um zu dem Build zurückzukehren, der vor dem Installieren von SP3a ausgeführt wurde, müssen Sie zunächst die Instanz des SQL Server 2000-Datenbankmoduls oder von MSDE 2000 deinstallieren. Anschließend müssen Sie diese Instanz neu installieren. Wenn ein früheres Service Pack von SQL Server 2000 ausgeführt oder QFE-Problembehebungen (Quick Fix Engineering) angewendet wurden, müssen Sie dieses Service Pack und sämtliche QFE-Problembehebungen erneut auf die Instanz anwenden.

Anmerkung  Zum Entfernen von SP3a benötigen Sie Sicherungskopien der Datenbanken master, model und msdb, die unmittelbar vor dem Anwenden von SP3a angefertigt wurden. Weitere Informationen finden Sie in Abschnitt 3.1, Sichern der SQL Server-Datenbanken, und Abschnitt 3.2, Sichern der Datenbanken und des Repository von Analysis Services.

Weitere Informationen finden Sie unter Deinstallieren von Database Components SP3a und Desktop Engine SP3a für SQL Server 2000.

Entfernen der SQL Server Analysis Services-Komponenten von SP3a

Um zu der Version von SQL Server Analysis Services vor SP3a zurückkehren zu können, müssen Sie vor dem Installieren von SP3a den Registrierungsschlüssel HK_LOCAL_MACHINE\Software\Microsoft\OLAP Server und alle Unterschlüssel sichern. Beim Deinstallieren von SP3a müssen Sie diesen Registrierungsschlüssel löschen und die Version vor SP3a von der Sicherung wiederherstellen.

Anmerkung  Während der Installation von SP3a vorgenommene Aktualisierungen auf MDAC 2.7 SP1a können nicht deinstalliert werden.

Weitere Informationen finden Sie unter Deinstallieren von Analysis Services SP3a für SQL Server 2000.

1.4 Identifizieren der aktuellen Version von SQL Server oder Analysis Services

Mithilfe der Techniken in den folgenden Abschnitten können Sie herausfinden, welche Version von SQL Server oder Analysis Services installiert ist.

SQL Server

Um zu identifizieren, welche Version des SQL Server 2000-Datenbankmoduls oder von MSDE 2000 installiert ist, geben Sie an der Befehlszeile im Dienstprogramm osql oder isql oder in SQL Query Analyzer im Abfragefenster SELECT @@VERSION oder SERVERPROPERTY('ProductVersion') ein.

Entsprechend kann die Produktebene einer bestimmten Version des SQL Server 2000-Datenbankmoduls oder von MSDE 2000 durch Ausführen von SELECT SERVERPROPERTY('ProductLevel') ermittelt werden.

In der folgenden Tabelle ist die Beziehung zwischen der SQL Server 2000-Version und -Ebene und der von @@VERSION gemeldeten Versionsnummer sowie der von SERVERPROPERTY('ProductLevel') gemeldeten Produktebene aufgeführt.

Version und Ebene von SQL Server 2000 @@VERSION ProductLevel
SQL Server 2000, ursprüngliche Version 8.00.194 RTM
Database Components SP1 oder Desktop Engine SP1 8.00.384 SP1
Database Components SP2 oder Desktop Engine SP2 8.00.534 SP2
Database Components SP3 oder SP3a oder Desktop Engine SP3 oder SP3a 8.00.760 SP3

Der letzten Zeile der Ausgabe von SELECT @@VERSION können Sie entnehmen, welche Edition des SQL Server 2000-Datenbankmoduls oder von MSDE 2000 ausgeführt wird. Die letzte Zeile sollte einer der folgenden entsprechen: 

Desktop Engine on Windows NT 5.0 (Build 2195: Service Pack 2)
Enterprise Evaluation Edition on Windows NT 5.0 (Build 2195: Service Pack 2)
Developer Edition on Windows NT 5.0 (Build 2195: Service Pack 2)
Personal Edition on Windows NT 5.0 (Build 2195: Service Pack 2)
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 2)
Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 2)

Anmerkung  Am Anfang der Zeile wird die Edition des SQL Server-Datenbankmoduls oder von MSDE 2000 angezeigt. Danach folgen Informationen zum aktuellen Betriebssystem.

Sie können die Edition auch ermitteln, indem Sie an der Befehlszeile im Dienstprogramm osql oder isql oder in SQL Query Analyzer im Abfragefenster SELECT SERVERPROPERTY('Edition') eingeben.

Analysis Services

Um zu identifizieren, welche Version von Analysis Services installiert ist, führen Sie folgende Schritte aus:

  1. Zeigen Sie im Startmenü auf Programme, auf Microsoft SQL Server und dann auf Analysis Services, und klicken Sie auf Analysis-Manager.

  2. Klicken Sie im Strukturbereich des Analysis-Managers mit der rechten Maustaste auf den Ordner Analysis Servers, und wählen Sie Info aus.

  3. Mithilfe der folgenden Tabelle können Sie ermitteln, welche Version von Analysis Services installiert ist.
Analysis Services-Version Buildnummer im Dialogfeld "Info"
SQL Server 2000 Analysis Services, ursprüngliche Version 8.0.194
Analysis Services SP1 8.0.382
Analysis Services SP2 8.0.534
Analysis Services SP3 oder SP3a 8.0.760

Unterscheiden zwischen SP3 und SP3a

Sie können anhand der Versionsnummer der Netzwerkbibliotheks-Datei Ssnetlib.dll bestimmen, ob SP3 oder SP3a installiert ist. Wenn die Versionsnummer dieser Datei 2000.80.760.0 lautet, ist SP3 installiert; wenn sie 2000.80.766.0 lautet, ist SP3a installiert.

Bei einer Instanz, die mit den Standardeinstellungen installiert wurde, befindet sich die Datei Ssnetlib.dll an einem der folgenden Speicherorte:

Um herauszufinden, ob Sie über den Installationsordner für SP3 oder für SP3a verfügen, öffnen Sie die Datei SP3Readme.htm, und lesen Sie die erste Seite. Die Service Pack-Version, SP3a oder SP3, ist oben auf der ersten Seite aufgeführt.

1.5 Zusätzliche Informationen zu SP3a

Eine Liste der Problembehebungen in diesem Service Pack finden Sie im Microsoft Knowledge Base-Artikel 306908. Jede im Artikel 306908 aufgeführte Problembehebung enthält einen Hyperlink zu dem Knowledge Base-Artikel, der das behobene Problem beschreibt. Folgen Sie den Hyperlinks zu den jeweiligen Knowledge Base-Artikeln, um Informationen zu den einzelnen Problembehebungen anzuzeigen.

So finden Sie einen Artikel in der Knowledge Base

  1. Wählen Sie in der Liste Wählen Sie Ihr Produkt die Option SQL Server aus.

  2. Geben Sie im Feld Suchbegriff(e) die Nummer des gesuchten Artikels ein.

  3. Wählen Sie unter Art der Suche die Option Artikelnummer aus.

  4. Klicken Sie auf die Schaltfläche Go. Falls der Artikel nicht gefunden wird, wählen Sie das Optionsfeld Englische Knowledge Base aus, und wiederholen Sie die Suche.

Informationen zu SQL Server 2000 Service Pack 3a, die erst nach Fertigstellung dieser Infodatei (Readme) verfügbar werden, werden im Microsoft Knowledge Base-Artikel 816502 veröffentlicht.

Die in dieser Infodatei erwähnten Knowledge Base-Artikel stehen in der Knowledge Base von Microsoft Support Services zur Verfügung.

Microsoft Data Access Components

Dieses Service Pack enthält Aktualisierungen für Microsoft Data Access Components (MDAC), einschließlich Aktualisierungen für MSXML.

Weitere Informationen finden Sie in Abschnitt 5.5.1, Aktualisierungen von Microsoft Data Access Components.

QFE-Problembehebungen

In SP3a wurden sämtliche veröffentlichten SQL Server 2000 SP2-Sicherheitsbulletins berücksichtigt.

Wenn Sie nach dem 14. Oktober 2002 einen SQL Server 2000-Hotfix erhalten haben, ist dieser Hotfix wahrscheinlich nicht in SP3a enthalten. Den entsprechenden Hotfix für SQL Server 2000 SP3a erhalten Sie bei Ihrem Hauptanbieter für technischen Support.

Aktualisierungen von Servertools für SQL Server CE

Benutzer von Microsoft SQL Server 2000 Windows® CE Edition (SQL Server CE), die Datenbank- und Verlegerserver von SQL Server 2000 auf SP3 oder höher aktualisiert haben oder aktualisieren möchten, sollten auch die Serverreplikationskomponenten auf Servern mit Microsoft Internetinformationsdienste (Internet Information Services, IIS) aktualisieren. Auf der Microsoft-Website ist ein aktualisiertes Installationsprogramm für die Servertools für SQL Server CE verfügbar.

1.6 Verfügbare aktualisierte Onlinedokumentation

Für SP3 und SP3a ist eine aktualisierte Dokumentation verfügbar. Die SQL Server 2000-Onlinedokumentation (aktualisiert – SP3) enthält kleinere Änderungen sowie neue Informationen zu SP3 und SP3a.

Sie können die SQL Server 2000-Onlinedokumentation (aktualisiert – SP3) von der Microsoft-Website downloaden.

1.7 Verfügbare aktualisierte Beispiele zu SQL Server und Analysis Services

Für SP3 und SP3a sind aktualisierte Beispiele zum SQL Server 2000-Datenbankmodul und zu Analysis Services verfügbar. Sie können diese aktualisierten Beispiele von der Microsoft-Website downloaden.

2.0 Downloaden und Extrahieren von SP3a

SP3a wird auf die folgenden Arten verteilt:

Anmerkung  Sowohl die SQL Server 2000 Service Pack 3a-CD-ROM als auch die Datei GER_Sql2kdesksp3.exe enthält alle Dateien, die zum Installieren einer neuen Desktop Engine-Instanz erforderlich sind.

Anmerkung  Die Namen der Downloaddateien für SP3a sind die gleichen wie für SP3.

Wenn Sie über eine SP3a-CD verfügen, können Sie SP3a direkt von der CD installieren.

Andernfalls können Sie die entsprechende Datei downloaden und dann ausführen. Beim Ausführen der Downloaddatei auf dem Computer wird eine Gruppe von Ordnern und Dateien auf dem Datenträger erstellt, die so strukturiert ist wie die Ordner und Dateien auf der SP3a-CD. Nach dem Extrahieren der Datei können Sie SP3a von den Ordnern auf dem Datenträger installieren.

Beachten Sie beim Downloaden und Extrahieren der Installationsdateien von SP3a aus dem Internet die folgenden Richtlinien:

Anmerkung  Bei einigen Dateien in den Service Packs handelt es sich um Systemdateien. Um sie anzuzeigen, müssen Sie den folgenden Vorgang ausführen: Klicken Sie in Windows Explorer im Menü Extras auf Ordneroptionen, klicken Sie auf die Registerkarte Ansicht, und wählen Sie das Optionsfeld Alle Dateien und Ordner anzeigen aus.

So bestimmen Sie die Sprache einer Instanz des SQL Server 2000-Datenbankmoduls oder von MSDE 2000

Service Packs für SQL Server 2000 sind sprachspezifisch. Zum Aktualisieren von SQL Server 2000 müssen Sie das Service Pack downloaden und anwenden, das die gleiche Sprachversion aufweist wie Ihre SQL Server 2000-Software. Beispielsweise müssen Sie zum Aktualisieren einer japanischen MSDE 2000-Instanz die japanische Version von Desktop Engine SP3a downloaden.

So bestimmen Sie die Sprache einer Instanz des SQL Server 2000-Datenbankmoduls oder von MSDE 2000:

Dateien von Database Components SP3a und Analysis Services SP3a

Die Installationsdateien für Database Components SP3a und Analysis Services SP3a enthalten eine aktualisierte Dokumentation zur Installation. Um darauf zuzugreifen, klicken Sie während der Installation von SP3a auf die Hilfeschaltfläche. Mit dieser Dokumentation wird nicht die Version der SQL Server 2000-Onlinedokumentation aktualisiert, die bereits auf dem Computer installiert ist. Informationen zum Erhalten der aktualisierten SQL Server-Onlinedokumentation finden Sie in Abschnitt 1.6, Verfügbare aktualisierte Onlinedokumentation. Wenn Sie nur auf die aktualisierte Dokumentation zur Installation von SQL Server 2000 SP3a zugreifen möchten, ohne die SQL Server-Onlinedokumentation zu aktualisieren, führen Sie die Datei Setupsql.chm aus. Setupsql.chm befindet sich im Unterordner \Books des Verzeichnisses mit den extrahierten Service Pack-Dateien. Dies kann ein Verzeichnis auf der SP3a-CD-ROM, ein lokales Verzeichnis oder eine Netzwerkfreigabe sein.

2.1 Downloaden und Extrahieren von Desktop Engine (MSDE 2000) SP3a

Zum Patchen einer vorhandenen MSDE 2000-Instanz müssen die Benutzer wissen, wie die Instanz installiert wurde. Sie können dies anhand der Informationen im Eintrag ProductCode eines Registrierungsschlüssels bestimmen. Folgen Sie dazu den Anweisungen im Microsoft Knowledge Base-Artikel 311762.

Downloaden von MSDE 2000 SP3a

Wenn die MSDE 2000-Instanz mit dem Setup-Dienstprogramm für MSDE installiert wurde (d. h., wenn der ursprüngliche Paketname aus dem Bereich SqlRun01.msi bis SqlRun16.msi stammt), können Sie die MSDE 2000-Instanz mit einer Downloaddatei für SQL Server 2000 SP3a aktualisieren:

Extrahieren der MSDE 2000 SP3a-Dateien

Nach dem Downloaden von SQL2KDeskSP3.exe oder LLL_SQL2KDeskSP3.exe müssen Sie die MSDE 2000 SP3a-Dateien wie folgt extrahieren:

3.0 Installieren des Service Packs

Installieren Sie SP3a mithilfe der Installationsanweisungen in den folgenden Abschnitten. Welche Schritte erforderlich sind, hängt davon ab, auf welche der folgenden Komponenten oder Konfigurationen von SQL Server 2000 das Service Pack angewendet wird:

Der erste Satz in jedem der folgenden Abschnitte besagt, für welche Komponente(n) der Abschnitt gilt.

Vor dem Beginn der Installation

Wenn Ihre Instanz des SQL Server 2000-Datenbankmoduls oder von MSDE 2000 von einer Anwendung verwendet wird, ermitteln Sie zunächst vom Anbieter der Anwendung, ob Sie anwendungsspezifische Aspekte beim Aktualisieren des Datenbankmoduls oder von MSDE 2000 beachten müssen.

Die Installation von SP3a schlägt fehl, wenn für eine der folgenden Sicherheitsrichtlinien die Option Installation nicht zulassen (bzw. Installation nicht erlauben) festgelegt wurde:

Wenn Sie die Einstellung Installation nicht zulassen (bzw. Installation nicht erlauben) verwenden, müssen Sie sie vor dem Installieren von SP3a in Ohne Warnung annehmen ändern. Bei Bedarf können Sie nach Abschluss der Installation die frühere Einstellung der Richtlinie wiederherstellen.

Anmerkung  Installation nicht zulassen (bzw. Installation nicht erlauben) ist nicht die Standardeinstellung für diese Sicherheitsrichtlinien.

Beim Installieren von SQL Server 2000 SP3a auf einem Computer unter Windows XP wird MDAC 2.7 nicht auf MDAC 2.7 Service Pack 1a (SP1a) aktualisiert. Wenn für Ihr System Problembehebungen aus MDAC 2.7 SP1a erforderlich sind, müssen Sie Windows XP Service Pack 1 vor SQL Server 2000 SP3a anwenden. Von Windows XP SP1 werden alle Problembehebungen aus MDAC 2.7 SP1a angewendet.

Beim Installieren dieses Service Packs unter einer Vorabversion von Microsoft Windows Server 2003, Build 3683 oder früher, erhalten Sie die folgende Fehlermeldung:

Die zu installierende Software hat den Windows-Logo-Test nicht bestanden,
der die Kompatibilität mit dieser Windows-Version überprüft. 
Diese Software wird nicht installiert. Wenden Sie sich an den Systemadministrator.

Sie können diese Meldung ignorieren. Klicken Sie auf OK, um mit dem Setup-Programm fortzufahren.

Anmerkung  Diese Meldung verhindert eine unbeaufsichtigte Installation.

Wenn Sie dieses Service Pack auf einem Computer unter Windows NT 4.0 Service Pack 6a installieren, müssen Sie den im Microsoft Knowledge Base-Artikel 258437 beschriebenen Hotfix anwenden.

Bevor Sie SP3a unter der französischen Version von Windows NT 4.0 installieren, müssen Sie die Anweisungen im Knowledge Base-Artikel 259484 befolgen. Sie können auf den Artikel in der Knowledge Base von Microsoft Support Services zugreifen. Anweisungen zum Durchsuchen der Knowledge Base finden Sie in Abschnitt 1.5, Zusätzliche Informationen zu SP3a.

Vor dem Beginn der Installation von Database Components SP3a

Wenn Sie Database Components SP3a auf eine SQL Server-Instanz auf einem Computer anwenden, auf dem auch Analysis Services installiert ist, kann das Setup-Programm beim Ausführen des Skripts Sp3_serv_uni.sql fehlschlagen. Starten Sie in diesem Fall den Computer neu, und führen Sie das Setup-Programm erneut aus.

Mit dem Setup-Programm für SP3a werden Benutzerdatenbanken aktualisiert, die zu einer Replikationstopologie gehören. Stellen Sie vor dem Installieren von SP3a sicher, dass die Datenbanken und Dateigruppen für die Replikation schreibbar sind und dass das Benutzerkonto, mit dem das Setup-Programm ausgeführt wird, Zugriffsberechtigungen für die Datenbanken besitzt. Weitere Informationen zum Anwenden von SP3a auf Datenbanken, die an Replikationstopologien beteiligt sind, finden Sie in Abschnitt 3.11, Installieren von SP3a auf Replikationsservern.

Wenn vom Setup-Programm für SP3a nicht schreibbare Benutzerdatenbanken oder Dateigruppen erkannt werden, werden folgende Schritte ausgeführt:

Sie können diese Warnung ignorieren, außer wenn im Installationsprotokoll aufgelistete Datenbanken zu einer Replikationstopologie gehören. Wenn im Installationsprotokoll aufgelistete nicht schreibbare Datenbanken zu einer Replikationstopologie gehören, müssen Sie sie schreibbar machen und das Setup-Programm für SP3a auf die betreffende SQL Server 2000-Instanz erneut anwenden.

Anmerkung  Diese Meldung hat keine Auswirkungen auf unbeaufsichtigte Installationen. Weitere Informationen zu unbeaufsichtigten Installationen finden Sie in Abschnitt 4.1, Unbeaufsichtigte Installationen.

Weitere Informationen zum Aufheben des Schreibschutzes für eine Datenbank finden Sie in Abschnitt 3.12, Anwenden von SP3a auf schreibgeschützte Datenbanken oder Dateigruppen. Weitere Informationen zum erneuten Anwenden von SP3a finden Sie in Abschnitt 3.14, Erneutes Anwenden von SP3a.

Da das Setup-Programm beim Vorliegen nicht schreibbarer Datenbanken nicht mehr fehlschlägt, müssen Sie vor dem Aktualisieren auf SP3a den Protokollversand nicht mehr entfernen. Wenn für die Datenbank jedoch Protokolle an eine Datenbank versendet werden, die ein Replikationsverleger ist, müssen Sie folgende Schritte ausführen:

  1. Schalten Sie die Datenbank vor dem Anwenden von SP3a offline.

  2. Wenden Sie SP3a auf die Instanz an.

  3. Schalten Sie die Datenbank wieder online.

  4. Melden Sie sich bei Query Analyzer an, und führen Sie folgendes Skript aus: 
    USE master
GO
EXEC sp_vpupgrade_replication
GO

Wenn Sie vor dem Anwenden von SP3a nicht alle nicht schreibbaren Datenbanken offline geschaltet haben, für die Protokolle an Publikationsdatenbanken versendet werden, wird folgende Fehlermeldung angezeigt:

"Fehler beim Ausführen eines Skripts: sp_vpupgrade_replication (1)"

Befolgen Sie bei Erhalt dieser Fehlermeldung das obige Verfahren.

Anmerkung  Während der Installation wird nicht zwischen schreibgeschützten Datenbanken und solchen unterschieden, die offline oder fehlerverdächtig sind. Wenn eine Datenbank oder Dateigruppe der Replikation sich während der Installation in einem dieser Zustände befindet und zu einer Replikationstopologie gehört, müssen Sie das Service Pack nach dem Schreibbarmachen der Datenbank erneut anwenden.

Anmerkung  Da das Setup-Programm beim Vorliegen nicht schreibbarer Datenbanken nicht mehr fehlschlägt, müssen Sie vor dem Aktualisieren auf SP3a den Protokollversand nicht mehr entfernen.

Vorbereiten einer verteilten Installation mit Systems Management Server

Sie können SQL Server 2000 Service Pack 3a nicht remote installieren. Sie können jedoch Microsoft Systems Management Server verwenden, um SP3a automatisch auf mehreren Computern unter Windows NT Server 4.0 zu installieren. Dazu müssen Sie eine Paketdefinitionsdatei (Smssql2ksp2.pdf) verwenden, die das Erstellen eines SQL Server-Pakets in Systems Management Server automatisiert. Das SQL Server-Paket kann dann auf Computern mit Systems Management Server verteilt und installiert werden. Die Datei Sms2kdef.bat ist eine Batchdatei zum Starten einer unbeaufsichtigten Installation mithilfe von Systems Management Server. Bei dieser Art der Installation werden notwendige relevante Systeminformationen automatisch vom Setup-Programm erkannt, und es sind keine Benutzereingaben erforderlich.

Anmerkung  Sie können Systems Management Server nicht zum Installieren von Desktop Engine SP3a verwenden.

3.1 Sichern der SQL Server-Datenbanken

Die folgenden Informationen gelten für alle Komponenteninstallationen außer für Datenbank-Clientkomponenten.

Sichern Sie vor dem Installieren von Database Components SP3a oder Desktop Engine SP3a die Datenbanken master, msdb und model. Beim Installieren von SP3a werden die Datenbanken master, msdb und model verändert, so dass sie mit SQL Server-Versionen vor SQL Server 2000 SP3 nicht mehr kompatibel sind. Sie benötigen die Sicherungen, wenn Sie wieder SQL Server 2000 ohne SP3 oder SP3a installieren möchten.

Vorsichtshalber sollten Sie auch die Benutzerdatenbanken sichern, obwohl mit SP3a nur Benutzerdatenbanken aktualisiert werden, die zu Replikationstopologien gehören.

3.2 Sichern der Datenbanken und des Repository von Analysis Services

Die folgenden Informationen gelten nur für Analysis Services.

Sichern Sie vor dem Installieren von Analysis Services SP3a die Analysis Services-Datenbanken, indem Sie eine Kopie des Ordners Microsoft Analysis Services\Data erstellen, der standardmäßig unter dem Ordner C:\Programme installiert ist. Wenn Sie das Analysis Services-Repository nicht zu SQL Server migriert haben, erstellen Sie eine Sicherungskopie der Datei Msmdrep.mdb, die sich im Ordner Microsoft Analysis Services\Bin befindet. Sie sollten auch die Registrierungseinträge für den Analysis-Server sichern, indem Sie Regedit.exe ausführen und im Menü Registrierung das Element Registrierungsdatei exportieren verwenden, um den Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server zur Sicherung in eine Datei zu exportieren. Wenn Sie das Analysis Services-Repository zu SQL Server migriert haben, sichern Sie vor dem Installieren von SP3a die Datenbank, die das Repository enthält. Weitere Informationen finden Sie unter Deinstallieren von Analysis Services SP3a für SQL Server 2000.

3.3 Sicherstellen von genügendem freiem Speicherplatz für die Systemdatenbanken

Die folgenden Informationen gelten für alle Komponenteninstallationen außer für Datenbank-Clientkomponenten und Analysis Services.

Wenn die Option autogrow für die Datenbanken master und msdb nicht aktiviert wurde, müssen die Datenbanken jeweils über mindestens 500 KB freien Speicherplatz verfügen. Um zu überprüfen, ob dieser Platz zur Verfügung steht, führen Sie die gespeicherte Systemprozedur sp_spaceused für die Datenbank master oder msdb aus. Wenn der nicht reservierte Speicherplatz in einer der Datenbanken 500 KB unterschreitet, vergrößern Sie die Datenbank. Weitere Informationen finden Sie unter "Erweitern einer Datenbank" in der SQL Server-Onlinedokumentation.

Wenn die Option autogrow für die Datenbanken master und msdb aktiviert wurde und genügend Speicherplatz auf den Laufwerken verfügbar ist, können Sie diesen Schritt auslassen.

Um sicherzustellen, dass die Option autogrow in SQL Server 2000 aktiviert wurde, öffnen Sie SQL Server Enterprise Manager, klicken Sie mit der rechten Maustaste auf das Symbol für die Datenbank, und klicken Sie dann auf Eigenschaften. Stellen Sie sicher, dass das Kontrollkästchen Datei automatisch vergrößern aktiviert ist.

Um zu überprüfen, ob diese Option in MSDE 2000 aktiviert wurde, geben Sie die folgenden SQL-Anweisungen im Befehlszeilen-Dienstprogramm osql ein:

Überprüfen Sie, ob in der Ausgabe dieser Anweisungen die Spalte für die Vergrößerung einen anderen Wert als 0 hat.

3.4 Beenden von Diensten und Anwendungen vor dem Installieren von SP3a

Die folgenden Informationen gelten für alle Komponenten.

Sie können SP3a anwenden, ohne Dienste herunterzufahren. Wenn Sie Dienste nicht herunterfahren, werden Sie nach Beendigung des Setup-Programms zum Neustart des Computers aufgefordert. Ohne einen Neustart des Computers werden die folgenden Dienste nicht gestartet.

Wenn Sie diese Dienste und Anwendungen beenden, bevor Sie SP3a anwenden, können Sie SP3a ohne einen Neustart des Computers anwenden.

In einer Clusterumgebung können Sie die Dienste nicht beenden. Weitere Informationen finden Sie in Abschnitt 3.10, Installieren von SP3a in einem Failovercluster.

3.5 Installieren von Database Components SP3a

Die folgenden Informationen gelten für alle Komponenteninstallationen außer für Desktop Engine und Analysis Services.

Führen Sie das Skript Setup.bat von einem der folgenden Speicherorte aus:

Anmerkung  Um Datenbankkomponenten von einer Netzwerkfreigabe zu installieren, müssen Sie zuerst eine der folgenden Aktionen ausführen:

Sie werden in einem Dialogfeld zum Angeben von Informationen aufgefordert, wie der Information, ob die SQL Server-Authentifizierung oder die Windows-Authentifizierung verwendet werden soll. Wenn Sie die SQL Server-Authentifizierung wählen, müssen Sie für das Setup-Programm das Kennwort für den Benutzernamen sa bereitstellen. Wenn Sie die Windows-Authentifizierung wählen, müssen Sie beim Ausführen des Setup-Programms mit einem Windows-Anmeldekonto bei Windows angemeldet sein. Dieses Anmeldekonto muss Mitglied der festen Serverrolle sysadmin für die zu aktualisierende Instanz von SQL Server 2000 sein.

Vom Setup-Programm werden anschließend die folgenden Aufgaben ausgeführt:

Dialogfeld für den Authentifizierungsmodus

Das Dialogfeld für den Authentifizierungsmodus enthält nicht standardmäßig die aktuellen Einstellungen für die Installation. Die Standardwerte im Dialogfeld sind wie folgt:

Das Setup-Programm platziert ein Protokoll der ausgeführten Aktionen in die Datei Sqlsp.log. Diese Protokolldatei ist im Windows-Verzeichnis des Computers gespeichert, auf dem das Setup-Programm ausgeführt wird. Wenn Sie mehrere Instanzen aktualisieren, wird nur die letzte Aktualisierung in diesem Protokoll aufgezeichnet.

Dialogfeld "Prüfliste für die Rückwärtskompatibilität"

Im Dialogfeld Prüfliste für die Rückwärtskompatibilität sind Rückwärtskompatibilitätsprobleme aufgeführt, die beim Anwenden des Service Packs auftreten können. Welche Rückwärtskompatibilitätsprobleme in der Prüfliste aufgeführt werden, hängt von der Konfiguration der zu aktualisierenden SQL Server 2000-Instanz ab.

In diesem Dialogfeld können die folgenden Rückwärtskompatibilitätsprobleme behandelt werden:

3.6 Installieren von Analysis Services SP3a

Die folgenden Informationen gelten nur für Analysis Services.

Führen Sie zum Installieren von Analysis Services SP3a das Programm Setup.exe von einem der folgenden Speicherorte aus:

Das Setup-Programm führt anschließend die folgenden Aufgaben aus:

Weitere Aspekte der Installation für Analysis Services

Nach dem Installieren von Analysis Services SP3a müssen Sie auch alle Computer auf SP3 oder SP3a aktualisieren, die für die Remoteverwaltung verwendet werden. Andernfalls erhalten Sie beim Versuch, über den Analysis-Manager eine Remoteverbindung herzustellen, die folgende Fehlermeldung:

Es kann keine Verbindung zur Registrierung auf dem Server (server_name) 
hergestellt werden, oder Sie sind nicht Mitglied der Gruppe
'OLAP Administrators' auf diesem Server.

In Meta Data Services wurde die neue dedizierte Rolle RepositoryUser hinzugefügt, mit das Zugreifen auf und Aktualisieren von Repository-Informationen in der msdb-Datenbank möglich ist. Die RepositoryUser-Rolle verfügt über die Berechtigungen zum Erstellen, Lesen, Aktualisieren, Löschen und Ausführen für das msdb-Repository. Die public-Rolle wurde durch diese neue Rolle ersetzt und hat keine Berechtigungen mehr für dieses Repository. Wenn die folgenden Bedingungen erfüllt sind, muss die Gruppe OLAP Administrators zur RepositoryUser-Rolle hinzugefügt werden, damit Mitglieder dieser Gruppe nach dem Anwenden des Service Packs auf das Repository zugreifen können:

Weitere Informationen zur RepositoryUser-Rolle finden Sie in Abschnitt 5.6.3, Neue RepositoryUser-Rolle zum Zugreifen auf Repository-Informationen.

Wenn sich der Datenordner von Analysis Services nicht auf dem Computer befindet, auf dem der Analysis-Server ausgeführt wird, müssen Sie die Berechtigungen für den Ordner nach dem Installieren von SP3a ändern. Weitere Informationen finden Sie in Abschnitt 5.2.10, Notwendige Berechtigungsänderung bei einem Remotedatenordner.

3.7 Installieren von Desktop Engine SP3a

Die folgenden Informationen gelten nur für Desktop Engine (MSDE 2000).

Desktop Engine SP3a enthält alle Dateien, die zum Installieren oder Aktualisieren von Instanzen von SQL Server 2000 Desktop Engine (MSDE 2000) erforderlich sind. Sie können alle Installationsaktionen für MSDE 2000 mit den Dateien aus Desktop Engine SP3a ausführen, falls Sie über eine Lizenz zum Installieren oder Aktualisieren einer Instanz von MSDE 2000 verfügen. Weitere Informationen zur Lizenzierung für MSDE 2000 finden Sie unter Appropriate Uses of MSDE 2000.

Möglicherweise können Sie Desktop Engine SP3a nicht auf MSDE 2000-Instanzen anwenden, die mit dem Setup-Dienstprogramm einer Anwendung installiert wurden. Beziehen Sie in diesem Fall eine Patchdatei zum Aktualisieren dieser MSDE 2000-Instanzen vom Anwendungsanbieter. Anweisungen, mit denen Sie bestimmen können, ob eine MSDE 2000-Instanz in diese Kategorie gehört, finden Sie in Abschnitt 2.1, Downloaden und Extrahieren von Desktop Engine (MSDE 2000) SP3a.

Die folgenden Abschnitte enthalten wichtige Hintergrundinformationen zum Setup-Programm für MSDE 2000 SP3a:

In den folgenden Abschnitten werden die häufigsten Szenarios zum Aktualisieren einer vorhandenen MSDE-Instanz auf SP3a oder zum Installieren einer neuen Instanz von MSDE 2000 SP3a beschrieben:

Wenn Sie weitere Informationen zum Installieren von MSDE 2000 SP3a benötigen, sollten Sie vor allem die SQL Server 2000-Onlinedokumentation (aktualisiert - SP3) heranziehen. Einige Änderungen von SP3 und SP3a an MSDE 2000 sind in der SQL Server 2000-Onlinedokumentation (aktualisiert - SP3) nicht vollständig wiedergegeben; diese Funktionen werden in der vorliegenden Infodatei (Readme) beschrieben. Weitere Informationen zum Installieren der SQL Server 2000-Onlinedokumentation (aktualisiert - SP3) finden Sie in Abschnitt 1.6, Verfügbare aktualisierte Onlinedokumentation.

3.7.1 Voraussetzungen für MSDE 2000 SP3a

Die folgenden Informationen gelten nur für Desktop Engine (MSDE 2000).

Die folgenden Anforderungen gelten für SP3a-Installationen für SQL Server 2000 Desktop Engine (MSDE 2000).

Beim Aktualisieren von MSDE 2000 müssen Sie Desktop Engine SP3a auf jede MSDE 2000-Instanz separat anwenden.

Anmerkung  Microsoft unterstützt keine Konfigurationen, bei denen sich mehr als 16 Instanzen des Datenbankmoduls auf einem einzelnen Computer befinden. Dazu gehören Instanzen von SQL Server 6.5, SQL Server 7.0, SQL Server 2000, MSDE 1.0 und MSDE 2000.

Starten Sie die Installation von MSDE 2000 immer durch Ausführen von Setup.exe. Rufen Sie nicht eine der MSI-Dateien für MSDE 2000 direkt auf, etwa durch Doppelklicken auf die Datei. Sie müssen zum Installieren oder Aktualisieren einer MSDE-Instanz immer das Setup-Programm von der Befehlszeile ausführen und Parameter angeben. Weitere Informationen zu den erforderlichen Parametern finden Sie in den Abschnitten 3.7.2 bis 3.7.6.

Es können Probleme auftreten, wenn Sie mit einer Verbindung von Terminaldienste eine vorhandene MSDE-Instanz auf SP3a aktualisieren oder eine neue Instanz von MSDE 2000 SP3a installieren. Falls Probleme auftreten, starten Sie das Setup-Programm vom lokalen Computer neu.

Sie müssen den Instanznamen der MSDE-Instanz kennen, die Sie mit dem Setup-Programm für MSDE 2000 SP3a installieren oder aktualisieren. Beim Installieren oder Aktualisieren einer benannten MSDE-Instanz müssen Sie den Instanznamen mit dem INSTANCENAME-Parameter angeben. Wenn Sie INSTANCENAME nicht angeben, wird das Setup-Programm für die Standardinstanz von MSDE auf dem Computer ausgeführt. Bei Versionen des Setup-Programms für MSDE 2000 vor SP3 müssen die Benutzer die MSI-Installationspaketdatei angeben, die zum Installieren oder Aktualisieren einer MSDE 2000-Instanz verwenden werden soll. Beim Setup-Programm für SP3 und höher werden die MSI-Dateien vom Setup-Programm verwaltet, und Sie müssen die MSI-Datei weder bei einer Aktualisierung noch bei einer Neuinstallation angeben.

Sie können das Setup-Programm für MSDE 2000 SP3a von der Festplatte, von einer Netzwerkfreigabe oder von einer CD-ROM ausführen. Beim Aktualisieren einer MSDE 2000-Instanz auf SP3a können Sie das Setup-Programm nur dann von einer Netzwerkfreigabe oder von einer CD-ROM ausführen, wenn die ursprünglichen Dateien, mit denen die MSDE 2000-Instanz installiert wurde, noch an dem Speicherort vorhanden sind, an dem sie sich während der ursprünglichen Installation befanden. Wenn die ursprüngliche Installation von einer CD-ROM erfolgte, wird die ursprüngliche CD-ROM während der Aktualisierung mit dem Setup-Programm von MSDE 2000 SP3a angefordert. Wenn sich die ursprünglichen Dateien nicht mehr am ursprünglichen Speicherort befinden oder wenn die ursprüngliche CD-ROM nicht verfügbar ist, müssen Sie die Dateien für MSDE 2000 SP3a auf die Festplatte kopieren und das Setup-Programm von dort ausführen.

Wenn Sie Ihre eigene CD-ROM zum Installieren von SP3a erstellen, muss die Datenträgerbezeichnung der CD-ROM SQL2KSP3 lauten. Wenn Sie als unabhängiger Softwareanbieter (Independent Software Vendor, ISV) eine CD-ROM zum Verteilen von Desktop Engine als Komponente Ihrer Anwendung erstellen, muss die Datenträgerbezeichnung der CD-ROM mit dem Wert der VolumeLabel-Eigenschaft in der Medientabelle des Windows Installer-Pakets (*.msi) übereinstimmen.

Sie können die Aktualisierung für Desktop Engine nur dann von einer CD-ROM installieren, wenn Sie Windows Installer, Version 2.0.2600.0 oder höher, verwenden. SP3a enthält auch die notwendigen Dateien zum Aktualisieren von Windows Installer.

So aktualisieren Sie Windows Installer:

  1. Navigieren Sie mit Windows Explorer zum Ordner \MSDE\MSI auf der SQL Server 2000 SP3a-CD oder in den aus GER_SQL2KDeskSP3.exe extrahierten Ordnern.

  2. Führen Sie InstMsi20.exe aus.

  3. Starten Sie den Computer neu, wenn Sie dazu aufgefordert werden.

3.7.2 Überlegungen zur Sicherheit für MSDE 2000 SP3a

Die folgenden Informationen gelten nur für Desktop Engine (MSDE 2000).

Das Setup-Programm für MSDE 2000 wurde in SP3a so verändert, dass mit den Standardeinstellungen eine sicherere Konfiguration erzielt wird.

Bei Desktop Engine SP3a ist das Standardverhalten des DISABLENETWORKPROTOCOLS-Installationparameters verändert, mit dem die Konfiguration der Netzwerkverbindungs-Unterstützung für eine MSDE 2000-Instanz angegeben wird. Wenn keine Verbindung von einer Anwendung auf einem anderen Computer zu der MSDE 2000-Instanz hergestellt werden soll, ist keine Netzwerkunterstützung für die Instanz notwendig, und die nicht verwendete Ressource sollte aus Sicherheitsgründen deaktiviert werden. Die Netzwerkunterstützung wird beim Installieren neuer MSDE 2000-Instanzen mit SP3a standardmäßig deaktiviert. Wenn Sie den Standard übernehmen, können Sie die Instanz später neu konfigurieren, um die Unterstützung zu aktivieren. Weitere Informationen zum Deaktivieren und Wiederherstellen des Netzwerkzugriffs finden Sie im Microsoft Knowledge Base-Artikel 814130.

Standardmäßig wird mit dem Setup-Programm für MSDE 2000 SP3a nur dann eine neue MSDE 2000-Instanz installiert, wenn Sie mit dem SAPWD-Parameter ein sicheres Kennwort für den Benutzer sa angeben. Standardmäßig wird mit dem Setup-Programm für MSDE 2000 SP3a eine vorhandene MSDE 2000-Instanz nur dann aktualisiert, wenn Sie dem Benutzernamen sa ein sicheres Kennwort zugewiesen haben. Sie sollten dem Benutzernamen sa auch dann ein sicheres Kennwort zuweisen, wenn Sie eine vorhandene Instanz aktualisieren, außer wenn ein leeres Kennwort für sa für die Anwendung notwendig ist, von der die MSDE-Instanz verwendet wird. Wenn die MSDE 2000-Instanz im Windows-Authentifizierungsmodus ausgeführt wird, wird das Kennwort für den Benutzer sa bei einem Wechsel in den gemischten Modus sofort aktiv. Ein leeres, einfaches oder bekanntes Kennwort für sa kann für nicht berechtigte Zugriffe verwendet werden. Wenn Sie vor dem Aktualisieren der MSDE 2000-Instanz auf SP3a ein sicheres Kennwort für sa zuweisen möchten, lesen Sie den Microsoft Knowledge Base-Artikel 322336.

Verwenden Sie zur Erhöhung der Sicherheit möglichst immer die Windows-Authentifizierung für Ihre Installation von MSDE 2000. Ziehen Sie in den folgenden Fällen einen Wechsel vom gemischten Modus zum Windows-Authentifizierungsmodus in Betracht:

Weitere Informationen zum Wechsel vom gemischten Modus in den Windows-Authentifizierungmodus für eine MSDE 2000-Instanz finden Sie im Microsoft Knowledge Base-Artikel 322336.

3.7.3 Setup-Parameter für MSDE 2000

Die folgenden Informationen gelten nur für Desktop Engine (MSDE 2000).

MSDE 2000 wurde zum Verteilen mit Anwendungen und Installieren mit dem Setup-Programm der Anwendung entworfen. Für MSDE 2000 gibt es kein interaktives Setup-Programm. Die Setup-Verfahren für MSDE 2000 sind so entworfen, dass sie vom Setup-Dienstprogramm einer Anwendung aufgerufen werden können. Jegliche erforderliche Anwenderinteraktion wird dabei vom Setup-Programm der Anwendung verarbeitet. Es gibt zwei Installationsverfahren für MSDE 2000:

Die Benutzer können mit dem Setup-Dienstprogramm von MSDE 2000 für die Befehlszeile vorhandene MSDE-Instanzen aktualisieren oder neue installieren. Um das Verhalten des Dienstprogramms zu steuern, können sie Parameter angeben. Es gibt zwei Möglichkeiten zum Angeben der Setup-Parameter:

Die meisten Parameter, die von der Setup-Programmversion für MSDE 2000 SP3a unterstützt werden, sind unter "Customizing Desktop Engine Setup.exe" in der SQL Server 2000-Onlinedokumentation (aktualisiert – SP3) dokumentiert. Weitere Informationen zum Installieren der SQL Server 2000-Onlinedokumentation finden Sie in Abschnitt 1.6, Verfügbare aktualisierte Onlinedokumentation.

Sie müssen die Werte für Setup-Parameter für MSDE in doppelte Anführungszeichen einschließen, wenn der angegebene Wert Sonderzeichen enthält, wie z. B. Leerzeichen. Andernfalls sind die Anführungszeichen optional.

Die folgenden Setup-Parameter von MSDE 2000 SP3a sind nicht in der SQL Server 2000-Onlinedokumentation (aktualisiert - SP3) dokumentiert, oder ihr Verhalten weicht von der Beschreibung in der Onlinedokumentation ab.

Parametername Beschreibung
ALLOWXDBCHAINING=1 Ermöglicht datenbankübergreifende Besitzverkettung. Weitere Informationen finden Sie in Abschnitt 5.1.11, Datenbankübergreifende Besitzverkettung.
SAPWD=sa_password Gibt beim Installieren einer neuen MSDE 2000-Instanz das Kennwort an, das dem Benutzernamen sa zugewiesen werden soll. Beim Aktualisieren einer vorhandenen MSDE 2000-Instanz wird SAPWD ignoriert; in diesem Fall sollten Sie vor dem Aktualisieren sicherstellen, dass der Benutzername sa über ein sicheres Kennwort verfügt. Sie sollten immer ein sicheres Kennwort für sa festlegen, auch bei Verwendung des Windows-Authentifizierungsmodus. Die SAPWD-Eigenschaft wird nur beim Installieren mit Zusammenführungsmodulen in die Installationsprotokolldatei geschrieben, nicht jedoch beim Ausführen von Setup.exe.
/upgradesp

{

SQLRUN

|

[<MSIPath>]SqlRunXX.msi

}

 Gibt an, dass mit dem Setup-Programm eine vorhandene MSDE 2000-Instanz auf SP3a aktualisiert werden soll. Bei SP3 und höher ersetzt dieser Schalter den Schalter /p, der von früheren Setup-Versionen unterstützt wird. Verwenden Sie bei SP3 oder höher nicht den Schalter /p. Beim Aktualisieren auf SP3a müssen Sie nicht mehr die MSI-Datei angeben, mit der die vorhandene MSDE 2000-Instanz installiert wurde.

Die meisten Benutzer geben einfach SQLRUN an. In diesem Fall wird die zu verwendende MSI-Datei vom Setup-Dienstprogramm für MSDE 2000 SP3a bestimmt. Wenn Sie SQLRUN, aber keinen Wert für INSTANCENAME angeben, wird die Standardinstanz von MSDE 2000 aktualisiert. Wenn Sie SQLRUN und einen Wert für den INSTANCENAME-Parameter angeben, wird die somit angegebene Instanz aktualisiert.

Wenn Sie den Namen einer MSI-Installationspaketdatei für MSDE 2000 angeben, wird die Instanz auf dem Computer aktualisiert, die ursprünglich mit einem gleichnamigen Zusammenführungsmodul installiert wurde. Wenn Sie beispielsweise SqlRun01.msi angeben, wird die ursprünglich mit SqlRun01.msi installierte MSDE 2000-Instanz aktualisiert. MSIPath ist der Pfad zum Ordner mit der MSI-Datei. Der Standardwert für MSIPath lautet Setup\.

Beispiele zum Angeben von /upgradesp finden Sie in Abschnitt 3.7.4, Aktualisieren vorhandener MSDE 2000-Instanzen auf SP3a.
UPGRADEUSER=AnAdminLogin Gibt den Benutzernamen an, der bei der Aktualisierung von MSDE 1.0 oder MSDE 2000 mithilfe der SQL Server-Authentifizierung verwendet werden soll. Der Benutzername muss Mitglied der festen Serverrolle sysadmin sein. Der Parameter wird nur dann verwendet, wenn Sie beim Aktualisieren einer MSDE-Instanz SECURITYMODE=SQL angeben.
UPGRADEPWD=

AdminPassword

 Gibt das Kennwort für den Benutzernamen an, der bei der Aktualisierung von Desktop Engine mithilfe der SQL Server-Authentifizierung in UPGRADEUSER angegeben wird.

Mit Desktop Engine SP3 wurde ein neuer DISABLENETWORKPROTOCOLS-Parameter eingeführt. Das Verhalten von DISABLENETWORKPROTOCOLS wurde in Desktop Engine SP3a zur Erhöhung der standardmäßigen Sicherheit verändert.

In der folgenden Tabelle wird das Verhalten von DISABLENETWORKPROTOCOLS in SP3a beschrieben.

Wert von DISABLENETWORKPROTOCOLS Aktualisieren einer vorhandenen Instanz Installieren einer neuen Instanz
1 In der Konfiguration der Instanz werden alle Server-Netzwerkbibliotheken deaktiviert. In der Konfiguration der Instanz werden alle Server-Netzwerkbibliotheken deaktiviert.
0 Die vorhandene Konfiguration der Server-Netzwerkbibliotheken wird beibehalten. In der Konfiguration der Instanz werden die standardmäßigen Server-Netzwerkbibliotheken und Adressen aktiviert.
Parameter nicht angegeben oder mit einem anderen Wert als 0 oder 1 Die vorhandene Konfiguration der Server-Netzwerkbibliotheken wird beibehalten. In der Konfiguration der Instanz werden alle Server-Netzwerkbibliotheken deaktiviert.

Das Verhalten von DISABLENETWORKPROTOCOLS in SP3 unterscheidet sich in zwei Aspekten von dem in SP3a:

Weitere Informationen zu standardmäßigen Konfigurationen der Netzwerkbibliotheken finden Sie unter "Steuern von Netzwerkbibliotheken und Kommunikationsadressen" in der SQL Server 2000-Onlinedokumentation.

Entwickler, die die Zusammenführungsmodule (MSI-Dateien) von MSDE 2000 in eine Installation mit Windows Installer integrieren, können die obigen Setup-Parameter als Eigenschaften in der MSI-Datei angeben. Von Desktop Engine (MSDE 2000) SP3a werden Zusammenführungsmodule zur Unterstützung vorhandener Anwendungen bereitgestellt, bei denen Zusammenführungsmodule verwendet werden können. Die Setup-Dienstprogramme für neue Anwendungen sollten so geschrieben werden, dass sie das Setup-Dienstprogramm von MSDE 2000 aufrufen, statt die Zusammenführungsmodule von MSDE 2000 direkt zu konsumieren.

Parametername Eigenschaft im Zusammenführungsmodul
ALLOWXDBCHAINING SqlAllowXDBChaining
DISABLENETWORKPROTOCOLS SqlDisableNetworkProtocols
SAPWD SqlSaPwd
UPGRADEUSER SqlUpgradeUser
UPGRADEPWD SqlUpgradePwd

Informationen zu den Eigenschaften in Zusammenführungsmodulen, die anderen Setup-Parametern entsprechen, finden Sie unter "Using the SQL Server Desktop Engine Merge Modules" in der SQL Server 2000-Onlinedokumentation.

Anfordern eines Setup-Protokolls

Wenn beim Ausführen des Setup-Programms Probleme auftreten und Sie zum Debuggen ein ausführliches Protokoll benötigen, geben Sie /L*v <LogFileName> an. Dabei ist <LogFileName> der Name einer Protokolldatei, in der alle Setup-Aktionen aufgezeichnet werden sollen. Wenn Sie keinen Pfad als Teil des Namens angeben, wird die Protokolldatei im aktuellen Ordner erstellt. Beim Ausführen des Setup-Programms von der SQL Server 2000 SP3a-CD müssen Sie den vollständigen Pfad zu einem Ordner auf der Festplatte angeben. Im folgenden Beispiel wird die Protokolldatei MSDELog.log im Stammverzeichnis des Laufwerks C: erstellt:

setup /upgradesp sqlrun DISABLENETWORKPROTOCOLS=1 /L*v C:/MSDELog.log

3.7.4 Aktualisieren vorhandener MSDE 2000-Instanzen auf SP3a

Die folgenden Informationen gelten nur für Desktop Engine (MSDE 2000).

Mit den Beispielen in diesem Abschnitt wird eine vorhandene MSDE 2000-Instanz auf SP3a aktualisiert, und die Netzwerkkonnektivität für die Instanz wird deaktiviert. Geben Sie den DISABLENETWORKPROTOCOLS-Parameter nicht an, wenn die Instanz Verbindungen von Anwendungen auf anderen Computern akzeptieren soll.

Für die Beispiele in diesem Abschnitt wird angenommen, dass der Benutzername sa ein sicheres Kennwort aufweist. Weitere Informationen zum Kennwort für den Benutzernamen sa finden Sie in Abschnitt 3.7.2, Überlegungen zur Sicherheit für MSDE 2000 SP3a.

So aktualisieren Sie SQL Server 2000 Desktop Engine

  1. Öffnen Sie ein Eingabeaufforderungsfenster.

  2. Navigieren Sie an der Eingabeaufforderung wie folgt mit dem Befehl cd zu dem Ordner, der das Setup-Dienstprogramm für MSDE 2000 SP3a enthält:

    cd c:\MSDESP3aFolder\MSDE

    Dabei steht c:\MSDESP3aFolder für den Pfad zu dem Ordner mit den extrahierten MSDE 2000 SP3a-Dateien oder für den Desktop Engine SP3a-Ordner auf der SQL Server 2000 SP3a-CD.

  3. Führen Sie einen der folgenden Befehle aus:

Wichtig  Wenn Sie während der Installation eine INI-Datei verwenden, vermeiden Sie es, darin Anmeldeinformationen zu speichern.

Anmerkung  Wenn Sie Desktop Engine auf einem Computer unter Windows 98 oder Windows Millennium Edition aktualisieren, muss die zu aktualisierende Desktop Engine-Instanz vor Beginn der Installation beendet werden.

3.7.5 Installieren einer neuen Instanz von MSDE 2000 SP3a

Die folgenden Informationen gelten nur für Desktop Engine (MSDE 2000).

Mit den Beispielen in diesem Abschnitt wird eine neue Instanz von MSDE 2000 SP3a installiert, in deren Konfiguration die Netzwerkkonnektivität deaktiviert ist. Wenn die Instanz Verbindungen von Anwendungen auf anderen Computern akzeptieren soll, geben Sie zusätzlich DISABLENETWORKPROTOCOLS=0 an.

Bei den Instanzen, die mit diesen Beispielen installiert werden, werden für alle Konfigurationselemente, wie die Sortierung und die Dateispeicherorte, Standardwerte verwendet. Die Konfigurationen können mit Setup-Parametern gesteuert werden, wie COLLATION, DATADIR und TARGETDIR. Weitere Informationen zu den Konfigurationsparametern, die Sie für das Setup-Programm angeben können, finden Sie unter "Customizing Desktop Engine Setup.exe" in der SQL Server 2000-Onlinedokumentation (aktualisiert – SP3). Weitere Informationen zum Installieren der SQL Server 2000-Onlinedokumentation (aktualisiert - SP3) finden Sie in Abschnitt 1.6, Verfügbare aktualisierte Onlinedokumentation.

So installieren Sie eine neue Desktop Engine-Instanz

  1. Öffnen Sie ein Eingabeaufforderungsfenster.

  2. Navigieren Sie an der Eingabeaufforderung wie folgt mit dem Befehl cd zu dem Ordner, der das Setup-Dienstprogramm für MSDE 2000 SP3a enthält:

    cd c:\MSDESP3aFolder\MSDE

    Dabei steht c:\MSDESP3aFolder für den Pfad zu dem Ordner mit den extrahierten MSDE 2000 SP3a-Dateien oder für den Desktop Engine SP3a-Ordner auf der SQL Server 2000 SP3a-CD.

  3. Führen Sie einen der folgenden Befehle aus:

Wichtig  Wenn Sie während der Installation eine INI-Datei verwenden, vermeiden Sie es, darin Anmeldeinformationen zu speichern.

Wichtig  Geben Sie immer ein sicheres Kennwort für den Benutzernamen sa an, auch wenn die Instanz zur Verwendung des Windows-Authentifizierungsmodus konfiguriert ist.

3.7.6 Aktualisieren von MSDE 1.0 auf MSDE 2000 SP3a

Die folgenden Informationen gelten nur für Desktop Engine (MSDE 2000).

Mit den Beispielen in diesem Abschnitt wird eine vorhandene Instanz von MSDE 1.0 auf MSDE 2000 SP3a aktualisiert. Außerdem wird die Netzwerkkonnektivität für die Instanz deaktiviert. Wenn die Instanz Verbindungen von Anwendungen auf anderen Computern akzeptieren soll, geben Sie nicht den DISABLENETWORKPROTOCOLS-Parameter an.

Das Verhalten von MSDE 1.0 entspricht dem einer Standardinstanz von MSDE 2000. MSDE 1.0 wird immer auf eine Standardinstanz von MSDE 2000 aktualisiert.

So aktualisieren Sie von Desktop Engine, Version 1.0

  1. Öffnen Sie ein Eingabeaufforderungsfenster.

  2. Navigieren Sie an der Eingabeaufforderung wie folgt mit dem Befehl cd zu dem Ordner, der das Setup-Dienstprogramm für MSDE 2000 SP3a enthält:

    cd c:\MSDESP3aFolder\MSDE

    Dabei steht c:\MSDESP3aFolder für den Pfad zu dem Ordner mit den extrahierten MSDE 2000 SP3a-Dateien oder für den Desktop Engine SP3a-Ordner auf der SQL Server 2000 SP3a-CD.

  3. Führen Sie einen der folgenden Befehle aus:

Anmerkung  Wenn Sie BLANKSAPWD=1 verwenden, müssen Sie SECURITYMODE=SQL, UPGRADEUSER und UPGRADEPWD nicht angeben.

Vorsicht  Von der Verwendung eines leeren Kennwortes wird dringend abgeraten.

Wichtig  Wenn Sie während der Installation eine INI-Datei verwenden, vermeiden Sie es, darin Anmeldeinformationen zu speichern.

3.7.7 Weitervertreiben von MSDE 2000 SP3a

Die folgenden Informationen gelten nur für Desktop Engine (MSDE 2000).

Desktop Engine SP3a enthält alle notwendigen Dateien zum Weitervertreiben von MSDE 2000 mit Anwendungen. Der Anwendungsanbieter benötigt dafür eine Lizenz zum Verteilen von MSDE 2000. Sie können die Desktop Engine SP3a-Dateien verteilen wie in der SQL Server 2000-Onlinedokumentation (aktualisiert - SP3) dokumentiert. Berücksichtigen Sie dabei die SP3a-spezifischen Änderungen, die in den folgenden Abschnitten dokumentiert werden:

Weitere Informationen zum Installieren der SQL Server 2000-Onlinedokumentation (aktualisiert - SP3) finden Sie in Abschnitt 1.6, Verfügbare aktualisierte Onlinedokumentation.

Verteilen von Patches für Desktop Engine SP3a

Anwendungen mit Windows Installer-basierten Setup-Dienstprogrammen können zum Installieren einer MSDE 2000-Instanz die Zusammenführungsmodule für MSDE 2000 konsumieren. Von Desktop Engine (MSDE 2000) SP3a werden Zusammenführungsmodule zur Unterstützung vorhandener Anwendungen bereitgestellt, bei denen Zusammenführungsmodule verwendet werden können. Die Setup-Dienstprogramme für neue Anwendungen sollten so geschrieben werden, dass sie das Setup-Dienstprogramm von MSDE 2000 aufrufen, statt die Zusammenführungsmodule von MSDE 2000 direkt zu konsumieren.

Anbieter, die MSDE 2000-Instanzen mithilfe der MSDE 2000-Zusammenführungsmodule installieren, müssen ihren Kunden auch alle nachfolgenden MSDE 2000-Patches ausliefern. MSDE 2000-Instanzen, die mit Zusammenführungsmodulen installiert werden, werden mit einer Produktcode-GUID markiert, die von Windows Installer mit der Anwendung verknüpft wird. Diese MSDE 2000-Instanzen können nur mit Patchdateien gepatcht werden, die ebenfalls die Produktcode-GUID der Anwendung enthalten. Nur Patchdateien vom Anwendungsanbieter enthalten die richtigen Produktcodes. Die von Microsoft bereitgestellten Service Packs für Desktop Engine (MSDE 2000) können auf diese Instanzen nicht angewendet werden. Der Anwendungsanbieter muss Patchdateien mithilfe der Desktop Engine SP3a-Dateien erstellen und sie dann an alle MSDE-Kunden verteilen, die die Problembehebungen für SP3a benötigen.

Weitere Informationen zum Erstellen von Patchpaketen finden Sie in der Dokumentation im Windows Installer Software Development Kit (SDK), das Sie von der Microsoft Platform SDK-Website downloaden können.

Wenn das Setup-Dienstprogramm einer Anwendung zum Installieren einer MSDE 2000-Instanz das Setup-Dienstprogramm von MSDE 2000 aufruft, wird die MSDE 2000-Instanz mit der Produktcode-GUID von MSDE 2000 markiert. Kunden können diese Instanzen mit den standardmäßigen Service Pack-Dateien für Microsoft MSDE 2000 patchen. Der Anwendungsanbieter kann eine der folgenden Alternativen zum Verteilen von MSDE 2000 SP3a wählen:

Anwendungsanbieter, die ihre Kunden zum direkten Anwenden von SP3a anweisen möchten, sollte Anweisungen schreiben, die an die Bedürfnisse der Kunden angepasst sind.

Beispiele für derartige Anweisungen für Service Packs für MSDE 2000, die von Microsoft-Anwendungsteams für Kunden erstellt wurden, finden Sie auf der Webseite zu Microsoft-Anwendungen mit MSDE.

3.7.8 Dateispeicherorte für MSDE 2000 SP3a

Die folgenden Informationen gelten nur für Desktop Engine (MSDE 2000).

Alle Installationsdateien und -ordner für Desktop Engine SP3a befinden sich im Ordner \MSDE an einem der folgenden Speicherorte:

Der Ordner \MSDE enthält die Datei SP3readme.htm, die Datei readme.txt, die Datei license.txt und die ausführbaren Dateien für das Setup-Dienstprogramm. Er enthält außerdem folgende Unterordner:

Informationen zum Verwenden der Zusammenführungsmodule für Desktop Engine finden Sie unter "Using SQL Server Desktop Engine Merge Modules" in der SQL Server-Onlinedokumentation.

Wenn das Setup-Programm Ihrer Anwendung das Setup-Programm von MSDE 2000 aufruft, erstellen Sie einen Ordner mit der folgenden Struktur und den folgenden Dateien (dabei steht MSDEInstallFolder für einen Ordnernamen):

MSDEInstallFolder

Kopieren Sie folgende Dateien aus dem Ordner \MSDE von Desktop Engine SP3a in diesen Ordner: Setup.exe, Setup.ini, Setup.rll und Sqlresld.dll.

MSDEInstallFolder\Msi

Kopieren Sie alle Dateien aus dem Ordner \MSDE\Msi von Desktop Engine SP3a in diesen Ordner.

MSDEInstallFolder\Setup

Kopieren Sie alle Dateien aus dem Ordner \MSDE\Setup von Desktop Engine SP3a in diesen Ordner.

Sie können nun mit Setup.exe Instanzen von MSDE 2000 SP3a installieren oder auf diese aktualisieren.

Wenn Windows Installer nicht auf dem Computer installiert ist oder wenn eine frühere Version installiert ist als die, die mit dem Setup-Programm für MSDE 2000 SP3a getestet wurde, wird Windows Installer mit den Dateien im Ordner MSDEInstallFolder\Msi aktualisiert.

3.8 Neustarten der Dienste

Die folgenden Informationen gelten für alle Komponenten.

Nach dem Abschließen des Setup-Programms werden Sie möglicherweise zum Neustarten des Systems aufgefordert. Nach dem Neustart des Systems (oder nachdem das Setup-Programm abgeschlossen wurde, ohne einen Neustart zu erfordern) müssen Sie mithilfe der Anwendung Dienste in der Systemsteuerung sicherstellen, dass alle Dienste wieder ausgeführt werden, die Sie vor dem Anwenden des Service Packs geschlossen haben. Dazu gehören die Dienste MS DTC, Microsoft Search, MSSQLServer, MSSQLServerOLAPService und SQLServerAgent oder ihre instanzspezifischen Äquivalente.

Aus Sicherheitsgründen sollten Sie zu diesem Zeitpunkt auch die aktualisierten Datenbanken master und msdb sichern.

3.9 Neustarten der Anwendungen

Die folgenden Informationen gelten für alle Komponenten.

Starten Sie die Anwendungen neu, die Sie vor dem Ausführen der Service Pack-Installation geschlossen haben.

3.10 Installieren von SP3a in einem Failovercluster

Die folgenden Informationen gelten nur für SQL Server 2000-Komponenten, die zu einem Failovercluster gehören.

So installieren Sie das Service Pack in einem Failovercluster

  1. Wenn Ressourcen hinzugefügt wurden, die von SQL Server-Ressourcen abhängig sind, müssen vor dem Installieren von SP3a diese Abhängigkeiten entfernt oder die Ressourcen offline geschaltet werden. Wenn dies nicht geschieht, kann die Installation von SP3a dazu führen, dass für diese abhängigen Ressourcen ein Failover ausgeführt wird.

  2. Führen Sie das Service Pack von dem Knoten aus, der Besitzer der Gruppe ist, in der der zu aktualisierende virtuelle Server enthalten ist. Dadurch werden die Service Pack-Dateien auf allen Knoten des Failoverclusters installiert.

  3. Geben Sie im Installationsdialogfeld den Namen des zu aktualisierenden virtuellen Servers ein.

  4. Lassen Sie alle Clusterknoten während des Setup-Vorgangs online. Damit wird sichergestellt, dass die Aktualisierung auf jeden Knoten im Cluster angewendet wird.

  5. Wenn Sie in Schritt 1 Abhängigkeiten beseitigt oder Ressourcen offline geschaltet haben, stellen Sie die Abhängigkeiten wieder her, oder schalten Sie die Ressourcen wieder online.

Anmerkung  Das Setup-Programm erfordert möglicherweise einen Neustart der Knoten im Failovercluster. Bei diesem Neustart werden die Dateien, die während der Ausführung des Setup-Programms in Verwendung waren, durch die aktualisierten Dateien ersetzt.

Wenn Sie eine standardmäßige (nicht in einem Cluster gruppierte) SQL Server-Instanz auf einen virtuellen Server aktualisieren, müssen Sie sie zunächst auf eine virtuelle Instanz aktualisieren und dann SP3a anwenden. Weitere Informationen zum Aktualisieren finden Sie unter "Aktualisieren von einer Standardinstanz auf eine gruppierte Standardinstanz von SQL Server 2000 (Setup-Programm)" in der SQL Server-Onlinedokumentation.

Weitere Informationen zum Installieren von SP3a in einem Failovercluster finden Sie im Knowledge Base-Artikel 811168.

Führen Sie folgende Schritte aus, um einen Knoten im Failovercluster erneut zu erstellen:

  1. Erstellen Sie den Knoten im Failovercluster erneut. Weitere Informationen zum erneuten Erstellen eines Knotens finden Sie unter "Wiederherstellen bei einem Failovercluster-Fehler in Szenario 1" in der SQL Server-Onlinedokumentation.

  2. Führen Sie SQL Server 2000 Setup (ursprüngliche Version) aus, um den Knoten wieder zum Failovercluster hinzuzufügen.

  3. Führen Sie das Setup-Programm von SP3a auf dem gerade hinzugefügten Knoten aus. Damit werden nur die Binärdateien auf dem neuen Knoten auf SP3a aktualisiert.

Anmerkung  Wenn Sie das Setup-Programm auf dem Knoten ausführen, auf dem der virtuelle Server ausgeführt wird, müssen Sie SP3a auf alle Knoten erneut anwenden. Außerdem müssen Sie die Datenbank-Aktualisierungsskripts erneut ausführen.

Beim Installieren von Analysis Services SP3a in einem Cluster muss jede Instanz einzeln aktualisiert werden.

So installieren Sie SP3a in einem Analysis Services-Cluster

  1. Installieren Sie SP3a auf einem Failoverknoten.

  2. Führen Sie ein Failover zum gerade aktualisierten Knoten aus.

  3. Wiederholen Sie die Schritte 1 und 2, bis alle Instanzen im Cluster aktualisiert sind.

3.11 Installieren von SP3a auf Replikationsservern

Die folgenden Informationen gelten nur für SQL Server 2000-Komponenten, die zu einer Replikationstopologie gehören:

Anmerkung  In vielen Fällen, vor allem bei der Mergereplikation, befinden sich der Verteiler und der Verleger auf demselben Server und werden zugleich aktualisiert.

Installieren von SP3a auf einem Server, der als Verleger und als Abonnent verwendet wird

Bei Replikationstopologien, die auf einer Mergereplikation oder einer Transaktionsreplikation mit Abonnenten mit Aktualisierungsberechtigung basieren und mindestens einen Server enthalten, der sowohl als Abonnent als auch als Verleger (oder Verteiler) verwendet wird, müssen Sie möglicherweise das System in einen inaktiven Status versetzen (d. h. alle Aktualisierungsvorgänge beenden) und alle Server gleichzeitig aktualisieren.

Beispiel 1: Topologie, die gleichzeitige Aktualisierungen erfordert

Die Server in der folgenden Tabelle veröffentlichen und abonnieren Publikationen, die auf dem Abonnenten aktualisiert werden können. Wie bereits erwähnt, müssen Sie bei Topologien, die Aktualisierungen auf dem Abonnenten zulassen, die Aktualisierungsreihenfolge Verteiler, Verleger, Abonnent beachten. Aufgrund dieser Reihenfolge müssen Sie Server A zuerst für die Mergepublikation und Server B zuerst für die Transaktionspublikation mit aktualisierenden Abonnenten aktualisieren. In diesem Fall müssen Sie das System in einen inaktiven Status versetzen und die Server gleichzeitig aktualisieren.

Server A Server B
Verleger/Verteiler für Mergereplikation Abonnent für Mergereplikation
Abonnent für Transaktionsreplikation mit Aktualisierung Verleger/Verteiler für Transaktionsreplikation mit Aktualisierung

Beispiel 2: Topologie, die sequenzielle Aktualisierungen ermöglicht

In diesem Beispiel können Sie Server A zuerst aktualisieren, weil bei der Nur-Lesen-Transaktionspublikation ein Abonnent vor dem Verleger/Verteiler aktualisiert werden kann.

Server A Server B
Verleger/Verteiler für Mergereplikation Abonnent für Mergereplikation
Abonnent für Nur-Lesen-Transaktionsreplikation Verleger/Verteiler für Nur-Lesen-Transaktionsreplikation

Weitere Installationsaspekte bei der Replikation

Wichtig  Vor dem Aktualisieren auf SP3a müssen Sie sicherstellen, dass der SQL Server-Dienst mit einem Windows-Konto ausgeführt wird, das Mitglied der festen Serverrolle sysadmin ist. Dies ist erforderlich, weil Verteilungsdatenbanken der Replikation im Kontext des SQL Server-Dienstkontos aktualisiert werden. Nach dem Aktualisieren auf SP3a müssen Sie das Windows-Konto aus der sysadmin-Rolle entfernen.

Wenn Sie eine Mergereplikation verwenden und der Verteiler sich auf einem anderen Computer oder einer anderen Datenbankinstanz befindet (Remoteverteiler), müssen Sie nach dem Anwenden von SP3a einen neuen Snapshot generieren.

Mit SP3a wird eine Änderung an den Anforderung für das Anfügen oder Wiederherstellen von Replikationsdatenbanken eingeführt. Weitere Informationen finden Sie in Abschnitt 5.3.17, Anforderungsänderungen für das Anfügen oder Wiederherstellen einer Replikationsdatenbank.

Mit dem Setup-Programm für SP3a werden Benutzerdatenbanken aktualisiert, die zu einer Replikationstopologie gehören. Wenn Datenbanken, die zu einer Replikationstopologie gehören, nicht schreibbar sind, müssen Sie sie schreibbar machen und das Setup-Programm für SP3a erneut anwenden, um SP3a auf diese Datenbanken anzuwenden. Weitere Informationen zum Aufheben des Schreibschutzes für eine Datenbank finden Sie in Abschnitt 3.12, Anwenden von SP3a auf schreibgeschützte Datenbanken oder Dateigruppen. Informationen zum erneuten Anwenden von SP3a finden Sie in Abschnitt 3.14, Erneutes Anwenden von SP3a.

Ein vorhandenes Sicherungsschema, das die Replikation einbezieht, ermöglicht nach der Aktualisierung auf SP3a im Fehlerfall das Wiederherstellen einer Datenbank in einen bekannten Zustand. Nach dem Anwenden von SP3a empfiehlt sich eine Protokollsicherung oder vollständige Datenbanksicherung für alle Benutzerdatenbanken, die zu einer Replikationstopologie gehören. Falls eine Replikationsdatenbank ausfällt, müssen Sie so SP3a nach dem Wiederherstellen der Datenbank nicht erneut anwenden.

3.12 Anwenden von SP3a auf schreibgeschützte Datenbanken oder Dateigruppen

Die folgenden Informationen gelten nur für SQL Server 2000-Komponenten, die zu einer Replikationstopologie gehören.

Wenn nicht schreibbare Datenbanken oder Dateigruppen vorhanden sind, zeigt das Setup-Programm die folgende Meldung an:

Das Setup-Programm hat mindestens eine schreibgeschützte Datenbank und Dateigruppe entdeckt.

Im Allgemeinen können Sie diese Warnung ignorieren, und das Setup-Programm wird fortgesetzt. Wenn jedoch im Installationsprotokoll aufgelistete nicht schreibbare Datenbanken Elemente einer Replikationstopologie sind, müssen Sie sie schreibbar machen und SP3a Setup auf die betreffende SQL Server 2000-Instanz erneut anwenden.

Anmerkung  Diese Meldung hat keine Auswirkungen auf unbeaufsichtigte Installationen. Weitere Informationen zu unbeaufsichtigten Installationen finden Sie in Abschnitt 4.1, Unbeaufsichtigte Installationen.

Anmerkung  Während der Installation unterscheidet das Setup-Programm nicht zwischen nicht schreibbaren Datenbanken und solchen, die offline oder fehlerverdächtig sind. Wenn sich eine Datenbank oder Dateigruppe während der Installation in einem dieser Zustände befindet, müssen Sie das Service Pack erneut anwenden. Weitere Informationen zum Onlineschalten einer Datenbank finden Sie unter "Anfügen und Trennen einer Datenbank" in der SQL Server-Onlinedokumentation. Weitere Informationen zur Diagnose fehlerverdächtiger Datenbanken finden Sie unter "Problembehandlung bei Servern und Datenbanken" in der SQL Server-Onlinedokumentation.

So wenden Sie SP3a auf eine schreibgeschützte Datenbank an

  1. Heben Sie den Schreibschutz für die schreibgeschützte Datenbank wie folgt mit der ALTER DATABASE-Anweisung auf: 
    ALTER DATABASE database SET READ_WRITE
  2. Wiederholen Sie Schritt 1 für alle schreibgeschützten Datenbanken.

  3. Wenden Sie das Service Pack an (bzw. wenden Sie es erneut an).

  4. Legen Sie den Schreibschutz für die Datenbank nötigenfalls wie folgt mit ALTER DATABASE wieder fest: 
    ALTER DATABASE database SET READ_ONLY

So wenden Sie SP3a auf eine schreibgeschützte Dateigruppe an

  1. Heben Sie den Schreibschutz für die schreibgeschützte Dateigruppe wie folgt mit ALTER DATABASE auf: 
    ALTER DATABASE Database 
MODIFY FILEGROUP filegroup_name READWRITE
  2. Wiederholen Sie Schritt 1 für alle schreibgeschützten Dateigruppen.

  3. Wenden Sie das Service Pack an (bzw. wenden Sie es erneut an).

  4. Legen Sie den Schreibschutz für die Dateigruppe nötigenfalls wie folgt mit ALTER DATABASE wieder fest: 
    ALTER DATABASE Database 
MODIFY FILEGROUP filegroup_name READONLY

Weitere Informationen zu ALTER DATABASE finden Sie im Referenzthema "ALTER DATABASE" in der SQL Server-Onlinedokumentation. Weitere Informationen zum erneuten Anwenden von SP3a finden Sie in Abschnitt 3.14, Erneutes Anwenden von SP3a.

3.13 Deinstallieren von SP3a

Auf welche Weise Sie SQL Server 2000 SP3a entfernen, hängt von den zu entfernenden SQL Server 2000 SP3a-Komponenten ab.

Anmerkung  MDAC-Aktualisierungen werden nicht deinstalliert. Weitere Informationen finden Sie in Abschnitt 5.5.1, Aktualisierungen von Microsoft Data Access Components.

Deinstallieren von Database Components SP3a und Desktop Engine SP3a für SQL Server 2000

Um zu der Version der SQL Server 2000-Komponenten vor SP3a zurückzukehren, benötigen Sie eine vor dem Installieren von SP3a erstellte Sicherungskopie der Datenbanken master, msdb und model. Weitere Informationen finden Sie in Abschnitt 3.1, Sichern der SQL Server-Datenbanken.

Anmerkung  Wenn Datenbanken an der Replikation beteiligt sind, müssen Sie die Publizierung deaktivieren. So deaktivieren Sie die Publizierung:

  1. Erweitern Sie in SQL Server Enterprise Manager eine SQL Server-Gruppe, erweitern Sie einen Server, klicken Sie mit der rechten Maustaste auf den Ordner Replikation, und klicken Sie dann auf Publizierung, Abonnenten und Verteilung konfigurieren.

  2. Klicken Sie auf die Registerkarte Publikationsdatenbanken.

  3. Deaktivieren Sie das Kontrollkästchen für jede an der Replikation beteiligte Datenbank. Dies ermöglicht das Trennen der Datenbanken.

So kehren Sie zu der Version von SQL Server vor SP3a zurück

  1. Trennen Sie alle Benutzerdatenbanken. Weitere Informationen finden Sie unter "Anfügen und Trennen einer Datenbank (Enterprise Manager)" in der SQL Server-Onlinedokumentation.

  2. Deinstallieren Sie SQL Server. Doppelklicken Sie in der Systemsteuerung auf Software, und wählen Sie dann die zu deinstallierende SQL Server-Instanz aus.

  3. Installieren Sie SQL Server 2000 von der CD-ROM oder dem Speicherort, von der bzw. dem Sie SQL Server ursprünglich installiert haben.

  4. Wenden Sie alle Service Packs und QFE-Problembehebungen an, die vor SP3a installiert wurden.

  5. Stellen Sie die Datenbanken master, msdb und model aus der letzten vor dem Anwenden von SP3a erstellten Sicherung wieder her. Damit werden alle Benutzerdatenbanken automatisch angefügt, die zum Erstellungszeitpunkt der Sicherung angefügt waren. Es wird davon ausgegangen, dass sich der Speicherort der Datendateien nicht geändert hat.

  6. Fügen Sie alle Benutzerdatenbanken an, die nach dem letzten Sichern der master-Datenbank erstellt wurden.

  7. Konfigurieren Sie nötigenfalls die Replikation.

    Warnung  Wenn Sie zu der SQL Server-Version vor SP3a zurückkehren, gehen alle Änderungen verloren, die seit dem Anwenden von SP3a an den Datenbanken master, msdb und model vorgenommen wurden.

Deinstallieren von Analysis Services SP3a für SQL Server 2000

Um zu der Version von Analysis Services vor SP3a zurückkehren zu können, müssen Sie vor dem Installieren von SP3a den Registrierungsschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server sichern. Weitere Informationen finden Sie in Abschnitt 3.2, Sichern der Datenbanken und des Repository von Analysis Services.

Anmerkung  Wenn Sie diesen Registrierungsschlüssel nicht gesichert haben, müssen Sie das im Microsoft Knowledge Base-Artikel 330244 beschriebene Verfahren ausführen.

So kehren Sie zu der SQL Server-Version vor SP3a zurück

  1. Deinstallieren Sie SQL Server 2000 Analysis Services. Doppelklicken Sie in der Systemsteuerung auf Software, klicken Sie auf SQL Server 2000 Analysis Services, und klicken Sie auf Entfernen.

  2. Installieren Sie SQL Server 2000 Analysis Services erneut von der CD-ROM oder dem Speicherort, von der bzw. dem Sie Analysis Services ursprünglich installiert haben.

  3. Wenden Sie alle Service Packs und QFE-Problembehebungen an, die vor SP3a installiert wurden.

  4. Entfernen Sie den Registrierungsschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server.

  5. Installieren Sie den Registrierungsschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server von der Sicherung vor SP3a neu.

3.14 Erneutes Anwenden von SP3a

Die folgenden Informationen gelten für alle Komponenten.

In den folgenden Fällen müssen Sie SP3a erneut anwenden:

Zum erneuten Anwenden von SP3a führen Sie die Schritte in Abschnitt 3.0, Installieren des Service Packs, aus.

4.0 Weitere Überlegungen zur Installation

In diesem Abschnitt werden weitere Überlegungen zur Installation des Service Packs beschrieben, die nur für Sonderfälle gelten.

4.1 Unbeaufsichtigte Installationen

Database Components SP3a kann im unbeaufsichtigten Modus auf eine SQL Server-Instanz angewendet werden. Die Database Components SP3a-CD-ROM enthält ISS-Dateien, mit denen unbeaufsichtigte SP3a-Installationen und andere Arten von Installationen ausgeführt werden können. Die folgenden Dateien befinden sich im Stammverzeichnis auf der CD-ROM:

Weitere Informationen zum Ausführen von unbeaufsichtigten SQL Server 2000-Installationen finden Sie unter "Durchführen einer unbeaufsichtigten Installation" in der SQL Server-Onlinedokumentation.

Überlegungen zur unbeaufsichtigten Installation

Die folgenden Überlegungen beziehen sich auf unbeaufsichtigte Installationen:

Option für die unbeaufsichtigte Installation Beschreibung
UpgradeMSSearch Diese Option wird für die erforderliche Neuerstellung von Volltextkatalogen benötigt. Wenn die Volltextsuche aktiviert ist, müssen Sie für diese Option den Wert 1 festlegen. Weitere Informationen finden Sie in Abschnitt 5.1.5, Erneutes Erstellen der Volltextkataloge nach Abschluss der Installation.
MSXTSXUpgraded Diese Option wird für die Aktualisierung der Konfiguration von Master-/Zielservern benötigt. Wenn Sie SP3a auf einen Master- oder Zielserver anwenden, müssen Sie für diese Option den Wert 1 festlegen. Weitere Informationen finden Sie in Abschnitt 5.4.2, Änderungen an der Konfiguration von Master-/Zielservern.
EnableCrossDBChaining (Optional) Diese Option wird verwendet, um die datenbankübergreifende Besitzverkettung zu aktivieren. Um die datenbankübergreifende Besitzverkettung zu aktivieren, legen Sie für diese Option den Wert 1 fest. Weitere Informationen finden Sie in Abschnitt 5.1.11, Datenbankübergreifende Besitzverkettung.

4.2 Weitervertreiben der Datenzugriffskomponenten von SP3a

Database Components SP3a enthält die selbstextrahierende Datei Sqlredis.exe. Wenn Sqlredis.exe ausgeführt wird, werden die folgenden Vorgänge ausgeführt:

  1. Ausführen der Datei Mdac_typ.exe von Microsoft Data Access Components (MDAC) 2.7 Service Pack 1a. Dieser Vorgang installiert die Kernkomponenten von MDAC 2.7 SP1a (wenn nicht dieselbe oder eine neuere Version erkannt wird) und die Versionen der Clientkonnektivitätskomponenten von SQL Server und Desktop Engine, die in SP3a enthalten sind. Weitere Informationen finden Sie in Abschnitt 5.5.1, Aktualisierungen von Microsoft Data Access Components.

  2. Installieren der ODBC-Treiber und der Konnektivitätskomponenten von Microsoft Jet.

Sie können die Datei Sqlredis.exe weitervertreiben, wenn Sie die Bedingungen in der mit SP3a ausgelieferten Datei Redist.txt einhalten und sie auch den Empfängern auferlegen.

5.0 Anmerkungen zur Dokumentation

In diesem Abschnitt werden Probleme beschrieben, die auftreten können, sowie neue Funktionen, die beim Ausführen von SP3a zur Verfügung stehen. Diese Probleme beziehen sich auf das Ausführen des Service Packs zum Aktualisieren von SQL Server 2000, SQL Server 2000 SP1 oder SQL Server 2000 SP2. Dieser Abschnitt soll keine Beschreibung aller in SP3a bereitgestellten Problembehebungen darstellen. Eine vollständige Liste dieser Problembehebungen finden Sie im Microsoft Knowledge Base-Artikel 306908.

Die Aussagen zu Analysis Services und Meta Data Services in diesem Abschnitt gelten nicht für reine Desktop Engine-Installationen.

Informationen zu SQL Server 2000 Service Pack 3a, die erst nach Fertigstellung dieser Infodatei (Readme) verfügbar werden, werden im Microsoft Knowledge Base-Artikel 816502 veröffentlicht.

Microsoft Knowledge Base-Artikel stehen in der Knowledge Base von Microsoft Support Services zur Verfügung.

5.1 Erweiterungen für die Datenbankkomponenten und Desktop Engine

Die folgenden Erweiterungen gelten für SQL Server 2000-Instanzen, auf denen Database Components SP3a installiert ist. Sie gelten auch für MSDE 2000-Instanzen, auf denen Desktop Engine SP3a installiert ist.

5.1.1 Verwenden von chinesischen, japanischen oder koreanischen Zeichen mit Database Components SP3a

Eingeführt in SP1

Wenn Sie Database Components SP3a auf einem Server unter Windows NT 4.0 oder Windows 98 installieren und später auf Windows 2000 aktualisieren, werden bei der Aktualisierung auf Windows 2000 bestimmte Systemdateien ersetzt. Diese Systemdateien werden zum Sortieren von chinesischen, japanischen oder koreanischen Zeichen benötigt. Führen Sie die SP3a-Version von Sqlredis.exe nach der Aktualisierung auf Windows 2000 erneut aus, falls Sie chinesische, japanische oder koreanische Zeichen in SQL Server-Datenbanken verwenden. Weitere Informationen zum Ausführen von Sqlredis.exe finden Sie in Abschnitt 4.2, Weitervertreiben der Clientkomponenten von Database Components SP3a.

Anmerkung  Auf Clientcomputern oder Servern, die keine Datenbanken mit enthaltenen chinesischen, japanischen oder koreanischen Zeichen aufweisen, müssen Sie Sqlredis.exe nicht erneut anwenden.

5.1.2 Nicht mehr verfügbare Hashteams

Eingeführt in SP1

Die Hashteams wurden entfernt. Wegen bestimmter Verbesserungen an SQL Server 2000 führen Hashteams nicht mehr zu den Leistungsverbesserungen, die sie in SQL Server 7.0 erzielten. Außerdem wird SQL Server 2000 durch das Entfernen der Hashteams stabiler.

Der Abfrageoptimierer generiert folglich keine Abfragepläne mit Hashteams mehr.

In seltenen Fällen kann das Entfernen der Hashteams zu einer langsameren Verarbeitung der Abfrage führen. Analysieren Sie solche Abfragen, um festzustellen, ob die Abfrageleistung durch das Erstellen besser geeigneter Indizes auf die frühere Ebene zurückgebracht werden kann.

5.1.3 Hinzugefügte Schalter für Affinitätsmaske

Eingeführt in SP1

Mit diesem Service Pack werden zwei Schalter für die Affinitätsmaskenoption hinzugefügt.

E/A-Schalter für die Affinitätsmaske

Mit diesem Service Pack können Sie angeben, welche CPUs zum Ausführen von Threads für Datenträger-E/A-Vorgänge verwendet werden sollen. Dieser Schalter muss zusammen mit der Option affinity mask verwendet werden. Weitere Informationen finden Sie in Artikel 298402 in der Knowledge Base von Microsoft Support Services. Anweisungen zum Durchsuchen der Knowledge Base finden Sie in Abschnitt 1.5, Zusätzliche Informationen zu SP3a.

Verbindungsschalter für die Affinitätsmaske

Mit diesem Service Pack können Sie Systeme, die für VIA (Virtual Interface Architecture) aktiviert sind, so konfigurieren, dass die SQL Server-Verbindungen von bestimmten Netzwerkkarten an einen Prozessor oder einen Satz von Prozessoren gebunden werden. Dieser Schalter muss zusammen mit der Option affinity mask verwendet werden. Weitere Informationen finden Sie in Artikel 299641 in der Knowledge Base von Microsoft Support Services.

5.1.4 Gefilterte indizierte Sicht

Eingeführt in SP2

Wenn bei Ihnen der SQL Server 2000-Bug 355069 aufgetreten ist, der im Microsoft Knowledge Base-Artikel 306467 dokumentiert ist, verhindert dieses Service Pack lediglich das zukünftige Auftreten unerwarteter Ergebnisse aufgrund von Datenänderungen. Deshalb müssen Sie zusätzlich zum Anwenden dieser Problembehebung alle Indizes neu erstellen, die auf Sichten mit Filterbedingungen basieren. Weitere Informationen finden Sie in der Knowledge Base von Microsoft Support Services.

5.1.5 Erneutes Erstellen der Volltextkataloge nach Abschluss der Installation

Eingeführt in SP3

Alle Volltextkataloge werden im Rahmen der Installation von SP3a erneut erstellt, außer beim Aktualisieren von SP3. Die Neuerstellung erfolgt automatisch und ist ressourcenintensiv. Bei Abfragen der Volltextkataloge werden bis zum Abschluss der Neuerstellung möglicherweise nur Teilergebnisse oder keine Ergebnisse zurückgegeben. Nach der Installation von SP3a enthalten die Systemereignisprotokolle Meldungen, die besagen, dass die Kataloge beschädigt waren oder dass es sich bei den Katalogen um ältere Versionen handelte, und dass diese neu erstellt werden mussten.

Weitere Informationen finden Sie im Knowledge Base-Artikel 327217, in dem auch mögliche Problemumgehungen zum Bereitstellen der Volltextsuche während der Neuerstellung und zum Vermeiden einer automatischen Neuerstellung beschrieben werden.

5.1.6 Syntaxänderungen für "sp_change_users_login"

Eingeführt in SP3

Wenn Sie sp_change_users_login mit dem @Action=Auto_Fix-Argument ausführen, müssen Sie nun ein Kennwort angeben. sp_change_users_login weist das Kennwort jedem neuen Benutzernamen zu, der für den Benutzer erstellt wird. Das folgende Beispiel zeigt das neue @Password-Argument:

sp_change_users_login [ @Action = ] 'action' 
    [ , [ @UserNamePattern = ] 'user' ] 
    [ , [ @LoginName = ] 'login' ]
    [ , [ @Password = ] 'password' ]

Verwenden sie das @Password–Argument nur mit @Action=Auto_Fix. Das folgende Beispiel zeigt die neue Syntax für den sp_change_users_login-Befehl bei Verwendung von Auto_Fix. Die anderen Beispiele in der SQL Server-Onlinedokumentation bleiben unverändert.

USE pubs
go
EXEC sp_change_users_login 'Auto_Fix', 'Mary', NULL, 'B3r12-36'
go

5.1.7 Standardmäßig deaktivierter Ad-hoc-Zugriff auf OLE DB-Provider

Eingeführt in SP3

Wenn die Registrierungsoption DisallowAdhocAccess nicht ausdrücklich festgelegt ist, ist der Ad-hoc-Zugriff auf OLE DB-Provider standardmäßig nicht zugelassen. Das bedeutet, dass eine Ad-hoc-Abfragesyntax, wie OPENDATASOURCE und OPENROWSET, nicht für Remoteserver verwendet werden kann. Um den Ad-hoc-Zugriff zu ermöglichen, müssen Sie für die Option DisallowAdhocAccess ausdrücklich den Wert 0 festlegen.

5.1.8 Neue Provideroption "SqlServerLike"

Eingeführt in SP3

Um eine effizientere Verarbeitung von Remoteanfragen zu ermöglichen, die LIKE-Prädikate enthalten, wurde in SP3 die SqlServerLike-Option hinzugefügt. Mit SQL Server 2000 SP3 oder höher gibt es zwei Optionen zum Senden von LIKE-Operationen an Verbindungsserver. Wenn der OLE DB-Provider für einen Verbindungsserver die SQL Server-Syntax für den LIKE-Operator und Platzhalter unterstützt, können Sie die Option SqlServerLIKE angeben, damit SQL Server LIKE-Operationen mit der SQL Server-Syntax sendet. Wenn vom OLE DB-Provider für einen Verbindungsserver gemeldet wird, dass er die Entry Level ANSI/ISO SQL-92-Syntax unterstützt, oder wenn der OLE DB-Provider die SQLPROP_ANSILIKE-Eigenschaft zurückgibt, sendet SQL Server LIKE-Operationen mithilfe der SQL-92-Syntax an den Verbindungsserver. Weitere Informationen zu SQLPROP_ANSILIKE finden Sie unter "Programmieren der SQLPROPSET_OPTHINTS-Eigenschaftengruppe" in der SQL Server 2000-Onlinedokumentation.

Zum Aktivieren der Option SqlServerLIKE für einen OLE DB-Provider müssen Sie einen Registrierungsschlüsselwert hinzufügen.

Vorsicht  Unsachgemäßes Bearbeiten der Registrierung kann zu schwerwiegenden Problemen führen, die ein Neuinstallieren des Betriebssystems erforderlich machen können. Microsoft garantiert nicht, dass Probleme, die durch unsachgemäßes Bearbeiten der Registrierung entstehen, gelöst werden können. Sichern Sie vor dem Bearbeiten der Registrierung alle wichtigen Daten.

  1. Öffnen Sie den Registrierungs-Editor.

  2. Navigieren Sie wie folgt zum entsprechenden Registrierungsschlüssel:
  3. Fügen Sie im Schlüssel <Provider Name> den DWORD-Wert SqlServerLIKE hinzu, und legen Sie den Wert auf 1 fest.

5.1.9 Erweiterte Fehlermeldungen für verteilte Abfragen

Eingeführt in SP3

Bei verteilten Abfragen gibt SQL Server Fehlerinformationen des Providers zusätzlich zu denen des Servers zurück. Wenn eine Abfrage zwischen Verbindungsservern zu einem Fehler führt, prüft SQL Server, ob der Provider die OLE DB-Schnittstelle IErrorRecords unterstützt. Wenn diese Schnittstelle unterstützt wird, ruft SQL Server die GetErrorInfo-Funktion auf, um weitere Fehlerinformationen vom Provider abzurufen. SQL Server gibt diese Informationen im Rahmen der Fehlermeldung an den Benutzer zurück. Wenn die Schnittstelle IErrorRecords nicht unterstützt wird, ändert sich das Verhalten von SQL Server nicht: SQL Server gibt einen allgemeinen Fehler zurück.

Führen Sie beispielsweise die folgende Abfrage für einen Server aus, der MSDASQL verwendet und daher sql_variant nicht unterstützt:

SELECT * FROM remote2k.dqtable.dbo.sqlvariantnotnull 
--Remote2k is a loopback server.

Vor SP3 gab SQL Server die folgende Fehlermeldung zurück:

Server: Meldung 7356, Ebene 16, Status 1, Zeile 1
Der OLE DB-Provider 'msdasql' hat inkonsistente Metadaten für eine Spalte übergeben. 
Die Metadateninformationen wurden zur Ausführungszeit geändert.

Nach der Anwendung von SP3 oder höher gibt SQL Server die folgende Fehlermeldung zurück:

Server: Meldung 7356, Ebene 16, Status 1, Zeile 1
Der OLE DB-Provider 'msdasql' hat inkonsistente Metadaten für eine Spalte übergeben. 
Die Metadateninformationen wurden zur Ausführungszeit geändert.
OLE DB-Fehlertrace [Non-interface error:  Column 'sql_variant' (compile-time
ordinal 3) of object '"dqtable"."dbo"."sqlvariantnotnull"' was reported 
to have a DBCOLUMNFLAGS_ISFIXEDLENGTH of 16 at compile time and 0 at run time].

5.1.10 Zurückgeben einer SQL-Anweisung mit der neuen fn_get_sql-Funktion

Eingeführt in SP3

SP3 und höher enthält die neue fn_get_sql-Funktion, die den Text der SQL-Anweisung für das angegebene SQL-Handle zurückgibt. Zur Unterstützung dieser Funktion wurden außerdem zur sysprocesses-Systemtabelle drei neue Spalten hinzugefügt, die in der folgenden Tabelle aufgeführt sind.

Spaltenname Datentyp Beschreibung
sql_handle binary(20) Stellt den derzeit ausgeführten Batch oder das derzeit ausgeführte Objekt dar.
stmt_start int Startoffset der aktuellen SQL-Anweisung für den angegebenen sql_handle-Wert.
stmt_end int Endoffset der aktuellen SQL-Anweisung für den angegebenen sql_handle-Wert.

Der Wert -1 gibt an, dass die aktuelle Anweisung bis zum Ende der Ergebnisse ausgeführt wird, die von der fn_get_sql-Funktion für den angegebenen sql_handle-Wert zurückgegeben werden.

Syntax

fn_get_sql ([ @SqlHandle = ] SqlHandle )

Argumente

[ @SqlHandle = ] SqlHandle

Der Handlewert. SqlHandle ist vom Typ binary(20).

Zurückgegebene Tabellen
Spaltenname Datentyp Beschreibung
dbid smallint Datenbank-ID. Dieser Wert ist für Ad-hoc-SQL-Anweisungen NULL.
objectid Int ID des Datenbankobjekts. Dieser Wert ist für Ad-hoc-SQL-Anweisungen NULL.
number smallint Die Nummer der Gruppe, wenn die Prozeduren gruppiert sind. Dieser Wert ist für Einträge, bei denen es sich nicht um Prozeduren handelt, 0 und für Ad-hoc-SQL-Anweisungen NULL.
encrypted Bit Zeigt an, ob das Objekt verschlüsselt ist. Der Wert ist 0, wenn das Objekt nicht verschlüsselt ist, und 1, wenn das Objekt verschlüsselt ist.
text Text Text der SQL-Anweisung. Dieser Wert ist für verschlüsselte Objekte NULL.

Hinweise

Sie können ein gültiges SQL-Handle aus der sql_handle-Spalte der sysprocesses-Systemtabelle abrufen.

Wenn Sie ein Handle übergeben, das nicht mehr im Cache gespeichert ist, gibt fn_get_sql ein leeres Resultset zurück. Wenn Sie ein ungültiges Handle übergeben, wird die Ausführung des Batches beendet, und die folgende Fehlermeldung wird zurückgegeben:

Server: Meldung 569, Ebene 16, Status 1, Prozedur fn_get_sql, Zeile 12 Das an "fn_get_sql" übergebene Handle war ungültig.

SQL Server 2000 kann einige Transact-SQL-Anweisungen nicht im Cache speichern, wie Massenkopieranweisungen und Anweisungen mit Zeichenfolgenliteralen, die größer als 8 KB sind. Sie können für diese Anweisungen keine Handles mithilfe der fn_get_sql-Funktion abrufen.

Die text-Spalte des Resultsets wird nach Text gefiltert, der möglicherweise Kennwörter enthält.

Die Informationen, die von der fn_get_sql-Funktion zurückgegeben werden, sind mit dem DBCC INPUTBUFFER-Befehl vergleichbar. Verwenden Sie die fn_get_sql-Funktion, wenn der DBCC INPUTBUFFER-Befehl nicht verwendet werden kann. Dies gilt beispielsweise in folgenden Fällen:

Berechtigungen

Nur Mitglieder der festen Serverrolle sysadmin können die fn_get_sql-Funktion ausführen.

Beispiele

Datenbankadministratoren können die fn_get_sql-Funktion zum Diagnostizieren problematischer Prozesse verwenden. Nachdem ein Administrator eine problematische Serverprozess-ID (SPID) erkannt hat, kann der Administrator das SQL-Handle für diese SPID abrufen, die fn_get_sql-Funktion mit dem Handle aufrufen und mithilfe der Start- und Endoffsets den SQL-Text der problematischen SPID ermitteln. Beispiel: 

DECLARE @Handle binary(20)
SELECT @Handle = sql_handle FROM sysprocesses WHERE spid = 52
SELECT * FROM ::fn_get_sql(@Handle)

5.1.11 Datenbankübergreifende Besitzverkettung

Eingeführt in SP3

Dieses Service Pack stellt neue Optionen zum Aktivieren und Deaktivieren der datenbankübergreifenden Besitzverkettung bereit.

Während der Installation von Database Components SP3a wird im Dialogfeld Prüfliste für die Rückwärtskompatibilität eine Option für die Konfiguration der datenbankübergreifenden Besitzverkettung angezeigt. Das Setup-Programm deaktiviert standardmäßig die datenbankübergreifende Besitzverkettung für alle Benutzerdatenbanken. Sie können die datenbankübergreifende Besitzverkettung für alle Datenbanken aktivieren. Weitere Informationen finden Sie unter Dialogfeld "Prüfliste für die Rückwärtskompatibilität".

Beim Installieren von Desktop Engine SP3a können Sie mit dem Setup-Parameter ALLOWXDBCHAINING die datenbankübergreifende Besitzverkettung für alle Datenbanken aktivieren. Weitere Informationen finden Sie in Abschnitt 3.7.3, Setup-Parameter für MSDE 2000.

Anmerkung  Das Aktivieren der datenbankübergreifenden Besitzverkettung für alle Datenbanken wird nicht empfohlen.

Nach der Installation können Sie mithilfe der folgenden Methoden die datenbankübergreifende Besitzverkettung für alle Datenbanken in der Instanz aktivieren und deaktivieren:

Wenn die datenbankübergreifende Besitzverkettung für die Instanz deaktiviert ist, können Sie sie für einzelne Datenbanken konfigurieren. Aktivieren und deaktivieren Sie für eine Datenbank die datenbankübergreifende Besitzverkettung mithilfe der folgenden Methoden:

Anmerkung  Wenn Sie zuvor die datenbankübergreifende Besitzverkettung bei einer Vorabversion von SP3 (vor Build 8.00.760) aktiviert haben, müssen Sie sie nach dem Installieren von SP3a erneut aktivieren.

Weitere Informationen erhalten Sie, indem Sie beim Ausführen des Setup-Programms auf der Seite Prüfliste für die Rückwärtskompatibilität auf die Hilfeschaltfläche klicken oder indem Sie die aktualisierte Edition der SQL Server 2000-Onlinedokumentation downloaden. Sie können auch den Knowledge Base-Artikel 810474 heranziehen.

5.1.12 Erweiterung für Ablaufverfolgungsflag 1204

Eingeführt in SP3

Das Ablaufverfolgungsflag 1204 gibt den Typ der an einem Deadlock beteiligten Sperren und den betroffenen aktuellen Befehl zurück. Wenn dieses Ablaufverfolgungsflag bei SP3 und höher aktiviert ist, werden die Deadlockinformationen automatisch in das Fehlerprotokoll geschrieben.

5.1.13 Berechtigungsänderung für "sp_changedbowner"

Eingeführt in SP3

Nur Mitglieder der festen Serverrolle sysadmin können die gespeicherte Systemprozedur sp_changedbowner ausführen.

5.1.14 Änderungen bei der Funktionalität zum Debuggen

Eingeführt in SP3

Die Funktionalität zum Debuggen gespeicherter Prozeduren mit Microsoft Visual Studio® 6.0 und früher oder mit SQL Server Query Analyzer vor SP3 ist standardmäßig deaktiviert. Auch das Debuggen von Anwendungen (Anhalten bei einem Transact-SQL-Haltepunkt von SQL Server beim Debuggen einer Clientanwendung) ist standardmäßig deaktiviert. Um die Funktionalität zum Debuggen zu aktivieren, führen Sie sp_sdidebug aus und übergeben dabei den legacy_on-Parameter. Um das Debuggen zu deaktivieren, übergeben Sie legacy_off an diese Prozedur.

Anmerkung  Es wird davon abgeraten, die gespeicherte Prozedur sp_sdidebug auf Produktionsservern auszuführen.

Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 328151. Dieser Artikel ist in der Knowledge Base von Microsoft Support Services verfügbar.

5.1.15 Vorgänge für UDP-Port 1434

Eingeführt in SP3a

Seit SQL Server 2000 SP3a verwenden Instanzen des SQL Server 2000-Datenbankmoduls und von MSDE 2000, die nicht zum Unterstützen der Netzwerkkommunikation konfiguriert sind, nicht mehr den UDP-Port 1434 (User Datagram Protocol). Instanzen, die zum Unterstützen der Netzwerkkommunikation konfiguriert sind, verwenden UDP 1434.

Eine auf SP3a aktualisierte Instanz verwendet UDP 1434 nicht, wenn alle Server-Netzwerkbibliotheken für die Instanz (außer der Shared Memory-Netzwerkbibliothek) deaktiviert sind. Sie verwendet Port 1434 wieder, wenn Sie eine der Server-Netzwerkbibliotheken aktivieren. Informationen zum Aktivieren und Deaktivieren von Server-Netzwerkbibliotheken finden Sie unter "SQL Server-Netzwerkkonfiguration" in der SQL Server 2000-Onlinedokumentation.

Die Verwendung von UDP-Port 1434 wird erst dann für einen Computer beendet, wenn alle Instanzen von SQL Server 2000 und MSDE 2000 auf dem Computer auf SP3a aktualisiert wurden und so konfiguriert wurden, dass sie keine Netzwerkkommunikation unterstützen.

Der Status der Shared Memory-Netzwerkbibliothek hat keinen Einfluss darauf, ob UDP-Port 1434 geöffnet oder geschlossen ist. Die Shared Memory-Netzwerkbibliothek wird nur für lokale Verbindungen verwendet. Für sie wird kein Netzwerk verwendet. Die Shared Memory-Netzwerkbibliothek ist immer aktiv. Sie kann nicht aktiviert oder deaktiviert werden.

Sie können außerdem festlegen, ob die Server-Netzwerkbibliotheken beim Installieren oder Aktualisieren einer MSDE 2000-Instanz deaktiviert werden sollen. Verwenden Sie dazu entweder den DISABLENETWORKPROTOCOLS-Parameter des Setup-Dienstprogramms für MSDE 2000 oder die SqlDisableNetworkProtocols-Eigenschaft im Zusammenführungsmodul für MSDE 2000. Weitere Informationen zu diesen Optionen finden Sie in Abschnitt 3.7.3, Setup-Parameter für MSDE 2000.

Beim Installieren oder Aktualisieren von Instanzen des SQL Server 2000-Datenbankmoduls können Sie nicht alle Server-Netzwerkbibliotheken deaktivieren.

5.2 Erweiterungen bei Analysis Services

In diesem Abschnitt werden die in SP3a enthaltenen Erweiterungen bei SQL Server 2000 Analysis Services beschrieben.

5.2.1 Remotepartitionen

Eingeführt in SP1

Wenn eine Remotepartition auf einem lokalen Server mit installiertem SP1 oder höher erstellt wird, muss der Remoteserver ein Domänenbenutzerkonto mit vollständigen Zugriffsberechtigungen für den übergeordneten Cube auf dem lokalen Server verwenden. Alle Benutzerkonten, die Mitglieder der Gruppe OLAP Administrators auf dem lokalen Server sind, verfügen über vollständige Zugriffsberechtigungen.

Wenn auf dem lokalen Server SP1 oder eine höhere Version installiert ist, muss auf dem Remoteserver ebenfalls SP1 oder eine höhere Version installiert sein, damit der lokale Server Remotepartitionen erstellen oder verwalten kann.

5.2.2 Aktualisierte weitervertreibbare Setup-Programme für Analysis Services-Clients

Eingeführt in SP1

Analysis Services SP1 und höhere Versionen enthalten aktualisierte Versionen der folgenden weitervertreibbaren Setup-Programme für Clients:

Diese Dateien befinden sich im Pfad \Msolap\Install\PTS des Service Pack-Installationsverzeichnisses.

Anmerkung  PTSFull.exe enthält MDAC, PTSLite.exe nicht.

Verwenden Sie diese aktualisierten Setup-Programme für Clients in Ihren Anwendungen, um Probleme bei der Clientinstallation zu verhindern oder zu lösen, die möglicherweise beim Verwenden von Analysis Services und Microsoft Office XP auftreten.

Anmerkung  Bei der Verwendung von Analysis Services mit Office XP ist das Aktualisieren des Clients dringend zu empfehlen.

5.2.3 Aktivierte Unterstützung für Datamining-Algorithmenanbieter von Drittanbietern

Eingeführt in SP1

Analysis Services SP1 und höhere Versionen enthalten Unterstützung für das Hinzufügen von Datamining-Algorithmenanbietern von Drittanbietern. Weitere Informationen zum Entwickeln eines Datamining-Algorithmenanbieters finden Sie im Whitepaper Third-Party Data Mining Providers und im OLE DB for Data Mining Resource Kit, das auch Beispielcode für einen Datamining-Algorithmenanbieter enthält.

5.2.4 Installieren von Analysis Services auf einem Computer mit aktualisierten Clientdateien

Eingeführt in SP1

Wenn Sie SQL Server 2000 Analysis Services auf einem Computer installieren, der aktualisierte Clientdateien enthält, wie Dateien von SQL Server 2000 SP1 oder von Office XP, müssen Sie Analysis Services SP1 oder eine höhere Version anwenden, um sicherzustellen, dass der Client ordnungsgemäß arbeitet und dass Sie Cubes anzeigen können.

5.2.5 Erhöhter Grenzwert für OLAP-Cubes, auf die ein virtueller Cube verweist

Eingeführt in SP3

Virtuelle Cubes können nun auf bis zu 255 Cubes verweisen. Ein virtueller Cube, der auf mehr als 64 Cubes verweist, ist jedoch für Versionen von Microsoft PivotTable® Service vor SP3 nicht sichtbar.

5.2.6 Neues DESCRIPTION-Schlüsselwort

Eingeführt in SP3

Lokale Cubes unterstützen nun die integrierte Elementeigenschaft DESCRIPTION für Measures und Dimensionen. Mithilfe des zur MDX-Anweisung (Multidimensional Expressions) CREATE CUBE hinzugefügten DESCRIPTION-Schlüsselwortes wird die Verwendung der integrierten Elementeigenschaft DESCRIPTION unterstützt. Die folgenden BNF-Klauseln beschreiben die Änderungen, die an der CREATE CUBE-Anweisung vorgenommen wurden:

<dimensions def> :: = DIMENSION <dimension name> [<time def>] 
  [DIMENSION_STRUCTURE <sub_type>] [<hidden def>] 
  [DESCRIPTION <description expression>] 
  <options def> <comma> <hierarchy def list> 
<measures def> :: = MEASURE <measure name> <measure function def> 
  [<measure format def>] [<measure type def>] [<hidden def>] 
  [DESCRIPTION <description expression>] [<comma> <measures def>]

5.2.7 Neue Restricted Client-Eigenschaft für PivotTable Service

Eingeführt in SP3

In SP3 wurde die neue Restricted Client-Eigenschaft für PivotTable Service in der Verbindungszeichenfolge eingeführt. Mithilfe dieser Eigenschaft kann verhindert werden, dass PivotTable Service die lokale Cubefunktionalität nutzt. Jedes Verwenden einer Anweisung, die das Erstellen oder die Verwendung eines lokalen Cube erfordert, wie CREATE CUBE, CREATE GLOBAL CUBE oder CREATE SESSION CUBE, löst dann einen Fehler aus. Außerdem löst jede Anweisung, die eine tiefe Rekursion erfordert, wie z. B. eine Reihe von geschachtelten DRILLDOWN-Anweisungen, einen Fehler aus, wenn die Anweisung möglicherweise zu einem Überlaufen des von PivotTable Service verwalteten Anweisungsstapels führen kann.

In dieser Eigenschaft wird ein Zeichenfolgenwert gespeichert. Wenn für den Wert ein Zeichenfolgenwert festgelegt wurde, der mit den Zeichen "Y", "y", "T" oder "t" beginnt, oder wenn ein Zeichenfolgenwert festgelegt wurde, der in einen anderen numerischen Wert als 0 konvertiert werden kann, wird PivotTable Service wie oben beschrieben eingeschränkt. Wenn für den Wert ein anderer Zeichenfolgenwert wie z. B. eine leere Zeichenfolge ("") oder ein Zeichenfolgenwert festgelegt wurde, der in den numerischen Wert 0 konvertiert werden kann, gibt es für PivotTable Service keine Beschränkung. Der Standardwert für diese Eigenschaft ist "0".

Anmerkung  Diese Eigenschaft schränkt nicht die Nutzung lokaler Dataminingmodelle ein.

5.2.8 Änderung der Safety Options-Eigenschaft

Eingeführt in SP3

Wenn für die Safety Options-Eigenschaft DBPROP_MSMD_SAFETY_OPTIONS_ALLOW_SAFE festgelegt wird, wird auch die Nutzung des PASSTHROUGH-Schlüsselwortes in lokalen Cubes verhindert.

5.2.9 Standardmäßig deaktiviertes Migrieren des Repository zu Meta Data Services

Eingeführt in SP3

Die Option zum Verwenden des Meta Data Services-Repository-Formats im Repositorymigrations-Assistenten ist in SP3 oder höher deaktiviert, und von der Verwendung dieses Formats wird abgeraten. Wenn dieses Format jedoch aus geschäftlichen Gründen benötigt wird, können Sie die Option über den Registrierungsschlüssel EnableMigrationToMetaDataServicesFormat aktivieren.

Standardmäßig ist dieser Registrierungsschlüssel nicht vorhanden. Er muss unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server\Server Connection Info manuell erstellt und so festgelegt werden, dass die Repositorymigration in das Meta Data Services-Format aktiviert wird. In diesem Registrierungsschlüssel wird ein Zeichenfolgenwert gespeichert, bei dem nach Groß-/Kleinschreibung unterschieden wird. Wenn für den Wert 1 oder True festgelegt wird, wird die Repositorymigration in das Meta Data Services-Format aktiviert. Wenn für den Wert ein beliebiger anderer Zeichenfolgenwert festgelegt wird, oder wenn der Registrierungsschlüssel nicht vorhanden ist, wird die Repositorymigration in das Meta Data Services-Format deaktiviert.

Anmerkung  Wenn der Wert dieses Registrierungsschlüssels geändert wird, wird die Änderung sofort wirksam.

5.2.10 Notwendige Berechtigungsänderung bei einem Remotedatenordner

Eingeführt in SP3

Wenn sich der Datenordner von Analysis Services nicht auf dem Computer befindet, auf dem der Analysis-Server ausgeführt wird, müssen Sie die Berechtigungen für den Ordner nach dem Installieren von SP3a ändern. Legen Sie auf dem Remotecomputer die Berechtigungen für den Ordner so fest, dass Vollzugriff für alle Mitglieder der Gruppe OLAP Administrators auf dem Computer mit dem Analysis-Server ermöglicht wird. Verändern Sie beim Hinzufügen oder Entfernen von Mitgliedern der Gruppe OLAP Administrators die Berechtigungen für den Remotedatenordner so, dass sie die aktuelle Mitgliedschaft der Gruppe OLAP Administrators widerspiegeln. Dies ermöglicht ordnungsgemäßes Sichern und Wiederherstellen.

Außerdem müssen Sie nach dem Ausführen des Setup-Programms für SP3a dem Konto, mit dem der Analysis-Server ausgeführt wird, Vollzugriff auf den Remotedatenordner erteilen.

Wenn Sie SP3a auf eine Analysis Services-Instanz in einer Clusterkonfiguration anwenden, muss der Gruppe OLAP Administrators auf Domänenebene Vollzugriff auf den Remotedatenordner erteilt werden. Weitere Informationen zum Erstellen und Verwenden einer Gruppe OLAP Administrators auf Domänenebene finden Sie im Supportartikel 308023 in der Knowledge Base von Microsoft Support Services.

5.3 Erweiterungen bei der Replikation

In diesem Abschnitt werden die in SP3a enthaltenen Erweiterungen bei der SQL Server 2000-Replikation beschrieben.

5.3.1 Benutzerdefinierte gespeicherte Prozedur für UPDATE bei der Transaktionsreplikation

Eingeführt in SP1

Beim Installieren der Transaktionsreplikation werden benutzerdefinierte gespeicherte Prozeduren für Einfüge-, Lösch- und Aktualisierungsaktionen in der Abonnementdatenbank erstellt. Die benutzerdefinierte gespeicherte Aktualisierungsprozedur aktualisiert alle Spalten in der Abonnementtabelle, unabhängig davon, wie viele Spalten von einer UPDATE-Anweisung betroffen sind. Spalten, die nicht geändert wurden, werden wieder auf die Werte festgelegt, die vor der Aktualisierung vorhanden waren. Normalerweise ist diese Aktion unproblematisch. Wenn jedoch mindestens eine dieser Spalten indiziert ist, kann das erneute Festlegen zeitintensiv sein.

Wenn beim Verwenden der Transaktionsreplikation mehrere Indizes für die Abonnementtabelle vorhanden sind und nur wenige Spaltenwerte aufgrund der Aktualisierungen geändert werden, kann der Aufwand zur Indexverwaltung die Leistung beim Anwenden von Änderungen auf den Abonnenten beschränken. Beispielsweise besitzt eine Abonnementdatenbank, die für Berichtzwecke verwendet wird, möglicherweise viel mehr Indizes als die Publikationsdatenbank. Möglicherweise kann die Leistung verbessert werden, indem die UPDATE-Anweisung dynamisch zur Laufzeit erstellt wird. Die Aktualisierung enthält dann nur die Spalten, die geändert wurden, so dass eine optimale UPDATE-Zeichenfolge erstellt wird.

Dieses Service Pack enthält die neue gespeicherte Prozedur sp_scriptdynamicupdproc. Sie generiert eine benutzerdefinierte gespeicherte Prozedur, die Sie auf dem Abonnenten verwenden können, um die UPDATE-Anweisung dynamisch zur Laufzeit zu erstellen. Das Erstellen der dynamischen UPDATE-Anweisung zur Laufzeit erfordert jedoch einen zusätzlichen Verarbeitungsaufwand.

sp_scriptdynamicupdproc

Die gespeicherte Prozedur sp_scriptdynamicupdproc generiert die CREATE PROCEDURE-Anweisung, die eine dynamische gespeicherte Aktualisierungsprozedur erstellt. Die UPDATE-Anweisung in der benutzerdefinierten gespeicherten Prozedur wird dynamisch erstellt. Als Grundlage wird die MCALL-Syntax verwendet, die anzeigt, welche Spalten geändert werden sollen. Verwenden Sie diese gespeicherte Prozedur, wenn die Anzahl der Indizes für die Abonnementtabelle vergrößert wird und die Anzahl der zu ändernden Spalten klein ist. Diese gespeicherte Prozedur wird auf dem Verleger für die Publikationsdatenbank ausgeführt.

Syntax

sp_scriptdynamicupdproc [ @artid =] artid

Argumente

[@artid =] artid

Die Artikel-ID. artid ist vom Datentyp int und hat keinen Standard.

Resultsets

Gibt ein Resultset zurück, das aus einer einzigen Spalte vom Typ nvarchar(4000) besteht. Das Resultset enthält die vollständige CREATE PROCEDURE-Anweisung, die zum Erstellen der benutzerdefinierten gespeicherten Prozedur verwendet wird.

Hinweise

sp_scriptdynamicupdproc wird bei der Transaktionsreplikation verwendet. Die standardmäßige MCALL-Skripterstellungslogik schließt alle Spalten in der UPDATE-Anweisung ein und verwendet ein Bitmuster, um die geänderten Spalten zu bestimmen Wenn eine Spalte nicht geändert wurde, wird sie wieder auf den bestehenden Wert festgelegt. Normalerweise ist dies unproblematisch. Wenn die Spalte indiziert ist, entsteht zusätzlicher Verarbeitungsaufwand. Hingegen verwendet diese gespeicherte Prozedur ein dynamisches Verfahren: Sie schließt nur die Spalten ein, die verändert wurden, so dass eine optimale UPDATE-Zeichenfolge bereitgestellt wird. Zur Laufzeit entsteht jedoch zusätzlicher Verarbeitungsaufwand für das Erstellen der dynamischen UPDATE-Anweisung. Es empfiehlt sich, sowohl das dynamische Verfahren der gespeicherten Prozedur als auch das statische Standardverfahren auszuprobieren und dann die beste Lösung für Ihre spezifischen Anforderungen auszuwählen.

Berechtigungen

Mitglieder der public-Rolle können sp_scriptdynamicupdproc ausführen.

Beispiele

In diesem Beispiel wird ein Artikel (mit dem Wert 1 für artid) für die authors-Tabelle in der pubs-Datenbank erstellt, und es wird angegeben, dass für die UPDATE-Anweisung die benutzerdefinierte gespeicherte Prozedur ausgeführt werden soll:

'MCALL sp_mupd_authors'

Um die benutzerdefinierten gespeicherten Prozeduren zu generieren, die der Verteilungs-Agent auf dem Abonnenten ausführen soll, führen Sie die folgende gespeicherte Prozedur auf dem Verleger aus:

EXEC sp_scriptdynamicupdproc @artid = '1'
Diese Anweisung gibt Folgendes zurück:

create procedure [sp_mupd_authors] 
  @c1 varchar(11),@c2 varchar(40),@c3 varchar(20),@c4 char(12),
  @c5 varchar(40),@c6 varchar(20),@c7 char(2),@c8 char(5),
  @c9 bit,@pkc1 varchar(11),@bitmap binary(2)
as

declare @stmt nvarchar(4000), @spacer nvarchar(1)
select @spacer =N''
select @stmt = N'update [authors] set '

if substring(@bitmap,1,1) & 2 = 2
begin
  select @stmt = @stmt + @spacer + N'[au_lname]' + N'=@2'
  select @spacer = N','
end
if substring(@bitmap,1,1) & 4 = 4
begin
  select @stmt = @stmt + @spacer + N'[au_fname]' + N'=@3'
  select @spacer = N','
end
if substring(@bitmap,1,1) & 8 = 8
begin
  select @stmt = @stmt + @spacer + N'[phone]' + N'=@4'
  select @spacer = N','
end
if substring(@bitmap,1,1) & 16 = 16
begin
  select @stmt = @stmt + @spacer + N'[address]' + N'=@5'
  select @spacer = N','
end
if substring(@bitmap,1,1) & 32 = 32
begin
  select @stmt = @stmt + @spacer + N'[city]' + N'=@6'
  select @spacer = N','
end
if substring(@bitmap,1,1) & 64 = 64
begin
  select @stmt = @stmt + @spacer + N'[state]' + N'=@7'
  select @spacer = N','
end
if substring(@bitmap,1,1) & 128 = 128
begin
  select @stmt = @stmt + @spacer + N'[zip]' + N'=@8'
  select @spacer = N','
end
if substring(@bitmap,2,1) & 1 = 1
begin
  select @stmt = @stmt + @spacer + N'[contract]' + N'=@9'
  select @spacer = N','
end
select @stmt = @stmt + N' where [au_id] = @1'
exec sp_executesql @stmt, N' @1 varchar(11),@2 varchar(40),@3 varchar(20),
  @4 char(12),@5 varchar(40),@6 varchar(20),@7 char(2),@8 char(5),@9 bit',
  @pkc1,@c2,@c3,@c4,@c5,@c6,@c7,@c8,@c9

if @@rowcount = 0
   if @@microsoftversion>0x07320000
      exec sp_MSreplraiserror 20598

Nach dem Ausführen dieser gespeicherten Prozedur können Sie den resultierenden Skriptcode zum manuellen Erstellen der gespeicherten Prozedur auf den Abonnenten verwenden.

5.3.2 UPDATE-Anweisungen für eindeutige Spalten bei der Transaktionsreplikation

Eingeführt in SP1

Bei der Transaktionsreplikation werden UPDATE-Anweisungen normalerweise als Aktualisierungen repliziert. Wenn die Aktualisierung jedoch mindestens eine Spalte ändert, die Teil eines eindeutigen Indexes, eines gruppierten Indexes oder eines als Eindeutigkeitseinschränkung verwendeten Ausdrucks ist, dann wird die Aktualisierung auf dem Abonnenten als DELETE-Anweisung gefolgt von einer INSERT-Anweisung ausgeführt. Der Grund ist, dass sich diese Art der Aktualisierung auf mehrere Zeilen auswirken kann und es zu einer Verletzung der Eindeutigkeit kommen kann, wenn die Aktualisierungen zeilenweise erfolgen.

Wenn sich die Aktualisierung nur auf eine Zeile auswirkt, besteht keine Möglichkeit, die Eindeutigkeit zu verletzen. Daher wurde in diesem Service Pack das Ablaufverfolgungsflag 8207 hinzugefügt, um zu ermöglichen, dass Aktualisierungen einer eindeutigen Spalte, die sich nur auf eine Zeile auswirken, als UPDATE-Anweisungen repliziert werden. Diese Optimierung wurde speziell für Anwendungen hinzugefügt, die benutzerdefinierte UPDATE-Trigger auf dem Abonnenten installieren und die es erfordern, dass diese Trigger bei Aktualisierungen ausgelöst werden, die sich nur auf eine Zeile einer eindeutigen Spalte auswirken.

Um das Ablaufverfolgungsflag 8207 zu verwenden, müssen Sie es von der Befehlszeile aus mithilfe von sqlservr.exe -T8207 oder zur Laufzeit mithilfe von DBCC TRACEON(8207, -1) aktivieren, bevor der Protokolllese-Agent gestartet wird.

Wichtig  Typischerweise wird das Ablaufverfolgungsflag 8207 bei der Nur-Lesen-Transaktionsreplikation verwendet. Verwenden Sie dieses Ablaufverfolgungsflag nicht bei aktualisierbaren Abonnements, wenn UPDATE für Primärschlüssel auf dem Abonnenten auftreten kann.

5.3.3 Wegfallende Einschränkungen bei der gleichzeitigen Snapshotverarbeitung

Eingeführt in SP1

In SQL Server 2000 ohne das Service Pack empfiehlt sich die gleichzeitige Snapshotverarbeitung nicht, wenn die Publikationstabelle einen eindeutigen Index aufweist, der weder der Primärschlüssel noch der Gruppierungsschlüssel ist. Wenn Datenänderungen am Gruppierungsschlüssel vorgenommen werden, während ein gleichzeitiger Snapshot generiert wird, kann die Replikation wegen eines doppelten Schlüsselwertes fehlschlagen, wenn der aktuelle Snapshot auf einen Abonnenten angewendet wird. Mit diesem Service Pack werden Einschränkungen bei der gleichzeitigen Snapshotverarbeitung entfernt.

5.3.4 Benutzerdefinierte gespeicherte Skripterstellungsprozeduren bei der Transaktionsreplikation

Eingeführt in SP1

Beim Einrichten von nicht synchronisierten Abonnements (d. h. Abonnements, die den Anfangssnapshot nicht erhalten) müssen die benutzerdefinierten gespeicherten Prozeduren für die Anweisungen INSERT, UPDATE und DELETE manuell erstellt werden. Typischerweise werden diese Anweisungen auf dem Abonnenten erstellt, wenn der Anfangssnapshot angewendet wird. Die neue gespeicherte Prozedur sp_scriptpublicationcustomprocs wurde hinzugefügt, um Skripts für die benutzerdefinierten gespeicherten Prozeduren auf Publikationsebene zu generieren. Diese neue Funktionalität kann das Einrichten nicht synchronisierter Abonnements erleichtern.

sp_scriptpublicationcustomprocs

Bei einer Publikation, für die die Option zum automatischen Generieren eines benutzerdefinierten Prozedurschemas aktiviert ist, erstellt die gespeicherte Prozedur sp_scriptpublicationcustomprocs Skriptcode für die benutzerdefinierten Prozeduren für INSERT, UPDATE und DELETE für alle Tabellenartikel. Besonders nützlich ist sp_scriptpublicationcustomprocs beim Einrichten von Abonnements, für die der Snapshot manuell angewendet wird.

Syntax

sp_scriptpublicationcustomprocs [@publication]= publication_name

Argumente

[@publication] = publication_name

Der Name der Publikation. publication_name ist vom Datentyp sysname und hat keinen Standard.

Rückgabecodewerte

0 (Erfolg) oder 1 (Fehler)

Resultsets

Gibt ein Resultset zurück, das aus einer einzigen Spalte vom Typ nvarchar(4000) besteht. Das Resultset enthält die vollständige CREATE PROCEDURE-Anweisung, die zum Erstellen der benutzerdefinierten gespeicherten Prozedur erforderlich ist.

Hinweise

Für benutzerdefinierte Prozeduren wird nur bei Artikeln Skriptcode erstellt, für die die Schemaoption für das automatische Generieren von benutzerdefinierten Prozeduren (0x2) aktiviert ist.

Berechtigungen

Über Ausführungsberechtigungen verfügt die public-Rolle; in dieser gespeicherten Prozedur wird eine Sicherheitsüberprüfung auf Prozedurebene ausgeführt, um den Zugriff nur Mitgliedern der festen Serverrolle sysadmin und der festen Datenbankrolle db_owner in der aktuellen Datenbank zu gewähren.

Beispiel

In diesem Beispiel wird ein Skript für die benutzerdefinierten gespeicherten Prozeduren in einer Publikation namens Northwind erstellt.

exec Northwind.dbo.sp_scriptpublicationcustomprocs 
@publication = N'Northwind'

5.3.5 Beibehaltungsbasierter Metadatencleanup bei der Mergereplikation

Eingeführt in SP1

Wenn die Systemtabellen einer Mergereplikation viele Metadaten enthalten, verbessert ein Metadatencleanup die Leistung. Vor SQL Server 2000 SP1 konnte ein Metadatencleanup nur mit sp_mergecleanupmetadata ausgeführt werden. SQL Server 2000 SP1 und höhere Versionen ermöglichen hingegen den beibehaltungsbasierten Metadatencleanup. Dies bedeutet, dass Metadaten aus den folgenden Systemtabellen automatisch gelöscht werden können:

Anmerkung  Anfangsabbildtabellen sind vorhanden, falls die Option @keep_partition_changes zur Synchronisierungsoptimierung für die Publikation aktiviert ist.

Der beibehaltungsbasierte Metadatencleanup tritt wie folgt auf:

Zusätzlicher Parameter für "sp_add_agent_parameter"

Die gespeicherte Systemprozedur sp_add_agent_parameter besitzt jetzt den MetadataRetentionCleanup-Parameter, mit dem Sie den beibehaltungsbasierten Metadatencleanup zu Merge-Agent-Profilen hinzufügen oder von diesen entfernen können. Der Wert 1 zeigt an, dass das Profil den Cleanup einschließen soll; der Wert 0 zeigt an, dass es keinen Cleanup einschließen soll. Um beispielsweise den beibehaltungsbasierten Metadatencleanup zu einem Profil hinzuzufügen, führen Sie folgenden Code aus:

EXEC sp_add_agent_parameter @profile_id=<my_profile_id>,
  @parameter_name='MetadataRetentionCleanup', @parameter_value=1

Metadatencleanup in Topologien mit verschiedenen SQL Server-Versionen

Damit der automatische beibehaltungsbasierte Cleanup in einer Datenbank auftritt, die in die Mergereplikation einbezogen wird, müssen sich die Datenbank und der Merge-Agent auf Servern mit SQL Server 2000 SP1 oder höher befinden. Beispiel:

Das Verwenden von automatischem Cleanup auf einigen Servern, aber nicht auf allen, führt im schlimmsten Fall zu falschen Konflikten, und auch diese sollten selten sein. Für Topologien, die SQL Server-Versionen vor SQL Server 2000 SP1 enthalten, ergeben sich möglicherweise Leistungsvorteile, wenn Sie sp_mergemetadatacleanup auf allen Servern ausführen, für die kein automatischer Cleanup erfolgt.

Verhindern falscher Konflikte

Der beibehaltungsbasierte Metadatencleanup verhindert den Zustand, in dem Daten nicht konvergieren, und das Überschreiben von Änderungen auf anderen Knoten ohne Warnung. Falsche Konflikte können jedoch auftreten, wenn die folgenden Bedingungen erfüllt sind:

Wenn beispielsweise ein Metadatencleanup auf dem Verleger erfolgt, nicht jedoch auf dem Abonnenten, und eine Aktualisierung auf dem Verleger vorgenommen wird, dann tritt ein Konflikt auf, obwohl die Daten scheinbar synchronisiert sind.

Um diesen Konflikt zu vermeiden, sollten Sie sicherstellen, dass der Metadatencleanup für Knoten, die miteinander in Beziehung stehen, ungefähr gleichzeitig erfolgt. Wenn -MetadataRetentionCleanup auf 1 festgelegt ist, erfolgt vor dem Beginn des Mergevorgangs automatisch ein Cleanup für den Verleger und den Abonnenten. Somit wird sichergestellt, dass der Cleanup für die beiden Knoten zur gleichen Zeit erfolgt. Verwenden Sie beim Auftreten eines Konflikts den Mergereplikationskonflikt-Viewer, um den Konflikt zu überprüfen und das Ergebnis nötigenfalls zu ändern.

Wenn ein Artikel zu mehreren Publikationen gehört oder Teil eines Neuverlegeszenarios ist, können die Beibehaltungsdauerwerte für eine gegebene Zeile auf dem Verleger und auf dem Abonnenten unterschiedlich sein. Um die Wahrscheinlichkeit zu verringern, dass ein Metadatencleanup auf einer Seite, nicht jedoch auf der anderen erfolgt, empfiehlt es sich, die gleiche Beibehaltungsdauer für diese unterschiedlichen Publikationen zu verwenden.

Anmerkung  Wenn die Systemtabellen viele Metadaten enthalten, für die ein Cleanup erforderlich ist, dauert die Ausführung des Mergeprozesses möglicherweise länger. Um dieses Problem zu verhindern, sollten Sie regelmäßig einen Metadatencleanup ausführen.

5.3.6 Aspekte zum Sichern und Wiederherstellen bei der Mergereplikation

Eingeführt in SP1

Für eine Publikationsdatenbank, die von einer Sicherung wiederhergestellt wird, sollte zuerst eine Synchronisierung mit einer Abonnementdatenbank ausgeführt werden, die über ein globales Abonnement verfügt (d. h. über ein Abonnement mit einem zugewiesenen Prioritätswert), um ein ordnungsgemäßes Konvergenzverhalten der Daten sicherzustellen. Durch die Synchronisierung wird sichergestellt, dass die Änderungen an der Publikationsdatenbank, die bei der Wiederherstellung verloren gegangen sind, ordnungsgemäß erneut angewendet werden.

Synchronisieren Sie die Publikationsdatenbank nicht mit einer Abonnementdatenbank, die über ein anonymes Abonnement verfügt. Da anonyme Abonnements nicht genug Metadaten aufweisen, um Änderungen auf die Publikationsdatenbank anzuwenden, kann eine derartige Synchronisierung dazu führen, dass Daten nicht konvergieren.

Bedenken Sie beim Planen von Sicherungs- und Wiederherstellungsvorgängen für die Mergereplikation die folgenden zusätzlichen Aspekte:

Stellen Sie eine Abonnementdatenbank nur dann aus einer Sicherung wieder her, wenn das Alter der Sicherung die kürzeste Beibehaltungsdauer aller vom Abonnenten abonnierten Publikationen nicht überschreitet. Wenn ein Abonnent beispielsweise drei Publikationen abonniert, deren Beibehaltungsdauerwerte 10, 20 und 30 Tage betragen, sollte die zum Wiederherstellen der Datenbank verwendete Sicherung höchstens 10 Tage alt sein.

Es empfiehlt sich dringend, einen Abonnenten vor dem Ausführen einer Sicherung mit dem Verleger zu synchronisieren. Andernfalls konvergieren die Daten im System möglicherweise nicht ordnungsgemäß, wenn der Abonnent von dieser Sicherung wiederhergestellt wird. Selbst wenn die Sicherungsdatei erst vor kurzem erstellt wurde, kann die letzte Synchronisierung mit dem Verleger fast um die Beibehaltungsdauer zurückliegen. Nehmen Sie beispielsweise an, dass eine Publikation mit einer Beibehaltungsdauer von 10 Tagen vorliegt. Die letzte Synchronisierung liegt 8 Tage zurück, und jetzt wird die Sicherung ausgeführt. Wenn die Sicherung 4 Tage später angewendet wird, ist die letzte Synchronisierung 12 Tage her. Dies überschreitet die Beibehaltungsdauer. Wenn die Synchronisierung des Abonnenten genau vor der Sicherung ausgeführt worden wäre, würde das Alter der Abonnementdatenbank die Beibehaltungsdauer nicht übersteigen.

Wenn Sie die Beibehaltungsdauer der Publikation ändern müssen, sollten Sie den Abonnenten manuell neu initialisieren, um sicherzustellen, dass die Daten konvergieren. Die Funktion zum beibehaltungsbasierten Metadatencleanup löscht veraltete Metadaten aus Mergesystemtabellen, wenn die Beibehaltungsdauer der Publikation erreicht wird.

Mithilfe der Beibehaltungsdauer der Publikation wird bestimmt, wann Abonnements ablaufen, für die während der Beibehaltungsdauer keine Synchronisierung durchgeführt wurde. Wenn die Beibehaltungsdauer der Publikation nach einem Cleanup erhöht wird und für ein Abonnement ein Mergevorgang mit dem Verleger versucht wird (auf dem die Metadaten bereits gelöscht wurden), dann läuft das Abonnement nicht ab, weil die Beibehaltungsdauer erhöht wurde. Außerdem verfügt der Verleger nicht über ausreichende Metadaten zum Downloaden der Änderungen auf den Abonnenten. Dies führt zu mangelnder Konvergenz der Daten.

5.3.7 Wiederherstellen replizierter Datenbanken von verschiedenen SQL Server-Versionen

Eingeführt in SP1

Wenn Sie eine Sicherung auf denselben Server und in dieselbe Datenbank wiederherstellen und dort dieselbe Version ausgeführt wird wie auf dem Server, von dem die Sicherung erstellt wurde, dann werden die Replikationseinstellungen beibehalten. Wenn Sie eine replizierte Datenbank mit einer anderen SQL Server-Version wiederherstellen als derjenigen, mit der die Datenbank gesichert wurden, sollten Sie die folgenden Aspekte berücksichtigen:

5.3.8 Neuer -MaxCmdsInTran-Parameter für den Protokolllese-Agent

Eingeführt in SP1

In SP1 wurde der neue -MaxCmdsInTran-Befehlszeilenparameter für den Protokolllese-Agent hinzugefügt. Für Transaktionen, die sich auf eine große Anzahl von Befehlen beziehen (normalerweise Massenaktualisierungen oder -löschungen), muss der Verteilungs-Agent warten, bis der Protokolllese-Agent die gesamte Transaktion in die Verteilungsdatenbank geschrieben hat, bevor der Verteilungs-Agent die Transaktion an den Abonnenten weitergeben kann. Diese Verspätung blockiert den Verteilungs-Agent und reduziert die Parallelität zwischen den beiden Agents.

Bei Verwendung von -MaxCmdsInTran zerlegt der Protokolllese-Agent große Transaktionen in kleinere Blöcke. Jeder Block enthält höchstens so viele Befehle, wie als Eingabewert bei -MaxCmdsInTran angegeben wurde. Daher kann der Verteilungs-Agent die früheren Blöcke einer Transaktion schon verarbeiten, während der Protokolllese-Agent noch die späteren Blöcke derselben Transaktion verarbeitet.

Diese Verbesserung der Parallelität zwischen dem Protokolllese-Agent und dem Verteilungs-Agent trägt dazu bei, dass der Replikationsdurchsatz insgesamt verbessert wird. Beachten Sie jedoch, dass für die entsprechenden Blöcke auf dem Abonnenten ein Commit ausgeführt wird wie für individuelle Transaktionen, so dass die Eigenschaft der Unteilbarkeit, eine der ACID-Eigenschaften (Atomicity, Consistency, Isolation und Durability; Unteilbarkeit, Konsistenz, Isolation und Beständigkeit), nicht gegeben ist. Unter den meisten Umständen stellt dieser Effekt kein Problem dar. Es empfiehlt sich jedoch, dies mithilfe von Tests sicherzustellen.

Definieren des –MaxCmdsInTran-Parameters

Geben Sie als Wert für den -MaxCmdsInTran-Parameter eine positive ganze Zahl (d. h. 1 oder höher) an. Das Angeben des Wertes 0 ist gleichbedeutend mit dem Weglassen des Parameters. Da dieser Parameter die Leistung nur dann verbessert, wenn die Transaktion sehr groß ist, hat er typischerweise mindestens den Wert 5000. Beispiel:

logread.exe -MaxCmdsInTran 10000

Damit dieser Parameter verwendet werden kann, muss auf dem Verleger SQL Server 2000 SP1 oder höher ausgeführt werden, und der Protokolllese-Agent und die Verteilungsdatenbank müssen auf SP3 oder höher aktualisiert werden. Andernfalls wird -MaxCmdsInTran ignoriert.

5.3.9 Einschränkung bei nicht eindeutigen gruppierten Indizes

Eingeführt in SP2 (gilt nur für die Transaktionsreplikation).

Sie können keinen nicht eindeutigen gruppierten Index für eine Tabelle erstellen, nachdem sie für die Transaktionsreplikation publiziert wurde. Vor dem Erstellen des Indexes müssen Sie zunächst alle Publikationen löschen, die die Tabelle einschließen.

5.3.10 Neues -MaxNetworkOptimization-Befehlszeilenargument für den Snapshot-Agent

Eingeführt in SP2.

Während der normalen Verarbeitung kann die Mergereplikation an Abonnenten DELETE-Befehle senden, die sich auf Zeilen beziehen, die nicht zur Partition des Abonnenten gehören. DELETE-Befehle dieser Art werden als irrelevante Löschungen bezeichnet. Irrelevante Löschungen haben keine Auswirkungen auf die Datenintegrität oder -konvergenz, können jedoch zu unnötigem Netzwerkverkehr führen.

Zum Verringern des Netzwerkverkehrs durch irrelevante Löschungen können Sie den neuen -MaxNetworkOptimization-Parameter für den Snapshot-Agent bei Mergereplikationspublikationen verwenden. Das Festlegen des Parameters auf 1 verringert die Wahrscheinlichkeit irrelevanter Löschungen, so dass die Netzwerkleistung erhöht wird.

Anmerkung  Das Festlegen dieses Parameters auf 1 ist nur dann von Nutzen, wenn die Option zur Synchronisierungsoptimierung der Mergepublikation auf true festgelegt ist (d. h. der @keep_partition_changes-Parameter von sp_addmergepublication).

Standard ist 0, weil das Festlegen des Parameters auf 1 die Speicherung von Metadaten erhöhen und so zu Leistungsabfall auf dem Verleger führen kann, wenn mehrere Ebenen von Verknüpfungsfiltern und komplexen Teilmengenfiltern vorhanden sind. Sie sollten Ihre Replikationstopologie sorgfältig prüfen und -MaxNetworkOptimization nur dann auf 1 festlegen, wenn der Netzwerkverkehr durch irrelevante Löschungen inakzeptabel hoch ist.

Sie können diesen Parameter zum Profil des Snapshot-Agents hinzufügen, indem Sie die Systemprozedur sp_add_agent_parameter wie folgt ausführen:

EXEC sp_add_agent_parameter 1, 'MaxNetworkOptimization', 1

5.3.11 Verwendung einer neuen Rolle bei der Mergereplikation

Eingeführt in SP3

Mit SP3 und höher wird automatisch eine neue Rolle zur Verwendung durch die Mergereplikation erstellt. Der Name der neuen Rolle hat das Format Msmerge-<publication ID>. Die Rolle wird für jede Mergereplikationspublikation auf dem Verleger erstellt und dient als Publikationszugriffsliste zum Steuern des Zugriffs auf Mergepublikationen auf dem Verleger. Wenn diese Rolle gelöscht wird, können Sie die in SP3 und höher enthaltene, neue gespeicherte Prozedur sp_createmergepalrole ausführen, um die Rolle neu zu erstellen. Diese gespeicherte Prozedur wird auf dem Verleger für die Publikationsdatenbank ausgeführt, um die Rolle neu zu erstellen.

Syntax

sp_createmergepalrole [ @publication = ] 'publication'

Argumente

[@publication = ] 'publication'

Der Name der Publikation. publication ist vom Datentyp sysname und hat keinen Standard. Dieser Parameter wird verwendet, um die bei der Neuerstellung einer Rolle durch die Mergepublikation zu verwendende Publikation auszuwählen.

Rückgabecodewerte

0 (Erfolg) oder 1 (Fehler)

Hinweise

Beim Ausführen von sp_createmergepalrole wird zur sysusers-Tabelle für die neue Rolle eine neue Zeile hinzugefügt. Der Name dieser neuen Rolle basiert auf dem Wert der pubid-Spalte in der sysmergepublications-Tabelle für den gegebenen Wert von publication. Das Präfix des Rollennamens lautet MSMerge_, und der pubid-Wert wird (ohne Bindestriche) an den Rollennamen angefügt.

Berechtigungen

Nur Mitglieder der festen Serverrolle sysadmin oder der festen Datenbankrolle db_owner können sp_createmergepalrole ausführen.

5.3.12 Neue Anforderungen für Abonnements, die nicht von Systemadministratoren erstellt wurden

Eingeführt in SP3

Wenn ein Abonnement von einem Benutzer erstellt wird, der kein Mitglied der festen Serverrolle sysadmin ist, müssen Sie eine der folgenden Aktionen ausführen:

Anmerkung  Für die Funktion zum Aktivieren des Remote-Agents ist es erforderlich, dass der Auftragsschritt im Kontext eines Benutzerkontos in der festen Serverrolle sysadmin ausgeführt wird.

5.3.13 Berechtigungsänderungen für gespeicherte Prozeduren

Eingeführt in SP3

Für eine Reihe von gespeicherten Prozeduren, die zum Implementieren, Verwalten und Überwachen einer Replikationstopologie verwendet werden, wurden Berechtigungen geändert. Die meisten dieser Änderungen bewirken, dass umfassendere Berechtigungen zum Ausführen der gespeicherten Prozeduren erforderlich sind. Weitere Informationen zu den neuen Berechtigungen finden Sie in der Transact-SQL-Referenz für gespeicherte Replikationsprozeduren in der aktualisierten Version der SQL Server-Onlinedokumentation. Weitere Informationen zur aktualisierten SQL Server-Onlinedokumentation finden Sie in Abschnitt 1.6, Verfügbare aktualisierte Onlinedokumentation.

5.3.14 Neuer Parameter für "sp_addmergearticle" und "sp_changemergearticle"

Eingeführt in SP3

Der neue @published_in_tran_pub-Parameter wurde sowohl zu sp_addmergearticle als auch zu sp_changemergearticle hinzugefügt. Mit diesem Parameter wird angezeigt, dass ein Artikel in einer Mergepublikation auch in einer Transaktionspublikation veröffentlicht wird. @published_in_tran_pub ist vom Dateityp nvarchar(5), der Standard ist False. Mit True wird angegeben, dass der Artikel auch in einer Transaktionspublikation veröffentlicht wird.

Anmerkung  Wenn dieser Parameter in sp_changemergearticle geändert wird, muss der Snapshot für ungültig erklärt und Abonnenten müssen erneut initialisiert werden.

5.3.15 Neue Seite des Publizierungs- und Verteilungskonfigurations-Assistenten

Eingeführt in SP3

Der Publizierungs- und Verteilungskonfigurations-Assistent enthält nun eine neue Seite: Verteilerkennwort. Sie müssen auf dieser Seite ein Kennwort eingeben, wenn Sie einen oder mehrere Verleger für die Verwendung des Servers als Remoteverteiler auswählen und mindestens einer dieser Verleger ein Kennwort benötigt. Die Verbindung zwischen einem Verleger und einem Remoteverteiler ist eine Mischung aus einer Verbindungsserver- und einer Remoteserververbindung. Für die Verbindung wird der Benutzername distributor_admin verwendet. Die Konfiguration des Remoteverteilers besagt standardmäßig, dass der Verleger nicht vertraut ist, so dass ein Kennwort erforderlich ist.

Anmerkung  Wenn Sie die SQL Server 2000-Onlinedokumentation (aktualisiert – SP3) gedownloadet und installiert haben, sind diese Informationen über die Hilfeschaltfläche für die neue Seite verfügbar.

5.3.16 Änderungen bei der Unterstützung der Synchronisierungsverwaltung von Windows

Eingeführt in SP3

In SQL Server können Sie vorhandene Abonnements (die mithilfe von SQL Server Enterprise Manager, SQL-DMO und gespeicherten Replikationsprozeduren erstellt wurden) für die Verwendung mit der Synchronisierungsverwaltung von Windows aktivieren. Mithilfe der Synchronisierungsverwaltung von Windows können Sie auch neue Abonnements erstellen. Nach dem Anwenden des Service Packs werden Sie bei der Synchronisierung eines Abonnements von der Synchronisierungsverwaltung von Windows aufgefordert, das Kennwort oder die Kennwörter einzugeben, die erforderlich sind, um zu den an der Synchronisierung beteiligten Servern eine Verbindung herzustellen.

5.3.17 Anforderungsänderungen für das Anfügen oder Wiederherstellen einer Replikationsdatenbank

Eingeführt in SP3

Unter bestimmten Bedingungen kann die Replikation beim Anfügen oder Wiederherstellen einer publizierten Datenbank fehlschlagen. Dies sind die folgenden Bedingungen:

Wenn alle Bedingungen erfüllt sind, sollten Sie die gespeicherte Prozedur sp_changedbowner für die angefügte oder wiederhergestellte Datenbank ausführen. Legen Sie als Besitzer den integrierten Administratorbenutzernamen sa fest. Damit wird eine ordnungemäße Funktion der Replikation sichergestellt.

Anmerkung  Sie müssen Mitglied der festen Serverrolle sysadmin sein, um sp_changedbowner auszuführen.

Weitere Informationen zur datenbankübergreifenden Besitzverkettung finden Sie in Abschnitt 5.1.11, Datenbankübergreifende Besitzverkettung.

5.4 Erweiterungen beim SQL Server-Agent

In diesem Abschnitt werden die in SP3a enthaltenen Erweiterungen beim SQL Server-Agent beschrieben.

5.4.1 Protokollierung von Kontoinformationen durch den SQL Server-Agent

Eingeführt in SP2

Im Auftragsverlauf des SQL Server-Agents wird nun das Windows-Konto aufgezeichnet, mit dem der jeweilige Auftragsschritt ausgeführt wird. Mit diesen Informationen können Administratoren Sicherheitsprobleme bei geplanten Aufträgen diagnostizieren, einschließlich geplanter Aufträge, die für die Replikation definiert sind, und DTS-Tasks (Data Transformation Services).

5.4.2 Änderungen an der Konfiguration von Master-/Zielservern

Eingeführt in SP3

Bei der Multiserveradministration werden Verwaltungsaufgaben über mehrere SQL Server-Instanzen hinweg automatisiert. Verwenden Sie die Multiserveradministration, wenn Sie zwei oder mehr Server verwalten und die Verwaltungsaufgaben zentralisieren möchten.

Bei SP3a muss das Konto des SQL Server-Agent-Dienstes nur dann ein Windows-Administratorkonto sein, wenn das Proxykonto des SQL Server-Agents verwendet werden muss. Weitere Informationen zum Proxykonto des SQL Server-Agents finden Sie in Abschnitt 5.7.3, Verbesserungen beim SQL Server-Agent-Proxykonto. Das Konto des SQL Server-Agent-Dienstes muss Mitglied der festen Serverrolle sysadmin sein.

Für die Multiserveradministration benötigen Sie mindestens einen Masterserver und mindestens einen Zielserver. Ein Masterserver verteilt Aufträge an die Zielserver und empfängt Ereignisse von ihnen. Auf dem Masterserver ist die zentrale Kopie der Auftragsdefinitionen für Aufträge gespeichert, die auf Zielservern ausgeführt werden. Zielserver stellen in regelmäßigen Abständen Verbindungen mit dem Masterserver her, um die Liste der auszuführenden Aufträge zu aktualisieren. Wenn ein neuer Auftrag vorhanden ist, downloadet der Zielserver den Auftrag und trennt dann die Verbindung mit dem Masterserver. Nach dem Beenden des Auftrags stellt der Zielserver erneut eine Verbindung mit dem Masterserver her und berichtet den Status des Auftrags.

Vor dem Anwenden von SP3a müssen Sie mehrere Schritte durchführen, um die Konfiguration der Master-/Zielserver mit SQL Server 2000 zu aktualisieren. Die mit SP3a eingeführten Änderungen sind mit Zielservern mit SQL Server 7.0 oder mit Servern ohne SP3a nicht kompatibel. Dies ist ein Unterschied zur ursprünglichen SQL Server 2000-Funktionalität.

So aktualisieren Sie die Konfiguration von Master-/Zielservern

  1. Erstellen Sie ein neues Masterserverkonto (MSX-Konto) auf Ihrem Masterserver. Damit werden die Zielserver (TSX-Server) für die Aktualisierung vorbereitet. Führen Sie dazu die folgenden Befehle aus. 
    --Option A: Windows authentication
EXEC sp_grantlogin 'DOMAIN\user'
GO
USE msdb
GO
EXEC sp_adduser 'DOMAIN\user', 'DOMAIN\user', 'TargetServersRole'
GO

--Option B: SQL Server authentication – see explanation below for 
--details.
EXEC sp_addlogin <MSXAccount>, <MSXAccountPassword>, 'msdb' 
GO
USE msdb
GO
EXEC sp_adduser <MSXAccount>, <MSXAccount>, 'TargetServersRole'
GO

    Dabei steht <MSXAccount> für den von Ihnen gewählten SQL-Benutzernamen und <MSXAccountPassword> für das zugehörige Kennwort.

    Anmerkung  Diese Werte müssen in einfache Anführungszeichen eingeschlossen werden.

Bei der Auswahl eines MSX-Kontos haben Sie die folgenden Möglichkeiten:

Geben Sie kein SQL Server-Agent-Untersuchungskonto (<computer_name>_msx_probe_login) an. SQL Server entfernt im Rahmen der Aktualisierung auf SP3 oder höher die alten Untersuchungskonten, da diese von den TSX-Servern nicht mehr verwendet werden.

  1. Aktualisieren Sie die TSX-Server nacheinander auf SP3a. (Lesen Sie vor dem Anwenden des Service Packs Schritt 3. Dort finden Sie Informationen zur zeitlichen Planung der Aktualisierung.)

  2. Um Ausfallzeiten zu minimieren, führen Sie auf jedem TSX-Server sofort nach Abschluss der SP3a-Aktualisierung die erweiterte gespeicherte Prozedur xp_sqlagent_msx_account aus.

    Anmerkung  Nach dem Ausführen von xp_sqlagent_msx_account muss der SQL-Agent auf jedem Server beendet und neu gestartet werden.

    Weitere Informationen zu xp_sqlagent_msx_account finden Sie in Abschnitt 5.4.3, Neue erweiterte gespeicherte Prozedur für den SQL Server-Agent.

  3. Wenden Sie SP3a auf dem Masterserver an. Die alten _msx_probe-Konten werden beim Installieren von SP3a gelöscht, da sie von den TSX-Servern nicht mehr verwendet werden. Wenn ein Konto SQL-Agent-Aufträge besitzt, wird das Konto nicht entfernt. In diesem Fall müssen Sie den Besitz der Aufträge an einen anderen Benutzer übertragen und diese Konten manuell entfernen. Wenn Sie die alten _msx_probe-Konten, die SQL-Agent-Aufträge besitzen, weiterhin verwenden möchten, müssen Sie möglicherweise das Kennwort des _msx_probe-Kontos ändern.

5.4.3 Neue erweiterte gespeicherte Prozedur für den SQL Server-Agent

Eingeführt in SP3

SP3a enthält eine neue erweiterte gespeicherte Prozedur, die es Ihnen ermöglicht, das Konto zu konfigurieren, das vom TSX-Server mit dem SQL Server-Agent zum Downloaden von Anweisungen von einem MSX-Server verwendet wird. Dieses Konto wird auch als MSX-Konto oder Masterserverkonto bezeichnet.

xp_sqlagent_msx_account

Die erweiterte gespeicherte Prozedur xp_sqlagent_msx_account legt den Benutzernamen und das Kennwort für das MSX-Konto des SQL Server-Agents in den LSA-Schlüsseln auf dem TSX-Server fest oder ruft sie von dort ab. Nur Mitglieder der festen Serverrolle securityadmin können diese erweiterte gespeicherte Prozedur ausführen.

Damit Sie diese erweiterte gespeicherte Prozedur ausführen können, muss der SQL Server-Agent ausgeführt werden. Wenn es sich bei dem angegebenen Konto um einen SQL Server-Benutzernamen handelt, muss der SQL Server-Agent außerdem über lokale Windows-Administratorrechte verfügen. Der SQL Server-Agent speichert den Benutzernamen und das Kennwort als LSA-Schlüssel, und der Zugriff ist auf lokale Windows-Administratoren beschränkt.

Syntax

xp_sqlagent_msx_account

    {N'GET' |

    N'SET' | N'DEL', N'MSX_domain_name', N'MSX_username', N'MSX_password'

    }

Argumente

N'GET'

Ruft das aktuelle MSX-Konto des SQL Server-Agents ab. N'GET' ist vom Datentyp nvarchar und hat keinen Standard. Das Kennwort wird aus Sicherheitsgründen nicht berichtet.

N'SET'

Legt das MSX-Konto des SQL Server-Agents fest. Verwenden Sie die Parameter MSX_username und MSX_password zum Angeben des Kontos, das als MSX-Konto des SQL Server-Agents verwendet werden soll. N'SET' ist vom Datentyp nvarchar und hat keinen Standard.

N'DEL'

Löscht das MSX-Konto des SQL Server-Agents.

'MSX_domain_name'

Reserviert für zukünftige Verwendung.

'MSX_username'

Der Name des Windows-Kontos, das als MSX-Konto des SQL Server-Agents verwendet werden soll. Geben Sie für diesen Parameter und für MSX_password leere Zeichenfolgen an, wenn Sie die Windows-Sicherheit auswählen möchten. In diesem Fall werden die Kontoanmeldeinformationen des SQL Server-Agent-Dienstes zum Anmelden am MSX-Server verwendet. MSX_username ist vom Datentyp nvarchar und hat keinen Standard.

'MSX_password'

Das Kennwort für das SQL Server-Konto, das mit MSX_username angegeben wird. Geben Sie für diesen Parameter und für MSX_username leere Zeichenfolgen an, wenn Sie die Windows-Sicherheit auswählen möchten. In diesem Fall werden die Kontoanmeldeinformationen des SQL Server-Agent-Dienstes zum Anmelden am MSX-Server verwendet. MSX_password ist vom Datentyp nvarchar und hat keinen Standard.

Anmerkung  Parameter für xp_sqlagent_msx_account müssen in der richtigen Reihenfolge angegeben werden. Es dürfen keine benannten Parameter verwendet werden.

Rückgabecodewerte

Gibt bei Erfolg den Wert 0 oder bei Fehler 1 zurück.

Wenn xp_sqlagent_msx_account fehlschlägt und den Wert 1 zurückgibt, generiert SQL Server eine Fehlermeldung mit Informationen zum Fehler.

Resultsets

Wenn ein MSX-Konto für den SQL Server-Agent festgelegt wurde, gibt xp_sqlagent_msx_account bei Angabe von N'GET' ein Resultset mit den folgenden Informationen zurück.

Spalte Datentyp Beschreibung
domain sysname N/V. Reserviert für zukünftige Verwendung.
username sysname Konto, das als MSX-Konto des SQL Server-Agents verwendet wird.

Wenn kein MSX-Konto für den SQL Server-Agent festgelegt wurde oder wenn N'SET' angegeben wurde, wird kein Resultset zurückgegeben.

Berechtigungen

Berechtigungen zum Ausführen von xp_sqlagent_msx_account erhalten standardmäßig die Mitglieder der festen Serverrolle securityadmin.

Beispiele
  1. Abrufen des aktuell zugewiesenen MSX-Kontos des SQL Server-Agents

Im folgenden Beispiel wird das Konto abgerufen, das aktuell als MSX-Konto des SQL Server-Agents zugewiesen ist:

EXEC master.dbo.xp_sqlagent_msx_account N'GET'
  1. Festlegen der Windows-Authentifizierung für das MSX-Konto des SQL Server-Agents

Im folgenden Beispiel wird festgelegt, dass für das MSX-Konto des SQL Server-Agents die Windows-Authentifizierung verwendet werden soll:

EXEC master.dbo.xp_sqlagent_msx_account N'SET',
   N'',  -- Reserved for future use 
   N'',  -- MSX_username
   N''  -- MSX_password
C. Festlegen der SQL Server-Authentifizierung für das MSX-Konto des SQL Server-Agents

Im folgenden Beispiel wird das Konto Ralph als MSX-Konto des SQL Server-Agents festgelegt und ein Kennwort angegeben:

EXEC master.dbo.xp_sqlagent_msx_account N'SET',
   N'',  -- Reserved for future use 
   N'Ralph',  -- MSX_username
   N'RalphPwd'  -- MSX_password
D. Löschen des MSX-Kontos des SQL Server-Agents

Im folgenden Beispiel wird das MSX-Konto des SQL Server-Agents gelöscht. Das bedeutet, dass für den SQL Server-Agent standardmäßig die integrierte Sicherheitsauthentifizierung von Windows verwendet wird.

EXEC master.dbo.xp_sqlagent_msx_account N'DEL'

5.4.4 Berechtigungsüberprüfungen beim SQL Server-Agent

Eingeführt in SP3

SQL Server überprüft jetzt, ob der Besitzer des Agent-Auftrags über die Berechtigung verfügt, Daten der einzelnen Aufträge an die Ausgabeprotokolldatei anzufügen oder diese zu überschreiben. Dies geschieht auf drei Arten:

In allen Fällen werden die Aufträge mit den Anmeldeinformationen des SQL Server-Agents geschrieben. In SQL Server wird jedoch jetzt mit diesem Testverfahren sichergestellt, dass der Benutzer über die Schreibberechtigungen für den ausgewählten Speicherort der Protokolldatei für die Auftragsausgabe auf dem Server verfügt. Im Auftragsverlauf werden Fehler angezeigt, aber die Auftragsschritte schlagen nicht fehl, wenn die Protokolldatei nicht geschrieben werden kann.

5.4.5 MAPI-Profile für SQL Agent Mail

Eingeführt in SP3

In der 32-Bit-Version von SQL Server 2000 kann SQL Agent Mail so konfiguriert werden, dass ein E-Mail-Profil von Extended MAPI zum Senden von E-Mail-Warnungen verwendet wird. Sie können eine E-Mail-Anwendung mit Extended MAPI, wie Microsoft Outlook, zum Erstellen eines Extended MAPI-Profils verwenden. In der 64-Bit-Version von SQL Server 2000 kann SQL Agent Mail nur Simple MAPI-Profile zum Senden von E-Mail-Warnungen verwenden. Verwenden Sie in der 32-Bit-Version von SQL Server 2000 keine Simple MAPI-Profile.

5.5 Verbesserungen bei den Konnektivitätskomponenten von SQL Server

In diesem Abschnitt werden die in SP3a enthaltenen Verbesserungen bei den Konnektivitätskomponenten von SQL Server 2000 beschrieben.

5.5.1 Aktualisierungen von Microsoft Data Access Components

Eingeführt in SP3a

SP3a enthält Aktualisierungen für Microsoft Data Access Components (MDAC). Beim Installieren von SP3a wird auch MDAC 2.7 Service Pack 1a installiert. MDAC 2.7 SP1a weist gegenüber der Version von MDAC, die mit SQL Server 2000 installiert wird (MDAC 2.6), keine Funktionsänderungen auf, enthält aber Problembehebungen und Verbesserungen hinsichtlich der Sicherheit. MDAC 2.7 SP1a enthält eine Aktualisierung von MSXML 3 SP3.

Anmerkung  Diese Version von MDAC wird nicht installiert, wenn das Setup-Programm die gleiche oder eine neuere Version erkennt.

Weitere Informationen zu dieser Version von MDAC finden Sie auf der Microsoft Universal Data Access-Website unter www.microsoft.com. Die in dieser Version von MDAC enthaltenen Problembehebungen sind im Knowledge Base-Artikel 326848 dokumentiert. Sie finden diesen Artikel in der Knowledge Base von Microsoft Support Services.

5.5.2 Unterstützung für QLogic Virtual Interface Architecture

Eingeführt in SP3

SQL Server unterstützt nun VIA-SAN-Implementierungen (Virtual Interface Architecture System Area Network) von QLogic. Zum Aktivieren der SQL Server-Unterstützung für Verbindungen über QLogic VIA muss sowohl der Client- als auch der Servercomputer eine IP-Adressauflösung in der Datei Vihosts im entsprechenden Windows-Ordner system32\drivers\etc bereitstellen.

Die Datei Vihosts muss folgendes Format aufweisen:

<VI IP Address of server computer> <SERVER_COMPUTERNAME>

<VI IP Address of client computer> <CLIENT_COMPUTERNAME>

Beispiel:

139.4.130.1  SQLCOMPUTER

139.4.130.2  SQLCLIENT

Verwenden Sie IP-Adressen der jeweiligen QLogic VIA-Netzwerkkarten und tatsächliche Computernamen. Andernfalls können keine Verbindungen zu benannten Instanzen oder über andere IP-Protokolle, wie TCP oder Named Pipes, hergestellt werden. Die Datei Vihosts ist für die Giganet VIA-Konnektivität nicht erforderlich.

Anmerkung  Auf Clientcomputern müssen Sie mithilfe von SQL Server-Clientkonfiguration den richtigen VIA-Hersteller identifizieren. Wählen Sie den entsprechenden Wert in der Dropdownliste Hersteller aus. Die entsprechende Aktion sollte mithilfe von SQL Server-Netzwerkkonfiguration auch auf Servercomputern durchgeführt werden.

5.6 Verbesserungen bei Meta Data Services

In diesem Abschnitt werden die in SP3a enthaltenen Erweiterungen für Meta Data Services in SQL Server 2000 beschrieben.

5.6.1 Exportieren in Unicode mit Meta Data-Browser

Eingeführt in SP1

Meta Data-Browser exportiert XML-basierte Metadaten jetzt in Unicode. In Versionen vor SQL Server 2000 SP1 exportiert der Browser ANSI-Code, der jedoch keine Zeichen außerhalb des lateinischen Grundalphabets unterstützt. Diese Funktionalitätsänderung ist für den Benutzer nicht sichtbar. Mit dieser SP3a-Version werden exportierte Daten immer in Unicode codiert. Sie können Daten jedoch in ANSI-Code exportieren, indem Sie den Wert des Registrierungsschlüssels HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Repository\Engine\XMLExport auf 0 festlegen. In der folgenden Liste sind die Werte aufgeführt, die Sie für diesen Registrierungsschlüssel festlegen können:

Weitere Informationen zu den einzelnen Flags finden Sie unter "IExport::Export Method" in der SQL Server-Onlinedokumentation.

5.6.2 Deaktivierte Skripterstellungsunterstützung

Eingeführt in SP3

Die Skriptunterstützung in Informationsmodellen wurde deaktiviert. Nach dem Installieren von SP3a wird folgende Fehlermeldung angezeigt, wenn die Anwendung auf eine Eigenschaft oder Methode zugreift, für die ein Skript definiert ist: 

EREP_SCRIPTS_NOTENABLED

So aktivieren Sie die Skriptunterstützung

Wenn Sie weiterhin Skripts ausführen möchten, können Sie mithilfe des folgenden Verfahrens eine Registrierungseinstellung erstellen, mit der die Skriptunterstützung aktiviert wird.

  1. Öffnen Sie den Registrierungs-Editor, und wechseln Sie zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.

  2. Erstellen Sie den Registrierungsschlüssel Repository (wenn dieser nicht bereits vorhanden ist), und erstellen Sie anschließend den Unterschlüssel Engine, so dass der Pfad Repository\Engine lautet.

  3. Fügen Sie im Registrierungsschlüssel Engine den neuen DWORD-Wert AllowScripting hinzu, und legen Sie den Wert auf 1 fest.

Wenn Sie die Skripterstellung zu einem späteren Zeitpunkt deaktivieren möchten, legen Sie den Wert für diesen neuen Registrierungsschlüssel auf 0 fest.

Wichtig  Sie sollten Informationsmodelle und die Repository-Datenbank immer sichern, um unbefugten Zugriff zu verhindern.

5.6.3 Neue RepositoryUser-Rolle zum Zugreifen auf Repository-Informationen

Eingeführt in SP3

Die msdb-Datenbank von SQL Server enthält eine Gruppe von Tabellen, gespeicherten Prozeduren und Sichten, in denen Informationen zur Verwendung durch das Meta Data Services-Repository-Modul gespeichert sind. In SP3 wurde die neue dedizierte RepositoryUser-Rolle hinzugefügt. Diese muss für den Zugriff auf und zum Aktualisieren von Repository-Informationen verwendet werden. Dieser Rolle wurden die Berechtigungen zum Erstellen, Lesen, Aktualisieren, Löschen und Ausführen dieser Objekte erteilt. Die public-Rolle hat keine Berechtigungen mehr für diese Objekte.

Diese Änderung hat Auswirkungen auf vorhandene Repository-Objekte sowie alle weiteren Objekte, die künftig vom Repository-Modul erstellt werden. Benutzer und Anwendungen, die auf das Repository über die public-Rolle zugreifen, müssen zur RepositoryUser-Rolle hinzugefügt werden.

5.7 Verbesserungen bei Data Transformation Services

In diesem Abschnitt werden die in SP3a enthaltenen Erweiterungen für Data Transformation Services in SQL Server 2000 beschrieben.

5.7.1 Wegfallende Einschränkung von Zeichenfolgenspalten auf 255 Zeichen beim DTS-Assistenten

Eingeführt in SP2

Beim Exportieren von Daten in eine Textdatei konfiguriert der DTS-Import/Export-Assistent das Paket nun so, dass bis zu 8.000 Zeichen jeder Spalte mit Zeichenfolgendaten geschrieben werden.

5.7.2 Protokollierung des Sicherheitskontextes bei DTS-Paketausführung durch den SQL Server-Agent

Eingeführt in SP2

Der SQL Server-Agent zeichnet den Sicherheitskontext auf, in dem jeder Schritt eines Auftrags ausgeführt wird. In SP3 und höher wird der Sicherheitskontext im Dialogfeld Auftragsverlauf angezeigt. Wenn Sie ein DTS-Paket von einem Auftragsschritt aus ausführen, protokolliert der SQL Server-Agent das Benutzerkonto, mit dem das Paket ausgeführt wird. Diese Informationen können von Administratoren verwendet werden, um Probleme bei Berechtigungen und bei der Authentifizierung zu diagnostizieren, die bei geplanter Ausführung von DTS-Paketen auf einem Server auftreten.

5.7.3 Verbesserungen beim SQL Server-Agent-Proxykonto

Eingeführt in SP2

Vor SP2 konnten auf dem Server gespeicherte DTS-Pakete nur dann mit den Anmeldeinformationen des SQL Server-Agent-Proxykontos ausgeführt werden, wenn das Proxykonto über Zugriff auf den Temp-Benutzerordner für das Konto verfügte, mit dem der Server (bei Aufträgen, die von xp_cmdshell aus ausgeführt wurden) bzw. der Agent (im Fall von Agent-Aufträgen) ausgeführt wurde. Daher mussten Benutzer oft die TEMP-Umgebungsvariable für das Startkonto von SQL Server oder dem SQL Server-Agent so anpassen, dass sie auf ein Verzeichnis zeigte, auf das das Startkonto und das Proxykonto Zugriff hatten, wie C:\Temp. Mit SP2 und höher wird DTS so erweitert, dass DTS den Temp-Ordner des Systems verwendet, wenn der Temp-Benutzerordner nicht verfügbar ist. Damit wird die Notwendigkeit, derartige Anpassungen vorzunehmen, stark verringert.

5.7.4 Standardmäßig deaktiviertes Speichern in Meta Data Services

Eingeführt in SP3

Mit SP3 und höher ist standardmäßig die Option zum Speichern von DTS-Paketen in Meta Data Services deaktiviert. Das bedeutet, dass die Option Meta Data Services im Dialogfeld DTS-Paket speichern in der Dropdownliste Speicherort nicht angezeigt wird. Darüber hinaus ist diese Option auf der Seite Paket speichern, Ausführungstermin planen und replizieren im DTS-Import/Export-Assistenten deaktiviert.

So ermöglichen Sie das Speichern von Paketen in Meta Data Services

Wenn die Option zum Speichern von Paketen in Meta Data Services deaktiviert ist, können Sie vorhandene Pakete von Meta Data Services laden, bearbeiten und mithilfe der Option Speichern in Meta Data Services speichern. Meta Data Services steht jedoch über die Option Speichern unter nicht zur Verfügung. So können Sie beispielsweise ein Paket nicht unter einem anderen Namen in Meta Data Services neu speichern.

5.8 XML-Erweiterungen

Im folgenden Thema wird eine Erweiterung für XML und SQLXML in SP3a beschrieben.

5.8.1 Verbesserte Überprüfung von XPath-Ausdrücken

Eingeführt in SP3

Bei der Version von MSXML, die mit SQL Server 2000 vor SP3 installiert wurde (MSXML 2.6), konnte ein Prädikat in einem XPath-Ausdruck auf das spezielle Abkürzungszeichen folgen, das den aktuellen Kontextknoten identifiziert. Dieser wird in der XPath-Syntax durch einen Punkt (.) gekennzeichnet. Dies verletzt die XPath-Syntaxspezifikation, nach der auf dieses Zeichen ein Positionspfadausdruck folgen muss.

Beim Anwenden von SP3 oder höher wird eine aktualisierte Version von MSXML (MSXML 3.0 SP3) im Rahmen der MDAC-Aktualisierung installiert. Weitere Informationen finden Sie in Abschnitt 5.5.1, Aktualisierungen von Microsoft Data Access Components.

Bei der neuen Version von MSXML darf auf das spezielle Abkürzungszeichen für den aktuellen Kontextknoten nicht direkt ein Prädikat folgen. XPath-Ausdrücke in SQLXML-Abfragen (XPath-Abfragen für Zuordnungsschemas mit Anmerkungen und in XSLT-Stylesheets, mit denen das Ergebnis von SQLXML-Abfragen transformiert wird), die die fehlerhafte Syntax enthalten, schlagen nach der Aktualisierung auf SP3 oder höher fehl.

Um diese Fehler zu vermeiden, müssen Sie jeden Ausdruck, der die falsche Syntax enthält, identifizieren und korrigieren. Die Syntax des XPath-Ausdrucks, der im folgenden xsl:if-Element als Wert des Testattributs angegeben ist, ist beispielsweise ungültig, da auf das spezielle Abkürzungszeichen, das den aktuellen Kontextknoten identifiziert, das Prädikat [@ResourceTypeID='2'] direkt folgt.

Die folgende Anweisung, die zuvor keinen Fehler generierte, schlägt nach der Installation von SP3 oder höher fehl. 

<xsl:if test=".[@ResourceTypeID='2']">

Um Fehler zu verhindern, muss der XPath-Ausdruck wie folgt verändert werden:

<xsl:if test="@ResourceTypeID='2'">

5.9 Erweiterungen der API für das virtuelle Sicherungsmedium

Das folgende Thema gilt für die API (Application Programming Interface, Schnittstelle für Anwendungsprogrammierung) für das virtuelle Sicherungsmedium von SQL Server 2000.

5.9.1 Aufzeichnen mehrerer Datenbanken in einem einzelnen Snapshot

Eingeführt in SP2

Die API für das virtuelle Sicherungsmedium (Virtual Backup Device API) ermöglicht unabhängigen Softwareanbietern (Independent Software Vendors, ISVs) das Integrieren von SQL Server 2000 in ihre Produkte. Die API ist so entworfen, dass sie hohe Verlässlichkeit und Leistung bietet. Sie unterstützt die Funktionalität zum Sichern und Wiederherstellen von SQL Server 2000 vollständig, darunter die gesamte Palette von Sicherungsmöglichkeiten im laufenden Betrieb und durch Snapshots.

In SP1 und früher gab es keine Möglichkeit, mehrere Datenbanken gleichzeitig zu fixieren und zu sichern. In SP3 und höher wird die serverseitige Unterstützung für das Fixieren und Aufzeichnen mehrerer Datenbanken in einem einzelnen Snapshot mithilfe des Befehls VDC_PrepareToFreeze zur Verfügung gestellt.

Die Spezifikation für das virtuelle Sicherungsmedium in SP3a enthält aktualisierte Informationen zum Befehl VDC_PrepareToFreeze. Eine aktualisierte Version der Headerdatei vdi.h für die Schnittstelle für das virtuelle Medium (Virtual Device Interface) finden Sie im Unterverzeichnis \Devtools\Include im SP3a-Installationsverzeichnis.

Sie können die aktualisierte Spezifikation aus dem Downloadcenter von Microsoft auf der Downloadwebsite für Microsoft SQL Server downloaden.

5.10 Fehlerberichte

Eingeführt in SP3

Fehlerberichte sind in Microsoft SQL Server standardmäßig deaktiviert. Sie können diese Funktion während der Installation über das Setup-Programm von SQL Server oder über das Setup-Programm von Analysis Services oder nach der Installation über das Dialogfeld Servereigenschaften in Enterprise Manager oder über das Dialogfeld Servereigenschaften im Analysis-Manager aktivieren. Wenn Sie die Fehlerberichtsfunktion beim Ausführen des Setup-Programms von SQL Server aktivieren, können Fehlerberichte für das SQL Server-Datenbankmodul und für den SQL Server-Agent erstellt werden. Wenn Sie die Fehlerberichtsfunktion beim Ausführen des Setup-Programms von Analysis Services aktivieren, können Fehlerberichte für Analysis Services erstellt werden. Wenn Sie die Fehlerberichtsfunktion sowohl für SQL Server als auch für Analysis Services aktivieren möchten, müssen Sie die Fehlerberichtsfunktion für SQL Server beim Ausführen des Setup-Programms von SQL Server und für Analysis Services beim Ausführen des Setup-Programms von Analysis Services aktivieren.

Wenn Sie diese Funktion aktivieren, wird SQL Server so konfiguriert, dass beim Auftreten eines schwerwiegenden Fehlers im SQL Server-Datenbankmodul, im SQL Server-Agent oder in SQL Server Analysis Services automatisch ein Bericht an Microsoft gesendet wird. Microsoft verwendet Fehlerberichte, um die SQL Server-Funktionalität zu verbessern, und behandelt alle Informationen vertraulich.

Informationen zu Fehlern werden über eine sichere Verbindung (HTTPS) an Microsoft gesendet und dort mit eingeschränktem Zugriff gespeichert. Alternativ dazu können Sie diese Informationen auch an Ihren Firmen-Fehlerberichtsserver senden. Weitere Informationen zum Einrichten eines Firmen-Fehlerberichtsservers finden Sie auf der Microsoft-Website.

Der Fehlerbericht enthält die folgenden Informationen:

Microsoft verfolgt nicht die Absicht, Dateien, Namen, Adresse, E-Mail-Adresse oder andere persönliche Daten von Ihnen zu sammeln. Der Fehlerbericht kann jedoch benutzerspezifische Daten aus dem Arbeitsspeicher oder aus Dateien des Prozesses enthalten, der den Fehler verursacht hat. Mithilfe dieser Daten ist es möglich, Ihre Identität zu ermitteln. Microsoft verwendet diese Daten jedoch nicht zu diesem Zweck.

Die Richtlinie von Microsoft zum Sammeln von Fehlerberichtsdaten finden Sie auf der Microsoft-Website.

Wenn Sie die Fehlerberichtsfunktion aktivieren und ein schwerwiegender Fehler auftritt, wird möglicherweise eine Antwort von Microsoft im Windows-Ereignisprotokoll aufgezeichnet, die auf einen Microsoft Knowledge Base-Artikel zum entsprechenden Fehler verweist. Eine Antwort kann folgendermaßen aussehen:

Source = MSSQLServerOlapServicesDW 
EventID = 1010
data = http://support.microsoft.com/support/misc/kblookup.asp?id=Q123456
&iBucketTable=1&iBucket=39980&Cab=21474432.cab&LCID=1033
&OS=5.1.2600.2.00010100.0.0

Wechseln Sie zum Deaktivieren der Fehlerberichtsfunktion für das SQL Server-Datenbankmodul und den SQL Server-Agent in Enterprise Manager zu SQL Server-Eigenschaften (Registerkarte Allgemein), und deaktivieren Sie das Kontrollkästchen Fehlerberichtsfunktion aktivieren. Wechseln Sie zum Deaktivieren der Fehlerberichtsfunktion für Analysis Services im Analysis-Manager zu Servereigenschaften, und deaktivieren Sie das Kontrollkästchen Fehlerberichtsfunktion aktivieren. Sind Fehlerberichte sowohl für SQL Server (Datenbankmodul und SQL Server-Agent) als auch für Analysis Services aktiviert, müssen Sie Fehlerberichte für SQL Server und Analysis Services einzeln deaktivieren.

5.11 Erweiterungen bei English Query

Eingeführt in SP1

Microsoft hat eine Sicherheitserweiterung für English Query-Anwendungen herausgegeben. Diese Erweiterung wird nicht als Teil des Service Packs installiert. Es empfiehlt sich jedoch, sie anzuwenden, falls Sie English Query verwenden. Die Sicherheitserweiterung befindet sich auf der SP3a-CD-ROM im Ordner \EQHotfix. Details zur English Query-Erweiterung finden Sie in der Knowledge Base von Microsoft Support Services. Suchen Sie in der Knowledge Base nach Artikel 297105.

5.12 DB-Library und Embedded SQL für C

Eingeführt in SP1

Die APIs (Application Programming Interfaces, Schnittstellen für Anwendungsprogrammierung) DB-Library und Embedded SQL für C werden in SQL Server 2000 zwar noch unterstützt, aber alle zukünftigen SQL Server-Versionen werden die Dateien nicht mehr enthalten, die zum Programmieren von Anwendungen mit diesen APIs erforderlich sind. Verbindungen von vorhandenen Anwendungen, die DB-Library und Embedded SQL für C verwenden, werden in der nächsten SQL Server-Version noch unterstützt, aber diese Unterstützung wird in späteren Versionen nicht mehr vorhanden sein. Vermeiden Sie diese Komponenten beim Schreiben neuer Anwendungen. Beim Verändern vorhandener Anwendungen sollten Sie möglichst die Abhängigkeiten von diesen Technologien entfernen. Statt DB-Library oder Embedded SQL für C können Sie ADO, OLE DB oder ODBC zum Zugreifen auf Daten in SQL Server verwenden. Weitere Informationen zu diesen Technologien finden Sie in der SQL Server-Onlinedokumentation.