Управление размером файла журнала транзакций

Перед началом

Предварительные требования

Резервные копии должны восстанавливаться в том же порядке, в котором они были созданы. Перед тем как можно будет восстановить определенную резервную копию журнала транзакций, вначале должны быть восстановлены следующие более ранние резервные копии без отката незафиксированных транзакций, т.е.с параметром WITH NORECOVERY:
- Полная резервная копия и последняя разностная резервная копия, если таковая имеется, созданные перед заданной резервной копией журнала транзакций. Перед созданием самой последней полной или разностной резервной копии базы данных необходимо, чтобы в базе данных использовалась модель полного восстановления (или модель восстановления с неполным протоколированием).
- Все резервные копии журнала транзакций, созданные после полной резервной копии базы данных или разностной резервной копии (если она восстанавливается), и перед заданной резервной копией журнала транзакций. Резервные копии журналов необходимо применять в порядке их создания, без разрывов в цепочке журналов.
  
  Дополнительные сведения о резервных копиях журналов транзакций см. в статье Резервные копии журналов транзакций (SQL Server) и Применение резервных копий журналов транзакций (SQL Server).

Permissions

Разрешения на выполнение инструкции RESTORE даются ролям, в которых данные о членстве всегда доступны серверу. Так как членство в предопределенной роли базы данных может быть проверено только тогда, когда база данных доступна и не повреждена, что не всегда имеет место при выполнении инструкции RESTORE, члены предопределенной роли базы данных db_owner не имеют разрешений RESTORE.

Копирование числовых ячеек из 1С в Excel Промо

Решение проблемы, когда значения скопированных ячеек из табличных документов 1С в Excel воспринимаются последним как текст, т.е. без дополнительного форматирования значений невозможно применить арифметические операции. Поводом для публикации послужило понимание того, что целое предприятие с более сотней активных пользователей уже на протяжении года мучилось с такой, казалось бы на первый взгляд, тривиальной проблемой. Варианты решения, предложенные специалистами helpdesk, обслуживающими данное предприятие, а так же многочисленные обсуждения на форумах, только подтвердили убеждение в необходимости описания способа, который позволил мне качественно и быстро справиться с ситуацией.

Операции, поддерживаемые журналом транзакций

Журнал транзакций поддерживает следующие операции:

восстановление отдельных транзакций;
восстановление всех незавершенных транзакций при запуске SQL Server ;
накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;
поддержка репликации транзакций;
Поддержка решений высокой уровня доступности и аварийного восстановления: Группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов.

Восстановление отдельных транзакций

Если приложение выдает инструкцию или Компонент Database Engine обнаруживает ошибку, такую как потеря связи с клиентом, записи журнала используются для отката изменений, выполненных в результате незавершенной транзакции.

Восстановление всех незавершенных транзакций при запуске SQL Server

Если на сервере происходит сбой, базы данных могут остаться в состоянии, когда часть изменений не переписана из буферного кэша в файлы данных, но в них имеются изменения, совершенные незаконченными транзакциями. Когда экземпляр SQL Server будет запущен, он выполнит восстановление каждой базы данных. Каждое изменение, записанное в журнале, которое, возможно, не было записано в файлы данных, накатывается. Чтобы сохранить целостность базы данных, будет также произведен откат каждой незавершенной транзакции, найденной в журнале транзакций. Дополнительные сведения см. в статье .

Накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя

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

При восстановлении каждой резервной копии журнала, Компонент Database Engine повторно применяет все изменения, записанные в журнале, для наката всех транзакций. После восстановления последней резервной копии журнала Компонент Database Engine затем использует данные журнала для отката всех транзакций, которые не были завершены на момент сбоя. Дополнительные сведения см. в статье .

Поддержка репликации транзакций

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

Поддержка решений высокого уровня доступности и аварийного восстановления

Решения резервного сервера, Группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов в значительной степени опираются на журнал транзакций.

