sql >> データベース >  >> RDS >> Sqlserver

SQLServerでのトランザクションログの重要性

    トランザクションログは、データベースアーキテクチャの重要かつ重要なコンポーネントです。この記事では、SQL Serverのトランザクションログ、重要性、およびデータベース移行におけるそれらの役割について説明します。

    はじめに

    SQLServerのバックアップを取るためのさまざまなオプションについて話しましょう。 SQL Serverは、3種類のバックアップをサポートしています。
    1。フル
    2。ディファレンシャル
    3。トランザクションログ

    トランザクションログの概念に飛び込む前に、SQLServerの他の基本的なバックアップの種類について説明しましょう。

    完全バックアップはすべてのコピーです。名前が示すように、それはすべてをバックアップします。すべてのデータ、ファイル、ファイルグループ、テーブルなどのデータベースのすべてのオブジェクトをバックアップします。–完全バックアップは、他のタイプのバックアップのベースです。

    差分バックアップは、最後の完全バックアップ以降に変更されたデータをバックアップします。

    3番目のオプションはトランザクションログバックアップです。これは、データベースに発行するすべてのステートメントをトランザクションログに記録します。トランザクションログは、「WAL」（先行書き込み）と呼ばれるメカニズムです。すべての情報を最初にトランザクションログに書き込み、次にデータベースに書き込みます。つまり、プロセスは通常、データベースを直接更新しません。これは、データベースの完全復旧モデルで使用可能な唯一の完全なオプションです。他のリカバリモデルでは、データが部分的であるか、ログに十分なデータがありません。たとえば、新しいトランザクションの開始を記録するときのログレコード（LOP_BEGIN_XACTログレコード）には、トランザクションの開始時刻が含まれ、LOP_COMMIT_XACT（またはLOP_ABORT_XACT）ログレコードには、トランザクションがコミット（または中止）された時刻が記録されます。

    オンライントランザクションログの内部を見つけるには、sys.fn_dblog関数をクエリします。

    システム関数sys.fn_dblogは、トランザクションのLSNの開始とLSNの終了の2つのパラメーターを受け入れます。デフォルトでは、NULLに設定されています。 NULLに設定すると、トランザクションログファイルからすべてのログレコードが返されます。

    USE WideWorldImporters
