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 :
- Migrer des utilisateurs Oracle vers Cloud SQL pour MySQL : terminologie et fonctionnalités (ce document)
- Migrer des utilisateurs Oracle vers Cloud SQL pour MySQL : types de données, utilisateurs et tables
- Migrer des utilisateurs Oracle vers Cloud SQL pour MySQL : requêtes, procédures stockées, fonctions et déclencheurs
- Migrer des utilisateurs Oracle vers Cloud SQL pour MySQL : sécurité, opérations, surveillance et journalisation
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 |
| 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/ |
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; 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.
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) :
-
La base de données système
mysqlcontient 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_SCHEMAsert 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. -
Base de données système qui collecte des informations statistiques sur l'instance MySQL. La base de données système
performance_schemacontient 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_scheman'est pas activé par défaut lorsque vous utilisez Cloud SQL pour MySQL. Pour l'activer, utilisez l'outil de ligne de commandegcloud: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-flagsen utilisant la page des options de base de données Cloud SQL pour MySQL dans la console Google Cloud. -
Le schéma
sysexiste dans MySQL version 5.5.7 et contient principalement des vues sur les tables systèmeperformance_schema. Ce schéma fournit un ensemble de vues plus lisible qui récapitule les donnéesperformance_schemasous une forme plus facile à comprendre. Le schémasyscontient également plusieurs procédures et fonctions stockées pour effectuer des opérations telles que la configuration deperformance_schemaet la génération de rapports de diagnostic.Le schéma
sysn'affiche des informations que lorsque le schémaperformance_schemaest 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 queSYSetSYSTEM.
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
spfiled'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-1dispose de 1,4 Go d'allocation de mémoire. - Le type d'instance
db-n1-highmem-8dispose 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.
Accédez à la page Modifier l'instance de Cloud Storage.
Sous Options, cliquez sur Ajouter un élément et recherchez
event_scheduler, comme dans la capture d'écran suivante.
gcloud
Utilisez la CLI gcloud pour activer le paramètre
event_scheduler:gcloud sql instances patch INSTANCE_NAME \ --database-flags event_scheduler=onLe 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.
Affichez les variables telles que
autocommit:mysql> SHOW VARIABLES LIKE '%autoc%';Le résultat suivant s'affiche, dans lequel
autocommitest défini surON:+---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | ON | +---------------+-------+
Désactivez
autocommit:mysql> SET autocommit=off;Affichez les variables telles que
autocommit:mysql> SHOW VARIABLES LIKE '%autoc%';Le résultat suivant s'affiche, dans lequel
autocommitest défini surOFF:+---------------+-------+ | 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 TRANSACTIONpour entrer dans le même mode transactionnel qu'Oracle. Utilisez l'instruction suivante pour définir le paramètre système
autocommitsurOFFau niveau de la session et utilisez explicitement les instructionsCOMMIT/ROLLBACKdans 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
COMMITou 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 UNCOMMITTEDREAD COMMITTEDREPEATABLE 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] ...]
|
|---|
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;