Добрый день! Посоветовали на ixbt спросить здесь. Буду рад любой помощи.
Ситуация очень горячая.
В двух словах:
1. 4 дня назад Была 1С8.2+SQL2008 enterprise, ~150 пользователей, база ~ размером 400Гб. Работало приемлемо, пользователи не жаловались.
2. Произвели замену SQL2008 на standart, сделали просто - детач, переустановка MSSQL, аттач. Все прошло хорошо .
3. При следующей регламентной переиндексации ночью, размер базы стал 1 тб. То есть, в 2 с лишним раза вырос размер базы.
4. Места катастрофически не хватает, пользователи жалуются, что база стала работать хуже.
5. База работает круглосуточно, остановка, даже кратковременная, очень вредит бизнесу.
Не могли бы Вы посоветовать, что можно сделать в такой ситуации? Надо вернуть базе её реальный размер, иначе пропадём.
Я не могу понять, как могло произойти такое изменение, и в размере базы, и в производительности. Знакомые админы говорят, что возможно индексы ДО были "правильные", а "ПОСЛЕ" индексы построил сам SQL по своим правилам, поэтому размер так резко увеличился.
Говорят, что надо было делать восстановление из бэкапа, а не аттач-детач, и в этом случае все бы было хорошо с размером.
Восстановление из бэкапа сейчас, с последующим внесением изменений, прошедших в боевой базе за 4 дня- означает вручную перепроверить 10 000 документов, которые были проведены за 4 дня, по словам программистов 1С. Это, конечно, не выход.
Возможно, кто-то сталкивался с такой ситуацией? Возможно, есть какие-то лучшие практики, как вернуть базе ее размер?
Шринки пробовали делать - не помогло.

(34) Было и у меня такое (база около 300 Гб) Иногда загрузка dt сваливалась после полусуток :((

(32) Кстати, отличная мысль. Сделаем!

(37) (34)  Неужели не только я такой "счастливый"....  dt-шник уже загружается в тест стенде, по результату отпишу!

(39) Просто так базы не вырастают. Сравнивай структуру и выросшие таблицы.

(36)(30)  Честно, не могу понять, что Вы порекомендовали. Понял, что я лгу и что что то с птичками нужно делать.
Шринк не помогает. Насчет нормальности - у меня в первый раз такая ситуация. Раньше был стабильный(постепенный) прирост базы, исходя из этой динамики, планировалось, в том числе, и место под сиквельные базы.

(41)а модель восстановления это понятно о чем? )))

(42) Да! Симпл была, и сейчас симпл.

(41) шринк базы и шринк файла - разные вещи, если после шринка данные сжались - место файл тебе обратно не отдаст, будет заполнятся потихоньку, не вызывая роста самого файла

(41)ТИИ со всеми птичками прибивает мусор

(45) Это Вы про тестирование и исправление - теперь понятно. Запустим. В последний раз попытка запускать была больше 5 месяцев назад, говорят заняла около 2-ух суток и вывалилась с ошибкой. Возможно, в этом и есть проблема...
(44) Спасибо, понял теперь. Уточните пожалуйста про то, как делается шринк файла. Я просто не умею этого делать.

http://msdn.microsoft.com/ru-ru/library/ms189493.aspx

а какой вы шринк делали в (0) то?

Хотя вариант (25) тоже стоит рассмотреть:
Вы на старом сервере сжатие не включали?
http://scarm-blog.livejournal.com/13666.html

(0) Не понятно, как может переиндексация вызывать рост файлов резкий рост файла базы... Если были добавлены какие-то индексы(или поля в индексы) - ещё понятно, а при неизменных - непонятно. Я бы взял две таблицы - старой и новой базы и сравнил бы записи.

(49)модель

(50) про модель автор вообще ничего не писал.
И как модель восстановления SQL влияет на таблицы 1С? никак.

(21) я вот вижу, что ВТ итогов РН сильно выросла. И индексы. Так что ТИИ и танцы с 1с-выгрузками.
SQL тут совершенно ни при чем.
(46) "говорят заняла около 2-ух суток и вывалилась с ошибкой."
вот и вылезло
(5)"Завтра опять база в 2 раза вырастет."
с какого перепугу? Ничего не вырастет также сильно в ближайшие полгода. У вас и так впритык места, покупайте срочно еще одно СХД.

