Вход | Регистрация


Форумы на Кубань.Ру


1С:Предприятие ::

Метки: 

1C SQL - туфта или реальная технология?

Ø
Я
   Sergey
11.09.00 - 10:20
В 1С7.7 конфигурация торговля возникли проблемы с производительностью (очень долго формируются отчеты). Было принято решение перейти на SQL технологию. Пререшли (SQL 7.0, sp2), проблемы остались. Трафик между запрашивающей отчет рабочей станцией и сервером нереально большой. Что можете подсказать, профи?
 
  Рекламное место пустует
   Dich
1 - 11.09.00 - 10:22
Отчет отчету разница, тем более в сиквельной версии. Подробнее, если можно - какие отчеты, какой механизм (запрос, бухзапрос или просто последовательный перебор субконто) и т.д.
   Sergey
2 - 11.09.00 - 10:24
Я сам не 1Сник. Например, формируется запрос на выборку товара по складам.
   Andrew
3 - 11.09.00 - 10:25
По отчетам 7.7 SQL работает быстрее dbf если там используются запросы, а так большей производительностью не пахнет. SQL более устойчив к сбоям. Если железо слабое, можно перейти на SQL 6.5, его можно ручками настроить и он шуршит гораздо быстрее 7.0. Проверял лично.
   HOS
4 - 11.09.00 - 10:40
2Sergey: Не надо ожидать от SQL - версии большей производительности, на том же железе, что и dbf... SQL очень прожерлив к ресурсам, но стабилен в работе с большими объемами данных, и если ты используешь какой-нить 233MMX в качестве сервака, то ничего хорошего у тебя не получиться.... Дык вот, если у тебя действительно перегружен трафик, значит енто именно твой случай...
С уважением, HOS
   Sergey
5 - 11.09.00 - 11:15
С ресурсами у меня все в порядке. Сервер - PIII500/256Mb и все такое... Существуют методы повышения производительность работы или мне вздохнуть и начать переходить на 100 Мб сеть?
   1С:Любитель
6 - 11.09.00 - 11:23
сервак: дуальная мама, пень3 500 мхц * 2, рам: 512, ибм скайзевый винч,
в сиквельной базе документ (большой довольно) проводится 55 секунд
в дбфной - 19 (это все на серваке и монопольно, разделенно, да по сетке,
да с какого нибудь "сраного" селерона гораздо дольше)
выход один - тсе, скорость работы на п-150 такая же,
как не серваке
   Sheridan
7 - 11.09.00 - 11:26
Переходить на 100 Мб. Кстати, непонятно почему, но при перепроведении документов в которых формируется запрос (например, на выборку партий) в SQL они перепроводятся раза в три медленней, чем в dbf версии.
   Andrew
8 - 11.09.00 - 11:28
А как у тебя с количеством юзеров? Если их много, то можно на серв поставить 2 сетевые карты и немного разгрузить сеть. Просто переход на 100 Мб много не даст. Нужен хороший Switch а не Hub. И слабые компы всеравно будут подтормаживать остальных.
   Птенец
9 - 11.09.00 - 12:42
Кстати, по поводу проведений в партиях - хто конкретно разбирался
с 1С-оптимизацией по SQL & DBF в комплексной: сервис->настройка
параметров конфигурации->торговый учет->вариант оптимизации партионного
учета?
   Sergey
10 - 11.09.00 - 12:46
...и отказаться от SQL нахрен! Я правильно понял?
 
  Рекламное место пустует
   Online
11 - 11.09.00 - 13:05
Реальная технология - это TSE, стоит попробовать и забудете о SQL как о страшном сне.
   Игорь
12 - 11.09.00 - 13:08
Может , кто действительно инфо сольет ..по SQL
 а то тенденция какая то грустная просматривается .. типа есть профи (типа Рарус), которые владеют информацией по 1CQL и активно на нем внедряют
..а что до остальных видимо подразумевается , что их задача существовать на других сегментах ..и не переходить на него.
Типа .. привет студентам МГИЭМА ..
   Olga
13 - 11.09.00 - 13:26
Такое ощущение, что у меня у одной успешный опыт перехода на SQL.
Все прекрасно, отчеты летают, документы проводятся гораздо быстрее, все довольны. Может быть я что-то не так делаю?
   Sergey
