1C SQL, wine@etersoft SQL , Selta (жуткие тормоза, помогите советом)

kerya33 · Сообщение **kerya33** » 30.01.2009 22:30

Djelf писал(а): ↑
06.01.2009 02:52
честно скажу, "я не в доли" в патче к dbeng32 и я не пробовал это решение, но вариант думаю все таки очень соблазнительный (я уже на прямых запросах под 1sqlite, поэтому мне это не подойдет).
Кстати если что-то удастся или не сложится пожалуйста не оставь нас в неведении

Не оставляю

После моих неудачных экспериментов с wine@etersoft, postgre и selta решил по совету Djelf попробовать dbeng32 от hogik и Advantage Database Server. Выгрузив почти 30Гб базу компонентой от romix'а, загрузил базу под ADS server на Linux, 1С оставил под виндой. Размер некоторых таблиц достигал 3Гб, но производительность при работе с журналами и списками стала на порядок выше, чем в selta. Работает не медленнее ms SQL 2000.
Установил 1С под wine@etersoft на ту же машину, что и ADS. Advantage Data Architect тоже из под wine@etersoft нормально видит и локальный сервер и удаленный (сервер в локальной сети так-же пробовол и под windows и под linux). 1C из под wine коннектится и к локальному и к к удаленному (через cifs) ресурсу. Но вот ошибку 7040 "File creation error" так и не смог победить. Подозреваю, что это из за того, что wine имеет ограниченную область видимости в linux, а ADS-у под линукс нужно зеркало расшареного ресурса в корне. Пока остановился на варианте: БД под ADS на Linux, 1С и теримнал сервер под виндой, терминальные клиенты - линуксовые. В боевых условиях еще ничего не пробовал.

aSteklov · Сообщение **aSteklov** » 31.01.2009 16:02

kerya33 писал(а): ↑
05.01.2009 21:23
В свое время при увеличении объема БД ушли от файл серверной к SQL версии. Теперь возвращать опять? Да и отзывов по работе с такими объемами 1С БД для DBEng32 я чего-то не нашел.

Не назад. Это тоже клиент-сервер, не файл-сервер. Просто язык запросов - не SQL, а остается xBase.

Вопрос в другом. Денежки. Стоит тот же Advantage где-то 3 тысячи долларов на 25 клиентских мест (не претендую на точность, но порядок цены - верен).

kerya33 · Сообщение **kerya33** » 01.02.2009 01:32

aSteklov писал(а): ↑
31.01.2009 16:02
Вопрос в другом. Денежки. Стоит тот же Advantage где-то 3 тысячи долларов на 25 клиентских мест (не претендую на точность, но порядок цены - верен).

Полностью согласен, но тестируя Advantage под Linux о денежках думал в последнюю очередь, думал о работоспособности связки 1С и ADS и о результатах возможной проверки контролирующими органами на предмет лицензирования ... В нашей провинции пока до этого не дошли, а дальше поживем - увидим.

DjSpike · Сообщение **DjSpike** » 09.02.2009 15:31

А кто нибудь в службу поддержки Etersoft обращался ??? Что там ответели ???

Я уже получил ответ. Все дело в баге http://bugs.etersoft.ru/show_bug.cgi?id=2800
Следим за развитием...

prof · Сообщение **prof** » 14.02.2009 03:02

DjSpike писал(а): ↑
09.02.2009 15:31
Я уже получил ответ. Все дело в баге http://bugs.etersoft.ru/show_bug.cgi?id=2800

Боюсь, что этот баг лишь следствие того о чём тут писали, а не причина.

DjSpike писал(а): ↑
09.02.2009 15:31
Следим за развитием...

Ну, в общем, больше ничего не остаётся...

WhiteNoise · Сообщение **WhiteNoise** » 20.02.2009 11:12

prof писал(а): ↑
14.02.2009 03:02
DjSpike писал(а): ↑
09.02.2009 15:31
Я уже получил ответ. Все дело в баге http://bugs.etersoft.ru/show_bug.cgi?id=2800
Боюсь, что этот баг лишь следствие того о чём тут писали, а не причина.

