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

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

Метки: 

v7: Медлено работает 1C7 на SQL после DBF. Есть ли решение?

Я
   Sevnet
 
27.01.18 - 18:17
Перенес базу из DBF в SQL, одни и те же отчёты стали работать медленнее до 8 раз по времени, 19 сек, против 157 сек.
Пошерстил по интеру нашел вот это: http://catalog.mista.ru/public/82018/?detail=Y
всё выполнил.
Шерстил этот форум, проблема есть, решений нигде не нашел.

База весит 4Гб, планировал загружать товары от поставщиков по 200-300тыс наименований, для выгрузки в инт. магазин, поэтому заведемо перешел на SQL.

Конфиг:
Софт
Win Serv 2008R2 + Сервер терминалов
MSSQL 2008 R2. Режимы совместимости пробовал все 2000/2005/2008
1С 7.7 v27 Секретный релиз

Xeon E5-1650v4 6*3,6-4,2GHz
16Gb 2400 DDR4 ECC
SSD 200Gb Intel S3710 (один из топовых)

Задача №1 ускорить работу, №2 расширить базу до объёмов 20ГБ++

Вопрос: мне пытаться дальше мучать 1С 7.7 чтобы она заработала быстро на SQL, или это мертвая тема?
 
 
   mehfk
 
1 - 27.01.18 - 18:20
Надо переписывать все запросы на прямые, с использованием 1с++.
   mehfk
 
2 - 27.01.18 - 18:21
Даже не так, недо переписать все на прямые запросы.
   Фрэнки
 
3 - 27.01.18 - 18:25
отчеты точно надо переписывать
   Злопчинский
 
Ведущий
4 - 27.01.18 - 18:25
Слава богу в типовых 77 торговли такого кода совсем немного
   Злопчинский
 
Ведущий
5 - 27.01.18 - 18:26
(3) аналитические - может быть... А остальные юзаются раз в неделю
   Фрэнки
 
6 - 27.01.18 - 18:29
(5) топик перечитай - там нет упоминания чего-то "типового"
   Злопчинский
 
Ведущий
7 - 27.01.18 - 18:30
(6) ускорить работу - хз что там тормозит
   Злопчинский
 
Ведущий
8 - 27.01.18 - 18:33
У меня например база растёт потихоньку, но например, отчет по остаткам время формирования меняется вообще совсем никак. Ведомость по движениям - да, конечно дольше формируются разница но на то оно иивыборка движений - тут отиувеличения объёма вывода и времени - не уйдешь
   vde69
 
9 - 27.01.18 - 18:39
1. не надо ничего переписывать
2. нужно настроить SQL сервер для работы с 7.7, поищи рекомендации... как минимум нужно убрать параллелизм (до 1 потока)...
3. нужно настроить регламент SQL (как минимум обновление статистики)
4. нужно поискать где именно тормозит http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

когда все пункты пройдешь, тогда уже можно думать чего делать в самой 1с...
   Злопчинский
 
Ведущий
10 - 27.01.18 - 18:47
Ну например у меня с секретным релизом жутко тормозят чёрные запросы с вхождениями  в список
Но тут я не готов сказать бо скуль и релиз не я готовил, но то что работает крайне не оптимально - это мне хватило увидеть навыка, так и оставил
 
 Рекламное место пустует
   Franchiser
 
11 - 27.01.18 - 19:09
Не знаю, у меня всё отчеты на sql работают быстро (даже без использования прямых запросов), sql 2005, база 20+++ гб
   vcv
 
12 - 27.01.18 - 19:18
SQL в 7.7 работает крайне неоптимально и обогнать DBF в терминале не способен. Но восьмикратное замедление, это как-то перебор.
Займитесь сначала оптимизацией SQL: запретите параллелизм, установите разумное ограничение по памяти, вынесите tempdb на быстрый независимый диск. Если нет возможности убрать SQL на другой сервер, включите протокол SharedMemory и выключите все остальные. И так далее, поиск по инету рулит.
Попробуйте в 1С применить http://catalog.mista.ru/public/64620/ . Особенно помогает в дописанных отчётах, куда натолкали десяток-другой группировок.
   mehfk
 