14 - 11.09.00 - 13:34
=Olga=
Ну так поделись тайной, как у тебя так получилось? Я в долгу не останусь.
=Online=
А вот на SQL я с терминал-технологии перешел. Слишком уж прожорлив оказался... Так что я о терминале пытаюсь забыть как о страшном сне...
   1C:Любитель
15 - 11.09.00 - 13:47
2Sergey: ну не знаю, спроси у г-на Козлова: что лучше сиквель или терминал
   Olga
16 - 11.09.00 - 13:52
Да ничего такого особенного я не делаю
1. Только бухгалтерия. Складывается впечатление, что реализация бух.компоненты под SQL лучше. Например, один и тот же отчет делаю с помощью обычного запроса и ВыполнитьЗапрос, результат может отличаеться на порядок. Специально проверяла.
2. Конфа своя напрочь, в модулях проведения расчетов по минимуму, все в форме, при проведении в основном только запись проводок.
3. Оптимизация. Все засовываем в один большой запрос. Здесь есть свои приколы, но если у тебя торговля, они тебе не помогут
5. Протокол NamedPipes поверх NetBEUI, сетка 100, трафик не напрягает, 2 свича
4. Сервер хороший ;)
   Olga
17 - 11.09.00 - 13:54
Да, кстати, пробовали ЗиК под SQL - отзывы как у большинства присутствующих
   leonid
18 - 11.09.00 - 14:09
Расскажите что такое NamedPipes протокол и постовляется ли он 95-х и 98-х?Спасибо.
   Mx
19 - 11.09.00 - 14:43
2 Olga
Да у вас нет _нормального_ опыта внедрения SQL раз вы сидите на NamedPipes, обязательно нужен TCP/IP ;-)
Для Всех:
SQL версия будет работать лучше ТОЛЬКО при большом числе пользователей, монопольный режим это для DBF (просто по сути). Отчеты в SQL формируются быстрее если ЗАПРОС соответствует языку запросов самого SQL.
А сравнение терминального режима с SQL зависит от количества пользователей и имеющегося железа. У меня есть варианты внедрения Терминал+SQL, но только из соображений надежности, а не скорости ;-)
   1С:Любитель
20 - 11.09.00 - 14:47
2Мх: чо значит болшое число ползователей?
   Andrew
21 - 11.09.00 - 14:58
Для Mx: Может мыльнешь мне свою конфигурацию железа для варианта Терминал+SQL. SQL юзаю уже год, но подозреваю, что его недостатки можно подлечить только симбиозом с Терминалом. С Терминалом не работал, поэтому буду признателен если просветишь.
   Olga
22 - 11.09.00 - 15:09
(19)Во-первых, не считаю себя спецам по сетям и протоколам, для этого у нас сисадмин есть.
Во-вторых, я неоднократно поднимала тему сравнения протоколов и ничего кроме высказываний типа "TCP/IP - рулез!" или наоборот не получила. Где цифры? Наш опыт показывает, что NetBEUI быстрее TCP/IP (хотя и менее надежен), а трафик не столь велик, как пугают.
На данный момент имею 2 базы под SQL, скоро 3-я подрастет ;) Это, конечно, не большой опыт, но почему-то успешный.
   Sergey
23 - 11.09.00 - 15:42
=Mx=
Да, ты конфигурацию железа для нормальной (с твоей точки зрения)работы терминал+SQL напиши. А то результат подобного внедрения на PIII500/256 меня абсолютно не удовлетворил (даже при 3-х пользователях!).
А вообще-то может и проблема у меня несколько в другом: при терминал технологии когда пользователь формирует отчет по товарам на складе проц уходит в 100% а остальные, естественно, ждут окончания обработки; при технологии SQL+терминал - то же самое. Может тут дело не в администраторе сети, а в администраторе 1С?
   Sergey
24 - 11.09.00 - 15:45
=1Cлюбитель=
А кто такой г-н Козлов?
   Dich