DjSpike писал(а): ↑
09.02.2009 15:31
Следим за развитием...
Ну, в общем, больше ничего не остаётся...

По многочисленным просьбам сейчас в SELTE делается так, что бы курсоры пересоздавались только при изменении таблиц, на основе которых этот курсор сделан. Если есть какие-то предложения, они будут учтены.
Версия с таким апгрейдом появится где-то в конце марта.

warlomak · Сообщение **warlomak** » 20.02.2009 15:57

WhiteNoise писал(а): ↑
20.02.2009 11:12
prof писал(а): ↑
14.02.2009 03:02
DjSpike писал(а): ↑
09.02.2009 15:31
Я уже получил ответ. Все дело в баге http://bugs.etersoft.ru/show_bug.cgi?id=2800
Боюсь, что этот баг лишь следствие того о чём тут писали, а не причина.

DjSpike писал(а): ↑
09.02.2009 15:31
Следим за развитием...
Ну, в общем, больше ничего не остаётся...

По многочисленным просьбам сейчас в SELTE делается так, что бы курсоры пересоздавались только при изменении таблиц, на основе которых этот курсор сделан. Если есть какие-то предложения, они будут учтены.
Версия с таким апгрейдом появится где-то в конце марта.

ну это уже интереснее... Когда можно попробовать бету и баги половить ?

WhiteNoise · Сообщение **WhiteNoise** » 20.02.2009 16:34

warlomak писал(а): ↑
20.02.2009 15:57
WhiteNoise писал(а): ↑
20.02.2009 11:12

По многочисленным просьбам сейчас в SELTE делается так, что бы курсоры пересоздавались только при изменении таблиц, на основе которых этот курсор сделан. Если есть какие-то предложения, они будут учтены.
Версия с таким апгрейдом появится где-то в конце марта.

ну это уже интереснее... Когда можно попробовать бету и баги половить ?

Недельки через три, я думаю. Если есть заинтересованность, я могу где-то через недели полторы выложить чего-нибудь уже работающее на тестирование.

prof · Сообщение **prof** » 21.02.2009 23:08

WhiteNoise писал(а): ↑
20.02.2009 16:34
Недельки через три, я думаю. Если есть заинтересованность, я могу где-то через недели полторы выложить чего-нибудь уже работающее на тестирование.

Приятно читать такие посты!

warlomak · Сообщение **warlomak** » 22.02.2009 16:02

prof писал(а): ↑
21.02.2009 23:08
WhiteNoise писал(а): ↑
20.02.2009 16:34
Недельки через три, я думаю. Если есть заинтересованность, я могу где-то через недели полторы выложить чего-нибудь уже работающее на тестирование.
Приятно читать такие посты!

Конечно есть !!! Просто очень мало выкладывается selta в current, отлавливание багов было бы гораздо быстрее ИМХО...

WhiteNoise · Сообщение **WhiteNoise** » 27.02.2009 11:22

warlomak писал(а): ↑
22.02.2009 16:02
Конечно есть !!! Просто очень мало выкладывается selta в current, отлавливание багов было бы гораздо быстрее ИМХО...

Идея состоит в том, что бы часто выкладывать новые версии (раз в два месяца), и в current не выкладывать новых версий и делать баг-фиксы. Не могу скахать, что это очень хорошо налажено. Но надо стремиться.
В результате этого появилась папочка unstable.
Куда и поместилась версия с новой работой динамических курсоров. (они не пересоздаются без изменения исходной таблицы)
ftp://updates.etersoft.ru/pub/Etersoft/SE....5.20090227.msi
Тут еще запуск/остановка переделаны. Это если что не установится.
Поглядите, например, как листается на большом количестве документов.
Буду рад, если отпишитесь.

Djelf · Сообщение **Djelf** » 27.02.2009 14:40

WhiteNoise писал(а): ↑
27.02.2009 11:22
ftp://updates.etersoft.ru/pub/Etersoft/SE....5.20090227.msi

Листается в журналах хорошо, но серьезно проверить не удается. Постоянно вылетает

