Data Management (DMS) の通常のデータ変更機能を使用すると、INSERT、UPDATE、DELETE、TRUNCATEなどのSQL文を直接または定期的に実行して、データベース内のデータを変更できます。 このトピックでは、通常のデータ変更チケットを送信する方法について説明します。
操作の概要
通常のデータ変更チケットを設定して送信します。
管理するデータベースまたはインスタンスを選択します。 次に、データ変更のSQL文を入力するか、SQL文を含むファイルをアップロードします。
事前チェックを実行します。
DMSは、送信したSQLステートメントが、サポートされている通常データの変更機能のタイプと一致するかどうか、およびSQLステートメントを実行するために必要な権限があるかどうかを確認します。
チケットを調べて承認します。
DMSは、実行するSQL文がデータベースのパフォーマンスに影響するかどうか、およびSQL文を実行するために必要な権限があるかどうかを確認します。
データを変更します。
データ変更のために送信されたSQL文を実行します。 データ変更中にエラーが発生した場合、またはSQL文によって行われたデータ変更を元に戻す必要がある場合、DMSを使用すると、変更完了後に元のデータを復元するためのロールバックチケットを作成できます。
前提条件
使用するデータベースインスタンスは、DMSの安定した変更またはセキュリティコラボレーションモードで管理されます。 詳細については、「制御モード」をご参照ください。
使用上の注意
承認のためにデータ変更チケットを提出した後、チケットが承認されたか拒否されたかに関係なく、チケットを閉じることができます。 これにより、チケットが承認された後に、チケットに関連付けられたタスクが実行されなくなります。
テスト環境でのデータ変更のチケットを提出することを推奨します。 これにより、システムは影響を受ける行の数を確認し、データ変更ごとにバックアップファイルを生成します。 これにより、データが期待どおりに変更されていない場合にデータを復元できます。
説明
高い研究開発効率を確保するために、テスト環境でデータ変更チケットの承認が不要であることを指定できます。 詳細については、「SQL Correct」をご参照ください。
DMSで論理データベース、論理テーブル、およびルーティングアルゴリズムを設定した場合、シャードデータベースとテーブルに送信できるチケットは1つだけです。 この方法では、物理データベースまたはテーブルごとにチケットを提出する必要はありません。
ルーティングアルゴリズムを構成し、データベースとテーブルのシャードに使用されるSQLステートメントにルーティングフィールドが含まれている場合、ルーティングアルゴリズムはステートメントを対応する物理テーブルにルーティングして実行します。
ルーティングアルゴリズムを設定しない場合、SQL文にルーティングフィールドが含まれていない場合、またはルーティングフィールドのデータ型がルーティングアルゴリズムで指定されたデータ型と一致しない場合、SQL文は各データベースの各テーブルに対して順番に実行されます。 このプロセスは、完了するのにより長い時間を必要とする。
DMSは、UPDATE
またはDELETE
ステートメントが実行される前に、対応するバックアップスクリプト添付ファイルを自動的に生成します。
手順
手順1: チケットの設定と送信
DMSコンソールV5.0 にログインします。
DMSコンソールの左上隅にある
アイコンの上にポインターを移動し、 を選択します。
説明
DMSコンソールを通常モードで使用する場合は、上部のナビゲーションバーで を選択します。
[データ変更チケット] ウィザードの [適用] ステップで、データ変更チケットを送信するためのパラメーターを設定します。 次の表に、いくつかのパラメーターを示します。
パラメーター | 必須 / 任意 | 説明 |
ターゲットの変更 | 対象 | 有効な値はデータベースとデータソースインスタンスです。 説明 データソースインスタンスの変更機能は、ApsaraDB RDS for MySQLインスタンス、PolarDB for MySQLクラスター、およびAnalyticDB for MySQLクラスターでのみサポートされています。 |
データベースまたはインスタンス | 対象 | チケットを送信するデータベースまたはインスタンス。 変更権限を持つデータベースまたはインスタンスを選択する必要があります。 説明 選択できるデータソースインスタンスは1つだけです。 |
理由カテゴリ | 対象 | データ変更の理由。 これにより、後続の操作でチケットを見つけることができます。 説明 DMS管理者の場合、モジュールの [設定管理] ページで理由カテゴリを変更できます。 詳細については、「構成管理」をご参照ください。 |
ビジネスの背景 | 対象 | データ変更の目的または目的。 承認プロセスを高速化するには、詳細な説明を入力します。 |
実行方法 | 対象 | チケットの実行方法。 有効な値: チケット提出者は承認時に実行します 承認時に自動的に実行 最後の承認者の実行
説明 DMS管理者の場合、モジュールの [設定の管理] ページで実行方法を変更できます。 詳細については、「構成管理」をご参照ください。 |
影響を受ける行 | 対象 | データ変更の影響を受ける可能性のあるデータ行の推定数。 |
変更のSQLステートメント | 対象 | データ変更に使用されるSQL文。 テキストまたは添付ファイルを選択できます。 |
SQLテキスト | 対象 | このパラメーターは、[変更] パラメーターを [テキスト] に設定した場合にのみ使用できます。 [SQLテキスト] フィールドに実行可能SQL文を入力します。 説明 複数のSQL文はセミコロン (;) で区切ります。 Change TargetパラメーターをData Source Instanceに設定した場合、SQL文のすべてのテーブル名の前に ${dbName}.${tableName} 形式でデータベース名を追加する必要があります。 DMSは、チケットの送信時にSQL文の構文が有効かどうかを確認します。 構文が無効な場合、チケットを起票することはできません。
|
添付ファイル | 対象 | このパラメーターは、[変更] パラメーターを [添付] に設定した場合にのみ使用できます。 データ変更に使用されるSQL文を格納するファイルをアップロードします。 説明 アップロードするファイルは、TXT、ZIP、またはSQLファイルです。 ファイルのサイズは15 MBを超えることはできません。 |
ロールバックのSQLステートメント | 非対象 | ロールバックに使用されるSQL文。 テキストまたは添付ファイルを選択できます。 説明 ロールバック用のSQLステートメントを入力した場合、またはロールバック用のSQLファイルをアップロードした場合にのみ、ロールバックチケットを作成するときに、DMSはロールバック用のステートメントを自動的に入力します。 それ以外の場合は、SQL文を手動で入力する必要があります。 |
SQLテキスト | 非対象 | このパラメーターは、ロールバック用SQLステートメントパラメーターをテキストに設定した場合にのみ使用できます。 ロールバック用のSQL文を入力します。 このパラメーターに指定するSQL文は、データ変更をロールバックするために使用されます。 |
添付ファイル | 非対象 | このパラメーターは、ロールバック用SQLステートメントパラメーターを [添付ファイル] に設定した場合にのみ使用できます。 [ファイル] をクリックして、ロールバックに使用するSQL文を含むファイルをアップロードします。 説明 アップロードするファイルは、TXT、ZIP、またはSQLファイルです。 ファイルのサイズは15 MBを超えることはできません。 |
利害関係者の変更 | 非対象 | データ変更に関与する利害関係者。 指定されたすべての利害関係者は、チケットの詳細を表示し、承認プロセスに参加できます。 DMS管理者とデータベース管理者 (DBA) 以外の無関係なユーザーは、チケットの詳細にアクセスできません。 |
添付ファイル | 非対象 | データ変更に関する追加情報を提供するために、チケットの添付ファイルとして使用されるファイル。 |
送信 をクリックします。
手順2: SQL文の事前チェック
チケットを送信すると、システムは自動的にチケットの事前チェックを実行します。 チケットが事前チェックに失敗した場合は、プロンプトに従ってSQL文を変更し、チケットを再度送信します。