В сценарии «Группы доступности AlwaysOn» каждое изменение в базе данных (первичной реплике) немедленно воспроизводится в ее полных автономных копиях (вторичных репликах). Первичная реплика немедленно отсылает каждую запись журнала во вторичные реплики, которые применяют входящие записи к базам данных групп доступности, производя непрерывный накат. Дополнительные сведения см. в разделе Экземпляры отказоустойчивого кластера AlwaysOn.

В сценарии доставки журналов основной сервер отправляет активный журнал транзакций основной базы данных в определенное назначение или множество назначений. Каждый сервер-получатель восстанавливает журнал в свою локальную базу данных-получатель. Дополнительные сведения см. в разделе Сведения о доставке журналов.

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

Шаг 2. Настройка сервера Microsoft SQL 2005

2.1. Настройка протоколов подключения

Для настройки протоколов взаимодействия сервера и клиента Microsoft SQL необходимо запустить «SQL Server Configuration Manager»:

…и оставить для работы только протоколы TCP/IP и Shared Memory:

Если устанавливается версия MS SQL Express по-умолчанию выключен протокол TCP/IP, нужный для работы с 1С:Предприятие 8 — его необходимо включить. Протокол именнованных каналов (Named Pipe) выключите совсем (и для «клиента» тоже на сервере приложений).

2.2. Перенос tempdb на быстрый независимый массив/диски

Для переноса tempdb необходимо запустить sql-скрипт примерно следующего содержания:

USE master
GO
ALTER DATABASE tempdb
modify file (NAME=tempdev, FILENAME='E:\Temp\tempdb_data.mdf')
GO
ALTER DATABASE tempdb
modify file (NAME=templog, FILENAME='E:\Temp\tempdb_log.ldf')
GO

где, E:\Temp\ — каталог, в котором будут лежать tempdb, а tempdb_data.mdf и tempdb_log.ldf имя файла базы данных и лога соответственно.

2.3. Настройка параметров сервера SQL

Для настройки сервера запускаем «SQL Server Management Studio», подключаемся к установленному серверу Database Engine‘ом и открываем свойства (Server Properties). Тут нам нужно настроить 3 пункта:

Память (Memory)

Параметр «Maximum server memory (in MB)» задает максимально отведенное серверу количество памяти из расчета: – – . Например,
если у нас на сервере всего 24 ГБ оперативной памяти, стоит Windows 2003
и запущен сервер 1С Предприятия с 2мя процессами rphost (которым нужна
память хотябы по 1,5Гб) то рассчет будет следующим: 24 — 1,5 — 1,5*2 =
19,5 ГБ ставит параметр «Maximum server memory (in MB)».
Это необходимо для того, чтобы sql-сервер рассчитывал на заданный объем
и освобождал память заблаговременно, т.к. если поставить неограниченный
объем, и сервер попробует получить память, которой нет, он начинает
лезть в файл подкачки, что сильно замедлит работу.

Процессоры (Processors)

Database Settings

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

Управление увеличением размера файла журнала транзакций

Для управления увеличением файла журнала транзакций используйте инструкцию ALTER DATABASE (Transact-SQL) с параметрами для файлов и файловых групп. Следует отметить следующее.

Чтобы изменить текущий размер файла в КБ, МБ, ГБ и ТБ, используйте параметр .
Чтобы изменить шаг приращения размера, используйте параметр . Значение 0 указывает, что автоматическое приращение выключено и дополнительное пространство для файла не разрешено.
Чтобы установить максимальный размер файла журнала в КБ, МБ, ГБ и ТБ или задать неограниченный размер (UNLIMITED), используйте параметр .

Дополнительные сведения см. в разделе этой статьи.

Процедуры обслуживания

Попробуем разобраться какие процедуры обслуживания нам необходимо выполнять и как часто. Для удобства объединим процедуры в связанные группы, впоследствии они станут субпланами обслуживания.

Субплан «В течение дня»