База не загружается из архива - вылет по ошибке selta.dll, в справочниках по mfc42.dll или msvcrt.dll, в отчетах иногда вообще без сообщений. На selta 1.0.5 база загрузилась и не вылетает.
winxp sp3, pgsql 8.3.6, selta selta-1.0.5.20090227

WhiteNoise · Сообщение **WhiteNoise** » 27.02.2009 15:42

Djelf писал(а): ↑
27.02.2009 14:40
WhiteNoise писал(а): ↑
27.02.2009 11:22
ftp://updates.etersoft.ru/pub/Etersoft/SE....5.20090227.msi

Листается в журналах хорошо, но серьезно проверить не удается. Постоянно вылетает База не загружается из архива - вылет по ошибке selta.dll, в справочниках по mfc42.dll или msvcrt.dll, в отчетах иногда вообще без сообщений. На selta 1.0.5 база загрузилась и не вылетает.
winxp sp3, pgsql 8.3.6, selta selta-1.0.5.20090227

Погляжу, чего-то не замечал такого.

prof · Сообщение **prof** » 03.03.2009 18:28

Djelf писал(а): ↑
27.02.2009 14:40
База не загружается из архива

+1 Гарантировано вылетает.

Код: Выделить всё

wine: Unhandled page fault on write access to 0x00000000 at address 0x68a01716 (thread 0024), starting debugger...
WineDbg starting on pid 0023
Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x68a01716).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:68a01716 ESP:0033d048 EBP:0033d060 EFLAGS:00210202(   - 00      - -RI1)
 EAX:0033d0f8 EBX:010d0c70 ECX:00000000 EDX:00000000
 ESI:010d0c70 EDI:0000008f
Stack dump:
0x0033d048:  0015f900 68a3b261 0033e128 0033d0f8
0x0033d058:  00000000 0033d4f8 0033d9b0 68a0d7f7
0x0033d068:  010d0c70 0033d0f8 00000001 68a576d0
0x0033d078:  68a576b0 68a576b0 61cee660 68a3b517
0x0033d088:  000000d0 00000000 00000000 010d2fe0
0x0033d098:  010d2440 68a022c6 0033d524 68a576f0
Backtrace:
=>1 0x68a01716 in selta (+0x1716) (0x0033d060)
  2 0x68a0d7f7 in selta (+0xd7f7) (0x0033d9b0)
  3 0x68a0dffb in selta (+0xdffb) (0x0033da20)
  4 0x6b75450e in psqlodbc35wselta (+0x5450e) (0x0033e090)
  5 0x1f7b9c30 in odbc32 (+0x9c30) (0x0033e0b0)
  6 0x1f7cd99c in odbc32 (+0x1d99c) (0x0033e0d4)
  7 0x201cc9ea in bkend (+0x1cc9ea) (0x0033e134)
  8 0x200dd259 in bkend (+0xdd259) (0x0033e450)
  9 0x290ebb29 in config (+0xebb29) (0x0033ea4c)
  10 0x290ce057 in config (+0xce057) (0x0033ead0)
  11 0x5f4022ae in mfc42 (+0x22ae) (0x0033eb00)
  12 0x5f408fc5 in mfc42 (+0x8fc5) (0x0033eb24)
  13 0x5f402976 in mfc42 (+0x2976) (0x0033eb74)
  14 0x5f401dcc in mfc42 (+0x1dcc) (0x0033ebf4)
  15 0x5f401cea in mfc42 (+0x1cea) (0x0033ec14)
  16 0x5f401c73 in mfc42 (+0x1c73) (0x0033ec74)
  17 0x5f401bfb in mfc42 (+0x1bfb) (0x0033ec90)
  18 0x5f401bba in mfc42 (+0x1bba) (0x0033ecbc)
  19 0x7eac3aaa WINPROC_wrapper+0x1a() in user32 (0x0033ecec)
  20 0x7eac4130 WINPROC_wrapper+0x6a0() in user32 (0x0033ed2c)
  21 0x7eac80a1 in user32 (+0xb80a1) (0x0033f3cc)
  22 0x7eaca564 in user32 (+0xba564) (0x0033f40c)
  23 0x7ea8a5c9 in user32 (+0x7a5c9) (0x0033f46c)
  24 0x7ea8d89e in user32 (+0x7d89e) (0x0033f4cc)
  25 0x7ea8dd6a SendMessageW+0x4a() in user32 (0x0033f50c)
  26 0x7ea33af8 in user32 (+0x23af8) (0x0033f5dc)
  27 0x7ea35052 in user32 (+0x25052) (0x0033f5fc)
  28 0x7eac3aaa WINPROC_wrapper+0x1a() in user32 (0x0033f62c)
  29 0x7eac4130 WINPROC_wrapper+0x6a0() in user32 (0x0033f66c)
  30 0x7eaca4d6 in user32 (+0xba4d6) (0x0033f6ac)
  31 0x7ea89eaf DispatchMessageW+0x9f() in user32 (0x0033f6ec)
  32 0x7ea5526a IsDialogMessageW+0xaa() in user32 (0x0033f84c)
  33 0x7ea89c48 IsDialogMessageA+0x68() in user32 (0x0033f88c)
  34 0x5f41690f in mfc42 (+0x1690f) (0x0043611c)
  35 0x00000202 (0x00030098)
  36 0x00000000 (0x00000000)