ステップ3: チケットの確認と承認
チケットが事前チェックに合格したら、[承認の送信] をクリックします。 [プロンプト] メッセージで、[OK] をクリックします。
説明
デフォルトでは、データ変更チケットはDBAによって承認されます。 既定の承認テンプレートを変更する方法の詳細については、「SQL Correct」トピックの既定の承認テンプレートの変更セクションをご参照ください。
ステップ4: データ変更
重要
オフピーク時にデータ変更を実行することを推奨します。
申請が承認されたら、[変更の実行] をクリックします。 [タスク設定] ダイアログボックスで、次の表に示すタスク実行パラメーターを設定し、[実行の確認] をクリックします。
パラメーター | 説明 |
実行戦略 | チケットのタスクをすぐに実行するか、スケジュールされた時間に実行するかを指定します。 有効な値: |
単一トランザクションとしての送信の有効化 | すべてのステートメントを1つのトランザクションとして送信するかどうかを指定します。 デフォルトでは、このスイッチはオフになっています。 有効な値: |
バックアップの有効化 | データをバックアップするかどうかを指定します。 デフォルトでは、このスイッチはオフになっています。 バックアップを有効にすると、バックアップファイルを使用してデータを復元できます。 有効な値: |
説明
SQLタスクの実行は、SQL実行を制御するためにセキュリティルールで構成されたチェックポイントによって監視されます。 チェックポイントの例には、SQL実行前のデータベースロックタイムアウトメカニズム、SQL実行前のデータベースロードチェック、およびSQL実行後のスリープポリシーが含まれます。 SQLの実行を制御するためにセキュリティルールに設定されているチェックポイントを確認するには、セキュリティルールの詳細ページに移動し、左側のウィンドウで [SQL実行制御] をクリックします。 デフォルトのチェックポイント設定を変更する方法の詳細については、「SQL実行時にコントロールを構成する」をご参照ください。
(オプションの手順) ロールバックチケットを作成し、元のデータを復元します。
データが期待どおりに変更されない場合は、ロールバックチケットを作成するか、手動で通常のデータ変更チケットを送信してデータを復元できます。 次のセクションでは、ロールバックチケットを作成する方法について説明します。
[実行] セクションで、管理するデータベースの [操作] 列の [ロールバックチケットの生成] をクリックします。
ロールバックするソースを選択し、[OK] をクリックします。 次のソースがサポートされています。
ロールバックテキスト: チケット情報を設定するときに事前に入力されるロールバックテキスト。
ロールバック添付ファイル: チケット情報を構成するときにアップロードされるロールバック添付ファイル。
バックアップファイル: チケットの実行中に生成されるバックアップ添付ファイル。
説明
バックアップファイルを使用してデータを復元するには、データ変更を実行する前にバックアップ機能を有効にする必要があります。
必要に応じて、 ビジネス要件に基づいて、ロールバックテキスト、ロールバック添付ファイル、またはバックアップファイルを設定します。
ロールバック情報を確認し、[送信] をクリックします。 フォローアップチケットプロセスは、通常のデータ変更チケットプロセスと同じです。
バックアップファイルをダウンロードします。
変更後にバックアップファイルを保存するか、バックアップファイルをDMSにアップロードする場合は、バックアップファイルをダウンロードする必要があります。
[操作] 列の [バックアップのダウンロード] をクリックします。 バックアップファイルには、次の情報が含まれます。
データを変更するために実行された元のSQL文。
元のSQL文のSELECT句。
データのバックアップに使用されるSQL文。
例:
REPLACE INTO `t_order`(`id`,`product_id`,`gmt_create`,`gmt_modified`,`customer_id`,`price`,`status`,`province`) VALUES
(10054,81,'2021-12-14 09:44:44','2021-12-14 09:44:44',71,63.45,'Success','Hangzhou');
バックアップファイルからデータバックアップ用のSQL文を抽出します。 ステートメントが有効であることを確認したら、通常のデータ変更チケットを起票し、実際のシナリオに基づいてデータベースデータを復元します。
説明
データ変更に対して不適切なUPDATE
ステートメントが実行され、データバックアップ用にINSERT
ステートメントが生成された場合、データを手動で復元する必要があります。
必要に応じて、 データが期待どおりに変更されているかどうかを確認します。
チケット詳細パネルの [基本情報] セクションで、データベース名の上にポインターを移動し、[クエリ] をクリックします。

データベースの [SQLConsole] タブで、テーブルデータが期待どおりかどうかを確認します。