Перестроение индексов и лог базы 1С 8.2 MS SQL #700748

Подскажите пожалуйста, перечитал кучу форумов, никак не собирается правильная последовательность в голове. У меня есть БД на MS SQL, режим восстановления full. Раз в неделю я хочу перестраивать индексы, в субботу, когда пользователи не работают. После этой операции лог базы вырастает с 7GB до 47GB. Необходимо его "обрезать". Но так как режим восстановления -  full, то необходимо делать бэкап лога. Но делать бэкап 47Gb - мне очень не хочется. Подскажите как правильно настроить, чтобы получить такую последовательность: Сначала перестроение индекса, затем бэкап базы, затем обрезание лога до 7GB (моей базе больше не надо обычно), затем бэкап разностный, затем бэкап лога. Ну или как правильно должно быть, но чтобы не бэкапить лог в 47GB.

без версии сиквела топик ни о чем

>>то необходимо делать бэкап лога. Но делать бэкап 47Gb - мне очень не хочется не надо ничего делать, никакой бэкап тебе на винт не упадёт, смотри Shrink file и т.д. Как я понимаю бэкапы делаете полные?

>>затем бэкап базы, затем обрезание лога до 7GB (моей базе больше не надо обычно), затем бэкап разностный, затем бэкап лога. где тут логика, объясни хоть... после полного бэкапа сразу разностный? что это? шринк лога вобще можно забыть, раз бэкапы только фулл и разностный. Политика бэкапирования какая?

Зачем тебе full - для начала.

backup with truncate only

>Но так как режим восстановления -  full, то необходимо делать бэкап лога накуа это делать после перестроения индексов?

и что должно дать перестроение индексов?

короче набирайтесь кармы

насколько я помню , можно перестроить индексы без регистрации в журнале.

Вот здесь всё разжёвано:

Начиная с sql server 2k8 это уже не работает.

Сервер 2008 r2 Тут всё просто. Я хочу повысить производительность 1С. Сейчас настроено так: Бэкап базы делается в субботу в 2 часа ночи. Затем с понедельника каждую ночь разностный бэкап и бэкап лога раз в 30 минут днём. Вопрос: Куда воткнуть перестроение индексов, если при перестроении лог-файл растет дико?

А в NULL нельзя сделать бэкап лога?

спасибо за ссыль

бекап. реиндекс. шринк лога. В такой последовательности

>Я хочу повысить производительность 1С. может проблема в очереди к диску... или памяти мало

типа BACKUP DATABASE [Testing] TO DISK = N'....' go BACKUP LOG [Testing] TO DISK= 'NUL:'

, Спасибо, попробую. , Реиндексация должна увеличить скорость работы.

вот это почитай

- Да нет, памяти 8 32Гб, достаточно. Просто положено иногда делать перестроение индексов, из-за того что база меняется, чтобы были более оптимизированные запросы и данные. Поэтому и хочу вставить это. Попутно вопрос: У меня процедура sp_spaceused показывает что у меня всего 33Гб, из них база 21 Гб, остальное - индексы. Вопрос - как убрать эти лишние 12Гб индексов? Раньше база была 22Гб и было нормально. Тут похоже сам что-то неверно где-то сделал, может как раз реорганизация индексов такое сделала.

>> Реиндексация должна увеличить скорость работы Можно ведь и без фанатизма. Используйте REORGANIZE вместо REBUILD для снижения фрагментации и не на всей базе, а только на тех таблицах, где это действительно нужно. >> Вопрос - как убрать эти лишние 12Гб индексов? В smss есть отчёт "disk usage by table" - в нём детальная информация, какой индекс на какой таблице сколько места занимает. Кстати, совсем не факт, что они окажутся "лишние".

>Реиндексация должна увеличить скорость работы это палка с двух концов... если база на чтение - увеличится, если на запись - может где-то и уменьшить - "накладные расходы" возрастут

скриптом можно выявлять "подозрительные" таблицы - слишком "мелкий" fill factor и издеваться только над ними, чтобы не лупить всю базу - это и объем лога уменьшит

Переключай в simple, реиндексируй, переключай в full

>Переключай в simple, реиндексируй, переключай в full извращения какие... вот зачем они truncate выпилили в 2008?

А зачем он нужен? Зачем журналировать изменения, чтобы потом их похерить? Всё логично.. если журнал не нужен, есть режим simple. Если нужен - значит, надо бэкапить.

Вариант 1 - не перестраивать все индексы, а перестраивать выборочно. В посоветовали мой скриптик. Для начала можно попробовать его. Реально объём разрастания журналов уменьшается раз в 10. Если что, там есть ссылка на этот же скрипт в гуглодоксах, да и вообще, если что-то непонятно - всегда готов уточнить. Вариант 2 (не ислючает вариант 1) - на время переиндексации переходить в модель bulk logged и включить сортировку в tempdb, после переиндексации - обратно в full, после чего рез. копию лога - тогда (если всё правильно сделать), файл лога разрастаться не будет, но бэкап лога будет жирненький (хотя со сжатием обычно это не критично). Расписание бэкапов в в общем-то прекрасное.

Всем спасибо! Сделал полный бэкап и шринканул лог. Теперь понятно - бэкап базы -> перестроение индексов -> шринк лога.

Зачем сервер зря насиловать журналированием страниц индексов с последующей очисткой? Я бы переключал в симпл, а после - обратно возвращал фулл, это было бы и быстрее.