0x68a01716: movb        $0x0,0x0(%edx)

Djelf · Сообщение **Djelf** » 03.03.2009 19:09

prof писал(а): ↑
03.03.2009 18:28
+1 Гарантировано вылетает.

В багах уже подтверждено: http://bugs.etersoft.ru/show_bug.cgi?id=3516
Сидим, курим, ждем

WhiteNoise · Сообщение **WhiteNoise** » 11.03.2009 11:44

Djelf писал(а): ↑
03.03.2009 19:09
prof писал(а): ↑
03.03.2009 18:28
+1 Гарантировано вылетает.

В багах уже подтверждено: http://bugs.etersoft.ru/show_bug.cgi?id=3516
Сидим, курим, ждем

Ну второе пришествие состоялось

. Сделал с помощью триггеров. Посмотрите их, может у вас по этому поводу думки получше есть.
Лежит тамже:
ftp://updates.etersoft.ru/pub/Etersoft/SE....5.20090311.msi

Djelf · Сообщение **Djelf** » 11.03.2009 15:25

WhiteNoise писал(а): ↑
11.03.2009 11:44
Ну второе пришествие состоялось . Сделал с помощью триггеров. Посмотрите их, может у вас по этому поводу думки получше есть.
Лежит тамже:
ftp://updates.etersoft.ru/pub/Etersoft/SE....5.20090311.msi

Русская версия selta почему ругается на "Доступ из одного каталога", на seltaEng-1.0.5.20090311.msi удалось загрузить и запустить базу ТИС(Демо).
Вылеты в справочниках остались, но какие то нестабильные, может и через минуту вылететь, а может и 10 продержаться... попробую поймать, как воспроизводить гарантийно.
Журналом/справочникам очень сильно полегчало при работе курсорными клавишами, но еще остались ощутимые подергивания при PgUp/PgDown и таскании ползунка мышью.
Скорость проведения упала на 10% (что-то многовато). Думаю, зря триггеры установлены на регистры - основные тормоза в экранных формах, а там только справочники и журнал. IMHO только на них и надо вешать триггеры, и волки сыты будут и овцы целы.
Вопрос: что произойдет при повторном чтении строки из курсора, если его не пересоздавать и если данные в этой строке поменялись. Будут старые данные или postgres все таки выведет новые? Как бы это проверить...

P.S. удалось загрузить и на русской версии. ТиС попросила открыть период и после "Ок" вылетела, но период открыть успела.

WhiteNoise · Сообщение **WhiteNoise** » 11.03.2009 17:53

