トランザクション ログ (SQL Server)The Transaction Log (SQL Server)

適用対象: ○SQL Server XAzure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

すべての SQL ServerSQL Server データベースにはトランザクション ログがあり、データベース内のすべてのトランザクションとそれらのトランザクションによって加えられた変更が記録されます。Every SQL ServerSQL Server database has a transaction log that records all transactions and the database modifications made by each transaction.

トランザクション ログは、データベースの重要なコンポーネントです。The transaction log is a critical component of the database. システム障害がある場合、データベースを一貫性のある状態に戻すには、そのログが必要になります。If there is a system failure, you will need that log to bring your database back to a consistent state.

トランザクション ログのアーキテクチャと内部構造の詳細については、「SQL Server トランザクション ログのアーキテクチャと管理ガイド」を参照してください。For information about the transaction log architecture and internals, see the SQL Server Transaction Log Architecture and Management Guide.

警告

もたらされる影響を完全に理解していない限り、このログを削除または移動しないでください。Never delete or move this log unless you fully understand the ramifications of doing so.

ヒント

データベース復旧時にトランザクション ログの適用を開始する既知の最適なポイントがチェックポイントによって作成されます。Known good points from which to begin applying transaction logs during database recovery are created by checkpoints. 詳細については、「Database Checkpoints (SQL Server)」 (データベース チェックポイント (SQL Server)) をご覧ください。For more information, see Database Checkpoints (SQL Server).

トランザクション ログによりサポートされる操作Operations supported by the transaction log

トランザクション ログでは、次の操作がサポートされます。The transaction log supports the following operations:

  • 個別のトランザクションの復旧Individual transaction recovery.
  • SQL ServerSQL Server の起動時に未完了だったすべてのトランザクションの復旧Recovery of all incomplete transactions when SQL ServerSQL Server is started.
  • 復元したデータベース、ファイル、ファイル グループ、またはページの障害時点までのロールフォワードRolling a restored database, file, filegroup, or page forward to the point of failure.
  • トランザクション レプリケーションのサポートSupporting transactional replication.
  • 高可用性およびディザスター リカバリー ソリューションのサポート: Always On 可用性グループAlways On availability groups、データベース ミラーリング、およびログ配布Supporting high availability and disaster recovery solutions: Always On 可用性グループAlways On availability groups, database mirroring, and log shipping.

個別のトランザクションの復旧Individual transaction recovery

アプリケーションで ROLLBACK ステートメントが実行されるか、データベース エンジンでクライアントとの通信の喪失などのエラーが検出された場合、未完了のトランザクションによって加えられた変更をロールバックするために、ログ レコードが使用されます。If an application issues a ROLLBACK statement, or if the Database Engine detects an error such as the loss of communication with a client, the log records are used to roll back the modifications made by an incomplete transaction.

SQL ServerSQL Server の起動時に未完了だったすべてのトランザクションの復旧Recovery of all incomplete transactions when SQL ServerSQL Server is started

サーバーに障害が起きると、データベースは一部の変更がバッファー キャッシュからデータ ファイルに書き込まれない状態になる場合があり、未完了のトランザクションによる変更がデータ ファイル内に存在している可能性もあります。If a server fails, the databases may be left in a state where some modifications were never written from the buffer cache to the data files, and there may be some modifications from incomplete transactions in the data files. SQL ServerSQL Server のインスタンスは、起動時に各データベースの復旧を行います。When an instance of SQL ServerSQL Server is started, it runs a recovery of each database. ログに記録されていて、データ ファイルに書き込まれなかった可能性があるすべての変更は、ロールフォワードされます。Every modification recorded in the log which may not have been written to the data files is rolled forward. その後、トランザクション ログに記録されている未完了のトランザクションは、データベースの整合性を確保するために、すべてロールバックされます。Every incomplete transaction found in the transaction log is then rolled back to make sure the integrity of the database is preserved.

