Тормоза SQL базы 1С... #310538

Доброго времени суток! Нужна помощь... Есть база 1С 7.7. Сейчас её размер перевалил за отметку 55 Гигабайт. Разумеется начались жуткие тормоза. На SQL-сервере появляются транзакции, которые сами себя блокируют. У одних данные рассчитываются быстро, у дргуих - очень долго. Висят на формировании отчётов. Есть ли какое-то решение данной проблемы? Срочно нужно выходить из положения, потому что сидеть и ждать 40 минут, пока сформируется отчёт - это издевательство над пользователями. Для справки: сейчас в базе работают одновременно 50 человек. Доступ организован через терминал.

Доброго времени суток! Нужна помощь... Есть база 1С 7.7. Сейчас её размер перевалил за отметку 55 Гигабайт. Разумеется начались жуткие тормоза. На SQL-сервере появляются транзакции, которые сами себя блокируют. У одних данные рассчитываются быстро, у дргуих - очень долго. Висят на формировании отчётов. Есть ли какое-то решение данной проблемы? Срочно нужно выходить из положения, потому что сидеть и ждать 40 минут, пока сформируется отчёт - это издевательство над пользователями. Для справки: сейчас в базе работают одновременно 50 человек. Доступ организован через терминал.

Оптимизация.

Попробовать создать индексы

Cap_1977: Делалась обрезка базы, регулярно производят Shrink логов и самой BD - это мало помогает. Иде я: создание индексов тоже не помогло.

файл базы и файл лога - на разные диски

Еще раз: - Оптимизация алгоритмов, кода - Мягкие блокировки или менеджер транзакций - Менять железо (особое внимани на контроллеры дисков/очереди к диску) -...

+ можно попробовать прямые запросы

Нанимайте программиста :)

Само собой, особеннов запросах ...

Программистов четыре человека - разводят руками.

О_О ... Ка-ак это !?

Может от этого полегчает?

Гибкие блокировки используются !? Прямые запросы в отчетах используются ?!

Обрежь на НГ по самое некуда.

реально помогает - рекомендую

Запросы в отчётах прямые. Попробую поставить патчик по ссылке romix. Может поможет, хотя не уверен. Потому что загрузка процессора максимум - 30%

Обрезать - нельзя. Потому что операторы обращаются постоянно к данным за прошлый год и таскают оттуда документы.

Не ну кто бы мог подумать в 1998 году что семёрка 55 гиг потянет!

Тогда посмотри в отчетах используется ли параметр (NOLOCK). Может быть имеет смысл поддерживать копию БД с актуальными итогами "минус" один день от текущего, а все отчеты переориентировать на эту базу ?

я такое делал, реплицировал базу на отдельный компьютер два раза в день

а диски какие?

Диски SCSI 8 штук по 146 Gb, в рейде, разумеется

город какой? Сюда смотрели?

Вообще то очень мало инфы по технологиям использующихся в конфе. Это плохо. А оптимизация она всегда нужна. Первым делом почитать раздел на ИТС..

А можно еще сюда посмотреть, если город не сильно далеко от Новосибирска:

От Новосибирска далековато...

Только 1С++ и прямые запросы!!

ещё раз говорю, что запросы и так прямые

MSSQL и терминал на разных компьютерах? можно еще попробовать из терминала вывести всех, кому скорость не так критична

Если есть прямые запросы, то не составит трудя тягать данные из базы-бабушки-прабабушки Я так делал при возвратах от покупателя... вся инфа содержится в итоге в возврате и он тупо проводится и все... более не вижу необходимости держать данные за 5 лет Если мега-отеты - лепи по ночам кубы и проч.

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

База большая, поэтому пришлось её поставить на терминальный сервер. Там же стоит и SQL. На предыдущем место исчерпалось, там остались другие быза. Если народ отключать от терминала, то работают они ещё медленнее...

perfmon что говорит? (кстати там есть счетчики блокировок SQL)

В общем купите сервер, позовите программистофф

не пора ли рубануть пару годиков в базе?

Что за конфа - не нашел. Судя по объему, это комплексная. Терминал и сиквельник разнесены? В профилях пользователей (тормозящих и нетормрзящих)различия есть? то же касается cfg в каталоге юзверя. типовые советы: сиквел и терминал на разные машины, запросы к регистрам и отчеты - на прямые запросы. Периодику (цены в частности) - тоже. Про бухкомпоненту не скажу - не юзал. Шринк базы, контроль размеров регистров остатков, реиндексация - выполняется? Обрезка периодики?

