SQL Server-Lasttests mit HammerDB

---

In dieser Anleitung wird gezeigt, wie HammerDB-Lasttests auf einer Compute Engine SQL Server-Instanz durchführt. In den folgenden Anleitungen erfahren Sie, wie eine SQL Server-Instanz installiert wird:

• SQL Server-Instanzen erstellen
• SQL Server-Hochleistungsinstanz erstellen

Es gibt eine Reihe von Tools für Lasttests. Einige sind kostenlos und als Open Source verfügbar, für andere sind Lizenzen erforderlich. HammerDB ist ein Open-Source-Tool, mit dem die Leistung der SQL Server-Datenbank im Allgemeinen gut überprüft werden kann. In dieser Anleitung werden die Standardschritte bei der Verwendung von HammerDB beschrieben. Es gibt aber auch noch andere Tools. Sie sollten jenes Tool auswählen, das Ihrer Arbeitslast am besten gerecht wird.

Ziele

In dieser Anleitung werden die folgenden Ziele behandelt:

• SQL Server für Lasttests konfigurieren.
• HammerDB installieren und ausführen
• Laufzeitstatistiken erfassen
• Ausführen des Transaktionsverarbeitungs-Benchmarks, der von der TPC-C-Spezifikation (TPROC-C) abgeleitet wurde

Kosten

Neben vorhandenen SQL Server-Instanzen, die in Compute Engine ausgeführt werden, werden in dieser Anleitung unter anderem die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

• Compute Engine
• Windows Server

Der Preisrechner kann eine Kostenschätzung basierend auf der voraussichtlichen Nutzung generieren. Der bereitgestellte Link zeigt eine Schätzung der Kosten für die in dieser Anleitung verwendeten Produkte, die sich auf durchschnittlich 16 US$ pro Tag belaufen können. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Hinweis

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. Wenn Sie auf Ihrem lokalen Computer nicht Windows nutzen, installieren Sie einen RDP-Client (Remote Desktop Protocol) eines Drittanbieters. Weitere Informationen finden Sie unter Microsoft Remote Desktop-Clients.

SQL Server-Instanz für Lasttest konfigurieren

Bevor Sie beginnen, müssen Sie prüfen, ob die Windows-Firewallregeln so eingerichtet sind, dass Traffic von der IP-Adresse der neu erstellten Windows-Instanz zugelassen wird. Erstellen Sie dann eine neue Datenbank für den TPCC-Lasttest und konfigurieren Sie wie unten beschrieben ein Nutzerkonto:

1. Klicken Sie mit der rechten Maustaste auf den Ordner Datenbanken in SQL Server Management Studio und wählen Sie dann Neue Datenbank aus.
2. Geben Sie "TPCC" als Namen der neuen Datenbank ein.
3. Legen Sie für die anfängliche Größe der Datendatei 190.000 MB und für die Logdatei 65.000 MB fest.

4. Erhöhen Sie die Grenzwerte für die Automatische Vergrößerung. Klicken Sie hierzu wie im folgenden Screenshot dargestellt auf die Auslassungspunkte:

   

5. Legen Sie fest, dass die Datendatei um jeweils 64 MB unbegrenzt vergrößert werden kann.

6. Deaktivieren Sie die automatische Vergrößerung für die Logdatei.

7. Klicken Sie auf OK.

8. Wählen Sie im Dialogfeld Neue Datenbank im linken Bereich die Seite Optionen aus.

9. Legen Sie für Kompatibilitätsgrad die Option SQL Server 2022 (160) fest.

10. Setzen Sie das Wiederherstellungsmodell auf Einfach, sodass die Transaktionslogs beim Laden nicht ausgefüllt werden.

    

11. Klicken Sie auf OK, um die TPCC-Datenbank zu erstellen. Dies kann einige Minuten dauern.

12. Im vorkonfigurierten SQL Server-Image ist nur die Windows-Authentifizierung aktiviert, sodass Sie die Authentifizierung wie in dieser Anleitung (nur auf Englisch verfügbar) beschrieben im gemischten Modus innerhalb von SSMS aktivieren müssen.

