Размер SQL базы и как ее уменьшить? #440782

Собственно тема такая: - Есть база 1с v8.1. на SQL 2000 c 4м сервиспаком - Размер базы 26 гигов - при создании новой перефирийной базы ее размер - 10 гигов что можно сделать для того, чтобы хотя бы на какое-то время центральная база приблизилась к подобным размерам? Заранее спасибо за ответы...

лог транкануть

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

база в режиме simple так что лог особо смысла транкать нетути... посмотрел по структуре, много места занимают индексы, есть подозрение, что первый раз они создаются на момент запроса к нужным данным..., реально ли покилять содержимое индексных таблиц,если реально то как? не скажется ли это на работоспособности 1с вопрос в размере центральной базы,а не перефирии

полная переиндексация, потом сжатие базы данных с реорганизацией таблиц

Индексы никогда не создаются сами по себе. Убирайте в конфигураторе ненужные индексы, если считаете, что таковые имеются, правда не доберетесь до тех которые 1С сама создает, но они вроде как вполне себе полезные. А зачем вам базу уменьшать, если не секрет?

10 ГБ - это новая пустая база?

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

Кстати,а DBCC SHRINKDATABASE не поможет? или SHRINKFILE

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

- полная реиндексация средствами 1с иди sql? - у нас аналитический отдел любит отчеты бодяжить за последние 2-3 года, думаю, что некоторые индексы уже устарели и их можно прибить 10 - это новая перефирийная база, т.е. такая же, как и центральная по наполнению данными - база самописная, все индексы осмысленные и речь идет не о изменении конфигуратора, а о удалении данных из таблицы индексов - неа, не шринькается база... я еще ни разу не обжимал, хочу разок сделать, посмотреть что выйдет, а то не хватает места на бекапы уже, а новый диск покупать неохота...

могу посоветовать удалить лишнии регистры, которые не используются... обнулить их и заблокировать по ним движения... хоть и геморно, но мне немного помогло это в УТшке этой здоровой...

SQL. Но это экви*но.

иэх у нас самые большие таблицы по остаткам да продажам, их особо не заблокируешь...

псб - запустил на попробовать

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

Шринк её... она там раздувается раза в 2... !

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

а своих регистров никаких нет?

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

Зачем вы создаете себе проблему? Архивируйте бэкапы, храните их n-дней, купите дополнителный жесткий диск в конце концов. Уменьшите вы размер базы, а через месяц она снова вырастет (если уменьшите с помощью shrink'a, то скорее всего даже раньше) - снова будете уменьшать? Кстати, так и не понял ваше высказывание в . Что значит "индексы устарели"? Вы считаете, что некоторые индексы не используются?

Итоги пересчитывать пробовали?

я про другое, вы уверены что ваши регистры оптимальные? а то я сам дурень тут громадный регистр сведений сделал неподумав... там и так строчек огромное количество, так я его сделал ещё периодичным, и некоторые ресурсы сделал реквизитами, хотя вполне можно было и ресурсами... в результате с 6-7 гигов регистр упал до 2 гигов...жаль только что больше улучшить нечего...

Выгрузи в файл - загрузи обратно. И итоги пересчитаешь, и индексы дефрагментируешь

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

Разберитесь с тем что такое индексы, как они создаются и для чего нужны. Идея у вас весьма, кхм, странная..   1С данные не кэширует - это делает SQL Server. Чем, кстати, вам кэш не угодил? Думаете, что каждый раз считывая данные с жесткого диска улучшите производительность?

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

я хочу сделать центральную базу размером хотя бы 15 гиг и посмотреть, как она будет расти, с какой скоростью, после чего... я хочу сделать центральную базу размером хотя бы 15 гиг и посмотреть, как она будет расти, с какой скоростью, после чего принимать какие-то решения.

Тут дело в чем.. SQL Server "не приспособлен" для сохранения места на жестком диске. Чтобы уменьшить занимаемое пространство - пересчитайте итоги (у нас таблицы итогов уменьшились почти на 5 Гб), выполните последовательно: use [your database name] DBCC SHRINKFILE (mdf_logical_name, 0, notruncate) DBCC SHRINKFILE (mdf_logical_name, 0, truncateonly) База сожмется максимально. НО! Первая инструкция dbcc shrinkfile (с параметром notruncate) будет перемещать занятые страницы данных из конца файла данных в свободное место в начале, что неминуемо приведет к дичайшей фрагментации. После того как вы это обнаружите и проведете дефрагментацию - страницы снова "расползутся" по местам, так что выигрыша почти никакого вы не получите (смотрите ). SQL Server'у, на самом деле, лучше знать сколько места ему нужно, поэтому лучше ему не мешать (:.

т.е. выходит изначально база криво делается в плане фрагментации?

1С данные не кэширует - ай-яй-яй, не надо лохматить бабушку, еще как кэширует.

Запусти профайлер СКЛ, прочитай данные первый раз, потом второй и сравни запросы.

Я не знаю какие механизмы используются создании переферийной базы и как туда переносятся данные. Но сильно сомневаюсь, что сначала копируется mdf файл, после чего сжимается). Ок. Пара минут.