сдается мне автор чего то незнал когда принимал на обслуживание данную шляпу.

Давай в рамках проекта ЦКТП отработаем?

(53) Судя по размеру таблицы и индексов до и после, даже с учетом выросшего количества записей, на жирных таблицах и индексах раньше был включен page compression

(55) согласен, делали бы не аттач-детач, а бэкап-рестор сразу бы это выявили.

(55)сейчас умник из (51) тебе объяснит что это никак на таблицы 1С не влияет

а вообще сначала надо было проверить какие функции entrp используются перед даунгрейдом.

(57) модель восстановления на размер таблицы никак не влияет.

(59)а кто сказал что таблица увеличилась?

(60) ТС написал что увеличился mdf файл.

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

(59) ну товарищ не в курсе, где компрессия, а где - модель.
Правда, умником тоже постеснялся себя назвать.

(55)"раньше был включен page compression"
ТС так жестко подставили? И зачем раньше компрессию включили? Она ж жрет CPU-время сразу существенно.

+ тем более, для таблиц с большими записями-строками (суммарный размер по строке более 8000 байт) сжатие не работает.

(0) Можно подробнее на сколько увеличились размеры самой базы - файла mdf и журнала транзакций log-файла. Может поможет выгрузка в dt, удаление базы на sql, и загрузка из dt в новую?

(66)загрузка базы из дт будет идти неделю при таких размерах

(59)(61)вы тут по ходу решили рисануться "page compression" а я мешаю )))

(64) На каком-то сайте с триксами по скулю недавно было показано, что на таблицах с текстовыми полями, которые хорошо жмутся, сжатие ускоряет выборку до 10и раз

(69)давай на рабочей базе пробуй и нам расскажешь

(67) ТС не написал же размер mdf-файла!? Впереди выходные, можно успеть...

(47) Добрый день! Делали шринк базы.

(48) нет, сжатие не включали!

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

(53) в точку!)

(58) Да, полностью согласен. Просто не предполагали даже, что такой пи**ворот начнется.

(62) Да, попробуем обязательно. Тестовый ресурс только один, к сожалению, операции занимают много времени, одновременно все проверить не получается.

(71) Да, небольшое уточнение.
Видимо, переиндексация даже не завершалась корректно(не хватило места), потому что попытка повторить процедуру в тестовой среде привела к таким размерам:
mdf-1 462 435,94 МБ
ldf-2 401 МБ.

В последней доступной копии было:
mdf-385 508 МБ.
ldf-16 901 МБ.

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

(0) А покажите скрипты для реиндексации на Enterprise и на Standard.
И заодно результаты выполнения скрипта ниже в контексте вашей базы (можно с тестового сервера после реиндексации)

DBCC UPDATEUSAGE(0)
EXEC sp_spaceused

(79) Скрипты показать не могу, т.к. не понимаю, как. Настроено с помощью мастера в плане обслуживания.
Результаты выполнения скрипта пришлю немного позже, т.к. сейчас делается реиндексация после выгрузки-загрузки через DT.
Очень странно. Выгрузка на тестовом сервере в dt с последующим разворачиванием из dt показывает размер базы 285 ГБ, что меньше, чем было!

(79) Реиндексация делается так-же, через планы обслуживания.

Так что проблема решена? если да то какой диагноз?

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

(80)"Результаты выполнения скрипта пришлю немного позже"
в каком виде? )))

(80)"Очень странно. Выгрузка на тестовом сервере в dt с последующим разворачиванием из dt показывает размер базы 285 ГБ, что меньше, чем было!"

тут тебе уже несколько раз указали на причины. лекции читать никто не будет.

(82) нет, в процессе! Как только появится диагноз, отпишу!

(83) Да, понимаю! Вы очень точны в своих определениях!

(78)"что компрессия в Standart не работает"
не работает, да.
И на зарубежных сайтах пишут, что даже восстановление бэкапа в Стандарт после сжатия в Энтерпрайз невозможно.
http://www.sqlskills.com/blogs/paul/sql-server-2008-does-my-database-contain-enterprise-only-features/
И вообще, вам на sql.ru надо, а вы тут...

