Добрый день! Посоветовали на 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С. Это, конечно, не выход.
Возможно, кто-то сталкивался с такой ситуацией? Возможно, есть какие-то лучшие практики, как вернуть базе ее размер?
Шринки пробовали делать - не помогло.

"Места катастрофически не хватает" - добавте диски в рэйд

" остановка.. очень вредит бизнесу" -
Вам к платным спецам

в softpoint.ru
   либо к Гилеву.

"размер базы стал 1 тб" - что увеличилось то??? mdf,ldf? Стандарный отчет по использованию места что показывает?

дайте ссылку на тему  ixbt

МихаилМ - диски в рейде.
Ссылка http://forum.ixbt.com/topic.cgi?id=7:42617-10#294
Heckfy - увеличился MDF.
Стандартный отчет показывает, что размер стал в 2 раза больше, и что данных там 60% и индексов 40%.
Данные просто так не появляются, думаю.

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

МихаилМ - я неправильно про диски понял. То есть, добавить дополнительных дисков в рейд - это прямое лечение симптомов, безусловно. Но это не поможет решить проблему. Завтра опять база в 2 раза вырастет. Думаю докопаться до причин, и исключить их на будущее.

>>Произвели замену SQL2008 на standart
не осилил... в чью светлую голову пришла мысль менять молноценный сиквел на стандарт?

*полноценный

ну а рост файла - можно попробовать сделать Шринк mdf, + как настроен Рост файла?

а, шринк делали уж

(6) + https://www.microsoft.com/sqlserver/2008/ru/ru/compare-std-ent.aspx

а лучше тут http://www.microsoft.com/sqlserver/ru/ru/product-info/compare.aspx#

Maxus43 - да, шринк делали.
"Светлая голова", к сожалению моя). Причина в особенностях лицензирования Enterprise и Standart.
рост файла настроен так:
mdf - 200 мб, рост не ограничен
ldf - 50 мб, рост ограничено до 2 ТБ.

(12) ну ты погляди в сравнениях - стандарт для больших систем это... нет приличного слова.
Реиндексацию средствами 1с можно сделать, но процесс долгий и в монопольном режиме

(0) вы бы хоть стандартный отчет "Использование дисковой памяти верхними таблицами" выложили. Желательно с базы до и после. чтоб понять какие таблицы разрослись, и за что они в 1С отвечают

(12) Maxus43 - такая разница в размерах файлов действительно может зависеть от смены версии SQL-сервера? Встречались подобные прецеденты?
Могу понять, что я что-то криво настроил, возможно, нарушил какую-то волшебную последовательность, но увеличить базу в 2 раза по причине именно различий в версиях...

(14) Сейчас сделаю!

(15) насчет роста файла и смены версии - сомневаюсь, а вот производительность упадёт - наверняка почти.
Скорее детач-атач был причиной. Таблицы смотри конечно

(17) не вижу ни одной причины, чтоб детач - атач был причиной роста базы. Обычно, когда <<База работает круглосуточно, остановка, даже кратковременная, очень вредит бизнесу.>> в момент переезда накатывают накопившееся изменения конфигурации т.к. есть свободное время и что-то едет...  возможно какая-нить таблица итогов распухла...

(18) я тоже не вижу, смущает только что на разные версии.
Ждём результатов по таблицам конкретным

настройки autogrow возможно стали другими...

в вообще, msdn тоже не помогает?

http://social.msdn.microsoft.com/Forums/sqlserver/en-US/e84b2504-355c-420a-bb55-040f9eaf42aa/rebuild-indexing-maintance-plan-growing-mdf?forum=sqldatabaseengine

(19) (14)
Результаты отчета до и после. Не смог тут прикрепить, положил сюда
http://rghost.ru/53198657

(21) я чисо не могу скачать, пишет я выиграл в викторину и понеслась...

(21)

кроме сервера , что-то еще поменялось

оличаются по колву записей таблица конфигурации (config) и настроек (files)

так, что Вы нас вводите в заблуждение.