GO
SELECT [Current LSN],
[Operation],
[Transaction Name],
[Transaction ID],
[Log Record Fixed Length],
[Log Record Length]
[Transaction SID],
[SPID],
[Begin Time],
*
FROM fn_dblog(null,null)

    ご存知のとおり、トランザクションはバイナリ形式で保存されており、読み取り可能な形式ではありません。オフライントランザクションログファイルを読み取るには、fn_dump_dblogを使用できます。

    トランザクションログファイルをクエリして、fn_dump_dblogを使用してオブジェクトをドロップしたユーザーを確認しましょう。

    SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], SUSER_SNAME ([Transaction SID]) AS DBUser
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
Context IN ('LCX_NULL') AND Operation IN ('LOP_BEGIN_XACT')
AND [Transaction Name] LIKE '%DROP%'

    fn_dblog（）関数を使用して、トランザクションログのアクティブな部分を読み取り、データに対して実行されるアクティビティを検索します。トランザクションログがクリアされたら、fn_dump_dblog（）を使用してログファイルからデータをクエリする必要があります。

    この関数はfn_dblog（）と同じ行セットを提供しますが、トラブルシューティングとリカバリのシナリオで役立ついくつかの興味深い機能があります。具体的には、現在のデータベースのトランザクションログだけでなく、ディスクまたはテープ上のトランザクションログのバックアップも読み取ることができます。

    トランザクションファイルを使用してドロップされるオブジェクトのリストを取得するには、次のクエリを実行します。最初に、データは一時テーブルにダンプされます。場合によっては、fun_dump_dblog（）の実行に少し時間がかかります。したがって、一時テーブルにデータをキャプチャすることをお勧めします。

    [ロック情報]列からオブジェクトIDを取得するには、次のクエリを実行します。

    SELECT * INTO TEMP
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
[Transaction ID] in(
SELECT DISTINCT [Transaction ID]
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
[Transaction Name] LIKE '%DROP%')
and [Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%'

    [ロック情報]列からオブジェクトIDを取得するには、次のクエリを実行します。

    SELECT DISTINCT [Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4,
Substring([Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4) objectid
from temp

    object_idは、[ロック情報]列の値を操作することで見つけることができます。対応するオブジェクトIDのオブジェクト名を見つけるには、テーブルが削除される直前にバックアップからデータベースを復元します。復元後、システムビューにクエリを実行して、オブジェクト名を取得できます。

    USE AdventureWorks2016;
GO
SELECT name, object_id from sys.objects
WHERE object_id = '1815677516';

    ここで、sys.dn_dblog、sys.fn_full_dblogを使用して、同じトランザクションの詳細のさまざまな形式を見てみましょう。システム関数fn_full_dblogは、SQLServer2017でのみ機能します。

    fn_dblogを使用して上位10件のトランザクションを取得するようにクエリします。

    SELECT TOP 10 * FROM sys.fn_dblog(null,null)

    SQL Server 2017以降では、fn_fulldblogを使用できます。

    SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)

    sp_helptext fn_full_dblogを使用して、システム関数をさらに詳しく調べることができます。

    次に、fn_full_dblogを使用してシステム関数を使用してバックアップファイルをクエリします。繰り返しになりますが、これはSQLServer2017以降にのみ適用されます。

    ポイントインタイムリストア

    ログバックアップ全体のリストがあると仮定します。その後、ログを復元する場合は、データのポイントインタイム復元を実行する可能性があります。したがって、ログの復元の過程で、必ずしもすべてのデータを復元する必要はありません。個々のトランザクションの直前、前、または直後にデータを復元できます。したがって、データベースが特定の時間にクラッシュし、完全バックアップとログバックアップの両方がある場合、最初に完全バックアップを復元してからログバックアップを復元し、その過程で、特定の時間まで最後のログを復元できるはずです。 、これにより、データベースはこの問題が発生する前の状態のままになります。

    ログバックアップは、かなり一般的なVLDB（Very Large Database）および最も重要なデータベースです。復元プロセスをテストすることを常にお勧めします。データベースのバックアップを行うときは常に、復元プロセスについてよく考えることをお勧めします。また、復元プロセスをより頻繁にテストする必要があります。

    復元プロセスのテストを時々軽減することは常に良いことです。そのため、プロセスが正常にバックアップを実行することを確認してください。

    シナリオ

    非常に大規模なデータベースを復元する必要があり、通常は数時間かかることがわかっているシナリオについて説明します。これは、誰もが知っておくべきことです。データ損失がゼロで停止ウィンドウが小さいデータベース移行を計画している場合でも、それはかなり大きな問題になる可能性があります。したがって、プロセスを高速化するために、必ずトランザクションログのバックアップに依存するようにしてください。

    2つの異なるバージョンのSQLServer間でデータベースを並べて移行する別のシナリオを考えてみましょう。ターゲット上の同じソフトウェアバージョンへのデータベースの移行に関与しており、オペレーティングシステム、データベース、アプリケーション、ネットワークなどの転送が含まれます。-;あるハードウェアから別のハードウェアにデータベースを移行する。ソフトウェアとハ​​ードウェアの両方を変更します。データベース移行のプロセスは常に課題であり、データの損失は常に可能であり、環境に左右されます。

    データベース移行のベストプラクティス

    データベース移行管理の標準的な方法について説明しましょう。

    移行は、データの不整合を回避するためにトランザクション方式で実行する必要があります。移行プロセスの通常の手順は、通常、次のとおりです。

    • アプリケーションサービスを停止します—ここからダウンタ​​イムが始まります
    • ログのバックアップを開始します。要件によって異なります
    • データベースにそれ以上の変更が加えられないように、データベースをリカバリモードにします
    • ログファイルを移動します
    • データベースのトランザクションログファイルを復元します。ただし、データベースの完全バックアップをターゲットに復元し、データベースを復元状態のままにしておきます。
    • ログインのクローンを作成し、孤立したユーザーを修正します
    • ジョブの作成
    • アプリケーションをインストールします
    • ネットワークの構成–DNSエントリの変更
    • アプリケーション設定を再構成する
    • アプリケーションサービスを開始する
    • アプリケーションをテストする

    はじめに

    この記事では、非常に大規模なOLTPデータベースの移行を処理する方法について説明します。 SQLサーバー技術とサードパーティツールを使用してデータの安全性を確保するための戦略と、本番システムの可用性への影響をゼロまたは最小限に抑える方法について説明します。プロセス中、データを失う可能性は常にあります。トランザクションのシームレスな処理は良い戦略だと思いますか？ 「はい」の場合、お気に入りのオプションは何ですか？

    利用可能なオプションについて詳しく見ていきましょう：

    • バックアップと復元
    • ログ配布
    • データベースのミラーリング
    • サードパーティツール

    バックアップと復元

    データベースのバックアップと復元の手法は、データベースの移行に最も適したオプションです。適切に計画およびテストされていれば、予期しない多くの移行エラーを回避できます。バックアップはオンラインプロセスであることは誰もが知っています。トランザクションログのバックアップをタイムリーに開始して、新しいデータベースに提供するトランザクションの数を絞り込むのは簡単です。移行期間中、ユーザーがデータベースにアクセスするのを制限し、最後の1つのログバックアップを開始して、それを宛先に転送することができます。このようにして、ダウンタイムを大幅に短縮できます。

    ログ配布

    私たちは皆、データベースの世界におけるログファイルの重要性を理解しています。ログ配布技術は、優れたディザスタリカバリソリューションを提供し、復元ジョブの合間に、セカンダリデータベースへの限定的な読み取り専用アクセスをサポートします。これは基本的にトランザクションログをバックアップするという概念であり、もう1つのセカンダリデータベースの完全バックアップで再生されます。これらのセカンダリデータベースはプライマリデータベースの複製コピーであり、プライマリデータベースとの同期を維持するために、トランザクションログのバックアップを独自のコピーに継続的に復元します。セカンダリデータベースは別のハードウェア上にあるため、何らかの理由でプライマリに障害が発生した場合、システムの完全にバックアップされたコピーをすぐに使用でき、ネットワークトラフィックをセカンダリサーバーに再ルーティングするだけで、ユーザーは障害が発生しました。ログ配布は、ほとんどの場合、移行をより広範囲に管理するための簡単で効果的な方法を提供します。

    ミラーリング

    ソースとターゲットの両方が同じバージョンとエディションである場合、データベースミラーリングはデータベース移行のオプションでもあります。基本的に、ミラーリングは2つのハードウェアインスタンス上にデータベースの2つの重複コピーを作成します。トランザクションは両方のデータベースで同時に発生します。本番データベースをオフラインにして、そのデータベースのミラーバージョンに切り替え、ユーザーが何も起こらなかったかのようにデータにアクセスし続けることができるようにすることができます。実装に関しては、プリンシパルサーバー、ミラーサーバー、および監視を扱います。ただし、これは非推奨の機能になり、SQLServerの将来のバージョンから削除される予定です。

    概要

    この記事では、バックアップの種類、トランザクションログのバックアップの詳細、データ移行の標準、プロセス、戦略について説明し、データ移行手順を効果的に処理するためにSQL技術を使用する方法を学びました。

    トランザクションログ書き込みメカニズムWALは、トランザクションが常に最初にログファイルに書き込まれることを保証します。このようにして、SQL Serverは、コミットされたすべてのトランザクションの効果が最終的にデータファイルに（ディスクに）書き込まれること、および不完全なトランザクションに起因するディスク上のデータ変更がロールバックされ、データファイルに反映されないことを保証します。

    ほとんどの場合、データ同期の遅延は予期せず、データの損失は永続的です。多くの場合、それはすべてデータベースのサイズと利用可能なインフラストラクチャに依存します。推奨される方法として、展開の一部としてではなく手動で移行を実行して、出力をより予測できるように物事を分離しておくことをお勧めします。

    個人的には、さまざまな理由でログ配布を希望します。古いサーバーからデータの完全バックアップを事前に取得し、新しいサーバーに取得して復元し、残りのトランザクションを適用することができます（t-logバックアップ）。 ）ポイントからカットオーバーの瞬間まで。プロセスは実際には非常に簡単です。

    正しい方法で行われれば、データベースの移行は難しくありません。この投稿が、データベースの移行をよりスムーズに実行するのに役立つことを願っています。


    1. MariaDB JSON_SET（）の説明

    2. Oracleデータベースで例外変数を使用してユーザー定義の例外を宣言する方法

    3. Oracleでカレンダーテーブルにデータを入力する方法は？

    4. PDOプリペアドステートメントの安全性