(84) видимо, в виде базы разошлет...

ну что? проблема таки в светлой голове из (6)?

>>И вообще, вам на sql.ru надо, а вы тут...
+100500

Проблема глубже и масштабней, тут насоветуют...

и кстати если база не влезает в оперативу то скулям нужно время на набор статистики и скуль  и ось требуют настройки и мозга

В 2008 R2 Standart - компрессия работает.
В 2008 Standart - не работает.

(92)и что эта компрессия делает из терабайта 400 гигов + ускорение поиска? )))

(93) вроде говорят, да.
Но, скорей всего, это на базах с примитивными данными (которые жмутся хорошо), и которые великолепно ложатся на нормализованные структуры хранения (что тоже в сторону хранения и обработки примитивных типов).
К сожалению, 1С в подавляющем большинстве баз и конф совсем далеко от этого всего.

(92) Компрессия данных только в Enterprise, не путайте со сжатием бэкапов.

(95) Да, точно.

(95) совершенно верно

При подключении сжатой базы к версии Standart все будет работать и компрессия старых страниц останется. Новые страницы или измененные будут делаться без компрессии. А после переиндексации, как у автора, включая кластерные индексы, то бишь сами данные таблиц, компрессия пропадет со всех старых страниц, т.е. со всей базы. Отсюда и такое увеличение размера базы.

(98) ссылка я дал, читайте.
Если "RESTORE DATABASE is terminating abnormally. Database ‘EnterpriseOnly’ cannot be started in this edition of SQL Server" для вас не является поводом сделать выводы - ждем ваших опытов.
У американцев не получается завести.
(62)"Если была включена компрессия, тебе сиквел сразу сообщит."
А кто-то вот не согласен :))

*ссылка выше, которуя я дал

*которую

(98)"и компрессия старых страниц останется. Новые страницы или измененные будут делаться без компрессии"
кстати, каким образом SQL будет чиать и сжатые, и несжатые данные одновременно, не имея такого функционала?

да походу дело не в компресси, атач бы тоже не прокатил в данном случае.
Вероятно в субботу кто то все таки что то в конфе менял.
Журнал регистрации посмотреть бы

больше интересно что за скрипты кто-то запускает в скулях о которых автор знает но сам не настраивал