13. Führen Sie diese Schritte aus (nur auf Englisch verfügbar), um auf Ihrem Datenbankserver ein neues SQL Server-Nutzerkonto zu erstellen, das die DBOwner-Berechtigung hat. Geben Sie dem Konto den Namen "loaduser" und weisen Sie ihm ein sicheres Passwort zu.

14. Notieren Sie die interne IP-Adresse des SQL Server mithilfe des Get-NetIPAddress-Cmdlets, da es für Leistung und die Sicherheit wichtig ist, die interne IP-Adresse zu nutzen.

HammerDB installieren

Sie können HammerDB direkt in der SQL Server-Instanz ausführen. Erstellen Sie aber für einen genaueren Test eine neue Windows-Instanz und testen Sie die SQL Server-Instanz per Remotezugriff.

Hinweis: Unter Umständen müssen Sie die Verstärkte Sicherheitskonfiguration für Internet Explorer deaktivieren, bevor Sie Dateien auf Ihre Windows Server-Instanz herunterladen.

Instanz erstellen

Führen Sie die folgenden Schritte aus, um eine neue Compute Engine-Instanz zu erstellen:

1. Rufen Sie in der Google Cloud Console die Seite Instanz erstellen auf.

   Zur Seite „Instanz erstellen“

2. Geben Sie für Name hammerdb-instance ein.

3. Wählen Sie im Abschnitt Maschinenkonfiguration den Maschinentyp mit mindestens der Hälfte der CPUs als Datenbankinstanz aus.

4. Klicken Sie im Abschnitt Bootlaufwerk auf Ändern und gehen Sie dann so vor:

   1. Wählen Sie auf dem Tab Öffentliche Images ein Windows Server-Betriebssystem aus.
   2. Klicken Sie in der Liste Version auf Windows Server 2022 Datacenter.
   3. Wählen Sie in der Liste Bootlaufwerkstyp die Option Nichtflüchtiger Standardspeicher aus.
   4. Klicken Sie auf Auswählen, um die Bootlaufwerksoptionen zu bestätigen.

5. Klicken Sie zum Erstellen und Starten der VM auf Erstellen.

Software installieren

Stellen Sie mit einem RDP-Client eine Verbindung zu Ihrer neuen Windows Server-Instanz her und installieren Sie die folgende Software:

• ODBC-Treiber 18 für SQL Server
• HammerDB for Windows 64-bit

HammerDB ausführen

Führen Sie die Datei hammerdb.bat aus, nachdem Sie die Installation von HammerDB abgeschlossen haben. HammerDB wird in der Anwendungsliste des Startmenüs nicht angezeigt. Mit folgendem Befehl führen Sie HammerDB aus:

Hinweis: In dieser Anleitung wurde HammerDB 4.10 verwendet. Wenn Sie eine neuere Version verwenden, haben sich einige Optionen möglicherweise geändert.

C:\Program Files\HammerDB-VERSION\hammerdb.bat

Ersetzen Sie VERSION durch die Version der installierten HammerDB.

Verbindung und Schema erstellen

Wenn die Anwendung ausgeführt wird, muss als Erstes die Verbindung konfiguriert werden, um das Schema zu erstellen.

1. Doppelklicken Sie im Steuerfeld Benchmark auf SQL Server.
2. Wählen Sie TPROC-C aus. Auf der HammerDB-Website steht dazu Folgendes:

   TPROC-C ist die in HammerDB implementierte OLTP-Arbeitslast, die aus der TPROC-C-Spezifikation abgeleitet wurde und so modifiziert wurde, dass die Ausführung von HammerDB in jeder der unterstützten Datenbankumgebungen einfach und kostengünstig ist. Die HammerDB-TPROC-C-Arbeitslast ist eine Open-Source-Arbeitslast, die aus dem TPROC-C-Benchmark-Standard abgeleitet wurde. Daher sind die Ergebnisse nicht mit veröffentlichten TPROC-C-Ergebnissen vergleichbar, da sie nicht dem vollständigen TPROC-C-Benchmark-Standard entsprechen, sondern nur einem Teil davon. Der Name der HammerDB-Arbeitslast „TPROC-C“ steht für „Transaction Processing Benchmark derived from the TPC "C" specification“ (Transaktionsverarbeitungs-Benchmarks, der von der TPC-C-Spezifikation abgeleitet wurde).