復元したデータベース、ファイル、ファイル グループ、またはページの障害時点までのロールフォワードRolling a restored database, file, filegroup, or page forward to the point of failure

ハードウェアの故障やディスク障害などによりデータベース ファイルが影響を受けた場合、そのデータベースを障害が発生した時点まで復元できます。After a hardware loss or disk failure affecting the database files, you can restore the database to the point of failure. まずデータベースの最新の完全バックアップまたは差分バックアップを復元し、次にその後の一連のトランザクション ログ バックアップを障害が発生した時点まで復元します。You first restore the last full database backup and the last differential database backup, and then restore the subsequent sequence of the transaction log backups to the point of failure.

各ログ バックアップを復元するときに、ログに記録されている変更がデータベース エンジンにより再適用されて、すべてのトランザクションがロールフォワードされます。As you restore each log backup, the Database Engine reapplies all the modifications recorded in the log to roll forward all the transactions. 最後のログ バックアップまで復元されると、データベース エンジンはログ情報を使用して、障害の時点では完了していなかったすべてのトランザクションをロールバックします。When the last log backup is restored, the Database Engine then uses the log information to roll back all transactions that were not complete at that point.

トランザクション レプリケーションのサポートSupporting transactional replication

ログ リーダー エージェントは、トランザクション レプリケーション用に構成された各データベースのトランザクション ログを監視し、レプリケーションのマークが付けられたトランザクションをトランザクション ログからディストリビューション データベースにコピーします。The Log Reader Agent monitors the transaction log of each database configured for transactional replication and copies the transactions marked for replication from the transaction log into the distribution database. 詳しくは、「 トランザクション レプリケーションの動作方法」をご覧ください。For more information, see How Transactional Replication Works.

高可用性とディザスター リカバリー ソリューションのサポートSupporting high availability and disaster recovery solutions

スタンバイ サーバー ソリューション、Always On 可用性グループAlways On availability groups、データベース ミラーリング、およびログ配布は、トランザクション ログに大きく依存しています。The standby-server solutions, Always On 可用性グループAlways On availability groups, database mirroring, and log shipping, rely heavily on the transaction log.

Always On 可用性グループAlways On availability groups シナリオでは、データベース (プライマリ レプリカ) に対するすべての更新は、別に存在するデータベースの完全なコピー (セカンダリ レプリカ) で直ちに再現されます。In an Always On 可用性グループAlways On availability groups scenario, every update to a database, the primary replica, is immediately reproduced in separate, full copies of the database, the secondary replicas. プライマリ レプリカは各ログ レコードを直ちにセカンダリ レプリカに送信し、セカンダリ レプリカは受信したログ レコードを可用性グループのデータベースに適用します。このようにして継続的に展開されます。The primary replica sends each log record immediately to the secondary replicas which applies the incoming log records to availability group databases, continually rolling it forward. 詳しくは、「 AlwaysOn フェールオーバー クラスター インスタンス」をご覧ください。For more information, see Always On Failover Cluster Instances

ログ配布シナリオでは、プライマリ データベースのアクティブなトランザクション ログがプライマリ サーバーから 1 つ以上の配布先に送信されます。In a log shipping scenario, the primary server sends the active transaction log of the primary database to one or more destinations. 各セカンダリ サーバーでは、受信したログがローカルのセカンダリ データベースに復元されます。Each secondary server restores the log to its local secondary database. 詳しくは、「 ログ配布について」をご覧ください。For more information, see About Log Shipping.

データベース ミラーリング シナリオでは、プリンシパル データベースに対するすべての更新が、そのデータベースの完全なコピーである、独立したミラー データベースに直ちに再現されます。In a database mirroring scenario, every update to a database, the principal database, is immediately reproduced in a separate, full copy of the database, the mirror database. 各ログ レコードは、プリンシパル サーバー インスタンスからミラー サーバー インスタンスに直ちに送信されます。ミラー サーバー インスタンスでは、受信したログ レコードがミラー データベースに適用され、ミラー データベースが継続的にロールフォワードされます。The principal server instance sends each log record immediately to the mirror server instance which applies the incoming log records to the mirror database, continually rolling it forward. 詳しくは、「 データベース ミラーリング」をご覧ください。For more information, see Database Mirroring.

