01
Kaufen Sie für die Workload, nicht für den Datenbanknamen
Bringen Sie ein Workload-Profil mit: Datenbank-Engine und -Version, aktive Datengröße, Spitzenspeichernutzung, gleichzeitige Abfragen, Schreibvolumen und Wachstum. Beziehen Sie Indizes, Transaktionsprotokolle, temporären Speicherplatz und Wartungsjobs ein. Eine kleine Geschäftsdatenbank und ein Reporting-Warehouse können sehr unterschiedliche Maschinen benötigen, selbst wenn sie dieselbe Software verwenden.
Identifizieren Sie die Einschränkung, die Sie ändern möchten. Wenn ein bestehendes System auf Speicher oder eine Remote-Anwendung wartet, ist der Kauf weiterer Kerne kein Beweis dafür, dass das Problem verschwindet. Verwenden Sie Ihre eigene Abfragemischung und einen repräsentativen Datensatz, um Akzeptanzkriterien für den neuen Host festzulegen.
02
Vergleichen Sie drei verschiedene Zuweisungen
Diese Kandidaten bieten unterschiedliche Speicher- und Festplattenzuweisungen; sie sind nicht nach Transaktionen pro Sekunde sortiert. Die angegebene Rohkapazität ist nach der von Ihnen gewählten Redundanz kein nutzbarer Datenbankspeicherplatz.
- Xeon E-2388G: 64 GB des aufgelisteten ECC Speichers und 2 TB roher NVMe Kapazität. Ein kleinerer Kandidat, wenn die gemessene Arbeitslast bequem passt.
- EPYC 7443P: 256 GB des gelisteten ECC-Speichers und 7.68 TB rohe NVMe-Kapazität. Vergleichen Sie dies, wenn Speicher- oder Datenwachstum die kleinere Konfiguration ausschließt.
- EPYC 7513: vier NVMe-Geräte und 15.36 TB Rohkapazität. Ziehen Sie es in Betracht, wenn das beabsichtigte Festplattenlayout mehr Geräte benötigt, und bestätigen Sie dann die tatsächliche Konfiguration.
03
Vereinbaren Sie, was die Daten schützt
Fragen Sie nach Laufwerksmodell und Ausdauer, wo anhaltende Schreibvorgänge wichtig sind. Der Katalog veröffentlicht keine gemessenen IOPS, Commit-Latenz oder einen Datenbank-Benchmark. Geben Sie das Festplattenlayout und die Wiederherstellungsanforderung an, anstatt anzunehmen, dass NVMe oder ECC einen vollständigen Resilienzplan darstellt.
Eine einzelne Vermietung ist ein physischer Host, kein verwalteter Datenbankcluster. Replikation, Failover, datenbankbewusste Backups und Wiederherstellungstests bleiben Ihre Verantwortung, sofern nicht separat vereinbart. Bestätigen Sie jede erforderliche Netzwerktrennung zwischen Datenbankknoten; ein öffentlicher Port oder eine zweite Maschine beinhaltet kein privates Replikationsnetzwerk.
04
Bepreisen Sie die vollständige Bereitstellung und Migration
Vergleichen Sie das Mietangebot zusammen mit Datenbanklizenzen, Backup-Speicher und allen angebotenen Optionen. Prüfen Sie die Softwarelizenzierung anhand der genauen Prozessorzuweisung. Wählen Sie das Betriebssystem und bestätigen Sie dessen Version, Festplattenlayout und Zugriffsmethode vor der Installation; das Mieten von Hardware umfasst keine Datenbankadministration.
Wählen Sie eine Region entsprechend den Netzwerkanforderungen der Anwendung und bestätigen Sie das Lieferfenster des Modells. Bewahren Sie die bestehende Datenbank auf, bis der neue Host Ihre Prüfungen besteht und eine Wiederherstellung nachgewiesen wurde. Eine Installationsanfrage in der Warteschlange ist keine abgeschlossene Migration und kein Grund, die alte Kopie zu entfernen.
Direkte Antworten
Fragen vor der Bestellung
Versprechen Sie eine Abfragerate oder Datenbanklatenz?
Es werden keine gemessenen Datenbankleistungen veröffentlicht. Legen Sie Abnahmekriterien mit Ihrer Engine, Ihrem Schema, Ihrer Abfragemischung und Ihrem Datensatz fest; eine Hardwarespezifikation allein kann das Ergebnis nicht belegen.
Ist Datenbankverwaltung oder automatisches Failover enthalten?
Nein. Dies ist dedizierte Hardwaremiete. Bestätigen Sie jede separat vereinbarte Unterstützung und planen Sie Administration, Replikation, Backups und Wiederherstellung, bevor Sie Produktionsdaten verschieben.