3. Klicken Sie auf OK.

   

4. Klicken Sie auf Schema und dann doppelt auf Optionen.

5. Füllen Sie das Formular wie in der Abbildung dargestellt aus. Geben Sie dabei Ihre IP-Adresse, Ihren Nutzernamen und Ihr Passwort ein.

   

6. Legen Sie den SQL Server ODBC-Treiber auf ODBC-Treiber 18 für SQL Server fest.

7. In diesem Fall ist die Anzahl der Lagerhäuser (die Skala) auf 460 festgelegt. Sie können aber auch einen anderen Wert auswählen. Einige Richtlinien empfehlen 10 bis 100 Warehouses pro CPU. Legen Sie im Rahmen dieser Anleitung einen Wert fest, der der Anzahl der Kerne mal 10 entspricht: 160 bei einer Instanz mit 16 Kernen.

8. Wählen Sie bei Virtual Users to Build Schema (Virtuelle Nutzer zum Erstellen des Schemas) einen Wert aus, der ein- bis zweimal so hoch wie die Anzahl der Client-vCPUs ist. Sie können auf den grauen Balken neben dem Schieberegler klicken, um die Anzahl zu erhöhen.

9. Heben Sie die Auswahl der Option BPC-Option verwenden auf.

10. Klicken Sie auf OK.

11. Doppelklicken Sie unter dem Abschnitt Schema-Build auf die Option Erstellen, um das Schema zu erstellen und die Tabellen zu laden. Wenn dieser Schritt abgeschlossen ist, klicken Sie auf das rote Blitzlichtsymbol oben in der Mitte des Bildschirms, um den virtuellen Nutzer zu löschen, und gehen Sie zum nächsten Schritt.

Hinweis: Wenn der Build aufgrund des SQL Server-ODBC-Treibers fehlschlägt, öffnen Sie die Anwendung „ODBC-Datenquellen“ in Windows und prüfen Sie auf dem Tab „Treiber“ die verfügbaren ODBC-Treiber.

Wenn Sie die Datenbank mit dem Wiederherstellungsmodell Simple erstellt haben, sollten Sie sie an dieser Stelle wieder in Full ändern, um einen genaueren Test eines Produktionsszenarios zu erhalten. Dies wird erst wirksam, nachdem Sie eine vollständige oder differenzielle Sicherung vorgenommen haben, um das Starten der neuen Logkette auszulösen.

Wichtig: Wenn Sie mehrere Tests ausführen möchten, erstellen Sie eine vollständige Sicherung der neuen TPROC-C-Datenbank, damit Sie diese später wiederherstellen können. Durch die Sicherung können Sie gegenüber dem erneuten Erstellen der Datenbank mit dem Tool Zeit sparen. Wenn Sie die Datenbank auf das vollständige Wiederherstellungsmodell zurücksetzen, sollten Sie die Transaktionslogs sichern, um sie später nach jedem Test zu löschen.

Treiberskript erstellen

HammerDB verwendet das Treiberskript, um den Fluss der SQL-Anweisungen an die Datenbank zu steuern und die erforderliche Last zu generieren.

