Migrazione degli utenti Oracle a Cloud SQL per MySQL: terminologia e funzionalità

Questo documento fa parte di una serie che fornisce informazioni e indicazioni chiave relative alla pianificazione ed esecuzione delle migrazioni dei database Oracle® 11g/12c a Cloud SQL per MySQL versione 5.7, istanze di seconda generazione. La serie include le seguenti parti:

• Migrazione degli utenti Oracle a Cloud SQL per MySQL: terminologia e funzionalità (questo documento)
• Migrazione degli utenti Oracle a Cloud SQL per MySQL: tipi di dati, utenti e tabelle
• Migrazione degli utenti Oracle a Cloud SQL per MySQL: query, stored procedure, funzioni e trigger
• Migrazione degli utenti Oracle a Cloud SQL per MySQL: sicurezza, operazioni, monitoraggio e registrazione

Terminologia

Questa sezione illustra le somiglianze e le differenze nella terminologia dei database tra Oracle e Cloud SQL per MySQL. Esamina e confronta gli aspetti di base di ciascuna delle piattaforme di database. Il confronto distingue tra le versioni Oracle 11g e 12c a causa di differenze di architettura (ad esempio, Oracle 12c introduce la funzionalità multi-tenant). La versione di Cloud SQL per MySQL a cui si fa riferimento qui è 5.7.x.

Differenze nella terminologia tra Oracle 11g e Cloud SQL per 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

Differenze nella terminologia tra Oracle 12c e Cloud SQL per MySQL

Funzionalità

Sebbene i database Oracle 11g/12c e Cloud SQL per MySQL funzionino su architetture diverse (infrastruttura e linguaggi procedurali estesi), condividono gli stessi aspetti fondamentali di un database relazionale. Supportano oggetti di database, carichi di lavoro di concorrenza multiutente e transazioni (compatibilità ACID). Gestiscono inoltre le contese per i blocchi che supportano più livelli di isolamento (in base alle esigenze aziendali) e soddisfano i requisiti delle applicazioni in corso come un datastore relazionale per le operazioni di elaborazione delle transazioni online (OLTP) e di analisi online (OLAP).

La sezione seguente fornisce una panoramica di alcune delle principali differenze funzionali tra Oracle e Cloud SQL per MySQL. In alcuni casi, se necessario, la sezione include confronti tecnici dettagliati.

Creazione e visualizzazione di database esistenti

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;

Gestione di un database tramite la console Cloud SQL

• Nella console Google Cloud, vai a Storage > SQL > Instance > Databases > View/Create.

  

Database e schemi di sistema

Le istanze di database Oracle ottengono determinati schemi di sistema, ad esempio SYS/SYSTEM, con il ruolo di proprietari degli oggetti metadati del database.

Al contrario, MySQL contiene diversi database di sistema (a differenza degli schemi Oracle), che forniscono il livello di metadati (tieni presente che i nomi dei database sono sensibili alle maiuscole):

• Mysql

  Il database di sistema mysql contiene tabelle che archiviano le informazioni richieste dal server MySQL durante l'esecuzione, ad esempio:

  • Tabelle dei privilegi di sistema
  • Tabelle di informazioni sugli oggetti
  • Tabelle di sistema dei log
  • Tabelle del sistema di replica
  • Tabelle di sistema dello strumento di ottimizzazione
  • Tabelle di sistema dei fusi orari

• INFORMATION_SCHEMA

  INFORMATION_SCHEMA funge da dizionario dei dati e catalogo di sistema principali del database. Fornisce l'accesso ai metadati del database, ovvero alle informazioni interne del database sul server MySQL, come il nome di un database o di una tabella, il tipo di dati della colonna e i privilegi di accesso.

• performance_schema

  Un database di sistema che raccoglie informazioni statistiche sull'istanza MySQL. Il database di sistema performance_schema contiene le metriche per il monitoraggio dell'esecuzione del server a un livello molto granulare. Lo schema fornisce un'ispezione dell'esecuzione interna del server in fase di esecuzione e può fungere da fonte principale per analizzare i problemi di prestazioni del database.

  performance_schema non è abilitato per impostazione predefinita con Cloud SQL per MySQL. Per attivare lo schema, utilizza lo strumento a riga di comando gcloud:

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

  Per completare questa configurazione, devi riavviare l'istanza. Non puoi modificare il parametro --database-flags utilizzando la pagina dei flag di database Cloud SQL per MySQL nella console Google Cloud.

