29.12.7 Performance Schema Transaction Tables

29.12.7 Performance Schema Transaction Tables

29.12.7.1 The events_transactions_current Table 29.12.7.2 The events_transactions_history Table 29.12.7.3 The events_transactions_history_long Table

Performance Schema는 트랜잭션을 인스트루먼트합니다. event 계층 구조 안에서 wait event는 stage event 안에 중첩되고, stage event는 statement event 안에 중첩되며, statement event는 트랜잭션 event 안에 중첩됩니다.

이 테이블들은 트랜잭션 event를 저장합니다:

• events_transactions_current: 각 thread에 대한 현재 트랜잭션 event입니다.

• events_transactions_history: 각 thread별로 종료된 가장 최근의 트랜잭션 event입니다.

• events_transactions_history_long: 전역적으로(모든 thread에 걸쳐) 종료된 가장 최근의 트랜잭션 event입니다.

다음 섹션에서는 트랜잭션 event 테이블을 설명합니다.

또한 트랜잭션 event에 대한 정보를 집계하는 요약 테이블도 있습니다.
Section 29.12.20.5, “Transaction Summary Tables”를 참조하십시오.

세 개의 트랜잭션 event 테이블 간의 관계에 대한 더 많은 정보는
Section 29.9, “Performance Schema Tables for Current and Historical Events”를 참조하십시오.

• Configuring Transaction Event Collection

• Transaction Boundaries

• Transaction Instrumentation

• Transactions and Nested Events

• Transactions and Stored Programs

• Transactions and Savepoints

• Transactions and Errors

Configuring Transaction Event Collection

트랜잭션 event를 수집할지 여부를 제어하려면 관련 인스트루먼트와 컨슈머의 상태를 설정하십시오:

• setup_instruments 테이블에는 transaction이라는 이름의 인스트루먼트가 있습니다. 이 인스트루먼트를 사용하여 개별 트랜잭션 event 클래스의 수집을 활성화하거나 비활성화합니다.

• setup_consumers 테이블에는 현재 및 과거 트랜잭션 event 테이블 이름에 해당하는 이름을 가진 컨슈머 값이 포함되어 있습니다. 이 컨슈머들을 사용하여 트랜잭션 event 수집을 필터링합니다.

transaction 인스트루먼트와 events_transactions_current, events_transactions_history 트랜잭션 컨슈머는 기본적으로 활성화되어 있습니다:

1mysql> SELECT NAME, ENABLED, TIMED
2       FROM performance_schema.setup_instruments
3       WHERE NAME = 'transaction';
4+-------------+---------+-------+
5| NAME        | ENABLED | TIMED |
6+-------------+---------+-------+
7| transaction | YES     | YES   |
8+-------------+---------+-------+
9mysql> SELECT *
10       FROM performance_schema.setup_consumers
11       WHERE NAME LIKE 'events_transactions%';
12+----------------------------------+---------+
13| NAME                             | ENABLED |
14+----------------------------------+---------+
15| events_transactions_current      | YES     |
16| events_transactions_history      | YES     |
17| events_transactions_history_long | NO      |
18+----------------------------------+---------+

서버 시작 시 트랜잭션 event 수집을 제어하려면 my.cnf 파일에 다음과 같은 줄을 사용하십시오:

• 활성화:

1[mysqld]
2performance-schema-instrument='transaction=ON'
3performance-schema-consumer-events-transactions-current=ON
4performance-schema-consumer-events-transactions-history=ON
5performance-schema-consumer-events-transactions-history-long=ON

• 비활성화:

1[mysqld]
2performance-schema-instrument='transaction=OFF'
3performance-schema-consumer-events-transactions-current=OFF
4performance-schema-consumer-events-transactions-history=OFF
5performance-schema-consumer-events-transactions-history-long=OFF

런타임에 트랜잭션 event 수집을 제어하려면
setup_instruments 및 setup_consumers 테이블을 업데이트하십시오:

• 활성화:

1UPDATE performance_schema.setup_instruments
2SET ENABLED = 'YES', TIMED = 'YES'
3WHERE NAME = 'transaction';
4
5UPDATE performance_schema.setup_consumers
6SET ENABLED = 'YES'
7WHERE NAME LIKE 'events_transactions%';

• 비활성화:

1UPDATE performance_schema.setup_instruments
2SET ENABLED = 'NO', TIMED = 'NO'
3WHERE NAME = 'transaction';
4
5UPDATE performance_schema.setup_consumers
6SET ENABLED = 'NO'
7WHERE NAME LIKE 'events_transactions%';