Итого:
Состояние ДО пздца
<========================================>
Конфиг сервера(железный): 2x2,4 Ghz Xeon + 64 Gb оперативки + Raid10 из 15 килооборотных дисков.
Скуль - SQL 2008 R2 Enterprise
1С УПП 8,2
Размер базы - 402 409,00 МБ.
150 юзеров в пиках на терминалке(терминалка отдельно)
Переиндексация базы средствами SQL по ночам - полет нормальный. База растет, по 3-5 ГБ в месяц.
Тестирование и исправление базы средствами 1С запускалось последний раз 5 месяцев назад, заняло много времени (говорят, 2 суток) и вылетело с ошибкой. Больше не пробовали.
Попытка выгрузки базы в DT делалась 1 раз, завершилась с ошибкой.
Установка, настройка, конфигурация 1С и SQL осуществлялась внешним контрагентом с громким именем, и была принята бизнесом (с комментом "Нам же все сделали хорошо!")
Инстанса SQL Enterprise не сохранилось, поэтому, посмотреть настройки не получается. Последние данные о том инстансе - сохранившиеся результаты этого:
EXEC sp_configure 'show advanced option', '1'
go
RECONFIGURE
EXEC sp_configure
с боевой базы, положил здесь http://rghost.ru/53327915
<========================================>
Пздц произошел по следующим причинам и состоял из следующих операций:
1. Причина - планируемый рост числа пользователей до 200 + особенности лицензирования MSSQL.
2. Причина - Мозг рака(отсутствие достаточных компетенций по связке SQL+1C)
Не видя в нашй конфигурации железа и архитектуры БД особых преимуществ у SQL Enterprise, решили заменить его на SQL Standart,
с лицензиями "на процессор".
В такой последовательности:
Бэкап средствами MSSQL
Детач базы.
переустановка инстанса - теперь стоит MS SQL 2008 R2 Standart.
Аттач базы.
Плановая ночная переиндексация средствами MSSQL => объем базы увеличился до 1 Тб. Позже выяснилось, что переиндексация не завершилась полностью, просто за недостаточностью места.
Изменений в 1С между последней переиндексацией в среде SQL Enterprise и первой в среде SQL Standart программисты не делали.
<========================================>
Что делали:
Много тупили и спрашивали для начала. Потеряли время около 4 дней, в это время бизнес продолжал работать на террабайтной базе. Затем:
1. Сделали бэкап MSSQL уже террабайтной базы.
2. Восстановили этот бэкап в тестовую среду (Там тоже установлен SQL 2008 R2 Standart). После восстановления получили тот же террабайт.
3. Провели переиндексацию в тестовой среде. Результат - размер базы стал 1,4 террабайта. (тут скрин стандартного отчета о месте на диске - http://rghost.ru/53328173) Предположили, что переиндексаия на боевой базе завершалась не полностью (там на боевой места всего террабайт)
4. В очередной раз осознали, что ничего не понимаем. Включили эмпирический метод.
5. В тестовой среде попробовали сделать выгрузку в dt. Выгрузка прошла за 3 часа, файл dt получился 28 гигабайт. Чудо.
6. В тестовой среде попробовали сделать загрузку из dt, поменяв модель совместимости в базе на 2008 (стояла 2005 по невыясненной причине) Загрузка заняла примерно 7 часов, размер загруженной базы ~ 258 гб. Что меньше, чем было до Пздца.
7. Запустили переиндексацию полученного в тестовой среде. Размер базы после переиндексации увеличился, но незначительно: ~ 10 гб, итого 268 Гб.
9. Повторили процедуры, опробованные в тестовой среде, с боевой базой.
10. Результат - те же 268 гб. (тут скрин стандартного отчета о месте на диске - http://rghost.ru/53328182)
11. Запустили тестирование и исправление (со всеми пртичками) в тестовой среде. Ждем результатов уже сутки, пока думает.
Выводы.
<========================================>
Из настроек нового инстанса SQL сделали только max degree of parallelism=4 и поменяли совместимость в базе.
Что было сделано не так, и привело к какому росту базы - не понятно до сих пор. Ответы типа - потому что ты дурак - не в счет.
Я надеялся разобраться с причиной, а не с симптомами. Но причину - так и не нашел, и боюсь повторить данный факап.
Большое спасибо всем, кто участвовал и советовал! Ваши советы очень помогли решить проблему!

(105) Чудеса.

(105) Предположу, что это связано с изменением способа хранения строковых полей в таблице при смене модели совместимости. Особенно длинных строк. И/или с включенным vardecimal.

(105) файлы гигабайтные ни какие не пихали в базу 1С?
(107) у них что - строковые поля по мегабайту каждое?

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

(107) Я правильно понимаю, что вы имеете ввиду - при модели совместимости SQL2005 "длинные строчки" хранились как-то иначе, чем при модели совместимости с SQL2008?
Вроде, никаких предпосылок для появления "длинных строк" нет.

(106) Лучше б не было таких чудес)
По последней операции -
Тестирование и исправление со всеми птичками через 1,5 суток в тестовом инстансе вывалилось с ошибкой, о недостаточности памяти. 14 гб. оперативки не хватило.

По информции из (105) следует, что вы наступили на самые наступаемые грабли, на которые наступают все неспецы в ms sql. Похоже, что база в режиме восстановления full и своими бездумными реиндексациями вы раздували размер лога.
Достаточно было хотя бы на время реиндексации перевести базу в режим simple и не заниматься всякой херней типа выгрузки/загрузки, ТИИ и т.д. А может и не только на время.

(111) Вы продолжаете упорно топтаться на тех же граблях.

(111) Кстати, ваше ТИИ потому и идет так долго, что сервер вынужден много-много раз расширять файл лога, а сие есть не быстрая операция.

Может, вы неправильно поняли. Модель восстановления - simple, и тогда была, и сейчас есть, и фулл там не включали.
Или о какой вы модели?
Не горячитесь только.

(114) Может, вы неправильно поняли. Модель восстановления - simple, и тогда была, и сейчас есть, и фулл там не включали.
Или о какой вы модели?
Не горячитесь только.

(115) И сервер с Вами согласен? Чудес, как уже сообщалось, не бывает. Лог пухнет  только в модели фулл.

(117) Не может же такого быть, что сервер показывает в свойствах бд simple, а на самом деле там full...

(117) И, если вы обратите внимание на этот скрин,  http://rghost.ru/53328173
Там не только лог распух, но и данные.

(117) Гоню. Даже не лог, а индексы распухли, и данные.

А как вы делали "реиндексацию" на старом и на новом инстансах? С какими параметрами? Может такое быть, что на старом был rebuild с параметром sort_in_tempdb, а на новом тот же rebuild, но без этого параметра?

Или кто-нибудь указал fill factor отличный от дефолтного на новом инстансе?

(122) филл-фактор точно не меняли. =0.
(121) На старом не могу уже посмотреть. На новом - sort in tempdb выключен(галка не стоит)

(123) а полуторотеррабайтная база на тестовом сервере ещё осталась? было бы интересно посмотреть результаты выполнения скрипта из (79).
В принципе, если на старом инстансе sort_in_tempdb было включено, логично, что на новом база выросла. Правда настолько всё равно не должна бы.

(110) Да, возможны разные варианты хранения строк, когда они до определенной длины помещаются "по месту" в странице, а не в LOB область. В результате в страницах может оставаться неиспользуемое место, как будто установили fillfactor > 0. Это тоже можно настраивать и возможно настройка по умолчанию изменилась для 2008.

(125)и как варианты хранения строк могут удвоить размер базы?

(105)
1.непонятны режим базы сейчас какой на боевом сервере
100 или 90 ( и на тестовом )
2.может все отличия разные сервис паки стоят(ли) на разных
серверах
3.как бы не ясен общий размер дисковой системы ?
Может банально места не хватило а когда остается места мало
sql работает но ему как бы не до оптимальности.
как бы из-за этого и индексы не переформатировались
при этом остались и старые индексы и частично построенные новые

4 выполните все таки
EXEC sp_spaceused
и результаты сюда. после этого можно будет дать какой либо совет.

(127)"при этом остались и старые индексы и частично построенные новые "
это как это? )))

