Это интересно

  • ОКД
  • ЗКС
  • ИПО
  • КНПВ
  • Мондиоринг
  • Большой ринг
  • Французский ринг
  • Аджилити
  • Фризби

Опрос

Какой уровень дрессировки необходим Вашей собаке?
 

Полезные ссылки

РКФ

 

Все о дрессировке собак


Стрижка собак в Коломне

Поиск по сайту

Главная » Журнал » Журнал бд

Системы управления базами данных. Журнал бд


Журнал транзакций (SQL Server) | Microsoft Docs

  • 01/04/2018
  • Время чтения: 22 мин
  • Соавторы

В этой статье

ПРИМЕНЯЕТСЯ к: SQL Serverбазы данных SQL Azureхранилище данных SQL Azure Параллельное хранилище данныхTHIS TOPIC APPLIES TO: SQL ServerAzure SQL DatabaseAzure SQL Data Warehouse Parallel 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.

Warning

Удаляя или перемещая этот журнал, вы должны понимать все последствия этого действия.Never delete or move this log unless you fully understand the ramifications of doing so.

Tip

Известные рабочие точки, от которых следует начинать применение журналов транзакций при восстановлении базы данных, создаются контрольными точками.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.

Note

Усечение журнала не приводит к уменьшению размера физического файла журнала.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. Сведения о сжатии физического файла журнала см. в разделе Manage the Size of the Transaction 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.

На самом деле усечение журнала может быть задержано из-за множества причин.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 DescriptionDescription
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. Дополнительные сведения см. в разделе Контрольные точки базы данных (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).

Note

Минимальное протоколирование не поддерживается для оптимизированных для памяти таблиц.Minimal logging is not supported for memory-optimized tables.

Note

В модели полного восстановлениявсе массовые операции полностью протоколируются.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.

    Warning

    Инструкции 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.

      Warning

      Инструкция 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.

Управление журналом транзакцийManaging the transaction log

См. также раздел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)

docs.microsoft.com

Системы управления базами данных

СУБД – комплекс программных и языковых средств, предназначенных для создания, ведения и использования баз данных.

Ведение базы данных - обновление и перестройка структуры базы данных с целью обеспечения ее целостности, сохранности и эффективности использования.

Основные функции субд

1. управление данными во внешней памяти. Методы и алгоритмы управления данными являются «внутренним делом» СУБД. Качество реализации этой функции наиболее сильно влияет на эффективность работы АИС, например, с огромными БД, со сложными запросами, большим объемом обработки данных.

2. управление буферами оперативной памяти. Буферы представляют собой области оперативной памяти, предназначенные для ускорения обмена между внешней и оперативной памятью. В буферах временно хранятся фрагменты БД, данные из которых предполагается использовать при обращении к СУБД или планируется записать в базу данных после обработки.

3. Управление транзакциями

Транзакцией называется последовательность операций, производимых над базой данных и переводящих базу данных из одного непротиворечивого (согласованного) состояния в другое непротиворечивое (согласованное) состояние.

Транзакция рассматривается как некоторое неделимое действие над базой данных, осмысленное с точки зрения пользователя. В то же время это логическая единица работы системы.

В настоящий момент выделяют следующие типы транзакций:

  • плоские или классические транзакции;

  • цепочечные транзакции;

  • вложенные транзакции.

Плоские или традиционные транзакции характеризуются четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) — ACID (Atomicity, Consistency, Isolation, Durability). Иногда традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее:

  • Свойство атомарности (Atomicity) выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе.

  • Свойство согласованности (Consistency) гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое - транзакция не разрушает взаимной согласованности данных.

  • Свойство изолированности (Isolation) означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.

  • Свойство долговечности (Durability) трактуется следующим образом: если транзакция завершена успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах (даже в случае последующих ошибок).

4. Ведение журнала изменений в бд

Ведение журнала изменений в БД (журнализация изменений) выполняется СУБД для обеспечения надежности хранения данных в базе данных при наличии аппаратных сбоев и отказов, а также ошибок в программном обеспечении.