Резервное копирование транзакционного лога. Когда для базы данных выбрана полная модель восстановления, необходимо регулярно делать резервное копирование транзакционного лога, иначе будет происходить его чрезмерное разрастание, пока тот не займет все пространство на диске, а SQL Server начнет сообщать об этой ошибке. Для простой модели восстановления данная задача не требуется. Частота бэкапа журнала транзакций напрямую зависит от выделенного для него размера на диске, а так же от интенсивности работы с базой. Зависимость эта заключается в рекомендации что транзакционной лог не должен расти (должен сохранять выделенное ему место на диске) в течение работы пользователей с базой данных. Для себя я выбрал частоту резервного копирования лога транзакций равной 1 часу.

Субплан «Ежедневный» (6 из 7 дней в неделе)

Для поддержания базы данных в эффективном для работы состоянии, необходимо ежедневно (в нерабочее время) выполнять следующие задачи:

Реорганизация/Дефрагментация индекса (Reorganize Index). Database Engine автоматически обновляет индекс при операциях INSERT, DELETE, UPDATE. Со временем эти операции могут привести к фрагментации индекса. Значительно фрагментированные индексы могут серьезно снижать производительность запросов и служить причиной замедления. Таким образом, необходимо в план обслуживания включить задание по устранению фрагментации индексов. Альтернативой дефрагментации индексов является реиндексация/перестроение индекса (rebuild index), но она имеет такие недостатки как: значительно большее время выполнения; сброс статистики использования индексов. Также в качестве альтернативы возможно использование хранимой процедуры условного (от степени фрагментации) выбора способа устранения фрагментации (реорганизация/перестроение) индекса.
Обновление статистики (Update Statistics). Скорость выполнения запроса зависит от построенного для него плана запроса, который, в свою очередь, опирается на информацию о существующих индексах, а также на статистику. Если статистика устарела, существует вероятность выбора не оптимального плана запроса, что приведет к снижению производительности. Таким образом, необходимо включить задание обновления статистики.
Разностное резервное копирование (Differential backup). Надеюсь, нет необходимости рассказывать почему надо делать периодическое резервное копирование базы данных, альтернативой разностному бэкапу является полное резервное копирование. Разностное резервное копирование включает в себя только изменения между текущим состоянием базы данных и состоянием базы данных на момент последнего полного резервного копирования, таким образом, задача разностного бэкапа выполняется быстрее, а сам файл занимает меньше места. В то же время есть и недостаток разностного бэкапа — без полного бэкапа он бесполезен.
Очистка процедурного кэша. Для очистки кэшированных планов запросов необходимо выполнить очистку процедурного кэша. Обновление статистики вызывает рекомпеляцию запросов, но, для надежности, рекомендуется включить данную задачу после выполнения задачи обновления статистики.

Субплан «Еженедельный» (7-ой день недели)

В целом, данный субплан похож на «Ежедневный», но в нем присутствует задача «Проверка целостности базы данных», дефрагментация заменена на более требовательную процедуру «Перестроение индекса», а также разностный бэкап заменен на полный. Если достаточно ресурсов (как системных, так и времени в которое не происходит работы пользователей), тогда при желании можно еженедельный план сделать ежедневным, отказавшись от ранее описанного ежедневного.

Проверка целостности базы данных (Check Database Integrity). Используется для проверки размещения и структурной целостности пользовательских и системных таблиц, а также индексов в базе данных.
Реиндексация/Перестроение индекса (Rebuild Index). Достаточно долгая и требовательная операция. Она удаляет и заново строит индексы. В результате данной операции удаляется статистика использования индексов.
Обновление статистики (Update Statistics)
Full backup (Полное резервное копирование)
Очистка процедурного кэша

Срываем покровы

Вам, наверняка интересно почему так получается. На самом деле, мне тоже интересно, почему так получается со SCHEMA_ONLY-таблицей. В целом, на msdn есть отличная статья про Durability Memory-Optimized таблиц (а если вам нужно детально разобраться с тем как устроен In-Memory OLTP, есть отличный whitepapper от Kalen Delaney). И, справедливости ради, нигде не написано, что для SCHEMA_ONLY таблиц поведение будет отличаться.