• sys

  Lo schema sys esiste dalla versione 5.5.7 di MySQL e contiene principalmente visualizzazioni delle tabelle di sistema performance_schema. Questo schema fornisce un insieme di visualizzazioni più leggibili che riassumono i dati di performance_schema in un formato più facilmente comprensibile. Lo schema sys contiene anche diverse procedure e funzioni memorizzate per eseguire operazioni come la configurazione di performance_schema e la generazione di report di diagnostica.

  Lo schema sys mostra le informazioni solo quando performance_schema è attivo.

Visualizzazione dei metadati e delle visualizzazioni dinamiche del sistema

Questa sezione fornisce una panoramica di alcune delle tabelle di metadati più comuni e delle viste dinamiche di sistema utilizzate in Oracle e dei relativi oggetti database in Cloud SQL per MySQL versione 5.7.

Oracle fornisce centinaia di tabelle e viste dei metadati di sistema, mentre MySQL ne contiene solo alcune dozzine. Per ogni caso, può essere presente più di un oggetto database, ciascuno con uno scopo specifico.

Oracle fornisce diversi livelli di oggetti di metadati, ognuno dei quali richiede diversi privilegi:

• USER_TableName: può essere visualizzato dall'utente.
• ALL_TableName: può essere visualizzato da tutti gli utenti.
• DBA_TableName: può essere visualizzato solo dagli utenti con il privilegio DBA, ad esempio SYS e SYSTEM.

Per le visualizzazioni dinamiche del rendimento, Oracle utilizza i prefissi V$ e GV$. Affinché un utente MySQL possa visualizzare le tabelle o le viste dei metadati di sistema, deve disporre di autorizzazioni specifiche per gli oggetti di sistema. Per ulteriori informazioni sulla sicurezza, consulta la sezione Sicurezza.

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

Motori di archiviazione MySQL

A differenza di molti altri RDBMS (incluso Oracle), MySQL può funzionare in modo polimorfico grazie al suo sistema di archiviazione pluggable. L'architettura del motore di archiviazione pluggable di MySQL consente a un amministratore di database di selezionare un motore di archiviazione specializzato per una determinata esigenza dell'applicazione.

Il componente del motore di archiviazione pluggable di MySQL nel server del database MySQL è responsabile dell'esecuzione delle operazioni di I/O dei dati, inclusa la memorizzazione dei dati nei dischi o nei buffer della memoria. L'architettura dell'engine di archiviazione plug-in fornisce un insieme standard di servizi di gestione e assistenza comuni a tutti gli engine di archiviazione sottostanti.

A partire dalla versione 5.5 di MySQL, il motore di archiviazione predefinito è il motore di archiviazione InnoDB, mentre InnoDB gestisce anche le tabelle temporanee. Puoi configurare gli engine di archiviazione durante la tabella CREATE o ALTER, come nell'esempio seguente:

mysql> SHOW CREATE TABLE JOBS \G;

L'output è il seguente:

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

Per ulteriori informazioni, consulta i diversi motori di archiviazione di MySQL.
Puoi visualizzare la configurazione del motore di archiviazione utilizzando la seguente query:

mysql> SHOW VARIABLES LIKE '%storage%';

L'output è simile al seguente:

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

Puoi visualizzare tutti i motori di archiviazione integrati:

mysql> SHOW STORAGE ENGINES;

L'output è simile al seguente:

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

Tieni presente che InnoDB è il motore di archiviazione predefinito ed è l'unico motore di archiviazione che supporta le transazioni (conforme ad ACID). Poiché InnoDB è l'unico motore di archiviazione che si avvicina alla funzionalità di Oracle, ti consigliamo di utilizzarlo sempre. Cloud SQL per MySQL di seconda generazione supporta solo il motore di archiviazione InnoDB.

Parametri di sistema