13 - 27.01.18 - 19:20
(11) Все ВошедшиеВЗапрос используешь в запросах?
   vcv
 
14 - 27.01.18 - 19:33
(11) "Быстро" - понятие относительное. На быстродействие больше повлияет не размер базы, а сложность учёта, количество субконто/регистров/измерений... ПУБ будет тормозить гораздо сильнее Бух при одинаковом размере базы, количестве и активности пользователей.
   mishaPH
 
Модератор
15 - 27.01.18 - 20:07
(0) для начала проведи анализ тормозов.. банально замером производительности.

я много раз занимался ускорением без прямых запросов.

как правило это неоптимальное обращение к вложенным реквизитам. Например в цикле постоянно используется

СтавкаНДС = Запрос.Док.Номенклатура.ставка.

простейший разбор 
Док = Запрос.Док
Ном = Запрос.Док.Ном. А далее с переменными.

Кроме того очень долго обращение к периодическим реквизитам.

например ту же ставкуНДС номенклатуры получают при каждом обращении к строке. бывали циклы когда ставку НДС получали 80 тыс раз перебирая строки дока при том, что номенклатура в базе 100 позиций.

ставку получать 1раз, пихать в ТЗ и далее получать из тз..

КОроче там такого тюнинга очень много
   mishaPH
 
Модератор
16 - 27.01.18 - 20:09
главный тормоз это
1. множественное обращение к вложенным реквизитам порой через 4-5 "точек"
2. периодические реквизиты медленное получение.
3. в типовых обращение и поиск свойств КА и Товаров..

если все кешировать в память при первом обращении а далее использовать уже полученное, все можно вернуть почти к дбф версии.
   mishaPH
 
Модератор
17 - 27.01.18 - 20:13
Если прямые запросы. то есть комплект ТИСа у тойскл от Шемякина Павла. Я вот его бух отчетами стандартными пользуюсь. Мегабаза на 100 гигов с 80 юрлицами. работает очень быстро
   vde69
 
18 - 27.01.18 - 20:40
(16) еще все что связано с ЗиК... замечено, что ЗиК лучше вообще не переводить, или переводить с осторожностью...
   ИТ директор
 
19 - 27.01.18 - 20:42
(18) а у ТС ЗиК, да?
   ИТ директор
 
20 - 27.01.18 - 20:47
(0) а что dbf 200-300 тыс. наименований не понятнет?
   Sevnet
 
21 - 27.01.18 - 20:53
Спасибо за советы по оптимизации, но вопрос то не в этом.
Ок, я оптимизирую до идеала, а толку то, получу 6 сек в DBF против 48ми в SQL.
Проблема то не в этом, а том чтобы разобраться почему одно и то же работает с такой разницей в скорости на разных типах БД?

(12) у меня конфа самописная, отчёт о котором речь я писал сам, ничего лишнего в нём нет, он тяжел тем, что рассчитываются итоги на каждый день за месяц, для расчета среднего. Можно было бы перепились регистр, но не хочу, отчёт 1 раз в месяц крутиться. Собсно и в других отчётах тоже тормоза, на этом я просто посчитал разницу во времени.
(13) нет
(14) учёт сложный, вопрос в том что DBF на том же серваке работает в разы быстрее, чем SQL? это и надо исправить. (15),(16),(17),(18)   см. мой ответ на (14)
(19)  у меня конфа самописная,
(20) боюсь нарваться на проблемы из-за размера, плюс проблема частая с блокировками из-за автоматический проводок документов с несколькими тысячами строк, что занимает ощутимое время.
   ИТ директор
 
22 - 27.01.18 - 20:58
(21) думаешь на SQL не будет блокировок?

