Migra usuarios de Oracle a Cloud SQL para MySQL: terminología y funcionalidad

Este documento es parte de una serie que proporciona información clave y orientación relacionada con la planificación y la realización de migraciones de bases de datos de Oracle® 11g o 12c a instancias de segunda generación con versión 5.7 de Cloud SQL para MySQL. En la serie, se incluyen las siguientes partes:

• Migra usuarios de Oracle a Cloud SQL para MySQL: terminología y funcionalidad (este documento)
• Migra usuarios de Oracle a Cloud SQL para MySQL: tipos de datos, usuarios y tablas
• Migra usuarios de Oracle a Cloud SQL para MySQL: consultas, procedimientos almacenados, funciones y activadores
• Migra usuarios de Oracle a Cloud SQL para MySQL: seguridad, operaciones, supervisión y registro

Terminología

En esta sección, se detallan las similitudes y las diferencias en la terminología de la base de datos entre Oracle y Cloud SQL para MySQL. Revisa y compara los aspectos principales de cada una de las plataformas de bases de datos. En la comparación, se hace una distinción entre las versiones 11g y 12c de Oracle debido a diferencias arquitectónicas (por ejemplo, Oracle 12c presenta la característica de multiusuarios). La versión de Cloud SQL para MySQL a la que se hace referencia aquí es la 5.7.x.

Diferencias en la terminología entre Oracle 11g y Cloud SQL para 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

Diferencias en la terminología entre Oracle 12c y Cloud SQL para MySQL

Funcionalidad

Aunque las bases de datos de Oracle 11g o 12c y Cloud SQL para MySQL funcionan en diferentes arquitecturas (infraestructura y lenguajes de procedimiento extendidos), comparten los mismos aspectos fundamentales de las bases de datos relacionales. Admiten objetos de base de datos, cargas de trabajo de simultaneidad multiusuario y transacciones (compatibilidad con ACID). También administran las contenciones de bloqueo que admiten varios niveles de aislamiento (según las necesidades de la empresa) y cumplen con los requisitos de aplicaciones actuales como un almacén de datos relacional para operaciones de transacción en línea (OLTP) y procesamiento analítico en línea (OLAP).

En la siguiente sección, se proporciona una descripción general de algunas de las principales diferencias funcionales entre Oracle y Cloud SQL para MySQL. En algunos casos, cuando es necesario, la sección incluye comparaciones técnicas detalladas.

Crea y visualiza bases de datos existentes

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;

Administra una base de datos a través de la consola de Cloud SQL

• En la consola de Google Cloud, ve a Almacenamiento > SQL > Instancia > Databases (Bases de datos) > Ver/crear.

  

Esquemas y bases de datos del sistema

Las instancias de base de datos de Oracle obtienen ciertos esquemas del sistema, por ejemplo, SYS/SYSTEM, con la función de propietarios de los objetos de metadatos de la base de datos.

Por el contrario, MySQL contiene varias bases de datos del sistema (a diferencia de los esquemas de Oracle) que entregan la capa de metadatos (ten en cuenta que los nombres de las bases de datos distinguen entre mayúsculas y minúsculas):

• Mysql

  La base de datos del sistema mysql contiene tablas que almacenan información requerida por el servidor MySQL mientras se ejecuta, como se muestra a continuación:

  • Tablas de privilegios del sistema
  • Tablas de información de objetos
  • Tablas del sistema de registros
  • Tablas del sistema de replicación
  • Tablas del sistema optimizador
  • Tablas del sistema por zonas horarias

• INFORMATION_SCHEMA

  INFORMATION_SCHEMA funciona como el diccionario de datos y catálogo del sistema de la base de datos principal. Proporciona acceso a los metadatos de la base de datos, que es información interna de la base de datos sobre el servidor de MySQL, como el nombre de una base de datos o tabla, el tipo de datos de columna y los privilegios de acceso.