Ещё раз повторяю: Сервер вполне достойный: Proliant DL580R04 X3.2 Dual Core Sas (2xXeon7130M/4x1024mb/noSFFHDD/RAID2xGigNIC/DVD-CDRWnoFDD Память 3 x HP 4GB 400MHz DDR2 PC3200 Registered ECC SD Винчестер 8 x HP 146GB 10K SAS 2.5 Hot Plug Hard Drive Процессор 4 x Dual-Core Xeon 7130M (3.2GHz/8MB) for servers ML570/DL580 G4 Программистов целый штат... В сейчас лишь данные за период с июля 2006 по декабрь 2007 (актуальна дата, разумеется). В профилях юзверей различий нет. Все настроены одинаково с одинаковыми правами. Все запросы прямые. Шринк, реиндексация делается. Дефрагментация тоже. Разнести SQL от Сервера возможности нет. На другом серваке висят ещё 6 баз.

Терминал и сиквел на одной машине - почти смерть. ПОсмотри на счетчик обмена страниц с памятью (вообще все счетчики из статьи "7 главных счетчиков SQL"). Если наряду с терминальными подключениями будет хоть одно сетевое - будет работать со скоростью сетевого. А вообще, при таких объемах (если это не с 1998 года база) жлобиться на сервер - это моветон

+1, особенно фраза "почти смерть".

Т.е. 55 Гиг за полтора года? Если не секрет чо делаете? Что за конфига? Сколько строко-доков в день?

Да, за пол года. Контора занимается торговлей. Более 4000 сотрудников, около 900 торговых точек Более подробно сказать не могу - нельзя палиться:) Документов забивается дохрена - это когда уже сбиваешься со счёта.

а "дохрена" эт скоко? 400, 4000, 40000 в день? это важно знать + сколько строчек в документах (в среднем)

Конфигурация самописная.

+

Торговые точки - это типо розница? Важны продажи по каждому чеку, отслеживаете часы? УРБД? У нас тоже торговые точки, но там крутится своя конфига, я беру сводные даные в основную заливаю ночью Объемы, конечно, гораздо меньшие... если бы 900, то... страшно подумать...

Документов каждый день около 1000. В каждом, в среднем по 30 строк

Кстати, что за инфа в базе весит особенно много? Таблицы с чем?

Смешно. У мну стандартная торговля с документооборотом 1000 в день по 80 строк - весит 4.5 ГБ, до сих пор файловая вообще....

99.9% документов чисто символьные: накладные, отчёты, шаблоны, распределения, возвраты, перемещения, счета-фактуры, прейскуранты... В общем обычный набор.

+ ну почти стандартная. Метаданные изменились процентов на 5...

Документов каждый день около 1000. В каждом, в среднем по 30 строк Пипец! За полтора месяца при таком мизерном количестве (для такого объема) Вы не ту траву курите, курите программистов.

Странно другое, имея такие объемы и такой штат прогов пожалеть на приобретение сервака, чтобы разнести Терминал и MS SQL SErver? - или несколько терминалов; - или использовать несколько баз, одна для ввода первички , другие для тяжелых отчетов

ОТ этого не легче... Нужно дожить до Нового года. с 1 января предприятие пересаживается на 1С 8.1. Но то, что проблемы растут по геометрической прогрессии, наводит на мысль, что можно не дотянуть...

извиняюсь... за полтора года, но смысл моего поста не изменился

размеры таблиц можете запостить?

По документо-обороту. Это только во головному филиалу 1000 в день по 30 строк. Есть ещё по мимо нашего 25 филиалов, которые свои базы автообменом к нам раз в неделю пристыковывают... На предприятии всего 8 серверов, но все они задействованы. Деньги на ещё один не дадут - скажут, что зажрались.

тут дело не в 1с8.1 , а скорее в консерватории

какие именно размеры интересуют?

А зачем пересаживается? ПЛАТФОРМА ПРОБЛЕМ САМА ПО СЕБЕ НЕ РЕШАЕТ! Пригласите г-на Садовникова из Новосибирска - на 7.7 можно работать ЗЫ. Вообще-то смиялсо... сервак купить не могут, а все переделать на 8.1 - это ж сущие пустяки ешкин кот, падалута!

забавно, вы думаете , что если засадите на один сервак по V8.1 - сервер приложения V8.XX - MS SQL Server то будет работать быстрее , чем на "семерке" ?

Повторяю, таблицы с какой инфой в БД весят больше всех????

для восьмёрки новый сервак прислан. Решают наверху. Сеть по всей России переходит на единую платформу с января, так что это не обсуждается.

+100 нибываит, что-бы 8.х работала быстрее 7.7 + 1С++ это просто физически невозможно.

Будет отдельно интернет-сервер для подключений, терминальный сервер, SQL -сервер...

а ну если за вас наверху решают, то думаю советы вам бесполезно давать есть кому советовать

Проблема не в том, что она будет работать быстрее...А в том, что это решение руководства, совместо с компанией 1C. у них там договор.