Sia i database Oracle che Cloud SQL per MySQL possono essere configurati in modo specifico per ottenere determinate funzionalità oltre la configurazione predefinita. Per modificare i parametri di configurazione in Oracle, sono necessarie alcune autorizzazioni di amministrazione (principalmente le autorizzazioni utente SYS/SYSTEM).

Di seguito è riportato un esempio di modifica della configurazione di Oracle mediante l'istruzione ALTER SYSTEM. In questo esempio, l'utente modifica il parametro "massimo tentativi di accesso non riusciti" solo a livello di configurazione spfile (con la modifica valida solo dopo un riavvio):

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

Nell'esempio seguente, l'utente chiede di visualizzare semplicemente il valore del parametro Oracle:

SQL> SHOW PARAMETER SEC_MAX_FAILED_LOGIN_ATTEMPTS;

L'output è simile al seguente:

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

La modifica del parametro Oracle funziona in tre ambiti:

• SPFILE: le modifiche ai parametri vengono scritte in spfile di Oracle, con un riavvio dell'istanza necessario per l'applicazione del parametro.
• MEMORIA: le modifiche ai parametri vengono applicate solo nel livello di memoria, mentre non è consentita alcuna modifica dei parametri statici.
• ENTRAMBI: le modifiche ai parametri vengono applicate sia nel file del parametro del server sia nella memoria dell'istanza, dove non è consentita alcuna modifica dei parametri statici.

Flag di configurazione di Cloud SQL per MySQL

Puoi modificare i parametri di sistema di Cloud SQL per MySQL utilizzando i flag di configurazione nella console Google Cloud, in gcloud CLI o in CURL. Consulta l'elenco completo di tutti i parametri supportati da Cloud SQL per MySQL che puoi modificare.

I parametri MySQL possono essere suddivisi in diversi ambiti:

• Parametri dinamici:possono essere modificati in fase di esecuzione.
• Parametri statici:richiedono il riavvio dell'istanza per essere applicati.
• Parametri globali:avranno un effetto globale su tutte le sessioni attuali e future.
• Parametri sessione:possono essere modificati a livello di sessione solo per la durata della sessione corrente, in modo isolato dalle altre sessioni.

Il parametro di memoria Cloud SQL per MySQL innodb_buffer_pool_size (uno dei parametri fondamentali da considerare durante la pianificazione e la definizione delle dimensioni di un ambiente MySQL) è determinato dal tipo di istanza e non può essere modificato utilizzando i flag di configurazione o qualsiasi altro metodo, ad esempio:

• Il tipo di istanza db-n1-standard-1 ha un'allocazione di memoria di 1,4 GB.
• Il tipo di istanza db-n1-highmem-8 ha un'allocazione di memoria di 38 GB.

Esempi di modifica dei parametri di Cloud SQL per MySQL

Transazioni e livelli di isolamento

Questa sezione descrive le principali differenze tra Oracle e Cloud SQL per MySQL pertinenti alle migrazioni a livello di transazione e isolamento.

Modalità di commit

Per impostazione predefinita, Oracle funziona in modalità di commit non automatico, in cui ogni transazione DML deve essere determinata con istruzioni COMMIT/ROLLBACK. Una delle differenze fondamentali tra Oracle e MySQL è che MySQL funziona per impostazione predefinita in modalità di commit automatico e ogni transazione DML viene eseguita con commit automatico specificando esplicitamente le istruzioni COMMIT/ROLLBACK.

Per forzare MySQL a funzionare in una modalità non di commit automatico, sono disponibili diverse opzioni:

• Quando gestisci le transazioni nell'ambito delle stored procedure, utilizza la clausola START TRANSACTION per inserire la stessa modalità transazionale di Oracle.

• Utilizza la seguente istruzione per impostare il parametro di sistema autocommit su OFF a livello di sessione e utilizza esplicitamente le istruzioni COMMIT/ROLLBACK nelle transazioni DML:

  mysql> SET autocommit=off;
  

Livelli di isolamento

Lo standard ANSI/ISO SQL (SQL92) definisce quattro livelli di isolamento. Ogni livello offre un approccio diverso per gestire l'esecuzione simultanea delle transazioni di database:

• Lettura non confermata: una transazione attualmente in fase di elaborazione può vedere i dati non confermati creati dall'altra transazione. Se viene eseguito un rollback, tutti i dati vengono ripristinati allo stato precedente.
• Lettura confermata:una transazione vede solo le modifiche ai dati che sono state confermate. Le modifiche non confermate("letture sporche") non sono possibili.
• Lettura ripetibile: una transazione può visualizzare le modifiche apportate dall'altra transazione solo dopo che entrambe le transazioni hanno emesso un COMMIT o dopo che entrambe sono state annullate.
• Serializable:il livello di isolamento più rigoroso/sicuro. Questo livello blocca tutti i record a cui viene eseguito l'accesso e la risorsa in modo che i record non possano essere aggiunti alla tabella.

I livelli di isolamento delle transazioni gestiscono la visibilità dei dati modificati come li vedono altre transazioni in esecuzione. Inoltre, quando più transazioni contemporaneamente accedono agli stessi dati, il livello di isolamento delle transazioni selezionato influisce sul modo in cui le diverse transazioni interagiscono.

Oracle supporta i seguenti livelli di isolamento:

• Lettura confermata (valore predefinito)
• Serializable
• Solo lettura (non fa parte dello standard SQL ANSI/ISO (SQL92)

Controllo della concorrenza multiversione (MVCC) di Oracle:

• Oracle utilizza il meccanismo MVCC per fornire coerenza di lettura automatica in tutto il database e in tutte le sessioni.
• Oracle si basa sul numero di modifica di sistema (SCN) della transazione corrente per ottenere una vista coerente del database. Pertanto, tutte le query del database restituiscono solo i dati committati rispetto all'SCN al momento dell'esecuzione della query.
• I livelli di isolamento possono essere modificati a livello di transazione e sessione.

Ecco un esempio di impostazione dei livelli di isolamento:

-- 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 per MySQL, come Oracle, supporta i seguenti quattro livelli di isolamento delle transazioni specificati nello standard ANSI SQL:92:

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

Il livello di isolamento predefinito di Cloud SQL per MySQL è REPEATABLE READ. Eventuali nuovi dati saranno disponibili per entrambi solo dopo che entrambe le transazioni avranno emesso un comando COMMIT. Questi livelli di isolamento possono essere modificati a livello di SESSION e GLOBAL (la modifica a livello globale è attualmente in versione beta e utilizza i flag di configurazione).

Per verificare i livelli di isolamento attuali sia a livello di SESSION sia a livello di GLOBAL, utilizza la seguente istruzione:

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

L'output è il seguente:

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

Puoi modificare la sintassi del livello di isolamento nel seguente modo:

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

Puoi anche modificare il livello di isolamento a livello di SESSION:

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

       -- Verify

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

L'output è il seguente:

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

Struttura delle transazioni di Cloud SQL per MySQL

Sintassi di Transazioni:

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}

Le transazioni possono essere implementate con START TRANSACTION o BEGIN.

L'opzione WITH CONSISTENT SNAPSHOT avvia una transazione READ coerente, che è in pratica la stessa cosa che emettere un START TRANSACTION, seguito da un SELECT da qualsiasi tabella. La clausola WITH CONSISTENT SNAPSHOT che avvia un READ coerente (un'operazione READ che utilizza le informazioni sulle istantanee per presentare risultati di query in base a un determinato momento) non modifica il livello di isolamento delle transazioni ed è supportata solo dal livello di isolamento REPEATABLE READ.

Un READ coerente utilizza le informazioni relative agli istantanei per rendere disponibili i risultati delle query in base a un determinato momento, indipendentemente dalle modifiche eseguite dalle transazioni simultanee. Se i dati sottoposti a query sono stati modificati da un'altra transazione, i dati originali vengono ricostruiti utilizzando il log di annullamento. In questo modo eviterai problemi di blocco che potrebbero ridurre la concorrenza.

Con il livello di isolamento REPEATABLE READ, lo snapshot si basa sul momento in cui viene eseguita la prima operazione READ. Con il livello di isolamento READ COMMITTED, lo snapshot viene reimpostato sul momento di ogni operazione READ coerente.

Di seguito è riportato un esempio di impostazione del livello di transazione e isolamento:

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;