>>Проблема то не в этом, а том чтобы разобраться почему одно и то же работает с такой разницей в скорости на разных типах БД?

вопросу тыщу лет, была на кубани статья "почему SQL тормозит" про 7-ку...чувак как ты телепортировался из прошлого?
   ИТ директор
 
23 - 27.01.18 - 20:59
>>1С 7.7 v27 Секретный релиз

что за релиз? патченный штоли?
   Sevnet
 
24 - 27.01.18 - 21:09
(22) читал, но у меня в 8 раз разница в производительности в отчётах... в 1,5-2 раза будет норм.
(23) да, пропатченный, брал отсюда: http://catalog.mista.ru/public/82018/?detail=Y
   Sevnet
 
25 - 27.01.18 - 21:18
(23) на том же серваке, ту же базу, тем же ехешником запускаю на dbf и вуаля, всё летает.
   Sevnet
 
26 - 27.01.18 - 21:24
Ещё вопрос аудитории. Если я перейду на 8.3 в конфу УТ 11.3, она на SQL будет быстрее работать, чем DBF?
   vcv
 
27 - 27.01.18 - 21:35
>> разобраться почему одно и то же работает с такой 
>> разницей в скорости на разных типах БД?
В том то и дело, что "одно и то же". Не может быстро работать приложение, когда оно работает с SQL базой в том же стиле, что и с DBF. Ну никак не получится "крутить педали" на камазе так же, как на велосипеде. Не уедете никуда.
Попробуйте посмотреть профайлером, что делает в SQL 7.7 при формировании какого-нибудь отчёта. Вместо идеального варианта одного запроса с выводом данных на клиенте без обращения к базе вы увидите активность в несколько сотен, если не тысяч, мелких запросиков.
Формируется отчёт с выводом ваших 200-300 тысяч наименований номенклатуры. 1С выбирает из базы сначала остатки/движения по регистру с внутренними идентификаторами номенклатуры. Потом для каждого внутреннего идентификатора делает запрос к таблице номенклатуры, что бы получить по идентификатору наименование.
В случае DBF это нормально. Особенно, если индекс таблицы номенклатуры достаточно мал, что бы целиком закешироваться в памяти. Для SQL это катастрофа. Потому что для SQL каждый из этих 200-300 тысяч запросиков, это полноправный запрос. Для которого нужно проверить статистику. Проанализировать и, при необходимости, распараллелить. Проверить права на таблицы. В общем - дохрена чего сделать кроме, собственно, выборки данных из таблицы.
   Chameleon1980
 
28 - 27.01.18 - 21:36
(26) ИМХО - не надо тебе 11. Десятку бери.
   vcv
 
29 - 27.01.18 - 21:37
(26) 8.3 с DBF не работает, так что ваш запрос не имеет смысла. Или вы имеете в виду файловая или серверная? Если вы планируете размер базы 20++, то без вариантов. Только серверная.
   vcv
 
30 - 27.01.18 - 21:43
(28) Не хочется поднимать флейм, но смысл для НОВОГО внедрения брать продукт, который производитель фактически считает мёртвым? По результатам вдумчивого изучения функциональности конфигурации, анализа потребностей бизнеса с прикидкой возможного развития на ближайшие несколько лет такое делать можно. Но осторожно.
   ИТ директор
 
31 - 27.01.18 - 22:10
Тема жесть)))
   ИТ директор
 
32 - 27.01.18 - 22:11
*ветка
   mishaPH
 
Модератор
33 - 27.01.18 - 23:59
(18) ну ЗИК да.
 
 
   toypaul
 
34 - 28.01.18 - 09:03
(21) ты на СКЛ переходишь не для того чтобы у тебя отчет за 6 сек выполнялся, а чтобы база на 20 Гб не умерла.

так что забудь про простые ответы на сложные вопросы.

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

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

можно просто терпеть. ну проживешь 50-60 вместо 80-90
   toypaul
 
