Oracle-Nutzer zu Cloud SQL for MySQL migrieren: Terminologie und Funktionalität

Dieses Dokument ist Teil einer Reihe, die wichtige Informationen und Anleitungen im Zusammenhang mit der Planung und Durchführung von Oracle® 11g/12c-Datenbankmigrationen zu Cloud SQL for MySQL Version 5.7 (Instanzen der zweiten Generation) enthält. Die Reihe besteht aus folgenden Teilen:

Terminologie

In diesem Abschnitt werden die Gemeinsamkeiten und Unterschiede in der Datenbankterminologie zwischen Oracle und Cloud SQL for MySQL beschrieben. Hierin werden die Kernaspekte der einzelnen Datenbankplattformen geprüft und verglichen. Beim Vergleich wird zwischen den Versionen 11g und 12c von Oracle aufgrund von Architekturunterschieden unterschieden (z. B. führt Oracle 12c die Funktion für mehrere Mandanten ein). Die Cloud SQL for MySQL-Version, auf die hier verwiesen wird, ist 5.7.x.

Unterschiede in der Terminologie zwischen Oracle 11g und Cloud SQL for MySQL

Oracle 11g Beschreibung Cloud SQL for MySQL Wichtige Unterschiede
Instanz Eine einzelne Oracle 11g-Instanz kann nur eine Datenbank enthalten. Instanz Eine MySQL-Instanz kann mehrere Datenbanken enthalten.
Datenbank Eine Datenbank gilt als eine einzelne Instanz (der Name der Datenbank ist mit dem Instanznamen identisch). Datenbank Mehrere oder einzelne Datenbanken stellen mehrere Anwendungen bereit.
Schema Schema und Nutzer sind identisch, da beide als Eigentümer von Datenbankobjekten betrachtet werden (ein Nutzer kann ohne Angabe oder Zuweisung zu einem Schema erstellt werden). Schema Ein Schema wird als Datenbank bezeichnet, während Datenbankobjekte unter einem bestimmten Schema/einer bestimmten Datenbank erstellt werden.
Nutzer Identisch mit Schema, da beide Inhaber von Datenbankobjekten sind, z. B. Instanz → Datenbank → Schemas/Nutzer → Datenbankobjekte. Nutzer Ein Datenbanknutzer mit bestimmten Berechtigungen zum Verbinden oder Ändern von Datenbankobjekten in bestimmten Schemas/Datenbanken, z. B. Instanz → Datenbanken/Schemas → Datenbankobjekte.
Rolle Definierte Gruppe von Datenbankberechtigungen, die als Gruppe verkettet und Datenbanknutzern zugewiesen werden können. MySQL-Berechtigungen MySQL 5.7 unterstützt keine Rollenverwaltung. Berechtigungen können mithilfe der GRANT-Klausel für Nutzer konfiguriert werden, um Berechtigungen für Datenbankobjekte auf verschiedenen Ebenen zu erhalten (Lese-/Schreibvorgänge usw.).
Admin-/SYSTEM-Nutzer Oracle-Administratoren mit der höchsten Zugriffsebene:
SYS
SYSTEM
Superuser Nach der Bereitstellung hat Cloud SQL for MySQL den Nutzer root@'%' (kann von jedem Host aus eine Verbindung herstellen) und einen zusätzlichen Nutzer namens mysql.sys, der nur vom lokalen Host aus eine Verbindung herstellen kann.
Wörterbuch/Metadaten Oracle verwendet die folgenden Metadatentabellen:
USER_TableName
ALL_TableName
DBA_TableName
Wörterbuch/Metadaten MySQL verwendet mehrere Datenbanken/Schemas für Wörterbuch/Metadaten:
MYSQL
INFORMATION_SCHEMA
PERFORMANCE_SCHEMA
SYS
Jede dieser Datenbanken ist auch eine Systemdatenbank und wird mit jeder Bereitstellung von Cloud SQL for MySQL erstellt.
Dynamische Systemansichten Dynamische Oracle-Ansichten:
V$ViewName
Dynamische Systemansichten Dynamische MySQL-Ansichten finden Sie in mehreren Systemdatenbanken:
INFORMATION_SCHEMA
PERFORMANCE_SCHEMA
SYS
Tablespace Die primären logischen Speicherstrukturen von Oracle-Datenbanken; jeder Tablespace kann eine oder mehrere Datendateien enthalten. Tablespace Ähnlich wie Oracle ist ein MySQL-Tablespace eine logische Einheit, stellt jedoch im Gegensatz zum Oracle-Tablespace nur eine einzelne Tabelle dar. Letzterer kann mehrere Datendateien enthalten (enthält Daten für mehrere Tabellen).

MySQL unterstützt das Erstellen eines neuen Tablespace mit einer zugewiesenen Datendatei und das Erstellen einer neuen Tabelle, die an den neu erstellten Tablespace angehängt ist. Beachten Sie, dass Tablespace-Konfigurationseinstellungen wie Größe und Limits mithilfe von Datenbankparametern und nicht während der Tablespace-Erstellung festgelegt werden.
Datendateien Die physischen Elemente einer Oracle-Datenbank, die die Daten enthalten und in einem bestimmten Tablespace definiert sind.

Eine einzelne Datendatei wird durch die anfängliche und die maximale Größe definiert und kann Daten für mehrere Tabellen enthalten.

Oracle-Datendateien verwenden das Suffix .dbf (nicht obligatorisch).
Datendateien Cloud SQL for MySQL verwendet den Parameter innodb_file_per_table mit dem Wert "ON" (Standard). Diese Konfiguration generiert eine neue Datendatei für jede Tabelle und einen dedizierten Tablespace.

