日常の運用・保守業務において、MySQL データベースサーバーで SQL 文を実行すると、サーバーの CPU 使用率が急激に上昇するため、どの SQL 文を確認すればよいかを既存の手段で迅速に特定し、応急処置を行う方法。この記事では、従来のオペレーティング システムのスレッドに基づく CPU 使用率の監視方法を紹介し、オペレーティング システムのスレッド ID と MySQL のスレッド ID の対応関係を使用して、異常な SQL とトランザクションを徐々に特定します。
1. オペレーティング システムのプロセスとスレッド ID
1.1 MySQL のシングル プロセスとマルチスレッドの関係
MySQL は単一プロセスのマルチスレッド データベースです. プロセスは実行中のプログラムのインスタンスであり、スレッドはオペレーティング システムが操作のスケジューリングを実行できる最小単位です.
- プロセス: メモリ内で実行されるアプリケーション プログラムを指し、各プロセスは独立したメモリ空間を持ちます; プロセスはプログラムの実行プロセスでもあり、プログラムを実行するシステムの基本単位です; システムでプログラムを実行します創造から死ぬまでのプロセスです。
- スレッド: スレッドはプロセス内の実行単位であり、現在のプロセス内のプログラムの実行を担当します。プロセス内には少なくとも 1 つのスレッドがあります。スレッドは、オペレーティング システムが操作のスケジューリングを実行できる最小単位であり、プロセスに含まれ、プロセス内の実際の操作単位です。プロセス内で複数のスレッドを同時に実行でき、各スレッドが異なるタスクを並行して実行します。
MySQL データベースは、プロセスが同時に多くのスレッドを異なる CPU に同時に送信し、スレッドが同じメモリ ユニット/メモリ アドレス空間を共有するため、シングルプロセス マルチスレッドを選択します。スレッド間の通信は同じアドレスで実行されるためです。通信を容易にし、情報転送を高速化する追加の通信メカニズムは必要ありません。
上の画像はMySQLストレージエンジンInnoDBのバックグラウンドスレッドで、「InnoDB Storage Engine Decryption」で詳しく紹介されています。InnoDB バックグラウンド スレッドは、主にサーバーの通常の動作を維持し、ユーザーが送信したタスクを完了するために使用されます。主に、マスター スレッド、ページ クリーナー スレッド、パージ スレッド、読み取りスレッド、書き込みスレッド、再実行ログ スレッド、挿入バッファー スレッド、モニター スレッドが含まれます。 、エラー監視スレッド、ロック監視スレッドなど
1.1.1 マスタースレッド
マスター スレッドはコア バックグラウンド スレッドであり、主にバッファー プール内のデータをディスクに非同期的に更新して、ダーティ ページの更新、バッファーのマージと挿入、取り消しページのリサイクルなど、データの整合性を確保します。マスター スレッドは、メイン ループ、バックグラウンド ループ、更新ループ、一時停止ループなどの複数のループで構成されており、マスター スレッドはデータベースの状態に応じて異なるループを切り替えます。InnoDB 1.0.x より前のメイン ループでは、1 秒ごとの操作と 10 秒ごとの操作の 2 つの主要な操作があります。
1) 1 秒に 1 回の操作には以下が含まれます。
- ログ バッファは、トランザクションがまだコミットされていなくても (常に) ディスクにフラッシュされます。これが、大規模なトランザクションのコミットが非常に高速である理由を説明しています
- マージ挿入バッファ (おそらく)、マージ挿入は毎秒発生しません。InnoDB は、現在の 1 秒間に発生している IO の数が 5 未満かどうかを判断します。はいの場合、システムは現在の IO 圧力が非常に小さいと判断します。マージ挿入バッファ操作を実行します。
- InnoDB のバッファー プールの最大 100 のダーティ ページをディスクに更新します (おそらく)。この 100 のダーティ ページの更新は、毎秒行われるわけではありません。
トランザクションがコミットされていない場合でも、InnoDB ストレージ エンジンは再実行ログ キャッシュの内容を毎秒再実行ログにフラッシュします。
2) 10 秒ごとの操作には以下が含まれます。
- 100 ページのダーティ ページをディスクにフラッシュします (おそらく)。
- 最大 5 つの挿入バッファーを (常に) マージします。
- ログ バッファをディスクにフラッシュします (常に)。
- 無駄な元に戻すページを削除します (常に)。
- チェックポイント (checkpoing) を生成します。
上記のプロセスでは、InnoDB ストレージ エンジンはまず、過去 10 秒間のディスク IO 操作が 200 回未満であるかどうかを判断し、十分なディスク IO 操作能力があると InnoDB ストレージ エンジンが判断した場合、100 個のダーティ ページをディスクにフラッシュします。ディスク。次に、InnoDB ストレージ エンジンは挿入バッファーをマージし、ログ バッファーをディスクにフラッシュします。最後に、InnoDB ストレージ エンジンは完全なパージ操作を実行して、不要な取り消しページを削除します. まず、現在のシステムで削除のマークが付けられている行を削除できるかどうかを判断し、削除できる場合はすぐに削除できます.
InnoDB 1.0.x バージョンより前では、InnoDB ストレージ エンジンには IO に関する制限があり、バッファー プールはディスク更新用にハードコーディングされていました. ディスク ハードウェア パフォーマンスの向上に伴い、この方法ではディスク IO での InnoDB のパフォーマンスが制限されます. したがって、バージョン 1.0.x 以降、InnoDB はディスク IO のスループットを示すパラメータ innodb_io_capacity を提供し、デフォルト値は 200 です。ディスクにフラッシュされるページ数は、innodb_io_capacity のパーセンテージに従って制御されます。
- 挿入バッファーをマージする場合、マージされた挿入バッファーの数は innodb_io_capacity 値の 5% です。
- ダーティ ページをバッファからフラッシュする場合、フラッシュされるダーティ ページの数は innodb_io_capacity です。
コマンド show engine innodb status; は、マスター スレッド情報を表示できます。
=====================================
2021-08-22 20:38:37 140186194323200 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 12 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 1 srv_active, 0 srv_shutdown, 255 srv_idle
srv_master_thread log flush and writes: 0
1.1.2 スレッドのパージ
After the transaction is commit, the undo log it uses may no longer need, so Purge Thread is needed to reclaim the undo pages that has been used and allocated. その機能は、実際にレコードを削除し、undo ログを削除することです。
たとえば、ステートメント delete from tb1 where pk=1; は次のようになります。
- pk=1 のレコードを削除としてマークします (delete-mark、infobits)。データベース内の pk=1 のレコードはこの時点でまだ存在し、スペースは解放されていません。この操作は同期操作です (SQLが実行され、マークが完成します)
- パージはバックグラウンド スレッド (パージ スレッド) の非同期操作であり、実際にレコードを削除してスペースを解放します。パージ スレッドはシステムによって自動化され、手動で制御することはできません。
ページが削除済みとしてマークされる理由は 2 つあります: 1) モノをロールバックする必要がある可能性があるため、最初にそれを保持します; 2) モノ 1 が pk=1 を削除し、それを送信しない場合、モノ 2 が表示できる必要がありますpk=1 記録 (モノの分離)。次の表に示すように、異なるフィルタ条件に従って、削除マークの処理が異なります。
したがって、delete-mark としてマークされたレコードは最後にパージ スレッドによって再利用され、Purge はそのレコードで取り消しを参照しているものが他にあるかどうかを検出し、そうでない場合は削除できます。InnoDB バージョン 1.2 以降、InnoDB は複数のパージ スレッドをサポートしており、元に戻すページの回復を高速化できます. 同時に、元に戻すページを個別に読み取ると、ディスクのランダム読み取りパフォーマンスがさらに向上します. 現在、MySQL 8.0 のデフォルト設定は 4 です。
mysql> show variables like 'innodb_purge_threads';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| innodb_purge_threads | 4 |
+----------------------+-------+
1 row in set (0.00 sec)
1.1.3 ページクリーナースレッド
Page Cleaner Thread は、InnoDB 1.2.x バージョンで新しく導入されました. その機能は、以前のバージョンのダーティ ページの更新操作を別のスレッドに配置することで、マスター スレッドの作業とユーザー クエリ スレッドのブロックを減らします.
1.1.4 IO スレッド
InnoDB ストレージ エンジンでは、書き込み IO 要求を処理するために非同期 IO が広く使用されています. IO スレッドの作業は、主にこれらの IO 要求のコールバック処理を担当します. InnoDB には 4 つの IO スレッド、つまり、書き込み、読み取り、挿入バッファー、およびログ IO スレッドがあります。
- 書き込みスレッド: データベースの書き込み操作を担当し、複数の書き込みスレッドを構成できます
- 読み取りスレッド: データベースの読み取り操作を担当し、複数の読み取りスレッドを構成できます
- 挿入バッファー スレッド: 主に挿入バッファーのマージ操作を担当します。
- ログ スレッド: REDO ログをログ ファイルにフラッシュするために使用されます。
InnoDB の IO スレッドは、コマンド SHOW ENGINE INNODB STATUS で確認できます。
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,
ibuf aio reads:, log i/o's:, sync i/o's:
Pending flushes (fsync) log: 0; buffer pool: 0
854 OS file reads, 207 OS file writes, 38 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
1.2 システムで MySQL プロセス ID を取得する
Linux システムで MySQL プロセス ID を取得する方法は非常に簡単で、コマンド ps -ef|grep mysqld を使用してシステム プロセス ID を確認します。以下に示すように、MySQL プロセスの実行中の ID は 1479 です。
[root@tango-GDB-DB01 ~]# ps -ef|grep mysqld
mysql 1479 1090 1 16:59 ? 00:00:03 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=tango-GDB-DB01.err --pid-file=/usr/local/mysql/data/tango-GDB-DB01.pid --socket=/tmp/mysql.sock
1.3 MySQL プロセス下のスレッド ID 情報
Linux で特定のスレッド情報を表示するには、いくつかの方法があります。
1) TOP -H スレッド情報を表示します
top コマンドは、各スレッドのステータスをリアルタイムで表示できます.top コマンドの "-H" オプションを呼び出すと、すべての Linux スレッドが一覧表示されます。-p を追加すると、次のように、特定のプロセスでスレッド情報がフィルター処理されます。
[root@tango-GDB-DB01 ~]# top -H -p 1479
top - 17:10:44 up 11 min, 2 users, load average: 0.00, 0.05, 0.05
Threads: 39 total, 0 running, 39 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1867024 total, 1051452 free, 495804 used, 319768 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 1185628 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1479 mysql 20 0 1318236 367380 16280 S 0.0 19.7 0:01.55 mysqld
1527 mysql 20 0 1318236 367380 16280 S 0.0 19.7 0:00.00 mysqld
1528 mysql 20 0 1318236 367380 16280 S 0.0 19.7 0:00.00 mysqld
2) ps コマンドで、「-T」オプションを使用すると、スレッドの表示を有効にできます。
次のコマンドは、プロセス ID 1479 によって作成されたすべてのスレッドを一覧表示します。
ps -aT -p <pid>
[root@tango-GDB-DB01 ~]# ps -aT -p 1479
PID SPID TTY TIME CMD
1479 1479 ? 00:00:01 mysqld
1479 1527 ? 00:00:00 mysqld
1479 1528 ? 00:00:00 mysqld
3) コマンド ps -Lef でスレッドを表示する
[root@tango-GDB-DB01 ~]# ps -Lef|grep 1479
UID PID PPID LWP C NLWP STIME TTY TIME CMD
mysql 1479 1090 1479 0 39 16:59 ? 00:00:01 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=tango-GDB-DB01.err --pid-file=/usr/local/mysql/data/tango-GDB-DB01.pid --socket=/tmp/mysql.sock
mysql 1479 1090 1527 0 39 16:59 ? 00:00:00 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=tango-GDB-DB01.err --pid-file=/usr/local/mysql/data/tango-GDB-DB01.pid --socket=/tmp/mysql.sock
上記のコマンドで、PID はプロセス番号を示し、LWP はスレッド ID を示し、C は CPU 使用率を示し、NLWP はスレッド グループ内のスレッドの数を示します。
1.4 pstack スレッドスタック情報を表示する
プロセス内のスタック情報を表示するにはコマンド pstack を使用します. pstack を実行すると mysqld プロセスが一時的にブロックされるため, 繁忙期には実行しないでください.
2.システムスレッドIDとMySQLスレッドIDの対応
2.1 MySQL の ProcessID と ThreadID
1) MySQL に接続し、次のステートメントを実行します。
[root@tango-GDB-DB01 local]# mysql -h192.168.112.121 -P3306 -uroot -p –A
mysql> begin;
mysql> begin;select count(1),sleep(2000) from tango.t2 for update;
2) show processlist プロセスリスト情報を表示し、processlist_id を見つける
mysql> show processlist;
+----+-----------------+----------------------+-------+---------+------+------------------------+-------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+----------------------+-------+---------+------+------------------------+-------------------------------------------+ |
| 10 | root | tango-GDB-DB01:50620 | tango | Query | 52 | User sleep | select count(1),sleep(2000) from tango.t2 for update |
| 11 | root | localhost | NULL | Query | 0 | init | show processlist |
+----+-----------------+----------------------+-------+---------+------+------------------------+-------------------------------------------+
3 rows in set (0.00 sec)
3) MySQL 内部スレッドに対応するシステム スレッド ID を見つけます。
MySQL 5.7 から、performance_schema.threads テーブルに THREAD_OS_ID カラムが追加されました。これは、MySQL 内部スレッドに対応するシステム スレッド ID を記録するために使用されます。
mysql> select * from performance_schema.threads where processlist_id=10\G
*************************** 1. row ***************************
THREAD_ID: 49
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 10
PROCESSLIST_USER: root
PROCESSLIST_HOST: tango-GDB-DB01
PROCESSLIST_DB: tango
PROCESSLIST_COMMAND: Query
PROCESSLIST_TIME: 84
PROCESSLIST_STATE: User sleep
PROCESSLIST_INFO: select count(1),sleep(2000) from tango.t2 for update
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: SSL/TLS
THREAD_OS_ID: 1657
RESOURCE_GROUP: USR_default
1 row in set (0.00 sec)
上記は、MySQL 内の thread_id と対応するオペレーティング システムのスレッド ID を検出します: THREAD_OS_ID
4) 対応するオペレーティング システムのスレッド情報を見つける
[root@tango-GDB-DB01 ~]# top -H -p 1479
top - 17:41:22 up 41 min, 3 users, load average: 0.00, 0.01, 0.05
Threads: 39 total, 0 running, 39 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 1.5 sy, 0.0 ni, 98.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1867024 total, 483128 free, 513864 used, 870032 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 1158844 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1657 mysql 20 0 1318236 377188 16536 S 0.0 20.2 0:00.04 mysqld
top -H を介して、メモリと CPU 使用率を含む、対応するスレッドの CPU 使用率を確認できます。
2.2 現在のステートメントと過去のステートメントのクエリ
1) 現在のステートメント テーブルをクエリする
mysql> select * from performance_schema.events_statements_current WHERE THREAD_ID = 49\G
*************************** 1. row ***************************
THREAD_ID: 49
EVENT_ID: 20
END_EVENT_ID: NULL
EVENT_NAME: statement/sql/select
SOURCE: init_net_server_extension.cc:96
TIMER_START: 10615744184481000
TIMER_END: 10743215769959000
TIMER_WAIT: 127471585478000
LOCK_TIME: 121000000
SQL_TEXT: select count(1),sleep(2000) from tango.t2 for update
DIGEST: 91558228446c9877c86805735096b85b8afe5a8148c4ea9c315a1948464ab27f
DIGEST_TEXT: SELECT COUNT (?) , `sleep` (?) FROM `tango` . `t2` FOR UPDATE
CURRENT_SCHEMA: tango
OBJECT_TYPE: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_INSTANCE_BEGIN: NULL
MYSQL_ERRNO: 0
RETURNED_SQLSTATE: NULL
MESSAGE_TEXT: NULL
ERRORS: 0
WARNINGS: 0
ROWS_AFFECTED: 0
ROWS_SENT: 0
ROWS_EXAMINED: 0
CREATED_TMP_DISK_TABLES: 0
CREATED_TMP_TABLES: 0
SELECT_FULL_JOIN: 0
SELECT_FULL_RANGE_JOIN: 0
SELECT_RANGE: 0
SELECT_RANGE_CHECK: 0
SELECT_SCAN: 1
SORT_MERGE_PASSES: 0
SORT_RANGE: 0
SORT_ROWS: 0
SORT_SCAN: 0
NO_INDEX_USED: 1
NO_GOOD_INDEX_USED: 0
NESTING_EVENT_ID: 18
NESTING_EVENT_TYPE: TRANSACTION
NESTING_EVENT_LEVEL: 0
STATEMENT_ID: 37
1 row in set (0.00 sec)
2) SHOW ENGINE INNODB STATUS\G を実行して、トランザクションのステータスを表示します。
---TRANSACTION 2715147, ACTIVE 480 sec
mysql tables in use 1, locked 1
2 lock struct(s), heap size 1136, 3 row lock(s)
MySQL thread id 10, OS thread handle 140127942276864, query id 37 tango-GDB-DB01 192.168.112.121 root User sleep
select count(1),sleep(2000) from tango.t2 for update
Trx read view will not see trx with id >= 2715147, sees < 2715147
MySQL 接続 ID = 10、OS スレッド ハンドル = 140127942276864
3) 過去の thread_statement 情報を表示する
mysql> select * from performance_schema.events_statements_history WHERE THREAD_ID = 49 limit 1 \G
*************************** 1. row ***************************
THREAD_ID: 49
EVENT_ID: 17
END_EVENT_ID: 18
EVENT_NAME: statement/sql/begin
SOURCE: init_net_server_extension.cc:96
TIMER_START: 10288037810168000
TIMER_END: 10288037917673000
TIMER_WAIT: 107505000
LOCK_TIME: 0
SQL_TEXT: begin
DIGEST: 55fa5810fbb2760e86d578526176c1497b134d4ef3dd0863dd78b1c5e819848c
DIGEST_TEXT: BEGIN
CURRENT_SCHEMA: tango
OBJECT_TYPE: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_INSTANCE_BEGIN: NULL
MYSQL_ERRNO: 0
RETURNED_SQLSTATE: 00000
MESSAGE_TEXT: NULL
ERRORS: 0
WARNINGS: 0
ROWS_AFFECTED: 0
ROWS_SENT: 0
ROWS_EXAMINED: 0
CREATED_TMP_DISK_TABLES: 0
CREATED_TMP_TABLES: 0
SELECT_FULL_JOIN: 0
SELECT_FULL_RANGE_JOIN: 0
SELECT_RANGE: 0
SELECT_RANGE_CHECK: 0
SELECT_SCAN: 0
SORT_MERGE_PASSES: 0
SORT_RANGE: 0
SORT_ROWS: 0
SORT_SCAN: 0
NO_INDEX_USED: 0
NO_GOOD_INDEX_USED: 0
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
NESTING_EVENT_LEVEL: 0
STATEMENT_ID: 28
1 row in set (0.00 sec)
2.3 実行時間の長いスレッドまたは高 CPU スレッドを強制終了する
1) 長時間実行されている SQL を見つけるためにプロセスリストを表示する
mysql> show processlist;
+----+-----------------+----------------------+-------+---------+-------+------------------------+------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+----------------------+-------+---------+-------+------------------------+------------------------------------------------------+
| 5 | event_scheduler | localhost | NULL | Daemon | 11423 | Waiting on empty queue | NULL |
| 10 | root | tango-GDB-DB01:50620 | tango | Query | 816 | User sleep | select count(1),sleep(2000) from tango.t2 for update |
2) TOP -H で CPU 消費量の多いスレッドを見つける
プロセスリスト ID への逆引き
mysql> select * from performance_schema.threads WHERE THREAD_OS_ID = 1657\G
*************************** 1. row ***************************
THREAD_ID: 49
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 10
PROCESSLIST_USER: root
PROCESSLIST_HOST: tango-GDB-DB01
PROCESSLIST_DB: tango
PROCESSLIST_COMMAND: Query
PROCESSLIST_TIME: 1050
PROCESSLIST_STATE: User sleep
PROCESSLIST_INFO: select count(1),sleep(2000) from tango.t2 for update
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: SSL/TLS
THREAD_OS_ID: 1657
RESOURCE_GROUP: USR_default
1 row in set (0.00 sec)
3) mysql クライアントでプロセスリスト ID を強制終了します。
mysql> kill 10;
Query OK, 0 rows affected (0.00 sec)
現在の長いトランザクションまたはスレッドを強制終了します
3. OSスレッドハンドルとOSスレッドIDの対応
手順 2.2 で見つかった OS スレッド ハンドル 140127942276864 (OS スレッド ハンドルは、プロセス内の各スレッドを識別するために使用される内部 ID です)。これは 10 進数値であり、最初に 16 進数に変換する必要があります。
mysql> select lower(conv(140127942276864, 10, 16));
+--------------------------------------+
| lower(conv(140127942276864, 10, 16)) |
+--------------------------------------+
| 7f721438f700 |
+--------------------------------------+
1 row in set (0.00 sec)
2) pstack を使用して、ハンドルとオペレーティング システムのスレッド ID の関連付けを照会します。
[root@tango-GDB-DB01 ~]# pstack 1479 |grep 7f721438f700
Thread 3 (Thread 0x7f721438f700 (LWP 1657)):
上記の THREAD_OS_ID 値に対応する LWP=1657 であることがわかります。LWP は Light-Weight Processes の略です。
- https://blog.csdn.net/n88Lpo/article/details/121964562
- データベースシリーズの InnoDB 復号化