35 - 28.01.18 - 09:05
и да. отчет на СКЛ можно сделать чтобы он работал за 6 сек. только потратить на это можно много сил. а можно потратить не очень много сил, чтобы он выполнялся скажем 20 сек, вместо 150.

зато на СКЛ можно сделать так чтобы отчеты выполняющиеся на ДБФ минутами выполнялись за секунды.

а еще на СКЛ можно сделать чтобы документы параллельно проводились.
   opus70
 
36 - 28.01.18 - 11:37
100 раз уже писали вариантов всего два или юзай 1cpp++ (http://www.1cpp.ru/index.php/Main)
или если лень купи готовы библиотеку на тауSQL у павла сайт не помню

и ты поймешь как медлено у тебя все работало на dbf
   mishaPH
 
Модератор
37 - 28.01.18 - 11:43
(36) (35) народ сравнивает монопольную дбф версию со скулем. а как только в дбф влезло 3-4 человека и начало активно что-то делать. скорость сразу просаживается. я уж молчу про много юзеров и большую базу
   mishaPH
 
Модератор
38 - 28.01.18 - 11:44
а если дбф версия не на терминале а доступ по сети то вообще вешалка
   Aleksey
 
39 - 28.01.18 - 11:59
(36) Не знаю у меня 100+ юзверей в базе в файловой дбф на штатных механизмов. Все попытки перевода на скуль проваливались из-за скорости работы (записи).
Покупка библиотеки тауSQL ничего не дает. ТОчнее надо полностью отказываться от штатных механизмов на прямые запросы. А это по силе равносильно переходу на 8-ку. Вот только вместе с переходом у тебя и современная платформа и шанс найти специалистов которые завтра смогут в твоей нетленки работать и типовые бибилиотеки (БСП, БПО, БЭД). А вот с в случае "покупки тауSQL" ты навечно привязан к единственному специалисту, и других ты будешь долго и безрезультатно искать (посмотрю я на 1с-ника который сегодня согласиться в новой конторе  сопровождать 7-ку с тауSQL, если конечно ценник не будет в 3-4 раза выше рынка)
   vde69
 
40 - 28.01.18 - 13:16
(39) у меня 8 лет назад замечательно работало 40 активных и еще 80 изредка в типовой SQL2000 7.7, ни кто не жаловался...

размер базы в не зазаипованом бекапе был около 40 гигов

вообще, все штатно и без извращений....


мой опыт показывает, что как только ты идешь не штатной дорогой ты где-то выигрываешь а где-то серьезно теряешь, по этому все эти плюсы, компоненты, драйвера и прочее абсолютно от лукавого, разумеется есть исключения но вот только не надо предлагать прямые запросы как панацея на любой чих, а ведь именно это и делают уже много лет. И выросло поколение для которых инструмент определяет все, а проффи которые и без инструментов все могут к сожалению все меньше и меньше...
   opus70
 
41 - 28.01.18 - 13:28
(39) не знаю сколько раз пытался больше 20 юзверов в dbf  на 7.7 всегда были тормоза, sql + 1cpp или toySQL это лучший выбор для 7.7 ине надо меня убеждать что 8.хх будет быстрей, никогда не будет , с чем соглашусь так это с тем что 8.хх технологичней и больше плюшек (особенно в управляемом режиме web это нечто ему альтернативу трудно придумать)
   opus70
 
42 - 28.01.18 - 13:29
(39) один тот кошмар что несет в себе вечная индексация базы по 15 30 минут в dbf
   opus70
 
43 - 28.01.18 - 13:31
(39) купив у павла toysql  ты кпишь еще и отчеты и модули проведения работы на один два дня и все летает, да свои отчеты придется тоже переписать но это не так уж и сложно при наличии  хороших примеров
   Фрэнки
 
44 - 28.01.18 - 13:46
только что мне нравится в этом обсуждении - топикстартер ни слова не сказал на какой же все-таки конфигурации он работает. Назвал только платформу и все с увлечением принялись обсуждать кусочек сферического коня в вакууме.
   Злопчинский
 
Ведущий
45 - 28.01.18 - 14:02
В типовых 77 тис не надо работать задним числом и тогда все норм.
   mehfk
 
46 - 28.01.18 - 14:23
(44) ТС где-то говорил, что самописка. Вангую самописку на опер. учете.

(45) Правильно будет так:
"В типовых 77 тис не надо работать".
   Max_Prog
 
47 - 28.01.18 - 14:24
У меня ТиС на SQL2005 WinServ2008, работает лет 7.
Настройку тут брал
http://needhelp-1c.narod.ru/sql2005_1c.htm
Как показывает практика Скуль быстрее работает в отчетах, при выборе товара в документы.
НО при восстановлении последовательности на севере все в разы дольше чем в DBF. База большая в день больше 200 доков.
Решил выгрузкой в базу DBF, далее восстановление последовательности и загрузка на Скуль. Нужно только менять на сервере BkEnd Для загрузки и BkEnd Для работы (ну или бантиком автоматизировать).
   kiruha
 
48 - 28.01.18 - 14:37
(0)
В свое время переписал на прямые запросы - на старом железе и куче юзеров под нагрузкой отчеты выполнялись 1 сек максимум

Основные тормозящие отчеты спец перепишет за месяц.
Это дешевле перехода на 8.3 раз в 10
   toypaul
 
49 - 28.01.18 - 14:38
(39),(40) хорошие сказки на ночь про 40 активных юзеров на ДБФ и 100+ юзеров в базе на ДБФ ... ну-ну. еще скажите что все 40 из них фигачат отгрузки, а не заводят контрагентов с договорами.
 
 Рекламное место пустует
   toypaul
 
50 - 28.01.18 - 14:41
(39) Вот это "А это по силе равносильно переходу на 8-ку" все неправда. Одно дело дело когда ты все свои извращения на 7ке хочешь перетащить в УТ11. А другое когда ты устоявшуюся логику просто оптимизируешь. Это 2 большие разницы.

Почему люди до сих пор и сидят на 7.7. Причем большинство из них на 1С++ или ToySQL или чем-то подобном. Я не говорю что это хорошо. Просто это ОХРЕНЕТЬ какая работа переводить все свое добро нажитое годами на 8ку. Обычно это решается только усилием воли - выбросить все к чертям и пилить типовую с 0.
   toypaul
 
51 - 28.01.18 - 14:43
Я бы уже честно и сайт-то свой закрыл, но раз или в два в год кому-то хочется (ВСЕ ЕЩЕ, КАРЛ!) перевести свою 7ку с ДБФ на СКЛ.
   Aleksey
 
52 - 28.01.18 - 14:48
(49) да активно финачать. Не все 100+, а где то 80 менеджеров, остальные по мелочи, ну там разносят кассу, банк. ревизоры движения по товару смотрят и т.п
   Aleksey
 
53 - 28.01.18 - 14:53
в день до 8000+ документов, в среднем на круг 10 строк в каждом
   kiruha
 
54 - 28.01.18 - 14:55
(52)
Я вижу тему у вас 1Sqlite )))
1Sqlite Левое соединение по документу неопределенного вида
это и есть прямые запросы на ДБФ и на штатные механизмы слабо похоже
   mishaPH
 