Transaction Log characteristicsTransaction Log characteristics

SQL Server データベース エンジンSQL Server Database Engine のトランザクション ログには、次のような特性があります。Characteristics of the SQL Server データベース エンジンSQL Server Database Engine transaction log:

  • トランザクション ログは、データベース内に別個のファイルまたはファイル セットとして実装されます。The transaction log is implemented as a separate file or set of files in the database. ログ キャッシュはデータ ページ用のバッファー キャッシュとは別に管理され、単純かつ高速の、堅牢なコードとしてSQL Server データベース エンジンSQL Server Database Engineに実装されています。The log cache is managed separately from the buffer cache for data pages, which results in simple, fast, and robust code within the SQL Server データベース エンジンSQL Server Database Engine. 詳細については、「トランザクション ログの物理アーキテクチャ」を参照してください。For more information, see Transaction Log Physical Architecture.
  • ログのレコードとページの形式は、データ ページの形式に従うように制約はされません。The format of log records and pages is not constrained to follow the format of data pages.
  • トランザクション ログは、複数のファイルとして実装できます。The transaction log can be implemented in several files. ログの FILEGROWTH 値を設定することで、これらのファイルが自動的に拡張されるように定義できます。The files can be defined to expand automatically by setting the FILEGROWTH value for the log. これにより、トランザクション ログが領域不足になる可能性が減り、同時に管理のオーバーヘッドも減少します。This reduces the potential of running out of space in the transaction log, while at the same time reducing administrative overhead. 詳細については、「ALTER DATABASE (Transact-SQL) の File および Filegroup オプション」を参照してください。For more information, see ALTER DATABASE (Transact-SQL) File and Filegroup Options.
  • ログ ファイル内の領域を再利用するメカニズムは高速で、トランザクションのスループットに及ぼす影響も最小限で済みます。The mechanism to reuse the space within the log files is quick and has minimal effect on transaction throughput.

トランザクション ログのアーキテクチャと内部構造の詳細については、「SQL Server トランザクション ログのアーキテクチャと管理ガイド」を参照してください。For information about the transaction log architecture and internals, see the SQL Server Transaction Log Architecture and Management Guide.

トランザクション ログの切り捨てTransaction log truncation

ログの切り捨てによりログ ファイルの領域が解放され、トランザクション ログで再利用できるようになります。Log truncation frees space in the log file for reuse by the transaction log. トランザクション ログの定期的な切り捨ては、ログがいっぱいにならないようにするために不可欠です。You must regularly truncate your transaction log to keep it from filling the alotted space. いくつかの要因によってログの切り捨てが遅れる可能性があるため、ログのサイズを監視することは重要です。Several factors can delay log truncation, so monitoring log size matters. 一部の操作は、トランザクション ログのサイズへの影響を軽減するためにログへの記録を最小限に抑えることができます。Some operations can be minimally logged to reduce their impact on transaction log size.

ログの切り捨てでは、SQL ServerSQL Server データベースの論理トランザクション ログから非アクティブな仮想ログ ファイル (VLF) が削除されます。これにより、論理ログの領域が解放され、物理トランザクション ログで再利用できるようになります。Log truncation deletes inactive virtual log files (VLFs) from the logical transaction log of a SQL ServerSQL Server database, freeing space in the logical log for reuse by the Physical transaction log. トランザクション ログが切り捨てられなければ、物理ログ ファイルに割り当てられているディスク上の領域がいっぱいになってしまいます。If a transaction log is never truncated, it will eventually fill all the disk space allocated to physical log files.