Djelf писал(а): ↑
11.03.2009 15:25
WhiteNoise писал(а): ↑
11.03.2009 11:44
Ну второе пришествие состоялось . Сделал с помощью триггеров. Посмотрите их, может у вас по этому поводу думки получше есть.
Лежит тамже:
ftp://updates.etersoft.ru/pub/Etersoft/SE....5.20090311.msi

Русская версия selta почему ругается на "Доступ из одного каталога", на seltaEng-1.0.5.20090311.msi удалось загрузить и запустить базу ТИС(Демо).

Такого не наблюдал.
А что за ОС? А базы иницализированы были этой версией?
Это вообще странно, у русской и английской версии разные тексты лицензий и readme. Все остальное одинаковое.

Djelf писал(а): ↑
11.03.2009 15:25
Вылеты в справочниках остались, но какие то нестабильные, может и через минуту вылететь, а может и 10 продержаться... попробую поймать, как воспроизводить гарантийно.

Расстроил ты меня

А что делаешь, просто бегаешь, по справочнику, или что-то добавляешь, удаляешь? Если бы узнать, как гарантировано поймать вылет, было бы прекрасно. Включи лог SELTA, может, там последний выполняющийся запрос что скажет интересного.

Djelf писал(а): ↑
11.03.2009 15:25
Журналом/справочникам очень сильно полегчало при работе курсорными клавишами, но еще остались ощутимые подергивания при PgUp/PgDown и таскании ползунка мышью.

Это рад

Djelf писал(а): ↑
11.03.2009 15:25
Скорость проведения упала на 10% (что-то многовато). Думаю, зря триггеры установлены на регистры - основные тормоза в экранных формах, а там только справочники и журнал. IMHO только на них и надо вешать триггеры, и волки сыты будут и овцы целы.

Тут могу сказать, что в идеале транслятор должен быть универсальным. Понятно, что до этого далеко, да и вообще не факт, что достижимо, но заниматься такими вещами, как разгребать, где там 1C делает справочники, думаю не надо.
Могу посоветовать самим взять и удалить триггеры из ненужных таблиц (только не забыть удалить имена этих таблиц из таблицы pg_table_changes). Могу написать функцию, которая бы удаляла бы их из таблиц справочников, но запускать ее все равно нужно будет самому.

Djelf писал(а): ↑
11.03.2009 15:25
Вопрос: что произойдет при повторном чтении строки из курсора, если его не пересоздавать и если данные в этой строке поменялись. Будут старые данные или postgres все таки выведет новые? Как бы это проверить...

Проверить это не сложно:
Что бы сделать динамический курсор, свойства у smtp должны быть SQL_CURSOR_DYNAMIC SQL_CONCUR_READ_ONLY.
Далее SQLExecDirect c каким-нибудь SELECT. И начинаем SQLFetchScroll.
Меняем данные, делаем еще раз.
Смотрим, изменилоси ли что.

Если таблица из которой тянулись данные бала создана в SELTA :
CREATE TABLE testfetch(testpole int);
INSERT INTO testfetch VALUES (8);
То значение поменяется (курсор пересоздастся)
Что бы курсоры не обновлялись нужно сделать так (уже не в SELTA, а если в SELTA не забудьте поставить "!!" перед запросами):
INSERT INTO pg_table_changes VALUES ('testfetch',0);
CREATE TABLE testfetch(testpole int);
INSERT INTO testfetch VALUES (8);
Триггер в таком случае не создаться и данные в pg_table_changes относительно testfetch обновлятся не будут. SELTA будет считать, что даные не изменились, и будут получены данные из того же курсора. Не обновленные.
Могу выложить нехитрую програмку с помощью которой я это дело проверял.

Djelf писал(а): ↑
11.03.2009 15:25
P.S. удалось загрузить и на русской версии. ТиС попросила открыть период и после "Ок" вылетела, но период открыть успела.

Не знаю хорошо это или плохо, но только что попробовал, ничего не упало.
Еще раз спрошу, что за ОС?

Djelf · Сообщение **Djelf** » 11.03.2009 19:27

