|
|
|
Причина разрастания журнала транзакций
|
|||
|---|---|---|---|
|
#18+
Последние недели наблюдаю за состоянием журналов транзакций в моих mssql базах 1С. Забавная история: основная база, развернутая около года назад регулярно имеет относительно малый лог, периферийная база, созданная сперва файловой, но после переведенная на sql после загрузки стала иметь лог ~70% от размера базы. Ужал транзакции, и отметил для себя как "пунктик" в сторону "1С". Понадобились копии периферийной, создал средствами sql. В результате имею, что логи периферийной базы и все ее копии (изначально поднятые из *.dt) растут как на дрожжах, устал их урезать. Урезаю логи подобным скриптом <script> USE DatabaseName; GO ALTER DATABASE DatabaseName SET RECOVERY SIMPLE; GO DBCC SHRINKFILE (logName, 1); GO ALTER DATABASE DatabaseName SET RECOVERY FULL; GO </script> Какая может быть причина? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2010, 15:00 |
|
||
|
Причина разрастания журнала транзакций
|
|||
|---|---|---|---|
|
#18+
смысл грубинный гонять базу из фулл в симпл для обрезки? В результате бэкапов журнала нету - навернется база - преимущества фулла все похерены. Не проще делжать в фулл и бэкапить лог с его обрезкой? Или реально в симпл перевести на постоянку? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2010, 15:05 |
|
||
|
Причина разрастания журнала транзакций
|
|||
|---|---|---|---|
|
#18+
Я очень плохо знаю mssql, и не понимаю разницы между режимами восстановления. Пример кода взял здесь http://msdn.microsoft.com/ru-ru/library/ms189493(v=SQL.90).aspx В принципе пробовал урезать лог строчкой DBCC SHRINKFILE (logName), DBCC SHRINKDataBasa (DatabaseName), интерфейсными окошками stidio sql server Подозреваю, что мои проблемы еще в том, что я абсолютно не понимаю, к чему приводит урезание журнала транзакции. Литературу, мануал читать пробовал - нахожу ответ: "удаляется неиспользуемые места". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2010, 16:53 |
|
||
|
Причина разрастания журнала транзакций
|
|||
|---|---|---|---|
|
#18+
причина скорее всего в том что у основной базы стоит simple а в переферийной full ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2010, 17:06 |
|
||
|
Причина разрастания журнала транзакций
|
|||
|---|---|---|---|
|
#18+
Лог растет от количества транзакций. Что делает твоя база? посмотри навешены ли тригеры ? Есть ли всякие средства мониторинга и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2010, 10:34 |
|
||
|
Причина разрастания журнала транзакций
|
|||
|---|---|---|---|
|
#18+
AleGolЯ очень плохо знаю mssql, и не понимаю разницы между режимами восстановления. Пример кода взял здесь http://msdn.microsoft.com/ru-ru/library/ms189493(v=SQL.90).aspx В принципе пробовал урезать лог строчкой DBCC SHRINKFILE (logName), DBCC SHRINKDataBasa (DatabaseName), интерфейсными окошками stidio sql server Подозреваю, что мои проблемы еще в том, что я абсолютно не понимаю, к чему приводит урезание журнала транзакции. Литературу, мануал читать пробовал - нахожу ответ: "удаляется неиспользуемые места".Обрезать не нужно. Просто делайте бэкап лога. Файл должен стабилизироваться на каком-то размере и перестать расти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2010, 10:56 |
|
||
|
Причина разрастания журнала транзакций
|
|||
|---|---|---|---|
|
#18+
2 TC Рекомендую сделать банальный жоб на MSSQL c командой DBCC SHRINKFILE(<log_logic_name>, <mB>) на вашу базу. И запускать его время от времени. Модель базы можно оставить FULL. Кстати, не стоит заниматься изъебствами вроде выгрузки в .dt Это можно делать на игрушечных базах. На промышленных юзайте SQL-бэкап и только его ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2010, 15:02 |
|
||
|
Причина разрастания журнала транзакций
|
|||
|---|---|---|---|
|
#18+
Программист 1сAleGolЯ очень плохо знаю mssql, и не понимаю разницы между режимами восстановления. Пример кода взял здесь http://msdn.microsoft.com/ru-ru/library/ms189493(v=SQL.90).aspx В принципе пробовал урезать лог строчкой DBCC SHRINKFILE (logName), DBCC SHRINKDataBasa (DatabaseName), интерфейсными окошками stidio sql server Подозреваю, что мои проблемы еще в том, что я абсолютно не понимаю, к чему приводит урезание журнала транзакции. Литературу, мануал читать пробовал - нахожу ответ: "удаляется неиспользуемые места".Обрезать не нужно. Просто делайте бэкап лога. Файл должен стабилизироваться на каком-то размере и перестать расти.+1 Когда Recovery model = Full, усечение журнала транзакций происходит при архивировании журнала транзакций командой Backup Log. Если бэкап лога регулярно не выполняется (а, например, выполняется только полный бэкап базы данных командой Backup Database), происходит разрастание журнала транзакций просто потому, что транзакции не удаляются из журнала. AleGol, Recovery Model в переводе на русский "модель восстановления". Почитайте BOL, разберитесь в отличиях моделей восстановления. И определитесь с тем, какая из моделей Вам больше всего подходит. Если Вы не делаете и не собираетесь делать бэкапы журнала транзакций, то модель восстановления Full вам просто не подходит, а подходит Simple (в этом случае журнал транзакций регулярно усекается автоматически, система не пытается дождаться бэкапа журнала транзакций). Если вы выбрали модель восстановления Full, то вы ДОЛЖНЫ делать бэкапы журнала транзакций. Хочу заметить, что модель восстановления Full, ПМСМ, имеет преимущества по сравнению с другими моделями. Она позволяет восстановить базу по состоянию на любой момент времени. В том числе на тот, который произошел после последнего бэкапа. При использовании других моделей восстановления это невозможно. Рекомендую настроить два джоба. Один пусть выполняет команду Backup Database, 1 раз в неделю - по выходным. Другой выполняет команду Backup Log - каждый вечер по рабочим дням. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2010, 12:15 |
|
||
|
Причина разрастания журнала транзакций
|
|||
|---|---|---|---|
|
#18+
AleGol, Если база относительно небольшая и бэкап средствами скуля делается за полчаса-час, то можно ограничиться простецким полным бэкапом в ночном задании по расписанию (Jobs), рекавери модель в этом случае лучше сделать Simple. Если база выросла и полный бэкап - накладное дело, то его делают реже, а между полными бэкапами делают (тоже джобами, само-собой) периодические бэкапы логов (изменений). А вообще, за базой ухаживать надо: обновление статистики/реиндексация еще желательны. В оболочке Enterprise Manager (для 2000) или SQL Server Management Studio (2005) в ветке Managment есть мастер: Maintenance plan - поможет джобов напечь, потом подрихтовать их можно, если надо. Пасабжу: Старая статья с ИТС: Уменьшение размера журнала транзакций MS SQL Server 2000 Выполнение интенсивных операций по модификации данных информационной базы приводит к увеличению размеров файлов данных и журнала транзакций. В какой-то момент времени старые записи журнала транзакций становятся не нужными для восстановления базы данных и могут быть удалены, освобождая тем самым место для новых записей. Если своевременно не удалять старые записи журнала транзакций, то через некоторое время файл журнала транзакций может занять все свободное дисковое пространство и работа с базой данных станет невозможной. Проблема Рост файла журнала транзакций. С помощью команды DBCC SHRINKFILE не удается уменьшить размер файла журнала транзакций до нужного размера . Решение Для решения описанной проблемы необходимо предварительно удалить неактивные записи журнала транзакций с помощью команды BACKUP LOG, а затем уже с помощью команды DBCC SHRINKFILE уменьшить размер файла журнала транзакций. Последовательность команд, которую нужно исполнить в Query Analyzer, выглядит следующим образом: BACKUP LOG Имя_Базы_Данных WITH TRUNCATE_ONLY go DBCC SHRINKFILE(Имя_Файла_Журнала_Транзакций) go ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2010, 07:48 |
|
||
|
|

start [/forum/topic.php?fid=28&msg=36685553&tid=1522233]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
164ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 451ms |

| 0 / 0 |
