Настройка SQL Server для работы с 1с 8.1 #418268

В бухгалтерской базе 1.6.15.5 которая размещена на SQL сервере долго проводятся документы. Сделал замер производительности оказалось что 90% времени выполняется операция Движения.Записать - 2-3 секунды записываются 3 проводки. Если эту же базу выгрузить в файловый вариант и проводить те же самые документы, на том же самом сервере на том же самом RAID то время записи уже измеряется миллисекундами, т.е. разница на порядки. В чем может быть проблема?

в неумении пользовать поиск

Движения по регистрам накопления быстро записываются?

все что нашел через поиск уже давно сделал ничего не помагает

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

Относительно регистров бухгалтерии быстрее. Но тоже гораздо дольше файловой версии.

Как переключить переключить базу в режим без логов?

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

Пробовал тоже самое. Что то на уровне SQL сервера

а ничего не сделаешь. На SQL будет заведомо в несколько раз медленнее, чем в файловой

в Managemen Studio. в русском скуле этот параметр называется "Модель восстановления"

ХА писал  на прошлой недели похожия ситуация ))) никто толком не тответил

выдай ка ты нам параметры железа SQL сервера

нашел ряд причин щас поделюсь яж не )) быдло

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

у меня Бух и ЗУП 8.1   в файловой проводилось  40 сек закрытие месяца в SQL 2005 стало 5 минут индексацию делал  тестирование делал , журнал и базы переносил на другой диск не помогло!  ни на 1 % сделал фрагментацию с перезагрузкой сервера , есть такая )) я о ней не знал ранбьше дало прирост докум закрытие стал проводиться  2 мин 45 сек

мысли устаканились по поводу тормазов SQL 2005 есть вариант поставить 2000 или Постгрис но в других фирмах по постгрису тоже тормаза были при начислении амортизации висело аж по часу))   либо переписывать всю базу  запросы и т д ,либо юзать последнюю 8.2.260 платформу   и наращивать железо , можно разедлить на 2 сервера если все на одном Сервер 1С и SQL

SQL на виртуальной машине 4 процессора памяти 4 Gb к ней подключен RAID10 довольно быстрый Гигабайтные базы копируются несколько секунд На производительность сервера не жалуемся при проведении он практически не загружен

2) переписывать все в базе 1С 3) разносить на 2 сервера 4) ретрансляция запросо в SQL  на Трансакт СКЛ  приводит к тормазам в 1С

SQL параллелит запросы .что вызывает медленное обработку их в 1С

и не хкуя тут не сделаешь больше )) в платформе файловой свой движок поэтому и летает все

именно регистр бухгалтерии именно на SQL именно при большом количестве записей именно задним числом тормозит. Что-то с реализацией не так. Может индексы очень тяжёлые перестраивать приходится. Может таблицы промежуточных итогов тяжёлые очень.

Сервера 1с и sql и так на разных серверах Ну не может sql работать в 10-100 раз медленнее чем в файловая версия ну согласен что может работать в 1.5 - 2 раза медленнее но не в 100 раз

я обычно наблюдал 3-5 раз разницу

у меня закрытие м-ца по времени примерно как полный бэкап базы... сервер 1С рестартуете регулярно?

ясно.. небось на VMWare бесплатном? переносите на обычную систему.. был опыт.. тормозит жутко не смотря на мощность сервера

У меня загрузка из периферийной базы в центральную за сутки не отработала, а в файловой версии меньше 2 часов

параметры в кластере 1С сервера поставь использовать много процессов AWE  в скуеле поставь  в параметрах сервера что еще сказать

1С сервер перезагружаем каждый день

щас с обеда приду будем вместе решать вопрос

AWE стоит SQL все 4 GB съел

еще раз говорю дело в виртуальной машине!!!

похожие тормоза , бухи жгут костры

а ну если на виртуальной машине стоит то понятно)

А какие проблемы с Виртуальной машиной?

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

ты лучше ответь _себе_ зачем именно Sql на виртуалку выносить...

переносите SQL в корневую систему и все будет замечательно!

да не работает бухгалтерия "замечательно" ни у кого на SQL у тебя точно бухгалтерия, а не торговля ?

Используем VMWare ESXi пробовали еще ESX 3.5 базы расположены на дисковой полке подключеной по FC База бухгалтерия это точно :)

точно :)

