Migrer des utilisateurs Oracle vers Cloud SQL pour MySQL : terminologie et fonctionnalités

Ce document fait partie d'une série qui fournit des informations et des conseils clés sur la planification et l'exécution des migrations de base de données Oracle® 11g/12c vers des instances Cloud SQL pour MySQL de deuxième génération, version 5.7. La série comprend les parties suivantes :

Terminologie

Cette section décrit les similitudes et les différences de terminologie entre les bases de données Oracle et Cloud SQL pour MySQL. Elle examine et compare les principaux aspects de chacune des plates-formes de base de données. La comparaison fait la distinction entre les versions 11g et 12c d'Oracle, en raison des différences architecturales (par exemple, Oracle 12c introduit la fonctionnalité de charge de travail mutualisée). La version Cloud SQL pour MySQL référencée ici est la version 5.7.x.

Différences de terminologie entre Oracle 11g et Cloud SQL pour MySQL

Oracle 11g Description Cloud SQL pour MySQL Différences majeures
Instance Une instance Oracle 11g ne peut contenir qu'une seule base de données. Instance Une instance MySQL peut contenir plusieurs bases de données.
Base de données Une base de données est considérée comme une instance unique (le nom de la base de données est identique au nom de l'instance). Base de données Les bases de données multiples ou uniques diffusent plusieurs applications.
Schéma Le schéma et les utilisateurs sont identiques, car ils sont considérés comme propriétaires d'objets de base de données (il est possible de créer un utilisateur sans spécifier de schéma ni attribuer celui-ci à un schéma). Schéma Un schéma est appelé "base de données", tandis que les objets de base de données sont créés sous un schéma/une base de données.
Utilisateur Identique au schéma, car les deux sont propriétaires d'objets de base de données, par exemple : instance → base de données → schémas/utilisateurs → objets de base de données. Utilisateur Un utilisateur de base de données disposant d'autorisations spécifiques pour se connecter ou modifier des objets de base de données sur des schémas/bases de données spécifiques, par exemple : instance → bases de données/schémas → objets de base de données.
Rôle Ensemble défini d'autorisations de base de données pouvant être associées en tant que groupe et attribuées aux utilisateurs de la base de données. Droits associés à MySQL MySQL 5.7 n'est pas compatible avec la gestion des rôles. Les autorisations peuvent être configurées à l'aide de la clause GRANT pour que les utilisateurs disposent de droits sur des objets de base de données à différents niveaux (LECTURE/ÉCRITURE, etc.).
Administrateurs/Utilisateurs système Administrateurs d'Oracle ayant le niveau d'accès le plus élevé :

SYS
SYSTEM
Super-utilisateurs Une fois déployé, Cloud SQL pour MySQL dispose de l'utilisateur root@'%' (qui peut se connecter depuis n'importe quel hôte) et d'un utilisateur supplémentaire appelé mysql.sys, qui ne peut se connecter que depuis l'hôte local.
Dictionnaire/métadonnées Oracle utilise les tables de métadonnées suivantes :

USER_TableName
ALL_TableName
DBA_TableName
Dictionnaire/métadonnées MySQL utilise plusieurs bases de données/schémas pour le dictionnaire/les métadonnées :

MYSQL
INFORMATION_SCHEMA
PERFORMANCE_SCHEMA
SYS
Chacune de ces bases de données est également une base de données système et est créée avec chaque déploiement Cloud SQL pour MySQL.
Vues dynamiques du système Vues dynamiques Oracle :

V$ViewName
Vues dynamiques du système Les vues dynamiques MySQL se trouvent dans plusieurs bases de données système :

INFORMATION_SCHEMA
PERFORMANCE_SCHEMA
SYS
Espace de table Principale structure de stockage logique des bases de données Oracle. Chaque espace de table peut contenir un ou plusieurs fichiers de données. Espace de table À l'instar d'Oracle, un espace de table MySQL est une unité logique, mais il ne représente qu'une seule table, contrairement à l'espace de table Oracle, qui peut contenir plusieurs fichiers de données (contient des données pour plusieurs tables).

MySQL permet de créer un espace de table avec un fichier de données alloué, puis de créer une table associée au nouvel espace de table. Notez que les paramètres de configuration des espaces de table, tels que le dimensionnement et les limites, sont définis à l'aide des paramètres de base de données et non lors de la création des espaces de table.
Fichiers de données Éléments physiques d'une base de données Oracle qui contiennent les données et sont définis sous un espace de table spécifique.

Un fichier de données est défini par sa taille initiale et sa taille maximale. Il peut contenir des données pour plusieurs tables.

Les fichiers de données Oracle utilisent le suffixe .dbf (pas obligatoire).		 Fichiers de données Cloud SQL pour MySQL utilise le paramètre innodb_file_per_table avec la valeur "ON" (par défaut). Cette configuration génère un nouveau fichier de données pour chaque table et un espace de table dédié.