특정 트랜잭션 event 테이블에 대해서만 트랜잭션 event를 수집하려면 transaction 인스트루먼트를 활성화하되, 원하는 테이블에 해당하는 트랜잭션 컨슈머만 활성화하십시오.

event 수집 구성에 대한 추가 정보는
Section 29.3, “Performance Schema Startup Configuration” 및
Section 29.4, “Performance Schema Runtime Configuration”를 참조하십시오.

Transaction Boundaries

MySQL 서버에서 트랜잭션은 다음 구문들로 명시적으로 시작됩니다:

1START TRANSACTION | BEGIN | XA START | XA BEGIN

트랜잭션은 암시적으로도 시작됩니다. 예를 들어
autocommit 시스템 변수가 활성화되어 있을 때는 각 구문의 시작이 새로운 트랜잭션의 시작이 됩니다.

autocommit이 비활성화된 경우, 커밋된 트랜잭션 다음의 첫 번째 구문이 새로운 트랜잭션의 시작을 표시합니다. 그 이후의 구문들은 해당 트랜잭션이 커밋될 때까지 그 트랜잭션의 일부입니다.

트랜잭션은 다음 구문들로 명시적으로 종료됩니다:

1COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK

트랜잭션은 DDL 구문, 잠금 구문, 서버 관리 구문의 실행에 의해 암시적으로도 종료됩니다.

다음 논의에서
START TRANSACTION에 대한 언급은
BEGIN, XA START, XA BEGIN에도 동일하게 적용됩니다.

마찬가지로
COMMIT 및 ROLLBACK에 대한 언급은 각각
XA COMMIT, XA ROLLBACK에도 적용됩니다.

Performance Schema는 트랜잭션 경계를 서버와 유사하게 정의합니다. 트랜잭션 event의 시작과 종료는 서버에서의 해당 상태 전이와 밀접하게 일치합니다:

• 명시적으로 시작된 트랜잭션의 경우, 트랜잭션 event는 START TRANSACTION 구문을 처리하는 동안 시작됩니다.

• 암시적으로 시작된 트랜잭션의 경우, 이전 트랜잭션이 종료된 후 트랜잭션 스토리지 엔진을 사용하는 첫 번째 구문에서 트랜잭션 event가 시작됩니다.

• 명시적 또는 암시적 종료 여부와 관계없이 모든 트랜잭션에 대해, 트랜잭션 event는 서버가
  COMMIT 또는 ROLLBACK를 처리하는 동안 활성 트랜잭션 상태에서 벗어날 때 종료됩니다.

이 접근 방식에는 미묘한 함의가 있습니다:

• Performance Schema의 트랜잭션 event는 대응하는
  START TRANSACTION, COMMIT, ROLLBACK 구문에 연관된 statement event를 완전히 포함하지 않습니다. 트랜잭션 event와 이러한 구문 사이에는 미미한 시간상의 중첩이 있습니다.

• 비트랜잭션 스토리지 엔진으로 동작하는 구문은 커넥션의 트랜잭션 상태에 아무런 영향을 주지 않습니다. 암시적 트랜잭션의 경우, 트랜잭션 event는 트랜잭션 스토리지 엔진을 사용하는 첫 번째 구문에서 시작됩니다. 즉, 비트랜잭션 테이블에 대해서만 동작하는 구문은
  START TRANSACTION 이후라 하더라도 무시됩니다.

이를 설명하기 위해 다음 시나리오를 고려하십시오:

11. SET autocommit = OFF;
22. CREATE TABLE t1 (a INT) ENGINE = InnoDB;
33. START TRANSACTION;                       -- Transaction 1 START
44. INSERT INTO t1 VALUES (1), (2), (3);
55. CREATE TABLE t2 (a INT) ENGINE = MyISAM; -- Transaction 1 COMMIT
6                                            -- (implicit; DDL forces commit)
76. INSERT INTO t2 VALUES (1), (2), (3);     -- Update nontransactional table
87. UPDATE t2 SET a = a + 1;                 -- ... and again
98. INSERT INTO t1 VALUES (4), (5), (6);     -- Write to transactional table
10                                            -- Transaction 2 START (implicit)
119. COMMIT;                                  -- Transaction 2 COMMIT

서버의 관점에서 Transaction 1은 테이블 t2가 생성될 때 종료됩니다. 비트랜잭션 테이블에 대한 중간 갱신이 있음에도 불구하고, Transaction 2는 트랜잭션 테이블에 접근할 때까지 시작되지 않습니다.

