none
Размер журнала транзакций при зеркалировании RRS feed

  • Вопрос

  • Имеем 2 сервера: SERVER1 и SERVER2

    На обоих - MSSQL 2005 SP1 Eng Std

    Есть database, размер базы - 54 гига. Была расположена на SERVER1, каждую ночь делался бакап журнала транзакций и DBCC SHRINKDATABASE(N'database' ), после чего файл журнала транзакций становился размером 1Мб (как и должно быть).

    Сейчас запустили зеркалирование, с SERVER1 на SERVER2, и данная процедура не работает. Размер файла журнала транзакций уже 34Гб, и продолжает расти.

    Вопрос - как при включенном зеркалировании урезать файл журнала транзакций.

    16 августа 2007 г. 15:02

Ответы

  • У Вас вот это:
    BACKUP LOG database WITH TRUNCATE_ONLY
    на бд, включенной в Mirroring работает???

    Сделайте бекап лога (по-моему, уже 3й раз пишу об этомSmile) БЕЗ WITH TRUNCATE_ONLY
    BACKUP LOG { database_name | @database_name_var }
    TO <backup_device>

    Следующим шагом
    dbcc shrinkfile ('LOG_file', size)
    20 августа 2007 г. 8:39
  • ALTER DATABASE DB_1 SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    или KILL по @@SPID, не убивая свой коннект. Но мои личные предпочтения - 1й вариант.
    20 августа 2007 г. 11:49
  •  FreemanRU написано:

     Alexander Gladchenko написано:
    Кстати, а почему уменьшаете всю базу, а не только файл журнала, это же очень вредно?

    В литературе не видел противопоказаний. Сделал

    Code Snippet

    DBCC SHRINKFILE (N'database_log' , 0, TRUNCATEONLY)

     

    , эффект тот же. Файл лога уже 37Гб, на обоих серверах.

     

    В литературе полно противопоказаний, смотрите внимательнее!

    Нет вреднее команды, чем DBCC SHRINKFILE, хорошо хоть не после реиндексации её не запускаете...

     

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

    21 августа 2007 г. 13:49

Все ответы

  • "Вопрос - как при включенном зеркалировании урезать файл журнала транзакций."

    Ответ - 1. Настроить Backup журнала транзакций:

    Backing Up the Transaction Log (full and bulk-logged recovery models)
    BACKUP LOG { database_name | @database_name_var }
      TO <backup_device> [ ,...n ]
      [ <MIRROR TO clause> ] [ next-mirror-to ]
      [ WITH { <general_WITH_options> | <log-specific_optionspec> } [ ,...n ] ]
    [;]

    2. Проверить, а работает ли Mirroring. Principal будет держать записи в логе активными, пока они не будут записаны на зеркало. Хотя сравнивая размеры БД и лога этот вариант маловероятен.
    16 августа 2007 г. 19:35
  • 1. Написано же - каждую ночь делался бакап журнала транзакций и DBCC SHRINKDATABASE(N'database' )

    2. mirroring работает, во всяком случае состояние стоит "Synchronized: the databases are fully synchronized"

    На SERVER2 файл лога транзакций имеет такой же размер, как и на основном SERVER1.

     

    17 августа 2007 г. 7:40
  • Опечатался с размером базы Sad 54 Гб...

    17 августа 2007 г. 7:41
  •  каждую ночь ДЕЛАЛСЯ (т.е. делался до настройки Mirroring, насколько я понимаю) бакап журнала транзакций и DBCC SHRINKDATABASE(N'database' ), после чего файл журнала транзакций становился размером 1Мб (как и должно быть).

    Сейчас запустили зеркалирование, с SERVER1 на SERVER2, и данная процедура НЕ работает (т.е. сейчас НЕ делается, так?).

    И чего же Вы тогда удивляетесь, что у Вас лог растёт? Настройте backup лога.
    17 августа 2007 г. 12:31
  •  

    Пробовали выполнить урезание базы вручную (скриптом)? интересует, что сообщается в ответ на попытку уменьшения базы...

    Кстати, а почему уменьшаете всю базу, а не только файл журнала, это же очень вредно?

    17 августа 2007 г. 13:48
  • Да, согласен, написал я не очень понятно.

    В общем обрезанием базы занимался Job с двумя шагами:

    Step1:

    Code Snippet

    BACKUP LOG database WITH TRUNCATE_ONLY

     

    Step2:

    Code Snippet

    DBCC SHRINKDATABASE(N'database')

     

     

    После включения зеркалирования, этот Job остался и сам он нормально отрабатывает. Только вот толку от него - 0. Т.е. после его выполнения файл лога транзакций не уменьшается.

    20 августа 2007 г. 6:40
  •  Alexander Gladchenko написано:
    Кстати, а почему уменьшаете всю базу, а не только файл журнала, это же очень вредно?

    В литературе не видел противопоказаний. Сделал

    Code Snippet

    DBCC SHRINKFILE (N'database_log' , 0, TRUNCATEONLY)

     

    , эффект тот же. Файл лога уже 37Гб, на обоих серверах.

    20 августа 2007 г. 6:47
  • У Вас вот это:
    BACKUP LOG database WITH TRUNCATE_ONLY
    на бд, включенной в Mirroring работает???

    Сделайте бекап лога (по-моему, уже 3й раз пишу об этомSmile) БЕЗ WITH TRUNCATE_ONLY
    BACKUP LOG { database_name | @database_name_var }
    TO <backup_device>

    Следующим шагом
    dbcc shrinkfile ('LOG_file', size)
    20 августа 2007 г. 8:39
  • Аааа.. Тупой я....

    Он же мне писал, черным по белому, "Cannot shrink log file 2 (ABONENT_Log) because all logical log files are in use."

    Всё, пора в отпуск...

     

    Ну и сразу вопрос - как отключить всех пользователей от базы (это будет ночью, так что коннекты остануться только у тех, кто просто не выключил комп.)

    20 августа 2007 г. 11:03
  • ALTER DATABASE DB_1 SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    или KILL по @@SPID, не убивая свой коннект. Но мои личные предпочтения - 1й вариант.
    20 августа 2007 г. 11:49
  •  FreemanRU написано:

     Alexander Gladchenko написано:
    Кстати, а почему уменьшаете всю базу, а не только файл журнала, это же очень вредно?

    В литературе не видел противопоказаний. Сделал

    Code Snippet

    DBCC SHRINKFILE (N'database_log' , 0, TRUNCATEONLY)

     

    , эффект тот же. Файл лога уже 37Гб, на обоих серверах.

     

    В литературе полно противопоказаний, смотрите внимательнее!

    Нет вреднее команды, чем DBCC SHRINKFILE, хорошо хоть не после реиндексации её не запускаете...

     

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

    21 августа 2007 г. 13:49