Les fichiers de données MySQL utilisent des fichiers .ibd (données) et .frm (métadonnées).
Espace de table système Contient les tables du dictionnaire de données et affiche les objets de l'ensemble de la base de données Oracle. Espace de table système Comme pour Oracle, contient les tables de dictionnaire/métadonnées. Cet élément est stocké dans l'espace de table innodb_system associé au fichier de données ibdata1.
Espace de table temporaire Contient des objets de schéma valides pour la durée d'une session. Permet également d'exécuter des opérations qui ne peuvent pas tenir dans la mémoire du serveur. Espace de table temporaire Le but est ici identique à Oracle. Cet élément est stocké dans l'espace de table innodb_temporary MySQL associé au fichier de données ibtmp1.
Espace de table
d'annulation		 Type spécial d'espace de table système permanent utilisé par Oracle pour gérer les opérations de rollback lors de l'exécution de la base de données en mode de gestion d'annulation automatique (par défaut). Espace de table d'annulation À l'instar d'Oracle, l'espace de table d'annulation MySQL contient des journaux d'annulation à des fins de rollback. Par défaut, cette option est définie sur OFF et mentionnée comme obsolète pour les prochaines versions de MySQL.
ASM La gestion automatique de l'espace de stockage (ASM) d'Oracle est un système de fichiers de base de données et de gestion de disque intégré hautes performances qui s'exécute automatiquement via une base de données Oracle configurée avec ASM. Non compatible MySQL utilise le terme "moteurs de stockage" pour décrire différentes mises en œuvre de la gestion des données, mais n'est pas compatible avec ASM d'Oracle. Cloud SQL pour MySQL est compatible avec de nombreuses fonctionnalités d'automatisation du stockage, telles que l'augmentation automatique du stockage et des performances, ou encore le scaling automatisé.
Tables/vues Objets de base de données essentiels créés par l'utilisateur. Tables/vues Identique à Oracle.
Vues matérialisées Définies avec des instructions SQL spécifiques, elles peuvent être actualisées manuellement ou automatiquement en fonction de configurations spécifiques. Incompatible avec MySQL Pour contourner ce problème, vous pouvez utiliser des déclencheurs/vues au lieu des vues matérialisées Oracle.
Séquence Générateur de valeur unique Oracle. Incrémentation automatique MySQL n'est pas compatible avec les séquences Oracle. Utilisez le code AUTO_INCREMENT comme solution alternative à la fonctionnalité de génération automatique de séquences.
Synonyme Objets de base de données Oracle qui servent d'identifiants alternatifs pour d'autres objets de base de données. Non compatible MySQL n'est pas compatible avec les synonymes Oracle. Pour contourner ce problème, vous pouvez utiliser les vues en définissant les autorisations appropriées.
Partitionnement Oracle propose de nombreuses solutions de partitionnement pour diviser de grandes tables en plus petits éléments gérés. Partitionnement MySQL offre un nombre plus limité d'options de partitionnement afin d'améliorer les performances, tout en conservant les opérations de gestion et de maintenance des données, comme les partitions Oracle.
Base de données Flashback Fonctionnalité propriétaire développée par Oracle permettant d'initialiser une base de données Oracle à une heure prédéfinie, ce qui vous permet d'interroger ou de restaurer des données modifiées ou corrompues par erreur. Non compatible En tant que solution alternative, vous pouvez utiliser les sauvegardes Cloud SQL et la récupération à un moment précis pour restaurer une base de données à un état antérieur (par exemple, restaurer la base avant une suppression de table).
sqlplus Interface de ligne de commande Oracle qui vous permet d'interroger et de gérer l'instance de base de données. mysql Interface de ligne de commande MySQL équivalente pour les requêtes et la gestion. Peut être connectée depuis n'importe quel client disposant des autorisations appropriées pour Cloud SQL.
PL/SQL Langage procédural étendu d'Oracle pour ANSI SQL. MySQL MySQL dispose de son propre langage procédural étendu avec une syntaxe et une implémentation différentes, et n'a pas de nom supplémentaire pour ce langage étendu.
Packages et contenu des packages Fonctionnalité propre à Oracle permettant de regrouper les procédures et les fonctions stockées sous la même référence logique. Non compatible MySQL accepte les procédures et les fonctions stockées en tant qu'objets uniques avec l'allocation de groupes.
Procédures et fonctions stockées Utilise PL/SQL pour mettre en œuvre la fonctionnalité de code. Procédures et fonctions stockées La création de procédures et de fonctions stockées est prise en charge par MySQL via sa fonctionnalité de mise en œuvre de langage procédural propriétaire.
Déclencheur Objet Oracle permettant de contrôler la mise en œuvre du LMD sur les tables. Déclencheur Identique à Oracle.
PFILE/SPFILE Les paramètres de l'instance et de la base de données Oracle sont conservés dans un fichier binaire appelé SPFILE (dans les versions précédentes, il s'appelait PFILE), qui peut être utilisé comme fichier texte pour définir les paramètres manuellement. Options de base de données Cloud SQL pour MySQL Vous pouvez définir ou modifier des paramètres Cloud SQL pour MySQL via les options de base de données. Vous ne pouvez pas modifier les paramètres de base de données dans Cloud SQL pour MySQL à l'aide de l'interface de ligne de commande du client MySQL (par exemple, mysql> SET GLOBAL ...). Vous ne pouvez modifier ces paramètres qu'à l'aide des options de base de données.
SGA/PGA/AMM Paramètres de mémoire Oracle qui contrôlent l'allocation de mémoire à l'instance de base de données. INNODB_BUFFER_POOL_SIZE MySQL possède ses propres paramètres de mémoire. Un paramètre équivalent peut être INNODB_BUFFER_POOL_SIZE. Dans Cloud SQL pour MySQL, ce paramètre est prédéfini par le type d'instance choisi et la valeur change en conséquence.
Cache des résultats Réduit les opérations d'E/S SQL en récupérant les lignes du cache des tampons, lequel peut être géré à l'aide de paramètres de base de données et d'optimisations au niveau de la session. Cache de requêtes Ce cache a le même objectif de base que le cache des résultats Oracle et peut être géré au niveau de la base de données et de la session.
Optimisations de base de données Impact contrôlé sur les instructions SQL qui influencent le comportement de l'optimiseur afin d'obtenir de meilleures performances. Oracle dispose de plus de 50 optimisations de base de données différentes. Optimisations de base de données MySQL est compatible avec un ensemble limité d'optimisations de base de données par rapport à Oracle (optimiseur et index). Notez que MySQL utilise des optimisations de base de données, une syntaxe et des noms différents.
RMAN Gestionnaire de récupération de données Oracle. Utilisé pour effectuer des sauvegardes de base de données avec des fonctionnalités étendues afin de prendre en charge plusieurs scénarios de reprise après sinistre et plus encore (clonage, etc.). Sauvegarde Cloud SQL pour MySQL Cloud SQL pour MySQL propose deux méthodes pour effectuer une sauvegarde complète : les sauvegardes à la demande et automatisées.
Vidage de données (EXPDP/IMPDP) Utilitaire de génération de fichiers de vidage Oracle pouvant être utilisé pour de nombreuses fonctionnalités, telles que l'exportation/importation, la sauvegarde de base de données (au niveau du schéma ou de l'objet), les métadonnées de schéma, la génération de fichiers SQL de schéma, etc. 