WhiteNoise писал(а): ↑
11.03.2009 17:53
Djelf писал(а): ↑
11.03.2009 15:25
Скорость проведения упала на 10% (что-то многовато). Думаю, зря триггеры установлены на регистры - основные тормоза в экранных формах, а там только справочники и журнал. IMHO только на них и надо вешать триггеры, и волки сыты будут и овцы целы.

Тут могу сказать, что в идеале транслятор должен быть универсальным. Понятно, что до этого далеко, да и вообще не факт, что достижимо, но заниматься такими вещами, как разгребать, где там 1C делает справочники, думаю не надо.
Могу посоветовать самим взять и удалить триггеры из ненужных таблиц (только не забыть удалить имена этих таблиц из таблицы pg_table_changes). Могу написать функцию, которая бы удаляла бы их из таблиц справочников, но запускать ее все равно нужно будет самому.

Универсальность это хорошо, но например у графических драйверов есть определенные настройки/твики под определенные приложения и от этого видимо уйти нереально. Если selta может как-то отличить с кем работает, лучше бы обойтись без скрипта. Тем более что разгребать особенно ничего не надо: если sc* то - справочник, если 1SJOURN это журнал, все остальное по скорости работает приемлемо.

WhiteNoise писал(а): ↑
11.03.2009 17:53
Djelf писал(а): ↑
11.03.2009 15:25
Вопрос: что произойдет при повторном чтении строки из курсора, если его не пересоздавать и если данные в этой строке поменялись. Будут старые данные или postgres все таки выведет новые? Как бы это проверить...

Проверить это не сложно:
...
Могу выложить нехитрую програмку с помощью которой я это дело проверял.

Я поверю на слово. Если проверяли, все таки новые или старые?

С падением и т.п. (WinXP SP, PGSQL 8.3.6.eter1,1С 7.7.027) попытаюсь разобраться. Возможно это у меня что-то искалечено до такого состояния

UPD: как и обещал - с падением разобрался. Самый быстрый способ завалить новую selta в ТиС - Операции/Проведение документов, падает на 3-4м документе. А ларчик открывался просто - у этой версии selta конфликт с DEP, нужно DEP перевести в режим "Только для основных служб", тогда не падает.
UPD2: Поторопился... все таки падает но значительно реже. Где то на 300м проведенном документы опять вылетел.
UPD3: Вообще отключил DEP: /NoExecute=AlwaysOff в boot.ini, пока не выпадал.

Djelf · Сообщение **Djelf** » 12.03.2009 13:30

WhiteNoise писал(а): ↑
11.03.2009 17:53
Могу посоветовать самим взять и удалить триггеры из ненужных таблиц (только не забыть удалить имена этих таблиц из таблицы pg_table_changes). Могу написать функцию, которая бы удаляла бы их из таблиц справочников, но запускать ее все равно нужно будет самому.

Еще раз проверил скорость перепроведения на ТиС(Демо) обработкой перепроведения. Обработка создает список документов, документы перепроводятся по 4 раза, в список попадает наименьшее значение. Перепроводил только Поступления и Реализации.
Все оказалось еще хуже чем казалось поначалу, средняя потеря производительности даже не 10% а все 30%. На некоторых документах падение скорости почти в 2 раза.
Удалил все триггеры кроме sc* и _1sjourn, удалил строки из pg_table_changes, добавил UNIQUE к pk_pg_pg_table_changes_tabname
На тесте перепроведения стало быстрее на 1.5% (в пределах погрешности измерения) по сравнению с версией selta без триггеров, журналы и справочники работают естественно быстро.

WhiteNoise · Сообщение **WhiteNoise** » 12.03.2009 15:43

Djelf писал(а): ↑
11.03.2009 19:27
Универсальность это хорошо, но например у графических драйверов есть определенные настройки/твики под определенные приложения и от этого видимо уйти нереально. Если selta может как-то отличить с кем работает, лучше бы обойтись без скрипта. Тем более что разгребать особенно ничего не надо: если sc* то - справочник, если 1SJOURN это журнал, все остальное по скорости работает приемлемо.

Djelf писал(а): ↑
11.03.2009 15:25
Я поверю на слово. Если проверяли, все таки новые или старые?

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