領域が足りなくなるのを回避するために、何かの理由でログの切り捨てが遅れている場合を除き、次のイベントの後に切り捨てが自動的に発生します。To avoid running out of space, unless log truncation is delayed for some reason, truncation occurs automatically after the following events:

  • 単純復旧モデルでは、チェックポイント以降。Under the simple recovery model, after a checkpoint.
  • 完全復旧モデルまたは一括ログ復旧モデルでは、前回のバックアップ後にチェックポイントが発生した場合、ログ バックアップ (コピーのみのログ バックアップの場合を除く) の後に切り捨てが発生します。Under the full recovery model or bulk-logged recovery model, if a checkpoint has occurred since the previous backup, truncation occurs after a log backup (unless it is a copy-only log backup).

詳細については、このトピックの「ログの切り捨てが遅れる原因となる要因」を参照してください。For more information, see Factors that can delay log truncation, later in this topic.

注意

ログの切り捨てを行っても、物理ログ ファイルのサイズは縮小されません。Log truncation does not reduce the size of the physical log file. 物理ログ ファイルの物理サイズを削減するには、ログ ファイルを圧縮する必要があります。To reduce the physical size of a physical log file, you must shrink the log file. 物理ログ ファイルのサイズの圧縮の詳細については、「 トランザクション ログ ファイルのサイズの管理」を参照してください。For information about shrinking the size of the physical log file, see Manage the Size of the Transaction Log File.
ただし、ログの切り捨てが遅れる原因となる要因には留意してください。However, keep in mind Factors that can delay log truncation. ログの圧縮後、ストレージ領域が再び必要になると、トランザクション ログが再び増え、その分のパフォーマンスのオーバーヘッドが発生します。If the storage space is required again after a log shrink, the transaction log will grow again and by doing that, introduce performance overhead during log grow operations.

Factors that can delay log truncationFactors that can delay log truncation

このトピックで前述したように、ログ レコードが長い間アクティブなままになると、トランザクション ログの切り捨てが遅れて、トランザクション ログがいっぱいになります。When log records remain active for a long time, transaction log truncation is delayed, and the transaction log can fill up, as we mentioned earlier in this long topic.

重要

トランザクション ログがいっぱいに応答する方法については、「 Troubleshoot a Full Transaction Log (SQL Server Error 9002)」を参照してください。For information about how to respond to a full transaction log, see Troubleshoot a Full Transaction Log (SQL Server Error 9002).

実際に、ログの切り捨てはさまざまな理由で遅延が発生する場合があります。Really, Log truncation can be delayed by a variety of reasons. ログの切り捨てを妨げている原因を、sys.databases カタログ ビューの log_reuse_wait 列と log_reuse_wait_desc 列に対するクエリを実行して確認してください。Learn what, if anything, is preventing your log truncation by querying the log_reuse_wait and log_reuse_wait_desc columns of the sys.databases catalog view. 次の表では、これらの列の値について説明します。The following table describes the values of these columns.

log_reuse_wait の値log_reuse_wait value log_reuse_wait_desc の値log_reuse_wait_desc value DescriptionDescription
00 NOTHINGNOTHING 現在 1 つ以上の再利用可能な仮想ログ ファイル (VLF) がある。Currently there are one or more reusable virtual log files (VLFs).
@shouldalert1 CHECKPOINTCHECKPOINT 最後にログの切り捨てを行ってからチェックポイントが発生していないか、ログの先頭が仮想ログ ファイル (VLF) を超えて移動していない。No checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond a virtual log file (VLF). (すべての復旧モデル)。(All recovery models)

これは、ログの切り捨てが遅れる一般的な原因です。This is a routine reason for delaying log truncation. 詳細については、「データベース チェックポイント (SQL Server)」を参照してください。For more information, see Database Checkpoints (SQL Server).
22 LOG_BACKUPLOG_BACKUP トランザクション ログを切り捨てる前にログ バックアップが必要であるA log backup is required before the transaction log can be truncated. (完全復旧モデルまたは一括ログ復旧モデルのみ)。(Full or bulk-logged recovery models only)

