Собственно вопрос встал после этого самого "обрезания" (пока тестовый режим).

Размер исходной БД 22 Гб (7.7, 5 лет инфы). Размер самых больших таблиц от 1,5 до 3,1 Гб (три остаточных регистра и один справочник на гиг).

После удаления 3х лет и шринкования удалось уменьшить размер до 11 Гб. НО после замеров оказалось что несмотря на то что размер топовых таблиц упал почти втрое (максимальная 1,2 та что была 3,1) скорость то не выросла (десяток секунд на отчетах по 20-30 минут - не выигрыш).

Чего делать ума не приложу. С скулем практически не общался никогда но видимо в отличии от файлового режима выигрыша тут я не добьюсь.

Да... БД не оптимизирована и не писана изначально под SQL (нет ни прямого обращения к таблицам ни хотябы "запросного" в объектах)

Аппаратная часть насколько я понимаю роли особо не играет но на всяк случай. Win2003 Ent 64x (AMD 2x2,6; SATA; 3 Gb RAM) + MS SQL 2005 ну и логи с данными на одном диске

Интересует вопрос не "ускорения" существующего а вообще смысл "архивирования" под SQL

PaulWist :) из бекапа ночного

есть ещё одна база там же и её размер 8 гиг... при попытке "выгрузить/загрузить" процесс идёт более 6 дней и пока что окончание я не дождался (то электрику вырубят то машину пригрузят) так что даже при успешном завершении загрузки время "неделя" неприемлимо

посему только бэкапы (средствами скл и бэкапера (МД и пользователей))

Да и чуть не забыл :) (жалко не могу отредактировать заголовочный пост) на SQL AWE включен и выделено 2,5 гиг максимум и 512 минимум... больше 1,92 гига оперативки не кушает а вот проц грузит на все 100

На базах автошринк отключен с журналами транзакций не работал так что там сказать не могу ничего

PaulWist, эээ а что есть "план обслуживания" в 7ке ? и как он повлияет на производительность (если речь идет о пакетном режиме то тут и неделю не проведёшь) ?

добавил вечером в maintenance plan к бекапировнию ещё и остальное что есть в визарде (кроме шринка) - отрабатывало полтора часа... перестроение индексов завалилось с ошибкой остальное вроде отработало

но на скорость никак не сказалось

неужелие "обрезание" SQL в 2 раза не даёт прирост производитльности вообще... или может техника у меня слабая да база маленькая ?

спасибо за помощь :)

авторВам еще многому нужно учиться по работе с "клюшками".

та да я не спорю опыта в админниньи скуля никакого

автор2. Какие рекомендуются параметры железа под 7.7 (подсказка - минимум 4 Гига оперативы, в вашем случае еще и поменять винты на SASовские, рейд только аппаратный, хороший бесперебойник на сервак, ...).

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

автор3. Как правильно создать скульную базу и распределить нагрузку (база и лог на физически разных дисках держать и т.д.. Все описывать нету смысла - сами почитаете).

это не сделано (з отсутствием аппаратной части) но на основном так и есть

авторКстати, после обрезки базы я надеюсь вы переиндексировали базу и пересчитали итоги?..

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

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

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

так вот речь идёт о том что по сравнению с файловым режимом пока получется что нет смысла проводить эту процедуру т.к. если в первом случе урезав вдвое производительость поднимется от четвертой до трети то в СКЛ нет прироста вообще

бекапы тут ни причем :) два винта по 640 Гб и вопрос решён на месяц... ради ускорения бекапирования за счет уменьшения размера самой базы смысла рвать период не вижу

авторПопробуй на копии запустить реиндексацию из конфигуратора.

под SQL смысла нет (индексировать нечего... он через пару секунд скажет что мол проиндексировал хотя не делал ничего) а выгружать в ДБФ и там это делать смысла то нет да и не сгенерю я 10 гиговую базу в файловом режиме на той технике что есть

вот ошибка в хистори

авторКод ошибки-1073548784
Текст сообщения

Executing the query "ALTER INDEX [PK_DH1790] ON [dbo].[DH1790] REBUILD WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = ON, ONLINE = ON )
" failed with the following error: "Online index operation cannot be performed for index 'PK_DH1790' because the index contains column 'SP1773' of data type text, ntext, image, varchar(max), nvarchar(max), varbinary(max) or xml. For non-clustered index the column could be an include column of the index, for clustered index it could be any column of the table. In case of drop_existing the column could be part of new or old index. The operation must be performed offline.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

сейчас гляну чья это таблица


Господа я ж не против что безалаберно писаное только свёрткой базы не вылечишь но "переезд" на ту же 8ку стоит большого количества времени а его понятное дело нет и насколько я понял владельцам это не интересно (психология "малых" фирм выросших из коротких штанишек но с психологией финансирования ИТ на том же уровне).

Зная по опыту как увеличивается прирост на файловых базах (опыт обрезания 5-7 гиговых баз до 1-2 благо есть и там показатели очень меняются) попробывал решить (вернее выгодать себе этот год чтоб переехать на что-то человеческое) эту проблему хотяб на время с минимальными затратами

В нете к сожалению инфы о целесообразности этой операции мало (вот в этой ветке подтверждение получил только вчера) посему и изыскания эти.

Вобщем спасибо всем участвовавшим и м ожно сделать необходимый вывод о том что смысла "обрезания/архивирования" периода для 1C SQL кроме как в целях уменьшения бэкапа просто нет .

:) вылечил ошибку с индексами - как и предполагалось - реквизит "строка" с неограниченой длинной был

langoliers,

авторА размер файла ldf, по сравнению с mdf, какой?

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

langoliersможет справляться (он-лайн транзакционной работой, 40-50 тис. строко-документов в день) с обемом базы 10-20 Гб, около 150 активных пользователей
речь о 7 ке ? или вообще не 1це ?

langoliers, да на тестовой копии которую делал для обрезания (восстановленной из бекапа основной) он чуть более гига а на той что резал (в свою очередь ещё одна копия копия ) после обрезания увеличился на полгига

модель full

авторв связке с 1С++ 2.0.3.7.

а вот ++ пока под 2003 64х запустить не получилось :(


ночью отработал на основном сервере план обслуживания 5ти баз (из возможностей отключал rebuild index и shrink модель бекапа полная) начало в 0-15 окончание 5-45 и память скушало всю

надеюсь сегодня побыстрее будет т.к. всё таки базы не обслуживались более года вообще насколько я понял