Вырос log файл базы до 420 гигов. Сама база весит 7 гигов. База РИК. Причем растет скачкообразно может неделю не изменятся размер а потом за раз вырасти сразу на 40 гигов. Все планы обслуживания испробованы результат нулевой. В чем проблема кто нибудь сталкивался???

(0)
что такое РИК ?

(1) РИБ опечатка )))

"может неделю не изменятся размер а потом за раз" запустили невменяемую обработку по закрытию какой-нить ереси на двое суток и получайте.

Как уменьшить размер log  файл а то скоро места не хватит?

(4) Ставишь у базы "Модель восстановления" Simple(Простая). ПКМ на базу, "задачи-сжать-файлы", выбираешь файл лога, ставишь новый размер.

Интересно, а можно файл log перенести на другой физический диск? А то, по моему, нахождение его на том же физическом устройстве, довольно прилично тормозит работу, при которой меняются большие объемы данных. Например, закрытие периода.

(6) Не поверишь - нужно! Это официальная рекомендация MS, так скуль будет работать быстрее.
И в (5) тебе правильно сказали, только перед этим тот же MS рекомендует бэкап сделать.

(7) Я уж это не стал писать:).
Вообще оптимизация быстродействия - отдельная песня, но общие рекомендации таковы - базу - на отдельный физический носитель либо на отдельный массив дисков. То же самое - с логом, так как 1с активно его использует. Лог-файл бьется на отдельные файлы, которые соответствуют количеству ядер в системе. Система  - на отдельном диске. Навскидку - так.

(5) Модель восстановление не хочется ставить Простую стоит полная. Задача сжать файлы не помогла. А поставить при рабочей базе новый размер лога как то боязно, а примерно сколько ставить размер лога и чем это может грозить???

(9) сжатие лога без транкейта, как новый год без ёлочки

(9) На работающей базе это делать не нужно. Выгони пользователей. Сделай бэкап. Затем сделай как я написал. Потом верни обратно модель восстановления.

Книга знаний: Почему разрастается журнал транзакций - файл .LDF для MS-SQL

А бэкапы журнала делаешь? Поидеи должен уменьшаться после резервной копии.

ldf растет наиболее сильно, когда происходит перестроение индексов. Нет ли у тебя такого в планах обслуживания? Если так, то нужно шринковать после обслуживания. Только не базу, а сам ldf. Еще вариант - массовая загрузка данных. Но индексы наиболее вероятно.

(8) бить нужно не лог, а tempdb. "биение" лога бессмысленно.

А простая выгрузка и загрузка средствами 1С решает проблему лога и фрагментации базы?

(15) хм

(0) Постоянно читаю вот эти статьи. Жду просветления.

http://msdn.microsoft.com/ru-ru/library/ms345419(v=sql.105)
http://msdn.microsoft.com/ru-ru/library/ms345583(v=sql.105)

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

Изучаю дальше эту тему... Еще много непонятного...

(16) опять же временно )

сделай бэкап ЛОГА и шринкани, это проще чем загружать выгружать dt

(19)Ну, хотя бы перед большими обработками.

(20)Дело в том, что админ в конторе совершенно не представляет себе всех нюансов работы с какой-либо SQL. Такое ощущение, что он оканчивал философский факультет политеха. Вот и думаю, что проще ему на 1С стандарте делать все операции.

(22) Чё за мода пошла на админов которые мышки меняют и винду переустанвливают вешать задачи по обслужаванию баз данных. Кто скорее специались по БД? Одинэсник или этот переустановщик винды?

(23) Что за мода пошла...на тех кто обслуживать бушек...вешать сервера...

(23)Нормальная такая мода. Он позиционирует себя, как крутой спец. Но, хотя бы элементарные вещи по SQL должен знать. К 1С это, совершенно, не относится.

(22) тогда урезать и переводить базу в режим simple, хотя переодически проблема с логом все равно будет возникать, но не в таких масштабах

(24)(25) Ну ладно останемся при своих мнениях. Я считаю что администрирование сети, винды совсем близко не радом с обслуживание БД типа SQL или Oracle. Это блин вообще отдельная специальность, которая согласитесь ближе к работе одинэсника.

(27) Да ладно...одинесник должен бушек обслуживать и облизывать..а серьезные вещи типа администрирование SQL и Оракл...как правильно сказал другие люди...и админ ближе к этому так как технический специалист по образованию...

база была 60 гб, лог файл 180 гб. Покурил покурил и так и не понял, на кой черт мне нужен этот лог файл. Сделал модель simply и живу дальше припеваючи. Всё ок

(28) Так стоп... Я думал одинэсники это технические специалисты с очень обширными позниниями в теории БД в первую очередь, Операционных система, сетях, БУ, НУ, МСФО. Я ошибался?

(29) Такая модель тоже имеет место быть. Это нормально. Это зависит от уровня пох...ма админа. Расскажи как часто делаются резервные копии базы в 60 гигов?

(30)Ошибаешься. Если спросить админа че нить про проводки, он со стула рухнет.

(32) Я правильно понял что ты хорошо знаешь теорию БУ, НУ а про индексы БД не слышал и принципиально не хочешь слышать?

(30) Просто есть еще универсалы вот и все. В глубинках России приходится так вот работать))))

(31) был куплен внешний винт на 1,5 ТБ. Делаются архивы каждый день. В итоге за месяц остаются архивы только на первое число. Остальное удаляется.

(34) Я сам из глубинки. Мне самому приносили утюги и телевизоры ремонтировать, и лампочки в туалете почему то тоже "компьютерщик" должен менять. Ну я про тоже что админ админит мышки и клавы, а чел по работе с БД вроде как занимается БД. Нет?