1. Blenden Sie im Steuerfeld Benchmark den Abschnitt Driver Script (Treiberskript) ein und doppelklicken Sie auf Options (Optionen).
2. Prüfen Sie, ob die Einstellungen mit den Angaben im Dialogfeld Schema Build (Schema-Build) übereinstimmen.
3. Wählen Sie Timed Driver Script (Zeitgesteuertes Treiberskript) aus.
4. Die Option Checkpoint when complete (Checkpoint bei Abschluss) zwingt die Datenbank, am Ende des Tests alles auf das Laufwerk zu schreiben. Aktivieren Sie diese Option also nur, wenn Sie mehrere Tests hintereinander ausführen möchten.
5. Für einen gründlichen Test setzen Sie Minutes of Rampup Time (Minuten zum Hochfahren) unbedingt auf 5 und Minutes for Test Duration (Minuten für die Testdauer) auf 20.
6. Klicken Sie auf OK, um das Dialogfeld zu schließen.
7. Klicken Sie im Abschnitt Driver Script des Steuerfelds Benchmark doppelt auf Load, um das Treiberskript zu aktivieren.

Virtuelle Nutzer erstellen

Für eine realistische Last müssen in der Regel Skripts für mehrere unterschiedliche Nutzer ausgeführt werden. Erstellen Sie daher für den Test einige virtuelle Nutzer.

1. Blenden Sie den Abschnitt Virtual Users ein und klicken Sie doppelt auf Options.
2. Wenn Sie die Warehouse-Anzahl (Skalierung) auf 160 eingestellt haben, setzen Sie Virtuelle Nutzer auf 16, denn die TPROC-C-Richtlinien empfehlen einen Faktor von 10, um zu verhindern, dass Zeilen gesperrt werden. Klicken Sie das Kästchen Show Output an, damit Fehlermeldungen in der Konsole angezeigt werden.
3. Klicken Sie auf OK.

Laufzeitstatistiken erfassen

Das Erfassen detaillierter Laufzeitstatistiken ist bei HammerDB und SQL Server nicht ganz einfach. Auch wenn die Statistiken tief innerhalb von SQL Server verfügbar sind, müssen sie regelmäßig erfasst und berechnet werden. Wenn Sie noch keine Prozedur und kein Tool zur Erfassung dieser Daten haben, können Sie mit der folgenden Prozedur während des Tests einige nützliche Messwerte erfassen. Die Ergebnisse werden in eine CSV-Datei im Windows-Verzeichnis temp geschrieben. Mit der Option Inhalte einfügen > CSV einfügen können Sie die Daten in eine Google-Tabelle kopieren.

Um diese Prozedur zu verwenden, müssen Sie zuerst OLE-Automatisierungsprozeduren vorübergehend aktivieren, um die Datei auf das Laufwerk zu schreiben. Nach dem Testen muss die Option wieder deaktiviert werden:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'Ole Automation Procedures', 1;
GO
RECONFIGURE;
GO

Hinweis: Diese Prozedur ist zwar sehr kurz, kann aber den gemeldeten Gesamtdurchsatz um einen Bruchteil von einem Prozent beeinflussen.

Hier ist der Code zum Erstellen der Prozedur sp_write_performance_counters in SQL Server Management Studio. Bevor Sie den Lasttest starten, führen Sie diese Prozedur in Management Studio aus:

USE [master]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

/***
LogFile path has to be in a directory that SQL Server can Write To.
*/
CREATE PROCEDURE [dbo].[sp_write_performance_counters] @LogFile varchar (2000) = 'C:\\WINDOWS\\TEMP\\sqlPerf.log', @SecondsToRun int =1600, @RunIntervalSeconds int = 2

AS

BEGIN
--File writing variables
DECLARE @OACreate INT, @OAFile INT, @FileName VARCHAR(2000), @RowText VARCHAR(500), @Loops int, @LoopCounter int, @WaitForSeconds varchar (10)
--Variables to save last counter values
DECLARE @LastTPS BIGINT, @LastLRS BIGINT, @LastLTS BIGINT, @LastLWS BIGINT, @LastNDS BIGINT, @LastAWT BIGINT, @LastAWT_Base BIGINT, @LastALWT BIGINT, @LastALWT_Base BIGINT
--Variables to save current counter values
DECLARE @TPS BIGINT, @Active BIGINT, @SCM BIGINT, @LRS BIGINT, @LTS BIGINT, @LWS BIGINT, @NDS BIGINT, @AWT BIGINT, @AWT_Base BIGINT, @ALWT BIGINT, @ALWT_Base BIGINT, @ALWT_DIV BIGINT, @AWT_DIV BIGINT