次のログ バックアップが完了した時点で、ログ領域の一部が再利用可能になります。When the next log backup is completed, some log space might become reusable.
33 ACTIVE_BACKUP_OR_RESTOREACTIVE_BACKUP_OR_RESTORE データ バックアップまたは復元が実行中である (すべての復旧モデル)。A data backup or a restore is in progress (all recovery models).

データ バックアップによってログの切り捨てが妨げられる場合、バックアップ操作を取り消すと、当面の問題には対処できます。If a data backup is preventing log truncation, canceling the backup operation might help the immediate problem.
44 ACTIVE_TRANSACTIONACTIVE_TRANSACTION トランザクションがアクティブである (すべての復旧モデル):A transaction is active (all recovery models):

実行時間の長いトランザクションがログ バックアップの先頭に存在する可能性がある。A long-running transaction might exist at the start of the log backup. この場合、領域を解放するには再度ログ バックアップが必要になります。In this case, freeing the space might require another log backup. 単純復旧モデルを含むすべての復旧モデルでは、実行時間の長いトランザクションによってログの切り捨てが妨げられます。この場合、通常は自動チェックポイントのたびにトランザクション ログが切り捨てられます。Note that long-running transactions prevent log truncation under all recovery models, including the simple recovery model, under which the transaction log is generally truncated on each automatic checkpoint.

トランザクションが遅延している。A transaction is deferred. 遅延トランザクション は、一部リソースが確保できないためにロールバックがブロックされている、実質的にはアクティブなトランザクションです。A deferred transaction is effectively an active transaction whose rollback is blocked because of some unavailable resource. 遅延トランザクションの原因、およびトランザクションの遅延を解決する方法については、「遅延トランザクション (SQL Server)」を参照してください。For information about the causes of deferred transactions and how to move them out of the deferred state, see Deferred Transactions (SQL Server).

実行時間の長いトランザクションも、tempdb のトランザクション ログをいっぱいにする可能性があります。Long-running transactions might also fill up tempdb's transaction log. tempdb は、並べ替えの作業テーブル、ハッシュの作業ファイル、カーソル作業テーブル、行のバージョン管理といった、内部オブジェクトに対するユーザー トランザクションで暗黙的に使用されます。Tempdb is used implicitly by user transactions for internal objects such as work tables for sorting, work files for hashing, cursor work tables, and row versioning. ユーザー トランザクションにデータ読み取り (SELECTクエリ) だけが含まれる場合でも、ユーザー トランザクションで内部オブジェクトが作成され使用されることがあります。Even if the user transaction includes only reading data (SELECT queries), internal objects may be created and used under user transactions. その結果 tempdb のトランザクション ログがいっぱいになる可能性があります。Then the tempdb transaction log can be filled.
55 DATABASE_MIRRORINGDATABASE_MIRRORING データベース ミラーリングが一時中断されるか、高パフォーマンス モードでは、ミラー データベースがプリンシパル データベースに大幅に遅れるDatabase mirroring is paused, or under high-performance mode, the mirror database is significantly behind the principal database. (完全復旧モデルのみ)。(Full recovery model only)

詳細については、「データベース ミラーリング (SQL Server)」を参照してください。For more information, see Database Mirroring (SQL Server).
66 REPLICATIONREPLICATION トランザクション レプリケーション中、パブリケーションに関連するトランザクションがディストリビューション データベースにまだ配信されていないDuring transactional replications, transactions relevant to the publications are still undelivered to the distribution database. (完全復旧モデルのみ)。(Full recovery model only)

トランザクション レプリケーションの詳細については、「 SQL Server Replication」を参照してください。For information about transactional replication, see SQL Server Replication.
77 DATABASE_SNAPSHOT_CREATIONDATABASE_SNAPSHOT_CREATION データベース スナップショットが作成されているA database snapshot is being created. (すべての復旧モデル)。(All recovery models)