MySQL-Datendateien verwenden .ibd-(Daten) und .frm-(Metadaten)-Dateien.
System-Tablespace Enthält die Datenwörterbuch-Tabellen und -Ansichtsobjekte für die gesamte Oracle-Datenbank. System-Tablespace Wie bei Oracle; enthält die Wörterbuch-/Metadatentabellen. Wird im Tabellenbereich innodb_system gespeichert, der die Datendatei ibdata1 angehängt ist.
Temporärer Tablespace Enthält Schemaobjekte, die für die Dauer einer Sitzung gültig sind. Darüber hinaus unterstützt es die Ausführung von Vorgängen, die nicht in den Serverspeicher passen. Temporärer Tablespace Der Zweck ist identisch mit Oracle. Wird im MySQL-Tablespace innodb_temporary gespeichert, der an die Datendatei ibtmp1 angehängt ist.
Rückgängig machen
Tablespace
Ein spezieller Typ von system-permanentem Tablespace, der von Oracle zur Verwaltung von Rollback-Operationen verwendet wird, wenn die Datenbank im automatischen Rückgängig-machen-Verwaltungsmodus ausgeführt wird (Standard). Tablespace rückgängig machen Ähnlich wie Oracle enthält der MySQL-Rückgängig-Tablespace Rückgängig-Logs für Rollback-Zwecke. Diese Option ist standardmäßig auf OFF gesetzt und wird in zukünftigen MySQL-Releases als verworfen bezeichnet.
ASM Die Automatische Speicherverwaltung von Oracle (ASM, Automatic Storage Management) ist ein integriertes Hochleistungs-Datenbankdateisystem und ein Festplattenmanager, die alle automatisch von einer Oracle-Datenbank ausgeführt werden, die mit ASM konfiguriert wurde. Nicht unterstützt MySQL verwendet den Begriff Speicher-Engines zur Beschreibung verschiedener Implementierungen der Datenverarbeitung, unterstützt jedoch Oracle ASM nicht. Cloud SQL for MySQL unterstützt viele Funktionen zur Speicherautomatisierung, z. B. automatische Speichererweiterungen, Leistung und Skalierbarkeit.
Tabellen/Ansichten Vom Nutzer erstellte grundlegende Datenbankobjekte. Tabellen/Ansichten Identisch mit Oracle.
Materialisierte Ansichten Wird mit bestimmten SQL-Anweisungen definiert und kann je nach Konfiguration manuell oder automatisch aktualisiert werden. Nicht von MySQL unterstützt Als Behelfslösung können Trigger/Ansichten anstelle von materialisierten Oracle-Ansichten verwendet werden.
Sequenz Oracle-Wertgenerator für eindeutige Werte. Automatische Erhöhung MySQL unterstützt keine Oracle-Sequenzen. Verwenden Sie AUTO_INCREMENT als Alternative zur automatischen Sequenzgenerierung.
Synonym Oracle-Datenbankobjekte, die als alternative Kennzeichnungen für andere Datenbankobjekte dienen. Nicht unterstützt MySQL unterstützt Oracle Synonym nicht. Als Behelfslösung können Ansichten verwendet werden, während die entsprechenden Berechtigungen festgelegt werden.
Partitionierung Oracle bietet viele Partitionierungslösungen zum Aufteilen großer Tabellen in kleinere verwaltete Teile. Partitionierung MySQL hat eine begrenztere Partitionierungsunterstützung, um die Leistung zu verbessern und gleichzeitig Datenverwaltungs- und Wartungsvorgänge wie Oracle-Partitionen beizubehalten.
Flashback-Datenbank Oracle-eigene Funktion, die zum Initialisieren einer Oracle-Datenbank zu einem zuvor definierten Zeitpunkt verwendet werden kann. Damit können Sie versehentlich geänderte oder beschädigte Daten abfragen oder wiederherstellen. Nicht unterstützt Als alternative Lösung können Sie Cloud SQL-Sicherungen und die Wiederherstellung zu einem bestimmten Zeitpunkt verwenden, um eine Datenbank in einen vorherigen Zustand zurückzusetzen (z. B. vor dem Löschen einer Tabelle).
sqlplus Oracle-Befehlszeilenschnittstelle, mit der Sie die Datenbankinstanz abfragen und verwalten können. mysql MySQL-äquivalente Befehlszeilenschnittstelle zum Abfragen und Verwalten. Kann von jedem Client mit den entsprechenden Berechtigungen für Cloud SQL verbunden werden.
PL/SQL Oracle hat die Verfahrenssprache auf ANSI SQL erweitert. MySQL MySQL verfügt über eine eigene erweiterte Verfahrenssprache mit unterschiedlicher Syntax und Implementierung und hat keine zusätzliche Benennung für diese erweiterte Sprache.
Paket und Pakettext Oracle-spezifische Funktionen zum Gruppieren von gespeicherten Verfahren und Funktionen unter derselben logischen Referenz. Nicht unterstützt MySQL unterstützt gespeicherte Verfahren und Funktionen als einzelne Objekte mit Gruppenzuordnung.
Gespeicherte Verfahren und Funktionen Verwendet PL/SQL zur Implementierung der Codefunktionalität. Gespeicherte Verfahren und Funktionen Das Erstellen von gespeicherten Verfahren und Funktionen wird von MySQL mit der Implementierung einer eigenen prozessualen Sprache unterstützt.
Trigger Oracle-Objekt zur Steuerung der DML-Implementierung über Tabellen. Trigger Identisch mit Oracle.
PFILE/SPFILE Die Parameter der Oracle-Instanz und der Datenbankebene werden in einer Binärdatei mit dem Namen SPFILE (in früheren Versionen hieß die Datei PFILE) gespeichert, die als Textdatei für die manuelle Einstellung von Parametern verwendet werden kann. Datenbank-Flags in Cloud SQL for MySQL Sie können Cloud SQL for MySQL-Parameter über das Dienstprogramm Datenbank-Flags festlegen oder ändern. Sie können Datenbankparameter in Cloud SQL for MySQL nicht über die Befehlszeilenschnittstelle des MySQL-Clients ändern (z. B. mysql> SET GLOBAL ...). Sie können diese Parameter nur mit dem Dienstprogramm für Datenbank-Flags ändern.
SGA/PGA/AMM Oracle-Speicherparameter, die die Speicherzuweisung für die Datenbankinstanz steuern. INNODB_BUFFER_POOL_SIZE MySQL hat eigene Speicherparameter. Ein entsprechender Parameter könnte INNODB_BUFFER_POOL_SIZE sein. In Cloud SQL for MySQL ist dieser Parameter durch den ausgewählten Instanztyp vordefiniert und der Wert ändert sich entsprechend.
Ergebnis-Cache Reduziert SQL-E/A-Vorgänge, indem Zeilen aus dem Puffercache abgerufen werden, der mithilfe von Datenbankparametern und Hinweisen auf Sitzungsebene verwaltet werden kann. Abfragecache Hat denselben grundlegenden Zweck wie der Ergebnis-Cache von Oracle und kann auf Datenbank- und Sitzungsebene verwaltet werden.
Datenbankhinweise Kontrollierte Auswirkungen auf SQL-Anweisungen, die das Verhalten des Optimierers beeinflussen, um eine bessere Leistung zu erzielen. Oracle bietet mehr als 50 verschiedene Datenbankhinweise. Datenbankhinweise MySQL unterstützt im Vergleich zu Oracle eine begrenzte Reihe von Datenbankhinweisen (Optimierungshinweise und Indexhinweise). Beachten Sie, dass MySQL unterschiedliche Datenbankhinweise, Syntax und Benennung verwendet.
RMAN Wiederherstellungs-Manager von Oracle. Wird für Datenbanksicherungen mit erweiterter Funktionalität verwendet, um mehrere Szenarien der Notfallwiederherstellung und mehr (Klonen usw.) zu unterstützen. Cloud SQL for MySQL-Sicherung Cloud SQL for MySQL bietet zwei Methoden zum Anwenden einer vollständigen Sicherung: Automatische Sicherungen und Sicherungen bei Bedarf.
Data Pump (EXPDP/IMPDP) Oracle-Dump-Generierungsprogramm, das für viele Funktionen verwendet werden kann, z. B. Export/Import, Datenbanksicherung (auf Schema- oder Objektebene), Schemametadaten, Schema-SQL-Dateien generieren und mehr.
mysqldump/mysqlimport
MySQL Dump-(Export-)-Programm, das als Client (remote) verbunden werden und eine Dumpdatei (SQL) erzeugen kann. Später können Sie die Dumpdatei komprimieren und in Cloud Storage verschieben. Das Dienstprogramm mysqldump ist nur für den Exportschritt vorgesehen.
SQL*Loader Tool zum Hochladen von Daten aus externen Dateien wie Textdateien, CSV-Dateien usw.
mysqlimport/
LOAD FILE INFILE
Das Dienstprogramm mysqlimport bietet die Möglichkeit, Text- oder CSV-Dateien (Oracle unterstützt zusätzliche Dateiformate) in eine Datenbanktabelle mit einer entsprechenden Struktur zu laden.
Data Guard Oracle-Notfallwiederherstellungslösung mit einer Standby-Instanz, mit der Nutzer Lesevorgänge von der Standby-Instanz aus durchführen können. Hohe Verfügbarkeit und Replikation in Cloud SQL for MySQL Für die Notfallwiederherstellung oder Hochverfügbarkeit bietet Cloud SQL for MySQL die Architektur des Failover-Replikats und für schreibgeschützte Vorgänge (Lese-/Schreib-Trennung) das Lesereplikat.
Active Data Guard/Golden Gate Die Hauptreplikationslösungen von Oracle, die verschiedene Zwecke erfüllen, z. B. Standby (DR), schreibgeschützte Instanz, bidirektionale Replikation (mit mehreren Quellen), Data-Warehouse-Prozesse und mehr Cloud SQL for MySQL-Lesereplikat Cloud SQL for MySQL-Lesereplikat zum Implementieren von Clustern mit Lese-/Schreib-Trennung. Derzeit werden Konfigurationen mit mehreren Quellen wie die bidirektionale Golden Gate-Replikation oder die heterogene Replikation nicht unterstützt.
RAC Oracle Real Application Cluster. Oracle-eigene Clustering-Lösung für Hochverfügbarkeit durch Bereitstellung mehrerer Datenbankinstanzen mit einer einzigen Speichereinheit. Nicht unterstützt Die Architektur mit mehreren Quellen wird in Google Cloud SQL noch nicht unterstützt. Verwenden Sie Cloud SQL-Hochverfügbarkeit und Lesereplikate, um eine Clustering-Architektur mit Lese-/Schreib-Trennung und hoher Verfügbarkeit zu erreichen.
Grid/Cloud Control (OEM) Oracle-Software zur Verwaltung und Überwachung von Datenbanken und anderen zugehörigen Diensten in einem Webanwendungsformat. Dieses Tool ist für die Datenbankanalyse in Echtzeit nützlich, um hohe Arbeitslasten zu verstehen. Cloud SQL for MySQL Console, Cloud Monitoring Verwenden Sie Cloud SQL for MySQL zum Monitoring, einschließlich detaillierter zeit- und ressourcenbasierter Grafiken. Verwenden Sie außerdem Cloud Monitoring, um bestimmte MySQL-Monitoringmesswerte und Loganalysen für erweiterte Monitoringfunktionen zu speichern.
REDO-Logs Oracle-Transaktionslogs, die aus zwei (oder mehr) vordefinierten Dateien bestehen, in denen alle Datenänderungen gespeichert werden. Der Zweck des Redo-Logs besteht darin, die Datenbank im Falle eines Instanzfehlers zu schützen. REDO-Logs MySQL verfügt auch über Redo-Log-Dateien, die während der Absturzwiederherstellung verwendet werden, um Daten zu korrigieren, die vom Redo-Log-Mechanismus unvollständiger Transaktionen geschrieben wurden.
Archivlogs Archivlogs bieten Unterstützung für Sicherungs- und Replikationsvorgänge und mehr. Oracle schreibt nach jedem Wechsel des Redo-Logs in Archivlogs (falls aktiviert). binlogs MySQL-Implementierung der Aufbewahrung von Transaktionslogs. Wird hauptsächlich für Replikationszwecke verwendet (standardmäßig mit Cloud SQL aktiviert).
Kontrolldatei Die Oracle-Kontrolldatei enthält Informationen über die Datenbank, z. B. Datendateien, Namen und Speicherorte von Redo-Logs, die aktuelle Log-Sequenznummer und Informationen zum Instanzprüfpunkt. MySQL Die MySQL-Architektur enthält keine Kontrolldatei, die der Oracle-Implementierung ähnelt. Dies wird über die MySQL-Parameter und den Befehl SHOW MASTER STATUS gesteuert, um die aktuelle Position des binären Logs anzuzeigen.
SCN Oracle SCN (System Change Number) ist die primäre Methode zur Aufrechterhaltung der Datenkonsistenz durch alle Oracle-Datenbankkomponenten, um das ACID-Transaktionsmodell zu erfüllen. Logsequenz-Nummer (LSN-Nummer) Die MySQL-Implementierung für die Datenbankkonsistenz verwendet die Logsequenz-Nummer.
AWR Oracle AWR (automatisches Arbeitslast-Repository) ist ein ausführlicher Bericht mit detaillierten Informationen zur Leistung der Oracle-Datenbankinstanz und gilt als DBA-Tool für die Leistungsdiagnose.
performance_schema
MySQL hat keinen Bericht, der mit Oracle AWR vergleichbar ist, aber MySQL erfasst Leistungsdaten, die von performance_schema erfasst wurden. Eine alternative Lösung wäre die Verwendung von MySQL Workbench-Leistungsdashboards.
DBMS_SCHEDULER
Oracle-Dienstprogramm zum Festlegen und Planen vordefinierter Vorgänge.
EVENT_SCHEDULER
Interne Scheduler-Funktionalität in der MySQL-Datenbank. Diese Funktion ist standardmäßig auf OFF eingestellt.
Transparente Datenverschlüsselung Verschlüsselung von auf Laufwerken gespeicherten Daten als Schutz für inaktive Daten. Cloud SQL Advanced Encryption Standard Cloud SQL for MySQL verwendet den 256-Bit-Advanced Encryption Standard (AES-256) für den Schutz inaktiver Daten sowie für Daten während der Übertragung
Erweiterte Komprimierung Um den Speicherbedarf der Datenbank zu verbessern, die Speicherkosten zu senken und die Datenbankleistung zu verbessern, bietet Oracle erweiterte Datenkomprimierungsfunktionen (Tabellen/Indexe). InnoDB-Tabellenkomprimierung MySQL bietet eine Tabellenkomprimierung, indem eine Tabelle mit dem Parameter ROW_FORMAT erstellt wird, der auf COMPRESSED gesetzt ist. Weitere Informationen zur Indexkomprimierung
SQL-Entwickler Kostenlose SQL-GUI von Oracle zum Verwalten und Ausführen von SQL- und PL/SQL-Anweisungen (kann auch mit MySQL verwendet werden). MySQL Workbench Kostenlose MySQL-SQL-GUI zum Verwalten und Ausführen von SQL- und MySQL-Codeanweisungen.
Benachrichtigungslogs Oracle-Hauptlog für allgemeine Datenbankvorgänge und Fehler. MySQL-Fehlerlog Verwendet die Loganzeige von Cloud Logging, um MySQL-Fehlerlogs anzusehen
DUAL-Tabelle Oracle-spezielle Tabelle, die hauptsächlich zum Abrufen von Pseudospaltenwerten wie SYSDATE oder USER dient DUAL-Tabelle Mit MySQL kann DUAL als Tabelle in SQL-Anweisungen angegeben werden, die nicht von Daten aus Tabellen abhängen.
Externe Tabelle Mit Oracle können Nutzer externe Tabellen mit den Quelldaten in Dateien außerhalb der Datenbank erstellen. Nicht unterstützt. Keine direkte Entsprechung.
Listener Oracle-Netzwerkprozess mit der Aufgabe, eingehende Datenbankverbindungen zu überwachen Für Cloud SQL autorisierte Netzwerke MySQL akzeptiert Verbindungen von Remote-Quellen, sobald dies auf der Cloud SQL-Konfigurationsseite Autorisierte Netzwerke zugelassen ist
TNSNAMES Oracle-Netzwerkkonfigurationsdatei, die Datenbankadressen für den Verbindungsaufbau mithilfe von Verbindungsaliasen definiert. Existiert nicht MySQL akzeptiert externe Verbindungen über den Verbindungsnamen der Cloud SQL-Instanz oder die private/öffentliche IP-Adresse. Cloud SQL Proxy ist eine zusätzliche sichere Zugriffsmethode, um eine Verbindung zu Cloud SQL for MySQL (Instanzen der zweiten Generation) herzustellen, ohne bestimmte IP-Adressen zuzulassen oder SSL zu konfigurieren.
Standardport der Instanz 1521 Standardport der Instanz 3306
Link zur Datenbank Oracle-Schemaobjekte, die zur Interaktion mit lokalen/Remote-Datenbankobjekten verwendet werden können. Nicht unterstützt Als alternative Problemumgehung verwenden Sie Anwendungscode, um eine Verbindung herzustellen und Daten aus einer Remote-Datenbank abzurufen.