Наверху такие же дятлы как и внизу, либо уже глазки заслюнявились на БМВ 645, купленную за откат :)

- вот пусть наверху еще договорятся с Рарусом например о нормальном внедрении 8.1... а то она через полгода сомостройки сдохнет

Да, но проблема внизу, а не наверху. Её здесь решать надо подручными средставми

Так, господа. Тут уже начались разговоры не по теме. БМВ - это другой пост....

Молитесь, осталось всего-то 14 рабочих дней...

знакомая ситуация, сам в свое время работал в очень большой структуре зае..... от полного идиотизма вышестоящих структур и свалил оттуда - также знакомо когда вышестоящее руководство договаривается за спиной IT-ков , а трах...ся потом IT-ки :) Пожелаю вам удачи в вашей нелегкой ситуации.

ПОДВОЖУ ИТОГИ более менее реальных предлагаемых решений: 1. Пропатчить 1С 2. Разнести SQL и Терминал (желательно не вдребезги:) Ещё что-то внятное кто подскажет?

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

*Айтишники

+ Пропатчить руки, моск :)

КонецЦикла: не в тему..., хотя некоторым очень хочется пропатчить...:)

- если уж очень "тяжелые" отчеты , кот. вешают базу , то лучше сделать базу для отчетов

если есть терминальный доступ - могу помочь. ICQ 169296011, ссылка на сайт , сотовый телефон 8-909-0544216 Павел

+1, мну чует, что там регистры топориком нарублены в зависимости от степени оволосения пяток...

Таблицы базы данных SQL, в которой эти 55 гигов лежат.

+ 77 - провести полный анализ производительности системы в плане выявления "узких мест" ("железо" и "софт") Думать, думать и еще раз думать. Ну а потом делать :)

Что особенно не даёт покоя, так это то, что тормоза начались после отметки в 39 Гигабайт. До этого всё было замечательно... Перетосовывание базы по серверам производительности не прибавило. На терминальном сервере работает максимально быстро, чем в других вариантах.

Ладно. Всем спасибо. Есть темы для размышлений, так что буду искать выход. Думаю, что больше координально нового никто не предложит...

"База большая, поэтому пришлось её поставить на терминальный сервер. Там же стоит и SQL" - сам назвал проблему. Слушайся MikeWare из . Никакой "Сервер вполне достойный" не поможет. Постоянный конфликт терминального и SQL сервера за ресурсы, особенно память. Каждый пытается захватить все. Постоянный своп гарантирован. Нужен очень грамотный сисадмин, чтобы это разрулить. Проще разнести на разное железо

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

Reaper 1c: К завтрашнему дню проаланизирую базу и выложу инфу, которая нужна...

ну еще "гибкие" блокировки можно порекомендовать , хорошая вещь Хотя , если за вас уже решили и вы с нового года перейдете на V8.1, то это вам не нужно. К сожаление вы влезете в такое гуано, из которого крайне сложно будет выпутаться. Жаль , что вы не можете выбирать.

Это и обидно. Сейас бросать все силы на оптимизацию того, что через две недели никому не надо будет...

А выгрузка данных(администрирование->ВЫГРУЗИТЬ данные) у вас работает? Мне вот что-то подсказывает что может работать на вашей базе :) Если да, то какой объем архива?

Убей незначащие регистры (и итоги, и движения) за прошлый год. И периодику за этот же период. И нули из итогов закрывшихся измерений регистров. (Естественно, перед этим сделай 20 копий и раздай всем). потом восстановишь ДТСом. И предупреди, чтоб в прошлый год не лазили. Две-три недели проживешь.

Работает. Но попробовать можно будет только в субботу. Потому что в остальное время в базе работают люди 24 часа в сутки...

Gepard: так и придётся сделать, если ничего другое не поможет

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

+1

koreav: пока живём бэкапами. Пытались как-то в cубботу выгрузить данные, но это слишком болго было по времени. Через 10 часов выгрузка так и не закончилась. Пришлось прервать...

А нафига выгрузка? Если что сколько ждать придется? Лучше уж сразу билет на самоль покупать пока не порвали попу...

Больше чем уверен что это косяк программеров, которые писали конфу. Что-то исправить уже сложно(и не нужно), т.к. есть ограничение в 48 часов простоя + очень близкая перспектива перехода на 8ку. Что-то конкретнее сказать можно только взглянув, как я уже и говорил, на размеры таблиц базы. Поэтому в самый оптимальный путь вашего Титаника.

ну я, не без основания, предположил, что база все-таки выгрузиться, хотя никак не должна (без еще одного патча от romix'а). Думаю, что основной объем занимают там данные которые в выгрузку не попадают. Т.к. набить 3гига данных в месяц т.ж. ппц - невозможно.