Журнал транзакций (SQL Server)The Transaction Log (SQL Server)

ОБЛАСТЬ ПРИМЕНЕНИЯ: даSQL Server нетБаза данных SQL AzureнетХранилище данных SQL AzureнетParallel 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. Дополнительные сведения см. в статье Контрольные точки базы данных (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.
  • Поддержка решений высокой уровня доступности и аварийного восстановления: Группы доступности AlwaysOnAlways On availability groups, зеркальное отображение базы данных и доставка журналов.Supporting high availability and disaster recovery solutions: Группы доступности AlwaysOnAlways 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 ServerRecovery 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

Решения резервного сервера, Группы доступности AlwaysOnAlways On availability groups, зеркальное отображение базы данных и доставка журналов в значительной степени опираются на журнал транзакций.The standby-server solutions, Группы доступности AlwaysOnAlways On availability groups, database mirroring, and log shipping, rely heavily on the transaction log.

В сценарии " Группы доступности AlwaysOnAlways On availability groups" каждое изменение в базе данных (первичной реплике) немедленно воспроизводится в ее полных автономных копиях (вторичных репликах).In an Группы доступности AlwaysOnAlways 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

В сценарии доставки журналов основной сервер отправляет активный журнал транзакций основной базы данных в определенное назначение или множество назначений.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 Database EngineSQL Server Database Engine.Characteristics of the Компонент SQL Server Database EngineSQL Server Database Engine transaction log:

  • Журнал транзакций выполнен как отдельный файл или набор файлов в базе данных.The transaction log is implemented as a separate file or set of files in the database. Кэш журнала управляется отдельно от буферного кэша для страниц данных, что приводит к простому, быстрому и устойчивому коду в пределах компонента Компонент SQL Server Database EngineSQL 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 Database EngineSQL 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) для файлов и файловых групп.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.

Усечение журнала удаляет неактивные виртуальные файлы журнала (VLF) из логического журнала транзакций базы данных SQL ServerSQL Server, освобождая в нем место для повторного использования физическим журналом транзакций.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. Чтобы узнать причину, препятствующую усечению журнала транзакций в конкретном случае, выполните запрос по столбцам log_reuse_wait и log_reuse_wait_desc представления каталога sys.database.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_waitlog_reuse_wait value Значение столбца log_reuse_wait_desclog_reuse_wait_desc value ОписаниеDescription
00 NOTHING;NOTHING Сейчас есть как минимум один виртуальный файл журнала (VLF), доступный для повторного использования.Currently there are one or more reusable virtual log files (VLFs).
11 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. Дополнительные сведения см. в разделе Database Checkpoints (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)

Дополнительные сведения см. в статье Обзор групп доступности AlwaysOn (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.

  • Частичные изменения типов данных с большими значениями с помощью предложения .WRITE инструкции UPDATE при вставке или добавлении новых данных.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).

  • ИнструкцииWRITETEXT и UPDATETEXT при вставке или добавлении новых данных в столбцы с типом данных text, ntext, и image .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 tasksRelated 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)