mysqldump/mysqlimport
Utilitaire MySQL de vidage (exportation) qui peut être connecté en tant que client (à distance) et générer un fichier de vidage (SQL). Vous pouvez ensuite compresser le fichier de vidage et le déplacer vers Cloud Storage. L'utilitaire mysqldump est réservé à l'étape d'exportation.
Outil de chargement SQL Outil permettant d'importer des données à partir de fichiers externes tels que des fichiers texte, des fichiers CSV, etc. 

mysqlimport/
LOAD FILE INFILE
L'utilitaire mysqlimport offre la possibilité de charger des fichiers texte ou CSV (Oracle accepte d'autres formats de fichiers) dans une table de base de données avec une structure correspondante.
Protection des données Solution de reprise après sinistre Oracle utilisant une instance de secours. Elle permet aux utilisateurs d'effectuer des opérations de lecture à partir de l'instance de secours. Haute disponibilité et réplication Cloud SQL pour MySQL Pour les fonctionnalités de reprise après sinistre et de haute disponibilité, Cloud SQL pour MySQL propose l'architecture d'instance dupliquée de basculement et, pour les opérations en lecture seule (séparation LECTURE/ÉCRITURE), l'instance dupliquée avec accès en lecture.
Protection active des données/Golden Gate Les solutions de réplication principales d'Oracle, qui peuvent répondre à plusieurs besoins tels que les solutions de secours (DR), l'instance en lecture seule, la réplication bidirectionnelle (multisource), l'entreposage de données, etc. Instance dupliquée avec accès en lecture seule Cloud SQL pour MySQL Cloud SQL pour MySQL offre une fonctionnalité d'Instance dupliquée avec accès en lecture seule pour mettre en œuvre le clustering avec la séparation LECTURE/ÉCRITURE. Les configurations multisource, comme par exemple la réplication bidirectionnelle Golden Gate et la réplication hétérogène, ne sont pas prises en charge à l'heure actuelle.
RAC Oracle Real Application Cluster. Solution de clustering propriétaire développée par Oracle permettant de fournir une haute disponibilité en déployant plusieurs instances de base de données avec une seule unité de stockage. Non compatible L'architecture multisource n'est pas encore prise en charge dans Google Cloud SQL. Pour obtenir une architecture de clustering avec une séparation LECTURE/ÉCRITURE et une haute disponibilité, utilisez la haute disponibilité Cloud SQL et les instances dupliquées avec accès en lecture.
Grid/Cloud Control (OEM) Logiciel Oracle pour la gestion et la surveillance des bases de données et d'autres services associés présenté sous la forme d'une application Web. Cet outil est utile pour analyser des bases de données en temps réel afin de comprendre les charges de travail élevées. Console Cloud SQL pour MySQL, Cloud Monitoring Utilisez Cloud SQL pour MySQL pour la surveillance, notamment grâce à des graphiques détaillés basés sur l'heure et les ressources. Vous pouvez également utiliser Cloud Monitoring pour conserver des métriques de surveillance MySQL spécifiques et des analyses de journaux pour des fonctionnalités de surveillance avancées.
Journaux de RÉTABLISSEMENT Journaux de transaction Oracle comportant au moins deux fichiers définis pré-alloués qui stockent toutes les modifications de données au fur et à mesure qu'elles sont effectuées. L'objectif du journal de rétablissement est de protéger la base de données en cas de défaillance d'une instance. Journaux de RÉTABLISSEMENT MySQL dispose également de fichiers de journaux de rétablissement, qui sont utilisés lors de la reprise après plantage pour corriger les données écrites grâce à un mécanisme de rétablissement des transactions incomplètes.
Journaux d'archive Les journaux d'archive fournissent une assistance pour les opérations de sauvegarde et de réplication, entre autres. Si cette option est activée, Oracle écrit dans les journaux d'archive après chaque opération de changement de journal de rétablissement. binlogs Méthode MySQL de conservation des journaux de transaction. Utilisée principalement à des fins de réplication (activée par défaut avec Cloud SQL).
Fichier de contrôle Le fichier de contrôle Oracle contient des informations sur la base de données, telles que des fichiers de données, des noms et des emplacements de journaux de rétablissement, le numéro de séquence de journal actuel et des informations sur le point de contrôle de l'instance. MySQL L'architecture MySQL n'inclut pas de fichier de contrôle semblable à la méthode d'Oracle. Il est possible de contrôler ceci via les paramètres MySQL et la commande SHOW MASTER STATUS afin de visualiser la position actuelle du journal binaire.
SCN Le SCN (System Change Number) Oracle est le principal moyen de maintenir la cohérence des données dans tous les composants de base de données Oracle afin de satisfaire le modèle de transaction ACID. Numéro séquentiel dans le journal Pour la cohérence de la base de données, l'architecture MySQL utilise le numéro séquentiel du journal.
Rapport AWR Le rapport AWR (Automatic Workload Repository) d'Oracle est un rapport détaillé qui fournit des informations sur les performances des instances de base de données Oracle. Il est considéré comme un outil de diagnostic des performances. 