Unterschiede in der Terminologie zwischen Oracle 12c und Cloud SQL for MySQL

Oracle 12c Beschreibung Cloud SQL for MySQL Wichtige Unterschiede
Instanz Die in der Oracle 12c-Instanz eingeführte Mehrmandantenfähigkeit, die mehrere Datenbanken als Plug-in-Datenbank (PDB) speichern kann, im Gegensatz zu Oracle 11g, wo eine Oracle-Instanz nur eine Datenbank erhalten kann. Instanz Cloud SQL for MySQL kann mehrere Datenbanken mit unterschiedlichen Namen enthalten, die für mehrere Dienste und Anwendungen verwendet werden.
CDB Eine mehrmandantenfähige Containerdatenbank (CDB) kann ein oder mehrere PDBs unterstützen, während globale CDB-Objekte (betrifft alle PDBs) wie z. B. Rollen erstellt werden können. MySQL-Instanz Die MySQL-Instanz ist mit der Oracle-CDB vergleichbar. Beide bieten eine Systemschicht für die PDBs.
PDB PDBs (Plug-in-Datenbanken) können verwendet werden, um Dienste und Anwendungen voneinander zu isolieren und als mobile Sammlung von Schemas zu verwenden. MySQL-Datenbanken/Schemas Eine MySQL-Datenbank kann mehrere Dienste und Anwendungen sowie viele Datenbanknutzer bereitstellen.
Sitzungssequenzen Ab Oracle 12c können Sequenzen auf Sitzungsebene (zurückgegebene eindeutige Werte nur innerhalb einer Sitzung) oder auf globaler Ebene (z. B. bei Verwendung temporärer Tabellen) erstellt werden. Automatische
Erhöhung
Sequenzen werden von MySQL nicht unterstützt, aber Nutzer können das Spaltenattribut AUTO_INCREMENT als alternative Lösung verwenden.
Identitätsspalten Der Oracle 12c-Typ IDENTITY generiert eine Sequenz und verknüpft sie mit einer Tabellenspalte, ohne dass manuell ein separates Sequenzobjekt erstellt werden muss. Automatische Erhöhung Verwenden Sie die Spalteneigenschaft AUTO_INCREMENT, um die gleiche Funktionalität wie die Oracle 12c-Identitätsspalte zu simulieren (eine Alternative zur Funktion zur automatischen Sequenzgenerierung).
Sharding Oracle Sharding ist eine Lösung, bei der eine Oracle-Datenbank in mehrere kleinere Datenbanken (Shards) partitioniert wird, um Skalierbarkeit, Verfügbarkeit und Geoverteilung für OLTP-Umgebungen zu ermöglichen. Nicht unterstützt (als Funktion) MySQL verfügt nicht über eine entsprechende Fragmentierungsfunktion. Die Fragmentierung kann mithilfe von MySQL (als Datenplattform) mit einer unterstützenden Anwendungsebene implementiert werden.
In-Memory-Datenbank Oracle bietet eine Reihe von Funktionen, die die Datenbankleistung für OLTP sowie für gemischte Arbeitslasten verbessern können. Nicht unterstützt MySQL verfügt nicht über eine entsprechende Funktion. Alternativ können Sie Memorystore verwenden.
Entfernen Als Teil der erweiterten Sicherheitsfunktionen von Oracle kann das Entfernen eine Spaltenmaskierung durchführen, um zu verhindern, dass sensible Daten von Nutzern und Anwendungen angezeigt werden. Nicht unterstützt MySQL verfügt nicht über eine entsprechende Funktion.

