Как почистить логи сервера MSSQL?
Не тот лог, который к базе прилагается в *.ldf-файле, а тот, который в папке самого сервера в россыпи *.log, *.mdmp и *.txt.
Желательно, штатными средствами сервера, что-то мне страшно удалять эти тысячи файлов вручную.

(0) Ну и плюс хочется ограничить рост этой папки впредь...

(0) в конфигураторе задай периодичность. и грохай старые по мере необходимости.

хотя у журнала другое расширение.

(2) Казалось бы, причем тут конфигуратор о_О??

сначала бы надо понимать откуда там это берется...

(5) +100500
и не удивляться, что к MS SQL это не имеет ни малейшего отношения

(4) я не вкурил сразу. в бине скуля что ли логи? или сервера 1с?

(2) Вы про конфигуратор 1С? А где я про него говорил?
(5) И как это узнать? Там 60 гигабайт, 36 с половиной тысяч файлов. Где копать?

(7) c:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\
Это логи скуля. Ни к 1С, ни к конкретной базе привязки не имеющие.

ctrl+a потом shift+del. а как еще то?

(6) может и имеет... настроили таск в скуле, он туда чего-то вваливает по окончанию джоба

(8) смотри джобы винды и скуля

ПКМ по "Журналы SQL сервер-Настроить" Что выставлено?

еще могут счетчики собираться...

(10) Слушайте, а давайте вы еще раз прочитаете (0), но на этот раз внимательно, ладно?
(13) Лимит 6. В списке 6 архивов и current, созданный сегодня.

(0)удали все будь мужиком .

(15) врят ли эти уже наваленные текстовики можно из скуля почистить.

(15) Тогда посмотри в
"Агент SQL сервер :ПКМ по "Журналы ошибок-Настроить" - По моему он туда спамит.

(18) У него, вроде, конкретный файл задан. Он ростом всего 2 килобайта.

.mdmp
файлы дампов. советую задуматься.

Заголовок файлов *.txt
=====================================================================                                            
      BugCheck Dump                                                                                            
=====================================================================                                            
                                                                                                               

У файлов *.log
pid51      * dbghelp                        12B40000  12C54FFF  00115000
2012-11-28 15:08:21.86 spid51      *


*.mdmp - бинарные какие-то.
(20) задуматься можно, а толку, если не знаешь, как это анализировать?

(20) +1

это жжж не спроста

О! А вот это уже улика...
в *.txt
End log dump for db = 'ESETRADB'

Никто не сталкивался с Eset Remote Administrator 4.2? Как решить эту проблему, или хотя бы определить, почему он мусорит в лог?
Выборка более-менее вменяемых строк из SQLDump10144.txt (номер 10144 тоже настораживает):
Begin transaction log dump for database 'ESETRADB'; for Index maintenance - filter on ObjId.
...
Operation = LOP_SET_BITS
Context = LCX_PFS
Log Record Fixed Length = 54
Log Record Length = 56
AllocUnitName = dbo.LinkClientQuarantine.IX_LinkClientQuarantine_ClientID
Log Record = 00003600000000000000000000000000000000000000070b0100000001000000a3000000e61b00009c01000003000001eb07010001000000
...
Operation = LOP_DELETE_ROWS
Context = LCX_MARK_AS_GHOST
Log Record Fixed Length = 62
Log Record Length = 116
AllocUnitName = dbo.LinkClientQuarantine.IX_LinkClientQuarantine_ClientID
Number of Locks = 3
Lock Information = HoBt 72057594043629568:ACQUIRE_LOCK_IX OBJECT: 22:1954106002:0 ;ACQUIRE_LOCK_IX PAGE: 22:1:249;ACQUIRE_LOCK_X KEY: 22:72057594043629568 (0400be72e6fc)
Log Record = 00003e00e61b00009c0100000400020096d02b0000000313f900000001000200a3000000e61b00002f010000090000010000570000000001010000000000020012001a000603000000019cec0000000000000000000000000101000c0000924a79740000010200040204000a0400be72e6fc0200
и таких пар LOP_SETS_BITS-LOP_DELETE_ROWS - на полтора мегабайта.

Люди! Есть кто живой? Он растет слишком быстро, помогите найти причину!

(25) http://social.technet.microsoft.com/Forums/ru/wsusru/thread/c015e958-0e29-4cfe-aada-8c3822655b6f

Проверьте базу ESETRADB с помощью DBCC CHECKDB

+(26) вторая ссылка в гугле по LOP_SETS_BITS...

Решил проблему немного кардинально, но все-таки результативно.
Короче, проблема была в том, что любой запрос на запись в таблицу LinkClientQuarantine падал с ошибкой. Даже напрямую в скуле, не то, чтобы от сервера Eset. Пришлось удалить эту таблицу и пересоздать заново. (Сначала Edit, открывается окно с запросом на создание, пока оно открыто - Drop Table, а потом выполняем запрос создания). Сейчас все работает.

Если можно, переименуйте тему в "Ошибка в Eset Remote Administrator Server при работе с MS SQL" и закройте обсуждение, пожалуйста.

Ах да! (0) Сами файлы лога удалять можно вручную, даже не останавливая серверов.