これは、通常、短い時間ログの切り捨てが遅れる一般的な原因となります。This is a routine, and typically brief, cause of delayed log truncation.
88 LOG_SCANLOG_SCAN ログ スキャンが行われているA log scan is occurring. (すべての復旧モデル)。(All recovery models)

これは、通常、短い時間ログの切り捨てが遅れる一般的な原因となります。This is a routine, and typically brief, cause of delayed log truncation.
99 AVAILABILITY_REPLICAAVAILABILITY_REPLICA 可用性グループのセカンダリ レプリカが、このデータベースのトランザクション ログ レコードを対応するセカンダリ データベースに適用中であるA secondary replica of an availability group is applying transaction log records of this database to a corresponding secondary database. (完全復旧モデル)。(Full recovery model)

詳細については、「 Always On 可用性グループの概要 (SQL Server)」を参照してください。For more information, see Overview of Always On Availability Groups (SQL Server).
1010 - 内部使用のみFor internal use only
1111 - 内部使用のみFor internal use only
1212 - 内部使用のみFor internal use only
1313 OLDEST_PAGEOLDEST_PAGE データベースが間接的なチェックポイントを使用するように構成されている場合、データベース上の最も古いページはチェックポイントのログ シーケンス番号 (LSN) よりも古くなることがある。If a database is configured to use indirect checkpoints, the oldest page on the database might be older than the checkpoint log sequence number (LSN). この場合、最も古いページのログの切り捨てが遅れる可能性がありますIn this case, the oldest page can delay log truncation. (すべての復旧モデル)。(All recovery models)

間接的なチェックポイントの詳細については、「 Database Checkpoints (SQL Server)」を参照してください。For information about indirect checkpoints, see Database Checkpoints (SQL Server).
1414 OTHER_TRANSIENTOTHER_TRANSIENT この値は現在使用されていません。This value is currently not used.

最小ログ記録が可能な操作Operations that can be minimally logged

最小ログ記録 では、トランザクションの復旧に必要な情報だけが記録されます。特定の時点への復旧はサポートしません。Minimal logging involves logging only the information that is required to recover the transaction without supporting point-in-time recovery. このトピックでは、一括ログ 復旧モデル で (バックアップが実行されていない場合は単純復旧モデルで) 最小ログが記録される操作について説明します。This topic identifies the operations that are minimally logged under the bulk-logged recovery model (as well as under the simple recovery model, except when a backup is running).

注意

最小ログ記録は、メモリ最適化テーブルではサポートされていません。Minimal logging is not supported for memory-optimized tables.

注意

完全 復旧モデルでは、すべての一括操作が完全にログに記録されます。Under the full recovery model, all bulk operations are fully logged. ただし、一括操作のためにデータベースを一時的に一括ログ復旧モデルに切り替えることで、一連の一括操作用のログ記録を最小限に抑えることができます。However, you can minimize logging for a set of bulk operations by switching the database to the bulk-logged recovery model temporarily for bulk operations. 最小ログ記録は、完全ログ記録より効率的であり、一括トランザクションの実行中に、使用可能なトランザクション ログ領域が大規模な一括操作でいっぱいになる可能性を低減します。Minimal logging is more efficient than full logging, and it reduces the possibility of a large-scale bulk operation filling the available transaction log space during a bulk transaction. ただし、最小ログ記録が有効なときにデータベースが破損または消失した場合は、データベースを障害発生時点まで復旧できません。However, if the database is damaged or lost when minimal logging is in effect, you cannot recover the database to the point of failure.

次に示す操作は、完全復旧モデルで完全にログ記録されますが、単純復旧モデルと一括ログ復旧モデルでは最小限にしかログ記録されません。The following operations, which are fully logged under the full recovery model, are minimally logged under the simple and bulk-logged recovery model:

トランザクション レプリケーションが有効な場合、BULK INSERT 操作は、一括ログ復旧モデルでも完全にログ記録されます。When transactional replication is enabled, BULK INSERT operations are fully logged even under the Bulk Logged recovery model.

トランザクション レプリケーションが有効な場合、SELECT INTO 操作は、一括ログ復旧モデルでも完全にログ記録されます。When transactional replication is enabled, SELECT INTO operations are fully logged even under the Bulk Logged recovery model.

  • 新規データの挿入時または追加時の、UPDATE ステートメントの .WRITE 句を使用した、大きな値のデータ型の部分更新。Partial updates to large value data types, using the .WRITE clause in the UPDATE statement when inserting or appending new data. 既存の値を更新する場合は、最小ログ記録は使用されません。Note that minimal logging is not used when existing values are updated. 大きな値のデータ型の詳細については、「データ型 (Transact-SQL)」を参照してください。For more information about large value data types, see Data Types (Transact-SQL).

  • textntextimageの各データ型列に新規データを挿入または追加するときの WRITETEXTステートメントおよび UPDATETEXT ステートメント。WRITETEXT and UPDATETEXT statements when inserting or appending new data into the text, ntext, and image data type columns. 既存の値を更新する場合は、最小ログ記録は使用されません。Note that minimal logging is not used when existing values are updated.

    警告

    WRITETEXT ステートメントおよび UPDATETEXT ステートメントの使用は推奨されなくなりました。新しいアプリケーションでは、これらを使用しないようにしてください。The WRITETEXT and UPDATETEXT statements are deprecated; avoid using them in new applications.

  • データベースが単純復旧モデルまたは一括ログ復旧モデルに設定されている場合、一部のインデックス DDL 操作は、オフラインで実行されても、オンラインで実行されても、最小ログ記録の対象になります。If the database is set to the simple or bulk-logged recovery model, some index DDL operations are minimally logged whether the operation is executed offline or online. 最小ログ記録が行われるインデックス操作は、次のとおりです。The minimally logged index operations are as follows:

    • CREATE INDEX 操作 (インデックス付きビューを含む)。CREATE INDEX operations (including indexed views).

    • ALTER INDEX REBUILD 操作または DBCC DBREINDEX 操作。ALTER INDEX REBUILD or DBCC DBREINDEX operations.

      警告

      DBCC DBREINDEX ステートメントは推奨されなくなりました。新しいアプリケーションでは使用しないようにしてください。The DBCC DBREINDEX statement is deprecated; Do not use it in new applications.

    • DROP INDEX による新しいヒープの再構築 (適用可能な場合)。DROP INDEX new heap rebuild (if applicable). DROP INDEX 操作中のインデックス ページの割り当て解除は、常に完全にログ記録されます。Index page deallocation during a DROP INDEX operation is always fully logged.

関連タスクRelated tasks

トランザクション ログの管理Managing the transaction log

トランザクション ログのバックアップ (完全復旧モデル)Backing Up the Transaction Log (Full Recovery Model)

トランザクション ログの復元 (完全復旧モデル)Restoring the Transaction Log (Full Recovery Model)

参照See also

SQL Server トランザクション ログのアーキテクチャと管理ガイド SQL Server Transaction Log Architecture and Management Guide
トランザクションの持続性の制御 Control Transaction Durability
一括インポートで最小ログ記録を行うための前提条件 Prerequisites for Minimal Logging in Bulk Import
SQL Server データベースのバックアップと復元 Back Up and Restore of SQL Server Databases
データベース チェックポイント (SQL Server) Database Checkpoints (SQL Server)
データベースのプロパティの表示または変更 View or Change the Properties of a Database
復旧モデル (SQL Server)Recovery Models (SQL Server)
トランザクション ログのバックアップ (SQL Server) Transaction Log Backups (SQL Server)
sys.dm_db_log_info (Transact-SQL)sys.dm_db_log_info (Transact-SQL)
sys.dm_db_log_space_usage (Transact-SQL)sys.dm_db_log_space_usage (Transact-SQL)