ВЫБРАТЬ ПЕРВЫЕ 1 * SELECT TOP 1 _InfoReg5994_Q_000_T_001._Period AS f_1, _InfoReg5994_Q_000_T_001._RecorderRRef AS f_2, _InfoReg5994_Q_000_T_001._LineNo AS f_3, _InfoReg5994_Q_000_T_001._Active AS f_4, _InfoReg5994_Q_000_T_001._Fld5995RRef AS f_5, _InfoReg5994_Q_000_T_001._Fld5996RRef AS f_6, _InfoReg5994_Q_000_T_001._Fld5997RRef AS f_7, _InfoReg5994_Q_000_T_001._Fld6046RRef AS f_8, _InfoReg5994_Q_000_T_001._Fld6537 AS f_9, _InfoReg5994_Q_000_T_001._Fld6936RRef AS f_10, _InfoReg5994_Q_000_T_001._Fld13512RRef AS f_11, _InfoReg5994_Q_000_T_001._Fld5998 AS f_12, _InfoReg5994_Q_000_T_001._Fld6047RRef AS f_13 FROM _InfoReg5994 _InfoReg5994_Q_000_T_001 WITH(NOLOCK) 2009-10-30 18:10:59 SELECT TOP 1 _InfoReg5994_Q_000_T_001._Period AS f_1, _InfoReg5994_Q_000_T_001._RecorderRRef AS f_2, _InfoReg5994_Q_000_T_001._LineNo AS f_3, _InfoReg5994_Q_000_T_001._Active AS f_4, _InfoReg5994_Q_000_T_001._Fld5995RRef AS f_5, _InfoReg5994_Q_000_T_001._Fld5996RRef AS f_6, _InfoReg5994_Q_000_T_001._Fld5997RRef AS f_7, _InfoReg5994_Q_000_T_001._Fld6046RRef AS f_8, _InfoReg5994_Q_000_T_001._Fld6537 AS f_9, _InfoReg5994_Q_000_T_001._Fld6936RRef AS f_10, _InfoReg5994_Q_000_T_001._Fld13512RRef AS f_11, _InfoReg5994_Q_000_T_001._Fld5998 AS f_12, _InfoReg5994_Q_000_T_001._Fld6047RRef AS f_13 FROM _InfoReg5994 _InfoReg5994_Q_000_T_001 WITH(NOLOCK)

Что я делаю не так?

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

Форму документа (справочника) открой.

Дефрагментация может быть на уровне диска и на уровне данных. Сначала дефрагментируешь данные (перестроением или выгрузкой загрузкой), затем стопаешь сервак и дефрагментируешь диск. Без остановки сервака дефрагментирует данные Diskeeper.

Diskeeper на уровне диска.

Запоминается ссылка на документ, номер и дата. Откройте после первого форму другого документа. И снова первый. Кстати, еще инетересный вопрос - это клиент ведь запоминает, да? Фрагментация, скорее всего вообще отсутствует. Страницы полностью заполнены и "прижаты" друг другу. Это имхо. Посмотрите про fillfactor. Просто в случае с рабочей базой - SQL Server не может сначала все данные переложить куда-нибудь, а потом спокойненько заполнить страницы данных. В то время как при создании новой базы - он знает точно сколько места ему потребуется и может все уложить максимально плотно (что, в принципе, тоже не есть хорошо).

Открой с разных клиентов. Если мне не изменяет память, запоминается все КРОМЕ ...ссылка на документ, номер и дата...

В течении вроде минуты...  не помню... доки поднять надо.

В течении минуты - это зачетный кэш :-D. Кроме того, в автор как раз беспокоился, что он не чистится. А с другого клиента попробую, спасибо. А где конкретно про кэш написано? Проф. разработка?

Не, там нет. Вроде где-то на ИТС видел, или на их сайте.

Ок. Вот, кстати, скрин: Открывал один и тот же документ. Прошло меньше минуты, но похоже кэширует исключительно клиент.

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

К вопросу о кэше в теме про индексы :). Нет, больше ничего не нарыл, но то что на скрине - запускал с разных машин, плюс в базу заходил под одним и тем же пользователем.