ну не может работать в 100 раз медленее Кстати файловая версия была расположена на том же самом виртуальном сервере

Сервер работает довольно шустро, это не первый наш виртуальный сервер.... 1С не может загрузить SQL сервер

думаю надо имено SQL сервер настроить

переключи базу в простой режим. переиндексируй, обнови статистику, сожми, дефрагментируй диск. что еще можно сказать..

В простой режим пока не пробовал. А все остальное делал спасибо попробую

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

на самом деле не сильно спасет отца русской демократии.. а какой у вас размер базы? сколько активных пользователей?

а пробывал с платформой 8.2? попробуй у меня просто щас нет возможности скачать

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

а что значит переключи базу в простой режим?

База в районе 3 GB если сохранить в dt то 300 мб, все операции которые я делаю - я делаю монопольно что бы исключить влияние других пользователей

и у меня в СКУле база 2 гига .а в файловом 240

службу 1С сервера давно перезапускали?

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

процессов 1С - 4 штуки

если процессы 1с не перезапускать они сами отвалются через 2-3 дня, но только пользователи ругаться будут :))))

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

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

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

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

преимущество одно - удобство администрирования

я на ноуте SQL  2005 развернул и сервер 1С кластер создал  поднял 1 процесс  ,занял 2 ядара проца  при выполнении запроса в 1С мой ноут загибался и грелся как печка))

основное преимущество: - распределение вычислительных ресурсов (захотели добавили SQL серверу производительности захотели убрали, передали ресурсы другому серверу) - если вдруг с физическим сервером что то случится 5 минут и мы перенесли образ сервера на другую машину и продолжаем работать

а mdf, ldf на другой машине валяются?

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

епти ну как не поймете , файловая  использует свой движок поэтому и летает SQL  распаралеливает запросы 1с обрабатывает их и снова возращает  1С поэтому тормоза

VMWare бесплатный это как?

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

вообще то "распаралеливает" подразумевает ускорение а не тормоза

По поводу распараллеливания я тоже не понял, т.к. у меня проблема только в записи данных, а чего там паралелить - вставить проводки и проапдейтить таблицы с остатками и оборотами. А выборка данных с SQL идет очень шустро кажется даже сложные отчеты быстрее строятся чем на файловой версии. У меня проблема только в записи данных

"VMware ESXi is the easiest way to get started with virtualization—and it’s free ..."

Да вроде проблем с производительностью на других серверах не наблюдается У нас много виртуальных серверов. Админы говорят что дали много ресурсов - даже 1с не может сервер загрузить. Реально при проведении SQL загружен 20-30%

а у тебя файловая и SQL версия не отличаются по скорости закрытия месяца ?

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

очередь записи на диск какая в perfmon?

Есть несколько простых действий по настройке SQL серверов, которые необходимо провести перед поиском узких мест: 1. Разнесение MDF и LDF на разные физические диски. 2. Отключение параллелизма. 3. Убедиться, что на сервере с SQL сервером не поднят терминал (это самое важное). 4. Базу TEMP рабить на несколько файлов, равное числу процессоров, и разложить по разным дискам. 5. Размер MDF и LDF сразу установить с запасом, чтобы не влазить в постоянный инкремент и фрагментацию. А уже после этого: 1. Отслеживать блокировки 2. Смотреть стандартные счетчики в PERFMON

а что такое "отключение параллелизьма" ?

Не знаю, какая у тебя версия SQL, но для 2000 - Entrprise Manager - клик првой по твоему инстансу SQL-сервера, закладка Processor - Parallelism - use 1 processor

хм. Какая странная настройка. И неужели с такой настройкой будет лучше ?

Безусловно. На пальцах: этот параметр говорит, что один текущий запрос может использовать только один процессор; другой запрос, который выполняется одновременно с первым, займет другой свободный процессор и т.д. (Это очень упрощенное обьяснение и спецов сразу прошу не придираться к буквам)

+ Забыл указать, что после клика правой по инстансу - Properties. Ну, надеюсь, это и так понятно.

+ В шедулер SQL каждую ночь: - обновление статистики. Для тебя проще всего - через DATABASE MAINTANCE PLANS.

Проблема решилась. Оказалась техническая проблема: в дисковой стойке села какая то батарейка и отключился кеш на запись. Теперь проводки записываются на порядок быстрее.

Интересно теперь замерить файловую версию, ведь она работала тоже на севшей батарейке :)