Ключевая, для меня, фраза в статье (хотя, на мой взгляд, она не передаёт все нюансы):

Исходя из написанного здесь (там про FILESTREAM) и собственного горького опыта, речь не столько о самих бэкапах и чекпоинтах (ВАЖНО! Не делайте чекпоинты без бэкапа журнала транзакций в полной модели восстановления, чтобы вызвать сборщик мусора — ситуация будет становиться только хуже), сколько о том, что для того, чтобы файлы могли совершить «transition through the phases» нужно чтобы тот VLF, в котором они были созданы, был помечен как неактивный. Ну ладно, скажете вы, это же ерунда — бэкапы журнала транзакций в полной модели восстановления у вас снимаются регулярно, а в простой модели восстановления и волноваться не о чем

И я скажу вам да, но нет

Ну ладно, скажете вы, это же ерунда — бэкапы журнала транзакций в полной модели восстановления у вас снимаются регулярно, а в простой модели восстановления и волноваться не о чем. И я скажу вам да, но нет.

Давайте посмотрим как это выглядит:

Повторим эксперимент. В одной сессии откроем транзакцию:

А во второй выполним:

Ой, в простой модели восстановления файловая группа для In-Memory продолжает расти, если что-то мешает «переводу» нужного VLF в статус «неактивный». Это может быть незакрытая транзакция, репликация, какой-нибудь REBUILD индексов — да много можно чего придумать.

В полной модели восстановления у вас, помимо перечисленного, может быть настроена Availability Group.

Использование Transact-SQL

Важно!

Во избежание неоднозначности в каждой инструкции WITH RECOVERY рекомендуется явное задание параметра WITH NORECOVERY или WITH RECOVERY

Это особенно важно учитывать при написании скриптов

Восстановление резервной копии журнала транзакций

Чтобы применить резервную копию журналов транзакций, выполните инструкцию RESTORE LOG, указав при этом:

Имя базы данных, к которой будет применен журнал транзакций.

устройство резервного копирования, с которого будет восстановлена резервная копия журналов транзакций;

Предложение NORECOVERY.

В этой инструкции применяется следующая основная синтаксическая конструкция:
RESTORE LOG имя_базы_данных FROM WITH NORECOVERY.
Здесь имя_базы_данных — имя базы данных, а — имя устройства, содержащего восстанавливаемую резервную копию журнала.

Повторите шаг 1 для каждой резервной копии журналов транзакций, которые необходимо применить.

После восстановления последней резервной копии из последовательности восстановления базу данных следует восстановить при помощи одной из следующих инструкций.

Восстановить базу данных в составе последней инструкции RESTORE LOG:

Подождать, а затем восстановить базу данных отдельной инструкцией RESTORE DATABASE:

В последнем случае можно проверить, восстановлены ли все нужные резервные копии журналов

Такой подход часто полезен при выполнении восстановления на момент времени.

Важно!
При создании зеркальной базы данных этап восстановления можно пропустить. Зеркальная база данных должна остаться в состоянии RESTORING.

Примеры (Transact-SQL)

По умолчанию для базы данных AdventureWorks2012 используется простая модель восстановления. В следующем примере для перехода на модель полного восстановления требуется изменить базу данных следующим образом:

A. Применение одной резервной копии журнала транзакций

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

Б. Применение нескольких резервных копий журналов транзакций

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

Типы публикации

Репликация транзакций поддерживает четыре типа публикаций:

Тип публикации	Описание
Стандартная публикация транзакций	Подходит для топологий, в которых все данные подписчика доступны только для чтения (репликация транзакций не устанавливает принудительно этот вид доступа на подписчике). Стандартные публикации транзакций создаются по умолчанию, если используется Transact-SQL или объекты RMO. Если используется мастер создания публикации, публикации транзакций создаются путем выбора Публикация транзакций на странице Тип публикации . Дополнительные сведения о создании публикаций см. в статье Публикация данных и объектов базы данных.
публикация транзакций с обновляемыми подписками;	Ниже приведены характеристики этого типа публикации: -Каждое расположение содержит идентичные данные с одним издателем и одним подписчиком. -Строки можно обновлять в подписчике -Эта топология более всего подходит для серверных сред, в которых требуется высокий уровень масштабируемости доступности и чтения.Дополнительные сведения см. в разделе Обновляемые подписки.
Одноранговая топология	Ниже приведены характеристики этого типа публикации: — Каждое расположение содержит идентичные данные и действует и как издатель, и как подписчик. — Одна и та же строка может быть изменена за раз только в одном расположении. — Поддерживает обнаружение конфликтов. — Эта топология более всего подходит для серверных сред, в которых требуется высокий уровень масштабируемости доступности и чтения.Дополнительные сведения см. в разделе Peer-to-Peer Transactional Replication.
Двунаправленная репликация транзакций	Ниже приведены характеристики этого типа публикации:Двунаправленная репликация аналогична одноранговой репликации, однако она не обеспечивает разрешение конфликтов. Кроме того, двунаправленная репликация ограничена 2 серверами. Дополнительные сведения см. в статье Двунаправленная репликация транзакций.

Use ApexSQL Log

ApexSQL Log – это инструмент, который позволяет работать с журналом транзакций SQL Server в наглядном виде. Он позволяет просматривать текущий журнал транзакций в режиме реального времени, обращаться к резервным копиям журнала транзакций, как обычным, так и созданных в режиме компрессии. При этом приложение самостоятельно считывает данные из резервных копий БД, чтобы получить всю необходимую информацию для успешного восстановления. С помощью ApexSQL Log вы можете просматривать цепочки транзакций, которые произошли в вашей БД, даже те, которые были совершены до установки утилиты. В отличии от недокументированных и неподдерживаемых функций, рассмотренных выше, вы получите наглядную информацию о том, какие операции происходили над объектами, сможете увидеть старое и новое значение.

Запустите ApexSQL Log
Подключитесь к базе данных, чей журнал транзакций вы хотите проанализировать
На шаге Select SQL logs to analyze, выберите записи, которые нужно прочитать. Убедитесь, что они образуют полную цепочку
Чтобы добавить резервные копии журнала транзакций и отдельные файлы LDF, используйте кнопку Add
Используйте фильтр на шаге Filter setup, чтобы уменьшить количество считываемых транзакций с помощью указания временного диапазона, типа операций, таблицы и другие фильтры
Нажмите Open

Полный результат можно будет увидеть в табличном виде

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

Чтобы избежать нечитаемых шестнадцатеричных значений, недокументированных функций, непонятного содержимого колонок, запросов со сложной конструкцией, сложных сценариев получения данных, неполных данных операций UPDATE, а также проблем с получением BLOB значений из журнала транзакций SQL Server, используйте программу ApexSQL Log. Она за вас выполнит все сложные операции и предоставит результат в читабельном виде. Кроме того, она позволит вам с помощью одного нажатия отменить или повторно выполнить нужную транзакцию.

Методы, чтобы узнать, как проверить журнал транзакций SQL Server

Как мы узнали, чтение файла журнала имеет огромное значение, отсутствие его анализа может привести к потере или повреждению данных в базе данных. Это не может быть подходящей ситуацией для любого пользователя как такового. Чтобы помочь тем, кто не знает, как открыть эти файлы, у нас есть 3 решения.

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

Второй метод проверки журнала транзакций SQL-сервера — применение сравнительно немного сложной команды. Этот метод требует, чтобы пользователи обладали техническими знаниями, чтобы правильно применить его с первого раза. В противном случае это может привести к ошибкам или может вызвать повреждение файлов журнала.

В третьем решении вы должны использовать SQL Server Management Studio, который может решить ту же проблему за вас. Пока это бесплатный метод, он сложен и может занять некоторое время, чтобы выполнить это упражнение.