Модератор
55 - 28.01.18 - 14:57
(52) (53) такое можно, если при проведении нет в модулях никаких расчетов чего либо.
Максимум все строго на ТА.
   toypaul
 
56 - 28.01.18 - 14:58
8000 доков на ДБФ в одной базе при 24ч рабочем дне это 5 доков в минуту. По 12 сек на документ...

Ну это можно сказать вероятный случай, но какой-то сильно сказочный.
   toypaul
 
57 - 28.01.18 - 15:00
Я и себе прям представляю как эти 80 менеджеров должны свои 100 документов за день ввести в таком режиме. Они там что у вас роботы что ль?
   Aleksey
 
58 - 28.01.18 - 15:00
(56) А что 24 часа, а что не 36 или 48?

А нас нормальный рабочий день с 9 до 18 + 1 час обеденный перерыв
Никто 24 часа в сутки не сидит не бъет.
В пике (если смотреть по ЖР) по 3-4 документа в секунду проводят
   Aleksey
 
59 - 28.01.18 - 15:01
(57) А я разве где то написал что 8000 реализаций?
   Aleksey
 
60 - 28.01.18 - 15:02
есть заявки, есть приходы, есть реализации и касса, есть еще куча более мелких документов (например документ рейс, или отчет водителя по рейсу)
   toypaul
 
