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 :

• 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

SYS
SYSTEM

USER_TableName
ALL_TableName
DBA_TableName

MYSQL
INFORMATION_SCHEMA
PERFORMANCE_SCHEMA
SYS

V$ViewName

INFORMATION_SCHEMA
PERFORMANCE_SCHEMA
SYS

mysqldump/mysqlimport

mysqlimport/
LOAD FILE INFILE

performance_schema

DBMS_SCHEDULER

EVENT_SCHEDULER

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

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

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;

mysql> CREATE DATABASE MYSQLDB;

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/';

mysql> CREATE DATABASE MYSQLDB;

SQL> SHOW is PDBS;

mysql> SHOW DATABASES;

SQL> ALTER SESSION SET CONTAINER=pdb;

mysql> use databaseName;

mysql> \u databaseName;

SQL> ALTER PLUGGABLE DATABASE pdb CLOSE;

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

• 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é.

V$SESSION

SHOW PROCESSLIST
INFORMATION_SCHEMA.PROCESSLIST
performance_schema.threads

V$TRANSACTION

INFORMATION_SCHEMA.INNODB_TRX

DBA_OBJECTS

DBA_TABLES

INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.INNODB_SYS_TABLES

DBA_TAB_COLUMNS

INFORMATION_SCHEMA.COLUMNS
INFORMATION_SCHEMA.INNODB_SYS_COLUMNS

TABLE_PRIVILEGES
DBA_COL_PRIVS
ROLE_TAB_PRIVS

INFORMATION_SCHEMA.COLUMN_PRIVILEGES

DBA_TAB_PARTITIONS
DBA_TAB_SUBPARTITIONS

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

DBA_VIEWS

INFORMATION_SCHEMA.VIEWS

DBA_CONSTRAINTS

INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS
SHOW CREATE TABLE TableName

DBA_INDEXES
DBA_PART_INDEXES

INFORMATION_SCHEMA.STATISTICS
INFORMATION_SCHEMA.INNODB_SYS_INDEXES
INFORMATION_SCHEMA.KEY_COLUMN_USAGE

DBA_MVIEWS

DBA_PROCEDURES

INFORMATION_SCHEMA.ROUTINES

DBA_PROCEDURES

INFORMATION_SCHEMA.ROUTINES

DBA_TRIGGERS

INFORMATION_SCHEMA.TRIGGERS

DBA_USERS

mysql.user

DBA_SYS_PRIVS
DBA_ROLE_PRIVS
SESSION_PRIVS

INFORMATION_SCHEMA.USER_PRIVILEGES

DBA_JOBS
DBA_JOBS_RUNNING
DBA_SCHEDULER_JOBS
DBA_SCHEDULER_JOB_LOG

INFORMATION_SCHEMA.EVENTS

DBA_TABLESPACES

INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES

DBA_DATA_FILES

INFORMATION_SCHEMA.FILES
INFORMATION_SCHEMA.INNODB_SYS_DATAFILES

DBA_SYNONYMS

DBA_SEQUENCES

DBA_DB_LINKS

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

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

V$PARAMETER
V$NLS_PARAMETERS
SHOW PARAMETER Param

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

DBA_SEGMENTS

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

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

V$VERSION

sys.version
SHOW VARIABLES LIKE '%version%';

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

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%';

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

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