• performance_schema

  Una base de datos del sistema que recopila información estadística sobre la instancia de MySQL. La base de datos del sistema performance_schema contiene métricas para la supervisión de la ejecución del servidor a un nivel muy detallado. El esquema proporciona una inspección de ejecución interna del servidor al momento de la ejecución y puede servir como fuente principal para analizar problemas de rendimiento de la base de datos.

  El performance_schema no está habilitado de forma predeterminada cuando se usa Cloud SQL para MySQL. Para habilitar el esquema, usa la herramienta de línea de comandos de gcloud:

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

  Para completar esta configuración, debes reiniciar la instancia. No puedes modificar el parámetro --database-flags mediante la página de marcas de la base de datos de Cloud SQL para MySQL en la consola de Google Cloud.

• sys

  El esquema sys existe desde la versión 5.5.7 de MySQL y conserva más que nada las vistas en las tablas del sistema performance_schema. Este esquema proporciona un conjunto de vistas más legibles que resumen los datos de performance_schema en un formulario más fácil de comprender. El esquema sys también contiene varios procedimientos y funciones almacenados para realizar operaciones como configurar performance_schema y generar informes de diagnóstico.

  El esquema sys muestra información solo cuando performance_schema está habilitado.

Visualiza metadatos y vistas dinámicas del sistema

En esta sección, se proporciona una descripción general de algunas de las tablas de metadatos y vistas dinámicas del sistema más comunes que se usan en Oracle y sus objetos de base de datos correspondientes en Cloud SQL para MySQL 5.7.

Oracle proporciona cientos de tablas y vistas de metadatos del sistema, mientras que MySQL solo contiene varias decenas. Para cada caso, puede haber más de un objeto de base de datos con un propósito específico.

Oracle proporciona varios niveles de objetos de metadatos, cada uno de los cuales requiere privilegios diferentes:

• USER_TableName: El usuario puede verlo.
• ALL_TableName: Todos los usuarios pueden verlo.
• DBA_TableName: Solo pueden verlo los usuarios con el privilegio de DBA, como SYS y SYSTEM.

Para las vistas de rendimiento dinámico, Oracle usa los prefijos V$ y GV$. Para que un usuario de MySQL pueda ver las tablas o vistas de metadatos del sistema, debe tener permisos específicos sobre los objetos del sistema. Para obtener más información sobre la seguridad, consulta la sección Seguridad.

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

Motores de almacenamiento de MySQL

A diferencia de muchos otros RDBMS (incluido el de Oracle), MySQL puede funcionar de manera polimórfica debido a su sistema de almacenamiento conectable. La arquitectura del motor de almacenamiento conectable de MySQL permite que un administrador de base de datos seleccione un motor de almacenamiento especializado para una necesidad en particular de una aplicación.

El componente del motor de almacenamiento conectable de MySQL en el servidor de la base de datos de MySQL es responsable de realizar las operaciones de E/S de los datos, incluido el almacenamiento de datos en los discos o búferes de memoria. La arquitectura del motor de almacenamiento conectable proporciona un conjunto estándar de servicios de asistencia y administración que son comunes entre todos los motores de almacenamiento subyacentes.

En MySQL 5.5 y versiones posteriores, el motor de almacenamiento predeterminado es el motor de almacenamiento InnoDB, mientras que InnoDB también maneja las tablas temporales. Puedes configurar los motores de almacenamiento durante los pasos CREATE o ALTER de la tabla, como en el siguiente ejemplo:

mysql> SHOW CREATE TABLE JOBS \G;

Este es el resultado:

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

Para obtener más información, consulta los diferentes motores de almacenamiento de MySQL.
Puedes ver la configuración del motor de almacenamiento mediante la siguiente consulta:

mysql> SHOW VARIABLES LIKE '%storage%';

El resultado es similar a este:

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

Puedes ver todos los motores de almacenamiento integrados:

mysql> SHOW STORAGE ENGINES;

El resultado es similar a este:

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

Ten en cuenta que InnoDB es el motor de almacenamiento predeterminado y es el único que admite transacciones (cumple con ACID). Debido a que InnoDB es el único motor de almacenamiento que se aproxima a la funcionalidad de Oracle, te recomendamos usar InnoDB en todo momento. La segunda generación de Cloud SQL para MySQL solo admite el motor de almacenamiento InnoDB.

Parámetros del sistema