SELECT @Loops = case when (@SecondsToRun % @RunIntervalSeconds) > 5 then @SecondsToRun / @RunIntervalSeconds + 1 else @SecondsToRun / @RunIntervalSeconds end
SET @LoopCounter = 0
SELECT @WaitForSeconds = CONVERT(varchar, DATEADD(s, @RunIntervalSeconds , 0), 114)
SELECT @FileName = @LogFile + FORMAT ( GETDATE(), '-MM-dd-yyyy_m', 'en-US' ) + '.txt'

--Create the File Handler and Open the File
EXECUTE sp_OACreate 'Scripting.FileSystemObject', @OACreate OUT
EXECUTE sp_OAMethod @OACreate, 'OpenTextFile', @OAFile OUT, @FileName, 2, True, -2

--Write the Header
EXECUTE sp_OAMethod @OAFile, 'WriteLine', NULL,'Transactions/sec, Active Transactions, SQL Cache Memory (KB), Lock Requests/sec, Lock Timeouts/sec, Lock Waits/sec, Number of Deadlocks/sec, Average Wait Time (ms), Average Latch Wait Time (ms)'
--Collect Initial Sample Values
SET ANSI_WARNINGS OFF
SELECT
  @LastTPS= max(case when counter_name = 'Transactions/sec' then cntr_value end),
  @LastLRS = max(case when counter_name = 'Lock Requests/sec' then cntr_value end),
  @LastLTS = max(case when counter_name = 'Lock Timeouts/sec' then cntr_value end),
  @LastLWS = max(case when counter_name = 'Lock Waits/sec' then cntr_value end),
  @LastNDS = max(case when counter_name = 'Number of Deadlocks/sec' then cntr_value end),
  @LastAWT = max(case when counter_name = 'Average Wait Time (ms)' then cntr_value end),
  @LastAWT_Base = max(case when counter_name = 'Average Wait Time base' then cntr_value end),
  @LastALWT = max(case when counter_name = 'Average Latch Wait Time (ms)' then cntr_value end),
  @LastALWT_Base = max(case when counter_name = 'Average Latch Wait Time base' then cntr_value end)
FROM sys.dm_os_performance_counters
WHERE counter_name IN (
'Transactions/sec',
'Lock Requests/sec',
'Lock Timeouts/sec',
'Lock Waits/sec',
'Number of Deadlocks/sec',
'Average Wait Time (ms)',
'Average Wait Time base',
'Average Latch Wait Time (ms)',
'Average Latch Wait Time base') AND instance_name IN( '_Total' ,'')
SET ANSI_WARNINGS ON
WHILE @LoopCounter <= @Loops
BEGIN
WAITFOR DELAY @WaitForSeconds
SET ANSI_WARNINGS OFF
SELECT
  @TPS= max(case when counter_name = 'Transactions/sec' then cntr_value end)   ,
  @Active = max(case when counter_name = 'Active Transactions' then cntr_value end)   ,
  @SCM = max(case when counter_name = 'SQL Cache Memory (KB)' then cntr_value end)   ,
  @LRS = max(case when counter_name = 'Lock Requests/sec' then cntr_value end)   ,
  @LTS = max(case when counter_name = 'Lock Timeouts/sec' then cntr_value end)   ,
  @LWS = max(case when counter_name = 'Lock Waits/sec' then cntr_value end)   ,
  @NDS = max(case when counter_name = 'Number of Deadlocks/sec' then cntr_value end)   ,
  @AWT = max(case when counter_name = 'Average Wait Time (ms)' then cntr_value end)   ,
  @AWT_Base = max(case when counter_name = 'Average Wait Time base' then cntr_value end)   ,
  @ALWT = max(case when counter_name = 'Average Latch Wait Time (ms)' then cntr_value end)   ,
  @ALWT_Base = max(case when counter_name = 'Average Latch Wait Time base' then cntr_value end)