25 - 11.09.00 - 17:05
Люди, опомнитесь, в чем предмет спора? Платформа выбирается исходя из текущих задач. SQL предлагает НАДЕЖНОСТЬ хранения данных, не обещая повышения производительности, разве что ну на очень больших объемах данных, где файл-серверные версии просто заткнутся. Если вас беспокоит скорость отчетов - оптимизируйте, благо возможности язык Т_SQL предоставляет. Кстати, объект "Бухгалтерский запрос" и структура хранения итогов в 1С достаточно оптимизированы для повышения производительности, так что иногда даже свои прибамбасы работают медленее.
А что касается отчетов, в которых подключены функции итогов и др, так ему и положено работать медленно, т.к. все основано на использовании курсоров, которые сами понимаете, работу SQL сервера не ускоряют а совсем наоборот. Вы посмотрите SQl Profiler - там сплошные FETCH, FETCH, FETCH... Отсюда и сетевой траффик, потому что технология перебора данных, что в файл-серверной, что в сиквельной версии равноценны.
2 Sergey. А по ресурсам все же поставь 500mB ОЗУ, и дуальную маму.
2 Любитель. В проведении у тебя скорее всего производится расчет промежуточных итогов (сальдо либо обычные итоги) для каждой позиции документа. В таком случае да, проведение больших доков неоправданно долгое. Выход, по моему один - доставать итоги напрямую, минуя функции 1С.
Имхо: за универсальность приходится расплачиваться тормозами...
   Vasek