Funktionsweise

Obwohl Oracle 11g/12c- und Cloud SQL for MySQL-Datenbanken auf verschiedenen Architekturen (Infrastruktur und erweiterte prozessuale Sprachen) funktionieren, haben sie dieselben grundlegenden Aspekte einer relationalen Datenbank. Sie unterstützen Datenbankobjekte, gleichzeitige Arbeitslasten für mehrere Nutzer und Transaktionen (ACID-Kompatibilität). Sie verwalten auch Sperrungsinhalte, die je nach den Geschäftsanforderungen mehrere Isolationsebenen unterstützen, und dienen fortlaufenden Anwendungsanforderungen als relationaler Datenspeicher für OLTP-Vorgänge (Online Transactional Processing) und OLAP-Vorgänge (Online Analytics Processing).

Der folgende Abschnitt bietet einen Überblick über einige der wichtigsten funktionalen Unterschiede zwischen Oracle und Cloud SQL for MySQL. In einigen Fällen enthält der Abschnitt bei Bedarf detaillierte technische Vergleiche.

Vorhandene Datenbanken erstellen und anzeigen

Oracle 11g/12c Cloud SQL for MySQL 5.7
Sie erstellen Datenbanken in der Regel mit dem Oracle-Dienstprogramm Database Creation Assistant (DBCA) und sehen sich vorhandene Datenbanken an. Bei manuell erstellten Datenbanken oder Instanzen müssen Sie zusätzliche Parameter angeben:
SQL> CREATE DATABASE ORADB
     USER SYS IDENTIFIED BY password
     USER SYSTEM IDENTIFIED BY password
     EXTENT MANAGEMENT LOCAL
     DEFAULT TEMPORARY TABLESPACE temp
     UNDO TABLESPACE undotbs1
     DEFAULT TABLESPACE users;
Verwenden Sie eine Anweisung im Format CREATE DATABASE Name;, wie in diesem Beispiel:
mysql> CREATE DATABASE MYSQLDB;
Oracle 12c Cloud SQL for MySQL 5.7
In Oracle 12c können Sie PDBs aus dem Startwert erstellen, entweder aus einer Containerdatenbankvorlage (CDB) oder durch Klonen eines PDB aus einem vorhandenen PDB. Sie verwenden mehrere Parameter:

SQL> CREATE PLUGGABLE DATABASE PDB
     ADMIN USER usr IDENTIFIED BY passwd
     ROLES = (dba)
     DEFAULT TABLESPACE sales
     DATAFILE '/disk1/ora/dbs/db/db.dbf'
     SIZE 250M AUTOEXTEND ON
     FILE_NAME_CONVERT =
     ('/disk1/oracle/dbs/pdbseed/',
      '/disk1/oracle/dbs/salespdb/')
      STORAGE (MAXSIZE 2G)
      PATH_PREFIX =
      '/disk1/oracle/dbs/salespdb/';