Журнал СУБД — это особая БД или часть основной БД, непосредственно недоступная пользователю и используемая для записи информации обо всех изменениях базы данных. В различных СУБД в журнал могут заноситься записи, соответствующие изменениям в СУБД на разных уровнях: от минимальной внутренней операции модификации страницы внешней памяти до логической операции модификации БД (например, вставки записи, удаления столбца, изменения значения в поле).

Для эффективной реализации функции ведения журнала изменений в БД необходимо обеспечить повышенную надежность хранения и поддержания в рабочем состоянии самого журнала. Иногда для этого в системе хранят несколько копий журнала.

studfiles.net

Журнализация

Журнализация

Одним из основных требований к СУБД является надежное хранение данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной.

В любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежного хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.

Журнал - это особая часть БД, недоступная пользователям ИС и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях. Например, иногда запись в журнале соответствует некоторой логической операции изменения БД (for example, операции удаления строки из таблицы реляционной БД), иногда запись в журнале соответствует минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Упрощенно говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).

При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций.

Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом.

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Проще говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала. Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что, исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после конца восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

belani.narod.ru

Базы данных

Доступ к реферативным (с 2012г по 2017г) и полнотекстовым (до 2011 года) материалам журналов и конференций по математикеwww.ams.org

Бессрочно без подписки, кроме доступа к реферативной базе MathSciNet®

 

Доступ к полнотекстовым материалам журналов и конференций по оптике и фотоникеwww.osa.org

Доступ открыт до 31/12/2017

 

Банк структурных данных органических соединенийwww.ccdc.cam.ac.uk

Доступ открыт до 31/12/2017

 

Курс на английском языке, бесплатный, интерактивный, с задачами и примерами. Все материалы курса доступны по лицензии Creative Commons, то есть их можно копировать, распространять и изменять.cyber.law.harvard.edu

Доступ свободный

 

Крупнейший российский информационный портал в области науки, технологии, медицины и образования.www.elibrary.ru

Доступ свободный

 

GreenFILE – это ресурс, который ориентирован на всех, кто интересуется вопросами охраны окружающей среды и нуждается в научной информации.www.greeninfoonline.com

Для всех ПК университета.

 

Интернет библиотека с доступом к реферативным и полнотекстовым статьям и материалам конференцийwww.ieeexplore.ieee.org

Бессрочно без подписки, не все полнотексты открыты

 

www.iop.org

В свободном доступе представлены все оглавления и все рефераты. Полные тексты всех статей во всех журналах находятся в свободном доступе в течение 30 дней после даты их онлайновой публикации.

 

Nano

Этот уникальный ресурс предоставляет данные о более 200 000 наноматериалов и наноустройств, собранные из самых авторитетных научных изданий.nano.nature.com

Доступ свободный

 

Nature

88 естественно-научных журналов, включая старейший и один из самых авторитетных научных журналов Naturewww.nature.com

Доступ свободный

 

Обзор средств массовой информации. Ежедневно тысяча новостей, полный текст на русском языке. Миллионы сюжетов информагентств и деловой прессы за 15 лет.www.polpred.com

Доступ свободный

 

Наукометрическая и реферативная база данных журналов и конференцийwww.scopus.com

Доступ открыт до 31/05/2018

 

Springer

Издательство с доступом к реферативным и полнотекстовым материалам журналов и книгwww.springer.com www.link.springer.com

Доступ открыт 31/12/2017

 

SpringerLink

Более 3 000 журналов Springer 1997 – 2018 гг.Более 80 000 электронных книг Springer 2005 – 2010 гг. (через РФФИ) и 2011 – 2017 гг., включая монографии, справочники и труды конференцийrd.springer.com

Ресурс доступен по IP-адресам ТУСУРа

 

SpringerMaterials

Springer Materials – это самая полная база данных, описывающая свойства и характеристики материалов. Она аккумулирует информацию из таких дисциплин, как материаловедение, физика, физическая и неорганическая химия, машиностроение и др.materials.springer.com