61 - 28.01.18 - 15:03
(60) я щяз заплачу ... каких еще у вас там есть документов, которые ну вообще от словам СОВСЕМ не влияют на производительность системы?
   Max_Prog
 
62 - 28.01.18 - 15:04
(50) Полностью согласен! Переписать что написано годами на 8?
Нужен штат программистов, а главное время на отладку. А если сеть магазинов там работа встанет.
   toypaul
 
63 - 28.01.18 - 15:05
(58) так если рабочий день 8ч, ситуация становится еще более сказочной. я же пытался эту сказку хоть как-то к реальности привести, но видимо не получится.
   Aleksey
 
64 - 28.01.18 - 15:06
понятно что менеджер не звонит в оперзал и поддиктовку никто не забивает реализацию. Есть ввод на основании. Есть свои статусы (например если цена в заявка ниже определенного уровня, то такая заявку упадет в отчет руководителю на согласования, а не в оперзал, как готовая к отгрузки

Более того какая нагрузка на систему когда менежджер сидит в подборе? никакой

А вот когда на основании отчета водителя системе нужно сформировать 250 приходников по кассю... или сформировать одновременно 80 фактур... вот тогда и понимаешь на сколько важна скорость записи и что средняя температура по больнице тут никак не канает, потому что машина не будет ждать до 20 вечера, если она должна в 15 часов уехать
   kiruha
 
65 - 28.01.18 - 15:06
Если все расчеты на прямых запросах, то собственно запись 10 строк в 1С доли сек штатно занимает в один регистр

ну проблема с общим журналом для всех документов имеет место быть
   Max_Prog
 
66 - 28.01.18 - 15:08
(56) А если база распределенная и документы прилетают из других баз?
Все реально.
   toypaul
 
67 - 28.01.18 - 15:08
(66) ну только так. и никак иначе. но это нечестно :)
   Aleksey
 
68 - 28.01.18 - 15:08
(62) и изучить и переписать ВСЕ на прямые запросы быстрее?
Все отчеты, подборы, документы, которые "писались годами" и "прекрасно" работали на dbf на скуле работать будут с большим скрипом.
И тут вопрос что лучше писать с 0 на прямых запросах но на 7-ке или писать с нуля но на 8-ке. Какой вариант более перспективным?
Более того в случае с 8-кой у тебя хоть сообщество есть у которого спросить можно, какого хрена оно тормозит и что покрутить. А в случае прямых запросов ты где найдешь мамонтов, которые согласны за спасибо все грабли рассказать?
   toypaul
 
69 - 28.01.18 - 15:10
(68) ну. так ты перешел на 8ку?
   Aleksey
 
70 - 28.01.18 - 15:11
(69) меня и дбф устраивает. Сейчас вот нашел косяк со модом, переделал кое что и всё хорошо.
   kiruha
 
71 - 28.01.18 - 15:12
(68)
За 8 ку больше платят и работы больше, интереснее, карьеры больше
так что выбор очевиден
   Aleksey
 
72 - 28.01.18 - 15:12
(66) нет как раз в этом году последний филиал пересадили в единную базу
До этого (лет 10 назад) пытались создать единную базу на скуле куда стекаются все данные, но тупо по времени не успевала обмены проходить.
Ушли на мод с выборочными обменами (НСИ + межфилиальные перемещения). А елинную базу создали на 8-ки
   Aleksey
 