26 - 11.09.00 - 17:17
1С и SQL-это брак по расчету,причем неравный.
Отчеты под SQL будут работать быстро только в том случае,если написаны под SQL,оптимизированы SQL.А в нашем случае SQL используется как банк,обеспечивающий целостность данных,т.е. для хранения шкатулки с бирюльками используется здание с бронированными сейфами и охраной на всех периметрах,на содержание которых приходится выделять значительные средства.
Пример из собственной практики.С полгода назад начали работать с конторой-7 машин (две Р-100,пять Р-166),торговля 7.5-3 клиента+гл.бух и директор,бух 6.0-три клиента+ гл.бух и директор,сетка коаксиал.Жалобы на тормроза
Приняли еще буха,для нее взял Р-II-350/96Mb озу,винт IDE UDMA-66,из нее сделал сервер на NT4.На все машины поставил сет.карточки 100 Compex+свитч Compex,протокол NetBEUI,для каждой машины настроил пакеты.За основу взял Бух 7.7 добавил оперативный учет с одним регистром остатки товаров и четыре дока для менеджеров -приход,расход,списание,инвентаризация.На основании любого дока бух может сформировать свои документы.По опер.учету только движение товара и только по количеству,за остальным смотрят бухи.
И все,нет больше жалоб на тормоза,при том,что сервер используется и как клиентская машина с параллельными задачами.Товаров 2600 наименований,с справочнике клиентов 1800,документов по торговле правда немного 50-60 в день,не считая бухгалтерских (тех больше).
Так что делай выводы,если увере,что сделал все,чтобы сетка летала,тогда уже траться на железо (а то тут примеры приводят по железу,которое впору для сеток на 1000 клиентов0
   Dich
27 - 11.09.00 - 17:26
Не понимаю, почему такое отношение к надежности хранения данных. Наверное кому-то очень нравится репайрить ДБФ базу после каждого пропадания питания на клиенте, или просто его отвале. SQL хоть и бронированный сейф, но назвать базу данных работающего предприятия шкатулкой с бирюльками, это знаете ли...
А насчет TSE - подскажите, какие ресурсы мне нужны для работы 30 клиентов под TSE. А то может оказаться, что железа нужно в два раза больше.
И персонально для Ольги - у меня нормально юзается SQL на 25 клиентов на Named Pipes (sic!!!), и все путем, так что буду вторым.
   ANDREY_
28 - 11.09.00 - 18:38
Dich= Win2000 требует 64Mb-70Mb + по 20Mb-35Mb для каждого клиента (при условии, что под TSE будет вертеться толко 1С). "Мама" - чем круче, тем лучше. У меня дуальная мака PIII-550,RAM 256Mb, IDE UDMA-66/7200. Для 10 клиентов все "летает".
   Dich
29 - 11.09.00 - 18:46
2 ANDREW. Резюме: минимум 0.5 ГБ ОЗУ для моих 25 клиентов только для терминальных подключений. Нет уж, покорно благодарю. У меня тоже дуальная мамка, PIII-650, 512 RAM, 3x Ultra Wide SCSI 9.1 GB IBM (10000 rpm), но что будет, когда мы вырастем в два-три раза, а это не за горами? Сиквел и только сиквел спасет отца русской демократии.
Тем более что если кто-нибудь следил за эволюцией сиквел+1С, то заметил, что 7.7 более сиквельная, чем 7.5. В следующей версии сиквела будет еще больше, на что и надеюсь.
   Mx
30 - 11.09.00 - 21:06
Ух наговорили...
Попорядку
-1С:Любитель много это больше 15-ти
-Andrew сервер не мощный PII-500/Ram 256, но у меня написано,что не для скорости, а для надежности, да там и пользователей всего 5
-Olga на счет сравнения протоколов я тоже не мастак, но люди, которым я доверяю, рекомендуют ОРБИТ ;-)
-Sergey Для нормальной работы Терминал+SQL нужны два компьютера, и вообще терминал-серверов можно сделать несколько и пускай подключаются к одному SQL-серверу...
В общем и целом я согласен с Dich, кроме одного утверждения:
"Выход, по моему один - доставать итоги напрямую, минуя функции 1С" - дайте мне такого человека, который это сделал!!! У меня это не получилось по одной причине: при проведении к таблицам не подступиться, т.к. они заблокированы :-(
   Sergey
31 - 12.09.00 - 10:04
Люди! О чем вы поете?! Какая к черту надежность! При чем тут она!? SQL переводится как Язык Структуированных Запросов и предназначен для повышения быстродействия (изначально). Задача клиента организовать оптимизированный запрос, а задача сервера этот запрос обработать! А если получается, что 1С SQL в силу свей корявости не в состоянии создать правильный запрос на элементарную выборку из нескольких баз, то это вовсе не значит, что SQL технология не предназначена для, скажем так - быстродействия. Естественно, что плюсы 1С SQL проявятся в больших базах, потому как ДБФ заткнется, но такой подход грустен. По уму для SQL реализации 1С за глаза должно хватить и 10Мб сети для тех же 15-25 юзеров. Я вчера вечерком построил сеточку на интеловских картах 100 и что я вижу! 1С грузится ну очень быстро, а отчеты формируются так же медленно!
Короче, 1С не смогла реализовать SQL версию своего продукта, а то, что она ей называет, таковой не является. Бардак!... :(
   1С: НЕЛюбитель
32 - 12.09.00 - 10:15
1С SQL я бы назвал "игрушечной" технологией SQL. Версия 1С-SQL имеет такое же отношение к технологии SQL, как молоток к мобильной связи. От SQL есть только возможность хранения даных на сервере. Вот и все. А где, позвольте спросить руководство 1С, определяемые пользователем хранимые процедуры, функции, триггера, просмотры. Где возможность управления транзакциями, так как это сделано не в 1С, а в "нормальном" SQL-сервере? Так что, 1С, мягко говоря лукавит, а грубо говоря - врет, когда подсовывает вам коробочку с надписью "1СSQL". Не верьте ! От SQL там только запах :)
   CJNucloN
33 - 12.09.00 - 10:42
Да уж... Посмотрите на Tables в SQL базе. Что вы там видите? Правильно - все те же dbf файлы. А процедуры не смотрели? Посмотрите - много чего "интерестного" увидите...
 
 
   MishGan
34 - 12.09.00 - 10:45
В общем-то от этого никуда не деться. У 1С напрочь отсутсвует понятие серверной части. Поэтому выход один - работать напрямую с данными и итогами 1С, используя свои хранимые приороцедуры, т.е. как отметил Dich.
Mx это ограничение на блокировки легко обходится. Более того, для работы вовсе не обязательно использовать разделенный режим.
   Dich
35 - 12.09.00 - 10:54
Может, все таки начнем работать, а то швырять пометом в фирму, за счет которой мы кормимся, это немного неэтично. А если серьезно, то по порядку на вопросы:
31: По поводу надежности мы говорим не о языке SQL, а о программном продукте Microsoft SQL Server 7.0 (6.5).
32: Кто запрещает писать хранимые процедуры под себя? В моей базе определенной мною процедур порядка 30.
33: Предопределенные хранимые процедуры 1С действительно, только достают элементы по их ID. Правда, есть еще процы на подсчет сумм по реквизитам с признаком сортировки, и процы для записи проводок и итогов, что конечно капля в море. Но я думаю, что 1С в развитии останавливаться не собирается. Что касается тех же ДБФ файлов в SQL базе, то скажите пожалуйста, как вы еще сохраните преемственность данных и технологии обработки при смене платформ?
   Станислав
36 - 12.09.00 - 11:26
Народ а как убрать заставку в 1С 7.5 под SQL ?
   Dich
37 - 12.09.00 - 11:51
2 Mx. Присоединяюсь к MishGan, и дополняю, что таки да, функции АДО не фурычат ф модуле проведения, но вот используя мою любимую Rainbow Service можно вызывать хранимые процы и из модулей проведения доков, так что можешь посмотреть на этого человека...
   MIshGan
38 - 12.09.00 - 12:08
Dich, а с Rainbow работаешь? Интересно, а как rainbow удается получать доступ к таблице, если она заблокирована или открыта монопольно? Для меня это прямо загадка.
   Avia
39 - 12.09.00 - 12:36
Может повторюсь ... но "проект" Rainbow "стал действительно открытым, т.е. перешел в категорию Open Source". См. http://wildhare.virtualave.net/rainbow.shtml
   Mx
40 - 12.09.00 - 22:04
МУЖИКИ!!!
Дайте примеры работы Rainbow с SQL, а то у меня на то, чтобы простроить простой запрос по движению ушёл весь вечер, причем причина в недостаточном (для меня) описании функций Rainbow :-(
Наверняка на одни и те же грабли наступаем...
А вообще Rainbow действительно работает в монопольном режиме :о)
   БТР
41 - 13.09.00 - 00:01
Разумеется, Rainbow работает в монопольном режиме, потому что возвращает хандль сессии ODBC самой 1С, захватившей монопольно базу ли, таблицу (в разделенном режиме, но во время проведения)
   Dich
42 - 13.09.00 - 09:05
2 MX: Пример отмылил.
Тем кто обратился по мылу - отмылю в конце дня (извините, коллеги, у меня сегодня напряг).
   duk
43 - 13.09.00 - 10:16
Вчера у меня первый клиент с SQL. First Cut. Законнектился на наш сервер SQL8 (2000). А 1с не находит ODBC, (говорит, что нужна версия не старше 3.50 - это при наличии-то 3.52) Передергал ODBC по-всякому - нормально вроде шьет. Инсталлировал 1C-ODBC, который исчез в реестрах 2000 как во вселенной. Помогите, кто еще осчастливил себя этим гибридом - Win2000!
   MishGan
44 - 13.09.00 - 11:17
Dich, БТР, ну понятно - rainbow может работать в монопольном режиме, но если таблица за-lock-ена, то каким образом она работает с ней (и вообще работает ли)?
   БТР
45 - 13.09.00 - 23:09
Потому что ты получаешь ту же самую хандлю, которая и залочила таблицу.
   Кибальчиш
46 - 14.09.00 - 21:35
По топику:
Есть ещё один аспект. Не могу представить, для кого не актуален.
Пусть винты закриптованы PGP. Любой сливает базу на локальный винт, меняет пароли и выдирает любые данные.
Посему базу на ЦКЛ, для .MD и .USR - NTFS'ые расширения - read (хотя, вроде, точно не помню, сиквельный 1С изменения в .USR и параметрах доступа к ЦКЛ отслеживает согласовано, т.е. ручной рихт бесполезен), запущенный сеанс на серв и усё.
Для залома необходимо раскриптовывать параметры доступа. Это затраты другого порядка. И голова за секьюрность на этом участке не болит.
А как это будет выглядеть под TSE?
   Кибальчиш
47 - 14.09.00 - 21:41
Уточнение: пока на серве крутится копия и параметры доступа бесполезны.




Список тем форума

Форум Территория 1С

 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует