Auf dieser Seite werden bekannte Probleme mit Cloud SQL for SQL Server sowie Möglichkeiten zu ihrer Vermeidung oder Behebung beschrieben.
Probleme mit der Instanzverbindung
Abgelaufene SSL/TLS-Zertifikate
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf und öffnen Sie die Instanz, wenn Ihre Instanz für die Verwendung von SSL konfiguriert ist. Rufen Sie die Seite Verbindungen auf, wählen Sie den Tab Sicherheit aus und prüfen Sie, ob das Serverzertifikat gültig ist. Wenn es abgelaufen ist, müssen Sie ein neues Zertifikat hinzufügen und zu diesem rotieren.
Version des Cloud SQL Auth-Proxys
Wenn Sie die Verbindung zum Cloud SQL Auth-Proxy herstellen, achten Sie darauf, dass Sie die neueste Version verwenden. Weitere Informationen finden Sie unter Cloud SQL Auth-Proxy auf dem aktuellen Stand halten.
Keine Berechtigung zum Herstellen einer Verbindung
Wenn Sie eine Verbindung zu einer Instanz herstellen, die in diesem Projekt nicht vorhanden ist, besagt die Fehlermeldung nur, dass Sie keine Zugriffsberechtigung für diese Instanz haben.
Kann keine Cloud SQL-Instanz erstellen
Wenn die Fehlermeldung Failed to create subnetwork. Router status is temporarily
unavailable. Please try again later. Help Token: [token-ID] angezeigt wird, versuchen Sie noch einmal, die Cloud SQL-Instanz zu erstellen.
Administrative Probleme
Ein großer Exportvorgang kann die Instanzverfügbarkeit beeinträchtigen.
Achten Sie vor dem Start eines großen Exports darauf, dass mindestens 25 % der Datenbankkapazität frei sind (auf der Instanz). So lassen sich Probleme mit aggressiver automatischer Vergrößerung verhindern, die die Verfügbarkeit der Instanz beeinträchtigen können.
Wenn Ihre SQL Server-Instanz eine SQL Server Express-Version verwendet:
Wenn Sie beim Erstellen einer neuen Instanz ein Flag angeben, schlägt die Erstellung der Instanz fehl.
Sie können keine Datenbank-Flags für eine vorhandene Instanz festlegen.
Cloud SQL-Import- und Exportinstanzvorgänge mit langer Ausführungszeit können nicht abgebrochen oder gestoppt werden.
Auf einer Cloud SQL-Instanz kann jeweils nur ein Vorgang ausgeführt werden. Wenn Sie einen Vorgang mit langer Ausführungszeit starten, sollten Sie darauf achten, dass Sie keine weiteren Vorgänge auf einer Instanz ausführen müssen.
Wenn Sie einen Cloud SQL-Instanzvorgang mit langer Ausführungszeit starten, z. B. einen Import- oder Exportvorgang, gibt es keine Möglichkeit, den Vorgang abzubrechen, ohne die Instanz neu zu starten.
Wenn Sie einen Import aus einer BAK-Datei abbrechen, bleibt die zu importierende Datenbank in einem Teilstatus. Sie müssen die Datenbank löschen. Wenn Sie einen Import aus einer SQL-Datei abbrechen, müssen Sie die Teildaten manuell bereinigen.
Probleme beim Importieren und Exportieren von Daten
Erstellen Sie keine BAK-Datei (für den Import) aus einer schreibgeschützten Datenbank oder aus einer Datenbank, die sich im Einzelnutzermodus befindet. Wenn Sie eine BAK-Datei aus einer schreibgeschützten Datenbank oder aus einer Datenbank erstellen, die sich im Einzelnutzermodus befindet, und diese Datei importieren, kann ein Fehler auftreten.
Wenn Sie versuchen, Daten aus einer großen Datenbank zu importieren und zu exportieren, z. B. eine Datenbank mit mindestens 500 GB, können die Import- und Exportvorgänge sehr lange dauern. Darüber hinaus stehen Ihnen andere Vorgänge (z. B. der Sicherungsvorgang) während des Imports oder Exports nicht zur Verfügung. Eine Möglichkeit zur Verbesserung der Leistung des Import- und Exportvorgangs ist die Wiederherstellung einer vorherigen Sicherung mit gcloud oder der API.
Cloud SQL unterstützt Bulk-Einfügungs-Vorgänge nur auf SQL Server 2022.
Cloud SQL unterstützt keine Bulk-Einfügungen auf Lesereplikaten.
Cloud SQL unterstützt Bulk-Einfügungen nur zum Importieren von Daten in Tabellen.
Cloud Storage unterstützt einzelne Objekte mit einer Größe von bis zu 5 Terabyte.
Wenn Sie Datenbanken haben, die größer als 5 TB sind, schlägt der Exportvorgang nach Cloud Storage fehl. In diesem Fall müssen Sie die Exportdateien in kleinere Segmente unterteilen.
Transaktionslogs und Laufwerkwachstum
Die Logs werden einmal täglich, nicht kontinuierlich gelöscht. Wenn die Anzahl der Tage für die Logaufbewahrung so konfiguriert ist, dass sie der Anzahl der Sicherungen entspricht, kann ein Tag für das Logging verloren gehen, je nachdem, wann die Sicherung erstellt wird. Wenn Sie beispielsweise die Logaufbewahrung auf sieben Tage und die Sicherungsaufbewahrung auf sieben Sicherungen festlegen, werden Logs von sechs bis sieben Tagen aufbewahrt.
Wir empfehlen, die Anzahl der Sicherungen mindestens auf eine mehr als die Anzahl von Tagen der Logaufbewahrung festzulegen, um eine Mindestanzahl von festgelegten Tagen für die Logaufbewahrung sicherzustellen.
Probleme im Zusammenhang mit Cloud Monitoring oder Cloud Logging
Instanzen mit den folgenden Regionsnamen werden in bestimmten Kontexten falsch angezeigt:
us-central1 wird als us-central angezeigt.
europe-west1 wird als europe angezeigt.
asia-east1 wird als asia angezeigt.
Dieses Problem tritt in folgenden Kontexten auf:
Benachrichtigungen in Cloud Monitoring
Metrics Explorer
Cloud Logging
Mithilfe von Ressourcenmetadatenlabels können Sie das Problem bei Benachrichtigungen in Cloud Monitoring und im Metrics Explorer minimieren.
Verwenden Sie das Systemmetadatenlabel region anstelle des überwachten cloudsql_database-Ressourcenlabels region.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[],[],null,["# Known issues\n\n\u003cbr /\u003e\n\n[MySQL](/sql/docs/mysql/known-issues \"View this page for the MySQL database engine\") \\| [PostgreSQL](/sql/docs/postgres/known-issues \"View this page for the PostgreSQL database engine\") \\| SQL Server\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nThis page lists known issues with Cloud SQL for SQL Server, along with\nways you can avoid or recover from these issues.\n\n### Instance connection issues\n\n- Expired SSL/TLS certificates\n\n\n If your instance is configured to use SSL, go to the\n [Cloud SQL Instances page](https://console.cloud.google.com/sql/instances)\n in the Google Cloud console and open the instance. Open its **Connections** page, select the\n **Security** tab and make sure that your server certificate is valid. If it has expired, you must\n add a new certificate and rotate to it.\n\n \u003cbr /\u003e\n\n- Cloud SQL Auth Proxy version\n\n If you are connecting using the Cloud SQL Auth Proxy, make sure you are using the\n most recent version. For more information, see\n [Keeping the Cloud SQL Auth Proxy up to date](/sql/docs/sqlserver/sql-proxy#keep-current).\n- Not authorized to connect\n\n If you try to connect to an instance that does not exist in that project,\n the error message only says that you are not authorized to access that\n instance.\n- Can't create a Cloud SQL instance\n\n If you see the `Failed to create subnetwork. Router status is temporarily\n unavailable. Please try again later. Help Token: [token-ID]` error\n message, try to create the Cloud SQL instance again.\n\n### Administrative issues\n\n\u003cbr /\u003e\n\n- A large export operation can adversely affect instance availability\n\n Before starting a large export, ensure that at least 25 percent of the\n database size is free (on the instance). Doing so helps prevent\n issues with aggressive autogrowth, which can affect the availability\n of the instance.\n - If your SQL Server instance uses a SQL Server Express edition:\n\n - If you specify a flag when you create a new instance, then creating the instance fails.\n\n - You can't set database flags on an existing instance.\n\n - Long-running Cloud SQL import and export instance operations can't be cancelled or stopped\n\n Only one operation can run at a time on a Cloud SQL instance. Make sure you\n don't need to perform other operations on an\n instance when you start a long-running operation.\n\n When you start a long-running Cloud SQL instance operation, such as an\n import or export operation, there's no way to cancel the operation without\n [restarting](/sql/docs/sqlserver/start-stop-restart-instance#restart) the instance.\n - If you cancel an import from a BAK file, then the database that you're importing is left in a partial state. You must drop the database. If you cancel an import from a SQL file, then you must clean up partial data manually.\n\n### Issues with importing and exporting data\n\n- Do not create a BAK file (for import) from a read-only database or from a\n database that is in single-user mode. If you create a BAK file from a read-only\n database or from a database that is in single-user mode, and import that file,\n an error may occur.\n\n \u003cbr /\u003e\n\n- If you're trying to import and export data from a large database (for example,\n a database that has 500 GB of data or greater), then the import and export\n operations might take a long time to complete. In addition, other operations\n (for example, the backup operation) aren't available for you to perform\n while the import or export is occurring. A potential option to improve the\n performance of the import and export process is to [restore a previous backup](/sql/docs/sqlserver/backup-recovery/restoring#projectid) using `gcloud`\n or the API.\n\n- Cloud SQL supports bulk insert only on SQL Server 2022.\n\n- Cloud SQL only supports the `RAW` [codepage](https://learn.microsoft.com/en-us/sql/t-sql/statements/bulk-insert-transact-sql?view=sql-server-ver16).\n\n- Cloud SQL doesn't support bulk insert on read replicas.\n\n- Cloud SQL supports bulk insert only for importing data to tables.\n\n\u003c!-- --\u003e\n\n- Cloud Storage supports a [maximum single-object size up five terabytes](/storage-transfer/docs/known-limitations-transfer#object-limit). If you have databases larger than 5TB, the export operation to Cloud Storage fails. In this case, you need to break down your export files into smaller segments.\n\n### Transaction logs and disk growth\n\nLogs are purged once daily, not continuously. When the number of days of log\nretention is configured to be the same as the number of backups, a day of\nlogging might be lost, depending on when the backup occurs. For example, setting\nlog retention to seven days and backup retention to seven backups means that\nbetween six and seven days of logs will be retained.\n\nWe recommend setting the number of backups to at least one more than the days of\nlog retention to guarantee a minimum of specified days of log retention.\n\n### Issues related to Cloud Monitoring or Cloud Logging\n\nInstances with the following region names are displayed incorrectly in certain\ncontexts, as follows:\n\n- `us-central1` is displayed as `us-central`\n- `europe-west1` is displayed as `europe`\n- `asia-east1` is displayed as `asia`\n\nThis issue occurs in the following contexts:\n\n- Alerting in Cloud Monitoring\n- Metrics Explorer\n- Cloud Logging\n\nYou can mitigate the issue for Alerting in Cloud Monitoring, and for Metrics\nExplorer, by using\n[Resource metadata labels](https://cloud.google.com/monitoring/api/v3/metric-model#meta-labels).\nUse the system metadata label `region` instead of the\n[cloudsql_database](https://cloud.google.com/monitoring/api/resources#tag_cloudsql_database)\nmonitored resource label `region`."]]
