Cтраница 1
Размер журналов задается администратором в пределах от 10 Кбайт до 10 Мбайт. [1]
Частота копирования зависит от жизненного цикла базы данных и размера журнала системы. Под жизненным циклом базы данных понимается время, в течение которого происходит полная замена всех значений данных. При этом изменения могут происходить за один-два сеанса или накапливаться постепенно. Копия и журнал системы, расположенные на различных носителях, позволяют полностью восстановить базу данных даже в случае полного разрушения ее основного носителя. [2]
Рекомендуется выполнять резервное копирование базы данных master до и после увеличения размера журнала транзакций; это защитит систему в случае возникновения каких-то трудностей после изменения размера журнала. [3]
Данный индикатор может быть очень полезен для определения, корректно ли установлен размер журнала транзакций. В таком случае может быть полезно увеличить размер журнала транзакций. [4]
Если планируется разместить данные и журнал транзакций в одном и том же устройстве баз данных, размер журнала можно не указывать. В этом случае данные и журнал транзакций будут совместно использовать устройство, и журнал будет занимать столько пространства, сколько ему необходимо. В этом примере предполагается, что для хранения данных и журнала транзакций будут использоваться разные устройства баз данных. [5]
Рекомендуется выполнять резервное копирование базы данных master до и после увеличения размера журнала транзакций; это защитит систему в случае возникновения каких-то трудностей после изменения размера журнала. [6]
Этот индикатор указывает на текущий размер журнала транзакций конкретной базы данных. Если размер журнала во время работы не изменяется, не изменится и этот показатель. [7]
Данный индикатор может быть очень полезен для определения, корректно ли установлен размер журнала транзакций. В таком случае может быть полезно увеличить размер журнала транзакций. [8]
В SQL Server 6.5 предлагается новый индикатор, который отображает максимальный процент используемого пространства журнала транзакций конкретной базы данных. Этот показатель можно сравнить с высшей точкой, которая помогает решить, корректно ли задан размер журнала. [9]
Ответ на этот вопрос в большой степени зависит от характера приложения, количества пользователей и структуры баз данных. В большинстве случаев, когда приложение функционирует вполне нормально, применять новую схему блокирования; не нужно. IRL имеет ряд преимуществ, однако при его использовании возникает опасность взаимоблокировок ( deadlocks), a также увеличивается размер журнала транзакций. С другой стороны, если разрабатывается новое приложение, с помощью которого множество пользователей будет одновременно вводить данные в одни и те же таблицы, можно попробовать применить IRL и посмотреть, как это отразится на функционировании системы. Если предполагается повышение производительности, следует вести подробную регистрацию характеристик системы до и после производимой модификации. [10]
В последнем примере рассмотрена база данных смешанного назначения, обслуживающая самых разных пользователей. В течение дня пользователи добавляют, обновляют и удаляют Данные, а также выполняют запросы и отчеты. Объем данных практически постоянно равен 500 Мбайтам. Пользователи сообщают, что для них крайне важно время реакции системы. Они также не возражают против того, чтобы в случае сбоя системы в течение рабочего дня повторно вводить свои транзакции. В данном случае предположим, что размер журнала транзакций составляет 15 % от всего размера базы данных, т.е. 75 Мбайтов. Так как пользователи при необходимости могут повторять ввод своих транзакций, скорее всего, не требуется часто выполнять резервное копирование журнала транзакций. [11]