Bekannte Probleme der Big Data-Cluster-Plattform (SQL Server 2019)

  • Artikel

Gilt für: SQL Server 2019 (15.x)

Wichtig

Das Microsoft SQL Server 2019-Big Data-Cluster-Add-On wird eingestellt. Der Support für SQL Server 2019-Big Data-Clusters endet am 28. Februar 2025. Alle vorhandenen Benutzer*innen von SQL Server 2019 mit Software Assurance werden auf der Plattform vollständig unterstützt, und die Software wird bis zu diesem Zeitpunkt weiterhin über kumulative SQL Server-Updates verwaltet. Weitere Informationen finden Sie im Ankündigungsblogbeitrag und unter Big Data-Optionen auf der Microsoft SQL Server-Plattform.

Bekannte Probleme

HDFS-Kopie großer Dateien mit azdata mit zufälligen Fehlern

  • Betroffene Releases: CU 14

  • Problem und Kundenauswirkung: Dies war ein Bug, der zufällige Fehler bei azdata bdc cp-Befehlen zwischen HDFS-Pfaden verursacht hat. Der Fehler wirkt sich häufiger auf größere Dateikopien aus.

  • Lösung: Update auf kumulatives Update 15 (CU15).

Log4j-Sicherheit

  • Betroffene Releases: Keine

  • Problem und Kundenauswirkung: Nach einer gründlichen Bewertung der SQL Server 2019 Big Data-Cluster-Codebasis wurde kein Risiko identifiziert, das mit dem im Dezember gemeldeten log4j-Sicherheitsrisiko verbunden ist. CU15 enthält eine aktualisierte Version von log4j (2.17) für die ElasticSearch-Instanz auf der Steuerungsebene, um sicherzustellen, dass Imagescanwarnungen nicht durch die statische Codeanalyse von Big Data-Clustercontainern ausgelöst werden.

  • Lösung: Halten Sie Ihren Big Data-Cluster immer auf dem Stand des neuesten Release.

Clusterupgrades von einem CU8-Release oder einem früherem Release auf ein Release höher als CU9 werden nicht unterstützt.

  • Betroffene Releases: CU8 und früher

  • Problem und Kundenauswirkung: Beim direkten Upgraden eines Clusters auf ein CU8-Release oder ein früheres Release auf ein Release höher als CU9 schlägt das Upgrade in der Überwachungsphase fehl.

  • Lösung: Führen Sie zuerst ein Upgrade auf CU9 durch. Führen Sie dann ein Upgrade von CU9 auf das neueste Release durch.

Kubernetes-Plattformen mit Kubernetes-API ab Version 1.21

  • Betroffene Releases: alle

  • Problem und Kundenauswirkung: Die Kubernetes-API 1.21 oder höher ist keine getestete Konfiguration für SQL Server-Big Data-Cluster ab CU12.

MicrosoftML-Pakete in SQL Server Machine Learning Services

  • Betroffene Releases: CU10, CU11, CU12 und CU13

  • Problem und Kundenauswirkung: Einige R- bzw. Python-Pakete für MicrosoftML in SQL Server Machine Learning Services funktionieren nicht. Dies wirkt sich auf alle SQL Server-Masterinstanzen aus.

Fehler beim Herstellen einer Verbindung mit der Remoteinstanz von SQL Server 2016 oder älter

  • Betroffene Releases: CU 10
  • Problem und Kundenauswirkung: Wenn Sie PolyBase in Big Data-Cluster für SQL Server 2019 CU10 verwenden, um eine Verbindung zu einer vorhandenen SQL Server-Instanz herzustellen, die ein Zertifikat zur Kanalverschlüsselung verwendet, das mit dem SHA1-Algorithmus erstellt wurde, kann der folgende Fehler auftreten:

Msg 105082, Level 16, State 1, Line 1 105082;Generic ODBC error: [Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: An existing connection was forcibly closed by the remote host. Additional error <2>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection, SqlState: 08001, NativeError: 10054 Additional error <3>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server] Invalid connection string attribute, SqlState: 01S00, NativeError: 0 .

  • Lösung: Aufgrund der höheren Sicherheitsanforderungen von Ubuntu 20.04 gegenüber der vorherigen Basisimageversion ist keine Remoteverbindung für Zertifikate mit SHA-1 zulässig. Das selbst signierte Standardzertifikat der SQL Server-Releases 2005–2016 verwendet SHA-1. Weitere Informationen zu dieser Änderung finden Sie unter Änderungen an selbstsignierten Zertifikaten in SQL Server 2017. Verwenden Sie in der SQL Server-Remoteinstanz ein Zertifikat, das mit einem Algorithmus erstellt wird, der für die Sicherheit mindestens 112 Bit verwendet (z. B. SHA-256). In Produktionsumgebungen wird die Verwendung eines von einer Zertifizierungsstelle ausgestellten vertrauenswürdigen Zertifikats empfohlen. Zu Testzwecken kann auch ein selbstsigniertes Zertifikat verwendet werden. Informationen zum Erstellen eines selbstsignierten Zertifikats finden Sie in den Artikeln zum PowerShell-Cmdlet New-SelfSignedCertificate bzw. zum certreq-Befehl. Anweisungen zum Installieren eines neuen Zertifikats auf einer SQL Server-Remoteinstanz finden Sie unter Aktivieren von verschlüsselten Verbindungen zur Datenbank-Engine.

Partieller Verlust von Protokollen, die in ElasticSearch bei einem Rollback gesammelt wurden

  • Betroffene Releases: Wirkt sich auf vorhandene Cluster aus, wenn ein nicht erfolgreiches Upgrade auf CU9 zu einem Rollback führt oder wenn ein Benutzer ein Downgrade auf ein älteres Release auslöst.

  • Problem und Kundenauswirkung: Die für ElasticSearch verwendete Softwareversion wurde mit CU9 upgegradet, und die neue Version ist nicht abwärtskompatibel mit dem vorherigen Protokollformat bzw. den vorherigen Metadaten. Wenn die ElasticSearch-Komponente erfolgreich aktualisiert wird, aber ein späteres Rollback ausgelöst wird, gehen die zwischen dem ElasticSearch-Upgrade und dem Rollback gesammelten Protokolle dauerhaft verloren. Wenn Sie ein Downgrade auf eine ältere Version von Big Data-Cluster für SQL Server 2019 auslösen (nicht empfohlen), gehen die in Elasticsearch gespeicherten Protokolle verloren. Wenn Sie wieder ein Upgrade auf CU9 durchführen, werden die Daten wiederhergestellt.

  • Problemumgehung: Bei Bedarf können Sie die Problembehandlung mithilfe von Protokollen über den Befehl azdata bdc debug copy-logs durchführen.

Fehlende Pods und Containermetriken

  • Betroffene Releases: Vorhandene und neue Cluster beim Upgrade auf CU9

  • Problem und Kundenauswirkung: Wenn Sie ein Upgrade der Version von Telegraf durchführen, die für die Überwachung von Komponenten in CU9 verwendet wird, werden Sie beim Upgrade des Clusters auf das CU9-Release feststellen, dass keine Pods und Containermetriken erfasst werden. Dies liegt daran, dass eine zusätzliche Ressource in der Definition der Clusterrolle erforderlich ist, die als Ergebnis des Softwareupgrades für Telegraf verwendet wird. Wenn der Benutzer, der den Cluster bereitstellt oder das Upgrade durchführt, nicht die erforderlichen Berechtigungen hat, wird die Bereitstellung bzw. das Upgrade mit einer Warnung fortgesetzt und erfolgreich abgeschlossen. Allerdings werden keine Pod- und Knotenmetriken gesammelt.

  • Problemumgehung: Sie können einen Administrator bitten, die Rolle und das zugehörige Dienstkonto (vor oder nach der Bereitstellung bzw. dem Upgrade) zu erstellen oder zu aktualisieren. Diese werden anschließend vom Big Data-Cluster verwendet. In diesem Artikel wird beschrieben, wie Sie die erforderlichen Artefakte erstellen.

Das Ausgeben von azdata bdc copy-logs führt nicht dazu, dass Protokolle kopiert werden

  • Betroffene Releases: Azure Data CLI (azdata)-Version 20.0.0

  • Problem und Kundenauswirkung: Beim Implementieren des Befehls copy-logs wird davon ausgegangen, dass das kubectl-Clienttool der Version 1.15 oder höher auf dem Clientcomputer installiert ist, von dem der Befehl gesendet wird. Wenn kubectl-Version 1.14 verwendet wird, wird der Befehl azdata bdc debug copy-logs ohne Fehler beendet, aber Protokolle werden nicht kopiert. Wenn Sie die Aktion mit dem Flag --debug ausführen, wird dieser Fehler in der Ausgabe angezeigt: source '.' is invalid (Die Quelle „.“ ist ungültig.)

  • Problemumgehung: Installieren Sie Version 1.15 oder höher des Tools kubectl auf demselben Clientcomputer, und geben Sie den azdata bdc copy-logs-Befehl erneut aus. Informationen zum Installieren von kubectl finden Sie unter diesem Link.

MS DTC-Funktionen können für die SQL Server-Masterinstanz nicht aktiviert werden

  • Betroffene Releases: Alle Bereitstellungskonfigurationen für Big Data-Cluster, unabhängig vom Release

  • Problem und Kundenauswirkung: Wenn SQL Server innerhalb des Big Data-Clusters als SQL Server-Masterinstanz bereitgestellt wird, kann das MS DTC-Feature nicht aktiviert werden. Für diesen Fall gibt es keine Problemumgehung.

Rotation der Verschlüsselungsschlüssel für SQL Server-Datenbanken mit Hochverfügbarkeit

  • Betroffene Releases: Alle Versionen bis zu CU8. Behoben für CU9.

  • Problem und Kundenauswirkung: Wenn SQL Server mit Hochverfügbarkeit bereitgestellt ist, schlägt die Zertifikatrotation für die verschlüsselte Datenbank fehl. Wenn der folgende Befehl für den Masterpool ausgeführt wird, wird eine Fehlermeldung angezeigt:

    ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER
CERTIFICATE <NewCertificateName>;

    Dies hat keine Auswirkung. Der Befehl schlägt fehl, und die Verschlüsselung der Zieldatenbank bleibt mithilfe des vorherigen Zertifikats erhalten.

Aktivieren der Unterstützung von HDFS-Verschlüsselungszonen in CU8

  • Betroffene Releases: Dieses Szenario tritt beim Upgrade von CU6 oder früheren Versionen auf CU8 auf. Bei neuen Bereitstellungen ab CU8 oder beim direkten Upgrade auf CU9 tritt dieses Szenario nicht auf. CU10 oder höhere Releases sind nicht betroffen.

  • Problem und Kundenauswirkung: Die Unterstützung von HDFS-Verschlüsselungszonen ist in diesem Szenario nicht standardmäßig aktiviert und muss anhand der im Konfigurationsleitfaden beschriebenen Schritte konfiguriert werden.

Leere Livy-Aufträge vor dem Anwenden kumulativer Updates

  • Betroffene Releases: Alle Versionen bis zu CU6. Behoben für CU8.

  • Problem und Kundenauswirkung: Während eines Upgrades gibt sparkhead den Fehler 404 zurück.

  • Problemumgehung: Stellen Sie vor dem Upgrade des Big Data-Clusters sicher, dass keine aktiven Livy-Sitzungen oder -Batchaufträge vorhanden sind. Folgen Sie den unter Upgrade von einem unterstützten Release angegebenen Anweisungen, um dies zu vermeiden.

    Wenn Livy während des Upgradevorgangs den Fehler 404 zurückgibt, starten Sie den Livy-Server auf beiden sparkhead-Knoten neu. Beispiel:

    kubectl -n <clustername> exec -it sparkhead-0/sparkhead-1 -c hadoop-livy-sparkhistory -- exec supervisorctl restart livy