FROM sys.dm_os_performance_counters
WHERE counter_name IN (
'Transactions/sec',
'Active Transactions',
'SQL Cache Memory (KB)',
'Lock Requests/sec',
'Lock Timeouts/sec',
'Lock Waits/sec',
'Number of Deadlocks/sec',
'Average Wait Time (ms)',
'Average Wait Time base',
'Average Latch Wait Time (ms)',
'Average Latch Wait Time base') AND instance_name IN( '_Total' ,'')
SET ANSI_WARNINGS ON

SELECT  @AWT_DIV = case when (@AWT_Base - @LastAWT_Base) > 0 then (@AWT_Base - @LastAWT_Base) else 1 end ,
    @ALWT_DIV = case when (@ALWT_Base - @LastALWT_Base) > 0 then (@ALWT_Base - @LastALWT_Base) else 1 end

SELECT @RowText = '' + convert(varchar, (@TPS - @LastTPS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, @Active) + ', ' +
          convert(varchar, @SCM) + ', ' +
          convert(varchar, (@LRS - @LastLRS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, (@LTS - @LastLTS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, (@LWS - @LastLWS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, (@NDS - @LastNDS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, (@AWT - @LastAWT)/@AWT_DIV) + ', ' +
          convert(varchar, (@ALWT - @LastALWT)/@ALWT_DIV)

SELECT  @LastTPS = @TPS,
    @LastLRS = @LRS,
    @LastLTS = @LTS,
    @LastLWS = @LWS,
    @LastNDS = @NDS,
    @LastAWT = @AWT,
    @LastAWT_Base = @AWT_Base,
    @LastALWT = @ALWT,
    @LastALWT_Base = @ALWT_Base

EXECUTE sp_OAMethod @OAFile, 'WriteLine', Null, @RowText

SET @LoopCounter = @LoopCounter + 1

END

--CLEAN UP
EXECUTE sp_OADestroy @OAFile
EXECUTE sp_OADestroy @OACreate
print 'Completed Logging Performance Metrics to file: ' + @FileName

END

GO

TPROC-C-Lasttest ausführen

Führen Sie die Erfassungsprozedur in SQL Server Management mit dem folgenden Skript aus:

Use master
Go
exec dbo.sp_write_performance_counters

Starten Sie den Test auf der Compute Engine-Instanz, auf der Sie HammerDB installiert haben, in der HammerDB-Anwendung:

1. Doppelklicken Sie im Steuerfeld Benchmark unter Virtual Users (Virtuelle Nutzer) auf Create (Erstellen), um die virtuellen Nutzer zu erstellen. Dadurch wird der Tab Virtual User Output (Virtuelle Nutzerausgabe) aktiviert.
2. Doppelklicken Sie direkt unter der Option Create (Erstellen) auf Run (Ausführen), um den Test zu starten.
3. Nach Abschluss des Tests sehen Sie die Berechnung für die Transaktionen pro Minute (TPM) auf dem Tab Virtual User Output.
4. Die Ergebnisse dieser Erfassungsprozedur finden Sie im Verzeichnis c:\Windows\temp.
5. Speichern Sie diese Werte in einer Google-Tabelle und verwenden Sie sie für den Vergleich mehrerer Testläufe.

Bereinigen

Nachdem Sie die Anleitung abgeschlossen haben, können Sie die erstellten Ressourcen bereinigen, damit sie keine Kontingente mehr nutzen und keine Gebühren mehr anfallen. In den folgenden Abschnitten erfahren Sie, wie Sie diese Ressourcen löschen oder deaktivieren.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das zum Ausführen der Anleitung erstellte Projekt löschen.

So löschen Sie das Projekt:

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Instanzen löschen

So löschen Sie eine Compute Engine-Instanz:

1. In the Google Cloud console, go to the VM instances page.

   Go to VM instances

2. Select the checkbox for the instance that you want to delete.
3. To delete the instance, click More actions, click Delete, and then follow the instructions.

Nächste Schritte

• Sehen Sie sich die Best Practices für SQL Server an.
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center