Verwenden Sie eine Anweisung im Format CREATE DATABASE Name;, wie in diesem Beispiel:
mysql> CREATE DATABASE MYSQLDB;
Alle PDBs auflisten:
SQL> SHOW is PDBS;
Alle vorhandenen Datenbanken auflisten:
mysql> SHOW DATABASES;
Verbindung zu einem anderen PDB herstellen:
SQL> ALTER SESSION SET CONTAINER=pdb;
Verbindung zu einer anderen Datenbank herstellen:
mysql> use databaseName;
Oder:
mysql> \u databaseName;
So öffnen oder schließen Sie einen bestimmten PDB (offen/schreibgeschützt):
SQL> ALTER PLUGGABLE DATABASE pdb CLOSE;
Wird für eine einzelne Datenbank nicht unterstützt.

Alle Datenbanken befinden sich unter derselben Cloud SQL for MySQL-Instanz. Daher sind alle Datenbanken hoch- oder heruntergefahren.

Datenbank über die Cloud SQL-Konsole verwalten

  • Gehen Sie in der Google Cloud Console zu Speicher > SQL > Instanzen > Datenbanken > Anzeigen/Erstellen.

    Konsolenseite zum Erstellen/Anzeigen einer MySQL-Datenbank.

Systemdatenbanken und -schemas

Oracle-Datenbankinstanzen erhalten bestimmte Systemschemas, z. B. SYS/SYSTEM, mit der Inhaberrolle von Datenbankmetadatenobjekten.

Im Gegensatz dazu enthält MySQL mehrere Systemdatenbanken (im Gegensatz zu Oracle-Schemas), die die Metadatenschicht bereitstellen. Beachten Sie, dass bei den Datenbanknamen die Groß- und Kleinschreibung beachtet werden muss:

  • Mysql

    Die mysql-Systemdatenbank enthält Tabellen, die Informationen speichern, die der MySQL-Server während der Ausführung benötigt, z. B.:

    • Systemberechtigungstabellen
    • Objekt-Informationstabellen
    • Log-Systemtabellen
    • Replikationssystemtabellen
    • Optimierungssystemtabellen
    • Zeitzonen-Systemtabellen
  • INFORMATION_SCHEMA

    INFORMATION_SCHEMA dient als wichtigstes Datenbankdatenwörterbuch und Systemkatalog. Es bietet Zugriff auf Datenbankmetadaten, bei denen es sich um interne Datenbankinformationen zum MySQL-Server handelt, z. B. den Namen einer Datenbank oder Tabelle, den Spaltendatentyp und die Zugriffsberechtigungen.

  • performance_schema

    Eine Systemdatenbank, die statistische Informationen über die MySQL-Instanz erfasst. Die Systemdatenbank performance_schema enthält Messwerte für die Überwachung der Serverausführung auf sehr detaillierter Ebene. Das Schema bietet eine serverinterne Ausführungsprüfung zur Laufzeit und kann als Hauptquelle für die Analyse von Datenbankleistungsproblemen dienen.

    performance_schema ist nicht standardmäßig mit Cloud SQL for MySQL aktiviert. Verwenden Sie das Befehlszeilentool gcloud, um das Schema zu aktivieren:

    gcloud sql instances patch INSTANCE_NAME --database-flags performance_schema=on
    

    Um diese Konfiguration abzuschließen, müssen Sie die Instanz neu starten. Sie können den Parameter --database-flags nicht über die Seite mit den Datenbank-Flags von Cloud SQL for MySQL in der Google Cloud Console ändern.

  • sys

    Das sys-Schema existiert in MySQL Version 5.5.7 und enthält hauptsächlich Ansichten der performance_schema-Systemtabellen. Dieses Schema bietet eine besser lesbare Gruppe von Ansichten, in denen performance_schema-Daten in einer leicht verständlichen Form zusammengefasst werden. Das sys-Schema enthält auch mehrere gespeicherte Verfahren und Funktionen, um Vorgänge wie die Konfiguration von performance_schema und die Generierung von Diagnoseberichten auszuführen.

    Das sys-Schema zeigt Informationen nur an, wenn performance_schema aktiviert ist.

Metadaten und dynamische Systemansichten ansehen

Dieser Abschnitt bietet eine Übersicht über einige der am häufigsten verwendeten Metadatentabellen und systemdynamischen Ansichten, die in Oracle verwendet werden, und die entsprechenden Datenbankobjekte in Cloud SQL for MySQL Version 5.7.

Oracle bietet Hunderte von Systemmetadatentabellen und -ansichten, während MySQL nur einige Dutzend enthält. Für jeden Fall kann es mehr als ein Datenbankobjekt geben, das einem bestimmten Zweck dient.

Oracle bietet mehrere Ebenen von Metadatenobjekten, die jeweils unterschiedliche Berechtigungen erfordern:

  • USER_TableName: Für den Nutzer sichtbar.
  • ALL_TableName: Für alle Nutzer sichtbar.
  • DBA_TableName: Für Nutzer mit DBA-Berechtigung wie SYS und SYSTEM sichtbar.

Für dynamische Leistungsansichten verwendet Oracle die Präfixe V$ und GV$. Damit ein MySQL-Nutzer Systemmetadatentabellen oder -ansichten anzeigen kann, benötigen sie bestimmte Berechtigungen für Systemobjekte. Weitere Informationen zur Sicherheit finden Sie im Abschnitt Sicherheit.