Las bases de datos de Oracle y Cloud SQL para MySQL pueden configurarse de manera específica para lograr cierta funcionalidad más allá de la configuración predeterminada. Para alterar los parámetros de configuración en Oracle, se requieren ciertos permisos de administración (en especial, los permisos del usuario SYS/SYSTEM).

A continuación, se muestra un ejemplo de cómo alterar la configuración de Oracle mediante la declaración ALTER SYSTEM. En este ejemplo, el usuario cambia el parámetro “cantidad máxima de intentos de acceso con errores” solo en el nivel de configuración spfile (con la modificación válida solo después de un reinicio):

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

En el siguiente ejemplo, el usuario solo solicita ver el valor del parámetro de Oracle:

SQL> SHOW PARAMETER SEC_MAX_FAILED_LOGIN_ATTEMPTS;

El resultado es similar a este:

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

La modificación del parámetro de Oracle funciona en tres permisos:

• SPFILE: Las modificaciones de parámetros se escriben en el spfile de Oracle, con un reinicio de instancia necesario para que el parámetro surta efecto.
• MEMORIA: Las modificaciones de parámetros se aplican en la capa de memoria solo cuando no se permite el cambio de parámetros estáticos.
• AMBOS: Las modificaciones de parámetros se aplican en el archivo de parámetros del servidor y en la memoria de la instancia, en la que no se permite el cambio de parámetros estáticos.

Marcas de configuración de Cloud SQL para MySQL

Puedes modificar los parámetros del sistema de Cloud SQL para MySQL mediante las marcas de configuración en la consola de Google Cloud, gcloud CLI o CURL. Consulta la lista completa de todos los parámetros compatibles con Cloud SQL para MySQL que puedes modificar.

Los parámetros de MySQL se pueden dividir en varios permisos:

• Parámetros dinámicos: se pueden modificar en el tiempo de ejecución.
• Parámetros estáticos: requieren que se reinicie la instancia para surtir efecto.
• Parámetros globales: tendrán un efecto global en todas las sesiones actuales y futuras.
• Parámetros de sesión: se pueden modificar a nivel de la sesión solo durante la vida útil de la sesión actual, aislada de otras sesiones.

El parámetro de memoria innodb_buffer_pool_size de Cloud SQL para MySQL (uno de los parámetros fundamentales que se debe tener en cuenta cuando se planifica y ajusta el tamaño de un entorno de MySQL) se determina por el tipo de instancia y no se puede alterar mediante el uso de marcas de configuración ni por cualquier otro método, por ejemplo:

• El tipo de instancia db-n1-standard-1 tiene 1.4 GB de asignación de memoria.
• El tipo de instancia db-n1-highmem-8 tiene 38 GB de asignación de memoria.

Ejemplos de alteración de los parámetros de Cloud SQL para MySQL

Transacciones y niveles de aislamiento

En esta sección, se describen las principales diferencias entre Oracle y Cloud SQL para MySQL relevantes para las migraciones a nivel de transacción y aislamiento.

Modo de confirmación

Oracle funciona de forma predeterminada en el modo sin confirmación automática, en el que cada transacción de DML se debe determinar con declaraciones COMMIT/ROLLBACK. Una de las diferencias fundamentales entre Oracle y MySQL es que MySQL funciona de forma predeterminada en el modo de confirmación automática y cada transacción de DML se confirma de manera automática con la especificación explícita de declaraciones COMMIT/ROLLBACK.

Para forzar el funcionamiento de MySQL en un modo sin confirmación automática, existen varias opciones:

• Cuando administres transacciones dentro del alcance de los procedimientos almacenados, usa la cláusula START TRANSACTION para ingresar al mismo modo transaccional que el de Oracle.

• Usa la siguiente declaración para establecer el parámetro del sistema autocommit en OFF a nivel de la sesión y usa de forma explícita las declaraciones COMMIT/ROLLBACK en las transacciones de DML:

  mysql> SET autocommit=off;
  

Niveles de aislamiento

El estándar ANSI/ISO de SQL (SQL92) define cuatro niveles de aislamiento. Cada nivel proporciona un enfoque diferente para manejar la ejecución simultánea de transacciones de bases de datos:

• Lectura no confirmada: Una transacción en proceso en ese momento puede ver los datos no confirmados que realiza otra transacción. Si se realiza una reversión, todos los datos se restablecen a su estado anterior.
• Lectura confirmada: Una transacción solo ve los cambios de datos que se confirmaron; no es posible ver los cambios no confirmados (“lecturas sucias”).
• Lectura repetible: Una transacción puede ver los cambios realizados por la otra transacción solo después de que ambas transacciones emiten una COMMIT o ambas se revierten.
• Serializable: El nivel de aislamiento más estricto y potente. Este nivel bloquea todos los registros a los que se accede, y bloquea el recurso para que no se puedan agregar registros a la tabla.

Los niveles de aislamiento de transacciones administran la visibilidad de los datos modificados según cómo lo ven otras transacciones en ejecución. Además, cuando varias transacciones simultáneas acceden a los mismos datos, el nivel de aislamiento de transacción seleccionado afecta la forma en que interactúan las diferentes transacciones.

Oracle admite los siguientes niveles de aislamiento:

• Lectura confirmada (predeterminado)
• Serializable
• Solo lectura (no es parte del estándar ANSI/ISO de SQL (SQL92)

MVCC en Oracle (Control de simultaneidad de varias versiones):

• Oracle usa el mecanismo de VMCC para proporcionar coherencia de lectura automática en toda la base de datos y en todas las sesiones.
• Oracle depende del número de cambio del sistema (SCN) de la transacción actual para obtener una vista coherente de la base de datos. Por lo tanto, todas las consultas de bases de datos solo muestran datos confirmados con respecto al SCN al momento de la ejecución de la consulta.
• Los niveles de aislamiento se pueden cambiar a nivel de transacción y de sesión.

Este es un ejemplo de configuración de los niveles de aislamiento:

-- 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 para MySQL, como Oracle, admite los siguientes cuatro niveles de aislamiento de transacciones especificados en el estándar ANSI SQL:92:

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

El nivel de aislamiento predeterminado de Cloud SQL para MySQL es REPEATABLE READ. Cualquier dato nuevo estará disponible para ambos solo después de que ambas transacciones emitan un comando COMMIT. Estos niveles de aislamiento se pueden modificar a nivel de SESSION y a nivel de GLOBAL (la modificación de nivel global se encuentra en etapa beta mediante marcas de configuración).

Para verificar los niveles de aislamiento actuales en los niveles SESSION y GLOBAL, usa la siguiente declaración:

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

Este es el resultado:

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

Puedes modificar la sintaxis del nivel de aislamiento de la siguiente manera:

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

Además, puedes modificar el nivel de aislamiento a nivel de SESSION:

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

       -- Verify

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

Este es el resultado:

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

Estructura de transacciones de Cloud SQL para MySQL

Sintaxis de Transacciones:

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}

Las transacciones se pueden implementar con START TRANSACTION o BEGIN.

La opción WITH CONSISTENT SNAPSHOT inicia una transacción READ coherente, que es lo mismo que emitir START TRANSACTION, seguido de un SELECT de cualquier tabla. La cláusula WITH CONSISTENT SNAPSHOT que inicia una READ coherente (una operación READ que usa información de instantáneas para presentar resultados de consultas basadas en un momento determinado) no cambia el nivel de aislamiento de la transacción y solo es compatible con el nivel de aislamiento REPEATABLE READ.

Una READ coherente usa información de instantáneas para que los resultados de las consultas estén disponibles en función de un momento determinado, sin tener en cuenta las modificaciones realizadas por transacciones simultáneas. Si otra transacción cambió los datos consultados, los datos originales se reconstruyen mediante el registro de deshacer. Esto ayudará a evitar problemas de bloqueo que puedan reducir la simultaneidad.

Con el nivel de aislamiento REPEATABLE READ, la instantánea se basa en el momento en que se realiza la primera operación READ. Con el nivel de aislamiento READ COMMITTED, la instantánea se restablece al momento de cada operación READ coherente.

Este es un ejemplo de configuración del nivel de la transacción y del aislamiento:

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;