performance_schema
MySQL ne dispose pas d'un rapport équivalent à Oracle AWR, mais MySQL sauvegarde les données de performances collectées par performance_schema. Une autre solution consiste à utiliser les tableaux de bord de performances Workbench MySQL. 

DBMS_SCHEDULER
Utilitaire Oracle permettant de définir et de planifier des opérations. 

EVENT_SCHEDULER
Fonctionnalité de planification interne de la base de données MySQL Par défaut, cette fonctionnalité est définie sur OFF.
Chiffrement transparent des données Chiffrement des données stockées sur des disques pour la protection des données au repos. Norme AES (Advanced Encryption Standard) pour Cloud SQL Cloud SQL pour MySQL utilise la norme AES-256 (Advanced Encryption Standard) 256 bits pour la protection des données au repos et en transit.
Compression avancée Pour améliorer l'empreinte de stockage de la base de données, réduire les coûts de stockage et améliorer les performances, Oracle fournit des fonctionnalités avancées de compression des données (tables/index). Compression de tables InnoDB MySQL permet de compresser des tables. Pour ce faire, vous devez définir le paramètre ROW_FORMAT sur COMPRESSED lors de la création de votre table. En savoir plus sur la compression des index
SQL Developer Interface utilisateur graphique SQL gratuite d'Oracle pour la gestion et l'exécution des instructions SQL et PL/SQL (peut également être utilisée avec MySQL). MySQL Workbench Interface utilisateur graphique MySQL gratuite pour la gestion et l'exécution des instructions de code SQL et MySQL.
Journal d'alertes Journal principal pour les opérations générales et les erreurs de base de données Oracle. Journal d'erreurs MySQL Utilise la visionneuse de journaux de Cloud Logging pour l'affichage des journaux d'erreurs MySQL.
table DUAL Table spéciale Oracle contenant principalement des valeurs de pseudo-colonne telles que SYSDATE ou USER. Table DUAL MySQL permet de spécifier DUAL en tant que table dans les instructions SQL qui ne dépendent pas des données des tables.
Table externe Oracle permet aux utilisateurs de créer des tables externes contenant les données sources sur des fichiers en dehors de la base de données. Non compatible Aucun équivalent direct.
Écouteur Processus réseau Oracle chargé d'écouter les connexions à la base de données Réseaux autorisés par Cloud SQL MySQL accepte les connexions provenant de sources à distance sous condition que celles-ci soient autorisées sur la page de configuration des réseaux autorisés de Cloud SQL.
TNSNAMES Ce fichier de configuration réseau Oracle définit les adresses des base de données pour établir des connexions à l'aide d'alias de connexion. N'existe pas MySQL accepte les connexions externes utilisant le nom de connexion de l'instance Cloud SQL ou l'adresse IP privée/publique. Le proxy Cloud SQL est une méthode d'accès sécurisé supplémentaire permettant de se connecter à Cloud SQL pour MySQL (instances de deuxième génération) sans avoir à autoriser d'adresses IP spécifiques ni à configurer SSL.
Port par défaut de l'instance 1521 Port par défaut de l'instance 3306
Lien vers la base de données Objet de schéma Oracle qui peut être utilisé pour interagir avec des objets de base de données locaux/distants. Non compatible Pour contourner ce problème, utilisez le code d'application permettant de se connecter et de récupérer des données à partir d'une base de données distante.

Différences de terminologie entre Oracle 12c et Cloud SQL pour MySQL

Oracle 12c Description Cloud SQL pour MySQL Différences majeures
Instance Capacité de mutualisation introduite dans l'instance Oracle 12c, laquelle peut contenir plusieurs bases de données sous la forme d'une base de données connectable (PDB), contrairement à la version 11g, où une instance Oracle ne peut obtenir qu'une seule base de données. Instance Cloud SQL pour MySQL peut contenir plusieurs bases de données avec des noms différents pour plusieurs services et applications.
CDB Une base de données de conteneurs mutualisés (CDB) peut prendre en charge une ou plusieurs PDB, tandis que des objets CDB globaux (affectant toutes les PDB) peuvent être créés, par exemple des rôles. Instance MySQL L'instance MySQL est comparable à la CDB d'Oracle. Les deux fournissent une couche système pour les PDB.
PDB Les PDB (bases de données connectables) peuvent être utilisées pour isoler les services et les applications et en tant qu'ensembles portables de schémas. Bases de données/schémas MySQL Une base de données MySQL peut diffuser plusieurs services et applications et desservir de nombreux utilisateurs de base de données.
Séquences de session À partir de la version Oracle 12c, vous pouvez créer des séquences au niveau de la session (renvoyer des valeurs uniques dans une session) ou au niveau global (par exemple, lorsque vous utilisez des tables temporaires). Incrémentation
automatique		 Les séquences ne sont pas compatibles avec MySQL, mais il est possible d'utiliser la propriété de colonne AUTO_INCREMENT comme solution alternative.
Colonnes d'identité Le type IDENTITY Oracle 12c génère une séquence et l'associe à une colonne de table sans qu'il soit nécessaire de créer manuellement un objet de séquence distinct. Incrémentation automatique Utilisez la propriété de colonne AUTO_INCREMENT pour simuler les mêmes fonctionnalités que la colonne d'identité Oracle 12c (solution alternative à la fonctionnalité de génération automatique de séquences).
Segmentation Solution dans laquelle une base de données Oracle est partitionnée en plusieurs bases de données plus petites (segments) pour permettre l'évolutivité, la disponibilité et la géolocalisation des environnements OLTP. Non compatible (en tant que fonctionnalité) MySQL ne dispose pas d'une fonctionnalité de segmentation équivalente. La segmentation peut être mise en œuvre en associant MySQL (en tant que plate-forme de données) avec une couche d'application compatible.
Base de données en mémoire Oracle propose une suite de fonctionnalités permettant d'améliorer les performances de la base de données pour les charges de travail OLTP et les charges de travail mixtes. Non compatible MySQL ne dispose pas d'une fonctionnalité équivalente. Vous pouvez utiliser Memorystore comme alternative.
Masquage Dans le cadre des fonctionnalités de sécurité avancées d'Oracle, le masquage des colonnes peut empêcher l'affichage des données sensibles par les utilisateurs et les applications. Non compatible MySQL ne dispose pas d'une fonctionnalité équivalente.