Metadatentyp Oracle-Tabelle/-Ansicht MySQL-Tabelle/-Ansicht/-Show (MySQL CMD)
Offene Sitzungen
V$SESSION
SHOW PROCESSLIST
INFORMATION_SCHEMA.PROCESSLIST
performance_schema.threads
Transaktionen ausführen
V$TRANSACTION
INFORMATION_SCHEMA.INNODB_TRX
Datenbankobjekte
DBA_OBJECTS
Nicht unterstützt. Fragen Sie jedes Objekt nach Typ ab.
Tabellen
DBA_TABLES
INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.INNODB_SYS_TABLES
Tabellenspalten
DBA_TAB_COLUMNS
INFORMATION_SCHEMA.COLUMNS
INFORMATION_SCHEMA.INNODB_SYS_COLUMNS
Berechtigungen für Tabellen und Spalten
TABLE_PRIVILEGES
DBA_COL_PRIVS
ROLE_TAB_PRIVS
INFORMATION_SCHEMA.COLUMN_PRIVILEGES
Partitionen
DBA_TAB_PARTITIONS
DBA_TAB_SUBPARTITIONS
INFORMATION_SCHEMA.PARTITIONS
SHOW CREATE TABLE TableName
SHOW TABLE STATUS LIKE 'TableName'
Aufrufe
DBA_VIEWS
INFORMATION_SCHEMA.VIEWS
Einschränkungen
DBA_CONSTRAINTS
INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS
SHOW CREATE TABLE TableName
Indexe
DBA_INDEXES
DBA_PART_INDEXES
INFORMATION_SCHEMA.STATISTICS
INFORMATION_SCHEMA.INNODB_SYS_INDEXES
INFORMATION_SCHEMA.KEY_COLUMN_USAGE
Materialisierte Ansichten
DBA_MVIEWS
Nicht unterstützt
Gespeicherte Prozeduren
DBA_PROCEDURES
INFORMATION_SCHEMA.ROUTINES
Gespeicherte Funktionen
DBA_PROCEDURES
INFORMATION_SCHEMA.ROUTINES
Trigger
DBA_TRIGGERS
INFORMATION_SCHEMA.TRIGGERS
Nutzer
DBA_USERS
mysql.user
Nutzerberechtigungen
DBA_SYS_PRIVS
DBA_ROLE_PRIVS
SESSION_PRIVS
INFORMATION_SCHEMA.USER_PRIVILEGES
Jobs/
Planer
DBA_JOBS
DBA_JOBS_RUNNING
DBA_SCHEDULER_JOBS
DBA_SCHEDULER_JOB_LOG
INFORMATION_SCHEMA.EVENTS
Tablespaces
DBA_TABLESPACES
INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES
Datendateien
DBA_DATA_FILES
INFORMATION_SCHEMA.FILES
INFORMATION_SCHEMA.INNODB_SYS_DATAFILES
Synonyme
DBA_SYNONYMS
Nicht unterstützt
Sequenzen
DBA_SEQUENCES
Nicht unterstützt
Datenbank-Links
DBA_DB_LINKS
Nicht unterstützt
Statistiken
DBA_TAB_STATISTICS
DBA_TAB_COL_STATISTICS
DBA_SQLTUNE_STATISTICS
DBA_CPU_USAGE_STATISTICS
INFORMATION_SCHEMA.STATISTICS
INFORMATION_SCHEMA.KEY_COLUMN_USAGE
SHOW INDEXES FROM TableName
Locks
DBA_LOCK
DBA_DDL_LOCKS
DBA_DML_LOCKS
V$SESSION_BLOCKERS
V$LOCKED_OBJECT
INFORMATION_SCHEMA.INNODB_LOCKS
INFORMATION_SCHEMA.INNODB_LOCK_WAITS
INFORMATION_SCHEMA.INNODB_TRX
performance_schema.metadata_locks
performance_schema.rwlock_instances
SHOW PROCESSLIST
Datenbankparameter
V$PARAMETER
V$NLS_PARAMETERS
SHOW PARAMETER Param
performance_schema.global_variables
performance_schema.session_variables
INFORMATION_SCHEMA.CHARACTER_SETS
SHOW VARIABLES LIKE '%variable%';
Segmente
DBA_SEGMENTS
Die Segmenttabelle wird nicht unterstützt. Fragen Sie jedes Objekt nach Typ ab.
Rollen
DBA_ROLES
DBA_ROLE_PRIVS
USER_ROLE_PRIVS
Roles not supported use instead:
information_schema.COLUMN_PRIVILEGES
information_schema.SCHEMA_PRIVILEGES
information_schema.TABLE_PRIVILEGES
information_schema.USER_PRIVILEGES
mysql.columns_priv
mysql.procs_priv
mysql.proxies_priv
mysql.tables_priv
Sitzungsverlauf
V$ACTIVE_SESSION_HISTORY
DBA_HIST_*
sys.statement_analysis
performance_schema.events_stages_history
performance_schema.events_stages_history_long
performance_schema.events_statements_history
performance_schema.events_statements_history_long
performance_schema.events_transactions_history
performance_schema.events_transactions_history_long
performance_schema.events_waits_history
performance_schema.events_waits_history_long
Version
V$VERSION
sys.version
SHOW VARIABLES LIKE '%version%';
Warteereignisse
V$WAITCLASSMETRIC
V$WAITCLASSMETRIC_HISTORY
V$WAITSTAT
V$WAIT_CHAINS
performance_schema.events_waits_current
performance_schema.events_waits_history
performance_schema.events_waits_history_long
sys.innodb_lock_waits
sys.io_global_by_wait_by_bytes
sys.io_global_by_wait_by_latency
sys.schema_table_lock_waits
sys.wait_classes_global_by_avg_latency
sys.wait_classes_global_by_latency
sys.waits_by_host_by_latency
sys.waits_by_user_by_latency
sys.waits_global_by_latency
SQL-Abstimmung und
Analyse
V$SQL
V$SQLAREA
V$SESS_IO
V$SYSSTAT
V$STATNAME
V$OSSTAT
V$ACTIVE_SESSION_HISTORY
V$SESSION_WAIT
V$SESSION_WAIT_CLASS
V$SYSTEM_WAIT_CLASS
V$LATCH
V$SYS_OPTIMIZER_ENV
V$SQL_PLAN
V$SQL_PLAN_STATISTICS
performance_schema.events_statements_current
performance_schema.events_statements_history
performance_schema.events_statements_history_long
sys.statement_analysis
sys.host_summary_by_statement_latency
sys.host_summary_by_statement_type
sys.statements_with_errors_or_warnings
sys.statements_with_full_table_scans
sys.statements_with_runtimes_in_95th_percentile
sys.statements_with_sorting
sys.statements_with_temp_tables
sys.user_summary_by_statement_latency
sys.user_summary_by_statement_type
slow-query-log
general-log
SHOW STATUS LIKE '%StatusName%';
Instanz
Arbeitsspeicheroptimierung
V$SGA
V$SGASTAT
V$SGAINFO
V$SGA_CURRENT_RESIZE_OPS
V$SGA_RESIZE_OPS
V$SGA_DYNAMIC_COMPONENTS
V$SGA_DYNAMIC_FREE_MEMORY
V$PGASTAT
information_schema.INNODB_CMPMEM_RESET
information_schema.INNODB_CMPMEM
performance_schema.memory_summary_by_account_by_event_name
performance_schema.memory_summary_by_host_by_event_name
performance_schema.memory_summary_by_thread_by_event_name
performance_schema.memory_summary_by_user_by_event_name
performance_schema.memory_summary_global_by_event_name
performance_schema.replication_group_member_stats
performance_schema.replication_group_members
sys.memory_by_host_by_current_bytes
sys.memory_by_thread_by_current_bytes
sys.memory_by_user_by_current_bytes
sys.memory_global_by_current_bytes
sys.memory_global_total

MySQL-Speicher-Engines

Im Gegensatz zu vielen anderen RDBMS (einschließlich Oracle) kann MySQL aufgrund seines steckbaren Speichersystems polymorphe Funktionen nutzen. Die MySQL-Plug-in-Speicher-Engine-Architektur ermöglicht es einem Datenbankadministrator, eine spezielle Speicher-Engine für eine bestimmte Anwendung auszuwählen.

Die MySQL-Plug-in-Speicherkomponente im MySQL-Datenbankserver ist für die Ausführung der E/A-Vorgänge verantwortlich, einschließlich der Speicherung der Daten in den Laufwerken oder Speicherpuffern. Die Plug-in-fähige Speicher-Engine-Architektur bietet einen Standardsatz von Verwaltungs- und Supportdiensten, die allen zugrunde liegenden Speicher-Engines gemeinsam sind.

Ab MySQL Version 5.5 ist die Standard-Speicher-Engine die InnoDB-Speicher-Engine, während InnoDB auch die temporären Tabellen verarbeitet. Sie können Speicher-Engines während der Tabelle CREATE oder ALTER wie im folgenden Beispiel konfigurieren:

mysql> SHOW CREATE TABLE JOBS \G;

Die Ausgabe sieht so aus:

*************************** 1. row ***************************
       Table: JOBS