Performance Schema의 관점에서 Transaction 2는 서버가 활성 트랜잭션 상태로 전이할 때 시작됩니다. 구문 6과 7은 Transaction 2의 경계 안에 포함되지 않으며, 이는 서버가 바이너리 로그에 트랜잭션을 기록하는 방식과 일치합니다.

Transaction Instrumentation

세 가지 속성이 트랜잭션을 정의합니다:

• 액세스 모드(읽기 전용, 읽기/쓰기)

• 격리 수준 ( SERIALIZABLE, REPEATABLE READ 등)

• 암시적 ( autocommit 활성화) 또는 명시적 ( autocommit 비활성화)

트랜잭션 인스트루먼트의 복잡성을 줄이고 수집된 트랜잭션 데이터가 완전하고 의미 있는 결과를 제공하도록 하기 위해, 모든 트랜잭션은 액세스 모드, 격리 수준, autocommit 모드와 무관하게 인스트루먼트됩니다.

트랜잭션 이력을 선택적으로 조사하려면 트랜잭션 event 테이블의 속성 컬럼인 ACCESS_MODE, ISOLATION_LEVEL, AUTOCOMMIT을 사용하십시오.

트랜잭션 인스트루먼트의 비용은 사용자, 계정, 호스트, thread(클라이언트 커넥션)에 따라 트랜잭션 인스트루먼트를 활성화하거나 비활성화하는 등의 여러 방법으로 줄일 수 있습니다.

Transactions and Nested Events

트랜잭션 event의 부모는 해당 트랜잭션을 시작한 event입니다. 명시적으로 시작된 트랜잭션의 경우 여기에는
START TRANSACTION 및 COMMIT AND CHAIN 구문이 포함됩니다. 암시적으로 시작된 트랜잭션의 경우, 이는 이전 트랜잭션이 종료된 후 트랜잭션 스토리지 엔진을 사용하는 첫 번째 구문입니다.

일반적으로 트랜잭션은 트랜잭션 동안 시작된 모든 event의 최상위 부모입니다. 여기에는
COMMIT 및 ROLLBACK과 같이 트랜잭션을 명시적으로 종료하는 구문도 포함됩니다. 예외는 DDL 구문과 같이 트랜잭션을 암시적으로 종료하는 구문입니다. 이 경우 현재 트랜잭션은 새 구문이 실행되기 전에 커밋되어야 합니다.

Transactions and Stored Programs

트랜잭션과 저장 프로그램 event의 관계는 다음과 같습니다:

• Stored Procedures

저장 프로시저는 트랜잭션과 독립적으로 동작합니다. 저장 프로시저는 트랜잭션 내에서 시작될 수 있으며, 트랜잭션은 저장 프로시저 내부에서 시작되거나 종료될 수 있습니다. 트랜잭션 내에서 호출되는 경우, 저장 프로시저는 부모 트랜잭션의 커밋을 강제하는 구문을 실행한 다음 새로운 트랜잭션을 시작할 수 있습니다.

저장 프로시저가 트랜잭션 내에서 시작된 경우, 해당 트랜잭션은 저장 프로시저 event의 부모입니다.

트랜잭션이 저장 프로시저에 의해 시작된 경우, 저장 프로시저는 트랜잭션 event의 부모입니다.

• Stored Functions

저장 함수는 명시적 또는 암시적 커밋이나 롤백을 유발하는 것이 제한됩니다. 저장 함수 event는 부모 트랜잭션 event 내에 위치할 수 있습니다.

• Triggers

트리거는 관련된 테이블에 접근하는 구문의 일부로 활성화되므로, 트리거 event의 부모는 항상 해당 트리거를 활성화한 구문입니다.

트리거는 트랜잭션의 명시적 또는 암시적 커밋이나 롤백을 유발하는 구문을 실행할 수 없습니다.

• Scheduled Events

스케줄 이벤트 본문 안의 구문 실행은 새로운 커넥션에서 수행됩니다. 스케줄 이벤트를 부모 트랜잭션 안에 중첩하는 것은 적용되지 않습니다.

Transactions and Savepoints

세이브포인트 구문은 개별적인 statement event로 기록됩니다. 트랜잭션 event는 트랜잭션 중에 발행된
SAVEPOINT, ROLLBACK TO SAVEPOINT, RELEASE SAVEPOINT 구문에 대한 별도의 카운터를 포함합니다.

Transactions and Errors

트랜잭션 내에서 발생하는 오류와 경고는 statement event에 기록되지만, 해당 트랜잭션 event에는 기록되지 않습니다. 여기에는 비트랜잭션 테이블에 대한 롤백이나 GTID 일관성 오류와 같은 트랜잭션 특정 오류 및 경고가 포함됩니다.