73 - 28.01.18 - 15:16
(65) все запросы штатные. Я прикручивал логи на модули проведения, там действительно все проводится за доли секунды. Вот если кто то задним числом пытается провести, то там да расчеты 10-15 секунд занимать. Но для нас работа задним числом больше нонсенс чем практика. Любыые изменения через документ (вычерки, клиент что-то не принял - возврат текущим числом, а ПФ уже учитывают структуру подчиненности и автоматом печатают за вычетом. Правка заявок - через ввод на основании и корректировка новой)
   Max_Prog
 
74 - 28.01.18 - 15:26
(72) Штатными средствами распределенных ИБ сложно (если много баз не реально по времени).
У меня текстовыми файлами все летит на сервер и обратно через почту.
   mexanik_96
 
75 - 28.01.18 - 15:50
(0) если вопрос в только "планировал загружать товары от поставщиков по 200-300тыс наименований" дак пиши в базу сразу и выборку делай для выгрузки тоже от туда
   mexanik_96
 
76 - 28.01.18 - 15:53
(9) п2 ну хз, ну поставишь один "поток"(на самом деле иам речь не о потоках в макс дигои паралилзм) ну и будут у тебя ио эвейтц постоянно. дальше что? автор метрики не привел что висит когда, где хз... будет что то ясное тогда и поговрить можно будет
   mexanik_96
 
77 - 28.01.18 - 16:01
(0) начни с монитора активности в сиквеле смотреть, ожидания, нагрузку, потом счетчики. например у тебя запрос может быть выбирает обороты за все года отсюда все поднимается в память потом сбрасывается на диск как вариант...
   Max_Prog
 
78 - 28.01.18 - 16:03
(76) Конечно все зависит чем базу нагружают отчетом, проведением документов или еще чем. Ведется запись или считывание информации? Исходя из этого и нужно копать.
(0) Скуль тупит по всему - я не верю.
   Aleksey
 
79 - 28.01.18 - 16:04
(75)  у меня тоже есть аналогичный справочник, куда я гружу прайсы поставщика (с ценами количеством).
При этом менеджер имеет возможность принимать заявки по этому справочнику (где он видит индивидуальные цены клиентов), автоматом загружаются фото при наличии (при загрузки тащатся с сайта поставщика)
Короче при количество элементов порядка 630 тысяч элементов дбф имеет размер в 450 метров.
Т.е. для дбф 200-300 тысяч это семечки по размеру. Т.е. будет порядка 200-300 мб.
   Aleksey
 
80 - 28.01.18 - 16:20
(54) А я и не говорил что у меня все без ВК. Я говорил про модули проведения и расчета.
Например у меня есть отчет который показывает текущую загрузку машины (в рублях, кг, в клиентах и т.п.) и в сравнении в средней за последние 3 месяца. Естественно я не считаю каждый раз данные за последние 3 месяца а храню их в SQlite таблицах. Т.е. к проведению и расчетам это никак не относится. Можно конечно зависит справочник и в 7-ке и хранить там, но я решил хранить во внешних таблицах
Еще на Sqlite у меня логи изменения документов (т.е. кто когда и что поменял в документах/справочниках)

Из 1С++ я юзаю ИТЗ ибо группировки для отчета проще формировать методом сгруппировать. Но опять таки это для внешних отчетов
Еще в некоторых отчетах Йоксель, чтобы "плюсики как в 8-ке"
Ну и Сканер, ФР - это тоже ВК

В частности та тема. (если ты прочел) тоже чисто для отчета и чисто для фана (ну просто хотелось эту задачу решить именно прямым запросом, чтобы всё летало). Т.е. к проведению и расчетам она не относится
   vde69
 
81 - 28.01.18 - 16:29
(49) 40 активных на ТИПОВОЙ SQL-2000  версии бухии
   mehfk
 