Kennwortablauf für die von Big Data-Clustern generierten Dienstkonten

  • Betroffene Releases: Alle Bereitstellungen von Big Data-Clustern mit Active Directory-Integration, unabhängig von der Version

  • Problem und Kundenauswirkung: Während der Bereitstellung eines Big Data-Clusters generiert der Workflow mehrere Dienstkonten. Abhängig von der im Domänencontroller festgelegten Richtlinie zum Kennwortablauf können die Kennwörter für diese Konten ablaufen (Standardwert: 42 Tage). Es gibt zurzeit keinen Mechanismus zum Rotieren von Anmeldeinformationen für alle Konten im Big Data-Cluster, sodass der Cluster nach dem Erreichen des Ablaufdatums nicht mehr funktionsfähig ist.

  • Problemumgehung: Ändern Sie die Ablaufrichtlinie für die Dienstkonten in einem Big Data-Cluster auf dem Domänencontroller in „Kennwort läuft nie ab“. Eine vollständige Liste dieser Konten finden Sie unter Automatisch generierte Active Directory-Objekte. Sie können diese Aktion vor oder nach der Ablaufzeit ausführen. Im letzteren Fall aktiviert Active Directory die abgelaufenen Kennwörter erneut.

Anmeldeinformationen für den Zugriff auf Dienste über den Gatewayendpunkt

  • Betroffene Releases: Neue Cluster, die ab CU5 bereitgestellt werden.

  • Problem und Kundenauswirkung: Bei neuen Big Data-Clustern, die mithilfe von SQL Server-Big Data-Clustern CU5 bereitgestellt werden, ist der Gatewaybenutzername nicht root. Wenn die Anwendung, die zum Herstellen einer Verbindung mit dem Gatewayendpunkt verwendet wird, die falschen Anmeldeinformationen verwendet, wird ein Authentifizierungsfehler angezeigt. Diese Änderung entsteht durch Ausführung von Anwendungen innerhalb des Big Data-Clusters, bei dem es sich nicht einen Root-Benutzer handelt. Ab dem Release der Big Data-Cluster-Plattform CU5 von SQL Server ist ein anderes Standardverhalten festgelegt: Wenn Sie mithilfe von CU5 einen neuen Big Data-Cluster bereitstellen, basiert der Benutzername des Gatewayendpunkts auf dem Wert, der von der Umgebungsvariablen AZDATA_USERNAME übergeben wird. Es handelt sich hierbei um denselben Benutzernamen, der für den Controller und die SQL Server-Endpunkte verwendet wird. Dies betrifft nur neue Bereitstellungen. Vorhandene Big Data-Cluster mit einem der vorherigen Releases verwenden weiterhin root. Es ergeben sich keine Auswirkungen auf Anmeldeinformationen, wenn der Cluster für die Active Directory-Authentifizierung konfiguriert wurde.

  • Problemumgehung: Azure Data Studio verarbeitet die Änderung der Anmeldeinformationen transparent für die Verbindung, die über das Gateway hergestellt wurde, um die HDFS-Suche im Objekt-Explorer zu ermöglichen. Sie müssen das neueste Azure Data Studio-Release installieren, das die erforderlichen Änderungen enthält, die diesen Anwendungsfall berücksichtigen. In anderen Szenarios, in denen Sie Anmeldeinformationen für den Zugriff auf den Dienst über das Gateway angeben müssen (z. B. Anmelden mit Azure Data CLI (azdata) oder Zugreifen auf Webdashboards für Spark), müssen Sie sicherstellen, dass die richtigen Anmeldeinformationen verwendet werden. Wenn die Bereitstellung in einem vorhandenen Cluster erfolgen soll, der vor CU5 bereitgestellt wurde, verwenden Sie weiterhin den root-Benutzernamen, um eine Verbindung mit dem Gateway herzustellen. Dies gilt auch, nachdem Sie den Cluster auf CU5 aktualisiert haben. Wenn Sie einen neuen Cluster mithilfe des CU5-Builds bereitstellen, melden Sie sich mit dem Benutzernamen an, der zur Umgebungsvariablen AZDATA_USERNAME gehört.

Metriken für Pods und Knoten werden nicht erfasst

  • Betroffene Releases: Neue und vorhandene Cluster, die CU5-Images verwenden

  • Problem und Kundenauswirkung: Aufgrund eines Sicherheitsfixes im Zusammenhang mit der API, die telegraf zum Erfassen von Pod -und Hostenknotenmetriken verwendet hat, werden Kunden möglicherweise feststellen, dass die Metriken nicht erfasst werden. Dies ist (nach dem Upgrade auf CU5) sowohl in neuen als auch in vorhandenen Bereitstellungen von Big Data-Cluster für SQL Server 2019 möglich. Aufgrund des Fixes verlangt Telegraf nun ein Dienstkonto mit Rollenberechtigungen für den gesamten Cluster. Bei der Bereitstellung wird versucht, das erforderliche Dienstkonto und die Clusterrolle zu erstellen, aber wenn der Benutzer, der den Cluster bereitstellt oder das Upgrade durchführt, nicht die erforderlichen Berechtigungen hat, wird die Bereitstellung bzw. das Upgrade mit einer Warnung fortgesetzt und erfolgreich abgeschlossen. Allerdings werden dabei keine Pod- und Knotenmetriken erfasst.

  • Problemumgehung: Sie können einen Administrator bitten, die Rolle und das Dienstkonto (vor oder nach der Bereitstellung bzw. dem Upgrade) zu erstellen. Diese werden anschließend vom Big Data-Cluster verwendet. In diesem Artikel wird beschrieben, wie Sie die erforderlichen Artefakte erstellen.

Fehler des Befehls „azdata bdc copy-logs“

  • Betroffene Releases: Azure Data CLI (azdata)-Version 20.0.0

  • Problem und Kundenauswirkung: Bei der Implementierung des Befehls copy-logs wird davon ausgegangen, dass das kubectl-Clienttool auf dem Clientcomputer installiert ist, von dem der Befehl gesendet wird. Wenn Sie den Befehl für einen unter OpenShift installierten Big Data-Cluster ausführen, wird von Clients, auf denen nur das Tool oc installiert ist, der folgende Fehler ausgegeben: An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified.

  • Problemumgehung: Installieren Sie das Tool kubectl auf demselben Clientcomputer, und führen Sie den Befehl azdata bdc copy-logs noch mal aus. Informationen zum Installieren von kubectl finden Sie unter diesem Link.

Bereitstellung mit privatem Repository

  • Betroffene Releases: Allgemeine Vertriebsversion 1, Kumulatives Update 1 und 2 (CU1 und 2). Gelöst für CU 3.

  • Problem und Kundenauswirkung: Das Upgrade von einem privaten Repository weist bestimmte Anforderungen auf.

  • Problemumgehung: Wenn Sie ein privates Repository verwenden, um die Images für die Bereitstellung oder das Upgrade eines Big Data-Clusters vorab per Pull abzurufen, stellen Sie sicher, dass sich die aktuellen Buildimages und die Zielbuildimages im privaten Repository befinden. Dadurch kann bei Bedarf ein Rollback durchgeführt werden. Wenn Sie die Anmeldeinformationen des privaten Repositorys seit der ursprünglichen Bereitstellung geändert haben, müssen Sie zudem das entsprechende Geheimnis in Kubernetes aktualisieren, bevor Sie das Upgrade durchführen. Azure Data CLI (azdata) bietet keine Unterstützung für das Aktualisieren der Anmeldeinformationen über die Umgebungsvariablen AZDATA_PASSWORD und AZDATA_USERNAME. Aktualisieren Sie den geheimen Schlüssel mithilfe von kubectl edit secrets.

Ein Upgrade unter Verwendung unterschiedlicher privater Repositorys für den aktuellen Build und den Zielbuild wird nicht unterstützt.

Beim Upgrade kann aufgrund eines Timeouts ein Fehler auftreten

  • Betroffene Releases: Allgemeine Vertriebsversion 1, Kumulatives Update 1 und 2 (CU1 und 2). Gelöst für CU 3.

  • Problem und Kundenauswirkung: Ein Upgrade kann aufgrund eines Timeouts fehlschlagen.

    Der folgende Code zeigt, wie der Fehler aussehen könnte:

    > azdata.EXE bdc upgrade --name <mssql-cluster>
Upgrading cluster to version 15.0.4003

NOTE: Cluster upgrade can take a significant amount of time depending on
configuration, network speed, and the number of nodes in the cluster.

Upgrading Control Plane.
Control plane upgrade failed. Failed to upgrade controller.

    Dieser Fehler tritt eher auf, wenn Sie das Upgrade von Big Data-Cluster für SQL Server 2019 in Azure Kubernetes Service (AKS) durchführen.

  • Problemumgehung: Erhöhen Sie den Timeoutwert für das Upgrade.

    Bearbeiten Sie die Konfigurationszuordnung für Upgrades, um die Timeoutwerte für Upgrades zu erhöhen. So bearbeiten Sie die Konfigurationszuordnung für Upgrades:

    1. Führen Sie den folgenden Befehl aus:

      kubectl edit configmap controller-upgrade-configmap

    2. Bearbeiten Sie die unten aufgeführten Felder:

      controllerUpgradeTimeoutInMinutes Gibt die Wartezeit in Minuten an, bis der Controller oder die Controllerdatenbank das Upgrade abgeschlossen hat. Der Standardwert ist 5. Aktualisieren Sie diesen Wert auf mindestens 20.

      totalUpgradeTimeoutInMinutes: Gibt die Kombination der Zeispannen an, in denen der Controller und die Controllerdatenbank das Upgrade abgeschlossen haben (Upgrade für controller + controllerdb). Der Standardwert ist 10. Aktualisieren Sie diesen Wert auf mindestens 40.

      componentUpgradeTimeoutInMinutes : Gibt die Zeitdauer an, in der jede nachfolgende Phase des Upgrades abgeschlossen sein muss. Der Standardwert ist 30. Aktualisieren Sie diesen Wert auf 45.

    3. Speichern Sie Ihre Änderungen, und schließen Sie die Anwendung.

    Das folgende Python-Skript zeigt eine weitere Möglichkeit zum Festlegen des Timeouts:

    from kubernetes import client, config
import json

def set_upgrade_timeouts(namespace, controller_timeout=20, controller_total_timeout=40, component_timeout=45):
     """ Set the timeouts for upgrades

     The timeout settings are as follows

     controllerUpgradeTimeoutInMinutes: sets the max amount of time for the controller
         or controllerdb to finish upgrading

     totalUpgradeTimeoutInMinutes: sets the max amount of time to wait for both the
         controller and controllerdb to complete their upgrade

     componentUpgradeTimeoutInMinutes: sets the max amount of time allowed for
         subsequent phases of the upgrade to complete
     """
     config.load_kube_config()

     upgrade_config_map = client.CoreV1Api().read_namespaced_config_map("controller-upgrade-configmap", namespace)

     upgrade_config = json.loads(upgrade_config_map.data["controller-upgrade"])

     upgrade_config["controllerUpgradeTimeoutInMinutes"] = controller_timeout

     upgrade_config["totalUpgradeTimeoutInMinutes"] = controller_total_timeout

     upgrade_config["componentUpgradeTimeoutInMinutes"] = component_timeout

     upgrade_config_map.data["controller-upgrade"] = json.dumps(upgrade_config)

     client.CoreV1Api().patch_namespaced_config_map("controller-upgrade-configmap", namespace, upgrade_config_map)