(33)Пожалуй, тебе на стольких БД, на которых я работал, не приходилось работать. Думаю, такая же ситуация и в области знаний по БУ, НУ. Я просто хочу чтобы каждый занимался своим делом. А БД, насколько позволяет мне мой опыт, ближе к администрированию.

(36) Ну т.е. раз в сутки, если вдруг в обед полетит винд с рабочей БД, то данные по 1000 отгрузок за полдня вручную перебивать с первички? Если тебя за это не подвесят то это приемлемый вариант.

(11) Попробую как посоветовал. А так архивы делаются раз в сутки и на SQL  и DT выгружается а вот архивирования журнала выключили так как подумали что вроде и не нужен, хотя после прочтения все ответов понял что лучше его включить и потихоньку log уменьшится.

(38) там зеркало )

(40) Видал я как эти зеркала сыплются, стоимость восстановления дороже чем всю базу перебить вручную.

(41) ага, я тоже видал как серверную из канализации заливало )

(36) С этим согласен но думаю что еще многое зависит от аппаратной части т.е. железа если сервер нормальна собран под задачи с минимальными рисками. У нас Raid  10. Причем архивы кидаются на другой сервер.

Включу архивацию лога раз в час посмотрим завтра как это повлияет на размер лога.

Мда дела пока болтали вырос еще на 22 гига. Т.е. буквально за 2 часа.

(15) Разумеется, я ошибся, прошу прощения. Файлы данных TempDB разбиваются, лог TempDB остается в остается одним файлом.

(45) Ну а что с базой-то происходит? Должны быть массовые операции со строками или операции с индексами. Что в профайлере видно?

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

(48) "перестроение индекса" - ну вот и лови 22 гига.

(48) "перестроение индекса-реорганизация индекса-обновление статистики"

Да... действительно ничё особенного... Как вы там ещё работаете...

(49) Я так понял что если я включил архивирования журнала транзакции то лог уменьшится. Все нормальна работало все это произошло буквально за пару недель. Но было включено архивирования лога транзакции. И плотформа была 15. В данный момент 16. И пошел рост лога.

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

(52) т.е  архивирование базы одиним планом обслуживания каждый день а остальное можно и раз в недельку другим планом обслуживания?

(53) Да. Правда, смотря какая база. Если много данных меняется - вставка, удаление - тогда можно и чаще. Опять же - не обязательно все подряд. Вот такая процедура крутится у меня:

DECLARE @SQL varchar(256), @DB_ID int;
SET @DB_ID = (SELECT DB_ID());

DECLARE reindex CURSOR GLOBAL FAST_FORWARD READ_ONLY FOR
SELECT    'ALTER INDEX ALL ON [' + OBJECT_NAME(afp.OBJECT_ID) + '] REBUILD WITH (SORT_IN_TEMPDB = ON);' AS [Инструкция T-SQL]
FROM    sys.dm_db_index_physical_stats (@DB_ID, NULL, NULL, NULL, 'SAMPLED') AS afp
WHERE    afp.database_id = @DB_ID
AND    afp.index_type_desc IN ('CLUSTERED INDEX')
AND    (afp.avg_fragmentation_in_percent >= 15 OR afp.avg_page_space_used_in_percent <= 60)
AND    afp.page_count > 12
UNION ALL
SELECT    [Инструкция T-SQL] =
   CASE
       WHEN afp.avg_fragmentation_in_percent >= 15
       OR afp.avg_page_space_used_in_percent <= 60
       THEN 'ALTER INDEX [' + i.name + '] ON [' + OBJECT_NAME(afp.OBJECT_ID) + '] REBUILD WITH (SORT_IN_TEMPDB = ON);'
       WHEN (afp.avg_fragmentation_in_percent < 15 AND afp.avg_fragmentation_in_percent >= 10)
       OR (afp.avg_page_space_used_in_percent > 60 AND afp.avg_page_space_used_in_percent < 75)
       THEN 'ALTER INDEX [' + i.name + '] ON [' + OBJECT_NAME(afp.OBJECT_ID) + '] REORGANIZE;'
   END
FROM    sys.dm_db_index_physical_stats (@DB_ID, NULL, NULL, NULL, 'SAMPLED') AS afp
JOIN    sys.indexes AS i
ON    (afp.OBJECT_ID = i.OBJECT_ID AND afp.index_id = i.index_id)
AND    afp.database_id = @DB_ID
AND    afp.index_type_desc IN ('NONCLUSTERED INDEX')
AND    (
       (afp.avg_fragmentation_in_percent >= 10 AND    afp.avg_fragmentation_in_percent < 15)
   OR    (afp.avg_page_space_used_in_percent > 60 AND afp.avg_page_space_used_in_percent < 75)
   )
AND    afp.page_count > 12
AND    afp.OBJECT_ID NOT IN    (    
                   SELECT    OBJECT_ID
                   FROM    sys.dm_db_index_physical_stats (@DB_ID, NULL, NULL, NULL, 'SAMPLED')
                   WHERE    database_id = @DB_ID
                   AND    index_type_desc IN ('CLUSTERED INDEX')
                   AND    (avg_fragmentation_in_percent >= 15 OR avg_page_space_used_in_percent < 60)
                   AND    page_count > 1
               )
ORDER BY [Инструкция T-SQL]




OPEN GLOBAL reindex
WHILE 1 = 1
BEGIN
   FETCH reindex INTO @SQL
   IF @@fetch_status <> 0 BREAK
   --select @SQL
   EXEC(@SQL)
PRINT @SQL
END
CLOSE GLOBAL reindex
DEALLOCATE reindex

(54) Понятно большое спасибо. Буду пробовать что получится)))

Проблема решена ))))