Ну  по убыванию   глянуть то 10  таблиц в БД.  навешивали УПО  на УПП. в результате  размер и так немаленькой БД почти удвоился.  размер увеличился сразу после обновления.  на тесте  почему то никто на размер БД не глянул :-(((

Так глянь средствами базы sql, что там ms? oracle ?

http://code.google.com/p/enterprise-integrator/downloads/list  вот эта штука умеет.

0.54 demo версия.

(0) в MS SMS правой кнопкой на базе, Reports и дальше сообразишь

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

sp_spaceused

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

http://infostart.ru/public/78049/

(4) спасибо   через реплортсы выяснил  что   увеличились почти вдове  все базы.   недавно правили обслуживание , не понимаю как оно могло так повлиять :-(

(8)
легко : шринк+ реструктуризация

(9)   а как исправитЬ?

(10)
не надо исправлять. лучше наборот- увеличить размер с запасом.

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

Это другая проблема. маловероятно, что она связана с размером БД.

кончно линейная скорость чтения-записи деградирует он начала к концу поверхеости диска в 1,5 раза.
но при  современных скоростях рейд- массивов это не имеет значения.

а вот дефрагментация дискового пространства может повлиять.

ошибки рейд-массива очень могут повлиять.

а размер не фрагментированой бд - маловероятно.

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

как так не должно вляить  база была 124 гига  стала 230  в одночасье
серевр постоянно стал чем то занят  диск лопатится и лопатится  сеть занята

(14)  не сочтите за хамство подскажите  где найти счетчики  я тольео по монитору  отслеживаю

(16)

http://www.sql.ru/articles/mssql/03121001perf_counters.shtml

(16) перфмон.
а подробнее - ищи на sql.ru статейку, типа "7 главных счетчиков", или типа того...

(16) монитор ресурсов

нифига. я сраниваю через репортс на sql копии месячной давности и живой бд  размер различен в двое  но процентное соотношение даты и индексов в целом сохранилось
т.е.  как в копии  около 75 проц даты  так и в рабочей  75 процентов  а размер различен вдвое

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

сравниваю топы  страниц   порядок кол0-ва записей  один а размер отличается вдвое

получается  что в двух базах  процентное соотношение распределения составляющих то же   размер удвоен а кол-во записей схоже.  получается что одна и та же таблица  выросла почти в двое без роста кол-ва записей    парадокс  я хз что это

получается  что вырос  объем именно данных!!!!!!  на всех бд  прописаных в обслуживании  при том же количестве записей!!!!!   помогите  я не понимаю что это такое.

сейчас пробую базу бухгалтерии как самую маленькую выгрузить и загрузить из файла. но джаже если прокатит для УПП  в 200 гигов это не вариант :-(  но можно попробовать понять что произошло если размер бухии сильно уменьшится

бух  размером 3.4 гига  выгрузил в dt   и загрузил  в чистую базу  получил базу размером  2.1 гиг.   что то лишнее там точно было  что делать с рабочей  базой  в 230 гигов я не знаю :-((((((((((((((((((((((((((

процент соотношения  даты и индексов  у 3.4 и 2.1   гигов  одинаковый.  т.е. как понимаю  были какие то пустые поля  которые  перегрузкой через dt почитстились  нужно то же самое  sql м как то сделать :-(   ПОМОГИТЕ