Die Übermittlung von Livy-Aufträgen von Azure Data Studio oder der curl-Befehl schlägt mit dem Fehler 500 fehl

  • Problem und Kundenauswirkung: In einer Hochverfügbarkeitskonfiguration werden freigegebene sparkhead-Spark-Ressourcen mit mehreren Replikaten konfiguriert. In diesem Fall können Fehler bei der Livy-Auftragsübermittlung von Azure Data Studio oder curl auftreten. Dies können Sie überprüfen, indem Sie curl auf einen beliebigen sparkhead-Pod ausführen. Dies resultiert dann in einer abgelehnten Verbindung. Beispielsweise geben curl https://sparkhead-0:8998/ oder curl https://sparkhead-1:8998 den Fehler 500 zurück.

    Dies geschieht in den folgenden Szenarios:

    • Zookeeper-Pods oder Prozesse einzelner Zookeeper-Instanzen werden mehrmals neu gestartet.
    • Wenn die Netzwerkkonnektivität zwischen sparkhead- und Zookeeper-Pods unzuverlässig ist.

  • Problemumgehung: Beide Livy-Server müssen neu gestartet werden.

    kubectl -n <clustername> exec sparkhead-0 -c hadoop-livy-sparkhistory supervisorctl restart livy

    kubectl -n <clustername> exec sparkhead-1 -c hadoop-livy-sparkhistory supervisorctl restart livy

Erstellen einer arbeitsspeicheroptimierten Tabelle, wenn die Masterinstanz sich in einer Verfügbarkeitsgruppe befindet

  • Problem und Kundenauswirkung: Sie können den primären Endpunkt, der zum Herstellen einer Verbindung mit Verfügbarkeitsgruppendatenbanken (Listener) verfügbar gemacht wird, nicht zum Erstellen arbeitsspeicheroptimierter Tabellen verwenden.

  • Problemumgehung:Stellen Sie eine Verbindung mit der SQL Server-Instanz her, stellen Sie einen Endpunkt zur Verfügung, stellen Sie eine Verbindung mit der SQL Server-Datenbank her, und erstellen Sie die arbeitsspeicheroptimierten Tabellen in der mit der neuen Verbindung erstellten Sitzung, um arbeitsspeicheroptimierte Tabellen zu erstellen, wenn sich die SQL Server-Masterinstanz in einer Verfügbarkeitsgruppe befindet.

Einfügen in externe Tabellen im Active Directory-Authentifizierungsmodus

  • Problem und Kundenauswirkung: Wenn sich die SQL Server-Masterinstanz im Active Directory-Authentifizierungsmodus befindet, gibt eine Abfrage, die nur aus externen Tabellen auswählt, von denen sich mindestens eine in einem Speicherpool befindet, und in eine andere externe Tabelle einfügt, Folgendes zurück:

Msg 7320, Level 16, State 102, Line 1 Cannot execute the query "Remote Query" against OLE DB provider "SQLNCLI11" for linked server "SQLNCLI11". Only domain logins can be used to query Kerberized storage pool.

  • Problemumgehung: Passen Sie die Abfrage auf einer der folgenden Weisen an. Verknüpfen Sie die Speicherpooltabelle mit einer lokalen Tabelle, oder fügen Sie zunächst in die lokale Tabelle ein, und lesen Sie dann aus der lokalen Tabelle, um etwas in den Datenpool einzufügen.

Transparent Data Encryption-Funktionen können nicht mit Datenbanken verwendet werden, die Teil der Verfügbarkeitsgruppe in der SQL Server-Masterinstanz sind

  • Problem und Kundenauswirkung: In einer Hochverfügbarkeitskonfiguration können Datenbanken mit aktivierter Verschlüsselung nach einem Failover nicht verwendet werden, da sich der für die Verschlüsselung verwendete Hauptschlüssel auf den einzelnen Replikaten unterscheidet.

  • Problemumgehung: Für dieses Problem gibt es derzeit keine Problemumgehung. Es wird empfohlen, die Verschlüsselung in dieser Konfiguration erst zu aktivieren, wenn ein Fix vorhanden ist.

Zugehöriger Inhalt

Weitere Informationen zu Big Data-Cluster für SQL Server 2019 finden Sie unter Einführung in Big Data-Cluster für SQL Server.