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


#0 by The_JOhn
Собственно тема такая: - Есть база 1с v8.1. на SQL 2000 c 4м сервиспаком - Размер базы 26 гигов - при создании новой перефирийной базы ее размер - 10 гигов что можно сделать для того, чтобы хотя бы на какое-то время центральная база приблизилась к подобным размерам? Заранее спасибо за ответы...
#1 by shuhard
лог транкануть
#2 by Vitorio
выгружай только то что касается новой базы, как вариант только документы этого склада или подразделения, зависит от того как у вас все ведется
#3 by The_JOhn
база в режиме simple так что лог особо смысла транкать нетути... посмотрел по структуре, много места занимают индексы, есть подозрение, что первый раз они создаются на момент запроса к нужным данным..., реально ли покилять содержимое индексных таблиц,если реально то как? не скажется ли это на работоспособности 1с вопрос в размере центральной базы,а не перефирии
#4 by ДенисЧ
полная переиндексация, потом сжатие базы данных с реорганизацией таблиц
#5 by Шляпентох
Индексы никогда не создаются сами по себе. Убирайте в конфигураторе ненужные индексы, если считаете, что таковые имеются, правда не доберетесь до тех которые 1С сама создает, но они вроде как вполне себе полезные. А зачем вам базу уменьшать, если не секрет?
#6 by EasyRider
10 ГБ - это новая пустая база?
#7 by МихаилМ
ну напишите программульку, которая сравнит размеры таблиц и  индексов. уже будет понятнее где аналицировать и какую программульку писать дальше.
#8 by EasyRider
Кстати,а DBCC SHRINKDATABASE не поможет? или SHRINKFILE
#9 by dragonIMV
у нас похожие проблемы...только база около 40 гигов, из них зачастую от 5 до 10 гигов пустые и можно было бы ужать базу, только она за сутки снова разрастается...
#10 by The_JOhn
- полная реиндексация средствами 1с иди sql? - у нас аналитический отдел любит отчеты бодяжить за последние 2-3 года, думаю, что некоторые индексы уже устарели и их можно прибить 10 - это новая перефирийная база, т.е. такая же, как и центральная по наполнению данными - база самописная, все индексы осмысленные и речь идет не о изменении конфигуратора, а о удалении данных из таблицы индексов - неа, не шринькается база... я еще ни разу не обжимал, хочу разок сделать, посмотреть что выйдет, а то не хватает места на бекапы уже, а новый диск покупать неохота...
#11 by dragonIMV
могу посоветовать удалить лишнии регистры, которые не используются... обнулить их и заблокировать по ним движения... хоть и геморно, но мне немного помогло это в УТшке этой здоровой...
#12 by ДенисЧ
SQL. Но это экви*но.
#13 by The_JOhn
иэх у нас самые большие таблицы по остаткам да продажам, их особо не заблокируешь...
#14 by The_JOhn
псб - запустил на попробовать
#15 by dragonIMV
а товары организаций есть? у меня он второй по размерам был после товары розницы, и не нужный оказался...вот его и убрал...
#16 by Megas
Шринк её... она там раздувается раза в 2... !
#17 by The_JOhn
не, только то, что продается, у нас самописка, причем уже вторая редакция, первая на 7ке была... пока что на переиндексирование запустил, шриньканье что-то эффекта не дает
#18 by dragonIMV
а своих регистров никаких нет?
#19 by The_JOhn
все регистры востребованы, мы же их под определенные отчеты писали... а те, что можно было бы удалить, те мало места занимают
#20 by Шляпентох
Зачем вы создаете себе проблему? Архивируйте бэкапы, храните их n-дней, купите дополнителный жесткий диск в конце концов. Уменьшите вы размер базы, а через месяц она снова вырастет (если уменьшите с помощью shrink'a, то скорее всего даже раньше) - снова будете уменьшать? Кстати, так и не понял ваше высказывание в . Что значит "индексы устарели"? Вы считаете, что некоторые индексы не используются?
#21 by Steelvan
Итоги пересчитывать пробовали?
#22 by dragonIMV
я про другое, вы уверены что ваши регистры оптимальные? а то я сам дурень тут громадный регистр сведений сделал неподумав... там и так строчек огромное количество, так я его сделал ещё периодичным, и некоторые ресурсы сделал реквизитами, хотя вполне можно было и ресурсами... в результате с 6-7 гигов регистр упал до 2 гигов...жаль только что больше улучшить нечего...
#23 by Steelvan
Выгрузи в файл - загрузи обратно. И итоги пересчитаешь, и индексы дефрагментируешь
#24 by The_JOhn
я считаю, что индексы ссылающиеся на 2000 год нафиг никому не нужны... да и вобще, создается ощущение, что 1С для убыстрения часто запрашиваемые данные кэширует где-то, а потом их не чистит в процессе.... да нет, все данные нужные, у нас просто товара много очень думаю об этом, ток боюсь это пару суток займет, база столько простаивать не может
#25 by Шляпентох
Разберитесь с тем что такое индексы, как они создаются и для чего нужны. Идея у вас весьма, кхм, странная..   1С данные не кэширует - это делает SQL Server. Чем, кстати, вам кэш не угодил? Думаете, что каждый раз считывая данные с жесткого диска улучшите производительность?
#26 by The_JOhn
вы нулевое сообщение читали? центральная база весит 26 гиг перефирийная, созданная с нее весит 10 гиг база самописная, мигрирует все... я хочу сделать центральную базу размером хотя бы 15 гиг и посмотреть, как она будет расти, с какой скоростью, после чего... а индексы - это одно из моих предположений... если есть идеи из-за чего еще может быть подобная разница в размере идентичных баз - подскажите, плз
#27 by The_JOhn
я хочу сделать центральную базу размером хотя бы 15 гиг и посмотреть, как она будет расти, с какой скоростью, после чего... я хочу сделать центральную базу размером хотя бы 15 гиг и посмотреть, как она будет расти, с какой скоростью, после чего принимать какие-то решения.
#28 by Шляпентох
Тут дело в чем.. 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'у, на самом деле, лучше знать сколько места ему нужно, поэтому лучше ему не мешать (:.
#29 by The_JOhn
т.е. выходит изначально база криво делается в плане фрагментации?
#30 by Steelvan
1С данные не кэширует - ай-яй-яй, не надо лохматить бабушку, еще как кэширует.
#31 by Steelvan
Запусти профайлер СКЛ, прочитай данные первый раз, потом второй и сравни запросы.
#32 by Шляпентох
Я не знаю какие механизмы используются создании переферийной базы и как туда переносятся данные. Но сильно сомневаюсь, что сначала копируется mdf файл, после чего сжимается). Ок. Пара минут.
#33 by Шляпентох
ВЫБРАТЬ ПЕРВЫЕ 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)
#34 by Шляпентох
Что я делаю не так?
#35 by The_JOhn
я вот тоже сильно сомневаюсь, поэтому предполагаю, что какие-то данные создаются уже в процессе работы с 1с, а раз в новой базе их нет, значит их можно безболезненно удалить
#36 by Steelvan
Форму документа (справочника) открой.
#37 by Steelvan
Дефрагментация может быть на уровне диска и на уровне данных. Сначала дефрагментируешь данные (перестроением или выгрузкой загрузкой), затем стопаешь сервак и дефрагментируешь диск. Без остановки сервака дефрагментирует данные Diskeeper.
#38 by Steelvan
Diskeeper на уровне диска.
#39 by Шляпентох
Запоминается ссылка на документ, номер и дата. Откройте после первого форму другого документа. И снова первый. Кстати, еще инетересный вопрос - это клиент ведь запоминает, да? Фрагментация, скорее всего вообще отсутствует. Страницы полностью заполнены и "прижаты" друг другу. Это имхо. Посмотрите про fillfactor. Просто в случае с рабочей базой - SQL Server не может сначала все данные переложить куда-нибудь, а потом спокойненько заполнить страницы данных. В то время как при создании новой базы - он знает точно сколько места ему потребуется и может все уложить максимально плотно (что, в принципе, тоже не есть хорошо).
#40 by Steelvan
Открой с разных клиентов. Если мне не изменяет память, запоминается все КРОМЕ ...ссылка на документ, номер и дата...
#41 by Steelvan
В течении вроде минуты...  не помню... доки поднять надо.
#42 by Шляпентох
В течении минуты - это зачетный кэш :-D. Кроме того, в автор как раз беспокоился, что он не чистится. А с другого клиента попробую, спасибо. А где конкретно про кэш написано? Проф. разработка?
#43 by Steelvan
Не, там нет. Вроде где-то на ИТС видел, или на их сайте.
#44 by Шляпентох
Ок. Вот, кстати, скрин: Открывал один и тот же документ. Прошло меньше минуты, но похоже кэширует исключительно клиент.
#45 by Steelvan
У тебя скорее всего все на одном компе, кеширует вроде сервак 1С (на случай если другой клиент обратиться или изменит данные - тогда надо их изменить и в кэше). Слушай, честно, не помню.
#46 by Шляпентох
К вопросу о кэше в теме про индексы :). Нет, больше ничего не нарыл, но то что на скрине - запускал с разных машин, плюс в базу заходил под одним и тем же пользователем.
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С

Back to top