Create Table: CREATE TABLE `JOBS` (
  `JOB_ID` varchar(10) NOT NULL,
  `JOB_TITLE` varchar(35) NOT NULL,
  `MIN_SALARY` decimal(6,0) DEFAULT NULL,
  `MAX_SALARY` decimal(6,0) DEFAULT NULL,
  PRIMARY KEY (`JOB_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Weitere Informationen finden Sie unter Verschiedene Speicher-Engines in MySQL.
Sie können die Konfiguration der Speicher-Engine mit der folgenden Abfrage aufrufen:

mysql> SHOW VARIABLES LIKE '%storage%';

Die Ausgabe sieht etwa so aus:

+----------------------------------+--------+
| Variable_name                    | Value  |
+----------------------------------+--------+
| default_storage_engine           | InnoDB |
| default_tmp_storage_engine       | InnoDB |
| disabled_storage_engines         |        |
| enforce_storage_engine           | Innodb |
| internal_tmp_disk_storage_engine | InnoDB |
+----------------------------------+--------+

Sie können sich alle integrierten Speicher-Engines ansehen:

mysql> SHOW STORAGE ENGINES;

Die Ausgabe sieht etwa so aus:

+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+

Beachten Sie, dass InnoDB die Standard-Speicher-Engine ist und die einzige Storage-Engine ist, die Transaktionen unterstützt (ACID-kompatibel). Da InnoDB die einzige Speicher-Engine ist, die sich der Oracle-Funktionalität annähert, empfehlen wir Ihnen, InnoDB immer zu verwenden. Cloud SQL for MySQL der zweiten Generation unterstützt nur die InnoDB-Speicher-Engine.

Systemparameter

Sowohl Oracle- als auch Cloud SQL for MySQL-Datenbanken können speziell konfiguriert werden, um bestimmte Funktionen über die Standardkonfiguration hinaus zu erreichen. Zum Ändern von Konfigurationsparametern in Oracle sind bestimmte Administratorberechtigungen erforderlich (vor allem die SYS/SYSTEM-Nutzerberechtigungen).

Das folgende Beispiel zeigt, wie Sie die Oracle-Konfiguration mit der Anweisung ALTER SYSTEM ändern. In diesem Beispiel ändert der Nutzer den Parameter "Maximale Anzahl fehlgeschlagener Anmeldeversuche" nur auf der Konfigurationsebene spfile (die Änderung gilt erst nach einem Neustart):

SQL> ALTER SYSTEM SET SEC_MAX_FAILED_LOGIN_ATTEMPTS=2 SCOPE=spfile;

Im nächsten Beispiel möchte der Nutzer einfach den Oracle-Parameterwert anzeigen:

SQL> SHOW PARAMETER SEC_MAX_FAILED_LOGIN_ATTEMPTS;

Die Ausgabe sieht etwa so aus:

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sec_max_failed_login_attempts        integer     2

Die Änderung des Oracle-Parameters funktioniert in drei Bereichen:

  • SPFILE: Parameteränderungen werden in das Oracle-spfile geschrieben, wobei ein Neustart der Instanz erforderlich ist, damit der Parameter wirksam wird.
  • SPEICHER: Parameteränderungen werden in der Speicherebene nur angewendet, wenn keine statischen Parameteränderungen zulässig sind.
  • BEIDE: Parameteränderungen werden sowohl in der Serverparameterdatei als auch im Instanzspeicher angewendet, wobei statische Parameteränderungen nicht zulässig sind.

Cloud SQL for MySQL-Konfigurations-Flags

Sie können die Systemparameter von Cloud SQL for MySQL mithilfe der Konfigurations-Flags in der Google Cloud Console, der gcloud CLI oder CURL ändern. Sehen Sie sich die vollständige Liste aller Parameter an, die von Cloud SQL for MySQL unterstützt werden und die Sie ändern können.

MySQL-Parameter können in mehrere Bereiche unterteilt werden:

  • Dynamische Parameter: Können während der Laufzeit geändert werden.
  • Statische Parameter: Damit die Instanz wirksam wird, muss sie neu gestartet werden.
  • Globale Parameter: Wirkt sich global auf alle aktuellen und zukünftigen Sitzungen aus.
  • Sitzungsparameter: Können auf Sitzungsebene nur für die aktuelle Sitzungsdauer geändert werden, getrennt von anderen Sitzungen.

Der Speicherparameter innodb_buffer_pool_size von Cloud SQL for MySQL ist einer der wichtigsten Parameter, die bei der Planung und Größenanpassung einer MySQL-Umgebung berücksichtigt werden. Er wird vom Instanztyp bestimmt und kann nicht mithilfe der Konfigurations-Flags oder mit einer anderen Methode geändert werden, z. B.:

  • Der Instanztyp db-n1-standard-1 hat eine Arbeitsspeicherzuordnung von 1,4 GB.
  • Der Instanztyp db-n1-highmem-8 hat eine Speicherzuordnung von 38 GB.

Beispiele für das Ändern von Cloud SQL for MySQL-Parametern

Console

Verwenden Sie die Google Cloud Console, um den Parameter event_scheduler zu aktivieren.

  1. Rufen Sie in Cloud Storage die Seite Instanz bearbeiten auf.

    Instanz bearbeiten

  2. Klicken Sie unter Flags auf Element hinzufügen und suchen Sie wie im folgenden Screenshot nach event_scheduler.

    Bearbeiten Sie die Ereignisplaner-Instanz in der Console.

gcloud

  • Verwenden Sie die gcloud CLI, um den Parameter event_scheduler zu aktivieren:

    gcloud sql instances patch INSTANCE_NAME \
        --database-flags event_scheduler=on
    

    Die Ausgabe sieht so aus:

    WARNING: This patch modifies database flag values, which may require
    your instance to be restarted. Check the list of supported flags -
    /sql/docs/mysql/flags - to see if your
    instance will be restarted when this patch is submitted.
    
    Do you want to continue (Y/n)?
    

MySQL-Sitzung

Deaktivieren Sie den AUTOCOMMIT-Modus auf Sitzungsebene. Diese Änderung gilt für die aktuelle Sitzung und gilt nur für die gesamte Lebensdauer der Sitzung.

  1. Variablen wie autocommit anzeigen:

    mysql> SHOW VARIABLES LIKE '%autoc%';
    

    Sie sehen die folgende Ausgabe, wobei autocommit ON ist:

    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | autocommit    | ON    |
    +---------------+-------+
    
  2. autocommit deaktivieren:

    mysql> SET autocommit=off;
    
  3. Variablen wie autocommit anzeigen:

    mysql> SHOW VARIABLES LIKE '%autoc%';
    

    Sie sehen die folgende Ausgabe, wobei autocommit OFF ist:

    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | autocommit    | OFF   |
    +---------------+-------+
    

Transaktionen und Isolationsebenen

In diesem Abschnitt werden die wichtigsten Unterschiede zwischen Oracle und Cloud SQL for MySQL für Migrationen auf Transaktions- und Isolationsebene beschrieben.

Commit-Modus

Oracle funktioniert standardmäßig im Nicht-Autocommit-Modus, in dem jede DML-Transaktion mit COMMIT/ROLLBACK-Anweisungen bestimmt werden muss. Einer der grundlegenden Unterschiede zwischen Oracle und MySQL besteht darin, dass MySQL standardmäßig im Autocommit-Modus arbeitet. Für jede DML-Transaktion wird mit expliziter Angabe der COMMIT/ROLLBACK-Anweisungen ein Auto-Commit durchgeführt.

Es gibt mehrere Möglichkeiten, MySQL in einem Modus ohne Autocommit zu erzwingen:

  • Verwenden Sie bei der Verwaltung von Transaktionen im Bereich gespeicherter Verfahren die START TRANSACTION-Klausel, um in denselben Transaktionsmodus wie in Oracle zu wechseln.
  • Verwenden Sie die folgende Anweisung, um den Systemparameter autocommit auf Sitzungsebene auf OFF zu setzen, und verwenden Sie explizit COMMIT/ROLLBACK-Anweisungen in DML-Transaktionen:

    mysql> SET autocommit=off;
    

Isolationsebenen

Der ANSI/ISO-SQL-Standard (SQL92) definiert vier Isolationsebenen. Jede Ebene bietet einen anderen Ansatz für die gleichzeitige Ausführung von Datenbanktransaktionen:

  • Lesevorgang ohne Commit: Eine aktuell verarbeitete Transaktion kann nicht festgelegte Daten der anderen Transaktion sehen. Wenn ein Rollback durchgeführt wird, werden alle Daten auf ihren vorherigen Zustand zurückgesetzt.
  • Lesevorgang mit Commit: Eine Transaktion sieht nur Datenänderungen, für die ein Commit durchgeführt wurde. Nicht festgeschriebene Änderungen ("fehlerhafte Lesevorgänge") sind nicht möglich.
  • Wiederholbarer Lesevorgang: Eine Transaktion kann Änderungen, die von der anderen Transaktion vorgenommen wurden, erst dann ansehen, wenn beide Transaktionen ein COMMIT ausgegeben haben oder wenn für beide ein Rollback durchgeführt wurde.
  • Serialisierbar: Die strengste/stärkste Isolationsebene. Auf dieser Ebene werden alle Datensätze, auf die zugegriffen wird, und die Ressource gesperrt, sodass keine Datensätze an die Tabelle angehängt werden können.

Transaktionsisolationsebenen verwalten die Sichtbarkeit von geänderten Daten für andere ausgeführte Transaktionen. Wenn mehrere Transaktionen gleichzeitig auf dieselben Daten zugreifen, wirkt sich die ausgewählte Transaktionsisolationebene auf die Interaktion verschiedener Transaktionen aus.

Oracle unterstützt die folgenden Isolationsebenen:

  • Lesevorgang mit Commit (Standard)
  • Serializable
  • Schreibgeschützt (nicht Teil des ANSI/ISO SQL-Standards (SQL92))

Oracle MVCC (Multiversion-Gleichzeitigkeitserkennung):

  • Oracle verwendet den MVCC-Mechanismus, um eine automatische Lesekonsistenz für die gesamte Datenbank und alle Sitzungen bereitzustellen.
  • Oracle verwendet die System Change Number (SCN) der aktuellen Transaktion, um eine konsistente Ansicht der Datenbank zu erhalten. Daher geben alle Datenbankabfragen nur Daten zurück, für die zum Zeitpunkt der Abfrageausführung in Bezug auf das SCN ein Commit durchgeführt wurde.
  • Die Isolationsebenen können auf Transaktions- und Sitzungsebene geändert werden.

Hier ein Beispiel für das Festlegen von Isolationsebenen:

-- Transaction Level
SQL> SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SQL> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SQL> SET TRANSACTION READ ONLY;

-- Session Level
SQL> ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE;
SQL> ALTER SESSION SET ISOLATION_LEVEL = READ COMMITTED;

Cloud SQL for MySQL unterstützt wie Oracle die folgenden vier Transaktionsisolationsebenen, die im ANSI-SQL:92-Standard angegeben sind.

  • READ UNCOMMITTED
  • READ COMMITTED
  • REPEATABLE READ (default)
  • SERIALIZABLE

Die standardmäßige Isolationsebene von Cloud SQL for MySQL ist REPEATABLE READ. Neue Daten sind erst dann für beide verfügbar, wenn beide Transaktionen den Befehl COMMIT ausführen. Diese Isolationsebenen können auf SESSION- und auf GLOBAL- Ebene geändert werden. Die globale Ebenenänderung befindet sich derzeit in der Betaphase und verwendet Konfigurations-Flags.

Verwenden Sie die folgende Anweisung, um die aktuellen Isolationsebenen sowohl auf SESSION- als auch auf GLOBAL- Ebene zu prüfen:

mysql> SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

Die Ausgabe sieht so aus:

+-----------------------+-----------------+
| @@GLOBAL.tx_isolation | @@tx_isolation  |
+-----------------------+-----------------+
| REPEATABLE-READ       | REPEATABLE-READ |
+-----------------------+-----------------+

Sie können die Syntax der Isolationsebene so ändern:

SET [SESSION] TRANSACTION ISOLATION LEVEL [READ WRITE | READ ONLY]
| REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED | SERIALIZABLE]

Und Sie können die Isolationsebene auf SESSION-Ebene ändern:

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

       -- Verify

mysql> SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

Die Ausgabe sieht so aus:

+-----------------------+------------------+
| @@GLOBAL.tx_isolation | @@tx_isolation   |
+-----------------------+------------------+
| REPEATABLE-READ       | READ-UNCOMMITTED |
+-----------------------+------------------+

Transaktionsstruktur in Cloud SQL for MySQL

Syntax für Transaktionen:

START TRANSACTION
    [transaction_characteristic [, transaction_characteristic] ...]

transaction_characteristic: { WITH CONSISTENT SNAPSHOT | READ WRITE | READ ONLY }
BEGIN [WORK] COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE] ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE] SET autocommit = {0 | 1}

Transaktionen können mit START TRANSACTION oder BEGIN implementiert werden.

Mit der Option WITH CONSISTENT SNAPSHOT wird eine konsistente READ-Transaktion gestartet. Dies entspricht im Grunde der Ausgabe eines START TRANSACTION, gefolgt von einem SELECT aus einer beliebigen Tabelle. Die WITH CONSISTENT SNAPSHOT-Klausel, die eine konsistente READ startet (ein READ-Vorgang, der Snapshot-Informationen verwendet, um Abfrageergebnisse basierend auf einem Zeitpunkt darzustellen), ändert die Transaktionsisolationsebene nicht und wird nur von der REPEATABLE READ-Isolationsebene unterstützt.

Ein konsistentes READ verwendet Snapshot-Informationen, um Abfrageergebnisse basierend auf einem Zeitpunkt verfügbar zu machen, unabhängig von Änderungen, die durch gleichzeitige Transaktionen vorgenommen werden. Wenn abgefragte Daten durch eine andere Transaktion geändert wurden, werden die ursprünglichen Daten mit dem Rückgängig-Log rekonstruiert. Dadurch werden Sperrprobleme vermieden, die die Gleichzeitigkeit reduzieren können.

Bei der Isolationsebene REPEATABLE READ basiert der Snapshot auf dem Zeitpunkt, zu dem der erste READ-Vorgang ausgeführt wird. Mit der Isolationsebene READ COMMITTED wird der Snapshot auf den Zeitpunkt jedes konsistenten READ-Vorgangs zurückgesetzt.

Hier ein Beispiel für eine Einstellung auf Transaktions- und Isolationsebene:

mysql> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
mysql> START TRANSACTION;
mysql> INSERT INTO tbl1 VALUES (1, 'A');
mysql> UPDATE tbl2 SET col1 = 'Done' WHERE KeyColumn = 1;
mysql> COMMIT;