Давайте перейдем ко всем этим методам и узнаем, как работают для каждого.

DBCC PAGE

Ещё одна полезная команда DBCC PAGE, но также, как и две предыдущих функции –недокументированная. Она позволяет просматривать содержимое файлов MDF и LDF. Её синтаксис:

DBCC PAGE ( {'dbname' | dbid}, filenum, pagenum )

Для просмотра содержимого первой страницы журнала транзакций БД AdventureWorks2012, необходимо выполнить:

SELECT FILE_ID ('AdventureWorks2012_Log') AS 'File ID' 
-- to determine Log file ID = 2
DBCC PAGE (AdventureWorks2012, 2, 0, 2)

В качестве результата вы получите сообщение:

DBCC execution completed. If DBCC printed error messages, 
contact your system administrator.

По умолчанию результат команды DBCC PAGE не выводится в SQL Server Management Studio и для её отображения первым шагом необходимо включить флаг трассировки 3604:

DBCC TRACEON (3604, -1)

И теперь повторно выполните команду:

DBCC PAGE (AdventureWorks2012, 2, 0, 2)

Вы увидите несколько ошибок и заголовок страницы, которые можно проигнорировать. Ниже вы получите шестнадцатеричное отображение LDF-файла:

Полученный результат ничем не отличается от того, который вы можете получить в любом hex-редакторе, а может быть даже и в менее наглядном виде. Главное отличие – это возможность просматривать файл в режиме реального времени, без отключения БД, но дружелюбным такой формат никак нельзя назвать.

Перед началом

Ограничения

Инструкция не разрешена в явных и неявных транзакциях. Явными транзакциями являются транзакции, для которых явно назначаются запуск и остановка.

Permissions

Нужные разрешения и назначаются по умолчанию членам предопределенной роли сервера sysadmin и предопределенным ролям базы данных db_owner и db_backupoperator. Перед началом убедитесь в наличии необходимых разрешений.

Проблемы, связанные с владельцем и разрешениями у физических файлов на устройстве резервного копирования, могут помешать операции резервного копирования. SQL Server должен иметь возможность считывать и записывать данные на устройстве; учетная запись, от имени которой выполняется служба SQL Server , должна иметь разрешения на запись. Однако процедура sp_addumpdevice, добавляющая запись для устройства резервного копирования в системные таблицы, не проверяет разрешения на доступ к файлу. Проблемы доступа к физическому файлу устройства резервного копирования могут не проявляться до обращения к физическому ресурсу при попытке резервного копирования или восстановления. Поэтому обязательно убедитесь в наличии необходимых разрешений, прежде чем начать.

Управление размером файла журнала транзакций

Перед началом

Предварительные требования

Permissions

Копирование числовых ячеек из 1С в Excel Промо

Операции, поддерживаемые журналом транзакций

Восстановление отдельных транзакций

Восстановление всех незавершенных транзакций при запуске SQL Server

Накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя

Поддержка репликации транзакций

Поддержка решений высокого уровня доступности и аварийного восстановления

Шаг 2. Настройка сервера Microsoft SQL 2005

2.1. Настройка протоколов подключения

2.2. Перенос tempdb на быстрый независимый массив/диски

2.3. Настройка параметров сервера SQL

Управление увеличением размера файла журнала транзакций

Процедуры обслуживания

Субплан «В течение дня»

Субплан «Ежедневный» (6 из 7 дней в неделе)

Субплан «Еженедельный» (7-ой день недели)

Срываем покровы

Использование Transact-SQL

Восстановление резервной копии журнала транзакций

Примеры (Transact-SQL)

A. Применение одной резервной копии журнала транзакций

Б. Применение нескольких резервных копий журналов транзакций

Типы публикации

Use ApexSQL Log

Рекомендации

Методы, чтобы узнать, как проверить журнал транзакций SQL Server

DBCC PAGE

Перед началом

Ограничения

Рекомендации

Permissions