Djelf писал(а): ↑
11.03.2009 15:25
С падением и т.п. (WinXP SP, PGSQL 8.3.6.eter1,1С 7.7.027) попытаюсь разобраться. Возможно это у меня что-то искалечено до такого состояния

Это многое объясняет. Я на WinXP еще не тестировал.

Djelf писал(а): ↑
11.03.2009 15:25
UPD: как и обещал - с падением разобрался. Самый быстрый способ завалить новую selta в ТиС - Операции/Проведение документов, падает на 3-4м документе. А ларчик открывался просто - у этой версии selta конфликт с DEP, нужно DEP перевести в режим "Только для основных служб", тогда не падает.
UPD2: Поторопился... все таки падает но значительно реже. Где то на 300м проведенном документы опять вылетел.
UPD3: Вообще отключил DEP: /NoExecute=AlwaysOff в boot.ini, пока не выпадал.

Это очень интересно. Хотя DEP не должен касаться SELTA. Постраюсь сделать, так что бы от этого не зависело.

WhiteNoise · Сообщение **WhiteNoise** » 12.03.2009 15:50

Djelf писал(а): ↑
12.03.2009 13:30
WhiteNoise писал(а): ↑
11.03.2009 17:53
Могу посоветовать самим взять и удалить триггеры из ненужных таблиц (только не забыть удалить имена этих таблиц из таблицы pg_table_changes). Могу написать функцию, которая бы удаляла бы их из таблиц справочников, но запускать ее все равно нужно будет самому.

Еще раз проверил скорость перепроведения на ТиС(Демо) обработкой перепроведения. Обработка создает список документов, документы перепроводятся по 4 раза, в список попадает наименьшее значение. Перепроводил только Поступления и Реализации.
Все оказалось еще хуже чем казалось поначалу, средняя потеря производительности даже не 10% а все 30%. На некоторых документах падение скорости почти в 2 раза.
Удалил все триггеры кроме sc* и _1sjourn, удалил строки из pg_table_changes, добавил UNIQUE к pk_pg_pg_table_changes_tabname
На тесте перепроведения стало быстрее на 1.5% (в пределах погрешности измерения) по сравнению с версией selta без триггеров, журналы и справочники работают естественно быстро.

30% -- это конечно слишком много.
Я подумаю как сделать так, что бы простой пользователь мог бы ограничивать создание лишних триггеров. Либо простое удаление лишних.
Так, конечно, будут и овцы сыты и волки целы, точнее наоборот.

DjSpike · Сообщение **DjSpike** » 03.04.2009 09:23

Результатов новых нет???

arahorn · Сообщение **arahorn** » 03.04.2009 09:36

DjSpike писал(а): ↑
03.04.2009 09:23
Результатов новых нет???

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

WhiteNoise · Сообщение **WhiteNoise** » 03.04.2009 15:06

DjSpike писал(а): ↑
03.04.2009 09:23
Результатов новых нет???

Есть новая SELTA 1.0.6 (Еще пока beta ) с триггерными курсорами, тут написано, как они работают -- http://wiki.etersoft.ru/SELTA/cursorstriggers, почитайте, может какие мысли придут, изложите.
ftp://updates.etersoft.ru/pub/Etersoft/SE...ndows/selta.msi

arahorn · Сообщение **arahorn** » 03.04.2009 18:06

WhiteNoise писал(а): ↑
03.04.2009 15:06
DjSpike писал(а): ↑
03.04.2009 09:23
Результатов новых нет???

Есть новая SELTA 1.0.6 (Еще пока beta ) с триггерными курсорами, тут написано, как они работают -- http://wiki.etersoft.ru/SELTA/cursorstriggers, почитайте, может какие мысли придут, изложите.
ftp://updates.etersoft.ru/pub/Etersoft/SE...ndows/selta.msi

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

сорри за гнусный тон ибо пьян

Vladimir2008 · Сообщение **Vladimir2008** » 03.04.2009 19:37