+(23)

кроме того кол-во таблиц совпадает а список названий таблиц разный.

(21) Возможно раньше было включено сжатие таблиц и индексов, при переходе на Standart Edition оно, естествено, выключилось

(25) это что за свойство такое?

(21) У вас разрослись таблицы движений регистра накопления, таблицы значений субконто регистра бухгалтерии и некоторые таблицы движений регистра накопления. В базах число записей в таблицах config разное + в новой базе таблица configsave не пустая. Значит в между переносом были доработки конфигурации + реструктуризация, из-за чего вырос объем БД. Сравнивайте конфигурации до и после. С вероятностью 99.99% если в первоначальную базу загрузить вашу текущую конфигурацию и обновить, ее объем также увеличиться в 2 раза.

Вот пример таблиц движений регистров накоплений, где число записей не менялось. Некоторые таблицы практически не изменились в объеме, некоторые сильно выросли. Значит была реструктуризация... Первая колока - число записей, дальше данные и индексы в бд1 и бд2
dbo._AccumRg20502     518        152        312            696        792  
dbo._AccumRg20549     175        104        240            160        352  
dbo._AccumRg20572     731        472        776            656        1 040  
dbo._AccumRg20587     5 435        5 408        5 312            7 248        6 904  
dbo._AccumRg20608     9 655        2 120        2 040            15 448        12 512  
dbo._AccumRg20853     17 995        27 072        16 296            28 792        17 128  
dbo._AccumRg20875     18 962        37 512        18 304            37 928        18 088  
dbo._AccumRg20929     18 950        49 920        18 336            50 536        18 160

(24) (23) (25)  (27) Спасибо большое за участие)
Возможно, действительно ввожу вас в заблуждение. Простите, если так.
Таблица, которая "после" - она сделана "на сейчас".
Таблица, которая "до" выгружена сейчас из последней доступной копии базы, которая продолжает благополучно занимать ~ 400 гб.
Сразу,(именно в момент смены версии) мне не хватило сообразительности эти выгрузки сделать, и опираться на эти файлы сложно. Конфигурация после смены версии сервера, уже менялась, буквально вчера.
Но, последовательность:
1. Ночь с пятницы на субботу - регламентная переиндексация базы(в субботу программисты не работают, уверяют что не прикасались к базе) - объем 400 гб.
2. Ночь с субботы на воскресенье - детач, переустановка SQL, аттач. База весит 400 гб.
3. ночь с субботы на воскресенье. Плановая переиндексация базы, уже в новом инстансе. 1 ТБ.
Помню, ко то говорил, что "все лгут", но здесь очень похоже на правду.
Мы очень затупили, что не сделали попытки сразу исправить ситуацию, не хватило компетенций.
Будем восстанавливать бэкап, который был сделан непосредственно перед сменой инстанса, и тот, который первый после этой смены, выгружать оттуда таблицы и уже их сравнивать.
С другой стороны, судя по последнему комментарию, я правильно понимаю, что это все-таки проблема в конфигурации, а не в кривой настройке SQL? Ведь если бы дело было в SQL, то все таблицы выросли бы примерно одинаково.
Мы сейчас на тестовом стенде сделали выгрузку базы в dt, и пробуем восстановить базу с последующей переиндексацией. Посмотрим, что получится в результате.

(0)шринк базы + шринк файла должен вернуть размер
если нет значит ваше описание не соответствует действительности

(30) в (29)

(29) сделайте тестовую копию старой БД, которая 400ГБ. накатите на нее вашу текущую конфигурацию. дождитесь реструктуризации и обновите. После сравните размер БД. Если сильно вырастит - зовите программистов и показывайте.

к (31) при простой модели восстановления скажем так кратко

было что то похожее. причину так и не нашел. решил вопрос только выгрузкой в dt и загрузкой из него.  размер БД было 200 с лишним гигов  заняло более полсуток :-(

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

перед (30) желательно тии со всеми птичками

(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С - нечего вязаться к каждому слову. Или пруф давай.