(124) Снесли после выгрузки в dt, теперь уже не посмотришь.
Я не могу въехать.
Если принять, что на старом sort_in_tempdb была включена, а на новом-выключена, и переезд -> рост базы,
Сейчас, на новом, по прежнему sort_in_tempdb выключена, но та же база ужалась до 268 гб.

(127) 1. Режим и на боевом и на тестовом - 100.
2. Различия конечно есть, - в одном случае обновленный Enterprise, во втором - Standart. Обновления одни и те же, разливаются на все инстансы примерно одновременно.
3. На боевом под боевую базу дисковая система 1 ТБ.
4. Большой базы уже нет, не смогу сделать

(129) при нормальной работе SQL Server в файле данных (mdf) всегда образуется свободное место - как внутри таблиц, так и просто внутри файла. Например, перестроили вы индекс, который частично лежит "между" двумя таблицами, а частично фиг знает где - sql server будет новый, перестроенный индекс укладывать так, чтобы все его страницы лежали рядышком - т.е. ему нужно будет найти свободный кусок достаточного размера внутри файла данных, либо, если такого не найдётся - увеличивать файл данных до тех пор, пока такой кусок не появится.
При загрузке из dt все объекты (таблицы, индексы) создаются заново и, соответственно, лежат наиболее компактно.
Возможно, sort_in_tempdb в данном случае не причём, хотя то что его использование приводит к тому, что в файле данных требуется дополнительное место - это факт.

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

(130) вообще, вам же сказали - расти больше не будет.
2. Покупайте новое СХД террабайт на 30.
3. Проблема не в SQL (там уже лет 20 проблем практически никаких, кроме косметических), а в связке с 1С.
Возможно, что-то "проиндексировали итоги" вы, что-то - изменилось во взаимодействии 1С и SQL (1С запросто может создавать гигабайты пустых таблиц, джа не "подозлевая" об этом).

*даже не "подозревая" об этом

(132) "1С запросто может создавать гигабайты пустых таблиц"
пруф или слив.

(134) пруф давай, что это не слив

(134) а вообщде, если не в теме про хранение в 1С - нечего вязаться к каждому слову. Или пруф давай.