Пробовал в связке Mandriva 2009+wine@etersoft SQL+ selta 1.05, клиенты через FreeNX, машинка AMDx2, 4 гига база после конвертации 14 ГБ
впринципе всё работает нормально, за исключением тормозов в списках(как я понял в 1.06 это поправлено), но самая большая проблема УРБД выгрузка влет, а загрузка о-о-очень медлено. на XP+MSSQL 15-20 минут а сейчас 2,5-3 часа примерно тотже объем. Кто нибудь знает как это можно лечить?

Djelf · Сообщение **Djelf** » 03.04.2009 21:50

Вот тут http://bugs.etersoft.ru/show_bug.cgi?id=2326 чуток еще не доделали
SELECT TOP 100 * FROM sc84 as СпрНом order - транслируется нормально, а если добавить ORDER BY или GROUP BY

SELECT TOP 100 * FROM sc84 as СпрНом ORDER BY что-то
selta 1.0.6 транслирует в
SELECT * FROM sc84 AS СпрНом LIMIT 100 ORDER BY что-то
а должно быть
SELECT * FROM sc84 AS СпрНом ORDER BY что-то LIMIT 100
Такие запросы делает поставщик данных (ODBCDataProvider.MSSQL) для табличного поля 1c++. Без парсинга все равно не заработает т.к. TOP 100 и ORDER BY поставщик данных добавляет к запросу сам т.е. !! не поможет.

Djelf · Сообщение **Djelf** » 04.04.2009 03:40

Для тех кто хочет потестить курсоры на триггерах в selta 1.0.6, но не хочет долго возится с их настройками, нарисовал обработку

для быстрой их установки из самой 1С. Копия обработки на slil.ru.
Управление - перетаскиванием в таблицу pg_trigger_table_mask и расстановкой галочек. В процедуре обработки масок (созданной etersoft`ом) приоритет include=false (нет галочки, нет триггера) выше чем include=true. Не забывайте нажимать кнопку "Пересоздать" вызывает pg_create_delete_trigger_from_mask() для принятия изменений.
Требует 1С++, качать отсюда: http://www.1cpp.ru/index.php/Image:Icpp-latest.rar
1cpp.dll нужно кинуть в каталог bin 1С или в каталог с базой. При первом запуске потребуются админские полномочия.
Ничего деструктивного обработка не производит, на ТиС и Комплексной проверил, вроде бы все в порядке, но на "боевой" базе лучше сразу не пробуйте.
Обработка при запуске проверяет версию базы и будет работать только на базах версии 1.0.6.

P.S. Инструкция по новым курсорам: http://wiki.etersoft.ru/SELTA/cursorstriggers

WhiteNoise · Сообщение **WhiteNoise** » 06.04.2009 12:25

Vladimir2008 писал(а): ↑
03.04.2009 19:37
Пробовал в связке Mandriva 2009+wine@etersoft SQL+ selta 1.05, клиенты через FreeNX, машинка AMDx2, 4 гига база после конвертации 14 ГБ
впринципе всё работает нормально, за исключением тормозов в списках(как я понял в 1.06 это поправлено),

Когда попробуете 1.0.6. (Наверное на "живой" базе после официального релиза), расскажите, насколько стало лучше.

Vladimir2008 писал(а): ↑
03.04.2009 19:37
но самая большая проблема УРБД выгрузка влет, а загрузка о-о-очень медлено. на XP+MSSQL 15-20 минут а сейчас 2,5-3 часа примерно тотже объем. Кто нибудь знает как это можно лечить?

Боюсь, что пока никто не знает. Но можно попробовать разобраться. Была точно такая же проблема у пользователя, но у него фалы лежали на CIFS, на что пока и списана эта проблема. Но Вы можете огорчить меня, сказав, что у Вас файлы бд лежат на сервере и обращение локальное

. И у него долго загружалось только когда запуск происходит не в монопольном режиме. (Что тоже не особо указывало на SELTA) Есть ли у Вас такие "симптомы"?

unixforum.org

1C SQL, wine@etersoft SQL , Selta (жуткие тормоза, помогите советом)

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta

Re: 1C SQL, wine@etersoft SQL , Selta