82 - 28.01.18 - 16:42
(51) Подожди, еще пара десятков постов и тебе начнут доказывать, что гибкие блокировки не нужны, и вообще покупатели у тебя ненастоящие :))))
   mehfk
 
83 - 28.01.18 - 16:46
(81) Честно говоря, использование прямых запросов на бух. учете не так эффективно как на опер.учете, в первую очередь из-за особенностей работы регистра бухгалтерии.
   Провинциальный 1сник
 
84 - 28.01.18 - 19:14
(83) С бухучетом и так проблем особых нет, на sql он хорошо работает через бухгалтерские запросы.
   Darych
 
85 - 28.01.18 - 19:22
(84) не ври.. переписывал для московской страховой под прямые
   mehfk
 
86 - 28.01.18 - 19:24
(84) Настолько "замечательно", что если стоит вопрос бух.учет переводить с dbf на sql или резать базу, режут базу.
   mishaPH
 
Модератор
87 - 28.01.18 - 19:25
(84) ага да типовая ОСВ по 41 счету в базе упрощенка с 30 юрлицами за месяц формировалась 10-15 минут. с той скл 15 -20 сек
   Провинциальный 1сник
 
88 - 28.01.18 - 19:39
(85) Ну не знаю. У нас одно время была семерочная база с 8 миллионами проводок - на sql отлично крутилась.
   Фрэнки
 
89 - 28.01.18 - 19:59
(88) если в базе крутится только то, что должнО крутиться и то, что мОжет крутиться быстро - проблем никаких.

Если вернуться к вопросу топикстартера - что-то у него в самопальной базе не хОчет крутиться внутри сиквела, а ему об этом так никто и не сказал.
   Ёпрст
 
90 - 28.01.18 - 21:09
(0) 4 гб в дбф это база ни о чем, можно было и не переводить
   Ёпрст
 
91 - 28.01.18 - 21:10
ну и почти любую базу, даже без вк можно заставить ездить
   Фрэнки
 
92 - 28.01.18 - 21:11
(90) // Задача №1 ускорить работу, №2 расширить базу до объёмов 20ГБ++
   Ёпрст
 
93 - 28.01.18 - 21:19
(92) Ну для начала, нужно было решить задача №0 - уменьшить размер базы в 2-5 раз. Уверен, там мусора больше, чем половина. И тогда, мот и на скуль не надо совсем.
   Sevnet
 
94 - 28.01.18 - 21:52
(44) писал я, самописная конфа у меня, не дал её один программер в 2006г когда я начинал бищнес, она была корявая и недописанная, но когда я это понял уже было не до перехода в другую.
   Злопчинский
 
Ведущий
95 - 28.01.18 - 22:08
(88) фигня какая, у меня на дбф крутилась база с под 16 млн проводов, норм.
Когда перестала влазить - года 4 назад купили скальный вариант
   Злопчинский
 
Ведущий
96 - 28.01.18 - 22:10
(93) угу. И регистров незакрытых. Поэтому и тормозит.
   Злопчинский
 
Ведущий
97 - 28.01.18 - 22:10
Тс для начала ужми базу на ИС обработка
Шишки для мартышки
   Ёпрст
 
98 - 28.01.18 - 22:21
(94) размер самого большого дбф файла огласите и его имя..ну и следующих пару в этом "рейтинге"
   Фрэнки
 
99 - 28.01.18 - 22:44
(97) обработка, насколько я помню, подразумевает те таблицы (скажем так) который ей известны, допустим, из типовых решений. Если решение нетиповое, то и результат использования обработки окажется нетиповым.
   Фрэнки
 
100 - 28.01.18 - 22:50
(94) я не против, а точнее, по топику еще догадался, что конфиг этот будет или полностью самописным или сильно переделанным и не похожим на типовые. Поэтому столь увлекательное обсуждение в этой ветке Вас может развлечь, но мало чем помочь. Надо смотреть саму базу - конфигурацию/структуру. Вот в (98) вопрос уже задан:

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

  1  2   

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