Ресурс доступен по IP-адресам ТУСУРа​

 

Издательство с доступом к реферативным и полнотекстовым материалам журналов и книгlink.springer.com

Ресурс доступен по IP-адресам ТУСУРа

 

SpringerProtocols

SpringerProtocols – это бесценный ресурс для современных исследовательских лабораторий. Крупнейшая база данных воспроизводимых лабораторных протоколов (более 40 000) предоставляет доступ к надёжным и проверенным данным, накопленным за последние 30 лет.www.springerprotocols.com

Ресурс доступен по IP-адресам ТУСУРа

 

Политематическая коллекция журналов Taylor&Francis Group включает в себя около двух тысяч журналов по различным областям знанияtandfonline.com

Доступ открыт до 31/12/2017

 

Наукометрическая реферативная база данных журналов и конференцийapps.webofknowledge.com

Доступ открыт до 31/10/2017

 

Издательство с доступом к реферативным и полнотекстовым материалам журналов и книгwww.wiley.com www.onlinelibrary.wiley.com

Доступ открыт до 31/12/2017

 

zbMATH

zbMATH – самая полная математическая база данных, охватывающая материалы с конца 19 века. zbMath содержит около 4 000 000 документов, из более 3 000 журналов и 170 000 книг по математике, статистике, информатике, а также машиностроению, физике, естественным наукам и др.zbmath.org

Доступ свободный

 

Архив журналов РАН

Российская академия наук и издательство «Наука» приняли решение открыть свободный доступ к архивам журналов РАН, включая номера журналов за 2017 год, выпуск которых по контракту с РАН осуществляло издательство «Наука». Бесплатный доступ к электронным версиям журналов РАН будет предоставляться на платформе elibrary.ru и libnauka.ru (электронная библиотека издательства «Наука»). Всего журналов в референтной группе 149.Список журналов

Доступ свободный

 

Система «ГАРАНТ» предоставляет доступ к федеральному и региональному законодательству, комментариям и разъяснениям из ведущих профессиональных СМИ, книгам и обновляемым энциклопедиям, типовым формам документов, судебной практике, международным договорам и другой нормативной информации.www.garant.ru

Система «ГАРАНТ» доступна только с ПК библиотеки

 

archive.neicon.ru

Доступ свободный

 

Электронная библиотека «ЛитРес»

Пользователям ТУСУРа доступны книги из Электронной библиотеки ЛитРес, приобретенные в фонд Муниципальной информационной библиотечной системы г. Томска.Лицензионные электронные книги и аудиокниги можно читать на любом смартфоне, планшете, ноутбуке, компьютере!Книги выдаются бесплатно на устройство пользователя на 14 дней в специализированное программное обеспечение "ЛитРес", либо для чтения он-лайн с сайта "ЛитРес". Хронологический охват: с 2007 года по настоящее время. Описание: на языке оригинала.

Полные тексты книг доступны бесплатно после онлайн-регистрации в МИБС и авторизации на сайте ЛитРес

 

Журналы РАН

Электронные версии журналов с 1997 годаwww.ioffe.ru

Доступ свободный

 

Система «КонсультантПлюс» – надёжный помощник для многих специалистов: юристов, бухгалтеров, руководителей организаций, а также для специалистов государственных органов, учёных и студентов. В ней содержится огромный массив правовой и справочной информации.www.consultant.ru

Система «КонсультантПлюс» доступна только с ПК библиотеки

 

Доступ свободный

 

Университетская информационная система РОССИЯ – тематическая электронная библиотека и база для исследований и учебных курсов в области экономики, управления, социологии, лингвистики, философии, филологии, международных отношений и других гуманитарных наук.uisrussia.msu.ru

Доступ по IP-адресам ТУСУРа.Логин и пароль спрашивайте в справочно-библиографическом отделе, ул. Красноармейская, 146 (УЛК), каб. 204 или по адресу [email protected].

lib.tusur.ru

Смотрите также

KDC-Toru | Все права защищены © 2018 | Карта сайта