Fonctionnalité

Bien que les bases de données Oracle 11g/12c et Cloud SQL pour MySQL fonctionnent sur différentes architectures (infrastructure et langages procéduraux étendus), elles possèdent les mêmes aspects fondamentaux qu'une base de données relationnelle. Elles sont compatibles avec les objets de base de données, les charges de travail multi-utilisateur simultanées et les transactions (compatibilité ACID). Elles gèrent également les fonctionnalités de verrouillage qui prennent en charge plusieurs niveaux d'isolation (en fonction des besoins de l'entreprise) et répondent aux exigences des applications en tant que magasin de données relationnel pour les opérations de traitement transactionnel en ligne (OTLP) et le traitement analytique en ligne (OLAP).

La section suivante présente certaines des principales différences fonctionnelles entre Oracle et Cloud SQL pour MySQL. Dans certains cas, si nécessaire, la section inclut des comparaisons techniques détaillées.

Créer et afficher des bases de données

Oracle 11g/12c Cloud SQL pour MySQL 5.7
Généralement, vous créez des bases de données et consultez celles qui existent déjà à l'aide de l'assistant de configuration de bases de données Oracle. Les bases de données ou instances créées manuellement nécessitent la spécification de paramètres supplémentaires :

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;
Utilisez une instruction au format CREATE DATABASE Name;, comme dans cet exemple :

mysql> CREATE DATABASE MYSQLDB;
Oracle 12c Cloud SQL pour MySQL 5.7
Dans Oracle 12c, vous pouvez créer des bases de données connectables (PDB) à partir d'un modèle de base de données de conteneurs (CDB) ou en clonant une PDB à partir d'une PDB existante. Vous devez utilisez plusieurs paramètres :


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/';
Utilisez une instruction au format CREATE DATABASE Name;, comme dans cet exemple :

mysql> CREATE DATABASE MYSQLDB;
Répertoriez toutes les PDB :

SQL> SHOW is PDBS;
Répertoriez toutes les bases de données existantes :

mysql> SHOW DATABASES;
Connectez-vous à une autre PDB :

SQL> ALTER SESSION SET CONTAINER=pdb;
Connectez-vous à une autre base de données :

mysql> use databaseName;
Ou :

mysql> \u databaseName;
Ouvrez ou fermez une PDB spécifique (ouverte/en lecture seule) :

SQL> ALTER PLUGGABLE DATABASE pdb CLOSE;
Non compatible avec une base de données unique.

Toutes les bases de données se trouvent dans la même instance Cloud SQL pour MySQL. Par conséquent, toutes les bases de données sont soit actives, soit inactives.

Gérer une base de données via la console Cloud SQL

  • Dans la console Google Cloud, accédez à Stockage > SQL > Instance > Bases de données > Afficher/Créer.

    Page de la console pour créer/afficher une base de données MySQL.

Bases de données système et schémas

Les instances de base de données Oracle obtiennent certains schémas système (par exemple, SYS/SYSTEM) avec le rôle de propriétaire des objets de métadonnées d'une base de données.

En revanche, MySQL contient plusieurs bases de données système (contrairement aux schémas Oracle), qui diffusent la couche de métadonnées (notez que les noms de base de données sont sensibles à la casse) :

  • Mysql

    La base de données système mysql contient des tables qui stockent les informations requises par le serveur MySQL lors de son exécution, telles que :

    • Tables des droits système
    • Tables d'informations sur les objets
    • Tables du système de journalisation
    • Tables du système de réplication
    • Tables du système d'optimisation
    • Tables du système de fuseau horaire

  • INFORMATION_SCHEMA

    INFORMATION_SCHEMA sert de dictionnaire de données pour la base de données principale et de catalogue système. Il permet d'accéder aux métadonnées de la base de données, qui sont des informations de base de données internes sur le serveur MySQL, telles que le nom d'une base de données ou d'une table, le type de données de la colonne et les droits d'accès.

  • performance_schema

    Base de données système qui collecte des informations statistiques sur l'instance MySQL. La base de données système performance_schema contient des métriques pour la surveillance de l'exécution du serveur à un niveau très précis. Le schéma fournit une vérification de l'exécution interne du serveur au moment de l'exécution et peut servir de source principale pour analyser les problèmes de performances de la base de données.

    Le schéma performance_schema n'est pas activé par défaut lorsque vous utilisez Cloud SQL pour MySQL. Pour l'activer, utilisez l'outil de ligne de commande gcloud :

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

    Pour terminer cette configuration, vous devez redémarrer l'instance. Vous ne pouvez pas modifier le paramètre --database-flags en utilisant la page des options de base de données Cloud SQL pour MySQL dans la console Google Cloud.

  • sys

    Le schéma sys existe dans MySQL version 5.5.7 et contient principalement des vues sur les tables système performance_schema. Ce schéma fournit un ensemble de vues plus lisible qui récapitule les données performance_schema sous une forme plus facile à comprendre. Le schéma sys contient également plusieurs procédures et fonctions stockées pour effectuer des opérations telles que la configuration de performance_schema et la génération de rapports de diagnostic.

    Le schéma sys n'affiche des informations que lorsque le schéma performance_schema est activé.

Afficher les métadonnées et les vues dynamiques du système

Cette section présente les principales tables de métadonnées et vues dynamiques du système utilisées dans Oracle, ainsi que les objets de base de données correspondants dans Cloud SQL pour MySQL version 5.7.

Oracle fournit des centaines de tables et de vues de métadonnées système, tandis que MySQL n'en contient que quelques dizaines. Pour chaque cas, il peut y avoir plusieurs objets de base de données, avec un objectif spécifique.

Oracle fournit plusieurs niveaux d'objets de métadonnées, chacun nécessitant des droits différents :

  • USER_TableName : visible par l'utilisateur.
  • ALL_TableName : visible par tous les utilisateurs.
  • DBA_TableName : visible uniquement par les utilisateurs disposant du droit DBA, tels que SYS et SYSTEM.

Pour les vues de performances dynamiques, Oracle utilise les préfixes V$ et GV$. Pour qu'un utilisateur MySQL puisse afficher des tables ou des vues de métadonnées système, il doit disposer d'autorisations spécifiques sur les objets système. Pour en savoir plus sur la sécurité, consultez la section Sécurité.

Type de métadonnées Table/vue Oracle Table/vue/affichage MySQL (MySQL CMD)
Sessions ouvertes 

V$SESSION


SHOW PROCESSLIST
INFORMATION_SCHEMA.PROCESSLIST
performance_schema.threads
Exécution de transactions 

V$TRANSACTION


INFORMATION_SCHEMA.INNODB_TRX
Objets de base de données 

DBA_OBJECTS
Non compatible. Interrogez chaque objet par son type.
Tables 

DBA_TABLES


INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.INNODB_SYS_TABLES
Colonnes de table 

DBA_TAB_COLUMNS


INFORMATION_SCHEMA.COLUMNS
INFORMATION_SCHEMA.INNODB_SYS_COLUMNS
Droits sur les tables et colonnes 

TABLE_PRIVILEGES
DBA_COL_PRIVS
ROLE_TAB_PRIVS


INFORMATION_SCHEMA.COLUMN_PRIVILEGES
Partitions 

DBA_TAB_PARTITIONS
DBA_TAB_SUBPARTITIONS


INFORMATION_SCHEMA.PARTITIONS
SHOW CREATE TABLE TableName
SHOW TABLE STATUS LIKE 'TableName'
Vues 

DBA_VIEWS


INFORMATION_SCHEMA.VIEWS
Contraintes 

DBA_CONSTRAINTS


INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS
SHOW CREATE TABLE TableName
Index 

DBA_INDEXES
DBA_PART_INDEXES


INFORMATION_SCHEMA.STATISTICS
INFORMATION_SCHEMA.INNODB_SYS_INDEXES
INFORMATION_SCHEMA.KEY_COLUMN_USAGE
Vues matérialisées 

DBA_MVIEWS
Non compatible
Procédures stockées 

DBA_PROCEDURES


INFORMATION_SCHEMA.ROUTINES
Fonctions stockées 

DBA_PROCEDURES


INFORMATION_SCHEMA.ROUTINES
Déclencheurs 

DBA_TRIGGERS


INFORMATION_SCHEMA.TRIGGERS
Utilisateurs 

DBA_USERS


mysql.user
Droits d'utilisateur 

DBA_SYS_PRIVS
DBA_ROLE_PRIVS
SESSION_PRIVS


INFORMATION_SCHEMA.USER_PRIVILEGES
{Tâches/
Programmeur		 

DBA_JOBS
DBA_JOBS_RUNNING
DBA_SCHEDULER_JOBS
DBA_SCHEDULER_JOB_LOG


INFORMATION_SCHEMA.EVENTS
Espaces de table 

DBA_TABLESPACES


INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES
Fichiers de données 

DBA_DATA_FILES


INFORMATION_SCHEMA.FILES
INFORMATION_SCHEMA.INNODB_SYS_DATAFILES
Synonymes 

DBA_SYNONYMS
Non compatible
Séquences 

DBA_SEQUENCES
Non compatible
Liens de base de données 

DBA_DB_LINKS
Non compatible
Statistiques 

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
Verrous 

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
Paramètres de base de données 

V$PARAMETER
V$NLS_PARAMETERS
SHOW PARAMETER Param


performance_schema.global_variables
performance_schema.session_variables
INFORMATION_SCHEMA.CHARACTER_SETS
SHOW VARIABLES LIKE '%variable%';
Segments 

DBA_SEGMENTS
La table des segments n'est pas compatible. Interrogez chaque objet par son type.
Rôles 

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
Historique des sessions 

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%';
Événements d'attente 

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
Optimisation et
analyse SQL		 

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%';
Réglage de la mémoire
de l'instance		 

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

Moteurs de stockage MySQL

Contrairement à de nombreux autres SGBDR (y compris ceux d'Oracle), MySQL peut fonctionner de manière polymorphe grâce à son système de stockage connectable. L'architecture du moteur de stockage connectable MySQL permet à un administrateur de base de données de sélectionner un moteur de stockage spécialisé pour un besoin d'application spécifique.

Le composant du moteur de stockage connectable MySQL du serveur de base de données MySQL est chargé d'effectuer les opérations d'E/S de données, y compris le stockage des données sur les disques ou la mémoire tampon. L'architecture du moteur de stockage connectable fournit un ensemble standard de services de gestion et d'assistance communs à tous les moteurs de stockage sous-jacents.

À partir de la version MySQL 5.5 (et versions ultérieures), le moteur de stockage par défaut est le moteur InnoDB. InnoDB gère également les tables temporaires. Vous pouvez configurer des moteurs de stockage lors d'une opération CREATE ou ALTER sur une table, comme dans l'exemple suivant :

mysql> SHOW CREATE TABLE JOBS \G;

Le résultat est le suivant :

*************************** 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

Pour en savoir plus, consultez la section présentant les différents moteurs de stockage MySQL.
Vous pouvez afficher la configuration du moteur de stockage à l'aide de la requête suivante :

mysql> SHOW VARIABLES LIKE '%storage%';

Le résultat ressemble à ce qui suit :

+----------------------------------+--------+
| 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 |
+----------------------------------+--------+

Vous pouvez afficher tous les moteurs de stockage intégrés :

mysql> SHOW STORAGE ENGINES;

Le résultat ressemble à ce qui suit :

+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| 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        |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+

Notez qu'InnoDB est le moteur de stockage par défaut, et le seul qui soit compatible avec les transactions ACID. Étant donné qu'InnoDB est le seul moteur de stockage qui se rapproche des fonctionnalités d'Oracle, nous vous recommandons de l'utiliser à chaque fois. Cloud SQL pour MySQL deuxième génération n'est compatible qu'avec le moteur de stockage InnoDB.

Paramètres système

Les bases de données Oracle et Cloud SQL pour MySQL peuvent être spécifiquement configurées pour offrir certaines fonctionnalités non disponibles avec la configuration par défaut. Pour modifier les paramètres de configuration dans Oracle, certaines autorisations d'administration sont requises (principalement les autorisations utilisateur SYS/SYSTEM).

Voici un exemple de modification de la configuration Oracle à l'aide de l'instruction ALTER SYSTEM. Dans cet exemple, l'utilisateur modifie le paramètre "Nombre maximal d'échecs de connexion" au niveau de la configuration spfile (la modification n'est valide qu'après un redémarrage) :

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

Dans l'exemple suivant, l'utilisateur demande simplement à afficher la valeur du paramètre Oracle :

SQL> SHOW PARAMETER SEC_MAX_FAILED_LOGIN_ATTEMPTS;

Le résultat ressemble à ce qui suit :

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

La modification du paramètre Oracle fonctionne dans trois champs d'application :

  • SPFILE : les modifications de paramètres sont écrites dans le fichier spfile d'Oracle. Un redémarrage de l'instance est nécessaire pour que le changement prenne effet.
  • MÉMOIRE : les modifications de paramètres ne sont appliquées à la couche mémoire que lorsqu'aucun changement de paramètre statique n'est autorisé.
  • LES DEUX : les modifications de paramètres sont appliquées à la fois dans le fichier de paramètres du serveur et dans la mémoire de l'instance, où aucun changement de paramètre statique n'est autorisé.

Options de configuration de Cloud SQL pour MySQL

Vous pouvez modifier les paramètres système de Cloud SQL pour MySQL à l'aide des options de configuration dans la console Google Cloud, gloud CLI ou CURL. Consultez la liste complète des paramètres acceptés par Cloud SQL pour MySQL que vous pouvez modifier.

Les paramètres MySQL peuvent être divisés en plusieurs catégories :

  • Paramètres dynamiques : ces éléments peuvent être modifiés lors de l'exécution de la base de données.
  • Paramètres statiques : un redémarrage de l'instance est nécessaire pour que la modification prenne effet.
  • Paramètres globaux : ces éléments ont un effet global sur toutes les sessions en cours et à venir.
  • Paramètres de session : ces éléments ne peuvent être modifiés au niveau de la session que pour la durée de la session en cours, et sont exclus des autres sessions.

Le paramètre de mémoire Cloud SQL pour MySQL innodb_buffer_pool_size (l'un des paramètres essentiels à prendre en compte lors de la planification et du dimensionnement d'un environnement MySQL) est déterminé par le type d'instance et ne peut pas être modifié à l'aide des options de configuration ou d'une autre méthode, par exemple :

  • Le type d'instance db-n1-standard-1 dispose de 1,4 Go d'allocation de mémoire.
  • Le type d'instance db-n1-highmem-8 dispose de 38 Go d'allocation de mémoire.

Exemples de modification des paramètres Cloud SQL pour MySQL

Console

Utilisez la console Google Cloud pour activer le paramètre event_scheduler.

  1. Accédez à la page Modifier l'instance de Cloud Storage.

    Accéder à la page Modifier l'instance

  2. Sous Options, cliquez sur Ajouter un élément et recherchez event_scheduler, comme dans la capture d'écran suivante.

    Modifiez l'instance du planificateur d'événements dans la console.

gcloud

  • Utilisez la CLI gcloud pour activer le paramètre event_scheduler :

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

    Le résultat est le suivant :

    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)?

Session MySQL

Désactivez le mode AUTOCOMMIT au niveau de la session. Cette modification reste en vigueur pour la session en cours et ne s'applique qu'à la durée de cette session.

  1. Affichez les variables telles que autocommit :

    mysql> SHOW VARIABLES LIKE '%autoc%';

    Le résultat suivant s'affiche, dans lequel autocommit est défini sur ON :

    +---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+

  2. Désactivez autocommit :

    mysql> SET autocommit=off;

  3. Affichez les variables telles que autocommit :

    mysql> SHOW VARIABLES LIKE '%autoc%';

    Le résultat suivant s'affiche, dans lequel autocommit est défini sur OFF :

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

Transactions et niveaux d'isolation

Cette section décrit les principales différences entre Oracle et Cloud SQL pour MySQL en ce qui concerne les migrations des transactions et des niveaux d'isolation.

Mode de commit

Par défaut, Oracle ne fonctionne pas en mode autocommit, ce qui signifie que chaque transaction LMD doit être déterminée à l'aide d'instructions COMMIT/ROLLBACK. L'une des principales différences entre Oracle et MySQL est que MySQL fonctionne par défaut en mode autocommit et que chaque transaction LMD est envoyée automatiquement en spécifiant explicitement les instructions COMMIT/ROLLBACK.

Pour forcer MySQL à ne pas fonctionner en mode autocommit, plusieurs options s'offrent à vous :

  • Lorsque vous gérez des transactions dans le cadre de procédures stockées, utilisez la clause START TRANSACTION pour entrer dans le même mode transactionnel qu'Oracle.

  • Utilisez l'instruction suivante pour définir le paramètre système autocommit sur OFF au niveau de la session et utilisez explicitement les instructions COMMIT/ROLLBACK dans les transactions LMD :

    mysql> SET autocommit=off;

Niveaux d'isolation

La norme SQL ANSI/ISO (SQL92) définit quatre niveaux d'isolation. Chaque niveau fournit une approche différente pour gérer l'exécution simultanée de transactions de base de données :

  • Read Uncommitted : une transaction en cours de traitement peut afficher les données non validées générées par l'autre transaction. Si un rollback est effectué, toutes les données sont restaurées à leur état précédent.
  • Read Committed : une transaction ne voit que les modifications de données validées. Les modifications non validées ("lectures sales") ne sont pas possibles.
  • Repeatable Read : une transaction ne peut afficher les modifications apportées par l'autre transaction qu'une fois que les deux transactions ont émis un COMMIT ou que les deux ont été annulées.
  • Serializable : niveau d'isolation le plus strict et contraignant. Ce niveau verrouille tous les enregistrements accessibles et la ressource afin que les enregistrements ne puissent pas être ajoutés à la table.

Les niveaux d'isolation des transactions gèrent la la façon dont les données modifiées peuvent être vues par les autres transactions en cours d'exécution. En outre, lorsque plusieurs transactions simultanées accèdent aux mêmes données, le niveau d'isolation sélectionné affecte la manière dont les différentes transactions interagissent.

Oracle est compatible avec les niveaux d'isolation suivants :

  • Read Committed (par défaut)
  • Serializable
  • Lecture seule (ne fait pas partie de la norme SQL ANSI/ISO (SQL92)

Contrôle de simultanéité multiversion Oracle (MVCC, Multiversion Concurrence Control) :

  • Oracle utilise le mécanisme MVCC pour fournir une cohérence de lecture automatique sur l'ensemble de la base de données et des sessions.
  • Oracle s'appuie sur le numéro de modification du système (SCN, System Change Number) de la transaction actuelle pour obtenir une vue cohérente de la base de données. Par conséquent, toutes les requêtes de base de données ne renvoient que des données validées par rapport au SCN au moment de l'exécution de la requête.
  • Les niveaux d'isolation peuvent être modifiés au niveau des transactions et des sessions.

Voici un exemple de définition de niveaux d'isolation :

-- 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 pour MySQL, comme Oracle, est compatible avec les quatre niveaux d'isolation des transactions suivants, spécifiés dans la norme ANSI SQL:92 :

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

Le niveau d'isolation par défaut de Cloud SQL pour MySQL est REPEATABLE READ. Les nouvelles données ne seront disponibles pour les deux transactions qu'une fois que ces dernières auront émis une commande COMMIT. Ces niveaux d'isolation peuvent être modifiés au niveau de la SESSION et au niveau GLOBAL (la modification globale est actuellement en phase bêta et utilise des options de configuration).

Pour vérifier les niveaux d'isolation actuels au niveau de la SESSION et au niveau GLOBAL, utilisez l'instruction suivante :

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

Le résultat est le suivant :

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

Vous pouvez modifier la syntaxe du niveau d'isolation comme suit :

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

Vous pouvez également modifier le niveau d'isolation au niveau de la SESSION :

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

       -- Verify

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

Le résultat est le suivant :

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

Structure des transactions Cloud SQL pour MySQL

Syntaxe des transactions :


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}

Les transactions peuvent être mises en œuvre avec START TRANSACTION ou BEGIN.

L'option WITH CONSISTENT SNAPSHOT démarre une transaction READ cohérente, ce qui revient à émettre l'option START TRANSACTION suivie de SELECT à partir de n'importe quelle table. La clause WITH CONSISTENT SNAPSHOT qui démarre une opération READ cohérente (READ qui utilise des informations d'instantané pour présenter les résultats de la requête en fonction d'un moment précis) ne modifie pas le niveau d'isolation des transactions et n'est compatible qu'avec le niveau d'isolation REPEATABLE READ.

Une opération READ cohérente utilise des informations d'instantané pour rendre les résultats de la requête disponibles en fonction d'un moment précis, quelles que soient les modifications effectuées par des transactions simultanées. Si les données interrogées ont été modifiées par une autre transaction, les données d'origine sont reconstruites à l'aide du journal d'annulation. Vous éviterez ainsi les problèmes de verrouillage susceptibles de réduire la simultanéité.

Avec le niveau d'isolation REPEATABLE READ, l'instantané est basé sur l'heure à laquelle la première opération READ est effectuée. Avec le niveau d'isolation READ COMMITTED, l'instantané est réinitialisé à l'heure de chaque opération READ cohérente.

Voici un exemple de paramètre de transaction et de niveau d'isolation :

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;